How I make Windows more bearable for web development

DISCLAIMER: This blog post is not meant to incite yet another flame war between operating systems. If you don’t like Windows, don’t use it.

I have Windows at home for gaming, but I also sometimes use it for development when I don’t feel like switching to another computer. This blog post will document some of the measures I’ve taken to ease the pain brought on by a lack of features/tools available to me in Linux.

Install CYGWIN
CYGWIN offers a collection of GNU and Open Source tools that provide functionality similar to a Linux distribution. It gives you the ability to use tools like ls, curl, wget, and more.

Install VirtualBox
Unless you have other VM software supported by Vagrant, this is necessary for the next step.

Install Vagrant
Vagrant is a tool used to setup portable development environments. I use it to set up an environment similar to our production web servers for testing code on. If you are getting started, I recommend taking a look at PuPHPet.

Better Windows command prompt

You may choose to use Cygwin’s Linux-like console, but I just use Windows cmd prompt. There are a few things you can do to make it “better”.

Please be careful below. I am not responsible if you mess up your computer.

  1. Add cygwin’s bin directory (e.g. C:\cygwin\bin) to the Path Windows environment variable. This lets you use Cygwin-installed programs in the command prompt.
  2. Create a folder for batch files (e.g. C:\cli) and add it to your Path environment variable. You can add batch files there and be able to call them in the command prompt no matter what directory you are in.
  3. Set up Windows’ version of bash aliases. Windows offers a tool called DOSKEY that lets you create macros. We can use this to setup aliases rather easily, but the trick is to make these aliases available to every new command prompt automatically.
    1. Create a file that will contain our aliases (e.g. C:\cli\autorun.bat). It’s contents may look something like:
      @echo off
      DOSKEY pac=php app/console $*
    2. Tell Windows to run that batch file every time a command prompt is opened.
      1. Open the registry editor (Win+R, regedit, enter) and navigate to HKEY_CURRENT_USER\Software\Microsoft\Command Processor
      2. Create a new string value named AutoRun. Set the value to the path of the autorun batch file you created earlier (e.g. C:\cli\autorun.bat)


If your computer has a decent amount of memory and you don’t mind switching back and forth between Linux and Windows, you could just install VM software and use it to setup a Linux distribution.

Autoloading Hamcrest functions for PHPUnit in Symfony2

Hamcrest offers plain PHP functions that wrap calls to its static methods. Examples are assertThat(), equalTo(), and so on.

To use these functions, you must first include Hamcrest.php in your tests. Rather than including that file at the top of each test, it can be autoloaded in your PHPUnit bootstrap script.

By default, Symfony2 uses app/bootstrap.php.cache as the bootstrap script, which is problematic since any changes to that file will likely be overwritten.

The workaround is simple:

1. Make your own bootstrap script and include app/bootstrap.php.cache at the top.
2. Change app/phpunit.xml to point to your custom bootstrap script. If you don’t have that file, then copy app/phpunit.xml.dist.

Here is an example of my custom bootstrap that loads Hamcrest.php:


# src/Test/bootstrap.php

namespace Test;

/** @var \Composer\Autoload\ClassLoader $loader */
$loader = require_once __DIR__.'/../../app/bootstrap.php.cache';

// Load Hamcrest functions
$utilPath = $loader->findFile('\Hamcrest\Util');
require dirname($utilPath).'/../Hamcrest.php';

Composer.json is out of sync with your lock file

So I got that message when running composer.phar install.

I found that it’s most likely caused by a mismatch between the hash value stored in composer.lock and what it ought to be based on composer.json.

Composer tells you to run composer.phar update to fix it. I warn you though.. don’t run that command (without additional arguments) unless you know of the consequences. Depending on how you configured composer.json, Composer may update one of your dependencies to an unstable/dev version and potentially break your app.

Luckily, fixing the "Composer.json is out of sync with your lock file" error is easy. Run composer.phar update nothing. This tells Composer to update only the nothing package. Because that is not a real package, Composer skips it and finishes by re-calculating the hash values in composer.lock. Hopefully… problem solved.