开发工具

107 个提交。从第一天开始就是完美的约定式提交。Feat、fix、refactor、chore — 所有内容都完美标记。那么 CHANGELOG 呢？空的。不存在。一个"明天再写"的文件，已经拖了两个月。 如果这听起来很熟悉，你不是一个人。手动编写变更日志是奥林匹克级别的苦差事。不是说它难 — 而是它乏味、重复，总有更紧急的事情要做。这就是为什么 git-cliff 存在的原因。 什么是 git-cliff（30 秒版本） 这是一个用 Rust 编写的变更日志生成器，它读取你的 git 提交，根据约定式提交解析它们，然后输出按版本和类型分组的 CHANGELOG.md。没有奇怪的依赖，没有插件，没有黑魔法。一个二进制文件，一个配置文件，就完了。 简单来说：你给它你的提交，它返回你拖延了几个月的文件。 1 2 brew install git-cliff git cliff --output CHANGELOG.md 这两行字面上就是开始所需的全部。如果你的提交遵循 类型: 描述 约定，git-cliff 无需额外配置就能理解它们。 真实案例：8 个版本的回溯性变更日志 在 Tokamak（我的监控 Claude 配额的菜单栏应用）中，我正好遇到了这个问题：107 个完美提交和一个空白的 CHANGELOG。应用已经是 v1.3.0 版本，但只有一个开始时的 v0.1 标签。 计划很简单： 步骤 1：在每个版本的提交上创建回溯性标签。 1 2 3 4 5 git tag v0.2.0 32950f4 # Dashboard, biblioteca, achievements v1 git tag v0.3.0 9c56985 # Rename a Tokamak, 6 idiomas git tag v1.0.0 a283490 # App Store: sandbox, privacy manifest git tag v1.3.0 6248bac # HEAD: multi-provider, fetch pipeline # ... 以此类推 步骤 2：运行 git-cliff。 ...

凌晨两点。你的应用编译通过。签名完成。打包成DMG。执行notarytool submit。苹果说"In Progress"。你等了5分钟。10分钟。20分钟。一个小时。两个小时。提交仍然是"In Progress"。你睡觉去了。第二天早上：Invalid。 除了"The signature of the binary is invalid"之外没有更多解释。对两种架构都是如此。谢谢苹果。非常有用。 公证是那种完美运行的流程…直到它不工作为止。当它失败时，会给你留下一个Gatekeeper不会打开的.dmg文件和一个什么都不告诉你的错误。在为Tokamak（我的用于监控Claude配额的菜单栏应用）与此斗争几天后，我决定记录所学到的一切并编写一个检查器以避免再次经历这种痛苦。 什么是公证（简单来说） 想象Mac App Store是一个有保安的购物中心。但你不想在购物中心销售——你想直接分发你的应用，用你自己的DMG。就像街边摊位。 苹果说：“好的，你可以。但首先要通过门卫。” 那个门卫就是公证。这是苹果的一个自动化服务，扫描你的已签名应用，验证它不包含已知的恶意软件，如果一切正常，就给你一个票据。你把这个票据钉在你的DMG上（stapler staple），从那时起，当用户下载并尝试打开它时，Gatekeeper看到票据就说"请进"。 没有那个票据，用户会看到这个： “Tokamak.app"无法打开，因为苹果无法检查它是否不含恶意软件。 你的应用就被丢在路边了。 苹果为什么这样做 有两个原因。一个是合理的。另一个…嗯。 合理的原因：保护用户。在公证之前（2019年在macOS 10.14.5中引入），任何人都可以用Developer ID分发已签名的.app，macOS会毫无怨言地打开它。代码签名验证开发者的身份，但不扫描内容。如果你的已签名应用包含键盘记录器，签名完整的情况下也会执行。 公证增加了一层：苹果在到达用户之前扫描二进制文件寻找已知的恶意软件和可疑行为。这不是像App Store那样的人工审查——这是一个自动化系统。但至少是个保障。 另一个原因：控制。苹果希望你通过App Store Connect处理所有事情。使用Developer ID的直接分发一直是二等公民。公证是在"你可以在App Store之外分发，但我们会让你感到不便"这条道路上的又一步。 话虽如此，从macOS 10.15开始，对于所有在App Store之外分发的应用，公证是强制性的。这不是可选的。你的应用要么经过公证，要么不会打开。没有商量余地。 会让你浪费数小时的7个错误 在收集了自己的错误和开发者论坛的错误后，这些是最痛苦的： 1. 缺少--timestamp 这是经典错误。你的codesign在本地完美工作，Gatekeeper不抱怨，但公证返回"The signature of the binary is invalid.” 1 2 3 4 5 # 错误 — 本地签名有效，苹果拒绝 codesign --force --options runtime --sign "Developer ID Application: ..." MiApp.app # 正确 — 使用苹果服务器的时间戳 codesign --force --options runtime --timestamp --sign "Developer ID Application: ..." MiApp.app 安全时间戳证明签名是在证书有效期内完成的。没有它，苹果不会信任。就像签署没有日期的合同——技术上有效，但没人会接受。 ...

