我对 Go 验证器中的运行时反射感到沮丧，因此我采用了代码生成的方法。
govalid 读取结构体标记并生成普通的 Go 验证代码。没有反射，运行时没有内存分配，速度比 go-playground/validator 快 5-44 倍。还支持 CEL 以处理复杂规则。
欢迎反馈 :)
返回首页
一周热榜
大家好，
我构建了一个运行时环境，用于通过 WebAssembly 沙箱隔离不可信代码。基本上，它保护您的主机系统免受不可信代码可能引发的问题。最近我们对 Python 中的沙箱化进行了深入讨论，更详细地阐述了这个问题[1]。在 TypeScript 中，由于两个生态系统之间的紧密联系，WebAssembly 的集成显得更加自然。
核心部分是用 Rust 编写的。在此基础上，我通过 wasmtime 和组件模型使用了 WASI 0.2，并结合自定义 SDK，使其尽可能符合语言习惯。
例如，在 Python 中，我们有一个简单的装饰器：
```python
from capsule import task
@task(
name="analyze_data",
compute="MEDIUM",
ram="512mb",
allowed_files=["./authorized-folder/"],
timeout="30s",
max_retries=1
)
def analyze_data(dataset: list) -> dict:
"""在一个隔离的、资源受控的环境中处理数据。"""
# 您的代码在 Wasm 沙箱中安全运行
return {"processed": len(dataset), "status": "complete"}
```
在 TypeScript 中，我们有一个包装器：
```typescript
import { task } from "@capsule-run/sdk"
export const analyze = task({
name: "analyzeData",
compute: "MEDIUM",
ram: "512mb",
allowedFiles: ["./authorized-folder/"],
timeout: 30000,
maxRetries: 1
}, (dataset: number[]) => {
return {processed: dataset.length, status: "complete"}
});
```
您可以设置 CPU（通过 compute）、内存、文件系统访问权限和重试次数，以精确控制您的任务。
虽然现在还处于早期阶段，但我非常希望能听到反馈。我会在这里回答问题。
GitHub: [https://github.com/mavdol/capsule](https://github.com/mavdol/capsule)
[1] [https://news.ycombinator.com/item?id=46500510](https://news.ycombinator.com/item?id=46500510)
嘿，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
我正在构建 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
我乐于学习、迭代，并修正错误的假设。