在這篇中，我們要進一步來討論，具體的授權許可是什麼？我們將改由時序的角度出發，探討模型中的物件如何交換訊息。如果覺得這段話太抽象，可以理解成，上一篇介紹了遊戲中的角色與道具，而在這篇，我們將來介紹遊戲的流程與規則。…

當需要取得使用者資訊時，我們可以合理假設，使用者資訊已經存在社群媒體中，例如 Google、Facebook、Twitter、GitHub，而我們需要的只是請求使用者同意，讓我們可以代表使用者，存取社群媒體中受限制的資源。也就是，我們關注的是有沒有一個授權框架，可以讓第三方應用取得對資源的訪問權限。這篇文的出發點是想探討 OAuth 2.0 的授權模型。讓開發者在選擇授權許可時，能理解角色間的互動，還有設計上要注意的資安風險。…

在雲原生的時代前，開發人員或維運人員通常會各自維護一份執行的程式，開發在開發環境中驗證後，交付維運部署上線，一次性處理好配置；但在雲原生時代，部署變得越來越頻繁，幾乎不太可能手動管理。這時要把問題倒過來想，不是因應開發出來的程式來設定配置，而是有沒有可能，因應部署會遇到的問題來設計開發？…

對分散式系統來說，消息的可靠性非常重要，想想一個金融應用的場景，如果在支付時，消息遺失了，或是重複遞送了，都會造成使用者的困擾。當我們在系統中引入消息隊列時，我們同時引入了複雜度，這意思是，系統的「處理消息」跟你想的不一定是同一件事。從可靠性的角度來看，「處理消息」的語義可以分為三個層次，第一層是「最多一次」，當你請系統處理消息時，它會幫你進行，但最多一次，並且不保證是否完成；第二層是「最少一次」…

錯誤處理是 Golang 最常被討論的一個點。這有幾個因素，首先，這跟它「錯誤是值」的設計理念有關，開發者需要在業務流程中穿插錯誤處理，違反關注點分離的原則，當然會引發爭議。另外，在 1.13 前，Golang 標準 errors 庫的表現力有限，當需求較為複雜時，需要開發者自行發明錯誤處理輔助函式。這讓人不禁好奇，Golang 的錯誤處理設計原則是什麼？有沒有比較好的實踐？或者說，我們能不能找到一種方式，優雅地處理錯誤？…

錯誤處理是所有 RPC 服務都要具備的設計，但是怎樣的錯誤處理模型，算是好的模型呢？從字面上來看，錯誤處理可以分解成「錯誤」跟「處理」，如果用 RESTful 的觀點，將錯誤當成是 Resource，一個好的模型應該要能匹配不同場景的 Resource，並根據場景需求來處理這些 Resource。 在 RESTful 中，通常會用 HTTP Status Code…

對現代開發者來講，單元測試已經不是可選，而是必備了。單元測試能保護程式碼，讓錯誤提早現形，也能讓重構時更安心。通常我們在評估單元測試的執行狀況時，會用 coverage 當成其中一項指標。當然，coverage 還是會有一些使用的場合跟侷限，當談到專案落地，可能大家會想知道的是，coverage 該怎麼使用，才能幫助到專案？…

相信平常開發時，即使沒真的用到，也會聽別人提起「依賴注入」的概念。我們都知道依賴注入的目的是解耦模組間的依賴，但具體來說，依賴注入應該要怎麼進行呢？Go 對於依賴注入有什麼比較好的實踐呢？這篇就來談談 Go 相關的依賴注入話題。…