**cargo-nextest** 是一款专为 Rust 设计的高性能下一代测试运行器。它的运行速度比 `cargo test` 快达 3 倍，并通过现代化、直观的界面以及强大的“每个测试独立进程”隔离机制，有效提升了开发者的工作效率。
主要特性包括：
* **高级控制：** 使用强大的过滤器 DSL 精确选择测试，并可针对每个测试进行自定义设置，包括超时、重试和资源限制。
* **CI/CD 优化：** 专为大规模工程设计，支持跨多个工作节点进行测试分区和分片，并提供 JUnit 输出和构建存档功能。
* **可靠性与调试：** 具备“记录与重放”功能，支持压力测试以识别不稳定的测试用例，并可集成 Perfetto 等工具进行深度性能分析。
* **可扩展生态：** 可与覆盖率工具、调试器及变异测试套件无缝集成。
`cargo-nextest` 具备跨平台特性且备受信赖，为 Rust 开发带来了基础设施级别的可靠性。虽然目前仍需通过单独的 `cargo test --doc` 步骤来运行文档测试，但它已成为标准测试工作流中稳健且可投入生产的替代方案。如需开始使用，只需安装二进制文件并运行 `cargo nextest run` 即可。
每日HackerNews RSS
本网站正在使用安全服务来保护自身免受在线攻击。您刚才的操作触发了安全防御机制。触发此拦截的操作可能有多种，包括提交了特定的词汇或短语、SQL 命令或格式错误的数据。
这是 Apache Shiro 的一个重要新版本，汇集了两年多的工作成果，带来了许多新功能和改进。 * JDK 17 作为新的最低基准要求 * 支持 Jakarta EE 9/10/11+（不再使用 javax.* 命名空间） * 支持 Spring 6/7+ 和 Spring Boot 3/4+ * 支持 Guice 7/8+ * 在 JDK 25+ 环境下，使用 Java Scoped Values 代替 ThreadLocals 来处理 Subject 和 SecurityManager * 提升了 Shiro 原生会话（SimpleSession、SimpleSessionFactory、CachingSessionDAO）的线程安全性
对不起。
截至 2026 年 7 月，作者的日常工作流程已因大语言模型（LLM）而发生根本性转变，这些模型现已成为其编程、研究和项目设计流程的核心。尽管这些工具无疑提高了生产力，并使作者能够探索陌生的技术领域，但对人工智能的依赖也滋生了日益增长的职业倦怠感。 除了应对模型幻觉和代码错误所带来的预期挫折外，作者发现自己越来越反感人工智能生成文本在风格上的单调性。那些僵硬的表达模式——表现为断续的措辞、重复的结构以及刻意使用的表情符号——已成为令人心烦意乱的源头。 尽管作者承认人类也会犯错，但人工智能输出那种独特且刻板的统一性正在造成一种倦怠感。尽管大语言模型十分实用，但作者却难以在提高效率的同时，克服对“AI 审美”日益加深的恐惧，这使得他们在面对既高效又令人心力交瘁的工作流程时，只能选择“咬牙坚持”。
作者主张将“计算中位数”作为高质量的软件工程面试题。相比简单的“Fizz Buzz”测试，该问题能更全面地评估候选人的技术成熟度和思维深度。 这项练习要求候选人在多个实际工程权衡中做出选择，包括 API 设计、副作用（可变性）以及排序的性能考量。同时，由于逻辑中常包含“差一错误”（off-by-one errors）以及针对数组长度奇偶性的分支判断等陷阱，该问题也为观察候选人的调试习惯提供了天然场景。 除了代码实现，该问题还是深入探讨统计概念（例如为何中位数通常比平均数更稳健）以及考察候选人是否能有效利用标准库的绝佳切入点。归根结底，该任务因其简洁性而具备极高的可测试性，同时能清晰揭示候选人是否能审慎地思考其代码所带来的影响。
围绕“中位数计算”这一面试题的讨论，揭示了招聘实践中存在的巨大分歧。
**批评者**认为，此类问题属于“计算机科学入门级的自我陶醉”，对于大多数行业岗位而言毫无意义，因为开发者几乎不需要从零开始计算中位数。他们指出，这些难题忽视了系统设计、沟通能力、错误处理及学习能力等高级职场必备技能。此外，许多面试官往往抱有刻板的预期（例如“必须对数据进行排序”），而忽略了快速选择（Quickselect）或流式算法等更高效的方案。
**支持者**则为该问题辩护，认为这是筛选无法编写基础代码的应聘者所必需的手段。他们认为大规模招聘需要一个“漏斗”来快速剔除不合格者。在验证了基本能力后，他们会转而探讨更深层的问题，如权衡考量（例如内存限制、数据流和时间复杂度）。
最终，业界的共识倾向于将简单易懂的问题作为切入点——其目的不在于考察死记硬背，而在于评估候选人的解决问题的思路、学习意愿以及进行有效技术对话的能力。面试的价值不在于“正确”的代码，而在于对现实约束条件的共同探索。
**Frugon** 是一款免费、本地化且开源的工具，旨在通过检查您的实际调用日志来分析并优化大语言模型（LLM）的成本。由于它完全在您的机器上运行，您的数据和 API 密钥将始终保持私密，绝不会与第三方共享。
**工作原理：**
* **捕获：** 使用 `frugon capture` 作为本地代理，将应用程序的 LLM 流量记录为 JSONL 日志。您也可以直接提供现有的日志文件。
* **分析：** 运行 `frugon analyze` 以生成详细的成本分析报告。该工具会将您当前的支出与各种模型替代方案进行比较，识别出哪些调用可以在不牺牲性能的前提下转向更便宜的模型。
* **评估：** 您可以选择使用 `--measure` 标志，利用您自己的供应商密钥针对真实流量对候选模型进行测试，确保在切换之前维持高质量表现。
Frugon 提供清晰且可操作的建议，例如“将困难任务保留在当前模型，将简单任务转移到更经济的模型”，从而帮助您显著节省每月的 LLM 开支。该工具轻量化，能快速处理超过 10 万条记录，并支持输出用于预算审查的专业报告。
如需持续、自动化的路由功能，请访问 [frugon.rodiun.io](https://frugon.rodiun.io)。
**Frugon** 是一款全新的本地命令行工具，旨在通过识别哪些大模型（LLM）调用可以使用更廉价的模型来处理（且不牺牲质量），从而帮助用户降低 AI Token 成本。
该工具由用户 *jarodrh* 开发，通过分析本地 OpenAI 风格的日志，基于 LMArena 的质量分级提供节省成本的建议。它完全在本地运行，也可选择使用本地代理，并确保在分析过程中没有任何数据流向外部端点。
该工具具备三大核心功能：
1. **分析（Analyze）：** 通过对比当前使用情况与更廉价模型的差异，估算潜在的每月成本节省额。
2. **衡量（Measure）：** 并排展示不同模型处理相同提示词（Prompt）和回复（Response）的输出结果。
3. **评估（Judge）：** 使用选定的大模型来对比候选模型与当前模型的性能，并采用倾向于“平局”的提示词模板，以确保输出结果在功能上等效。
通过将成本分析与“以大模型为裁判（LLM-as-a-judge）”的验证循环相结合，Frugon 能够帮助开发者超越简单的削减成本，确保路由决策能够维持其特定任务所需的质量标准。该工具开源（MIT 协议），可通过 `uv` 安装。
关于 新闻 版权 联系我们 创作者 广告 开发者 条款 隐私 政策与安全 YouTube 的运作方式 测试新功能 © 2026 Google LLC
Nicolas Seriot 证明了 Unicode 技术标准 #35 (UTS #35) 中的音译规则（通常用于将“é”转换为“e”等简单的文本转换）是**图灵完备的**。
通过利用该规范的“重访游标”（revisiting cursor）功能，这些规则可以实现复杂的计算模型，包括 2-标签系统、Collatz 函数、110 号规则元胞自动机以及素数生成算法。由于音译引擎在规范中没有限制，因此无法判定给定的规则文件是否会终止。
虽然广泛使用的 ICU 库包含一个务实的“循环限制”来防止无限执行，但其底层的规则本质上是可执行代码。Seriot 的研究发现，在大多数操作系统、浏览器和数据库中被隐式信任并内置的区域设置（locale）数据文件，实际上具备执行任意计算的能力。这揭示了一个重大的安全隐患：接受来自不受信任来源的音译规则文件，等同于执行任意代码，因此应以同等的安全严谨度进行对待。
一项近期的发现指出，用于文本处理的 Unicode UTS #35 音译规则系统是图灵完备的。研究人员通过证明仅需三条重写规则即可计算考拉兹猜想（Collatz conjecture），再次揭示了一个在看似平凡的数据处理格式中出现的“意外”图灵完备性案例。
Hacker News 上的讨论阐明了几个关键点：
* **安全影响：** 虽然该规则引擎在技术上是图灵完备的，但它并不构成现实的安全威胁。用户无法通过标准输入执行任意代码；该引擎需要加载自定义的、不可信的规则集，而这本身就意味着主机系统已经遭到入侵。
* **实用性：** 诸如 ICU 库（在操作系统和 .NET 等运行时中广泛使用）之类的实现，已包含重写次数限制等安全机制，以防止无限循环并确保程序能够终止。
* **更广泛的趋势：** 评论者指出，图灵完备性经常出现在配置繁杂的复杂系统中——从 Microsoft Word 的自动更正到基于字体的语言模型（LLM）。专家认为，随着数据处理规范为了应对全球语言需求而变得日益灵活，防止它们成为计算通用系统变得越来越困难，使得“可判定性”反而成了例外，而非惯例。