將兩篇文章的原始碼做了整理，然後放上 Github

續上篇，預設 Nexus 建立後，預設就支援 nuget，不用作太多的設定就可以上傳 nuget package

Sonatype Nexus Repository 是一款支援多種協定的 Artifacts Management 成品管理工具，

下圖出自：Sonatype Platform Integrations | Sonatype 

Docker Image 現在已經應用程式產出的標準配備，想要利用 Nexus 建立 Private Docker Image Registry，當我要 Push Docker Image 時碰到了一些小亂流特此記錄下操作步驟。

使用 dotnet cli 來對 visual studio solution 檔案打包成 nuget package 的旅程

有時候會需要採用比較靈活的功能選單，希望能靠著資料繫結來完成，比較普遍的做法就是採用階層式資料繫結，讓我們一步步來完成這個需求。

在 .NET Core 定義了兩種快取，本機快取(IMemoryCache)；分散式快取(IDistributedCache)，用於將快取資料儲存於外部儲存裝置中（如 Redis、SQL Server 或其他分散式快取提供者），使用上沒有甚麼太特別的，單純的記錄下。

過去工作專案大多使用 RabbitMQ 來處理訊息佇列，RabbitMQ 的幾種模式（Direct, Topic, Fanout）都有使用，因為都可以解決大多數的應用情境，所以就沒有想要去使用 Kafak，畢竟多建立一套服務就需要再多花時間去維護。

一直以來也想要找個時間來玩玩 Kafka，於是就利用週末時間學習怎麼使用 Docker 架設服務，程式開發練習怎麼使用 Confluent.Kafka，這是一篇學習筆記。

公司的資料庫有很多功能用到了分表分庫，根據條件，決定要連哪一台資料庫，用哪一張資料表，概念上很簡單，花了一點時間研究，EF Core 的寫法。

在 Visual Studio 下建立資料庫專案是資料庫版控的一種好方式，但是一個資料庫專案只能針對一個資料庫做處理，如果遇到需要跨資料庫處理的時候該如何來做處理會比較方便 ? 

我只是想要內嵌 Markdown 到 OpenAPI.yaml 裡，並且用 Redoc 產生出靜態檔案，就卡了一個下午，這沒有筆記一下接下來一定會忘記的，參考連結在這裡 Embed Markdown in Redocly API reference docs

前一篇「使用 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 方法的回應時間就能夠加快一些。

MassTransit 的架構是一個基於事件驅動和 Message 傳遞的分佈式系統架構，主要是要解偶服務之間的通訊。它使用 Message Broker（如 RabbitMQ、ActiveMQ、Kafaka、Azure Service Bus、Amazon SQS 等）來傳遞不同服務之間的訊息，它大大的簡化事件驅動的開發門檻

上一篇「背景常駐執行計時工作 - 使用 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 訪問機敏性資源吧！