Installing PHP on Debian without Apache

When you apt-get install php5 on a Debian/Ubuntu server, you’ll notice that APT will automatically install a bunch of apache2 packages as well. This can be pretty annoying if you’re planning on using another web server (or no web server at all).

If you take a look at the package dependencies (Debian/Ubuntu) you’ll see why this happens – php5 needs one of either libapache2-mod-php5, libapache2-mod-php5filter, php5-cgi, or php5-fpm. APT doesn’t care which package it installs; it just picks the first package that satisfies the dependency, which is why you get the apache2 packages.

You can get around this by installing one of the other dependencies before php5. For example, apt-get install php5-fpm php5 or apt-get install php5-cgi php5.

Using SSH agent forwarding with Vagrant

Sometimes you’ll want to use your local SSH keys on your Vagrant boxes, so that you don’t have to manage password-less keys for each box. This can be done with SSH agent forwarding, which is explained in great detail on

Setting this up is fairly straightforward. On the host machine, you need to add the following to ~/.ssh/config (which you should create if it doesn’t exist):

    ForwardAgent yes

You need to replace with either the domain or the IP address of your Vagrant box. You can wildcard this with host *, but this is a really bad idea because it lets every server you SSH to access your keys.

Once you’ve done that, just run ssh-add to ensure you ensure your identities are added to the SSH agent.

Now, add the following to the config block in your Vagrantfile:

config.ssh.forward_agent = true

That’s all it takes. You can make sure it worked by comparing the output of ssh-add -L on both the host machine and the guest box.

Worst fonts for programming

There are plenty of discussions about which font is the best for programming. The problem is, there are so many “best” fonts that it’s difficult to choose one. Rather than have an exhaustive list of “best” fonts for programming, wouldn’t it be easier to simply know which fonts to avoid?

Brush Script MT

This font was created in 1942 by Robert E. Smith. It’s designed to look like the characters have been handwritten with an ink brush. This font will make you feel right at home if you grew up writing your code with an ink brush. Otherwise, don’t use it.

Brush Script MT


A relatively modern font (1995), Chiller is supposed to be very legible even at small sizes. This font is great for giving your code that “spooky” feel. However if you prefer emotionless, monospaced fonts, Chiller is probably not for you.


Comic Sans MS

By far the most loved font on the web, Comic Sans has been bringing joy to peoples’ lives since its inception in 1994. Coding in Comic Sans is fun, and reading code in Comic Sans is even funner-er. Unfortunately, some people don’t like Comic Sans, so you should avoid using it unless you enjoy being ridiculed by your colleagues.

Comic Sans MS


Created in the Swinging Sixties by a fellow named Geoffrey Lee, Impact was intended for headlines. Why should headlines be the only text with emphasis, though? Using Impact will give your code the emphasis it deserves by making every single line a headline. The downside is that prolonged exposure to Impact can cause developers to read everything in a yelling voice. If this is a problem for you, avoid using this font.


When did dependency management get so complicated?

This evening I wanted to start hacking on a project of mine, which is a simple WordPress theme. My main development machine was being used by somebody else, so I decided to boot up my old Sony Vaio running Ubuntu. It’ll be simple, I thought. I’ve just got to clone the repo, run npm install, bower install, and grunt build, and I’ll be good to go. I was wrong.

First, the version of npm installed on the laptop is apparently so out-of-date that it can’t run the install. So I let it update itself (and all the other packages I have installed – why not?) with sudo npm -g update. Being a Sunday night, my broadband connection is running spectacularly slow, so the update process takes about 10 minutes at 40kB/s. But hey, at least now I can run npm install, right?

Nope. Now npm is throwing some errors with unhelpful messages, but that’s fine, I’ll just trawl through the error log. 5 minutes later, I figure out that ~/tmp belongs to root (probably from running npm update as root). Ok, fine, I’ll change the permissions and try again. This time npm install works! But of course, my connection is so horribly slow and grunt has so many dependencies that the install process takes over 15 minutes. (more…)

Blazing fast WordPress with Nginx and Memcached

Inspired by Eric Mann’s post on caching WordPress with Redis, I thought I’d experiment with a similar setup using Memcached. Any memory caching system should work just as well, but I’ve chosen Memcached because it’s already running on my server and because PHP already has a built-in libmemcached API.

My current setup is Nginx and PHP-FPM, with WP Super Cache. The cache is saved to the filesystem, allowing Nginx to serve static files (which it is very good at) without needing to pass any requests to PHP. This setup has worked very well, so I’ll be using it as a baseline.

