Docker Image 我們可以從 DockerHub 中找到 Microsoft 官方的 Images 連結入口。以這次要執行 ASP.NET 程式來說我們可以在這裡找到可以用的 Images。基本上上面都會有簡易的教學要怎麼用，不過琳瑯滿目的 Images 裡面還是有目前相對比較推薦的，像是 Alpine 為基底的 Images 應該是目前佔用空間最小的 Images，當然以此為代價，裡面安裝的工具真的是再基本不過。 ASP.NET Core Install 選擇 .NET Core SDK 來安裝，官方載點。目前版本 3.1 是 LTS 所以我們就選擇這個來裝吧(記得要選 Build Apps，也就是 SDK 來裝，不要選 runtime)。 一旦安裝完畢在 CMD/Power Shell 中就可以使用 dotnet 來操作 dotnet core SDK 了。 可以執行 dotnet --list-sdks 來看看自己目前安裝了哪些 SDK。 我們可以使用 CLI 提供的 new 指令搭配 template 來生成預設的範本，這邊就先使用 asp.net core mvc 當作示範。若需要詳細的 template 種類的話，有官方文件可參考，或可以執行 dotnet new --help 指令來看 new 指令可以有哪些操作，而用 dotnet new --list 來取得目前 SDK 所提供的所有 Template，輸出大致會長以下這樣： ...

前言 三年前寫了一篇跟 Serilog 有關的極致入門文章後就把這個主題閒置到現在，他的很多特色不要說點到為止，而是根本沒提到，但這樣對於這樣一個好用的 Library 來說實在太糟蹋，所以打算重啟這個主題。因為當時就有位這個主題開個 repo 所以我們也就不要浪費網路的空間了，直接回收利用吧(還順便把 solution 檔給升級了)～ source code 這次將會針對設定做一點初步的介紹，雖然近期事情開始漸漸變多，但看看能抽出多少時間來把相關的內容介紹一下，也許有機會變成一個小的系列 (也許啦 XD)。 內文 這邊會展示在進行 Serilog 設置時可以採行什麼樣的寫法在 Production 環境下可以有比較好的閱讀性與維護性，還有我們可以針對需要寫 Log 的情境給予一些過濾條件，讓這個系統更有彈性，最後我們整合目前官方網站上有提供的一些 Sink 來稍稍展示 Serilog 搭配上 Sink 之後可以展現的可能性。 在先前的文章之中我們直接針對 Serilog 的 LoggerConfiguration 類別來設定，但若是需要設定的條件眾多那麼光是這個設定就會讓程式看起來很複雜。這邊會使用一個小技巧來讓設定看起來比較簡潔一點。 首先建立一個給 Serilog 做初始的一個類別，並使用最簡單的設定方式來為 Logger 做設定。 ps. 這邊的 LogFactory 類別只是作範例簡單使用，重點在於 InitMyLogger 方法內的寫法 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 public class LogFactory { public static void InitMyLogger() { Log.Logger = new LoggerConfiguration() .WriteTo.NLog( Serilog.Events.LogEventLevel.Error, "[AppId:{AppId}]{Message:lj}{NewLine}{Exception}") .WriteTo.Console( restrictedToMinimumLevel: Serilog.Events.LogEventLevel.Information, outputTemplate: "{Timestamp:HH:mm:ss} [AppId:{AppId} {Level:u3}] {Message:lj}{NewLine}{Exception}") .WriteTo.Logger(configer => { configer.Filter .ByIncludingOnly(Matching.FromSource<BusinessLogic>()) .WriteTo.Console( Serilog.Events.LogEventLevel.Warning, "{Timestamp:HH:mm:ss} [AppId:{AppId2}{AppId} {Level:u3}]$ {Message:lj}{NewLine}{Exception}"); }).CreateLogger(); } } 這邊不難看出目前雖然只是簡單的三樣設定就已將讓這個設定開始顯得有些複雜了。若這是一段需要被維護的程式碼不難想像應該會是個痛苦的開始。 ...

