ThoughtWorks:技術雷達-有態度的前沿技術解析(第28期)(43頁).pdf

編號:124888 PDF 43頁 2.45MB 下載積分:VIP專享
下載報告請您先登錄!

ThoughtWorks:技術雷達-有態度的前沿技術解析(第28期)(43頁).pdf

1、 Thoughtworks,Inc.All Rights Reserved.1有態度的前沿技術解析第 28 期技術雷達 Thoughtworks,Inc.All Rights Reserved.2關于技術雷達 3雷達一覽 4貢獻者 5本期主題 6The Radar 8技術 11平臺 19工具 26語言和框架 36Thoughtworks Technology Radar Thoughtworks,Inc.All Rights Reserved.Thoughtworks 技術雷達關于技術雷達Thoughtworker 酷愛技術。我們為每個人建造技術,研究技術,測試技術,開源技術,書寫技術,并不斷

2、致力于改進技術。我們的使命是支持卓越軟件并掀起 IT 革命。我們創建并分享 Thoughtworks 技術雷達就是為了支持這一使命。由 Thoughtworks中一群資深技術領導組成的 Thoughtworks 技術顧問委員會創建了該雷達。他們定期開會討論Thoughtworks 的全球技術戰略以及對行業有重大影響的技術趨勢。技術雷達以獨特的形式記錄技術顧問委員會的討論結果,從首席技術官到開發人員,雷達為各路利益相關方提供價值。這些內容只是簡要的總結。我們建議您探究這些技術以了解更多細節。技術雷達的本質是圖形性質,把各種技術項目歸類為技術、工具、平臺和語言和框架。如果技術可以被歸類到多個象限,

3、我們選擇看起來最合適的一個。我們還進一步將這些技術分為四個環以反映我們目前對其的態度。Thoughtworks,Inc.All Rights Reserved.4Thoughtworks 技術雷達技術雷達是具有前瞻性的。為了給新的技術條目騰出空間,我們挪出了近期沒有發生太多變化的技術條目,但略去某項技術并不表示我們不再關心它。暫緩評估試驗采納采納:我們強烈主張業界采用這些技術。我們會在適當時候將其用于我們的項目。試驗:值得追求。重要的是理解如何建立這種能力。企業應該在風險可控的項目中嘗試此技術。評估:為了確認它將如何影響你所在的企業,值得作一番探究。暫緩:謹慎推行新的挪進/挪出沒有變化雷達一覽

4、技術雷達持續追蹤有趣的技術是如何發展的,我們將其稱之為條目。在技術雷達中,我們使用象限和環對其進行分類,不同象限代表不同種類的技術,而環則代表我們對它作出的成熟度評估。軟件領域瞬息萬變,我們追蹤的技術條目也如此,因此您會發現它們在雷達中的位置也會改變。Thoughtworks,Inc.All Rights Reserved.5貢獻者技術顧問委員會(TAB)由 Thoughtworks 的 21 名高級技術專家組成。TAB 每年召開兩次面對面會議,每兩周召開一次視頻會議。技術顧問委員會由 Thoughtworks 首席技術官 Rebecca Parsons 組建。作為一個綜合型組織,TAB 能夠

5、審視影響 Thoughtworks 技術和技術人員的各種主題。本期技術雷達內容基于2023 年 3 月的 TAB 線上會議創建。Rebecca Parsons(CTO)Camilla Falconi CrispimJames LewisScott ShawMartin Fowler(Chief Scientist)Erik DrnenburgMarisa HoenigSelvakumar NatesanShangqi LiuSofia TaniaVanya SethBharani SubramaniamFausto de la TorreMike MasonMaya OrmazaBirgitt

6、a BckelerHao XuNeal FordPawan ShahBrandon ByarsIan Cartwright中國區技術雷達漢化組:陳鋒|李輝|婁麒麟|嚴嘉陽|邊曉琳|程博|程顯通|董翔銳|樊卓文|馮煒|符雨菡|高曉明|高玉山|郭晨|何蜜|何蔚 何向東|蔣亦雄|李光正|李康寧|李思遠|李天舒|李妍|梁晶|廖燊|盧冠昀|馬宇航|任旭東|沈哲宇|蘇曉風|孫郁儼 索云清|陶慧|田鵬|童圣|王啟瑞|王芹芹|王浠嬋|肖森元|邢硯敏|邢硯敏|熊欣|楊陽|于海源|余琦|張麗|張雙海 張旭海|鄭茗蔓 Thoughtworks,Inc.All Rights Reserved.6實用人工智能的飛速崛起

7、別多想,這篇主題文章并非由 ChatGPT 撰寫。人工智能已經在專業領域默默醞釀了幾十年,像 GitHub Copilot這樣的工具在幾年前就已經存在(并逐漸被采用)了。然而,在過去幾個月里,類似 ChatGPT 這樣的工具已經徹底改變了人們對人工智能的認識,并使得這類工具開始被廣泛使用。本期技術雷達中有幾個條目涉及到了 AI在項目上的實際應用,不僅僅是關于代碼建議的范疇:基于 AI 輔助的測試先行開發、使用 AI 幫助構建分析模型等。類似于電子表格能夠讓會計師停止用計算器手動重新計算復雜表格,下一代的 AI 會承擔起替換需要知識(而不是智慧)的乏味任務,來解放技術從業者包括開發人員。不過,我

8、們提醒不要過度或不當使用人工智能?,F今,AI 模型能夠生成一個良好的初稿。但生成的內容始終需要由人類監測、驗證、審查和負責任地使用。如果忽視這些預警,機構和用戶可能面臨名譽和安全風險。甚至有些產品用例也提醒用戶,“AI 生成的內容可能存在錯誤。在使用前請確保它的正確性和合理性”。易用的無障礙設計多年來,無障礙設計一直是組織重視的因素。最近,我們著重展示了我們的團隊在工具和技術方面經驗的增長,這些經驗使開發具備了更好的無障礙設計。我們幾個地區的團隊通過宣傳活動增強了對這些技術的認知。我們在持續集成流水線開發、設計中的無障礙注解、智能引導無障礙測試、靜態檢查和單元測試方面,提出了與無障礙設計相關的

9、條目。我們很愿意看到人們越來越重視這個主題,為更多的人提供改進后的功能訪問方式,這些技術毫無疑問是優秀的。Lambda 陷阱無服務器函數 AWS Lambdas 越來越頻繁地出現在架構師和開發者的工具箱中,并被用于實現各種基于于云基礎架構的任務。然而,就像許多有用的東西一樣,有時候解決方案開始時簡潔實用,但隨著不斷成功、持續演進,最終違反范式中規定的約束、變得沉重不堪,終遭棄用。在看到許多無服務器風格解決方案成功應用的同時,我們也從項目中聽到了許多警示性的故事,比如 Lambda 彈球反模式。雖然出現了很多解決這些問題的工具,但是這些工具極易被誤用。例如,幫助 Lambda 之間共享代碼或協調

10、復雜互動的工具,它可能可以解決一個簡單常見的問題,但隨著新的構建模塊的加入就會面臨出現低劣架構模式的風險。如果您需要一個工具來管理跨無服務器函數集合的代碼共享和獨立部署,那么也許是時候重新思考該方法的適用性了。像所有的技術解決方案一樣,無服務器有其適宜的應用場景,但它的許多功能在使用時都需要權衡利弊,這種情況隨著解決方案的演進會更加突出。本期主題 Thoughtworks,Inc.All Rights Reserved.7數據分析和人工智能中的工程嚴謹性我們始終認為“質量內建”是開發可靠的數據分析與機器學習模型的重要因素。測試驅動的數據轉化,數據健全測試和數據模型測試使數據流水線可以更有力的支

11、持分析系統。機器學習系統需要模型驗證和質量控制來確保結果符合倫理,平等無偏見。通過整合這些實踐,企業能更好地利用人工智能和機器學習,基于各自的用戶群體打造負責任、數據驅動的解決方案。相關的工具生態也在不斷演進,日趨成熟。例如,Soda Core 是一個在接收數據伊始就開始驗證并自動監測異常的數據質量工具,Deepchecks 結合了持續集成和模型檢查,將好的工程實踐融入分析系統。Giskard 對 AI 模型進行質量控制,可以檢查模型的偏見等其他負面因素,這與我們提倡的在開發 AI 解決方案時關注倫理的理念相符。我們認為這些逐漸成熟的工具可以證明,數據分析、人工智能與良好的工程實踐相結合正在成

12、為主流。聲明,還是編程?每次技術雷達討論時都會發生的,好像永無止境的話題在這次會議變得格外激烈對于給定的任務,應該使用 JSON、YAML 或者像 HCL 這樣的領域特定語言來編寫聲明性規范,還是應該在通用編程中編寫代碼語言?例如,我們討論了 Terraform Cloud Operator 與 Crossplane 的區別,在其他情況下對部署流水線進行編程時,是否使用 AWS CDK 或 Dagger。聲明性規范雖然通常更易于閱讀和編寫,但其有限的抽象會導致重復代碼的產生。適當的編程語言可以使用抽象來避免重復,但這些抽象會讓代碼變得更難理解,特別是當抽象經過多年的變化而分層時。根據我們的經驗

13、,上述問題沒有標準答案。這兩種方法團隊都應該考慮,當一個解決方案無法用一種語言類型去簡潔的實現時,就應該重新評估使用另一種類型。有些時候拆分關注點并用不同的語言實現它們會更加合理。Thoughtworks,Inc.All Rights Reserved.81421232631323327343536373844394041424328287510112012131415161722181937661596057555250474864656667686970717273747578777953514946929394959697989910010110210310410510610783828

14、48586918987242530298088908169455658626354暫緩暫緩評估評估試驗試驗采納采納The Radar新的挪進/挪出沒有變化 Thoughtworks,Inc.All Rights Reserved.采納1.將產品管理思維應用于內部平臺2.將 CI/CD 基礎設施作為一種服務3.精簡軟件依賴項4.將運行成本作為架構健康度的考量試驗5.設計中的無障礙注解6.有限界的使用低代碼平臺7.對僅提供 API 的產品的演示前端8.Lakehouse 架構9.可驗證憑證評估10.無障礙意識的組件測試設計11.基于 AI 輔助的測試驅動開發12.領域特定的大型語言模型13.智能引

15、導無障礙測試14.使用 Logseq 構建團隊知識庫15.提示工程16.測試基礎設施時的可達性分析17.自托管式大型語言模型18.管理技術健康狀況優先于技術債務19.CI/CD 的零信任保護暫緩20.對 Webhooks 的管理不夠嚴謹21.Lambda 彈球22.竭盡全力的計劃采納23.Contentful24.GitHub Actions25.K3s試驗26.Apache Hudi27.云上 Arm28.Ax29.DuckDB30.特征庫31.RudderStack32.Strapi33.TypeDB評估34.Autoware35.Cozo36.Dapr37.Immuta38.Matter

16、39.Modal40.Neon41.OpenLineage42.Passkeys43.Spin暫緩44.Denodo 作為主要的數據轉換工具技術平臺The Radar Thoughtworks,Inc.All Rights Reserved.采納45.DVC試驗46.Akeyless47.Apicurio Registry48.EventCatalog49.FOSSA50.Gitleaks51.Helmfile52.IBM Equal Access Accessibility Checker53.Ktlint54.Kubeflow55.Mend SCA56.Mozilla SOPS57.Ruf

17、f58.Soda Core59.Steampipe60.Terraform Cloud Operator61.TruffleHog62.Typesense63.Vite評估64.axe Linter65.ChatGPT66.DataFusion67.Deepchecks68.設計令牌翻譯工具69.Devbox70.Evidently71.Giskard72.GitHub Copilot73.iamlive74.Kepler75.Kubernetes External Secrets Operator76.Kubeshark77.Obsidian78.Ory Kratos79.Philips 的

18、自我托管 GitHub 運行器暫緩采納80.Gradle Kotlin DSL81.PyTorch試驗82.dbt 單元測試83.Jetpack CameraViewfinder84.Jetpack DataStore85.Mikro ORM86.按應用設定的語言偏好設置87.Quarto88.River89.Stencil90.Synthetic Data Vault91.Vitest評估92.NET 7 Native AOT93.NET MAUI94.dbt-expectations95.Directus96.Ferrocene97.Flutter 嵌入式平臺98.Fugue99.Gala

19、cean Engine100.LangChain101.mljar-supervised102.nanoGPT103.pandera104.Qwik105.SolidJS106.Turborepo107.WebXR 設備 APIHold 暫緩工具語言和框架The Radar Thoughtworks,Inc.All Rights Reserved.技術142123263132332734353637384439404142432828751011201213141516172218193766159605755525047486465666768697071727374757877795351

