One thing that I used to be particularly guilty of was repeatedly hammering j and k rather than performing the mental arithmetic required to use the much shorter 37j. I had the same issues deleting or moving lines where switching into visual mode was quicker than counting lines and using d12d.

Relative line numbers in Vim

Going Relative

Vim now has a setting called relativenumber which acts in a similar way to the number setting. However, rather than calculating line numbers from the top of the file it shows them relative to the line you’re currently on.

I always disable the arrow keys in insert mode, to force myself to use 10j and keep my hands on the home row (plus it’s great for trolling). I prefer to use relative line numbers when in normal mode for ease of movement and absolute line numbers in insert mode. We can set this up with:

Occasionally it’s useful to go to a specific line, such as when fixing failing tests. At first glance using relative line numbers appears to complicate the issue somewhat. But, line movement shortcuts such as <line-number>gg still work.

And it’s that process that is the magic.

I switched to the Nginx/Apache configuration just before the start of June and, thankfully, it appears that the performance increase I noticed has also been observed by others.

Additionally, Google reports that the slowest load time was a shocking 5,572ms with a fastest time of 225ms. Not too shabby from a single 256MB server.

I took a typical approach and installed the WP Super Cache plugin. Page loads dropped down to ~1 second. Much better, but there must be some more performance gains to be found somewhere without modifying the WordPress source code itself.

Inspired by this post by Mark Maunder I decided to see if I could shoehorn WordPress into a similar reverse proxy/persistent process mould. So far, it works brilliantly.

With the following tweaks I managed to go from 12 requests/s to over 30 requests/s on the same hardware – a single 256MB Rackspace Cloud server – whilst reducing latency from ~2 seconds to an average of only 0.4 seconds.

Step 1. Configure Apache

You’ve really got to be running Apache with mod_php. Even if you stop reading here you’ll still find that your server performs better. In order to allow more requests to be handled by Apache, disable Keepalive connections.

You’ll find at this point that your requests will slow down a bit as clients will have to create a new connection for every request. You will, however, be able to handle many more requests as you will no longer have clients with slow connections tying up processes. We’re going to rectify this slow down in the next step.

It is also important to change the IP address that Apache listens on to 127.0.0.1 so that it can only be accessed from the local machine. Additionally, you will need to change the port from the default port 80 to, for example, port 81. This is because Nginx will need to run on port 80.

Step 2. Configure Nginx as a Reverse Proxy

Nginx is a “high performance web server and a reverse proxy server” that’s capable of handling thousands of concurrent users whilst occupying only a few megabytes of memory.

To install Nginx on Debian/Ubuntu distributions it’s as simple as:

Initially we’re just going to create an Nginx virtual host that acts as a reverse proxy to our persistent Apache processes. If you have never worked with Nginx before this may sound a little daunting so I’ve copied the important parts of my conf file below:

Because we’re running WordPress behind a proxy it’s important that we forward information such as the website host name and the client IP address. By adding proxy_set_header Host $host we can make the reverse proxy completely transparent. We’ll make use of the X-Forwarded-For header later.

Unfortunately, if you omit the proxy_set_header Host line you will no longer be able to log into your WordPress installation and any internal links may cease to work.

At this point you want to enable Keepalive requests on Nginx and crank their timeout to as high as you dare. This will offset the slow down you experienced by turning off Keepalive requests on Apache.

The beauty of this setup means that the time Apache now takes to handle a request is due solely to the amount of CPU time it takes to actually handle the request – there’s zero latency from a loopback request.

Child processes are now no longer tied up by clients with slow connections meaning that each child can process many more requests per second. It’s therefore possible to handle a huge amount of traffic without having to increase the number of processes and RAM.

Step 3. Configure WordPress

There are a few modules in WordPress (mostly based around the comment system and plugins such as Akismet) that use the client remote IP address. Unfortunately, with our current configuration $_SERVER['REMOTE_ADDR'] will always return 127.0.0.1.

In order to fix this we just need to set $_SERVER['REMOTE_ADDR'] to the value of the X-Forwarded-For header that we set in our Nginx config. You can do this by adding the following code to the top of your wp-config.php.

Why wp-config.php? It’s because it’s one of the only files that isn’t effected by WordPress updates. Deploy your wp-config.php to your server, sit back and enjoy your new speedy WordPress blog.

Tl;dr:

