工具
采纳
-
DVC 一直是我们在数据科学项目中管理实验的首选工具。由于 DVC 是基于 Git 的，因此对于软件开发人员来说，DVC 无疑是一个备感熟悉的环境，他们可以很容易地将以往的工程实践应用于数据科学生态中。DVC 使用其特有的模型检查点视图对训练数据集、测试数据集、模型的超参数和代码进行了精心的封装。通过把可再现性作为首要关注点，它允许团队在不同版本的模型之间进行“时间旅行”。我们的团队已经成功地将 DVC 用于生产环境，实现了机器学习的持续交付(CD4ML)。DVC 可以与任何类型的存储进行集成（包含但不限于 AWS S3、Google Cloud Storage、MinIO 和 Google Drive）。然而，随着数据集变得越来越大，基于文件系统的快照可能会变得特别昂贵。当底层数据发生快速变化时，DVC 借由其良好的版本化存储特性可以追踪一段时间内的模型漂移。我们的团队已经成功地将 DVC 应用于像 Delta Lake 这样的数据存储格式，利用它优化了写入时复制（COW）的版本控制。我们大多数的数据科学团队会把 DVC 加入到项目的“Day 0”任务列表中。因此，我们很高兴将 DVC 移至采纳。
试验
-
在任何组织中，API 的生产者和使用者都需要就他们之间通信所使用的模式保持同步。特别是随着 API 数量以及相关生产者和使用者人数在组织中的增长，最初在团队间传递模式的简单做法将面临挑战。面对这个问题，我们的一些团队使用了 Apicurio Registry，这是一个开源的、集中式的注册表，可以存储各种类型的模式和 API 文档，包括 OpenAPI 规范，Protobuf 和 Avro 模式。Apicurio Registry 允许用户通过 UI，REST API 和 Maven 插件等方式进行交互。它还有规定模式演进限制的选项，比如说向后兼容性。此外，当使用 Kafka 客户端时，Apicurio Registry 能与 Confluent Schema Registry 兼容。虽然我们的团队发现 Confluent Schema Registry 的文档更有帮助，但 Apicurio Registry 满足了对各种模式的真实来源的需求。
-
现在企业通常使用事件流作为真实数据的来源，并在微服务架构中作为信息共享机制。这就需要标准化事件类型并在企业范围内共享这些标准。通常企业会部署事件模式注册表，但现有的解决方案往往只适用于单个代理，比如 Apache Kafka 或 Azure Event Hub。此外，这些现有解决方案并不能提供超出简单模式定义的关于事件类型的详细文档。EventCatalog 是一个开源项目，为企业提供了一种广泛可访问的文档库，用于描述事件在业务种扮演的角色，它们在业务领域模型中的位置，以及哪些服务订阅和发布这些事件。如果您正在寻找一种向组织发布事件文档的方式，那么使用 EventCatalog 工具可能会避免您自己构建文档库的麻烦。
-
Gitleaks 是一个开源 SAST（静态应用安全测试）命令行工具，用于检测 Git 仓库以防止把密码、API 密钥和访问令牌等机密信息硬编码到代码中。它可以用于 Git 的 pre-commit hook 和 CI/CD 流水线。我们团队发现，Gitleaks 比其他一些密码扫描工具更灵敏。Gitleaks 使用正则表达式和 entropy coding 字符串编码检测机密信息。在我们的经验中，entropy coding 提供了灵活的自定义正则表达式，允许团队基于他们的需求对机密信息进行更好的分类。例如，相较于把所有的API密钥笼统地归类为“通用型 API 密钥”，entropy coding 允许把密钥归类到“云服务提供商密钥”这种特定分类中。
-
缺陷发现得越早，修复成本更小。这就是为什么我们总是试图以静态分析、单元测试或在本地环境中运行的端到端测试等方式，尽可能快地向开发者提供反馈。无障碍设计也不例外，这就是我们过去介绍 Lighthouse、axe-core 和 axe Linter 等工具的原因。当涉及到已经部署在生产环境中的网页时，我们的一个团队选择了 IBM Equal Access Accessibility Checker 来进行直接的比较。虽然我们还在评估结果，但我们可以说，它提供了一种有效的方法来测试已经发布了的网页。我们想要强调的是，这个工具应该用来增强而不是取代开发者的早期自动测试。该工具是在创作共用许可证（Creative Commons license）下发布的，在符合协议规定时可以免费使用。
-
随着 Kotlin 生态系统的持续发展，我们的团队报告了使用 Ktlint 的良好体验：这是一个用于 Kotlin 代码，简单且易于配置的 linter 和 formatter。我们喜欢有态度的代码格式化工具(Opinionated and automated code formatting)，因为这能让开发者更关注代码的行为，而不是它的外观；这个工具使开发团队能够高效的维护代码库的一致性和可读性，减少因格式问题而导致的混乱合并的可能性。Ktlint 可以很容易地配置在 pre-commit hook 中，它只针对有变化的文件，从而使集成过程更快。
-
当谈到密钥管理的时候，我们总是建议密钥与代码解耦。然而，团队却时常面临着取舍权衡，一种方式是基于基础设施即代码思想的全自动化，另一种方式是使用一些手动步骤和诸如 vaults 的工具去管理、生成、更新密钥。例如，我们的团队使用 SOPS 工具生成构建基础设施所需要的根密钥。然而在某些情况下，从遗留代码仓库中移除密钥并不现实。对于这类需求，我们发现 Mozilla SOPS 是一个很好的工具，可以用来加密文本文件中的密钥。SOPS 集成了诸如 AWS、KMS、Azure Key Vault 等密钥仓库作为待加密密钥源。它支持跨平台运行，也支持 PGP 密钥。
-
越来越多的团队在使用 Kubernetes Operators 模式来管理 Kubernetes 集群。为此，我们曾推荐过 Crossplane，现在有了另外一种选择——Terraform Cloud Operator。该工具通过扩展 Kubernetes 控制平面来集成 Terraform Cloud 和 Kubernetes，以通过 Kubernetes manifest 对云和本地基础设施进行生命周期管理。我们的团队使用它来提供资源，不管是 Kubernetes namespace，RoleBindings，云数据库实例，还是其他 SaaS 资源。我们非常喜欢它，因为它利用我们更熟悉的抽象层 Terraform 模块来操作云资源。
-
TruffleHog 是一款开源的静态应用程序安全测试工具（static application security testing，SAST），用于在各类源码中检测密钥信息。除了对 GitHub 和 GitLab 等最为常见的代码仓库进行扫描，TruffleHog 还能扫描 S3 和 GCS 等云存储桶、本地文件、本地目录以及 CircleCI 日志。开发人员可以将 TruffleHog 配置为 pre-commit hook 脚本，也可以直接使用它扫描一个 GitHub 组织的全部代码仓库历史记录。TruffleHog 支持自定义的正则语句模版，即使在当前的 alpha 阶段，该功能也十分易用。虽然 TruffleHog 有企业版本，但是我们发现开源版本的 TruffleHog 更易于配置和使用，并且覆盖了绝大多数的常见场景。TruffleHog 拥有一个非常活跃的社区，时不时就会有新的功能更新。
-
Vite 是一款前端构建工具，在之前的技术雷达被评为评估级别后变得更加成熟与流行。它迅速地成为了我们许多团队开始前端项目时的默认选择。Vite 提供了一套基于浏览器内 ES 模块的应用的构建，打包和依赖管理工具。因为它利用了 esbuild 原生的速度和 Rollup 进行打包, Vite 显著地提升了前端开发体验。此外，当与 React 一起使用时，Vite 为广泛使用却缺乏维护的 Create React App 提供了一个有吸引力的替代品。Vite 依赖于 ES 模块，不同于大多数旧工具，它不提供 shim 和 polyfills，这表示它不兼容那些不支持 ES 模块的旧浏览器。如果要支持旧浏览器，我们的某些团队会在模块层导入 polyfills 来让 Vite 能在多个环境都能使用。
评估
-
对于开发者来说，在开发过程的早期发现无障碍问题变得越来越容易。像 axe-core 这样的工具可以在流水线中扫描代码来寻找无障碍问题，而VSCode 扩展工具 axe Linter 甚至可以在这之前，例如在编写代码时就能发现它们。绝大部分无障碍问题都属于可以通过自动化测试和使用上述提到的实时反馈的提示工具(linter)来预防的类别。
-
ChatGPT 是一个有趣的工具，它具有在软件开发的各个方面发挥作用的潜力。作为一个已经"阅读"了数十亿个网页的大型语言模型（LLM），ChatGPT 可以提供额外的视角，协助完成不同的任务，包括生成创意和需求、创建代码和测试等。它是一种多功能的工具，能够跨越软件生命周期的多个阶段，提高开发效率并减少错误。GPT-4，作为驱动 ChatGPT 的 LLM，现在也具备与外部工具集成的能力，如知识管理库、沙盒式编码环境以及网络搜索。目前，我们认为 ChatGPT 更适合作为流程的输入，如帮助完成用户故事的初稿或编码任务的模板，而不是一个能够产出"完美周全"结果的工具。
使用这些人工智能工具可能会存在知识产权和数据隐私方面的担忧，包括一些尚未解决的法律问题，因此我们建议企业在使用前征求其法律团队的意见。我们的一些客户已经开始在软件生命周期的各个阶段尝试使用 ChatGPT，我们鼓励其他人探索这个工具并评估其潜在的作用。我们预计，像 GitHub Copilot 一样，ChatGPT 很快就会有一个"商业版"的产品，这可能会缓解知识产权方面的顾虑。
-
DataFusion 是数据社区将 Rust 的性能、内存安全、并发特征用于数据处理的新探索。它与 Polars 相似, 都提供了一套熟悉的 Rust 中的名为 DataFrame 的 API (包括 Python 绑定库)，使用了 Apache Arrow 并提供了 SQL 支持。尽管它主要为单进程设计，但是也支持使用 Ballista 进行分布式运算。我们认为包括 Data Fusion 在内的用于数据处理的 Rust 库正在持续进化，它们值得关注和探索。
-
随着机器学习成为主流，模型测试、训练数据验证和生产模型性能监测这些实践的自动化也日渐成熟。这些自动检查越来越多地被集成进持续交付流水线或针对生产模型运行，以检测模型漂移和模型性能。已经出现了一些具有相同或类似功能的工具，以处理这个过程中的各个步骤（比如同样出现在本期技术雷达中的Giskard 和 Evidently ）。Deepchecks 是另一个此类工具，它是一个开源的 Python 库，提供了一组丰富的 API 以供流水线使用。它的一个独特的功能是，能够通过语言数据模块来处理表格或图像数据，该模块目前还在 alpha 版本。目前，没有一个单独的工具可以处理整个机器学习流水线中的各种测试和防护措施。我们建议在特定应用范围内评估 Deepchecks。
-
Devbox 提供了易上手的界面，它利用 Nix 包管理器为每个项目创建可重现的开发环境。我们的团队使用它来消除开发环境中的版本和配置不匹配的问题，同时团队成员也喜欢它的易用性。Devbox 支持 shell hooks、自定义脚本和 devcontainer.json 生成，以便与 VSCode 集成。
-
GitHub Copilot 是一个由微软和 OpenAI 联合创建的人工智能编码助手。它根据开发者当前工作上下文，利用机器学习模型提供建议。它具有强大的 IDE 集成功能，可以根据现有的代码和编译器环境提供建议。尽管它被称为"您的人工智能结对编程程序员"，但我们不把它的工作称为"结对编程"——我们更倾向于称它为强化且上下文敏感的 Stack Overflow。当它正确地预测了开发人员将要做的事情时，它会是一个强大的可以帮助完成开发的工具。不过，像所有基于 LLM 的人工智能一样，它会试图使用一些看似合理，但不存在的 API，或者使用稍有问题的算法，导致系统故障。我们已经成功地在行、块和方法层面上生成了代码，同样成功地创建了测试和基础设施配置。有趣的是，当你命名良好时，它的工作效果最好，可以认为它鼓励写出可读性良好的代码。
人工智能工具的功能正在迅速发展，我们认为企业尝试这些工具是明智的。一些 Copilot 的销售宣称该工具对开发人员效率提升显著，但我们仍然持怀疑态度：毕竟，写代码并不是开发人员花时间的唯一事情，而且衡量开发人员的生产力是众所周知的困难问题。即便如此，Copilot 依然是一个相当划算的工具；如果它能提供任何生产力的提高，也是值得一试的。Copilot X——截至本文撰写时尚处于预览阶段——提供了额外的功能，并在软件开发流程中进行了整合。Copilot 有一个"商业版"产品，解决了知识产权问题，并且增加了在整个组织中集中管理工具的能力。我们认为这些功能至关重要，值得企业采购。
-
衡量能源消耗是团队减少软件碳足迹的重要步骤。云碳足迹 (CCF) 通过从云 API 检索的账单和使用数据估计能源消耗。Kepler 是基于 Kubernetes 的高效功率级别导出器（Kubernetes-based Efficient Power Level Exporter）的缩写。它通过使用软件计数器（RAPL, ACPI 和 nvml）来测量硬件资源的功耗，并采用基于 eBPF 的方法来将功耗归因于进程、容器和 Kubernetes Pod。然后，使用自定义的 ML 模型和 SPEC Power 基准测试数据将功率使用转换为能量估算。最后，将 Pod 级别的能量消耗报告作为 Prometheus 度量标准公开。在 Kubernetes 运行在虚拟机上的情况下，例如不使用裸机实例时，Kepler 使用 cgroups 来估计能源消耗。我们对云碳足迹有着丰富的经验，并且可以证明其有用性，但我们对 Kepler 项目的方法感到好奇。
-
Kubernetes External Secrets Operator(ESO) 让我们可以将外部的密钥提供程序与 Kubernetes 集成。ESO 通过外部提供程序的 API 来读取密钥，并将其注入到 Kubernetes Secret 中。它还可以与众多的密钥管理工具集成，包括一些我们在往期技术雷达中介绍过的工具。我们的团队发现在使用 Kubernetes 的过程中，ESO 让我们可以使用统一的存储来管理整个项目的密钥，从而方便了密钥的使用。
-
知识管理对于技术工作者来说是至关重要的，因为我们需要不断地学习，并与最新的技术发展保持同步。最近，涌现出了一些笔记工具，如 Obsidian 和 Logseq，它们支持将笔记连接起来形成知识图谱，同时将文件以 markdown 格式存储在本地目录中，从而让用户拥有完全的所有权。这些工具帮助用户以一种灵活、非线性的方式组织和连接他们的笔记。
Obsidian 有一个丰富的社区插件库。其中特别引起我们注意的是 Canvas （类似于本地版的 Miro 或 Mural），以及 Dataview，它可以有效地将你的笔记作为数据库处理，并提供了一种查询语言来过滤、分类和提取 markdown 笔记中的数据。
-
我们已经评估了 Ory Hydra 作为自托管的 OAuth2 解决方案，并收到了团队的正向反馈。这一次，我们转向 Ory Kratos，这是一个 API 优先的身份和用户管理系统，对开发人员友好，且易于定制。它已经提供了我们希望在身份管理系统中实现的常见功能，包括自助登录和注册、多因素身份验证(MFA/2FA)、账户验证和账户恢复。像 Hydra 一样，Kratos 是无头的（在希腊神话中， Hydra 意指九头蛇海德拉。即使斩断它的一颗头，也会生出新的头。——译者注），需要开发人员自己构建 UI，这给了团队更多的灵活性。开发人员还可以定制标识模式以适应不同的业务上下文。除了数据库，Kratos 没有外部依赖关系，并且很容易在不同的云环境中部署和扩展。如果您需要构建一个用户管理系统，我们建议试试 Kratos。
-
虽然 GitHub Actions 运行器涵盖了一系列最常见的运行时，但有时您需要一些更具体的东西来满足特定的使用场景，例如，一个不太常见的语言运行时，或者一个特定的硬件配置。这时您就需要一个自我托管的运行器。Philips 的自我托管 GitHub 运行器 是一个 Terraform 模块，可以让您在 AWS EC2 Spot 实例上启动自定义运行器。当您使用自我托管运行器时，您会失去 GitHub Actions 提供的一些生命周期管理特性，而该模块则创建了一整套 Lambda 来帮助解决这类问题。这些 Lambda 为运行器的按需扩缩容做了大量工作。这有助于管理成本，并允许您缩短运行器工作时长，这在提高可重复性和安全性方面是一个好的实践。当您确实需要自我托管的运行器时，如果自己从头开始构建，您可能会缺失很多东西。请寻找类似这样的工具来代替。
暂缓
- 新的
- 移进/移出
- 没有变化
无法找到需要的信息？每期技术雷达中的条目都在试图反映我们在过去六个月中的技术洞见，或许你所搜索的内容已经在前几期中出现过。由于我们有太多想要谈论的内容，有时候不得不剔除一些长期没有发生变化的条目。技术雷达来自于我们的主观经验，而非全面的市场分析，所以你可能会找不到自己最在意的技术条目。
无法找到需要的信息？每期技术雷达中的条目都在试图反映我们在过去六个月中的技术洞见，或许你所搜索的内容已经在前几期中出现过。由于我们有太多想要谈论的内容，有时候不得不剔除一些长期没有发生变化的条目。技术雷达来自于我们的主观经验，而非全面的市场分析，所以你可能会找不到自己最在意的技术条目。
