API First 在跨企業的系統交互越來越頻繁的今天，提供有效的擴展業務的方法。過往什麼功能都要自行開發，但卻因為內部資源不足；亦或錯估新業務規模的深度與需求層次，造成投入沒有成效、或者必須不斷的加碼投入，最後才意會到，這是個獨立領域，需要獨立的專業團隊，像是 MarTech、支付、通訊 …

API First 的概念，背後是雙方在技術上彼此溝通的通訊協議，透過這層協議，雙方可以更快速的仰賴彼此的擅長的領域，進而拓展業務。最常見的就是電商與支付系統、廣告服務、電信系統、物流業、與 ChatBot / AI … 等整合。

開放 API 是個策略性決策，背後代表著要與合作夥伴達成策略聯盟，本質上是 B2B 的商業行為；同時開放 API 也意味著內部系統需要有高度整合，提供對外統一介面與標準，讓合作夥伴在開發過程，可以有一致性的使用介面與理解。

基於這樣的前提，只要是 API 對外開放、或者是內部整合，都要面對本文要提到的問題：API 通訊模式與協議

原文是 2021/06/14 寫下的 memo，摘錄一場失敗的會議有哪些現象，與另一篇 一場有效的會議 成對比。

2022 年初的時候，經過朋友的介紹認識成大資工系 李信杰 教授，因此才有了這本書的誕生。

李老師對軟體工程非常有熱情，特別是軟體測試領域，是全球最熱門開源測試軟體 Selenium IDE V3、Katalon Recorder 與 Qualys Recorder 原型創造者。

在 Macbook Pro M1 (Apple Silicon) 安裝 K3s 的筆記。

這是一場很特別的活動：雲端職涯探索日 (104專區)，第一時間 AWS 的邀請我就毫不猶豫的答應了 XDD

只要是軟體開發，不管 Web Services、還是 Mobile 或 Desktop Application，都會需要建置 (Build) 與交付 (Delivery) 兩個核心過程。Web Services 的交付稱為部署 (Deployment)，應用程式稱為發佈 (Publish)。而這些過程，也伴隨著一些衍生的任務 (Task)，組成一連串的行為，隨著時間的推進，架構的改變，這些任務的組合，往往是工程師們的夢靨的開始。

工作上經常問題還沒被看清楚，只求快，要有成果，往往都只是做表面工作。

這篇整理自 2022/09/08、2022/07/22 我自己的思考的筆記，延伸 QBQ (問題背後的問題) 以及 如何意識到問題的存在，我自己深度體悟與昇華後的心得。

架構師的工作到底是做啥？用一張十年前 (2012) 我自己在 Plurk 寫下的定義，然後再真實經歷之後，重新回顧這段話。

Plurk Permalink

這篇是我在粉專寫下的 隨筆文，放在 blog 做個紀錄。

上一次的分享 之後，開始有 QA 的朋友找我聊很多他正在面對的問題。其中一個問題是：

Backend 開發人員說建立環境很難？是這樣嗎？

本文針對這個問題，整理背後可能的問題，以及實際可行的方法。全文整理自 09/18 在 FB 寫的草稿。

在 “淺談軟體測試的階段與策略“ 整理了各種測試的 “階段”，其中 #整合測試 (Integration Test) 是常見的階段之一，針對 “整合” 我的脈絡有以下：

1. 功能對功能 的整合
2. 系統對系統 的整合
3. 功能對系統 的整合

引用我 上次分享 整理的文字描述，如下圖：

Source: 演講：從理想、到現實的距離，開啟品味軟體測試之路

20230523 更新: 本文部分收錄在 共同著作《軟體測試實務》 第一冊 第五章之中，歡迎大家彭場指導。

整理對 Development Experience (DX) 的看法，原文草稿發表於 Facebook。

之前 很常跟朋友分享這段想法，底下把想法記錄下來。

我把工作上遇到的問題分兩大類：

1. 雜 (Complicate)
2. 難 (Defficult)

每個人對於寫 Blog 這件事情，都有自己背後的動機，我的初衷跟寫程式一樣，透過不斷的重構精練，這個過程是我學到最多的。

今天很高興在 台灣軟體工程協會，成功大學 李信杰 老師的邀請之下，讓我第一次分享關於軟體測試的想法與心得。

