推薦指數：★☆☆☆☆

並不是說不推薦，只是不知道通用性有多高。本書主要是針對一個硬體平臺為標的，雖然利用了大量Linux核心的抽象，應該移植不會困難。但雖然我也沒有實際操作，但本書仍然可以看到Linux核心的設計和原則，其中我也進一步了解過去不清楚的部份。僅推薦給已經有一部分概念的人閱讀。那麼一樣，紀錄一下我認為值得紀錄的部份。（雖然這次不多，因為大部分段落沒完全看懂，感受不到很深刻）

還有，這篇筆記寫得蠻亂的XXDDD

TED連結：Transcript of “Why you should define your fears instead of your goals”

看完後，最近我也在嘗試使用這樣的方式分析、協助自己做決策。有時候定義目標很難，那何不嘗試試定義恐懼？

定義恐懼

斯多葛主義(Stoicism)的一種衍伸，其幫助於自己專注於自己可以控制的要件，而不去擔心不可控制的部份所產生出的恐懼。

你能控制與你不能控制(專注於前者)

未知是恐懼的。未來充滿未知、充滿恐懼，但或許是想多了？

「我們在想像中所受的苦比在現實中還多」
“We suffer more often in imagination than in reality,”
—塞內卡(Seneca)

間單說就是：

書名：

• 學徒模式－優秀軟體開發者的養成之路
• Apprenticeship Patterns(原文)
• 軟體開發者路線圖：從學徒到高手(陸譯)

讀完日期：2020/10/31
推薦指數：★★☆☆☆

這本書我是因為看到別人的書評筆記才去找來看的，其中最重要的幾點是因為有些與我想法相符，我想更了解作者還有什麼想法。這當中有許多想法或許與現在的主流思想不同(我認識一些求快而不懂原理的人)，所以或許並不那麼值得推薦。但如果你是正在專研一項技術知識路上的旅人/學徒，這本絕對值得看看同為路上的人怎麼想。

與熊共舞，這本書的筆記你會發現跟我之前寫的筆記方式有些不同。我對本書有很多感觸，也因此我更想好好的整理。但總拖著，本書我六月份就看完了，也做過一些初步整理，直至今日才來寫寫心得筆記，撰寫之初亦沒有把握這筆記能夠寫得我滿意。不管怎說，這件事總覺得應該做、必須做，有很多東西，也只有做了才知道。

書名：與熊共舞
讀完日期：2020/06/13
推薦指數：★★★★★
(如果你已經帶過幾次軟體專案，我推薦爆表)

關於與熊共舞

在筆記之前，還是得來吹吹這本書的地位。「與熊共舞」和「人月神話」、「最後期限」並列為軟體專案管理，歷久不衰的必讀經典著作，如果你是軟體開發人員，我會額外推薦你閱讀Bob大叔的「Clean Code」。

儘管我聽過「與熊共舞」和「人月神話」好一段日子，但是這是我第一次讀三本中的其中一本。「最後期限」更是本書推薦後我才知道，亦非常期待之後閱讀。
そか～在看其他東西，都忘了我自己還訂了這兩本書單。

本書的副標題揭露的探討的內容：「軟體專案的風險管理」。但我認為其中提到的風險管理概念，不只可以用於軟體專案，對於任何形式的專案都具有幫助。

風險的定義

這本書以一個個假想的案例，帶讀者看看文字分析、對話機器人、臉部辨識、表情分析、強化學習、預測與推薦。內容不深，也有一些建議，可以是作一個個簡單的案例來看。

推薦指數：★★☆☆☆
閱讀日期：2020/05/28

編寫可讀代碼的藝術(The Art of Readable Code) - 閱讀筆記

這本書有些地方是不合時宜的、我不太認同的，尤其是關於JS的部份，畢竟ES6後JS這個語言本身變化得非常多。我還是想引用Bob大叔在《Clean Code》的裡寫的：

當然，本書的許多建議是具爭議性的，你或許不會完同意這些意見，…… ，我們也無法主張自己的看法就是最終的權威。……。所以先不論你是否同意我們的想法，如果你根本沒有看到，或尊重我們的看法，你應該要感到羞愧。
– by Robert C. Martin（人稱Bob大叔（Uncle Bob））。Clean Code無暇的程式碼。

總之，儘管有些部份與自己作法略有不同，但不管是內容，還是內文漫畫(cartoon¹真的話的很有趣)都有很大閱讀的價值，非常推薦！

推薦指數：★★★★☆
閱讀日期：2020/05/07

《軟體測試的藝術》，寫過筆記的人也不少，但筆記畢竟主要是給自己看的，就還是紀錄一下自己認為值得反覆咀嚼的內容。值得意外的有點多，尤其是第六章節。很多我無法用一兩句話去記憶、帶過，自己尚未內化或許是原因之一，所以這篇筆記會很亂。總之，雖然剛開頭覺得有些無趣，但是強烈推薦去完整讀讀第六章節。

