My RSS » Items by Stuart Herbert

Items by Stuart Herbert

PHPUnit Plugin For Sublime Text 2

Posted: February 4th, 2012, 11:57am MST by Stuart Herbert

Sublime Text 2 is a new cross-platform text editor that I’ve recently switched to. It’s still in public beta, but already offers better performance (and battery life!) and a better look (fonts that render properly!) than Java-based IDEs such as Netbeans.

One thing it didn’t have was support for PHPUnit, so I’ve made a plugin. It’s available to install via Package Control.

You Need A phpunit.xml or phpunit.xml.dist File

To use this plugin, your project needs to contain either a phpunit.xml or a phpunit.xml.dist file. This file contains all the configuration that needs to be passed to PHPUnit. The plugin searches upwards from your code, and will favour a phpunit.xml file over a phpunit.xml.dist file if it finds both.

If you don’t have one, you need to go and create one now.

How To Use

If you have your code open in a Sublime Text 2 window, right-click inside the window to see what your options are:

Test This Class – click this option to run just the unit tests for this class.
This option appears if the PHPUnit plugin can find your unit tests. It takes the name of your class, and uses the standard PSR-0 transformation to figure out what the name of your test file should be.

For example, if your class is called ‘Phix_Project\CommandLineLib\CommandParser.php’, the PHPUnit plugin will search for a file ‘CommandLineParserTest.php’ that’s in a folder called ‘Phix_Project/CommandLineLib’.
Open Test Class – click this option to open up your tests in Sublime Text 2. If you already have the tests open, this will switch tabs to your tests.
Again, this option only appears if the PHPUnit plugin can find your unit tests.
Run All Unit Tests – click this option to run all the unit tests for your code.
This option just points PHPUnit at your phpunit.xml or phpunit.xml.dist file.

If you have your tests open in a Sublime Text 2 window, right-click inside the window to see what your options are:

Run These Tests – run these unit tests, using the phpunit.xml or phpunit.xml.dist file that the PHPUnit plugin has found.
Open Class Being Tested – open the class that these tests are for in Sublime Text 2. If you already have the class open, this will switch tags to your code.
Run All Unit Tests – click this option to run all the unit tests for your code.

If you’re someone who prefers keyboard over mouse, then you’ll probably want to run the PHPUnit plugin commands from Sublime Text 2′s Command Palette:

You get the same commands that appear on the right-click menu … the right commands will appear for the file that you’re currently editing, just as you’d expect.

Finally, you can also right-click on your phpunit.xml (or phpunit.xml.dist) file in the Project Sidebar, and run your unit tests using that specific config file.

Helpful Snippets

Like TextMate before it, Sublime Text 2 also has a handy snippets feature, where it can insert a pre-crafted block of text (or, in our case, PHP code) to speed up your coding. I’m collecting most PHP-related snippets in my Additional PHP Snippets plugin (hat-tip to Rob Allen for the inspiration for this), but the PHPUnit plugin includes a few PHPUnit-related snippets to help.

phpunit-testcase – will create a new test class for you to fill out.
I find this handy mostly so that I don’t have to remember which class my test class has to extend :)
phpunit-test – will

Truncated by Planet PHP, read more at the original (another 664 bytes)

Phix 0.15 Released

Posted: January 31st, 2012, 1:00am MST by Stuart Herbert

Phix v0.15 is now available from pear.phix-project.org.

This release is dedicated to my Dad, Leslie Herbert, who passed away in December 2011 whilst I was recovering from surgery. He was always encouraging me to spend as much time as possible working on my own software, and I’m sure he’d be happy that his PC has become my new dev box for working on things like Phix.

What’s New In This Release

phploc support – the “phing code-review” command now also calculates the size of your component using phploc.
subset support – you can now do “phix php-library:init –subset=<role>[,<role> ...]” to create components that only contain some of the different file types supported by the PEAR Installer. There’s also a “phix php-library:removeunusedroles” command if you want to strip unused roles from an existing component.
phpunit.xml.dist support – components now use phpunit.xml.dist by default, so that you can put your own phpunit.xml in place if you ever need to override the default settings.
src/README.md – we now drop a (hopefully helpful) README file inside the src/ folder to explain what goes where.
misc robustness improvements to build.xml files – I’ve made some small tweaks to the build.xml file to try and catch a few error conditions and display helpful messages.
internal debugging – “phix -d …” (which has been documented for several release now) enables internal debugging tests inside Phix and its components. It’s mostly there for me to use, but I thought I’d mention it in case you’re testing a patch for phix before sending it to me.

A big thanks to everyone who attended my workshop at PHPNW11 in October for their feedback and feature requests for this release.

How To Install

To install Phix, we have handy one-line install scripts on the Phix project homepage. And I’ve put together a screencast of how to install Phix on Ubuntu. It’s my first ever screencast, so please be gentle :)

How To Upgrade

To upgrade from an earlier release of Phix, please do the following:

sudo pear clear-cache
sudo pear upgrade phix/phix4componentdev

Once you’ve upgraded phix itself, don’t forget to go into each of your components, and run

phix php-library:upgrade .

to upgrade all of the skeleton files (build.xml et al) for your component.

What’s Coming In Phix 0.16

Windows support hasn’t happened yet, but I hopefully have a volunteer who is going to look into that during February.

My priority for phix-0.16 is to make it easy to build phix-based components in Jenkins, based on Sebastian’s Jenkins Template. I’m doing this next because I’m not sure how much I’ve got to change things to suit Jenkins, so I’d rather get it done sooner so it’s done and out of the way. (And I promise that I haven’t forgotten docblox support either …)

Our roadmap has all the details.

Comparing ContractLib to PHP’s Built-In assert()

Posted: January 17th, 2012, 1:30am MST by Stuart Herbert

One of the questions I’ve been asked after yesterday’s blog post about Phix’s ContractLib is why not just use PHP’s built-in assert() function? I think it’s a great question, and the best way to answer it is to take a look at the key differences between two solutions.

Side By Side Comparison

