Mile
Zero

This week, I'm starting the winter quarter at Seattle Central Community College as an instructor for Intro to Programming and Intro to JavaScript. Understandably, this is cutting into my blogging time at the moment. If you're a student who has found this page by searching for my name, or if you'd like to follow along, my class pages are located here.

I'm tremendously excited by the chance to teach these classes--there's no better way to keep your skills sharp than to try to teach them to someone else.

On vacation in the Pacific Northwest. Back next week.

About a year back, Mile Zero started to seriously drag in terms of performance, taking more than two seconds to render the page. The problem seemed to be a combination of things: the CGI interface was slow, it didn't run under mod_perl, and I had accumulated a vast number of posts it was having to sift through--which, given that my Blosxom CMS uses the file system as its database, meant lots of drive I/O.

Since I needed to dip my feet into server-side coding anyway, I rewrote Blosxom in PHP. There are a few PHP versions of the script online, but they seemed like a hassle to install, and none of them had support for the plugins I was using--it was almost easier to just do it myself. The result was faster, smaller, and proved to be a great first programming project. Since it's also proved basically stable over the last year, I've decided to go ahead and post the source code in case anyone else wants it (consider it released under the WTF Public License). I suspect the market for file-based blogging scripts is fairly small at this point, but you never know.

HOW IT WORKS

Essentially, both versions of Blosxom work the same way: they recurse through the contents of your blog folder, looking for text files with a certain extension (.txt by default) and building a list. Then they sort the list by reverse-chron date and insert the contents of the first N entries into a set of templates (head, foot, story, and date). Using a REST-like URL scheme, you can change templates (helpful for mobile or RSS) or filter entries by subfolder. It's primitive, but it's also practically unhackable, and it's an awesome way to blog if you like text files. Turns out that I like text files a lot.

Original Blosxom boasted an impressive plugin collection, which it implemented via a package system: plugins exposed a function for each stage of the page assembly process where they wanted to get involved, and the main script would call out to them during those actions, passing in various parameters depending on the task. This being Perl, the whole thing was a weird approximation of object-oriented code that looked like a string of constant cartoon profanity.

PHP provided, I think, better tools. So a plugin for my new version of Blosxom does three things: it sets up its class definition, which should include the appropriate methods for its type, as well as any class or static properties it might need, then it instantiates itself, and finally adds itself to one of several global arrays by plugin type. During execution, the main script iterates through these arrays at the proper time, calling each plugin object's processing method in turn. At least, that's how it works in theory. In practice, I've only implemented plugins for entry text manipulation, because that's all I needed. But the pattern should carry forward without problems to other parts of the process, although you might want to rename the existing process() API method to something more specific, like processEntry(). That way a single plugin could register to handle multiple stages of rendering.

ENOUGH OF THAT, HOW DO I INSTALL IT?

Just copy the script to a publicly-accessible directory, and edit the configuration variables to point it toward your content directory. The part that tends to be confusing is the $datadir variable, which needs to be set to your internal server path (what you see if you log in via FTP or SSH), not the external URL path.

Next, you'll need to set up your templates. For each flavor, Blosxom loads a series of template files and inserts your content. These files are:

• content_type.flavor - Allows you to mess with the HTTP content-type, if you really want to.
• head.flavor - Everything that comes before your entries
• date.flavor - Format for the date subhead
• story.flavor - Template for each story, including its title and metadata
• foot.flavor - Everything that comes after your entries
• 404.flavor - What to display instead of an entry if no content is found

At that point, when you put text files in the data directory, they'll be assembled into blog entries based on the file modification time. The first line becomes the title of the entry. You can categorize entries by putting them in subfolders, or subfolders of subfolders, and then appending the path after the Blosxom script URL.