• Install mod_php
• Disable Apache Keepalive connections
• Make Apache listen on 127.0.0.1:81
• Install Nginx
• Configure Nginx as a reverse proxy to Apache
• Update wp-config.php to work with our new setup
• Epic win

Spotio is optimised for use in a modern WebKit browser (such as Google Chrome and Mobile Safari). As such it’s possible for multiple people using multiple devices to control the playback of a Spotify playlist with realtime feedback.

The need for a Spotify remote with multi-user support reared it’s head whilst working at the office. Spotify is an excellent tool for allowing many people to collaborate on a playlist, but actually controlling what’s played is an area that hasn’t been fully explored yet.

As such, the office is now using a Mac Mini as a dedicated jukebox with our copy of Spotify running on it. This is in turn driving a 5.1 surround sound setup (courtesy of Adam Rhoades) with a central volume control. The final piece of the jigsaw is Spotio – this is installed as an application shortcut on everyone’s PC and iPhone allowing full control of the playlist as long as they’re connected to the office network.

Despite the fact that Spotio is far from finished, I’ve decided to start promoting it so that people can start playing with it, finding bugs and adding features.

Documentation is non-existent (unless you count a readme as documentation) but there isn’t really that much code so it shouldn’t take too much time to rectify matters (in theory).

How It Works

There are two distinct parts to Spotio. First there is the SIMBL bundle that provides us with a very simple API that can be used to control Spotify remotely. Ideally there should only be one connection to the API so that we minimise our impact on the Spotify process. Part two is little more than a proxy server written in Node.js and CoffeeScript that can easily scale to thousands of clients on one server.

The two parts are completely independent, however it’s important to realise that the SIMBL bundle can be used without Node but not vice-versa.

Requirements

• Mac OS X 10.6 – 10.5 might work, but it will never be officially supported
• SIMBL
• Node
• Npm for CoffeeScript support

If you want to compile Spotio from source you will also need:

• Git VCS
• Xcode 4
• Rake

Installation

First, make sure you’ve installed the various dependencies. You can then download the latest copy of the Spotio SIMBL bundle and Node server from GitHub. You will then need to move the Spotio bundle into your ~/Library/Application Support/SIMBL/Plugins directory for a single user installation or /Library/Application Support/SIMBL/Plugins for all users.

Alternatively, if you like living on the edge, you can build the latest version of Spotio from source:

Rake will spit out the build results and then copy the compiled bundle into ~/Library/Application Support/SIMBL/Plugins.

Once you have installed Spotio you will need to restart Spotify for changes to take effect.

Usage

1. Start Spotify
2. Open the Spotio Node directory in Finder
3. Open a terminal (/Applications/Utilities/Terminal), type coffee and drag server.coffee into the terminal window. Hit enter.
4. Open 127.0.0.1:8080 (change this IP address for the one on your computer) in Chrome (or another WebKit browser).

By default Spotio binds to all available IP addresses on port 8080. It’s fully compatible with DNS.

Contributing

This project was created as a way for me to learn Node/CoffeeScript and Objective-C. Without doubt things can be improved, so if you would like to lend a hand simply fork the repository and send me a pull request.

If you’re not on GitHub feel free to email me at matt@mattkirman.com.

To disable the preference that you’ve just enabled change true to false and vice versa.

I’ve been an avid reader of Jason Calacanis‘ various newsletters for some time, not least for the sheer amount of work he puts into each and every one.

In his latest newsletter he offers a suggestion as to why Facebook is perceived as either evil, clueless or just plain unlucky when it comes to releasing new products:

Facebook’s success — and mistakes — are based on its developer-driven culture, not because Zuckerberg is some evil mastermind.

The Zuckerberg Doctrine: Developers design products with significantly improved speed and functionality compared to product managers and designers, outweighing potential mistakes and drawbacks.

And in this world, speed is everything. We shouldn’t be afraid of making mistakes at the cost of innovation. New Year Resolution anyone?

You can sign up for Jason’s free newsletter here.

In order to preserve at least some of the remnants of our sanity I decided, after my colleague managed to corrupt his entire local repository, that I needed to enforce some sort of system. What I finished up with is this fairly typical workflow:

