One of the more problematic legacies of the show's origin is the transporter (another, Star Trek's laughable treatment of economics, should probably get a whole treatise rather than just a blog post, but I'll leave that for another time), which is one of those technologies sometimes posited in science fiction stories that, for various reasons, writers fail to fully explore. One of the most common reasons is that some technologies (or, in the case of superheroes, some powers) are altogether too powerful, and the consequences of that power pose a problem for storytelling; if characters have godlike abilities at their command, what room does that leave for drama, for tension and its relief, for a satisfying plot?

As for the larger project, I'll publish more about that here soon, so keep visiting!

• SimplyNoise is a website with white, pink, and brown noise generators, any of which can be amplitude modulated by a slowly varying sinusoid. I suspect the oscillation prevents my mind from getting too good at filtering the noise out and picking up voices again.
• RainyMood.com offers a recording of a rainstorm with occasional thunder. This audio signal is certainly more structured than the other noise sources I use, but the sound of rain is so natural that it's not usually able to break my concentration.
• My absolute favorite, though, has to be this 24-hour long (!) YouTube video of the ambient engine noise heard on the Enterprise from Star Trek: The Next Generation. I grew up with ST:TNG, and I have to admit there's something very comforting about getting some work done with this particular soundtrack!

For more on the relationship between sensory stimulation and workplace productivity, I recommend Susan Cain's Quiet: The Power of Introverts in a World That Can't Stop Talking, which, among other influences, has lately given teeth to my desire for a quiet and focused workplace.

Since I was going to radically change it anyway, I took the opportunity to implement my new two-page résumé in LaTeX instead of InDesign, partially for geek-cred but also to make it more maintainable: for instance, the plain-text source file works well with revision control tools and now resides in a git respository.

Building my résumé from source also solves an irritating little problem I had with my InDesign workflow: the need to maintain two otherwise-identical *.indd files, one with my personal phone number and email address for sending to recruiters, and one without them for publishing on the Internet. If I changed anything in one, I had to make the same changes in the other, and then make sure to export both to PDF. With LaTeX I can pass command-line arguments to conditional statements to make this easy. For even more geek-cred, I can automate all this using SCons and provide myself with “public” and “private” build targets for the two versions of the document.

Black never goes out of style

This fits into the trend of survival experts and EDC enthusiasts carrying miles of paracord on their persons at all times, usually by tightly weaving it into something like a watch band or key chain. I'm impressed by their techniques but I'm far from being a serious student of wilderness survival—I only sniff around the edges of that community—but I enjoy hiking now and again and I'm very much a fan of preparedness and capability in all aspects of life.

Regular guests, please let me know if anything's broken from the move. Thanks for your attention.

• 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.