I've included a couple of entry plugins, as well, just to show how they generally work. One is a comment counter for the old Pollxn comment system that I still use--the CGI script works fine for comments, but the Perl can't interface with the new PHP script to say how many comments there are on any given entry. The other is a port of the directorybrowse plugin, which creates the little broken-up paths at the end of each entry, so people can jump up to a different level of the category heirarchy. They're short and mostly self-explanatory.

LESSONS LEARNED

At this point, I've been blogging on Blosxom, either the original or this custom version, for slightly more than five years. During that time, I've had all the dates wiped out during a bad server transition, I've moved hosts two or three times, and I've tweaked the site constantly. I think the level of effort is comparable to people I know on more traditional blogging platforms like Wordpress or Movable Type. Of course, the art of writing online isn't really about the tools. But there are some ways that Blosxom has its own quirks--for better and for worse.

The big hassle has been the folder system, especially for a personal blog like this one, where I may ramble across any number of loosely-connected topics from day to day. Basing a taxonomy on folders means that posts can't span multiple categories--I can't have something that's both /journalism and /gaming, for example, which is unfortunate when writing about something like incentive systems for news sites. And once it's been created, you're pretty much stuck with a category, since most of the old links will target the old folder. There aren't many reasons I would want to switch to a database CMS, but the ability to categorize by tags tops the list.

On the other hand, there's something to be said as a writer for the flat-file approach. It has an immediacy to it that a database layer can't duplicate. I don't have to sign into an admin page, visit the "create post" section, type my code into one of those text-mangling rich editing forms, select "publish," and then watch it validate and republish the whole blog. I just open a text editor and start typing, and when I save it somewhere, it's live. Working this way is great for eliminating distractions and obstacles. There's no abstraction between what my fingers and the end product.

And while working via individual files is probably less safe or reliable compared to a SQL store, it benefits from easy hackability. I don't have to understand the CMS schema to fix anything that goes wrong, or add new features, or make wide changes. If I decided to change where my linked images are located tomorrow, I'd have all the power of UNIX's text-obsessed command line at my fingertips for propagating those changes. For an organization, that'd be insane. But it works pretty well as long as it's just me tinkering around on the server in my spare time.

Blosxom also ended up being a pretty decent content framework when I recoded my portfolio earlier this year as a single-page JQuery interactive. I tweaked a couple of themes, added a client URL parameter and a teaser plugin, and within a day had it serving up the desired HTML snippets in response to my AJAX calls, while still providing a low-fidelity version for JavaScript-disabled browsers. I'm sure you could do the same kind of thing with a serious CMS like Drupal or Django, but I don't know that I could have done it as quickly or simply.

I don't recommend that anyone else try running a web page this way. But as a learning experience, writing your own tiny server framework serves pretty well. It's a good challenge that covers the broadest parts of Internet programming--file access, data structures, sorting, filtering, caching, HTTP requests, and output. And hey, it works for me. Maybe it'll work for you too.

I woke up this morning to hear that Robert Byrd had died, and that I needed to fix the timeline we had made of his life. As I logged into the VPN, the screen went oddly pink and blue, like Doom's old Hall of Mirrors effect if you cheated your way out of a valid sector. Then it went black, and then it refused to boot to anything but an external monitor in Psychedelic Snow VGA Mode. The video card, it would seem, is fried. Luckily, I'm just barely within the three-year extended service plan (good until August!), so Lenovo is sending a box and will fix it for no extra cost. But I'll be without hardware for probably three to five days.

I've been on a vaguely weekly schedule here for a while now, so I figure going quite for another week won't shock anyone too much. I had planned, starting today or tomorrow, to write my one-year look back at b-boying, but it looks like that will have to wait. I'll also have to hold off on playing through more of Planescape: Torment, which is too bad since it was just starting to get pretty good, and I'm looking forward to rambling a little on its relationship with death and meta-gaming when I get a chance. And finally, I hope I've gotten the database bugs straightened out on NPR's client now, because it'll be a lot harder to debug and fix them on my lunch hour at work. Still, it's not all bad: forced breaks like this are no doubt good for my tendonitis, and maybe it'll give me some extra incentive to drill footwork for Crafty Bastards if the heat lets up. Here's to a productive week, and a speedy return of my soon-to-be-repaired Thinkpad.