20、494692939495969798991001011021031041051061078382848586918987242530298088908169455658626354暫緩暫緩評估評估試驗試驗采納采納采納1.將產品管理思維應用于內部平臺2.將 CI/CD 基礎設施作為一種服務3.精簡軟件依賴項4.將運行成本作為架構健康度的考量試驗5.設計中的無障礙注解6.有限界的使用低代碼平臺7.對僅提供 API 的產品的演示前端8.Lakehouse 架構9.可驗證憑證評估10.無障礙意識的組件測試設計11.基于 AI 輔助的測試驅動開發12.領域特定的大型語言模型13.智能引導無障礙測試14.

21、使用 Logseq 構建團隊知識庫15.提示工程16.測試基礎設施時的可達性分析17.自托管式大型語言模型18.管理技術健康狀況優先于技術債務19.CI/CD 的零信任保護暫緩20.對 Webhooks 的管理不夠嚴謹21.Lambda 彈球22.竭盡全力的計劃新的挪進/挪出沒有變化 Thoughtworks,Inc.All Rights Reserved.12技術1.將產品管理思維應用于內部平臺采納我們持續從那些將產品管理思維應用于內部平臺的團隊獲得良好的反饋。不過,要記住一個關鍵特征:這不只是關于團隊結構或重命名已有的平臺團隊;它還涉及到在團隊中應用以產品為中心的工作實踐。具體來說,我們收

22、到的反饋表明,除非團隊具有以產品為中心的思維方式,否則他們在使用此技術時將面臨挑戰。這可能意味著需要額外的角色,比如產品經理,以及對其他領域的改變,比如需求收集和對成功的衡量。以這種方式工作意味著與內部消費者(開發團隊)建立同理心并且在設計上與他們合作。平臺產品經理制定路線圖并確保平臺為業務帶來價值和增強開發人員的體驗。我們會繼續將這項技術視為構建內部平臺的關鍵,以求快速而高效地推出新數字解決方案。2.將 CI/CD 基礎設施作為一種服務采納將 CI/CD 基礎設施作為一種服務已經是很多元化以及成熟的方案,以至于需要自己管理整個 CI 基礎設施的情況變得非常少見。使用 GitHub Actio

23、ns、Azure DevOps 或 Gitlab CI/CD 等管理服務,具有托管云服務的所有常見優勢(和權衡)。您不需要花時間、精力和硬件成本來維護和運營這個通常很復雜的基礎設施。對于自己托管CI 設施的公司,雖然團隊可以受益于彈性和自助服務,然而往往在配置更多合適的代理或獲得新的插件或功能時遇到瓶頸。即使是需要在自己的硬件上運行構建和驗證的用例,現在也大多可以用自我托管的運行器來滿足需求(我們已經寫過一些關于 GitHub Actions 的文章,actions-runner-controller 和 Philips 的自我托管 GitHub運行器)。然而,請注意,使用托管服務并不意味著您

24、可以輕易獲得安全保障;雖然成熟的服務提供了所需要的所有安全功能,但仍然需要實施對 CI/CD 基礎架構的零信任安全。3.精簡軟件依賴項采納初始工具包和模板被廣泛用于軟件項目以加快初始設置,但它們可能會為項目引入許多不必要的依賴項。實踐依賴裁剪很重要定期仔細檢查這些依賴并剔除未使用的依賴,這有助于減少構建和部署時間,并且可以通過移除潛在漏洞來降低項目受攻擊的風險。盡管這不是一項新技術,但鑒于對軟件上下游的攻擊頻率越來越高,我們提倡重新關注它。4.將運行成本作為架構健康度的考量采納自動估算、跟蹤和預測云基礎設施運行成本對于今天的組織至關重要。云服務商精心設計的定價模型,加上價格參數的不斷增多以及持

25、續變化的架構,可能會導致運行成本超出預算。盡管這種技術已經在 2019 年后被采用,我們仍然想強調考慮將運行成本作為架構健康度的考量的重要性,特別是在云服務被廣泛采用和 FinOps 實踐越來越受到關注的今天。許多商業平臺提供了工具來協助企業的負責人人整合并說明云服務的成本。其中一些旨在向財務機構或原始業務單位顯示云服務運行成本。然而,云服務消費決策通常是在系統設計時做出。因此 Thoughtworks,Inc.All Rights Reserved.13在做出設計決策時使用一些方法來預測其架構決策對成本產生的影響就顯得很重要。一些團隊會在開發進程的初期通過自動化方式預算成本。像 Infrac

26、ost 這樣的工具可以幫助團隊在考慮更改“基礎設施即代碼”時預測成本影響,這種計算可以自動化執行,并納入持續集成(CD)流程中。請注意,成本將受架構決策和實際使用水平的影響;要做到這一點,您需要對期望使用水平進行審慎地預測。及早和頻繁地反饋運行成本可以防止其失控。當預測成本偏離了預期或可接受的范圍時,團隊可以討論是否是時候進一步調整架構了。5.設計中的無障礙注解試驗在軟件交付中越早考慮無障礙,就能越簡單、更低成本的保證交付物對盡可能多的人可用。設計中的無障礙注釋工具能促進溝通,幫助團隊從工作的開始就考慮到文檔結構、語義化的 HTML 和替代文本等重要的元素。這使得團隊確保用戶界面符合國際無障礙

27、標準,并解決那些實際上很容易避免的常見無障礙問題。Figma 提供了一系列的無障礙性注釋插件:The A11y Annotation Kit,Twitter 的 Accessibility Annotation Library 和 Axe的工具集 Axe for Designers。6.有限界的使用低代碼平臺試驗我們一直倡導寫盡可能少的代碼。簡潔是我們在軟件開發時篤信的核心價值之一。例如,我們盡量不預測未來的需求,只實現滿足當前業務需求的代碼,而不考慮其他內容。創建工程平臺是一個在組織層面上實現這個目標的可能方法。這也是現在許多流行的低代碼平臺的既定目標。像 Mendix 或 Microsof

28、t Power Apps 這些平臺可以展示通用的業務流程以方便重復使用,并簡化了部署新功能和交付給用戶的問題。近年來,這些平臺在可測試性和對良好工程實踐的支持方面取得了巨大的進步。它們特別適用于簡單的任務或事件觸發的應用程序。然而,要求它們適應幾乎無限的業務需求會帶來復雜性。雖然開發人員可能會少寫(或不寫)代碼,但他們也必須成為一個全面的商業平臺的專家。我們建議企業考慮他們是否需要這些產品帶來的所有功能,或者他們是否更應該追求限界的低代碼平臺,無論是開發自己的作為內部產品的平臺,還是通過謹慎限制商業低代碼平臺的使用范圍,使其僅限完成于它們擅長的簡單任務。7.對僅提供 API 的產品的演示前端試

29、驗捕捉并傳達 API 的業務價值是開發 API 時的一大挑戰。就其本質而言,API 是一種技術產品。盡管開發人員可以輕松理解 JSON 數據、OpenAPI(Swagger)規范和 Postman 演示,但業務利益相關者會更傾向于可交互的 API 產品演示。通常當我們能夠實際看到并親身體驗產品時,產品的價值會更加清晰地表達出來。也正是因為這樣,我們有時會認為投資對僅提供 API 的產品的演示前端是值得的。當定制化界面 UI 與 API 產品一起構建時,業務利益相關者可以將產品與他們可能更熟悉的紙質表格或報告進行類比。隨著交互模型和 UI 演示的豐富性不斷發展,業務利益相關者可以對 API 產品

30、的發展方向做出更明智的決策?;?UI 工作也有額外的益處,它技術 Thoughtworks,Inc.All Rights Reserved.14可以增加開發人員對業務用戶的同理心。雖然 API 產品的演示前端并不是一項新技術當 API 產品出現時,我們就能在必要時構建演示前端。然而,由于這項技術并不廣為人知,我們仍然認為該技術值得關注。8.Lakehouse 架構試驗Lakehouse(數據湖倉一體)架構是一種數據湖的可擴展性與數據倉庫可靠性和性能相結合的架構風格,它使得組織能在一個平臺上使用類似于 SQL 的工具和技術,儲存分析大量不同的數據,而不是將他們放在單獨的在數據湖和數據倉庫層中。

31、盡管這個術語(LakeHouse)經常與作為供應商的 Databricks 之類的廠商有關,像Delta Lake,Apache Iceberg 和 Apache Hudi 之類的開源方案也值得考慮。Lakehouse 架構可以補充數據網格的實現。自治的數據產品團隊可以在他們的數據產品選擇使用 Lakehouse。9.可驗證憑證試驗三年前,當我們第一次在雷達中提及可驗證憑證(VC)時,它是一個引人注目的標準,有著一些潛在的應用前景,但在愛好者群體之外并沒有廣為人知。對于如州政府等負責實施該標準的證書授予機構,情況更是如此。三年疫情之后,隨著加密安全、尊重隱私和機器可驗證電子證書的需求增長,政府

32、開始意識到可驗證憑證的潛力。W3C 標準以憑證持有者為中心,這與我們使用物理憑證時的體驗相似:用戶可以將他們可驗證的憑證放到自己的數字錢包中,并在任何時候向任何人展示,而無需得到憑證發行者的許可。這種去中心化的方式有助于用戶更好地管理和有選擇地披露自己的信息,大大提高了數據隱私的保護。在過去的 6 個月里,我們的一些團隊參與了使用可驗證憑證技術的項目。毫不意外,不同國家和政府部門的情況并不相同。我們的團隊在多個項目上探索了去中心化標識、可驗證憑證和可驗證展示的不同組合。這是一個仍在發展的領域,現在我們有了更多的經驗,我們希望在雷達中持續跟蹤它。10.無障礙意識的組件測試設計評估在軟件交付過程中

33、,需要提早考慮無障礙設計的地方有很多,Web 組件測試是其中環節之一。像 chai-a11y-axe這樣的測試框架插件在其 API 中提供了斷言,以檢查基本的無障礙設計。但是,除了使用測試框架所提供的功能外,無障礙意識組件測試設計進一步提供了屏幕閱讀器和其他輔助技術所需的所有語義元素。首先,不要使用 test id 或 class 來尋找和選擇你要驗證的元素,而是使用通過 ARIA 角色或其他輔助技術使用的語義屬性來識別元素。一些測試庫,如 Testing Library,甚至在文檔中直接推薦這樣做。其次,不要只測試點擊交互,還要考慮不能使用鼠標或看不到屏幕的用戶,并考慮增加對鍵盤和其他交互的

34、測試。11.基于 AI 輔助的測試驅動開發評估和軟件行業的許多人一樣,我們一直在探索快速演進的 AI 工具,以幫助我們編寫代碼。我們看到很多人通過將實現代碼輸入 ChatGPT,然后請求其生成測試代碼。但作為 TDD(測試驅動開發)的堅定支持者,我們并不技術 Thoughtworks,Inc.All Rights Reserved.15想經常將可能包含敏感信息的實現代碼輸入到外部模型中,因此我們嘗試了基于 AI 輔助的測試驅動開發的技術。在這種方法中,我們讓 ChatGPT 為我們生成測試代碼,然后由開發人員來實現功能。具體而言,我們首先在一個可在多個用例中重復使用的提示“片段”中描述我們使用

35、的技術棧和設計模式。然后,我們描述我們想要實現的具體功能,包括驗收標準?;谶@些信息,我們要求 ChatGPT 生成在我們的架構風格和技術棧中實現這一功能的實現計劃。一旦我們對這個實現計劃進行了合理性檢查,我們就要求它為我們的驗收標準生成測試代碼。這種方法對我們來說效果出奇的好:它要求團隊提供對其架構風格的簡明描述,幫助初級開發人員和新團隊成員編寫符合團隊現有風格的功能特性。這種方法的主要缺點是,盡管我們沒有向模型提供源代碼,但我們仍然向其輸入了可能包含敏感信息的技術棧和功能描述。至少在這些 AI 工具的“商業版”面世之前,團隊應確保與法律顧問合作,以避免任何知識產權問題。12.領域特定的大型

36、語言模型評估在之前的技術雷達中,我們已經提到過 BERT 和 ERNIE 之類的大型語言模型(LLMs);但是領域特定的大型語言模型是一個新興的趨勢。使用領域特定數據對通用大型語言模型進行微調能將它們用于各種各樣的任務,包括信息查詢,增強用戶支持和內容創作。這種實踐已經在法律和金融領域展現出現它的潛力,例如使用 OpenNYAI進行法律文書分析。隨著越來越多的組織開始對大型語言模型進行試驗和越來越多像 GPT-4 這樣的新模型的發布,我們預期大型語言模型在不久的將來會有更多領域特定的用例。但是使用大型語言模型仍面臨許多挑戰和缺陷。首先,大型語言模型能“很自信地犯錯”,所以需要構建一些機制來保證

