编程与软件工程hanselman.com
满月时代码行为不同
The code worked differently when the moon was full
2021 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Scott Hanselman 讲述了一个经典调试故事：代码在满月时表现不同，看似玄学，实则往往有真实的物理或环境原因。文章引发读者分享大量类似的诡异故障排查经历。
为什么经久不衰：它提醒我们：再离奇的 bug 背后通常也有合理解释，这种'环境因素导致故障'的排查思路对任何工程师都历久弥新。
HN 评论精选
太阳角度导致的镜头眩光造成间歇性误判，每年两次
我们曾有个客户每年都会惊慌来电几次，说我们的检测设备出现异常高的误判率，废品率飙升。等技术人员第二天赶到现场，一切运转正常，客户也无法复现。这样折腾了近三年。终于有一天，技术员在现场做别的项目时，客户跑来说'正在发生！快来修！'技术员赶到设备旁，发现阳光恰好以某个角度射入，在一台相机里造成了镜头眩光。随着太阳轨迹移动，这种情况每年发生两次。一块 strategically 放置的不透明塑料片永久解决了问题。
vidanay查看英文原文
We once had a customer who would call us in a panic a couple of times a year saying our inspection equipment was experiencing unusually high false rejects and they were generating very high scrap rate. By the time we got a technician on site the next day, everything was working flawlessly and the customer couldn't reproduce the problem either. This went on for almost three years with various levels of escalation to the current management. Finally, one day a technician was on site for another project when the customer came up to him and said "It's happening right now! Come fix it!" The technician rushed over to the equipment and discovered that the sun was shining at exactly the right angle to cause a lens flare in one of our cameras. This happened twice a year as the sun moved along its trajectory. A strategically placed piece of opaque plastic fixed it permanently.
潮汐（受月相影响）导致无线信号周期性衰落，有论文佐证
月相真的会影响性能。我朋友在苏格兰做无线链路，遇到每天时间不固定的信号损耗。把损耗对时间作图后发现周期约为 12 小时 25 分钟——正是两次低潮之间的间隔。低潮时水面反射路径干扰视距路径导致信号衰落，高潮时干扰小得多。潮汐高度确实取决于月相，所以损耗大概也随月相变化。
mhandley查看英文原文
The phase of the moon really can affect performance. A friend of mine worked on wireless links in Scotland and was struggling with loss at certain times of day, but not exactly the same time every day. When they graphed loss against time, the pattern was really periodic over many days. The periodicity turned out to be 12 hours 25 minutes, which they eventually realized is exactly the time between low tides. The problem was at low tide the reflected path off the water interfered with the line-of-sight path causing signal fading, whereas at high tide it interfered much less. In particular, see figure 2 of their paper for the correlation between tide height and SNR: https://homepages.inf.ed.ac.uk/mmarina/papers/EDI-INF-RR-1365.pdf As tide height really does depend on the phase of the moon, presumably their loss did too, if they measured for long enough.
地铁列车振动导致扫描仪间歇性出错
一个数字化项目里，某俄罗斯图书馆扫描的书质量很好，但偶尔页面中途会出现错位扭曲。大家怀疑扫描仪机械故障或软件内存泄漏。后来与莫斯科长途通话时，背景传来轰隆声——原来扫描中心紧邻地铁隧道，列车经过的振动足以造成故障，但只有恰好在扫描时经过才会触发。书越厚越容易被注意到，只是因为扫描时间更长、更容易碰上列车经过。
acdha查看英文原文
I heard a great story a while back for a digitization project where historic content was being provided by many libraries around the world, including one in Russia. The quality of the scanned books was excellent, except for a weird distortion every so often where part of the page would be shifted partway through as if someone had shifted half the page in Photoshop. This was only noticed in books over a certain size so people were checking to see if there was some kind of mechanical problem with the scanner (these were robots with automatic page turners so it was plausible that there could be something which was only an issue past a certain position), trying to figure out of there was some way that the software had some kind of memory leak or other issue which would explain the long and inconsistent intervals. Eventually they were on a long-distance phone call to Moscow and not turning up anything when there was a loud rumble in the background. “What was that?” lead to the realization that the library's scan center was close to a subway tunnel. The vibration of a passing train was enough to cause a glitch but only if you happened to be scanning at the exact time it went by: the reason longer books were noticed was simply because having more pages meant that at any point in time a long book was more likely to be sitting in the scanner and the technicians running the scanner were apparently tuning out the trains as background noise. This was reportedly the first project they'd done with one of the scan robots which can process an entire book unattended so it was plausible that smaller past projects simply hadn't been scanning frequently enough to hit this problem or that some previous technician had noticed and immediately redone the page.
新开启的 GSM 天线电磁干扰导致特定楼层网络丢包
90 年代中期我在一家跨国公司总部做 IT 支持，某天开始接到大量间歇性网络故障报告：10M 有线网络频繁出现 90% 丢包，但只有五楼受影响，且笔记本用户没事。我们拉了长网线边走边 ping，发现到楼梯一半就开始丢包。最后请来电磁干扰专业公司，发现是半年前对面楼顶新开的 GSM 天线，高度正好对准我们五楼……
vanviegen查看英文原文
This reminds me of something I lived through as a nerdy teenager working a summer job as first line IT support at the headquarters of a multinational, in the mid-90s... One day, I started receiving calls (through my pager!) from rather many people about intermittent networking problems. The state of the art 10mbit wired UTP network would have frequent bursts of 90% package loss. What was weird: only people on the fifth floor would have this issue..!? Our first thought was that they were on a single hub/switch that might have broken. But no, they were connected to the same uplinks as the computers on the problem-free surrounding floors. Furthermore, laptop users (who were of course also wired at the time) were reporting no problems whatsoever. We were pretty much out of ideas by that point, but did an experiment just to test our assumptions: we took a PC and hooked it up with a long network cable and a power extension cable on the fourth floor and started pinging it. Flawless. Then we started walking up the stairs, and, yes indeed, somewhere around halfway up the stairs packets started to drop. (But not at all times, sometimes it would be fine, like all PCs on the fifth.) If you want to guess at the cause, this is your chance. :-) We brought in a company specialized in EM interference. It turns out that a GSM antenna placed on the roof of the four story building opposite to ours about half a year ago, had just been turned on. Its height aligned to our fifth flour. Whenever someone was using this mast to make a call (which certainly wasn't all of the time back then), it would cause interference on a specific model of network card that we were using in all of our PCs. It had a relatively large metal component that was apparently a pretty good 900 MHz antenna. When confronted, the mobile operator quickly adjusted the antenna to not be directed at us. I believe all network cards were replaced soon after. Fun times!
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选