架构设计参考项目系列主题：Thoughtworks 第 29 期技术雷达——工具象限概览

本文转自：Thoughtworks 洞见

工具象限

采纳

42. Mermaid

Mermaid 通过使用类似 Markdown 的标记语言来生成图表。自从上次在技术雷达中介绍以来，Mermaid 添加了对更多图表和与源代码存储库、集成开发环境和知识管理工具集成的支持。值得注意的是，它在 GitHub 和 GitLab 等流行源代码存储库中得到原生支持，从而可以在 Markdown 文档中嵌入并轻松更新 Mermaid 图表。我们的许多团队都倾向于使用 Mermaid 作为他们的图表即代码工具，因为它易于使用、集成广泛，且支持的图表类型不断增多。

43. Ruff

Ruff 是一个新的 Python linter 。使用 linter 是毋庸置疑的，只需要考虑具体要使用哪一个。Ruff 能够脱颖而出有两个原因：开箱即用的体验，以及性能。其中内置了500多条规则，可以轻松取代 Flake8 和它的许多插件。我们的经验证实了 Ruff 团队对其性能的说法。实际上，它的速度至少比其它 linter 快出一个数量级，这是一个巨大的优势，有助于减少大型代码库的构建时间。基于上述原因，Ruff 已成为我们实施 Python linter 的默认选择。

44. Snyk

Snyk 提供静态应用程序安全测试（SAST）和软件组件分析（SCA）测试，以帮助您在软件开发生命周期中寻找、修复和监控安全问题。其广泛的功能旨在加快反馈循环，倾向于采用“左移”方法，而不是安全三明治反模式。作为今天可用的最佳安全平台之一，Snyk 之所以脱颖而出，是因为它能够识别更广泛的问题，而这主要得益于有专门的研究团队不断更新其漏洞数据库。

但是 Synk 仍有改进的空间：仪表板目前没有提供一个简便的方法从一个具体的可操作的信息中过滤一些多余繁杂的信息；根据语言生态系统的不同，基于 SCA 的集成可能与基于流水线的集成相比产生误报，因为 Snyk 必须猜测已解决的依赖关系；自动解决方案的成功性不一致；在高度监管的环境中，需要进行重大的集成投资，以实现适当的门控或建立软件物料清单。尽管存在这些缺点，我们的许多企业客户依然采用了 Snyk，我们自己也在 IT 部门中使用了它。

试验

45. AWS Control Tower

在 AWS 中，多团队的账户管理是一项挑战，尤其是在设置和治理方面。AWS Control Tower 通过简化设置和自动化治理来应对这个挑战，并通过防护措施应对监管要求。AWS Control Tower 内置了一个账户工厂，帮助自动化账户的配置流程。您可以通过账户工厂来取消账户托管、更新和关闭创建与配置的账户。由于其缺乏自动化和定制化，亚马逊引入了 Terraform 的 AWS Control Tower 账户工厂 （AFT） 。AFT 允许配置定制化的 Webhook 或特定操作，以便与其他工具集成来启动账户创建流程。我们的团队通过整合一组开箱即用的账户配置项，一劳永逸地为 GitHub Actions 的角色做了基础设置和访问权限的配置。这可为开发者提供一个完全集成 VPC 安全基线、可用于 GitHub Actions 接收工作负载的账户。我们的团队报告说，使用 AWS Control Tower 和 AFT 统一管理多个团队的账户非常方便。

46. Bloc

Bloc 是 Flutter 的一款响应式状态管理库。在 Flutter 可用的状态管理选项中，我们想突出 Bloc，因为我们团队在使用该库构建复杂移动应用程序时体验很好。当UI组件通过流和事件接收器与业务逻辑进行通信时，围绕 BLoC 模式结构化的组织代码实现了业务逻辑与表示层的完全分离。Bloc 在 IntelliJ 和 VSCode IDE 中都提供了良好的插件支持。

47. cdk-nag

