Thinking, Coding, and Learning.

先生不知來自何方,亦不知歸去何處,年過而立,參悟生與死,淡泊名與利,但憂天下蒼生。蹤跡走紅塵,藏身山林田野,撫琴於搖滾,振筆於網路,傳道於教學;神遊金庸武俠,往返程式思考,常以此樂而忘眠。... 更多關於我

置頂 - 最近更新文章 2018/07/08 10:30:00

底下整理的是這個 Blog 最近更新的文章記錄,如果您是第一次來這裡、或者是老朋友,想要知道我最近更新哪一些文章,可以從這裡知道。

更新時間 更新方式 文章標題 發布時間
2019/04/07 重構結構 Study Notes - Virtual Private Cloud (VPC) 2016/02/21
2019/04/04 重構結構 Study Notes - EC2 Auto Scaling 2017/02/04
2019/04/04 調整結構 Resource Provisioning and DevOps 2017/02/11
2019/03/23 增加段落 Overview API Gateway 2018/01/24
2019/01/18 增加段落 Artifacts Management 2018/07/08
2019/01/11 增加段落 怎樣的 CI/CD 才夠 Quality? 2018/04/01
2019/01/06 重構結構 學習法則 2017/09/20
2019/01/06 增加段落 聊聊人力招募 2017/02/04
2019/01/06 文句修飾 Go Live 2017/11/14
2019/01/05 文句修飾 需要專職的 Release Engineer? 2018/12/16
2018/12/26 重構系列文 Study Notes - CloudWatch 2017/03/02
2018/12/22 重構系列文 Study Notes - CloudFormation 2017/03/30
Read More

置頂 - 全站索引 2018/07/08 10:30:00

這篇是整個 Blog 的全站索引,如果您是第一次來這裡,可以先看看這篇索引,大概知道 Blog 的全貌:

不管是程式、文章、資料還是房間,我都會定期重新整理,基本的概念來自於這篇 分類的哲學

Read More

一直很想找一些人,這些人有個特質:喜歡思考事物的本質性、背後的故事、問題、原理、抽象化、延伸、想像,像是:

Read More

置頂 - 軟體工程實踐之道 2017/07/01 10:30:00

這個 Index 整理跟 軟體工程實踐 相關的文章,重點在 實踐與執行,主要內容包含以下:

  • 執行 (Execution):執行管理實踐方法,像是 Redmine 應用與整合、相關工具 (VSTS)
  • 研究 (Research):研究新技術相關資料,計算機科學、網路、資料結構、演算法,新技術應用,像是 AWS Study Roadmap
  • 開發 (Development):程式、資料庫應用
  • 驗證 (Acceptance):Quality Assurance and Testing
  • 維運 (Operation):上線 現場 (Live) 前、中、後,像是 CI/CD、SRE、Monitoring、Observability、事件管理

DevOps 我個人傾向於用整個企業的角度來看,而不是產品研發單位個別看,請參閱 經營管理

Read More

置頂 - AWS Study Roadmap 2016/10/01 13:30:00

AWS 範圍很大,有系統的學習是必要的。就像以前學音樂一樣,從各個面向整理 學習地圖,試著拼這張圖,過程中就可以知道自己哪裡還有缺,把缺的補上 (擁有技能)、把圖拼出來 (擁有知識)、把他們連結 (Connected and Linked) 起來 (產生智慧)、用他們創造 (產生創意)。

底下這張 mindmap 則是我自己的分類、重要性、以及學習的進度狀況,用以看到全貌:

以下依照 AWS Services 的分類、Solution … 等,整理過去的心得筆記。

Read More

置頂 - 經營管理 2017/07/01 10:30:00

經營管理 是我正在學習的領域。因為工作職務關係,斷斷續續都有在讀類似的書籍,工作上經常需要思考相關的事情。因為這樣寫了一些比較屬於筆記性質的文字,有時候回來翻翻看看,覺得似乎慢慢形成自己的一套方法與哲學,雖然很多都還不夠成熟與完整,但總是自己的思考的足跡。