Feature	assert()	ContractLib
Implementation	PHP extension written in C (ships as standard part of PHP)	PHP library written in PHP
Enable / disable execution	Partial (there is an overhead when disabled, but it’s low)	Partial (there is an overhead when disabled, but it’s higher)
Issues PHP4-style warning when tests fail	Yes (configurable)	No (throws a ContractFailedException instead)
Terminate PHP script when tests fail	Yes (configurable)	Only if the ContractFailedException is never caught
Quiet eval of test expression	Yes (configurable)	No (not required; test expressions are pure PHP code, not eval() strings)
Callback on failed test	Yes (configurable)	No (unwinds the stack instead by throwing ContractFailedException)
Throws Exception when tests fail	No (but can emulate if you write your own assert() callback method)	Yes (standard behaviour)
Tests are pure PHP code	No – recommended way is to pass strings into assert() to be eval()’d	Yes
Error report includes original value that failed the test	No	Yes
Support for per-test custom failure messages	No	Yes – are required to provide one
Support for Old Value storage and recall	No (but can emulate by hand)	Yes

The Differences Explained

The key difference is one of philosophy. assert() sits well with the PHP4 style of error reporting and handling, whereas ContractLib is firmly in favour of the OO world’s approach to reporting errors.

It’s a personal preference, but I think that PHP4-style errors have no place in code that has any desire to be robust. Exceptions aren’t perfect, don’t get me wrong, but their core property of unwinding the call stack in an orderly fashion makes writing robust code much easier. And they also carry a payload – information about what went wrong and why – which PHP’s assert() cannot provide to the same extent.

It’s much quicker to debug something when there’s a record of the value that failed the test. For that reason alone, I’d always prefer something like ContractLib over the built-in assert() approach.

But we can’t ignore the fact that these are tests that get shipped to, and executed in, the production environment. Unlike unit tests, adopting programming by contract will slow down your PHP code in production. The question is: by how much?

What About The Performance?

I’ve done some benchmarking between the two, using the five tests listed in the final example in yesterday’s blog post. It’s a real-world example of the kind of tests that I would look to add to code to improve robustness.

Here are the results I gathered, calling the tests 10,000 times in a tight loop. The tests were run from the command line, and the times do include PHP start-up / shutdown time and the time taken to parse each test file. I assumed a best-case scenario, where the tests would always pass.

Test Approach	Time w/ Tests Disabled	Time w/ Tests Enabled
Tests written using assert()	1.103s (100%)	5.989s (543%)
Tests written using ContractLib	3.055s (277%)	3.096s (281%)

When tests are disabled, using assert() is much cheaper than using ContractLib today. That’s to be expected, as assert() is wr

Truncated by Planet PHP, read more at the original (another 1645 bytes)

Getting Started With ContractLib

Posted: January 16th, 2012, 1:30am MST by Stuart Herbert

In my last blog post, I introduced ContractLib, a simple programming by contract library that I’ve created for PHP 5.3 onwards. And I promised some examples :)

Installing ContractLib

ContractLib is available from the Phix project’s PEAR channel. Installing it is as easy as:

$ pear channel-discover pear.phix-project.org
$ pear install -a phix/ContractLib

At the time of writing, this will install ContractLib-2.1.0. We use semantic versioning, so these examples will continue to work with all future releases of ContractLib-2.x.

Adding ContractLib To Your Project

Assuming you’re using a PSR-0 compatible autoloader, just import the Contract class into your PHP file:

<?php

use Phix_Project\ContractLib\Contract;

Adding A Pre-condition Contract To Your Method Or Function

Take a trivial method like this:

<?php

class ActionToApply
{
    public function appendNow($params)
    {
        $params[] = time();
    }
}

This method works fine … until someone passes a non-array as the parameter. At that point, your code stops working – not because your code is wrong, but because someone used it in the wrong way. This is a classic cause of buggy PHP apps. Thankfully, it’s very easy to address using ContractLib.

If we were certain that the $params parameter was always an array, then we can keep the method itself extremely simple and clean. We can ensure that by adding a pre-condition using ContractLib.

<?php

use Phix_Project\ContractLib\Contract;

class ActionToApply
{
    public function appendNow($params)
    {
        Contract::Preconditions(function() use ($params)
        {
            Contract::RequiresValue(
                $params,
                is_array($params),
                '$params must be an array'
            );
        });

        // original method code continues here
        $params[] = time();
    }
}

Now, if someone passes in a non-array, the caller will automatically get an E5xx_ContractFailedException, which makes it clear that the fault is in the caller’s code … not your’s.

PHP 5.4′s upcoming support for better type-hinting is another way to catch this kind of error, but not only does ContractLib work today with PHP 5.3 (which means you don’t have to wait to migrate to PHP 5.4), but also that you can write tests for anything, not just the checking that’s built into PHP.

This means you can make your code much more robust, by tightening up on the quality of the parameter passed into your code by other programmers. To extend our example, we might decide that an empty array is also unacceptable:

<?php

use Phix_Project\ContractLib\Contract;

class ActionToApply
{
    public function appendNow($params)
    {
        Contract::Preconditions(function() use ($params)
        {
            Contract::RequiresValue(
                $params,
                is_array($params),
                '$params must be an array'
            );
            Contract::RequiresValue(
                $params,
                count($params) > 0,
                '$params cannot be an empty array'
            );
        });

        // original method code continues here
        $params[] = time();
    }
}

The point here is that we can go way beyond type-hinting checks (important as they are) and look inside parameters to make sure they are suitable.

Here’s a real example from Phix’s CommandLineLib:


use Phix_Project\ContractLib\Contract;

class CommandLineParser
{
    // ...