cdk-nag 能够识别并报告 AWS CDK 应用程序或 CloudFormation 模板中的安全性和合规性问题。它附带了几个所谓的规则包：一个通用的 AWS 规则包，包括 AWS 认为的最佳实践检查，以及用于 HIPAA、NIST 和 PCI 合规性的规则包。您可以根据需要添加额外的规则。规则可以导致警告或错误，这两者都包含在工具生成的报告中。当存在错误时，cdk deploy 命令将无法进行部署。如果错误的原因无法及时修复，仍然可以在错误存在但已被抑制的情况下进行部署。显然，这应该只在特殊情况下执行。

48. Checkov

Checkov 是一个专门用于基础设施即代码（laC）的静态安全扫描器。它支持多种基础设施语言，包括 Kubernetes清单、Helm 图表、CloudFormation 模板和 Terraform。它可在 CI/CD 管道中轻松部署，防止各种云基础设施配置中出现潜在的安全漏洞。它利用一套默认规则，识别常见的安全情景，并在其网站上提供详细的修改建议。Checkov 支持自定义规则，并使用 YAML 进行简单的准则定义，或使用 Python 制作更复杂的准则定义。我们的团队已成功使用 Checkov 在基础架构部署过程中增强安全性，并对其在部署前提供的潜在问题表示欣赏。

49. Chromatic

Chromatic 是一款可视化回归测试工具，可帮助捕捉网络应用程序中的用户界面回归。它的工作原理是拍摄用户界面组件的快照，并在组件发生变化时将其与之前的快照进行比较。Chromatic 是一种托管服务，可与流行的云代码托管服务集成。它建立在 Storybook 之上，进行组件级可视化回归测试。它可以在不同的视口宽度下渲染组件，以进行响应式测试，并与 CI 工作流集成，为每次提交生成用户界面变更集，从而方便审查。我们的团队发现 Chromatic 与该领域其他工具的视觉差异要大得多；可视化高亮显示变更的功能让它非常实用。

50. Cilium

eBPF 以其应用透明、高性能和低开销而闻名，因此云原生社区一直在探索其在无边车网格服务（service mesh without sidecar） 中的应用场景。Cilium 是一个为云原生环境如（Kubernetes 集群和其他容器编排平台）提供网络、安全性和可观察性的开源项目。Cilium 为路由或覆盖网络提供了一个简单的第三层网络，并且还支持 L7 协议。通过将安全性从寻址中解耦，Cilium 可以作为一种新的网络保护层发挥重要作用。我们已经看到一些云服务提供商采用了 Cilium，我们的一些项目中也使用了 Cilium。社区仍在讨论 eBPF 是否可以替代边车（sidecar），但似乎这已经达成共识，即某些网格功能不能或不应该在内核中执行。此外，使用 Cilium 还需要 eBPF 相关的经验。基于我们项目取得的良好成果，我们建议您亲自实践一下这项技术。

51. 云服务的碳足迹

Cloud Carbon Footprint (CCF) 是一款估算主要云服务提供商的云工作负载碳排放量的开源工具。它通过云平台的 API 查询资源使用数据，并使用多种（数据）来源跟踪碳排放情况。CCF 遵循公开发布的方法，将这些数据合并为排放量估算值，并提供随时间变化的数据可视化。云提供商已经开始在其平台上添加类似产品，但是一些企业仍在部署 CCF，因为它具有以下所有功能：它是开源的，可扩展的，能跨多云工作，并且有一个透明公开的计算方法。此外，它还包括范围 2 和范围 3 排放的估算，分别针对电力使用和硬件生产。在我们的实验中，不同工具的估算结果不尽相同，这并不奇怪，因为该领域的所有工具都会进行估算，并将估算值相乘。然而，确定一种工具、设定基准线并在此基础上进行改进是我们遇到的主要使用场景，类似 Kepler 这样的工具可能会在未来减少对估算的需求。CCF 还提供基于 GCP 和 AWS 的优化建议，这不仅有助于减少云服务的碳足迹，还可以成为更广泛的云成本优化战略的一部分。Thoughtworks 是 CCF 的重要贡献者。

