Kim's Note

前言 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再標記並推送 ...