Kim's Note

 最近看到 Codex 5.3 Spark 是使用獨立配額 ，一時興起，突然想到一件之前一直想做、但始終沒有真的動手的事情： 做一個自己的線上工具網站。 於是就有了 NexaForge 。 網站： https://nexaforge.kimx.info/ GitHub： https://github.com/kimx/NexaForge 從「不然來試試看」開始 一開始其實沒有什麼完整的開發計畫。 單純看到 Codex 5.3 Spark 有獨立配額，就想拿來試試之前放在腦中的構想。 我的想法很簡單：把平常偶爾會用到的圖片、PDF、JSON、文字處理以及開發者工具，集中在同一個網站，而且盡可能直接在瀏覽器完成。 不用為了一個 JSON Formatter 找一個網站，要處理 PDF 又換另一個網站；更重要的是，能在瀏覽器處理的東西，就不要把檔案傳到伺服器。 第一階段：Codex Spark，大約完成六成 前面的主要開發工作幾乎都交給 Codex Spark。 從網站架構、工具頁面，到各種功能實作，就這樣一路加下去。 做到大約六成左右時，網站的基本輪廓已經出來了，包括： 圖片轉換、壓縮與裁切 PDF 合併、分割與轉檔 JSON、CSV、XML 處理 Base64、JWT、UUID QR Code、Barcode 一些常用的文字工具 原本只是想「試做看看」，結果工具越加越多，也慢慢變成一個真的可以使用的網站。 第二階段：順便體驗 GitHub Copilot Bot 做到大約六成之後，我沒有真的把開發主力切到 GitHub Copilot，而是剛好想體驗另一種開發流程： 直接在 GitHub 開 Issue，再交給 Bot 接手修改。 也就是把要調整的功能、Bug 或需求寫成 Issue，看看 GitHub Copilot 能不能直接理解需求、修改程式碼，再透過 GitHub 的流程完成後續處理。 這一段比較像是在測試： Issue 能不能直接變成開發任務 Bot 對既有專案的理解程度 自動修改的結果是否真的能用 不開 IDE，也能不能完成一部分開發工作 順便也把 GitHub Plus 的額度消耗得差不多了。 所以這個階段與其說是「GitHub Copilot 接手開發」，比較像是拿 NexaForge 當成一個實際專案，體驗一次 Issue → Bot → 修...