分類這些心得如下:

  • 思考本質
  • 人才、角色
  • 經營、領導
Read More

去年翻譯了這本書: 分散式系統設計 (Designing Distributed Systems, DDS) 最近 (2019/05/20) 要上市了。以下純粹是譯者自己的筆記與心得,非官方。

Read More

Redmine 的安裝流程相對於一般的網站應用程式來講,是複雜的,特別是如果不熟悉 Ruby on Rails 的生態系,或者不熟悉 Nginx 的配置,那麼整個安裝過程會是非常挫折的。

本文記錄如何在 Ubuntu 16.04 安裝與配置最新版 Redmine 4.0.3 (201905) 筆記,相關資訊放在 GitHub 供參考。

Read More

Service Catalog 2019/05/06 12:43:00

記錄 之前 寫下的 Service Catalog 的概念。

Read More

敏捷三叔公 David Ko 的邀約,讓我有機會到新竹交大跟大家分享 持續交付 2.0 的心得~

底下整理這次分享的簡報、摘要與錄影。

Read More

Java Version Manager 2019/04/07 18:21:00

現在各個語言都有 Version Manager,像是 node 的 nvm、ruby 的 rvm、golang 的 gvm,Java 沒有官方的工具,但也有類似的工具。

底下整理的都是針對 macOS。

Read More

Study Notes - VPC - FAQ 2019/04/07 13:30:00

整理 VPC 一些常見的問答。

Read More

哪一種架構師? 2019/04/06 13:30:00

整理研讀 AWS Well-Architected Framework Whitepaper (June 2018) 時,提到的 各種架構師 的說明。

Read More

一個人的 Working Backwards 2019/04/05 10:30:00

AWS CTO 在他的 Blog 提到 Amazon 產品規劃的方法: Working Backwards,最近我把這想法放在 個人團隊、還有 企業發展 三個地方。

Read More

上週 (2019/03/28) DevOps Meetup 分享的主題:聊聊軟體交付的濫觴 談產出物管理 (Artifacts Management),我提出了 軟體交付四大支柱 (Four Pillars of Software Delivery) 的想法,如下圖:

支柱 (Pillar) 的意思就是在交付軟體過程,如同蓋房子,要先蓋地基與支柱,然後才能疊加其他的東西、蓋牆壁、放水電管線等,對應到軟體開發也就是開發、測試、維運任務。

Pillars 的命名想法參考自 AWS Well-Architected

依照四大支柱的描述,整理過去寫的文章列表,以及對應到這四個 Pillars 的關係:

Read More

整理導入 EC2 Auto Scaling 到新的系統、新架構過程中,在團隊協作溝通、前中後的技術確認、以及常見問答 … 等問題。

EC2 Auto Scaling 系列文章

Read More

Read More

EC2 Auto Scaling 是自動控制 EC2 橫向擴展 (Scalable) 的機制,名稱有個 Auto 的字眼,很多同事就會問這樣問題:

不是 Auto 了,為什麼還要設定?

這是個好問題,因為大家都以為自動了,就啥都不要管了 XD

實際上自動只是一種最終目的,而整個機制必須保留彈性,讓過程中,如果有非預期的狀況,可以做各種適度的橋整與安排,而這就叫做 Scaling Policies

EC2 Auto Scaling 系列文章

Read More

Auto Scaling 會自動增加機器,也會自動刪除機器,那 Auto Scaling 怎麼知道要砍哪一台?看最舊的?看最新的?還是看心情?

如同前面說描述,一個通用的機制的考慮必須是全面性的,所以接下整理的就是很多人會關心的問題:EC2 Auto Scaling 對 Instance 的 刪除策略 (Termination Policies)

EC2 Auto Scaling 系列文章

Read More

