返回首页
最新
我正在寻找结果为 -0.0 的边界情况。根据我的了解，在求和中得到 -0.0 的唯一方法是：
```
(-0.0) + (-0.0)
```
有没有人知道在 IEEE 754 中还有其他情况？
附加问题：在减法中会发生什么？我只知道：
```
(-0.0) - (+0.0)
```
还有其他情况吗？
我创建 Focuser 是因为我在应该工作的时候总是无休止地刷屏。
**它的功能**
你可以选择任何一个浪费时间的网站。
下次访问时，Focuser 会问：“你真的需要这个网站吗？”
如果你点击“是”，你必须：
1⃣ 写下你需要它的理由
2⃣ 精确选择你需要访问的时间
这个 20 秒的阻力基于肖恩·艾克的习惯形成研究。
**它的不同之处**
完全在客户端运行——没有分析，没有外部调用。
已经使用 Manifest V3（为 2025 年 6 月 Chrome 停用做好了未来准备）。
支持离线使用。
设置存储在 localStorage 中。
**提问**
20 秒的规则感觉太长还是太短？
有没有让你担心的权限边缘案例？
有没有想要移植到 Firefox 的想法？
在这里试用（免费）： [https://focuser.app](https://focuser.app)
我在线上，乐意回答任何问题。感谢你的阅读！
嗨，HN！<p>我创建了 NaturalCron，因为我厌倦了编写和调试像这样的 CRON 语法：<p><i>/5 </i> * * 5<p>现在你可以在 .NET 中写出更易读的内容：<p>var expression = new NaturalCronExpression("每周五每 5 分钟一次");<p>或者使用流式构建器以获得强类型和 IDE 支持：<p>var expression = NaturalCronExpressionBuilder
.Every().Minutes(5)
.On(DayOfWeek.Friday)
.Build();<p>非常适合：
- 在 .NET 应用程序中基于代码的调度
- 从配置文件或数据库覆盖调度
- 在用户界面中显示易读的规则<p>NuGet: <a href="https://www.nuget.org/packages/NaturalCron" rel="nofollow">https://www.nuget.org/packages/NaturalCron</a>
GitHub: <a href="https://github.com/hugoj0s3/NaturalCron">https://github.com/hugoj0s3/NaturalCron</a><p>欢迎你对语法、构建器设计以及你希望看到的功能提供反馈！
当我创建我的最后一个初创公司时，我通过 AI 工具目录、新闻文章、Reddit、自然搜索、电子邮件等渠道获得了流量。但我始终无法确定哪些来源实际上推动了付费用户的转化，或者这些用户在生命周期价值（LTV）、流失率等方面的价值有多大。这就像一个黑匣子。
因此，我开发了一款轻量级工具，帮助 SaaS 创始人将流量来源（通过 UTM/自定义推荐参数）与 Stripe 收入连接起来。这使得创始人能够回答以下问题：
- “哪些流量来源带来了收入？我应该在哪些方面加大投入？”
- “我最有价值/最没有价值的用户来自哪里？”
这个工具为创始人提供了他们所需的信号，以理解哪些营销努力实际上有效。我希望保持设置简单，专为没有时间或资源进行复杂数据堆栈的独立创始人和小团队设计。它包括：
- 在您的网站上添加一个 JS 代码片段，以捕获 UTM/推荐数据
- 连接您的 Stripe 账户
- 当收入事件发生时，该工具将 Stripe 客户电子邮件与归因数据进行匹配
您将获得一个仪表板，显示流量来源以及收入、LTV、流失率和每周洞察，例如：
- 特定渠道的流失率激增
- 驱动超额收入的新流量来源
在构建这个工具的过程中，我遇到了一些挑战：
1. 范围蔓延 — 有太多的分析和洞察用例。将其简化到一个仍能提供价值的最小版本非常困难。我希望获得关于如何从这里演变仪表板和洞察的反馈，但制定一个可交付的 MVP 并保持其价值对我来说是一个真正的挑战。
2. 冷启动问题 — 产品的价值在于归因，但归因数据在嵌入 JS 代码片段后需要时间来积累。作为一名产品驱动增长（PLG）的支持者，我无法承受较长的价值实现时间，因此我还构建了一套最小的 Stripe 收入指标和洞察，这些在 Stripe 的默认仪表板中不可用。这使得用户在连接 Stripe 后立即获得价值。
我正在寻找希望更清晰了解哪些营销渠道值得投入的 SaaS 创始人。如果您希望在我开发这个工具时成为早期设计合作伙伴，请注册，我会直接联系您： [https://www.getboone.com/?utm_source=hackernews&utm_medium=show_hn&utm_campaign=launch](https://www.getboone.com/?utm_source=hackernews&utm_medium=show_hn&utm_campaign=launch)
昨天关于在线技术社区中民主的讨论真是精彩绝伦。这个社区所展现的深刻见解总是让我感到惊讶。
特别感谢Paul Houle提供的理论框架，将哈贝马斯的协商过程与现代电子通讯联系起来。你提到的早期采用者的质量与可扩展性之间的紧张关系，正是我们正在努力解决的问题。
感谢orionblastar倡导亚伦·斯沃茨关于真正自由的信息和透明治理的愿景。你提醒我们“适度妥协了真正民主和言论自由的理想”，这句话深深触动了我。
感谢ethan_smith引入Discourse的信任等级作为一个实际例子，以及对社区流失问题的关键见解的构思，感谢zeroCalories分享Discord民主实验失败的案例。
每一条评论都影响了我们对这些挑战的思考。共识很明确：开发者渴望更好的社区治理，但问题复杂且真实。
感谢你们证明了真正的知识讨论在互联网仍然存在。这就是HN之所以特别的原因。