我正在构建一个 macOS 的菜单栏应用程序。在我的 Mac 上运行完美。现在我需要知道它是否能在干净的 macOS 环境中正常工作：没有我的配置、没有我的权限、没有我的数据。一个全新安装的用户环境。 如何测试这种情况？你需要一个虚拟机。 “简单”，我想。“我安装了 UTM。打开向导，创建一个 macOS 虚拟机，然后运行。” 事情并没有那么简单。 UTM：漂亮但难以驯服 UTM 是一个很棒的应用程序。精心设计的界面，支持在 Apple Silicon 上运行 macOS 客户机，全屏显示，共享剪贴板。手动使用确实很棒。 当你试图自动化时问题就出现了。 UTM 有一个叫做 utmctl 的命令行界面。可以列出虚拟机、启动它们、停止它们、克隆它们。它不能做的是创建虚拟机。对于 macOS 客户机，甚至 UTM 的 AppleScript 也不允许创建它们——操作系统字段被硬编码为 Linux。 简单来说：如果你想在 UTM 中创建 macOS 虚拟机，你必须通过向导手动创建。每次都是。需要点击、下载 IPSW（Apple Silicon 的 macOS 安装映像——相当于传统的 ISO，但由 Apple 打包）、等待安装。 对于需要在质量保证流程中频繁创建和销毁虚拟机的开发者来说，这真是个麻烦事。 Tart：为开发者设计的 macOS 虚拟机 Tart 是当有人在设计虚拟化工具时考虑开发者而不是最终用户的结果。 它使用与 UTM 完全相同的 Apple Virtualization.framework。相同的技术，相同的功能，相同的原生速度。区别在于界面：Tart 是命令行优先的。 1 brew install cirruslabs/cli/tart 就这样。没有图形界面配置，没有向导。只是在你的 PATH 中的一个二进制文件。 一个命令统治一切 创建一个使用最新可用版本的 macOS 虚拟机： ...

敲敲敲。谁？Touch ID。又来了。 想象一下：你正在终端工作，用op read查询1Password的密钥。需要Linear的API密钥。Touch ID。OpenRouter的。Touch ID。Gitea的。Touch ID。 半小时内它要求我验证指纹十四次。 你知道当一个安全工具在三十分钟内打断你十四次会发生什么吗？第五次时你就不再看它在要求什么了。你下意识地放上手指。“是的，随便什么，让我工作吧。” 而这正是安全性完全崩溃的地方。 授权疲劳：没人愿意正视的问题 这在安全领域有个名词：授权疲劳。这不是什么新概念。这与MFA疲劳攻击使用的原理相同：用授权请求轰炸用户，直到他们纯粹因为疲惫而接受一个。 2022年，一个17岁的孩子正是这样进入Uber内部系统的。他反复向员工发送认证推送通知，深夜时分，直到那个人为了能睡觉而接受了一个。 显然，1Password要求Touch ID不是攻击。但心理效应是相同的：它训练你不假思索地批准。 这就像那些多年来出现在每个网站上的cookie横幅。一开始你会阅读它们。现在你不看就点击"全部接受"。恭喜：一个设计用来保护你隐私的机制教会了你更快地放弃你的隐私。 为什么1Password每次都要我的手指 我的设置：我使用op read从终端读取1Password的密钥。运行得很好。问题是我使用Claude Code（一个终端AI助手），它执行的每个命令都是一个新进程。 1Password的生物识别会话超时是10分钟不活动，并在每次使用时刷新。理论上，不应该这么频繁地要求手指。但Claude Code不重用进程：每次需要密钥时，它启动一个新的shell，1Password将其解释为新会话。 结果：每次Claude需要密钥时都要Touch ID。这是持续性的。 解决方案：40行缓存 想法很简单：一个包装器在PATH中排在op前面。当你执行op read时，它检查是否已经缓存了新鲜的结果。如果有，直接返回而不接触1Password。如果没有，调用真正的op，缓存结果，完成。 对于任何其他子命令（op signin、op item list等），直接传递给真正的op而不干预。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 #!/bin/bash # ~/.local/bin/op — 1Password CLI的缓存包装器 # 仅缓存'op read'。其他所有内容直接传递给真正的op。 # 可使用OP_CACHE_TTL配置缓存TTL（默认：3600s = 1h） REAL_OP="/opt/homebrew/bin/op" CACHE_DIR="${HOME}/.cache/op-cache" CACHE_TTL="${OP_CACHE_TTL:-3600}" # 仅缓存'op read' if [[ "$1" == "read" ]]; then mkdir -p "$CACHE_DIR" && chmod 700 "$CACHE_DIR" # 所有参数的哈希作为缓存键 CACHE_KEY=$(printf '%s\0' "$@" | shasum -a 256 | cut -d' ' -f1) CACHE_FILE="${CACHE_DIR}/${CACHE_KEY}" # 缓存命中：文件存在且未过期 if [[ -f "$CACHE_FILE" ]]; then FILE_AGE=$(( $(date +%s) - $(stat -c %Y "$CACHE_FILE") )) if [[ $FILE_AGE -lt $CACHE_TTL ]]; then cat "$CACHE_FILE" exit 0 fi fi # 缓存未命中或过期：调用真正的op RESULT=$("$REAL_OP" "$@") EXIT_CODE=$? # 仅在op成功时缓存 if [[ $EXIT_CODE -eq 0 ]]; then printf '%s' "$RESULT" > "$CACHE_FILE" chmod 600 "$CACHE_FILE" fi printf '%s' "$RESULT" exit $EXIT_CODE else # 任何其他子命令：直接传递 exec "$REAL_OP" "$@" fi 将它保存在~/.local/bin/op，给予执行权限，由于~/.local/bin在PATH中排在/opt/homebrew/bin之前，你的包装器会拦截调用。 ...