這篇是整個 Blog 的全站索引，如果您是第一次來這裡，可以先看看這篇索引，大概知道 Blog 的全貌：
不管是程式、文章、資料、還是房間，我都會定期重新整理 / 重構，核心概念來自於 分類的哲學
底下整理 Blog 更新的文章記錄，提供給想知道哪些文章有更動的朋友。
| 更新時間 | 更新方式 | 文章標題 | 更新說明 | 發布時間 |
|---|---|---|---|---|
| 2024/10/06 | 新增內容 | 如何用 G Guite 整合 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 |
我在開發時，很習慣用 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 (問題背後的問題) 以及 如何意識到問題的存在，我自己深度體悟與昇華後的心得。
上一次的分享 之後，開始有 QA 的朋友找我聊很多他正在面對的問題。其中一個問題是：
Backend 開發人員說建立環境很難？是這樣嗎？
本文針對這個問題，整理背後可能的問題，以及實際可行的方法。全文整理自 09/18 在 FB 寫的草稿。
在 “淺談軟體測試的階段與策略“ 整理了各種測試的 “階段”，其中 #整合測試 (Integration Test) 是常見的階段之一，針對 “整合” 我的脈絡有以下：
功能對功能 的整合系統對系統 的整合功能對系統 的整合引用我 上次分享 整理的文字描述，如下圖：
Source: 演講：從理想、到現實的距離，開啟品味軟體測試之路
20230523 更新: 本文部分收錄在 共同著作《軟體測試實務》 第一冊 第五章之中，歡迎大家彭場指導。
每個人對於寫 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 分享這幾年的一些心得與想法。
