我算是 Travis CI 的老用戶了。

以前 Travis CI 很慢，對 Docker 不友善，又很難 debug，讓我一度將重心轉移到後起之秀 CircleCI。後來 Travis CI 向 CircleCI 看齊，讓我們能夠 ssh 進去虛擬機 debug，兩者的差距已經逐漸縮小。所以，我自己的重要專案，總是盡量同時掛上 Travis CI 及 CircleCI，讓 CI pipeline 的核心在某種程度上也能盡量 reproducible 不被 lock in。

Travis CI 也提供許多常見的程式語言及伺服器軟體，以方便做 CI 測試。我個人的習慣是，盡量不去使用這些功能，而是直接用 Docker 或 Docker Compose 來組裝，以降低對於 Travis CI 的依賴（尤其我還要兼顧 CircleCI）。

不過，如果是與人合作的專案，就得顧及其他人的習慣。我在使用 Travis CI 提供的伺服器軟體 Postgres、Cassandra、RabbitMQ 時，遇到一些雷，特地記錄下來，供有類似困擾的人參考。

實體看板

在導入 Scrum 時，我偏好實體看板。

實體看板容易 zoom in/out，利於適時切換俯瞰與細節視角，不需過度的數字管理。

實體看板的空間共時性，容易塑造團隊的一體感。

實體看板彈性大，能以最小成本，讓團隊在敏捷路上不斷嘗試與調整。

RESTful API 時代，我們有許多簡單好用的測試工具：有酷炫的 Postman，有命令列控愛用的 HTTPie，當然也有硬漢必備的萬用瑞士刀 curl。

那麼，gRPC 呢？

這篇文章介紹兩個好用的小工具：gRPCurl 及 ghz，一個是輸入輸出介面測試工具，另一個是壓測工具，也順便介紹一些簡化測試的技巧。

Kubernetes 有個很方便的地方：只要修改 deployment 的 spec.replicas 數字，就能橫向擴展 pod，以應付更大的流量負載需求。

這一招，對於 stateless 的 HTTP 服務很管用，也是 Kubernetes 入門教學愛用的例子。但是，對於 gRPC 呢？

最近幾年，在微服務打滾的人，不時會遇到神祕的 “idempotency key” 字眼。本文爬梳 idempotency key 的技術背景，探討運作流程，並分析資料庫的實作選項。

Idempotency 冪等性

在 API 服務中，常常需要留意 idempotency（冪等性）。

名詞：idempotency，形容詞：idempotent。

“Idempotency” 這字眼源自數學。維基百科是這麼解釋 “idempotent function” 的：