Tech

同事私下抱怨:Ralph 身上味道很重 討好 叫抱怨的人忍一下→ 有人離職 指責 「你很臭,去處理一下」→ Ralph 受傷,還是不知道原因 超理智 全員信:「請注意個人衛生」→ 人人覺得被點名,只有 Ralph 沒認出 打岔 不處理,等它自己消失→ 問題惡化 言行一致 私下、直接、好好跟 Ralph 談→ Ralph 去看醫生,還很感謝 三個點 = 自己(上)/ 對方(左)/ 情境(右);實心 = 有顧到,空心 = 忽略了

領導力 - 力量與言行一致

· tech · 約 7 分鐘 · 📚 成為 Tech Leader 讀書筆記 #11

激勵篇的最後兩章(Ch14–15)談的是「力量」——但 Weinberg 講的力量,跟一般人想的不一樣。 Ch14 第一句話就把常識翻掉:力量不是你身上的東西,是你和別人之間的關係。 工程師最容易混淆…

#leadership

每一次比較只能把「還有可能的排列」分成兩半 a < b ? b < c ? a < c ? 小於 大於 a b c a < c ? b a c b < c ? 小於 大於 小於 大於 a c b c a b b c a c b a 小於 大於 小於 大於 n! 片葉子 → 高度 ≥ log₂(n!) ≈ n log n → 最壞情況至少 n log n 次比較

排序是最便宜的結構:比較的下界、counting sort 與二分搜尋

· tech · 約 9 分鐘 · 📚 Competitive Programmer's Handbook 讀書筆記 #2

上一篇講的是看到 $n$ 就知道該寫什麼複雜度。這一篇講 CPHB 第 3 章:排序。原書這章很短,但它藏著一個我覺得比排序演算法本身更重要的觀念——排序不是目的,是在替後面的問題製造結構。 很多題目…

#algorithms#cphb#sorting#binary-search#book-notes

時限 1 秒 ≈ 數億次基本運算:看 n,反推能用的複雜度 輸入大小 n 可接受的複雜度 典型做法 運算量 n ≤ 10 O(n!) 試所有排列 10! ≈ 3.6×10⁶ n ≤ 20 O(2ⁿ) 試所有子集 2²⁰ ≈ 10⁶ n ≤ 500 O(n³) 三層迴圈 500³ ≈ 1.3×10⁸ n ≤ 5000 O(n²) 兩層迴圈、所有配對 5000² = 2.5×10⁷ n ≤ 10⁶ O(n log n) 或 O(n) 排序、掃一遍 10⁶×20 = 2×10⁷ n 很大 O(log n) 或 O(1) 二分搜尋、公式 — 例:n = 10⁵ 卻寫了 O(n²) → 10¹⁰ 次運算,要跑數十秒——還沒寫就知道不行

看到 n,就知道該寫什麼:時間複雜度與最大子陣列和

· tech · 約 10 分鐘 · 📚 Competitive Programmer's Handbook 讀書筆記 #1

開一個新系列:讀 Antti Laaksonen 的 Competitive Programmer's Handbook(CPHB)。這本書是 CSES Problem Set 的配套教材,線上 PD…

#algorithms#cphb#complexity#book-notes

231 次 CI 執行 綠燈 194 取消 22 紅 15 15 次紅燈,原因 測試 8 lint 4 基礎設施 3 mypy 0 8 次測試紅燈,攔下了 靜默 bug ×3 repo 狀態變 CLEAN 單一 OS ×2 內容已確認 單一 OS ×2 log 已過期 flaky 15 次全在 PR branch 漏進 master:0 次 「log 已過期」的兩次只知道紅在哪個平台、不知道是哪個測試。flaky 那次是唯一帶著紅燈 merge 的 PR。 取消 22 次:21 次是 master 上被較新的 merge 取代,1 次是 PR 上被新 push 取代。

護欄工程:測試與規範在 AI 產線的新角色

· tech · 約 10 分鐘 · 📚 帶 AI 的手藝(2026) #7