    public function parseSwitches($args, $argIndex, DefinedSwitches $expectedOptions)
    {
        // catch programming errors
        Contract::Preconditions(function() use ($args, $argIndex, $expectedOptions)
        {
            Contract::RequiresValue(
                $args,
                is_array($args),
                '$args must be array'
            );
            Contract::RequiresValue(
                $args,
                count($args) > 0,
                '$args cannot be an empty array'
            );

            Contract::RequiresValue(
                $argIndex,
                is_integer($argIndex),
                '$argIndex must be an integer'
            );
            Contract::RequiresValue(
                $argIndex,
                count($args) >= $argIndex,
                '$argIndex cannot be more than +1 beyond the end of $args'
            );

            Contract::RequiresValue(
                $expectedOptions,
                count($expectedOptions->getSwitches()) > 0,
                '$expect

Truncated by Planet PHP, read more at the original (another 2318 bytes)

Introducing ContractLib

Posted: January 11th, 2012, 1:30am MST by Stuart Herbert

ContractLib is a simple-to-use PHP component for easily enforcing programming contracts throughout your PHP components. These programming contracts can go a long way to helping you, and the users of your components, develop more robust code.

ContractLib is loosely inspired by Microsoft Research’s work on the Code Contracts Library for .NET.

What Are Programming Contracts?

Programming contracts are tests around functions and methods, and they are normally used:

to catch any ‘bad’ data that has been passed into the function or method from the caller, and
to catch any ‘bad’ data generated by the function or method before it can be returned to the caller

These are pre-condition and post-condition tests, and they are tests that either pass or fail.

Why Have Programming Contracts?

Two reasons: code robustness and time saved.

Programming contracts catch errors early, and (unlike unit tests) they don’t just catch your errors, they catch errors made by programmers who reuse your code.

Catching errors early
There is a class of bugs best described as garbage in, garbage out. The “garbage in” is data that is of the wrong type, or out of range, or missing (think empty arrays, empty strings, nulls). Often, the garbage being fed in is also garbage that has come out of a buggy function or method.

Simple pre-condition checks at the start of your functions and methods quickly catches garbage data before it can propagate through your code. The more functions and methods contain pre-condition checks, the easier it becomes to catch garbage data closer to where it is being created. This allows you to spend less time tracking down the original source of a bug, and more time writing new code.

These pre-conditions also greatly increase the chances of bugs in your code being caught in development, especially when combined with a healthy amount of unit testing.

You can also add post-conditions at the end of your functions and methods, to make sure that you’re never returning any garbage back out of your function or method. There’s a lot of overlap between post-conditions and unit tests; the main difference is that your post-conditions will run 100% of the time, whereas your unit tests will only run when you run them and against the (often extremely limited) data you use in your unit tests.
Catching errors when code is reused
Unit tests are great, and a very important part of creating high-quality code. But they’re your tests. They’re written to prove that your code does what you think it does.

Unit tests don’t prove that someone else is reusing your code the way you meant them to.

And neither do integration tests, because if someone is reusing your code, integration tests are their tests. Integration tests are tests to prove that they have glued their code on top of your code in a way that they are happy with.

Simple pre-condition checks at the start of your functions and methods are your best opportunity to test how someone else is reusing your code, and to tell them if they’re getting it wrong.

Programming contracts are about building trust (just like unit tests). Code that you can trust is normally code that is quicker to work with. They’re really quick to write (normally far quicker than unit tests), and they can make it really quick to track down the origin of bugs in your code.

Don’t Programming Contracts Make Code Stupidly Strict?

An appropriate amount of strictness is a requirement of all high-quality code. The trick is knowing what to be strict about. Not strict enough, and you let in shitty data that causes your code to fail or be insecure. Too strict, and people will think that your code is too much trouble to work with.

As a general rule, pre-conditions should check for:

data that’s in an incorrect format
data that’s out of range
data that’s missing

Post-conditions should check the same things. They can also be used to check for data that should have been changed, but hasn’t been changed.

Aren’t Programming Contracts Too Old-Fashioned For PHP?

The concept has been around for decades. As a C programmer, I first learned about programming contracts in the early 90′s, when I was writing code that had to run for months at a time with zero downtime. We were debugging and improving code dating back from the 1980′s, and introducing programming contracts played an important role

Truncated by Planet PHP, read more at the original (another 972 bytes)

Phix 0.14 Released

Posted: October 24th, 2011, 2:57pm MDT by Stuart Herbert

Phix v0.14 is now available from pear.phix-project.org.

What’s New In This Release

Snapshot versions of components – not ready to release a stable version of your component, but still need to publish your component to your PEAR channel for testing? You can now set the project.snapshot property in your build.properties file, and get non-stable packages for distribution.
Code coverage improvements – when you run phing test to run your component’s unit tests and generate the code coverage report, the code coverage report now automatically picks up all of your component’s PHP code, regardless of whether there is a test for it or not.
phpunit.xml support – phix now puts a phpunit.xml file inside your component, which includes all of the settings required to execute your component’s unit tests. This should help TextMate users a lot. This change was requested by attendees at the PHPNW11 conference.
More hooks in build.local.xml – for every target in your component’s build.xml file, you can now add “local.<target>” in build.local.xml, to perform any additional steps that you want to do. This feature was contributed by Martin Wernståhl.
Usability improvements – your component’s build.xml file now traps more errors than before, hopefully making it even easier to learn how to work with components.

How To Upgrade

To upgrade from an earlier release of Phix, please do the following:

sudo pear clear-cache
sudo pear upgrade phix/phix4componentdev

Once you’ve upgraded phix itself, don’t forget to go into each of your components, and run

phix php-library:upgrade .

to upgrade all of the skeleton files (build.xml et al) for your component.

What’s Coming In Phix 0.15

Phix 0.15 is all about making sure that Phix works as well on Windows as it already does on Linux and OSX. The feedback from the ZendCon session (which I was gutted to be unable to attend) was that there isn’t much needed, mostly setup instructions. Once that is done, we’ll continue to support Phix on Windows just as we already do on Linux and OSX.

Our roadmap for Phix 0.15 has all the details.

PHPNW11 Conference – The Other Photos

Posted: October 15th, 2011, 1:00am MDT by Stuart Herbert

The PHP North West User Group ran it’s 4th (and largest yet!) PHP conference – PHPNW11 in Manchester last weekend.

My last set of photos from PHP North West 2011 are the odd ones out, the ones that didn’t really fit into any of the other sets.

I hope you’ve enjoyed my photos from the conference, and maybe – just maybe – they’ve made you think about going to a PHP conference somewhere near you in the near future.

PHPNW11 Conference – The Organisers And Volunteers

Posted: October 14th, 2011, 1:00am MDT by Stuart Herbert

The PHP North West User Group ran it’s 4th (and largest yet!) PHP conference – PHPNW11 in Manchester last weekend.

No conference – especially one as well-run as PHP North West – can happen without the small army of folks who give up their time to organise and staff the conference. I’m afraid that I didn’t manage to photograph everyone involved on the day (sorry!) but here’s to everyone who made PHP North West 2011 possible.

PHPNW11 Conference – The Sponsors

Posted: October 13th, 2011, 7:00am MDT by Stuart Herbert

The PHP North West User Group ran it’s 4th (and largest yet!) PHP conference – PHPNW11 in Manchester last weekend.

This year, many of the sponsors were here not to drum up new business, but to hire new talent, continuing a trend from PHPUK11 earlier in the year. Sponsoring a conference is cheaper than paying traditional recruiters, with no shortage of motivated attendees to talk to.

Community tech conferences like PHP North West simply could not happen without the funds raised from the organisations who sponsor each conference. This short set of photos is my way, as a conference speaker, of saying thank you to every organisation who sponsored this year’s PHPNW conference.

PHPNW11 Conference – The Saturday Audience

Posted: October 13th, 2011, 1:00am MDT by Stuart Herbert

The PHP North West User Group ran it’s 4th (and largest yet!) PHP conference – PHPNW11 in Manchester last weekend.

The audience is a key part of any conference, and each year the PHP North West conference manages to attract more and more people back as it establishes its reputation for being one of the very best PHP conferences (and indeed, one of the very best UK tech conferences) around.

If you’ve never been to any PHP conference anywhere before, I hope these photos manage to show you just a little bit of the cracking atmosphere you’re missing out on :)

If you like these photos, please do let me know – leave a comment on my blog, or click through each photo to Flickr and leave a comment there. Thanks!

PHPNW11 – How To Dig Your Own Grave

Posted: October 12th, 2011, 1:00am MDT by Stuart Herbert

The PHP North West User Group ran it’s 4th (and largest yet!) PHP conference – PHPNW11 in Manchester last weekend.

This year’s conference line-up was particularly strong, both with the quality of speaker and the quality of topics, but there was one talk in particular that topped them all. It all began with Rowan’s laptop …

So Rowan had this laptop … but no matter how hard he stared at it, it just wasn’t going to work with the projector at the conference …

… so his friends rallied round and swaped his laptop for one that would work …

… the audience watches on with growing hilarity as Ben, Lorna and Ian try to get Rowan’s PDF slides presenting nicely in OSX’s Preview … only to be thwarted when the remote control for moving from slide to slide doesn’t work …

… in the end, Rowan press-gangs the conference’s keynote speaker into being his Speaker Slave (TM), advancing the slides forward on command throughout the talk.

Many speakers would have been destroyed by the sequence of problems, but Rowan successfully turned them into a great warm-up for what was without doubt the funniest talk all day.

PHPNW11 Conference – Saturday Speakers Photos

Posted: October 11th, 2011, 1:00am MDT by Stuart Herbert

The PHP North West User Group ran it’s 4th (and largest yet!) PHP conference – PHPNW11 in Manchester last weekend.

Once again there were three main tracks to the conference, a total of 15 speakers from both near and wide to choose from. New this year was the fourth track – the Unconference (perhaps lightning talks would be a better description tbh) organised by Elizabeth Naramore. Unfortunately, it was too dark in the Unconference to shoot handheld, but hopefully Rob Allen snagged some of the speakers from there during the day.

At times, I struggled in the main rooms too with the low light, so my apologies to those speakers I didn’t snag clean shots of this year.

These are my photos of all of the speakers from the main tracks on Saturday.

Derick’s talk on building extensions for PHP was so popular that there wasn’t room for me to get the door open far enough to snag a shot, sorry :(

Rowan’s talk deserves its own blog post and photo set, coming soon :-)

"/>

Truncated by Planet PHP, read more at the original (another 1543 bytes)

PHPNW11 Conference – Tutorial Day Photos

Posted: October 10th, 2011, 2:37am MDT by Stuart Herbert

The PHP North West User Group ran it’s 4th (and largest yet!) PHP conference – PHPNW11 in Manchester last weekend.

New this year was Tutorial Day: the opportunity to spend half a day or more in hands-on tutorials getting into the nitty-gritty of useful subjects such as Zend Framework 2, Security, Drupal, Web Services and Component Architectures.

These are my photos from the Tutorial Day.

Your Preparation For My PHP Components Session At #phpnw11 On Friday

Posted: October 4th, 2011, 12:00am MDT by Stuart Herbert

Coming to my Friday session Maintainable Applications In PHP Using Components at PHP NorthWest 2011 Conference? Great! I’m looking forward to meeting you.

And I have a little bit of prep work for you to do before the session, please :-)

This is a hands-on session, so make sure that you pack your laptop and its power supply!
Please get your dev environment setup and working before you leave – in particular, make sure that you have the latest version of phix (current 0.13.2) installed.
I’ve published installation instructions for:
If your operating system of choice isn’t one of those, there are also manual installation instructions on the Phix Project’s website.

There’ll be a few minutes at the start to help anyone having trouble with their development environment, (and I’m free all morning for anyone who needs longer) but because we only have about 3.5 hours to cover everything, anyone who turns up with a seriously fscked dev environment will be asked to pair-program for the rest of the session, sorry!
Have a clear idea what you need to get out of our afternoon session together.
Bring along a list of any questions you might have. Hopefully the session will cover most of these … the rest I’m sure we’ll cover in the bar afterwards!

I’m not expecting you to have read my series of blog posts about creating and maintaining packaged components of PHP code, but you will find the session easier to follow if you have.

Interested, but haven’t bought a ticket yet? Buy one now :-) In the US? I’ll be doing an all-day version of this session at ZendCon in mid-October together with Chris Hartjes.

Already using phix, and got ideas and suggestions to make it better? I’ll be around throughout the Saturday and Sunday of #phpnw11 (normally with my beloved Nikon at hand – that’s how to recognise me!), and I’d be delighted to get your feedback and discuss your ideas further.

PHP Components: Installing Phix on CentOS

Posted: October 3rd, 2011, 12:00pm MDT by Stuart Herbert

In my Beyond Frameworks talk, I explained how a component-based architecture can help answer some of the important (i.e. expensive!) questions you might face when creating long-lived apps that rely on a PHP framework. In this series of blog posts, I’m going to look at how to go about creating and working with components.

We’ve created a development tool, called phix, to make it as easy as possible to create and maintain your own components written in PHP. Phix is normally installed onto a development desktop or laptop; you would normally only need to install Phix on a server running CentOS if the server is a shared development server or a continuous integration server running something like Jenkins.

Follow these easy instructions to get phix installed on CentOS.

Using The One-Line Installer

The easiest way to get phix installed onto your CentOS server is to run the following command from a Terminal window:

curl -O [phix-project.org] ; su -c 'bash centos-6.sh'

This command downloads a simple shell script (which you can find on GitHub if you want to read it before trying it!), which is then run as the user “root”. The shell script:

Makes sure that you have a suitable version of PHP installed
Uses apt-get to install required dependencies
Uses the pecl command to install PHP extensions that we can’t get packaged for CentOS
Upgrades the PEAR installer to the latest version
Installs the package phix/phix4componentdev, plus dependencies, from the PEAR channel pear.phix-project.org

If all goes well, once everything has finished, run the following command and you’ll see that phix is now installed:

$ pear list -c phix | grep phix
phix                       0.13.2  stable
phix4componentdev          0.13.2  stable

Where To Find The Latest Installation Instructions

You can always find the latest installation instructions for phix on the Phix project’s website, including full instructions on how to do a manual install if you have trouble with our one-line installer.

We Need An Oktober(blog)Fest!

Posted: October 3rd, 2011, 8:00am MDT by Stuart Herbert

After Chris Shiflett‘s Ideas of March call earlier in the year, we had a fantastic period where the conversation moved from Twitter back to longer pieces on blogs.

Sadly, that has faded out once more. We need another blog revival.

To (slightly) paraphrase Chris’s original call, it’s very easy to take part in Oktober(blog)Fest:

Write a post called Oktober(blog)Fest.
List some of the reasons you like blogs.
Pledge to blog more the rest of the month.
Share your thoughts on Twitter with the #oktoberblogfest hashtag.
If we all blog a little more than we normally would this month, maybe we can be reminded of all of the reasons blogs are great.

Over in Germany, it’s currently the OktoberFest, where much beer gets consumed. And it just happens that October is also one of the important months in the PHP conference calendar … where much beer gets consumed :-)

There are two of the larger PHP conferences this month – PHP NorthWest 2011 and ZendCon.
If you go to either of these conferences, please blog about your experiences of the conferences, the topics you see and hear, and especially the fantastic ideas you come away with that you’re dying to try for yourself
Share the link to your conference blog post on Twitter with the #oktoberblogfest hashtag, so that we can all find and read your blog post.

It should be a great month of reading :-)