再談『為什麼寫文件?』 2019/04/03 10:30:00

寫文件,對很多人是很痛苦的事情,特別是工程師。不過,我卻一直很享受這件事情,享受重新組織整理知識的過程,因為這個過程獲得最多的是我自己。

Read More

將與才之『縱觀全局』 2019/04/02 01:21:00

我喜歡有這種特質的人:

  • 整個系列的 小說
  • 整個系列的 電影
  • 整個系列的 遊戲
  • 整個系列的 音樂
  • 整個系列的 產品
  • ….

他們對於這些作品,有一系列、完整的體驗、心得、想法、延伸、甚至是創作。

Read More

很多技術背景的工程師,隨著年紀與歷練,會有機會帶團隊,成為 Team Leader / Techincal Leader,甚至轉換身份成為管理者。這些轉換很常是學而優則仕、公司上級的期待、被逼上火線 … 但這都算是被動因素,也就是不是自己願意的。

管理 實際上是另一個高度專業的工作,所需要的技能與技術工作者是截然不同的,像是協調、溝通、管人、管事、領導、激勵 … 等看起來像是打雜的任務。因為需要漸漸地放手最熟悉技能 (技術) 讓團隊去執行,也因此很多初任管理工作會常常出現 患得患失 的狀況。

這一收一放,一段時間之後會發現,自己對技術會越來越陌生,跟團隊成員比較起來會越來越不如,很常會被底下的人質疑自己的技術能力,可是頭上戴著主管的帽子,需要做技術決策、選擇、提出建議 … 等,很多人因此就打退堂鼓放棄了,回到純粹的 Tech Leader 的角色。

接下來,我打算整理一些心得,分享從工程師到技術管理者的心得,先以這個問題開始:

管理者如何持續學習技術?

Read More

Artifacts Management (以下簡稱 AM) 這個題目很少人在談,大部分 持續交付 也不太會著墨,有趣的是大家每天都在用它,卻從來不知道他是什麼,所以 AM 有以下這三個特色:

  • 沒啥存在感
  • 很少人知道這是什麼
  • 大部分『持續交付』的書不會談

有趣的是,Google “Artifacts Management“ 這個關鍵字,我的文章居然是排在第一位。。。表示這題目真的不多人在討論 XD

Read More

整理安裝 Kubernetes 的筆記,主要是以 kubeadm 為主。

K8s Cluster 安裝管理的四種選擇:手動 (kubeadm)半自動 (kops)自動 (EKS)全自動 (GKE)

Read More

看見怎樣的全貌 2019/03/17 10:30:00

自從 Ruddy 老師提倡:《專案之初,首重看見全貌》的觀念,這想法與我過去引導團隊的 視野 很雷同。因為我一直用 視野 在思考全貌這件事,這反映了各個組織層面的運作、協作、溝通、產能。

我這邊講的『視野』一詞,可以是 Perspective (遠景)、Aspect (觀點)、View (視圖)、Dimension (維度)、 …

視野包含的 X、Y、Z 軸,三軸構成的整體全貌:

  • X 軸 - 產品 (Product): 抽象的事,也就是產品的概念,例如 ERP、CMS 都是一些產品
  • Y 軸 - 團隊 (Team): 具象的人群,可以是 技能團隊跨職能團隊 (任務團隊) 或者 管理團隊
  • Z 軸 - 架構 (Architecture): 具象的物,也就是技術架構與實踐,包含單體架構、微服務、分散式架構 … 等。

這些會構成三種主要排列組合 (XY、XZ、YZ),形成了全貌的層次。除了三軸,另外看不到的是 時間軸 (T),會牽動 X / Y / Z 的改變,講的是 企業的發展階段。我畫了一張圖,呈現如何用三軸看到視野與全貌在組織運作的關係,底下分別說明三軸的關係。

updated 2019/04/27
這張圖於新竹敏捷社群 Meetup 的分享:導讀持續交付 2.0 - 談當代軟體交付之虛實融合

