今天單純分享一下。在持續轉貼文章之後，我得到了幾個不錯的東東：

首先是寫作力的復甦（？），畢竟部落格已經斷更好一陣子，要寫點東西都有點抗拒，也懶懶的。

但藉著簡單的轉貼文章、以及「只需要加上一點整理和心得」的小小門檻，漸漸地好像對花時間寫點東西不再那麼抗拒，並且開始習慣每天花 15~60 分鐘在閱讀文章和整理筆記，感覺很不錯，就像是一種寫作復健。

除了培養習慣以外，也能夠把自己喜歡的文章分享出來、給更多人認識，這也是一件很棒的事情。
壓線摸魚的部份不算的話

而在轉貼的過程中，也被推薦了更多文章，有時也會挖到寶藏。如果有觀念落後的地方，也能得到前輩們的補充。也許這就是公開學習的好處吧！（雖然也有因為菜而看不懂的時候就是了 xD）

講完收穫之後，來聊聊最近的想法。

隨著存到筆記庫的文章多了起來，有些時候卡片就會散散的。看著這堆散散的筆記，就開始有了些想法

像是想把時間投入在相近的主題，集中火力把這些卡片之間的網路建起來；或是消滅那些放了很久卻沒看的書，乾脆用書本當主軸來展開每天的筆記等等。

最重要的是：想用同樣的方式再一小步一小步走，就像是轉貼一些文章這樣的小事就很好。

如此如此這般這般，總之就決定就把每天轉貼的這串緩下來了。接著打算每天整理一小篇筆記，先把相關主題或是同一本書籍的卡片吃完，剩下的就再看看吧。

如果是欣梅爾的話，也一定會這樣做的。

最後想貼幾則之前轉貼過（或沒轉貼過？）的文章，給有興趣的朋友閱讀，同時也讓我自己複習：

鐵人賽——30天可以給自己多大轉變？

我本來就是初學者，我為什麼要害怕讓別人知道我不夠強呢XD？

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

他說：「還能怎麼辦，都花幾萬塊了，結業之後一定要找到工作啊，就只能拼命自己學」
那時我才意識到動力是可以被創造出來的，可以被另外一件重要的事情創造出來。所以你要找到對你來說真的重要的事。

面對拖延糾結、恐懼沒時間，我幫助自己進入心流靠一個關鍵步驟

用「設計適合自己的挑戰」，取代「能力焦慮」

明知要改變，卻怎麼也踏不出第一步？你需要的是「心理戰術」！

在接下來的每一步告訴自己：我還沒有真的要下定決心，
或者說，我也可以不急著決定，我只是把眼前的小步驟做好，而且隨時可以退出。

當我覺得自己做的很爛時，我會做些什麼？

如果你還沒有達到某個特定的點，你並不需要因此對自己太過苛責。
你無法讓時間流速變快，也沒辦法改變你每天需要完成的重複次數。
你唯一能控制的只有：下一次重複。

《原子習慣》細微改變帶來巨大成就的實證法則｜心得筆記

這個過程只有簡單的兩步驟：

1. 決定你想要成為什麼樣的人
   
2. 透過生活中的小勝利來向自己證明

那麼，今天的小心得就到這裡，希望大家也能體會到轉貼文章對我們菜雞的好。可能下篇轉貼再見 ><"

「人很容易高估一個決定性瞬間的重要性，也很容易低估每天都做些小改善的價值」

最近在想一些關於習慣培養的事情，正好整理到這篇關於《原子習慣》的筆記。
寫得很不錯，推薦大家過去看看：
《原子習慣》細微改變帶來巨大成就的實證法則｜心得筆記 - 德瑞克 Derek

那麼按照慣例，節錄文章的一些片段參雜個人心得來丟筆記庫。

首先要認識這本書，就要先從「習慣帶來的複利」開始：

如果每天都能進步 1％，持續一年，最後你會進步 37 倍；
相反地，若是每天退步 1％，持續一年，到頭來你會弱化到趨近於零。

習慣就是「自我改善」這件事的複利。
如同錢財透過複利加倍，習慣的效果也在你重複執行的過程中加倍。

隨便挑一天來看，習慣的效應似乎很小，
但幾個月、甚至幾年下來，它們就可能造成極巨大的影響。

我們每天的進步和退步，都會延續到下一天。這樣長久下來，就像是複利一樣。