測試是為發現錯誤而執行程序的過程。
軟體測試更適宜被視為試圖發現程序中錯誤（假設其存在）的破壞性的過程。軟體做了其應該做的，未做其不應該做的。

推薦指數：★★★☆☆ 閱讀日期：2020/04/24

以下為筆記內容

第六章、更高級別的測試

軟體開發週期：

1. 最終用戶轉換為書面需求（最終實現目標）(需求分析)
2. 評估可行性與成本，消除相牴觸的用戶需求，建立優先級別和平衡關係，轉換為具體目標。(WPS、干特圖)(設計)
3. 轉換為規格說明（外部格說明）
4. 如果該產品是一個系統，接著就是系統設計。拆分成多的獨立的子程序、部件或子系統，並定義接口。
5. 通過定義的每個模塊功能、模塊層次結構與接口，來設計程式或程式集合的結構。
6. 設計一份 準確的規格說明 ，定義每個模塊的功能與接口。
7. 經過一個或多個子步驟，將模塊接口規格說明轉換為每個模塊的原始碼。(開發)

• 需求規格 說明定義了為什麼要開發程序。
• 目標定義 了程序要做什麼，以及應做的怎樣。
• 外部規格說明 定義了程序對用戶的準確表現。
• 與後續階段相關的文檔越來越詳細地規定了程序是如何建立起來的。

測試方法、階段：

程式設計師應當避免測試自己編寫的程序。（除了單元測試外）

目前在服義務役當兵，這本有點忘記啥時看完的了，印象中在入營前。總之，利用放假一點時間寫一下筆記。

喔！對了，我也看完「軟體測試的藝術」了。有時間再來寫。

六六三十六，數中有術，術中有數。
陰陽變理，機在其中。
機不可設，設則不中。
– 《三十六計》

推薦指數：★★★☆☆

本書分成三大部份：

• 第一部份：修改機理
• 第二部份：修改代碼的技術
• 第三部份：解依賴的技術

對我而言有幫助的在後兩個部份，但我也還在理解中。一個是個人經驗不足，有些內容沒有那麼深刻的體會。故如果你跟我一樣沒有多少重構經驗，看這本書可能也會像在霧裡看花。但我仍然覺得有些收穫，所以我會給2-3顆星。而如果你已經有一些重構經驗，但重構的有些痛苦，這本書或許會很適合你。

好的技術書籍一般有兩種情況，一種是介紹一些新奇而有趣的技術，另一種是能將現有的技術闡述或概括得通透淋漓。然而， 實際上還有第三種–既非介紹新奇的技術，也非闡述紀有的技術，而是將長期實踐所證明了的大量技術手法囊括在一起。看起來琳瑯滿目五花八門，但又各有各的用武之地。 這樣的書一般較少見，因為需要長期的累積和時間的洗禮。
本書正式這樣一本書。
– p.6 譯者序 節錄

我對Common Lisp的喜愛應該不用多說。我不知道他還可以帶給我多少驚喜。

節錄幾個Common Lisp文章的相關敘述。

超凡脫俗的極限 - Common Lisp 文/田春

在文中最後寫：

原文: 超凡脫俗的極限 文/田春 鏈接已失效。

我閱讀位置：https://open343.github.io/Writing/zh-cmn-Hant/Overworldly-Common-Lisp.html

這應該是我第二次看，第一次看應該是在原本連結處。

語法

中序表達式可以徹底避免運算符優先級，例如 C 語言的表達式 1+23 在 Lisp 中將寫成 (+ 1 ( 2 3)) ，其中的 + 和 * 都是普通函數的名稱，和其他用戶定義的函數沒有區別。 值得注意的是，小括號的使用並不是必須，只是 Lisp 讀取器的一種標識，完全可以定製。如果用戶喜歡用中括號甚至後序表達式來描述 Lisp 程序，也是有可能的，相關的方法請查詢 Common Lisp 的 get-macro-character 和 set-macro-character 函數。

高度賦予程式成員自由性

Common Lisp 是唯一的允許程序員控制從源代碼到目標程序的所有方面的編程語言 。典型的 Lisp 代碼的處理分為三個階段：讀取、編譯、加載以及執行，其中每個階段都允許程序員介入。

• 在讀取階段，用戶可以設置特殊的讀取宏，用簡潔的形式讀取用戶自定義的對象；
• 在編譯階段，通過定義宏可以執行任意代碼來生成被編譯器所讀取的代碼；
• 在程序加載階段，附加的代碼有機會被執行，例如全局變量的初始化；
• 而在最終的程序執行階段，Lisp 系統還仍然有機會繼續編譯和加載程序的其餘部分，例如補丁，因為包括 compile 和 load 在內的函數是語言規範的一部分。