Read More

文件的持續交付 2019/03/10 19:55:31

協同合作系統建制與導入 一文中,有個段落在說明 文件管理,主要概念就是如何讓 文件的持續交付 這件事情,在組織裡能夠落實。底下文字整理自今年 02/22 的 草稿

Read More

Study Notes - I/O Models 2019/02/27 22:30:00

很久以前在研究 nginx 時,過程針對他的 I/O Model 有了初步的了解,但是追本朔源還是經典著作 UNIX Network Programming Chapter 6. I/O Multiplexing,本文整理 BIO、NIO、AIO 等著名的 I/O Models 筆記。

W. Richard Stevens 美國電腦科學家,有多本經典著作,像是 UNIX Network ProgrammingTCP/IP Illustrated 系列

Read More

SRE Team Lifecycles 2019/02/04 12:43:00

整理並且簡譯 Google Blog 文章:Do you have an SRE team yet? How to start and assess your journey 的摘要,這篇文章描述如何建立 SRE 團隊,以及三種階段的 SRE 團隊。

Read More

這段原文是去年我寫的 memo (2018/10/16),主要是討論 Issue Tracking 在企業裡的價值,我的結論:

隨著時間的前進與企業的發展,他 應該 是內部的 知識管理庫 (KM)

基本的概念源自底下這張圖:

Read More

閱讀能力的重要性 2019/01/20 21:42:30

這篇文章是我在 FB 上寫的 隨筆,重點在於閱讀能力的重要性。

Read More

天賦與努力 2019/01/12 21:42:30

整理關於 天賦努力,一些普遍人錯誤的認知,原文是我 2018/07/07 寫在 facebook 的 草稿

Read More

2018 的思考隨記:上半年 2019/01/10 21:42:30

有時候樂手在舞台上表演的時候,同一首歌彈了幾百次、甚至幾千次,彈久了即興是理所當然的。但可能因為現場氣氛、溫度、當天晚餐的食物、空氣的味道、聽眾的情緒 …. 眾多因素,最後即興出一段自己都不知道怎麼彈出來的經典,事後也很難彈出那樣的感覺與味道。有些我個人喜歡樂手的 Live ,同一首歌重複找了 n 個版本,錄音室版、Live、Unplugged、Rock、Orchestration、Pinao、Acoustic Guitar …. 通常會有幾版本特別的棒,但也就出現那一次而已。

很多想法,是在特定情境、時空背景之下疊加出來的,而那些時空背景激盪的想法,在事後回顧的時候,會想,為什麼平常的我想不出這樣的東西?底下的截圖,是 2018 年我在特定條件之下,寫下的想法整理,有些有公開,有些則沒有。

  • 因為是私人的筆記,所以圖中的人名就馬賽克了。
  • 整理過程發現有點多,拆分成 H1、H2 兩篇。
Read More

2018 的思考隨記:下半年 2019/01/10 21:42:30

延續 上一篇 的整理,這篇整理 2018 年下半年的思考隨記。

Read More

關於 DevOps 的討論與想法 2019/01/08 12:39:00

這篇整理我 2018 年在 DevOps Taiwan 發言過的文字,談論到的包含軟體測試、持續交付、Artifact Management、軟體開發流程、維運 … 等,主要是記錄一些想法、觀念、觀察、經驗分享,然後截圖作紀錄。

這些文字發文的時間大多在上下班的公車路上,可以集中精神的狀況留下的,一些想法都是透過討論以及問題激盪出來的。

  • 因為是公開發言,所以文中的人名我就不馬賽克啦 XDD
  • 為了避免爭議,發言以截圖方式紀錄。
Read More

經過漫長的 確認需求撈單一面二面談薪資確認報到時程,新人總算報到了,然後就可以放鬆了?是這樣嗎?這篇整理新人報到後,要做的工作有哪些。

Read More