52. 容器结构测试

容器结构测试 (CST) 是由 Google 开发的一个工具，用于测试容器镜像的结构。CST 可以用于检查镜像文件系统中某个文件的存在或缺失，验证文件的内容，检查容器中发出的特定命令的输出或错误，并检查容器镜像的元数据（例如标签、入口点和命令），以确保符合 CIS Docker Benchmark 的规范。我们在使用 CST 方面有很好的经验，建议您可以试用一下。除了预防漏洞，检查容器是否暴露不必要的端口之外，我们还使用它来验证每个 Docker 容器是否满足在企业平台上部署和运行一个应用程序的所有必要要求。其中一个要求是镜像中安装了可观测性代理。需要注意的是，CST 并没有得到 Google 的官方支持，这可能会影响它的维护情况。

53. Devbox

Devbox 是一款基于终端的工具，具有便捷易用的界面，用于创建可重用，项目独立的开发环境，Devbox 利用 Nix 软件包管理器，而无需使用虚拟机或容器。我们的团队使用它消除不同项目的开发环境中 CLI 工具和自定义脚本的版本与配置不匹配的问题，以及标准化管理项目中不同语言包的提供。我们发现 Devbox 显著简化了项目入门流程，只要代码库配置了该工具，只需运行一个 CLI 命令（"devbox shell"）就能将开发环境配置到新机器上。Devbox 支持 shell 钩子、自定义脚本和生成便于集成 VSCode 的 devcontainer.json 。

54. DX DevEx 360

DX DevEx 360 是一款基于调查的工具，它通过聚焦开发人员在日常工作中面临的阻力点，如代码审查流程、代码质量、深度工作能力等，寻找提高开发人员生产力的关键指标。该调查由 Nicole Forsgren 和 Margaret-Anne Storey 制定，他们曾和其他专家一并主导了 DORA 和 SPACE 两个项目。

我们的平台工程团队已成功使用 DX DevEx 360 来了解开发人员的观点并识别存在的阻力点，从而为平台发展路线提供参考。与类似调查工具不同，使用 DX DevEx 360，我们获得了90%以上的回应率，开发人员通常会就问题和改进想法进行详细评论。该工具令人赞赏之处还有：它将结果透明化给公司的工程师，而不仅仅是经理，此外它支持按团队进行分析，从而实现每个团队环境的持续改进。

55. GitHub Copilot

GitHub Copilot 被我们的许多团队用来帮助他们更快地编写代码，总体来说，我们的绝大多数开发人员认为这个工具非常有用，并且如果我们限制这个工具的使用，他们可能会感到失望。我们一直在通过生成式 AI 探索集 和 Copilot 入门指南 整理和分享我们使用 Copilot 的经验。请注意，任何代码库都可以使用 Github Copilot，不局限于托管在 GitHub 上的代码库。

我们还很高兴看到自上次在技术雷达中亮相以来，来自 Copilot X 路线图 的 Copilot 聊天功能已经变得更加的普及。这是 Copilot 内联辅助功能的一个强大的补充。应用在 IDE 内的聊天界面，提高了常见信息检索的可发现性，并且与开放式编辑器上下文的集成使得对错误的研究或请求聊天协助执行与焦点代码相关的任务变得轻而易举。

56. Insomnia

