david winter - you were expecting someone else?

Install and manage WordPress with Git

2012-04-09T00:00:00-07:00

I've been a massive fan of the 'Installing/Updating Wordpress with Subversion' instructions on the WordPress codex for a good few years. If you have ssh access to a server and are managing a couple of WordPress sites, keeping them up-to-date with the latest version is easy with just one svn command.

However, with a bigger WordPress project in the pipeline, I need to be able to manage my themes and plugins in a git repository, while at the same time keep a reference to the core WordPress files, and allow it to be as easy to update when a new version is released.

I'm not going to continue with the SVN instructions because that'd add a lot of mess to my git repository - including SVN history. I want to keep track of my changes only - none of the WordPress related ones.

The good news is, this is all possible. It takes a few minutes longer to setup, but once done, updating will be as easy. You'll also have a really tidy git repo.

Setup

Note: You can view the finished project on Github; davidwinter/wordpress-with-git

Create a new project directory:

mkdir mysite && cd mysite
git init
touch README.md
git add README.md
git commit -m "Initial commit."

You now have a blank project to start with.

We'll be using the Github WordPress mirror that is synced with the official SVN repository every 30 minutes. It includes all tags and branches.

We want to add this as a subrepository to our main project.

git submodule add git://github.com/WordPress/WordPress.git wordpress

WordPress is quite a big project if you haven't already noticed, so it might take a while to make a clone. Once done, commit the new subrepository:

git commit -m "Add Wordpress subrepository."

We want to ensure our project is using the current stable version. As of writing, this is 3.3.1.

cd wordpress
git checkout 3.3.1
cd ..

This has now updated the WordPress repository to 3.3.1 - commit the changes to your main project.

git commit -am "Checkout Wordpress 3.3.1"

The subrepository is now isolated, and we don't want to make any changes to it, besides bumping version numbers. This means we can't modify wp-config.php, themes or plugins. We'll have to move things about a bit.

First up, we'll create our config file. WordPress allows for this to be stored one directory up from the core WordPress files.

cp wordpress/wp-config-sample.php wp-config.php
git add wp-config.php
git commit -m "Adding default wp-config.php file"

Now that this is outside of the Wordpress repository, we'll be able to configure Wordpress and commit the changes to our main project repository.

Now, in order to manage themes and plugins we need to make a copy of the wp-content directory:

cp -R wordpress/wp-content .

This will copy the directory and its contents into our main project repo.

Now, at this point you may like to tidy up that directory a little. This isn't required, but will save you commiting themes and plugins you'll probably never use.

rm wp-content/plugins/hello.php
rm -rf wp-content/themes/twentyten

If you plan on using the default WordPress theme, Twenty Eleven, don't run the following command:

rm -rf wp-content/themes/twentyeleven

Now commit this directory:

git add wp-content
git commit -m "Adding default wp-content directory"

We now have a trimed down wp-content directory ready for only our themes and plugins.

To finish off the project structure, we need to copy the WordPress index.php file:

cp wordpress/index.php .
git add index.php
git commit -m "Adding index.php"

Now we need to configure these files and let WordPress know where to talk to everything.

Configuring

We'll start with index.php. This is the file all requests go via, and we just need to update a require statement. Find the following line:

require('./wp-blog-header.php');

And update it to:

require('./wordpress/wp-blog-header.php');

Commit:

git commit -am "Pointing index.php to the correct location"

Now into wp-config.php, open it up. Because we have the core Wordpress files in a different directory to that of the index.php file, we need to let Wordpress know about it. Add the following two constants to the file. I prefer just below the @package WordPress statement so my changes are near the top of the file:

 * @package WordPress
 */

define('WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/wordpress');
define('WP_HOME',    'http://' . $_SERVER['SERVER_NAME']);

This lets WordPress know that the core files are in the wordpress directory, but that the site is to be served at the root of the project directory.

Because we moved the wp-content directory out of the core WordPress directory, we also have to let it know about this change. Add the following after the previous define statements:

define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/wp-content');
define('WP_CONTENT_URL', 'http://' . $_SERVER['SERVER_NAME'] . '/wp-content');

And finally, if you're not using the default twentyeleven theme, and want to specify the one WordPress should use instead:

define('WP_DEFAULT_THEME', 'mytheme');

Simply replace mytheme with the name of the theme you have. Be sure that you've placed it inside the wp-content/themes directory.

Now simply complete the database details as normal further down in the file, and then visit the project on your webhost and you'll be up and running.

git commit -am "Update settings in wp-config.php"

Updating

Change into the Wordpress subrepository:

cd wordpress
git fetch --tags
git checkout 3.3.2

Replace 3.3.2 with the correct version number.

Now commit the changes subrepository version to your main project:

cd ..
git commit -m "Update Wordpress to version 3.3.2"

Helpful references

Introduction to Puppet

2012-03-04T00:00:00-08:00

Have you ever had that déjà vu feeling when setting up a new server? That you've done it all before, and that it's really tedious to have to do it all over again? You'd rather be able to just hit a button to deploy your app and start showing it off to the world.

It's exactly what happened to me, and at first I thought I'd just write a bash script with all the various steps that I had started noting down in a plain text file. Luckily, at the point I was considering this, I saw the release of a new project called Vagrant. It's a tool that allows you to run a virtual machine locally, with a helpful shared directory to your files on your local (host) machine. It allows you to setup a self contained development environment without messing around with your system.

Reading through the documentation, I saw it mention Puppet and Chef which both appeared to be some sort of witchcraft that allowed you to automatically configure and setup these virtualised servers. Bingo. Easy server configuration management.

You don't have to use Vagrant to use Puppet. It's just a really easy way to test it out locally. For your production environments you'll still use the same puppet manifests, but you'll manage the running of those manifests a little different. I'll be covering the Vagrant approach for this blog post.

What do I want to demonstrate? Just a quick demo of how to get Puppet to install Nginx and php-fpm on a server, serving a simple phpinfo() file. It should be enough to make you thirtsy for more.

Some quick steps for setup

You'll need to have Virtual Box installed with the command line tools option. Then install the Vagrant gem on your computer with a simple

gem install vagrant

Now create a new directory on your machine where you're going to work on this project.

mkdir testing-vagrant
cd testing-vagrant/