PHP Components: Installing Phix On Debian

Posted: October 3rd, 2011, 12:00am MDT by Stuart Herbert

We’ve created a development tool, called phix, to make it as easy as possible to create and maintain your own components written in PHP. Phix is normally installed onto a development desktop or laptop; you would normally only need to install Phix on a server running Debian if the server is a shared development server or a continuous integration server running something like Jenkins.

Follow these easy instructions to get phix installed on Debian.

Using The One-Line Installer

The easiest way to get phix installed onto your Debian server is to run the following command from a Terminal window:

curl -O [phix-project.org] ; su -c 'bash debian-6.sh'

This command downloads a simple shell script (which you can find on GitHub if you want to read it before trying it!), which is then run as the user “root”. The shell script:

Makes sure that you have a suitable version of PHP installed
Uses apt-get to install required dependencies
Uses the pecl command to install PHP extensions that we can’t get packaged for Debian
Upgrades the PEAR installer to the latest version
Installs the package phix/phix4componentdev, plus dependencies, from the PEAR channel pear.phix-project.org

If all goes well, once everything has finished, run the following command and you’ll see that phix is now installed:

$ pear list -c phix | grep phix
phix                       0.13.2  stable
phix4componentdev          0.13.2  stable

Where To Find The Latest Installation Instructions

