第 158 期 - 順利度過雙十一了嗎?

本週專欄

Understanding Exactly-once Semantics

大家好,這週的專欄是 Starbugs Writers 俊廷 所發表的 「Understanding Exactly-once Semantics」。在服務與服務之間傳送消息時,因為網路可能會不穩定,所以要做到「只處理一次」消息其實不是一件容易的事情。因此這週的專欄想要跟大家分享「只處理一次」在 Producer、Consumer 跟 Sink 的角度可能會遇到怎麼樣的困難,以及相對應的解決方式。

前端開發

Why you should never use px to set font-size in CSS

這有點標題殺人的意味,但是作者只是想在文章裡面表達,開發者要清楚他在 CSS 內所使用的單位意義是什麼是非常重要的事。

Improve your TypeScript Skills with Type Challenges

在 GitHub 上面有一個 type-challenges,裡面有許多關於 TypeScript 的型別問題,如果你已經學會基本的 TypeScript 且想要更深入了解型別原理的話,就很適合挑戰這個 repo!

5 websites to learn Frontend-web development faster

在文章中列出了 5 個網站可以幫助你學習有關前端開發的技能,其中最喜歡的是第一個網站 exercism 能夠根據你想學習的技能繪出學習路線,讓在學習時不會突然迷失下一步的方向。

軟體工程

團隊協作 Git Flow

為了讓工程師們可以有效率的協作,很多公司都會使用 Git Flow 或 Github Flow 來進行開發,這篇文章詳細解釋了 Git Flow 到底解決了什麼問題、已經實際的開發流程會長什麼樣子,推薦給未來可能會進入軟體業的莘莘學子們~

抽象層 — 重要的幾件事

程式寫久了,就會發現在寫程式的過程中,常常會需要把底層的東西給抽象化,如此一來我們才可以從更高的層次來思考如何解決問題。而關於抽象化,這篇文章舉了幾個很生活化的例子,文章不長建議大家都可以讀讀看。

Fundamental Software Architectural Patterns

在看很多協定、函式庫的架構時,會發現有一些 pattern 是很常見到的,譬如 TCP/IP 就是以 Layer Pattern 來設計,而 Docker 則是用上了 Client Server Pattern。學習這些 pattern 可以讓我們參考前人的經驗,設計出更好的軟體。

DevOps

17 DevOps Metrics You Should Be Tracking

除了服務 metrics 之外,作者建議 17 個 DevOps 相關的 metrics 也需要被追蹤,metrics 主要的方向有:

  • DORA Metrics,用於測量組織開發
  • Cycle Time,另外一種測量組織開發產能的 metric
  • 品質,可以整合在 CI pipeline 做測量
  • 客戶的回饋
  • 員工滿意度,對於文件、意見是否被聆聽到、組織是否接受失敗等等
  • CI 平均所花的時間、一天跑幾次、壞掉的恢復時間、測試失敗率和成功率
  • 穩定率,用來測量 CICD pipeline 是否會因不明原因失敗
  • Code Coverage
  • 錯誤逃逸率,測量有多少正式生產環境的錯誤是 CICD pipeline 裡沒有偵測到的
  • 正常運行時間
  • SLI(Service Level Indicator)
  • 平均意外察覺時間,當服務發生意外時,要多久 on-call 人員才會被分配搶救任務
  • 平均意外發生時間,當新的功能上線後多久才會有意外

Technology in the Cloud Native Maturity Model

CNMM(Cloud Native Maturity Model)用於檢視組織 Cloud Native 轉型是否成熟,並且以 5 個面向來做分析:商業產出、人、政策、流程和技術。除了本文外,可以直接看 CNCF GitHub 有更詳細的說明

9 Best Practices for Designing Microservice Architectures

微服務一直都不容易駕馭,作者推薦 9 個實踐方法(但裡面只有 8 點)讓微服務架構設計更成功:

  1. 嘗試事件風暴
  2. 實踐情境繪製
  3. 在一開始規劃好網路
  4. 盡量自動化
  5. 了解遷移到微服務真正的原因是什麼
  6. 工具互動性保持簡單
  7. 架構保持彈性
  8. 考慮使用混沌工程

Kubernetes

Why you shouldn’t use Kubernetes

