6 篇文章 含有標籤「JavaScript」

🚀 使用 GitHub Copilot 代理模式現代化 Java 專案的逐步指南​

Source: https://github.blog/ai-and-ml/github-copilot/a-step-by-step-guide-to-modernizing-java-projects-with-github-copilot-agent-mode/

• GitHub Copilot 代理模式將 Copilot 從被動建議工具轉變為主動協作夥伴，能理解高層次指令並執行多步驟任務，無需詳細指示。
• 搭配 GitHub Copilot 應用現代化 VS Code 擴充功能，此工具組提供互動式、逐步指引，幫助開發者更快、更少錯誤地升級和遷移 Java 專案。
• 現代化流程包括：分析專案、生成升級計畫、自動應用變更、修復建構問題、驗證測試、檢測並修復 CVEs，並提供完整的摘要報告。
• 範例指令與程式碼片段：
  • 啟動代理會話後，輸入：

    Using Java upgrade tools,upgrade this project to Java 21. Analyze deprecated APIs, update Gradle dependencies, and propose a safe, testable migration plan.
    

  • 程式碼升級前後對比：

    // Before (deprecated constructor)
    View view = this.resolver.resolveViewName("intro", new Locale("EN"));
    
    // After Java 21 upgrade
    View view = this.resolver.resolveViewName("intro", Locale.of("EN"));
    

• 此外，它還支援將應用程式遷移到 Azure，進行雲端就緒評估，並將認證從地端遷移到 Microsoft Entra ID。
• 自動化 CVE 掃描是其關鍵安全功能，可智慧地提出安全版本替換或推薦替代函式庫，以維持安全合規。

GitHub SSH 存取引入後量子安全 🔒​

Source: https://github.blog/engineering/platform-security/post-quantum-security-for-ssh-access-on-github/

• GitHub 將為其 SSH 端點新增一個後量子安全 SSH 金鑰交換演算法：sntrup761x25519-sha512（或 sntrup761x25519-sha512@openssh.com）。
• 此變更僅影響 SSH 存取，對 HTTPS 存取無影響，也不影響位於美國地區的 GitHub Enterprise Cloud 資料駐留。
• 目的是防範未來量子電腦可能進行的「先儲存，後解密」攻擊，確保資料的長期安全。
• 採用混合式方法，結合了 Streamlined NTRU Prime（一種新的後量子安全演算法）與經典的 Elliptic Curve Diffie-Hellman（使用 X25519 曲線），確保安全性不低於經典演算法。
• 此演算法將於 2025 年 9 月 17 日起在 GitHub.com 和非美國地區的 GitHub Enterprise Cloud 上啟用，並將包含在 GitHub Enterprise Server 3.19 中。
• 大多數現代 SSH 客戶端（例如 OpenSSH 9.0 或更新版本）將自動選擇新演算法，無需手動配置；舊版客戶端將回退到舊演算法。
• 您可以透過執行 ssh -Q kex 來檢查 SSH 客戶端是否支援此演算法，並使用 ssh -v git@github.com exit 2>&1 | grep 'kex: algorithm:' 來查看連接 GitHub 時所使用的金鑰交換演算法。

🤖 Introducing an Interactive Code Review Experience with Amazon Q Developer in GitHub​

Source: https://aws.amazon.com/blogs/devops/introducing-an-interactive-code-review-experience-with-amazon-q-developer-in-github/

• Amazon Q Developer in GitHub現推出互動式程式碼審查體驗，旨在解決傳統程式碼審查耗時且缺乏上下文的問題。
• 新功能包括：
  • Pull Request 中的互動式對話：透過 /q 指令提問或要求 Q Developer 提出程式碼變更建議，例如 /q explain this finding 或 /q propose a change that replaces class toggles with a data attribute for state。
  • 帶有串接發現的程式碼審查摘要：每個審查都以簡潔摘要開始，並將個別發現串接在下方，提升可追蹤性。
  • 更快的執行與清晰的通知：縮短等待時間，加快審查週期。