Polly .NET foundation 的 Polly 專案是為了解決暫時性錯誤處理（transient-fault-handling）的一個函式庫，裡面提供了處理眾多相關錯誤處理的函式呼叫。 目前的應用程式越來越少是自己獨立作業就把一個 request 或是一項作業給處理完成的，通常都會跟內部或是外部系統合作，而這個部份通常為了解相依關係，會定義好介面常見的就是定義 Api 他的傳入與回傳值，尤其是在這個微服務觀念盛行的時期，這個作法尤其常見。 但是像這種鬆耦合的系統架構，雖然美其名是開發/佈署不會互相影響彼此，但單一服務獨活於系統中又顯的很雞肋，偏偏依賴 Api 的方式其實並不可靠，網路基本上就不是建立在可靠的傳輸之上，所以連線失敗/服務暫時下線可以說是需要假定會隨時發生的事情。 不過很多時候這種連線失敗很可能只是一個突波，下一個 request 可能就成功了，而 Polly 就像是把這些繁瑣設定與工作包起來方便重複使用的函式庫。 其實這個函式庫，跟混亂工程有著密不可分的關係，不過這個部份主題很大，這篇就不提了，只列出一些可以供參考的資料。 Demo source code GitHub: link How to install Polly 若你覺得安裝 Package 就是一行 nuget 指令就可以，那其實也沒錯，不過你會發現 Polly 這個套件相依的 packages 預設實在多的驚人。 Install-Package Polly -Version 7.1.1 真的這樣幹的話你會發現，用預設的版本安裝相依套件的話，它會幫你安裝超多 System 相關的 Library, 主要原因就是 NETStandard.Library 預設安裝的版本實在太低，導致這些東西會一起裝進去，若想要避免這種情況，的話就需要先把相依的套件先升級。 Install Microsoft.NETCore.Platforms 這是為了 NETStandard 2.x 要安裝的 預設版本號是需要大於 1.1.0 不過這邊可以先升到頂 Install NETStandard.Library 這邊就直接裝到 2.x 以上的版本，Polly 目前的版本 (7.1.1) 預設最低版號要求到 1.6.1，但若真的只裝到 1.6.1 的話就需要安裝一堆 System 相關的套件，所以不太推薦。 ...

寫了 Unit Test 然後呢 一般來說談到要讓程式碼的品質變好，多數人想到的除了規範團隊的 Coding Style 、Code Review 之外，就屬撰寫 Unit test 來確保 production code 可以確實符合商業需求。 但是這邊就有一個問題產生了，究竟我要寫多少單元測試才夠呢？我的覆蓋率已經 100% 了，是否代表萬無一失了？但 100% 根本神話，而且這樣要寫超多單元測試，寫測試的時間都可以拿來做下一個需求了。。。 上述的問題在尚未引入 Mutation test 之前看起來是真的挺無解，也容易陷入覆蓋率的迷思之中。 Mutation Test 是什麼 Mutation test 說實話不是個新概念，他的歷史應該可以往回推到 1978 年的這篇論文。他的基本概念就是藉由改變 production code 來檢驗你的單元測試能否抓到這些改變，若能夠抓到就代表你的測試能夠確保目前的程式碼夠強健，能夠確保在商業邏輯改變後你可以知道什麼東西會跟以前不同。反之，若改變 production code 後單元測試卻沒有反應出來，就代表需要再補強單元測試。 會用到的必要 Packages junit official site org.pitest official site junit 目前第五版也是可以使用 PIT，不過作法比較不同，需要引用不同的 Packages，可以參考這個來試試。 Demo Code source code：github repo 範例程式 以下這個是一個迴文函式，目的是用來判斷一個傳入的字串是否屬於迴文。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 public class Palindrome { public boolean isPalindrome(String inputString) { if (inputString.length() == 0) { return true; } else { char firstChar = inputString.charAt(0); char lastChar = inputString.charAt(inputString.length() - 1); String mid = ""; if (inputString.length() > 1){ mid = inputString.substring(1, inputString.length() - 1); } return (firstChar == lastChar) && isPalindrome(mid); } } } 以下則是這個函式的測試程式 ...

