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

Generated by Perplexity 問題說明 前陣子我遇到一個值得記錄的問題（至少對我而言）：在維護一個有點舊的 .NET framework 專案時，發現透過 ProjectReference 方式依賴的 NuGet 套件無法自動還原。經過一番調查後，才發現這是 NuGet 在處理某些舊式專案時的一個行為特性。對 .NET 很不熟的我覺得可以記錄一下，以防未來又忘記。 專案結構與重現情境 MainApp.csproj ← 主專案，透過 ProjectReference 參考 SharedLibrary.csproj └── SharedLibrary.csproj └── <PackageReference Include="ICSharpCode.SharpZipLib" /> 我的 solution 中有兩個專案： MainApp.csproj：主應用程式專案 SharedLibrary.csproj：共用函式庫，透過 ProjectReference 被 MainApp 參考 在 SharedLibrary.csproj 中，使用了常見的壓縮解壓縮函式庫 ICSharpCode.SharpZipLib，並以以下方式引用： <PackageReference Include="ICSharpCode.SharpZipLib" Version="1.4.2" /> 然而在建置 MainApp.csproj 時，卻發現 SharpZipLib 的相關類別無法解析，沒有編譯出 .dll 檔。反觀其他套件如 NPOI 和 EntityFramework 則一切正常，讓我相當困惑（因為不論是在 prodution 或是 test 環境中都沒看到 .dll 缺失的問題）。 至於為什麼會發生這種事情，我想…就技術債這三個字吧 嘗試與排查過程 一開始我找問題的方式比較粗暴簡單，那就是找其他也有引用 SharedLibrary.csproj，但卻可以成功編譯的專案，看他們跟有問題的專案差在哪裡。於是我找到了其他專案多的這一行： <PackageReference Include="EntityFramework" Version="5.0.0" /> 神奇的事情發生了，SharpZipLib 居然也能正確還原了！ 這讓我開始懷疑問題出在 NuGet 的套件還原邏輯上。經過研究，終於找到癥結所在。 ...

今天看到一段影片，是 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。 ...