最新

我非常支持WebAssembly和.NET。当我发现.NET现在可以在浏览器中通过WASM运行，无论是否使用Blazor时，我觉得这可能会有一些潜力。由于Blazor对于TypeScript开发者来说往往是一个过于庞大的步骤，我认为最近新增的将.NET WASM应用作为库包含在JS包中的功能，可能是WASM在我们这个以JS为主的网页环境中获得一些发展机会的良好起点。 使用JSExport/JSImport互操作性相对繁琐，它仅支持静态方法，没有面向对象的概念（如类，仅有对象句柄），并且需要手动编写导出方法的TypeScript定义。因此，我决定尝试制作一些工具，以提高开发者的体验和可靠性。 于是，TypeShim应运而生：一个代码生成工具，旨在创建.NET WebAssembly与TypeScript之间无缝的编程体验。完整的类级别导出会被转换为C#代码生成，从而自动定义你的JSExports/JSImports，并使用一个包装这些方法的TypeScript类。这会创建看起来与C#类完全相同并且行为一致的代理，包括静态/成员、构造函数、属性、方法，甚至像引用相等这样的特性。TypeShim支持所有JSExport支持的类型，同时将你自己的类也包含在内，因此它提供了JSExport所提供功能的超集。 由于Roslyn代码生成不允许我生成JSExport代码生成可以消费的代码，我不得不制作自己的CLI代码生成工具（这非常有趣）。感谢Roslyn导出其API，使我能够运行自己的编译，然后用它来构建与标记为导出的类匹配的C#和TypeScript。 这也是一个进行性能优化工作的好借口（为什么不呢？！），NativeAOT特别适合这种短时间运行的工具，通过解决PerfView发现的一些瓶颈，我成功将代码生成时间降低到大约100毫秒，适用于需要代码生成的100多个类的项目。 这让我走上了一些我从未预料到的道路，比如在对解决方案进行端到端测试时发现了两个会导致.NET WASM运行时崩溃的bug，这让我深入到dotnet/runtime仓库进行修复。dotnet团队对此表示感谢，并非常欢迎我尝试在新的.NET11互操作实现中修复相同的问题，该实现运行在CoreCLR而不是mono上。这是一次很棒的经历，我会继续参与更多与TypeShim相关的挑战：向互操作库中添加更多类型。 总之，这就是我最近开源活动的一些激动人心的事情。如果你有时间看看TypeShim，甚至给个星星，我将非常感激。但最重要的是，我希望听到你的反馈！ 祝好， ArcadeMode