前言 AI已經很會寫程式，但在大型專案中，真正的問題通常不是「不會寫」， 而是「不了解整個專案的上下文」。 例如:修改一個 API，Codex 需要知道 Endpoint 在哪裡、呼叫了哪些 Service、 Repository 是否共用、DTO 是否被前端使用，以及修改後可能影響哪些功能。 GitNexus 的目的，就是將 Repository 建立成 Code Knowledge Graph， 讓 Codex 在修改程式前，先查詢 Call Chain、相依關係與 Impact Analysis。 GitNexus 解決的問題 GitNexus 的價值不是多一個搜尋工具，而是讓 Codex 先理解程式關係。 適用情境 大型 .NET 專案 API Contract 調整 Service 或 Repository 重構 Bug 影響範圍分析 舊系統理解與維護 跨模組修改 安裝 npm install -g gitnexus@latest -- 設定Codex MCP codex mcp add gitnexus -- npx -y gitnexus@latest mcp 進入專案建立索引 ： gitnexus analyze 第一次分析後，GitNexus 會建立 Code Knowledge Graph， 修改專案 AGENTS.md及建立skills，讓 Codex 依照專案規則工作。 本機檢視已分析過的 repo npx gitnexus@latest serve http://localhost:4747/ Prompt 範例 根據AGENTS.md的內容，它也會自行透過MCP 找index來找到所需的檔案。也可以依提示請它工作: 請先用 GitNexus 找出此 API 從 Endpoint 到 Database 的完整流程， 再整理修改步驟，不要直接修改程式。 請使用 GitNexus impact 分析這個 method 修改後會影響哪些呼叫端， 不要直接改程式。 修改前請先使用 GitNexus 查詢此功能的 call chain、被誰呼叫、 會影響哪些檔案，整理影響範圍後再提出修改方案。 AGENTS.md 建議 除了GitNexus產生的規則。 建議在 AGENTS.md 中加上一些最重要的工作規則即： ## GitNexus 使用規則 1...

  開頭 如果你手上有一個靜態前端專案，但又需要一點後端能力，例如查詢資料、處理簡單商業邏輯，Azure Static Web Apps 是一條很值得考慮的路線。 這篇筆記整理的是我在 Azure Static Web Apps 免費方案下，搭配 Azure Functions 當後端 API 的實作觀察。重點不是把架構講得很大，而是記下真正上線時會碰到的幾個關鍵限制。 背景 我這次是拿一個 Blazor WebAssembly 測試網站來做實驗，想確認前端部署到 Azure Static Web Apps 之後，能不能順便把 API 一起帶上去。 結果是可以，但不是「把前端丟上去就結束」這麼簡單。實際上還要注意部署流程、專案相依關係，以及免費方案底下的受控模式限制。 說明 1. 免費方案下，API 其實是受控的 Azure Functions Azure Static Web Apps 的免費方案可以搭配後端 API，但那個 API 不是你平常獨立管理的 Function App，而是由 SWA 受控的 Azure Functions。 這代表幾件事： 你不會在 Azure Portal 的 Function Apps 清單裡看到它 它比較適合輕量 API 如果要做長時間執行、排程或佇列處理，就不太適合放在這裡 2. 部署流程要一起調整，不能只看前端 一開始如果是 Azure 自動產生的部署流程，常常只夠發前端。 但當你把 Function 一起加進來時，workflow 通常還要再調整一次，確保前端和 API 都有被正確發行。參考 github workflows yml 3. 專案之間不能互相依賴 當 Function 加進來之後，架構上要保持乾淨分離。 我在這次測試裡特別注意到： 前端專案與 Function 專案不能互相相依 TargetFramework 要從 net48 改成 net9.0 。 Azure Static Web Apps 不支援 .NET 10 。 如果目標框架不在 Azure Static Web Apps 支援範圍內，部署就會卡住 這類問題通常不是程式碼本身錯，而是平台與專案結構不合。 4. 免費方案有自己的配額與邊界 Azure Static Web Ap...

  前言 續前一篇  Docker Image To GCP Cloud Run 本文記錄，將一個.NET Web程式，使用docker image放到Azure Container上。 由於Azure Container Registry，沒有免費的，本文採docker hub的方式(有免費額度) ps: GCP Azure Container，有每月前0.5G免費 使用方式 推送到Docker Hub 先到docker.com 註冊帳號 用command 登入，或直接用docker for window登入 docker login Build image docker build -f AzureConatinerLab/Dockerfile -t azurecontainerlab . 標記並推送到 Docker Hub docker tag azurecontainerlab:latest kimxinfo/azurecontainerlab:latest docker push kimxinfo/azurecontainerlab:latest Azure Container App 建立 Container App，輸入Hub上的image 設定 Ingress 完成後，Overview 可以使用Application Url瀏覽 其他 如果希望服務閒置時不持續計費，可以保留  Min replicas = 0 免費額度 請求次數 ：每月前  200 萬次  請求免費。 CPU 資源 ：每月前  180,000 vCPU-秒  免費。 記憶體資源 ：每月前  360,000 GiB-秒  免費。 特點 ：支援「縮減至零 (Scale to Zero)」，沒流量時不計費。 總結 本文重點是 Docker Hub + Azure Container App 的串接 相關參考 Docker Image To GCP Cloud Run

  前言 本文記錄，將一個.NET Web程式，使用docker image放到Cloud run上。 使用方式 本地初始化環境 安裝GCP CLI (New-Object Net.WebClient).DownloadFile("https://dl.google.com/dl/cloudsdk/channels/rapid/GoogleCloudSDKInstaller.exe", "$env:Temp\GoogleCloudSDKInstaller.exe") & $env:Temp\GoogleCloudSDKInstaller.exe 裝完後，會接著要你登入及選擇預設的專案(畫面..略) 啟用必要的 GCP 服務 gcloud services enable run.googleapis.com cloudbuild.googleapis.com Google Consle 建立 Artifact Registry repo 設定 Docker 對 GCP Registry 的驗證 gcloud auth configure-docker asia-east1-docker.pkg.dev Build image docker build -f MondayAr/Dockerfile -t mondayart100 . 標記並推送 image 到 Artifact Registry # 標記 image docker tag mondayart100 asia-east1-docker.pkg.dev/gen-lang-client-xxxxx/monday-ar-t100/mondayart100:latest # 推送至 GCP docker push asia-east1-docker.pkg.dev/gen-lang-client-xxxxx/monday-ar-t100/mondayart100:latest 在 Cloud Run 建立服務，並選擇 Artifact Registry 裡的 image 設定個數量下限0，閒置不算費用。Ingress允許網路使用 設定  .env  或其他環境變數 完成，在服務可以取得網址 後續更新 之後image更新，一樣先Build Image再標記並推送 ...