自从 Postman 在2023年5月宣布将逐渐淘汰具有离线功能的 Scratch Pad 模式以后，需要将 API 工作区数据从第三方服务器上隔离的团队不得不寻找替代方案。Insomnia 就是可选的替代方案之一：这是一款专为 API 测试、开发和调试而设计的开源桌面应用程序。虽然 Insomnia 支持在线同步，但它可以让你离线保存 API 工作区数据。我们的团队发现，从 Postman 到 Insomnia 进行人工 API 测试是无缝迁移的，因为它们功能相似，而且 Insomnia 允许导入 Postman 的集合。尽管我们的团队在 Insomnia 上获得了良好的体验，但我们仍在关注其他各种形式的开发替代方案——从 GUI 工具（如即插即用的Insomnia），到 CLI 工具(如 HTTPie), 再到 IDE 插件(如 IntelliJ HTTP 客户端插件)

57. IntelliJ HTTP 客户端插件

IntelliJ HTTP 客户端插件允许开发人员在代码编辑器中创建、编辑和执行 HTTP 请求，从而简化了构建和使用 API 的开发流程。

它在我们的团队中越来越受欢迎，团队成员们喜欢它的用户友好性和便利性。它的显著特点包括支持私有文件（默认情况下将敏感密钥排除在 git 之外，从而保护这些密钥）、版本控制和使用变量的能力，这增强了开发者的体验。鉴于它能简化开发人员的工作流程并增强安全措施，我们建议您尝试使用这个工具。

58. KEDA

KEDA 全称 Kubernetes Event-Driven Autoscaler，正如名字所展示的，它可以根据需要处理的事件数量来伸缩 Kubernetes 集群。根据我们的经验，相比采用 CPU 使用率等滞后指标，更加推荐使用队列深度等领先指标。KEDA 能支持不同的事件源，并提供了一个包含50多种自动缩放器的工具箱，可用于各种云平台、数据库、消息系统、遥测系统、CI/CD 系统等。我们的团队报告称，KEDA 的易集成性使他们能够继续在 Kubernetes 中运行微服务的全部功能，否则可能会考虑将一些事件处理代码转移到无服务器函数中。

59. Kubeconform

Kubeconform 是一个用来验证 Kubernetes 清单和自定义资源 (CRD) 的简化工具。它能很容易地在 CI/CD 流水线或本地机器中部署，通过在部署前验证资源，以减少潜在的错误。鉴于 Kubeconform 在加强运行保证方面有良好记录，特别是在跨团队共享模板资源方面，我们建议试用 Kubeconform 以提高资源验证流程的安全性和效率。

60. mob

mob 是一个用于远程结对编程或集体编程中无缝进行 git 交接的命令行工具。它将所有版本控制工具隐藏在一个命令行界面背后，这使参与集体编程会话变得更加简单。它还提供了关于如何远程参与的具体建议，例如，在 Zoom 中“窃取屏幕共享”，而不是结束屏幕共享，以确保参与者的视频布局不发生变化。我们的一些团队强烈推荐 mob，并且它已经成为我们在远程协作或集体编程中工具链的重要组成部分。

61. MobSF

MobSF 是一个开源的、自动化的静态和动态安全测试工具，用于检测 iOS 和 Android 移动应用程序中的安全漏洞。它扫描应用程序源代码和二进制文件，并提供有关漏洞的详细报告。MobSF 以 Docker 镜像的形式分发，并提供易于使用的 REST API，可以通过 mobsfscan 集成到持续集成/持续发布流水线中。我们使用 MobSF 对 Android 应用程序进行安全方面测试的体验是积极的，我们建议您尝试使用它来满足您对移动应用程序安全测试需求。

62. Mocks Server

Mocks Server 是一个基于 Node.js 的 API Mock 工具，它能够复制复杂的 API 响应、响应头和状态码，因此受到了我们团队的重视。它的动态响应生成支持模拟多种场景，允许对 API 交互进行严格测试。Mock 可以描述为 YAML 或 JSON，并通过 CLI、REST API 或 JavaScript 代码进行管理。Mocks Server 的功能包括请求匹配、代理和录制重现功能，这些功能有助于模拟真实的 API 交互。我们特别喜欢将它与 Docker 容器集成，使其可以轻易地在不同环境之间一致地部署，因此它可以作为整个生态系统的一种构件进行版本控制和维护。它简单直接的方法与我们在开发过程中强调的简单性和效率相一致。随着我们的解决方案和测试策略的演进，我们期待更广泛地使用 Mocks Server。

