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"。
前篇已經聊過關於 Extension members 的一些基本操作，這裡補充一些前篇沒提到的部分。
目前手上常用來建置與發佈程式的 CI/CD 服務與架構系統，大略可簡化為 "GitLab 的雲端服務 + 地端主機上所運作的 Docker"。
如果要在 C# 14 的眾多新功能中挑選一個最令我心動的，一定是 Extension members。這項功能不僅是對既有 this extension methods 的延展，而且是進一步的語言層級提升、更為貼近原生成員的使用體驗。
在 GitLab.com 申請好的帳號與建立第一個專案的 Repo 之後，就可以進行 Pipeline 的使用。
根據 ChatGPT 對 GitLab 中的 Pipeline 其定義是：
在程式碼變動時，自動執行 CI/CD（Continuous Integration / Continuous Delivery）流程。
技術一點的說：
當程式碼有異動的時候時，GitLab 會依照 .gitlab-ci.yml 的設定，根據 Pipeline 中所設計的 Stages (階段)，如: 建置、測試、部署…等，來自動化的執行一連串 Jobs (工作)。
不知道大家是否有這樣的困擾，使用Google Antigravity要開啟瀏覽器來進行除錯或測試的時候，有時候瀏覽器的開啟就是卡卡的，不順利，這個問題一個設定，也許就能處理。
在使用 GitLab 進行專案管理時，透過範本建立專案可以大幅減少初始化設定的時間。
這篇來介紹一下如何在 GitLab 中使用 .NET 專案範本 (dotnet template) 建立第一個專案，從建立 GitLab Project、套用範本，到完成基本的專案結構與設定。
這樣可以快速建立標準化的 .NET 專案環境，為後續的版本控制與 CI/CD 自動化流程奠定一定程度的基礎。
在雲端原生 (Cloud Native) 的世界裡，無伺服器 (Serverless) 架構已經不是什麼新鮮事。今天，我們就來聊聊微軟 Azure 上的無伺服器解決方案 — Azure Function App，並實際走一遍如何用 C# 開發，最後再透過 GitHub Actions 帥氣地自動部署上去。
Azure App Service 是微軟提供的全託管式 Web 應用程式平台，讓開發者能專注於程式開發，不需要擔心基礎架構的管理。搭配 GitHub Actions，可以實現完全自動化的持續部署流程。這篇文章會介紹如何使用 Azure App Service 部署和管理 Web 應用程式，以及透過 GitHub Actions 實現 CI/CD 自動部署。
在前端開發中，UI/UX 設計是一個不可迴避的環節。傳統的做法是設計師手工繪製 Figma，開發者再根據設計稿實作。但這樣有個問題：溝通成本高、反覆調整多、時程壓力大。我一直在尋找一個更高效的方式，能否讓 AI 幫我快速產生設計元素，然後一鍵整合成完整介面？Pencil 搭配 UI/UX Pro Max Skill 就是這樣的工具。它透過 AI 助手的對話能力，讓你用自然語言描述需求，自動產生設計元素和設計稿。
本文會分享我使用 Pencil 的實務經驗，希望能幫助你建立一個「需求 → 設計 → 開發」的快速迴圈。
