最新

我正在饱受紧张性头痛和颈部肌肉僵硬的困扰。靠墙站立时，我的后脑勺和墙壁之间大约有一个手掌的宽度。而我的伴侣只有一根手指的宽度。 我看了很多声称可以治疗“低头族颈”的视频，但其中一些说法相互矛盾。例如：有的说“不要做下巴内收”，有的却说要反着做。我对那些骗子持怀疑态度，希望找到值得信赖的建议。 这里有人成功治疗过“低头族颈”吗？如果是，你们是怎么做的，又注意到了哪些改善？我设想需要遵循某种“方案”，但我不知道自己能不能独自完成，或者是否真的需要去看理疗师。 简而言之：网上有很多建议，但我更信任 HN 社区，非常乐意听到一些个人经历。谢谢！

我在支付行业工作了很长时间，尤其是在一个相当小众的报告/聚合平台上，该平台的工作负载具有峰值，并且不易并行化。为了尽可能多地将数据输送到我们的管道中，我们不得不依赖于大约六个左右的、不太微服务的复杂锁定方案——清楚地了解服务如何与给定数据源交互是一个主要的难题。这个问题一直困扰着我，即使我不再在那家公司工作，并导致了 Wool 的开发。 如果你使用过 Ray 或 Prefect 这样的框架，你可能熟悉“用两行代码（或类似的东西）从脚本到规模”的承诺。这基本上就是我一直在寻找的解决方案：一个具有有限样板的框架，它在一个连贯的代码库中促进任意的分布式方案。然而，我希望的是更专注的东西——我没有在做机器学习管道，除了分布式层之外，不需要太多其他东西。这就是 Wool 的用武之地。虽然它的 API 与 Ray 和 Prefect 类似，但它的不同之处在于它的范围和架构。 首先，Wool 不是一个任务编排器。它提供基于推送的、尽力而为的、最多一次的执行。没有内置的协调状态、重试逻辑或持久的任务跟踪。这些问题仍然由应用程序定义。Wool 的优点在于它看起来和感觉就像原生的异步 Python，允许你根据需要使用专门构建的库，就像你使用任何其他 Python 应用程序一样（有一些注意事项）。 其次，Wool 在设计时就考虑到了速度。因为它没有被功能所累，所以它实际上非常快，即使在它目前的早期阶段也是如此。Wool 例程直接分派到 gRPC 工作人员的去中心化对等网络，这些工作人员可以依次在它们之间分发嵌套的例程。这导致了低分派延迟和高吞吐量。在组装一些更强大的基准测试之前，我不会做出任何性能声明，但在我的 M4 MacBook Pro 上运行本地工作人员（一个微不足道的例子，我知道），我可以轻松实现亚毫秒级的分派延迟。 总之，看看吧，欢迎任何和所有反馈。关于文档——代码目前就是文档，但我保证我很快就会解决这个问题。我对下一步有很多想法，但当人们真正使用你构建的东西时，总是更有趣，所以我欢迎关于有影响力的功能的建议。 -康拉德

决策卫士 通过直接呈现过去的架构决策，防止机构性遗忘 # 全局安装 npm install -g decision-guardian # 或者直接使用，无需安装 npx decision-guardian --help # 检查已暂存的更改 decision-guardian check .decispher/decisions.md # 针对分支进行检查 decision-guardian check .decispher/decisions.md --branch main # 自动发现所有决策文件 decision-guardian checkall --fail-on-critical # 使用模板初始化新项目 decision-guardian init --template security 可在任何 CI 系统中使用 — GitLab、Jenkins、CircleCI、pre-commit hooks 等 Github 开源 -: https://github.com/DecispherHQ/decision-guardian

我经常接触各种行业，注意到现场计算的情况非常普遍。比如楼梯尺寸、屋顶坡度、混凝土体积，或者快速估算材料用量，通常都是靠猜测、手机计算器和潦草的笔记来完成的。 所以我开发了 TradeSet。 这是一个为行业人士设计的简单工具箱应用，将常用的建筑计算器整合在一起，方便你在现场快速计算。 目前，它包含以下功能： * 楼梯计算器 * 屋顶坡度计算 * 混凝土和测量计算器 * 保存常用计算结果 * 可选云同步 我们的目标是保持它的简单实用，而不是将其变成一个复杂的项目管理工具。 它刚刚在 iOS 上线，我将根据行业人士的反馈，继续添加更多计算器和工具。 如果这里有人从事建筑行业，或者之前开发过行业工具，我很想听听你们认为哪些工具在现场 realmente 有用。