Sunday 31 December 2006

Looking back at PEAR in 2006

Greg Beaver has posted a nice history of PEAR in 2006, entitled 2006: a PEAR retrospective. From the article:

2006 was an interesting year for PEAR, a number of exciting events happened both inside PEAR's workings and in PHP at large that affected PEAR. I will attempt to give my best shot at a 20-20 hindsight look back at PEAR in the past year.

Of course, 2006 was a big year for me in PEAR. My account was opened by Pierre in July, just a few months before he announced his retirement. The PHP_CodeSniffer proposal was submitted in July and finally approved in late August and I released the first version of PHP_CodeSniffer through PEAR in early September, a very proud moment for everyone involved at Squiz.

The first stable version of PHP_CodeSniffer is planned for release sometime in 2007, so next year should include another proud milestone for my involvement in the PEAR project.

Saturday 30 December 2006

Congratuations Animal Logic, Happy Feet was great!

I went and saw Happy Feet at the movies last night. What a great movie. The animation and music were fantastic. I was surprised to see the use of live footage mixed in, but it worked really well.

I know a couple of the guys who worked on the film at Animal Logic. Steve Agland was the lead developer at Squiz when I started working there, and the best man at my wedding. Peter Brownlow was a mate of mine at UTS during computer science. Both were credited for their R&D work on the film, and both next to each other, which made it easy to find them in the extensive credit list.

Congratulations on your first feature film guys. Job well done.

Friday 29 December 2006

Using Xdebug and PHPUnit3 for code coverage analysis

I've tried compiling Xdebug (both from a source download and through PECL) on my PowerBook before, but I've always had problems. Today, however, it finally worked. I also installed the latest release of PHPUnit (version 3.0.0 stable) after running with both PHPUnit2 and 3.0.0alpha11 (the last PEAR release) for a while.

Changing the PHP_CodeSniffer unit tests to support PHPUnit3 was harder than I anticipated, probably due to the fact that I was constructing my test suites in an "interesting" way. But it didn't take long, and with Xdebug now installed (thanks to a little help from this article) I was able to start generating code coverage reports for PHP_CodeSniffer.


I have to say that I am impressed by the code coverage reports that are generated. They really are quite good and make it very easy to see which directories, files and lines require additional testing. I'm also pleased to say that the coverage analysis for PHP_CodeSniffer is quite high, although I still have a few places that need testing.

Thursday 28 December 2006

If not test first, then test really soon!

I've spent the last week or so porting the Squiz coding standard sniffs from our old SVN repository to PEAR's PHP_CodeSniffer CVS repository. I'd forgotten just how many there are! For each sniff, I have to write the unit tests as well, which really should have been done back when the sniffs were first written.

For such a small piece of software, the number of tests I have to write is amazing. It doesn't surprise me, but it is getting to me. There is not a lot of "real coding" to be done during this port. Some of the sniffs need a rewrite to bring them in-line with the newer version of PHP_CodeSniffer, but the number of lines of test code far outweigh the number of lines of sniff code, and the job is rapidly losing its appeal.

Compare PHP_CodeSniffer to a large project like MySource Matrix and it's pretty easy to see why the tests need to be written at the same time as the code. Unit testing is not something you can just introduce into a large mature software product (believe me, I've tried) unless you want to spend the next N months writing tests instead of new functionality. Even if you could find the time to do it, you would rapidly lose team members out of sheer boredom.

I'm not into the whole "test first" thing, although I do use it for projects like PHP_CodeSniffer, which is almost too well suited for the concept. Having said that, if you're not going to test first, you'd better test really soon!