Switching to Vim

A few months ago, I stopped using TextMate as my primary code editor in favour of Vim (specifically, MacVim). I first encountered Vim as a Linux-curious high-schooler, and had been averse to it ever since. The requirement to press i before inserting text seemed ludicrous to me. To navigate with hjkl instead of the arrow keys was like a masochistic exercise in self-deprivation. Like most of my generation, I learned the Microsoft Word/Notepad style of text editing, which is totally incompatible with how one uses Vim. On the rare occasion that I felt brave enough to use Vim, I’d make lots of mistakes, and I’d usually give up and use nano instead.


But in 2011, there was a tide of positivity about Vim, and I couldn’t ignore it. It was Vim’s 20th birthday, and there were lots of articles online about how productive it made its users and how rewarding it was to learn. My friends George and Nick would tweet about how they’d tweak their Vim setups for maximum efficacy, and my geek pride was dented somewhat by my inability to take part in their discussion. I watched people code in Vim, and not only had they overcome the learning curve, they were moving with incredible speed. The biggest factor for me, though, was that TextMate seemed to be stuck in a rut. There hadn’t been any major changes or improvements to it, and there was no indication of when TextMate 2 would come out (of course, TextMate 2 Alpha was released in December, but by then I had already switched to Vim). The time seemed right to give Vim another chance.

The switch

As expected, my first couple days in Vim were not hugely successful. It’s difficult to unlearn years of editing text the “usual” way. The most important insight I’ve had since I switched is that I spend most of my time as a coder editing code, not inserting code. Viewed in this light, Vim’s distinction between insert mode and normal mode makes lots of sense. Vim’s major advantage over other editors is the speed with which I can move around and manipulate code, even if I’m no faster at inserting new code. If you’re starting out, I’d recommend you get comfortable with b, e, and w first, as well as the hjkl home keys. Once you’re moving around without having to think about your keypresses, start referring to the cheatsheets at the bottom of this page. You’ll be a Vim guru in no time!


If you’re curious about Vim, there is a wealth of resources that’ll get you started. I use Janus, a distribution of common plugins that provide many of the comforts of TextMate. Not everybody thinks Janus is a good idea, but I like it and am sticking with it for now. It’s worth printing out a couple cheatsheets: this one and this one are my favourites. This post about Vim Text Objects is a goldmine of information. One of the most inspirational articles I read was Staying the hell out of insert mode, which really emphasized for me how great normal mode is and has done a lot to inform my overall philosophy on Vim.

If you’re curious to see how my Vim is setup, my personal dotfiles can be found on my GitHub.

In conclusion

I think switching to Vim is one of the best development decisions I’ve made recently. It enables me to work much faster than I could previously, and I’m proud that I can edit files in the terminal without resorting to lesser editors. If you’re curious about Vim, I’d strongly recommend trying it out. It’s definitely a little painful at first, but you’ll be surprised at how much more effective you become.

Red Dirt JS

Red Dirt JS

On November 3rd I attended the Red Dirt JS conference in Oklahoma City, where I gave a presentation about the Underscore.js library. I was nervous that my talk might not be very novel - most JavaScript developers I know are already big fans of Underscore - but it turned out that most attendees had never used it. If just one attendee ends up less frustrated with JavaScript collections as a result of my talk, I’ll consider myself successful!

The other talks were great. To name a few, Nathan Smith gave a very entertaining history of the Web thus far, fellow Waco resident Derick Bailey presented on Backbone, and JD Dalton introduced Benchmark.js. Brandon Satrom’s talk on CoffeeScript was exceptionally interesting, even with it being prerecorded - I hope in the future I’ll get to hear him in person.

My slide deck is online here. This was my first ever conference presentation, so I’m very grateful to the organizers for giving me the opportunity and the audience for being so gracious with their attention. Looking forward to next time!

Migrating to Jekyll

As of 29 August 2011, I’ve migrated my blog from a self-hosted WordPress installation to (at the time of writing) 35 static HTML files hosted on Amazon S3. These HTML files are generated on my computer by Jekyll and uploaded using Transmit, in which I press a button and all my posts are synchronized to the cloud.

This is much lower-tech than a blog on a content management system, and wouldn’t work for most people. Indeed, the first time I heard about Jekyll I dismissed it as being too basic. After all, why would I forgo all the features of a CMS for the sake of some boring HTML files?

I decided to make the switch two weeks ago. I was struggling to write a post about Google App Engine’s free tier when I realized that WordPress’s bulk was slowing me down. I don’t need plugins, or TinyMCE, or multiple users, or post types: I just want to write about technical things that I think are interesting. I’d recently decided that I wanted to write in Markdown, which Jekyll enables by default. I found the official migration documentation, noticed that migrating to Jekyll looked very straightforward, and started building my new blog.

I found moving from WordPress to Jekyll very easy. I followed this migration guide and imported all my old posts into Markdown, which after you learn the format is much better for blogging than HTML. I wrote a new theme using the Liquid templating language (there are many example themes you can crib from here), and styled it primarily from the Twitter Bootstrap CSS framework. I put the site on S3 by following Amazon’s guide, and the payoff was immediate: as you can see below, the site’s response time has more than halved.

Blog Speed

I’m really glad I’ve switched my blog to Jekyll. There’s less code to maintain, greater flexibility, fewer distractions, and now that my setup is simpler, I feel like my writing has improved. I’d recommend Jekyll to any technical blogger who’s tired of their bloated CMS and who wants to write more efficiently and enjoyably.

The Limits of "Free" on Google App Engine

Update: Just my luck - I write 99% of a blog post about how I got around the limitations of Google App Engine’s free tier, and then I get an email announcing how Google will drastically change their price structure not in my favour. Looks like I’m not done trying to outsmart Google’s billing department…

Google App Engine’s free tier is great for small apps, but as I discovered when Twitty City reached a gigabyte of storage, its limitations can be extremely frustrating.

Twitty City ran well for its first few months, but after 400,000 tweets its datastore was full and needed to be cleaned up. Unlike the typical MySQL/PHP setup, GAE does not give the user the ability to delete from the datastore with SQL commands: data must be obtained programmatically. The only way to delete several rows is to select them in your program’s code, iterate over them, and delete them individually. This would be tolerable, except for three factors:

  1. It’s not possible to delete more than 1000 rows at once.
  2. Deleting rows is very CPU intensive: to delete 1000 rows at once consumes two minutes of the 6.5 CPU hours a free app is allowed in a day.
  3. There is no programatic way to see how much of your CPU quota remains, so you can’t automate a deletion task without the risk of depleting your CPU.

I reasoned that, if deleting 1000 rows used two minutes of my daily 6.5 CPU hours, I could run my ‘TidyUpHandler’ every eight minutes and not take my app offine. After many hours of gradual purging, the stale data was cleared and Twitty City was brought within disk and CPU quota. The TidyUpHandler still runs every eight minutes, and as a result storage is now stable at around 12% of capacity.

If you aren’t constantly maintaining your data, GAE is quite unforgiving. A gigabyte of free storage is unparalleled in web app hosting, but if your app’s datastore grows quickly by itself you need to take measures to ensure it won’t get out of hand, and you need to do so before you’re near quota.

(Or, you could just pay for extra storage/CPU, but where’s the fun in that?)