放了四天假回來上班，不到十點就已經想下班了。決定今天分享一些有趣的：
CodeTengu / JokeKappa - Github

這是碼天狗週刊朋朋整理的笑話集，笑話文本在 jokekappa/jokes jokes

建議可以從 others.json 和 pyjokes.json 開始觀賞，內容大概像這樣：

{
    "content": "我想大部分人都知道通常一名工程師會具有的美德；當然了，有三種：懶惰、暴躁、傲慢",
    "reference": "Larry Wall"
},
{
    "content": "寫程式時要保持這種心態：就好像將來要維護你這些程式的人是一位殘暴的精神病患者，而且他知道你住在哪",
    "reference": "Martin Golding"
},
{
    "content": "一個人寫的爛軟體將會給另一個人帶來一份全職工作",
    "reference": "Jessica Gaston"
},
{
    "content": "如果建築工人像工程師寫軟體那樣蓋房子，那第一隻飛來的啄木鳥就能毀掉人類文明",
    "reference": "Gerald Weinberg"
}

決定今天整天就看著笑話度過了，薪水偷起來，嘻嘻。

今天認識到了一個新東東：完形心理學（又稱格式塔心理學），馬上把相關文章丟上來分享給大家：
用「完形心理學」，增加介面設計有感度 - Seal

格式塔心理學（=完形心理學）認為我們看到某些東西的時候是「整體大於個體的總合」的。

像是當我們在做色盲測驗時，紙上面明明印著許多不同顏色的圓圈，但我們卻能將同一個顏色的圓圈視作一個「整體」，進而看出一個數字。

剛剛滑推特的時候，收到這篇 有時覺得寫 layout 就是一個跟格式塔心理對抗的過程 ，裡面聊了一些切版時的盲區，並且提到了「格式塔心理學」這個詞。

順著這個名詞，找到了上面推薦給大家的那篇文章。作者是一位 UI/UX 設計師，為了向老闆和工程師們說明「這邊為什麼要留白，那邊為什麼不能滿版」

他整理出完形心理學中跟 UI 設計比較有關的七個原則：

1. 相似性 (Similarity) — 我們的大腦會把相似的事物看成一體
2. 接近性 (Proximity) — 我們的大腦會把靠近的事物看成一體
3. 連續性 (Continuity) — 我們的大腦會把事物看成連續的形體
4. 封閉性 (Closure) — 我們的大腦在觀察事物的時候，會將許多個獨立的元素視認為一個完整封閉的圖形
5. 圖地原理 (Figure-Ground) — 我們的大腦會把圖案視為圖（前景）與地（後景）的結合
6. 共同命運 (Common Fate) — 我們的大腦會把動態相近的事物看成一體
7. 對稱性 (Symmetry) — 我們的大腦會把對稱的物體，視為一個整體

文章內每一項重點都有附上圖片比較和案例說明，非常好懂。推薦大家閱讀

昨天的分享文有提到公開學習這件事。我個人覺得對工程師來說最有效的公開學習還是寫部落格，因此今天想要分享這篇：

我為什麼鼓勵工程師寫 blog

這篇文章中，91 大大逐一列出了六項好處：

• 產生學習動機，有方向性地篩選資訊
• 檢視自己既有知識，將input的新資訊與既有的知識建立連結
• 透過寫文，刻意強化刺激知識轉化，進行內化知識過程
• 取得回饋，突破盲點
• 受益的總是自己
• 證明自己的能力、特質、發展潛力

文章內針對每一點好處都有仔細地說明，而且相當有道理。不過整個引用的話篇幅有點太長了，我粗略地描述一下：

如果我們的學習沒有方向和目標，就會漫無目的地漂流；而如果我們給自己一個承諾，每個月發一篇文章，那麼我們就會針對這個主題下去研究，也就會開始蒐集相關的資料、有目標地整理這些資訊