• 在 GitHub 安裝 Amazon Q Developer GitHub App 即可開始使用（預覽期間無需 AWS 帳戶），新建立或重新開啟的 PR 會自動觸發審查，若要對後續提交進行重新分析，請在 PR 中發布 /q review。

💡 使用 MCP 引導機制打造更智能的互動：從繁瑣的工具呼叫到流暢的使用者體驗​

Source: https://github.blog/ai-and-ml/github-copilot/building-smarter-interactions-with-mcp-elicitation-from-clunky-tool-calls-to-seamless-user-experiences/

• 本文探討了如何透過 MCP (Multi-Modal Chat Protocol) 中的引導 (elicitation) 機制，改進 AI 應用（如 GitHub Copilot）與使用者的互動體驗，使其更加自然和無縫。引導機制讓 AI 在缺少必要資訊時能主動暫停並提問，而非僅依賴預設值。
• 範例應用: 在建立回合制遊戲（如井字遊戲、剪刀石頭布）時，若使用者未提供難度、玩家名稱或先手順序等資訊，AI 會透過引導機制提問，而不是直接使用預設值。
• 實作挑戰與解決方案:
  • 工具命名混淆: 過去因工具名稱相似（如 create-tic-tac-toe-game 與 create-tic-tac-toe-game-interactive），導致 AI 選錯工具。解決方案是合併工具並使用清晰、獨特的名稱（例如：將八個工具縮減為 create-game、play-game、analyze-game、wait-for-player-move）。
  • 處理部分資訊: 直播時發現引導機制會重複詢問所有偏好，即使部分資訊已提供。修復方式是在工具被呼叫後檢查已提供的資訊，只引導詢問缺失的部分。
• 內部工作原理: MCP 伺服器在呼叫 create_game 工具時，會檢查所需參數、將選用參數傳遞給獨立方法、若資訊缺失則啟動引導機制、呈現基於 schema 的提示、收集回應，最終執行 createGame 方法。
• 重要學習: 使用者體驗、工具命名清晰度和迭代開發對於建立更優質的 AI 工具至關重要。

🧠 混合式 AI 已來臨，並在 Docker 中運行​

Source: https://www.docker.com/blog/hybrid-ai-and-how-it-runs-in-docker/

• 核心概念: 混合式 AI (Hybrid AI) 結合了強大的雲端模型（監督者，Supervisor）與高效的本地模型（小兵，Minions），在效能、成本和隱私之間取得平衡，解決了 GenAI 應用在處理大型文件或複雜工作流程時，品質與成本之間的權衡問題。
• Minions 協議: 遠端模型（Supervisor）不直接處理所有數據，而是生成可執行程式碼來分解任務；本地模型（Minions）在 Docker 容器中執行這些平行子任務；遠端模型最終聚合結果。
• Docker 化實作範例:
  • 使用 docker compose up 啟動 Minions 應用伺服器。
  • 遠端模型接收請求，生成協調程式碼。
  • 協調程式碼在 Docker 容器內的 Minions 應用伺服器中執行，提供沙盒隔離。
  • 本地模型平行處理子任務（如分析文件塊、摘要、分類）。
  • 結果返回給遠端模型進行彙總。
• 優勢:
  • 成本降低: 本地模型處理大部分 tokens，顯著減少雲端模型使用量（MinionS 協議可降低 5.7 倍成本，同時保持 97.9% 效能）。
  • 可擴展性: 將大型任務分解為小型任務，可在本地模型間水平擴展。
  • 安全性: 應用伺服器在 Docker 容器中運行，提供沙盒隔離，確保動態協調的安全性。
  • 開發者簡便性: Docker Compose 將所有配置整合到單一檔案，無需複雜環境設定。
• Docker Compose 配置範例:

  models:
    worker:
      model: ai/llama3.2
      context_size: 10000
  

  此配置可啟動一個運行 Llama 3.2 模型並擁有 10k 上下文視窗的本地 worker。
• 權衡: 儘管顯著降低雲端成本，但由於任務拆分、本地處理和聚合，回應時間可能會較慢（約 10 倍）。

