Live data from Hacker News

The code worked differently when the moon was full

hanselman.com

81–90 of 175 posts

Re: The code worked differently when the moon was full

#81
post #44

Earlier quoted context omitted.

This is like a real-world equivalent of the "cleaning lady unplugged the machine" urban legend.

I was going to say it was the real world equivalent of, like, Redwall, or one of those other fantasy books where an event happens once a year when the sun shines in exactly the right spot to illuminate some secret writing.

Indiana Jones, Raiders of the Lost Ark.

Re: The code worked differently when the moon was full

#82
post #39
post #31

Earlier quoted context omitted.

I heard a story about an astronomer loosing the chance to be the first to report a commet one cold winter night - just as he wanted to send the email to report it, the Internet connection was dead! He ran from the observatory to the nearest place with Internet connectivity, but by the time he sent the email from there, there was already a report from another astronomer elsewhere, a few minutes ago. Reason for the mys…

When I started dating my wife she lived in a shared student residence. She would tell me that her internet didn't work when her room was cold. She had to wait for her space heater to heat up the the room. I didn't believe her at first but it turned out be true. She lived there for a year so I observed it several times. Never did find out what the problem is. I don't know if thermal contraction could effect solders be…

Some electronic parts are not rated to work below 0° C - for ‘commercial’ equipment the range is usually 0° to 50°C, and you often have to pay extra to get ‘industrial’ or extended range versions of parts that have ranges like -45° to 85°C (some fairly common parts you can even get to 105°C).

It it’s failing at 10°, I’d suspect there is a crack in a PCB somewhere or a badly soldered joint that isn’t actually making proper contact until there’s some thermal expansion. We don’t do anything special with the PCBs or soldering specifically, and all the stuff we make is tested down to -35° and up to 55°C with no issues…

Re: The code worked differently when the moon was full

#83
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).

WolframAlpha works well for those types of calculations.

Re: The code worked differently when the moon was full

#84
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…

This is like a real-world equivalent of the "cleaning lady unplugged the machine" urban legend.

I thought it was an urban legend and then somewhere in 2005/2006 I first spoke to one guy who claimed it was a bank in Tønsberg, Norway.

Later I worked with a IT manager who also confirmed it was such-and-such bank in Tønsberg. I have forgotten the name of the bank but I am still on friendly terms with him so I could ask next time I see him.

(My first draft of this post said that the first bloke had claimed to be in the room, but this is 15 - 16 years ago and the next story is also close to a decade ago so I might have mixed up who said what.)

Re: The code worked differently when the moon was full

#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 and what is green.

This might be a manager vs engineer perspective, because for me the graphs are the main point: it allows me to spot

- patterns (each night, each weekend, some weekends, more-or-less-randomly-except)

- and also trends: at this speed we are going to reach 80% utilization before November.

Re: The code worked differently when the moon was full

#87
post #81
post #44

Earlier quoted context omitted.

I was going to say it was the real world equivalent of, like, Redwall, or one of those other fantasy books where an event happens once a year when the sun shines in exactly the right spot to illuminate some secret writing.

Indiana Jones, Raiders of the Lost Ark.

The hobbit

Re: The code worked differently when the moon was full

#88
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…

I had a similar issue in my industrial automation class. We were sorting cylinders by diameter and height as they went down the conveyor belt. PLC controlling motors, sensors, etc.

My group got everything setup, built our program, and everything worked fine. Waited a few minutes for the TA to verify, but it failed. We changed a few things, it worked, but failed when he came over.

Another group looked over our code, no issues noticed.

Finally I realized I was standing when we were testing things. I sat down waiting for the TA to verify. My shadow blocked the sun from the photo eye. Wasted half the lab on an issue that was entirely dependent on our position in the room, but found the root cause.

Re: The code worked differently when the moon was full

#90
post #67
post #57

Earlier quoted context omitted.

Our garage door opener has this problem. At very specific times of the year the sun confuses the infrared blockage sensor. The cause occurred to me when I lined up my eye to see what the sensor was seeing when it was failing, and I noticed the morning sun right next to the other end of the sensor stream. I moved a trash can to shade the sensor and it worked fine.

I had the same problem with my garage door opener. Tried shading the sensor but it still didn't work reliably. Finally replaced both the sensor and transmitter and it has been good ever since. My theory is that the lens got dirty or scratched over the years and was picking up stray light from odd angles.

+1, I had this issue as well and went through a bunch of futile efforts to block the sun and the angle and wish I had replaced the transmitter a lot sooner instead of trying to move trash cans because that worked 50% of the time. I think this is the kit I bought: https://www.chamberlain.com/safety-sensor-kit/p/041A5034
Post reply on HN