I spend a lot of time working on the command line. Day in; day out. Hours at a time. This is a brief rundown of the setup that I’ve been using for some time and am finally happy with.

One quick note: In some cases I’ve extensively customised my tools from their defaults. Some of the changes are too many to detail here – I’ll go into more detail in additional posts.

My setup comprises of an extended Bourne shell, a terminal multiplexer and an advanced text editor.

Zsh

Zsh (the Z shell) is an interactive login shell with powerful command completion, extended file globbing, path expansion, spelling correction and a lot more. If you want it Zsh (probably) has it.

Zsh is installed on OS X by default but it’s quite out of date (version 4.3.11 on OS X 10.8.2). You will want to get the latest version via Homebrew instead:

In comparison to some shells my prompt is relatively straightforward. It’s tailored for a Git and Ruby development environment:

The left prompt displays information such as the username, working directory and the current Git branch. The lightning bolt indicates that there are some unstaged changes that need to be committed. My right prompt simply shows the current Ruby version (with switching enabled by rbenv).

What isn’t shown in the screenshot above is a sudo indicator. When working as a superuser the left prompt is suffixed by two red exclamation marks.

The full Zsh prompt configuration is available in my dotfiles repository.

Tmux

Rather than opening multiple terminal windows or tabs I much prefer to use tmux – a terminal multiplexer. Basically this means that you can manage multiple terminal sessions within one terminal window.

Again, tmux is available from Homebrew:

I typically split my main tmux window into three sections:

1. Vim – for writing code
2. a command prompt – for running Rake, Git etc.
3. a utility pane for long running processes such as Foreman and Guard that tail their logs to the terminal. This pane often gets subdivided further.

Occasionally I’ll like to push a window to a separate device such as an iPad or iPhone for monitoring long running processes away from my desk. Unfortunately tmux forces all clients to have the same window visible.

To counter this I’ve added a tmx shell script that allows clients view different windows from within the same session. Finally make sure you add the following to your tmux config so that only visible windows are resized:

I’ve made a number of other changes to the tmux defaults – you can view my full config in my dotfiles repository.

Vim

Switching to Vim was the best thing to happen to my development workflow and day-to-day productivity despite the daunting (and seemingly never ending) learning curve.

If you’re tempted to give Vim a go I highly recommend that you stick with it for at least a couple before deciding whether it’s for you.

As usual the copy of Vim bundled with OS X is quite out of date. Install the latest version with Homebrew:

Plugins are kept to a minimum. Due to the intricate Vim command scheme it makes sense to fully understand the editor before confusing matters with third party functionality. Bonus: my Vim isn’t that different from default making much it easier to move between unfamiliar environments.

The few plugins to make the cut include:

• Vundle – a plugin manager
• vim-surround – quoting/parenthesizing made simple
• SuperTab – insert mode code completions
• command-t – TextMate style “Go to File” window
• nerdtree – a file tree explorer

Usually I opt for command line Vim rather than MacVim. Differences between the two versions are minimal plus CLI Vim is accesible remotely through my tmux sessions. I haven’t found a convenient way to open files in CLI Vim from Finder or other apps quite yet; so have MacVim as the default editor for certain file types.

As before, my .vimrc and .gvimrc is available on GitHub.

The post I Use This: Terminal Edition appeared first on Matt Kirman.

Remapping the caps lock key is becoming an increasingly common modification in the Vim community. Thankfully it’s extremely easy to set up on OS X – with no third party software required.

Tucked away in the Keyboard section of System Preferences there is the Modifier Keys section. You can then just change the value in the Caps Lock key dropdown to ‘^ Control’.

OS X Modifier Keys dialog

Some users report that they encounter a slight delay on the caps lock key when using this method but I can’t replicate this issue in Mountain Lion.

I’ve converted the above process into an Applescript so that I can run it automatically when setting up a Mac from scratch. Once I’ve cloned and installed my dotfiles Git repo (mattkirman/dotfiles) it’s as simple as running $DOTFILES_DIR/osx/set-defaults.sh.

The Applescript:

You can download and run this script from mattkirman/dotfiles/blob/master/osx/capslock-to-control.scpt.

The post Mac: How to Rebind Caps Lock to Control appeared first on Matt Kirman.

Cirrus has been tested on WordPress 3.3.2 (latest version as of time of posting) and PHP 5.3. It’s fully compatible with both the Free and Pro versions of CloudApp.

Demo

http://mtt.io/HBJF → http://mattkirman.com/2012/06/06/introducing-cirrus-cloudapp-powered-shortlinks/

Installation

Source code is available for download on GitHub or, if you would prefer to install the plugin through the WordPress admin interface, you can do so by downloading a zipped version here.

Cirrus settings page

Once the plugin is installed successfully you will then need to navigate to the Cirrus settings page (found at Settings > Cirrus) and add your CloudApp credentials. At this point you will probably want to click “Add shortlinks to existing posts” (not recommended if you’re using the free version of CloudApp). Depending on the size of your blog this may take some time.

Usage

Cirrus does not replace the existing WordPress functionality instead adding the custom field cirrus_shortlink to posts. On the plus side it makes uninstalling the plugin easy, however you will have to modify your theme files if you want to expose the shortlink to your readers.

Where you want the link to show up add the following to your theme file (this assumes that you’re currently in the Loop):

Limitations

Shortlinks are only generated for posts, that means categories, tags and pages are not included. This may be resolved in a future update, or if you’d like to patch it yourself I’m accepting GitHub pull requests.

The post Introducing Cirrus: CloudApp powered WordPress shortlinks appeared first on Matt Kirman.

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.

The post Relative Line Numbers in Vim appeared first on Matt Kirman.

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.

The post Graphing the switch to Nginx appeared first on Matt Kirman.

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

The post How to speed up WordPress with Nginx appeared first on Matt Kirman.

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.

The post Introducing Spotio: A Spotify Remote appeared first on Matt Kirman.

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

The post Super Secret Preferences in Twitter for Mac without the Nanobundle appeared first on Matt Kirman.

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.

The post What I Learned from Zuckerberg’s Mistakes appeared first on Matt Kirman.

The post Facebook Places launches in the UK appeared first on Matt Kirman.

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

The post My Git Workflow; Introducing Flit appeared first on Matt Kirman.

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!

The post YUI Compressor TextMate Bundle appeared first on Matt Kirman.

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!

The post Google Closure Compiler TextMate Bundle appeared first on Matt Kirman.

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.

The post Equal height columns with pure CSS appeared first on Matt Kirman.

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.

The post Blog redesign #4 (and why the WordPress Plugin API needs fixing) appeared first on Matt Kirman.