Why Jenkins Pipeline 談到 CI/CD 最為人所知，學習資源也最豐富的莫過於老古董 Jenkins 了吧。 Jenkins 自身有相當多的 plugin 可供選擇，讓建制的流程可以非常客製化，而且自從它推出了 pipeline 之後，讓這個調整跟變化顯的更加容易，至少對 RD 來講是這樣啦，看起來更像是 Code as infrastructure。 雖然 Jenkins pipeline 提供了兩種不同的語法樣式來實做，聲明式語法（declarative syntax）、腳本式語法（scripted syntax）。 這兩種語法基本上可以適用在每個情境下，聲明式能做到的腳本式也能做到，反之亦然。所以要用那一個就真的是看個人喜好跟習慣了。 Declarative syntax聲明式語法 Scripted syntax腳本式語法 Pros:更加貼近傳統的Web表單形式，轉換上較容易可以通過Blue Ocean自動生成更有好的錯誤識別，語法檢查Cons:較難勝認複雜的建制流程較難實現自定義程式碼 Pros:對於較複雜的建制流程支援程度比較好更靈活的自定義程式碼操作較少的規範要求Cons:語法檢查受限於Groovy語言與環境與傳統Web表單形式差很大，轉換上較難 Management Plugin DotNet Solution Need 若要建制 .NET Solution 的話那 CI 機器上肯定要安裝 MSBuild (2015, 2019)，再用 Web Platform Intaller 安裝 Web Deploy，當然還要有 .NET Framework (4.8, 4.6.2, 3.5 的話需要在 Windows 10/8 內啟用即可) 安裝好，基本上這樣對於一個 .NET Solution 的建制環境來說就大抵可用了。 ...

前言 在開發時應該很多時候都需要跟第三方合作，大多數的時候都是用 API 的方式串接，所以都會先談好介接的格式，像是傳入的資料要用 JSON 或是 XML 等， Http Method 要用 GET, POST, PUT, DELETE, PATCH ，但是當這些規格都談完的時候要進入開發的時候你就會需要一個 Dummy API 可以回應你一個罐頭訊息讓你可以在開發時不會因為對方還沒好就讓你的開發無法進行。 不過，若你手邊有 POSTMAN 的話這個需求可以很輕易的做到。 前製準備 安裝 POSTMAN New 一個 Collection New 一個 request 設定罐頭訊息內容 在設定罐頭訊息之前，會需要先有一個 request，所以點擊 request 之後，就看到畫面的右上方的 Examples 並點擊下去。 點擊後就可以進入編輯。底下有一個很大的輸入框叫 Example Response，它可以輸入 Body, Header, Status Body Heaser Status 回應的內容，這邊將會是去打 Mock Api 時的回應內容 這邊就是打 Mock Api 時他的回應 Header 可以不予填寫 就是回應時的Http Status Code 像是 500 Internal Server Error 或是 200 OK, Response Status Codes 可以參考這裡 ...

前言 系統槽空間不足的問題，坦白說在我拿到公司的電腦後就一直在捆擾我，尤其是這部電腦的前主人還灌了些很多開發工具之下顯的更加嚴重。 最一開始 一開始的時候我幾乎是每天都打開 Powershell cleanmgr /lowdisk 來清出空間，很多時候只要當天有 Windows update，都有一些些空間可以謄出來，不過依然免不了會把既有空間逐漸佔去的問題，說到底這只是個緩兵之計。所以後來就開始打開 應用程式與功能 開始砍應用程式。 幫你找出最肥的是誰 但要砍程式，也要看一下是不是真的肥，不然砍了幫助也不大，因此有一款工具可以很好的幫我辨識誰才是戰犯的好工具。 windirstat 不得不說這真的是 Windows 平台上針對此需求不可多得的好工具，不但掃的快還有圖形化的顯示與排序，可以快速看出到底你可以砍的檔案中誰才是最該死的那一個。 mklink大顯神威 不管怎麼砍應用也是會遇到砍不了的時候，這個時候就很需要將一些預設放在系統槽，但又沒有介面讓你更改的檔案放在系統槽以外的地方。不要小看這部份，若有用 windirstate 掃的話會發現，你可以騰出的空間會有數十 GB 之多。 官方文件： Microsoft Docs 這邊我們需要用到的參數其實就是「/J」，藉由產生 Junction Directory 來將一些預設放在系統槽的檔案搬移出去。 最一開始被我盯上的就是 C:\ProgramData\Package Cache 這個資料夾，畢竟當初一掃就掃出了快 10GB 的空間！ 首先先將 X 槽建立一個資料夾 “DirJunction” 方便將未來使用這個方式的資料夾統一放在一起 再來將 C:\ProgramData\Package Cache 的 Package Cahce 資歷夾直接剪去 X 槽的 “DirJunction” 資料夾底下 使用 Admin 權限開啟 cmd 輸入 mklink /J "C:\ProgramData\Package Cache" "X:\DirJunction\ProgramData\Package Cache" 打完收工 你可以藉由這個方法，不斷把空間清出來 結語 說實話，在用 mklink 之前每天使用 cleanmgr 實在痛苦成效又不彰，在改用 mklink 之後確實好了很多，唯一的缺點大概就是未來 Windows 做大型更新時要先確認一下連結是否還是 Work 的狀態 ...