前言 影片太長，試著用AI工具產生Blog文章，加速學習 內容來源: .NET Conf 2025 Welcome to .NET 10 & Visual Studio 2026! 工具 這裡簡述一下使用的AI工具 Google NotebookLm : 將Youte的內容，產生報告。 grok / chatGPT: 將報告請它將此篇內容轉成繁體中文，並以部落格的風格撰寫 歡迎來到 .NET 10 & Visual Studio 2026 1. 效能大躍進，簡直是「撿到錢」的感覺 升級新版 .NET 總有點效能小升級，但 .NET 10 這次玩真的——效能提升大到讓人懷疑人生，重點是，你可能連一行碼都不用改！Scott Hanselman 在台上秀了 TechEmpower Fortunes 基準測試的內部數據：比起 .NET 8，.NET 10 的記憶體用量狂砍 93%，每秒請求量還多出 15%。 這可不是運氣好，這是 Microsoft 十年來在運行時、JIT 編譯器和垃圾回收器上層層疊加的投資成果。Scott 說得一針見血：「升級 .NET 10 不是為了新功能，這是個效能風落財，讓你對託管運行時的期待徹底重定義。」 想想看，你的舊專案跑起來更快、更省資源，誰不愛？這次升級，絕對是零成本的爽快體驗。 2. 一個 .cs 檔案，就能搞定整個 C# 應用？太狂了！ 想當年，寫個簡單的 C# 程式還得先建 csproj 專案檔，現在？拜拜傳統！.NET 10 推出「基於檔案的應用」（file-based apps），Damian 在 demo 裡秀了：就一個 .cs 檔，從頭到尾的完整應用，跑起來超簡單——直接 net run hello.cs 就開幹。 這招直接拉低新手門檻，讓 C# 變得像 Python 或 Go 一樣適合腳本和小工具。超讚的是，它不會綁死你：當你的 app 長大變複雜時，一個 net project convert 指令，就能無痛轉成標準專案結構，繼續深耕。 對初學者來說，這是「一鍵入門」的福音；對老鳥呢？終於能輕鬆 hack 小工具，不用搞一堆 boilerplate 了。C# 從此不只企業級，還能街頭巷尾玩！ 3. Aspire 脫離 .NET，變身多語言神器 這公告最出人意料：原來叫「.NET Aspire」的東西，直接改...

  前言 目前的專案，git分支，切分為如下: master : 由release併入，發行到PRD release : 由develop併入，發行到QAS develop : 由個別開發者併入。 問題來了! 這兩天併入到release的變更，只想挑最上方那一筆紅框併入到master，其他的綠框不可以併入。如下圖所示: 解決方式 使用cherry-pick 挑選某一筆的commit併入。 使用方式 切換到master 或master checkout另一分支hoftix(本文使用此方式，可以避免操作錯誤，刪除就好) 。 取得該筆的commit ID 8碼。 在hotfix分支執行命令 git cherry-pick e957cc4e 4 . 完成畫面，只有Finished那筆commit併入 最後確認無誤的話，就可以從hotfix併入master 總結 cherry-pick 是一個很好的工具，可以幫助你精確地應用某些 commit，但在使用時需要小心，它不適合複雜的歷史操作，特別是處理依賴關係和衝突的情況。

  Foreword 使用微軟提供的Dev Tunnels取代之前使用NGROK的方式，將本機開發的URL公開在外部網路。 此方式為方便與外部服務整合測試，例如:LineAPI Dev Tunnels 有2種使用方式，以下會介紹何使用 1. Visual Studio 2022 .NetCore程式 內建就有Dev Tunnels功能，第一次使用先建立tunnels 選擇建立好的通道，執行網頁即會出現外部URL 2. 非.Net Core程式 (.Net Framework) 安裝 dev tunnels 程式 裝完後 重開機 ，環境變數位罝才會生效 winget install Microsoft.devtunnel 登入 第一次使用，需要登入Github或微軟帳號 devtunnel user login 執行本機程式，http port 50893 ps: 不能使用https 執行devtunnel 將本機程式公開，並允許匿使用者可以瀏覽 devtunnel host -p 50893 --allow-anonymous 執行後，取得公開的URL，大功告成 進入後按Continue Reference Dev Tunnels Visual Studio in 10 Minutes or Less 董大偉使用DevTunnel取代NGROK

前言 工作有一需求，需要將root 導向www，例如: kimx.info to www.kimx.info 。此方式個人知道的解決方式，有2種: 1. 在IIS設定Rewrite。 2. 在DNS 服務商設定 (本文針對Cloudflare)。ps: 要看是否有支援。 使用方式 1. 如下圖，設定root 並啟用代理，此為給Cloudflare的Page Rule轉發用。 2.設定Page Rule 將root 轉到www 總結 這樣的設定比去IIS設定方便許多，省下Rewrite及Bining等設定，也比較好管理。 相關參考 https://developers.cloudflare.com/support/page-rules/configuring-url-forwarding-or-redirects-with-page-rules/