而我們為了整理這些資訊，自然就會把他們分類或互相關聯，這時候我們就可以把自己既有的知識和新的資訊關聯起來，也就可以活化舊知識。

同時，也因為我們主動地去整理和吸收，再用我們自己的方式表達出來，過程中融入了我們的經驗和想法，這份資訊才會被內化成我們擁有的知識

前面三項基本就是輸出式學習所帶來的好處。從這邊開始就感覺到公開學習的好處了 （延伸閱讀：《最高學以致用法》讀後心得：活用知識的五種方法 ）

當我們把學習成果公開出去，就有可能取得別人的回饋。這些回饋可以幫我們破除盲點、修正錯誤。

除了受到別人的幫助以外，這些文章也可能幫助下一個踩坑的人，甚至很可能會是之後的自己（其實自己回頭查筆記的次數會是最多的，效果也最好，畢竟跟讀檔差不多）。

累積了一定的成果之後，也能夠證明自己的特質。例如持續學習、充滿毅力、樂於分享等等。怎麼看都不虧。

這篇文裡面有很多段落都讓我一直點頭認同，例如這句：

相信很多有在寫 blog 文章的朋友一定都有過這樣的感受：素材整理了八九成，但開始寫作時，往往會再多個 20 % ~ 60 % 的內容是原本素材沒有的，一邊在寫的過程，其實是迅速的在過程中校準自己的知識點。

在寫文章的時候真的是一直查一直補充，原本很多覺得自己很懂的東西，要組織成語言的時候才會發現東缺西漏，結果為了把洞補完又延伸了許多知識點，最後累得半死，但也有所收穫。

除了這點以外，還有一段心魔的部份：

為什麼許多人會自己整理學習筆記、讀書心得，卻少了這一段外顯知識的過程？大部分的人都是說自己沒那時間、沒那衝動，其實很多是卡在自己心裡那一關：不敢展露出自己學習的結果，怕被別人笑，怕被人酸。

老實說我真的超怕的，畢竟是真的菜。但後來看到 〈鐵人賽——30天可以給自己多大轉變？〉 後有點轉念，尤其是那句：「我本來就是初學者，我為什麼要害怕讓別人知道我不夠強呢XD？」讓我理解更是因為我菜，才更需要這樣做。

最後，之前有幫朋友整理過相關的文章，這邊也貼一份上來。如果有正在猶豫要不要寫部落格的朋友，也許可以閱讀看看

• 寫一年技術文章的心得
• 寫作不是從空白頁開始，而是從寫思考筆記的 5 個習慣開始
• 我是如何完成一篇文章的
• 技術寫作六步驟 讓工程師撰寫流暢的技術部落格

當別人請我給他們一些寫 blog 的建議，我總是回他：挑個你自認為可以的時間行程安排，什麼時候開始寫 blog，預計多久寫一篇文，開始動工，並堅持下去。在你這麼做之前，任何建議對你來說都是不重要的。

你文章是否寫得很糟糕不重要，是否沒有任何人會看你的 blog 不重要，是不是沒啥有趣的東西可以紀錄也不重要。重要的是，只要你能透過寫文來表現出寫作的意願，而且渴望持續地寫作，檢視、思考與改善自己的寫作，你終究會成功的。

最近公事私事的拖延狀況越來越嚴重，昨天直接滑到翻車。今天空閒的時候重溫了之前看過的拖延症相關文章，想一想乾脆分享上來給大家：

致跟我一樣的拖延症患者：動力是需要刻意創造的 - Huli’s blog

文章開頭的例子根本就是我本人。我現在的行動方針就像裡面說的：

動力來自於每隔一段時間就漸漸累積的愧疚感，「怎麼了、我累了、說好的、學習呢？」，累積到一定程度就會對自己說：「我覺得這樣不行」，把這些愧疚感以及不安轉換成學習的動力。但轉換完之後的量，大概燒個一兩週就差不多了。