🔍 靜態程式碼分析提升開發者體驗的五種方式​

Source: https://blog.jetbrains.com/qodana/2025/09/improve-developer-experience/

• 靜態程式碼分析 (Static Code Analysis) 是一種強大的工具，無需運行程式碼即可檢查潛在問題，從而減少開發人員的摩擦，使他們能更專注於解決問題。
• 提升開發者體驗的五種方式:
  1. 更快的反饋循環: 直接整合到開發環境或 CI/CD 管線中，提供即時的錯誤、風格違規和安全漏洞洞察，讓開發者在編碼時就能即時修復問題。
  2. 降低認知負荷: 作為安全網，自動捕捉程式碼標準違規、不安全結構，並提醒最佳實踐，減少記憶所有規範的心理負擔。
  3. 改進程式碼品質和一致性: 強制專案的編碼標準，確保一致性和可讀性；檢測常見錯誤模式，如空指針解引用、未初始化變數。
  4. 整個生命週期的時間節省: 在開發早期階段捕獲問題，大幅降低發布後修復缺陷的成本；透過預過濾瑣碎問題，讓程式碼審查更專注於架構和邏輯。例如，Qodana 提供的快速修復功能能節省大量時間。
  5. 與現代開發者體驗工具整合: 與 CI/CD 管線整合，建立自動化的品質門禁；與 IDE 整合，提供即時回饋；甚至可將發現結果與合規標準對齊。
• 結論: 靜態程式碼分析不僅是錯誤捕獲工具，更是改善開發者體驗、提高生產力和交付更高品質軟體的關鍵。

🛠️ ReSharper 與 Rider 2025.2.1 更新與修正已發布！​

Source: https://blog.jetbrains.com/dotnet/2025/09/04/resharper-and-rider-2025-2-1-is-out/

• JetBrains 發布了 ReSharper 和 Rider 2025.2 的首個錯誤修復更新，帶來了重要的修正和品質改進，以及針對性的效能優化。
• ReSharper 2025.2.1 關鍵更新:
  • Unity 支援整合至命令列工具 (CLT): ReSharper 的 Unity 專屬檢查和清理規則現在可以在 inspectcode 和 cleanupcode 等命令列工具中運行，確保 IDE 和 CI/CD 管線之間的一致性。
  • 重要修正:
    • ReSharper C++ 在獨立安裝時可在 Out-of-Process (OOP) 模式下運行。
    • C++ 單元測試可在 OOP 模式下執行。
    • Search Everywhere 對話框即使在解決方案未完全載入的情況下也能在 OOP 模式中獲得焦點。
    • 恢復了 OOP 模式下 IDE 快捷鍵的正確行為。
    • 修復了 Visual Studio 觸發 ReSharper 動作或開啟擴充功能選單後可能凍結的問題。
    • 恢復了異步上下文中程式碼自動完成的正確行為。
• Rider 2025.2.1 關鍵更新:
  • 單元測試: 單元測試探查器不再顯示重複條目，包括 xUnit 專案。
  • 偵錯: 使用嵌入式偵錯符號時，Edit & Continue 功能恢復正常；修復了偵錯器在異常處停止但不允許恢復執行的問題。
  • AI 助手: 修復了 AI 助手在 C# 專案中可能生成 C++ 程式碼片段的問題。
  • 其他修正: Encapsulate Field 重構快捷鍵恢復；GDScript 檔案正確識別；環境變數中的分號值處理問題；Frame Viewer 相關修復；Create Branch 操作的可用性恢復；Windows 上 Dynamic Program Analysis (DPA) 快照檔案未清理的問題；macOS 上 Monitoring 工具視窗的 CPU 使用率優化。
• 下載方式: 可透過 JetBrains 網站或 Toolbox App 下載最新版本。

🗓️ JetBrains JavaScript Day 2025 開放報名​

Source: https://blog.jetbrains.com/webstorm/2025/09/jetbrains-javascript-day-2025-registration-is-now-open/

