菜雞寫筆記，踩坑全紀錄
這兩天休假都在《P 的謊言》裡被 Boss 吊起來打，正好分享一下看過、關於魂系遊戲的文章：
在這兩篇文章中，作者先介紹到內在動機與外在動機的區別：
心理學家把人做事情的動機區分成兩種：內在（intrinsic）跟外在（extrinsic）。
簡單來說，當你出於內在動機做一件事，代表你是為了享受那件事情帶來的當下經驗而做，例如為了體驗刺激而參加高空跳傘活動。
若你不特別享受那件事情，而是為了進一步的目的，那麼你就是出於為外在動機去做事，例如本身不特別喜歡跳傘的特技跳傘表演者，或者想要以跳傘吸引心儀對象注意的人。
當人出於內在動機行為，代表人為了行為本身的樂趣而做（例如唱KTV）； 當人出於外在動機行為，代表人是為了行為的其他後果（例如陪長官唱KTV）。
接著闡述為什麼《血源詛咒》利用合理的困難度，成功讓玩家基於內在動機去享受遊戲：
……
今天和大家分享一篇前兩天看到的 Code Review 觀念文：
從 Code Review 的小事看到大事 - William Yeh
這篇的內容從 Code Review 出發，提了多個延伸議題。從程式碼品質、團隊共識，到需要哪些人事物才能促進 Code Review 的環境，引用的數量和思考都蠻廣的。像是談到 Code Review 的重點時，就引用了《軟體測試實務：業界成功案例與高效實踐（第一冊）》：
又或者在 Code Review 的鬆緊度這點上，引用了 Google 的 “What to look for in a code review”：
Don’t accept CLs (change lists) that degrade the code health of the system.
「童子軍規則」(The Boy Scout Rule)：「離開營地前，讓營地比使用前更加乾淨。（Always leave the campground cleaner than you found it.）」
我所在的團隊也有將 Code Review 拉進開發流程，目前給我的整體感覺是舒適的。在 Review 和被 Review 之中，我也常從同事們學到一些程式碼的簡化技巧，或是突然認識到「原來維護者是這樣理解我的程式碼的」而得到優化品質的機會（這也就是文內提到的 four eyes：多一個人來確保品質）
但同時，我也感覺到內文所寫的「品質不是白吃的午餐」是有道理的。Code Review 並不是萬靈丹，說一句「Reviewer 要把關啊」就可以消滅所有 Bug 和團隊問題。因此在閱讀這篇文章的時候，其中有幾個部分就會讓我覺得是個可以延伸出去的思考點：
……
放假前的下午無心上班，今天來轉貼一些輕鬆的： 忍者程式碼（Ninja Code）
微乎微乎！至于無形；神乎神乎！至于無聲，故能為敵之司命。 ——《孫子兵法．虛實》
這是一篇完美的忍者指南，講述了一名軟體忍者該具備的技能和美德
一位真正的忍者、強大的軟體工程師，知道什麼時候運用抽象化、什麼時候喚醒同伴的注意力、什麼時候展現他的熱情。
他將給予考驗；他將帶來驚奇；他將帶給我們啟發。
很多人試著跟隨忍者的腳步，但很少有人成功。但只要我們遵循裏面記載的建議，一定可以成為一位高深莫測的軟體忍者。推薦給大家
……
上一篇聊到：不同的程式語言、不同的工具都代表了不同的資訊選擇，也就是抽象化。那麼，我們在解決問題、學習新技能和知識的時候，是不是也有相似的概念呢？
今天想和大家分享 Huli 大大的這篇：
當我們在學程式時，要學的到底是什麼？ - Huli
我很喜歡 Huli 大大文章的一個特色：有趣而且貼切的故事。前面小明的故事真的是看了都會哭，很多人應該也能得到共鳴 => 這種的 :0hah: 共鳴
其中有一個問題，當時打中了我：
你是在鍛鍊記憶力還是解題能力？
當我們看見題目、思考方案、動手解決問題的時候。如果我們能夠整理並歸納出背後的邏輯，那麼這些題目也許就是同一個精神延伸的變化題；但如果我們只是死背硬記，那麼每個題目和場景，就會變成獨立且無窮無盡的背誦題。
這中間的差別就在於「抽象化」，或是文內提到的：計算思維
計算思維中最重要的概念之一，是能夠將計算「抽象化」與「具體化」的能力
回到主軸上面來。那麼當我們學習寫程式的時候，或是學習解決某個問題、應用某種工具的時候，要做什麼才能夠漸漸學會找到背後的抽象呢？我們可以從 Huli 大大整理出來的，學習一項新技術該做的事情中看出一些端倪：
……
在前一篇轉貼時，我分享了「知識點應該也有大綱到細節等等，不同抽象程度的顆粒度」的想法。
這個念頭是來自於幾年前閱讀到的一篇鐵人賽文章，今天我想順著把這篇文章介紹給大家：
Day2：[心得]一個語言如果不改變你的思考方式，就不值得學？談程式語言的本質 - Nissen
我曾經想過為什麼程式語言不能只留下一種，大家就學同一種就好，為什麼還要分強型別弱型別、物件導向函數導向等等……
直到看見這篇文章，我才有一些關於知識點和程式語言等等，這些資訊被「抽象化」的輪廓。
這篇文章用原始人看見「真正的牛」之後，畫出「牛的符號」作為例子，解決了我當時的疑惑，因為它說明了每種程式語言所做的「抽象化」：
抽象化是什麼？抽象化就是一種「選擇」 比如說，當原始人把牛畫下來的時候，他就已經做出了選擇。
咦！？有嗎？什麼時候？他做了什麼選擇什麼？
他在繪畫的時候，選擇了要保留or刪除什麼資訊。
當原始人在畫畫的時候：
牛身上的有「多少毛」、牛的「顏色」、牛的「重量」….這些資訊，重要嗎？不重要
牛的「輪廓」、牛的「線條」，這重要嗎？重要
這個原始人其實是從一個完整的牛身上刪除了大量資訊（重量、顏色、毛），抽象出了他留下最重要的資訊，也就是線條與輪廓。
每種語言看待世界的方式並不一樣，思考方式也就不一樣。因此，當它們把這些資訊抽象化成程式語言的符號時，選擇保留下來的資訊也就不一樣。
每一種語言，或是說每一種特性和設計方式，其實就代表了一種資訊的選擇、一種看待世界的方式。
因此才有開頭的那個問題，以及這篇文章所引用的這句話：
……A language that doesn’t affect the way you think about programming, is not worth knowing. – Alan Peris
今天想跟大家分享一種「閱讀文章並做筆記」的方式：「漸進式總結」
使用「漸進式總結」來寫筆記，逐步萃取出高含金量的知識內容 - PM 的生產力工具箱
我們工程師在研究某個主題或學習某些技能的時候，常常會需要閱讀大量文章。但要把閱讀完畢的文章整理成一篇筆記，其實還是蠻難的，像我就時常會遇到腦袋打結、看後面忘前面的狀況。
這種時候，我們就可以試試看漸進式總結：
藉由畫重點、用自己的話整理，再進行總結，這樣一層又一層的篩選和壓縮，就能幫助我們篩出關鍵部份、得到一份有著不同顆粒度的筆記，也會讓我們對筆記的內容更有印象。
在上 Domain Storytelling 的導讀時，講者說過一組故事會有不同的顆粒度，可能廣到能看見一片大海，或是細到看見一個貝殼。我想在我們學習的時候，每個知識點和相關的資訊，也有著顆粒度的差別。從大綱到細節的展開，應該會是不同抽象程度的資訊
漸進式總結能夠幫助我們從原始文檔中一步一步地提取不同顆粒度的資訊，對整個知識點的輪廓就會有更清晰的了解，有興趣的朋友可以嘗試看看。
……
今天禮拜一太過厭世，想簡單跟大家分享前陣子看到的酷東西：
LSB 隱寫術：在圖片裡偷渡敏感資訊的方法
我們都知道圖片是由許多像素構成的，每一個像素都有 RGB 來代表這個點的顏色。例如 R:255, G:0, B:0 就是黑色。
但我們的肉眼其實很難分辨出這些顏色之間 0 和 1 的區別，例如 (255, 0, 0) 和 (255, 0, 1)，對我們來說看起來根本就沒差
利用這個特性，我們就可以在圖片中不影響視覺觀看的同時，又能夾帶一些訊息進去
最常舉例的用途就是在截圖上面偷偷押上浮水印（像是員工編號之類的），那麼流出的時候就可以迅速抓到內鬼，終止交易
這篇的圖片說明清楚，篇幅簡短，非常推薦像我一樣還不知道隱寫術的朋朋們看看
……
今天有種想慵懶度日的感覺，是適合當貓的日子。因此今天丟一下自己的舊文來分享給大家：
菜雞抓蟲: Url 變得怪怪的？你可能是零寬空格（ZWSP）的受害者！
這是之前某次抓蟲的奇妙旅程，某些 API 突如其來地報錯，看似正常的查詢字串卻一直跳出查無資料或參數錯誤。找了老半天，竟然是**零寬空格（Zero-width space, ZWSP）**在作祟！
零寬空格是完全沒有寬度的空白字元。這東西在 Unicode 叫做 U+200B，我們比較常見到的是編碼之後的樣子 %e2%80%8b 或 \xe2\x80\x8b。他還有另外兩個兄弟 U+200C、U+200D，平常在泰文、高棉文之類的地方工作，這東西的特色就是：肉眼不可見、殺人於無形。
這兩天和朋友聊到研究新技術時的痛苦和心魔，因此想跟大家分享電腦玩物的這篇：
面對拖延糾結、恐懼沒時間，我幫助自己進入心流靠一個關鍵步驟 (playpcesor.com)
我個人很喜歡裡面的這段：
把「因為……所以我沒辦法做到……」，變成「因為……所以我現在可以做到……」：
- 因為現在時間只有30分鐘，所以我現在寫不完一篇文章。
- 變成：因為現在時間只有30分鐘，所以我先寫出腦中有的開場白草稿就好。
- 因為現在還不確定怎麼畫海報更好，所以我現在沒辦法做設計。
- 變成：因為現在還不確定怎麼畫海報更好，所以我先寫好海報上必備的基本資料。
- 因為等等還要開會，所以我現在無法專心動手寫完企劃案。
- 變成：因為等等還要開會，所以我現在先把企畫案基本規格做好就好。
- 因為我沒有設計過這種產品，所以我現在還沒辦法提供最佳方案。
- 變成：因為我沒有設計過這種產品，所以我先完成一個自己目前能想到的方案，再做討論。
這種轉換心態先推動做得到的部分，讓我想到大人學 Podcast 的其中一集：主持人對出國念書這個遠大的目標抱持恐懼和不確定，因此他決定先告訴自己「我並不是真的就馬上要出國念書了，我只是先研究看看而已！」
然後用同樣的技巧讓自己「唸一下」托福、「做一下」落點分析，一步一步地推進。最後等到真的要出國念書的時候，準備也都做得差不多了，一切就進行得非常順利。（ 明知要改變，卻怎麼也踏不出第一步？你需要的是「心理戰術」！ ）
面對太難太遠的目標，我們很容易拖延、焦慮和逃避；而太簡單的目標，又往往對我們沒有幫助。這時候我們也許就可轉個念頭，設計適合自己的挑戰，給自己十分鐘嘗試看看，也許就是進步的開始。
……
今天想分享給大家的是 Marcus 大大的這篇筆記：
[筆記] 商業思維學院 - 學習永動機
我們要怎麼樣才能夠在學習上一直進步呢？也許關鍵點就在複利
在這篇筆記中，從第一組正向迴圈：找到實際和目標的差距開始，規劃額外的工作量和工作時間。
進一步抓到更多的切入點，例如增加工作效率、提升工作的產值等等。
從不同方向擴充整個迴圈的模型，讓每一步都可以成為飛輪加速的一環。
其中每個過程都有附圖，很容易就能理解 懶人包 裡要表達的概念，值得一看。
在後段有提到學習的階段，也就是從資訊整理為知識，知識精煉成技能，最後從技能變現出價值。
這讓我想到先前看過的這篇：知識是如何形成的？ | PM的生產力工具箱 的 DIKW 模型
其中「知識到底怎麼來的？」的食譜與做菜譬喻非常直覺，有興趣的朋友也可以作為延伸閱讀看看～
最後想放一下看這邊筆記時很喜歡的一句話：
……如果你是一位伐木工，你的斧頭多久沒有磨了 ?