63. Prisma 运行时防护

Prisma 运行时防护是 Prisma 云套件的一部分，为容器安全提供了一种新方法。它采用一种机制来建立容器预期行为模型，然后在运行期间发现异常时检测并阻止异常活动。Prisma 运行时防护监控容器进程、网络活动和文件系统，查找表明可能正在进行攻击的模式和变化，并根据配置的规则进行阻止。学习构成“正常”行为的模型是通过对 Docker 镜像的静态分析和预先配置的时间段内的动态行为分析构建的。我们的团队从使用中发现了可喜的成果。

64. Terratest

Terratest 仍是我们感兴趣的基础设施测试工具。

它是一个 Golang 库，用来简化基础设施代码的自动化测试编写。通过基础设施即代码的工具，例如 Terraform，你可以创建真实的基础设施组件(如服务器、防火墙或负载均衡器)，在它们之上部署应用程序，并使用 Terratest 验证预期的行为。在测试结束后，Terratest 可以取消应用的部署并清理资源。

我们的团队们认为这种测试基础设施组件的方式有助于提供对基础设施即代码的自信。我们看到我们的团队们对应用组件和它们之间的集成编写了各种基础设施安全测试，包括检查错误配置，验证访问权限（比如检查特定 IAM 角色和权限是否被正确配置），检查对敏感资源的未认证访问的网络安全测试等这使得安全测试左移并在开发过程中提供反馈成为可能。

65. Thanos

尽管 Prometheus 一直是自维护可观察性工具链中的一个可靠选择，但当监测指标在基数和总量上增长，以及开始需要高可用性设置时，许多管理现代云原生分布式系统的团队都会碰到其单节点的限制。Thanos 通过添加一些适用于大规模、长期和高可用性监控的功能来扩展 Prometheus 。例如，它引入了一些组件将从 Prometheus 实例中读取的数据存储到对象存储系统中，管理对象存储系统对数据的保留和压缩，并且横跨多个 Prometheus 实例做联合查询。我们的团队发现从 Prometheus 迁移到 Thanos 是无缝的，因为 Thanos 保持了与 Prometheus 查询 API 的兼容性。这意味着团队可以继续使用现有的仪表板、警报工具和其他与 Prometheus API 集成的工具。尽管我们的团队在使用 Thanos 上已经取得了成功，但我们也推荐关注另一种扩展 Prometheus 的方式 —— Cortex 。

66. Yalc

Yalc 是一个简易的本地 JavaScript 包管理库以及跨本地开发环境进行发布与包管理的工具。对于有一些限制的 npm link 指令来说，Yalc 是一个更可靠的替代品。在使用多个包的时候 Yalc 特别好用，尤其是当有些包使用 yarn，而有些包使用 npm 的时候。它同样能帮助在发布包到远端之前进行本地的测试。根据我们的经验，Yalc 在配置多个包和加速前端以及其他 JavaScript 应用开发的工作流方面非常有价值。

评估

67. ChatGPT

ChatGPT 继续引起关注。随着充满想象力的应用场景和创造性地提示词的涌现，它正在不断扩大其实用性。GPT4这一驱动 ChatGPT 的大语言模型(LLMs)，现在也有能力与知识管理库、沙箱编程环境或网络搜索等外部工具进行集成。最近推出的 ChatGPT 企业版提供了使用情况记录和通过单点登录的用户管理等“企业版”功能，可能有助于缓解一些关于知识产权的担忧。