• JetBrains 宣布第五屆年度 JavaScript Day 免費線上活動已開放報名。
• 活動資訊:
  • 日期: 2025 年 10 月 2 日
  • 時間: 美東時間上午 9:00 / 中歐夏令時間下午 3:00
  • 地點: 線上舉行
  • 費用: 免費
• 活動內容: 將匯集 JavaScript 領域具啟發性的講者，分享他們的故事、想法和經驗教訓，提供實用的見解，幫助參與者在快速發展的 JavaScript 生態系統中保持領先。
• 部分講者與主題包括:
  • Craig Spence: Quantumania.js
  • Alexander Lichter: Faster Builds and Fewer Headaches with Modern JavaScript Tooling
  • Victor Savkin: Beyond Build Orchestration: What It Takes to Build Modern JavaScript Monorepos
  • Kent C. Dodds: The New User Interaction Model
  • Ryan Carniato: Beyond Signals
  • Jan-Niklas Wortmann: JetBrains Doesn’t Want Me To Give This Talk
  • Lydia Hallie: Bun: The Fast JavaScript Runtime
  • Jessica Janiuk: Tough Decisions: the complexities of maintaining a popular open source project

✨ Kotlin 2.2 改善註解處理：減少樣板程式碼，減少意外​

Source: https://blog.jetbrains.com/idea/2025/09/improved-annotation-handling-in-kotlin-2-2-less-boilerplate-fewer-surprises/

• Kotlin 2.2 針對註解處理進行了改進，解決了與 Spring 或 JPA 等框架協作時，註解行為可能不如預期的問題，減少了樣板程式碼並帶來更可預測的行為。
• 過去問題: 在 Kotlin 2.2 之前，諸如 @NotBlank 或 @Email 等註解若應用於建構函式參數，預設只會應用到參數本身 (@param)。這意味著屬性驗證只在物件首次創建時發生，而不會在後續屬性更新時觸發。

  public class Order {
    @Id @GeneratedValue private final long id;
    @NotNull private String name;
    @NotNull private String email;
    public Order(long id, @NotBlank @NotNull String name, @Email @NotNull String email) { /* ... */ }
  }
  

• 舊的解決方案: 必須明確指定 use-site target，如使用 @field: 來確保註解應用於底層欄位或屬性，這增加了程式碼的冗餘。

  @Entity
  class Order(
      @field:Id @GeneratedValue val id: Long,
      @field:NotNull var name: String,
      @field:Email var email: String
  )
  

• Kotlin 2.2 的新預設行為:
  • 自 Kotlin 2.2 起，沒有明確指定 use-site target 的註解將同時應用於建構函式參數和屬性/欄位，與大多數框架的預期行為保持一致。
  • 原始的簡潔程式碼現在能如預期般工作，無需額外的 @field: 語法。

  @Entity
  class Order(
      @Id @GeneratedValue val id: Long,
      @NotBlank var name: String,
      @Email var email: String
  )
  

• 如何啟用新行為:
  • 需要 Kotlin 2.2。預設情況下，編譯器會針對行為可能改變的程式碼發出警告。
  • 在 build.gradle.kts 中添加以下編譯器選項以完全啟用新行為：

    kotlin {
        compilerOptions {
            freeCompilerArgs.add("-Xannotation-default-target=param-property")
        }
    }
    

  • 若想保留舊行為或過渡模式，可使用 -Xannotation-defaulting=first-only 或 -Xannotation-defaulting=first-only-warn。
• 重要性: 此改變使註解行為更具可預測性，減少樣板程式碼，並消除了 Spring 和 JPA 開發人員多年來面臨的一類潛在錯誤，提升了 Kotlin 與主流框架的整合體驗。

🤝 如何利用 AI 增強 Scrum 儀式​

Source: https://dzone.com/articles/ai-enhance-scrum-ceremonies