37、結果的準確性。其次,第三方大型語言模型可能保留或二次分享你的數據,這會對保密信息和數據的所有權帶來風險。組織應當仔細審閱使用條款和供應商的可信度,或考慮在自己控制的基礎設施上訓練和運行大型語言模型。就像其他的新技術一樣,在業務上使用大語言模型前需要保持謹慎,并理解采用大型語言模型帶來的后果和風險。13.智能引導無障礙測試評估對于從未使用過輔助技術,并且覺得對像 Web 內容無障礙指南(WCAG)這樣的標準仍然一無所知的人來說,使網頁應用程序兼容輔助技術可能會有些困難。智能輔助無障礙測試是這樣一類可以幫助測試已正確實現無障礙設計的工具,而無需成為無障礙技術專家。這些工具是瀏覽器擴展,它們會掃描網

38、站,總結輔助技術會如何解釋網頁,然后通過一組問題以確認您創建的結構和元素是否符合預期。我們已經在一些項目中使用過 axe DevTools、Web Accessibility Insights for Web 或 ARC Toolkit 等工具。14.使用 Logseq 構建團隊知識庫評估團隊知識管理是一個熟悉的概念,團隊使用諸如維基(wikis)等工具來存儲信息和培訓新團隊成員。我們的一些團隊現在更傾向于將 Logseq 作為團隊知識庫。Logseq 是一種開源的知識管理系統,由圖形數據庫驅動,幫助用戶組織想法、筆記和創意,并可以通過基于 Git 的存儲方式適應團隊使用。Logseq 允許團

39、隊構建一個公開透明的知識庫,為每個成員提供個性化的學習路徑,促進高效的啟動培訓。然而,與任何知識管理工具一樣,團隊需要對他們的知識庫進行良好的歸納整理,以避免信息過載或組織混亂。技術 Thoughtworks,Inc.All Rights Reserved.16雖然類似的功能也可以在像 Obsidian 這樣的工具中找到,但 Logseq 的關鍵區別在于其注重于知識的使用,基于段落的鏈接使團隊成員能夠快速找到相關的上下文,而無需閱讀整篇文章。15.提示工程評估提示工程(Prompt engineering)指的是為生成式 AI 模型設計和優化提示的過程,以獲得高質量的模型響應。這個過程包括精心

40、設計特定、清晰易懂和與所需任務或應用相關的提示,以引導模型輸出有用的結果。提示工程旨在增強大型語言模型(LLM)在問題回答、算術推理任務或特定領域上下文中的能力。在軟件開發中,我們可以使用提示工程讓 LLM 根據與利益相關者的簡要對話或一些筆記撰寫故事、API 或測試套件。培養有效的提示技巧正在成為處理人工智能系統的重要技能。提示工程被一些人認為是一門藝術,而另一些人則認為它是一門科學。同時我們也需要考慮到其潛在的安全風險,例如“提示注入攻擊”。16.測試基礎設施時的可達性分析評估在部署基礎設施代碼時,我們發現很多時間會花費在診斷和修復因系統之間無法相互通信導致的生產問題上。由于它們之間的網絡

41、拓撲結構可能非常復雜,即使已經正確配置了單個端口和端點,整個路由也可能無法完全遍歷?;A設施測試實踐通常包括驗證正確的端口是開放還是關閉,或者某個端點是否可以被訪問,但我們最近才開始在測試基礎設施時進行可達性分析。該分析通常涉及比簡單的是/否判斷更多的內容。例如,工具可能會遍歷并報告通過中轉網關的多個路由。此技術得到了所有主要云供應商工具的支持。Azure 有一個名為網絡觀察程序的服務,可以在自動化測試中進行腳本編寫,而 GCP 則支持連通性測試。而現在,在 AWS 中,您可以測試同一組織內跨賬戶的可達性。17.自托管式大型語言模型評估大型語言模型通常會運行在具有強大的 GPU 的基礎設施上。

42、我們如今可以看到一些大型語言模型的移植版本,比如 llama.cpp,這些模型能在不同的硬件上運行,包括 Raspberry Pi(樹莓派)、筆記本電腦和通用服務器等。因此自托管式大型語言模型已經成為現實。目前,有許多開源的自托管式大型語言模型,如 GPT-J、GPT-JT 和LLaMA。自托管這種方式有許多好處,比如可以更好地控制模型在一些特定使用場景的微調、提高安全性和隱私性,以及支持離線訪問。不過在決定使用自托管這種方式之前,您應該仔細評估組織的能力和運行此類大型語言模型需要消耗的成本。18.管理技術健康狀況優先于技術債務評估在軟件交付組織中,如何管理技術債務是一個經久不衰的話題。哪些是

43、技術債務而哪些不是?如何確定它的優先級?最重要的是,如何向內部利益相關者展示償還技術債務的價值?遵循敏捷宣言的推理方式“盡管右項技術 Thoughtworks,Inc.All Rights Reserved.17有其價值,我們更重視左項的價值”,我們喜歡“管理技術健康狀況優先于技術債務”的想法。澳大利亞的 REA團隊分享了一個很好的案例,介紹了他們如何追蹤管理開發、運維和架構三個方面的系統健康狀況。將關注點放在技術健康狀況而非技術債務上更有建設性。這樣將團隊與減少技術債務的最終價值聯系起來,并幫助團隊確定優先級。理想情況下,每個被解決的技術債務都應與某項已達成共識的期望相關聯。團隊應將技術健康

44、狀況評級與其他服務級別目標(SLO)一樣對待,并在某個類別的健康評級跌出“安全區域”時優先進行改進。19.CI/CD 的零信任保護評估如果沒有得到正確的安全配置,運行構建和交付的流水線的基礎設施和工具可能成為一個大麻煩。流水線需要訪問關鍵數據和系統比如源代碼,憑證和密碼來構建和部署軟件。這讓這些系統非常容易吸引惡意攻擊者。因此,我們強烈推薦引入零信任安全機制來保障 CI/CD 流水線和基礎設施盡可能少地信賴它們。這包含一系列技術:如果可行,根據你的云供應商通過聯合身份校驗機制如 OIDC 來驗證你的流水線,而不是直接給他們獲取機密數據的權限。實現最小特權原則,最小化個人用戶和執行賬戶的權限,而

45、不是創建一個擁有無限訪問權限的全能賬戶。用臨時的方式去使用任務執行器而不是復用他們,來減少暴露先前任務的秘密或在受到攻擊的運行器上運行任務的風險。保證軟件在你的代理服務器和任務執行器上是最新的。像監控你的生產環境軟件一樣監控你的 CI/CD 系統的完整性,保密性和可用性。我們不斷見到有團隊會忘記這些實踐,特別是當他們使用在內網自我管理的 CI/CD 基礎設施的時候。所有這些實踐在不僅在內網中都很重要,在使用托管服務時,因為擴大了攻擊面和影響范圍,這種實踐會變得更加重要。20.對 Webhooks 的管理不夠嚴謹暫緩隨著遠程工作的增加,聊天協作平臺和 ChatOps 的采用也在增加。這些平臺通常

46、提供 Webhook(網絡掛鉤)作為自動發送消息和通知的簡單方式,但我們關注到一個令人擔憂的趨勢:對 Webhooks 的管理不夠嚴謹將它們視為配置而不是秘密或憑據。這可能會導致釣魚攻擊和內部信息泄露。Webhook 是提供對內部空間的特權訪問的憑據,可能包含可以輕松提取和直接使用的 API 密鑰。不將它們視為密鑰會導致釣魚攻擊的發生。在 Git 倉庫中的 Webhook 可以輕松提取并用于發送有效的欺詐信息,用戶可能沒有任何身份驗證的方式。為了緩解這種威脅,處理 Webhook 的團隊需要改變他們的習慣,并將 Webhook 視為敏感憑據。軟件開發人員與 ChatOps 平臺構建集成必須注意

47、到這種風險,確保這些 Webhook 具備適當的安全措施。技術 Thoughtworks,Inc.All Rights Reserved.1821.Lambda 彈球暫緩雖然無服務器架構對解決一些問題非常有用,但它們確實有一定的復雜性,尤其是當它們涉及到復雜執行和跨多個相互依賴的 Lambdas 的數據流時這有時會導致所謂的 Lambda 彈球架構。我們團隊發現維護和測試 Lambda 彈球架構可能非常有挑戰:理解基礎設施、部署、診斷和調試都會變得困難。在代碼層面上,根本不可能將領域概念和所涉及的多個 Lambdas 之間做簡單映射,這使得任何改變和添加都具有挑戰。盡管我們相信無服務器是適合某

48、些問題和領域的,但它并不是每個問題的“萬能解法”,這就是為什么你應該盡量避免陷入 Lambda 彈球。一種有助于解決這個問題的方法,就是區分公共接口(public interface)和已發布接口(published interface),并在它們之間應用帶有已發布接口的領域邊界。22.竭盡全力的計劃暫緩雖然在產品管理社區中,應該預留一些交付能力余量是眾所周知的,但我們發現仍然有許多團隊會為團隊制訂竭盡全力的計劃。在迭代計劃中預留一定的產能,往往可以提高可預測性以及更好的質量。因為這不僅有助于增強團隊應對意外事件(如疾病、生產問題、意外的產品請求和技術債務)的彈性,還讓團隊可以進行提升生產力的

49、活動,比如團隊建設和創意構思,從而推動產品創新。留有一定的交付余量,可以讓團隊更加專注于所生產的軟件的健壯性,并更加關注正確的度量信息。我們的經驗表明,就像高速公路的車輛過多就會導致緩慢而令人沮喪的交通一樣,充分利用團隊的能力往往會導致生產效率的崩潰。當我們的一個團隊需要處理不可預測的支持請求時,他們只按照開發能力的 2/3 來計劃功能交付的速度,從而增加了 25%的交付量,并減少了50%的周期時間波動。技術 Thoughtworks,Inc.All Rights Reserved.平臺142123263132332734353637384439404142432828751011201213

50、141516172218193766159605755525047486465666768697071727374757877795351494692939495969798991001011021031041051061078382848586918987242530298088908169455658626354暫緩暫緩評估評估試驗試驗采納采納采納23.Contentful24.GitHub Actions25.K3s試驗26.Apache Hudi27.云上 Arm28.Ax29.DuckDB30.特征庫31.RudderStack32.Strapi33.TypeDB評估34.Autow

51、are35.Cozo36.Dapr37.Immuta38.Matter39.Modal40.Neon41.OpenLineage42.Passkeys43.Spin暫緩44.Denodo 作為主要的數據轉換工具新的挪進/挪出沒有變化 Thoughtworks,Inc.All Rights Reserved.2023.Contentful采納無頭內容管理系統已經成為數字平臺的常見組成部分,Contentful 仍然是我們在這個領域的首選,但像 Strapi這樣的新進入者也給我們留下了深刻的印象。我們尤為喜歡Contentful的API優先的工作方式以及實現了CMS as code。它支持強大的代

52、碼化內容模型原語和內容模型演化腳本,這使得它可以像其他數據存儲模式一樣被處理,并演進式數據庫設計實踐可以應用于 CMS 開發。最近,Contentful 發布了應用程序框架來編寫應用,以便更容易地將 Contentful 適應個人業務流程并與其他服務集成。這些應用程序可以由特定組織建立,也可以為特定組織構建,與此同時市場上的應用也在快速增多。24.GitHub Actions采納對于許多需要在新環境中快速啟動和運行 CI 或 CD 的團隊來說,GitHub Actions 已經成為了默認選擇。此外,它還能承載更復雜的工作流程,并且能夠調用其他復合任務中的任務。盡管 GitHub 應用市場中的生

53、態在不斷發展,我們仍然強烈建議謹慎授予第三方 GitHub Actions 權限訪問您的構建流水線。我們建議您遵循 Github有關安全強化的建議,避免以不安全的方式共享機密信息。但是,直接在托管源代碼的 GitHub 上創建構建工作流的便利性,再加上能使用像 act 等開源工具在本地運行 GitHub Actions,讓其成為簡化團隊設置和新成員上手流程的一個引人注目的選項。25.K3s采納K3s 仍是我們在邊緣計算和資源受限環境下的默認 Kubernetes 發行版。它輕量,完全兼容 Kubernetes,且操作開銷較少。它使用 sqlite3 作為默認存儲引擎,而不是 etcd。由于它在

54、一個進程中運行所有相關組件,因此具有減少內存占用的優點。我們已將 K3s 用于工控系統和 POS 機環境中,我們對自己的決定非常滿意。K3s 的運行時 containerd 已經支持 wasm,因此 K3s 可以直接運行和管理 WebAssembly 負載,進一步減少了運行時開銷。26.Apache Hudi試驗Apache Hudi 是一款開源數據湖平臺,它將 ACID 事務保障引入了數據湖中。我們嘗試了在大數據量高吞吐量場景下使用 Hudi 進行實時寫入和更新數據,取得了非常理想的效果。特別令人滿意的是,Hudi 對定制壓縮算法的支持很靈活,這有助于解決“小文件”讀寫的問題。Apache

