TechSummary 2025-09-22

🚀 Gartner 再次將 GitHub 評為 2025 年 AI 程式碼助理魔力象限領導者

Source: https://github.blog/ai-and-ml/github-copilot/gartner-positions-github-as-a-leader-in-the-2025-magic-quadrant-for-ai-code-assistants-for-the-second-year-in-a-row/

• Gartner 預測，到 2028 年，90% 的企業軟體工程師將採用 AI 程式碼助理，顯著高於 2024 年初的不到 14%。這顯示 AI 正以前所未有的速度重塑軟體開發。
• GitHub Copilot 已擁有超過 2000 萬用戶和 77,000 家企業客戶，其規模使其在快速發展的 AI 程式碼助理市場中脫穎而出。
• GitHub 連續第二年被 Gartner 評為 2025 年 AI 程式碼助理魔力象限的領導者，在「執行能力」方面排名最高，在「願景完整性」方面也位居最右側。
• Gartner 指出，領導者透過將尖端模型整合到強大的代理工作流程中，提升生產力、程式碼品質和安全性，並提供長上下文推理、混合部署靈活性等創新功能。
• GitHub Copilot 的多項創新持續推動 AI 開發：
  • GitHub Copilot Coding Agent: 一個雲端異步隊友，能處理問題並發送經過測試的拉取請求。
  • Copilot agent mode: 一個即時協作者，能在編輯器中根據需求修改文件。
  • Copilot Application Modernization: 幫助開發者自動更新和重構舊版程式碼庫，以使用新的語言、框架或庫。
  • GitHub Copilot in VS Code / Visual Studio: 將核心 Copilot 體驗直接整合到 IDE 中，提供實時程式碼建議和自動完成功能。

💡 Git 的下一步：20 年後，社群仍在持續推進

Source: https://github.blog/open-source/whats-next-for-git-20-years-in-the-community-is-still-pushing-forward/

• Git 慶祝其第一個提交 20 週年，現已成為從小規模專案到大型單一儲存庫的預設版本控制系統。
• Git 社群持續在效能、使用者體驗和互操作性方面進行改進，並探索新的工具和應用場景。
• Git Merge 2025 會議將探討 Git 的未來方向，包括：
  • 提供更快的合併、新的後端，並在正確性方面進行實驗。
  • 啟用 SHA-256 互操作性，以實現更安全的未來。
  • 將二十年的 Git UX 經驗轉化為更好的客戶端。
  • 透過視覺化、模擬和遊戲化來教授 Git。
  • 應用於新的使用案例，如本地優先應用程式、基因組研究和 WASM Git 伺服器。
• AI 與 Git 的結合是未來重要議題，GitHub 和 GitButler 共同創辦人 Scott Chacon 將探討如何教導 AI 代理良好的 Git 習慣，例如撰寫有意義的 commit 訊息、執行 amending、squashing 和 rebasing 等。

✨ JetBrains IDEs 將迎來全新 Islands 主題外觀

Source: https://blog.jetbrains.com/platform/2025/09/islands-theme-the-new-look-coming-to-jetbrains-ides/

• 從 2025.2.3 版本開始，JetBrains IDEs 將推出全新的 Islands 主題，提供深色和淺色兩種模式，這是一個純粹的視覺更新，所有功能保持不變。
• 新主題旨在提供現代化外觀，跟隨設計趨勢，並改進使用者介面：更清晰地分離編輯器和工具視窗、更顯眼的導航、以及更好的標籤可見性，同時確保 JetBrains 產品之間的一致性。
• 在 2025.2 EAP 期間，JetBrains 測試了兩種設計方向，並根據使用者回饋最終選擇了 Islands 主題，使用者普遍認為其現代、清晰且易於導航。
• 例如，有用戶表示：「它看起來和感覺都很現代和簡潔，幫助我專注於工作。」和「感覺很清爽，同時讓 IDE 的每個部分區分得更明顯。」
• Islands 主題目前處於 Beta 階段，JetBrains 鼓勵使用者提供反饋，以進一步完善設計並解決已知問題。

🌐 Compose Multiplatform 1.9.0 發布：Compose Multiplatform for Web 進入 Beta 階段

Source: https://blog.jetbrains.com/kotlin/2025/09/compose-multiplatform-1-9-0-compose-for-web-beta/

• Compose Multiplatform for Web (由 Wasm 驅動) 正式進入 Beta 階段，標誌著它已不再是實驗性功能，可供早期採用者應用於實際專案。
• 此版本讓開發者能以最小的努力，將現有的 Compose 技能和程式碼模式帶到 Web 平台，用於建立新應用或擴展行動與桌面應用。
• 主要特性包括：Material 3 組件，用於設計保真度；響應式佈局和流暢動畫，可無縫適應不同設備和螢幕尺寸；與瀏覽器導航（前進/後退按鈕、深層連結、歷史記錄）整合；以及支援系統和瀏覽器偏好設定（如深色模式）。
• Compose Multiplatform for Web 現在包含構建現代 Web 應用所需的一切，例如：
  • 核心 API 在通用程式碼中運作。
  • 與 HTML 的互操作性，可混合 Compose UI 和原生 Web 元素。
  • 帶有深層連結的型別安全導航。
  • 基本的輔助功能支援和跨瀏覽器兼容性。
