I am delighted to let you spread the word about an amazing innovation from Lian Li, the acclaimed maker of computer cases. They have thrown caution to the wind and finally introduced the thing we've all been waiting for - the Choo Choo Train Computer Case.

Yes. Yes. Let that sink in. It's a computer case shaped like an old steam-powered locomotive. It has a 300 watt power supply in the front section, and the cart can fit a Mini ITX motherboard, a slim optical drive, and a single internal hard drive. One might point out that these are somewhat weak specs as far as cases go, but hey, IT'S A FUCKING TRAIN.

But wait. There's more. No, seriously, there's more.

I saw that the case had 5 star revies, so I clicked to see what proud owners had to say about it.

This SKU, which ends in an S, does NOT move compared to the more expensive SKU that ends in an L. It has no motor, it's just a case that looks like a train. The more expensive model [...] actually has a motor and a transmission, and comes with extra rails, so it will roll back and forth when the computer is turned on.

Yup. Lian Li's product page for this puppy is epic Not only is there a more expensive version that moves (and comes with "Rail x6" instead of "Rail x1"), there's a limited edition one that has an atomizer. That's right. It makes steam!

Basically, I'm spent just thinking about this. The amount of space accommodated by the case isn't ideal for the plans I have for an HTPC (I was on Newegg for a reason, afterall), and I definitely couldn't handle "Rail x6" and a computer case scooting back and forth, but y'all know what to get me for my birthday now. I'll make it work.

Unfortunately, it's out of stock on NewEgg and I can't find it for sale anywhere, so I fear that the opportunity may have passed. Who knows when Lian Li will elect to share their genius with us again? I'll probably end up having to purchase one of these guys on Ebay for thousands of dollars as a collectors item years from now.

Back in the days of fire fighting and database optimizing at Flickr, when I could debate the merits of different MVCC options comfortably, I built a little tool called Ishmael to help us make sense of mk-query-digest data more easily (apparently, the project has been moved to the "Percona Toolit" and renamed pt-query-digest). Tim Denike made some improvements during his remaining time at Flickr after I had left, and then Asher Feldman took the project with him to The Wikimedia Foundation. Eventually, he sent in a large enough pull request that I simply did not have the capacity to test it - I, after all, have not used MySQL in anger in ages. So I did the natural thing and made Asher a collaborator on the repo.

This past week, during a moment of vanity, I noticed that there were quite a few more stars on the repo than there had been. I wondered what might have caused it, and shrugged. Then on Sunday the DevOps Weekly email provided the answer: Asher had written a post about MariaDB on Wikimedia's blog, in which he mentions their use of Ishmael in comparing performance between old and new database versions. It is a good read for anyone interested in database migrations and upgrades, especially "doing it live!"

Everyone, look, this is my "proud open source moment" face.

Programmers have been lamenting each others' inability to properly document software for many decades. Some recent examples include:

• Tom Preston Werner's call for README-driven development

  a beautifully crafted library with no documentation is also damn near worthless.

• Ted Nyman's recent Basho Chats diatribe about software expressing itself poorly (video not yet uploaded)
• Peter Morgan's eloquent Go issue report

  Is that all we want to do is explain bits of code, and its runningz what it does.. Hopefully there is a lot of coders looking at it cos we can auto gen documentation..

Powerful stuff. There's been a corresponding surge in tools to assist in creating documentation. Some examples:

• Eric Holscher et al's Read The Docs
• Ryan Tomayko's ronn

Still I see repositories with READMEs like "Gathers and relays system metrics" (not to pick on anyone in particular, just an example) and ones that skip straight to installation instructions and licensing info. That's bad.

The README is a project's face to the world. It should tell the audience what the project does and what motivated its creation at a minimum. Not to belabor the already-well-made point too much further, I've created a tool for myself and others to help formulate a basic README when inspiration betrays us.

It's called readmeme - and yet again, Richard Crowley helped me name it. It is apt. I hope it starts a meme of informative READMEs.

For more info on the project, check it's README (get it?)

There are many mistakes people make when programming for the web. Here are three that I've seen everywhere I've worked. I think they deserve extra attention because they are relatively easy to avoid, but very difficult to recover from.

Encodings

Even if you only ever have US based users, enough folks have accents in their names and all sorts of other reasons to introduce non-ascii characters into your systems. Enforce UTF-8 at all levels, and especially at storage time. Fixing an encoding issue is difficult, and usually involves re-writing all the data. It is unpleasant, no matter the underlying datastore.

Limits and Pagination on API Requests

This is pretty straight-forward, but I've seen it neglected in practice quite a few times. Whether it's a POST where the bath size isn't bounded or a GET that returns "all the _____," it inevitably becomes a nightmare that is difficult to fix due to clients not expecting to have to paginate. This is particularly exacerbated in APIs used by mobile apps - a total fix requires getting all the client apps to upgrade to a new version of the library AND for all their users to upgrade.

Timezones

This issue is similar to the encoding one - a matter of consistency. Storing everythign at UTC forces consistency on the data. Not doing so leaves an opening for rows in the same table to be written with different time zones, making querying and comparisons more complicated and possibly expensive. Almost without exception, you only want to think about timezones at display or query time; it's much easier to deal with DST when your data is normalized to the same, consistent, season-immune representation.

Cal's book has a lot of really good info on other details that merit attention when working on the Internets.

It is becoming increasingly plausible that I have a partially torn miniscus in my left knee. The unusual, difficult to place pain, the occasional painful popping and "catching" in the joint, the frequent unprompted discomfort.. I run into people on a regular basis playing soccer - any number of recent collisions could damage a ligament.

But the ligament is not the issue.