在投入 軟體測試 (Software Testing) 與 軟體品質 (Software Quality Assurance, SQA) 之前，我主要的工作角色是 軟體開發 為主，程式語言以 PHP / Java / Python、開發大型 Jave Enterprise Application 應用程式與 Eclipse Plugins 為主。過程中因為協助測試團隊改善 Application UI / WebUI 測試，因而踩入測試領域。

因為本身是具備開發背景，踩入軟體測試有別於一般人經歷，因此開啟不一樣的路。實際軟體測試的經歷，包含 WebUI / Desktop UI / Unit Test / E2E … 等自動化測試，設計與開發大型 “Test Framework and Architect for Regression Test“ 實務經驗。

這段經歷讓我對軟體測試的 技術與工程面 有很完整的歷鍊，所以後來也挑戰 在新創事業 (IoT 領域) 從零開始 建立軟體測試團隊，從團隊建立、制度、流程、工程、協作，建立完整的開發流程，其中領悟出最重要的 心法 就是 品質 的想法，因此寫下以下領悟：

品質不只有測試，而是整個 (開發) 過程。
品質從需求開始，測試只是種手段
用品質建立數量，由數量產生速度。

測試金字塔 是很多書、很多演講都會提的概念，從上到下是 E2E、Integration、Unit Test，佔比也是這個次序。

很多大神、知名的軟體教練、傳教士、訪間的訓練機構也都一再強調 Unit Test (以下簡稱 UT) 的重要，經過幾年的宣導與討論，基本上，現在很多軟體工程師都自己會先做 Unit Test，或者在跑 Scrum 時都有出現 Task 內容是要做 Unit Test。對於整個軟體產業而言，是個很好的現象。

這年代跑 Scrum 也越來越普遍，大家也有意識到一個 Scrum Team 就是在做一個產品，大概就像 天龍特攻隊 (A Team) 、或者是阿湯哥 不可能任務、或者一個 搖滾樂團 ，都是 Team Work，理論上，要交付的是一個共同的價值。

整理關於 SaaS 架構設計的想法，部分是來自於 Eclipse 這個著名 Java IED 的設計概念。

大約從 2018 之後，VSCode 可以算是統一 Open Source 的 IDE 了，之前由 GitHub 開發的 Atom 在微軟收購了 GitHub 之後，已經將在 December 15, 2022 落下了句點，其他 Editors (還不到 IDE) 大多還是屬於輔助性質，像是 Notepad++ 。

而 VSCode 主要的設計者 Erich Gamma 則是著名的 Design Pattern 的共同作者之一 (又稱 GoF)，而這個理論背後源自於他的實作，也是著名的 Java IDE - Eclipse，Erich Gamma 負責最核心的 JDT (Java development Tooling) 的設計。

2004 - 2012 年期間，我在 IBM 駐點開發 Rational 相關產品，其中主要就是 Eclipse Plugins 的開發，產品是給 Web Developer 用的工具，可以說就是在寫 IDE 的概念。過程曾經鑽研了 Eclipse Plugins、RCP (Rich Client Platform, XMind / DBeaver 就是這個開發的) / Equinox OSGi / SWT / JFace / EMF / GEF … 等設計概念，也因此對於 Eclipse 整個架構略有研究，而這些設計概念也不知不覺的用在之後工作上。

這些年的更迭與代換，我自己的工作環境 從 Windows 換到 macOS，開發工具從 Eclipse 換到了 Atom，然後又跳到 VSCode。在使用 VS Code 的過程，處處都聞到 Eclipse 的設計感。開始做分散式架構設計、重讀作業系統、學習 CS 基礎知識、探索 AWS / K8s … 等過程，發現這些背後的本質都有高度的雷同。

感謝 AWS 與 主辦單位 (iTHome) 的邀請，讓我在 04/29 有機會在第一次的 SRE Conf 分享這幾年的一些心得與想法。

這篇是我在 2021/05/23 寫的一篇關於 Developer 的條件寫的文章，我自己覺得這樣的要求是不過分的，但是，可能跟很多現代的過念有所差異，特別是一些從外面的培訓機構訓練出來的學生。

應用程式 在啟動 or 初始化 (Initial / Startup)的時候，配置 (Configuration) 載入的流程經過這麼多年的發展，基本上已經有一個常見的策略模式了，這些概念很重要，卻也很常被忽略，最後系統上線後只能夠透過改 Code 重新部署才能處理問題，好的設計應該是改配置就能滿足需求。

