平常，Web 比較多人問關於「時間」的問題是「排程」，在課程被問到「Retry」機制，想想，真的托開發微信API的福，我還真的寫過那麼一小段 Retry 機制的程式碼。完整程式碼沒幾行，就說點小故事，拉點畫面行數吧。
當時我們與微信的測試主機是放在 Azure 東亞(香港)機房，不過因為大陸特別的網路關係，每每從下班之後就變得不穩定，我們某個 API 需要收到對方很明確的回應(成功-失敗)訊息才能往下進行。但好死不死，大陸在下班至午夜的國際網路相當不穩定，以至於我們的 API 常常在下班｜半夜被搞死，那段時間，半夜看著Slack的Log偵錯，更是家常便飯。找了好久，才確定那支 API 不是問題點。但問題點來了，對方不知是有意或無意 loss 非內陸的請求，我們知道，把正式機放到 China Azure 就能解決特別的網路問題(後來我們正式機放進去了，還是一堆雷 >__< )。有無更好的解法？想了很久，我決定寫一個 Retry 機制。
From:網路Microsoft Build 2017 已經落幕，但開發者的重點才要開始，數百堂的技術分享，要如何吸收。還好，Scott Hanselman 幫我整理好了 BUILD 2017 Conference Rollup for .NET Developers 。目前我只看了前二個，簡單做了點小筆記。如果你對 .NET Standard 2.0 / .NET Core 2.0 / ASP.NET Core 2.0 興趣，最少建議花點時間把這兩篇看完。
你是否有過邊看 MSDN Library 文件，不時浮現一個「x」字，心想：「這是在寫什麼鬼？」(台語)的疑問。
.NET 開發人員，你一定讀過 MSDN Library，早些年，MSDN Library 可說是 .NET 開發人員最好的朋友。但近年來，大量的機器翻譯，讓 MSDN Library 品質直線下降。其實，各位所提交的建議，原有一群義工人士，是"真"人工審核。後來不為何，義工人士不斷消失。小弟有幸加入這個消失中的義工團，就我而言，審核分專業和非專業，我不可能專精整個 MSDN Library 技術，在審核非專業內容時需要大量的時間。由於下班後時間有限，只能慢慢放低義工時間，最後，好像能瞭解，機器人造成大量的品質不良，要靠少數幾個人來改善是有難度的。
目前微軟新版文件庫叫 Microsoft Docs，這一個以開源為導向的文件庫，所有文件內容都開源開放在 Github 上，目前繁體中文化正在火熱進行中(但目前還有很大比例，你點擊後還是看到英文內容)，既然開源開放，那麼只要你有心，人人都能成為Microsoft Docs繁體中文貢獻者。目前有二種途徑可以參與：
