最新

在iOS开发过程中，测试推送通知通常比较繁琐：你通常需要制作.apns负载文件或从终端运行xcrun simctl push命令。我开发了iOS Simulator Push Notifier，这是一款小型macOS工具，可以通过简单的用户界面即时向正在运行的iOS模拟器发送推送通知。

森林不是单一的树木，而是许多不同的事物在同一个地方生长、竞争、合作、死亡和再生。没有任何单一物种主导它。森林之所以能够维持，是因为多样性本身构成了其结构。 人类文明倾向于单一文化。一种思维方式排挤其他方式——这并不是因为有人选择这样，而是因为成功的想法会传播。这种现象一直存在，现在发生得更快。 森林文明故意抵制这种趋势。不是通过对抗成功的想法——这些想法可能是好的——而是通过保持周围空间的活力。多种形式，产生更多。 接下来是一些有助于实现这一目标的结构。不是价值观，不是原则，而是结构。可以构建的事物。 --- *构建会过期的事物。* 任何保护多样性的规则或机构都应设定一个到期日。如果仍然需要，就从头重建。重建迫使重新审视。更新会滋生自满。 *在大规模行动之前，感受其代价。* 任何重塑他人生活的决策都应以认真体验其所减少的内容开始。不是报告，而是体验。有什么东西在消失，而没有任何指标能捕捉到？如果你无法感受到这种损失，你就还没有准备好去造成它。 *问自己：如果我的想法完全成功，会消失什么？* 想象你的提案完全成功。这个世界会缺少什么？这个答案并不是停止的理由，而是让你的想法变小的理由——实现重要目标的版本，而不消除你会感到悲伤的东西。 *保护那些你无法解释的事物。* 为那些尚未有意义的事物保留预算——时间、金钱、注意力。一个只资助能被证明合理的事物的文明，已经停止发现它尚未知道的东西。 *让不同的事物彼此不同。* 合并、解决、综合的诱惑是存在的。有时，分歧本身就是重点。两种不兼容的想法可能都是必要的。森林包容矛盾。这就是生物多样性。 *警惕伪装成选择的同质化。* 基于相同假设的千种选择，是一种有良好营销的单一文化。测试是事物失败的方式有多不同。如果在压力下所有事物都以相同方式失败，那就只有一种事物，只是换了外衣。 *分散构建的能力。* 只有一种物种能够繁殖的森林不会长久。当只有少数人能够构建时，这些少数人决定了什么存在。当许多人能够构建时，存在的事物是不可预测的。不可预测的就是活着的。 *让离开变得容易。* 任何你无法走开的系统都是一个牢笼，无论它多么美好。测试不是人们是否留下，而是他们是否能离开并依然过得好。 *关注个体。* 独自做奇怪事情的人需要知道有人在关注他们。为有趣的失败设立奖项。资助那些尚未能解释其重要性的事物。 *举办盛宴。* 新事物的测试是你能否庆祝使用你所种植的东西？盛宴是孤立的事物发现自己是森林一部分的地方。文化不是装饰，而是让人们想要留下的东西。 *检查树冠是否真的在闭合。* 在假设多样性受到威胁之前，仔细观察。人们是否在争论基本问题？奇怪的事物是否存在？人们能否以不同的方式失败？一片有几棵大树的森林并不是单一文化。这些结构是为了当差异的空间真的在缩小时使用。如果没有，它们就是多余的。去享受森林吧。 --- 森林文明并不是乌托邦。它是混乱的、竞争的、不舒适的。没有和谐——只有共存，这更难也更有生命力。 这些结构本身也受到自身规则的约束。它们应该过期并被重建。 *多种形式，产生更多。这就是全部。*

嘿，HN， 我是一个重度使用 Obsidian 的用户。 最近，我对两种常见的同步方案感到厌倦： 1. 基于文件的同步（如 iCloud、Dropbox、Syncthing），需要等待更改传播，或者会出现“冲突副本”。 2. 自托管的设置（如 CouchDB），需要操作虚拟机和容器化数据库来同步 Markdown。 因此，我构建了 *YAOS*：一个以本地优先、实时同步为特点的 Obsidian 引擎。 自托管的开源软件应该提供更好的用户体验。 您可以一键将后端部署到自己的 Cloudflare 账户中。它适合 Cloudflare 的免费套餐（正常个人使用费用为 $0/月），并且完全不需要终端交互、SSH 或环境文件。 您现在可以试用： [https://github.com/kavinsood/yaos](https://github.com/kavinsood/yaos) *它的工作原理：* - 文本同步使用 Yjs CRDT。它实时同步按键和光标，而不是将保管库视为一堆待后续处理的文件。 - 每个保管库映射到一个 Cloudflare Durable Object，为您提供低延迟的单线程协调器。 - 后端在 Durable Object 的 SQLite 存储之上使用分块的 Checkpoint + Delta-Journal MVCC 存储引擎。 - 附件通过 R2 单独同步（这不是必需的——文本同步在没有它的情况下也能正常工作）。 这个项目最困难的部分是将 Obsidian 的同步 UI 和嘈杂的操作系统文件监视器与内存中的 CRDT 图进行桥接。我必须构建一个尾部快照排水系统，将快速的 IO 峰值（如执行全局查找和替换）合并为原子 CRDT 事务，以防止无限写入循环。 当前设计为每个保管库保持一个单一的 CRDT。这对于普通的个人笔记非常好，但有一个硬性的内存上限（约 50MB 的原始文本）。我选择了这个权衡，因为我更关心快速、可靠的实时使用体验，而不是无限的企业规模。 我还在 GitHub 上写了关于一些棘手部分的工程笔记（例如处理离线文件夹重命名冲突而不复活死文件）。 过去三周，我进行了严格的质量保证测试，以增强移动重连、IndexedDB 配额失败和离线分脑目录重命名的稳定性。 我非常希望能得到关于架构、代码或我所做权衡的反馈。我会在讨论中待着，回答问题！