• Find a feature (or bugfix, ticket, etc.) to work on
• git checkout -b my_new_feature
• Hack away at some code
• git commit early and often. Small diffs are the key.
• When I’ve finished git checkout master
• git pull any changes
• git checkout my_new_feature
• git rebase master
• Fix any merge conflicts that I may have. If there are conflicts, fix them and keep going. Merge conflicts should be kept off the master branch if at all possible.
• git rebase -i so that I squash all the commits in my branch down into one. This keeps the master branch nice and tidy.
• git checkout master once the code is ready
• git merge my_new_feature
• git push

Once our code is ready for staging we push our code to the staging branch, and likewise to the production branch. The master branch is reserved for bleeding edge code.

I then started thinking, surely there must be a much easier way to manage this workflow? A minimum of seven separate commands to merge my changes into master and push it back to the server?

Introducing Flit

Flit is a command line utility that eases the typical Git workflow that I’ve outlined above. Setting up Flit to work with either a new or existing Git repository is a simple as flit init. If you haven’t already created a Git repository then Flit will create one for you.

Then, whenever you want to start, or continue with, a feature or bugfix simply do flit start feature my_new_feature. Flit will create, or switch, to your feature branch, ready for you to start hacking away.

You can then use Git as normal, committing your changes as and when you see fit. Once you’ve finished work for the day on your feature or bugfix, flit stop will return you back to your development branch.

Once your feature is complete flit finish feature my_new_feature will pull down changes in master, rebase them into your feature branch and then merge your feature back into master.

Caveats

Flit is an extremely early alpha. Features may be broken or just plain missing, but getting this code out into the open-source community where people can start hacking away with it is much more important.

To that end, the entire codebase is hosted on GitHub. If something’s missing just fork the code, add your fix and send me a pull request.

Requirements

• Git 1.6.4 or greater
• Ruby 1.8.7 or greater
• RubyGems

Installation

The easiest way to install Flit is through RubyGems:
gem install flit --pre

Alternatively you can install Flit from source:
rake gem && rake install

It has support for compressing multiple JavaScript and CSS files at the same time; just select the files you want to compress and hit ⇧⌘Y.

Requirements

The YUI Compressor bundle requires:

• The YUI Compressor
• Ruby version 1.8.7 or greater (installed as default on Mac OS 10.5 and above)
• and TextMate (obviously)

Please make sure you read the README before installing. The YUI Compressor TextMate bundle is licenced under the GPL Licence. This bundle has only been tested with the latest versions of Mac OS X (v10.6.2) and TextMate (v1.5.8) but should work with earlier versions as long as the requirements above are met.

Get It

• Downloads
• Source

Using this bundle? Got any suggestions? Let me know in the comments!

Anyway, in an effort to make a pretty good piece of software even better I decided to make a TextMate bundle for it so that it’s never more than a keystroke away (defaults to ⇧⌘G).

Requirements

The Google Closure Compiler bundle requires:

• The Google Closure Compiler (not included in the bundle)
• Ruby version 1.8.7 or greater (installed as standard on Mac OS 10.5 and above)
• TextMate (obviously)

Make sure you read the README file before installing. The Google Closure Compiler TextMate bundle is licenced under the GPL Licence. This bundle has only been tested with the latest versions of Mac OS X (v10.6.2) and TextMate (v1.5.8) but should work with earlier versions as long as the requirements above are met.

Get It

• [Update] The bundle is now available via the GetBundles TextMate bundle. Simply search for “Google Closure Compiler” (Recommended)
• Downloads
• Source code

Using this bundle? Got any suggestions? Let me know in the comments!

HTML

The HTML of our page is going to look something like this:

CSS

Our page is going to be 500px wide, with a 300px content area and a 200px sidebar. The CSS:

The Demo

Putting this together you end up with something like this:

Why does this work?

The key to creating equal height columns using this method are the overflow: hidden selector on the wrapper and the large padding-bottom and negative margin-bottom. Any padding is hidden when setting the overflow of the container to hidden. Basically, this means that by setting a large enough padding-bottom then we can effectively stretch the background colour of the element to the bottom of the page. If 10000px isn’t enough then just make it even larger.

The large negative margin-bottom then tells the browser where to render the bottom of the box (I think. Don’t quote me on that). If we had set a height of the container this wouldn’t have worked, and without the negative margin-bottom we would have ended up with a container over 10000px tall.

When using this method always make sure that you set the margin-bottom to be equal and negative of the padding-bottom.

And the best bit of this method? If you decide that you now want your sidebar on the right, simply set float: right on the #sidebar and float: left on the #content.

