Txr is a baroque and painfully hard to use language inspired by, among others, the idea of reversing “here document” generation into “here template” extraction. Since its inception in September 2009, it has grown hair, such as functions that aren’t really like normal functions, and try/catch/finally exception handling. If a complicated Txr query fails on your sample input, just give up. Don’t even think about trying to understand the debug trace output, and the mailing list is likely to be of little help, since pretty much only the author reads it. It is recommended for those who are faced with some simple, boring little problem that is dire need of compounding.
If only all software package descriptions were so honest.
I seem to recall that, despite the hoopla, the transition from 1999 to 2000 was pretty uneventful, software-wise. (To be fair, the hoopla also involved a lot of actual bug-fixing, which helped make things anticlimactic.) But Slashdot reported on a couple bugs caused by going from 2009 to 2010.
This one actually affected us at UNH mildly: One of the heuristic rules used by SpamAssassin is to watch for messages dated “grossly in the future”, presumably caused by spammers who are careless with such things. But it turned out that the developers’ idea of “grossly in the future” was hard-coded back, well, grossly in the past. The actual code snippet:
header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]
describe FH_DATE_PAST_20XX The date is grossly in the future.
Darn, they really should have caught that before 2010 rolled around. As it was, the normal update of SpamAssassin rules early on January 2 changed the regex to /20/[2-9][0-9]/. Still a number of messages delivered in the meantime got an extra unwarranted bump in their spam scores. Hopefully, SpamAssassin will come up with a better fix sometime before 2020.
But SpamAssassin is free software; we know we’d never see that kind of blunder in commercial software, right?
Well, this one is pretty good too: both SMS-reading software in Windows Mobile and some point-of-sale terminals in Australia jumped ahead to the year 2016 on January 1. The bug is apparently caused by timestamps where the one-byte year field is supposed to be interpreted as binary-coded decimal (so 0x10 means “ten”); instead the software did the binary conversion (where 0x10 means “sixteen”). Voila, you’re in the future!
Thank goodness we’d never make such mistakes ourselves.
Yet another website about programming is Software Engineering Tips, written by an anonymous (as near as I can tell) genius. It’s full of opinions, wisdom, and humor, and may make you laugh, squirm uncomfortably, nod your head in vigorous agreement, or punch the screen. Or all four of those things in some combination.
If you’re looking for security wisdom, D. A. Norman has some.
The numerous incidents of defeating security measures prompts my cynical slogan: The more secure you make something, the less secure it becomes. Why? Because when security gets in the way, sensible, well-meaning, dedicated people develop hacks and workarounds that defeat the security. Hence the prevalence of doors propped open by bricks and wastebaskets, of passwords pasted on the fronts of monitors or hidden under the keyboard or in the drawer, of home keys hidden under the mat or above the doorframe or under fake rocks that can be purchased for this purpose.
He’s not particularly fond of complex password rules. Fortunately, he didn’t make fun of ours. Because he found Northwestern’s.
One reason programmers dislike meetings so much is that they’re on a
different type of schedule from other people. Meetings cost them more.
There are two types of schedule, which I’ll call the manager’s schedule
and the maker’s schedule. The manager’s schedule is for bosses. It’s
embodied in the traditional appointment book, with each day cut into one
hour intervals. You can block off several hours for a single task if you
need to, but by default you change what you’re doing every hour.