All Vagrant projects use a 'box' as a starting point for your project. It's an virtual disk image of an OS installation that has all the dependencies to interact with Vagrant, and to run puppet manifests. Now, the one on the Vagrant website is Ubuntu 10.04 Lucid Lynx, and without some tinkering, it's not as easy to get the latest versions of packages. So instead, I created my own Vagrant box for Ubuntu 11.10 Oneiric Ocelot using the open source tool VeeWee. It's hosted on my public Dropbox folder, and to add this box to your vagrant setup, run the following:

vagrant box add oneiric32 http://dl.dropbox.com/u/11342885/oneiric32.box

Once this has been downloaded, you need to initialise your Vagrant project with this box:

vagrant init oneiric32

This will create a file named Vagrantfile in your project directory. This file has a bunch of different configuration options commented out. It's a really helpful file to read through.

One configuration option you'll need to set is the port forwarding of the webserver. Ensure this line is present:

config.vm.forward_port 80, 8080

This will forward on the port 8080 of your local machine to port 80 on the vagrant virtualbox. If you don't have any other webservers running on your local machine, feel free to point this to port 80 directly.

Also, ensure these lines are present too:

config.vm.provision :puppet, :module_path => "private/puppet/modules" do |puppet|
  puppet.manifests_path = "private/puppet/manifests"
  puppet.manifest_file  = "base.pp"
end

This is the Puppet configuration. It tells Vagrant where the modules and manifests directories are, and the base manifest file.

And finally, create these directories in your project for storing the different Puppet configuration files we need:

mkdir -p private/puppet/{manifests,modules/nginx/files}

Playing with Puppet

To understand how to use Puppet, you need to think of a Puppet manifest as a file that defines the different resources your server requires. Resources in Puppet speak are things like users, groups, packages, commands, services and files--to name a few. We define these resources in a manifests file which you'll place in private/puppet/manifests/base.pp.

Now the first thing we want to do with the base box is ensure that everything is up-to-date. The first resource we'll define is an executable command to run. Basically an apt-get update. In your base.pp file add the following:

exec { 'apt-get update': 
    command => '/usr/bin/apt-get update',
}

All resources follow this same structure:

resource_type { 'title':
    options => value,
}

The title is quite an important value, as it is often used as a default option value too. For example, with the user resource, the title you specify will be the name of the user to create. This can be overriden if you need to define a descriptive title that isn't the name of the user you want to create. For the user resource, you'd override this with the name option. For example, the following would both create the same user:

user { 'david':
    ensure => present,
}

user { 'my descriptive title for my username':
    name   => 'david',
    ensure => present,
}

Note: Due to an issue with VeeWee not creating a required user group on the Oneiric box, you need to also tell Puppet to create the puppet group. This can be done with the following. Not doing this will result in errors:

group { 'puppet':
    ensure => present,
}

Back to our example. We now have a command resource that will run apt-get update. Once this has been run, we want to install the packages nginx and php-fpm. We want to ensure though that apt-get update has run beforehand. Now, with Puppet, it's important to note that the manifest files are not run through sequentially as you might expect. Each time they are run, they can happen in a different order. You need to explicity set dependencies and requirements.

To install the nginx package, we'll add the following:

package { 'nginx': 
    ensure => present,
    require => Exec['apt-get update'],
}

A few things to note here. The package to install is being derived from the resource title. It defaults to this, or you can specify the option with the option key name. We tell puppet to ensure that it's present on the system. We also say that this resource requires that the executable command apt-get update has already been applied.

When you reference other resources in a manifest file, the resource type has the first letter capitalised. Then you specify the title of the resource you're referencing. This is where resource titles are used.

We'll also do the same for the php-fpm package:

package { 'php5-fpm':
    ensure => present,
    require => Exec['apt-get update'],
}

Each of these packages come with a service that runs in the background, that we want to ensure is running all the time. We can make Puppet check this is the case with the following:

service { 'nginx':
    ensure => running,
    require => Package['nginx'],
}

service { 'php5-fpm':
    ensure => running,
    require => Package['php5-fpm'],
}

Notice the require dependencies? Whenever Puppet runs it will check that these are running, and if they're not, for whatever reason, it will start them.

Ready to see some magic? Save the file and run vagrant up. Vagrant will boot up the virtual machine, and run the Puppet manifest on it. Once it's finished visit http://localhost:8080 and you should see:

Welcome to nginx!

You've not had to ssh into the machine once or run anything on the command line of that VM.

Now in order to get PHP setup and running with nginx, we need to modify some of the nginx config files. We need to do the following:

Disable the default nginx virtual host.
Copy over a new virtual host for our vagrant setup that forwards on PHP requests to php-fpm.
Symbolically link the virtual host config file to the sites-enabled directory.

In the private/puppet/modules/nginx/files directory we created, add the following in a file called vagrant:

server {
    listen 80;
    server_name _;
    root /vagrant;
    index index.php;

    location / {
        try_files $uri /index.php;
    }

    location ~ \.php$ {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        include fastcgi_params;
    }
}

This is a standard nginx configuration file for a virtual host. It will use /vagrant on the virtual machine as the document root. This is a shared directory that Vagrant sets up to link to your project directory on your local machine.

Saving that file, we can now open up the base.pp file again and add a few more resources. The first is to copy over this virtual host to the correct location:

file { 'vagrant-nginx':
    path => '/etc/nginx/sites-available/vagrant',
    ensure => file,
    require => Package['nginx'],
    source => 'puppet:///modules/nginx/vagrant',
}

Now lets disable the default virtual host the nginx package provides:

file { 'default-nginx-disable':
    path => '/etc/nginx/sites-enabled/default',
    ensure => absent,
    require => Package['nginx'],
}

And finally, enable our new vagrant virtual host:

file { 'vagrant-nginx-enable':
    path => '/etc/nginx/sites-enabled/vagrant',
    target => '/etc/nginx/sites-available/vagrant',
    ensure => link,
    notify => Service['nginx'],
    require => [
        File['vagrant-nginx'],
        File['default-nginx-disable'],
    ],
}

Save the file and run vagrant reload. This tells vagrant to run the puppet provisioner again and ensure that the virtual machine matches the resources specified in the manifests file. We've just added three new ones, so it will action these.

Ready to test it has all worked as expected? Create an index.php file in your project directory, the same location where your Vagrantfile is. In there just put a simple:

<?php phpinfo();

Save the file. Visit http://localhost:8080 again and you should see the standard phpinfo page being served over php-fpm via nginx.

That's it for this introduction. Hopefully it's enough to get you excited. For me, it means being able to keep a manifest file up-to-date, and if I ever change my VPS to a different provider and want to get it up and running within a few minutes rather than hours, I can apply it with Puppet. No more keeping a log of the many steps I would have to manually run over ssh as the alternative.