不管是生產力、知識、壓力或是負面想法，這些東西都會形成迴圈、不斷累積下去。
因此，累積好的習慣是很重要的。

但是，要建立持久的習慣是很難的。其中一個困難點就是「失望之谷」：

在你跨越一個關鍵門檻、解鎖新等級的表現之前，習慣往往看起來沒什麼影響。

在任何追尋的前期或中期，常常出現所謂的「失望之谷」 — — 你期待有線性的進展，但在前幾天、幾週，甚至幾個月，效果都很不顯著，令人感到挫敗。

建立持久習慣之所以如此困難，這便是核心因素之一。
我們做了一點小小的改變，沒能看見有形的成果，就決定要放棄。

你心想：「我每天都跑步，跑了一個月，怎麼身材沒有任何變化？」
一旦萌生這樣的念頭，好習慣就很容易被拋諸腦後。

然而，想要造成有意義的差異，你必須維持一個習慣夠久，以突破這個停滯期，稱之為「潛伏之力的停滯期」。

而要突破它，我們必須忽視目標、專注於系統上。其中最關鍵的做法，就是「改變身份認同」：

許多人在展開改變習慣的過程時，都把重點放在想要達成什麼。
這會將我們引至以結果為基礎的習慣。

替代做法是建立以身份認同為基礎的習慣
在這種方式下，我們一開始就把重點放在希望成為什麼樣的人。

• 目標不是讀一本書，而是成為讀書的人
• 目標不是跑一趟馬拉松，而是成為跑步的人
• 目標不是學會一種樂器，而是成為演奏音樂的人

做正確的事很容易，畢竟當你的行為與身份認同完全一致，你便不再追求行為的改變。
你只是相信自己是某種人，然後去做那種人會做的事而已。

決定你想要成為什麼樣的人，透過生活中的小勝利來向自己證明

我很喜歡其中一個例子；「我在戒菸」或是「我不抽菸」，
兩者產生的力量其實並不一樣，因為他們對自己的看法截然不同。

當我們有了新的身份認同，接著就是認識培養習慣的步驟和方法。

要形成一個習慣，會經過四個步驟：「提示、渴望、回應、獎賞」

• 法則一（提示）：讓提示顯而易見
• 法則二（渴望）：讓習慣有吸引力
• 法則三（回應）：讓行動輕而易舉
• 法則四（獎賞）：讓獎賞令人滿足

當然，它們也可以用來戒除壞習慣：

• 法則一的反轉（提示）：讓提示隱而不現
• 法則二的反轉（渴望）：讓習慣毫無吸引力
• 法則三的反轉（回應）：讓行動困難無比
• 法則四的反轉（獎賞）：讓獎賞令人不滿

關於這一段，書裡面用了四個章節來逐一說明，還搭配各種小技巧。
因為真的太長了，有興趣的朋友可以直接抓書來看。

（備註：在習慣戒除的這段，除了原子習慣以外，我個人也很推薦《多巴胺國度》）

但同樣的習慣，我們執行的動力還是會慢慢變少。要怎麼讓習慣持續吸引我們呢？
書上提了「金髮女孩原則」：

當執行的任務恰好位在當下能力的邊緣，人便會感受到最高程度的動力。
不要太難，也不要太簡單，恰到好處就對了。

總覺得這邊有種「舒適圈」和「成長圈」的感覺。畢竟，太舒適就會無聊了嘛：

成功最大的威脅不是失敗，而是無聊。我們之所以對習慣感到倦怠、無聊，是因為它們不再帶來愉悅感，結果變得可以預期。

而當習慣變得平凡無奇，我們就會為了尋找新鮮感，而讓進步脫離正軌。

現在我們已經認識了習慣的力量。然後呢？我們要怎麼藉由習慣來變強、變得精通呢？

想要讓潛能最大化，追求菁英級的表現，就需要更細膩的做法。
你不能盲目重複做一樣的事，卻期待自己變得突出。

追求精通，習慣是必要的，但只有習慣並不夠，你需要的是自動化習慣與刻意練習的組合。

精通是一個過程，你在此過程中將焦點鎖定在成功的一個微小元素，
不斷重複該技能，直到將其內化

然後以這個新習慣為基礎，往個人發展的下一個疆界前進。第二次執行時，就任務變得比較容易，但整體難度並沒有下降，因為現在你要把能量投入下一個挑戰中。

每個習慣都為更高層次的表現解鎖，這是個無止境的循環。