55、Hudi 和 Delta Lake 以及 Apache Iceberg 都是同類的工具,它們提供相似的功能,但是在底層的實現方式和功能細節上又各有千秋。平臺 Thoughtworks,Inc.All Rights Reserved.2127.云上 Arm試驗云上 Arm 計算實例在過去幾年中越來越受歡迎。因為與傳統的基于 x86 的實例相比,其成本更低,能源效率也更高。如今 AWS、Azure 和 GCP 等許多云供應商都提供基于 Arm 的實例。云上 Arm 的成本優勢對于運行大型工作負載或需要擴容的企業來說特別有利。根據我們的經驗,除非依賴于特定架構,建議所有工作負載都使用Arm 計算實例

56、。多架構 docker 鏡像等很多支持多架構的工具也可以簡化構建和部署的工作流。28.Ax試驗在面對探索大型配置空間的挑戰時,可能需要大量的時間來評估給定配置,團隊可以轉向自適應實驗,這是一種機器引導的迭代過程,以資源高效的方式找到最佳解決方案。Ax 是一個用來管理和自動化自適應實驗的平臺,它包括機器學習實驗,A/B 測試和模擬。目前,它支持兩種優化策略,一種是使用 BoTorch 的貝葉斯優化,它是建立在 PyTorch 基礎上的,以及 contextual bandits。Facebook 在發布 Ax 和 BoTorch 時描述了例如提高后端基礎設施的效率,調整排名模型和優化機器學習平臺

57、的超參數搜索的用例。我們已經在多種用例中有了豐富的 Ax 應用經驗,雖然超參數調整工具是存在的,我們尚未發現有能提供與 Ax 在一定范圍上具有相似功能的平臺。29.DuckDB試驗DuckDB 是一個用于數據科學與數據分析的嵌入式列式數據庫。數據分析師通常會在本地將數據加載進諸如pandas 或 data.table 這些工具中,從而可以在于服務器內擴展解決方案前就做到快速分析模式和形成假設。然而,我們現在使用 DuckDB 來處理這些用例,因為它釋放出了比內存分析更大的潛力。DuckDB 支持龐大事務的 range joins,向量化執行和多版本并發控制(MVCC),我們的團隊對此表示非常滿

58、意。30.特征庫試驗任何軟件都需要正確表示其所應用的那一領域,并且應該始終了解關鍵的目標。機器學習項目也不例外。特征工程是機器學習軟件系統工程和設計的重要部分。特征庫是一個架構上的概念,能促進識別、發現和監測與給定領域或業務問題有關的特征。實現這一概念需要結合架構設計,數據工程和基礎設施管理,來創建一個可擴展的、高效的、可靠的機器學習系統。從工具的角度看,您可以找到開源的和完全托管的方案,但這些只包含了這個概念的一部分。在端到端的機器學習系統設計中,實現特征庫帶來了以下能力:(1)定義準確特征的能力;(2)增強數據的可復用性并且讓特征在不同模型中保持一致和可用的能力,其中還包括設置特征工程管道

59、,以規劃特征庫中的數據的能力;(3)幫助特征發現的能力和(4)提供特征服務的能力。我們的團隊利用特征庫獲得了這些對端到端機器學習系統的便利。平臺 Thoughtworks,Inc.All Rights Reserved.2231.RudderStack試驗RudderStack 是一個可以輕松存儲數據至數據倉庫或數據湖的客戶數據平臺(CDP)。這種方法越來越多地被稱為無頭 CDP(Headless CDP),它將 CDP 的功能和用戶界面分離,強調可通過 API 靈活配置,同時強調數據倉庫/數據湖為主要存儲方式。正如人們對此類產品所期望的那樣,RudderStack 既擁有豐富的類庫支持與第三

60、方服務集成(可同時作為源和接收器),也能夠接受自定義事件。RudderStack 既有商業產品,也有部分功能受限的自托管 OSS 版本。32.Strapi試驗Strapi 是一個基于 Node.js 的開源無頭內容管理系統(CMS),它類似于 Contentful。它已經出現了一段時間,我們也成功將其用于部分項目。Strapi 提供了 REST 和 GraphQL 兩種類型的 API,具有豐富的文檔,易用的數據模型 API,并且支持界面和邏輯的定制化。33.TypeDB試驗TypeDB 是一個知識圖譜數據庫,設計用于處理復雜的數據關系,從而簡化查詢和分析大型數據集。TypeDB 的TypeQL

61、 查詢語言類似于 SQL 語法,它可以簡化模式定義、查詢和探索的學習曲線。TypeDB 帶有各種工具,包括一個命令行界面和一個圖形用戶界面,這使其更容易與數據庫集成,TypeDB Studio 提供了一些集成 TypeDB的功能,如管理模式,查詢數據,可視化關系,甚至與他人合作。它有大量的文檔,并且有一個活躍的支持社區。我們的團隊用它來建立跨不同數據庫的分類學概念知識圖譜,并通過增加新的推理規則來利用其強大的推理能力來提高效率、減少工作量。憑借其友好的開發者體驗和有幫助的社區,TypeDB 是一個很好的候選者,任何團隊,如果在實施依賴復雜數據關系的解決方案,都可以考慮這個工具,包括自然語言數據

62、、推薦引擎和知識圖譜。34.Autoware評估Autoware 是一個基于 ROS(機器人操作系統)開發的,開源的自動駕駛軟件棧。它可以用于為各種各樣的車輛,如汽車和卡車等,開發和部署先進輔助駕駛系統(ADAS)。它不僅為自動駕駛的各個組成方面提供了一套開發工具與算法,譬如車身感知,駕駛決策和控制;而且它也內置有路線規劃和控制的模塊,可以基于周圍環境和目的地的信息為車輛提供路線信息。它的出現促進了自動駕駛技術的開放式創新。我們在 Autoware 上構建自動駕駛原型去驗證新產品構想,并發現它卓有成效。平臺 Thoughtworks,Inc.All Rights Reserved.2335.C

63、ozo評估Cozo 是一個以 Datalog 作為查詢語言的可嵌入關系型數據庫。其對時間旅行(time-travel)查詢及對在關系型數據模式中建模圖數據的支持使我們非常感興趣。我們很喜歡它將數據存儲委托給現有的主流引擎,例如SQLite,RocksDB,Sled 和 TiKV。盡管 Cozo 還處在早期開發階段,我們仍認為它值得一試。36.Dapr評估Dapr 是分布式應用程序運行時(Distributed Application Runtime)的縮寫,幫助開發人員構建在云中運行的具有彈性、無狀態和有狀態微服務。一些人可能會將其與服務網格(service mesh)混淆,因為它使用一個邊車

64、(Sidecar)架構,作為應用程序旁邊獨立運行的進程。Dapr 更加面向應用程序,并專注于封裝構建分布式應用所需的容錯性和連接性。例如,Dapr 提供多個構建塊(building blocks),從服務調用和消息發布/訂閱到分布式鎖定等都是分布式通信中常見的模式。我們團隊最近在一個項目上評估了 Dapr;基于這一成功經驗,他們期待將其引入未來其他項目中。37.Immuta評估Immuta 是一個數據安全平臺,它允許你安全地訪問數據,自動發現敏感數據并審計數據在組織中的使用情況。在過去,當我們考慮安全風險時,我們已經談到了自動化、工程實踐和將安全策略代碼化的重要性。數據安全也不例外。我們的團隊

65、一直在探索 Immuta,它能將數據訪問策略作為代碼來管理,以實現精細化的訪問控制,這超出了基于角色的訪問控制(RBAC)所能提供的范圍?;诎姹究刂频牟呗钥梢员粶y試,然后配置為 CI/CD管道的一部分。在一個去中心化的數據生態系統中,比如由數據網格促成的生態系統,擁有特定領域的角色會導致身份認證系統中的角色或用戶組擴散。Immuta 的基于屬性的訪問控制(ABAC)的特性將訪問授權簡化為一個數學方程式,即把用戶的“屬性”與數據源的“標簽”相匹配。這個平臺雖然很新,但在滿足數據安全需求方面絕對值得考慮。38.Matter評估Matter 是由亞馬遜、蘋果、谷歌、康卡斯特和 Zigbee 聯盟(

66、現已更名為 Connectivity Standards Alliance,簡稱 CSA)聯合推出的智能家居技術的開放標準。它使設備能夠與任何已通過 Matter 認證的生態系統配合使用,從而減少了不同供應商的設備和物聯網平臺之間的碎片化,促進了互操作性。它專注于在應用層面上的標準化、支持 Wi-Fi 和 Thread 作為通信媒介。與 Zigbee 等其他協議不同,Matter 得到了主要科技公司的支持。盡管支持 Matter 的設備數量仍然相對較少,但它在物聯網領域日益重要,因此對于那些希望構建智能家居和物聯網解決方案的人來說,它是值得評估的。平臺 Thoughtworks,Inc.All

67、 Rights Reserved.2439.Modal評估Modal 是一種平臺即服務(PaaS),您無需自己的基礎設施即可按需計算。Modal 讓您可以部署機器學習模型、大規模并行計算作業、任務隊列和 Web 應用程序。它提供了容器抽象,使得從本地部署到云端部署無縫切換,在本地和云端都可以熱重載。它甚至可以自動刪除部署,避免了手動清理的需要,但也可以使其持久化。Modal 由為 Spotify 開發第一個推薦引擎的同一個團隊編寫。它負責端到端的人工智能(AI)/ML 棧,并能提供按需的 GPU 資源,如果您有特別密集的計算需求,這將非常有用。無論您是在筆記本電腦上還是在云端工作,Modal

68、都能發揮作用,為運行和部署您的項目提供了一種簡單高效的方式。40.Neon評估Neon 是 AWS Aurora PostgreSQL 的一款開源替代產品。云原生分析型數據庫已經采用了將存儲與計算節點分離的技術,以便根據需要彈性擴展。然而,在事務性數據庫中進行相同的操作比較困難。Neon 通過其新的多租戶存儲引擎技術實現了這一點。它對主流 PostgreSQL 代碼進行最小的更改,并利用 AWS S3 進行長期數據存儲,在計算方面彈性擴縮容(包括縮放到零)。這種架構有幾個好處,包括便宜和快速地克隆、寫入時復制和分支。我們對基于 PostgreSQL 的創新非常興奮。我們的團隊正在評估 Neon

69、,并建議您也對其進行評估。41.OpenLineage評估OpenLineage 是一個開放的數據管道沿襲元數據收集標準,旨在在作業運行時對其進行編整。它使用一致的命名約定定義了運行、作業和數據集實體的通用模型。沿襲模型的核心是可擴展的,可以通過定制切面來增加實體。OpenLineage 解決了生產者和消費者之間互通問題,否則大家不得不想各種辦法實現互通。雖然存在它會成為另一個“中間標準”的風險,但作為 Linux 基金會 AI 和數據基金會項目,它獲得被廣泛采用的機會很大。OpenLineage 目前支持多個平臺的數據采集,如 Spark、Airflow 和 dbt,但用戶需要自己配置監聽器

70、。OpenLineage 對數據消費者的支持目前較為有限。42.Passkeys評估“密碼的終結”可能終于要到來了。在 FIDO 聯盟的指導和蘋果、谷歌、微軟的支持下,passkeys 的可用性正在接近其他主流身份驗證方式。當用 passkeys 注冊新的登錄信息時,它會產生一對密鑰:網站收到公鑰而用戶保留私鑰。它使用非對稱加密處理登錄。用戶需要證明他們擁有私鑰,但與密碼不同,私鑰不會被發送到網站上。在用戶的設備上,會使用生物識別技術或 PIN 碼來保護對 passkeys 的訪問。平臺 Thoughtworks,Inc.All Rights Reserved.25Passkeys可以在各大軟

71、件生態中存儲和同步,例如蘋果的iCloud鑰匙鏈、谷歌的密碼管理器或微軟的Windows Hello。在大多數情況下,該功能只適用于最新的操作系統和瀏覽器版本。值得注意的是,Windows 10 并不支持在 Windows Hello 中存儲密碼。不過幸運的是,客戶端到認證器協議(CTAP)讓 passkeys 可以被保存在創建密鑰或需要密鑰登錄的設備之外的不同設備上。例如,一個用戶在 Windows 10 上為一個網站創建了一個passkeys,并通過掃描二維碼將其存儲在 iPhone 上。因為密鑰是通過 iCloud 同步的,所以用戶可以從他們的MacBook 等其他 Apple 生態設備

72、上登錄到該網站。Passkeys 也可以存儲在硬件安全密鑰上,在 iOS 和 Android上也提供了對原生應用的支持。盡管仍有一些可用性問題例如,登錄時需要設備支持并開啟藍牙,因為掃描二維碼時要檢查設備是否接近passkeys 依然是值得考慮的。我們建議你在 passkeys.io 上試用,以了解它們的可用性。43.Spin評估Spin 是一個開源平臺,用于在 WebAssembly(WASM)中構建和運行微服務。在技術雷達以前的版本中,我們曾談論過在瀏覽器中使用 WebAssembly,但現在由于它在細粒度的沙盒功能、跨語言互操作性和熱重載的能力,我們正在目睹其在服務器端的滲透。通過使用