其實每過一段時間就會有人提出不一定需要使用 Kubernetes 的想法,這次看到這篇文所提出的論點為 1) 太複雜,因為一座嶄新的 K8s Cluster 其實是無法使用的,你必須要安裝適合自己的 Ingress Controller,或是 Storage Provider 給 Persistent Volume 使用,同理可證,為了監控,安全性或是其他的功能,你就需要再安裝更多的套件,這些額外安裝的東西都會需要有人熟悉且去維護它,除此之外也耗費了不少的 CPU 與 Memory 資源

再來是太昂貴,因為 K8s Cluster 就跟其他的分散式系統一樣,會需要更多額外的資源來確保可用性與擴展性,如同前一點所述,你為了讓 K8s 變得堪用,你必須要安裝超多額外的東西,後面當然就是更多反應在帳單的雲端資源,除此之外應用服務的部屬方式也必須要改變,所以作者建議大家可以考慮看看先使用其他的 PaaS 或是 FaaS 平台來滿足需求,而不一定要在一開始就選擇使用 K8s 這麼龐大的解決方案

Selenium Grid Using K8S

對於瀏覽器自動化測試有經驗的人,應該或多或少都會聽過 Selenium,而 Selenium Grid 是可以讓自動化測試平行運行在多台機器中的方式,這篇文章便是要分享如何將 Selenium Grid 整合到 K8s Cluster 中,讓自動化測試可以平行化第運行在 K8s Cluster 中,讓測試人員可以事半功倍!

How to validate Kubernetes YAML files

活在當年的 IT 領域中應該很難避免去使用 YAML 檔案,甚至有人都會戲謔地稱自以為 YAML 工程師,而這篇發布到 Cloud Native 部落格的文章便想要跟大家分享如何去驗證準備要給 Kubernetes 使用的 YAML 檔案,文中提到驗證的方式可以從幾個面向來看,分別是結構,語義和安全性;而在驗證時的最佳準則就是確保 Shift Left 的精神落實,讓 DevOps 往 DevSecOps 邁進,對於此議題有興趣的朋友可以參閱內文

StarBugs Weekly

StarBugs Weekly 由一群不寫文章就會想要亂花錢,但是又沒有那麼多錢,只好繼續寫文章的開發者所創立。
內容包含 Web 前端、中端、後端、DevOps、產品開發、精實創業,一切跟產品有關的知識,都是我們的守備範圍!
不想漏追科技新聞的人,趕緊把 StarBugs Telegram Bot 訂閱起來 https://t.me/starbugs_weekly_bot (對機器人說 /subscribe 即可)

另外,為了讓 Starbugs 的專欄有更多豐富、優質的內容,我們決定要開始誠徵 Writer 了。如果你本來就有在寫文章,對於文章的品質有要求、而且也樂於分享討論技術,那很歡迎你以 Writer 的身份加入我們。請動動手指頭私訊我們粉專 星巴哥技術週刊,並附上自我介紹跟最近寫的文章,就有機會加入我們唷 🙌

Writers:

  • @HannahLin - 從台灣到矽谷,熱愛前端的工程師女孩。
  • @KyleMo - 雜食性軟體工程師,喜歡的技術我都想學。
  • @Airwaves - Hi~我是 Airwaves,熱愛研究如何造輪子的前端工程師。
  • @Andy - 目標成為用嘴巴工作的工程師,專長為網頁開發以及 K8s。
  • @lazypro - 從 embedded 到 kernel,從 device 上雲端,程式無涯、無法靠岸,軟體的求道者。
  • @ianchen0119 - 5G 領域研究生,同時也是喜歡學習不同領域技術的工程師。
  • @00-talk - 我是 00,脖子痠痛的前端生命鬥士。

Maintainers:

  • @GQSM - Hi!我是神 Q 超人,一個先衝再說的男人。
  • @LarryLu - 我是 Larry,傳說中的 0.1 倍工程師!
  • @LukaTW - 一名全身都是死角的工程師。
  • @smalltown - 熱愛鑽研各種可以提升雲端服務品質及增進團隊開發效率的開源技術。
  • @RicoChen - 熱愛許多技術且努力看透技術的本質,如果有什麼好玩的技術,還請各位歡迎直接找我聊聊。

Feedback

本週呈現主題方式做了一些改變,希望讓讀者能夠更快速精準的找到自己要的資訊。也加入社群活動這個區塊,每週更新社群活動的資訊。如果有任何建議,歡迎私訊 星巴哥技術週刊 FB 粉絲專頁 與我們聯繫。