或許我就是必須要跟著大家多繞點彎路，陪著大家一起犯錯，並適時的提供自己的經驗。
想到這裡突然就很感謝這些年陪著我練功的前輩們，當時看著我繞彎路時他們心情是甚麼呢？有沒有過我現在這種掙扎？
原來只是換我接棒了而已，這是我現在的答案，曾經聽過前輩們心中有種「憑一口氣，點一盞燈。」的氣魄想要改變整個大環境，我沒有那麼大的夢想，但受人恩惠的我也會試著把從大家身上學來的東西傳承下去的。
看朋友的工作心得，很喜歡這種心路轉折的整理。現在遇到一些神奇(?)的同事，也會陷入同樣的掙扎，但從『把前輩交給我們的東西傳承下去』的角度來看，也許都只是一種過程吧。
最近跟新朋友一起開發，想起了當初看到的這段：
我覺得所有的程式都可以看成一個巨大的金字塔，頂端是這個程式的最終目標，一個模糊的概念；底部是細節的程式碼。而中間是一個經由不斷切割與抽象化所構成的高塔，每一個程式都是切割為許多的元件、模組，再切為更細的 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 最大的嚴重的問題就是：在一個根本錯誤的方向上浪費他人大量的時間和精力！
More people should write - James Somers：
That’s the promise: you will live more curiously if you write. You will become a scientist, if not of the natural world than of whatever world you care about. More of that world will pop alive. You will see more when you look at it.
這就是承諾：如果你寫作，你會活得更有好奇心。你會成為一名科學家；即使不是自然世界的科學家，也會成為你所關心的那個世界的科學家。那個世界會有更多部分忽然鮮活起來。當你注視它時，你會看見更多。
喜歡這篇的角度：寫作讓我們更加好奇 也許跟上面提到的「寫技術文章的時候時常會發現不足的地方、邊寫邊查」有點相似吧。
拖稿一個月的我：我本來是要寫什麼來著？
学了、听了，就知道和懂了？那是骗自己，因为：
1）一小时后，已忘了56%。
2）到第二天，已忘了74%。
3）一个月后，只记得21%。
只记得56%或21%，在没有人提醒、提起的时候，你是回忆不出来的。 …
Spaced Repetition for Better Learning - Cheng-Wei Hu：
Spaced repetition is a learning technique that optimizes reviewing previously learned material by scheduling reviews at increasing intervals over time. This method is based on the psychological principle of the forgetting curve, which states that we forget information exponentially unless we reinforce it.
間隔重複是一種學習技巧，透過隨著時間推移，依照逐漸拉長的間隔來安排複習，從而優化對先前學過內容的回顧。這種方法建立在遺忘曲線的心理學原理之上，該原理指出，除非我們加以強化，否則資訊會以指數方式遺忘。
By strategically timing reviews just before forgetting occurs, spaced repetition enhances long-term retention. Each time a learner successfully recalls information, the intervals between subsequent reviews can be extended, allowing for more efficient study sessions.
透過策略性地在遺忘發生前安排複習，間隔重複能夠提升長期記憶保留。每當學習者成功回想起資訊後，後續複習之間的間隔就可以拉長，讓學習過程更加有效率。
Research has shown that using spaced repetition techniques can significantly improve memory retention, with participants demonstrating between 10% and 50% better recall compared to those using massed practice methods. See more research supporting Spaced Repetition in the appendix.
研究顯示，使用間隔重複技巧能顯著提升記憶保留率，與密集練習方法相比，參與者的回憶表現可提升 10% 到 50%。更多支持間隔重複的研究請參見附錄。
我覺得如果已經「確知」需要某種抽象層來避免很可能發生的需求變動，預先加入這個抽象層是合理的。
然而，若將這類預想進一步擴大實施，每一次剛開始設計就加入一些預先推想的抽象層，這恐怕有個問題：忘了自己並沒有「預測未來的能力」，因而設計出一堆其實根本不會用到的抽象層，只因為擔心未來某種可能（但不見得會出現）的變動。
每一個抽象層都是有成本的，而疊床架屋所衍生的維護成本通常不低，故強調「只有確知需要的時候才加入」。我認為有豐富開發經驗的人應該會比新手更能判斷加入哪些抽象層是必要的，但如果對任何人宣稱運用 OCP 或 SOLID 就能夠「即使增加了三四五六七個功能，還是不會影響到原有程式。」卻沒有提醒加入無謂的抽象層反而會增加日後的維護成本，也不知道這個領域還有 YAGNI 和 KISS 原則，那麼當程式從 green field 進入 brown field，恐怕會碰到很多麻煩。
「設計出一堆其實根本不會用到的抽象層，只因為擔心未來某種可能（但不見得會出現）的變動。」🥲🥲🥲
拖稿一個月的我：我本來是要寫什麼來著？
学了、听了，就知道和懂了？那是骗自己，因为：
— 陈思远Yosef (@YosefBlockchain) July 11, 2024
1）一小时后，已忘了56%。
2）到第二天，已忘了74%。
3）一个月后，只记得21%。
只记得56%或21%，在没有人提醒、提起的时候，你是回忆不出来的。 pic.twitter.com/L41Eg1vCTr
A typical graph of the forgetting curve purports to show that humans tend to halve their memory of newly learned knowledge in a matter of days or weeks unless they consciously review the learned material.
遺忘曲線的典型圖表聲稱，除非人們有意識地複習所學內容，否則人類對新學知識的記憶往往會在數天或數週內減半。
我們的妙妙 DateTime.ToString()
Alpine 3.18 的時候是 2024-02-29 12:47:57
升到 Alpine 3.19 變成 2024-02-29 12 Minute Minute: 50
謝謝 aspnet:6.0-alpine，搭配微軟把拔好棒的 CultureInfo，禮拜一都不無聊了呢
需要更多資訊的朋友，可以參考 TimeSeparator 以及 Custom format 的頁面說明：
以及這則相關 issue：
DateTime format issue with Alpine 3.19 #5234
按照 issue 內的操作，就可以重現 Alpine 3.18 和 3.19 的行為差異，並且可以印出 CurrentCulture 並看見 TimeSeparator 變成空值（而非文檔中的 “:"）
如果有朋友遇到同樣問題並來到這裡，上面 issue 的一段話節錄給你參考：
I noticed that you are missing the package icu-data-full in your repro Dockerfile. We have this package documented in our Alpine ICU sample Dockerfile. I’m not sure why the behavior changed between alpine versions. If you add icu-data-full to your final image layer you should get the correct behavior.
我注意到你在重現用的 Dockerfile 裡少了 icu-data-full 套件。我們在 Alpine ICU 的範例 Dockerfile 中有記錄這個套件。我不確定為什麼在不同的 alpine 版本之間行為會改變。若你把 icu-data-full 加到 final image layer，應該就會得到正確的行為。
尤其這句 I'm not sure why the behavior changed between alpine versions.
……真是道盡了我抓蟲的心情。
とある尊敬するデザイナーさんが言っていた
— りゅー (@ryuki_kyoto) April 2, 2024
「デザインに行き詰まる時は、情報が足りないか、前提が間違ってるかのどちらか」に、定期的に助けられる
「當設計陷入困境時，要不就是缺乏資訊，要不就是前提有誤」
感覺軟體設計也適用。
我：天哪真不知道這些前輩去哪找這麼多優質技術文章
同樣也是我：這怎麼讀得完= =
checkcheckzz / system-design-interview - Github
上面就是我看到這 Repo 的感想。現在我們有更多讀不完的技術部落格了
以前總覺得 Windows 到底怎麼搞的，字體邊邊都有鋸齒，真傷眼。
現在換新電腦之後才發現，好像只是我之前螢幕解析度太低而已……
但我還是安裝了 MacType，讚
趁著黑五特價組了台小紅點，當作給自己的生日禮物。接下來的日子還要請新夥伴多多指教了