73、Spin CLI,您可以創建和分發基于 Rust、TypeScript、Python和 TinyGo 的 WebAssembly 微服務。我們對 Spin 充滿期待,并建議您仔細評估它,因為它正在退出早期預覽階段。44.Denodo 作為主要的數據轉換工具暫緩Denodo 是一款數據虛擬化工具,可以從單個平臺將來自多個底層數據源和各種接口、經過轉換后對使用者友好的數據方便地進行展示和保護。在 Denodo 中,可以使用類似于 SQL 的語言 VQL 創建虛擬數據庫和視圖,來實現數據轉換。這些視圖和虛擬數據庫會在用戶查詢虛擬數據庫時執行。在底層,Denodo 可以將虛擬數據庫的查詢委托給一個或多

74、個底層數據庫。盡管 Denodo 可以簡化展示消費者友好的數據的工作,但隨著視圖和虛擬數據庫層的疊加,特別當查詢需要連接多個底層數據庫時,性能會受到影響。只有對產品行為和性能調優方案有相當深入的了解,才能解決這些問題。由于這些缺點,以及對單元測試支持有限,我們不建議使用 Denodo 作為主要數據轉換工具,而應使用 Spark或 SQL(通過 dbt)等工具做數據轉換。平臺 Thoughtworks,Inc.All Rights Reserved.26工具采納45.DVC試驗46.Akeyless47.Apicurio Registry48.EventCatalog49.FOSSA50.Git

75、leaks51.Helmfile52.IBM Equal Access Accessibility Checker53.Ktlint54.Kubeflow55.Mend SCA56.Mozilla SOPS57.Ruff58.Soda Core59.Steampipe60.Terraform Cloud Operator61.TruffleHog62.Typesense63.Vite評估64.axe Linter65.ChatGPT66.DataFusion67.Deepchecks68.設計令牌翻譯工具69.Devbox70.Evidently71.Giskard72.GitHub Copi

76、lot73.iamlive74.Kepler75.Kubernetes External Secrets Operator76.Kubeshark77.Obsidian78.Ory Kratos79.Philips 的自我托管 GitHub 運行器暫緩142123263132332734353637384439404142432828751011201213141516172218193766159605755525047486465666768697071727374757877795351494692939495969798991001011021031041051061078382848

77、586918987242530298088908169455658626354暫緩暫緩評估評估試驗試驗采納采納新的挪進/挪出沒有變化 Thoughtworks,Inc.All Rights Reserved.2745.DVC采納DVC 一直是我們在數據科學項目中管理實驗的首選工具。由于 DVC 是基于 Git 的,因此對于軟件開發人員來說,DVC 無疑是一個備感熟悉的環境,他們可以很容易地將以往的工程實踐應用于數據科學生態中。DVC 使用其特有的模型檢查點視圖對訓練數據集、測試數據集、模型的超參數和代碼進行了精心的封裝。通過把可再現性作為首要關注點,它允許團隊在不同版本的模型之間進行“時間旅行

78、”。我們的團隊已經成功地將 DVC 用于生產環境,實現了機器學習的持續交付(CD4ML)。DVC 可以與任何類型的存儲進行集成(包含但不限于 AWS S3、Google Cloud Storage、MinIO 和 Google Drive)。然而,隨著數據集變得越來越大,基于文件系統的快照可能會變得特別昂貴。當底層數據發生快速變化時,DVC 借由其良好的版本化存儲特性可以追蹤一段時間內的模型漂移。我們的團隊已經成功地將 DVC 應用于像 Delta Lake 這樣的數據存儲格式,利用它優化了寫入時復制(COW)的版本控制。我們大多數的數據科學團隊會把 DVC 加入到項目的“Day 0”任務列表

79、中。因此,我們很高興將 DVC 移至采納。46.Akeyless試驗隨著越來越多的組織采用云計算,許多組織開始同時集成多個云提供商,以最大限度地提高靈活性并最小化供應商鎖定。然而,跨多個云提供商的密鑰管理和訪問控制可能會導致復雜性和安全風險增加,從而成為一項重大挑戰。Akeyless 是一個基于云的集中化平臺,提供統一的密鑰管理,在管理密鑰和敏感數據方面具有一系列優勢。它能夠與不同的云提供商無縫集成,簡化了密鑰管理和訪問控制,以監測和控制誰可以訪問敏感數據;通過加密、訪問控制、多因素身份驗證和其他安全機制,確保只有授權用戶才能訪問敏感數據。此外,它還提供了一個直觀的界面用于管理和監控,這為開發

80、和管理人員帶來了更簡單且更可擴展的體驗。47.Apicurio Registry試驗在任何組織中,API 的生產者和使用者都需要就他們之間通信所使用的模式保持同步。特別是隨著 API 數量以及相關生產者和使用者人數在組織中的增長,最初在團隊間傳遞模式的簡單做法將面臨挑戰。面對這個問題,我們的一些團隊使用了 Apicurio Registry,這是一個開源的、集中式的注冊表,可以存儲各種類型的模式和 API文檔,包括 OpenAPI 規范,Protobuf 和 Avro 模式。Apicurio Registry 允許用戶通過 UI,REST API 和 Maven插件等方式進行交互。它還有規定模

81、式演進限制的選項,比如說向后兼容性。此外,當使用 Kafka 客戶端時,Apicurio Registry 能與 Confluent Schema Registry 兼容。雖然我們的團隊發現 Confluent Schema Registry的文檔更有幫助,但 Apicurio Registry 滿足了對各種模式的真實來源的需求。48.EventCatalog試驗現在企業通常使用事件流作為真實數據的來源,并在微服務架構中作為信息共享機制。這就需要標準化事件類型并在企業范圍內共享這些標準。通常企業會部署事件模式注冊表,但現有的解決方案往往只適用于單個代理,工具 Thoughtworks,Inc.

82、All Rights Reserved.28比如 Apache Kafka 或 Azure Event Hub。此外,這些現有解決方案并不能提供超出簡單模式定義的關于事件類型的詳細文檔。EventCatalog 是一個開源項目,為企業提供了一種廣泛可訪問的文檔庫,用于描述事件在業務種扮演的角色,它們在業務領域模型中的位置,以及哪些服務訂閱和發布這些事件。如果您正在尋找一種向組織發布事件文檔的方式,那么使用 EventCatalog 工具可能會避免您自己構建文檔庫的麻煩。49.FOSSA試驗FOSSA 是一個開源合規性工具,可以幫助開發人員和團隊確定他們的代碼依賴哪些開源組件,以及這些組件是根據

83、哪些許可發布的。這些信息對于確保遵守各種開源許可證和維護軟件物料清單十分重要。FOSSA 可以與各種技術棧的依賴管理工具集成,以識別項目中使用了哪些開源組件。還可以根據組織的政策突出顯示任何許可證問題,并生成對應的報告。此外,FOSSA 的一些關鍵特性還包括與開發工作流(如 CI)集成,以及實時監控合規性。我們的許多團隊和客戶都認為 FOSSA 是一個有用且高效的工具。50.Gitleaks試驗Gitleaks 是一個開源 SAST(靜態應用安全測試)命令行工具,用于檢測 Git 倉庫以防止把密碼、API 密鑰和訪問令牌等機密信息硬編碼到代碼中。它可以用于 Git 的 pre-commit h

84、ook 和 CI/CD 流水線。我們團隊發現,Gitleaks 比其他一些密碼掃描工具更靈敏。Gitleaks 使用正則表達式和 entropy coding 字符串編碼檢測機密信息。在我們的經驗中,entropy coding 提供了靈活的自定義正則表達式,允許團隊基于他們的需求對機密信息進行更好的分類。例如,相較于把所有的 API 密鑰籠統地歸類為“通用型 API 密鑰”,entropy coding 允許把密鑰歸類到“云服務提供商密鑰”這種特定分類中。51.Helmfile試驗Helmfile 是一款開源命令行工具和聲明式的標準,用于安裝和管理多個 Helm chart,幫助您進行 He

85、lm 配置文件、使用的 chart 等變更的版本管理。它使 Helm chart 能用于 CI/CD 工作流,有助于創建可重現環境。我們已經在使用 Helmfile 來管理那些包含大量 Helm chart 的復雜部署,并且發現它簡化了我們的部署工作流。52.IBM Equal Access Accessibility Checker試驗缺陷發現得越早,修復成本更小。這就是為什么我們總是試圖以靜態分析、單元測試或在本地環境中運行的端到端測試等方式,盡可能快地向開發者提供反饋。無障礙設計也不例外,這就是我們過去介紹 Lighthouse、axe-core和axe Linter等工具的原因。當涉及

86、到已經部署在生產環境中的網頁時,我們的一個團隊選擇了IBM Equal Access Accessibility Checker 來進行直接的比較。雖然我們還在評估結果,但我們可以說,它提供了一種有效工具 Thoughtworks,Inc.All Rights Reserved.29的方法來測試已經發布了的網頁。我們想要強調的是,這個工具應該用來增強而不是取代開發者的早期自動測試。該工具是在創作共用許可證(Creative Commons license)下發布的,在符合協議規定時可以免費使用。53.Ktlint試驗隨著 Kotlin 生態系統的持續發展,我們的團隊報告了使用 Ktlint 的

87、良好體驗:這是一個用于 Kotlin 代碼,簡單且易于配置的 linter 和 formatter。我們喜歡有態度的代碼格式化工具(Opinionated and automated code formatting),因為這能讓開發者更關注代碼的行為,而不是它的外觀;這個工具使開發團隊能夠高效的維護代碼庫的一致性和可讀性,減少因格式問題而導致的混亂合并的可能性。Ktlint 可以很容易地配置在 pre-commit hook 中,它只針對有變化的文件,從而使集成過程更快。54.Kubeflow試驗Kubeflow 是一個 Kubernetes 原生的機器學習(ML)平臺,它能簡化模型生命周期中

88、在不同基礎設施上的構建、訓練和部署流程。我們已經大量使用它的 Pipelines 來編碼多個模型的包括實驗、訓練、服務用例的 ML 工作流。除 Pipelines 外,Kubeflow 還帶有許多其他的組件,我們發現其中用于超參數調優的 Katib 組件以及多租戶組件都是非常有用的。55.Mend SCA試驗Mend SCA(之前稱為 Whitesource)可以用于檢測開源軟件依賴項,以識別它們是否最新、是否含有安全漏洞,或存在特殊許可證需求。我們的團隊在將 Mend SCA 集成到生產流程方面有著不錯的經驗。無論是從 IDE集成還是從 CI/CD 流水線集成中識別問題并自動提出 PR,Me

89、nd SCA 都提供了出色的開發體驗。其他一些流行的 SCA 工具,如 Snyk,也值得探索,以滿足你的安全需求。56.Mozilla SOPS試驗當談到密鑰管理的時候,我們總是建議密鑰與代碼解耦。然而,團隊卻時常面臨著取舍權衡,一種方式是基于基礎設施即代碼思想的全自動化,另一種方式是使用一些手動步驟和諸如 vaults 的工具去管理、生成、更新密鑰。例如,我們的團隊使用 SOPS 工具生成構建基礎設施所需要的根密鑰。然而在某些情況下,從遺留代碼倉庫中移除密鑰并不現實。對于這類需求,我們發現 Mozilla SOPS 是一個很好的工具,可以用來加密文本文件中的密鑰。SOPS 集成了諸如 AWS

90、、KMS、Azure Key Vault 等密鑰倉庫作為待加密密鑰源。它支持跨平臺運行,也支持 PGP 密鑰。工具 Thoughtworks,Inc.All Rights Reserved.3057.Ruff試驗Ruff 是一個新的 Python linter。我們認為,使用 linter 是毋庸置疑的,只需要考慮使用哪個 linter,因為 Python提供了很多選擇。Ruff 能夠脫穎而出有兩個原因:開箱即用的體驗,以及性能。它內置了 500 多條規則,可以輕松取代 Flake8 和它的許多插件。我們的經驗證實了 Ruff 團隊對其性能的說法。它確實比其他 linter 快出至少一個數量級

91、,這是一個巨大的優勢,有助于減少大型代碼庫的構建時間。58.Soda Core試驗Soda Core 是一個開源數據質量與可觀測性工具。我們的團隊已經使用它來驗證數據在到達系統之前和之后的轉換,并設置自動化監測檢查以檢測異常情況。我們對 Soda Core 中用于編寫數據檢查的 DSLSodaCL 非常滿意.SodaCL 能幫助除了數據工程師以外的其他團隊成員來編寫質量檢查??偟膩碚f,我們在解決大規模數據問題時使用 Soda Core 的體驗非常好。59.Steampipe試驗Steampipe 是一個可以讓你使用 SQL 實時查詢 AWS,Azure,以及 GCP 等云服務的開源工具。Ste