這篇原文是寫在 SRE 社群的一篇 筆記，借保哥的 整理 發揮另一個常見的東西：配置與設定的讀取策略設計

幾年前的分享 聊聊軟體交付的濫觴 - 談產出物管理，簡報最後面留幾個問題讓大家思考。

最近有朋友私下敲我，問了最後一個問題：

分支策略 跟 Artifact Management 的關係？

問題背後是他在新創團隊裡，遇到在處理分支策略的同時，也遇到如何打包 Artifact ，兩者的衝突與矛盾。

底下是我針對這個問題整理的摘要。

本文重新整理我在 FB 寫的草稿，之後嘗試錄了一段口述，提供給大家參考。

怎樣做好溝通、有效的溝通一直以來都是管理者的工作範疇之一。也因此我一直在探索背後的本質問題，像是 溝通的原理、表達與溝通的差異、會議原則、一場有效的會議

底下整理幾篇今年隨筆寫下的想法，主要是關於 團隊溝通的通訊協議 的想法。

• 2021/09/24: 通訊協議與團隊溝通
• 2021/05/10: 團隊溝通的標準化

AWS 把 EKS 本身開源了，稱為 EKS Anywhere，除了在 AWS 自己之外，也可以安裝在私有 (on-premises) 的環境。

本文整理體驗的筆記，我在 macOS、ubuntu20.04 都有做過，本文記錄則以 ubuntu 20.04 為主，內容以參考 EKS Anywhere 官方文件為主。

一直以來，都有朋友會找我聊 職涯規劃 的問題，整理幾段我敲在 Facebook 上的隨筆

• 2021/06/25: 談探索自我
• 2019/04/21: 談退休

內容以職涯角度切入，談的是 探索自己，然後延伸到 生死、退休 … 等。

很高興有機會被推薦成為 2021 年的 AWS Community Hero。

感謝 AWS Leslie 的推薦，過程中 Kim 得協助，讓我有機會可以有這份榮耀。

底下是 AWS 官方公告，截圖作紀念：

Announcing the latest AWS Heroes – August 2021

過去幾年，沈浸在 AWS 的技術領域，我自己很享受學習 AWS 的過程，很多想法都在研究過程中激盪出來，最終把想法實際落地。

今年 (2021) 我開始有機會專注在新一代基礎架構設計，過去累積的經驗與想法、從學習 AWS 中累積的能量，有機會動手一一實踐。

HTTPS 也稱 HTTP over TLS、HTTP over SSL、HTTP Secure，是透過計算機網路安全 通訊協議 (Protocol)。

在 摘要密碼學與資訊安全 整理了部分的關於 TLS 協議的資料，本文重新整理我自己對於 HTTPS 這個通訊協議的理解。

上一篇整理了 Dapr Secret Store，本文繼續整理分散式系統很重要的通訊模式： Pub/Sub

大部分開發者聊到 微服務架構、分散式系統，都會談到 服務發現 (Service Discovery) 這個東西，讓開發者的應用程式可以透過他知道別的服務的位置。

這是視角的問題，開發者習慣從 App 內部往外 看 (白箱)，由內而外通訊需要知道的就是一個服務清單，然後對照相關的資訊。服務發現 (Service Discovery) 就是這樣的東西，大部分也會順便負責一些 Health Check、Service Status 的提供，但是有個很關鍵的問題是大部分服務發現沒有的，就是服務的 生命週期管理 與 服務實例 (Service Instance) 管理 。

而實際上，系統是要給人用的，系統需要被治理、管理，這個角度則是 由外往裡 看的，也就是 黑箱 的概念。

特別整理一段跟朋友的對話，聊聊這幾年我對於服務治理的看法。

在這年代不管是開發單體應用架構、還是分散式系統，不管怎樣的語言、平台，都要處理這個問題：

機敏性資料，如 資料庫連線、第三方串接的 API Token …

這些東西不管在哪個年代都要處理，在這個 DevOps、DevSecOps、經常有 資安事件 的年代，實際的解決方案就顯得更重要了，從 Key Management、Secret Management 都是很重要的過程。其實三大公有雲也都有對應的解決方案，像是 AWS Secret Manager, Azure Key Vault, GCP Secret Manager … 經過一些時日，對於 Dapr 的基本概念與實際架構有了初步認識之後，第一個我想了解的就是 Dapr 如何處理 Secret Manager 這件事情？