尽管 ChatGPT “编写”代码的能力受到了诸多赞誉，但我们认为组织更应考虑在全软件生命周期范围内利用它来提高效率并减少错误。例如，ChatGPT 可以为需求分析、架构设计或对遗留系统进行逆向工程等任务提供额外的视角和建议。我们仍认为 ChatGPT 最好作为一个流程的输入—— 例如起草一个故事的初稿或给出某项编码任务的框架——而不是一个生成“成熟”结果的工具。话虽如此，ChatGPT 的能力还在持续增强，通过谨慎地给出提示词，它已经可以完成很多编程任务。而提示工程本身就是一门艺术。

68. Codeium

在 AI 编程辅助工具中，Codeium 是一款较为有前景的产品。类似于 Tabnine，Codeium 也尝试去解决公司使用编程辅助工具最担心的问题：通过不使用无授权代码训练自己的模型，他们消除了部分开源代码许可证带来的担忧。同时他们允许您自托管这个工具，所以无需向第三方发送代码片段。Codeium 在广泛支持各种 IDE 和计算笔记本上表现突出， 并且虽然它的出现晚于 GitHub Copilot 和 Tabnine，但是我们对这一产品的第一印象非常正面。

69. GitHub 合并队列

我们一直是短暂开发分支的倡导者，这些分支经常合并到主代码分支中，主代码分支始终准备好进行部署。这种主干开发的实践与持续集成密切相关，并且在条件允许的情况下，可以实现最快的反馈循环和最高效的开发流程。然而，并不是每个人都喜欢这种方法，我们经常根据客户的实践来调整我们的风格。有时，这包括长期存在的特性分支和拉取请求必须被手动审查和批准，然后才能将它们合并到主分支中。在这些情况下，我们使用新的 GitHub 合并队列功能。它允许我们自动排队接收的拉取请求，并将它们合并到特殊分支中，按接收顺序进行排序。然后，我们可以选择自动执行我们自己的“合并检查”，以防止不兼容的提交。这本质上是模拟主干开发（即使 PR 尚未合并到主代码分支中），允许开发人员在上下文中测试其功能，而无需等待批准拉取请求。使用 GitHub 合并队列，即使你不能直接提交到主干，也可以获得主干开发的好处。

70. Google Bard

Google Bard 是由 Google AI 开发的生成式 AI 聊天机器人。与 ChatGPT 非常相似，它能够通过生成类似人类的文本，会话式地对各种提示和问题提供回复。Bard 由 Google 的 Pathways 语言模型 (PaLM 2) 提供支持，PaLM 2 是在海量文本和代码数据集上训练出的大语言模型(LLM)。Bard 能够生成文本、翻译语言、生成各种创意内容，以及详尽回答提出的问题。

Bard 还可以指导软件开发。我们的开发人员发现，Bard 有时可以针对不同场景提供一些编码建议、最佳实践或基础设施配置。我们还尝试使用 Bard 翻译技术雷达，可以得到不错的初稿。尽管该工具仍在开发中，与 ChatGPT 相比它可能会慢一些，但我们仍然鼓励开发人员探索使用这个工具，并评估其潜在优点。

71. Google Cloud 工作站

Google Cloud 工作站 是 GCP 提供的云端开发环境（Cloud Development Environment，CDE）。它提供了完全托管的容器化开发环境，可以通过 SSH、HTTPS、VSCode、Jetbrains IDEs 等多种方式进行访问，使开发人员可以享受和连接本地环境一致的体验。Google Cloud 工作站允许管理员将容器化开发环境纳入私有网络，并可以选择使其对外公开或仅在内部访问。这种网络配置的灵活性，再加上支持使用自定义或预定义的镜像构建环境，使得 Google Cloud 工作站，在我们看来，值得那些在其 GCP 边界内寻找安全的 CDE 解决方案的组织将其纳入评估。如果您正在考虑使用 Google Cloud 工作站，我们建议在广泛推广之前先测试网络配置，因为高延迟可能会对开发者在这些容器中的使用体验造成一定的影响。

72. Gradio