我建立了一个临时文件共享服务，支付通过HTTP 402状态码和Base/Arbitrum上的USDC进行。 这个想法是：HTTP 402（“需要支付”）自1997年以来就存在，但从未真正被使用。x402协议（[https://x402.org](https://x402.org)）终于为其提供了一个实际的实现——服务器以402响应并提出支付挑战，客户端签署无燃气费的USDC转账（EIP-3009），中介在链上结算，客户端再通过支付头重试。无需API密钥，无需OAuth，无需账户。 x402drop将其作为临时文件存储的支付层： - 连接钱包（SIWE），拖放文件（每个文件最大5 GB，每次上传最多10 GB） - 选择存储时长（1小时到90天），查看报价（$0.0003/MB/天，最低$0.01） - 签署一次USDC转账——无燃气费，中介支付燃气费 - 获取分享链接——接收者可以免费下载，无需钱包 - 文件将在到期后约15分钟内自动从R2删除，通过定时任务实现 还有一个代理API——AI代理和脚本可以使用相同的x402支付流程以编程方式创建上传。无需API密钥，402支付头即为认证。 技术栈：Next.js（应用路由器），SIWE + RainbowKit，Drizzle ORM + Neon Postgres，Cloudflare R2，@x402/next，Vercel。 定价是确定性的：每个文件的费用为max(fileSizeMB × durationDays × 0.0003, 0.01)。 已知限制： - 仅支持主网（尚无测试网模式） - 仅支持USDC（不支持ETH或其他代币） - 不提供到期警告的电子邮件通知 我认为从技术上讲，最有趣的部分是将HTTP 402作为一个真正的协议原语使用，而不是作为支付墙的花招。中介模型意味着付款方无需接触燃气费，整个流程仅为HTTP请求 → 402 → 签名头 → 200。 服务已上线，访问 [https://x402drop.com](https://x402drop.com)。文档在 [https://x402drop.com/docs](https://x402drop.com/docs)。 欢迎就x402协议的实现或架构提出问题。

我与大型语言模型（LLMs）的对话可以朝多个方向发展。我希望能够追踪这些分支，随时回到其他话题，并在任意点创建新的分支。因此，我构建了自己的解决方案。 这本质上是一个用于非线性思维的工具。我有很多想要添加的功能，在将其推向其他地方之前，我需要一些反馈。所以，我在倾听你们认为存在问题的地方。 基本功能包括： - 分支对话：可以随时从任何节点进行跟进，而不仅仅是最新的消息。 - 上下文继承：当你从一个节点分支时，AI会获得该分支的完整历史作为上下文，因此回答会考虑到导致该回答的整个对话路径。 - 文本转问题：在回答中突出显示任何文本，可以立即从中生成一个新问题。 - 多提供者AI：比较和调整来自OpenAI、Anthropic和Google Gemini的响应。 - 可视化图表：对话以React Flow图的形式呈现，具有自动布局，因此你可以一目了然地看到整个结构。 - 可分享链接：你的整个聊天记录被压缩并存储在URL中。所有内容都是本地的（除了API调用）。 - 分支压缩：长分支可以折叠成一个摘要节点，以保持图表的整洁。

我目前同时订阅了Claude和ChatGPT。一般来说，我更喜欢Claude，但由于我的工作中涉及大量数学内容，它在正确渲染LaTeX方面常常存在问题，因此我无法完全依赖它。<p>一个渲染失败的例子可以在这里找到[1]。如果我将所有工作都交给Claude，几乎每天都会遇到这样或更糟的问题。因此，我发现直接向ChatGPT提问数学问题更为简单，因为它似乎在输出LaTeX方面有更强大的系统。<p>不过，我希望能够合并我的订阅，所以我想问问是否有人有有效的系统提示，可以指导Claude生成有效的LaTeX。我自己尝试了一些提示，但很难找到它能够始终遵循的内容。<p>[1] https://imgur.com/yzlluOA

自托管是否值得与SaaS相比？你在自托管什么？你放弃了什么？

在使用不同工作树中的并行代理时，我发现我遇到了很多端口冲突，不断来回检查我的开发服务器运行在哪个递增端口，以及出现了 cookie 泄漏。<p>如果只是运行几个完整栈框架的服务器，比如 Next、Nuxt 或 Sveltekit，这并不是个大问题，但如果你在多个工作树中同时运行 Rust 后端和 Vite 前端，那就复杂得多，思维模型也开始崩溃。更不用说数据库或缓存了。<p>因此，我构建了 Roxy，这是一个单一的 Go 二进制文件，可以包装你的开发服务器（实际上也可以是任何进程），并根据分支名称和当前工作目录提供一个稳定的 .test 域名。<p>它运行一个代理和 DNS 服务器，处理所有的域名路由、TLS、端口映射和转发。<p>目前支持：<p>- 用于你的 web 应用和 API 的 HTTP - 大多数 TCP 连接，用于你的数据库、缓存和消息/队列层 - TLS 支持，以便你可以运行 HTTPS - 同时运行多个进程，每个进程都有一个独特的 URL，类似于 Docker Compose - Git 和工作树的感知 - 分离模式 - 零配置启动<p>我和我的同事们在我们的工作流程中频繁使用它，我认为它已经准备好公开使用。<p>我们支持 MacOS 和 Linux。<p>我将致力于一些更有用的功能，比如 Docker Compose/Procfile 兼容性和隧道功能，以便你可以通过易读的 URL 远程访问你的开发环境。<p>试试看，如果有什么不太对劲的地方，请提出问题或请求功能！<p><a href="https://github.com/logscore/roxy" rel="nofollow">https://github.com/logscore/roxy</a>