.NET / C# / OOP

不只是 TDD #2, 兩個版本自我驗證 + 執行期驗證

| |

LeetCode Logo

接續 上一篇,如果你以為要在本機解 LeetCode 的題目,只是把 test cases 改成 unit test 就結束的話,那 我就不需要寫這幾篇文章了。如果你的目標只擺在 “解題”,那的確看第一篇就夠了。如果這是老闆或是客戶給你的 “需求”,那 你得訂更高的目標去執行才行,包含正確性,執行效率之外,還有可維護性等等考量。

這篇就會跳出大家常看到的 “狹義” 的 TDD 做法。TDD 絕對不只是寫單元測試而已。你總是會有想像不到的狀況發生,我面對這問題時採取 兩個做法來解決:

  1. 把單元測試,從開發階段延伸到執行階段
  2. 自動化產生新的測試案例,讓機器隨機擴大測試案例的涵蓋範圍

(2) 可能抽象一點,我的想法是先創造一個 “可敬的對手“,再讓這個對手不斷隨機的產生測試案例來測試自己,同時由這個對手來告訴我做的對不對…

這情境有沒有很熟悉? 2016 的大事: AlphaGo 打敗世界冠軍,背後一個關鍵成功因素, 就是 AlphaGo 沒日沒夜的跟自己對練,累積的經驗。我們面對的問題不像圍棋這麼複雜 (10170 種組合),實作起來很容易的, 唯一的障礙是你想不想做而已…。

不只是 TDD #1, 單元測試, 寫出高品質 code 的基本功夫

| |

LeetCode Logo

其實在這十幾年的工作期間,不時地都有人問我 coding 能力怎樣才能更上一層樓? 我的答案都是一樣的老生常談,就是 “要打好基礎”。 不過這實在很抽象啊! 最近有空就會上 LeetCode.com 來練習一下 coding 技巧,這其實是個練功的好方法, 你可以把 LeetCode 當成訓練 coding 能力的健身房。

我就拿這當作主題,分享一下我的作法,還有為什麼這樣做的道理吧! 其實用到的技巧都不算很新穎,但是卻很實用。幾個能提升 code 品質的 基本技巧 (尤其是 TDD,以及測試相關的環節) 若能徹底落實,你寫出來的 code 品質就會大幅提升。有心鑽研 coding 技巧的朋友們可以參考看看!

掃雷回憶錄 - Windows Container Network & Docker Compose

| |

最近外務比較多,文章耽擱了一陣子… 在繼續寫 microservices 系列文章前,我先補一篇最近跟 windows container network 奮鬥的紀錄吧,踩過的地雷跟掃雷的經驗,就分享給有同樣困擾的朋友們…

network trouble

對,我的感受就像 Frodo 在山洞碰到蜘蛛一樣… 被 network 困住了… T_T

網路搶票小幫手 - 遠端網站時鐘, WebServerClock v1.0

| |

LOGO 圖片來源: http://blog.mixflavor.com/2013/12/ticket.html

很多線上訂票,或是限時搶購等等的應用,都會碰到一個困擾:

我的電腦時鐘跟網站的時鐘有誤差,我怎樣才能在網站的 00:00 整按下訂購的按鈕??

如果你有這種困擾,哈哈哈,那你看這篇就對了 :D

如果你以為這是自動搶票的機器人,那你可以關掉瀏覽器了 XD 這篇文章不會教你任何後門,用非正當手段搶到票,只是個輔助工具,讓你能更精確掌握 server 的時鐘,可以 更準確的在那關鍵的一秒按下訂購的按鈕而已..

微服務架構 #4, 如何強化微服務的安全性? API Token / JWT 的應用

| |

洛基的權杖 - Token

其實本來就有打算寫這篇了,聊聊微服務架構下的安全機制該怎麼做? 微服務把整套系統切割成很多套獨立的服務,這些 獨立的服務就必須有機制去識別其他的服務是否是安全的? 有沒有很簡單的方法解決他? 這類越是基礎的問題,越需要 使用正確的架構及演算法。沒有理論的基礎,只會越搞越糟而已,這也是架構師最重要的職責。微服務是個很要求 架構正確的應用模式,想要導入微服務,千萬別忽略這部分。

很巧的是,兩個禮拜前受邀在線上讀書會分享這個主題, 我就把我過去土炮 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。

API & SDK Design #4, API 上線前的準備 - Swagger + Azure API Apps

