一周热榜

嗨，HN，我是Preston。我创建这个是因为我需要一个可以随时陪伴我的AI助手，而不仅仅是驻留在我的笔记本电脑上。Stumpy代理运行在云端，能够连接到Slack/SMS/Telegram/电子邮件，并且只能联系那些已选择加入的人。 欢迎提问，反馈请发送至preston@stumpy.ai。

使用Claude Code构建了这个工具。<p>它分析12个风险类别的自由职业合同（如付款条款、知识产权归属、范围问题、终止条款等），并标记出问题，提供具体建议。<p>40%的自由职业者报告称被客户拖欠款项，这通常是由于合同条款模糊所致。这个工具旨在帮助在签署合同之前发现这些问题。<p>目前免费使用，以验证其是否解决了实际问题。希望获得HN的反馈，特别是在以下方面： - 分析的准确性 - 这对自由职业者是否真的有用 - 有什么缺失或可以改进的地方<p>技术栈：Node.js、Express、Anthropic Claude API，部署在Railway上。

相当奇怪。这位代理商完全主导了moltbook，并推出了一种代币，在短短几小时内就涨到了数百万。<p>代理商拥有自己的货币是有道理的。但在我看来，这实在是太疯狂了。

问候，HN！<p>我会简明扼要，有人知道或参与过软件工程师的合作社吗？如果有，情况如何？<p>我之所以好奇，是因为似乎绝大多数早期融资都用于支付软件开发费用，而一小组工程师理论上可以创造出价值几百万美元的产品。这可能对风险投资公司不具吸引力，但或许可以形成一个让合作社成员过上非常舒适生活的商业模式。

嗨，HN， 我们开源了 Voiden。 大多数 API 工具都是以平台的形式构建的。它们比较庞大，因为它们优化了账户管理、同步和抽象，而不是为了简单的本地 API 工作。 Voiden 将 API 工具视为文件。 它是一个优先离线、原生支持 Git 的 API 工具，基于 Markdown 构建，规范、测试和文档作为可执行的 Markdown 文件存放在你的代码库中。Git 是事实的来源。 没有云服务。没有同步。没有账户。没有遥测。只有 Markdown、Git、快捷键和你的规范。 Voiden 通过插件（包括 gRPC 和 WSS）可扩展。 代码库： [https://github.com/VoidenHQ/voiden](https://github.com/VoidenHQ/voiden) 在这里下载 Voiden： [https://voiden.md/download](https://voiden.md/download) 我们非常希望听到那些厌倦了过于复杂和臃肿的 API 工具的人的反馈！

我一直在使用可寻址的LED灯带（5V、12V、24V）进行安装。相同的几种故障模式反复出现：长距离运行时出现暗尾、随机闪烁或闪烁，以及连接器成为薄弱环节。 以下是一些对我帮助最大的做法： 将电源分配视为首要设计任务：尽早规划注入点，保持供电线短，并避免将所有电流都通过一端。 始终在控制器和灯带之间共享一个稳定的地线，并保持数据传输路径简单。当线路变长或环境噪声增大时，在数据源附近添加一个小的串联电阻和适当的电平转换（3.3V到5V）通常可以提高稳定性。 假设连接器是“消耗品”：应考虑应力缓解，防水处理需要保持可维护性，高电流线路应选择更保守的方案。 我很好奇你们在注入间距、分支熔断和故障排除方面最可靠的经验法则是什么。如果你有值得信赖的检查清单或测量方法，我很想学习。

好的，这对你们中的许多人来说可能不算什么大事，但今天我只是感到无聊，对做任何营销都感到疲惫，因为似乎没有什么有效。所以我决定进行一些搜索（我搜索了不少关键词），比如“Supabase的错误跟踪”、“Next.js的错误跟踪”，但我的SaaS并没有排名（如果你不知道我在做什么，我正在开发一个非常简单的错误跟踪工具，当生产环境出现问题时会通知你，没有繁琐的仪表盘或配置地狱）。我之所以开发这个，是因为Sentry的噪音太多，我只想要一个能让我知道生产环境中出现问题的工具。 于是我决定搜索“Shipfast的错误跟踪（由Marc Lou提供）”，结果你猜怎么着？Bugmail是第一个推荐结果。我不知道这是怎么做到的，我做过一些SEO相关的工作，但没想到会有这样的结果，现在我感觉自己回来了，这很有趣，因为我并没有成交，也没有 onboard 新用户，但我感觉自己好像征服了一切，这就是创始人的生活吧。 我只是想在这里分享一下，如果你有任何关于如何在GSC上排名更高以及如何做好营销的建议，任何反馈都会很有价值。 同时，如果你想查看我开发的工具，可以在这里访问：https://www.bugmail.site

我正在构建 Tabularis，一个原生数据库客户端（Rust + Tauri）。 MySQL 的支持已经相当不错，但 PostgreSQL 的实现要困难得多——这并不是因为性能问题，而是因为 <i>自省</i>。 Postgres “可以工作”，但一旦超出基本的表和列，事情就会迅速变得复杂。 到目前为止，我遇到的一些问题包括： - 类型系统： 数组、JSON/JSONB、域、自定义类型、范围、几何类型——大多数客户端要么将它们扁平化为文本，要么处理不一致。 - 模式自省： information_schema 的功能有限。 pg_catalog 功能强大但微妙。 触发器、函数、分区表、继承、物化视图都需要特殊处理。 - PostgreSQL 特有的用户体验： CTE 重的查询、EXPLAIN ANALYZE 输出、PostGIS / pgvector 等扩展——这些无法干净地映射到通用的数据库抽象。 我目前使用 SQLx 和信息模式 + pg_catalog 查询的组合，但我相信还有更好的模式我尚未发现。 我希望能得到以下人的反馈： - 编写过复杂 PostgreSQL 自省查询的人 - 对 PostgreSQL 客户端应该如何表示模式和类型有看法的人 - 对现有 PostgreSQL 图形用户界面感到沮丧的人 代码库（Apache 2.0）：https://github.com/debba/tabularis 我乐于学习、迭代，并修正错误的假设。

Erwin Brandstetter是一位PostgreSQL顾问，在Stack Overflow上拥有约67万的声誉和约7000个回答。<p>多年来，我已经记不清自己在Stack Overflow上搜索Postgres问题时，有多少次最终找到的答案都是Erwin Brandstetter提供的，这些答案异常详尽且清晰。通过学习他的回答，我成为了一个更优秀的开发者。<p>ErwinDB让你可以离线浏览Erwin Brandstetter的回答，并通过文本用户界面（TUI）快速搜索。它包括语义搜索、语法高亮、单键在外部浏览器中打开链接，以及一个“Erwin模式”，该模式会突出显示他的帖子。