Happy holidays! Between festivities and the blizzard, it's been almost two weeks since I wrote here, but posting has been slow for several months anyway. The main reason is that I've been increasingly busy at CQ as the new Multimedia Team Leader since the end of November. As such, I'm responsible for directing the team's choice of technology, projects, and long-term strategy. It's a nice step forward for me professionally, but it eats up a lot of time and mindshare that might have normally gone into blogging.

I don't believe, as many journalism-watchers do, that print is dead. On the contrary, I think it's possible to argue that print retains an audience capable of supporting newspapers, just not at the same elevated level of profit that was once routine for the industry. But as someone who self-identifies as a "new media" journalist, my primary focus is the organizational transition toward a print-online hybrid journalism, with the eventual goal of moving entirely online as print inevitably becomes untenable. The Multimedia Team Leader is an opportunity for me to more directly play a role in that process, one that I'm sure will prove both frustrating and exciting in turn.

As for Mile Zero, rather than beating myself up over the frequency of updates, I'm going to a more relaxed schedule--slightly meatier posts once or twice a week, hopefully. I'm also going to try tweaking the subject matter a bit--I feel like it's gotten a bit review-ish lately, and that's not a place I really want to be. Anyway, pardon the digression, and thanks for reading. Here's to 2010!

Gone to San Francisco. Back next week.

When I only had 30 entries on Blosxom, this blog ran great. Over the last five years, however, I've written almost 2,000 posts, and the original Perl script has started to bog down a bit. Adding an plugin to cache the filesystem helped some, but it still takes a little more than 2 seconds to render the page. I think it has something to do with the Perl interpreter--there's some discussion online about how Blosxom doesn't like running under Apache's mod_perl, or something like that. As far as I'm concerned, Apache is a practical joke played on DYI-types by malicious shell coders, so I can't really be bothered to find out.

Long story short, last night I rewrote Blosxom as a PHP script. That sounds really hardcore, until you realize that A) it's only 16KB to begin with, and B) I took out all the features I don't use, like static rendering and complete plugin support (mine only supports entry and document processing plugins). It's running now at index.php instead of the old index.cgi, and I've redirected the domain default. I'll be leaving the old Perl script in place so that legacy links will continue to function, but anything that didn't specify an index script should now benefit from the speed boost.

If you're reading this via Google Reader, you probably don't need to do anything--Google doesn't care how slow my server is. On other RSS readers, you may notice a faster refresh and more accurate post times by switching to the new feed. And if you read via the actual page (or link to it) at the .cgi URL, you'll notice a real difference by switching to the new URL--it's about an order of magnitude faster, going from ~3 seconds to ~300ms in my tests, even without optimizations.

The worst ways people found Mile Zero this month:

• time gentlemen please zombie cow torrent: Listen, it's a five-dollar game. You should be ashamed.
• benefits of working at the world bank experience for those who have worked there: Hey, a serious query! As an American, for me the benefits were twofold: they paid well, and the institution is relatively diverse, which I found fascinating. You get to meet a lot of new and interesting people. On the other hand, you will become acquainted with a lot of very tedious tax paperwork.
• jerry jenkins writing ability: Nope.
• assume that your system is being dos attacked right now. what are the various steps that you will take to counter the attack?: Well, first I'd laugh. Then I'd cry. Then I would call someone who knew what they were doing.
• precious you ever conceived of: It puts the lotion in the basket...
• critique: Literally the entire search term. Zen, really.
• baltar graphic groovebox: Gives you a basic beat, then betrays you to the Cylons.
• animal crossing rooms: Not actually about the game. They're trying to train their pets to go from one side of the house to another.
• how much does it cost to fix line six delay switch?: In my case, it's $50 for the pedal, $2 for gas to drive to the closest authorized repair shop, and $400 to buy a different pedal when the DL-4 breaks again.

