一周热榜

我对 Go 验证器中的运行时反射感到沮丧，因此我采用了代码生成的方法。 govalid 读取结构体标记并生成普通的 Go 验证代码。没有反射，运行时没有内存分配，速度比 go-playground/validator 快 5-44 倍。还支持 CEL 以处理复杂规则。 欢迎反馈 :)

核心理念是最小任务模型 + 可编程行为——一个小型核心可以支持无限的功能，因为每个任务都可以携带可执行脚本。 最近的更新： - 虚拟机现在使用NaN-boxing技术。 - 所有栈值为64位（u64），但编码了5种不同类型： 布尔值、字符串、调用数据、U32和内存切片（25位偏移量 + 25位大小）。 - 添加了InlineVec——一种类似向量的结构，基于固定大小的数组。虚拟机栈、控制栈、调用栈和跳转栈现在都使用它，并设定了明确的限制。 - 虚拟机现在有内存（堆）。内存是简单的Vec<u64>，动态增长，但从技术上讲，长度受mem_slice_val格式的限制：偏移量和大小各占25位有效载荷。 该项目仍处于非常早期的阶段。 代码库在这里：https://github.com/tracyspacy/spacydo

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

嘿，HN，我们刚刚发布了 Hebo Gateway 的 v0.1 版本。 市面上已经有很多网关，但我们不断遇到同样的问题：一旦需要真正的定制（如身份验证、路由、速率限制、可观察性、请求/响应转换），大多数“现成”的网关就变得难以扩展。 Hebo Gateway 适用于希望将网关作为应用程序一部分的场景。您可以独立运行它，或将其嵌入到现有的后端中。它暴露了与 OpenAI 兼容的端点（/chat/completions、/embeddings、/models），可以与任何 Vercel AI SDK 提供者配合使用，并添加了一个钩子系统，您可以在不修改核心代码的情况下将逻辑插入请求生命周期中。 快速入门、示例和“接下来是什么”都在这篇文章中： <a href="https://hebo.ai/blog/260127-hebo-gateway" rel="nofollow">https://hebo.ai/blog/260127-hebo-gateway</a> 我非常希望能收到您在 OpenAI 兼容边缘案例中遇到的问题反馈（特别是与流媒体和推理相关的内容），以及您希望网关默认提供的钩子功能。

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

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

嗨，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 工具的人的反馈！

我正在构建 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 我乐于学习、迭代，并修正错误的假设。