If you want to know more, here are some great resources:

Testing Javascript websites with Behat

2012-01-14T00:00:00-08:00

This is my third blog post on how to use Behat for your web application testing. If you haven't already, be sure to read Getting started with Behat and Using Behat with Mink as this post continues on where they left off.

In my previous post I left you with being able to create your own custom, reusable definitions in Behat. We've touched on the real basics of testing with Behat on a very simple example website. However, in 2012, you'll find it very hard to find a website that doesn't have some kind of Javascript included providing a dynamic and better user experience for visitors. It's crucial that we're able to test and guarantee that the animations and ajax requests that the users interact with work as we expect.

In this blog post, we'll be using the twitter bootstrap example site. It has a variety of different JS related widgets and interactions which are perfect for explaining some of the basic Javascript testing concepts when it comes to Behat. Here is the behat.yml configuration file being used:

default:
  context:
    parameters:
      base_url: http://twitter.github.com/bootstrap/

Now take a look at the following example test:

Feature: Modal dialog

    Scenario: Open modal dialog
        Given I am on "/javascript.html"
        And I should see "Launch Modal"
        When I press "Launch Modal"
        Then I should see "One fine body…"

If you visit the modals section on the example site, there is a red button under the demo heading. Clicking that opens a modal box with the text 'One fine body…'. That's what our above test is for. Run that test and you'll probably see:

Feature: Modal dialog

  Scenario: Open modal dialog            # features/modal.feature:3
    Given I am on "/javascript.html"     # FeatureContext::visit()
    And I should see "Launch Modal"      # FeatureContext::assertPageContainsText()
    When I press "Launch Modal"          # FeatureContext::pressButton()
      The selected node does not have a form ancestor.
    Then I should see "One fine body…" # FeatureContext::assertPageContainsText()

1 scenario (1 failed)
4 steps (2 passed, 1 skipped, 1 failed)

Great. Test failure. But we know it should work because we just did the exact same steps our test has in our browser. Why did it fail?

Behat by default uses a headless driver called Goutte for all tests. It's a very fast driver, but it doesn't support Javascript. As the official documentation for Mink so perfectly states:

Those browser emulators send a real HTTP requests against an application and parse the response content. They are very simple to run and configure, because this type of emulators can be written in any available programming language and can be run through console on servers without GUI. Headless emulators have both, advantages and disadvantages. Advantages are simplicity, speed and ability to run it without the need in real browser. But this type of browsers have one big disadvantage - they have no JS/AJAX support. So, you can’t test your rich GUI web applications with headless browsers.

We need to use a different type of driver for our Javascript-dependant tests. These type of drivers are called 'browser controllers'. They launch the browser you designate and then it does exactly what your tests say. This means your tests have the full Javascript support of your browser behind them.

The easiest of these drivers to get setup and running is Selenium2Driver. We're going to use this with Google Chrome to get our tests passing. Thanks to @ColonelRosa for pointing out Selenium2 support in Mink 1.3.

First of all you'll need the chromedriver on your machine, and have it available in your path. You're able to download the driver from the Google code project page. Or if you're on a Mac and have homebrew installed, simply run brew install chromedriver.

The last thing you'll need is the WebDriver. Go to http://seleniumhq.org/download/ and then you want to choose the 'Selenium Server'. As of writing, it's version 2.16.1. This will download a Java .jar file. Once you have this, simply run the following command in the terminal. It's good idea to have this run in it's own window or tab, because it must be running while the tests are active:

java -jar /path/to/selenium-server-standalone-2.16.1.jar

You now have all the required tools.

Now we just need to update our behat config, and our tests slightly. Update your behat.yml to contain:

default:
  context:
    parameters:
      base_url: http://twitter.github.com/bootstrap/
      browser: chrome
      javascript_session: webdriver

This is telling behat that for our javascript tests, we want it to use the WebDriver driver (Selenium2). Also, that it is to use Google Chrome as the browser the driver controls.

Now, we need to simply mark our test as being Javascript dependant, which is as easy as adding a @javascript tag above the Scenario:

Feature: Modal dialog

    @javascript
    Scenario: Open modal dialog
        Given I am on "/javascript.html"
        And I should see "Launch Modal"
        When I press "Launch Modal"
        Then I should see "One fine body…"

Now run behat.

Damn. The tests are still failing. This is because when the button is pressed, Javascript animates the opening of the modal window, and hasn't completed by the time the next step runs searching for the text. The animation hasn't completed, and therefore the step fails.

Well, we can get the test passing, and also add an additional definition that will make testing modals easier in the future. Lets update the scenario to the following:

    @javascript
    Scenario: Open modal dialog
        Given I am on "/javascript.html"
            And I should see "Launch Modal"
        When I press "Launch Modal"
        Then I should see the modal "Modal Heading"
            And I should see "One fine body…"

We've added a new definition I should see the modal "Modal Heading". This will allow us to write other tests that depend on modal dialogs opening with various headings. Run behat to get the skeleton definition method and add it to your FeatureContext.php file:

/**
 * @Then /^I should see the modal "([^"]*)"$/
 */
public function iShouldSeeTheModal($title)
{
    $this->getSession()->wait(20000, '(0 === jQuery.active && 0 === jQuery(\':animated\').length)');
    $this->assertElementContainsText('#modal-from-dom .modal-header h3', $title);
    assertTrue($this->getSession()->getPage()->find('css', '#modal-from-dom')->isVisible());
}

I'll run through this method now line-by-line:

We use the wait method to allow us to wait for the animation to complete. The first parameter sets 20 seconds to wait or until the following Javascript evaluates to true. We test to ensure that all Jquery ajax calls have completed, and that no elements are being animated.
We want to check that the heading portion of the modal dialog contains the heading text that we pass through in the step. In our test, this is "Modal Heading". So we use a CSS selector to do this.
Finally, we just want to be sure that the modal dialog is actually visible on the page.

That's it. One final change we can make is to move our Jquery wait check code into it's own method so that we can use this in any other custom definitions we may create in future:

protected function jqueryWait($duration = 1000)
{
        $this->getSession()->wait($duration, '(0 === jQuery.active && 0 === jQuery(\':animated\').length)');
}

/**
 * @Then /^I should see the modal "([^"]*)"$/
 */
public function iShouldSeeTheModal($title)
{
    $this->jqueryWait(20000);
    $this->assertElementContainsText('#modal-from-dom .modal-header h3', $title);
    assertTrue($this->getSession()->getPage()->find('css', '#modal-from-dom')->isVisible());
}