……總覺得看這段的時候有種看見那群極速開發恐怖份子的 feel 🤔

利用有目標、有回饋的刻意練習，搭配培養習慣帶來的複利。
這樣一個習慣一個習慣的踏下去，我們的飛輪就轉起來了

沒錯！這時候就是複習我們第二天轉貼過的「學習永動機」的時候了 XD

最後想貼一下這篇文章裡我很愛的一段：

最有自制力的，通常是最少用到自制力的人。
當你不需要常常動用自制力，就比較容易克制自我。

你或許可以抵抗誘惑一次或兩次，但不大可能每次都讓抑制裡凌駕於欲望。與其讓每次想要做正確的事情時都鼓起意志力，倒不如把能量用來優化所處的環境，避免無謂的外界干擾。

這就是自制力的秘密：讓好習慣的提示顯而易見，讓壞習慣的提示隱而不現。

共勉之。

最近在動手整理之前的筆記，也找了一些相關的文章。今天要轉貼的是讓我有點反思的這篇：
為什麼你「不需要」所謂的人生管理系統 - Code and Me

人生管理系統是指那些「全方位自我管理」、「可以改變你的人生」、「提高生產力的方法論」的厲害東西。通常還會有兩個特徵：複雜、流程化。

而這篇文章開場就說清楚了主要論點：

打造大而全的「人生管理系統」，期望它全面提升你的生產力，可能不是一個好主意。

我相信對大部分人而言，真正有效的提升並不在於建立一個龐大而複雜的系統。反而一些簡單的做法，往往更有效。

沿著主要論點，作者提出了三個理由，以下依序用我的理解來筆記一下。

• 成本過高：要維持這麼大的系統，要花費更多的心力和時間，例如大量的紀錄和手動操作，但這些投入並不會有相應的回報
• 適得其反：為了跑完複雜、龐大的流程，反而需要做更多不重要的瑣事，變相減少整體產出的價值
• 追求完整：複雜的系統容易激發我們追求完整的本能，尤其是要改變人生的系統，會讓我們想要講究每個細節、填滿每個空白

而這些問題組合起來，就變成：

在大系統中，我們可能花很多時間思考系統本身的設計、優化管理方法，而忽略了真正對我們重要的事情，也就是系統「本來」想達到的目的。

追求完整的本能，再結合複雜的系統設計，最終可能導致我們的生產力「下降」，而非提升。

這篇的三個理由各自都有一小段進行說明。其中我覺得這句最有打到我：

大部分時候，產出價值的關鍵在於「把事情做好」，而不是「做好多事情」

因為我個人就是那種喜歡筆記庫放一堆東西看了就開心的類型。文章中一小段也直接命中：

簡言之，基於一種「完整記錄」的偏好，你可能會增加一些實際上沒多少用處，但會「讓人感覺很好、很完整」的欄位。

這些欄位在 Notion 閱讀管理資料庫中經常出現，但它們更多是為了追求「完整性」，而非實際的閱讀效益而設計，比如：

1. 書籍封面圖片

第一項我就中了。我的 Notion 裡放書籍資訊的地方，每一則都放了美美的封面圖= =

那麼，像我們這些喜歡存筆記，但又容易被龐大複雜的筆記架構卷進去絞死的朋友們可以怎麼做呢？

作者提了一種更可行的思路：「局部實現」

局部實現，是一種心法或價值觀，說穿了沒什麼，就是「緊扣著需求尋找並選定方法，需要多少才投入多少」。

（這邊讓我有種「如無必要，勿增實體」或是 YAGNI 原則的 feel）

而對於局部實現，作者也提了兩個點，其中適可而止這項我個人還蠻認同的：

一、方法改進宜適可而止

如果當前方法已能做出 80 分成果，一定程度滿足需求了，就不要再繼續追尋「更有效方法」——宜適可而止。

必須強調，這裡不是指結果一律只追求 80 分就好。

而是，如果結果已經有 80 分，但你想要進一步提升，建議不要試圖從「手段、方法」上去改進。更不需要去建立一個複雜的系統。

無論什麼系統，對於已有 80 分的產出結果，很可能已不構成影響。再從方法上改進，企圖更進一步提升產出品質，往往只是緣木求魚。

二、分別而非整體：謹慎關聯

「系統」二字最讓我害怕的，就是它隱約暗示著系統的各個元件之間，存在著巧妙的「關聯」，所以它們能共同組合成一個「工作流」。

