Business
某個下雪天，我拖著病體，組裝一套供使用者簡報之用的破爛系統，莎朗進來發現我在操控台前勉強支撐，她便離開了，幾分鐘後，她端著一鍋湯回來，為我倒了一杯，我的精神為之一振。我問她要做的管理工作那麼多，怎麼會有空做這種事，她向我展露她的招牌微笑，說：「湯姆，這就是管理。」 －《Peopleware: Productive Projects and Teams》 有次跟一名職涯顧問聊天。我提到：「我希望透過打造產品來替別人創造價值，如果有很棒的團隊，我相信自己能辦到。」她問：「團隊是必須的嗎？」我愣住了，隨口說：「因為打造產品需要很多不同的職能……還需要可持續性的運作，對，我想團隊是必要的。」事後回想，她的問題很有趣，現代社會好像把「團隊」和「領導」當成是成功的標配，人力市場也一堆團隊主管的職缺，這是一則現代神話嗎？還是某種工業革命時代的遺產？ 身為個人貢獻者的管理者 不是說團隊不重要，只是在現代，你會用不同的角度審視完成目標需要的條件。你想想，如果你是個開發者，自己架網站、
Web
Phil Karlton 有句名言：「計算機科學中只有兩件難事：快取失效和命名。」 想像你在管理網站，因為傳輸速度與伺服器效能問題，網站讀取速度很差，特別是當你的使用者來自地球另外一端，常常需要等待幾秒才能看到畫面，這讓他們的使用體驗大打折扣。身為一名重視使用體驗的開發者，你肯定知道該如何解決這問題，沒錯，答案就是 CDN（內容傳遞網路）。 CDN 可以看成是服務商在全球各地建置伺服器，當你的網站內容（例如圖片、CSS、JavaScript、影片等）流經這些伺服器時，它會保留一份複本（稱為快取），等到下次有人讀取同樣的內容，CDN 會拿出複本給使用者。因為全球各地都有 CDN 節點，美國的使用者可以由美國節點提供，日本的使用者可以由日本節點提供。這樣既加速網路傳遞效率，也降低來源伺服器的效能壓力，可謂一舉兩得。 當然這是有條件的。CDN 會使用網址來判斷快取是否是相同檔案，假設你的內容以圖片為主，通常來說，當你更換圖片，新舊兩張圖片會有不同網址，被當成兩個不同的檔案，新圖使用新快取，舊快取留著也沒差；但如果你的內容是文字，新舊版文字很可能有相同網址，
Business
想搬家想很久，連身邊的朋友都搬完了，我還沒動工。 原因是我懶，我討厭麻煩，每次有人問我吃什麼，我都回答麥當勞。搬家是一件麻煩事，我已經有一份很讚的工作了，全副精神都放在工作上，偶爾才會想起來，反正家什麼時候都能搬，一點也不急，有什麼好急的呢對吧。這樣一拖，就拖到現在。 繼續用 Medium 不好嗎？ 跟男女朋友分手一樣，通常被問到：「對方不好嗎？」得到回答是：「也沒有不好啦，只是……（以下開放填空）。」 從優點開始講吧！Medium 的編輯器很棒，它是 WYSIWYG（所見即所得）類型的編輯器，能讓創作者快速發佈內容，也因為它讓內容發佈更容易了，它開始吸引一批優秀的創作者，這批創作者持續創作內容，又吸引來更多讀者，更多讀者激勵創作者產出內容，內容又再吸引讀者……這形成一個增強迴圈。Medium 還能支援多人協作，拜它時尚簡約的風格所賜，科技公司會使用 Medium 來打造品牌形象，例如我前公司的 Tech Blog
Observability
點進 OpenTelemetry 的官方文件，它最先映入眼中的句子是「什麼是 OpenTelemetry」。例如，它是套可觀察性框架，用於檢測、蒐集與導出遙測數據；它是開源且供應商中立，能搭配其他的開源工具，像 Jaeger 或 Prometheus；它能將應用程式與系統儀表化，無關是用 Go 還是 .NET 開發，也無關部署在 AWS 還是 GCP 上。 但是身為一名開發者，當下我們想的是：「公司常開發一些沒人要用的功能，聽說 OpenTelemetry 可以提高可觀察性，也許我們應該放棄開發功能，轉頭建立更好的開發環境。」「AWS 常常要不到需要的數據，也許我們應該改用另一套工具，像是 OpenTelemetry，來解決這件事。」我們想像 OpenTelemetry 「應該」要能解決目前面臨到的一些問題，就像在技術的鏡像中尋找願望一樣。 如果已經有在用 Sentry，還需要導入 OpenTelemetry
Go
Ian Lance Taylor 在 "Range Over Function Types" 這篇文章聊到 iterator 誕生的原因。如果我們有兩個容器，稱為集合(Set)，想要取得這兩個集合中的不重複元素，加到新的集合中形成聯集，我們可以寫個 Union 函式來執行 // Set holds a set of elements. type Set[E comparable] struct { m map[E]struct{} } // Union returns the union of two sets. func Union[E comparable](s1, s2 *Set[
Web
OAuth 2 讓網路服務可以存取第三方的受保護資源，因此，有些開發者會進一步利用 OAuth 2 來進行使用者認證。但這中間存在著一些語義落差，因為 OAuth 2 當初設計目的是「授權」而不是「認證」，兩者關注的焦點會有些不同。OpenID Connect 是基於 OAuth 2 的一套身份認證協定，讓開發者可以在 OAuth 2 授權的基礎上，再加入標準的認證流程。在這篇文章中，我會說明授權跟認證的場景有何差異，並講解 OpenID Connect 如何滿足認證需求。 因為 OpenID Connect 是建構在 OAuth 2 的基礎上，我會假設這篇文章的讀者已經知道 OAuth 2 的組件與流程，如果你不熟悉，可以先閱讀另外兩篇文章 * OAuth 2.0：
Security
因為 HTTP 是無狀態協定，為了保持使用者狀態，需要後端實作 Session 管理機制。在早期方式中，使用者狀態會跟 HTTP 的 Cookie 綁定，等到有需要的時候，例如驗證身份，就能使用 Cookie 內的資訊搭配後端 Session 來進行。但自從 JWT 出現後，使用者資訊可以編碼在 JWT 內，也開始有人用它來管理使用者身份。前些日子跟公司的資安團隊討論，發現 JWT 用來管理身份認證會有些風險。在這篇文章中，我會比較原本的 Session 管理跟 JWT 的差異，並說明可能的風險所在。 Session 管理 Session 是什麼意思？為什麼需要管理？我們可以從 HTTP 無狀態的特性聊起。所謂的無狀態，翻譯成白話，就是後面請求不會受前面請求的影響。想像現在有個朋友跟你借錢，
Go
從併發的角度來看，Goroutine 跟 Thread 的概念很類似，都是將任務交給一個執行單元來處理。然而不同的是，Goroutine 將調度放在用戶態，因此更加輕量，也能避免多餘的 Context Switch。我們可以說，Go 的併發處理是由語言原生支援，有著更好的開發者體驗，但也因此更容易忘記底層仍存在著輕量成本，當這些成本積沙成塔，就會造成 Out of Memory。這篇文章會從 Goroutine 的生命週期切入，試著說明在併發的情境中，應該如何保持 Goroutine 的正常運作。 因為這篇講的內容會比較底層，如果對應用情境不熟的人，建議先看過同系列 * Goroutine 的併發治理：由錯誤處理談起 * Goroutine 的併發治理：值是怎麼傳遞？ * Goroutine 的併發治理：管理 Worker Pool 再回來看這篇，應該會更容易理解。 Goroutine 的資源使用量 讓我們看個最簡單的例子，假設現在同時開
Go
併發會需要多個 Goroutine 來同時執行任務，Goroutine 雖然輕量，也還是有配置成本，如果每次新的任務進來，都需要重新建立並配置 Goroutine，一方面不容易管理 Goroutine 的記憶體，一方面也會消耗 CPU 的運算效能。這時 Worker Pool 就登場了，我們可以在執行前，先將 Goroutine 配置好放到資源池中，要用時再調用閒置資源來處理，藉此資源回收重複利用。這篇文章會從 0 開始建立 Work Pool，試著丟進不同的場景需求，看看如何實現。 基本的 Worker Pool Worker Pool 的概念可以用這張圖來解釋 Job 會放在 Queue 中送給 Pool 內配置好的 Worker，Worker 處理完後再將結果送到另一個 Queue 內。因為這是很常見的併發模式，
Ken Chen 的技術部落格，聊聊後端開發、Go 語言、DevOps 與系統架構等話題。
當併發時，每個 Goroutine 可以看成是一個個單獨的個體，他們維護著自己的 Call Stack，彼此互不干涉。如果希望這些默默運行的 Goroutine 攜手完成任務，就要在他們之間建立一種通訊方式。在 Go 中，資訊應該如何被傳遞？其中的權衡又有哪些？這篇文章會介紹 Goroutine 常用的三種值的傳遞方式，以及相關衍生議題。 使用閉包取得值 第一種方式是使用閉包。先來想想輸出應該要長怎樣，假設建立 100 個 Goroutine，每個 Goroutine 會收到一個值並印出來，傳給 Goroutine 的值應該都要不同，最後印出來的結果會是 0 到 99。這裡用 time.Sleep 模擬長時間的處理，用 println 印出值來觀察操作結果。程式碼是 func main() { var wg
當需要同時執行多個任務時，Go 開發者會多開 Goroutine 來分擔任務，這稱為併發。併發聽起來似乎很理想，能其他任務等待時，照樣執行需要運算的任務，有效利用 CPU 資源，但如果要用在生產環境，它也需要完善的管理機制。想想看，Goroutine 在哪個情況下會被啟動？哪個情況下會結束？如果任務需要回傳結果，它應該要怎麼回傳？而如果執行中發生錯誤，又應該怎麼處理？ 我們可以稱呼這類主題為「併發治理」，需要開發者理解執行期的運作，而如何處理好 Goroutine 的開始與結束，讓錯誤能被意識到，可說是併發治理的第一關。 基本併發 來看個基本的併發操作。我們起 100 個 Goroutine，讓它們處理任務。如果執行時發生 error，就呼叫 HandleError 處理錯誤。 func main() { var wg sync.WaitGroup for i
「設計模式」這個詞出自 Christopher Alexander 的《建築模式語言》，這本書出版於 1977 年，主題圍繞著建築，城市設計和社區宜居性。作者 Alexander 是一名建築師，他在意的是，能不能找到一種切實可行的模式語言，讓讀者用以設計辦公室、車庫或公共建築。 儘管這樣的期待難免於可操作性，但在另一方面，Alexander 同時是名評論家跟創作者，在創作的過程中，他也想知道，現實繁複的表象下，是不是存在某種共通性，能用於解釋建築間特定的規律？我們可以看到作者羅列出 253 個模式，像是活動中心(30)、墓地(70)與啤酒館(90)，Alexander 說：「每一模式描述我們周圍環境中一再發生的某項問題，接著描述解決該問題的關鍵所在，如此一來，你就能上萬次利用這種解決方式，而不必每次從頭來過。」 如同描述資料的資料稱為「後設資料(metadata)」，描述語言的語言稱為後設語言，而 Alexander 給這套後設語言起的名字是「
在上一篇的結論中，我們講到開發者通常最想知道，開發 OAuth 2.0 客戶端需要什麼知識。後端工程師要實現 OAuth 2.0，最常見的情境是開發一個客戶端應用，用來存取資源擁有者的受保護資源。因此在這篇中，我們將用 Go 來牛刀小試一番，開發一個網路應用，它會取得使用者同意後，跟 Google 拿取使用者姓名並顯示出來。 註冊客戶端 不是隨便哪個應用都能跟 Google 授權伺服器申請授權，要跟授權伺服器互動，首先要人家願意信任你。因此，在開始寫程式前，要先到 GCP 的 APIs & Services 中註冊客戶端，連結是這個 點選 CREATE CREDENTIALS 並選擇 OAuth client ID，創造一個新的客戶端憑證 我們要開發的是個網路應用，Application type 選
在前一篇中，我們討論了 OAuth 2.0 的角色與信道，知道 OAuth 2.0 將授權模型劃分為四個角色，讓它們經由前／後端信道交流，完成整個授權許可流程。在這篇中，我們要進一步來討論，具體的授權許可是什麼？我們將改由時序的角度出發，探討模型中的物件如何交換訊息。如果覺得這段話太抽象，可以理解成，上一篇介紹了遊戲中的角色與道具，而在這篇，我們將來介紹遊戲的流程與規則。 底下的介紹會著重在授權碼許可(Authorization Code Grant)跟隱式許可(Implicit Grant)兩種 Web 應用場景的授權許可。至於資源擁有者憑證許可(Resource Owner Password Credentials)跟客戶端憑證許可(Client Credentials)，雖然在 RFC 6749 有提到，但因資安風險較高，需要資源擁有者非常信賴客戶端且沒有其他方式情況下，才會拿來使用。 Authorization
使用者體驗是 B2C 重要的產品面向。通常一個網路服務，會要求使用者註冊帳戶後才能開始使用——以台灣金融保險法規為例，使用者需要建立帳戶後，才能得到報價。站在行銷觀點，註冊會降低用戶的轉換率，因為它需要填寫姓名、暱稱、生日、信箱等資料，步驟相當繁瑣，對行動場景，這百分百是個負面體驗。這讓人不禁想問，這個環節是可以優化的嗎？ 事實上，我們可以合理假設使用者資訊已經存在社群媒體中，例如 Google、Facebook、Twitter、GitHub，而我們需要的只是請求使用者同意，讓我們可以代表使用者，存取社群媒體中受限制的資源。也就是，我們關注的是有沒有一個授權框架，可以讓第三方應用取得對資源的訪問權限。 OAuth 2.0 這就帶到 OAuth 2.0 想要解決的問題。在傳統的 Client-Server 認證架構中，當客戶端要存取伺服端資源時，需要提供使用者的帳號密碼。如果發起請求的是第三方應用，則資源擁有者要將帳號密碼提供給第三方應用。可以想像，你需要請人幫你收信，就需要把家裡鑰匙交給對方。
在雲原生的環境中，程式通常採用容器部署，而不同環境間所需要的配置也會不同，像是開發環境的資料需要與生產環境分離；金絲雀部署要分流生產環境的流量，但不會寫資料到生產環境中；開發環境為了除錯，要印出 level 低的 log；開發環境跟生產環境要拿取的 key vault 的 key 跟 version 不同；等等。在雲原生的時代前，開發人員或維運人員通常會各自維護一份執行的程式，開發在開發環境中驗證後，交付維運部署上線，一次性處理好配置；但在雲原生時代，部署變得越來越頻繁，幾乎不太可能手動管理。這時要把問題倒過來想，不是因應開發出來的程式來設定配置，而是有沒有可能，因應部署會遇到的問題來設計開發？ Store config in the environment Heroku 基於 SaaS(Software-as-a-Service) 實踐，歸納出 12 條雲原生應用的設計原則，稱為 The Twelve-Factor App，其中關於配置，
對分散式系統來說，消息的可靠性非常重要，想想一個金融應用的場景，如果在支付時，消息遺失了，或是重複遞送了，都會造成使用者的困擾。當我們在系統中引入消息隊列時，我們同時引入了複雜度，這意思是，系統的「處理消息」跟你想的不一定是同一件事。從可靠性的角度來看，「處理消息」的語義可以分為三個層次，第一層是「最多一次」，當你請系統處理消息時，它會幫你進行，但最多一次，並且不保證是否完成；第二層是「最少一次」，系統會幫你處理消息，而且附帶必要的錯誤處理，確保消息至少被完成一次；第三層是「準確一次」，意指消息不多不少，恰恰好被準確處理並完成了一次。 當試著從語言學的角度來看待系統時，我們才能規劃出系統的整體面貌。儘管「準確處理一次」有最佳的可靠性，但因為其處理成本，降低了系統整體的吞吐量。在〈Starbucks Does Not Use Two-Phase Commit〉一文中，Gregor Hohpe 精確描繪了星巴克的異步系統。收銀員收費後，
錯誤處理是 Golang 最常被討論的一個點。這有幾個因素，首先，這跟它「錯誤是值」的設計理念有關，開發者需要在業務流程中穿插錯誤處理，違反關注點分離的原則，當然會引發爭議。另外，在 1.13 前，Golang 標準 errors 庫的表現力有限，當需求較為複雜時，需要開發者自行發明錯誤處理輔助函式。這讓人不禁好奇，Golang 的錯誤處理設計原則是什麼？有沒有比較好的實踐？或者說，我們能不能找到一種方式，優雅地處理錯誤？ 錯誤與異常 先來看看不同人的觀點，Robert Martin 在討論到錯誤處理時，是如此建議的 使用異常替代返回錯誤碼，錯誤處理代碼就能從主路徑代碼中分離出來，得到簡化 他給出的例子是 try { deletePage(page); registry.deleteReference(page.name); configKeys.deleteKey(page.name.
錯誤處理是所有 RPC 服務都要具備的設計，但是怎樣的錯誤處理模型，算是好的模型呢？從字面上來看，錯誤處理可以分解成「錯誤」跟「處理」，如果用 RESTful 的觀點，將錯誤當成是 Resource，一個好的模型應該要能匹配不同場景的 Resource，並根據場景需求來處理這些 Resource。 錯誤模型 在 RESTful 中，通常會用 HTTP Status Code 當錯誤訊息的分類(Category)，錯誤內容則放在 Payload。這樣的好處是，只要看到分類，就能先進行大方向的處理，如果需要特定資訊，再從 Payload 拿取。通常錯誤內容的格式會自行定義，以支付服務 Stripe 的 API 為例，定義的格式就有 * type (string) * code (string) * decline_
對現代開發者來講，單元測試已經不是可選，而是必備了。單元測試能保護程式碼，讓錯誤提早現形，也能讓重構時更安心。通常我們在評估單元測試的執行狀況時，會用 coverage 當成其中一項指標。當然，coverage 還是會有一些使用的場合跟侷限，當談到專案落地，可能大家會想知道的是，coverage 該怎麼使用，才能幫助到專案？ 開發、審查、回顧 我們先來看看什麼時候會需要知道 coverage？通常依照團隊的工作流程，將它分為三個階段：開發、審查、回顧。每個階段關注的場景會略有不同。 一個一個講。對開發中情形，開發者想知道的是剛寫完的邏輯是否能正常運行，有沒有對應的測試，覆蓋範圍是否已經足夠，如果還有條件分支沒覆蓋到的話，是哪裡？是不是每個錯誤都有處理了。這時最需要的是，codebase 要能 highlight 剛剛講的資訊，幫助開發者一眼掌握。 當開發完成，feature branch 被提交到原始碼管理系統，例如 GitLab，會需要一名
相信平常開發時，即使沒真的用到，也會聽別人提起「依賴注入」的概念。我們都知道依賴注入的目的是解耦模組間的依賴，但具體來說，依賴注入應該要怎麼進行呢？Go 對於依賴注入有什麼比較好的實踐呢？這篇就來談談 Go 相關的依賴注入話題。 常見的實踐方式 講到依賴注入，從 OOP 的觀點來看，可以回到 Martin Fowler 的 SOLID 原則，其中的 Dependency Inversion Principle 落實到編程中，就是依賴注入。James Grenning 曾經簡單扼要說明 DIP 原則的出發點 Martin tells us that high-level modules shouldn’t depend on low-level modules. 這裡，高層級的模組指的是商業邏輯的實現。依賴反轉原則之所以重要，