Now run behat, and you should get a perfect test score:

1 scenario (1 passed)
5 steps (5 passed)

Example code used in this post can be found on Github.

Using Behat with Mink

2012-01-13T00:00:00-08:00

This is my second blog post on how to use Behat for your web application testing. If you haven't already, be sure to read Getting started with Behat as this post continues on where that left off.

In my last post, I left you with hopefully enough knowledge to get started with some basic testing that comes for free, out of the box, by just installing Behat and Mink. You were able to do that because Mink comes with around 34 bundled definitions.

We created a very basic test to ensure that users were able to log into our example website:

Feature: User sessions
    In order to access their account
    As a user
    I need to be able to log into the website

    Scenario: Login
        Given I am on "/"
            And I should see "Login"
        When I fill in "email" with "myemail@test.com"
            And I fill in "password" with "mysecurepassword"
            And I press "Login"
        Then I should be on "/dashboard"
            And I should see "Welcome back"

    Scenario: Logout
        Given I am on "/dashboard"
        When I follow "Logout"
        Then I should be on "/"
            And I should see "Login"

So that we can work on this further, I've created a basic PHP script that we can use to play with. It's written with the Silex micro-framework and doesn't require any modification in order for us to write the tests in this blog post.

If you do want to play along, clone the example from github, setup a virtual host. Then just be sure to update the behat.yml file so that the base_url points to your new virtual host.

If you run bin/behat now, it'll run through the test and fail:

2 scenarios (1 passed, 1 failed)
11 steps (8 passed, 2 skipped, 1 failed)

In our test, we've missed something! For the second scenario, we've not logged in the user! So they're unable to access the /dashboard.

If we focus on just the Logout scenario from here on, in order to log in the user, we could do something like this:

Scenario: Logout
    Given I am on "/"
        And I should see "Login"
    When I fill in "email" with "myemail@test.com"
        And I fill in "password" with "mysecurepassword"
        And I press "Login"
        And I should be on "/dashboard"
    When I follow "Logout"
    Then I should be on "/"
        And I should see "Login"

This is basically duplicating the steps from the above login scenario. Running this, the tests now pass. Excellent. Are we finished? No. The test above isn't very tidy because we just copy and pasted code. It'd be so much nicer if we could write something like:

Scenario: Logout
    Given I am logged in as "myemail@test.com" with password "mysecurepassword"
        And I am on "/dashboard"
    When I follow "Logout"
    Then I should be on "/"
        And I should see "Login"

That makes our feature file a lot more readable, cleaner, and also provides us with a new custom definition that we can then use in other future tests. How do we make this work?

When you run bin/behat and you've added a custom definition, it's very kind by providing you with an example template for creating the PHP code to have this new definition work:

/**
 * @Given /^I am logged in as "([^"]*)" with password "([^"]*)"$/
 */
public function iAmLoggedInAsWithPassword($argument1, $argument2)
{
    throw new PendingException();
}

What do we do with this? Paste it directly into features/bootstrap/FeatureContext.php.

Now we just need to use Mink to program the definition. Looking at the source for the base mink context, we can use the following methods to complete the definition:

/**
 * @Given /^I am logged in as "([^"]*)" with password "([^"]*)"$/
 */
public function iAmLoggedInAsWithPassword($email, $password)
{
    $this->visit('/');
    $this->fillField('email', $email);
    $this->fillField('password', $password);
    $this->pressButton('Login');
}

Saving, and then running bin/behat again, the tests will now pass. And you've just created your first custom definition.

There is one final change we could make to this. As our definition is using all existing definitions, we could future proof it by changing it to the following:

/**
 * @Given /^I am logged in as "([^"]*)" with password "([^"]*)"$/
 */
public function iAmLoggedInAsWithPassword($email, $password)
{
    return array(
        new Step\Given('I am on "/"'),
        new Step\When('I fill in "email" with "'.$email.'"'),
        new Step\When('I fill in "password" with "'.$password.'"'),
        new Step\When('I press "Login"'),
    );
}

In order to use the above, be sure to update the use statement at the top of the file so it contains the last line of the following:

use Behat\Behat\Context\ClosuredContextInterface,
    Behat\Behat\Context\TranslatedContextInterface,
    Behat\Behat\Context\BehatContext,
    Behat\Behat\Exception\PendingException,
    Behat\Behat\Context\Step;

That's all there is to it when creating custom definitions. The Mink source is a great way to look at how the out-of-the-box definitions work.

Setup rbenv on Mac OS X

2011-12-10T00:00:00-08:00

rbenv is a quick way to get different ruby versions installed on your OS, without interfering with any default installs it may provide.

Run the following commands:

brew update
brew install rbenv
brew install ruby-build

In your bash profile file, ensure that the following is included:

eval "$(rbenv init -)"

Now, install the latest version of ruby:

rbenv install 1.9.3-p0

Run the following to set rbenv to use this new version of ruby.

rbenv global 1.9.3-p0

Open a new shell and type ruby --version and if you see ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin11.2.0] then all is good and you're all setup!

One thing to note is that if you install a new gem that installs a binary, you'll need to run rbenv rehash afterwards in order for the binary to become available to you on the command line.

Getting started with Behat

2011-11-06T00:00:00-07:00

Where PHPUnit is for testing the individual pieces of your code (unit testing), Behat is a great tool for testing that an application behaves as expected when following a series of steps (functional testing). And for testing web applications, Behat ties in perfectly with Mink to give you a bunch of web browser related tests out-of-the-box.

Install

We'll be using composer to setup Behat and Mink. Create a composer.json file in your project directory with:

{
    "require": {
        "behat/behat": ">=2.2.4",
        "behat/mink": ">=1.3.2"
    },

    "repositories": {
        "behat/mink-deps": { "composer": { "url": "behat.org" } }
    },

    "config": {
        "bin-dir": "bin/"
    }
}

If you don't have the composer.phar file already on your machine, simply run:

wget http://getcomposer.org/composer.phar

Then run:

php composer.phar install

Behat and Mink will then install into a vendor and bin directory.

In your project directory, run:

bin/behat --init

This will create a features directory for you that contains the required files to get started.

In order to setup Behat to use Mink, go into features/bootstrap/FeatureContext.php and make sure that the following is defined:

require_once __DIR__.'/../../vendor/.composer/autoload.php';

And:

class FeatureContext extends Behat\Mink\Behat\Context\MinkContext