第一篇把護欄定義成「加寬頸的工具」——把每次都要人眼看的檢查交給機器,人的驗收頻寬留給機器驗不了的東西。上一篇在一份綠燈 PR 裡看到這句話的反面:1294 個測試全綠,但它們全部只用一個 stash…

#ai#testing#side-project

作者盲測 裸 AI +CLAUDE.md +review skill B1 index 反轉 邏輯邊界 △ 沒有 test 釘住,沒驗證 3/3 3/3 3/3 B2 Apply 變 Pop 靜默回歸 ✓ 3/3 3/3 3/3 B3 越層用 pygit2 架構判斷 ✓ 1/3 2/3 3/3 沒埋的真 bug 部分失敗卻只報錯 ✗ 1/3 1/3 3/3 花費 20 分鐘 每次 0.4–2.2 分鐘、$0.09–0.19 B1 怎麼確認 讀 diff 9 份裡 8 份寫腳本實測 pygit2

驗收的手藝:怎麼 review AI 的 code

· tech · 約 11 分鐘 · 📚 帶 AI 的手藝(2026) #6

第一篇說,頸寬等於你能負責任地驗收的頻寬;上一篇說,規範決定的是「什麼時候算做完」。這篇往下走一步:東西做完了,交到你手上,你怎麼驗? 「review AI 的 code」聽起來跟 review 人的…

#ai#code-review#leadership

沒有規範 有規範 同樣六個正式程式檔、同樣的分層、幾乎同樣的行數 既有的 codebase 本身就是一份隱性規範——兩組都照著它長 程式碼 責任層:差異全在這裡 出貨路徑 直接 commit 到 master 開 branch,等 PR 發布閘門 draft: false,寫完即發 draft: true,等作者確認圖 第一手經驗 代寫「我的經驗是……」 拒絕代寫,標出要作者補 驗收 跑單元測試,沒開 app 把 app 真的跑起來(e2e) 切分 一個 commit 照架構分層拆兩個 commit 規範改變的不是 code 長什麼樣,是責任落在哪裡

規範即程式:CLAUDE.md 是新時代的 onboarding 文件

· tech · 約 14 分鐘 · 📚 帶 AI 的手藝(2026) #5

前四篇立的是公理:責任守恆、頸上有時鐘、工具怎麼設計責任、AI 不收保費。從這篇開始是推導——如果責任百分之百收斂在你身上,那第一個推得出來的手藝就是:你的要求必須寫清楚。 這個推論聽起來像常識,但它…

#ai#leadership#side-project

① 他要嗎? ② 問題定義一致嗎? ③ 幫他,還是幫我? 想幫的衝動我看到問題了! 真正的幫助對方也這麼覺得 沒過 → 打擾 沒過 → 雞同鴨講 沒過 → 搶戲 幫助是不是幫助,由被幫的人認定——不是由出手的人

領導力 - 幫助的難題

· tech · 約 5 分鐘 · 📚 成為 Tech Leader 讀書筆記 #10

上一篇收在「激勵的起點是先看懂人」。看懂之後呢?最自然冒出來的衝動就是幫——他卡住了,我看得到問題,我出手。這章(Ch12–13)潑的就是這盆冷水:幫助本身就是難題,而且幫得越熱心,越容易踩坑。 We…

#leadership

你以為的溝通(把人當電腦) 指令 = 行動 實際的溝通(人) 你說的話你以為很清楚 ≠ 他聽到的漏掉一半 ≠ 他解讀的用他的框架 ≠ 他的感受被威脅?被信任? ≠ 他做的你只看得到這個 整條鏈只有頭尾看得見——中間三步全在對方心裡發生

領導力 - 激勵的兩大障礙

· tech · 約 4 分鐘 · 📚 成為 Tech Leader 讀書筆記 #9

系列走進第三部:激勵(Motivation)——MOI 的 M。創新篇談的是點子和方向,激勵篇要回答的問題更根本:為什麼你講的東西,別人不動? 書給的答案很不客氣:問題通常不在「別人」,在你自己身上—…

#leadership

