Do Not Push the Red Button!

So this is the time of year when all Nice Jewish Boys (and Girls) should turn their minds to ethical questions. And no field is more fraught with ethical conundrums than… technical writing. For example: is it better to document every API method or option, no matter how obsolete or dangerous? (Otherwise known as the “Give them rope and explain how they can tie their own noose” approach.) Or should you try to hide all the bad stuff for the user’s own good? (Otherwise known as the “Allanon School of Technical Writing.”)

Usually I advocate the first school. Basically I figure that people are grownups, and if you do your best to explain things, hey, it’s their lookout. This is not to say some projects shouldn’t go the other way, but for the most part, I think more information is good. Plus, the first approach means more work to do, which theoretically means more employment for myself and my fellow tech writers! Solidarity, my brothers and sisters!

Anyway, while I do prefer the first school, this approach sometimes leads to amusing results. For example, my group maintains a certain internal tool that has a few dangerous command-line options. Most of these fall into the category of, “only use this if you really know what you’re doing,” which is fine. But there’s one that I had to document like this:

“[blah blah blah descriptive text.] CAUTION: Using this option can completely destroy your system. Do not use this option.”

I ran across this description again just a few days ago, and man, it never fails to crack me up. Trust me, we technical writers are really hilarious once you get to know us.

Adventures in Post-Apocalyptic Dentistry

Sam: who needs an alarm system? http://news.yahoo.com/s/nm/20060922/od_nm/austria_heads_dc

Evan: Wunderbar.

Evan: I thought that in order to construct your Post-Apocalyptic Throne of Skulls, you had to actually live in the post-apocalyptic era. But I guess all you need to be is an ordinary Austrian dentist.

Sam: Who knew?

Evan: seriously.

Sam: Novacaine for the Blood God!

Evan: haha

Evan: I wonder if those tests you take for job aptitude & career placement are able to measure your capabilities as a post-apocalyptic warlord.

Evan: “Dentist, Pharmacist, …”

Evan: “Post Apocalyptic Warlord”

Sam: “On a scale of 1 to 10, how positively do you view pain inflicted on others for your own gain?”

Sam: 9-10 range probably qualifies you for dentist/warlord

Sam: altho the pile of skulls thing does make dentistry that much more metal.

Evan: Again, who knew?

Sam: Not your average austrian burglar thats for sure.

Hacking MT 2.6; Or, I Don’t Understand Perl

So I’m trying to make a couple of minor modifications to my Movable Type installation’s MT::App::Comments Perl module, in order to make life a little more difficult for comment spammers. My goal is hampered slightly because I don’t know a damn thing about Perl.

In fact, the only language I know reasonably well is Java. Which means that any time I look at code for Language X, my brain does its best to overlay Java syntax on top of Language X, adding in any bits of Language X that I might have accidentally picked up over the years.[1] For example, I can read C++, sort of, because Java’s syntax was designed to be a lot like C++. Except that C++ has all these funny characters sprinkled in: ampersands and asterisks and God knows what else. And when my brain goes down into the depths to retrieve the meaning of these funny characters, it unlocks a door called “CS 5“,[2] and I curl up in a fetal ball and start rocking back and forth and moaning, and the only thing that snaps me out of it is hearing my co-worker Jud singing “The Lunchtime Song.” Yes, we really have a lunchtime song. Want to make something of it?

Anyway, Movable Type is written in Perl, and the module that handles comments contains several hundred lines of code, some of which looks like:

if (!$q->param('text')) {
    return $app->handle_error($app->translate("Comment text is required."));
}

Now, even my poor little Java-addled brain can understand what this means. For starters, I understand “if” and curly braces. I undertand the “!“, the “return“, and the basic idea behind “handle_error(stuff);“. Heck, I even think I understand “q->param('text')“! And in fact, if you try to submit a comment and you leave the “text” field blank, you do indeed get an error message:

Comment text is required.

Try it! It’s fun!

So as a test of my elite Perl-hacking skills, I changed the snippet above to:

if (!$q->param('text')) {
    return $app->handle_error($app->translate("Comment text is required, silly."));
}

But to my great disappointment, submitting a comment with no text resulted in:

Comment text is required.

This could mean one of two things:

  • The Perl module is cached in memory, and the server is not picking up my change.
  • The actual error message is specifed somewhere else in the code, and the snippet I was editing is just a red herring.

The red herring possibility seems unlikely. First, it would be perverse to create a module named MT::App::Comments, have a snippet that appears to handle the empty text field error, but actually handle the error somewhere else. I mean, I know the Perl world is whacky and crazy and There’s! More! Than! One! Way! To Do It!, but seriously. Second, I grepped through all of MT’s Perl code and did not find that particular error string anywhere other than in the Comments.pm file.

That leaves us with the caching possibility. To test this, I renamed the Comments.pm file, and lo! this completely broke comments. Excellent! Except that when I moved the file back, comment functionality resumed, but the system still wasn’t picking up my changes. So it seems that the system’s cache does bother to check whether any of its Perl module files have moved, but it doesn’t bother to waste time checking whether the module contents have actually changed. Perish the thought!

I can understand a caching system that is extremely “sticky” — even if you totally mess with the underlying files, the system doggedly continues to run with whatever it’s got in memory, until you somehow force the system to re-initialize. And I can understand a caching system that continually monitors the state of its files and obediently re-reads the code if it detects any changes. But the in-between behavior makes no sense. Why would you break if a file is missing, but not bother to read the file again when the file magically reappears? I have a hard time believing that this is actually the case. I must be misunderstanding how Perl is working here. Then again, after encountering the utter stupidity of pod2html for Perl 5.8 on Red Hat,[3] I’m willing to believe anything.

Update: Success! Turns out I was grepping in the wrong place. The hack is now in place. See comments.

1. This is sort of like trying to read French by A) looking for words that are very similar in English and B) sprinkling in the thirty-odd actual French words that you dimly remember from high school. Which is, coincidentally, exactly how I read French. Quel surprise!

2. After taking that class, I swore I would never, ever work for the computer industry. And if I ever had to write software, it would only be to do something useful, like solving a physics problem.

3. As opposed to pod2html for Perl 5.8 on FreeBSD, which basically works okay-ish.

Well, This Is Ominous…

Remember those giant communist spiders I was worried about? Okay, I haven’t, like, done a scientific study or anything… but it seems to me that as the summer draws to a close, there are definitely fewer communist spiders, but the ones that remain are larger and fatter and just plain wickeder than ever.

Nature frightens me.

In other, related scary Nature news, my cousin Auros points out this NY Times article about arthropod sexual cannibalism. As my cousin put it, “Well, when het marriage involves having your innards literally liquified and sucked out of your body, the gay agenda starts to sound rather appealing.” Hmmm. Somewhere there’s an old-school vaudeville-style joke about alimony or something in there… but I’m just not in touch enough with my inner Shecky Greene to make it happen. Hey, look, I’m a lamp! Take my wife, please! Eh.