菜雞寫筆記，踩坑全紀錄
今天頭超暈的，想說來貼個相關的文章(?)
人体系统调优不完全指南 (zijie0/HumanSystemOptimization) - Github
這篇整理了要健健康康活下去(?)的一些相關知識，例如睡眠、飲食、動力、學習。
並且每個小節都有原理說明和實踐方式。例如睡眠這一小節，就會先提到生物鐘、光照和體溫。接著列出該做的內容，像是起床需要先接觸陽光、晚上要減少光源接觸等等
而心態和動力這節，就會提到我們 3/20 轉貼過的多巴胺、會影響的飲食，然後接到利用多巴胺的機制來提升自我等等
文章整體有點長，但分小節看的話其實也蠻快的。對各個術語有興趣的話也可以再進一步搜尋，感覺還是挺不錯的，就轉貼上來給各位朋朋
另外再補一篇相關閱讀（方便我筆記關聯）：
geekan/HowToLiveLonger (程序员延寿指南) - Github
前幾天丟了滿多篇文章到收件閘裡，今天就先從最有興趣的這篇開始讀起：
如何發想解決方案？產品團隊的創意思考流程！ - 3PM LAB 產品三眼怪實驗室
這篇一打開就看到熟悉的雙鑽石（上次看到還是在《柔型要術》的時候）：
- DISCOVER（發散）：透過使用者研究、市場研究來探索問題與機會
- DEFINE（聚焦）：根據前一步驟蒐集到的資訊來定義問題與場景，聚焦至一個待解決的問題
- DEVELOP（發散）：發想各種解決問題的方法、滿足使用者需求的手段
- DELIVER（聚焦）：製作 Prototype 並測試、進行實驗，透過使用者/市場的回饋推進與聚焦至我們最終想要推出的變動或功能
緊接著的這一小段我覺得很不錯，很有敏捷的 feel：
發想解法的步驟並不是單一流程的「想出一個解法」，也不是「想出很多個解法，挑一個最棒的出來」，而是 「想出很多個解法，先挑一個我們認為最棒的出來，用很小的成本讓使用者測試，如果實驗成功就繼續發展；如果實驗失敗就從其他解法再挑下一個出來測試」 這樣一個不斷迭代的過程。
但要實驗各式各樣的想法，首先要先有夠多的解法。這篇文章介紹了幾種「好想法從何而來」的途徑，包括：
實務經驗累積：「累積的經驗愈多，每當遇到一個新問題，你可以延伸出來的子議題、思考方向、點子就愈多」
產品和競品研究：「研究其他軟體產品、競爭對手的產品，學習與參考他們的解決方法，或是從類似用途的元素中找到發想的靈感」
創意發想的工具與框架：「透過一些創意發想的工具與框架，產出大量同時又充滿廣度的點子，能夠逼迫我們探索更多的可能性」
而在工具和框架這部份，這篇文章也分享了一些發想工具。例如心智圖、嘔吐法、丟出爛點子等等
並且文內對每項工具都標上了使用情境和說明，有興趣的朋友可以看看。我個人則特別存了這段：
下班就該下班了其實，但為什麼上班的時候想不出這些東西呢？
之前上《Learning How To Learn》這個線上課程時，裡面提到了專注模式（Focused Mode）和發散模式（Diffuse Mode）這兩種腦袋的運作方式。
專注模式：當我們集中注意力時，會用已知的方法、經驗來解決我們熟悉的問題，一般來說上班、上課都是處在這個模式之下，思想會照著既定的迴路在走。如圖所見，大腦此時會集中在某一部分的神經區塊中工作，此外腦內組織起來的東西（類似釘子）也比較多。
發散模式：當我們注意力較分散的時候，腦內的釘子減少了、也變得不規則，思想可以移動的空間變大、範圍變廣、也較隨機。這個模式適合在面對陌生問題時，幫助我們找到新的觀點，從更廣、更綜觀、更自由的角度去思考，也較有利於創意發想。
我們的大腦同一時間只會處在其中一種模式中，因此學習如何有效的切換到不同模式，將有利於幫助自己用更有創造力的方式解決難題。
就是這樣，我要去開 Steam 發散一下了，明天見～
……今天也弄得挺晚才開工，還好今天有前輩發了一篇有趣的文：
使用 Airtable 在小型需求上取代傳統資料庫 - .NET Walker
主要讓我覺得有趣的是這一句話：
傳統的關聯式資料庫，其實對於教育訓練和小型的專案來說，是一種負擔。
仔細想想也蠻有道理，有時候我只是想示範一下某些工具簡單的操作，但只要想把東西存起來，就有種「好像該丟到資料庫？」的感覺
但就像這篇說的：
如果你做一個小型專案或POC的話，『儲存』也往往不是重點，儲存只是『必要之惡』。
其實，若是從這個角度廣義的來說，軟體開發的GUI、資料庫，都只是細節(枝微末節)，都應該要是可以隨時被抽換或取代的部分，而非系統核心。
一套軟體或解決方案的真正核心，是商業邏輯。它(商業邏輯)才是一個應用程式真正展現價值的部分。
我們把主題拉回來。所以，我最近這幾年在上課的時候，盡量不讓範例程式碼涉及資料庫存取，特別是關聯式資料庫的存取。因為這對讀者或學員來說，變成了另一種必須學習的負擔。
如果只是做一個簡單的 POC，的確不該把重點放在儲存工具上。而在這篇文章裡，作者使用了簡單輕便的雲端工具 Airtable 來處理掉儲存體的部份
Airtable 可以簡單地呼叫 REST API 來處理掉 CRUD 的操作，可以說是無腦開箱即用。
（是不是也該來嘗試看看xD）
這邊文章把數據決策分析拆出四個步驟：
每個階段都有進一步的說明。例如在第一個步驟，我們開始前要問三個問題：
問題與目標 (Question & Goal)：我想知道的問題是什麼? 目標是什麼?
假設 (Hypothesis)：我到底想看什麼樣的數據?是基於什麼觀察與假設？
行動 (Next Steps)：如果數據撈出來了，會怎麼影響我的下一步?分析完的決策可能是什麼?
在第二步驟的指標計算裡，需要在第一步驟的「想看什麼樣的數據」時就進一步設想實際需要的數字。以文章內的電商背景為例，就像：
我想知道最近三個月中，每月成交次數都 ≥ 5 次的用戶 (=消費次數高的高頻用戶)，分別是買了哪些商品類型，不同性別的用戶人數有多少，而平均購買商品數又是多少?
當拿到資料並且確認沒問題之後，進入第三步驟，開始解讀。解讀的發現我看得是有點玄(?)。
這很仰賴產品經理對用戶的理解、以及對產品與市場的敏銳度，其中也包含一部分的行動方針，但不管如何儘管大膽假設，之後再小心求證即可。
但除了這部份以外，整體的解讀方式「嘗試做圖進行分析、找出特徵，然後列出發現，和之前的假設互相比對…」這個流程解釋得很好理解。
如果前面的步驟發現了好東西，就可以來搞第四步驟的資料呈現與視覺化。我覺得重點就在於示範前的這句：
可視化與圖像化就是把「數據」變成「資訊」、成為輕鬆說服他人的有利工具，但不是把圖拉出來就好，而是思考怎麼樣的呈現能讓看的人不帶腦、一眼就看出重點，甚至是默默認同你想強調的論點
以上把這篇文章的流程簡化很多，文章內從一個範例背景開始走完四個步驟，過程中列出很多舉例和說明，讓讀者能夠迅速理解這四個步驟
例如我在這邊文章就認識了決定使用者行為動機的模型「Fogg’s Behavior Model」：
Behavior(行為) ＝ Motivation(動機) * Ability(能力) * Prompt(提示)
感覺相當不錯，已收藏。也推薦有興趣的朋朋閱讀。
……今天閱讀效率有點不大行，決定來推薦一些實際幫助(?)的文章：
開發人員的面試指南 – A developer’s guide to interviewing - louie_lu’s blog
這篇的內容非常直接：如何面試一間公司
你有沒有過，當你在面試的時候，面試官坐在桌子對面，雙眼注視著問你：「你還有其他問題嗎？」，而你回眼回去並說：「umm, 大概沒有了」。如果這曾經發生在你身上，你有很大的機率得到了一個單一面向的面試經驗。
作為一個應試者，可以想見你把目標放在一件事情上：取得工作職缺。但是別忘記，面試並不是一個單向的工作。如同面試官在面試你，你也必須要面試公司。
不過，你需要問他們什麼呢？
首先我們要先搞清楚：我們對話的對象是誰？
根據對象是軟體工程師 or 管理階層 or 公司領導，這篇文章準備不同的問題，並且每個問題都有簡單直接的描述來幫助你了解，有些還有延伸問題或判斷標準
例如對軟體工程師的問題，其中一題是：「你喜歡在這邊工作嗎？」，而根據回答分成了強指標跟弱指標：
強指標：我從我的工作中獲得許多成就。
強指標：我們的工作很有趣。
（略）
弱指標：他付我薪水。
弱指標：這裡沒有太大的壓力來提交成果。
我最驚訝的是這點：
不要以為我在虎爛，我真的在面試時聽過這些答案。
一些奇怪的面試回憶突然湧現
當然，針對開發人員也有像是「你們寫單元測試嗎？」「你們有持續整合嗎？」的這些題目（及延伸題目，例如執行時間）
有幾個問題還是我真沒想過的，例如「你的下一個 deadline 在什麼時候？誰設定這個 deadline？」
或是問管理階層「你手下的工程師如何得知每日該做什麼？」來比對開發人員回答的答案（這算一種分開訊問嗎？）
如果最近有在面試，也許可以參考看看。
……今天剛好跟同事聊到充血模型的概念，決定轉貼小朱大的這篇，順手收進我的筆記庫：
這裡貧血、那裡充血，到底資料模型要怎麼設計？ - 小朱® 的技術隨手寫
首先我們先看一下貧血模型的部份，比較常見的應該就是單純放一下資料用的 DTO（Data Transfer Object）：
貧血模型之所以為貧血，其最大原因是，不論是 DTO 或是 POCO，它的業務邏輯都操控在別人手上，自己沒辦法去維護自己的業務規則，以上面 DTO 或 POCO 作為例子，它們都沒有內建的處理存款與提款的程式碼，都要倚賴外部程式
當業務邏輯只能由別人處理時，相對的就破壞了這個領域知識的內聚力，也提高了向外的耦合性，而且它並沒有辦法自我處理自己的領域知識，在後續系統的擴充與延長時，若與別人共用這個模型時，別人也一樣要實作這類領域知識，從而發生領域知識不一致的可能，導致系統設計的風險。
因此，若系統內的業務邏輯、流程或知識會有共用的可能性時，就應該要考慮以領域模型的方式設計，而不是使用 DTO 或 POCO 的設計作法。
而相對的，充血模型則是：
所謂的充血模型，只是大家在學校學過物件導向程式設計中，具有足夠內聚力的類別而己，但用一個新名詞來講，一個平凡無奇的概念突然瞬間高大上了起來。
一個充血模型，封裝 (Encapsulation) 的特性會十分明顯，它該有的資料就是它自己維護，外部想要對這個模型的資料做異動，就只能使用它所開放的方法 API 執行…這不就教科書上說的嗎？
在最後一段，小朱大有列出這兩種模型適用的時機。
例如說，應用程式很小、資料單純的時候，就可以考慮貧血模型；而如果某些領域知識會需要重複使用的時候，就可以考慮充血模型等等，有興趣的朋友可以再點進去參考一下。
之前在維護三層式的專案時，各層之間都是用 DTO 來傳遞資料。就像工廠流水線一樣，到了某一段就把資料倒出來處理處理，然後塞到另一個 DTO 傳到下一站。
後來到了現在的公司，才接觸到貧血充血這些名詞。但想想物件會動(?)好像也是理所當然的…吧？
……之前為了從根本解決宵夜跟熬夜問題，買了《多巴胺國度》，但一直沒翻開看（應該說，買了一堆書都沒看）。
今天看到瓦基貼了讀書心得，就決定就轉貼這篇了：
《多巴胺國度》讀後心得：如何在上癮的爽痛之間取得平衡？ - 閱讀前哨站
既然書名都已經叫做多巴胺國度了，當然要從認識多巴胺開始：
多巴胺是一種神經傳導物質，最重要的功能是讓大腦產生「獎勵機制」。
像是我們滑手機看到別人按讚、玩遊戲提升了等級、喝酒感覺到飄飄然、進行性愛的時候體驗到的高潮，大腦都會分泌多巴胺獎賞我們
但這個獎勵是會漸漸麻痺的，例如我們看搞笑影片，就會分泌多巴胺，然後我們就會感到快樂。
但隨著越滑越爽，要感到快樂需要的門檻也越來越高、也就需要更多的刺激才能感到快樂
而當我們隨著門檻變高，遲遲沒辦法得到快樂的時候，會發生什麼呢？
當他沒有辦法獲得這種刺激的時候，蹺蹺板另外一邊的痛苦會開始增加，他反而會感到更大的空虛和焦慮。
換句話說，一開始用來獲得快樂的行為，最終反而會增加我們的痛苦，因為大腦中的「爽痛平衡」被破壞了。
就像對毒品上癮的人，你突然不給他毒品吃，他會感受到前所未有的痛苦，用盡方法想要再度吃到毒品。
因此，即使是又香又好吃的雞排一樣，也只能有節制的吃，否則就會越來越依賴，需要更多的雞排才能撫慰下班的心。只有節制，才有平衡。
但反過來說：如果我們先痛呢？
有些人喜歡吃辣，在吃辣之後感覺心情很好。其實我們的味蕾對於辣的反應是一種「疼痛」的感覺，感受到辣的疼痛之後，大腦為了達到爽痛平衡，所以給我們一種愉悅的感覺，這就是吃辣為什麼會人感覺到開心的原因。
另外，像是有些人在運動之後體會到「跑者的高潮」，或者看完恐怖片之後感覺到莫名的愉悅，都是基於一樣的道理。
「爽就是我們付出痛苦之後兌換到的獎勵。」
為了平衡，所以我們來一點小小的苦痛，反而可以得到一種爽感。這也解答了我長久以來的一些疑問，例如「上班上到賭爛之後去騎腳踏車反而心情會變好」之類的。
最後，我想要特別截出瓦基的這段心得，也算是勉勵我和同樣練習寫作的朋友們：
每次我要整理讀書筆記的時候，我也會覺得有點辛苦。不要覺得我好像寫起來很輕鬆，其實做筆記是很花力氣的事情。特別是有些書真的不容易寫成心得分享，可是我又覺得自己必須接受這個挑戰，所以就算絞盡腦汁我也要把它寫出來。
有趣的是，當我熬過這種痛苦的時候，我就會覺得自己好棒棒，那種成就感可以維持很久很久。還有，未來再度看到這篇心得文章的時候，我會讚嘆自己竟然連這麼難的書也可以分享給大家。這就等於是一次的痛苦，可以帶來很多次的愉悅。
延伸閱讀（警告，有肌肉恐懼症勿入）：
……一開臉書就被推送了德魯大大的文章，當然是馬上看：
架構面試題 #5: Re-Order Messages - 安德魯的部落格
如果我透過 API 短時間收到大量的 Request, 我如何保證訊息必須按照順序處理?
這篇文章裡德魯大大示範處理訊息順序問題，從基本觀念開始、抓出要處理的問題，動手搭建環境模擬，然後實作出 IReOrderBuffer 以及最後的監控及總結
內容非常的長，推薦可以慢慢閱讀並消化思路。這邊按照慣例截一些我要收進筆記本的點。
首先在「訊息排序的基本觀念」這段，其實就已經說明了這篇文章的核心：
如果收到的訊息是對的，就馬上處理；如果不對，那就放在手上 (時間越短越好)，看是要等缺的訊息補上，或是放棄某個訊息繼續往下。
其中你要抉擇的是，到底是要等待的時間越短越好? 還是放棄的訊息數量越少越好? 兩者通常必須取捨 ..
接著德魯大大列了幾個需要注意的問題：
在一連串的環境模擬之後，開始實作時又會提到這個決策點：
掉訊息困難的地方在於: 在當下你不會知道這訊息是已經掉了，還是只是晚一點才會拿到。已經掉了的話你越早放棄他 (SKIP) 越好，反正你等再久也等不到，早點放棄可以用更低的 Buffer，也能讓後面的訊息更早發出去；
晚一點到的話你等他越久越好，你的訊息完整性會更好 (都不用放棄任何一個訊息)，但是你需要更大的 Buffer, 暫存更多 Command 在 Buffer 內，也會讓更多 Command 的延遲提高，有可能違背你對整個系統的 SLO 期待。
「對整個系統的 SLO 期待」 對我來說算是比較新的概念。
之前的目光都只放在「讓系統不要爆炸= =」，倒是沒有正面地想「對系統的 SLO 有所要求」這個方向。但其實就像文末提的：
這類服務應該以 SLO 為主要目標，實做或是演算法都應該是支撐目標才對，而非目標來遷就設計
另一個我覺得「哇啊」的部分是整個文章架構：先說明核心概念、把解題的框架建立起來，設計好介面、做出第一個測試案例，接著搭建用來模擬的環境，然後抓好處理範圍、動手實作，再進行測試來觀察不同狀況的表現。感覺就像是一步一步地跟著走開發過程，意外地舒服(?)
尤其是模擬並且測試的部份，我覺得總結的這一小段就能表達其意義：
這個例子，最終是要上戰場的服務啊。你無法控制網路品質，你也無法用 “計算” 的方式預估你要多大的 Buffer Size, 因此如果你沒有用模型來模擬，你也無從 “猜測” 你的做法是否能真的上線解決問題。
架構師難為的地方就在於，只有困難 (大家搞不定，也想不通怎麼解決) 的問題才會來找你。在這前提之下你從有了想法，到真的能上線驗證，通常需要花很長的時間才走得到這一步。因此，想盡一切辦法，讓問題還在很早期的階段就能被驗證，對架構師這角色而言是非常重要的。如果你提出一個錯誤的方式，其他人要等半年後才能告訴你行不通，那架構師的存在意義就不見了不是嗎?
最後引用文章開頭的這句給自己，共勉之：
……別再糾結 “是否有必要重新發明輪子” 的問題了，你不需要重新發明每個輪子，但是要不要讓自己有能力重新建立 “必要” 的輪子，就是你的選擇了。
為什麼打開檔案時會看到亂碼？跟著小明一起從傳紙條學習編碼 - Huli
這篇從班上的小明傳紙條開始，一步一步認識「編碼」到底在幹嘛，我們又為什麼會遇到亂碼，最後又是怎麼整合不同的編碼格式的
因為傳紙條的場景大家都經歷過（應該有吧?），超級好懂，推薦閱讀
收件閘的存貨快沒了，難道終究要靠之前那一車技術部落格嗎 QQ
……剛剛看到一篇單元測試相關的筆記，對裡面提到的內容連連稱是，馬上轉貼上來給大家：
《Python 工匠》筆記（二）對「單元測試」的看法與建議 - Code and Me
大家都說單元測試好，但到處都看不到。我們很常聽到一些不寫測試的理由：東西很簡單不用寫啦、東西太複雜寫不了啦、沒時間啦…
（沒時間的可以左轉 你就是都不寫測試才會沒時間 ）
而這篇的筆記整理了《Python 工匠》裡關於單元測試的五個重要理解
寫單元測試不是浪費時間：寫單元測試可以省下的時間主要在把東西改壞 Dedug 的時間，還可以給我們重構的勇氣
不要總想著「補」測試：補測試其實代表我們覺得測試是額外的、事後的，但其實我們完全可以邊開發邊寫測試，還可以幫助我們改進設計
難測試的程式就是爛程式：當我們覺得很難測試的時候，應該要重構程式碼，而不是降低測試的門檻
像應用程式一樣對待測試程式：不要把測試的程式碼當成附屬品，因為測試寫太爛也是一種負債
避免教條主義：很多觀點都有狂熱追隨者，例如「只有 TDD 才是真的在寫測試！」。去了解，但不要盲從
每一項在這篇筆記中都有直接好懂的說明，但我個人最喜歡的是「5. 避免教條主義」這項。讓我節錄這篇文章的其中一段：
說起來很奇怪，在單元測試領域有非常多的理論與說法。人們總是樂於發表種對單元測試的見解，在文章、演講以及與同事的交談中，你常常能聽到這些話：
- 「只有 TDD 才是寫單元測試的正確方式，其他都不行！」
- 「TDD 已死，測試萬歲！」
- 「單元測試應該純粹，任何相依都應該被 mock 掉！」
- 「mock 是一種垃圾技術，mock 越多，表示程式越爛！」
- 「只有專案測試覆蓋率達到 100%，才算是合格！」 ……
看到書中的這段，我真的會笑死XDDD —— 因為這個「怪現象」竟是如此的真實。
哪怕還沒有開始寫測試之前，我就已經看過不少這類言論。說真的，這些言論——或者說「信仰」——恐怕或多或少增加了想要入門測試的人，在心理上的門檻。
好像你不把測試做到 100 分、盡善盡美，就乾脆不要寫測試了——我覺得這不是一種健康的姿態。
……針對這現象，作者認為：
這些觀點各自都有許多狂熱的追隨者，但我有個建議：你應該了解這些理論，越多越好，但是千萬不要陷入教條主義。
因為在現實世界裡，每個人參與的專案千差萬別，別人的理論不一定適用於你，如果盲目遵從，反而會給自己增加麻煩。