燒完以後就陷入無窮迴圈：認真做事 => 倦怠耍廢 => 愧疚不安 => 認真做事，一日打魚五日曬網，一直拖一直拖，把所有其他事情都做盡了才會想到要來做正事。

上面的悲劇迴圈好像沒有任何出口。但作者換個方向一想：如果說，我就是拖延症，我本來就做不到呢？

這時候我們的思考邏輯，就會從「為什麼我做不到」的自責迴圈，變成思考「我要怎麼樣才做得到？」

接著，文章裡面舉了幾個例子：

我有個朋友去了某個地方學程式，花了好幾萬塊想讓自己轉職成工程師，但在中間卻跟我說那邊的教學沒有很好，很多地方都聽不懂，要問問題也很困難，我就問了他：那怎麼辦？

他說：「還能怎麼辦，都花幾萬塊了，結業之後一定要找到工作啊，就只能拼命自己學」

假設今天突然有個拿刀的小精靈出現在你目前，跟你說：「安安，如果你三個月後多益考不到 950 分以上，我就砍斷你的手喔！」，接著立刻把你手砍斷三秒後又接回來，證明了這個小精靈是真的有這個能力，而你也用了三秒體驗手被砍斷的感覺。

接著你會怎麼做？

靠杯，當然是一直唸英文啊！雖然還是偶爾會耍廢，但頻率絕對不會像以前那麼高。為什麼？因為唸英文這件事情對你來說變得超級重要，沒唸好就會被砍斷手，誰敢不念？

除了這兩個例子以外，還有金錢（我沒早睡就一人發一百元）、形象（被說：蛤你就是那個開天窗的人哦？）等等

藉由這些例子，我們就可以發現一件事：動力是可以由外力創造的

昨天和朋友聊到面試被考了 DI 和 IOC，心想「該不會現在是貼我的筆記賺廣告費的好機會？！」

結果沒找到機會爽貼一波。為了彌平這股不甘(?)，決定插播先把之前的依賴注入筆記分享上來：
菜雞新訓記 (6): 使用 依賴注入 (Dependency Injection) 來解除強耦合吧

延伸閱讀：菜雞與物件導向 (14): 依賴反轉原則

既然都分享上來了，也就順便複習複習、整理一下當時的思路。我們可以先找到一個藏在標題裡的問題：為什麼我們需要解耦合？

假設現在有間小小公司，老闆請來了小明當工程師，並請他開工撰寫產品程式碼。

當「撰寫產品程式」對「工程師」直接依賴的時候，狀況可能是這樣的：

public Product Work() // 撰寫產品程式
{
    Ming programmer = new Ming();
    var product = programmer.Programming();
    return product;
}

過一陣子，老闆發現小明寫出來的東西似乎不太行，於是把小明趕走，另外請了小華。這時候因為用到的類別不一樣了，我們就必須要改一次程式碼：

public Product Work()
{
    Hua programmer = new Hua(); // 把小明改成小華
    var product = programmer.Programming();
    return product;
}

又過了好一陣子，老闆又另外請了小美來工作。於是又要再改一次，而且小美的工作方式甚至不叫做 Programming，而是 Coding：

public Product Work()
{
    Mei programmer = new Mei(); // 把小華改成小美
    var product = programmer.Coding(); // 呼叫方法也要改
    return product;
}

現在有感覺到一點問題了嗎？如果一直換人，程式碼不就每次都要修改？

昨天分享了用來留時間給自己的「進攻型行事曆」。今天想延續這個話題，分享一下關於時間稀缺度的文章：時間的價值與價格 - gipi的商業思維筆記

在進攻型行事曆的文章中，我們藉由預先把任務排進行事曆裡來幫助我們衡量某個時段，我們是否能夠吃下額外的工作。 同時文章裡面也提到：『像是「拚拚看用半天完成一天的任務」、「做不完就回家或假日再做」的想法，都是在預排進攻型行事曆時一定要避免的想法』