• 開發工具方面，可使用 IntelliJ IDEA 或 Android Studio 搭配 Kotlin Multiplatform 插件，提供專案創建、瀏覽器運行與調試等功能。
• 除了 Web，Compose Multiplatform 1.9.0 也帶來了 iOS、桌面和通用程式碼的改進，例如 iOS 上的幀率控制和自定義文字輸入行為，桌面上的新視窗管理功能，以及所有平台上更強大的設計和預覽體驗。

⚙️ Kubernetes v1.34：Pod 層級資源管理功能升級至 Beta

Source: https://kubernetes.io/blog/2025/09/22/kubernetes-v1-34-pod-level-resources/

• Kubernetes v1.34 版本中，Pod Level Resources 功能已升級至 Beta 階段並預設啟用，為 Pod 資源分配提供了新的靈活性。
• 此功能允許為整個 Pod 定義 CPU、記憶體和 Hugepages 資源請求與限制，可與容器層級的資源規格結合使用。
• Pod 層級資源管理的重要性在於：
  • 簡化了多容器 Pod 的資源聲明，減少了精細化、逐容器管理的需求。
  • 促進 Pod 內部容器之間的資源共享，提高利用率，並防止 sidecar 容器成為效能瓶頸。
  • 當同時指定 Pod 層級和容器層級資源時，Pod 層級的請求和限制具有優先權，作為整體資源邊界。
• 範例 Pod YAML 定義：

  apiVersion: v1
  kind: Pod
  metadata:
    name: pod-resources-demo
    namespace: pod-resources-example
  spec:
    resources: # Pod-level resources
      limits:
        cpu: "1" # 整個 Pod 不能使用超過 1 CPU 核心。
        memory: "200Mi" # 整個 Pod 不能使用超過 200 MiB 記憶體。
      requests:
        cpu: "1" # 調度時，Pod 保證 1 CPU 核心。
        memory: "100Mi" # 調度時，Pod 保證 100 MiB 記憶體。
    containers:
    - name: main-app-container
      image: nginx
    - name: auxiliary-container
      image: fedora
      command: ["sleep", "inf"]

• 該功能目前存在一些限制：不支援 v1.34 或更早版本中的 Pod 層級資源原地調整大小；目前僅支援 CPU、記憶體和 hugepages 資源；不支援 Windows Pods；Topology Manager、Memory Manager 和 CPU Manager 暫不支援 Pod 層級資源對齊。

🧠 AI 代理和 LLM 的基礎設施：選項、工具和優化

Source: https://dzone.com/articles/ai-infrastructure-agents-llms-tools-optimization

• 基礎設施（無論是雲端、本地或混合雲）在實現 AI 架構中扮演著關鍵角色，尤其是在推論 (inference) 方面。
• 現代 AI 應用程式需要複雜的基礎設施來處理大型語言模型 (LLMs) 的計算強度、多代理系統的複雜性以及即時應用程式的需求。
• 本文深入探討了部署和優化 AI 代理和 LLMs 的各種基礎設施選項、工具 (包括開源解決方案)，並透過圖表說明推論流程，強調了實現高效、可擴展 AI 部署的關鍵考量。
• 挑戰不僅在於選擇正確的工具，更在於理解它們如何整合到整個技術堆疊中，以提供可靠、可擴展且具成本效益的解決方案。

🔒 MongoDB 多文件事務的隔離級別（強一致性）

Source: https://dzone.com/articles/mongodb-isolation-level-transactions

• 許多關於 MongoDB 事務隔離級別的說法已過時或不精確，這些說法可能基於 MongoDB 4.0 (引入多文件事務) 之前的舊版本。
• 將 MongoDB 的事務隔離映射到 SQL 隔離級別是不合適的，因為 SQL 標準定義忽略了多版本並發控制 (MVCC)，而 MongoDB 等大多數資料庫都利用了 MVCC。
• 文章將運用 Martin Kleppmann 討論並提供的測試來評估事務隔離和潛在異常，以解釋 MongoDB 多文件事務的運作方式並避免這些異常。

🛡️ 如何為 AI 代理構建安全的知識庫整合

Source: https://dzone.com/articles/building-secure-knowledge-base-integrations-ai

• 設計良好的知識庫整合能讓 AI 代理提供具體、上下文豐富的答案，而無需員工自行搜尋大量文件。
• 但如果實作不當，這些整合可能引入安全漏洞和權限錯誤，從而侵蝕使用者信任。
• 軟體開發人員在構建這些整合時面臨的挑戰是，沒有兩個知識庫處理權限的方式是相同的；例如，有的可能在空間層級控制內容，有的在頁面層級，還有的在附件層級。