• Scrum 作為主流的敏捷開發方法，其核心儀式包括衝刺規劃、每日站會、衝刺審查和衝刺回顧，旨在促進協作、對齊和交付。
• Gartner 的報告指出，87% 執行敏捷開發的組織採用 Scrum。
• 人工智慧 (AI) 透過應用進階分析和基於邏輯的技術（包括機器學習），可以解釋事件、支持和自動化決策並採取行動，從而增強這些 Scrum 儀式，提升其效率和洞察力。

🔒 在 LLM 應用中保護 PII：資料匿名化的完整指南​

Source: https://dzone.com/articles/llm-pii-anonymization-guide

• 組織渴望利用大型語言模型 (LLM) 解決業務問題，但對於將敏感資料（特別是個人身份資訊 PII）傳輸到第三方託管模型存在顧慮。
• 本文探討了一種強大的緩解技術：資料匿名化 (anonymization) 與去匿名化 (de-anonymization)，以在保護敏感資料的同時，有效利用企業環境中的 LLM。

🔗 供應鏈攻擊時代的 CI/CD：如何保護每個提交​

Source: https://dzone.com/articles/ci-cd-pipeline-security-supply-chain

• 數位基礎設施的脆弱性日益顯現，一次受損的依賴、惡意提交或被忽視的漏洞都可能導致整個系統崩潰。例如，2024 年 3 月發現的 XZ Utils 後門事件，凸顯了精心策劃的供應鏈攻擊對開源開發基礎的威脅。
• 本文強調在 CI/CD (持續整合/持續交付) 管道中保護每一個提交的重要性，呼籲業界應將供應鏈安全視為必須解決的關鍵問題，以應對日益複雜的網路攻擊。

🤔 建立 AI 代理前需問的 5 個關鍵問題​

Source: https://dzone.com/articles/agentic-ai-questions-adoption

• 代理式 AI (Agentic AI) 正在改變遊戲規則，但公司在急於建構或部署 AI 代理之前，必須提出一些關鍵問題。
• 並非所有問題都需要 AI 代理來解決，如果沒有正確的基礎，尤其是在資料方面，代理式 AI 可能會迅速變成一個昂貴且高風險的錯誤。
• 本文旨在引導組織在自動化代理式 AI 之前進行深思熟慮的規劃，避免資源浪費和錯失機會。

💰 手動 K8s 成本優化的無止境循環耗費組織巨大成本​

Source: https://dzone.com/articles/the-endless-cycle-of-manual-k8s-cost-optimization

• Kubernetes (K8s) 的開發人員和 DevOps 團隊通常將重心放在效能上，而對成本方面關注較少。當工作負載運行順暢並符合服務級別協議 (SLA) 時，預算考量往往退居次位，直到外部壓力（通常來自財務團隊）要求進行優化。
• 然而，忽略成本直到財務介入的現實，會導致效率低下和資源浪費，最終耗費大量時間和精力於成本優化，這些時間本可以用於其他戰略性計畫。這強調了需要更主動、系統化的 K8s 成本管理方法。

🚀 將 AI 帶出孤島——為何團隊經驗超越開發者工具​

Source: https://dzone.com/articles/rethinking-ai-team-productivity

• 許多 AI 實作僅專注於單一步驟的局部優化，而忽略了團隊協作的整體情境。本文認為，在設計產品時，最佳方法是重新構想問題，而非僅做漸進式改進。
• 質疑為何在 AI 作為近年來最大的技術創新時，許多產品卻仍專注於單獨改進每個步驟，而不是從團隊協作的角度來完成工作。
• 提倡將 AI 應用從孤立的個人工具提升到促進團隊生產力和整體體驗的層面，強調團隊經驗在充分發揮 AI 潛力方面的重要性。

🚀 GitHub Copilot AI 模型進化與多模型架構​

Source: https://github.blog/ai-and-ml/github-copilot/under-the-hood-exploring-the-ai-models-powering-github-copilot/

