Datasheets for electronic components frequently present maximum ratings and other such specifications in the form of lists where a label, “Operating Temperature Range” for example, is separated from a value, say “-55 to 125 C”, by a dot leader, or row of dots intended to make it obvious which value belongs to which label. Maxim Integrated does this (page two), as does Microchip (page three), among many others. Here's a way to implement it in LaTeX.

I recently rewrote my professional résumé. In accordance with received wisdom I was always careful to limit the story of my working life to a single page, but I've heard too much lately about how this restriction is out-of-date and likely to shortchange an applicant; in my case I had to describe the positions I've held very thinly and leave out some of my minor honors altogether. Some of the layout compromises I was forced to make never sat quite well with me either.

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.

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.

As a way of trying out github for myself I uploaded a small script that iteratively solves the Colebrook equation for the Darcy-Weisbach friction factor, which can be used to estimate head loss due to pipe friction; this played a very minor role in my recent MSEE thesis. The script runs in GNU Octave and it certainly should run in Matlab as well, although I haven't tested that.

I recently found myself having to make some php configuration changes which are specific to a particular subdomain on my Mediatemple DV web host, and found that yet another part of subdomain setup is mildly broken out-of-the-box. This is the sort of thing that most people who need it can probably figure out for themselves, but I'm posting the solution hoping someone will find it useful.

On my DV the domain specific apache configuration is located in /var/www/vhosts/domain-name/conf/, where domain-name is of course replaced by your actual domain name. In this directory you should find at least httpd.include, and possibly vhost.conf as well. If you open httpd.include you'll find the following alarming warning at the top: