前一篇「使用 Wolverine 實作生產者-消費者模式（Producer-Consumer Pattern）」介紹了將原本使用 Channels + BackgroundService 的生產者-消費者模式改用 Wolverine  來實作。

就以現實的問題來看，如果服務是相當頻繁地被使用時，如果 MessageCreatedEventHandler 消費者的處理速度有所延遲，那麼 Channels 裡就會堆積大量的 MessageCreatedEvent 事件，一旦服務出現問題而重新啟動或是有版本更新而需要重新部署，那麼佇列在 Channels 裡的事件就會消失不見了，這可是不得了的事情。所以這篇就來用 WolverineFx.RabbitMQ，生產者將事件發送到 RabbitMQ 裡，然後消費者再去接收存放在 RabbitMQ 裡的訊息，如此的改變就是為了避免因為服務重新啟動而讓佇列在 Channels 裡的事件消失不見。

之前寫了一篇「使用 Channels 與 BackgroundService 實作生產者-消費者模式（Producer-Consumer Pattern）」是使用 Channels 與 BackgroundService 來實作，而這一次就來改用 Wolverine 這個套件來試試看。

有關 Wolverine 這個套件我也看了好久，一直想拿來試試看，會想要用這個套件，主要是它是一個輕量化的工具，適合用於整合訊息佇列、事件驅動設計和後台任務處理。

而且也因為適合用於整合訊息佇列、事件驅動設計，所以支援了許多第三方服務，例如：RabbitMQ, Kafaka, MQTT, AzureServiceBux, AmazonSqs 等，所以打算之後也繼續玩玩 Wolverine。

前幾個禮拜 ChatGPT 推出了 Advanced Voice Mode，讓我們可以透過更自然的對話方式來跟 ChatGPT 詢問問題，而後續也推出了對應的 Readtime Api ，可以讓我們透過程式來建置出屬於自己的 Realtime 的應用程式，而在 Azure 上面當然也提供了這個模型，一樣來測試看看吧。

從 .NET Framework  開發 WebApi 服務時就開始使用 Swagger UI，直到現在都已經是直接在預設的 ASP.NET Core WebApi 專案範本裡就包含在內。

但是…  我一直都覺得 Swagger UI 做為 API 文件工具並不是很好閱讀，要查看輸入參數或輸出資料格式內容都不是那麼方便，我想大家或多或少應該都有這樣的感覺，所以我都還會在專案裡安裝 ReDoc 套件，ReDoc 做為 API 文件工具來檢視 API 的輸出入各種資訊都相當直觀且清楚，比 Swagger UI 更好閱讀，但是 ReDoc 只是個單純的 API 文件檢視工具，無法在 ReDoc 裡測試執行 API。

所以之前看到 Scalar 這個新的 API 文件檢視工具時就讓我眼睛一亮，有著如同 ReDoc 一般的 UI 外觀，可以方便且直覺地查看 API Endpoints 的資訊，而且還可以直接在上面測試執行 API，所以就趕緊來試試看。

在偵錯一些資料時，實體型別裡的資料有時是繼承而來

而物件裡的方法，也常常會使用到基底的方法或是參數

雖然這些資料的出發點是不希望開發者去在意的

若是可以拿到這些資料，在偵錯上有時反而可以幫上一些忙

過去的工作專案為了要加快 Request 的回應速度，所以就想方設法地去做了很多的調整…

例如一個訊息建立後要做很多的事情，像是要許多相關資料 Table 的資料異動、透過 RabbitMQ 去發送 message 通知其他 Client、快取資料的更新等等等

這麼多的處理如果都是在一個 Request 裡全部處理完成後才回傳 Response 結果，因為每個處理都會花費一些時間，全部累積起來就相當可觀，於是就會想到是不是要往平行處理或多執行緒的方式來解決，但是在繁忙的網站服務去使用這些解決方案又有很多風險，程式沒有寫好的話就會出現嚴重錯誤。

所以就想到用發送事件的方式，當訊息建立完成後，就發送一個事件到一個佇列裡，然後有一個 BackgroundService 去專門接收訊息建立完成事件，當收到事件後就開始一連串的處理，這麼一來 Action 方法的回應時間就能夠加快一些。

上一篇「背景常駐執行計時工作 - 使用 BackgroundService 與 PeriodicTimer」介紹了使用 BackgroundService 與 PeriodicTimer 實作計時的工作處理。

但如果有時候一些工作處理並不是每幾秒鐘或每幾分鐘、每幾個小時這樣的週期行為時，使用 PeriodicTimer 就無法滿足這樣的需求，而在使用 Hangfire 建立 Recurring Job 時都會使用到 Cron Expression 去定義工作的執行週期，而就有看到這麼一個 NuGet 套件就有提供這樣的功能，所以就拿來試試看。

背景常駐執行計時工作的實作方式有很多種，而我習慣在 ASP.NET Coe Web Application 使用 BackgroundService 然後搭配 Task.Delay 的方式來完成計時執行工作的處理，而在 .NET 6 提供了 PeriodicTimer 後就可以更方便的處理計時工作，這篇就來認識執行計時工作的幾種實作方式。

公司內部大多都有建置內部使用的一些工具套件，但僅供內部使用

這邊會程現在 docker 盛行的年代，如何使用 ci/cd 自動建置，搭配自動拉取內部工具套件建置

相信大家對 JWT 都很熟悉了，不熟的可以到這裡複習一下Hashicorp Vault Server 支援 JWT Authentication Method，話不多說，客倌上碼。

現在生成式 AI 發展越來越快，也越來越多開發人員使用來產生程式碼的建議，但是對於企業來說除了考慮程式碼會不會被拿出去訓練之外的問題，就是要確保產生的程式碼是否有使用到公開的程式碼，有使用的話又是哪種授權，避免一不小心就產生的著作權的問題，本文就來介紹使用 GitHub Copilot 的時候該如何判斷，以及透過 Azure AI Content Safety 來判斷非 GitHub Copilot 產生的程式碼如何判斷是否有用到公開程式碼。

AppRole Authentication Method 也是 Hashicorp Vault Server 所提供的驗證(Authentication) 之一，搭配 Policy 授權(Authorization)，存取機敏性資料，使用上也是相當的簡單。

前一篇文章「練習題 - 設計模式 - 責任鍊模式 (職責鍊模式) Chain of Responsibility Pattern」是不藉助任何套件的方式下完成實作，但我總會想應該是有人會做個 NuGet 套件來讓開發者可以直接套用就能夠完成責任鍊模式的實作，找了一輪後發現到還蠻少的，雖然少但也還是有一些，不過有的是已經很久沒有更新或是用的人不多，而有些是不適合真的拿來使用，有這種情況大概是責任鍊模式的實作其實並不複雜。

不過還是有找到一個還可以的套件，所以就拿來用在之前的練習題裡，看看是不是適合。

前面提到的案例都是使用 root token 進行登入。登入後，通過身分驗證 (Authentication)，接著依照定義的 ACL Policy 和 Role 來決定誰能訪問哪些資源，這個過程稱為授權 (Authorization)。由於 root token 具有最高權限，理論上應避免壤非管理人員使用它。現在，我們來看看如何使用 HashiCorp Vault Server 的 GitHub Authentication Method 訪問機敏性資源吧！

Dynamic Credentials 每一次產生出來的憑證，都是變動且有時效性的，這跟固定的 Key/Value，有很大的不一樣，用這樣的機制就可以保護真正的資訊，更有效的隱藏機敏性資料
 

工作專案裡並不會去刻意地去使用設計模式，不過在很多時候為了想要有更好的實作，又或者是覺得當下的程式一定會有更好的解法，就會去找目前情境所適合使用的設計模式來改寫。

有的時後會看到誤用了不適合的設計模式所實作的程式，明明應該是用行為類的設計模式來做，卻用了結構類的設計模式來做，雖然最後的執行結果是有符合預期，但怎麼看就怎麼怪，所以設計模式還是要好好地認識認識，於是這次就來練習練習責任鍊模式。

開發者不應該把機敏性資料，用明碼的方式存放在電腦，HashiCorp Vault 是一套基於身份的私鑰和加密管理系統，Hashicorp Vault 是一個安全管理工具，專門用於管理機敏性資料，例如：密碼、API 密鑰和其他機密訊息，下圖出自 Introduction | Vault | HashiCorp Developer

原本我本來想要自幹一套 Secret Manager / Config Manage，因為有 Vault 我省去了自幹的時間，這裡，我將嘗試學習使用 C# VaultSharp 訪問 Hashicorp Vault

甚麼是 ODBC，維基百科這樣說

"ODBC（Open Database Connectivity，開放資料庫互連）提供了一種標準的 API（ 應用程式編程介面）方法來訪問資料庫管理系統（DBMS）。ODBC 的運用形態通常是由應用程式經過一個稱之為 ODBC 管理器的工具，建立一個 DSN，指明需要呼叫的 ODBC 驅動程式，從而訪問對應的資料庫。"

簡單來說，可以透過 ODBC 來簡化連線字串的管理，最近工作上，需要用到它，趕緊趁無風無雨的颱風天，重新學習一下。

.NET Core 原生的組態設定是使用 appsettings.json 來讀取組態設定，要先產生出各個環境的組態設定 appsettings.Development.json、appsettings.Staging.json、appsettings.Production.json，再透過環境變數+Build，取代掉原本的值，要佈署的環境越多檔案就越多，每次的改動設定都要很小心，生怕一個不注意就弄壞了，我想要讓組態管理的行為變簡單一些…

前面分享的兩篇文章，分別介紹了 Microsoft.Bcl.TimeProvider 和 AutoFixture 的 AutoData

• 使用 Microsoft.Bcl.TimeProvider 取代 DateTime 吧
• 使用 AutoFixture.AutoData 來改寫以前的的測試程式碼

另外在寫測試時，可以使用 FakeTimeProvider 去做抽換，就可以設定時區、時間來完成測試情境的執行。

那麼是不是也可以用 AutoData 的特性，讓我們在寫測試的時候可以省下建立 FakeTimeProvider 的步驟呢？當然可以，不過需要先瞭解該怎麼做、可以怎麼做以及應該如何做。

經過好友 張少齊 的推薦得知了這一套 Mock Server，趁著無風無雨的颱風假把玩一下這一套工具，跟著官方文件一路啃到底。

這是一篇借花獻佛、拾人牙慧的文章，之前有寫過這麼一篇文章「單元測試使用 AutoFixture.AutoNSubstitute」

當時是使用了 AutoFixture.AutoNSubsititute 來減少測試類別裡相依類別的 Stub  建立步驟，用了很奇怪的方式來解決我當時的煩惱。

直到我進入到另一個團隊後，才知道可以藉由 AutoFixture.AutoData 做到更為簡單與彈性的解決方式，這篇就來簡單介紹怎麼做。

箕輪城位在東京西北邊，高崎市箕郷町中的一座平山城
目前僅有2016年修復的木造角馬出西虎口門外，並沒有留下其他任何的建築物
而城下町也保留了過去的氛圍，只可惜店家數量略少，整體環境幽靜。避開雨季前往即可

從本篇文章開始，百大名城攻略也加入了影片以及字幕解說，不想看文章想看影片的人，可以從這裡看看攻略箕輪城的影片
日本百大名城No.16，適合散步踏青的箕輪城，一個人的旅行

我想很多人看到標題後都會直接想
「程式裡直接用 DateTime  難道錯了嗎？」
「DateTime  用得好好的，為什麼要改用 Microsoft.Bcl.TimeProvider ?」
「我又不必寫測試，我就是要用 DateTime！」

我也管不著各位想怎麼用、想怎麼寫程式，只是看到很多有關於交易處理的程式都是跟時間判斷有關，而且有著種種原因而沒有寫測試，就讓人覺得那些產品妥當嗎？
而且一遇到 DateTime 的處理，就會卡在不知道如何寫測試。

所以就來寫這一篇簡單介紹 Microsoft.Bcl.TimeProvider

以往為了要測試 Oracle , 要弄 VM 來安裝 Linux , 然後再來使用相關指令安裝 Oracle , 現在利用 Docker 技術可以讓整個程序方便多了。