• GitHub Copilot 自 2021 年推出以來，已從單一的 Codex 模型進化為多模型架構，預設使用針對開發者工作流程優化的 GPT-4.1。
• 為了應對快速變化的 AI 環境，Copilot 採用多模型架構，讓開發者能根據任務需求選擇不同的 LLM，提供更高的靈活性。
• 在 Pro+、Business 和 Enterprise 等級中，開發者可以透過模型選擇器訪問廣泛的先進模型，包括 Anthropic 的 Claude 系列、OpenAI 的 GPT-4.1、GPT-5 (預覽) 及 Google 的 Gemini 2.0 Flash、Gemini 2.5 Pro 等。
• Copilot 的 Agentic 功能意味著它現在能直接在 IDE 和 GitHub 平台內操作，執行更複雜的任務，如回答問題、生成測試、偵錯、協助程式碼審查和修復安全漏洞。
• 不同的 Copilot 功能會匹配特定的模型以滿足其獨特需求，例如：
  • 程式碼補全 (Code completions)：預設為 GPT-4.1，針對速度、準確性和相關性進行優化。
  • Agent 模式 (Agent mode)：預設為 GPT-4.1，但可選擇其他先進模型來處理多步驟複雜任務。
  • Copilot Chat：預設為 GPT-4.1，並可選擇 Claude 或 Gemini 等模型進行自然語言查詢。
  • Coding agent (新)：將 Copilot 轉變為可委派任務的助手，處理問題分類、生成 Pull Request、修補漏洞等。
  • 程式碼審查 (Code review (新))：由 GPT-4.1 提供支援，並可選擇 Claude 等模型進行深度推理。
• 最近的升級將 Copilot Chat、程式碼補全和 Pull Request 摘要都整合到 GPT-4.1，帶來約 40% 更快的響應速度和更大的上下文視窗。

加速 Docker 強化映像的 FedRAMP 合規性 🚀​

Source: https://www.docker.com/blog/fedramp-compliance-with-hardened-images/

• FedRAMP 合規挑戰： 聯邦風險與授權管理計畫 (FedRAMP) 合規成本高昂（45 萬至 200 萬美元以上），且需耗時 12 至 18 個月，這期間競爭對手可能已搶佔政府合約。企業需面對 NIST SP 800-53 中超過 400 項嚴格的安全控制要求。
• Docker 強化映像 (DHI) 解決方案： Docker 硬化映像提供自動化、可稽核的安全解決方案，旨在加速 FedRAMP 合規流程並降低維護成本。DHI 是一系列精簡的映像，持續更新以確保幾乎沒有已知的 CVE。
• FIPS 140 合規性： DHI 支援 FIPS 140 驗證的密碼學模組，預配置並經過測試，可確保正確功能。每個 FIPS 合規映像都附有簽名的證明，列出使用的 FIPS 驗證軟體及其 CMVP 認證和測試結果連結，支援 OpenSSL、Bouncy Castle 和 Go 等主要開源密碼學模組。
• STIG 強化映像： Docker 根據國防信息系統局 (DISA) 發布的通用作業系統 (GPOS) SRG，創建了客製化的容器 STIG。STIG 強化映像在安全建構過程中會使用 OpenSCAP 進行掃描，結果會作為簽名證明提供，其中包含易於查看的 STIG 合規分數，並支援輸出為 HTML 和 XCCDF 格式，便於稽核。
• 持續合規性：
  • 漏洞減少： DHI 起始攻擊面減少高達 95%（按包數量計算），持續更新以確保幾乎沒有已知 CVE，並掃描病毒和機密。
  • 漏洞檢測與修復： Docker 持續監控 CVE 來源，DHI 對嚴重/高風險漏洞的修復 SLA 為 7 天，中/低風險為 30 天，幫助滿足 FedRAMP 修復時限。提供 VEX (Vulnerability Exploitability eXchange) 證明來過濾不適用漏洞。
  • 供應鏈透明度： DHI 使用 SLSA Build Level 3 安全建構管道，確保建構可驗證性與防篡改。提供簽名證明和多種 SBOM 格式。
  • 稽核證據： DHI 證明符合 in-toto 證明標準，作為 provenance、資產管理、漏洞掃描及 FIPS 合規性的安全證據。