告警越多，通知就越多；
通知越多，對通知麻痺的人就越多；
對通知麻痺的人越多，能被看到的告警就越少。
所以，告警越多，告警越少。
這次鏈鋸人的〈JANE DOE〉聽起來有種圓舞曲的感覺，重播了好幾次。搜到了這篇訪談，原來是這樣子的畫面呀
【音樂翻譯‧雜感】米津玄師 - JANE DOE - 箱庭博物館
── 撰寫〈JANE DOE〉的歌詞時你有過什麼畫面嗎？
米津：首先浮現的是，赤著腳站在破碎成片的玻璃上，用割傷的腳前進的景象呢。蕾潔是一位來歷不明的女性，對她來說生活的重心就在於消除自己的痕跡而活。擁有這樣人性一面的她，在玻璃碎片上行走，傷口鮮血直流，成為一個又一個的紅色腳印，這景象首先浮現在我的腦海，讓我想到「妳就是這樣走來的呢」。我思考這樣的景象是否能成為這首歌的主軸。
偶然看到真三國無雙２要重製的消息，真令我歡喜。
二代是我認識無雙的入坑作，當時 PS2 一半時間都給了它，留下了在合肥新城涼亭被弓箭手射成刺蝟、打南蠻被大象輾過去的一卡車遊戲回憶。想不到隔了二十幾年，還有機會用當代的畫質重溫當年的感動，這次只能謝謝光榮了
在受過職場無情的鞭打之後，我現在信奉的估時技巧是：
「數值和單位各加一」
兩小時就是三天，三天就是四週
有專案要做到年底？跟我的退休金說去吧
同事們還在把點數當划拳喊的時候，我已經在看股票了
這就是生產力的差距。
來聊聊那些非常欠人教訓的提問 & 發問 | 是 Ray 不是 Array
清楚描述你的邏輯以及過程
除了上面提到的「#求解」、「#救命」、「#我不會」、「#我不懂」以及「#在線等」等字眼，不可以出現在問題內容中之外，你也必須清楚 詳細的描述你的程式碼邏輯，如果你不清楚的話，我會這樣建議您條列你的問題：
- 提供原始碼
- 覺得有問題的檔案以及行數
- 你預期結果會出現什麼
- 但實際結果是什麼
- 你已經嘗試過哪些以及搜尋過哪些資料
- 你理解之後又是如何
除了這些之外的內容「通通不要有」，我是認真的。
今天在脆收到這篇，基本上就是當代白話版的〈提問的智慧〉，決定關聯到之前分享過的精準提問術做為參考，同時列到「當同事問了奇怪問題時直接甩過去」的文章清單
這週假日完全投入在絲之歌，目前進度為腐汁澤結束。
這代的推圖跳跳樂有感變多，即使是當年能在楓谷忍耐任務叱吒風雲的我也有點吃不消，尤其某些椅子和 BOSS 相距很遠，甚至加上跳跳樂 + 車輪戰 + BOSS 戰的可怕 Combo，死了馬上就得重跑，跑到都快幻聽〈三百六十五里路〉了，非常痛苦。
但戰鬥實在太好玩，大黃蜂的機動性非常高，在拿到飛針這類技能之後，搭配道具和下劈可以打出令人舒暢的空中戰鬥，還有不同紋章帶來的不同攻擊模組及特性，純論打架的話實在沒什麼能挑剔的，打完一場考驗玩家勇氣和冷靜的 BOSS 戰所帶來的快樂（或是用外鄉手段解決一些專門噁心人 BOSS 的愉悅）足以讓我願意多跳上兩三小時的跳跳樂。
幸好下週還有教師節連假，希望能一路殺進第一個結局。
10.22 回來補上這部影片：
【絲之歌】為什麼我說 腐汁澤的設計水準並不低？ - Bilibili
刷到這部談腐汁澤地圖設計的影片。回想了一下，雖然玩的時候氣得牙癢癢，但通關後的確會覺得腐汁澤是優秀的關卡。
開場先展示陷阱方向的差異，過程中也讓玩家有足夠次數練習躲避怪物的攻擊，大量利用標示和習慣誘導玩家踏入陷阱，並且基於玩家前面對蛆水的經驗形成的厭惡，準備了如果敢跳進蛆水反而更好打的 Boss 戰和隱藏補給點。
雖然有非常噁心的超長跑圖打王環節，但如果不是精心設計的話，還真的沒辦法給玩家留下這麼深的恨意，值得敬佩。
Heptabase Gallery 上線了： https://heptabase.com/gallery
能夠正大光明的逛別人的白板對我來說是一件很有趣的事，畢竟比起某個問題的答案，我更常好奇「其他人是怎麼思考、理解、梳理這個問題的？」前陣子曼報 Pro 開賣的時候，也是看到有「研究團隊筆記 x1」就課下去了
趁著出門前上去巡了一圈，真香，期待後續更多人投稿的白板。
Do the simplest thing that could possibly work - sean goedecke
When designing software systems, do the simplest thing that could possibly work.
在設計軟體系統時，盡可能做出最簡單可行的事。
You really can build a whole application from scratch this way: start with the absolute simplest thing, and then only extend it when you have new requirements that force you to. It sounds silly, but it works. Think of it as taking YAGNI as the ultimate design principle: above single-responsibility, above choosing the best tool for the job, and above “good design”.
你真的可以用這種方式從零開始構建整個應用程式：先從絕對最簡單的做法開始，然後只有在出現迫使你擴充的新需求時才去擴充。這聽起來很傻，但它有效。把它當作把 YAGNI 當成終極設計原則：高於單一職責、高於為工作選擇最佳工具，以及高於「良好設計」。
「找出最簡單的解法需要考慮許多不同的做法。換句話說，這需要工程思維。」
「出色的軟體設計看起來平淡無奇」
這幾句都讓我想到之前在令人難以理解的「軟體工程師」生涯看過的這段：
二流的軟體工程師，喜歡把簡單的問題弄的複雜，寫出別人看不懂的程式。
一流的軟體工程師，喜歡把複雜的問題簡單化，寫出架構清楚明白的程式，讓人看了之後，覺得問題好像很簡單。
三流的軟體工程師會去崇拜二流的軟體工程師，因為他們會覺得二流工程師寫的程式都看不懂，一定是超級厲害。
三流的軟體工程師不會去崇拜一流的軟體工程師，因為他們會覺得一流工程師所做的事情都很好懂，好像都很簡單。
只有一流的的軟體工程師才會佩服一流的軟體工程師，因為只有他們才能看的出來，其他的一流軟體工程師厲害在哪裡？
今天學到的新詞：大便化 （Enshittification）
Enshittification（大便化）
其實這種現象有個專有名詞，叫做「Enshittification」（大便化、變爛化）。這個詞是由作家 Cory Doctorow 提出的，用來描述網路平台和軟體服務的生命週期：
💕 第一階段，對使用者好：軟體剛推出時，超好用、超乾淨、使用者體驗極佳。
💰 第二階段，對商業客戶好：累積了大量用戶並將他們綁架後，平台開始對廣告商好，到處狂塞廣告，使用者體驗開始大幅下降。
🪓 第三階段，收割韭菜：等到商業客戶也被綁架後，平台開始兩面通吃，從所有人身上榨取最大價值。這時產品會變得超爛，但因為大家都用習慣了，資料都在上面、朋友都在用、流量都靠它，根本跳不走，就只能咬牙忍受。
🪦 第四階段，平台死亡：平台變得實在太爛、太貴、太煩人，最終被新的競爭對手取代，重新開始第一階段的循環。
《禪與摩托車維修的藝術》：
她寫不出文章，是因為她聽過別人針對同一主題的說法，想依樣複誦在紙上，正如斐卓斯在第一堂課上想重複自己決定要說的內容一樣。她不知如何描寫波司曼，是因為她回憶不出值得複誦的說法。奇怪的是，她不知道自己可以找找看，不懂得以個人的新角度看待事物，付諸文字，不需把全副精神放在別人說過的話。當範圍縮小到一塊磚頭時，便突破了心障，因為她不得不正面去觀察主題，寫一些原創的東西。
如果寫不出東西，可能是因為自己並沒有什麼想說的話。
之前想寫但放最久的筆記，反而是網路資源和相關文獻豐富的主題。只是單純把資料放在一起是不行的，你終究要把他們關聯起來，才能從中得到一些自己的東西。
The Brain’s Power to Read Jumbled Text | by Watathi, N. S. | Medium
它是什麼？這個現象令人著迷。當一個字中的字母被打亂，但第一個和最後一個字母保持原位時，大多數人仍然能閱讀出來。大腦幾乎能即刻辨識出該字。例如，「fi yuo cna raed tihs」會變成「if you can read this」。很神奇，對吧？彷彿大腦把整個字當作一個整體來看，而不是逐個字母閱讀。這顯示我們的心智並非逐字母閱讀，而是以略讀方式運作，我們辨識形狀與模式。這個現象突顯了大腦令人難以置信的填補能力。我們仰賴熟悉度、語境與經驗來理解被打亂的文字。
它是如何運作的？一切都歸結於模式識別。我們的大腦以效率為導向。與其逐一處理每個字母，我們會掃描可識別的結構。大腦知道首尾字母是關鍵。因此即使中間的字母被打亂，也能迅速辨認出該詞。經驗也扮演著角色。熟練的讀者在解讀打亂的單字時更快，因為他們的大腦已被訓練成處理文字片段，而非單個字母。這個過程是自動且幾乎瞬間發生的。我們並不會去刻意思考──就像大腦替我們把空白補上。這種能力顯示出人類心智有多麼強大且具適應性。
感想：「漢字的序順並不定一能影閱響讀。」
試了一下 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）。
- 規則：將原理轉化為可操作的行為準則。
- 程式：將規則寫入系統，使其能自動判斷與執行。
這樣寫出來的程式碼，不但有邏輯，更有根據，因為它回應的是人類的真實經驗與目的。
