I'm thrilled that Make magazine has featured our 2003 senior design project, the Pipe Crawler, on its blog. I thank Sean Ragan for taking an interest and for writing the post; visitors from Make are very welcome indeed. I've taken this as prompting to update the site a bit; prior readers may notice that I've added links to an RSS feed of this blog; please subscribe if you're so inclined. Using my new and very precariously assembled light tent (details of which are for a later post); I've also updated some of the photos of the pipe crawler; and finally, I've restored the link to the original paper my team gave to our professors at the end of the class, although I cringe to read it today—hopefully I've learned a thing or two in the years since!

I occasionally post samples of source code in a handful of languages on this site; to present these in the most readable form I started looking for client-side syntax highlighting scripts, always with an eye towards matching the behavior of emacs and its major modes. I made attempts with the most popular choices in this area, but was disappointed with them for various reasons:

• google-code-prettify did not highlight C correctly; it marked types (char, for example) as keywords sometimes, and it's not actually hosted on the google CDN, which I would think is one of the major reasons to use a google project for something like this.
• highlight.js relies on a mysterious process of automatically "detecting" the language used in a particular code block, which failed in my test case when it mismarked C as perl. Despite that, it comes with some nice color themes and, unlike google-code-prettify, is hosted externally, although I would be more comfortable if it was hosted on a major CDN like google's.
• SyntaxHighlighter has extensive language support and uses an autoloader to load only the scripts necessary for highlighting the languages contained in the current page, a significant point in its favor. However, the html produced by this script is heavy with non-semantic <div>'s (one for each line!) and wraps every highlighted token in its own <code> tags. I prefer client-side scripts not to throw semantics out the window when possible; one <span> with appropriate class names for each token should be sufficient.

But just as I was about to turn away from this project and put syntax highlighting on the shelf for awhile, I found another script: Rainbow, by Craig Campbell. This library makes heavy use of regular expressions, which I'm fond of, and seems to have been designed from the beginning for ease of extensibility. It's also hosted on GitHub, and I've already taken advantage of that to make some small contributions to the project. Rainbow is relatively young and doesn't support very many languages as yet, it's true, but this script is so easy to extend that I don't anticipate that will be much of a problem—I'll probably just write a new mode myself if I need one.

I've meant to make and share more videos for some time now, ever since my first smartphone brought with it a decent video camera, in fact. This has meant diving deeply into technical subjects I had previously neglected, wrestling with various open-source video editors, and, of course, updating my blog theme so that I could properly embed YouTube iframes into posts. This last turned out to be surprisingly difficult.

I had the pleasure this weekend of seeing the only presently flying example of the B-29 Superfortess, a salvaged plane named “Fifi” that was restored and is kept airworthy by the fine people of the Commerative Air Force. A recently restored P-51D Mustang, “The Brat III” was also on display, and the public could even fly in both planes. I couldn't afford that ($570 to $1395 for the B-29, depending on the seat, $1995 for the P-51) but was very happy taking a tour through the bomb-bay and cockpit.

By the way, I only became aware of Fifi's visit to Fort Lauderdale Executive Airport because I happened to be overflown at low altitude by it, heard a somewhat remarkable noise, and was surprised to find a B-29 overhead. A little google-searching revealed what was going on this week. Either the CAF might want to try to get the word out more effectively, or I need to be more plugged into the local aviation and warbird community, if such exists. Any suggestions to that end will be appreciated.

Be liberal in what you accept, and conservative in what you send.

—Postel's Prescription, by Jon Postel

I have a day job as a hardware engineer for a telecommunications company, and in this capacity I'm often designing equipment to be installed in phone company Central Offices (COs). Unlike the designers of consumer electronics or data center hardware, I can rely on having DC available to power my devices; COs have “rectifier plants” that convert mains AC to 48-volt DC and distribute this power through the facility with giant copper or aluminum busbars over the racks.

Most CO equipment uses two-pin Phoenix-style connectors as power inlets. These come with a pluggable terminal block with screw-down style connectors that accept bare wire from the rack's fuse and power distribution panel. Because installers wire this plug on site and mistakes are easy to make, it's good sense (and company policy) for the hardware designer to put a bridge rectifier across the input leads so that this connection can be insensitive to polarity.

This is an application of the first part of Postel's Prescription, “be liberal in what you accept”, to power engineering. If the second part, “conservative in what you send”, has an analogue in this field, it could be this: make sure your power outputs, if any, have clearly defined polarity. Another possible analogue would be: keep the output to a tighter voltage range than the telecom standard 36-72 volts.