Here you're including the Mink library, and then ensuring that FeatureContext extends from MinkContext. You don't really need to worry about what this file does for this example.

Now let Behat know where it can test your web app from. In the root of your project directory, create a file called behat.yml and include the following:

default:
  context:
    parameters:
      base_url: http://localhost/mywebapp/

This is a YAML file, and you just need to update the base_url value to whatever URL behat can access your app.

You're ready to start.

Describe your application with features

Run the following command:

bin/behat -dl

You should see a long list of available definitions that Behat currently has available to it. You can use these to write some powerful feature files that test your application.

First, lets set the scene:

Say on your homepage you have a login form and you want to make sure when someone logs in, they get directed to a dashboard page with a welcome message. You also want to check that when they logout, they are taken to the homepage with a confirmation message saying they've been logged out.

Each test file has the .feature extension that Behat uses to search for tests to run when calling the behat command.

These feature files are written in the Gherkin syntax. First of all you specify a particular feature you are testing. This is with the keyword Feature: and a name. After which, you add a brief description of what the benefit, the role, and the actual feature is. You can have anything here, but it's good practice to follow this format to make things readable.

For each feature, you have a bunch of different scenarios that you want to test against to ensure it matches the expected behaviour. Scenarios consist of definitions that can be prefixed with either Given, When, Then and And. These keywords don't mean anything, and are there purely to aid readability. Given is where you'd set a bunch of pre-conditions for your test, When for the steps taken to test, and Then should describe what expected result you should see. And can be used to include additional definitions per stage in a scenario.

Feature: User sessions
    In order to access their account
    As a user
    I need to be able to log into the website

    Scenario: Login
        Given I am on "/"
        And I should see "Login"
        When I fill in "email" with "myemail@test.com"
        And I fill in "password" with "mysecurepassword"
        And I press "Login"
        Then I should be on "/dashboard"
        And I should see "Welcome back"

    Scenario: Logout
        Given I am on "/dashboard"
        When I click on "Logout"
        Then I should be on "/"
        And I should see "Logged out"

Because we've written the steps in the available Mink definitions, we don't need to write any PHP code! You can now run bin/behat in the Terminal and you'll see the result of the tests and whether your application conforms to them--all lit up in green!

These example tests may seem rather trivial, but having them means you have a safety net for your application, so that if you or someone changes something, however small or large to your code, and it breaks the expected application behaviour, your Behat tests will let you know sooner, when it's easy to fix, rather than later when it'll become a nightmare to track down.

As an aside, it should be noted that Behat isn't just great for us developers. If you're working on a project for someone else, you can write up these feature files based on a clients spec, and get them to sign off of them for extra security and peace of mind for all parties.

With the available definitions that Mink provides for Behat, you could quite easily write a ton of tests with just the definitions Mink provides. In a future blog post I'll go on further to show how to write custom defintitions. Hopefully this is enough information to get you started and excited about using Behat in your projects.

Setting up Github Pages

2011-10-29T00:00:00-07:00

I've not had time recently to keep my copy of Wordpress up-to-date (yes, even though it's setup with SVN). I wanted something a little easier to manage. Having read good things about Github Pages, I decided to take the plunge. I've now migrated this entire site over. It's simple to setup, and also has Jekyll support enabled by default.

Jekyll allows you to generate a static website from plain text post files, and templates. When you push your new posts to Github, Jekyll is run on the files and the static site is built and hosted for you.

Setup

To get started, install jekyll:

sudo gem install jekyll

If you want to use Markdown formatting in your posts, also install:

sudo gem install rdiscount

Now you'll need to create a git repository to manage your blog. There is a great Jekyll skeleton setup that I used here, so we'll go ahead and clone that.

git clone https://github.com/danielmcgraw/Jekyll-Base.git yourgithubusername.github.com

Be sure you replace yourgithubusername with your Github username. This isn't required on your local repo, but is for the repository you create on Github. It's in this format so that Github can detect it's a Github Pages site, and so it just makes sense to name it the same locally too.

Now, we don't want the git history for this skeleton setup, so remove the .git directory:

cd yourgithubusername.github.com/
rm -rf .git

To test things are working at this stage, open another terminal window in the same directory and run jekyll --server. It keeps a process open, along with a webserver running on port 4000, monitoring file changes, and rebuilding the site automatically on the fly. So you'll want to keep this terminal window open and running. You should now be able to see the generated site by visiting http://localhost:4000

When jekyll builds the site, it puts the generated files into a _site directory. You don't want this directory in Git, so in the .gitignore file add _site to the bottom so that it'll be ignored.

Now on Github, create a new repository naming it in the same format yourgithubusername.github.com. Then on your local machine:

git init
git add .
git commit -m "Initial commit. Jekyll base setup."

Then follow Github's instructions on adding the remote reference, which is along the lines of (substitute username):

git remote add origin git@github.com:username/username.github.com.git
git push -u origin master

This pushes your site up to Github. After this initial push you can do a plain old git push when you've made changes that are ready to be published.

They say it can take up to 10 minutes for new sites to be generated when they are first pushed, however, it'll likely be under a minute. They'll email you either way when it's done.

You can then visit http://yourgithubusername.github.com to see your new static site all built, and being served. Snappy isn't it?

Wordpress migration

There were two important things that I wanted to ensure kept the same during the migration to Github pages; the URLs for the posts, and the comments posted.

My permalink structure on Wordpress was:

/articles/%year%/%monthnum%/%day%/%postname%/

So to set this up on Jekyll, all I had to do was edit _config.yml and set:

permalink: /articles/:year/:month/:day/:title/

For comments, I had already been using Disqus on my Wordpress install, so they already had that content. All I had to do was setup the Javascript to pull in those comments. In the _layouts/post.html file, all I did was add:

