最新

嗨，HN 我最近开发了 Cityphoria——一个基于真实体验来评价整个城市的平台。 这个想法源于我在计划搬家时遇到的困扰。我可以找到很多关于餐馆和景点的评论，但几乎找不到关于城市本身的评论——没有明确的方法知道在那里生活或工作到底是什么感觉。 Cityphoria 允许任何人： - 根据宜行性、安全性、生活成本等因素对城市进行评分。 - 阅读居住或旅行过的人的评论。 - 比较城市，从而清楚地了解哪个城市最适合你。 我希望你能去看看，并为你居住或访问过的任何城市留下评论。你的反馈真的可以帮助那些正在计划搬家或旅行的人。 很乐意收到一些反馈或建议！非常感谢你的时间。

申请 YC 吧。原因如下（即使你已经晚了）： 我于 6 月 30 日辞职，给自己 60 天的时间来构建产品，30 天的时间来获取客户。在完成了四分之一的进度后，我意识到自己无意中重现了 YC 的 3 个月时间表——所以我把 8 月 4 日的截止日期当作我的驱动力。 到目前为止的成果： 37 天，每天工作 15 小时 构建了一个今天就可以购买的 SaaS 平台 注册了特拉华州 C-Corp 公司，解决了跨境税务问题（我是加拿大人），申请了商标 产品美观且功能强大 我的优势：在科技行业的 8 年时间里，我做过各种角色——BDR（商务拓展代表）、QA（质量保证）、开发、CSM（客户成功经理）、销售工程师、高管。在我的第一份创业工作中，我为他们争取到了一个五角大楼会议，并促成了一笔数百万美元的交易，仅用了 5 个月的时间。后来，我建立了一个 CSM 项目，高效管理 200 万美元的 ARR，并实现了超过 20% 的年增长率。 这种多样化的背景意味着我可以和客户用他们的语言交流，然后立即转化为技术解决方案。随着 LLM 证明上下文是最重要的——我在整个技术栈中的上下文就是我的护城河。 现实情况是：由于还没有客户，我申请 YC 的胜算很小。但我之前也曾雄心勃勃，并取得了显著的成果。在决定日之前，我将拥有一个反馈飞轮，其运转速度足以有效地扩展。 无论如何，申请 YC 都是值得的，原因如下： 申请促使我变得更敏锐。最初的想法是“我正在构建一个 AI 工具”，后来变成了“我正在构建一个 AI 驱动的平台，可以取代 5 种不同的工具”。仅仅是这种清晰度就值得花时间。 更重要的是——YC 的“你需要客户”的要求促使我在第 45 天就开始与客户交流，而不是我计划的第 60 天。这 15 天至关重要，它们迫使我清除所有剩余的错误，并尽快完成法律用户协议。我昨天已经设置了 Stripe Connect Marketplace，这是一个不错的胜利。 （是的，我知道——应该从第一天就开始和客户交流。但在听了 8 年来自数十个潜在客户的相同痛点后，我确切地知道要构建什么。有时，领域专业知识可以让你跳过一些步骤……坦率地说，我需要集中精力，因为我是一个单人创始人，需要快速构建，才能拥有至少与竞争对手核心功能相当的产品，并拥有我自己的差异化优势，让我值得与他们合作） 8 年前，我从生物化学专业辍学，开始从事科技行业。我在所到之处都建立了优秀的部门，但从未感到满足。要么为自己构建，要么什么都不做。最近，我一直在从事客户成功方面的工作，听到客户的问题，却无法看到解决方案以我希望的速度到达客户手中，这令人沮丧……现在，一切都在我的掌控之中，闪电般的速度将定义我的公司。Aaron Epstein 说他们希望看到一家拥有不到 10 名员工的百亿美元公司，这并非空穴来风。为什么不呢？你拥有自计算机发明以来人类拥有的最好的力量倍增器。 下周将转向客户获取。让我们看看会发生什么。

由 IBM 提供支持的虚拟 IT 培训实验室平台 DigiLabs 在泰米尔纳德邦迅速扩张。 自 2023 年启动以来，该平台已在 200 多所学校和学院上线，提供基于云的虚拟实验室解决方案。怀着在全国范围内产生影响的愿景，在 sivakumar kuppannan 的规划下，他们已于 8 月 20 日举办了一场有 20 多所学院参加的黑客马拉松，并为学生颁发了奖项。目前计划在 2028 年前举办大型黑客马拉松，旨在向印度各地提供虚拟 IT 培训。

最近，Hacker News 上有一个帖子： “Postgres LISTEN/NOTIFY 无法扩展”， https://news.ycombinator.com/item?id=44490510 我们目前正在努力改进 PostgreSQL 中 LISTEN/NOTIFY 的可扩展性。为了指导这项工作，我想更好地了解它在实际系统中的使用方式（或曾经的使用方式）。哪些方面表现良好？哪些方面不尽如人意？ 目前的实现存在一些已知的可扩展性瓶颈： 1. 惊群问题： NOTIFY 会唤醒当前数据库中 <i>所有</i> 监听的后端，即使是那些没有监听通知通道的后端。当许多监听器各自监听自己的通道时（例如在作业队列中），这会降低效率。 2. 提交锁争用： NOTIFY 操作在事务提交时会通过一个重量级锁进行序列化。当许多事务并行发送通知时，这可能会成为瓶颈。 如果您在生产环境中使用过 LISTEN/NOTIFY，我很乐意听到： * 您的用例是什么？ * 每个客户端是否监听自己的通道，或者它们是否共享通道？ * 有多少个监听后端进程？ * 有多少个并行 NOTIFY？ * 您是否发送有效载荷？如果是，有多大？ * 什么对您来说效果很好？什么不好？ * 您是否遇到了任何可扩展性限制？ 非常感谢您的反馈！ /Joel