這篇是整個 Blog 的全站索引，如果您是第一次來這裡，可以先看看這篇索引，大概知道 Blog 的全貌：
不管是程式、文章、資料、還是房間，我都會定期重新整理 / 重構，核心概念來自於 分類的哲學
底下整理 Blog 更新的文章記錄，提供給想知道哪些文章有更動的朋友。
| 更新時間 | 更新方式 | 文章標題 | 更新說明 | 發佈時間 |
|---|---|---|---|---|
| 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 |
| 2025/12/22 | 新增內容 | 簡介 HTTPS / TLS 安全通訊協議 | 新增 SSH 交握過程 | 2021/08/20 |
| 2024/10/06 | 新增內容 | 如何用 G Suite 整合 AWS Single Sign-On | 紀錄更新憑證的流程 | 2019/05/30 |
| 2024/09/14 | 重構結構 | 從 經營管理 中，新增 人才管理、知識管理、溝通、Career 四個 Category，調整文章分類 |
新增目錄 | |
| 2023/07/01 | 新增內容 | 面試常見的問題 | 新增錄影 | 2020/06/21 |
| 2021/08/21 | 更新參照 | 資深軟體工程師 | 新增參考資料 | 2015/08/22 |
| 2021/04/30 | 新增資料 | 關於軟體測試，一些觀察到的現象 | 新增軟體測試管理工具的選擇 | 2019/10/30 |
我很常用 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 通訊模式與協議
原文是 2021/06/14 寫下的 memo，摘錄一場失敗的會議有哪些現象，與另一篇 一場有效的會議 成對比。
2022 年初的時候，經過朋友的介紹認識成大資工系 李信杰 教授，因此才有了這本書的誕生。
李老師對軟體工程非常有熱情，特別是軟體測試領域，是全球最熱門開源測試軟體 Selenium IDE V3、Katalon Recorder 與 Qualys Recorder 原型創造者。
在 Macbook Pro M1 (Apple Silicon) 安裝 K3s 的筆記。
只要是軟體開發，不管 Web Services、還是 Mobile 或 Desktop Application，都會需要建置 (Build) 與交付 (Delivery) 兩個核心過程。Web Services 的交付稱為部署 (Deployment)，應用程式稱為發佈 (Publish)。而這些過程，也伴隨著一些衍生的任務 (Task)，組成一連串的行為，隨著時間的推進，架構的改變，這些任務的組合，往往是工程師們的夢靨的開始。
工作上經常問題還沒被看清楚，只求快，要有成果，往往都只是做表面工作。
這篇整理自 2022/09/08、2022/07/22 我自己的思考的筆記，延伸 QBQ (問題背後的問題) 以及 如何意識到問題的存在，我自己深度體悟與昇華後的心得。
