最新

嘿，HN社区， 我是一名来自尼日利亚的独立开发者。我开发了Quran Unlock——一款在你完成每日阅读《古兰经》之前，阻止你使用干扰性应用（如TikTok、Instagram等）的应用。 这个想法源于我自己对手机成瘾的挣扎。我想每天阅读《古兰经》，但总是被各种干扰分心。因此，我为自己开发了这个应用，然后决定分享给大家。 经过两个月的一些统计数据： - 超过123,000名用户 - 64.9%的回访用户率 - 31百万个事件被追踪 技术栈： - React Native - Firebase（身份验证、Firestore、分析、云消息） - RevenueCat用于订阅 - iOS屏幕时间API + Android使用统计 应用商店链接： [App Store](https://apps.apple.com/app/quran-unlock/id6754449406) 谷歌商店链接： [Play Store](https://play.google.com/store/apps/details?id=com.app.quranu) 期待HN社区的反馈！

我对当前的档案格式感到失望，要么它们过于复杂，要么是杂七杂八的，要么不支持随机访问（如磁带格式），或者有奇怪的限制（如ar档案）。因此，我自己设计了一个简单的随机访问档案格式。

我一直认为，DDD在当时是一个令人惊讶的优秀调试工具。它让程序执行变得可视化：堆栈、数据和控制流都能同时呈现。你可以真正“看到”程序在做什么。 与此同时，它显然是一个不同年代的产物： - 单进程 - 主要是同步代码 - 没有真正的并发或异步概念 - 过时的用户界面和交互模型 今天我们调试的系统截然不同：多线程代码、异步运行时、长时间运行的服务、分布式组件。然而，大多数调试器在概念上仍然与GDB + 单步调试相似，只是包装在一个更美观的用户界面中。 我很好奇其他人对此的看法： - DDD（或类似旧工具）中有哪些理念仍然有价值？ - “现代DDD”需要如何处理今天的软件？ - 你认为交互式调试仍然是正确的抽象方式吗？ 我主要是从设计的角度提问——我自己也在尝试一些调试器的想法，但我更感兴趣的是听听经验丰富的工程师们今天如何看待这个问题。

随着代理的使用，我发现自己越来越多地使用工作树。最初是手动操作，然后是使用 conductor.build，接着是 worktrunk.dev。<p>我更喜欢使用命令行界面（CLI）进行编码，而不是图形用户界面（UI）封装，因为终端通常更高效（这取决于你选择的代理），并且可以立即访问新功能。<p>目前，Ghostty 的自动化有些挑战——我最初考虑过为 Ghostty 构建一个补充应用。但由于最近我一直在开发本地 mac 应用（以及为代理构建工具，处理它们的日志等），我决定直接修改 Ghostty，以实现本地工作树管理。<p>你可以通过 Homebrew 下载：brew install sidequery/tap/ghostree