部落格復活之路 pt.1 - 自動更新荒廢兩年終於復活的部落格筆者我的 部落格 自從兩年前換了工作之後，一路荒廢更新到前陣子，在生活中心有所轉移後，決定要來直面我荒廢已久的部落格了。 這兩年間雖然時不時也會寫點筆記、製作些讀書會有關的報告，但卻毫無更新動力。於是就把這些文章暗自存在 hackmd.io 上沒有發佈。 兩年的時間不長不短，但久到我可以忘記我的部落格專案是存在哪一個 Github Repository 了，基本也忘記了部落格框架的使用方法，檔案架構… etc。 簡單來說，在悠久且漫長的歲月中，我什麼都不記得了！ 復活之路腦袋一片空白要怎麼復活部落格？這時候有一個愛寫部落格的好友就很重要了，筆者在這邊鼓勵大家多多結交愛寫部落格的朋友，你有什麼問題直接投靠就對了。 所以本文致謝 Bear 在筆者最徬徨無助的時候猶如雪中送炭般的給予筆者人生前進道路中的一盞明光 實際上呢，也真的是辛苦 Bear 了，一步一步引領著我，帶我回想起來悠久流長的歲月中，部落格的使用、建立、部署方式。 自動更新部落格？筆者的部落格是由 Hexo 搭配 Markdown 語法及 Github Page 建立 ...

企業軟體架構模式 - ch9.1 Transaction Script (交易指令碼) 按照「程序」來組織商業邏輯，其中每一個程序負責處理來自展示層的單一請求 大多數的商業邏輯都可以被視為一系列的交易(transaction)，每一個交易都有自己的 Transactin Script ， Transactin Script 主要是將這些邏輯組織封裝成為單一程序。 運作原理原理舉個例子來說迷，如果我的需求是「預定一間旅館的房間」，那麼我會在我的預定程序中找到「檢查剩餘空房間」、「計算住宿價格」、「更新資料庫」等邏輯，而 Transactin Script 則是將這些邏輯封裝在預定房間的程序中。 位置與分層Transactin Script 放置的位置取決於你的軟體分層，不過作者推薦你盡量的將 Transactin Script 與其他分層隔離，另外不要讓你的 Transactin Script 去呼叫任何來自展示層的邏輯，這會讓你在修改和測試 Transactin Script 變得困難。 實踐方式你可以透過兩種方式將 Transactin Script 組織到類別中。 Transac ...

持續 API 管理 - ch9 API 園林API 園林的定義API 園林就是一個組織發表的所有 API 。園林內的 API 可能處於不同發展階段，也可能有不同的風格與實踐方法。 人們可能會用 API portfolio、API catalog、API surface area 來稱呼 API 園林。 API 考古API 園林的定義API 考古就是尋找整合處，研究他們為何會被做出來、怎麼做出來，用以了解複雜的 IT 系統歷史與結構 proto-API讓組件互動的「非」API 機制都可以稱作 proto-API （你可以把它想成尚未發展成真的 API，還停留在原型階段的意味） 總之API 考古可以幫助你更了解 API 園林，即使組件大部分都還是 proto-API，他是了解過往整合需求的起點。 大規模的 API 管理管理大規模的 API 就是在「實施某種園林規模設計規則」和「將個別 API 等級的設計自由度最大化」之間進行平衡。這種平衡型是經常出現在典型的複雜系統裡：「為了實現一制性和潛在的優化而將整合中心化」 vs. 「為了實現敏捷性與可發展性而去中心化」 整合中心化 這種作法的主要 ...