在讀取階段有set-macro-character等讀取宏(read macro，我更喜歡使用原文。宏或巨集都不太能表達其強大)。
在編譯階段有defmacro、define-compiler-macro等可以使用。

kk音表解碼

課程影片：音標解碼：如何用26個英文字母來帶出所有的美式音標符號 （30分鐘必學課程）

筆記：https://postimg.cc/gallery/2rtdl5o5g/

想跟著寫一次，算是填上坑了
不過掃描後，黃色highlight變得好不明顯XD

國際拼音

今天寫的筆記，都是公開文檔。我會推薦都去看看。有些原則不一定需要遵守，保留彈性。內容與我之前寫的筆記也有關，最好先完整閱讀一個，且最好是買本Bob大叔的clean code。

無瑕的程式碼 JavaScript

連結：https://hackmd.io/@trylovetom/SJnKIrajH

受到Bob大叔的clean code啟發，是clean code的js版本。除了提到一些原則外，另有提及一些JS生態使用的工具。筆記僅簡單紀錄紀個我感興趣的部份，推薦要寫JS的還是去完整閱讀。

注意！你不必嚴格遵守每一項原則，有些甚至不被大眾所認同。雖然這只是份指南，卻是來自《無暇的程式碼》作者的多年結晶。

軟體工程只發展了五十年，仍然有很多地方值得去探討。當軟體與建築一樣古老時，也許會有一些墨守成規的原則。但現在，先讓這份指南當試金石，作為你和團隊的 JS 程式碼標準。

還有一件事情：知道這些原則，並不會立刻讓你成為出色的開發者，長期奉行它們，不代表你能高枕無憂不再犯錯。但是，千里之行，始於足下，時常與志同道合們進行討論（Code Review），改善不完備之處。不要因為自己寫出來的程式碼很糟糕而害怕分享，而是要畏懼自己居然寫出了這樣的程式碼！

評估程式碼好壞的方法

透過計算閱讀程式碼時的咒罵次數，來評估軟體品質

這方法與「可不可以不要寫糙 code」有異曲同工之妙。

協助維持軟體品質的工具

除了Golang，上週也把Emacs相關的、Rust、Kotlin等給看完取得成就～

就來簡短紀錄一下。

學習GNU Emacs

推薦指數：★☆☆☆☆
讀完日期：2020/02/12

想要學習Gnu Emacs，看一下內建的教程就好。這本我只是略讀，感覺對我幫助不大。總之如果你想學Gnu Emacs，不用讀這本，應該這樣做：

1. 下載Gnu Emacs
2. M-x help-with-tutorial-spec-language
3. 選擇繁體中文
4. 然後閱讀它

※ 如果你有開上方的menu-bar，也可以直接選擇help->Emacs Tutorial(C-h t)。

GNU Emacs Lisp編程入門

推薦指數：★☆☆☆☆
讀完日期：2020/02/13

如果你有寫elisp的需求，這本書可以略過，但有的話，可以看下。Emacs Lisp API文檔並不那麼好入門，這個可以帶你入一點點門(幫助有限就是)。

上面兩本書我看的都是比較舊的了，也都是略讀。這本裡面提到的技術手冊我沒找著。

Kotlin語言文檔(v1.3)

推薦指數：★★★☆☆
讀完日期：2020/02/13

簡評

怎麼說呢…看完當下的感覺是覺得，這本書很特別，我想這會許是因為這本書與Go語言設計者本身有關係。

Alan Donovan特别感謝：Sameer Ajmani、Chris Demetriou、Walt Drummond和Google公司的Reid Tatge允許他有充裕的時間去寫本書；

Alan A. A. Donovan 是作者之一，從致謝頁來看，同時也是Google員工。而Go語言，又是Google所開發的一個簡潔、高效的程式語言。Alan很可能參與了Go語言的設計與開發，也很可能是最早使用Go語言的一批人。這或許說明為何此種，跟閱讀「松本行弘的程序設計」之後的感覺，是相似的。推薦大家閱讀。

推薦指數：★★★★☆

紀錄並分享幾個，這幾天看完的系列文章。

iT體人賽，有蠻多很優質的文章，雖然有些東西還是要看時間讀，才比較有感覺。但總之，這次算是把之前先訂閱的系列看個一遍，今天做一下紀錄。

淺入淺出-計算機組織

系列連結：https://ithelp.ithome.com.tw/users/20091778/ironman/921