The issue is the reluctance to call it what it is - the orthopedic sugeon dictated "possible meniscus irregularity" into his recorder. The physical therapist opted for the cautious "possibility of some miniscus involvement." Having already been primed, I pressed a bit: "A torn miniscus, you mean?" "Yes, a partial tear."

Come on guys, I'm not going to die of a torn miniscus. The upper bound on recovery from a miniscus repair is 4 months, and I'm 26 - it would likely take less than that. Surely they don't expect me to break down crying right there in the office when confronted with the news..

Why am I writing about this harmless, albeit frustrating, experience? I do have a reason: it reminded me of a great piece The Economist ran on the subject of "euphemisms" last December. It is particularly relevant in the current political climate, especially the very last section titled "Little white lies."

The piece ends with a call to abandon euphemisms for a day. I highly recommend this exercise, having lived it long before this article was published. You'll piss some people off, but at least they (and you) will know where you stand.

As I exited the Civic Center metro stop on this beautiful sunny morning, I glanced up Hyde street. There was no 19 bus to be seen up the street, which meant it was at least 5 minutes away. At best, it would make it to my destination at 8th and Bryant around the same time as I would on foot.

Rounding the corner onto 8th, just past the 19 stop, I came upon 20 to 30 people, mostly men, mostly in their mid 20s, lined up against a fence. Nobody was talking, everybody had headphones on, some were smoking. They were waiting for the Xynga shuttle to take them to their office 6 blocks away, about 2/3 of a mile down 8th street. 15 minutes by foot, 5 by bike.

At their feet started a freshly painted bikelane, possibly the widest in the city.

Somewhere far away, in an empty bar completely unaware of the human tragedy unfolding at 8th and Market, the jukebox played "Don't Know What You Got Till It's Gone."

While discussing what to do for a Free Friday project, Neil and I decided we want to build some sort of visualization related to the location data UA had been processing. I quickly thought of the dashboard that Jon Rohan wrote for SimpleGeo, which would plot the coordinates that API requests were targetted at as those requests came in. After finding Jon's code, I realized that the front end portion was going to be very easy to adopt, as well as make generic. Having obtained Jon's blessing, I tidied the code up a bit and open-sourced it. Of course, the backend code that supplies our geo data will remain closed source and proprietary, but there is an example data source included to help others get started.

I called the project Windshield because the points look like bugs that show up on the glass over the course of a long drive. The source is here. I have an example up here.

I could make this a wordy post about programming practices, javascript, and technology, but this was a really simple project. Besides, other people did most of the hard work:

• PolyMaps did all the map parts of it.
• CloudMade made the gorgeous tiles.
• Jon Rohan wrote the code I aped heavy-handedly to get a grip on the thing.
• I made the function that supplies the points pluggable so that it was easy to test and extend, so HURRAY for higher order functions.

Probably the most surprising thing was Aaron submitting a pull request hours after I had open sourced the damn thing to make the demo work correclty in FireFox. Thanks, Aaron!

Things I know I still need to do:

• Make it easier to manipulate the map once it's created (perhaps return something from the windshield function)
• Explore the concept of a PolyMaps "layer"
  • Can I create a custom layer for my points and use the DOM element for that layer to more efficeintly prune points over time? The present implementation of selecting all circle tags, then removing the parent of their parent of their parent brings the browser to its knees
• Remove points over time in a FIFO arrangement? Would require quite a bit more javascript than I presently have appetite for, but who knows...

Highly relevant:

Conference talks on the subject of infrastructure are often lacking in actionable advice - especially for fledgling startups. I am shamefully guilty of this myself.

A notable exception is a recent talk by Paul Hammond, my old manager and good friend. His Velocity 2012 talk titled "Infrastructure for Startups" was a refreshing dose of pragmatism, drawn from the experience of building and growing TypeKit. Paul ran Flickr Engineering before that - he has street cred for weeks. Unfortunately, video of the talk does not appear to be available, though that may change soon according to Paul.

Though I am prone to lengthy rants about building things the "right" way and am often heard advocating more rigorous planning at the start, I can't agree more with most of what Paul says - a 2-3 person startup just doesn't have the time to be mucking around with anything but the product they're building. This being 2012, there is an army of service providers ready to share the burden - for much less than the opportunity cost of building everything yourself.

Don't forget to measure

I'd add one more thing to Paul's lists (here and here) - you need good graphs right away. I'm surprised Paul didn't mention this after "all performance problems have been on things we don't yet measure." Good metrics collection and display are critical to both business success and technical efficiency. The easier it is to put together dashboards that zero in on meaningful metrics and correlations, the more you'll do it, and the more quickly you'll identify inefficiencies and opportunities.

I've yet to hear a favorable review of the baked in ec2 monitoring tools (CloudWatch), so I, as usual, recommend the slick, easy to use, gorgeous Librato Metrics for these purposes. As a bonus, the product comes with some basic alerting features (haven't tried yet, in the interest of honesty), so it may help stall or obviate the need to set up nagios or one of the related monsters. All the tools for getting data in have already been written.

Speaking of alerts, PagerDuty is another no-brainer for small teams starting to set up more fine-grained monitoring. Big surprise: Librato has PagerDuty integration.

I had some experience with the competing Cloudkick product and sadly don't have many kind words, although much has probably changed since our last interaction.

I'm tired of Wordpress and the associated bullshit (upgrades, vulnerabilities, etc), so I'm finally ripping the bandaid off and moving my blog to a Jekyll-generated static site hosted on s3. I will not be migrating the old content, as that would be an epic pain in the ass, the benefits of which do not seem substantial to me. The old site will live on, its database and directories set to read-only mode, to serve what little google traffic still washes up there.

ONWARDS!