Category: Geek

If you’re a geek who’s been following the silliness about SCO’s claims about Linux, you’ll love We Love the SCO Information Minister.

Boss Ross let me take a panorama of his cubicle while I was waiting for him to finish an online chat with a client.

Wired magazine’s September 2003 issue has an article on Extreme Programming called The New X-Men.

From the Japan Times:

Japanese researchers in robot technology are advocating a grand project, under which the government would spend 50 billion yen a year over three decades to develop a humanoid robot with the mental, physical and emotional capacity of a 5-year-old human.

The researchers believe the Atom Project, inspired by the popular robot animation series “Tetsuwan Atom” [known here in North America as Astroboy — Joey] by the late cartoonist Osamu Tezuka, would help promote scientific and technological advances in Japan, just like the U.S. Apollo Project, which not only succeeded in landing men on the moon but contributed to a broad range of technological breakthroughs.

I wonder if this robot will have machine guns in his butt, just like Astroboy did.

Or, more accurately, what’s the programming language mandated by your company: Visual Basic .NET or C#? And what’s the size of your company (small — 1 to 10 / medium — 11 to 100 / large — 101 or more)?

Let me know in the comments.

For the past couple of days, I’ve been getting echospam. Some spammer or spammers have been forging my email address as the return address for their spamming, and the bounce messages are ending up in my mailbox. And the worst thing is, if I were to find this spammer and kill him, it would be me that went to jail. Where’s the justice?

I notice that Tim Bray’s getting echospammed too.

Joe Mahoney, on his blog Cheerschopper, points to Jon Bentley’s site for his classic book on good programming practices, Programming Pearls. Distilled from his columns from the magazine Communications of the ACM in the 1980s, the advice Bentley gives is still good today. I’m glad to see that he’s included samples from the book to peruse.

Here’s a good one on debugging:

The expert debugger never forgets that there has to be a logical explanation, no matter how mysterious the system’s behavior may seem when first observed.

That attitude is illustrated in an anecdote from IBM’s Yorktown Heights Research Center. A programmer had recently installed a new workstation. All was fine when he was sitting down, but he couldn’t log in to the system when he was standing up. That behavior was one hundred percent repeatable: he could always log in when sitting and never when standing.

Most of us just sit back and marvel at such a story. How could that workstation know whether the poor guy was sitting or standing? Good debuggers, though, know that there has to be a reason. Electrical theories are the easiest to hypothesize. Was there a loose wire under the carpet, or problems with static electricity? But electrical problems are rarely one-hundred-percent consistent. An alert colleague finally asked the right question: how did the programmer log in when he was sitting and when he was standing? Hold your hands out and try it yourself.

The problem was in the keyboard: the tops of two keys were switched. When the programmer was seated he was a touch typist and the problem went unnoticed, but when he stood he was led astray by hunting and pecking. With this hint and a convenient screwdriver, the expert debugger swapped the two wandering keytops and all was well.

A banking system built in Chicago had worked correctly for many months, but unexpectedly quit the first time it was used on international data. Programmers spent days scouring the code, but they couldn’t find any stray command that would quit the program. When they observed the behavior more closely, they found that the program quit as they entered data for the country of Ecuador. Closer inspection showed that when the user typed the name of the capital city (Quito), the program interpreted that as a request to quit the run!

Bob Martin once watched a system “work once twice”. It handled the first transaction correctly, then exhibited a minor flaw in all later transactions. When the system was rebooted, it once again correctly processed the first transaction, and failed on all subsequent transactions. When Martin characterized the behavior as having “worked once twice”, the developers immediately knew to look for a variable that was initialized correctly when the program was loaded, but was not reset properly after the first transaction.

In all cases the right questions guided wise programmers to nasty bugs in short order: “What do you do differently sitting and standing? May I watch you logging in each way?” “Precisely what did you type before the program quit?” “Did the program ever work correctly before it started failing? How many times?”