我的建議是：謹慎關聯。

可以的話，不要關聯，因為所有關聯都是有「代價」的。

而關聯的這一項，作者又說：

追求完整往往帶來不必要的複雜，而「關聯」正是複雜小惡魔們誕生的溫床

這，我的筆記之間「耦合」了，難以維護了是吧。好像真的蠻像的。

看完這篇有點反思：會不會很多時候，真的就只是沉迷在一些複雜又龐大的方法裡，而忽略了本來的目的；太執著在一些多餘的操作，而放棄了內容的品質？

會不會就像一些被濫用的、太過度設計的架構，讓太多的工用在無聊的細微末節，反而讓我們交付價值的速度被拖累？

但這些我可能還要消化一下。這邊就引用作者的一小段思考來結束吧：

我認為，保持方法的殘缺與遺憾，是一種「高明的妥協」。

小方法比大系統更容易掌握，更可能讓我們專注於「畫作」本身。

接受殘缺並不意味著放棄進步，而是在進步的過程中，試著學會區分：哪些只是手段，而哪些才是本質。

那麼，今天的轉貼就到這邊。我們明天見。

延伸閱讀：《人生 4 千個禮拜》筆記（一）病態的生產力 #效率陷阱

前兩天貼了編碼、加密、雜湊的文章，今天接著貼它的續集：

聽說不能用明文存密碼，那到底該怎麼存？ - Starbugs Weekly 星巴哥技術專欄

這篇列了幾個方案，從編碼到雜湊，搭配圖文解釋，非常適合貼給同事然後叫他們密碼不要亂存。

真的，只要你同事一說「那我們就用 bas…」就直接把這篇甩在他臉上。

備註：剛剛收到另一篇，感覺也可以拿來甩：密碼存明碼，怎麼不直接去裸奔算了？淺談 Hash , 用雜湊保護密碼

此外黑大也有寫過相關的科普，有興趣的朋友可以參考參考：密碼要怎麼儲存才安全？該加多少鹽？-科普角度

按慣例，這邊也迅速節錄一下、收進筆記庫。

方案一：Base64 編碼

先回顧上一篇的這句：

所謂的編碼並不會修改資料、也沒有任何加密的效果，單純就是換個方式來表達資料而已

沒有加密效果！沒有加密效果！沒有加密效果！而且 base64 的 == 真的太好認了= =

經過 Base64 後的結果很常都是 = 或 == 結尾，所以如果有一天資料庫真的洩漏出去了，駭客也會在第一時間就發現可以用 Base64 解開，然後在很短的時間內得到原本的密碼

那如果不要用 base64，用一些比較冷門的編碼呢？

也不行，雖然這些編碼演算法比較少人在用，但頂多騙騙不懂電腦的路人甲乙。真正的駭客很可能會使用各種方法嘗試要 decode 密碼，所以不管用哪一種編碼都是不安全的，結論就是不要使用編碼來儲存密碼！

方案二：AES256 加密

那用加密呢？加密就會牽涉到保管 key 的問題：

因爲使用者要登入時，後端必須確認使用者輸入的密碼加密後跟資料庫內的 password 是否符合，所以還是必須把 key 放在 server 上。既然是放在 server 上，那駭客就還是有機會拿到

因為公司內的員工可能會知道 key，所以就可以從資料庫得到使用者的密碼。如果你知道 Facebook 的工程師只要想要就能得到所有人的密碼，應該也不太放心吧，尤其很多人都在多個網站使用同樣的密碼

結論就是因為無法保證 key 的安全，所以不建議用加密的方式保存密碼

方案三：SHA1 雜湊

雜湊代表是不可逆的，通常是拿到密碼之後再雜湊一次比對結果：

當使用者 Luka 要登入時，就把他輸入的密碼拿去經過 SHA1 雜湊，如果算出來的雜湊值跟資料庫內那一大串一樣，那就代表 Luka 有極高機率輸入了正確的密碼，所以就放行讓他登入

但因為現在的電腦已經很猛了，所以針對一些長度很短的、常出現的密碼，其實就可以直接拿來比對 SAH1，結果就還是會被猜出來

剛剛的 love1234 之所以可以被破解其實是因為他太簡單了，只要把長度為 8 的字串雜湊值都算過一遍就好。而且小寫字母加上數字也才 36 個字元，算一算 36⁸ 大約才 2.8 兆種組合，很快就可以建一個表出來

