Fabien Potencier has a new post to the symfony framework's blog today talking about some more of the "little things" they've added to the latest version of the framework.

Symfony 1.2 already comes with a lot of great new features but smaller things also matter a lot. Here is yet another post about small things we have recently added to symfony 1.2.

The list includes the ability to generate a URL in an action using the routing object, new methods in the form object that make it simpler to use in templates and an update to the Phing/Propel interface to help with debugging.

On the Developer Tutorials blog, there's a recent example of how to validate a common task of many signup forms - if the email sent is actually received.

For any web developer that's ever had to build a signup routine, email is the necessary evil that takes pride of place among hated activities. Sure, a simple call to the language's mail library will send a message through, but the moment the boss wants a HTML email, or users need attachments, everything starts to get tricky.

They try to solve the mail return issue (it tells if the message has gone to the queue, not been delivered) with a little testing and Fakemail. The software looks for emails based on the configuration given and pulls them out to a local directory. Your script can then look here and check the validity of the message before its sent.

This even allows for integration with things like Phing, SimpleTest and Selenium.

On the PHP::Impact blog, there's a new tutorial showing how to use the Phing build system to deploy your application.

A common way to automate development and deployment tasks is by writing shell scripts, however, Phing provides some advantages over shell scripts for task automation. [...] But, having a large collection of shell scripts can lead to a maintenance nightmare, reason why I decided to port some of them to PHP as Phing tasks. I chose Phing because it's simple, powerful and very easy to extend.

He talks about DbDeployTask (an optional task for database revisions) and how to use the system for Agile development practices.

Ken Guest has posted a review of yet another PHP-related book from APress publishing, "PHP Objects, Patterns and Practice (Second Edition)".

While being an easy read, this is a well written, serious book and is aimed squarely at enterprise-level developers and software engineers who make their living through the development and architecture of solutions developed in PHP.

He breaks down the book into the three sections its title mentions - working with objects, design patterns and a healthy dose of PEAR, phpDocumentor, PHPUnit, CVS and phing.

Stefan Priebsch has posted an example of how he uses PHPUnit "manually" to reduce the overhead (and added complexity) of calling phing.

Instead of instantiating PHPUnit from phing, I use the command line interface to call PHPUnit. This decouples phing and PHPUnit, which should cause less problems with version updates in the future. To configure PHPUnit, phing creates a temporary XML configuration file which is deleted after PHPUnit has finished.

The source is included in the post - it manually builds the XML file needed for phing to do its job.

The Zend Developer Zone has posted the fifth and final installment of the series Stefan Priebsch has written up about debugging your application via the XDebug software.

Today, we will have a look at another great feature of xdebug - creating code coverage statistics. Code coverage statistics show how many times each line of the code has been executed. Conversely, they also show which lines of code have not been executed, which is in fact much more interesting.

He talks a bit about what code coverage is and how it can help you fine tune your application. He walks you through the installation of the two packages that will help out with running the reports - phing and PHPUnit. Using these, he shows how to create a simple unit test and a build file for phing that combine and, via the XDebug calls to xdebug_start_code_coverage, xdebug_stop_code_coverage and xdebug_get_code_coverage, are used to generate the output graphs and stats in a nice, easy to read interface.

The Xinc project has released the latest version of their application - 1.0:

The Xinc team are proud to announce the release of Xinc 1.0. Xinc is a free open source continuous integration tool written in PHP 5. It currently supports Subversion and Phing but is extensible to work with any version control or build tool. Xinc is released under an LGPL license.

You can find out more about this library on its new home on Google Code including documentation and two example projects to learn from. You can download this latest version here.

In this new post to his blog today, Raphael Stolt shows how to combine the Zend Framework and Phing to create a simple, quick setup utility for future ZF projects.

After spending too much time on directory and view script shifting to align an 'older' Zend Framework application to the very useful ViewRenderer Action Helper of the follow-up releases I crafted a single Phing buildfile to stick to the recommended conventions and to have a nearly 'one-button' setup solution for any upcoming projects.

He'd found some other packages that did something similar, but wanted to do it with Phing. He includes the requirements (the software) features that the buildfile makes easy to include and some future improvements that could be made to the install to make things even easier. The buildfile is included and any path or configuration changes that might need to be made.

Phing is a "make" replacement that uses XML build files to define tasks in classes.

The Xinc (Xinc Is Not CruiseControl) group has released an announcement about reaching the beta mark in the development live of thier tool, Xinc.

Xinc is an open source PHP 5 continuous integration tool designed to integrate with Subversion, Phing and PHPUnit.

There is a growing awareness of continuous integration in the PHP world and we feel that to have to rely on Java to provide this functionality (i.e. CruiseControl) sucks big time. So we are building the PHP 5 alternative.

Their system seems clean and lets you not only set up the push via a running background process but can pull it from Subversion and run any unit tests (via PHPUnit) you might have before pushing the project out.

Wanting to automate a common task he found himself doing, Raphael Stolt came up with his own process and use Phing to help.

To round off an older article on this blog called "Using the PHP 5 reflection API to keep track of unsolved refactorings" I wanted to automate the following task: collect and log some information about developer marked unsolved refactorings for a single class file or more common multiple files of an whole directory. And as I'm getting more and more acquainted with Phing I wanted to craft this custom task by using it's provided extension possibilities.

He gives examples of what the "unsolvedRefactoring" notation looks, the XML mapping for its definition, and the code that actually makes the mapping work - and makes it easy to pull out the needed information. There's two versions presented, one a normal pull and the other modified slightly to "actually retrieve the metadata of the methods marked as improveable via the @unsolvedRefactoring doclet". And, finally, the integration with Phing comes, showing how to run the files and what the results should look like.