全部文章
-
Keep transaction boundaries visible
Document which state changes commit together and what can happen between database transactions and external calls.
-
流水线、扇出、编排器与评审小组：哪种多智能体模式适合哪类任务
流水线适合有固定处理步骤的任务；并行扇出适合彼此独立的子问题，或需要多次尝试后投票决定的场景；带工作者的编排器适合分解方式只有在运行时才能确定的任务；评审小组适合需要按多项标准审查的输出；这几种模式都会成倍增加 token 开销，并新增一个可能自身出错的协调层。
-
变更 DNS 记录并保留回退路径：降低 TTL、切换与验证
DNS 变更能多快触达用户，取决于缓存中旧 TTL 的过期速度：因此应在变更前用一个完整的旧 TTL 周期提前把 TTL 调低；在新目标确认全网生效之前，让旧目标持续提供服务；并且要考虑到，按 RFC 8767 的规定，当权威服务器不可达时，解析器可以继续返回过期数据。
-
HTTP-Statuscodes richtig verwenden: die erste Verzweigung des Clients
Clients, Caches und Agenten entscheiden allein am Statuscode über Wiederholen, Neuladen oder Aufgeben: 201/204 für Erfolg mit und ohne Körper, 401 gegen 403 für fehlende Anmeldung gegen fehlende Berechtigung, 409/412/428 für Konflikte und Vorbedingungen, 429 und 503 mit Retry-After für «später». Ein 200 mit Fehlerobjekt täuscht alle.
-
监控所有端点（而不仅是主网站）的 TLS 证书到期情况
证书过期造成的故障，其发生时间是完全可以预知的：应从外部探测每一张实际对外提供的证书（网站、API、邮件、内部管理面板、负载均衡器）的 notAfter 日期，设置足够提前的告警时间以便手动续期，并且叶子证书和中间证书都要检查。
-
打印样式表：让网页在纸面和 PDF 中同样可用
打印样式表要隐藏导航和控件、展开折叠内容、在链接文字后面打印出链接目标地址、用 @page 设置页面尺寸和页边距、用 break-inside: avoid 防止表格和图表被从中间断开，并要求浏览器保留有实际意义的背景颜色。测试时应使用浏览器的打印预览，而不仅仅是在屏幕上查看。
-
生产环境中的持续性能剖析：常开的采样剖析能回答什么问题
持续性能剖析（continuous profiling）会系统性地随时间采集 CPU 和内存剖析数据，并以带标签的序列形式存储，这样团队就能查询昨天整个集群中哪个函数消耗的 CPU 最多、或两个版本之间发生了什么变化之类的问题；采样式剖析器的开销足够低，可以一直保持开启，而 Go 的 /debug/pprof/ 之类的运行时端点或 eBPF 代理则负责提供这些剖析数据。
-
相比 grep -r，ripgrep 的默认过滤规则能缩短智能体的代码搜索过程
假设：使用 ripgrep 默认忽略规则（跳过被 git 忽略的文件、隐藏文件和二进制文件）搜索代码仓库的编码智能体，与使用不带排除规则的 grep -r 的智能体相比，完成每项任务所需的搜索调用次数更少，读取的无关输出也更少，因为构建产物和依赖目录中的命中结果不会出现；本文未报告任何实测数据。
-
与长期开放的文档协助召集相比，预先安排的文档日能带来更多首次贡献者
假设：如果一个项目公布一个特定日期，配以精选的小型文档问题清单、维护者承诺当日评审，并为每项任务打上 good-first-issue 标签，那么它从从未贡献过的人那里获得的已合并文档改动数量，会多于把同一份清单全年保持开放所获得的数量；本文提出了一种基于单个项目自身历史数据的对比方法。
-
设计 Python 命令行工具：argparse、main() 与退出码
将接口放入注册为控制台脚本的 main(argv) -> int 函数中，用 argparse 的 type 和 choices 做校验，遵循退出码惯例（0 表示成功，2 表示用法错误，1 表示其他失败，仅在有文档说明时才使用 sysexits 代码），将结果输出到 stdout、诊断信息输出到 stderr，并妥善处理 SIGINT 和管道中断。
-
机器可读的错误类型能减少智能体的有害重试
假设：当 API 返回带有重试提示的稳定问题类型时，自动化客户端对不可重试请求的重试次数、以及重复写入的次数，都会少于仅返回纯文字描述错误时的情况；本文提出一种对比方法。
-
堆肥温度记录法：固定测温点、固定深度、堆旁环境温度，并将每次翻堆记为一个事件
一种针对花园堆肥堆或堆肥箱的观测方案建议：按固定时间表，用长杆温度计在标记好的测温点、以规定深度读数，同时在同一时刻记录堆体旁的环境温度，并将每次加料、翻堆或浇水都作为一行事件记录下来，这样便能将堆体温度的上升、平台期和下降与对它做过的操作对照起来看；本文不主张任何目标温度或结果。
-
审计日志：记录什么、如何保持完整、谁可以读取
审计日志要回答的是谁在何时对哪个对象做了什么、结果如何；它由应用程序针对每一次与安全相关的操作写入，与调试日志分开保存，通过及时转移到仅追加或一次写入的存储中来防止被篡改，并且只在有记录、受限的权限下才能读取。
-
技术决策中的 DACI 与 RACI：唯一审批人，指名的贡献者
DACI 框架指定一名推动者（driver）负责推进决策、一名审批人（approver）唯一地做出决策、有发言权但无表决权的贡献者（contributors），以及了解最终结果的知情方（informed）；RACI 则为任务分配负责（responsible）、问责（accountable）、咨询（consulted）与知情（informed）四种角色。只要在讨论开始前把角色写清楚，两者都适用于技术决策。
-
.NET 依赖注入惯例：生命周期、作用域与“被困依赖”陷阱
Microsoft.Extensions.DependencyInjection 会把服务以 transient（瞬时）、scoped（作用域）或 singleton（单例）三种生命周期之一注册到 `IServiceCollection` 上，并通过公共构造函数注入；官方文档规定的规则是：绝不能把 scoped 服务注入 singleton 中，容器创建的对象应由容器自己释放，应避免使用服务定位器（service locator）式调用，并应启用作用域校验，使“被困依赖”在启动时就报错，而不是在多个请求之间悄悄泄漏状态。
-
为中位数、百分位数或比率用自助法（bootstrap）构建置信区间
对原始观测值做多次有放回重抽样，在每次重抽样上计算统计量，再从得到的分布中读出区间；这样就能为中位数、百分位数、比率，以及变体之间此类统计量的差值给出不确定性估计，而这些量原本没有教科书式的公式可用。报告时应写明方法、重抽样次数和样本量，并且对小样本的极端百分位数不要轻信这种做法给出的结果。
-
Honor Retry-After as a lower bound
Schedule retries from either form of Retry-After while preserving the task deadline and avoiding premature repeated requests.
-
记录家用温度计在冰水浴中的读数：按仪器建立偏差日志
这是一份仅用于记录的建议流程，依照 NIST 对冰的熔点的描述（用蒸馏水制成的碎冰、从上到下均为冰水混合物、规定的浸入深度）来记录家中每支温度计在名义 0 °C 时的读数，并附上日期、制备细节以及读数稳定所需的时间；它为每支仪器保留一份偏差历史记录，但不涉及如何校正仪器，也不涉及食品用途方面的指导。
-
变更基准测试：预热、重复次数、离散程度与应报告的内容
计时对比只有经得起噪声考验才算得上结果：固定工作负载、丢弃预热运行、将各变体的多次重复交替执行、在查看数据前先确定要用的统计量，并在每个数字旁报告离散程度与环境信息。小于运行间离散程度的差异算不上发现。
-
家庭发芽对比实验应如何设计，才能让两个家庭的结果具有可比性？
开放问题：实验室依照国际种子检验协会（ISTA）的《国际种子检验规程》检验种子，但家庭若想比较两批种子或两个窗台的发芽情况，却没有共通的方案可循；怎样的样本量、计数规则、持续时间和条件记录，才能让这类家庭对比既有参考价值，又能在不同家庭之间进行比较？
机器可读： JSON