前言： 目前想到要測試 Web Service 的首選或是第一個印入腦簾的我想應該就非 POSTMAN 莫屬了。不過目前大多測試的都是 Restful api 或是資料交換格式用 JSON ，要見到這以外的方式通常會比較少，或是要與舊系統介接時才會遇到，而剛好舊系統通常在做 Web Service 時都是選用 SOAP 做資料交換的協議，因此如何讓 POSTMAN 這個新工具跟老骨頭(SOAP)做搭配就是這篇主要要解決的問題。 前置準備 範例網站 POSTMAN SoapUI 使用 SoapUI 組 message 使用 SoapUI 來幫忙組 message 的話會讓建立 message 的過程輕鬆很多。 首先開啟 SoapUI 後在 將 WSDL 的位置填入，並給一個好識別的名稱，記得把 Create Request 打勾 建立後應該會長這樣 右鍵產生一個新的 request SoapUI 會協助產生一個 message 樣板，複製拿去用即可 這個產生出來的就是去打這個 Web Service 的 Method1 方法，它會產生一個樣板，只要把這個樣板複製到 POSTMAN 的 request body 就好，格式就選 raw (text/xml)， http method 選擇 POST，比較需要注意的就是 header 要帶上 SOAPAction ，而他的值就要看一開始去打 WSDL 時該值為何。 ...

前言 當你的專案要升級套件時你是怎麼做的呢？打開你的 Visual Studio 然後再選擇 Nuget Package Manager 然後在 console 中去執行指令更新嗎？不論版本是否只是 patch 類型的微升級還是跳一個 major 的大改版都這樣做嗎？ 安裝 在安裝之前這個工具會需要你先安裝 .NET Core 2.1 或更新的版本 若還沒有安裝的話可以先到這裡把所需要的環境先裝好。 安裝的指令相當簡單：dotnet tool install nukeeper --global，而更新的 使用檢查模式 藉由開啟這麼模式可以先讓你看看有哪些套件是可以進行升級 cd {your_repo_dir} nukeeper inspect 或是 nukeeper inspect {your_repo_dir} 從這邊可以看出它不只可以幫你查出有哪些套件可以進行升級，還可以看出到底距離這些版本你 delay 了多久。 直接更新專案的套件 cd {your_repo_dir} nukeeper update 同樣，另一種方式也是類似的 nukeeper update {your_repo_dir} 當然，若你覺得某一些套件更動實在影響太大，你可以用 exclude 參數來跳過這些套件 nukeeper update {your_repo_dir} --exclude {package_name} 而這個參數是可以接受簡單的 regex 判斷的，像是這樣用： nukeeper update {your_repo_dir} --exclude ^AWSSDK. 上述的更新就可以將 AWSSDK. 開頭的套件給排除在外，就不用擔心一口氣將太多第三方的套件更新，讓測試範圍暴增。 ...