Better luck next month, Internet.

Last week, I got a phone call from someone who had worked for one of the outlets where I've been published. Their name was listed in my copy of the article at thomaswilburn.net, and they asked if I could take it out in the interests of trimming their online presence a bit--I guess they didn't want to be associated with the publication anymore. I can certainly sympathize with that feeling, and was more than happy to help.

It was an interesting coincidence, though, because I've been thinking more about my own Internet shadow lately. I write here, and maintain a portfolio elsewhere, under my real name. This has advantages, and it also has disadvantages. At the very least, it can be surprising: the now-unnamed correspondent was able to contact me at my (unlisted) work number because I list my current place of employment on the portfolio (and also likely because I don't provide an e-mail address there, which I should probably fix). Like it or not, I can be easily located online, which ties my realspace identity to all the writing I've done here. And while I consider that a net positive (pardon the pun), it should still give any reasonable person pause.

Or to put it another way, when I meet someone who says "Oh, I've read your stuff," my first impulse shouldn't be to wonder if I've advocated a coup or something similarly inflammatory lately.

The obvious solution is to try not to write stupid posts, and I'm working on that (it's one reason that I suspect entries here have become both less lengthier and less frequent). But at the same time, over the last week or two, I've gone back through the archives here and spiked quite a few entries. They're not permanently deleted, but they are unpublished. A post may have been spiked for any number of reasons, including:

• It wasn't very well-written.
• I don't agree with what I wrote there anymore.
• It didn't contribute any interesting content to the blog (delay/maintenance notices, joke posts, now-invalid links, etc).
• It may contradict the policies of my full-time employer (most of the politics category is gone for this reason).

In my experience, this is an unpopular action for a blogger to take, and I'm not entirely comfortable with it myself. That said, I believe it's necessary and prudent. While it's a nice idea for the "arc" of the blog to follow my viewpoints and development as a writer and a person, the fact is that very few people will ever read it that way. More likely, any entry needs to be something that I can support professionally, regardless of the publication date, since it may be encountered without context or supporting posts.

It should also be stressed that this is hardly the first time my archives have been reshuffled and restructured, although it is the first time it has happened intentionally. Over a period of four years, the process of changing hosts, tweaking Blosxom and its plugins, and server outages means that any website will undergo some level of "memory loss," and Mile Zero is no different. This time, it's simply editorially-directed--and for most of the cuts, I suspect, the posts won't be missed.

In any case, while I've already conducted this surgery on the archives, I'm announcing it here in the interests of full disclosure. If something you found valuable has been pulled, or you believe that a particular post should have been retained, please feel free to send me a note via the mail link on the right, and we'll see if we can work something out.

Although I reserve the right to change plans at any time, both writing and commenting will probably be thin this week. I'm trying cut down on the amount of extra typing at the moment, as well as temporarily giving up use of the XBox and my musical equipment, since I've been feeling the twinges that herald the return of repetitive stress injury. As a writer, coder, bassist, and gamer, RSI is something that I've come to know fairly well. And after working with sufferers in a data-input center, I have no desire to aggravate my symptoms. I'd urge anyone here who suspects that they might be in a similar situation to be very, very careful: you only get one set of hands, after all.

Like I said, at the moment my recovery strategy consists of avoiding activities which aggravate my joints whenever possible. I also habitually use a trackball at work, which I find is slightly easier on my wrists, and I'm trying to take advantage of Vista's voice command app to do my computing at home. Feel free to suggest other helpful measures in the comments.

Update: Hands and wrists still hurting. Picked up an ergonomic mouse, made a doctor's appointment on Thursday, still trying to stay away from keyboards/basses/video games, but unable to avoid work at this time. Actually kind of enjoying the lack of blogging, although that won't last.