如果你的密碼又臭又長又亂、包含了大小寫甚至還有一些怪怪的字元，像是 -y]@7k[BSB@3m]r$.>“R，那以現在電腦的計算速度就還無法破解，因為長度 20 以內由數字、大小寫還有特殊字元組成的字串太多了，算到天荒地老都不見得能算出來

（只到這步的話，感覺平常只要密碼夠長就沒啥問題？）

補充：感謝前輩提醒，SHA1 已經在 2017 年被攻破（Announcing the first SHA1 collision - Security Blog），並在 2020 年被公認不再安全（Critical flaw demonstrated in common digital security algorithm）

因此建議不要再用 SHA1 了，請改用更舒適安全的雜湊，例如 SHA256 🤔

方案四：加鹽 & SHA256

哦？聽起來只要密碼夠長、夠亂就沒問題了，那我能不能自己產生隨機字串，把使用者的密碼加長呢？

答案是可以，這就是所謂的 加鹽（Salt）。如果今天有一個新的使用者要註冊，這時我們的後端系統就隨機生成一個長度十的字串稱作 Salt，計算 Hash 時就把使用者輸入的密碼跟 Salt 合在一起算

我現在碰到的密碼處理幾乎都是這種，安心實在。

原本攻擊者遇到簡單的雜湊，可能都已經把各個密碼對應的表都算好了（延伸閱讀：彩虹表）

但只要加了鹽，這張準備好的小抄就不能用啦～只要多一兩個步驟，就可以讓駭客算到天荒地老，何樂而不為呢？

方案五：Bcrypt

完全沒看過的東西！馬上節錄文章內的介紹：

雖然 Bcrypt 的名字裡面有個 crypt，但他並不是加密法，而是跟 SHA1 一樣是雜湊演算法，唯一的差別是他計算很慢

計算慢有什麼好處呢？前面有提到 SHA1 的雜湊值之所以可以被查表查出來，就是因為現今的電腦計算太快了，就連建個表反查也不需要太多時間

而 Bcrypt 則是可以透過設定疊代次數讓他變慢，以疊代五次的 Bcrypt 來說，他的計算速度大概比 SHA1 慢 1000 倍。也就是說，假如你原本用 SHA1 計算三天就能反查出所有使用者的密碼，現在卻要花大概八年的時間才可以

竟然就只是，算很慢？但想想還是很有道理，畢竟現在的玩法就是炸裂駭客的時間成本讓他去找別人，這樣看起來其實挺有用的？

補充：Argon2

這篇上推之後，發現蠻多朋朋提到 Argon2 這個香東西，第一次認識。怕忘記，先抓兩篇丟上來：

• Password Storage Cheat Sheet - OWASP Cheat Sheet Series
• What is Argon2 Hash? - debugpointer

目前看起來最大的特色是可以自訂 Time Cost、Memory Cost 跟 Parallelism Factor，然後因為太吃記憶體(?) 所以打擊用 GPU 的挑戰者特有效？

晚點再研究研究，先補充上來🤔

最後標一下總結的這一小句。我發現有很多朋友曾經跟我有一樣的迷思：
「安全是不是就等於完全無法被攻破？」但其實不是這樣的。

在資安領域沒有所謂絕對的安全，你只能不斷提高攻擊者的成本，當那個成本高到攻擊者無法負荷時（像是破解一個密碼要租超級電腦連續計算十年），那就可以說是足夠安全了XD

今天在群組剛好看有人在討論加密跟雜湊，馬上把收藏已久的這篇拿出來：

一次搞懂密碼學中的三兄弟 — Encode、Encrypt 跟 Hash - Starbugs Weekly 星巴哥技術專欄

這篇文章依序介紹編碼、加密和雜湊，並且都有給範例和應用，很適合剛認識的朋友。（也可以拿去丟給每次都講錯的朋友）

那按照慣例，我們也迅速筆記一下，讓我收到卡片庫裡：

首先是編碼。編碼其實就是換個方式表達資料而已。

例如跟朋友約好 ㄅ=A, ㄆ=B… 這樣轉換下去，基本上只要知道對應的內容就可以馬上轉回來，摩斯密碼就是這類。

（題外話，以前還在紙條上用過豬圈密碼 xD）

延伸閱讀：為什麼打開檔案時會看到亂碼？跟著小明一起從傳紙條學習編碼