| |

寫到這邊,寫了那麼多 code, 你的 API 總該要上線了吧! 這篇就來探討一下,除了寫好 Code 之外,API 上線還要 注意什麼? API 這種東西不比一般的系統,API 的開發者是 developer, 使用者也是 developer,溝通可以用更有效率 (更宅? XD) 的方法,而不是只能靠傳統的文件~

這篇主題就擺在 API 開發完成後,要上線的考量。包括如何顧好 DX? 如何讓使用你 API 的 developer 有最好的 usability? 另外一個議題,就是如何挑選適合 hosting API service 的服務? 雲端時代就別再自己架設 server 了, 挑選個好的環境可以事倍功半,輕鬆容易就顧好 reliability.

這篇講的東西比較瑣碎,我分三個部分進行:
第一部分: 以需求為主,把我考量的思考過程花點篇幅寫出來。
第二部分: 介紹 swagger 這套 API Framework 以及 tool chain, 靠他來跟其他 developer 聰明的溝通。
第三部分: Hosting 環境的選擇,我會介紹 Azure 上的 API Apps,選用他可以替我們解決那些問題。

API & SDK Design #3, API 的向前相容機制

| |

上一篇意外的受歡迎,那麼續集就不富樫了,sample code 準備好就開始動工…

You shall not pass

這篇要講向前相容,不知為何我就直覺的聯想到甘道夫對抗炎魔的場景了 XDD,如果你的 API 沒做好這件事,那麼使用你服務的 APP 結果就會…

“You shall NOT pass!”

講完 API / SDK 之間當下的約定,接下來來講講 API 跟 SDK 之間的承諾吧! 當下的約定,會保證當下的 API 跟 SDK 可以搭配運作,然而承諾,則是保證當下的 API 能夠跟過去某個時間以後的所有版本 SDK 都能夠 搭配,這個很考驗架構師的功力了。一個不小心,過去某個不知名的版本就給你出問題了。負責開發維護 API 的人,該怎麼確保這種問題不會 發生?

暌違多年的獎盃 - Microsoft MVP Award Get!

| |

MVP Banner

其實拿到這獎項時,我比其他人還意外 XD, 每個人都只跟我說..

什麼!? 我以為你早就是 MVP 了…

哈哈,不論如何,直到 2016/10,我總算拿到這頭銜了 :D

API & SDK Design #2, 設計專屬的 SDK

| |

上一篇出來後,才發現,原來不是每個人都清楚 API 跟 SDK 的差別… 接下去之前我就花點篇幅來說明一下。 這個分不清楚的話實在有點囧啊,以前在本機上,這可能幾乎是一樣的東西,但是到了分散式的環境就不是那麼一回事..。

我這系列打算從 上一篇 介紹 client side 如何用 C# 呼叫 Http API 的技巧,延續到如何開發搭配的 SDK 設計, 以及 web api 在正式上線時必須考量的安全、效能、確保介面的相容性,可靠性等等設計。不過當你的 API 要正式 發布給其他人使用時,要面臨的就遠遠不止設計跟開發層面而已,還會有線上維運等問題,這邊我也會介紹一下 Azure 上的 API App Service, 還有 API Management

範例程式: 請從 GitHub 下載,本篇的內容對應到 dev-SDK 分支


(sorry, 這圖找不到原圖出處, 知道的請通知我,我再補上~)

API & SDK Design #1, 資料分頁的處理方式

| |


(圖片來源: http://hamidarebai.blogspot.tw/2016/09/building-restful-api-with-aspnet-core.html)

這篇算是 “微服務架構” 系列文章的外傳… 所以標題稍微改一下 XD!

上一篇講到 “重構“,不斷的進行重構,直到能夠將模組切割為服務為止。 這篇就接續這個話題,展示一下服務化之後的 API / SDK / APP 之間的關係,以及設計上要顧慮到的細節。我用最常碰到的資料查詢 API 的分頁機制 當作案例來說明這些觀念。資料分頁是個很煩人的東西,不論是在 UI 或是在 API 層面上都是。尤其是 client 端要把 分頁後的資料重新組合起來,就會有越來越多的 義大利麵風格 的 dirty code 被加進來..

這時 SDK 扮演很重要的角色,善用 C# 的 yield return 就能很漂亮的解決這問題。這篇就來示範幾個 API / SDK 的實作技巧 (C#),之後微服務講到這部份時,可以再回頭參考這篇的內容。