在我打字的时候，Reddit 正在宕机。我自己的请求返回了500错误，Down Detector 报告说出现了故障，但 Reddit 自身却表示所有系统正常运行。<p>这是我多次注意到的许多服务的一个模式。如果状态页面不能实时准确地反映情况，那为什么还要设置状态页面呢？较小的问题往往也不会被承认，这并不罕见。<p>这是否与 Atlassian Statuspage 的工作方式有关？<p>编辑：Redditstatus 在太平洋时间04:27终于承认了这个问题，距离 Down Detector 图表显示的峰值已经过去了20多分钟。
返回首页
24小时热榜
想象一下，你在1996年阅读了一篇《连线》杂志的文章，设想了以下情景：<p>(1) 股市持续上涨，而唯一的增长和资本支出都集中在人工智能领域<p>(2) 大规模裁员，许多人工工作岗位消失<p>(3) 由于数据中心的爆炸性增长，资源消耗激增<p>你会认为人类及其易出错的系统是通过一系列意外和贪婪的投资导致了这一切吗？就像我们在经历了郁金香泡沫、铁路泡沫、垃圾债券、Web 1.0等之后，似乎已经准备好相信的那样？<p>如果到了2025年11月，萨姆口袋里有一个通用人工智能，正在利用所有这些资金来发展自己，情况会显得多么不同呢？
当与另一方通过ChatGPT发送论点和冗长回应时，你的策略是什么？这些回应针对的是你真实、经过深思熟虑并基于数十年经验的请求。<p>我有一个朋友最近抱怨对方浪费时间，生成大量需要评估和反驳的事项清单。这种情况是否在处理更大案件的较大律师事务所的对方律师中出现，他们通常是直接沟通的？你在较小案件中处理过这种情况吗？
是时候有一个更好的 Venmo/PayPal 了……
一个全球可访问的，让你赚钱，并从利润中抽取一部分，而不是通过高额费用和糟糕的汇率来坑你。
我制作了这个 iOS 和网页应用，现在把它交给你。
通过电子邮件发送 USDC。
Btwn Friends 是一个开源的 PayPal/Venmo 替代品，允许你将稳定币发送到任何人的电子邮件，而对方无需安装应用、拥有钱包或了解加密货币。
它的工作原理如下：
每个 P2P 支付应用都要求你创建账户、保存 12 个单词、链接钱包应用、进行 KYC、转账燃料代币……
这让人感到害怕，工作量也太大。
你的朋友只想要回他们的 20 美元。他们并不关心“去中心化”。
在这里，你只需用电子邮件和一次性密码（OTP）登录。
就这样。
你刚刚登录了你的钱包或创建了一个。无需钱包应用、Chrome 扩展、种子短语或加密知识。
你的钱包是由 Coinbase 开发者平台自动创建的。
要发送钱，你只需要一个电子邮件地址。
不是钱包地址或 ENS 名称。只需一个电子邮件。
输入：friend@example.com → $25 USDC → 发送。
这就是整个流程。
收款人会收到一封电子邮件：“John 给你发送了 25 美元”。
他们点击链接 → 用电子邮件登录 → 资金出现。
他们无需：
- 设置钱包
- 拥有 ETH 作为燃料
- 知道什么是区块链
- 复制/粘贴地址
如果你的朋友在应用上 → 钱直接转给他们。
如果他们不在 → 钱会进入托管账户。
当他们用电子邮件和 OTP 登录时，证明他们拥有该电子邮件。
托管账户会自动释放资金。他们在仪表板加载之前就能看到余额。
你可以构建链上应用，而不强迫用户“学习加密”。
Between Friends 是基于 Base（以太坊二层）构建的，使用了基本的托管智能合约，并由 Coinbase 开发者平台的嵌入式钱包（智能账户）和支付管理器提供支持。
我已经为你完成了大部分工作，并留下了关于剩余工作的说明。
Coinbase 开发者平台的嵌入式钱包已经为你提供了约 4% 的余额奖励。
你可以利用链上工具，如 @MorphoLabs、@MoonwellDeFi、@superformxyz 等，为自己和用户赚取更多。
→ 网页应用：
[https://btwnfriends.com](https://btwnfriends.com)
→ iOS 测试版：
[https://testflight.apple.com/join/aZCPAjwZ](https://testflight.apple.com/join/aZCPAjwZ)
→ 代码库：
[https://github.com/Must-be-Ash/btwnfriends](https://github.com/Must-be-Ash/btwnfriends)
大家好，我们是Iyan和Datta，Barcable的创始人。
Barcable可以连接到您的后端（HTTP、gRPC、GraphQL），并利用自主代理直接在您的CI/CD中生成和运行负载测试。无需配置，无需脚本。它会扫描您的代码库，理解您的API路由，并构建真实的测试场景，以现实的负载对您的端点进行测试。
文档： [https://www.barcable.dev/documentation](https://www.barcable.dev/documentation)
我们之所以开发这个工具，是因为感到沮丧。我们合作过的每个团队都遇到了同样的问题：可靠性测试从未跟上开发的速度。管道的部署速度快于任何人验证性能的速度。大多数“负载测试”都是脆弱的JMeter遗留物或在第一次重构后就失效的临时脚本。
Barcable是我们对这一问题的自动化尝试。它：
- 自动解析您的OpenAPI规范或代码以发现端点
- 从PR差异中生成真实的负载测试（无需手动脚本）
- 启动隔离的Cloud Run作业以进行大规模执行
- 直接在您的仪表板中报告延迟、吞吐量和错误细分
- 接入您的CI，以便在部署前自动运行测试
每个代理处理过程的一部分——发现、生成、执行、分析——使得测试随着您的代码库而演进，而不是与之对抗。
目前，它在Docker化的代码库中效果最佳。您可以从GitHub上进行入驻，探索端点，生成测试，运行测试，并在统一的仪表板中查看指标。
这仍然是一个正在进行中的项目。我们会手动创建账户，并与任何有兴趣尝试的人分享凭据。由于Cloud Run的成本，我们目前限制了访问。
我们并不是想取代性能工程师，而是希望让团队在生产之前更容易捕捉回归和事件，而无需繁琐的设置。
我们非常希望听到任何曾因不稳定的负载测试管道而受挫，或以不同方式解决可靠性问题的反馈。我们尤其对gRPC边缘案例和复杂的身份验证设置感到好奇。
HN一直是我们灵感的巨大来源，我们希望听到您如何测试、破坏或改进它的想法。
—— Iyan & Datta
[https://www.barcable.dev](https://www.barcable.dev)