接著認識一下二哥：加密。

加密不只是像編碼一樣單純轉換而已，而是需要使用金鑰。

例如 ㄅ=A, ㄆ=B 之後，這時候我們約好 key=2，代表字母要往下數幾格，這時候就變成 ㄅ=C, ㄆ=D，如果不知道 key=2 就可能會數錯了

當然現在用的加密還是比較正經一點，被暴力解都要跑超久那種的。此外，根據加解密是不是用同一把 Key，還會分對稱式跟非對稱式

有興趣的朋友可以閱讀內文，以及延伸閱讀：

• 基礎密碼學(對稱式與非對稱式加密技術) - Chan
• 圖解“非對稱”與“對稱”加密技術

最後是雜湊，雜湊沒在跟你還不還原的，直接就是打爛。

把各個欄位/字元 丟進去某個公式計算的方式就叫做雜湊（Hash），而這個計算公式就稱為雜湊函數（Hash function），過程可能會做各種加減乘除，最後算出一個值或字串。

因為最後一個數字是經由前幾個數字計算、濃縮出來的，所以理所當然不可能由雜湊後的結果回推出前幾個數字分別是什麼，所以雜湊的過程是不可逆的

這邊想貼另一篇的說明，也非常好懂：

[資料結構] 雜湊 (Hash)

舉例來說，雜湊函數就像一台果汁機，我們把蘋果香蕉你個芭樂 (資料) 都丟進去打一打、攪一攪，全部變得爛爛的很噁心對吧？！這時候出來的產物 (經過雜湊函數後的值)，是獨一無二的，沒有辦法反向組合成原來的水果 (資料)。倘若我們把蘋果改成紅龍果，出來的產物 (經過雜湊函數後的值) 就會跟著改變，變成桃紅色的，不再是原來的淡黃色。

我個人通常是在存密碼的時候碰到，反正就算要比對的話，只要照同樣步驟打爛兩次結果長的一樣就好了吧～

最後引用一下這篇文章簡潔有力的小結，結束這一回合：

• 編碼（Encoding）
  • 只是換個方式表達資料
  • 不需要 Key 即可解碼（不安全）
• 加密（Encrypt）
  • 用 Key 來保護資料的機密性
  • 加密跟解密都需要 Key
• 雜湊（Hashing）
  • 把資料丟進一串公式計算出一個結果
  • 無法反推回原字串

那麼，今天的轉貼就到這邊，明天見～

最近專案進行得熱烈，團隊間的溝通也比較頻繁。決定來轉貼這一篇：
第一天上班就該學會的精準提問術

這篇提供了我們菜鳥朋朋們一些工作上溝通要注意的事情，例如「讓對方感受到你有尊重他的時間」、「溝通頻率一天不要超過三次」等等。

除此之外，還列了一些小技巧。
例如想要從對方身上獲得資訊的時候，可以描述一下預期結果和實際結果的差異：

「你原本認知的事情是要跑 A 流程，但試著執行後卻發現出現預期外的 B 結果，想詢問自己認知是否有錯」

「我看了你的 UI 畫面，本來是認為從 A 頁面要連到 B 頁面應該是用 slide 轉場，但是我看到了 C 頁面好像跟我預期想像的動畫轉場好像不一樣，你可以描述你心目中的正確轉場方式嗎？」

或是要請別人替你處理事情時，可以試試提供選擇題：

「這個問題困擾了我很久，我想到 A、B、C 作法，但不知道哪個比較好，你可以幫我看看哪個比較適合呢？」

「主管你臨時插件的 B 案子我覺得沒問題，那你要先做這個 B 案子嗎？如果是這樣 本來 A 案今天下班前就可以給你，就會變成 後天下班前才能給你，這樣 ok 嗎？」

搭配同個系列的這兩篇服用，效果更佳：

• 專業就是連麻瓜都聽得懂的溝通術
• 工程師如何與 PM 溝通 - 菜鳥工程師必修的 30 堂溝通課

如果想繼續了解「我該怎麼發問」，或是希望自己至少上班的時候不要問出白癡問題的話，
絕對絕對要閱讀這一篇經典：

• 提問的智慧 (How To Ask Questions The Smart Way)

如果真的沒時間，至少可以看看〈好問題跟蠢問題〉以及〈不該問的問題〉兩小節。拜託。

反正我現在看到怪怪的問題都直接把這篇文甩過去