持續 API 管理 - ch1 管理 API 的挑戰與承諾本書嘗試著解決一個問題，作者試圖找出各種 API 管理成功的案例下所具備的共同特徵，並彙整分享。 在管理 API 時，還有個重要的挑戰，那就是我們必須要區分「設計、建構與發表單一 API」、「支援和管理多個 API（本書稱之為 API 園林 (landscape) ）」之間的差異。 最後，書上則會討論 API 生態系統的管理決策程序。 然而在討論以上議題前，我們先來看兩個重要的問題：什麼是 API 管理，以及為何它如此困難？ 什麼是 API 管理？如同前面所說到， API 管理並非只和設計、實作與發表 API 有關。同時也包含 API 生態系統的管理、如何在組織裡發俵決策，甚至是將現有的 API 遷移到正在成長的 API 園林等過程。 但在討論這些之前，我們需要討論 API 存在的終極理由，即 API 商務。 API 商務除了建立 API 與管理他們的細節外，製作 API 本身完全是為了支援商業目標和目的， API 通常是釋放組織現有價值的一種方式。 以下有幾種商業目的的方向及釋放組織價值的方式可參考 存取資料API 為企業做出 ...

簡潔架構 - ch29 整潔的嵌入式架構作者在他的生涯歷程發現一個現象，許多軟體被化作韌體，而與硬體牢牢地綁在一起。 軟體是可以有很長壽命的東西，但隨著硬體的演進，韌體會變得過時。 儘管軟體不會磨損，但可能因為韌體或硬體上未被管理的依賴性而被破壞。 嵌入式軟體由於硬體依賴性的影響而被剝奪其長壽潛力，並不罕見。 韌體依賴於硬體，隨著硬體的演進，他卻難以改變，所以我們應該考慮到這個現實來建構我們的嵌入式程式碼。 這章節主要想討論如何保持嵌入式軟體架構的整潔。 App 性質的測試這邊介紹 Kent Beck 的三種軟體建置活動（註解為作者的評論） 「先讓他可以運作」 如果他不能運作，我們就會失業 「然後把他做對」 重構程式碼，以便你和他人能夠理解他，並且能隨著需求變化或更容易理解而演化。 「然後讓他變快」 重構「需要」效能的程式碼 為什麼這麼多潛在的嵌入式軟體變成韌體？因為大多數的開發重點只放在了「讓他可以運作」上。 所以作者在這邊提到程式設計師的「App 性質的測試」，主要是來自於我們「只」關心我們的程式是否可以運作。 僅僅是通過了「App 性質的測試」，並不能說這個應 ...

整潔架構 - ch5 物件導向程式設計歷史小故事大家可以自己當故事看一下，這邊提到了關於物件導向通常都會具備三種特質，但現今的版本通常是四種（書上沒有提到關於抽象的不份） 物件導向四個特性： 抽象（Abstraction） 封裝（Encapsulation） 繼承（Inheritance） 多型（Polymorphism） 關於書中提到的封裝及繼承也有許多歷史小故事的部分，喜歡的可以去看看，這邊關於特性的解說我先跳過，因為網路上已經有太多寫得真的很棒的文章來解說這幾個特性了，這邊我們關注書中提到的比較有趣的部分：多型 依賴反向（Dependency Inversion）或是有人翻譯為依賴反轉。 承前面提到的歷史小故事，以前使用多型是一件代價不小的事情，在安全及方便得多型機制可用前，軟體中的功能會透過典型的呼叫樹去實現。也就是高層模組的函式呼叫中層模組的函式，而中層模組的函式呼叫低層模組的函式，程式碼之間的依賴關係緊緊跟隨著控制流程。 然而，在多型的設計發揮作用時（你可以想像這些模組都 implement 某個 interface），原始碼之間的依賴關係會朝著 interface 去 ...