PHP Components: Installing Phix On OSX

Posted: October 2nd, 2011, 12:00am MDT by Stuart Herbert

We’ve created a development tool, called phix, to make it as easy as possible to create and maintain your own components written in PHP. Apple OSX users might want to follow these instructions for setting up PHP et al on OS X 10.7 Lion first, before installing phix.

We assume that you’ve installed Xcode (which is free from the Mac Store)!

Using The One-Line Installer

The easiest way to get phix installed onto your shiny Macbook Air or Macbook Pro is to run the following command from a Terminal window:

curl [phix-project.org] | sudo bash

This command downloads a simple shell script (which you can find on GitHub if you want to read it before trying it!), which is then run as the user “root”. The shell script:

Makes sure that you have a suitable version of PHP installed
Upgrades the PEAR installer to the latest version
Uses the PECL command to install additional PHP extensions (this is what you need Xcode for!)
Installs the package phix/phix4componentdev, plus dependencies, from the PEAR channel pear.phix-project.org

If all goes well, once everything has finished, run the following command and you’ll see that phix is now installed:

$ pear list -c phix | grep phix
phix                       0.13.2  stable
phix4componentdev          0.13.2  stable

Where To Find The Latest Installation Instructions

PHP Components: Installing Phix On Fedora

Posted: October 1st, 2011, 10:00am MDT by Stuart Herbert

We’ve created a development tool, called phix, to make it as easy as possible to create and maintain your own components written in PHP. Follow these easy instructions to get phix installed on Fedora.

Using The One-Line Installer

The easiest way to get phix installed onto your Fedora box is to run the following command from a Terminal window:

curl [phix-project.org] | sudo bash

This command downloads a simple shell script (which you can find on GitHub if you want to read it before trying it!), and which is then run as the user “root”. The shell script:

Makes sure that you have a suitable version of PHP installed
Uses apt-get to install required dependencies
Uses the pecl command to install PHP extensions that we can’t get packaged for Fedora
Upgrades the PEAR installer to the latest version
Installs the package phix/phix4componentdev, plus dependencies, from the PEAR channel pear.phix-project.org

If all goes well, once everything has finished, run the following command and you’ll see that phix is now installed:

$ pear list -c phix | grep phix
phix                       0.13.2  stable
phix4componentdev          0.13.2  stable

Where To Find The Latest Installation Instructions

PHP Components: Installing Phix On Ubuntu

Posted: October 1st, 2011, 12:00am MDT by Stuart Herbert

Using The One-Line Installer

The easiest way to get phix installed onto your Ubuntu box is to run the following command from a Terminal window:

curl [phix-project.org] | sudo bash

This command downloads a simple shell script (which you can find on GitHub if you want to read it before trying it!), and which is then run as the user “root”. The shell script:

Makes sure that you have a suitable version of PHP installed
Uses apt-get to install required dependencies
Uses the pecl command to install PHP extensions that we can’t get packaged for Ubuntu
Upgrades the PEAR installer to the latest version
Installs the package phix/phix4componentdev, plus dependencies, from the PEAR channel pear.phix-project.org

If all goes well, once everything has finished, run the following command and you’ll see that phix is now installed:

$ pear list -c phix | grep phix
phix                       0.13.2  stable
phix4componentdev          0.13.2  stable

Where To Find The Latest Installation Instructions

Where Do You Get Your PHP From For Windows?

Posted: September 27th, 2011, 3:28pm MDT by Stuart Herbert

I’m currently working out installation instructions for phix on Microsoft Windows before my sessions at PHPNW 11 and ZendCon in October … and I need your help, because it has been many years now since I used Windows.

If you do your PHP development using Windows on the desktop or laptop, where do you prefer to get your copy of PHP from?

