這篇是整個 Blog 的全站索引，如果您是第一次來這裡，可以先看看這篇索引，大概知道 Blog 的大方向，介紹分成 置頂文、熱門文章、最新更新、一些 Q&A 幾個部分。
底下是置頂文（也是目錄），也是希望第一次來的讀者可以從這裡看到全貌的：
不管是程式、文章、資料還是房間，我都會定期重新整理，基本的概念來自於這篇 分類的哲學
一直很想找一些人，這些人有個特質：喜歡思考事物的本質性、背後的故事、問題、原理、抽象化、延伸、想像，像是：
星艦企業號 這樣的劇情？這篇整理站內熱門文章。依據 GA 最近三個月的排名整理。如果發現別字、或者想法疑惑，都歡迎留言跟我討論。
這篇整理是這個 Blog 最近更新的文章記錄，如果你是第一次、或者是老朋友，想要知道我最近更新哪一些文章，可以從這裡知道。
| 更新時間 | 文章標題 | 發布時間 |
|---|---|---|
| 2018/08/10 | AWS Certified Solutions Architect - Associate 準備心得 | 2016/04/22 |
| 2018/08/07 | 思考本質、實踐、抽象、想像力、教育 | 2017/11/26 |
| 2018/08/07 | 推薦：Site Reliability Engineering (SRE, 網站可靠性工程) | 2018/08/03 |
| 2018/08/06 | 聊聊分散式系統 | 2018/06/17 |
| 2018/08/06 | Artifacts Management | 2018/07/08 |
| 2018/08/05 | Stages in Software Testing | 2018/07/22 |
| 2018/08/05 | 輕鬆聊：系統測試 (SVT) 的三兩事 | 2018/07/22 |
這個 Index 整理跟 軟體工程實踐 相關的文章，重點在 實踐與執行，主要內容包含以下：
(Execution)：執行管理實踐方法，像是 Redmine 應用與整合、相關工具 (VSTS)(Research)：研究新技術相關資料，計算機科學、網路、資料結構、演算法，新技術應用，像是 AWS Study Roadmap(Development)：程式、資料庫應用(Acceptance)：Quality Assurance and Testing(Operation)：上線 現場 (Live) 前、中、後，像是 CI/CD、SRE、Monitoring、Observability、事件管理DevOps 我個人傾向於用整個企業的角度來看，而不是產品研發單位個別看，請參閱 經營管理
AWS 範圍很大，有系統的學習是必要的。就像以前學音樂一樣，從各個面向整理 學習地圖，試著拼這張圖，過程中就可以知道自己哪裡還有缺，把缺的補上 (擁有技能)、把圖拼出來 (擁有知識)、把他們連結 (Connected and Linked) 起來 (產生智慧)、用他們創造 (產生創意)。
底下這張 mindmap 則是我自己的分類、重要性、以及學習的進度狀況，用以看到全貌：
以下依照 AWS Services 的分類，整理過去的心得筆記。
經營管理是我正在學習的領域。因為工作職務關係，斷斷續續都有在讀類似的書籍，工作上經常需要思考相關的事情。因為這樣寫了一些比較屬於筆記性質的文字，有時候回來翻翻看看，覺得似乎慢慢形成自己的一套方法與哲學，雖然很多都還不夠成熟與完整，但總是自己的思考的足跡。
分類這些心得如下：
最近研讀分散式系統時，遇到兩個常出現的議題：
整理最近瀏覽的資料。
SRE 全名是 Site Reliability Engineering 網站可靠性工程，是 Google 提倡的系統管理實踐之道、指導思想，這個名詞同時也是 軟體工程師 (Software Engineer) 的角色，可以類比於傳統的維運工程師或系統工程師，但是 SRE 是用 計算機科學 和 軟體工程 手段，實踐 大型系統維運、分散式系統 的設計與開發。
本文整理重新摘分在 Stages in Software Testing 整理的效能測試部分。
應 AWS 的邀請，在 06/28 讓我有機會站上台灣技術研討會的至高點之一：AWS Summit ，分享在公司導入 API Gateway 的心得！這是個難得而且讓人興奮的機會！同時 AWS User Group Taiwan 也是邀請我分享心得，兩場時間很近，所以同樣主題，兩個時間點 06/28、07/28 我用不同的形式，跟不同的族群做了分享！
Artifacts 是 CI/CD 很關鍵的點，他承接著接下來整個 Development Pipeline 的樞紐因子，能否有靈活、有彈性的佈署，都仰賴於 Artifacts Management。
Artifact 的目的就如同交付軟體給另一個陌生人，他可以透過取得一個檔案 (通常是壓縮檔)，然後解開後，依據 README.md 的說明，不管手動還是自動，可以自行完成部署或者安裝。而這個過程交付的 一個檔案 就稱作 Artifacts，在 github 上來講，就是 releases 上的檔案，像是 awscli
昨天跟同事聊到識人、用人，我提出這樣的想法，要知道一個人能否解決問題的前提，這個人要意會到什麼『是真實的世界』，舉例個誇張點的例子，例如：
有些人是活在被保護的環境之下長大的，從來就不知道：坐車是要錢的、漢堡不是從樹上長出來的、飛機是人造的，牛肉不見得是牛做的 …
這例子聽起來很誇張？是嗎
整理資料，回顧之前寫的東西，常常覺得這些就是要不斷地拿出來提，特別是分散式系統 (Distributed Systems) 已經是現代架構的常態，他就跟組織一樣，要面對各式各樣 依賴性、內外聚合、可控性、可治理、可觀測、網路拓墣、效能、快取、錯誤處理 … 等問題，這些問題不只可以對應到系統，也可以對應到人、組織 (康威定律)。
整理 分散式通訊系統 (Distributed Message Systems) 相關的基本概念，包含名詞定義、常用情境、實作技術、架構樣式、以及參考資料。
在整理 Overview API Gateway 一開始就提到關於 架構的可視性 (Visibility) 的問題，討論了可能的應用場景與實務架構問題。當時 AWS 的 API Gateway 並沒有 Private 的概念，預設只有 Regional 和 Edge 兩種類型，而且都是 Public。跟同事討論架構時，大家提出內部服務也需要 Gateway 達到類似限速、安全性控管的功能。
今天一早起來看到 API Gateway Private Endpoint 終於發佈了！期待已久，簡單整理筆記與心得！
上上週在一個 公開的演講 (Monitoring) 之後，去搭捷運時遇到一個陌生朋友，走過來跟我握手，說他聽了我某次的 演講之後 (Ops as Code) ，很有感，講到他遭遇的問題、處境，這次他又特別來聽我講，我心想：大概就是遇到同溫層吧，我只是把那些問題點出來而已～很高興他的 Feedback，讓我又更確認這些問題不是只有我一個人遇到。
幾個月前跟朋友聊到架構的問題，那時候我們在外面一起吃飯，我坐在一根柱子旁。
Role And Responsibility 簡稱 R&R，用軍中術語就是：
Role 談的是能力，也就是 技能 (Skills)
Responsibility 談的是責任，達成什麼 任務 (Mission)
底下整理我在思考這件事情過程的思路以及分析。
整理某天 (04/14) 跟同事聊到 獨立思考 這個題目，整理一些想法。
整理在 OS X 使用 Go Version Manager 的筆記，類似於 Node.js 的 NVM ，方便設定 golang version 的管理工具。
《產品、組織有沒有靈魂，看名字就知道了。你的兒女會隨便取名？》
《軟體開發流程要有 魂 與 體，敏捷精神 是魂，協作系統則是 體。》
新版的 AWS Certified Developer (Release June 2018)，考試代號 (DVA-C01)，範圍果然改了，多不少東西。
關於 SRE CH34 章提到跨領域的 緊急應變 (Emergency Response) 例，我舉了比較不同的領域：音樂 驗證同樣的概念。
由 DevOps Taiwan 主辦的活動： Monitoring Tools 大亂鬥
準備的時候思考要講什麼，整理以下的觀點：
Stages in Software Testing 提到過去因為需要自動化 Regression Test，然後設計、開發 Test Framework / Architecture 的經驗。最近也有人在問我怎麼做這件事情，重新整理一下這段經歷的分享，補充了一些資料。
本文延續 Amazon API Gateway 裡很重要的觀念：限速 Rate Limit、Throttling、Burst 等概念。
Rate Limit 概念在 SRE CH21: 處理系統超載 (Handling Overload)、Service Mesh 都有直接關聯。
整理如何使用 Amazon API Gateway 當作 Proxy 直接存取 DynamoDB，而不需要透過 Lambda。
接續前一篇 Compare GCP VPC Network with AWS 的整理，繼續整理如何透過 VPN 把 GCP 和 AWS 的 VPC 串接起來，形成 Hybrid Cloud 架構。
在 PTT Soft_Job 看到這篇討論： 敏捷課程觀察心得
我的看法跟這位差不多，不是反對敏捷，覺得敏捷就是種『軟體開發管理』的『原則』、『方法』、『概念』、『精神』 … 用我個人的詞彙來說，就是『有節奏的軟體開發方法』
音樂沒有節奏，就不是音樂。
導入能否成功，跟團隊、組織、文化很有關係。
敏捷宣言 沒有啥規則，就是概念，換言之『抽象』。抽象的好處是，怎麼解釋都可以，最後太抽象會衍生出各式各樣的分支，或者因為講者個人特色，變得很有特色，有點像是宗教。如果團隊、組織沒意會到是在做 軟體開發 的工作，而是用工廠的思維在管理，那『敏捷』到最後是穿西裝打領帶的宗教儀式。
底下整理一些觀察到的現象與想法。
整理 AWS 2018Q2 還有 AWS Summit San Francisco 2018 發表的新功能。
前一篇 『導入 CI/CD 的第一步』提到了一些基本觀念、想法，這篇繼續整理一些關於 軟體開發過程，怎樣的 CI/CD 才算是有品質。一般介紹 Jenkins、Gitlab CI、Drone 的課程重點在於怎麼利用工具串接 CI/CD Pipeline 的 Task / Jobs，除了這些，怎麼讓 CI/CD 真正達到團隊合作，我想是非常重要的。
底下是我看 CI/CD 做得好不好的 驗證點 (Verification Point)，夠不夠 Quality 就看這些了 (好像在做認證一樣 XD)：
由 DevOps Taiwan 主辦的活動： Monitoring Tools 大亂鬥
我會用：人們不會買你買什麼；他們買你的為什麼 這個角度切入，分享一些想法、實務經驗，有興趣的朋友一起來聊。
這是今天 (2018/03/29) 在 iThome 主辦的活動 - Serverless All-Star 分享的主題： Ops as Code using Serverless，主軸如同過往，用問題開場、以說文解字切入，然後帶到 現場 (Live, 真實案例)，帶出新技術的價值，強調 軟體工程 的重要性，最後帶到反思。