而在這篇《時間的價值與價格中》，我們也可以看到相關聯的觀點（也是我收藏這篇文章的原因）：「時間的價值是浮動的」

忙碌時的一小時跟不忙時的一小時，價值完全不可同日而語，當你已經很忙碌時，還要被插單，那你很可能承接了過量的工作，導致生活品質變差，家庭失和，孩子不認老爸，也可能因為精神不繼，產出品質下降，反而獲得了較差的工作評價，更甚者，因為過量的工作而導致身體健康變差，發生了不可逆的後果。

時間的價值之所以是浮動的，是因為我們剩下的時間有稀缺性：

當我們的行程非常密集、工作繁重，剩下的時間就已經很稀少了，並且我們可能會需要犧牲生活品質或身體健康來交換，這時候如果還要塞進更多的任務，對我們的成本就會是比較高的

而當我們的行程很少，剩下的時間非常充裕，足夠我們兼顧生活品質和身體健康，那麼要塞進新的任務就會是比較簡單的，成本也就相對比較低了

藉由衡量「時間價值」，我們就能夠從市場機制的角度更客觀地評估自己的時間，也能幫助我們的決策（我到底要不要把這個任務吃下來？我吃得了嗎）或談判（你想要月底就上線？真的吃不下了，不然我們踢掉別的任務）

另外，我也想補充一點延伸思考。在文章中提到：

你得學會跟市場溝通，把時間價值換成價格，而這個市場往往是你的老闆、客戶、同事、部屬以及家人、朋友。

當他們希望占用你稀缺的時間時，你是否敢於拒絕呢？或者你會先接收對方的需求，然後試著調整自己的計畫？又或者你承接下來後，不論如何就是加班把兩件事同時搞定呢？

但我認為，不只是我們的客戶和老闆，連我們自己也是我們時間的消費者

今天看到 Notion 新行事曆 提供了 Google 的串接功能

剛好想起之前看過一篇行事曆運用的文章，這邊就順手分享上來給大家：
實作進攻型行事曆：學會留時間給自己的進度排程心法

進攻型行事曆是一種「在行事曆上留時間給自己的技巧」

當我們要排一些計畫，或是被詢問行程的時候，很多時候只能盯著空空蕩蕩的行事曆，模模糊糊知道「下個月好像有什麼專案？」而無法確定。這是因為我們很容易會忽略中長遠的目標，這時候也可以嘗試使用進攻型行事曆把時間先預留起來。

進攻型行事曆要做的事情很簡單：

• 先把長期計畫和重要截止日都標記到行事曆上
• 把手上的計劃列出來，拆解每個計劃要執行的任務。在行事曆上分配時間給這些任務
• 任務如果太長容易失焦，所以太長的任務要拆成一週左右的時間區段
• 有些小任務可能只需要占用半天一天，這時可以用全天行程先把這些小任務指派到某一天

剛剛看到推特上有人分享他們公司傳資料發現要傳三天，果斷開車送硬碟，一天就送達的故事。

決定今天和各位分享「目前資料傳輸速度最快」的網路通訊協議：
RFC 1149 - 以鳥類為載體的網際網路協定（IP over Avian Carriers, IPoAC）

簡單來說，就是讓鴿子送封包。咕。

這組通訊協定歷史已久，最遠可以追溯到古代中國，而在 1990 年由 D. Waitzman 正式提出為 RFC 1149 ，簡稱 IPoAC

後續更追加了 Qos 功能（ RFC 2549 ），並在 2011 年正式支援 IPv6（ RFC6214 ）

雖然「基於鳥類」的協定有著不少的缺點，例如：

• 丟包率嚴重。實驗中 9 個封包中只有 4 個封包成功傳送，丟包率高達 55%
• 回應時間長。從 54 分鐘到 1.77 小時不等
• 會被病毒攻擊，例如禽流感

但同時也可以藉由一些技術處理解決部分問題：