windows.php.net (and if so, which build?)
Microsoft Web Platform
XAMPP
WAMP

… or somewhere else entirely?

The Phix Project Has A New Home

Posted: September 23rd, 2011, 2:00am MDT by Stuart Herbert

Phix now has a new home, as I’ve recently left Gradwell. And a new PEAR channel. And an awesome new logo thanks to Jeremy and Kerry from Magma Digital. And a roadmap on Trello.

And, if you’re using either Ubuntu or Fedora as your dev desktop/laptop, a new one-line installer that takes care of those pesky system-level dependencies that the PEAR Installer can’t help you with :)

How To Move To The New PEAR Channel

If you have already installed an older version of Phix from pear.gradwell.com, you’ll need to run the following commands in order to switch over to our new PEAR channel pear.phix-project.org.

$ sudo pear uninstall Gradwell/ComponentManager
Gradwell/ComponentManagerPhpLibrary Gradwell/ComponentManagerPhpWebapp
Gradwell/ComponentManagerPhpDocbook Gradwell/ComponentManagerShared
Gradwell/ConsoleDisplayLib Gradwell/CommandLineLib
Gradwell/ValidationLib Gradwell/phix
Gradwell/Autoloader Gradwell/ExtenderLib

Then, visit the installation instructions on phix-project.org. Try out our new one-line installers for Ubuntu or Fedora. (Got a one-line installer for another platform? Fork the website on GitHub and send me a pull request :)

If all goes well, you should end up with phix-0.13 installed on your computer:

$ pear list -c phix | grep phix
phix                       0.13.2  stable
phix4componentdev          0.13.2  stable

If You Have Components That Depend On Phix’s Components …

… you’ll need to edit their package.xml files:

Swap any references to pear.gradwell.com to pear.phix-project.org.
Check any <min> and <max> version numbers of any Phix components you depend on, as I’ve bumped all the version numbers.

All of Phix’s components now live in the Phix_Project namespace. You’ll need to update any classes that ‘use’ any of the Phix classes accordingly.

PHP Components: Publishing Your PEAR Channel On Github

Posted: September 22nd, 2011, 2:04pm MDT by Stuart Herbert

This is a guest post by Martin Wernståhl. Martin is a university student at Chalmers University of Technology, Sweden, currently studying the first year of Engineering Physics. He started programming at an age of 9 by writing Not-Quite-C for LEGO robots. Since then he has been programming a little bit of everything until he started with PHP around five years ago. Using CodeIgniter at first, he soon started to write libraries and hack the core of CodeIgniter until he felt that it was too limiting and resorted to starting to experiment with creating his own ORM tools (IgnitedRecord, discontinued as he no longer uses CodeIgniter and RapidDataMapper, development paused because of indecision related to syntax) and lately he has gone back to experimenting with creating a very modular PHP framework. Martin has also been a very enthusiastic supporter and tester of Phix and ComponentManager since their first releases.

If you would like to contribute a guest post about PHP components, please poke @stuherbert on Twitter.

How to Host a PEAR Channel on GitHub

GitHub has a feature called GitHub pages which they introduced about 2.5 years ago. This enables you to host static files located in a specific branch in a repository (gh-pages) on GitHub’s webserver. This can also be used to host a PEAR channel and can be very useful for smaller projects or if you don’t have the time or money to configure a specific server for PEAR. An added bonus is that the content of your PEAR channel server will be versioned by git.

For an example of a GitHub hosted PEAR channel, see the Inject Framework’s PEAR channel page.

The Repository

First, create a new repository on GitHub for your PEAR channel. You may now wonder why I wrote a new repository, this is because of the fact that it is usually better to separate your projects and the PEAR channel repository because of the difference in content, plus, the repository name will be a part of the URL. You might also not want to limit which packages you can put in the channel because of the naming of the parent repository.

A recommended name for the new repository is pear, as that will be equivalent with ${yourusername}.github.com/pear. A must is that the name is lowercase, as GitHub’s URLs are case sensitive.

For an example repository hosting a PEAR channel, see the Inject Framework’s PEAR repo on GitHub.

Create Your Repository Locally

To create the repository we are going to use Pirum. Pirum is a PEAR channel server "generator" which generates static files which can be used by any PEAR installer to install your packages.

So, create a folder for your pear repository and then place a pirum.xml file there:

<?xml version="1.0" encoding="UTF-8" ?>
<server>
    <name>${yourusername}.github.com/${pear_repository}</name>
    <summary>${page_title}</summary>
    <alias>${short_prefix}</alias>
    <url> [http:] {yourusername}.github.com/${pear_repository}</url>
</server>

yourusername and page_title are fairly self-explanatory. pear_repository is the name of the GitHub repository you will store your PEAR channel in. But what does the <alias> tag do?

The contents of the <alias> tag is the channel alias which can be used instead of the contents of <name> when installing PEAR packages after you have run pear channel-discover. An example is the InjectFramework: instead of injectframework.github.com/pear/InjectStack you write injectfw/InjectStack [1].

Then we create our new Git repository, run pirum build . to create the PEAR channel, then link our repository with GitHub and finally create

Truncated by Planet PHP, read more at the original (another 3706 bytes)

Real-Time Graphing With Graphite

Posted: September 21st, 2011, 7:52am MDT by Stuart Herbert

If you’re building a web-based app, it’s always a good idea to build some instrumentation into your app. That way, you can see how your app is behaving, and how your users are interacting with your app over time.

I’m sure everyone who reads my blog is familiar with Google Analytics for tracking page hits. But what about what’s happening inside your app? Right now? Do you know?

Graphite is one way to graph the stats that you add to your app. Combine it with (say) statsd from Etsy, and adding any stats you want is easy. (Read this blog post from Etsy if you want to learn more about measuring your app, and how to add support for Statsd to your app).

Normally, you’ll probably be interested in looking at graphs that show your stats over a period of hours or days (for trend analysis), and both Graphite and Statsd are sensibly tuned for that. But what if you want to see what’s happening now, in real time? I couldn’t find any clear instructions on how to do that elsewhere, so here’s my take on how to do it. I’m assuming you’re already familiar with installing both Statsd and Graphite, and that you’ve already had both up and running successfully with their default configurations.

Making Statsd Forward Data In Real Time

By default, Etsy’s Statsd collects the data sent from your apps, and forwards it on to Graphite’s data collector (known as Carbon) every 10 seconds. For real time, we need the data forwarded on every second. To do that, edit your Statsd config, adding the ‘flushInterval’ value:

