最新

我创建了Orchestera，这是一个平台即服务（PaaS），允许您在自己的AWS账户中编排Apache Spark集群，使用EC2实例时没有额外的计算费用。 我之所以开发这个，是因为我厌倦了像AWS EMR和Databricks这样的产品在使用Apache Spark时收取的计算费用。虽然有人可能会认为Databricks是一个更优越的产品，提供了更多附加价值，但我在使用AWS EMR的Apache Spark时并没有感受到这一点（根据我个人的使用经验）。 我构建这个工具的动机是希望能够创建自己的Apache Spark集群，而无需了解底层的数据基础设施工程，从而快速进入编写Spark管道的阶段，无论是作为Python应用程序还是Jupyter笔记本。 我花了将近一年的时间来构建它，同时还要兼顾日常工作。当然，我在前端设计和视频解说中使用了人工智能，而背后的基础设施工程则是基于我在行业中的丰富经验。负责集群编排的后端使用了以下技术： - Django和DRF用于API - Temporal用于异步工作者 - Pulumi通过Temporal工作者运行以编排集群 - Karpenter根据Spark执行器的工作负载和请求进行节点自动扩展 - Librechat用于Spark历史服务器和基于MCP的Spark管道运行分析调试 目前CPU限制没有上限，因此您可以在自己的个人AWS账户中免费试用这个工具。 同时，我也期待在Hacker News上获得反馈。

嗨，HN——我是布鲁诺。我创建了My Market Study，因为我对昂贵的代理报告感到失望，这些报告既慢又浅显。 您只需回答一个简短的向导问题 → 它会生成一个结构化的12章市场研究报告：包括市场总量（TAM）/可服务市场（SAM）/可获取市场（SOM）、竞争格局、市场定位、风险等信息——并附带来源——以PDF格式提供，同时还提供一个PPTX和HTML格式的入门演示文稿！ 我希望能获得关于准确性、结构和用户引导的直接反馈。 样本报告：<a href="https://my-market-study.com/sample-study" rel="nofollow">https://my-market-study.com/sample-study</a>

嗨，HN，我用Python从零开始构建了一个PostScript解释器。 PostForge实现了完整的PostScript Level 2规范——包括操作符、图形模型、字体系统、保存/恢复虚拟机等功能。它可以读取.ps和.eps文件，并输出PNG、PDF、SVG格式，或者渲染到一个交互式的Qt窗口中。 为什么要构建这个？GhostScript是目前唯一的PostScript解释器，而它的代码库已有35年历史，基于C语言。我希望能有一个可以真正阅读代码、逐步执行并理解发生了什么的工具。PostForge是模块化且易于接近的——每个操作符类别都在自己的文件中，类型系统清晰，并且有一个交互式提示符，可以让你查看解释器的状态。 一些技术亮点： - 完全符合Level 2标准，并选取了一些Level 3特性 - 支持PDF输出，包含Type 1字体重构/子集和TrueType/CID嵌入 - ICC颜色管理（通过lcms2支持sRGB、CMYK、灰度配置文件） - 可选的Cython编译执行循环（速度提升15-40%） - 使用自定义断言框架编写的2500多个单元测试，测试代码本身就是PostScript - 交互式执行模式，带有实时Qt显示——对调试PS程序非常有用 它并不是：用于生产/打印用途的GhostScript替代品。由于它是解释型Python，因此速度较慢。但它能够很好地处理复杂的现实世界PostScript文件，输出质量也很可靠。 我非常希望得到反馈，尤其是来自那些有PostScript或构建语言解释器经验的朋友。如果你想深入了解，架构文档可以在docs/developer/architecture-overview.md找到。

我一直想买一块像迪士尼乐园那样的砖，上面刻着我的名字。但这个机会从来没有出现在我面前。应该有人创建一个市场，汇集所有购买砖块的机会。我希望我的名字在我离开后依然能够被铭记。

我开发了Crit，这是一款命令行工具，能够让你从iOS模拟器中捕获屏幕截图，标记出问题所在，并向任何编码代理提供结构化反馈。 你只需： - `crit capture` — 截取你的应用屏幕截图 - `crit serve` — 在浏览器中查看，点击标记错误并添加评论 告诉你的代理：“查看 .crit 并修复每个问题”。 它会将带注释的截图和JSON文件保存到 `.crit/` 文件夹中。可以与Claude Code、Cursor、Codex、Gemini等任何能够读取图像的工具配合使用。无需插件、无需MCP、无需依赖。 需要macOS和Xcode。尚不支持Android。 代码库： [https://github.com/natethegreat/crit](https://github.com/natethegreat/crit)

嗨，HN， 我一直在实验将文件转换尽可能多地推向浏览器的可行性。去年，我尝试将 LibreOffice 无头模式编译为 WASM。我能得到的最小构建大约是 150MB——仅仅为了将 DOCX 转换为 PDF，这个体积实在太大了。于是我转向了一种混合的方法。 如今，大约 90% 的转换是在客户端使用 WASM 进行的（FFmpeg、PDF/图像工具、电子表格等）。较重的边缘案例则回退到一个小型服务器管道（LibreOffice、Pandoc、Poppler）。 主要的挑战并不在于库本身，而在于： - 浏览器的内存限制 - 处理大文件时不冻结用户界面 - 仅在需要时懒加载大约 30MB 的 WASM - Safari 与 Chromium 行为差异 FFmpeg.wasm 的运行速度大约是原生速度的 10% 到 20%。对于小型和中型文件来说是可以接受的，但对于大型媒体文件就不太合适了。我还尝试在浏览器中使用多线程的 FFmpeg，但还没有找到稳定的设置。 我很好奇其他人如何看待客户端处理与完全服务器端管道之间的权衡。 → anythingconverter.com