技術 FOMO｜見習程式碼整理師｜魂遊雲玩家｜截圖貼文愛好者｜一鍵轉貼狂魔｜不太會 .Net 的菜雞，謝謝微軟把拔供我吃穿｜筆記本：igouist.net
Joined May 2022
- Tweets 2,534
- Following 1,259
- Followers 972
- Likes 29,197
452 Photos and videos
Pinned Tweet
28 Jan 2024
開始每天轉貼文章之後，我發現我真的蠻喜歡看生產力和工作心得相關的文章。先不論做不做得到，緩解知識焦慮是真的不錯
45
326
14,182
Jun 13
非常認同「目標清晰、上下文好、品味和判斷強的人，會被 AI 放大；目標混亂、沒有文件、沒有判斷的人，也會被 AI 放大混亂」，以及 Skill 封裝專家經驗的部份。
這個體悟在我前陣子比對了我用 AI 無腦生產的單元測試，以及使用前輩的 Skill 所寫出的單元測試之後來到一個高峰。
Jun 13
好文！把我抽象的想法具現化了
AI 是放大器不是平權器
目標清晰、上下文好、品味和判斷強的人，會被 AI 放大；目標混亂、沒有文件、沒有判斷的人，也會被 AI 放大混亂
Skill 則可彌合 AI 使用能力差距
Skill 把專家經驗、工作流程、品味和工具呼叫封裝成可分發、可重複使用、可迭代的 AI 能力單元
1
1
22
955
順便寫完了五月份的同樂會了。能用這種方式與大家產生連結真的是件蠻酷的事耶。
blog.kalan.dev/random/a-quot…
4
34
5,296
無情的 CRUD 機器 retweeted
May 30
之前有發推談談我對軟體工程師被取代的看法，現在把比較完整的心得寫成文章了
會談談近期對於 AI 能力看法的轉變，工程師工作內容、甚至是團隊不同角色的分工以及工作流程的轉變，工程師被取代的前提，以及工程師的轉型
不是什麼很嚴謹的論述文章，閒聊一下近期感想而已
life.huli.tw/2026/05/30/ai-e…
5
23
121
5,531
無情的 CRUD 機器 retweeted
May 28
opasschang.com/blog/i-paid-2…
受眾分析得很好，感想也寫得很好
對於具有一定程度跟自學能力的工程師來說，這些課確實 CP 值不高（我自己幾年前也好奇報過）
至於對其他人來說如何，就要看他們自己的感想了
3
18
92
10,076
無情的 CRUD 機器 retweeted
May 25
說來慚愧，真正讓我有更多時間好好生活的不是我花了數十年專研的軟體技術，而是理財能力，不要困在一個讓自己愈陷愈深的局裏
19
5
66
2,857
無情的 CRUD 機器 retweeted
May 25
blog.huli.tw/2026/05/25/dive…
由於最近供應鏈攻擊實在太多了，只好把拖稿很久的主題優先寫完，再回頭研究了一下不曾理解過的安裝套件流程以及各家對於供應鏈攻擊的防禦（懶得研究 yarn，抱歉了）
只要把一些參數設定好至少能擋掉大部分的，或是裝最新版 pnpm，預設就幫你擋掉，想更安全再裝個 sfw
30
112
14,189
May 23
這兩天回鍋艾爾登法環。
不記得的部份：
- 支線劇情和觸發方式
- 裝備和地下墓地的位置
記得的部份：
- 開場直衝瑪莉卡第三教堂，傳送到蓋利德把黑夜騎士摔死賺第一桶金
- 野獸神殿門口雜兵一隻一千
- 帶弓箭到蒙格銀行找大烏鴉提款
1
3
415
無情的 CRUD 機器 retweeted
May 17
前幾天收到了很令人開心的讚賞，而且這個方式我很喜歡。讚賞的對象是我的 blog 技術文章 & 書籍，大意是「少數碰到不是小說，但是會用精彩來形容」
覺得這是對技術文章很高的稱讚，讓人讀起技術文章像是讀小說那樣引人入勝，明明是技術文卻不會無聊
4
5
82
2,368
22 Jan 2024
【每天分享一篇文章】公開學習與部落格
昨天的分享文有提到公開學習這件事。我個人覺得對工程師來說最有效的公開學習還是寫部落格，因此今天想要分享這篇：
我為什麼鼓勵工程師寫 blog
dotblogs.com.tw/hatelove/201…
---
這篇文章中，91 大大逐一列出了六項好處：
1. 產生學習動機，有方向性地篩選資訊
2. 檢視自己既有知識，將input的新資訊與既有的知識建立連結
3. 透過寫文，刻意強化刺激知識轉化，進行內化知識過程
4. 取得回饋，突破盲點
5. 受益的總是自己
6. 證明自己的能力、特質、發展潛力
文章內針對每一點好處都有仔細地說明，而且相當有道理。不過整個引用的話篇幅有點太長了，我粗略地描述一下：
如果我們的學習沒有方向和目標，就會漫無目的地漂流；而如果我們給自己一個承諾，每個月發一篇文章，那麼我們就會針對這個主題下去研究，也就會開始蒐集相關的資料、有目標地整理這些資訊
而我們為了整理這些資訊，自然就會把他們分類或互相關聯，這時候我們就可以把自己既有的知識和新的資訊關聯起來，也就可以活化舊知識。
同時，也因為我們主動地去整理和吸收，再用我們自己的方式表達出來，過程中融入了我們的經驗和想法，這份資訊才會被內化成我們擁有的知識
延伸閱讀：《最高學以致用法》讀後心得：活用知識的五種方法
readingoutpost.com/power-of-…
前面三項基本就是輸出式學習所帶來的好處。接著後三項就開始感覺到公開學習的好處了
當我們把學習成果公開出去，就有可能取得別人的回饋。這些回饋可以幫我們破除盲點、修正錯誤。
除了受到別人的幫助以外，這些文章也可能幫助下一個踩坑的人，甚至很可能會是之後的自己（其實自己回頭查筆記的次數會是最多的，效果也最好，畢竟跟讀檔差不多）。
累積了一定的成果之後，也能夠證明自己的特質。例如持續學習、充滿毅力、樂於分享等等。怎麼看都不虧。
---
這篇文裡面有很多段落都讓我一直點頭認同，例如這句：
> 相信很多有在寫 blog 文章的朋友一定都有過這樣的感受：素材整理了八九成，但開始寫作時，往往會再多個 20 % ~ 60 % 的內容是原本素材沒有的，一邊在寫的過程，其實是迅速的在過程中校準自己的知識點。
在寫文章的時候真的是一直查一直補充，原本很多覺得自己很懂的東西，要組織成語言的時候才會發現東缺西漏，結果為了把洞補完又延伸了許多知識點，最後累得半死但也有所收穫。
除了這點以外，還有一段心魔的部份：
> 為什麼許多人會自己整理學習筆記、讀書心得，卻少了這一段外顯知識的過程？大部分的人都是說自己沒那時間、沒那衝動，其實很多是卡在自己心裡那一關：不敢展露出自己學習的結果，怕被別人笑，怕被人酸。
老實說我真的超怕的，畢竟是真的菜。但後來看到 〈鐵人賽——30天可以給自己多大轉變？〉 後有點轉念，尤其是那句：「我本來就是初學者，我為什麼要害怕讓別人知道我不夠強呢XD？」讓我理解更是因為我菜，才更需要這樣做。
〈鐵人賽——30天可以給自己多大轉變？〉
ithelp.ithome.com.tw/article…
最後，之前有幫朋友整理過開始寫作的文章，這邊也貼一份上來。如果有正在猶豫要不要寫部落格的朋友，也許可以閱讀看看
寫一年技術文章的心得 - jyt0532's Blog
jyt0532.com/2017/11/23/why-b…
寫作不是從空白頁開始，而是從寫思考筆記的 5 個習慣開始 - 電腦玩物
playpcesor.com/2020/10/5.htm…
我是如何完成一篇文章的 - Huli
hulitw.medium.com/how-do-i-w…
技術寫作六步驟 讓工程師撰寫流暢的技術部落格
tw.alphacamp.co/blog/2018-06…
---
Jeff Atwood《How To Achieve Ultimate Blog Success In One Easy Step》：
> 當別人請我給他們一些寫 blog 的建議，我總是回他：挑個你自認為可以的時間行程安排，什麼時候開始寫 blog，預計多久寫一篇文，開始動工，並堅持下去。在你這麼做之前，任何建議對你來說都是不重要的。
> 你文章是否寫得很糟糕不重要，是否沒有任何人會看你的 blog 不重要，是不是沒啥有趣的東西可以紀錄也不重要。重要的是，只要你能透過寫文來表現出寫作的意願，而且渴望持續地寫作，檢視、思考與改善自己的寫作，你終究會成功的。
那麼，今天的轉貼就先到這邊。明天見 ><"
8
8
34
2,378
May 10
为什么要写作 - Limboy's Blog
limboy.me/posts/why-write
-
> 在工業革命之前，大多數人的工作都能強健體魄。現在如果你想變得強壯，你得主動去健身。強壯的人依然存在，但只有那些「選擇」強壯的人才會如此。寫作（即思考）正在經歷同樣的轉變。
1
133
May 10
蠻認同這篇的，尤其是強壯變成了一種需要主動去做的選擇的這段引用
在越來越多人使用 AI 工具產生文字內容的這個時刻，「藉由寫作來思考」也漸漸地會成為一種個人選擇吧
99
May 9
BlogBlog 同樂會的四月份回顧文出來了
特別喜歡主題是「生產力」，然後一堆人（包含我）在截稿日投稿的部份
-
BlogBlog 同樂會回顧：「生產力」的 102 種面向 - Wen的生產力實驗室
wen-lab.tw/blogblog-producti…
-
2
4
345
無情的 CRUD 機器 retweeted
blog.huli.tw/notes/
把之前放在臉書粉專的貼文都搬過來了，然後新開了一個 RSS，不想用臉書的可以直接追 RSS
這邊都是一些短文，通常講資安居多，就想到什麼寫什麼
原本在想要分開還是跟之前文章放一起
投票結果五五波，最後還是選了分開的形式
寫到這裡突然想到，這算不算一種文章版的 shorts
1
5
18
1,194
無情的 CRUD 機器 retweeted
今天要把臉書上的貼文搬到部落格
弄了新的頁面，跟之前的長文區隔開來
比較用心需要花幾天寫的是長文，比較隨便寫的是短文
其實更像是長一點的推文
顯示方式也不同，短文像是動態牆直接顯示內容
長文要點進去
但弄著弄著想說雖然短了點，直接當文章其實也行
不曉得哪種對讀者更友善
想問問大家意見
50%
分開，短文直接顯示內容
50%
合在一起，都是文章不用分這麼細
0%
0%
0%
0%
0%
0%
12 votes • Final results
3
1
12
1,140
無情的 CRUD 機器 retweeted
Apr 28
2008 年在 PTT 鍵鼠板上跟了 Filco 團購，買了一把 Filco 104 鍵茶軸，當時已經知道 Filco 的鍵盤其實都是在台灣生產組裝，但卻沒有在台灣沒有販售，只能從日本買回來
上週傳出 Filco 品牌所屬公司 Diatec 結束營運，想說該不會 Filco 就此絕響，沒想到台灣代工廠共榮/非爾特會承接下來
共榮在中和，接送太太上下班時都會經過他們門口
4
54
458
43,997
Apr 26
前幾天和同事聊到：如果 Feature Flag 沒有好好管理、年久失修，還散得到處都是的話，會發生什麼事呢？稍微爬了一些相關文章，也丟上來這邊，供需要的朋友參考。
首先先來一個經典案例：
Knightmare: A DevOps Cautionary Tale
dougseven.com/2014/04/17/kni…
> 對 SMARS 的更新原本是要替換名為「Power Peg」的舊有、未使用程式碼——這項功能 Knight 已經整整 8 年沒用過了（為什麼一段已經死了 8 年的程式碼還會留在程式碼庫中，這是個謎，但這不是重點）。此次更新的程式碼重新利用了一個舊 Flag，該 Flag 原本是用來啟用 Power Peg 功能。這段程式碼經過徹底測試，並已證明能正確且可靠地運作。還能出什麼差錯呢？
> 在東部時間 2012 年 8 月 1 日上午 9:30，市場開盤，Knight 開始代表其客戶處理來自券商交易商的新版零售流動性計畫訂單。那七台已正確部署 SMARS 的伺服器開始正確處理這些訂單。送至第八台伺服器的訂單觸發了疑似被重新用途化的 Flag，並讓早已被棄用的 Power Peg 程式碼死而復生。
> 短短 45 分鐘內，Knight 從美國股票市場最大交易商、NYSE 與 NASDAQ 的重要做市商，變成了破產公司。
只是一個被錯誤打開的開關，就可以導致一間公司的毀滅。可見 Feature Flag 的管理不可不慎，但我們要怎麼管理這些 Flag 呢？
首先我們要先認識 Feature Flag 的生命週期，這部份可以參考我們馬丁叔叔這篇：
Feature Toggles (aka Feature Flags)
martinfowler.com/articles/fe…
簡單筆記一下：Feature Flag 的生命週期應該根據用途去分類，不同種類應該要有不同的生命週期，我們可以把 Flag 分為四種
1. Release Toggles（發布切換）
- 用途：隱藏還沒做完的功能，讓程式碼可以安心合回主幹，不影響現有使用者
- 生命週期：極短，功能上線後就可以拔了
- 動態程度低，不是開就是關
2. Experiment Toggles（實驗切換）
- 用途：做 A/B Testing 之類的實驗，讓不同使用者看到不同版本
- 生命週期：短，實驗結束後移除
- 動態程度高，會需要根據實驗設計去對不同實驗者判斷要丟到開還是關
3. Ops Toggles（營運切換）
- 用途：給維運人員用的緊急開關，在出問題時可以快速關閉功能，降低影響範圍
- 生命週期：大多偏短，但要看系統怎麼設計，有些緊急閘門會長期存活
- 動態程度：中，主要看有沒有需要人工操作
4. Permissioning Toggle（權限切換）
- 用途：控制哪些使用者能使用哪些功能，例如付費方案、Beta 搶先體驗名單等等
- 生命週期：長，甚至永久，功能分級存在多久就活多久
- 動態程度高，需要根據使用者身分和請求判斷要丟到開還是關
替 Feature Flag 分類之後，重要的下一步就是：在建立 Flag 的時候就想好退場機制。
在這篇文章中也提到了一些 Feature Flag 的常見退場作法：
> Feature Flags 有快速倍增的傾向，特別是在剛導入時。它們既實用又容易建立，因此常常會被大量新增。然而，開關也是有維護成本的。它們會要求你在程式碼中引入新的抽象層或條件邏輯，也會帶來相當大的測試負擔
> 精明的團隊會將程式碼庫中的 Feature Toggles 視為一種存貨，而存貨是有持有成本的，因此會盡可能把這些存貨維持在最低。為了讓 feature flags 的數量保持在可管理的範圍內，團隊必須主動移除那些已不再需要的 feature flag
> 有些團隊會規定：每當第一次引入一個 Release Toggle 時，就一定要在團隊的 backlog 中新增一個移除 toggle 的任務。另一些團隊則會替他們的 toggles 設定「到期日」。有些團隊甚至會建立「定時炸彈」；如果某個 feature flag 在到期日之後仍然存在，測試就會失敗（甚至應用程式會拒絕啟動！）
> 我們也可以採用精實（Lean）的方法來降低存貨，對系統在任何時間點允許擁有的 feature flags 數量設下上限。一旦達到這個上限，如果有人想新增一個新的 toggle，就必須先花時間移除現有的 flag
除了上面馬丁叔叔的文章，以下這幾篇也可以作為參考：
Feature Flag Best Practices: Understanding the Feature Flag Lifecycle
cloudbees.com/blog/feature-f…
Your Feature Flag Management Needs to Include Retirement
cloudbees.com/blog/feature-f…
Feature Flag Best Practices: 7 Common Mistakes to Avoid
configcat.com/blog/feature-f…
以上就是 Feature Flag 退場機制的相關文章，祝福各位不會遇到開關多到變成飛機駕駛艙的狀況。阿彌陀佛。
3
19
1,784
無情的 CRUD 機器 retweeted
Apr 18
這陣子用 AI 逆向的一些心得，我是從這邊開始對 AI 改觀的，以前只覺得 AI 在軟體這領域很厲害，現在有一種 AI 在軟體領域無所不能的感覺
至少在逆向這塊，完全出乎我意料，打開了我這個井底之蛙的眼界，什麼都拆，什麼都不奇怪，萬物皆可逆
blog.huli.tw/2026/04/18/ai-r…
16
72
514
47,588
Apr 18
認同這段，囤積第二大腦的同時，別忘了第一大腦需要餵養。
---
AI 幫你建了第二大腦，但你的第一大腦呢？ - Tech Trig Point
ttp.brecht.im/posts/2026-04-…
1
2
17
425