前篇已經聊過關於 Extension members 的一些基本操作，這裡補充一些前篇沒提到的部分。

目前手上常用來建置與發佈程式的 CI/CD 服務與架構系統，大略可簡化為 "GitLab 的雲端服務 + 地端主機上所運作的 Docker"。

要完全地端也當然不是不行，畢竟可以自行架設 gitlab 的 Server 在地端的環境內運作。

如果要在 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 的實務經驗，希望能幫助你建立一個「需求 → 設計 → 開發」的快速迴圈。

(圖片取自 Gogoro 官網活動)

2026/1/26~2026/2/1 有到 7-ELEVEn 換電站交換電池的 Gogoro 車主，可獲得一點小確幸唷！

最近在研究 AI 進行 E2E 測試，我選擇 Microsoft 開發的 Playwright。它支援多瀏覽器（Chromium、Firefox、WebKit）、自動等待機制，還有一個很方便的錄製功能，可以直接操作網站產生測試腳本，搭配 Claude、Copilot、Gemini 又可以解省錄製、除厝的時間，本篇會簡單介紹我的使用方式。

複合指派運算子 (compound assignment operators) 早就存在於 C# 中，在 C# 14 開放了可以自行定義這類複合運算子的功能，本篇文章說明如何自行定義，且這個自行定義在程式上的意義又有甚麼不一樣。

field 關鍵字首見於 C# 13，當時是預覽版功能，並未正式釋出；時至今日的 C# 14 成為了正式版本的功能。

先回顧一下在 "前一篇" 當中有提到基本的使用架構：

+--------------------+                          +--------------------+
|   Server Process   |         Named Pipe       |   Client Process   |
|                    | <----------------------> |                    |
|   NamedPipeServer  |       \\.\pipe\demo      |   NamedPipeClient  |
+--------------------+                          +--------------------+

當前手上接觸到的一個系統專案，其整體的程式架構概念可以簡化成：

HW/FW ←→ CLI ←→ GUI

HW/FW 的程式，大多是透由 C/C++ 撰寫，這部分有專業的人員處理開發；而系統中的 CLI 與 GUI 這兩部分的程式，是仰賴 .NET 來進行開發的。

也因此隨著 .NET 的跨平台發展，便得以讓這兩部分的程式，除了既保留在 Windows 上的順利運作，也能逐步有序地從轉移至 Linux 當中運作。

也就是 .NET 一直強調的： 

Write once, run multi-platform.

^{(原文為 Write once, run everywhere. 在此做些文字改動)}

在電腦的 Process 與 Process 之間要相互通訊（IPC, Inter-Process Communication），粗略的來分可以有兩種方式：

• Socket
• Pipe

以下列出對照：

開發公開 API 時，防範惡意濫用是不可或缺的一環。本文將探討如何運用 ASP.NET Core 建構安全防護機制，為允許匿名存取的 Web API 提供堅實保障。

續上篇 .NET 9 HybridCache 實戰，我們已介紹 Server\-Side 的快取架構（L1 記憶體快取、L2 分散式快取）。本篇將聚焦在 Client-Side 的快取機制（HTTP Cache）：透過正確設定 HTTP 標頭，讓瀏覽器優先使用本地快取，降低伺服器負載並提升使用者體驗。

本篇會以實作程式碼示範各種 Cache-Control 指令的行為差異與適用情境。

今年是移居荷蘭的第三天，該適應的，不該適應的，都適應了 :D  
2025 最有感的是 AI 的爆炸進展，無論生活或工作中，都高度的依賴 AI 工具