菜雞寫筆記，踩坑全紀錄
離開工又近了一天，我需要更多 Power。所以今天想轉貼的是這則 TED 演講影片：
Your body language may shape who you are | Amy Cuddy | TED
會看到這則演講，是在閱讀大大的讀書心得時被引起了興趣，這邊也一併附上來：
周末讀書會 - 姿勢決定你是誰 - .NET Walker
在看這篇的時候，我其實對即使是講過無數場的講座的業界前輩會緊張感到蠻驚訝的（我一直以為這些大前輩可能從某場演講開始就麻痺了，然後就變成無情的專業講師，眼睛張開就可以握麥）
其中一段讓我蠻認同的，就是「對未來的不確定性會導致焦慮，而焦慮會更進一步讓我們無法發揮出實力」
順著這篇心得看了演講影片，發現作者提出了一個我沒想過的觀點：我們能不能先從姿勢或動作這些生理上的因素，去影響我們的心理？
例如說藉由「充滿力量」的肢體動作，讓我們覺得自己「充滿力量」？
之前聽說過肢體語言佔了溝通裡很重要的一環，但我並沒有反過來想過「用肢體語言來影響自己」的做法
……
年假已經過了一半，離開工越來越近了。今天想轉貼一篇之前看到的讀書心得：
《贏回自主人生，終結過勞崇拜》讀後心得與三個深刻體悟
在這本書中提到一個常見的迷思：我們經常會不自覺把「忙碌」和「成就」畫上等號，好像越忙就越有生產力、越有成就；而越不忙的鐵定是因為工作量不夠多。但針對這個奇怪的連結，作者問：
忙碌跟工作的成就是同一件事情嗎？
接著，作者從這個疑問，介紹了忙碌謬誤的假象：
這是一種叫做「忙碌謬誤」（Hustle Fallacy）的假象。我們覺得只要再努力一點，就可以撐過所有壓力。
工作的要求不斷累積，而我們則努力跑得更快。我們覺得只要工作方法更精明、工作效率衝高，就可以趕上進度，甚至超前進度。但是不管我們怎麼做，工作責任總是跑得比我們的努力還快。
我們之所以會掉入忙碌的陷阱，就是因為我們覺得只要生產力夠高、只要我們夠努力、只要能夠「來一件事就解決一件事、來十件事就解決十件事」就可以把工作「做完」
但實際上並不是這樣的，我們永遠都會有無限多的事情可以做。真正重要的是搞清楚優先順序：
「超時工作的主要原因，就是因為我們沒搞懂最重要的是什麼，所以我們急著把要發生的每一件事處理掉，而不是持續專注在幾個不可妥協的重要任務上，也就是自我照顧、重要人際關係和專業成果。」
真正重要的事情是什麼？書中提倡三種「不可妥協的重要任務」
分別是「自我照顧」，也就是先照顧我們的健康、情緒、休閒嗜好、運動活動、與親密的人的相處時光
接著是「重要人際關係」，包含我們的家人、伴侶、子女和最要好的朋友，經營這些關係需要刻意安排時間
最後是「專業成果」，也就是我今天要專注在什麼地方，才能在未來產出更好的工作成果。
這三種不可妥協的任務都是屬於「重要，但是不緊急」的事情。要如何專注在這些事情上面？方法就是把這些事情「優先」排在行程表上。
我覺得這個順序對每個人也許並不一樣，但找到「不可妥協的重要任務」這點，應該都會是必須學習的目標。
而上面提到的「優先排在行事曆上」，也頗有我們之前轉貼的時間成本和進攻型行事曆的味道。
在這篇瓦基的心得中，我最喜歡的是這句。希望開工之後我也能這樣期許自己：
……我給自己的新方向是避免跟別人炫耀：「我真的好忙喔。」相反的，我更想讓自己的回答是這樣的：「我沒有很忙，但我都在做重要的事情。」
剛剛才知道，原來還有台灣本土版語言模型這檔事 @@ 轉貼上來一起長知識：
AI 共筆 - 台灣本土版語言模型 - Taiwan LLM 是怎麼煉成的？-黑暗執行緒
來源影片：Taiwan LLM 解析台灣第一個大型對話式語言模型 - 林彥廷
其中一個部份讓我比較驚訝，是在展示 ChatGPT 和 Taiwan LLM 回答的部份
當詢問「什麼是載具」的時候，ChatGPT 會回答：「載具是購物袋或容器，他是問你要不要裝袋…」
而 Taiwan LLM 能夠回答：「載具是儲存電子發票的設備…」
很明顯就有慣用詞的差異，也讓 GPT 產生了更多的誤會
也因此，往後 AI 助理也會需要做更多的在地化，才能更精準地幫助使用者解決問題
就像文章裡寫的這段：
……LLM 的訓練資料繁體中文佔比很低，在全世界的文本可能佔不到 0.1% (英文 54%、西班牙文 30%，中文僅 1%；其中簡體中文 90%，繁體中文 10%)
語言不只是翻譯就好，在文化、價值觀、常識 (例如：發票載具) 方面也要對齊才算在地化，使用者多聊兩句便能感受這是會講中文的外國機器人，還是真的具有台灣魂？
大年初一的，大家一定忍不住想趕快 Coding 了吧(?)
這邊轉貼一篇我查閱頻率超高的工具文章，讓大家在龍年 Commit 的時候可以龍謀問題：
Git Commit Message 這樣寫會更好，替專案引入規範與範例
這篇裡最推薦大家看的部份是「好與不好的真實案例」，完全體現出好的 Commit Message 對 抓戰犯 釐清問題是多麼的有幫助
就像文章裡面提到的：
……Commit Message 最好兼俱 Why 及 What，讓日後進行維護人員更快進入狀況
不能只把 Git 當作程式碼的 FTP，要把 Git 當作歷史查閱的工具才拿發揮 Git 的功能
邊咳嗽邊繼續清空收件閘。今天想轉貼的是一篇整理了許多時間管理相關概念的文章：
【時間管理】一篇文章搞定時間管理的所有技巧！
這邊節錄幾個我比較有共鳴的段落：
在《高效能人士的7個習慣》裡，史蒂芬·柯維 (Stephen Covey) 提到了一個故事。
說美國的小鎮裡有個消防隊，他們每天都疲於奔波在”重要且緊急”的火災上，而一旦火災發生是要出人命的，連消防員自己可能都有生命危險。所以他們就在想 —— 有沒有辦法做些什麼，來降低火災發生的機率呢?
於是，為了讓自己每天不用在出生入死，他們決定除了救火之外，要把大量的時間，放在了”重要但不緊急”的上街檢查上 —— 防火通道、滅火器、老化電路、易燃物和各種隱患……
雖然剛開始工作量明顯增大了，但過段時間後，小鎮發生火災的機率真的減少了，並開始有了正向循環 —— 消防隊有了更多了時間上街檢查，災情又進一步的減少，到最後，這個消防隊的主要工作變成了防火，而不是救火。
… 之前之所以有那麼多”重要又緊急”的事情頻繁發生，就是因為你在”重要但不緊急”的事上做得還不夠。
看到這一段的時候我在想：我們維運老舊系統的時候，是不是也一樣呢？
我們會有很多地方需要去救火，但如果我們真的要降低救火的頻率，反而更應該投入資源在重構和優化上，讓系統變得更穩固
就像這一段提到的「到最後，這個消防隊的主要工作變成了防火，而不是救火」
也許正是被舊專案的 Bug 燒得死去活來時，最需要的思維吧
……
我們在 1/25 的時候轉貼過安德魯大大的「開發人員該如何看待 AI 帶來的改變」
今天看到 Alan Tsai 大大也發了一篇相關的文章，覺得其中一段蠻有趣的，決定轉貼上來：
回顧一下 .NET Conf Taiwan 2023 提到的 Generative AI 的衝擊和應對準備 - Alan Tsai 的學習筆記
Generative AI 的 Application 某種程度上和你要交辦工作請人處理是一樣的道理
今天你給的描述夠精準，請人完成的機率就越高。因此你的溝通技巧越好（Prompt Engineering），那麼你請的人（Generative AI Application 或者說 LLM 模型）完成符合你預期的機會就越大
所以，從用的角度來說，請把 Generative AI Application 當成是一個技術能力很好，但是不會思考的工程師
也許能夠說明為什麼有些朋友用 GPT 用得很順，而有些朋友總是覺得 GPT 在雷？
……
今天是過年前最後一天工作日了，早就已經無心上班等著吃尾牙。決定分享一些和過年有關的有趣小知識：
四格漫畫看台灣民俗（上）：除了年獸之外，台灣其實有自己的新年「燈猴」傳說
在日治時期刊物《民俗臺灣》、《語苑》中，都曾記載著台灣的「沉地傳說」，也就是吃不到「餉耗」湯圓的燈猴胡亂告狀，導致台灣差點被玉皇大帝沉入海中的故事。
傳說玉帝原本有意在大年初一將大地沉入海裡，人們聽到傳聞十分緊張，連忙通知在外的家人回家團聚，在過年前一天圍爐，吃最後一頓飯，並守夜以免在睡夢中被沉入海裡。
世界末日近在眼前，好在眼見人間騷亂的土地公連忙求見玉皇大帝告知實情，危機才終於解除。
初一清晨，人們發現台灣並沒有沉沒，連忙互道恭喜，表達劫後餘生的心情。
至於燈猴，只能繼續擔任照明的燈具，在佛桌上供奉神明。並且每年圍爐時舊的燈猴會被燒掉換成新的，以焚燒之苦作為懲罰。
除了燈猴的故事，這篇文章還蘇州碼子、床母之類的民俗小故事漫畫
之前我都只知道年獸，前幾天滑推的時候看到有人提起燈猴，這才知道了台灣史上最大危機(?)，也算是長知識了
……
昨天的轉貼文聊到 HTTP Status Code，正好今天想起了一篇之前挺喜歡的文章，貼上來給大家
一把梭：REST API 全用 POST - 酷壳 CoolShell
分享幾個我比較有共鳴的部份，最強烈的是關於標準的部份：
Restful API 算是一个 HTTP 的规范和标准了，你要说是最佳实践也好，总之，它是一个全世界对 HTTP API 的一个共识。
在这个共识上，你可以无成本地享受很多的技术红利，比如：CDN，API 网关，服务治理，监控……等等。
这些都是可以让你大幅度降低研发成本，避免踩坑的原因。
這和作者的另一篇文章想表達的一樣，這邊作為延伸閱讀貼上來： 我做系统架构的一些原则 - 酷壳 CoolShell
……只有服从了标准，你的架构才能够有更好的扩展性。
比如：我经常性的见到很多公司的系统既没有服从业界标准，也没有形成自己公司的标准，感觉就像一群乌合之众一样。
最典型的例子就是 HTTP 调用的状态返回码。业内给你的标准是 200 表示成功，3xx 跳转，4xx 表示调用端出错，5xx 表示服务端出错
我实在是不明白为什么无论成功和失败大家都喜欢返回 200，然后在 body 里指出是否 error（前两年我在微信公众号里看到一个有一定名气的互联网老兵推荐使用无论正确还是出错都返回 200 的做法，我在后台再三确认后，我发现这样的架构师真是害人不浅）。
这样做最大的问题是——监控系统将在一种低效的状态下工作。监控系统需要把所有的网络请求包打开后才知道是否是错误，而且完全不知道是调用端出错还是服务端出错，于是一些像重试或熔断这样的控制系统完全不知道怎么搞（如果是 4xx 错，那么重试或熔断是没有意义的，只有 5xx 才有意义）。
有时候，我会有种越活越退步的感觉，错误码设计这种最基本最基础的东西为什么会没有？并且一个公司会任由着大家乱来？这些基础技能怎么就这样丢掉了？
又到了憂鬱的星期一，按照慣例(?)該分享一些輕鬆的東西了。今天想轉貼給大家的是這篇：
常見與不常見的 HTTP Status Code - Noob’s Space
相信 Http Status Code 大家都很熟了（不熟的朋友請進：什麼是 HTTP Status Code ）
而分享這一篇的原因是：它介紹了 Http 418 - I’m a teapot xD
等等，你說 HTTP 418 是什麼？我是一個茶壺？
HTTP 418 是 1998 年訂的愚人節笑話（收錄在 RFC 2324），指當一個控制茶壺的伺服器收到要求煮咖啡的 Request 時候，要回應 418，告訴使用者這是一個茶壺不是咖啡機 XD！
其中一段也很鬧：「控制茶壺的伺服器收到要求煮咖啡的 Request 時候，要回應 418？」
這就不得不提到我們的 HTCPCP 了，全名 超文字咖啡壺控制協定。顧名思義，就是用來煮咖啡的：
……該協定被設計為一個類似 HTTP 的協定，可以用於控制、監測和診斷咖啡壺，後來也被拓展到茶壺
今天放假有整個早上的時間，決定來整理 Discord 上面大大貼的香香文章：
Avoiding Double Payments in a Distributed Payments System
裡面提到實現最終一致性的三種方式：
Airbnb 他們在不同的地方都有應用到這三種方式，這篇主要是介紹使用了 write repair 的解決方案。也就是每次客戶端向服務器發出寫入請求時，都會嘗試修復不一致、破損的狀態。
為了讓客戶端能夠自動重試，就需要讓 API 是具有冪等性的：重複發出相同的 Requset，結果也會保持一致。而因為他們需要極低的延遲，不能拆服務出來跑，所以他們弄了一個叫做「奧菲斯（Orpheus）」的 library 來處理這件事
這邊整理了一些我（覺得）可能會遇到的相關內容，有興趣的朋友也可以閱讀原文，文章內有許多圖片來進行說明，值得一讀。
整個 API 請求會被重構成三個部分：
因為資料庫已經提供了 ACID，並且只會產生兩種結果（成功或失敗）。因此 Pre-RPC 和 Post-PRC 對資料庫的操作都會包成 Transaction，確保一起成功或失敗。文章內示範了使用 Java 的 Lambda 來把多個操作包在一起（C# 應該用 EFCore 就可以了？）
延伸閱讀：淺談關聯式資料庫與ACID特性
除此之外，他們還嚴格地將資料庫操作和網路互動拆開，藉此降低風險
To maintain data integrity, we adhere to two simple ground rules: 為了保持數據的完整性，我們遵循兩個簡單的基本原則：
No service interaction over networks in Pre and Post-RPC phases 預先和後續的RPC階段中，網絡上沒有服務互動
No database interactions in the RPC phases 在 RPC 階段中沒有數據庫交互
為了確認能不能夠重試，所有的錯誤都要被分類（當然也會遇到一些比較模糊的）：
In general, we believe unexpected runtime exceptions due to network and infrastructure issues (5XX HTTP statuses) are retryable. We expect these errors to be transient, and we expect that a later retry of the same request may eventually be successful.
一般而言，我們認為由於網路和基礎設施問題而引起的意外運行時異常（5XX HTTP狀態）是可重試的。我們預期這些錯誤是暫時性的，並且我們期望稍後重新嘗試相同的請求可能最終會成功。
……We categorize validation errors, such as invalid input and states (for example, you can’t refund a refund), as non-retryable (4XX HTTP statuses) — we expect all subsequent retries of the same request to fail in the same manner. We created a custom, generic exception class that handled these cases, defaulting to “non-retryable”, and for certain other cases, categorized as “retryable”.
我們將驗證錯誤分類為不可重試的錯誤，例如無效的輸入和狀態（例如，無法對退款進行退款），這些錯誤屬於非可重試的類型（4XX HTTP狀態碼）- 我們預期同一請求的所有後續重試都會以相同的方式失敗。我們創建了一個自定義的通用異常類，用於處理這些情況，默認為“不可重試”，對於某些其他情況，則歸類為“可重試”。
