Hi, I’m Hsien-Te Hsieh 🧑🏻‍💻

Kong 與 Nginx 設定關係筆記 工作上遇到一些狀況，需要處理 HTTPS 加解密演算法，剛好趁這個機會記錄一下 Kong 跟 Nginx 的關係。 這邊以 SSL Ciphers 為例，整理 Kong 設定如何流向至 Nginx 實際生效的過程。 概念架構 Kong 的設定與 Nginx 的設定之間存在著三層結構： 層級 檔案位置 用途 源頭 kong.conf Kong 的主設定檔，定義所有運行參數 入口 nginx.conf Nginx 的起點，僅做全域/事件設定，在 http {} 內 include 真正的設定檔 生效 nginx-kong.conf 實際生效的設定，包含 ssl_ciphers、ssl_protocols、各個 listen 等 TLS/Server 設定 簡單來說：kong.conf 是來源、nginx.conf 是入口、nginx-kong.conf 是實際生效結果。 設定流向 - 以 SSL Ciphers 為例 Step 1: 源設定 在 kong.conf 設定 ssl_cipher_suite 和 ssl_ciphers： ssl_cipher_suite = custom ssl_ciphers = ECDHE-RSA-AES256-GCM-SHA384:... Step 2: Kong 翻譯 當你執行 kong start 或 kong restart 時，Kong 會根據 kong.conf 生成 Nginx 的實際設定。 ...

看到一篇文章寫的不錯，紀錄留存一下，並且簡單的重點整理。 本文僅做紀錄與整理，觀點本身皆來自原文作者。 原文：https://www.facebook.com/100063744608911/posts/1526846902783449/?mibextid=wwXIfr&rdid=ABv4HxePsdb0LmOe Agent 開發的三個階段演變 第一階段：工具連接期 (Function Calling / MCP) 作法：利用 LLM 的 API 與 Function Calling 能力，將 AI 與後端系統串接。後來演變成標準化的 MCP (Model Context Protocol)。 痛點：技術門檻過高，能獨立完成的人很少。 第二階段：多代理協作期 (A2A / Multi-Agent) 作法：類似 Google 提出的 Agent to Agent，讓多個 AI 各司其職。 痛點：類似「微服務」亂象，過度設計 (Over-engineering)。管理多個 Agent 的 Context 很困難，且往往「一個 Agent + 多個 Tools」就能解決問題。 第三階段：Coding Agent 與 SDK 成熟期 (現在) 作法：使用 Claude Code 或 GitHub Copilot 這類高度可自訂的 Coding Agent。 突破：透過自訂 Instructions 和 SKILLs (流程知識)，不僅能寫程式，還能處理非開發任務。這是最直覺有效的路徑。 AI 時代的 MVP (最小可行性產品) 開發新路徑 過去的軟體開發往往是「從輪子造車」(從底層一行行寫)，風險在於最後一刻才知道客戶喜不喜歡。AI 讓「理想的 MVP 路徑」(滑板車 -> 腳踏車 -> 汽車) 變得成本極低且可行： ...

前言 在進行 Entity Framework 查詢時，當你執行的是「唯讀」操作，卻沒有使用 AsNoTracking() 時，效能會有差距。本篇記錄實際踩雷的經驗——當資料量小時還看不出來，但隨著資料成長，超過預設的 60 秒 Timeout 限制，導致排程工作失敗。 問題情景 某個 .NET Framework 排程工作，定期執行一份複雜的資料查詢： using (var db = new MyDbContext()) { var result = db.Orders .Where(o => o.Status == "Completed") .GroupBy(o => o.CustomerId) .Select(g => new { CustomerId = g.Key, TotalAmount = g.Sum(o => o.Amount), OrderCount = g.Count() }) .ToList(); // 處理 result... } 起初，資料量只有幾千筆，執行速度很快。但隨著程式修改，時間推移，累積到數十萬筆以上，這個查詢開始變得異常緩慢，最終超過預設的 60 秒 Timeout，排程執行失敗。 根本原因：Change Tracking Entity Framework 預設會追蹤查詢結果中的每一個實體： ...

最近因為有需求，需要了解一下 Azure APIM 的用法，初步整理一下，從 Kong 的角度來理解新東西。 設定 API 從 Kong 的觀念來理解 Azure APIM 對應之概念 Kong Azure 差異 Service API (或 Backend) 在 Kong 中我們使用 Service 來定義上游 URL；Azure 中則在 API 層定義，或使用 Backend 實體來管理共用的上游設定。 Route Operation Kong 的 Route 負責路徑匹配；Azure 則在 API 層的 Operation 定義具體 HTTP method 與路徑。 Plugin Policy Kong 使用內建 Plugin，直接套用，或使用 lua 寫自訂 plugin；Azure 則使用 XML 定義 Policy。 Consumer Subscription Kong 透過 Consumer 身分來控制 API 存取權；Azure 透過 Subscription (訂閱帳戶) 來控制。每一個「訂用帳戶」都會產生一組 Subscription Key (Primary & Secondary Key)，呼叫 API 時，於 Header 設置 Ocp-Apim-Subscription-Key 來呼叫。 Product 在 Azure APIM 中，API 必須被包在一個 Product 中才能被「訂閱」與呼叫(除非該 API 是 open 的，所有人皆可呼叫)。 ...

前言 三十天的鐵人賽，像一場技術馬拉松，終於來到了終點線前。最初的目標很明確：結合我對 iOS 開發的熱情與工作上學習到的 DevOps 實踐，從零到一打造一款名為「台灣公路 K 點通」的 SwiftUI App，並為它建立一套完整的自動化開發流程。 每天產出一篇文章是個挑戰，也是將腦中零散知識點串連成完整實踐地圖的過程。從動機、UI/UX 的草圖規劃，到 Swift 語法的基礎、SwiftUI 的畫面雕刻，再整合 Core Location 與 MapKit, Google map 的地圖服務，期間並導入 Azure Boards 進行專案管理，最後用 Azure Pipelines 實現 CI/CD。 旅程回顧：從痛點到 App Store 的完整路徑 這三十天的內容，可以劃分為四個階段，描繪了一個 iOS App 從概念誕生到最終上架的完整生命週期。 第一階段：從痛點到藍圖 萬事起頭難，在一開始專注於「想清楚要做什麼」與如何做。 我們從一個生活中的真實痛點出發：在公路上難以快速找到特定里程的確切位置，這個具體的目標，成為了整個專案的起點。在技術選型上，我們比較了 UIKit 與 SwiftUI，並基於開發效率、宣告式語法的優勢，以及想要嘗試新技術的心情，最終選擇了 SwiftUI 作為主力框架。 接著，我們在 Azure DevOps 上初始化了專案，設定了 Git Repo，並選擇了適合個人專案的 Basic 流程，為後續的專案管理與 CI/CD 建立基礎架構。 在開始動手寫 App 前，我們先透過使用者流程圖釐清了 App 的操作路徑，再用手繪 Wireframe 與 AI 工具輔助，描繪出 App 的畫面草圖，確保了後續開發的方向明確。 第二階段：掌握 SwiftUI 在這個階段建立 Swift 的語言基礎，快速複習了變數、常數、Optional 型別與流程控制等核心語法，並釐清了 Class 與 Struct 的關鍵差異。接著，我們深入 SwiftUI 的核心，從 Text、Image 與 Button 等基本元件著手，並學習運用 VStack、HStack 與 ZStack 這些佈局容器將畫面元素組合起來。在此過程中，我們掌握了 @State 與 @Binding 如何驅動畫面即時更新，理解了 SwiftUI 的宣告式思想。 ...