實體看板

在導入 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” 的：

在網路上看到 Joe 喟然嘆曰：「今天重要功課：仔細看過明天 20 位履歷課同學的履歷以及繳交的功課。說起來這堂課好像是我們最耗能的一堂課，完全是做功德的一堂課。」

我，身為履歷表價值鏈另一端的面試官，也很能瞭解這番滋味。¹

近年來，履歷教戰守則廣傳，有專書，甚至還有專門課程。理論上，「不懂得 包裝美化履歷 正確呈現履歷」的低級錯誤應該會越來越少見——其實不然。驚訝的是，即使是獵頭轉來的履歷也常無法倖免，真不知該怎麼說了。

遇到比較多的反例，是沒有亮點。