<div id="disqus_thread"></div>
<script type="text/javascript">
    /* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */
    var disqus_shortname = 'davidwinter'; // required: replace example with your forum shortname
    var disqus_url = 'http://davidwinter.me{{ page.url }}';

    /* * * DON'T EDIT BELOW THIS LINE * * */
    (function() {
        var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
        dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js';
        (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
    })();
</script>
<noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
<a href="http://disqus.com" class="dsq-brlink">blog comments powered by <span class="logo-disqus">Disqus</span></a>

The important stuff here is the disqus_shortname and disqus_url variables. These are required in order for Disqus to know which site comments to display, and the disqus_url to know which page comments to render. Because my URLs are staying the same, this was easy by just using the domain and the {{ page.url }} variable.

While you're setting this up locally, you may want to include:

var disqus_developer = 1;

As the help documents explain:

Tells the Disqus service that you are testing the system on an inaccessible website, e.g. secured staging server or a local environment. If disqus_developer is off or undefined, Disqus' default behavior will be to attempt to read the location of your page and validate the URL. If unsuccessful, Disqus will not load. Use this variable to get around this restriction while you are testing on an inaccessible website.

Be sure that this is only set while testing the integration of Disqus. When you know it's working locally, remove this variable, so that it doesn't get pushed up to Github.

And also, ensure that your yourgithubusername.github.com address is added to your trusted domains list in the Disqus admin.

One last thing that is quite important to bring over to my new Github Pages setup is all of my old posts... duh. Depending on the size of your existing blog, you may just want to do this by hand. However, with 50+ posts, I wanted something automated.

In Wordpress, you can do an export of your posts under the Tools section of the left hand menu. Just select to export the posts, not all content, as you don't need it.

I wrote a quick PHP tool to convert this exported data into Jekyll friendly post files. Once these have been generated, you can copy them into your _posts directory, and Jekyll will generate the pages (if it's still running).

Push up to Github, and you're all set. Just tinker around with the layouts and styling and you'll then have a super fast, easy to manage, Jekyll powered Github Pages site.

Simple local web development with Apache and Dnsmasq

2011-06-18T00:00:00-07:00

When you sit down and start work on a new project, what hoops do you have to jump through before you get your app running in your browser? There are more than likely always going to be two; creating a spoof domain that you create in /etc/hosts so that you can access your app, and then a virtual host in Apache to make your files accessible. And it sucks having to do this each time. Don't you wish you could just get on with the project as soon as you think of it? Read on.

This was all inspired by Pow, a zero-configuration rack server created by 37signals, that allows Rails developers to do exactly that. By following convention over configuration, this can all be easily achieved. If you're happy with accessing your apps via a spoof domain ending in .dev, then follow these steps.

Requirements

I'm assuming that you've got Homebrew installed, and that you're using the built-in version of Apache on Mac OS X 10.6 Snow Leopard. However, these instructions should work fine on Linux too.

Dnsmasq

Dnsmasq is a simple to install and setup mini DNS server. We'll use it to setup a wildcard record of anything .dev to point to your local machine.

brew install dnsmasq

Follow the instructions after install about copying the configuration file to the expected place in /usr/local/etc/dnsmasq, but don't copy the launchd settings yet. First of all edit /usr/local/etc/dnsmasq and add the following at the very bottom:

address=/dev/127.0.0.1
listen-address=127.0.0.1

Save. Now copy the launchd settings across. Dnsmasq should now be running. You now need to tell your system to use it as a DNS server.

Open up System Preferences and go to your Network settings and the DNS servers. Add 127.0.0.1 to the top of the list, and then add whatever your normal internet facing DNS servers are beneath. I use OpenDNS. My DNS server list then looks like:

127.0.0.1
208.67.222.222
208.67.220.220

Apply changes. Now open the Terminal and run a ping on anything ending with a .dev:

ping test.dev

It should start pinging your machine, 127.0.0.1 - if it does, all is good.

Now we can move onto configuring Apache for the last time.

Apache

Edit the following file, substituting yourusername with whatever your system username is:

sudo nano /etc/apache2/users/yourusername.conf

And then make it look like the following, again replacing yourusername:

NameVirtualHost *:80

<Directory "/Users/yourusername/Sites/">
    Options Indexes MultiViews FollowSymLinks Includes
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

<VirtualHost *:80>
    UseCanonicalName off
    VirtualDocumentRoot /Users/yourusername/Sites/%0/public
</VirtualHost>

Save. And then run sudo apachectl graceful. This will restart Apache. In the above configuration, we're using Apache's mod_vhost_alias module to dynamically configure virtual hosts and document roots on the fly.

Testing it all works

mkdir -p ~/Sites/test.dev/public
echo "test.dev" > ~/Sites/test.dev/public/index.html

Now visit http://test.dev/ in your web browser. Hopefully you should see test.dev - if so congratulations; you're going to save so much time in the future now.

Setup UFW on Ubuntu 11.04

2011-06-05T00:00:00-07:00

Not much more than a few hours have passed since I posted my APF setup howto, but I've found something even simpler.

ufw - uncomplicated firewall. It does exactly as it says on the tin.

sudo aptitude install ufw
sudo ufw allow 22
sudo ufw enable

That's ssh sorted, and the firewall is enabled. It's important to allow port 22 first before enabling, otherwise you'll get locked out. You can see the status of the firewall by running:

sudo ufw status verbose

And to allow Apache traffic:

sudo ufw allow 80

That's it. Outgoing traffic is allowed by default. Everything else is blocked. Also, all of these rules are saved transparently, so you don't have to worry about things like that. Reboot away, and everything will just work.

If you need to disable ufw just run:

sudo ufw disable

Install APF on Ubuntu 11.04

2011-06-05T00:00:00-07:00

I just setup a new Linode to host my new twitter app, lists dj and wanted to lock it down to basically Apache and SSH.

iptables gives me a headache, and I don't want to spend a day learning how to use it. APF uses iptables, but the configuration is so much easier.

sudo aptitude install apf-firewall
sudo nano /etc/apf-firewall/conf.apf

If you're using Linode, you'll need to ensure the following line and configuration value is set:

SET_MONOKERN="1"

This is because iptables is installed into the kernel rather than as a package. Not setting this will prevent APF from running.

Then, to open the desired ports, just update this line with the port numbers, separated with a space:

IG_TCP_CPORTS="22 80 443"

And ensure this line is set:

DEVEL_MODE="0"

This means that the firewall isn't in development mode, otherwise your rules will be flushed every 5 minutes. Handy if you're experimenting with new rules and don't want to be locked out of your server. Worse case, you'd only have to wait 5 minutes before being able to get back in. But because I'm only opening ports, I don't need this. Just make sure you leave your SSH port open!

Lastly, open up this file:

sudo nano /etc/default/apf-firewall

And set it to:

RUN="yes"

Now you can start up APF and you're all protected:

sudo /etc/init.d/apf-firewall start

PHP development on Mac OS X 10.6 Snow Leopard

2011-05-27T00:00:00-07:00

Having a reliable and easy to use developer environment on my Mac is essential for my work, and the odd project I work on.

I original used the Entropy PHP packages as they were so easy to install, and just worked. Unfortunately, Marc Liyanage had stopped updating the packages with new OS X releases, so I then tried alternatives such as Macports, and more recently MAMP. However, it hasn't been working out of late, so I went in search of alternatives.

For a long shot, I visited Marc's PHP page and noticed that he is now endorsing a project which forked off from his own. Like his packages, it uses the default Apache install that comes with OS X, but uses their own alternative PHP package. It installs into /usr/local so that it doesn't interfere with anything else. So here are some steps to get this all up and running.

Setup

Before I started, I uninstalled Macports and MAMP. Not required, but I didn't want any of those packages to interfere or conflict with the new install of PHP. I now use homebrew as a replacement to Macports for tools that I require (such as MongoDB and MySQL).

Install PHP for OS X

Install PHP via http://php-osx.liip.ch:

curl -s http://php-osx.liip.ch/install.sh | bash -

It'll ask for your password so that it can install to /usr/local. If you're cautious of running a shell script from a webpage--as you should be!--why not view the source in your browser first to be sure all is as it should.

Setup path

If you want to use any of the PHP tools via the command line, such as pear or pecl, it's best if you add the new PHP bin to your path. I updated mine to:

export PATH="/usr/local/php5/bin:/usr/local/bin:$PATH"

The important part here is the inclusion of /usr/local/php5/bin. You'll then want to open a new terminal window so that the path update takes effect. Check by running:

echo $PATH

If you're going to use pear or pecl, it may be worth checking that it's configured to use the correct php.ini file.

Run the following command:

pear config-get php_ini

If it doesn't say:

/usr/local/php5/lib/php.ini

Then run:

sudo pear config-set php_ini /usr/local/php5/lib/php.ini

And then just check that pecl has the same config set:

pecl config-get php_ini

That should now be PHP setup and running.

Easy Apache configuration

With some great pointers by Roger Johansson here is a great way to make configuring Apache easy for projects you work on. You'll need to edit two files. One will make some hostname aliases to your local machine so that you can access a project via a url such as http://myproject.local. The other file is the Apache configuration file for your user, where you specify the server name and document root location. Here we go:

Edit /etc/apache2/users/yourusername.conf substituting yourusername with the actual username you use on your Mac. Update it so that it looks like this (again updating the path with your actual username):

NameVirtualHost *:80

<Directory "/Users/yourusername/Sites/">
    Options Indexes MultiViews FollowSymLinks Includes
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

<VirtualHost *:80>
    ServerName myproject.local
    DocumentRoot /Users/yourusername/Sites/myproject.local
</VirtualHost>

Now edit /etc/hosts and add to the bottom:

127.0.0.1    myproject.local

Now reload Apache, and you should be all set:

sudo apachectl graceful

You're all set now! Hopefully this will make PHP development easier for you, as it has done for me.

Merging MKV files together

2011-05-21T00:00:00-07:00

mkvmerge -o merged_file.mkv file1.mkv + file2.mkv

Mod rewrite rules in htaccess files

2011-02-08T00:00:00-08:00

Rewrite rules in an htaccess file don't need to leading slash, otherwise they won't work.

Be warned. Don't waste two hours wondering why it isn't working.

Authentication with CodeIgniter 2.0

2011-01-29T00:00:00-08:00

I've started using CodeIgniter again recently, and have noticed that my how-to on implementing basic authentication could do with an upgrade for version 2.0.

The process is identical. We subclass the base CI_Controller class. This simply checks whether a logged in session is present. If not, it redirects the user to a sessions controller that can handle the logging in of a user. Once the user is logged in, the controller acts as normal.

So, first up, lets create our basic subclass:

<?php

class MY_Controller extends CI_Controller 
{
    function __construct()
    {
        parent::__construct();

        $this->load->library('session');

        if (!$this->session->userdata('loggedin'))
        {
            redirect('sessions/login');
        }
    }
}

Now, this needs to be saved to application/core. This is important. You can't add it to application/library like with the previous how-to. There have been some changes to CI that require the change. This new class is also auto-loaded automatically.

Now, the sessions controller needs to extend CI_Controller. Users don't need to be authenticated to access this controller.

<?php

class Sessions extends CI_Controller
{
    function __construct()
    {
        parent::__construct();

        $this->load->library('session');
    }

    function login()
    {
        $this->load->view('header');
        $this->load->view('login');
        $this->load->view('footer');
    }

    function authenticate()
    {
        $this->load->model('user', '', true);

        $user = $this->input->post('user');

        if ($this->user->authenticate($user['email'], $user['password']))
        {
            $this->session->set_userdata('loggedin', true);
        }

        redirect('/');
    }

    function logout()
    {
        $this->session->unset_userdata('loggedin');

        redirect('/');
    }
}

Your login view will look something like this:

<h2>Login</h2>
<?php echo form_open('sessions/authenticate'); ?>
    <dl>
        <dt><?php echo form_label('Email', 'user_email'); ?></dt>
        <dd><?php echo form_input(array(
            'name' => 'user[email]', 
            'id' => 'user_email'
        )); ?></dd>

        <dt><?php echo form_label('Password', 'user_password'); ?></dt>
        <dd><?php echo form_password(array(
            'name' => 'user[password]', 
            'id' => 'user_password'
        )); ?></dd>
    </dl>
    <ul>
        <li><?php echo form_submit('submit', 'Login'); ?></li>
        <li><a href="<?php echo site_url('/'); ?>">Cancel</a></li>
    </ul>
<?php echo form_close(); ?>

Here's a basic user model you could use. It includes hashing with extra salt security:

<?php

class User extends CI_Model
{
    public function authenticate($email, $password)
    {
        // get salt

        $salt = $this->db->select('salt')->get_where('users', array('email' => $email))->row()->salt;

        if ($salt)
        {
            // hash password with salt and find user

            $hash = sha1($salt.sha1($salt.$password));

            $user = $this->db->select('id')->get_where('users', array(
                'email' => $email,
                'hash' => $hash
            ))->row();

            return $user;
        }

        return false;
    }
}

Now all that's left is to change the parent classes of the controllers that we want protected from CI_Controller to MY_Controller.

<?php

class Admin extends MY_Controller
{
    ...

Authentication is now in place.

A simple chat room with WebSockets

2010-11-21T00:00:00-08:00

Sorry, I promised a blog post, but instead you get a link to bitbucket with the source of a basic chat app written using WebSockets.

https://bitbucket.org/davidwinter/websockets-chat/src

Using Capistrano to deploy Mercurial changes

2010-08-22T00:00:00-07:00

We have a few production servers at work, and we have a central bitbucket repository to store our core code. Once we make a change on our testing server (!), we used to have to commit, push changes to bitbucket, and then ssh into each server, then pull changes, and update each repository. A pain in the backside! Enter Capistrano. A ruby ssh automation tool. In a few simple steps you can create a recipe file that will let you do this all with one command.

On the machine where you'd like to kick this all off---where you'll be pushing the changes from---install Capistrano (requires Ruby and RubyGems to be installed):

sudo gem install capistrano

Capistrano is opinionated software; meaning it makes a few assumptions about your server setup which you'll need to comply with. Mainly that either you have public key authentication setup to connect to these remote servers, or, you use the same password across all of them.

Now, create a capfile, perhaps in your home directory, and here is an example that you can modify for your own setup:

role :production_servers, "srv1.internet.com", "srv2.internet.com"

task :push_deploy, :roles => :production_servers do
    system "cd /local/path/to/repos && hg push"
    run "cd /remote/path/to/repos && hg pull && hg update"
end

With that now saved, you can issue this task with the following command:

cap push_deploy

This will first of all run a local command to push the changes to bitbucket. After that is complete, it'll connect to each of the production servers listed, pull changes and then update the repository. And that's it. You don't need to do anything else. Piece of cake.

SSH and public key authentication

2010-08-22T00:00:00-07:00

Fed up with having to type your password in each time you log into a server over SSH? Me too. Down with passwords, and in with public key authentication!

First thing to do, is to check that you have a SSH key setup already on your local computer:

cd ~/.ssh
ls

If you see some files in there starting with id_, like id_rsa.pub or id_tsa.pub, you're all set. If not, you'll need to generate these files:

ssh-keygen -t rsa

At the prompts you see, you can just hit enter to accept the defaults.

With your public key now in place, we need to transfer that to the server we want to log into.

scp ~/.ssh/id_rsa.pub username@remote.server.com:

Don't forget the colon at the end. This has now transfered the public key over. Now you need to log into the remote server (with your password - last time, I promise):

ssh username@remote.server.com

Now, check if there is a .ssh directory on the remote server in your home directory:

cd ~/.ssh/

If there isn't:

mkdir ~/.ssh

Now move the public key to a file named authorized_keys:

mv ~/id_rsa.pub ~/.ssh/authorized_keys

Now we need to set the correct permissions to ensure no one can tamper with these files:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

And you're done. Now you can logout, and log back in again - and all going well (if your SSH server has been setup correctly - by default it usually is), you won't be prompted for a password.

If it doesn't work, one problem I encountered was where the actual home directory permissions weren't set to 700. So try:

chmod 700 /home/username

All done.

Setting up SSH host shortnames

2010-08-22T00:00:00-07:00

Here's an example setup to create SSH host shortnames. On you local computer, add the following to ~/.ssh/config:

Host server1
HostName server1.internet.com
User david

Host server2
HostName server2.internet.com
User david

Host *
User davidwinter

Now with this file saved, you can ssh into server2.internet.com with just the following command:

ssh server2

This will save you having to type out:

ssh david@server2.internet.com

And if you have public key authentication setup, it makes the process even smoother. Adding the wildcard host record at the bottom allows you to specify a default username to use for other servers to the ones you've not specified above.

Using o2 PAYG mobile broadband

2010-06-19T00:00:00-07:00

Our internet connection via our landline has been dead since Tuesday afternoon, so I've needed an alternative connection in the meantime to give me my twitter fix!

I'd kept an eye on the o2 pay-as-you-go mobile broadband for a while, because it offered the cheapest, noncommittal setup. A one off £20 for the USB dongle, and then as little as £2 for 500MB for a 24 hour period.

So I plug in the dongle and we get a nice little installer to set everything up; installing drivers and the o2 Mobile Connect application. The annoying thing is that if you install going this route, you can only connect if you have this app open. You can't just use system preferences. Also, turns out this 'handy' installer program then blocks you from getting to the installation files again, and the dongle will refuse to do anything unless Mobile Connect is open (you'll get a red light on the dongle when it's being evil).

So, what can you do?

Drag Mobile Connect.app to the trash from your Applications directory.
Then head into System > Library > Extensions and delete ZTEUSBCDCACMData.kext and ZTEUSBMassStorageFilter.kext
Go into Network in System Preferences and remove the devices starting with ZTEUSB.
Then restart your Mac.

Now, let's install things a different route giving everyone more flexibility.

Plug in the dongle and when the CD Icon appears on the desktop, open it up, but rather than double clicking on the installer, right click on it and select 'Show Package Contents'.
Now head to Contents then Resources. Now double click on the drv.pkg file and install this only.
Once complete, restart your Mac again.

And now to configure the connection:

Open System Preferences, and go to the Network pane.
You should have three new items in there. Click on ZTEUSBModem.
Set the telephone number to *99#
Username to o2bb
Password to password
Click on Advanced. Select Vendor; Generic, Model; GPRS (GSM/3G) and set the APN to m-bb.o2.co.uk
Click on OK and then Apply.
Now you can click 'Connect' and all should work fine.

That is of course, besides the crappy image compression and caching o2 force onto you! Need to find a solution for that next.

Update: Here's a solution for getting around the image compression, and Javascript injection; use a SSH SOCKS proxy. Works a treat.

Open up Terminal.app
Run ssh -ND 9999 username@yourserver.com
Enter your password if/when prompted (you may have key authentication setup)
That's the SOCKS proxy setup. Now go to System Preferences and open the network connection.
Click on ZTEUSBModem.
Then Advanced, Proxies
Check the SOCKS Proxy and enter in localhost and 9999
Click OK and then Apply.

All done. You should now get perfect images and no longer have Javascript inserted into all webpages. Both of which weren't clearly mentioned when purchasing my dongle.

Redirecting Apache traffic to a maintenance page

2010-05-03T00:00:00-07:00

Here's a simple solution to redirect users to a maintenance page in Apache. This rewrite rule can stay in your config (<VirtualHost> or .htaccess) all the time; all that you need to enable it is to create the file maintenance.html.

The first rewrite condition checks to see if the file exists, and only if it does, will it redirect all traffic to it. The second rewrite condition is there to prevent an infinite loop, by only redirecting traffic to files other than maintenance.html.

RewriteEngine On

RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteCond %{REQUEST_FILENAME} !/maintenance.html
RewriteRule ^.*$    /maintenance.html [L]