92、ampipe 擁有 100 多個插件以及內置的創建儀表板功能,使連接實時云配置數據和內外部數據集以及創建安全合規的儀表板變得非常簡單。我們非常喜歡 Steampipe,并已經使用 AWS 云配置創建了幾個此類儀表板。60.Terraform Cloud Operator試驗越來越多的團隊在使用 Kubernetes Operators 模式來管理 Kubernetes 集群。為此,我們曾推薦過 Crossplane,現在有了另外一種選擇Terraform Cloud Operator。該工具通過擴展 Kubernetes 控制平面來集成Terraform Cloud 和 Kubernetes,

93、以通過 Kubernetes manifest 對云和本地基礎設施進行生命周期管理。我們的團隊使用它來提供資源,不管是 Kubernetes namespace,RoleBindings,云數據庫實例,還是其他 SaaS資源。我們非常喜歡它,因為它利用我們更熟悉的抽象層 Terraform 模塊來操作云資源。61.TruffleHog試驗TruffleHog 是一款開源的靜態應用程序安全測試工具(static application security testing,SAST),用于在各類源碼中檢測密鑰信息。除了對 GitHub 和 GitLab 等最為常見的代碼倉庫進行掃描,TruffleH

94、og 還能掃描 S3和 GCS 等云存儲桶、本地文件、本地目錄以及 CircleCI 日志。開發人員可以將 TruffleHog 配置為 pre-commit hook 腳本,也可以直接使用它掃描一個 GitHub 組織的全部代碼倉庫歷史記錄。TruffleHog 支持自定義的正則語句模版,即使在當前的 alpha 階段,該功能也十分易用。雖然 TruffleHog 有企業版本,但是我們發現開源版工具 Thoughtworks,Inc.All Rights Reserved.31本的 TruffleHog 更易于配置和使用,并且覆蓋了絕大多數的常見場景。TruffleHog 擁有一個非?;钴S的

95、社區,時不時就會有新的功能更新。62.Typesense試驗Typesense 是一款可容錯的開源搜索引擎,它針對高性能和低延遲的搜索體驗進行了優化。如果您正在構建對延遲有較高要求的搜索應用,而且索引的大小可以載入內存,Typesense 將是個很好的選擇。我們團隊在高可用的多節點集群里使用 Typesense 實現負載分布,并確保關鍵的搜索基礎設施能自適應負載變化。在實際使用中 Typesense 表現良好,因此我們將其移動到試驗環中。63.Vite試驗Vite 是一款前端構建工具,在之前的技術雷達被評為評估級別后變得更加成熟與流行。它迅速地成為了我們許多團隊開始前端項目時的默認選擇。Vit

96、e 提供了一套基于瀏覽器內 ES 模塊的應用的構建,打包和依賴管理工具。因為它利用了 esbuild 原生的速度和 Rollup 進行打包,Vite 顯著地提升了前端開發體驗。此外,當與 React 一起使用時,Vite 為廣泛使用卻缺乏維護的 Create React App 提供了一個有吸引力的替代品。Vite 依賴于 ES 模塊,不同于大多數舊工具,它不提供 shim 和 polyfills,這表示它不兼容那些不支持 ES 模塊的舊瀏覽器。如果要支持舊瀏覽器,我們的某些團隊會在模塊層導入 polyfills 來讓 Vite 能在多個環境都能使用。64.axe Linter評估對于開發者來

97、說,在開發過程的早期發現無障礙問題變得越來越容易。像 axe-core 這樣的工具可以在流水線中掃描代碼來尋找無障礙問題,而 VSCode 擴展工具 axe Linter 甚至可以在這之前,例如在編寫代碼時就能發現它們。絕大部分無障礙問題都屬于可以通過自動化測試和使用上述提到的實時反饋的提示工具(linter)來預防的類別。65.ChatGPT評估ChatGPT 是一個有趣的工具,它具有在軟件開發的各個方面發揮作用的潛力。作為一個已經“閱讀”了數十億個網頁的大型語言模型(LLM),ChatGPT 可以提供額外的視角,協助完成不同的任務,包括生成創意和需求、創建代碼和測試等。它是一種多功能的工具

98、,能夠跨越軟件生命周期的多個階段,提高開發效率并減少錯誤。GPT-4,作為驅動 ChatGPT 的 LLM,現在也具備與外部工具集成的能力,如知識管理庫、沙盒式編碼環境以及網絡搜索。目前,我們認為 ChatGPT 更適合作為流程的輸入,如幫助完成用戶故事的初稿或編碼任務的模板,而不是一個能夠產出“完美周全”結果的工具。工具 Thoughtworks,Inc.All Rights Reserved.32使用這些人工智能工具可能會存在知識產權和數據隱私方面的擔憂,包括一些尚未解決的法律問題,因此我們建議企業在使用前征求其法律團隊的意見。我們的一些客戶已經開始在軟件生命周期的各個階段嘗試使用Chat

99、GPT,我們鼓勵其他人探索這個工具并評估其潛在的作用。我們預計,像 GitHub Copilot 一樣,ChatGPT很快就會有一個“商業版”的產品,這可能會緩解知識產權方面的顧慮。66.DataFusion評估DataFusion 是數據社區將 Rust 的性能、內存安全、并發特征用于數據處理的新探索。它與 Polars 相似,都提供了一套熟悉的 Rust 中的名為 DataFrame 的 API(包括 Python 綁定庫),使用了 Apache Arrow 并提供了SQL 支持。盡管它主要為單進程設計,但是也支持使用 Ballista 進行分布式運算。我們認為包括 Data Fusion

100、在內的用于數據處理的 Rust 庫正在持續進化,它們值得關注和探索。67.Deepchecks評估隨著機器學習成為主流,模型測試、訓練數據驗證和生產模型性能監測這些實踐的自動化也日漸成熟。這些自動檢查越來越多地被集成進持續交付流水線或針對生產模型運行,以檢測模型漂移和模型性能。已經出現了一些具有相同或類似功能的工具,以處理這個過程中的各個步驟(比如同樣出現在本期技術雷達中的 Giskard 和Evidently)。Deepchecks 是另一個此類工具,它是一個開源的 Python 庫,提供了一組豐富的 API 以供流水線使用。它的一個獨特的功能是,能夠通過語言數據模塊來處理表格或圖像數據,該

101、模塊目前還在 alpha 版本。目前,沒有一個單獨的工具可以處理整個機器學習流水線中的各種測試和防護措施。我們建議在特定應用范圍內評估 Deepchecks。68.設計令牌翻譯工具評估設計令牌是定義設計體系中標準元素的有用機制。但是,在移動應用程序或 Web 應用等媒介上保持這些設計元素的一致性是一項愈發艱巨的任務。設計令牌翻譯工具通過整理和自動化地將(在 YAML 或 JSON 中的)令牌描述轉換為在指定媒介中控制渲染的代碼(如 CSS、React 組件或 HTML),從而簡化了這個問題。Style Dictionary 是一個廣泛使用的開源示例,很好地集成了自動化構建流水線,但它也有商業替

102、代品,例如 Specify。69.Devbox評估Devbox 提供了易上手的界面,它利用 Nix 包管理器為每個項目創建可重現的開發環境。我們的團隊使用它來消除開發環境中的版本和配置不匹配的問題,同時團隊成員也喜歡它的易用性。Devbox 支持 shell hooks、自定義腳本和 devcontainer.json 生成,以便與 VSCode 集成。工具 Thoughtworks,Inc.All Rights Reserved.3370.Evidently評估Evidently 是一個開源的 Python 工具,旨在幫助構建對機器學習模型的監控,以確保它們的質量和在生產環境運行的穩定性。它

103、可以用于模型生命周期的多個階段:作為 notebook 中檢查模型的儀表板,作為 pipeline 的一部分,或者作為部署后的監控。Evidently 特別關注模型漂移,同時也提供了模型質量檢查、數據質量檢查和目標漂變監測等功能。此外,它還提供了多種內置的指標、可視化圖形和測試,可以輕松地放入報告、儀表板或測試驅動的 pipeline 中。71.Giskard評估Giskard 是一個開源工具,旨在通過聚焦于可解釋性和公平性來保證質量,幫助組織構建更加強大、更符合道德的 AI 模型。它促進技術和非技術利益相關者之間的合作,使他們可以共同評估模型,并建立基于避免偏見和其他必要質量指標的驗收標準。

104、Giskard 確保模型結果更好地與業務目標保持一致,并幫助解決生產部署前的質量問題。72.GitHub Copilot評估GitHub Copilot 是一個由微軟和 OpenAI 聯合創建的人工智能編碼助手。它根據開發者當前工作上下文,利用機器學習模型提供建議。它具有強大的 IDE 集成功能,可以根據現有的代碼和編譯器環境提供建議。盡管它被稱為“您的人工智能結對編程程序員”,但我們不把它的工作稱為“結對編程”我們更傾向于稱它為強化且上下文敏感的 Stack Overflow。當它正確地預測了開發人員將要做的事情時,它會是一個強大的可以幫助完成開發的工具。不過,像所有基于 LLM 的人工智能

105、一樣,它會試圖使用一些看似合理,但不存在的 API,或者使用稍有問題的算法,導致系統故障。我們已經成功地在行、塊和方法層面上生成了代碼,同樣成功地創建了測試和基礎設施配置。有趣的是,當你命名良好時,它的工作效果最好,可以認為它鼓勵寫出可讀性良好的代碼。人工智能工具的功能正在迅速發展,我們認為企業嘗試這些工具是明智的。一些 Copilot 的銷售宣稱該工具對開發人員效率提升顯著,但我們仍然持懷疑態度:畢竟,寫代碼并不是開發人員花時間的唯一事情,而且衡量開發人員的生產力是眾所周知的困難問題。即便如此,Copilot 依然是一個相當劃算的工具;如果它能提供任何生產力的提高,也是值得一試的。Copil

106、ot X截至本文撰寫時尚處于預覽階段提供了額外的功能,并在軟件開發流程中進行了整合。Copilot 有一個“商業版”產品,解決了知識產權問題,并且增加了在整個組織中集中管理工具的能力。我們認為這些功能至關重要,值得企業采購。73.iamlive評估按照最小權限原則來創建我們想要的最小可行 AWS IAM 策略(Policy)可能需要經歷一段很長的試錯過程。而iamlive 可以在很大程度上縮短這一過程,它監控機器上執行過的 AWS CLI 調用,并確定執行這些調用所需的策工具 Thoughtworks,Inc.All Rights Reserved.34工具略。該工具會生成一個包含了語句(St

107、atement),動作(Actions),主體(Principals)以及資源(Resources)的策略文檔,這可以為我們提供一個很好的開始。我們發現,iamlive 對創建用于提供基礎架構的 CI/CD 流水線所需的策略特別有用,也減少了 IAM 角色策略不足導致 Terraform 運行失敗后的反復嘗試。74.Kepler評估衡量能源消耗是團隊減少軟件碳足跡的重要步驟。云碳足跡(CCF)通過從云 API 檢索的賬單和使用數據估計能源消耗。Kepler 是基于 Kubernetes 的高效功率級別導出器(Kubernetes-based Efficient Power Level Expo

108、rter)的縮寫。它通過使用軟件計數器(RAPL,ACPI 和 nvml)來測量硬件資源的功耗,并采用基于 eBPF的方法來將功耗歸因于進程、容器和 Kubernetes Pod。然后,使用自定義的 ML 模型和 SPEC Power 基準測試數據將功率使用轉換為能量估算。最后,將 Pod 級別的能量消耗報告作為 Prometheus 度量標準公開。在Kubernetes 運行在虛擬機上的情況下,例如不使用裸機實例時,Kepler 使用 cgroups 來估計能源消耗。我們對云碳足跡有著豐富的經驗,并且可以證明其有用性,但我們對 Kepler 項目的方法感到好奇。75.Kubernetes E

109、xternal Secrets Operator評估Kubernetes External Secrets Operator(ESO)讓我們可以將外部的密鑰提供程序與 Kubernetes 集成。ESO通過外部提供程序的 API 來讀取密鑰,并將其注入到 Kubernetes Secret 中。它還可以與眾多的密鑰管理工具集成,包括一些我們在往期技術雷達中介紹過的工具。我們的團隊發現在使用 Kubernetes 的過程中,ESO 讓我們可以使用統一的存儲來管理整個項目的密鑰,從而方便了密鑰的使用。76.Kubeshark評估Kubeshark 是一個 Kubernetes 的 API 流量監控

