Live data from Hacker News

The code worked differently when the moon was full

hanselman.com

101–110 of 175 posts

Re: The code worked differently when the moon was full

#102
post #99

I've resolved several "celestial body" problems with routers and modems in East/West Africa over the years by pointing USB fans at them – between the sun and the workday generating heat with higher load in lower-end routers or insufficiently-air-conditioned units, can work surprisingly well to improve the network at almost no cost.

Neat Trick!

Re: The code worked differently when the moon was full

#103
post #26

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 t…

> 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.

Somewhat infamously, "a rare alignment of sunlight on high-altitude clouds above North Dakota and the Molniya orbits of the satellites" the Soviets used for their nuclear attack early warning system triggered a false alarm, which, had it been treated as a real situation, could have lead to nuclear war in the early 80s.

https://en.wikipedia.org/wiki/1983_Soviet_nuclear_false_alar...

Re: The code worked differently when the moon was full

#104
post #86

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 probl…

> 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. I've set up a couple of monitoring systems at a couple of different companies and one thing I've heard some people saying is that they don't care about "fancy graphs", they just want a dashboard of what is red…

The key here is to describe and explain what/why to look for and how to do it. Don't leave it to the Client/Customer to struggle and figure it out on his own.

I have often found it surprisingly difficult (in spite of being an Engineer myself) to read and interpret the various graphs in monitoring dashboards when i don't know what i am looking for. This is ten times harder for most "Manager" types.

Re: The code worked differently when the moon was full

#105

F'n A. Reading the comments on this thread makes me love humanity. So much ingenuity, raw engineering horsepower, creativity. Goddamn, you are great people and you should be proud of yourselves. Reading this makes me believe we will survive as a species.

you'll appreciate this:

I worked with a factory that spent several years tracking down a quality problem. Eventual cause was wind direction...whenever they were down wind of the local cattle stockyard during a hot day.

Re: The code worked differently when the moon was full

#106
post #66

Earlier quoted context omitted.

The end of that article is a good reminder of the units command, I've been using Google for units conversion for so long that I forgot about the standalone units . It even comes standard with OSX.

Is there an equivalent command for doing things like 147 days from today or days since 21 jun 2021 or 88 days after 15 Aug 2021? This is the one thing I really wish was in Spotlight (I use spotlight for unit conversion and calculations which is really handy).

https://www.timeanddate.com/date/dateadded.html

Re: The code worked differently when the moon was full

#107

Earlier quoted context omitted.

The end of that article is a good reminder of the units command, I've been using Google for units conversion for so long that I forgot about the standalone units . It even comes standard with OSX.

I love the GNU units program so much. I think I use it at least 4 times/week. It's useful for kitchen conversions and also quick nuclear fuel burnup calcs. For example I used it on this blog post covering the long-term sustainability of nuclear fuel resources on earth. https://whatisnuclear.com/blog/2020-10-28-nuclear-energy-is-...

Interesting kitchen you have. Calculating nuclear fuel burnup.

I wonder what's cooking? Does it glow in the dark? ;>

Re: The code worked differently when the moon was full

#108
post #26

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 t…

You get the same problem with geostationary satellites, e.g. for satellite TV. There's period of about 10 days every spring and fall where, for up to 30 minutes every day, the sun transits 'behind' a satellite within the beamwidth of the dish and totally overwhelms the signal at the LNB.

I experienced this when I was working on a cable company but sometimes they give out notices when it's going to happen. Random stuff still happens because of the sun. The sun is a very scary thing if you are studying it everyday but most people don't know it.

Re: The code worked differently when the moon was full

#109
post #26

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 t…

So much time and money wasted by not recording the camera. Could've simply reviewed the footage from the right timestamp and immediately discovered what was wrong. All you had to do was take a still picture every time the system makes a rejection.

Looks like a cool solution, when issue is known )

Re: The code worked differently when the moon was full

#110
post #26

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 t…

You get the same problem with geostationary satellites, e.g. for satellite TV. There's period of about 10 days every spring and fall where, for up to 30 minutes every day, the sun transits 'behind' a satellite within the beamwidth of the dish and totally overwhelms the signal at the LNB.

Once upon a time I had a problem with remote control. It woukd stop working from different positions, but from time to time, not always. It took a while for me to realize there’s a heating radiator behind my back in that directions. And it went hotter or colder depending on thermostate. I guess at one point its IR output would overwhelm IR output from remote control.
Post reply on HN