直屬人數,決定你這個 manager 實際在做什麼 可投資的時間(coaching / 寫策略 / 推動改變) 最高點 1–3 人 你是 TLM 還在分擔設計與實作 4–5 人 勉強成團 輪得動,但很薄 6–8 人 甜蜜點:你是投資者 帶人 + 寫策略 + 推改變 9 人以上 你退化成教練 + 安全網 只接得住問題,投資歸零 直屬工程師人數 → 同一條軸的上一層:manager of managers 帶 4–6 個 manager (人再多,連「協調 manager」都會變成純轉發)

團隊該多大:6 到 8 這個數字在買什麼

· tech · 約 8 分鐘 · 📚 An Elegant Puzzle 讀書筆記 #2

「團隊該幾個人」聽起來像 HR 的題目——其實它是這本書第一個、也是最有操作性的系統設計題。Larson 給的數字很直接:一個 manager 帶 6 到 8 個工程師,一個帶 manager 的 m…

#engineering-management

處理事件 接得越快,來得越理所當然 系統(編制 / 流程 / 沒寫下來的規則) 你 一件一件處理完 ✓ 下週一樣多——源頭一根寒毛都沒動 改系統 同一件事第三次,就別再接了 系統 + 一條政策 / 一個機制 你 剩下的才需要你判斷 ✓ 代價:幾週到幾個月後才看得到效果

工程管理是一道優雅的謎題:別修事件,修系統

· tech · 約 9 分鐘 · 📚 An Elegant Puzzle 讀書筆記 #1

站內已經有一個領導力系列了(成為 Tech Leader),為什麼還要再開一個? 因為那本書談的是人怎麼長成一個 leader——影響力、自我覺察、願景;而 Will Larson 的 An Eleg…

#engineering-management

checkout sh 'build' sh 'test' deploy 每個步驟之間,把「執行到哪 + 變數裡有什麼」整包寫到磁碟 ⚡ controller 在這裡重啟 重啟後:從最後一次存檔的狀態接著跑,不用從頭來過 為了能隨時存檔,Jenkins 把你的 Groovy 轉成「可以一步步暫停」的形式(CPS) 而能存檔的前提是:所有還活著的變數,都必須可以序列化 NotSerializableException、@NonCPS、某些寫法行為詭異——全部源自這一句話

Jenkinsfile 不是 Groovy:CPS、序列化與沙箱

· tech · 約 6 分鐘 · 📚 Jenkins 學習筆記 #9