Gradio 是一个开源的 Python 库，它能够帮助我们快速简单地为机器学习模型创建基于Web的交互式界面。基于机器学习模型的图形化界面，使得非技术受众能够更好地理解输入、约束和输出。Gradio 支持多种输入和输出类型，从文本到图像再到语音，并且它已经成为了快速原型设计和模型评估的首选工具。Gradio 可以让您轻松地将您的演示托管到 Hugging Face ，或者在本地运行它，然后允许他人通过带有"XXXXX.gradio.app”的 URL 来访问您的远程演示。例如，著名的DALL-E迷你实验就是利用 Gradio实现，并且托管在 Hugging Face Spaces。我们的团队在实验和原型设计中使用这个库的体验非常愉快，这也是我们将其纳入评估的原因。

73. KWOK

KWOK (Kubernetes WithOut Kubelet) 是一个模拟虚拟节点和pod生命周期的工具，旨在测试Kubernetes 集群的控制面板。在没有显著大型集群的情况下，很难对自定义 Kubernetes 控制器和操作器进行压力测试。然而，通过 KWOK，你可以在笔记本电脑上轻松设置一个拥有数千个节点的集群，而无需消耗大量 CPU 或内存资源。这种模拟支持节点类型和 pod 的不同配置，以测试各种场景和边缘情况。如果你需要一个真正的 Kubernetes 集群来测试操作器和自定义资源定义 (CRDs)，我们推荐 kind 或 k3s; 但如果你只需要模拟大量的虚拟节点，那么我们建议你评估KWOK。

74. Llama 2

Llama 2 是一个来自 Meta 的强大的语言模型，可免费用于研究和商业用途。它既提供原始的预训练模型，也提供了经过微调的用于对话的 Llama-2-chat 和用于代码补全的 Code Llama 。Llama 2 提供了多种尺寸的模型 —— 7B、13B 和 70B ，因此如果您想控制自己的数据，Llama 2 是自托管式大型语言模型的一个好选择。

Meta 声称 Llama 2 是“开源”的，但这一说法受到了一些批评。Meta 的许可证和适用策略对用户的商业用途以及对模型和软件的用途做了限制。Llama 2 的训练数据并不开放，这可能会阻碍理解和修改模型。尽管如此，至少在“半开放”的形式下，一个强大、能干的模型仍然是值得欢迎的。

75. Maestro

Maestro 是一款新的跨平台移动端 UI 测试自动化工具，它内置了由网络因素导致的应用加载时长变化的容错能力。通过声明式的 YAML 语法，它使编写和维护移动应用自动化测试变得很简单。Maestro 支持 iOS 和 Android 原生应用、 React Native 和 Flutter 应用，能够自动化复杂的移动端UI交互(如点击、滚动和滑动)的各种功能。Maestro 以单个二进制文件进行发布、方便使用，以解释器模式运行，并且通过连续模式等特性来简化新的测试的编写。尽管 Maestro 对 iOS 设备的特定功能还欠缺支持，但该工具正在迅速演进。

76. Open-source LLMs for coding

GitHub Copilot 是软件开发时有价值的辅助编程工具。而在工具背后，大语言模型（LLMs）通过赋能内联代码助手、代码微调和 IDE 中的对话支持等方式，无缝提升开发人员的体验。大多数这些模型都是专有的，只能通过订阅服务使用。好消息是，您可以使用几种开源的 LLMs 进行编码。如果您需要构建自己的编码辅助服务（比如受到高度监管的行业），可以考虑  StarCoder 和 WizardCoder。StarCoder 使用由 BigCode 维护的大型数据集 进行训练，而 Wizardcoder 是  Evol-Instruct 调整后的 StarCoder 模型。