前言： 在前一篇的 Anti-Pattern 中我們介紹了最經典的反模式：Control Freak 。而在這篇我們要介紹的另外一個常見的反模式可以說是他的進化版本，尤其是這個模式是知名的架構師 Martin Fowler 提出的。不過在數年後有人挑戰了這個想法，該文章的討論串比正文還要長，但思辨的過程還是值得一看。 常見類型 Anti-pattern Description Control Freak 依賴反轉（Inversion of Control）的對立面，直接控制實體 Service Locator 使用一個內隱服務提供依賴給呼叫端 Ambient Context 使用靜態存取子，提供單一的依賴 Constrained Construction 讓建構子有一個特定的方法簽章 Service Locator 定義 是一種軟體開發中的設計模式，通過一個集中註冊表（通常會是 Singleton）來處理請求並返回處理特定任務所需的必要訊息。最常見的實做方式通常就是利用 Static Factory 來實做這個註冊表。而系統中可以在系統進入點以外的地方呼叫這個註冊表的方法取得指定的實做。 表準案例 1 2 3 4 5 6 7 8 9 10 11 12 13 14 public class HomeController : Controller { public HomeController() { } public ViewResult Index() { IProductService service = Locator.GetService<IProductService>(); var products = service.GetProducts(); return this.View(products); } } 1 2 3 4 5 6 7 8 9 10 11 public class ProductService : IProductService { private readonly IProductRepository repository; public ProductService() { this.repository = Locator.GetService<IProductRepository>(); } public IEnumerable<Product> GetProducts() { return this.repository.GetProducts(); } } 這邊可以看到當要使用 IProductService 時，就呼叫註冊表的方法來取得實做，但這個依賴關係因為不是在建構時給予因此從外部會不容易知道他們兩者之間會有這樣的關係存在。另外這個作法同樣也會遇到 Static Factory 會遇到的問題，只是 Service Locator 將原本呼叫與依賴關係建立的那一層做了一個包裝。原本的 Static Factory 會與實做相同介面的類別緊緊的綁在一個 Factory 類別中，而包裝起來之後變成所有類型的依賴與實做會都綁在 Service Locator 這個類別裡，它變得與更多依賴有關。同時，在使用上每個需要取得依賴的地方都需要能存取 Service Locator 。 ...