To use Memcached, every request needs to be passed to PHP. My gut feeling was that this would be slower than serving static files with Nginx due to the overhead of spinning up a PHP process for each request.


To find out which of the two setups was faster, I measured the following metrics using WebPagetest and Blitz (referral link):


Increasing the size of the LISH console

If you’ve used Linode’s LISH console to get remote access to your server, you’re probably familiar with the way the console wraps everything to 60×20 (columns x rows) – even when you’re connected via ssh in a much larger terminal.

LISH Wrapping

Everything looks fine until…

LISH Wrapping

… The terminal wraps on itself

Luckily, the fix is easy. The LISH console is essentially emulating a raw serial port connected to the server. The serial port itself has no natural size, so the terminal gives it a default safe size (60×20). We can tell the terminal to change this size, using the stty command:

stty cols 200 rows 75

It’s as simple as that. Just set the cols and rows values to whatever size suits you.

If you’re having to do this a lot, you might consider putting this into your ~/.bashrc so that it runs each time you open a connection.

Stop posting jobs for “hackers”

I understand what people mean when they say that they want to hire a hacker. It means that they want to hire a developer; probably one who is enthusiastic and good at solving problems. The thing is, to me, the term hacker is no different from terms like rock star or ninja. When I see these terms in a job advertisement, a few red flags are raised in my mind:

You’re probably a start-up

This isn’t necessarily a bad thing, but it often means that whoever posted the job advertisement has a lack of technical knowledge, which probably also means…

You don’t actually know what kind of developer you want

Hacker, rock star, ninja – these don’t actually mean anything in the context of programming. Do you want a front-end web developer who can make complex JavaScript apps, or a Ruby developer with a working knowledge in system administration, or do you just want an all-rounder? If the title of your job advertisement has no context, I (and many other people) will simply ignore it.

The job requires more than one person

You really need 2 or 3 people for this job, but budgeting concerns have forced you to go for a single super-developer instead. This also leads me to believe that the job will have ill-defined requirements, and that I’m likely to be over-worked and under-paid.

For the most part, I think that if you find yourself posting an ad for a hacker, rock star, or ninja, you should take it as a sign that you need to re-think your hiring requirements. Take a little extra time to figure out what kind of developer you really want to hire, and write the advertisement accordingly.

Setting up your editor

Setting up your editor correctly can make working with other developers much less painful. Below are some things that I believe every developer should do when editing source code. Any good IDE or editor should have settings to do these things automatically – the points below are paired with their Sublime Text setting.

  • Trim trailing whitespace – "trim_trailing_white_space_on_save": true
  • Always use Unix line endings (LF) - "default_line_ending": "unix"
  • Ensure files end with a new line – "ensure_newline_at_eof_on_save": true
  • Automatically detect indentation style – "detect_indentation": true
  • Or, failing the above, have a way to quickly switch between indentation styles.

Non-tech books I should read

This post is to help me keep track of non-tech books that I would like to read.

Breakfast of Champions by Kurt Vonnegut
Slaughterhouse-Five by Kurt Vonnegut
Cat’s Cradle by Kurt Vonnegut

Do Androids Dream Of Electric Sheep by Philip K Dick

Neuromancer by William Gibson

Ham on Rye by Charles Bukowski

Solving “502 Bad Gateway” with nginx & php-fpm

After upgrading php-fpm, my PHP-based sites were returning “502 Bad Gateway” errors. This can happen when the php5-fpm package reconfigures itself to listen on a different socket. Here’s how you can solve it.

Check to make sure that php-fpm is running with ps aux | grep php – if you can’t see any php-fpm processes in the output, then you may need to re-install php-fpm. If php-fpm is running okay, then skip this first step.

sudo apt-get remove php5 php5-cgi php5-fpm
sudo apt-get install php5 php5-cgi php5-fpm

The thing to notice here is that the order in which you install the packages is important. In the past I have found that installing them in the wrong order causes the packages to be configured incorrectly.

Next, get php-fpm to listen on the correct host/port. In /etc/php5/fpm/pool.d/www.conf change the listen value to match the fastcgi_pass location in your Nginx configuration. For example, I changed mine from:

listen = /var/run/php5-fpm.sock


listen =

If you are configuring php-fpm to listen on a Unix socket, you should also check that the socket file has the correct owner and permissions. While I wouldn’t recommend it, you can simply give read-write permissions to all with sudo chmod go+rw /var/run/php5-fpm.sock.

Restart php-fpm with sudo service php5-fpm restart and everything should work normally again.