底下整理 Blog 更新的文章記錄，提供給想知道哪些文章有更動的朋友。
| 更新時間 | 更新方式 | 文章標題 | 更新說明 | 發佈時間 |
|---|---|---|---|---|
| 2026/05/21 | 新增內容 | 管理必經之路：資遣、解僱、辭呈 | 增加 23-26 資遣統計，及看法 | 2019/07/09 |
| 2026/03/28 | 新增內容 | 資訊技術與工程專有名詞 | 補充現代化技術名詞 | 2017/07/01 |
| 2026/03/28 | 新增內容 | 計算機科學專有名詞 | 補充基礎科學名詞 | 2017/07/01 |
| 2026/03/28 | 新增內容 | 經營管理專有名詞 | 補充管理名詞 | 2017/07/01 |
| 2026/01/26 | 新增內容 | Problem Behind Question | 新增相關連結 | 2022/10/15 |
這篇是整個 Blog 的全站索引，如果您是第一次來這裡，可以先看看這篇索引，大概知道 Blog 的全貌：
不管是程式、文章、資料、還是房間，我都會定期重新整理 / 重構，核心概念來自於 分類的哲學
最近除了自己持續研究 “作業系統實作“ 相關議題，跟 AI 趨勢的概念也是沒有停下來。Harness Engineering 是最近我持續在關注的課題，相關的技術也是持續在爆炸的生出來。
整理 2026/04/28 隨筆: 聊聊 AI 發展趨勢 以及 Harness Engineering 的想法。
整理 關於 AI 現象的隨筆：
主要探討的是 AI 為個人帶來的衝擊，然後如何有效經營個人的知識體系，以及個人如何真正的「慢活」。
在 《如何量測系統的容量？》 一文有提到量測的方法與概念，開頭提到思路有三種，其中 「第二個思路：以系統資源做基準值，找到理想值 / 基準值」 是該文章主要提供的論述。類似概念我在工作上也很常使用，去年 (2025) 在高雄師範大學分享的 《從應用程式 Inside-Out 出發的 Web 可靠性設計》 概念，其實本質也是類似。
去年 (2015) 記憶體還沒漲價前，我買了幾台 Mini PC，規格大概是記憶體 64GB、SSD 2TB、Ethernet 1Gbps 的規格。這主要是我的 HomeLab 的 Lab Machine，用來做各種實驗，取代原本在 NAS 上跑 VM、《學習 K8s (kubeadm 手動安裝)》，這用法曾在 《資料備份還原 - 第一原則 資料分層》 提到的。
買了 Mini PC 除了跑現在流行的龍蝦、或者開發我個人工具，「效能」與「資源」之間的平衡，一直是我很有興趣的題目。自從搞定 《從應用程式 Inside-Out 出發的 Web 可靠性設計》 裡提到類似 《AWS DynamoDB》 RCU / WCU 的 Capacity Unit 設計與實作，我對於如何「榨乾」眼前的硬體資源，取得效能極致與最佳化，一直是很感興趣的。像是 “Let’s Handle 1 Million Requests per Second, It’s Scarier Than You Think!“ 這樣的題目，這是 《如何量測系統的容量？》 提到的 「第一個思路：業務導向」，從業務目標尋找需要多少資源。
我想要知道幾件事情：
整個量測的執行第一次透過 Codex 運行、第二次我手動執行，結果主要透過 ChatGPT 整理，Gemini Pro 為輔。
實驗最後預期會得到一張表，成為 Backend Server Stack 效能上限值，這張表可以作為大部分 Backend Server 量測容量的基準線 (Baseline)，或者理想值。
註一：為了不要讓文章看起來 AI 味，原則上不使用 AI 文字。但是這種實驗數據的整理，其實 AI 生圖反而很適合。權衡之下，我在實驗結果章節，用 ChatGPT / NotebookLM 整理幾張圖總結。
註二：Concurrency翻譯使用並行非併發
四月初我買了一台電子閱讀器，讓我用閱讀方式慢下來。
第一本讀的是赫胥黎的反烏托邦小說《美麗新世界》，這算是我第三次讀了。
自幹作業系統 - Simple OS 學習筆記來到第五篇，上一篇整理了 Task 的定義、排程器概念、以及排程演算法，順著這樣的思路，往下深挖一個很重要的概念：Context Switch，中文翻譯成 上下文切換、內容轉換、環境切換，我自己習慣翻譯 上下文切換 。對應到 課程大綱 大約在 day31 ~ 36 的範圍。
本文將整理以下內容：
除了在作業系統裡，Context Switch 也可以用在人身上，代表人處於同時在很多任務之間切換，因而無法專注的現象，背後隱含著成本很高的意思。我很久以前寫的 Cost in Context Switch 就是在描述工作頻繁被干擾，造成無法專注，這種極端現象帶來的影響，以及可能的解決方法。類似概念在 Peopleware：腦力密集產業的人才管理之道 以及 心流:高手都在研究的最優體驗心理學 這些書裡也有提到。
最後再來聊聊 AI 話題，這次整理 關於 Harness Engineering 的想法與相關資料，因為概念跟我在自幹作業系統實在太像了。
最近幫一些朋友做 職涯健診，透過 1 on 1 深度對談，我總結 十點摘要 給大家做參考。下圖是朋友幫忙用 AI 產生出來的摘要圖：
重點在於：
心態轉換，找到內在動能，佈自己人生的局。
本文針對第二點：「抱怨的內容背後，往往就藏著獨特的觀點」，整理深度的分析與觀點，以及經驗分享。
職場上大家吃飯聊天最常發生的：「抱怨」，抱怨主管、抱怨公司、抱怨同事、抱怨環境、抱怨政府、抱怨競業、抱怨樓下管理員、抱怨先生/太太、抱怨房價 ….. 過了一年後，抱怨的人還是那群人，停在原地的還是那群人。抱怨沒啥問題，壓力要有些出口，但是抱怨完了之後呢？一年後不是繼續抱怨的那個人，而是不斷成長與蛻變的人。
用**「把抱怨轉化成動力」**為目標，我整理了深度分析與觀點，以及我自己的經驗分享。
註：我在整理文字內容時，用 Claude 幫忙潤稿，但 Claude 把用詞改的比較溫和，但我希望給予讀者的是更真實世界的 第一性原理 ，而不是包裝過的用詞。簡單說，我希望 講真話 大於安慰性質的內容。都在做 健診 了，解讀報告就是要面對現實。當然醫療上會有比較微婉的用詞，因為那畢竟是生死交關，醫生需要照顧患者與家屬的情緒。但自己的職涯，我覺得早點面對現實，承認自己的不足，早點爭取時間提升自己才是重點。
我很常用 FSM (Finite-State Machine, 有限狀態機) 做 系統設計 (System Design) 或者 流程規劃 (Business Flow)。因為 FSM 的 有限性，容易 收斂邊界，同時在實作上也更容易聚焦。所以從設計角度，我覺得是個非常好的設計方法。當在 Reivew 別人的系統設計時，通常我也會觀察是否有類似 FSM 概念存在，缺乏有限性的邊界，通常系統的 可靠性 與 穩定性 都不容易達成。
系統設計最常用的是 API Design、自幹作業系統的 task 分析，流程規劃則是 專案管理 (Redmine / JIRA)、或者內部系統 (資產、人事) 等。也在工作時針對這部分整理過不少教育訓練素材以及相關概念解說，但好像沒有專注整理 FSM 的資料。
這篇從我在 FB 整理的資料開始，加上 Blog 已經寫過類似的資訊做個彙整。如果有在使用 AI 設計，這篇大概就是一個 SKILL.md 的整理。
自幹作業系統 系列的第三篇整理 初探 Timer 原理 探索筆記，本來是想帶到怎麼實作 sleep()，不過 sleep 其實只是一個小小的應用而已，真正的核心是 task.c 以及裡面的 schedule() (排程演算法) 這兩個概念，本文就以這兩個為主整理相關的學習筆記。
避免篇幅過多，其中 Task 資料結構理會提到 Paging 和 Stack 之後再整理。
在 自幹作業系統 - Simple OS 的過程中，我的學習方法是快速的先取得成就感，透過與 AI 協作過程，快速刻出能動的、完整的，只用了三週就完成實作 (03/12 - 03/27)，但是非常古早味的作業系統，說白話：先能動再說，好聽的就是 麻雀雖小，五臟俱全。但往下探索，很容易暴露一個現實：知其然，不知所以然，有些東西就是沒有透測的理解。但也是這份好奇心停留在心裡，我開始往下了解與深究背後的原理以及知識，同時也連結到以前的經驗與知識 (或者資訊)。
Day12 - Timer/PIT (Programmable Interval Timer) 是我開始深究的題目，底下是我好奇的幾個點：
整理一下探索過程學習到的資料，以及自問自答相關資料。
自幹作業系統 - SimpleOS 完成第一階段之後，感覺意猶未竟，有很多東西想繼續玩玩看，所以開啟了第二階段，其中最複雜也數最有趣的是 網路基礎 (Networking Fundamentals) 部分，從最底層硬體 PCI Bus 掃描，實作驅動程式 (RTL8139)、到 Ethernet Layer (L2)、IPv4、ARP、ARP Table、UDP、TCP … 一路打上去，最後用 ping、host、wget、udprecv、tcptest 等 User Space 封裝的應用程式做驗收。
下圖是我請 Gemini 幫我畫的總結，總結第二階段網路部分的學習。
很久以前就想做的事 - 純手工自幹一個作業系統
有點瘋狂，有點無聊，但卻又超有趣！
以前做不來，是因為門檻高、網路上的資料雜亂、內容太硬核，加上沒人可以討論、工作忙碌沒時間等因素。
但現在是 AI 時代，許多過去看似困難、門檻極高的事，在 AI 的協助下都變得有趣且可行！
自幹作業系統 系列:
註：內容僅是自學的一些筆記，如果有發現資訊不正確，或者描述錯誤，請不令給予指教，感謝。
Job Description，簡稱 JD，是企業在招人，提供對外招募的資訊，包含 工作內容、以及 職缺條件。
以前花不少心思在想這件事情，這篇整理以前在寫 JD 時背後的思路與心得。
紀錄從 RyiSnow 的 Java 2D RPG Game 課程，手工完成 Java 2D RPG (Role-Playing Game) 的開發歷程與心得，遊戲玩法類似 薩爾達傳說 的 動作 RPG (Action RPG)，相關紀錄放在 Youtube 播放清單: Game Learning and DevLog、以及 Source Code。
C4 model 是一個 2018 年之後發展出來的 架構描述方式，我在 2017 年底也在組織內部弄了類似概念的表達架構方式，很巧不巧，概念很 C4 model 很像，這段想法在我的著作 SRE實踐與開發平台指南 有提到，底下用 FB 寫的草稿，讓 ChatGPT 幫我整理的想法～
整理我個人這幾年來 (Since 2017) 接觸 API 有關的議題，共分成以下的大議題：
API 設計：重點在於滿足業務需求、控制範圍，包含資料模型、設計方法、流程與驗證API 架構：API Gateway、快取、效能、通訊協議、監控 … API 治理與管理：版本控管、導入策略 (API First / Spec First / Contract First)、上架政策、訂閱管理、問題排查API 實作與模式：包含常見的機制，像是 async、pagination、tracing、idempotence、batch、bulk … 等API 軟體工程：開發方法、測試方法、開發流程、跨團隊協作、文件以及寫在 FB 的隨筆，包含 API 在當代軟體開發的重要性、設計方法論、實務經驗談，以及一些背後的思路。
整理一下我個人開發環境的資訊。
我在開發時，很習慣用 Linux 當作主要的運行環境，然後用 Windows or macOS 當作作業環境 (IDE)。主要的工作配置是：
主要是確保應用程式的 runtime 的 development and production 是一致的。
之前注意到 UTM 是因為想在 iPad Pro 上跑 Linux，但實驗後效果不如預期，所以放棄這個念頭。最近嘗試把執行環境在 Macbook Pro 上，用 UTM 跑 Ubuntu 24.04 Server，運行了差不多一個月左右，感覺還可以。過去我比較熟悉的 Virtualization 是 VMWare，連假期間順手 VMWare 兩者在 Intel 與 Apple Silicon M1 環境的效能差異。
這篇是 2022/09/12 寫下的隨筆，主要是整理軟體版本在軟體開發團隊內部、外部的意義。
版本的概念在我的職涯生涯裡，對個人來說幾乎是常識，而且大部分 Open Source Software (OSS) 也都是這樣，如下圖。但實際上在軟體開發團隊的經驗裡，很難直接套在團隊上，因為普遍的團隊，無論怎樣的角色，對於版本是沒有概念的。
特別感謝 DevOps 艦長 陳正瑋 幫忙整理文字的摘要，如下：
其中，商業思維學院 院長 Gipi 也參與了討論，交換了不少想法，很有共鳴～
這篇是我在 2023/09/07 聊到關於 Code Generator (底下簡稱 codegen or CodeGen) 的經驗與想法。
整理自 FB 20200615 的隨筆，針對底下這段話的延續探討：
系統思維好系統有三個特徵：抗打擊、自組織、以及中央控制和子系統自治要有一個平衡關係 —— 這三個特徵明顯更符合生態系統的特徵。
這些三點，背後有各自的問題與實際案例。
聊聊 NAS 的一些心得，整理 Facebook 寫的草稿。
討論 NAS 這種「解決方案」之前，應該先好好想清楚，資料對於自己而言，到底有多重要？
NAS 對我來說核心價值就是 備份資料 與 還原資料，所以對於「資料」的存放，過去從早期用光碟備份資料，到後來使用 NAS，這麼多年的經驗累積下來之後，我設計了一些原則，定義備份與還原資料的原則，如下圖，第一原則：資料分層原則 (如圖)
多租戶架構 (Mulit-Tenancy Architecture, 以下稱作 MTA) 是 SaaS (Software as a Service, 軟體及服務) 設計的核心議題，也是我過去幾年工作研究的題目之一，大部分的人針對這個題目討論的多是 K8s 的 Namespace 劃分、或者資料庫的拆分方式、使用 Single or Shared / Hybrid … 等策略。
多租戶架構背後需要討論的，除了這些技術架構的議題，更重要的是往前一步：
SaaS 的
多租戶應該怎麼定義？以及能夠解決那些問題？
基於這些討論與實踐，最後我提出設計 MTA 的關鍵抽象概念，我把它稱為 Isolation Factor (隔離因子)。
這篇文章嘗試解釋與探討 多租戶 背景與核心議題，同時用真實世界的租賃關係，剖析設計 SaaS 時必須要知道的概念，嘗試帶出 Isolation Factor 的重要性。
相關文章：
去年 (2022) 受邀 AWS Career Exploration Day 分享職涯的想法，今年因為個人因素，無法到現場。但是在主辦單位熱情的邀約以及協助下，改用錄影的方式，延續去年分享的想法～
Updated: 20231122 媒體的報導: 迎向 AI 與雲端共融世代，如何校準自身技能成長策略？
這篇整理自今年二月跟朋友分享的內容，主要是關於溝通效率的目錄、總整理。
整理一段關於 SRE 問題的訪談紀錄，歡迎大家提供不一樣的經驗與想法。
API 存在的目的，最早期是程式邏輯可以重複使用，例如 時間相關的工具，透過標準的介面定義，以及模組化的概念，每個人在開發應用程式的時候，都可以引用同一個函示庫，透過標準介面就可以調用。像是 Java 語言的 java.util.Date 這樣的標準介面，所以 API 的概念就出現了。
API First 在跨企業的系統交互越來越頻繁的今天，提供有效的擴展業務的方法。過往什麼功能都要自行開發，但卻因為內部資源不足；亦或錯估新業務規模的深度與需求層次，造成投入沒有成效、或者必須不斷的加碼投入，最後才意會到，這是個獨立領域，需要獨立的專業團隊，像是 MarTech、支付、通訊 …
API First 的概念，背後是雙方在技術上彼此溝通的通訊協議，透過這層協議，雙方可以更快速的仰賴彼此的擅長的領域，進而拓展業務。最常見的就是電商與支付系統、廣告服務、電信系統、物流業、與 ChatBot / AI … 等整合。
開放 API 是個策略性決策，背後代表著要與合作夥伴達成策略聯盟，本質上是 B2B 的商業行為；同時開放 API 也意味著內部系統需要有高度整合，提供對外統一介面與標準，讓合作夥伴在開發過程，可以有一致性的使用介面與理解。
基於這樣的前提，只要是 API 對外開放、或者是內部整合，都要面對本文要提到的問題：API 通訊模式與協議
