-
不只是 TDD #2, 兩個版本自我驗證 + 執行期驗證
接續 上一篇，如果你以為要在本機解 LeetCode 的題目，只是把 test cases 改成 unit test 就結束的話，那 我就不需要寫這幾篇文章了。如果你的目標只擺在 “解題”，那的確看第一篇就夠了。如果這是老闆或是客戶給你的 “需求”，那 你得訂更高的目標去執行才行，包含正確性，執行效率之外，還有可維護性等等考量。
這篇就會跳出大家常看到的 “狹義” 的 TDD 做法。TDD 絕對不只是寫單元測試而已。你總是會有想像不到的狀況發生，我面對這問題時採取 兩個做法來解決:
- 把單元測試，從開發階段延伸到執行階段
- 自動化產生新的測試案例，讓機器隨機擴大測試案例的涵蓋範圍
(2) 可能抽象一點，我的想法是先創造一個 “可敬的對手“，再讓這個對手不斷隨機的產生測試案例來測試自己，同時由這個對手來告訴我做的對不對…
這情境有沒有很熟悉? 2016 的大事: AlphaGo 打敗世界冠軍，背後一個關鍵成功因素， 就是 AlphaGo 沒日沒夜的跟自己對練，累積的經驗。我們面對的問題不像圍棋這麼複雜 (10170 種組合)，實作起來很容易的， 唯一的障礙是你想不想做而已…。
-
不只是 TDD #1, 單元測試, 寫出高品質 code 的基本功夫
其實在這十幾年的工作期間，不時地都有人問我 coding 能力怎樣才能更上一層樓? 我的答案都是一樣的老生常談，就是 “要打好基礎”。 不過這實在很抽象啊! 最近有空就會上 LeetCode.com 來練習一下 coding 技巧，這其實是個練功的好方法， 你可以把 LeetCode 當成訓練 coding 能力的健身房。
我就拿這當作主題，分享一下我的作法，還有為什麼這樣做的道理吧! 其實用到的技巧都不算很新穎，但是卻很實用。幾個能提升 code 品質的 基本技巧 (尤其是 TDD，以及測試相關的環節) 若能徹底落實，你寫出來的 code 品質就會大幅提升。有心鑽研 coding 技巧的朋友們可以參考看看!
-
掃雷回憶錄 - Windows Container Network & Docker Compose
最近外務比較多，文章耽擱了一陣子… 在繼續寫 microservices 系列文章前，我先補一篇最近跟 windows container network 奮鬥的紀錄吧，踩過的地雷跟掃雷的經驗，就分享給有同樣困擾的朋友們…
對，我的感受就像 Frodo 在山洞碰到蜘蛛一樣… 被 network 困住了… T_T
-
網路搶票小幫手 - 遠端網站時鐘, WebServerClock v1.0
圖片來源: http://blog.mixflavor.com/2013/12/ticket.html很多線上訂票，或是限時搶購等等的應用，都會碰到一個困擾:
我的電腦時鐘跟網站的時鐘有誤差，我怎樣才能在網站的 00:00 整按下訂購的按鈕??
如果你有這種困擾，哈哈哈，那你看這篇就對了 :D
如果你以為這是自動搶票的機器人，那你可以關掉瀏覽器了 XD 這篇文章不會教你任何後門，用非正當手段搶到票，只是個輔助工具，讓你能更精確掌握 server 的時鐘，可以 更準確的在那關鍵的一秒按下訂購的按鈕而已..
-
微服務架構 #4, 如何強化微服務的安全性? API Token / JWT 的應用
其實本來就有打算寫這篇了，聊聊微服務架構下的安全機制該怎麼做? 微服務把整套系統切割成很多套獨立的服務，這些 獨立的服務就必須有機制去識別其他的服務是否是安全的? 有沒有很簡單的方法解決他? 這類越是基礎的問題，越需要 使用正確的架構及演算法。沒有理論的基礎，只會越搞越糟而已，這也是架構師最重要的職責。微服務是個很要求 架構正確的應用模式，想要導入微服務，千萬別忽略這部分。
很巧的是，兩個禮拜前受邀在線上讀書會分享這個主題， 我就把我過去土炮 API Token 的經驗拿來分享了，藉由簡單的 POC 過程，讓大家 了解 API Token 的原理跟應用。這套機制尤其適用在 microservices 架構下，因為這套機制靠著密碼學的原理，讓兩個 service 之間不需要直接溝通，就能完成驗證的過程。
這兩年 JWT (Json Web Token) 當紅，但是跟幾個人聊了聊，大都是停在 library 用的很熟練 的階段，但是問到如何應用? 有無變通的應用方式就剩一半了，再問下去問知不知道 JWT 背後怎麼運作的? 若要實作有無 辦法自己做一套? 就沒有了 XD
在開始之前，先聊一下我為何會想挑這個主題。從事軟體開發的行業，我一直覺的我這年代是很幸運的。比我還年長的， 大都經歷過寫組合語言，甚至是用卡片的年代。比我年輕的，才剛入行就要面對各種技術及 framework。比我年長的那一代， 過程大都在跟工具及技術奮鬥，能把心思花在解決 user 問題本身的比例不高。比我年輕的這一代，面臨太多 framework, 每個 framework 都是累積多少經驗跟智慧才堆積起來的結晶，能夠充分掌握怎麼 “使用” 就很了不起了，哪有時間等你 慢慢鑽研背後的原理?
所以很幸運的，我經歷過軟體還不是這麼複雜難搞的年代，也經歷過 Java, C#, JavaScript 這些可以 讓我專心思考架構之美的程式語言。我碰過很多問題，當年都還沒有妥善的 framework 可以直接套用，因此多了自己 土炮過一些基礎架構的 framework, 包含 ORM (在 SQL2000 年代，實作 object > xml > database，外加 xml index), Content Server (自己處理 URL, mapping URL to file system), MVC 架構 (對，用 asp.net webform + url rewrite, 實作 MVC 架構) 等等，當然也包括這次的主題: API Token。
