Downloading a single file to use PHPUnit? Not an idea that is too phar out anymore! Starting with version 3.7.5, PHPUnit seems to finally work correctly when packaged as a PHP Archive (PHAR).

He includes a list of steps you can follow to pull down the latest code and use the phar branch that executes with the archive file instead of the local "phpunit" executable. Of course, you can still (as always) install PHPUnit via the PEAR process as well.

Users of PHPUnit frequently ask me questions such as "How do I use PHPUnit from a Git checkout?" or "How do I run PHPUnit's own test suite?" This article provides the answers to these questions.

The git checkout is as easy as cloning the latest version (at the time of this post, it's 3.5). If you want a different version, you can checkout that branch with one or two more commands. The checkout comes with the test runner PHP script that is used when the "phpunit" command is run based on the "phpunit.xml.dist" file included in the checkout.

Features mentioned include:

• One-Page Checkout
• Shipping to Multiple Addresses in One Order
• Guest Checkout
• Checkout with Account to Use Address Book
• Accept Gift Messages Per Order and Per Item
• Saved Shopping Carts with Configurable Expiration Time

He also points out an issue where dynamic IPs could cause an "empty cart" problem because of a security measure Magento has in place.

I dug around a bit, but most resources I came across on Google were about using the tidy extension for PHP rather than doing a custom build of PHP that included the tidy extension. Once I figured the details out, I thought I'd share. They admittedly seemed somewhat obvious after the fact, though also were not communicated as explicitly as I would have liked anywhere that I could see.

TO use his method you'll need to have CVS working (either on a server or, like he did, a local machine) and be able to grab the latest PHP 5.3.x and tidy extension versions. When you do the compile for PHP, all you need to do is point it at the CVS checkout of tidy and you should be all set.

The wrapper is called PHPillow, lays on top of the Couch and offers even more comfort laying anything into the database. :) It has complete API documentation, currently a test coverage of >95%, tutorials and practical examples included. Even I would call it alpha - as CouchDB is still alpha at the current state - you can expect it stay quite stable API wise, as I rely heavily on it in other projects and therefore won't break too much.

You can check out the latest version of this wrapper from its subversion site and get more information about CouchDB on its website and wiki.

We just completed a reorganization of our subversion repository. The reorganization was necessary due to changes we are introducting both in our proposal system as well as project architecture. Specifically, we are introducing a new library, our 'Extras' library, which will contain contributions that are not officially supported by Zend but which still require successful completion of our proposal process. Additionally, we are merging our Laboratory repository.

This page on the Zend Framework website gives the new structure along with a list of key changes and an example of how to switch our your current checkout with this new version.

Some time has elapsed since we wrote our draft for a message queue system written in and for PHP. Now it's time to give you guys an update and working beta-code. [...] You can find the project homepage at https://opensource.ruempler.eu/pmq/. We'd be proud if you have some cool naming tips for this project - we haven't registered a domain yet. At the moment it's temporarily called "PHP Message Queue".

Check out the post for more specifics about the updates/advancements they've made or you can download the current code from their SVN repository.

One of the new features in the upcoming PHPUnit 3.1 release is the support for distributed testing through the ability to log test result and code coverage data to a database. This way, the same test suite can be run on different platforms with the results being aggregated in the database. For this to work, however, we need a key in the database that identifies test runs from different machines as being related. A Subversion revision number is a perfect candidate for this.

He includes a sample script that helps with the storage of the results in the database by grabbing a unique id for the machine pushing the updates in.