試了一下 Heptabase 的 AI Chat，挺好用的。
我習慣開發時先把大致上要實作的方法跟相關資訊都開一個工作用白板丟著。有了這功能之後，不用再敘述一堆五四三，可以直接和 AI Chat 討論目前設計有沒有缺漏、有哪些替代方案，或是請它先幫我整理參考資料，用起來蠻方便的。
另一個覺得不錯的場景是配合我的 Calendar 白板，我會把一整季的 Journal 開個白板丟一起，而且會把一些有的沒的想法記在當天的筆記上。
昨天開 Chat 請它整理上一季最開心和最不開心的日子、工作項目、有趣的想法等等，有種把之前的想法和感受撿回來的感覺，蠻新奇的。
有種 Chat 還是要基於知識庫才能正確發揮的感覺。
年終其實是最糟糕的邪惡，因為它延長了社畜的痛苦。
和朋友聊到了最近 AI 對我們工程師工作模式的改變。他提起了他最近聽到、比較有感受的一段：
有些人會說：我知道 AI 逼迫著軟體工程師要轉換工作方式，但我就不想要跟人溝通，怎麼辦？
背後的問題是：你是真的這麼喜歡寫程式？還是喜歡解決問題？如果你只是很喜歡敲鍵盤，那可能就沒辦法；如果是喜歡解決問題，今天只是換了一個方式讓你去解決問題，你怎麼就不能接受了？
對這段話，我蠻認同的。
但我同時也認為：如果是喜歡解決問題的，到某個階段就會意識到「程式不是唯一解，甚至某些問題不該優先解」有著這樣觀念的人，根本不會產生上面這種疑問。
除了所謂「喜歡解決問題的人」以外，我也不認為所謂「喜歡敲鍵盤的人」只有一種，就算是喜歡敲鍵盤，本質上還是有區別。
有些人，本質是某種工匠，享受用合理或精妙的方式來提出解決方案的快感，架構、權衡、程式碼風格都只是一種技巧展示，這種人根本不可能不碰 AI，光是 AI 能擴展眼界和更高效的實作頻率，就不可能放棄；
但某些「敲鍵盤」的，本質是一種逃避，你跟他們對話的時候，他們會說「因為我不想跟人接觸」「因為我不想搞辦公室政治」「因為我不想走服務業…」，對於這類人，我覺得今天即便遇到的不是 AI，也遲早是要被沖刷掉的吧。
小時候讀「佛渡有緣人」這句話，以為是佛祖只幫有慧根、聰明的人，或者是要有誠意才能打動祂。現在覺得，可能因為是站在過來人看得清楚，知道自己無法幫助每一個人，才選擇放手。
剛好聽到股癌 podcast EP568，裡面提到有一種來請教的人，明明是來尋求建議的，自尊心卻很高，聽到了建議卻想要反駁、辯論到底。於是股癌只要發現對方開始辯論、也不想要改變，就會直接離開，祝他好運。
一個人要改變的前提，必須是自己想要改變。
可能是這陣子遇到會主動來討論問題的人，也看到兩手一攤說「我就是不會」的人，所以讀到這段的時候特別有感吧。
想到之前讀《QBQ！問題背後的問題》看到的一段：
有些人知道自己正試著改變別人，只是不想承認罷了。
有一次，我和一位負責員工訓練的經理，正為了QBQ 的課程做最後安排，她問：「你想知道副總裁為什麼要安排這些課程嗎？」
「當然。」我提高注意力，不知道她接下來想說什麼。
「他想調整艾德。」
調整艾德？
她接著解釋說，艾德是一位不稱職的主管，但副總裁並沒有擔起責任， 也沒有開誠布公地處理眼前的狀況， 反而要整個團隊接受訓練。「調整艾德」這四個字在我腦海一再出現。
還有人把改變他人視為己任。我拜訪過一位年近三十的男士，他竟然說：「我相信『改變他人』是我的責任，因為我是管理者！」抱歉，管理者是無法改變人的。管理者可以輔導、諮商、教導，但是誰都無法改變他人。唯有當事人痛下決心，才可能從內心改變。
這是很難學會的一門功課。即使口口聲聲說自己「懂了」，但是距離了解「是的，我只能改變我自己！」、並誠實檢視自己的真實想法和行為，還相差甚遠。
讀到「調整艾德」的時候真的蠻衝擊的，但看完整段之後反思，其實工作時也很常產生這種想「調整艾德」的慾望和衝動。
學會「放下助人情節、尊重他人命運」比想像中還難。
前兩週突然無法上傳圖片到 Imgur，嘗試登入也只會跳「Imgur is temporarily over capacity. Please try again later」的 Error，回報客服也沒有下文。
{
"data": {
"error": "Imgur is temporarily over capacity. Please try again later."
},
"success": false,
"status": 500
}
今天突然看到巴哈有人說台灣 IP 被 Imgur 給擋了，試了一下用 VPN 跳出去，還真的就能登入上傳了囧
更新：直接寫成一篇了 → Imgur 一直 temporarily over capacity 嗎？先檢查網路看看吧
在推特上看到有公司把 HTTP 狀態 4xx 當成功在用，看來複習這篇的時候又到了。
最典型的例子就是 HTTP 調用的狀態返回碼。
業內給你的標準是 200表示成功，3xx 跳轉，4xx 表示調用端出錯，5xx 表示服務端出錯，我實在是不明白為什麼無論成功和失敗大家都喜歡返回 200，然後在 body 裡指出是否error（前兩年我在微信公眾號里看到一個有一定名氣的互聯網老兵推薦使用無論正確還是出錯都返回 200 的做法，我在後台再三確認後，我發現這樣的架構師真是害人不淺）。
這樣做最大的問題是——監控系統將在一種低效的狀態下工作。 監控系統需要把所有的網路請求包打開后才知道是否是錯誤，而且完全不知道是調用端出錯還是服務端出錯，於是一些像重試或熔斷這樣的控制系統完全不知道怎麼搞（如果是 4xx錯，那麼重試或熔斷是沒有意義的，只有 5xx 才有意義）。
有時候，我會有種越活越退步的感覺，錯誤碼設計這種最基本最基礎的東西為什麼會沒有？ 並且一個公司會任由著大家亂來？ 這些基礎技能怎麼就這樣丟掉了？
「在網路上寫文章的人」本身就是非常珍貴的資源，隨著成長，他們有可能寫出有益的文章，我想這一點也能獲得共識。本文主張，應該保護這樣的人，讓他們不會被打擊，並鼓勵他們撰寫技術文章。
推這篇對於「規則」和「情境」的舉例。
明確的故事能幫助我們更快理解程式所要達到的目的，尤其是無腦捏測試的時候如果已經有使用者故事就更舒服（？）了。
故事思維：程式是規則的實現，而原理來自情境 - Ruddy Lee 分享空間
情境是理解問題的橋梁
什麼是「情境」？它並不是指我們蒐集了多少資料，也不是使用者提供了幾頁需求文件。
真正的情境，是對於角色、目標、限制與變因的整體掌握。
舉例說明：
某家系統的使用者經常反映「忘記密碼」，讓團隊直覺地想要簡化登入流程。但進一步訪談後發現，這群使用者多半是年長者，而且常常在公共電腦上操作，不敢使用「自動記住密碼」，也不熟悉手機驗證流程。
這段故事，遠比單一句「忘記密碼」來得有意義。它幫助我們理解為什麼某些行為會發生，也說明了什麼設計才是對的。
情境是一種知識轉譯機制，它將顯性資料轉化為理解的結構。
從故事 → 情境 → 原理 → 規則 → 程式
這是一條不該被打斷的路徑：
- 故事（原理）：清楚敘述誰遇到什麼問題、為什麼需要解決。
- 情境：萃取出具體的背景因素，建構問題的脈絡。
- 原理：在類似情境中反覆被驗證的做法（Best practice）。
- 規則：將原理轉化為可操作的行為準則。
- 程式：將規則寫入系統，使其能自動判斷與執行。
這樣寫出來的程式碼，不但有邏輯，更有根據，因為它回應的是人類的真實經驗與目的。
有次，我們的系統在午間出現異常。
某個服務負載暴增，導致對外 API 幾乎停擺。
還好有同仁臨機應變，緊急調整參數、加上快取，才把系統救了回來。當天下午，大家在 Teams 上一片感謝與稱讚：「反應太快了！」「厲害！」「幸好有你！」
然後，事情好像就這樣告一段落了。
但讓我印象很深的是——沒有人再回頭問：「為什麼會出問題？」
更沒有人提：「我們下次該怎麼避免這件事？」
這不是第一次，也不會是最後一次。
很多團隊都有個像是默契般的傾向：只看事情怎麼解決，卻不去問事情為什麼會發生。
表面上看起來是一種積極正向的態度，但其實正是這種「避談錯誤」的文化，悄悄地讓我們錯失最寶貴的反省機會。
我一直很認同一句話：「寫出 bug、系統出錯、都沒關係，重點是團隊有沒有從中學到什麼?」每個迭代後的 Retrospective，才是團隊讓自己成長的機會。
看這段的時候特別有既視感。
但想了一想，這邊也還算好的了。畢竟在某些更歡樂的職場，比起「沒人追問題根源和改善」，更容易看到提出這些問題的人被當作是破壞團隊和諧的「壞人」而受到責難。
又是和和氣氣的一天，問題依舊沒有解決。
同樣地，該如何區分自我否定與自我檢討？例如：曾經搞砸了一個演講，每次準備的時候都會想到上次的失敗經驗，思考如何避免重蹈覆轍、也覺得心理堵堵的，這樣是自我檢討嗎？還是自我否定？
兩者都會有點不愉快的感受，也包含對如何改進的思考。延續前者的例子，若上次演講失敗是因為沒有檢查到設備：
自我檢討：這次要檢查的設備有什麼？要預留多少時間？
自我否定：我是一個粗心大意的人嗎？我要怎麼成為細心的人？
上述兩段討論都涉及改善、都會懊悔，但前者無關自己是什麼樣的人，極端而言，發生一百次都還是無關，依舊是純粹的問題解決；而後者貼了標籤與評價，發生幾次後，可能就會認同這個自我描述。
看到這段自我檢討和自我否定的差異有點感想。
儘管隱約察覺到有些檢討只是某種自我否定，但還是很容易會把問題歸咎於自己或他人的某些特質，認為「如果不是因為這些特質（例如粗心、驕傲等等）就不會犯下這樣的錯吧。」
但這樣一來，就能很容易地把發生的問題都怪罪在性格的弱點上，也許反而是某種逃避也說不定。
身為資深軟體開發者，應該要有能力培養技術等級低的開發者，而不是排擠或邊緣化他們。一個有能力培養新進開發者的資深開發者是更有價值的。在遊戲裡，30% 團隊戰鬥力加成的靈氣，通常是很強的技能。
我決定 Log Level 只有兩種方式：
- 參考下面的 Stack Overflow 討論串
- 無腦 Info（= 非常遵循團隊默契 :D ）
logging - When to use the different log levels - Stack Overflow
Trace - 只有在我會「追蹤」程式碼並試圖特別找到函式的一部分時才使用。
Debug - 對開發者以外的人（IT、系統管理員等）在診斷上有幫助的資訊。
Info - 一般有用的記錄資訊（服務啟動/停止、設定假設等）。這些是我想要永遠可用但在正常情況下通常不會在意的資訊。這是我預設的設定等級。
Warn - 任何可能導致應用出現異常但我會自動恢復的情況（例如從主伺服器切換到備援伺服器、重試操作、次要資料遺失等）。
Error - 對某項操作致命但不會使服務或應用程式當機的錯誤（無法開啟必要檔案、缺少資料等）。這些錯誤會迫使使用者（管理員或直接使用者）介入。在我的應用中，通常用來表示錯誤的連線字串、缺少服務等情況。
Fatal - 任何將強制關閉服務或應用程式以避免資料遺失（或進一步遺失）的錯誤。我僅將此等級保留給最嚴重的錯誤和確認已發生資料損毀或遺失的情況。
「有研究顯示，打字的時候不喜歡在中文和英文之間加空格的人，感情路都走得很辛苦，有七成的比例會在 34 歲的時候跟自己不愛的人結婚，而其餘三成的人最後只能把遺產留給自己的貓。畢竟愛情跟書寫都需要適時地留白。
與大家共勉之。」——vinta/paranoid-auto-spacing
昨天還在開《暗影戰略：將軍之刃》拚關卡速通成就，今天無意間看到遊戲工作室 Mimimi Games 原來已經解散了，有點感慨。將軍之刃真的是一款很棒的遊戲。
將軍之刃的每個關卡都有不同的條件和限制，局部區域也有不同的敵兵要處理，玩家能採用的解決方案也不只一兩種。這就組成了一環接一環的謎題鏈，玩家必須考慮各種限制和我方行動去規劃策略、嘗試突破眼前的阻礙，完成任務目標。
在這段遊玩過程中，觀察、規劃、嘗試、不斷調整，最終達成目標的爽快感是難以言喻的（感覺有點像 Coding？），更不用說人物和場景設計都很有魅力，很容易沉浸在遊戲世界裡，腦子充滿刺殺計畫，力求完美執行。
決定再開來玩一把，該在遊戲裡刺殺些工作人員來表示尊敬了吧。
搜了一下要用來推坑給朋友的介紹文章和影片，目前這部提的內容最接近我想推的點：
FromSoftware 在 Switch 2 推出的新作 The Duskbloods 看起來超香，可惜我家的 Switch 買來根本沒開過幾次，實在買不下新機，只能流著口水等移植了。
不過看隔壁一卡車都上 PC 仍然無動於衷的血源……🥲
在朋友的推坑下開始玩 Wizardry Variants Daphne 了，目前進度在第一章王關前。
第一人稱視角帶來的帶入感，跟開場時怪物步步進逼的壓迫感營造得很不錯，在一些陷阱和地圖設計的惡意（例如進怪物房被鎖門）也很有緊張感。
劇情方面，重要角色死亡時會跳出死因相關的「知識」，暗示後續能嘗試逆天改命的感覺很不錯。目前傾向會繼續玩一陣子（雖然對於角色連續死亡可能會永久消失的設定還是有點不安就是了）
不過入坑時正在舉辦的活動是周回刷箱類型的，即使受過 FGO 嚴苛的訓練，要不斷重複走圖開箱的作業感還是很重，只能希望後續的活動不要這麼無聊就好了。
舊專案過弱掃時被擋，原來是前人快樂組裝 XML 的地方翻車了。如此如此這般這般，認識了 XXE（XML eXternal Entity） Injection：
Cognitive load is what matters
Cognitive load is how much a developer needs to think in order to complete a task.
認知負荷是指開發者為了完成某項任務需要思考的程度。
When reading code, you put things like values of variables, control flow logic and call sequences into your head. The average person can hold roughly four such chunks in working memory. Once the cognitive load reaches this threshold, it becomes much harder to understand things.
在閱讀程式碼時，你會在腦中放入變數的值、控制流程邏輯以及呼叫序列等資訊。一般人工作記憶大約能同時保有四個這類資訊區塊。一旦認知負荷達到這個門檻，理解事物就會變得困難許多。
腦子的容量有限，請珍惜使用。
文字溝通時，為求快，假設對方已經知道某些關鍵資訊，例如討論主題、縮寫、專有名詞。原本希望節省「自己」的時間，沒想到對方會錯意，進而浪費了「全部人」的時間。
看似小賺，實則大虧。戒之，慎之。
以為對方不知道，說得多了，效率就差了
以為對方知道，說得少了，誤會就產生了
也許合作默契的前提，就是能先掌握彼此持有的資訊吧
qing 兄的兩篇文章指出程式員的兩種型態，一是重視演算法、資料結構、執行效率的「效率魔人」，二是重視程式架構、擴充性、彈性、可理解性的「架構狂」。這兩種人其實都很好，要完成一個偉大的軟體，團隊中兩種人一定都要有。
比較糟糕的是，有很多「第三型態人」，他們的信念只有一條：「程式只要會動就好」。第三型態人不在乎效率，也不管架構漂不漂亮，上面要求他做什麼，他就想辦法東湊西湊，從 Google 找程式剪貼，從 MSDN 抓範例來用，反正只要能隨便測過一個 case 就能交差了。
其實第三型態人也不一定是不懂演算法、不懂 design patterns，他們常常只是因為火燒屁股了，就不管三七二十一先弄出可以動的程式再說，效率或架構等到下一階段再來改就好…。
問題是，下一階段又有新的功能要做，這些人再度面臨抉擇時還是會決定先讓程式「會動再說」。
我看過很多各式各樣的程式員，只要碰到這種人，同樣的過程是履試不爽不斷出現。
這一切都是 trade-off。
對你來說程式寫得漂亮很重要，但因此失去了即時完成的時間；但另一種人來說，他們可以用很醜的方法很快完成，但接下來要再繼續在這基礎上做更多修改就「應該」要花更多時間。
要注意的是，我說應該是因為事實不見得是這樣。如果你用很漂亮的程式完成了工作，但接下來後續的維護和修改沒有幫你或者整個團隊省到時間，那其實是代表你之前的時間白花了。相反的，另一種人雖然草率的寫完一開始的程式，但他可能是發現這程式也只會被用一次，用完就再也不會被維護了，這時他其實是做了對的選擇，幫團隊省下很多時間。
如果你對程式的架構和 style 很講究，這是好事。但同時，在有限的時間和資源下完成也是很重要的。如何拿捏其中的平衡就是個人本事了。
從「就可以不把程式寫好嗎？」的疑問想起了之前看過的這一篇。
也許差別只是我們決定成為哪一種人，以及我們在開發的過程中又如何去權衡吧。