上一篇整理了 Dapr 概念與設計，本文整理 Dapr 如何透過 Building Block，實際整合各種 Secret Store 的方法，以及實際要注意的事項。

前面兩篇先從體驗 Dapr 開始，從 Self-Hosted 到實際 Run on K8s 的體驗，大概了解的 Dapr 實際上怎麼用。Dapr 背後實際上把 分散式系統概念 與 微服務架構實踐的挑戰 、以及 K8s 圍繞這三個主題做了全面性的考慮與設計，特別是 Kubernetes Patterns 一書的作者 Bilgin Ibryam 提出 Multi-Runtime Microservices Architecture 的概念之後，加上 Dapr 這樣的分散式應用框架的出現，我感覺到下一個世代的來臨。

Bilgin Ibryam 的 The Evolution of Distributed Systems on Kubernetes、Multi-Runtime Microservices Architecture (簡中翻譯)，還有 Kubernetes Patterns 這些資料很直得一讀。

本文整理在 Study Dapr 過程中，整理背後設計的思路與概念。

上一篇 整理了體驗 Dapr 在本機模式的 Hello World，Dapr 在官方文件稱為 Self-Hosted，這篇要體驗則是 Run on K8s。

最近看到一篇有趣的文章，標題是： Java and C# are Obsolete in the Age of Docker

很有趣的題目，可以梳理一些觀念，整理一些想到的比較與想法。

Dapr 是微軟開發的 Distributed Application Framework。核心概念是 Sidecar 模式，搭配 Building Blocks、Components 等類似 Middleware / Pipeline 的概念，以及 K8s CRD (Custom Resource Definition) 的 擴充 Extensions / Plugins 的機制，以這些為主要設計的結構，然後完善大部分分散式系統 (或者說 Microservice) 所必要的基礎建設、開發體驗、維運考量、及架構擴展的需求。

這些概念與特性疊加起來實在是非常吸引我，加上 Dapr 本身很輕量，版本也已經到了 1.0 版，官方宣稱 production ready，可以一試了！底下是探索性的整理使用體驗。

在這之前，我也 Study 過類似的框架，其中有 Line 的 Armeria、carousell 的 Orion … 不過概念以及考量的成熟度，還是 Dapr 比較完整。

Shell 是使用者與作業系統溝通的介面，人機介面的形式分成 CLI 與 GUI 兩種。CLI (Command Line Interface) 讓一堆指令可以透過 指令搞 (command script) 變成自動化 程序 (procedure)，提高工作效能，這樣的指令搞我們把它稱為 shell scripts，中文通常翻譯成 程式化腳本、Shell 指令搞。

Shell 本身也是一個程式，但是他並沒有一個表準的型態，不同作業系統使用的也不盡相同。Unix-like 上最基本的 Shell 叫做 sh，全名是 Bouren Shell，是個 POSIX 標準。Bash 全名是 Bourne Again Shell，是 sh 的 superset。sh 與 bash 有點像 vi vs vim 的關係。

Unix / Linux 上很常用 Bash Script 做一些工作，本文整理 Linux 上的 Shell 和 Bash Script 重要的概念 … 等 外在因子。

• 註一：Shell 中文為 殼，由法國計算機科學家 Louis Pouzin 在 1964-1965 年間提出來的概念，後來實作在 Multics 上，而 Multics 後來催促 Unix 的誕生。
• 註二：中文的 程序 一詞，有時候指的是作業系統的 process 概念，是個實際上佔有資源的單位；有時候也指的是 procedure，指的是一段 作業流程 (workflow)，後面描述視狀況會增加英文註記。

標題是最近 (2020/10) 在 Facebook 上的熱門話題，經過幾天之後，看了很多業界高手、前輩、專家的熱烈討論之後，沈澱了幾天，昨天 (10/17 Sat) 午休睡醒後迷迷糊糊寫下的， 原始文章連結 … 過程中，陸續修補一些想法和參考資料。

Updated:

• 2023/07/19: 本文全文內容收錄在個人著作 《SRE 實踐與開發平台指南》 - 2023/08 上市
• 2026/06/17: 「星期五要不要部署」五年後：當主詞不再是人

原文是 2020/08/13 寫下的 memo，主要是有效的會議，最後一段則是 08/06 寫的一段想法，也是會議效率化的想法。與標題相對應的，則是 一場失敗的會議。