上一篇 用 IDistributedCache + MemoryCache 做了一個簡單版本的冪等，適合單節點演練。但在多 Pod / Container 部署的環境下，MemoryCache 各自獨立，不同 Pod 看不到彼此的快取，冪等保護會直接失效。
這篇換用 Redis 來實現分散式冪等，目標是能跑在 Kubernetes / Docker Swarm 這類環境。
Harmony Library 補丁方式的最終章，Reverse Patch。
Transpiler 是 Harmony Library 的重量級功能，相較於 Prefix 或 Postfix 是在原始方法前後插入程式碼，Transpiler 直接操作 IL 指令，讓你在程式執行前就重新改寫方法本身，威力驚人。
已經有一段時間沒開 Android Studio 起來用，看到 GitHub Copilot 有說可以在 Android Studio 當中使用 GitHub Copilot Chat 的 Plugin (對，已經腿很久了)，就不假思索的打開電腦上已經安裝的 Android Studio 來試試看。
在 Android Studio 中點開 Plugins 找到 Marketplace：
這一篇談論終結器補丁 – Finalizer。
持續介紹 Prefix 和 Postfix 的其他使用方式。
系列：從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案（5/10）
系列：從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案（4/10）
續上篇，繼續來實作不同情境的 Prefix 與 Postfix。
前篇簡單介紹了 Harmony Library，這篇開始介紹補丁的實作，因為 Prefix 與 Postfix 常常會搭配，所以就併在一起說明。
系列：從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案（3/10）
想要讓 GitHub Copilot 串其他 AI 平台的 model 到 GitHub Copilot 在 Organtization 來使用，行不行？
行，當然行！
看 GitHub 設定 API key 的選項：
基本上主流的幾家 AI 平台都支援了！
記錄把本地 Terraform State 文件轉移到 AWS S3 的過程與注意事項
Harmony 是一個 .NET 的開源 Runtime Patching 函式庫，由 Andreas Pardeike 開發，這個函式庫能夠在不具有原始碼的狀況下動態修改任何 .NET 方法的行為。這系列文章記錄一些關於這個函式庫的使用方式。
系列：從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案（2/10）
系列：從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案（1/10）
2025 年 8 月到 9 月，我參加了 iThome 鐵人賽，花了 30 天寫完「重啟挑戰：老派軟體工程師的測試修練」這個系列。一直沒有在部落格這邊正式介紹過，趁這個機會寫一篇導讀，讓大家在還沒有把 30 篇全部看完也能瞭解裡面在講什麼。
30 天的內容從最基本的「為什麼要寫測試」一路寫到 Testcontainers、.NET Aspire 整合測試、TUnit，每一篇都有技術介紹說明、程式碼範例，以及我自己在專案裡踩過的坑。如果你對 .NET 測試有興趣但不確定要從哪裡開始看，這篇可以幫你省點時間。
另外，完賽之後我把這 30 天的測試知識重新整理成了 29 個 Agent Skills，讓 AI 可以直接拿來用。後續會有一系列文章介紹 `dotnet-testing-agent-skills` 這個專案 — 從 Agent Skills 到 Agent Orchestration 的完整方案。所以這篇鐵人賽導讀也算是後續系列的起點，先從源頭說起。
Vibe Coding 課程的繁榮與隱憂：當非技術出身的人開始販售「人人都能寫軟體」的夢想，轉職者與初階工程師該如何判斷？
GetCreationTimeUtc / GetCreationTime 其實都會有同樣的問題。
更正確地說 .NET 對檔案的 CreationTime 在 Windows 與 Unix-like (macOS、Linux…等，後面都統一稱呼 Linux) 的 OS 上定義不同。
"對 GitHub 的 Organization 中的成員設定 GitHub Copilot : 解釋篇" 所提到的 Organization 請理解為：
群體
這個 "群體" 可能會是：
…等這樣的詞彙解釋。
在 AI 盛行起來後，在數位世界中的任何一個 "單位" 中有可能存在多個 "人類" 或 "Agent" 的個體，那就適用這個 "Organization" 的觀點。
Reference：https://github.com/bubbliiiing/yolov4-pytorch
Key Word：WSL2、Bubbliiiing、Pytorch YOLOv4、Object Detection、RTX4060、Github License Issue、Roboflow、CrowdHuman
C# 14 新功能還有一些比較無法長篇描述的就集中在這裡一次說完。
在 GitHub Copilot (以 2026Q1 這時間點瞭解到) 所設計的各種 Plans 來看，在使用上分成兩大區塊：
如果你就是只有一個人，基本上都是 Individuals (個人/獨立個體商)。
這樣的使用情境大概就是，想要自己放飛自我寫程式或是整間公司就只有你一個人，不用跟其他任何 "人類" 或 "Agent" 有交流與互動就能完成工作，那可以選的 Plan 有：
在微服務架構中，一個使用者請求可能跨越多個服務，當問題發生時，如何追蹤這個請求到底經過了哪些服務？每個服務做了什麼事？花了多少時間？這就是「可觀測性（Observability）」要解決的問題。
本篇文章將介紹如何在 ASP.NET Core 10 微服務中整合 OpenTelemetry、Serilog、Jaeger 與 Aspire Dashboard，建立完整的分散式追蹤與結構化日誌方案。
目前手上常用來建置與發佈程式的 CI/CD 服務與架構系統，大略可簡化為 "GitLab 的雲端服務 + 地端主機上所運作的 Docker"。