最近在 code review 的過程中，總是常常會看到一些令人驚喜的事情，其中一件事情和程式的寫法有關．有時候是邏輯可以在簡化，有時候是 coding style 上可以在簡化以便閱讀．首先來看 coding style 可以簡化的部份．在寫程式的過程中，有時會因為業務邏輯面的複雜而造成會寫出多個 nested if statements 的情況，如下面的例子
This file contains bidirectional Unicode text that may be interpreted or compiled differently...
#83 最近搜尋清單資料結構
最近遇到一個特別的需求有關一種像 Queue 但又不是 Queue 的資料結構
需求如下:
1. 可以自訂清單數量大小
2. 內容一筆一筆的存放，但讀取時是後進先出
3. 如果存放時，該資料已存在，則讀取時它會先被讀取.
舉些實例來說明
以下為動作順序
Initialize as size of 5
Set 1
Set 2
Set 3
GetItems() ==> 資料是 3,2,1
Set 4
Set 5
GetItems() ==> 資料是 5,4,3,2,1
Set 6
Set 7
GetItems() ==> 資料是 7,6,5,4,3
Set 5
GetItems() ==> 資料是 5,7,6,4,3
Set 3
GetItems() ==>...
#82 K個最近鄰居演算法 (k-nearest neighbor algorithm, KNN)
在大部份的科學領域裡都蠻注重分類 (Classification) 這件事．透過分類，它能幫助我們整理問題，也能整理答案，甚至在不同的問題集合裡找出通用的答案．在人工智慧的領域裡，有一門科目叫模式辨認 (pattern recognition)，它應用在影像辨識，人臉辨識，語言辨識等的範圍，其中需要一個重要的技能就是將所要辦認的物件做分類，然後在該分類裡找出合適的對應結果．在這過程中，k-nearest neighbor (KNN) 是一種相對古老且直覺的方法．方法簡單而且能有高準確率，並且不需要所謂的 “訓練”．在人工智慧的領域裡，簡單而言，做的事情就是收集資料，然後依這些資料整理出一個數學模型，未來有新資料出現時，就可以丟入這數學模型加以運算，得出來的結果就是此模型的預測結果．KNN...
#81 出神入化的用介面 第四集 修改共用的介面 part.2
這一篇文章是上一集的延伸，再來說明新版本 interface 的後續實際使用的情況．先將此篇文章要解決問題再描述一次．想像一家公司出版了一套軟體，而這個產品裡包含了許多的元件檔案 (.dll)，而且每一個元件是由不同的團隊產生．每個元件可以有獨立的發行時間，也就是說當 A 團隊要釋出新功能的版本時，他們可以自行釋出．在客戶端裡，可以透過該軟體裡的更新程式來下載並且安裝 A 團隊所製做的新版本元件．由於各元件釋出的時間並非一致，因此元件之間的互動將變得有挑戰性．
A 團隊裡的某些功能是透過 B 團隊的元件所完成的．例如，A 團隊提供的功能裡有一項是計算產品折扣，而這項功能的細節實作者其實是 B 團隊，因此 B 團隊會提供 interface component 給 A 團隊使用，如:
...
#80 寫程式的參考準則 (coding guideline) - C# 篇
曾有一些朋友問我，在微軟公司裡是否有寫程式的準則 (coding guideline)．這件事因不同的團隊而異，大部份的團隊都會依循 MSDN 文件裡的建議，但並非每一個團隊都有文件記錄這些準則．以前我在 Windows 部門裡的某個團隊就正好有文件說明 C# coding guideline．除了 C# coding guideline 以外，還有其他的文件，例如 code review 文件, database 開發文件等等．在這篇文章中，我將從 C# coding guideline 開始寫起．這些 coding guideline 不是什麼秘密，很多都是來自 MSDN 的文件．若你的團隊也需要一份 C# coding guideline, 希望能派的上用場．
1. 在一份 C# 原始碼裡，別有...
#79 貪心策略 - Greedy (2)
上一篇文章談了貪心策略的基本想法，但並沒有提到任何的程式碼來說明貪心策略是怎麼進行的．其實貪心策略並沒有一個很明顯程式碼撰寫方式，如果硬是要湊出一個程式碼外型的話，我覺得它的長相可能如下:
while ( 依問題條件來決定是否要繼續下一步 )
{
// 1. 依照問題，在這一個步驟裡取得最佳解
// 2. 根據步驟一得到的最佳解來決定程式的下一個狀態
// 3. 將程式目前的狀態移動到下一個狀態，下一個狀態將會更接近最終的答案
}
老鼠走迷宮是很典型資料結構 Stack 作業，它的內容是假設一個方形的土地，這土地用畫分成許多面積相等的小格子，就像棋盤那樣．每一個格子都是一種地形，如山，河，平地．老鼠只能走平地，不能爬山也不能過河．老鼠將從起點走到終點，起點是在這土地的左上角，而終點是在右下角．這個作業就是要讓老鼠能走出一條路從起點到終點．如果沒有路存在，則最後的答案是...
#78 貪心策略 - Greedy (1)
前面的文章曾提過，在這世界上有很多不同類型的問題，基本上我們太不可能找到一個方法來解決所有的問題．所以，不同類型的問題就會有不同的解法．有的解法很好理解並且單純，有的解法不易理解．解法本身並沒有所謂的好壞，只有適不適合使用的情況．通常來說，難的問題若要有好的執行結果，通常那個解法不見得簡單，就算是簡單，也絕非容易可以想的出來．這也許就是演算法美妙的地方，或許可以說是邏輯之美．廣泛地也可以說成是數學之美，都是宇宙空間裡所擁有的一些特質．
今天要提的解法是一種貪心 (Greedy) 的 “精神”．若你沒念過演算法這門課，恭喜你可以免除這個宇由特質的迫害，可以遠離那種整晚埋頭寫作業的崩潰時光．我想我是比較笨的，所以我以前寫演算法和計算理論的作業時，常常抱著頭在燒．如今，回頭看看，這些都是人生裡蠻有趣且值得回憶的時光．演算法課本裡，前面一半的內容中主要是提到一般市面上對問題的...
#77 部落格的原始動機與人生所需的財務智商
這篇文章來分享二個主題，第一是為何我開始寫這個部落格，第二是人生所需的財務智商．
我在 "大毛電腦科學筆記" 裡從 2015 年 3 月開始寫下第一篇文章到現在已經有三年半的時間了．剛開始的第一年，由於我沒有設計任何的讀者回饋方式，因此第一年並不知道寫的內容是否有用．後來第二年開始加入 Google Form 讓讀者們可以留下回饋資訊，並且也為網站上加入 Google Analytics 用來查看網站的流量資訊．大約一年前成立了 Facebook 社團以及舉辦公益課程來做為另一種推廣此部落格的管道．從去年 (2017) 開始，我陸陸續續收到一些讀者們的回饋，有些是單純地謝謝我寫這些淺顯易懂的內容，也有些是來問我一些工作上的問題．謝謝大家的捧場和問題讓我知道這個部落格已經發揮了一些作用．其實，我最早的想法並不是寫部落格，而是打算把所有的資訊匯集成冊出版用．早在十年前，我收集了以前在台灣和美國念的上課筆記，打算將這些內容寫成書來出版．但可惜，後來因為搬家緣故，那一大本的筆記已下落不明，所以把筆記匯集成書的想法便中斷了．但我並沒有忘記要分享電腦科學的基礎知識這件事．後來心想，匯集成冊需要大量時間並且有出版時程的壓力，於是...
#76 演算法裡一個基本的觀念 - Reduction
Reduction 是一個在演算法知識裡基本且簡單的觀念．其實在各位的工作中也一定常用到這觀念，只是你不知道而己．在這文章裡一如往昔，不用學術理論的描述方式，而是用平常寫程式的例子來讓非電腦科系畢業的資訊人了解什麼是 Reduction．
接下來用寫程式的角度來看什麼是 Reduction．假設你需要寫一個影像辨識的程式，這個程式需要辨識一個圖片裡是否含有某個數字，所以你寫的 function 可能會像下列:
This file contains bidirectional Unicode text that may be interpreted...
#75 將問題和演算法分類
學習基礎的演算法過程中，許多課本最常用的方式是將問題分類好，然後對每一類問題進行討論並給出一些著名的演算法來解決這一類的問題．因此，要了解自己面對的問題屬於那一類型的問題便是件重要的課題．在這一系列的文章中，我的目的並不是要告訴你大學課程的演算法內容，而是希望用一種比較實際工作上會遇到的普遍情況來說明在工作中可能會碰到跟演算法課本內容有關係的課題．就像上一篇文章提過的，演算法的內容就像是你寫的程式裡某一個 function，每一個 function 一定有一個特定的目的．因此，你可以想像世界上存在許多的演算法，每一個演算法都有一個目的．當你認識了許多演算法時，有一個簡單的方法來分類演算法的種類，就是按照目的來分類．只要你知道你的問題是屬於那一類，這樣你就知道該去找那一類的演算法．例如，你的工作裡某一個任務需要將資料庫中的訂單做排序，因此，你就可以在市面上找到許多的排序演算法，挑一個適合用在你的工作裡．排序是一個相當簡單的例子，你甚至不用找演算法，因為這類基礎的演算法都已被實做在許多產品裡．另外一個例子，你的工作是做一個檢查文章裡的英文字是否拼錯，如果拼錯的話，必須列出一些建議清單來讓使用者選擇．這一類的演算法通常不會在一般的...
#74 演算法從零開始
資料結構和演算法算是最基礎而且重要的知識．若沒有這兩個科目的足夠知識的話是很難在其他電腦科學領域有所進步的，其中也包括程式設計這一條路．基本上來說，程式設計這條路需要強大的邏輯基礎，除了你得對 if .. else .. for loop 用的很熟練外，你還得了解你所用的 SDK, framework 的優缺點，這樣使用起來，你才知道你的 SDK, framework 為你的程式做了什麼事情．除此之外，你便需要知道資料結構和演算法的基本知識，這兩個學科是能幫助你寫出好程式的關鍵．
從前面的文章裡，我談了許多資料結構及其應用，也談了許多面試考題．當你看完那些文章後，你應該能抓到一個重點，這重點就是儘量地省時間 (省運算步驟)，不然的話，就得用空間來換時間 (提高空間複雜度來降低時間複雜度)．雖然每一種問題的情況都不一樣，不見得都能用空間換時間，但至少這是一個讓你思考的方向．演算法在這過程中扮演了重要角色，因為這門學問能幫助你辨別問題，知道什麼樣的問題...
#73 Coding面試 LeetCode#14 Longest Common Prefix
原題目網址是 https://leetcode.com/problems/longest-common-prefix/description/
這一題在 LeetCode 的難易度分類屬於簡單級，題目的意思是你會得到一個 string array，然後你得從這個 string array 裡面找到最長從頭開始的共同子字串．在題目裡有給了簡單的範例，例如 Input: ["flower","flow","flight"] , 則答案就是 "fl"．如果找不到合適的子字串，就直接回傳空字串．同時題目也告訴你，input 字串只有 a 到 z 之間的小寫字母，不會有其他的符號，這個條件大大降低了答案的難易度，因為可以少一些大小寫辦別或特殊字元或文化上的處理．
解法的邏輯也相對單純．找出最短長度的字串，以它為基礎，然後去比對每一字串從頭開始的字母，以此類推做到有一個字母是不符合條件或是最短長度已經到達．
參考的程式碼如下:
...
#72 一秒38萬個交易的故事 - 資料庫引擎篇
與資料庫有關的文章到目前為止已張貼了二十二篇文章，這些文章所談論的內容大部份都是描述資料庫引擎裡 Storage 和 Transaction 的內容．資料庫引擎裡的內容當然不只這些，還包括 SQL query parser, query optimizer, logging manager, 以及一些基本的功能如 security control 等等．光是有關 storage manager 的故事就能寫一本書了，除非你想做資料庫引擎的專家才需要知道所有的細節，不然的話，只要了解一些基本的設計便能幫助你在工作上做到更好的境界．在這些二十二篇與資料庫引擎有關的文章，我寫的那些內容其實簡化或跳過不少的細節，但那些細節並不會影響你對資料庫引擎設計的了解，只讓你可以用比較高層次的角度來檢視資料庫引擎會為你做的事情．畢竟這些內容主要的對象是給非電腦科系畢業的資訊人所參考用，因此忽略了許多數學上的推導與比較．若你是電腦科系的學生正在學習資料庫理論，請以課本內容為主，因為課本內容裡面會用一些數學來明確表達運作成本等事情．為什麼要說這些呢...
#71 資料庫引擎 - Deadlock 偵測 (Wait-For graph)
前兩篇文章談完了 table join，接著這篇文章把主題拉回到資料庫的 Transaction．
之前文章曾提過 deadlock 的發生，這在關聯式資料庫裡算是件平常可見的事情．之前曾提過當 deadlock 發生時，資料庫引擎可利用 wait-for graph 來偵測 deadlock 的發生．這篇文章將說明什麼是 wait-for graph．
Wait-for graph 是一個簡單的圖形，是一個有方向的圖形 (directed graph)，也就是它圖形上的邊具有方向性，這裡的方向性用來代表是那一個交易等待那一個交易．如下圖:
上圖的...
#70 Coding面試 - LeetCode #5 Longest Palindromic Substring
原文網址 : https://leetcode.com/problems/longest-palindromic-substring
這一題與之前曾提過的試驗字串是否為 Palindromic 的題目蠻雷同的．如果搭配 Palindromic 字串的檢驗法用在這題上，可能的解法如下:
從上面的程式碼你可以看到是將所有可能的子字串從大到小的長度逐一檢查是否為 Palindromic．因為題目是要找最長的 Palindromic，所以子字串長度才會從大到小．上述寫法的空間複雜度是 O(1)，但時間複雜度卻是 O(n3) ，主要因為有三個迴圈與字串長度是有關係的．雖然上述的寫法可以在合格的時間內通過 LeetCode 的 test cases，但若你提了這樣的 solution，面試官很有可能會再問你在空間複雜度上還有進步的空間．
如果你從第一篇文章看到現在的話，你應該可以發現我在許多文章都提過不少次...