這幾天被某台新出的彩色電子閱讀器燒到，剛好眼睛也開始有點不太舒服，整個非常心動。

但其實我一直不是很懂電子書閱讀器的發光功能是要幹嘛用的，查資料翻到這兩篇，決定轉貼上來：

• 彩色電子紙的前光(背光)迷思 - Jack Black
• 彩色電子紙開前光是否就失去了護眼的意義？ - Jack Black

這兩篇還有科普了電子書的一些迷思，例如「光線太暗會傷眼」、「亮度越亮顏色越鮮豔」等等

但因為我之前的迷思主要在「如果我用閱讀器開了這個燈，那不是跟我用平板一樣？」，因此主要節錄一些前光和背光的部份來筆記就好。

首先讓我們看看電子書的發光方式：

所謂電子紙的前光源，是裝置在電子紙紙面側邊上方的 LED 燈珠，它發出的光會透過導光板均勻的分佈到紙面中間上方並照射墨水分子，而墨水分子再把這個光反射回來給我們看到，因此也是反射光

彩色電子紙的前光源其實跟環境的人工照明光源（如檯燈）並無不同，一樣都是光線照射到墨水分子後再反射墨水分子的顏色光到使用者的眼睛，與液晶螢幕、OLED、Mini or Micro LED 這些使用背光源照明直射成像的方式不一樣。

電子書閱讀器的是「前光」，就是其實有個很近的檯燈照到文字，再反射到眼睛上。

而不是像平板那種直接在液晶背後發光的「背光」，也就不會有背光為了顯示而必須比環境還亮、造成眼睛負擔的問題了

（當然，如果用前光或檯燈然後跟環境光源差異很大，例如房間超暗檯燈超亮，還是會造成負擔）

大概是這樣，今天認識了「前光」和「背光」。感覺從名字就能看出差異🧐

那我們什麼時候要把電子書的背光打開呢？

基本上開啟前光的時機只有一個原則：當螢幕距離眼睛必須要小於 30 公分才有辦法看清楚字或圖片的輪廓時，就必須要開前光，因為這個時候代表對比度已經太差了，開始要多用眼力與腦力的狀態。

當發現身子不由自主地一直想靠近的時候，應該就是警訊了。就像另一段所說的：

真正造成眼睛過大負擔的其實是近距離長時間用眼，例如字太小為了要讀清楚而拉近距離，或是太暗想看清楚而拉近距離，造成睫狀肌持續收縮得不到休息

不要離螢幕太近！不要離螢幕太近！不要離螢幕太近！
替每次都把整個把臉貼在螢幕上的朋朋默哀

大 Guy 這樣。今天的轉貼就來點豆知識，我們明天見～

今天要推薦的是這篇 CAP 的小故事：
A plain english introduction to CAP Theorem - Kaushik Sathupadi

為了怕有朋友跟我一樣對 CAP 不太熟，這邊先筆記一下。

首先讓我們認識 CAP 各自代表的意思：

• 一致性（Consistency）：使用者總是可以查到最新的資料
• 可用性（Availability）：使用者總是可以正常讀寫，不會突然送你個 Error
• 分區容錯性（Partition tolerance）：即使系統之間斷訊了，大家各自還是得做事，做完還要能同步

