如果想複製某則動態的連結，可以按右下角的🐔。但不開放留言，因為我玻璃心。
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）。
- 規則：將原理轉化為可操作的行為準則。
- 程式：將規則寫入系統，使其能自動判斷與執行。
這樣寫出來的程式碼，不但有邏輯，更有根據，因為它回應的是人類的真實經驗與目的。
有次，我們的系統在午間出現異常。
某個服務負載暴增，導致對外 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？），更不用說人物和場景設計都很有魅力，很容易沉浸在遊戲世界裡，腦子充滿刺殺計畫，力求完美執行。
決定再開來玩一把，該在遊戲裡刺殺些工作人員來表示尊敬了吧。
搜了一下要用來推坑給朋友的介紹文章和影片，目前這部提的內容最接近我想推的點：