🤖 使用 ChatGPT API 將 AI 整合到測試自動化框架中

Source: https://dzone.com/articles/ai-test-automation-frameworks-chatgpt-api

• 作者最初預期 AI 在測試自動化中僅限於少數基本用例，但經過實驗發現 ChatGPT API 能在多個方面節省時間並增強測試框架。
• 這些應用包括：
  • 生成真實的測試數據。
  • 在白盒測試中分析日誌。
  • 處理 CI/CD 中的不穩定測試 (flaky tests)。
• ChatGPT API 是 OpenAI 提供的基於 HTTP(s) 協定的程式設計介面，允許發送請求並從預選模型中以原始文本、JSON、XML 或任何其他偏好格式檢索輸出。

🔄 Spring REST API 客戶端演進：從 RestTemplate 到 RestClient

Source: https://dzone.com/articles/resttemplate-to-restclient

• 應用程式之間需要交換數據以進行協作，這種交互通常是透過對話式（如 REST APIs 的同步請求與回應）或異步通知（如事件驅動 APIs 的發送與消費）進行。
• 本文將探討 Spring 框架中用於構建 REST API 客戶端的不同方法，特別關注從傳統的 RestTemplate 到較新的 RestClient 的演進。
• RestTemplate 是 Spring 早期版本中用於同步 HTTP 客戶端通訊的經典類別。
• RestClient 是 Spring Framework 6.1 中引入的新的輕量級、同步 HTTP 客戶端，提供了更現代的 API 和更簡潔的寫法，與 WebClient 有相似的流暢風格，但專注於同步操作。

📊 停止被動式網路故障排除：監控這 5 個指標以預防停機

Source: https://dzone.com/articles/stop-reactive-network-troubleshooting

• 在製造業和醫療保健等關鍵行業中，網路停機不僅帶來不便，更可能造成災難性後果。
• 預防這些底線災難的關鍵在於對網路保持警惕，並持續監控。
• 這需要對關鍵變數進行實時監控：了解哪些核心指標能預測特定環境中的問題，區分正常波動與實際性能問題，並在管理層因 IT 開支提出質疑前，將技術問題轉化為業務影響。
• 文章將重點介紹五個關鍵的網路指標，這些指標有助於主動預測問題並有效防止停機。

☁️ Azure IoT 雲端到設備通訊方法

Source: https://dzone.com/articles/azure-iot-cloud-to-device-communication-methods

• 管理雲端與數百萬智能設備之間的通訊是一個重大挑戰，尤其當設備離線或網路連線不穩定時，確保關鍵訊息的傳遞成為難題。
• Azure IoT Hub 提供三種主要的雲端到設備 (Cloud-to-Device, C2D) 通訊機制：
  • C2D 訊息 (C2D messages): 用於單向通知或輕量級命令。
  • 直接方法 (direct methods): 用於即時的請求-回應互動，例如遠端重新啟動設備。
  • 設備對應項中的所需屬性 (desired properties in the device twin): 用於長期狀態同步和配置管理，即使設備離線也能在重新連線時同步。
• 了解這些方法的細節及其適用場景，對於構建可靠、可擴展且高效的 IoT 解決方案至關重要。

🔍 針對 Amazon OpenSearch 工作負載的實例類型基準測試

Source: https://dzone.com/articles/amazon-opensearch-instance-benchmarking

• 為 Amazon OpenSearch 叢集選擇最佳實例類型，對於平衡性能和成本至關重要。
• AWS 提供了兩種主要選擇：OpenSearch 專用的 OM2 實例和較新的通用型 M7g 實例。
• OM2 實例專為 OpenSearch 量身定制，具有高記憶體與 vCPU 比率，旨在優化 OpenSearch 的效能。
• M7g 實例採用最新技術，承諾提升整體性能，並可能在某些工作負載下提供更好的效益。
• 最佳選擇取決於具體的工作負載特性和需求，例如，高寫入量、查詢複雜度或數據量等。

🔗 不僅僅是鏈條：JGraphlet 用於任務管道

Source: https://dzone.com/articles/jgraphlet-for-taskpipelines

• JGraphlet 是一個微小、零依賴的 Java 庫，專為構建任務管道而設計。
• 其強大之處在於一組核心設計原則，這些原則和諧地協同工作，而非依賴冗長的功能列表。
• JGraphlet 的核心是基於圖 (Graph) 的簡潔性：將任務 (Tasks) 添加到管道中，然後連接它們以創建任務圖。
• 每個任務都有明確的輸入和輸出。
• TaskPipeline 負責構建和執行整個管道，同時管理每個任務的輸入/輸出。這使得任務可以非線性地組織和執行，形成複雜的工作流程。