After a few minutes hacking it together on my local web-server I had a pretty good implementation, even if I say so myself. However, once I’d installed it onto my live server it stopped returning any results. The reason for this? I had WP Super Cache installed on my live server, but not on my local server, and was messing up the JSON output by putting a comment at the bottom. Obviously, the JavaScript function refused to parse it as valid JSON. When I turned WP Super Cache off everything returned to normal.

As a developer this was simple enough to debug and fix, but for the average user who just wants to use WordPress, install some plugins and then start blogging away this incompatibility simply isn’t good enough. Before you know it you’ll end up with your support forums full of posts such as “Your plugin doesn’t work with xxxx, please fix it“, even if you have already stated this issue in your readme and installation guides.

Then it struck me: the WordPress Plugin API is broken. As developers we shouldn’t have to rely on users checking that their plugins play nicely together, the plugin should know before it has even been activated. An excellent example of this is the RubyGems framework. I propose, therefore, Glimmer – the next-generation plugin manager for WordPress. Now, that’s a pretty bold claim to make, but I strongly believe that this is the route that WordPress ought to be going down. But just don’t take my word for it, let’s have a look at what’s planned for Glimmer Alpha 1:

Dependency checking

Utilise the hours of work carried out by other developers by building on their plugins. The user is prompted if a required plugin is missing. Glimmer can then, in some cases, automatically install missing plugins. Glimmer can even check to make sure that the correct WordPress version in installed and that certain PHP functions and extensions are available.

Incompatibility checking

Known issues with a third party plugin? Don’t rely on the user, Glimmer can warn them about possible incompatibilities before they have even activated the plugin on their site.

Easy distribution

You are no longer forced to use the WordPress hosted SVN if you want to provide automatic updates of your plugin. Glimmer uses Appcasts, a RSS variant, to distribute your code from any web server. If users have already installed Glimmer they can ask it to install from the your-plugin-name.glimmer file which gets distributed with your plugin, saving them the need to upload your plugin via FTP (and potentially getting it wrong).

Awesome updates

Glimmer automatically checks for plugin updates. Better still, Glimmer supports multiple development branches (e.g. providing a legacy branch for a previous version of WordPress) and scheduling future updates via the RSS pubDate element. You can also embed any release notes in the feed to be displayed to the user before they update.

Glimmer is an extension, not a replacement

Users who haven’t got Glimmer installed will still be able to use your plugin but just without all the fancy features and improvements that Glimmer provides. If you want to Glimmer-ise an existing plugin simply add a your-plugin-name.glimmer file to the plugin directory.

Glimmer is open-source, it’s licensed under the GPL Licence, and is available on GitHub. If you would like to contribute to Glimmer please get in touch, by leaving a comment here, messaging me on Twitter or just send me a pull request on GitHub.

All of my code is stored in the Git VCS with a bare repository on the server, which is what you should be doing as well. Once you’ve got used to managing your code with Git over SSH you will never want to go back to FTP again. Seriously, try it.

My work-flow is fairly typical: clone the repository onto my local machine; hack away; commit the changes and push the commit back to the server. The problem arises when it comes to deploying this code – I could either set up a post-update hook in the bare repository to pull the changes into the web root or do it manually.

Using a post-update hook is not ideal. For one, I might not want to trigger a git pull every time I push a commit to the server. Furthermore, how would I go about differentiating between staging and production servers? And manually SSH-ing into the server, changing to the correct directory and running a git pull every time is just too long winded and time consuming.

Instead, I looked at a way to automate the process. I’m quite a fan of Ruby, so I naturally turned to a Ruby solution, Capistrano. Plus the blurb on their home page described the exact tool that I was looking for. That’s some really great copy writing. So, without any hesitation, I quickly ran sudo gem install capistrano and started to have a play around.

The first thing you want to do is to create a capfile in the root of your web application. This is to capistrano as a rakefile is to rake and a makefile is to make. Once you’ve got your capfile you can run cap -T to see a list of your Capistrano recipes. By default Capistrano includes the invoke and shell recipes. I’m not going to explain what these do as they are documented well enough elsewhere.

The next thing you want to do is to create your deploy namespace:

Then once you decide that your code is at the right point to be deployed to your web server, simply call cap deploy. That’s it! No more messing around with Git commands on a remote server.

This isn’t an ideal configuration, obviously there ought to be a way to decide which branch/tag is checked out. But, as a 2 minute fix, this’ll do for now.