110、工具,在 2022 年 11 月之前,它被稱為 Mizu(日語“水”,象征著透明和流動性),與其他工具不同的是,Kubeshark 不需要安裝監測工具或改動代碼,它作為 DaemonSet 守護進程集在 Kubernetes 集群的節點層面上注入一個容器,并執行類似 tcpdump 的操作。我們認為 Kubeshark是一個很有用的調試工具,因為它可以實時地監控多種協議(REST,gRPC,Kafka,AMQP 和 Redis)之間的所有 API 通信。77.Obsidian評估知識管理對于技術工作者來說是至關重要的,因為我們需要不斷地學習,并與最新的技術發展保持同步。最近,涌現出了一些筆記工

111、具,如 Obsidian 和 Logseq,它們支持將筆記連接起來形成知識圖譜,同時將文件以markdown 格式存儲在本地目錄中,從而讓用戶擁有完全的所有權。這些工具幫助用戶以一種靈活、非線性的方式組織和連接他們的筆記。Thoughtworks,Inc.All Rights Reserved.35工具Obsidian有一個豐富的社區插件庫。其中特別引起我們注意的是Canvas(類似于本地版的Miro或Mural),以及Dataview,它可以有效地將你的筆記作為數據庫處理,并提供了一種查詢語言來過濾、分類和提取 markdown筆記中的數據。78.Ory Kratos評估我們已經評估了 Or

112、y Hydra 作為自托管的 OAuth2 解決方案,并收到了團隊的正向反饋。這一次,我們轉向 Ory Kratos,這是一個 API 優先的身份和用戶管理系統,對開發人員友好,且易于定制。它已經提供了我們希望在身份管理系統中實現的常見功能,包括自助登錄和注冊、多因素身份驗證(MFA/2FA)、賬戶驗證和賬戶恢復。像Hydra 一樣,Kratos 是無頭的(在希臘神話中,Hydra 意指九頭蛇海德拉。即使斬斷它的一顆頭,也會生出新的頭。譯者注),需要開發人員自己構建 UI,這給了團隊更多的靈活性。開發人員還可以定制標識模式以適應不同的業務上下文。除了數據庫,Kratos 沒有外部依賴關系,并且

113、很容易在不同的云環境中部署和擴展。如果您需要構建一個用戶管理系統,我們建議試試 Kratos。79.Philips 的自我托管 GitHub 運行器評估雖然 GitHub Actions 運行器涵蓋了一系列最常見的運行時,但有時您需要一些更具體的東西來滿足特定的使用場景,例如,一個不太常見的語言運行時,或者一個特定的硬件配置。這時您就需要一個自我托管的運行器。Philips 的自我托管 GitHub 運行器是一個 Terraform 模塊,可以讓您在 AWS EC2 Spot 實例上啟動自定義運行器。當您使用自我托管運行器時,您會失去 GitHub Actions 提供的一些生命周期管理特性,

114、而該模塊則創建了一整套 Lambda 來幫助解決這類問題。這些 Lambda 為運行器的按需擴縮容做了大量工作。這有助于管理成本,并允許您縮短運行器工作時長,這在提高可重復性和安全性方面是一個好的實踐。當您確實需要自我托管的運行器時,如果自己從頭開始構建,您可能會缺失很多東西。請尋找類似這樣的工具來代替。Thoughtworks,Inc.All Rights Reserved.語言和框架采納80.Gradle Kotlin DSL81.PyTorch試驗82.dbt 單元測試83.Jetpack CameraViewfinder84.Jetpack DataStore85.Mikro ORM8

115、6.按應用設定的語言偏好設置87.Quarto88.River89.Stencil90.Synthetic Data Vault91.Vitest評估92.NET 7 Native AOT93.NET MAUI94.dbt-expectations95.Directus96.Ferrocene97.Flutter 嵌入式平臺98.Fugue99.Galacean Engine100.LangChain101.mljar-supervised102.nanoGPT103.pandera104.Qwik105.SolidJS106.Turborepo107.WebXR 設備 APIHold 暫緩1

116、42123263132332734353637384439404142432828751011201213141516172218193766159605755525047486465666768697071727374757877795351494692939495969798991001011021031041051061078382848586918987242530298088908169455658626354暫緩暫緩評估評估試驗試驗采納采納新的挪進/挪出沒有變化 Thoughtworks,Inc.All Rights Reserved.3780.Gradle Kotlin DSL采

117、納現在,相比 Groovy,我們的團隊在使用 Gradle 啟動新項目時更傾向于將 Gradle Kotlin DSL(Domain-Specific Language,領域專用語言)視作默認選項。已經在使用 Groovy 的團隊應考慮遷移。Kotlin 為 IDE(Integrated Development Environment,集成開發環境)中的重構與更簡便的編輯提供更好的支持,而且我們的團隊報告稱,其產出的代碼更易閱讀與維護。鑒于一些 IDE 現在支持遷移,嘗試替換現有的 Groovy 應該相對較快。在某些情況下,Kotlin 可能會比 Groovy 慢;然而,對于許多項目而言,這不

118、太可能會影響到團隊。81.PyTorch采納PyTorch 一直是我們選擇的機器學習(ML)框架。相比于 TensorFlow,大多數團隊更喜歡 PyTorch,因為它暴露了 TensorFlow 隱藏的 ML 內部工作原理,使其更易于調試。動態計算圖使得模型優化比其他任何 ML 框架都更容易。State-of-the-Art(SOTA)模型的廣泛可用性以及實現研究論文的便利性使 PyTorch 脫穎而出。在圖 ML 領域,PyTorch Geometric 是一個更成熟的生態系統,我們的團隊在使用中獲得了良好的體驗。PyTorch在模型部署和擴展方面也逐漸彌合了缺失,例如,我們的團隊已成功地

119、在生產中使用 TorchServe 服務預訓練模型。隨著許多團隊默認使用 PyTorch 來滿足其端到端的深度學習需求,我們很高興地建議采納 PyTorch。82.dbt 單元測試試驗dbt 單元測試是一個 dbt 的軟件包,它可以為編寫數據處理模型和其邏輯的單元測試提供對依賴項的模擬。這為數據處理領域帶來了更加準確的快速開發反饋。盡管它只能應用于簡單的數據轉換,我們的團隊在 Snowflake上依然使用該軟件包實踐了測試驅動開發(TDD)。雖然該軟件包對失敗測試的調試支持還有很大提升空間,但它依然能為編寫數據轉換器的單元測試提供一個優雅的開發體驗。83.Jetpack CameraViewf

120、inder試驗在 為 Android 應 用 程 序 添 加 相 機 功 能 時,開 發 人 員 必 須 注 意 潛 在 的 風 險。最 近 推 出 的 Jetpack CameraViewfinder API在顯著改善了開發人員在這方面的體驗。它內部使用了TextureView或SurfaceView來顯示相機的視頻流,并對其進行必要的轉換以正確顯示取景器,比如修正寬高比、縮放和旋轉方向。此外,還提供了針對可折疊設備優化的布局。雖然不是一個主要的功能,但我們在這里強調它的存在,以確保團隊意識到有這個選項。84.Jetpack DataStore試驗Jetpack DataStore 是一個新

121、的數據存儲解決方案,提供異步性、一致性和事務性的存儲數據功能。它有兩種實現方式:Preferences DataStore 用于無類型的鍵值對的存儲,Proto DataStore 用于使用 Protobufs 的復雜語言和框架 Thoughtworks,Inc.All Rights Reserved.38數據類型的存儲。默認情況下,它與 Kotlin 的 coroutines 和 Flow 一起使用,但對 RXJava 2 和 3 也有額外支持。其文檔建議,如果你目前正在使用 SharedPreferences,可以考慮遷移到 DataStore,我們認同這個建議。85.Mikro ORM試

122、驗Mikro ORM 是一個基于 TypeScript 的對象關系映射(ORM)框架。全棧使用 TypeScript,能從瀏覽器到后端為開發人員提供一致的開發體驗,讓他們更容易編寫和維護代碼。另外值得注意的是,Mikro ORM 的性能非常出色,可以快速執行查詢并將延遲降低到最小。雖然 Mikro ORM 提供了吸引人的功能,但仍然需提防 ORM 的常見使用問題。ORM 框架通常很復雜,而且為關系型數據存儲只提供了一個“有漏洞風險”的抽象層,因此采用一個 ORM 框架前一定需要權衡利弊。86.按應用設定的語言偏好設置試驗很多人都可以使用多種語言,并且會在不同的情境下使用不同的語言。運行應用程序

123、的設備和平臺通常會要求用戶選擇一種系統語言,然后要求應用程序也使用這個系統語言。但手機用戶有時會希望某些應用能夠使用與系統語言不同的語言。蘋果公司早些時候在 iOS 中提供了按應用設定的語言偏好設置功能。然而在 Android 13之前,如果安卓應用程序開發者想要提供此選項,就只能在應用程序中自行實現。Android 13 提供了一項新的系統設置:按應用設定的語言偏好設置和一個公共 API,使開發者能夠更容易地提供此功能。為了向后兼容,AndroidX 還通過 AppCompatDelegate 提供了相應的 API。我們建議開發者們使用這項新功能替換之前的自定義解決方案。87.Quarto試

124、驗Quarto 是一個開源的科技出版系統,它允許我們使用 markdown 方式編寫文檔來構建計算筆記本(notebooks),在最終的文檔中插入代碼及其輸出。它可用于創建可重復和可定制的數據分析報告,并輕松地以各種格式進行共享。我們的數據科學團隊使用 Quarto 共享包含可視化(圖表)和表格的數據分析報告。他們喜歡能使用 R 和 Python 來生成這些動態報告,然后導出為 HTML 與相關人員共享。如果你希望在組織內部或外部分享你的研究和分析,我們建議評估 Quarto。88.River試驗許多機器學習方法的核心是從一組訓練數據中創建模型。一旦創建了模型,它就可以一遍又一遍地使用。然而,

125、世界并不是靜止的,隨著新數據的出現,模型往往需要更新。簡單粗暴地重新訓練模型可能會很慢,而且成本很高。增量學習的出現解決了這個問題,使得從數據流中不斷學習成為可能,從而更快地對變化做出反應。其也有一些額外的好處:它對算力和內存的要求更低,而且可以預測。我們對 River 的實踐體驗仍然是正面的。Vowpal Wabbit 可以作為一個替代方案,但它的學習曲線更陡峭,而 River 提供的類似 Scikit 的 API 使 River更容易被數據科學家所接受。語言和框架 Thoughtworks,Inc.All Rights Reserved.3989.Stencil試驗Stencil 是一個庫

126、,使開發人員能夠使用 TypeScript、JSX 和 JSDoc 等成熟的工具構建可復用的 Web 組件。根據我們團隊的經驗,Stencil 是構建平臺無關的設計系統的一個非常好的選擇。對于少數不支持現代瀏覽器特性的瀏覽器,Stencil 通過按需 polyfilling 不支持的功能和 API 來確保兼容性。90.Synthetic Data Vault試驗Synthetic Data Vault(SDV)是一個數據生成工具庫,它通過學習數據集的分布,生成與源數據具有相同格式和統計屬性的合成數據。在往期的技術雷達中,我們討論過應用測試環境中的生產數據的弊端。然而,生產環境中數據分布的細微差

127、別很難手工復制,這會導致合成數據中的一些缺陷和無法預知的情況。我們使用 SDV 來生成大數據進行性能測試時獲得了很好的體驗。SDV 在為單表建模時表現良好。然而,隨著帶有外鍵約束的表數量的增加,數據生成時間也大大增加。盡管如此,SDV 為本地性能測試提供了很大的希望。它是一個生成合成數據的好工具,值得考慮用于你的測試需求。91.Vitest試驗Vitest 是一款 JavaScript 的單元測試框架。迄今為止,許多團隊一直依賴 Jest,但 Jest 與現代前端構建工具Vite 不兼容。同時使用 Jest 和 Vite 強制團隊創建兩個流程管道,一個用于構建和開發,另一個用于單元測試,這需要

128、繁瑣的管道配置和重復的設置。這些問題都可以通過 Vitest 解決。它專門為 Vite 設計,并使用 Vite 作為打包工具。此外,Vitest 還具有 Jest 兼容的 API,這使得在各種構建設置中可以使用 Vitest 作為 Jest 的替代品。Vite 和 Vitest 結合使用提供了更好的開發者體驗,Vitest 也很快,但以我們的實際經驗來看,它未必比使用 Jest 更快。92.NET 7 Native AOT評估.NET 7 Native AOT 在一眾原生部署.NET 應用程序的方法中邁出了一大步。它完全摒棄了運行時的中間語言(IL)和實時編譯(JIT)。這項在.NET 7 中

