Software, technology, sysadmin war stories, and more. Feed
Sunday, January 6, 2013

Feedback: offset clocks, resumes, and variable honks

It's time for more reader feedback!

Daniel read Thursday's post about "future-dating" your unit tests, and asks:

Was there a reason why you would want to run your tests 90 days in advance instead of specifying times at future points where there is likely to be a problem?

To be honest, I don't know which future points might have a problem. Lots of times have the potential to be freaky depending on what's going on. For instance, if your locale observes daylight saving time or summer time, then you probably have a discontinuity in local clock time twice a year. This means you probably jump from 1:59 AM to 3:00 AM at one point in the year, and from 1:59 AM to 1:00 AM at another.

This can introduce some fun problems. The original release of Windows 95 notoriously "forgot" it had already done the adjustment, so it would keep "falling back" every hour until you finally knocked some sense into it.

Leap seconds can be inserted twice a year, and they happen irregularly. That means your June 30th or December 31st might be longer than usual. Also, if something cosmically bizarre should happen which causes the rotation to speed up for long enough, we might have a second removed to keep things on track.

February 29th is a special day. December 31st can also be special, particularly if it's a leap year and you now have a 366th day in your year. There are just so many corner cases that trying to track all of them would be an exercise in futility. You can certainly try, but I'd still recommend running offset time in some of your tests just in case you miss something.

Random bonus note: go look at a calendar for September 1752. How many days does it have? Will it look like that for everyone? Are you sure?

Handling time and dates properly is ridiculously difficult.


A reader wishing to remain anonymous wrote in response to Friday's post about life as a frequent interviewer at a big company. His position is that people don't read resumes because they are poor readers, and they "... commonly assume that resumes are just nicely formatted lies". He goes on to mention that written English skills and software development are correlated in his experience.

So, okay, about that. I actually read through the resumes of people who I interviewed, but I didn't trust anything on them. If anything, I treated a resume as a series of claims which potentially needed to be verified. Some candidates had unreasonable lists of skills or experience, and I tended to ask about those to see where they were coming from.

For instance, I remember this one person who mentioned Sendmail, Qmail, Exif, that wacky Java mail thing called James and Postfix all in the same context: a former job. His implication by listing all of that stuff in one place was that somehow he wrangled all of them at the same time. This sounded unlikely, so I asked about how they were interconnected.

That's when he revealed that they only really used one mail program, and he hadn't done a whole lot with it anyway. All of the others on there were just fluff. That little interaction teaches me that everything he claimed is now suspect, since he's been peppering his resume with "grep bait".

For the record, my resume has had a list of stuff on it too. The difference is that I actually label it "buzzword compliance / grep bait" to hang a lampshade on what I'm doing, and (more importantly) everything on there is something I feel comfortable being quizzed about.

As for using all of those mail programs at one job? That's actually totally possible. Hint: my former job as a web support monkey involved touching all sorts of grungy mail software installs, including one that wasn't even officially supported.

The official line was "anything on your resume is fair game". In other words, if you claim knowledge of something on there, be prepared to defend it.


Finally, regarding an older post from back in August about car horns and types of honks, I received a comment which talks about how older cars didn't have this problem. On them, you could usually get a nice "beep beep" or a full-blown HONK by frobbing the controller one way or the other.

The difference is that these older cars didn't have air bags, and the newer ones do. Cars with air bags in their steering wheels tend to be "all or nothing" when it comes to honking. Giving it a light touch might not make any noise at all!

I had forgotten about that little change in things. It's been a while since I last drove a car without a driver-side airbag. Thinking back, it did seem that the sensor was right there under the cover and it was trivial to just *boop* it the right amount. These days, it seems like the entire steering wheel cover has to travel a fair bit before anything happens, and then you get a whole lot of noise when it does.

Thanks for the questions and comments!