整潔架構 - ch4 結構化程式設計這邊的主角是上一章節提到的 Edsger Wybe Dijkstra。 Dijkstra 於 1968 年發表的結構化程式設計，他證明了使用無限制地跳耀(goto 語句)對於程式的結構是有害的。比起這樣的跳耀他更推薦使用 if/then/else 和 do/while/until 來建構程式。 (第一段主要是在講歷史小故事，有興趣的人可以自己看一下) 證明Dijkstra 認為程式設計師可以像數學家一樣，使用數學證明的層次結構來證明程式是正確的 Dijkstra 想要使用真正數學意義上的證明(proof)，他想建立一個歐幾里德式的數學證明層次，亦即公設(postulate)、定理(theorem)、引申定理(corollary)和輔助定理(lemma) 但他失敗了 原因是因為他發現在使模組遞回的被分解成越來越小的單元時， goto 語句 的某些使用方式會使分解過程失敗，而無法被分解為粒度夠小的單元的前提下，就會讓他無法去證明。 （在理解了 goto 語句及用法後好像會發現，這種失敗感覺起來可能跟深度的強依賴有關聯） 而在這樣試圖證明的過程中，Di ...

整潔架構 - ch3 範式概述這一章會概述這個章節會提到的三種程式設計範式(programming paradigms) 範式(paradigms)是指程式設計的方式，與語言無關。範式告訴我們有哪些程式設計結構可以使用，以及何時該使用它們 ch4. 結構化程式設計(structured programming) ch5. 物件導向程式設計(object-orient programming) ch6. 函數程式設計(functional programming) 結構化程式設計第一個被採納的範式（並不是第一個被發明）是由 Edsger Wybe Dijkstra 於 1968 年發表的結構化程式設計，他證明了使用無限制地跳耀(goto 語句)對於程式的結構是有害的。比起這樣的跳耀他更推薦使用 if/then/else 和 do/while/until 來建構程式。 我們可以將結構化程式設計範式總結：結構化程式設計在直接的控制移轉上加上規範 關於 goto 語句可以參考以下兩篇文章來了解 你所不知道的 C 語言: goto 和流程控制篇 使用流程控制：GOTO 物件導向程式設 ...

提升程式設計師的面試力 - Ch 11 - 測試面試所遇到的與測試相關的問題大致上分為四大類 測試真實物體 測試軟體 為一個功能撰寫測試程式碼 解決已知問題 面試官想看到什麼整體的理解程度主要在測驗你是不是一個真正了解軟體的人，能不能適當的排出測試案例的優先順序。 知道如何化零為整主要在測驗你是不是真的理解軟體如何運作，還有軟體是否適合其所在的生態圈。 組織能力主要在測驗你在處理問題的方式是否是有條理的。 實際性主要在測驗你是否可以實際制定合理的測試計畫。 測試真實的物體題目：如何測試一個迴紋針 誰將使用它？為什麼？ 使用該產品的人是誰？如何使用？ 使用情境是什麼？ 盡可能列出使用的情境 使用限制是什麼？ 如標題，就是探討關於使用方面的限制 壓力、故障條件是什麼？ 探討故障條件是否是該產品可以接受的 你會怎麼做測試？ 測試方面的細節 測試軟體軟體測試跟測試實際的物體很類似，不過會更著重測試的細節 而軟體測試有兩個核心的方面： 手動測試和自動測試 黑箱測試與白箱測試 底下描述一下測試軟體的脈絡 我們要做的是黑箱測試還是白箱測試？ 可以詢問面試官他想做的是 ...

提升程式設計師的面試力 - Ch6 - 數學和邏輯謎題機率 A 和 B 的機率$$P(A \cap B)=P(同時發生 A 及 B 的機率) \=P(發生 A 的情況下，發生 B 的機率)=P(B \mid A)P(A) \=P(發生 B 的情況下，發生 A 的機率)=P(A \mid B)P(B) \$$ 由上可以得知 $$P(A \mid B)=\frac{P(B \mid A)P(A)}{P(B)}$$ 這個式子為 貝氏定理(Baye’s Therem) 的特例表示 A 或 B 的機率$$P(A \cup B)=P(A)+P(B)-P(A \cap B)$$ 獨立(Independent)A 與 B 互為獨立事件表示 發生 A 的機率與 B 無關 發生 B 的機率與 A 無關 所以 $$P(B \mid A) = P(B) \P(A \mid B) = P(A)\$$ 則由 $P(A \cap B)$ 的列式我們可以得知 $$P(A \cap B) \=P(B \mid A)P ...