{
  graphitePort: 2003
, graphiteHost: "localhost"
, port: 8123
, flushInterval: 1000
}

A value of 1000 tells Statsd to forward data on every second.

Making Graphite Store Data At One Second Resolution

Graphite’s default / sample configuration tells it to store incoming data at 60-second resolution; that allows us to look at the total stats recorded minute by minute, but we can’t drill down to see what happens second by second. To do that, we have to tell Graphite to store the data on a second-by-second basis.

Edit /opt/graphite/conf/storage-schemas.conf, and add the following clause:

[real_time]
priority = 200
pattern = ^stats.*
retentions = 1:34560000

This tells Graphite that we want all the data received from Statsd to be kept on a second-by-second basis for 400 days … plenty long enough for any sort of comparison you might need to do.

I found that, to get Graphite to start using this new storage definition, I had to go and delete the existing data files by doing:

$ rm -rf /opt/graphite/storage/whisper/stats*

Getting Graphite To Draw Real-Time Graphs

Now all we need to do is to get Graphite showing you all the collected data in real-time. By default, Graphite will happily plot the data onto a graph, but will only generate an updated graph every 60 seconds. That’s perfect for an ops team looking for trends over hours, but it isn’t real-time.

If you’re using Memcache with Graphite, you’ll need to add this to your /opt/graphite/webapp/graphite/local_settings.py file, to tell Graphite to only cache data in Memcache for 1 second:

MEMCACHE_DURATION = 1

Is it worth caching the data at all at this resolution? Honestly, I don’t know. I guess that depends on how many people need to watch the data in real-time or not. Ideally, it would be better if Graphite dynamically set the Memcache timeout based on the data stored in the particular key, but for now, you need to either stop using Memcache, or set the cache duration to 1 second.

This now gives you graphs with 1-second resolution … now we just need to change the Graphite web-app’s auto-refresh feature to load a new graph every second. By default, it will only generate an updated graph every 60 seconds. To change this, we have to edit some of the app’s Javascript code.

Open the file /opt/graphite/webapp/content/js/composer_widgets.js, and locate the function ‘toggleAutoRefresh’.
Locate the ‘interval’ variable inside that function. Change its value from ’60′ to ’1′.
Save the file, then refresh your web browser page.

Et voila. If you switch on auto refresh, you should now be able to see your app’s data being plotted second by second, giving you a real-time view of what your app is doing.

Steps For Building A Test VM

Posted: September 18th, 2011, 4:05pm MDT by Stuart Herbert

Using virtual machines for testing software is great. I can try out anything I want, and there’s never any risk of trashing my main dev machine (which avoids hours of lost coding time!). I’ve been using virtual machines since the 1990′s, and frankly I couldn’t develop without them. (I’ve also got a lot of experience running a private cloud of VMs for one of the UK’s fastest-growing tech companies, but that’s a topic for another day or maybe a conversation over a nice whisky at one of the upcoming conferences ;)

Right now, I’m using them to test phix out on multiple Linux distros before release. It’s a sad fact of life that all of the major distros think they can create a better PHP than the folks upstream at PHP.net intended, and that unfortunately means that a default install of PHP on Ubuntu can’t always run the same PHP code as a default install of PHP on Fedora. I found this out the hard way with an early release of phix; now, every release gets tested in a small but growing library of test VMs before I push it up to my public website.

But the best thing of all? You can backup a VM (normally by creating a snapshot), and then rollback to your snapshot in future – resetting your test environment to a known state before you test again. Perfect for this weekend’s task, which has been documenting and double-checking the steps needed to install phix on Linux dev desktops.

I thought it would be useful (to jog my own memory when the Linux distros release their next versions), to write up the steps that I do when I create a new test VM.

Install Linux distro from latest available ISO image.
Run the software upgrade tools to make sure the system is fully patched.
Disable SELinux if it is enabled.
Make sure gcc and the Linux kernel headers are installed on the system.
Install VMWare tools (for VMWare Workstation / Fusion) or VirtualBox Addons (for VirtualBox OSE).
Use Firefox to install Google Chrome.
Install some useful dev tools: curl and git

At this point, I shut down the virtual machine, and take a snapshot – before PHP is installed. That’s because I need to make sure that phix’s upcoming installer script does the right thing when there is no PHP. If you’re building your own test VMs, you’ll probably want to get Apache, PHP and MySQL installed and your app’s vhosts serving static pages before you snapshot.

What else would you do to a test VM to make it ready to run your tests?

Does Phix Need A Screencast Or Two?

Posted: August 17th, 2011, 12:00am MDT by Stuart Herbert

Just a quick straw poll … is there much interest in me making a screencast or two for how to install and work with Phix?

PHP Components: Shipping Web Pages With Your Components

Posted: August 16th, 2011, 12:00am MDT by Stuart Herbert

I’m now going under the bonnet of our components, and looking at the different file roles that the PEAR installer expects to find when we distribute our component as a PEAR-compatible package. It isn’t very often that a component needs to ship web pages too, but should the need arise, here’s how to do it.

What Is A Web Page?

A web page (the ‘www’ file role supported by the PEAR Installer) is any sort of content meant to be served up by web server software such as Apache. This can be a html file, a PHP script, CSS files, Javascript files, images … you name it.

Where Do Web Pages Go Inside Your Component’s Structure?

If we look at the PhpInfo component, you’ll find that the web pages live in the src/www/ folder:

src/www/ is meant to be a folder that holds all of the web pages (and related content) that you want installed into the computer system.

Where Does The PEAR Installer Install The Web Pages?

When you use the PEAR installer to install your component:

$ pear install phix/PhpInfo

all of the web pages get installed into /usr/share/php/www/ on your computer:

The PEAR installer’s behaviour here is almost identical to command-line scripts; the installer installs your web pages directly into the main www_dir folder. This does create the potential for clashes, where two or more packages want to install files with identical names. In practice, PHP components include web pages so rarely that the problem is unlikely to happen.

The test file src/www/phpinfo.php therefore ends up installed onto your computer as /usr/share/php/www/phpinfo.php.

There’s always the possibility that some Linux distros (and Mac OS X) will install doc files into a different folder. You can see where the PEAR installer will put these files on your computer by running:

$ sudo pear config-show | grep www_dir
PEAR www files directory   www_dir          /usr/share/php/www

How Do I Get Apache To Serve These Files?

