.NET Core 的多國語系套件是 Microsoft.Extensions.Localization，再透過 IStringLocalizer<T> 物件來取得資源檔內容，預設整合了資源檔，上篇介紹了 Tolgee 管理多國語系，它支援了 i18n 的檔案，這篇將記錄使用 I18Next.Net 的方式，再來想辦法將它們整合。

SonarQube 是一套程式碼品質分析工具，分析程式是否存在 Bug、漏洞或不好的寫法，第一關品質分析就交給它了，它的運作方式很簡單，透過 SonarQube Scanner 把報告提交到 SonarQube Server，這篇我會用 .NET Core 的專案實驗。
下圖出自官網 https://docs.sonarsource.com/sonarqube-server/latest/setup-and-upgrade/install-the-server/introduction/

位在長野縣上田市的上田城，現在殘留下來的是在江戶時代重建的一座平城
每年四月上旬春天的花季，都會吸引許多觀光遊客參觀，也是個一年四季都可以前往的觀光地點
如果你是真田迷，更是不能錯過上田城與上田這個地方

在 Azure  上很常利用 Key Vault 來儲存一些所需要使用的密碼或金鑰，但指派使用者的權限要稍微注意一下

使用 NuGet Explorer 來檢查一個 NuGet Package 的時候會發現有一個 NuGet Health Status 的區段，那要怎麼讓我們做出的 NuGet Package 都是綠燈呢？

在 Visaul Studio 當中開發桌面應用程式時，可以透過 WSL 直接偵錯執行 Linux 版本的桌面應用 (根據所安裝的 Linux 環境而定)。

而對於一個不太熟悉 Linux 相關設定的小白來說，每當透過 WSL 執行所設計的跨平台桌面應用程式時，若其畫面有中文字要顯示時，就會呈現豆腐塊的結果，著實讓人有點小困擾。

在部份環境下因為建立計算欄位造成伺服器效能低弱 , 因此改用其他方法來解決效能問題

在調查多國語系時發現了 Tolgee，它提供雲端和自架的方案，Self-hosted Pricing | Tolgee

Writing HTTPS API server code pair to provide AI model inference using python.

在使用 GitHub Copilot 的情境中，我們可以透過它來幫助我們做 Code Review，而前陣子的更新讓這個情境變的更加好用跟方便，後面就來介紹如何更方便的透過 GitHub Copilot 來做 Code Review。

在使用生成式 AI 來提供程式碼建議的時候會希望產出的程式碼建議會符合自己或是團隊的 Code Style，或是可以在協助做 Code Review 的時候可以幫忙檢查出不符合 Code Style 的程式碼，最近 GitHib Copilot 更新了一個實驗性的功能，可以讓我們方便設定自定義的提示詞，讓 AI 在回覆的時候更符合我們的需求，後面就來說明該如何設定。

小諸城位在長野縣小諸市的市區中，又名醉月城、穴城或是白鶴城
19世紀時，透過自然景觀的活用改造成了市營公園，並整理成為小諸城址懷古園
是個一年四季不論何時都可以前往旅遊的好地點

本篇是 Chrome Extension 的第七篇入門文章。

將兩篇文章的原始碼做了整理，然後放上 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。