返回首页
一周热榜
我对 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
我乐于学习、迭代,并修正错误的假设。