129、引入的改進,對于在無服務器函數(Serverless Functions)中運行.NET 應用程序意義重大。這種新的部署方式解決了一直以來在 AWS Lambda 或 Azure Functions 等無服務器平臺上運行.Net 程序的冷啟動問題。相比其它部署方法,使用 Native AOT,可以生成更小的可部署二進制文件,從而縮短冷啟動所需的時間。AWS 已通過 Amazon Lambda Tools 正式支持 Native AOT。這種新的部署方式令.NET 7 的冷啟動時間降低到與 TypeScript/JavaScript 一致的水平,使它成為大規模采用.NET 基礎架構的組織的可用部

130、署方式。語言和框架 Thoughtworks,Inc.All Rights Reserved.4093.NET MAUI評估.NET MAUI 是一個使用 C#和 XAML 創建原生移動端和桌面端應用程序的新的跨平臺框架。它可以用同一份代碼庫構建可在 Android、iOS、macOS 和 Windows 上運行的應用程序。然而,作為一項新技術,MAUI 的生態系統仍不如 React Native 或其他跨系統平臺的生態發達,并且它只支持 C#。此外,企業和組織在使用 MAUI 時可能也會面臨過去使用 Xamarin 時遇到的挑戰,包括糟糕的跨平臺工具、移動端集成問題、開發人員難以招聘和不成熟

131、的生態系統。盡管微軟宣稱他們致力于將 MAUI 打造為以移動端為主的開源移動開發框架,但 MAUI 尚未得到市場認可。如果您已經使用了 Xamarin,可以嘗試將 MAUI 作為潛在的技術升級方向進行評估。然而,如果 C#或 Xamarin目前不是您技術棧的一部分,在其可靠性得到驗證和被市場廣泛采用之前,建議您謹慎對待 MAUI。94.dbt-expectations評估dbt-expectations 是一個用于 dbt 的拓展包,它產生的靈感來自于 Great Expectations。數據質量是數據治理的宗旨,所以當提及自動數據治理時,在數據管道中加入內建的管控來標記異常和質量問題很重要

132、。就像在構建流水線中的單元測試,dbt-expectations 在數據管道運行時進行斷言。在 dbt 中,你可以直接編寫 Great Expectations 風格的測試對你的數據倉庫數據質量測試。我們的團隊已經開始探索它,并強調其是有意義的。95.Directus評估我們評估了 Directus 作為一種無頭內容管理系統(content management system,CMS)。盡管無頭 CMS 系統有很多可選項,但我們期望它是一個自托管解決方案,包含豐富的數字資產管理和內容創作工作流程。根據這些標準,我們發現 Directus 完全滿足這些需求,特別是它通過 flows 實現的事件驅

133、動數據處理和自動化功能。96.Ferrocene評估近年來 Rust 語言因其安全性、性能和并發特性而越來越受歡迎,然而,在汽車等安全攸關市場仍缺少經過認證的 Rust 工具鏈。目前這個缺口正在由 Ferrocene 這一 Rust 編譯器工具鏈所填補。Ferrocene 承諾符合道路車輛電子系統的 ISO26262 功能安全標準,同時它也正在努力使該領域中使用的語言和工具鏈也符合條件。這部分工作也在加速推進中,我們對此感到興奮,可以使用此類符合安全標準的工具肯定會加速 Rust 在汽車行業的應用。97.Flutter 嵌入式平臺評估Flutter 嵌入式平臺使得創建和維護現代 UI(mode

134、rn UI)變得相對容易,這種 UI 類似于移動應用程序卻適用于嵌入式系統,如汽車、冰箱和其他消費類電器中的人機界面(HMI)。因為 Flutter 現在支持自定義嵌入器,從而語言和框架 Thoughtworks,Inc.All Rights Reserved.41使其移植到不同的平臺成為可能。這些應用程序使用 Dart 編程語言編寫,使用 Flutter SDK 及其生態系統。我們一直在用它構建原型 我們的開發人員喜歡這種開發體驗,我們的客戶喜歡它帶來的靈活、速度和現代化的用戶體驗。98.Fugue評估在數據工程領域,可選用工具和技術數量之多,讓人眼花繚亂。對于經驗較少的工程師,借助一個抽象

135、層來接觸這些工具未嘗不是一種合理的對策。這讓他們能夠專注于手頭的任務,而不必分心去學習各個技術專用的 API,并且可以不費力地配置不同的底層實現技術。Fugue 就是這樣一個抽象層。它為分布式計算提供統一的接口,使得在 Spark、Dask、Ray 和 DuckDB 經過較少的修改就能運行 Python、pandas 和 SQL 代碼。不過,如果團隊已經決定采用某一組確定的技術,并且熟悉這些技術的 API,能夠對工具的系統底層做深入的調整和設置,那么這樣的抽象層提供的價值就會降低。99.Galacean Engine評估Galacean Engine 是一個 Web 和移動優先的交互引擎,旨在

136、提供一種無縫的方式,以移動友好的方式渲染基于組件的架構和動畫。憑借其對輕量級和高性能渲染的關注,它已成為開發者創建引人入勝的移動游戲時一個越來越受歡迎的選擇。它是一個基于 TypeScript 的引擎,開發者稱其性能優于其他引擎。100.LangChain評估LangChain 是一個用于構建基于大型語言模型(LLMs)應用的框架。這些模型已經引起了一場生成式人工智能在各種場景下的競賽。但是,單獨使用這些 LLMs 可能是不夠的你必須將其與差異化的資產相結合去構建有影響力的產品。LangChain 提供了一些方便的功能去填補了模型和應用之間的裂痕,這些功能包括提示管理,組件鏈式連接,生成增強數

137、據及豐富的用于確定執行動作和順序的代理。我們期待基于 LLMs 演變出更多的工具和框架,并且我們推薦對 LangChain 進行評估。101.mljar-supervised評估mljar-supervised 是一個 AutoML Python 包,協助理解和解釋表格式數據。我們的數據科學團隊很喜歡它,并已開始使用它進行自動探索性數據分析。為了找到最佳模型它抽象了如下常用方法:預處理數據、構建機器學習(ML)模型和執行超參數調整??山忉屝院屯该鞫仁侵匾脑瓌t,而這正是 mljar-supervised 的亮點。它會為每個 ML 模型都生成一個詳細的 Markdown 報告,讓你清晰地看到 M

138、L 管道是如何構建的。這絕對是一個有趣的 AutoML 包,值得你在 ML 需求中嘗試。語言和框架 Thoughtworks,Inc.All Rights Reserved.42102.nanoGPT評估nanoGPT 是一個用于對中等規模的生成式預訓練 Transformer(GPT)進行訓練和調優的框架。其作者 Andrej Karpathy 基于注意力機制和 OpenAI 的 GPT-3 兩篇論文的理論,使用 PyTorch 從零開始構建一個 GPT。在生成式人工智能火熱的趨勢下,我們想要強調 nanoGPT 的簡潔性,并且注重對 GPT 架構的構建模塊進行清晰 呈現。103.pande

139、ra評估在之前的雷達中,我們介紹了例如 Great Expectations 的數據驗證和測試平臺,其可用于驗證假設并測試用于培訓或分類的輸入數據的質量。但是有時候,只需要一個簡單的代碼庫就可以直接在流水線中實現測試和質量檢查。pandera 是一個 Python 庫,用于測試和驗證跨各種框架類型的數據,例如 pandas,Dask 或者 PySpark。pandera 可以實現關于字段的簡單斷言或基于統計模型的假設驗證。其廣泛支持的框架庫意味著只需編寫一次測試就可以應用于各種底層數據格式。此外,pandera 還可以用于生成測試 ML 模型的合成數據 synthetic data to te

140、st ML models.104.Qwik評估創建一個豐富、交互式的基于瀏覽器的體驗的挑戰之一就是盡量縮短從第一次請求到用戶可以進行完整交互的時間。在網頁剛打開時,應用程序可能需要下載大量的 JavaScript 到瀏覽器中,或者在服務器上執行一個漫長的過程來恢復應用程序狀態。Qwik 是一個新的前端框架,它通過序列化應用程序狀態,使其可以在服務端渲染而無需重新激活和重現程序的狀態。這是通過“可恢復性”來實現的,應用程序的執行可以在服務器上暫停,并在需要時在客戶端上恢復。與其他較新的前端框架(如 Astro 或 Svelte)一樣,Qwik 也通過減少需要加載的 JavaScript 的數量來

141、加速初始頁面的加載。但 Qwik 在應用程序初始化時會只下載基本 HTML,大多數JavaScript 在需要時動態地從本地緩存中加載(如果可能的話)。105.SolidJS評估SolidJS 是一個用于創建用戶界面的聲明式 JavaScript 庫。在過去的一年里,我們看到 SolidJS 在開發者中的出現次數和受歡迎程度有所提高,尤其是那些對創建更豐富的用戶互動感興趣的開發者。SolidJS 將其模板編譯為真實的 DOM 節點(而不是使用虛擬 DOM),并通過細粒度的反應來更新它們,這減少了不必要的 DOM 更新,從而獲得更快的性能和更好的用戶體驗。它的 API 很簡單,并且很好的支持了

142、TypeScript,這對開發過程中發現錯誤很有幫助。SolidJS 的另一個好處是它的組件包很小,這對于快速構建和輕量級的網絡應用來說非常合適,特別是移動優先的場景。SolidJS 是一個相對較新的框架,它不像其他框架那樣擁有龐大的社區或生態系統。然而,從越來越多的有用的庫和工具來看,它似乎越來越受歡迎。它的反應式更新系統、功能性組件模型和模板系統使 SolidJS 成為一個有吸引力的選擇,我們看到一些團隊和社區對其感興趣。語言和框架 Thoughtworks,Inc.All Rights Reserved.43106.Turborepo評估單一代碼庫的話題似乎永遠會引起我們的興趣。一些地方

143、已經采用了單一代碼庫來管理整個組織的代碼,而另一些地方則將這個概念應用于某些特定的應用程序,比如移動應用程序或組合的 UI/BFF 開發。無論單一代碼庫是否適合使用,行業似乎都在重新尋找能夠有效地管理大型代碼庫并將它們構建成可部署單元的工具。Turborepo 是這個領域中的一個相對較新的工具,它為大型的 JavaScript 或 TypeScript 代碼庫提供了一種與Nx 或 Lerna 不同的選擇。大型代碼庫的挑戰之一是如何快速地執行構建,以使其不會中斷開發者的流程或降低效率。Turborepo 是用 Rust 編寫的,這使得它有不錯的性能;它還采用遞增構建和緩存中間步驟的方法,進一步加

144、速構建過程。但是,它會改變開發者工作流程,需要時間學習,并且最適用于具有需要多個不同的方法獨立構建的大型代碼庫。我們發現 Turborepo 的文檔很少,這導致一些團隊目前仍然堅持使用更成熟的工具。然而,Turborepo 及其新的伴侶 Turbopack(目前處于測試版)是否繼續發展仍值得評估和查看。107.WebXR 設備 API評估在使用具有實驗性的 WebVR API 時,明顯可以發現將 VR 和 AR 合并到一個 API 中更加合理。為此,誕生了一個新的規范:WebXR,以避免大幅改變原有的 WebVR API。WebXR 的核心是 WebXR 設備 API,它為在網頁瀏覽器中編寫 VR 和 AR 應用提供了關鍵的能力。這個 API 用途廣泛,但在寫下該評論時,它還未被所有的瀏覽器完全支持。我們的團隊在一些場景中使用了 WebXR,并在其中發現了 Immersive Web Working Group 所描述的好處。對于原型,我們特別喜歡的是用戶可以立即在網頁瀏覽器中進行體驗。開發團隊不需要到應用商店完成上架流程,用戶也可以無需安裝應用就可以嘗試體驗??紤]到 API 的現狀以及它在某些瀏覽器中還是一個需要手動打開的隱藏功能的實際情況,我們還沒有發現它在概念驗證和原型之外的用途。語言和框架

友情提示

1、下載報告失敗解決辦法
2、PDF文件下載后,可能會被瀏覽器默認打開,此種情況可以點擊瀏覽器菜單,保存網頁到桌面,就可以正常下載了。
3、本站不支持迅雷下載,請使用電腦自帶的IE瀏覽器,或者360瀏覽器、谷歌瀏覽器下載即可。
4、本站報告下載后的文檔和圖紙-無水印,預覽文檔經過壓縮,下載后原文更清晰。

本文(ThoughtWorks:技術雷達-有態度的前沿技術解析(第28期)(43頁).pdf)為本站 (海平線) 主動上傳,三個皮匠報告文庫僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對上載內容本身不做任何修改或編輯。 若此文所含內容侵犯了您的版權或隱私,請立即通知三個皮匠報告文庫(點擊聯系客服),我們立即給予刪除!

溫馨提示:如果因為網速或其他原因下載失敗請重新下載,重復下載不扣分。
客服
商務合作
小程序
服務號
折疊
午夜网日韩中文字幕,日韩Av中文字幕久久,亚洲中文字幕在线一区二区,最新中文字幕在线视频网站