最新

我一直受到常规的紧张性头痛和颈部肌肉僵硬的困扰。当我站在墙边时，墙壁与我后脑勺之间大约有一只手的宽度，而我的伴侣则只有一个手指的宽度。 我看过很多声称可以治疗“书呆子脖”的视频，但其中一些内容相互矛盾。例如，有些人说“不要做下巴收缩”，而有些人则说正好相反。我对那些投机者持怀疑态度，希望能找到可信的建议。 这里有没有人成功治疗过“书呆子脖”？如果有，你是怎么做到的？你注意到了哪些改善？我想象着需要遵循某种“方案”，但我不知道自己是否能独立完成，还是实际上需要去看物理治疗师。 简而言之：网上有很多建议，但我更信任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、预提交钩子等 GitHub 开源项目： https://github.com/DecispherHQ/decision-guardian

我花了很多时间接触各类工种，注意到在工作中经常需要临时进行计算。比如楼梯测量、屋顶坡度、混凝土体积或快速材料估算，通常都是靠猜测、手机计算器和潦草的笔记来完成的。 因此，我开发了TradeSet。 这是一款简单的工具箱应用，专为工人设计，将常用的建筑计算器集中在一个地方，让你在工地上能够快速进行计算。 目前它包括以下功能： • 楼梯计算器 • 屋顶坡度计算 • 混凝土和测量计算器 • 保存常用计算 • 可选的云同步 我们的目标是保持简单实用，而不是将其变成一个复杂的项目管理工具。 该应用刚刚在iOS上发布，我会根据行业内人士的反馈继续添加更多计算器和工具。 如果这里有从事建筑行业或曾为工人开发工具的人，我很想听听你们认为哪些工具在工地上会真正有用。