如果想複製某則動態的連結，可以按右下角的🐔。但不開放留言，因為我玻璃心。
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 很講究，這是好事。但同時，在有限的時間和資源下完成也是很重要的。如何拿捏其中的平衡就是個人本事了。
從「就可以不把程式寫好嗎？」的疑問想起了之前看過的這一篇。
也許差別只是我們決定成為哪一種人，以及我們在開發的過程中又如何去權衡吧。
或許我就是必須要跟著大家多繞點彎路，陪著大家一起犯錯，並適時的提供自己的經驗。
想到這裡突然就很感謝這些年陪著我練功的前輩們，當時看著我繞彎路時他們心情是甚麼呢？有沒有過我現在這種掙扎？
原來只是換我接棒了而已，這是我現在的答案，曾經聽過前輩們心中有種「憑一口氣，點一盞燈。」的氣魄想要改變整個大環境，我沒有那麼大的夢想，但受人恩惠的我也會試著把從大家身上學來的東西傳承下去的。
看朋友的工作心得，很喜歡這種心路轉折的整理。現在遇到一些神奇(?)的同事，也會陷入同樣的掙扎，但從『把前輩交給我們的東西傳承下去』的角度來看，也許都只是一種過程吧。
最近跟新朋友一起開發，想起了當初看到的這段：
我覺得所有的程式都可以看成一個巨大的金字塔，頂端是這個程式的最終目標，一個模糊的概念；底部是細節的程式碼。而中間是一個經由不斷切割與抽象化所構成的高塔，每一個程式都是切割為許多的元件、模組，再切為更細的 class 和 function，再來是最底下的變數與邏輯判斷式。
很有趣的是，不同的人看這個塔就會有不同的樣子。初學者看到的塔只有兩層，他們和人溝通的方法是鉅細靡遺的描述程式碼：「我在這裡寫個 for，第一次把 i 設成 0，在迴圈內每次檢查這個陣列的第 i 個元素…」
在他們眼中只有程式的目標和程式碼本身，所以還可能會寫出下面這種讓人哭笑不得的註解：
a = 1; // 把 a 設為 1有些經驗後，會再多看到一層，利用 function 把一段程式碼包裝起來，賦予一個名字和獨特的意義。學會這個後，就可以利用抽象化後的 function 名稱來溝通，例如：「我在這個迴圈裡每次都用 isCaptial 來檢查這個字串是不是都是大寫…」再接下去呢，可以再利用 class，利用 design patterns，利用更大的模組、子系統來溝通，認真說起來，這其實是一個無止境的切割。
在導入團隊之前必須有幾句話謹記在心
- 不是每個人都與你一樣對這東西有強烈的興趣。
- 你得非常清楚優劣在哪裡，不適合的場景就不要這麼堅持，除非你可以想出更好的替代方案。
- 多聽多看成員的狀況及遇到的困難，解決他們的困擾，你有義務做這件事，只有你最清楚它到底好在哪。
以上幾句不只適用於 FP 本身，任何你想導入的新想法或工具都適用，要讓技術真正對團隊起到效果，必須讓成員都有共識與認知，一有人落單很容易慢慢走歪，甚至是失敗導致最後還要收拾殘局。
特別推這句：「要讓技術真正對團隊起到效果，必須讓成員都有共識與認知」
Everything Must Be Paid for Twice - raptitude
One financial lesson they should teach in school is that most of the things we buy have to be paid for twice.
有一堂理財課應該在學校教：我們買的大多數東西都得付兩次錢。
There’s the first price, usually paid in dollars, just to gain possession of the desired thing, whatever it is: a book, a budgeting app, a unicycle, a bundle of kale.
第一筆價格，通常以金錢支付，只是為了取得想要的東西，不管是一本書、一個記帳 App、一台單輪車，或是一把羽衣甘藍。
But then, in order to make use of the thing, you must also pay a second price. This is the effort and initiative required to gain its benefits, and it can be much higher than the first price.
但接著，為了真正利用那個東西，你還必須支付第二筆價格。這是為獲得其效益所需的努力與主動性，往往遠高於第一筆價格。
A new novel, for example, might require twenty dollars for its first price—and ten hours of dedicated reading time for its second. Only once the second price is being paid do you see any return on the first one. Paying only the first price is about the same as throwing money in the garbage.
例如，一本新小說的第一筆價格可能是二十美元——而第二筆價格則是十小時的專心閱讀時間。只有當第二筆價格被付出時，你才能看到第一筆錢的回報。只付第一筆錢，無異於把錢丟進垃圾桶。
大多數東西都要支付兩次，第一次是金錢，第二次是努力、時間，或其他更昂貴的成本。只花健身房的月費不會讓你變健康、買好的書也不會自動把知識塞進腦袋。
有些人會覺得：「我那麼菜，哪有什麼可以分享？」。但其實是有的，因為你總是會找到比你更菜的人。你學程式一個月，總是可以找到學程式 15 天的人，我甚至覺得程式入門這種東西，應該由「新手」來教「超級新手」，為什麼？因為那些新手可能一個禮拜前跟你一樣卡在迴圈，不知道迴圈到底可以做什麼，但是這禮拜他就領悟了。我覺得這時候是最適合教學的時機，因為他們還記得「當初卡住的那種心情」，他們是最懂你心情的人。
像我接觸程式這麼久，你問我當初第一次學遞迴的時候是什麼感覺，我真的完全忘了。接觸久了以後，寫程式就像吃飯喝水一樣，你問我怎麼吃飯怎麼喝水，我只能跟你說：「阿不就把嘴張開吃飯嗎？這個要怎麼教？」。
所以儘管你覺得你很菜，你還是可以試著寫下自己學習程式的心得，以及自己卡關的地方跟之後怎麼解開的方法，相信一定會對比你更菜的人有幫助。像我現在寫的很多文章技術深度也很淺，但還是幫助了很多人一樣。
有天我們會無法理解菜鳥朋友們到底都在想些什麼，而能幫助他們的，其實是菜鳥時期的我們。所以即使寫出了很菜的心得、分享、筆記，也許都會在某些時候，幫助到正在經歷同樣時期的朋友吧。
用 Heptabase 思考人生問題與一篇寫了一年還寫不完的文章 - Huli
喜歡這篇把思考過程逐步整理出來的感覺。
尤其在「希望活得快樂」的時候，反過來問「那怎樣會不快樂？」的思路很值得參考。曾經做過類似的嘗試，但做了可能會快樂的事情實在列不完，思路就發散出去了。
或許這也該保持「如果我知道我會死在哪裡，我就永遠不去那個地方。」的心態去規劃吧。
另外，這篇也展現了我覺得 Heptabase 一個很棒的點：可以在白板上思考、整理，讓想法往外生長，並把途徑跟過程保留下來。
讓我想起某段看過的對話：
『哦，所以這張紙就是你思考的紀錄』
「這不是我思考過程的紀錄。它們就是我的思考過程。」
講別的話題，都讓企業人士興趣缺缺，當你提到最新技術或是競爭對手產品，你就可以看到老闆們開始玩手機，也不知道在看些什麼，可能是兩個女人對著貓咪鬼哭神號的梗圖、還是新的限量款跑鞋之類的，但只要提到成長，就立刻讓會議室裡頭瀰漫起一股腎上腺素與睪丸酮的亢奮氣味。老闆們還會自以為謙遜地標榜「我們不自許成功，而是追求成長」 — 好像這個世上真的會有毫無限制、永不停歇的成長，而且相信這一套，就一點都不像神經病。
所以你就發現，這年頭我們沒有品質駭客、沒有價值駭客、沒有幸福或是企業良心的駭客，甚至沒有法遵駭客。我們有什麼？只有成長駭客。我們需要的 Mindset，就是 Growth Mindset。
尾牙時聽高層在台上喊著「成長！」，馬上就想到了這一篇。
當年看還覺得都是段子，想不到我們才是戲班子
漸漸發現幫忙解答問題的最佳途徑是先確認脈絡，尤其是同事們直接拋出某個技術問題的時候。
對於 X-Y Problem 的意思如下：
- 有人想解決問題 X
- 他覺得 Y 可能是解決 X 問題的方法
- 但是他不知道 Y 應該怎麼做
- 於是他去問別人 Y 應該怎麼做？
簡而言之，沒有去問怎麼解決問題 X，而是去問解決方案 Y 應該怎麼去實現和操作。
於是乎：
- 熱心的人們幫助並告訴這個人 Y 應該怎麼搞，但是大家都覺得 Y 這個方案有點怪異。
- 在經過大量地討論和浪費了大量的時間后，熱心的人終於明白了原始的問題 X 是怎麼一回事。
- 於是大家都發現，Y 根本就不是用來解決 X 的合適的方案。
X-Y Problem 最大的嚴重的問題就是：在一個根本錯誤的方向上浪費他人大量的時間和精力！
我覺得如果已經「確知」需要某種抽象層來避免很可能發生的需求變動，預先加入這個抽象層是合理的。
然而，若將這類預想進一步擴大實施，每一次剛開始設計就加入一些預先推想的抽象層，這恐怕有個問題：忘了自己並沒有「預測未來的能力」，因而設計出一堆其實根本不會用到的抽象層，只因為擔心未來某種可能（但不見得會出現）的變動。
每一個抽象層都是有成本的，而疊床架屋所衍生的維護成本通常不低，故強調「只有確知需要的時候才加入」。我認為有豐富開發經驗的人應該會比新手更能判斷加入哪些抽象層是必要的，但如果對任何人宣稱運用 OCP 或 SOLID 就能夠「即使增加了三四五六七個功能，還是不會影響到原有程式。」卻沒有提醒加入無謂的抽象層反而會增加日後的維護成本，也不知道這個領域還有 YAGNI 和 KISS 原則，那麼當程式從 green field 進入 brown field，恐怕會碰到很多麻煩。
「設計出一堆其實根本不會用到的抽象層，只因為擔心未來某種可能（但不見得會出現）的變動。」🥲🥲🥲
