領導力 - 發想力
· tech · 約 6 分鐘 · 📚 成為 Tech Leader 讀書筆記 #7
前面談過擋住創新的三道牆,也談過用日記拆掉第一道牆——但牆拆掉之後呢?點子要從哪裡來? 這章給的答案是:發想力(idea power)是一種可以練的技能,不是天分。而且更反直覺的是——Leader 對…
Tech
責任的保費:AI 不收,也不賠
· tech · 約 9 分鐘 · 📚 帶 AI 的手藝(2026) #4
這篇的起點是一個樸素到近乎廢話的觀察:僱一個員工,他會負責,所以責任不(全)在你身上;用一個 AI,責任百分之百在你身上。第一篇把它叫做分流與全反射。但往下多想一步,它會裂開成一個更大的問題——雇用,…
看板上的頸:工具怎麼設計人的責任——兩個開源專案的對照稽核
· tech · 約 11 分鐘 · 📚 帶 AI 的手藝(2026) #3
第一篇立了模型:AI 吃寬層,人守頸口。第二篇把模型丟進事故現場驗證。這一篇看工具——因為 2026 年的工程師不是在白紙上跟 AI 協作,是在一堆新工具裡:agent 看板、多 agent 編排、s…
頸上有時鐘:事故中的 AI——重播一場毒藥訊息事故
· tech · 約 12 分鐘 · 📚 帶 AI 的手藝(2026) #2
上一篇講了漏斗:AI 吃掉寬層的量,人守住頸口的責任。這一篇把漏斗搬到它最極端的測試場——事故。事故是頸上有時鐘的場景:主播在罵、營運在催,而你必須在資訊不全的情況下做決定。AI 不能替你決定要不要在…
責任漏斗:AI 能做掉九成的事,為什麼剩下的一成是你
· tech · 約 6 分鐘 · 📚 帶 AI 的手藝(2026) #1
寫完 GitCrisp 和 部落格產線 兩篇之後,讀者最自然的下一個問題是:如果 AI 能做掉這麼多事,那你還剩什麼? 我的答案是一個形狀:漏斗。工作的量,大部分真的可以交給 AI——code、測試、…
這個部落格本身,就是一個作品:把寫作做成一條產線
· tech · 約 5 分鐘
寫了 旅遊分帳 和 GitCrisp 的介紹之後,發現漏了一個最常被使用的作品——你現在正在看的這個網站。它不是「架個 blog」:一百六十多篇文章、十幾個系列、一排小工具的背後,是一個 Astro …
GitCrisp:我和 AI 一起寫了一個 Git 桌面客戶端
· tech · 約 6 分鐘
GitCrisp 是一個桌面版的 Git 客戶端:視覺化 commit graph、逐 hunk staging、互動式 rebase、衝突解決介面、多倉庫管理,Python + PySide6(Qt…
Servers as Code:烘烤線畫在哪,決定你開機多快、改動多痛
· tech · 約 5 分鐘 · 📚 Infrastructure as Code 讀書筆記 #8
Stack 那層管的是「有哪些資源」;這篇往下鑽進資源裡最有內容物的那種——伺服器本身。一台 server 從開機到能服務,身上堆了一整疊東西,而 IaC 在這層要回答兩個問題:這疊東西什麼時候放上去…
Stack 與環境:staging 不該是另一份 code,是同一份的另一個 instance
· tech · 約 5 分鐘 · 📚 Infrastructure as Code 讀書筆記 #7
進入書的第二部分:stack。前面講切割時一直在說「一個 stack」怎樣怎樣,這篇先把這個詞站穩,再處理它最日常的應用場景——同一包基礎設施,要生出 dev、staging、prod 好幾份。這件事…
小而簡單的元件:爆炸半徑決定你敢不敢改
· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #6
三個核心實踐的最後一個。上一篇說變更批次要小,這篇補上它的前提:批次小得起來,元件先要小——如果整個系統是一包巨大的 stack,再小的改動也會被迫帶著整包一起上路。這章講的就是怎麼把基礎設施切成「小…
持續測試與交付:品質來自快回饋,不是守關卡
· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #5
三個核心實踐的第二個。上一篇把一切變成程式碼之後,下一個問題自然是:程式碼會錯,怎麼知道這次變更是安全的?書的答案跟傳統直覺相反——不是在上線前設一道更嚴的關卡,而是把驗證拆碎、塞進工作的每一步。品質…
一切皆程式碼:宣告式寫終點,程序式寫路徑
· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #4
前三章鋪完為什麼、原則、平台,從這章開始進入三個核心實踐,第一個就是招牌:把所有東西定義成程式碼——不只伺服器,網路、pipeline、監控、權限,全部。好處書裡列得很整齊(可重用、一致、透明、可測試…
基礎設施平台:你家的雲,是真的雲嗎?
· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #3
前兩章講完 為什麼和原則,第三章回頭補一個地基問題:IaC 要有東西可以 code——你的定義檔寫得再漂亮,也要有一個收到 API 呼叫就能生出資源的平台在下面接著。這章就在講這個「動態基礎設施平台」…
雲時代基礎設施的原則:壞了就重建,可靠性來自軟體
· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #2
第一章說雲時代該擁抱變更,這章回答「憑什麼敢」。前提先翻轉:鐵器時代的可靠性是用錢買硬體——更貴的機器、雙電源、RAID、原廠保固;雲跑在海量便宜的 commodity 硬體上,供應商直白告訴你:任何…
Infrastructure as Code 是什麼?從「變更」的成本翻轉講起
· tech · 約 7 分鐘 · 📚 Infrastructure as Code 讀書筆記 #1
開一個新系列:讀 Kief Morris 的 Infrastructure as Code,用的是第三版(2025)——副標從第二版的 Dynamic Systems for the Cloud Ag…
旅遊分帳:把 Google Sheet 當後端,寫一個不會把帳弄丟的分帳工具
· tech · 約 6 分鐘
每次跟朋友出國,分帳都是同一個劇本:有人先墊機票、有人刷了租車、晚餐又是另一個人付——回國後對著一堆收據算「誰欠誰多少」,算到懷疑人生。市面上的分帳 App 不是要每個人都註冊帳號,就是要大家都裝同一…
維運中斷:殺死生產力的不是工作量,是被切碎的時間
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #17
On-call 那篇講「怎麼設計告警、誰值班」,Toil 那篇講「用 50% 護欄別讓維運吃光工程時間」。但這兩條之間,漏了一個每天都在發生、卻很少被當成問題來管的東西:中斷(interrupts)—…
生產就緒審查(PRR):SRE 憑什麼接手一個服務
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #16
前面十五篇,講的幾乎都是「服務已經在線上了,怎麼讓它更可靠」——SLO、監控、postmortem、降級。但有一個更前面的問題一直沒問:一個新服務,憑什麼可以上線、憑什麼值得 SRE 接手扛 page…
關聯:從一個尖峰,點到那一行 log
· tech · 約 4 分鐘 · 📚 Grafana LGTM 可觀測性 #8
整個系列從第一篇的黃金路徑就一直押著一句:metric 看有沒有、trace 看在哪、log 看是什麼,由粗到細。但我一直跳過最關鍵的一步——這三格之間,到底怎麼「跳」過去?Tempo 那篇說「找 t…
Playbook 進階:變數、條件,與重新定義成功
· tech · 約 5 分鐘 · 📚 Ansible for DevOps 讀書筆記 #4
上一篇的 playbook 是死的:寫死的套件、寫死的路徑,只能打一種環境。第五章一口氣補上讓它活起來的所有機關——變數、條件、錯誤處理。內容很雜,但整理之後其實就三個主題:資料從哪來(變數、fact…