By default, and for very good reasons, Apache does not serve content directly from /usr/share/php/www/. You will need to copy any files from /usr/share/php/www/ to your website folders (normally found under /var/www/) before they can be used.

PHP Components: Shipping Unit Tests With Your Component

Posted: August 15th, 2011, 12:00am MDT by Stuart Herbert

I’m now going under the bonnet of our components, and looking at the different file roles that the PEAR installer expects to find when we distribute our component as a PEAR-compatible package. One of the most important file roles allows you to ship your tests with your package – and it’s vital that this is something that you get in the habit of doing routinely.

Test Your Code, And Ship Your Tests

If you want other developers to re-use your code in their projects, it is essential that you earn their trust. Trust has to be earned over time, by establishing a track record of dependability. There are many things you need to do to establish such a reputation, such as semantic versioning to flag backwards-compatibility breaks, and writing unit tests to prove that your code works as expected.

Although the PEAR Installer has long supported shipping unit test code, to date the PHP community hasn’t really embraced this, and it is still very rare for a PEAR package to include unit tests when downloaded. This is also compounded by unfortunate legacy choices in some Linux distributions (ubuntu bug, fedora bug), where unit test code currently ends up being installed under the same directory tree as the main code from the PEAR packages – something that only really matters since the PHP Community started to adopt PSR-0 as the standard for autoloading.

What Are PHP Tests?

PHP tests (the ‘test’ file role supported by the PEAR Installer) are executable tests. There is currently no formal standard for these tests; however, PHPUnit has emerged as the community’s de facto standard for unit tests, and is the approach that the PHP components skeleton supports out of the box to make life much easier for you.

Just as important as shipping tests is making sure that it is extremely easy for someone who knows nothing about your code to safely and reliably execute any tests that you ship. The components skeleton handles much of this for you, by including a PHPUnit bootstrap.php file, and a build.xml file with full instructions on how to execute the tests.

However, it is important that you write your tests in a way that doesn’t rely on anything that your users won’t have installed or configured.

Where Do Tests Go Inside Your Component’s Structure?

If we look at the CommandLineLibrary component, you’ll find that the unit test files live in the src/tests/unit-tests/ folder:

Important notes:

The folder structure underneath src/tests/unit-tests exactly matches the folder structure for both PHP scripts and PHP files under the src/ folder.
Each unit test script is designed for PSR-0 autoloading, just like the PHP scripts that they test.
Each unit test script ends in the word ‘Test’. This is a convention that is supported in IDEs such as Netbeans.

Where Does The PEAR Installer Install The Tests?

When you use the PEAR installer to install your component:

$ pear install Gradwell/CommandLineLib

all of the test files get installed into /usr/share/php/tests/<package-name> on your computer:

"/>

Truncated by Planet PHP, read more at the original (another 1846 bytes)

Poll: How Important Is Good Documentation To You?

Posted: August 8th, 2011, 2:30am MDT by Stuart Herbert

I’m currently looking at the tricky subject of documenting your PHP components, and I’d like your help! If you’ve got a minute to spare, could you please vote in this poll about how important good documentation is to you? Thanks.

Sharing My Reading List, Looking For Recommendations

Posted: July 31st, 2011, 3:08am MDT by Stuart Herbert

I’m a great believer in the power of self-education, especially if you are (or want to be) in a more senior role in your firm or organisation. A regular reading list is a great way to learn more about how others are solving problems that you might be, or are about to be, struggling with. I’ve been surprised at how little people I know read, though.

Over the years, I’ve built up a list of blogs that I read daily to try and keep up with what is happening in the wider digital world. It isn’t a complete list for sure, but it’s a good start.

I’m certain that there are many other blogs out there that belong on this list. If you know of any, please send me a pull request

Creating PHP 5.[34] Packages On Debian / Ubuntu?

Posted: July 31st, 2011, 2:36am MDT by Stuart Herbert

I was just wondering if anyone has published instructions on how to take the latest PHP 5.3 and PHP 5.4 source tarballs, and turn them into drop-in packages for Debian and Ubuntu, a la the DotDeb or Damz’s packages?

My RSS » Items by Stuart Herbert

Feeds

Items by Stuart Herbert

Posted: February 4th, 2012, 11:57am MST by Stuart Herbert

Posted: January 31st, 2012, 1:00am MST by Stuart Herbert

Posted: January 17th, 2012, 1:30am MST by Stuart Herbert

Posted: January 16th, 2012, 1:30am MST by Stuart Herbert

Posted: January 11th, 2012, 1:30am MST by Stuart Herbert

Posted: October 24th, 2011, 2:57pm MDT by Stuart Herbert

Posted: October 15th, 2011, 1:00am MDT by Stuart Herbert

Posted: October 14th, 2011, 1:00am MDT by Stuart Herbert

Posted: October 13th, 2011, 7:00am MDT by Stuart Herbert

Posted: October 13th, 2011, 1:00am MDT by Stuart Herbert

Posted: October 12th, 2011, 1:00am MDT by Stuart Herbert

Posted: October 11th, 2011, 1:00am MDT by Stuart Herbert

Posted: October 10th, 2011, 2:37am MDT by Stuart Herbert

Posted: October 4th, 2011, 12:00am MDT by Stuart Herbert

Posted: October 3rd, 2011, 12:00pm MDT by Stuart Herbert

Posted: October 3rd, 2011, 8:00am MDT by Stuart Herbert

Posted: October 3rd, 2011, 12:00am MDT by Stuart Herbert

Posted: October 2nd, 2011, 12:00am MDT by Stuart Herbert

Posted: October 1st, 2011, 10:00am MDT by Stuart Herbert

Posted: October 1st, 2011, 12:00am MDT by Stuart Herbert

Posted: September 27th, 2011, 3:28pm MDT by Stuart Herbert

Posted: September 23rd, 2011, 2:00am MDT by Stuart Herbert

Posted: September 22nd, 2011, 2:04pm MDT by Stuart Herbert

Posted: September 21st, 2011, 7:52am MDT by Stuart Herbert

Posted: September 18th, 2011, 4:05pm MDT by Stuart Herbert

Posted: August 17th, 2011, 12:00am MDT by Stuart Herbert

Posted: August 16th, 2011, 12:00am MDT by Stuart Herbert

Posted: August 15th, 2011, 12:00am MDT by Stuart Herbert

Posted: August 8th, 2011, 2:30am MDT by Stuart Herbert

Posted: July 31st, 2011, 3:08am MDT by Stuart Herbert

Posted: July 31st, 2011, 2:36am MDT by Stuart Herbert