這篇文章應該是上Coursera的課程，那個北大的課程我也上過（其給予的連結我上去沒看到，這是另外找的），不過沒把問題做完，所以不算完課。雖然當時是準備考研究所去上的，最後也不算是考上我最主要目標的學校科系，但這門課老師說的真的很有趣，有興趣的可以去看看。

另外離散數學這門課也很好，雖然我有完課，但沒買證書。內容也有些忘記，之後可能會在挖出來複習一下。

整體而言，我會更推薦直接去聽課，課程中有動畫，解釋也比較清楚，但是作為基礎導覽或複習，這系列文章可以看看。

可不可以不要寫糙 code

https://ithelp.ithome.com.tw/users/20107637/ironman/1927

糙，注音：ㄘㄠˋ；拼音：cao。
意思是：不細緻的、草率、鹵莽(魯莽)。

特別注意：

1. 這個詞與看 code 時發出的狀聲詞若發音相同，一定是巧合。
2. 若這一系列介紹的範例 code ，讓你有一種親切感，也一定是巧合，因為文章並不會只是針對某些人，而指的是在座的各位…，沒啦！一定是巧合。

1月9號把一本經典的書籍給看完了，這麼說其實也不太對，因為我幾乎略過所有程式相關的部份，至於原因待會會提到。個人並不是非常推薦這本書– 設計模式：可覆用物件導向軟體基礎 ，就連已經看過「深入淺出設計模式」的我，都認為其中有些描述有點難懂。不過，設計模式本就有其應用的環境(context)，如過無法沈浸在其環境，就難裡理解為什麼使用這個模式。比較不好的是，有人反而為了使用模式，而用模式，沒有考慮到其環境是否適合。這本書我認為的價值，是可以釐清模式的價值，與一些被人捧上天的錯誤想法。

推薦指數：★★☆☆☆
(應該可以多給半顆拉！反正都是我的主觀判斷www)

這是一本「不只是Ruby的Ruby技術書籍」，要我在下另一個註腳的話，應該會是「從Ruby看計算機概論」。內容涵蓋之廣，物件導向程式設計、動態程式語言、原形程式設計(Propotype-base programming)、鴨子型別(算是一種設計模式)、強大的元編程(Meta Programming)、設計模式、有趣的猴子補丁、文字編碼、Ajax網頁技術、正則表達式(Rege)、平行處理(多工)、資訊安全、資料持久化(Serialization)、函數型程式設計(Functional Programming)。儘管只有快400頁，但可以從一本書裡窺看不同角度的技術世界。自己升大學以前，曾經在暑假看了至少三本計算機概論，好了解自己未來所選的科系，大學更是又讀了一次，在我看來，這本「松本行弘的程序世界」簡直就是技術界的計算機概論。對於只學過一種編程想法(如結構化程式設計或是物件導向程式設計)的人來說，或許會有許多地方看不懂，就當做個入門。不過，我自己到是看的頗為愉快。之前就有人說：Ruby的開發者是語言學家、Python的開發者是數學家。我看完本書後，松本行弘的視野真的很多角度、很廣。研究學習程式語言也是我的興趣之一，看在本書的當下，真覺得我和松大哥很投緣。

上面順序主要照書內出現的順序，下面稍微歸類整理一下：

• 程式語言設計思想
  • 動態程式語言
  • 物件導向程式設計(Object-oriented programming)
  • 原形程式設計(Propotype-base programming)
  • 函數型程式設計(Functional Programming)
• 開發設計思想
  • 設計模式(Design Pattern)
  • 鴨子型別(算是一種設計模式)
  • 有趣的猴子補丁(Monkey Pitching)
  • 強大的元編程(Meta Programming)
• 計算機概論常見內容
  • 文字編碼
  • 正則表達式(Rege)
  • Ajax網頁技術
  • 平行處理(多工)
  • 資訊安全
  • 資料持久化(Serialization)

這本書我在 2019/12/28 其實就看完了，不過跑去試了一些其他東西，到今天才來寫心得筆記。(看得當下其實就很想寫了🐰)

推薦指數：★★★★★

在讀這本書的時候，我腦內不斷的出現過去上UI/UX課程內容與以前看過的影片。雖然我確定是第一次看這本書，因為剛買時看書評說並不是非常好懂，就一直放著，真不知道放了多久。這回看下來，收穫頗多，加深了很多知識點。

內容短介

當代知名認知心理學先驅 唐納諾曼 的著作–設計的心理學。帶讀者瞭解生活上各種事物背後的設計與心理。人的行爲模式、心理與設計方法、流程。為何人會犯錯？是錯誤還是失誤？

「人為過失？錯了，是設計不良」透過欲設功能、意指、使用局限降低人犯錯的機會。 「五個為什麼」探討深層目的與原因¹。 「一個產品開發的那一天，就已經進度落後」如何在商業環境與設計達到平衡？

推薦指數：★★★★☆