前言 現在很多系統在撰寫時都會使用到一些常見 DI Container 尤其在使用一些編譯式語言(ex. .Net, Java)時(Autofac for .Net, Unity for .Net, guice for Java, di-ninja for NodeJS 等族繁不及備載…)。不過系統即使用上這些 container 只要使用方式不正確，還是可以寫出強耦合性的程式，因此這邊要來介紹一些常見的 Anti-patterns，避免自己寫出高耦合性的程式。 這一篇基本上是 Dependency Injection in .Net 這本書第二版在第五章的心得 (第二版叫 Dependency Injection Principles, Practices, and Patterns)。雖然他連簡體中文的翻譯都還沒有出來，不過還是相當推薦買來看看。 常見類型 Anti-pattern Description Control Freak 依賴反轉（Inversion of Control）的對立面，直接控制實體 Service Locator 使用一個內隱服務提供依賴給呼叫端 Ambient Context 使用靜態存取子，提供單一的依賴 Constrained Construction 讓建構子有一個特定的方法簽章 Control Freak 定義 就是直接了當的把你需要的實體給產生出來，這個與依賴反轉的原則剛好相違背。 案例 標準案例 1 2 3 4 5 6 7 8 9 public string GetContent(string fileName) { // 這個直接把要使用的實體寫在呼叫時 var saveService = new FileSaveService(); var fileContent = saveService.Read($"{fileName}.txt"); return fileContent; } 基本上這個寫法比較容易出現在所謂的 legacy code 裡，近年來 program to an interface 的意識抬頭，工程師應該都不會這樣寫了。 ...

前言 這篇沒有技術成份，但是卻是很實用。尤其當你會使用到很多不同環境（測試/正式）的資料庫時，這個小技巧可以幫你快速分辨目前正在操作那一個環境的資料庫。 起步走 Step 1 開啟 Object Explore 視窗 按下連線 Step 2 點擊 Options 按鈕，進入細部設定頁籤 選擇喜歡的顏色後按下連線 Step 3 開啟查詢就可以看到狀態欄的顏色改變了 Take away 連線時選擇 Options 就可以選擇連線後狀態欄的顏色 建議依據環境來使用不同的顏色 通常正式環境會建議使用紅色，提醒自己要小心 開發環境通常會選擇使用藍色或是綠色等安全的顏色 這個小技巧說實話，會在你精神不濟時發揮很大的幫助，也可以幫助你在操作正式資料時集中精神。

前言 會來參加這場活動其實是被同事推坑，一開始其實還在猶豫，不過實際來參加之後，收穫倒是出乎預料的多。這次的活動共分三軌並行，所以我就針對我所參與的三場來做心得分享。 持續測試：如果我可以重來一次 我們都知道測試很重要，因此現在有越多公司/團隊導入測試。持續整合測試更能讓團隊知道目前產品整體的狀態，而自動測試會讓測試的執行成本降低，進而讓團隊更願意頻繁的測試產品。但當市面上大神的那些導入方法在公司環境裡不 Work 時，要怎麼辦呢？ 對於一個產品重要的是要拿到回饋改進產品，不論是交與測試團隊，或是放上正式環境讓使用者使用，都是一種方式，而持續測試就是一種安全又快速可以拿到回饋的方式。 但是既有的程式(系統)越是龐大複雜，regression test 的工就越大，執行起來越耗時，也會讓團隊對於執行測試感到不耐。甚至到後來會因為測試耗時，導致新功能上正式的時間被影響到。 將測試的範圍往產品設計，開發與上線這兩端推 在產品設計階段： 使用實例化規格，將需求轉化為具體的 Case 這可以幫助團隊對於需求的理解更好達成一致性。 減少溝通成本 在開發階段： 使用單元測試與靜態分析 單元測試是所有測試的類型中，執行負擔最小的一種 能提供最基本的品質保證 在測試階段： 使用 E2E test 模擬使用者在使用產品時一般的操作流程 確保整個流程是符合預期的行為 測試一整個 user story 在上線階段： 使用即時監控 讓使用者協助做 corner case 的測試 畢竟 QA 也只能代表少部份的使用者 藉由各項觀測值來觀察使用者的使用情況 Git Branch Pattern Trunk base development： 頻繁交付到主線 Feature toggle 需要每個 commit 都足夠乾淨，讓 release 時可以方便將 commit 撿入 release branch 中 需要有較為完整的測試在 trunk branch，確保目前是可以發布的狀態 從工程角度，引領團隊持續挖掘產品風險 瞭解商業邏輯中的重點數據 這些數據會是重點監控指標 Prometheus + Grafana 資料的呈現與數據的監控 Prometheus ...

前言 這幾年有越來越多開發者選擇將 blog 放在以下服務中 github page gitlab page Bitbucket page 一方面是這些服務支援使用 Markdown 寫作，另一方面是可以直接增加 side project 的曝光程度。 不過因為 github 服務較廣為人知，所以一般來說教學文章與大眾選擇都是 github 居多，不過在多方比較後，發現其實架設在 gitlab 上面其實比 github 簡單，而且 blog 的原始檔案可以使用 private repo 的形式存放，不用擔心會被人 fork 或是 dowload 一份，瞬間將整份內容都搬走，另外就是 gitlab 與 CI/CD 整合得很好，可以在 blog 中直接將部屬設定好，過幾分鐘後線上就會更新。 內文 工具 Hugo version 0.51 Visual Studio Code Better TOML Markdown All in One 在撰寫工具的使用上面，有很多可供選擇，像是老牌的 Jekyll，不過這次選用相對年輕很多的 Hugo，一方面是夠年輕，另外一面是安裝與使用夠簡單。 Hugo 在官方網站上面有一篇很簡單的安裝教學，連結。 若用 Mac 的話使用 brew 安裝無難度 brew install hugo 就結束了，若是 windows 的話其實可以考慮使用 binary 檔案，抓下來後其.exe檔案路徑存入環境變數中，就可以在命令列中使用，也是相當無腦的安裝方式。 ...

Step1: Install 本機環境：Windows10 ========注意！ 2019/10/28 updated======== 在 Windows 環境中使用 pip 安裝 sam ，在執行時會發生 「NpipeHTTPAdapter 沒有定義」的錯誤 ref。 解決方式是使用 msi 方式安裝 ref。 ================================== 安裝 Docker for windows 這是Option選項，要用 sam 做本機測試的話需要安裝 docker， sam 會用近似 AWS Lambda 的執行環境去執行你的程式。 安裝 python 3.6+ download python –version 確認將 python 的執行檔加入環境變數 PATH 安裝 pip (或是說確認 pip，python 3 >= 3.4, python 2 >= 2.7.9 預設 python 裝好就會有) 1 pip3 --version 安裝 aws-sam-cli 1 pip install --user aws-sam-cli 確認 aws 安裝完成 1 aws --version 當前的版本輸出為：aws-cli/1.16.263 Python/3.7.4 Windows/10 botocore/1.12.253 ...