這個系列到目前為止給過三次同一個建議:Jenkinsfile 只做編排,邏輯放到 shell 腳本或 src/ 的 class 裡。 但我給的理由一直都很軟——好讀(半夜看它的人不一定會 Groovy…

#jenkins#ci-cd

payment-api(repo) main feature/refund feature/webhook PR #12 PR #15 webhook掃描 Multibranch有 Jenkinsfile 的就自動長一個 job job: main跑 main 的 Jenkinsfile job: feature/refund跑「它自己那版」 job: feature/webhook跑「它自己那版」 job: PR-12合併前先驗 job: PR-15合併前先驗 每個分支跑「它自己那一版」Jenkinsfile,不是共用一份 所以改 pipeline 的 PR,是用改過之後的版本跑的——建置流程的變更,合併前就被驗過了 分支刪掉,對應的 job 也要跟著消失(孤兒 job 清理策略)——否則就是下一批要清的堆積

Multibranch 與 PR 觸發:讓每個分支都有自己的 pipeline

· tech · 約 11 分鐘 · 📚 Jenkins 學習筆記 #8

前面七篇談的都是「一條 pipeline」。但真實的 repo 從來不只有一條路:main 上有人在合、三個 feature branch 在跑、還有兩個 PR 等著 review。 這篇處理的就是這…

#jenkins#ci-cd

✗ 十份複製貼上的 Jenkinsfile 專案 A · 200 行修過安全性設定 專案 B · 205 行沒跟上那個修補 專案 C · 180 行兩年前複製的版本 專案 D · 240 行有人改過,原因失傳 專案 E · 200 行複製自 C(所以也舊) 沒有人知道哪一份才是對的 一個修補要改十次,而且一定會漏掉兩個 「最佳實務」只存在於最早那份,之後只有漂移 ✓ 收斂成一份,各自釘版本 A · 15 行@1.4.0 B · 15 行@1.4.0 C · 18 行@1.5.0 D · 22 行@1.4.0 E · 15 行@1.5.0 pipeline-lib一份 · 有版本 一次修補,全體受惠 但同一件事的反面是:一改,可能全炸 所以要釘版本——升不升、什麼時候升,由專案自己決定 收斂解決的是「漂移」,版本解決的是「連坐」 只做前者不做後者,你會把十個獨立的小問題,換成一個全公司同時發作的大問題

Shared Library:把十份幾乎一樣的 Jenkinsfile,變成公司資產

· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #7

第 2 篇的結論是:把 pipeline 寫成程式碼、放進 repo。這件事在一個專案上是純粹的勝利,但當公司有十個、三十個專案之後,會長出一個新問題——十份幾乎一樣、但又不完全一樣的 Jenkins…

#jenkins#ci-cd#pipeline

✗ 一把萬能鑰匙,放 Global prod-deploy-keyGlobal · 永久有效 · 全權限 前端 build 後端 build 工具 job 外部 PR build 能讓任何一個 build 跑起來的人 = 拿到了 Production 的鑰匙 ✓ 按 folder 切 + 短期票 folder: web只有 npm registry token folder: api只有內部 maven 憑證 folder: deployprod 憑證只在這裡 · 只能部署,不能刪叢集每次 build 現發,build 結束就失效 PR build 在 web / api folder 底下 它根本看不到 deploy folder 的憑證 看憑證只問三題:能做什麼 · 活多久 · 誰拿得到 三題都答得出來,才輪得到討論「有沒有加密」——那從來不是重點

憑證管理:機密怎麼進 pipeline,又不會漏出去

· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #6

第 2 篇的結論是:pipeline 要寫成程式碼、進 git、讓每個人都能 review。這是整個系列的立場,但它有一個必須同時付的代價——這條路上的每一行,所有能讀這個 repo 的人都看得到。 …

#jenkins#ci-cd#security

序列:一個接一個 Unit 4m Integration 6m 1m Image 3m 14m 010 分 平行:同時開跑 Unit 4m Integration 6m ← 最慢的那條 1m Image 3m 6m —— 總時間 = 最慢的那一條 所以再加平行不會更快,要動的是那條 6 分鐘的 平行的代價:每條各佔一個 executor 格子 · 同機互搶 CPU 與硬碟 · 日誌交錯變難讀 格子不夠時,「平行」會退化成「排隊」——只是排在 Jenkins 內部,你在 UI 上看不出來

進階 pipeline:平行、條件、失敗處理與那個很貴的人工關卡

· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #5

前面四篇處理的是「在哪跑」與「東西放哪」。這一篇回到 Jenkinsfile 本身:同樣一條會動的 pipeline,怎麼讓它跑得快、失敗得清楚、而且不會在半夜卡住一台機器。 這批東西的共同點是:它們…

#jenkins#ci-cd#pipeline

① build #41 跑完target/ · node_modules/build 時產生的 config.yml.gradle / .m2 快取全部留在 workspace 裡 ② build #42 開始checkout 更新 git 追蹤的檔案沒被追蹤的殘骸 → 原封不動(它不是 clean,只是 update) ③ build #42 綠燈 ✓但測試讀到的是 #41 產生的那份 config.yml換一台乾淨機器 → 爆 同一個 workspace 目錄,被 #41、#42、#43… 重複使用——它是一個沒人在管的共用狀態 檢驗問題:同一個 commit,在一個全新的環境跑,還會過嗎? 答不出來,你的綠燈就是靠殘留撐著——而殘留遲早會被清掉、或換一台 agent 就消失 這也是「在我機器上明明可以」的反面:在 CI 上明明可以

Workspace 與 Artifact:build 出來的東西去哪了

· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #4

上一篇解決了「在哪台機器上跑」。這一篇往下挖一層:跑起來之後,檔案到底放在哪、留多久、誰看得到。 這聽起來很枝微末節,但它其實是整個系列主軸裡「可重現」最常破功的地方——而且破得很安靜:你的 CI 一…

#jenkins#ci-cd

① 觸發webhook / PR ② 佇列等一個空格子 ③ 依 label 媒合Jenkinsfile 說:linux && docker agent-alabel: linux docker3 個 executor,還剩 1 格 → 派這台 agent-blabel: linux全空,但沒有 docker → 輪不到它 agent-maclabel: mac簽 iOS 用的,別的工作不派來 排隊等的是 executor 格子,不是機器 一台 agent 有幾個 executor,就能同時跑幾個 build——格子開太多,大家一起搶 CPU 與硬碟 而 label 不符的 agent,就算整台閒著也不會被派工:你的 build 在等的往往不是「機器」,是「對的機器」

Controller 與 Agent:工作到底在哪台機器上跑

· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #3

上一篇那份 Jenkinsfile 裡有一行 sh './scripts/ci-build.sh'。它到底在哪台機器上執行? 這個問題聽起來很基本,但它決定了三件事:你的 build 要等多久、失敗時…

#jenkins#ci-cd#infrastructure

設定住在 Jenkins UI 上 v1 · 1月 v2 · 3月 v3 · 8月 job 設定(config.xml)只有「現在」這一份 checkout v1 想重 build 一次 配到的是 8 月的設定,不是 1 月的 那顆產物,再也組不回來 設定住在 repo 裡 v1 · 1月 v2 · 3月 v3 · 8月 Jenkinsfile Jenkinsfile Jenkinsfile 每個 commit 自己帶著當時的建置方式 checkout v1 想重 build 一次 拿到的就是 1 月那份 Jenkinsfile 程式碼與建置方式永遠同版本 「這版是怎麼 build 出來的?」——只有右邊答得出來 同一個 commit、同一次 review、同一次 revert:可審查買一送二,順便買到可重現與可回滾

第一個 Jenkinsfile:pipeline as code 為什麼贏過 UI 點按鈕

· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #2

上一篇最後那份 Jenkinsfile 只有二十行,語法簡單到不需要解釋。但我還是要為它寫一整篇——因為這二十行真正的價值不在語法,而在它躺在哪裡。 同一個 build,你可以在 Jenkins 的 …

#jenkins#ci-cd#pipeline

同一條路,三個名字——差別只在自動化走到哪裡 ① 提交程式碼push / open PR ② 建置 + 測試自動、每次都跑 ③ 打包產物一顆可部署的東西 ④ 測試環境驗收隨時可上線的狀態 ⑤ 上 Production誰按下這一步? CI(持續整合) 合回主幹 + 每次都自動驗證 Continuous Delivery(持續交付) 隨時可上線,但人按 Continuous Deployment(持續部署)——過關就自動上,沒有那顆按鈕 兩個 CD 的差別不是技術,是你敢不敢把那顆按鈕拿掉 敢不敢,取決於前面幾關擋得住多少——這也是為什麼品質關卡與回滾是後面幾篇的重點

Jenkins 是什麼:CI 不是「有跑測試」,是「頻繁合回主幹」

· tech · 約 13 分鐘 · 📚 Jenkins 學習筆記 #1

大部分人第一次碰 Jenkins,情境都差不多:公司有一台跑很久的 Jenkins,你要在上面「加一個 job」。點進去、複製隔壁專案的設定、改幾個欄位、按存檔——會動了,收工。這樣用了兩年,你會很熟…

#jenkins#ci-cd#concept

沒有願景 有願景 每個都是好點子,合力 ≈ 0 ✦ 那個畫面 不必平行,方向相近就會疊加

領導力 - 願景

· tech · 約 7 分鐘 · 📚 成為 Tech Leader 讀書筆記 #8

創新篇走到這裡:拆了牆、學會看見自己、養起了點子流。但還剩最後一個問題——點子流有了,誰決定它流往哪裡? 一個團隊可以點子很多、討論很熱,但每個點子指向不同方向——這時候點子多反而是內耗。這章的答案是…

#leadership#innovation