今天看到一段影片，是 Andrej Karpathy(Vibe coding 一詞之創始人)的演講片段 中英雙字版本 軟體開發的三個重要階段 他提到目前軟體開發演進可分為三個重要階段： (擷取自影片) Software 1.0：由工程師手寫的程式碼。 Software 2.0：神經網路的權重，工程師不再直接撰寫程式，而是透過調整資料集並運行優化器來訓練模型，進而產生這些程式碼（權重）。例如特斯拉自動駕駛系統中許多功能已從 1.0 轉為 2.0。 Software 3.0：大型語言模型 (LLMs) 可以透過自然語言提示來「程式設計」。英文本身成為一種強大的程式語言，讓每個人都成為潛在的程式設計師。 LLMs 的角色與挑戰 Karpathy 將大型語言模型（LLMs）比喻為新型的作業系統，類似 1960 年代初期集中於雲端的電腦運算。他認為 LLMs 具備類似人類的「心理」，擁有百科全書般的知識與超能力般的記憶力，但同時也存在認知缺陷，例如會產生幻覺、智慧表現不穩定，以及類似「順向失憶症」的特性——每次互動後會清除記憶。因此，Karpathy 提醒我們在利用其強大能力的同時，必須特別注意並避開這些弱點。 Prompt 成為新時代的程式語言 隨著 LLMs 的出現，「prompts」本身成為了一種新型態的程式，這大幅降低了寫程式的門檻。現在，人人都能利用 AI 輕鬆產生基本的程式碼。Karpathy 甚至分享，他自己在完全不懂 Swift 語言的情況下，僅用一天就透過 Vibe Coding 完成了一個基本的 iOS 應用程式。 軟體工程師價值的轉變 然而，因為 LLMs 仍然是「會犯錯的系統」，Karpathy 認為軟體工程師的價值也隨之轉變——從純粹的程式碼撰寫，轉向設計與維護人機協作的「生成—驗證」循環。AI 負責生成內容，而人類工程師則負責驗證其輸出。他以鋼鐵人的鋼鐵裝為例，強調我們應將 AI 視為「人類的增強工具」，而非完全自主的 agent。我們必須「將 AI 拴住（keep the AI on the leash）」，確保其輸出符合預期且無潛在問題，並避免 AI 生成過於龐大的修改，導致審核困難。現在軟體工程師的的任務是「讓這個循環盡可能地快速進行」。軟體工程師的價值轉向設計更有效率的工具和介面（GUI），使人類能夠快速地審核與驗證 AI 所生成的結果。 個人觀後感 以上僅提到一些我認為的重要觀點，影片還有許多內容，有興趣的人可以自己去看，蠻建議花時間看完的。 ...

A basic record of local n8n deployment. Steps Docker docker-compose.yml version: "3.9" volumes: n8n_storage: services: n8n: image: n8nio/n8n:latest restart: always ports: - "127.0.0.1:5678:5678" volumes: - n8n_storage:/home/node/.n8n environment: - WEBHOOK_URL=https://<your-ngrok-domain>.ngrok-free.app # External webhook URL Usage Expose local port 5678 to the internet via ngrok: ngrok http http://localhost:5678 Copy the generated ngrok public URL (e.g., https://xxxx-xxx-xxx.ngrok-free.app). Edit the docker-compose.yml file and replace <your-ngrok-domain> in WEBHOOK_URL with your actual ngrok URL. Start the n8n service using Docker Compose: ...

前言 公司原本的上線流程最近要走 Azure DevOps 方式上線，我維護的 iOS App 不外乎也要走這個流程。原本測試都沒有太大問題，但上線之後發現 App Groups 功能沒有正確運作，就開始查找問題，最終找到問題所在並解決，記錄一下過程，並延伸相關知識。 Trouble Shooting 一開始覺得很奇怪，這次上線的內容並沒有異動到 App Group 的設定，所以應該跟 source code 沒有太大關係。後來先嘗試在本機 build 一版，結果發現透過這個方式運作正常，但透過 Azure pipeline build 出來的就會發生問題。因此轉向研究 pipeline yaml 的設定是否出現狀況。 先進一步確認透過 Azure pipeline 包出來的 artifacts 內容是否正確，一般而言，iOS App 打包後的成品如下： DistributionSummary.plist ExportOptions.plist YourAppName.ipa Packaging.log 查看 .ipa 我們可以查看 YourAppName.ipa 裡面到底簽入了哪些權限： 解壓縮 .ipa 檔案： unzip YourAppName.ipa -d AppContents 進入 Payload 目錄： cd AppContents/Payload 執行 codesign 指令： codesign -d --entitlements :- YourAppName.app 每個部分的含義是： codesign：呼叫程式碼簽署工具 d：表示 “display”，用於顯示簽署資訊 -entitlements :-：要求工具顯示應用程式中包含的所有權限（entitlements） 這裡的 :- 是一個特殊的語法，表示將輸出導向到標準輸出（stdout） YourAppName.app：要檢查的應用程式套件路徑 如果有正確簽入 App Groups 的權限，應該要有 <key>com.apple.security.application-groups</key> 的蹤跡，但發現透過 Azure pipeline 包出來 .ipa 沒有。 ...

小弟最近要接手管理 APIM 了，會把踩的點記錄下來。 在管理 Kong API Gateway 的過程中，發現在啟用 IP Restriction Plugin 並設置白名單後，該 consumer 仍然驗證失敗。經確認此情況與 IP 置換有關。 該 consumer request 路徑為： Client → Load Balancer → Kong API Gateway → Backend Service 在這樣的架構中，Kong 接收到的 IP 並不是實際的 Client IP，而是來自 Load Balancer 的內部 IP。 經確認： Kong 接收到的 client_ip 顯示為內部網段 IP（例如：以 .254 結尾）。 這些 IP 實際上是 Load Balancer 的 IP。 導致 IP Restriction Plugin 誤判來源 IP，合法用戶被錯誤拒絕。 Nginx 真實 IP 辨識機制 Kong 是建構在 Nginx 之上，利用 Nginx 的 ngx_http_realip_module 模組來從 HTTP Header 中擷取真正的 Client IP，並改寫 $remote_addr。 ...

雖然説這個靜態網頁主要是拿來做個人筆記記錄用，但想到如果有寫錯的地方，誤人子弟又沒有人告知好像也是個問題， 研究了一下，原來有將留言直接串接到指定 GitHub repo 的 Issues 充作留言區 (但必需要登入 GitHub 才能留言。)的方式。 實驗了一下，串接成功，記錄一下過程。 Step 1: 準備 GitHub repo 確認你有一個公開的 GitHub repo，留言將儲存在這個 repo 的 Issues。 因為本站是部署在 GitHub Pages，理當就建立在這個 page 所屬 repo 上。 Step 2: 安裝 Utterances GitHub App 前往 Utterances 的 GitHub App 頁面，將 App 安裝到你的留言 repo。 這裡沒有必要全部授權，只授權單一 repo 即可。 Step 3: 產生 Utterances script 繼續下一步，前往設定頁，依序填寫以下內容： repo 名稱（格式：username/repo） Issue 對應規則（建議選 pathname 或 title） 可自訂 label（如 blog-comment）方便分類 選擇主題色系 將產生 <script ...></script> 複製下來。 Step 4: 整合到 Hugo（PaperMod） 在 Hugo 專案目錄下建立或修改 layouts/partials/comments.html，貼上剛剛產生的的 script。 接著在你的文章裡面啟用 comment: true ...