我们在实验中使用了 StarCoder，发现它对于生成诸如代码、YAML、SQL 和 JSON 等 结构化软件工程元素十分有用。根据我们的实验，我们发现这两个模型都可以使用提示词中的 小样本示例 进行上下文学习 。尽管如此，对于特定的下游任务（例如为 Postgres 等特定数据库生成 SQL），模型仍需要微调。最近，Meta 推出了 Code Llama，一款专用于编程的 Llama 2。使用这些开源模型时务必要小心谨慎。在选择任何这些编码 LLMs 供您的组织使用之前，请考虑它们的许可，包括代码的许可和用于训练模型的数据集的许可，仔细评估这些方面后再做决定。

77. OpenCost

OpenCost 是一个开源项目，用于监控基础设施成本，并以 Kubernetes 对象（Pod、容器、集群等）的粒度展示成本信息，涵盖各种集群内资源（CPU、GPU、RAM、存储、网络）的成本数据。它与多个云服务提供商的 API 进行集成，以获取计费数据，并可配置用于本地 Kubernetes 集群的定价策略。OpenCost 是最初由 Kubecost 构建并仍被其使用的成本分配引擎，但也可以单独使用。OpenCost 的成本分配数据可以导出为 CSV 文件或导入到 Prometheus 进行进一步分析和可视化。我们的团队正在密切关注像 OpenCost 和 Kubecost 这样的工具的发展，这些工具可以为采用 Kubernetes 的产品和平台团队提供成本可见性。然而在目前的阶段，我们发现 OpenCost 在某些工作负载（如数据管道中经常使用的短期 Spot 实例）上尚不完全适用。

78. OpenRewrite

我们已经看到了一些代码智能工具的使用案例：例如把一个广泛使用的库迁移到新的 API 版本，了解一个库中刚发现的漏洞对整个企业的影响，以及对从同一模板创建的多个服务应用更新时。在这一领域，Sourcegraph 仍然是一个很受欢迎的工具。OpenRewrite 是另一个我们想提及的工具。我们的团队已经在 Java 中使用它解决特定的问题，比如更新用入门套件创建的服务。目前它仍在持续拓宽覆盖的语言和使用案例。我们喜欢它附带的变革方案，这些方案描述了需要进行的更改，例如用于跨版本迁移常用框架。重构引擎、捆绑方案和构建工具插件都是开源软件，这使得团队在需要时可以更容易地使用 OpenRewrite。代码智能工具都是基于将源代码解析为抽象语法树（AST），这些工具将如何受到大语言模型领域快速发展的影响，我们拭目以待。

79. OrbStack

OrbStack 是在 macOS 上运行 Docker 容器的一种方式；我们的开发人员发现，与 Docker Desktop 和 Colima 相比，它更轻量、更快速并且更容易部署和使用。这个工具仍在开发阶段，所以目前功能较少，但其简洁和速度已经显示出了它的巨大潜力。您也可以使用 OrbStack 在 macOS 上创建和管理 Linux 虚拟机。

80. Pixie

Pixie 是一个用于 Kubernetes 原生应用程序的可观察性工具。它通过利用 eBPF 从多个 数据源 自动地采集遥测数据，以一种有趣的方式实现了可观察性。收集到的遥测数据被本地存储到每个节点上，并通过其控制平面 API 进行集中处理。总的来说，我们认为 Pixie 在 Kubernetes 生态系统中用于可观察性是值得评估的。

81. Tabnine

Tabnine 是目前炙手可热的编程助手领域的有力竞争者之一。它提供了内嵌的代码补全建议，以及直接在 IDE (Integrated development environment，集成开发环境) 中进行对话的能力。与 GitHub Copilot 类似，Tabnine 的出现远远早于现在这个各家纷纷大肆炒作的时期，也因此成为了该领域中最成熟的产品之一。与 Copilot 不同的是，Tabnine 使用的模型仅在获得授权的代码上进行训练，并提供了一个可以自行托管的版本，供担心其代码片段会被发送给其他第三方服务的组织使用。Tabnine 既提供有受限制的免费版本，也提供付费版本，后者会有更全面的建议，还提供了一种使用本地模型的模式（尽管功能较弱），供您在没有互联网连接的情况下使用。