CAP 定理是指在一致性、可用性、分區容錯性這三項之中，我們只能滿足其中兩項 :(

通常來說，我們會先拿著 P 確保服務活著，然後在 C 一致性跟 A 可用性之間痛苦地抉擇

例如保證可以操作，但是還沒同步完所以會查到舊資料（AP）；或是被卡著乖乖等到資料同步完才能查（CP）等等

這部分想進一步了解的朋友可以參考最後的延伸閱讀。現在讓我們回到今天推薦的這篇文章

這篇小故事從「幫客人記得事情」的一人公司(?)開始，
隨著客戶數量變多，老闆決定請老婆進來一起幫忙記東西（殊不知這就是分散式惡夢的開端）

他們經歷了第一次查詢失敗危機、想出一些同步機制，然後面對可怕的休假等等

最後…… 結局就留給各位自己看了。

總之，以後有人問起 CAP 的問題，我決定就甩這篇給他們了 xD

延伸閱讀，想多認識 CAP 一點的可以繼續看看下面這些文章：

• The CAP FAQ - henryr
• CAP 定理 101 — 分散式系統，有一好沒兩好 - 後端新手村
• 什麼是 CAP 定理 - puritys.me

那麼，今天的轉貼就到這邊。我們明天見～

剛剛收件閘巡到一篇 Code Review 的文章，感覺挺適合轉貼上來分享給大家：
Code review 的好處與 bad smells - Huan-Lin 學習筆記

我們在 1/13 的時候分享過 Code Review 的這兩篇：

• 從 Code Review 的小事看大事
• Google 教我如何進行 Code Review

經由這些文章，我們能大約知道 Code Review 該看哪些東西，又有什麼好處等等（問就是 FOUR EYES!）

而今天轉貼的這篇 Huan-Lin 大大的〈Code review 的好處與 bad smells〉，則提到了另一個有趣的點：有問題的 Code Review 會有哪些壞味道？

文章裡面列了三項，並且每一項都用了一小段來解釋。這邊就按照慣例，簡單收一下筆記：

• 馬馬虎虎：我很忙，看個意思意思就好
• 合作無間：自個兒人，幫個忙唄
• 粗魯評論：挑毛病、戰習慣、叫你改就改

有採用 Code Review 的朋朋們，也可以觀察一下團隊有沒有提到的這些狀況

那麼，今天的轉貼就到這邊。我們明天見～

最近對「每個人的抽象化思考能力有所不同」蠻有感的。想轉貼之前 vgod 大大的這篇：
追求神乎其技的程式設計之道(七） - vgod’s blog

這個系列真的蠻好看的，但今天推的主要是文章中的這段：

我覺得所有的程式都可以看成一個巨大的金字塔，頂端是這個程式的最終目標，一個模糊的概念；底部是細節的程式碼。

而中間是一個經由不斷切割與抽象化所構成的高塔，每一個程式都是切割為許多的元件、模組，再切為更細的 class 和 function，再來是最底下的變數與邏輯判斷式。

接著讓我們看看像我這樣的菜鳥跟真正的專業人士，他們所看見的「金字塔」有什麼差別：

很有趣的是，不同的人看這個塔就會有不同的樣子。

初學者看到的塔只有兩層，他們和人溝通的方法是鉅細靡遺的描述程式碼：「我在這裡寫個 for，第一次把 i設成 0，在迴圈內每次檢查這個陣列的第 i 個元素…」

在他們眼中只有程式的目標和程式碼本身，所以還可能會寫出下面這種讓人哭笑不得的註解：

a = 1; // 把 a 設為 1

有些經驗後，會再多看到一層，利用 function 把一段程式碼包裝起來，賦予一個名字和獨特的意義。學會這個後，就可以利用抽象化後的 function 名稱來溝通，例如：「我在這個迴圈裡每次都用 isCaptial 來檢查這個字串是不是都是大寫…」

再接下去呢，可以再利用 class，利用 design patterns，利用更大的模組、子系統來溝通，認真說起來，這其實是一個無止境的切割。

隨著我們的經驗增長，我們漸漸可以切出更多的「層」或「模組」，從不同顆粒度的層次去檢視、溝通。這就是抽象化的力量。

最後再截一段我很喜歡的段落：

在資訊科學這個領域，抽象化是個無窮無盡的必要行為。因為世間萬物實在太多太複雜，我們只好不斷把東西歸類，並賦予一個名稱、一個意義，經由這樣的過程我們才能用抽象的語言和符號來溝通，避免每次都要從最底層的瑣碎細節開始說起。

而平凡和偉大的程式設計師，我覺得他們之間的差別就在於能看到多少這個高塔中間的分層。

厲害的高手都很善於切換自己思考的高度，一下能跟你討論高階的系統架構設計，一下又能深入到最底下的組合語言和二進位除錯。他們腦中除了有這高塔每一層的詳盡平面圖，甚至也非常了解不同樓層之間的交互關係。

平凡的程式設計師大多只能專注於自己所開發的範圍，對於其上的架構或其下的細節都不一定能理清頭緒，萬一出現 bug 也會搞不清楚到底是哪一層出了錯，而被完全無關的細節絆住手腳。

希望我們都能擁有更多不同層次的視野，共勉之。

這篇文章的後半段聊了一些被語言的慣例限制了思考方式的故事。

對於這方面，我也推薦 1/10 轉貼過的這篇：
一個語言如果不改變你的思考方式，就不值得學？

每一種語言，其實都是一種對資訊的選擇

那麼，今天的轉貼就到這邊。我們明天見～