• 丟包率嚴重：可以藉由提高發送的封包數量解決，只要鴿子夠多就不是問題
• 回應時間長：可以讓鴿子攜帶更大量的記憶卡，提升單趟的傳輸量

和朋友聊的時候提到雪花 ID，但我之前都無腦用套件（.Net 的 IdGen，香 ）直接產完甩資料庫完事，因此趁著回家有空的時候趕快認識一下，順手也分享上來： Snowflake 算法

雪花演算法是用來產生唯一 ID 的算法，產出來的 ID 會有以下幾個部份：

• 最前面的 1 bit 不使用，只會放 0 （畢竟放 1 被判定成負數就麻煩了）
• 接續的 41 bit 用來放時間戳，精確到毫秒
  • 這段也是雪花 ID 能夠按照時間排序的原因
• 中間 10 bit 用來放機器序號
• 最後 12 bit 用來放序列號，會持續遞增

這樣就可以得到一組香香的雪花 ID 💯

雪花演算法的優點在於可以排序：因為使用時間戳，所以產生出來的 ID 是有順序性的。

可以排序的優點同時也避免了用 GUID 當 Key 的時候索引破碎之類的問題（延伸閱讀：GUID Primary Key資料庫避雷守則 - 黑暗執行緒 ）

而缺點則是因為依賴時間戳來產生 ID，所以非常依賴機器上的時間。如果機器上的時間回溯了之類就會撞車出事

此外，如果系統是分散式的話，為了避免每台機器在同一時間各自產生的 ID 都一樣，所以要嘛就得集中在一個地方產生，或是分配每個機器唯一的機器序號（放在第三段的 10 bit）

上一篇分享的遊戲與內在動機文章中，提到了「動機與操弄」，這讓我想到之前看《先問為什麼》時寫的筆記，決定分享上來賺點廣告費：

• 讀《先問為什麼》- 伊果的沒人看筆記本
• 賽門西奈克：偉大的領袖如何鼓動行為

作者認為影響人類行為的方法有兩種：操弄以及感召，其中操弄是指使用手段或策略去影響他人，例如說談判、利誘、情緒勒索、削價競爭等等。而感召則是用激勵人心的方式去影響他人、促使別人展開行動。

為了說明領導者是如何感召、鼓舞他人的，作者提出了黃金圈理論，從外到內分別是：

• 做什麼：負責什麼工作、提供什麼商品等等。每個人都能說得出來。
• 怎麼做：流程、方法、技術。知道怎麼把事情做好，比做什麼更加抽象。
• 為什麼：目的、使命、信念。真正的核心，但很少人能清楚說明。

許多公司或銷售，常常是從外圈開始，也就是我做了什麼什麼；然而能夠吸引人們的，必須從內圈開始，也就是「我為什麼要做這件事」

為了表達「為什麼」與「怎麼做」之間的關係，作者提出了芹菜測試：

假設你去參加一個晚宴，忽然有朋友跑來告訴你，「你知道你的組織需要什麼嗎？M&M巧克力。不用M&M，根本就是有錢不去賺。」

這時，另一個朋友又跑過來，說：「你知道自己該做什麼嗎？豆漿。研究顯示，現在每個人都在買豆漿。你應該賣豆漿才對。」

當你站在雞尾酒桌旁邊的時候，另一位朋友又給你一個建議。「Oreo餅乾，」他說。「我們靠Oreo餅乾賺進了好幾百萬美元。你絕對要做Oreo餅乾。」

這時又來了一個人，告訴你：「芹菜！你一定得做芹菜這門生意。」

所有這些有成就的朋友給了你那麼多重要建議。有些人和你身處同一產業，有些人比你成功，有些人也給別人相同的建議，結果讓人受益匪淺。這時，你該怎麼辦？

當你跑去超市把上面提到的東西一股腦都買了，在排隊付錢時，所有人看著你手上的東西，根本不知道你相信什麼。你做的事情應該體現你的目標，但你手上什麼都有。