In a follow up to his previous post about how PHP is broken (and what can be done to fix it), Court Ewing has this new post with a few suggestions on how PHP development could be better, but admits that PHP itself is not broken.

It is no secret that the PHP development process has never been a shining example of project organization or quality assurance. Until recently, some of the most important aspects of any project's development cycle were either entirely lacking or were ill-defined. Worse, there was little in the form of systemic quality assurance. Fortunately, the core devs did not ignore these issues, and they've been pushing really hard to improve on these areas over the past few years.

He points out two things that he sees as things that could be improved in the overall process of developing the language - noting that failing automated tests are ineffective and that communication is a key factor in the trust developers have in PHP.

The core PHP developers have long been a key component of [the amazing things the language can do], and none of progress that modern PHP applications have made would be possible without their ongoing efforts. As a result of those efforts, PHP is a stable, secure, and beautifully-practical language that is both easy for novices to wrap their heads around and experts to build the most-used web applications the world has ever seen.

On the Web Builder Zone (a part of DZone.com) Giorgio Sironi take a high-level look at some of the tools you can use for automated code reviews in your projects without you ever having to lift a finger (well, once it's set up, of course).

I'm exploring an approach to automated code review: it's not as precise as the human-based one, but it scales better. [...] All in all, automated code reviews, performed with tools instead of with human intellect, can be a starting point to search for the problematic zones of a codebase. Then the human may come in, since they also have to clean up the code: their intervention was already scheduled.

The tools he mentions (and, in some cases, shows how to install/use) are:

• PHPUnit
• PHP_Depend
• PHP_CodeSniffer
• PHP Mess Detector (pmd)
• the Jenkins job template

On the Web Builder Zone (from DZone) Giorgio Sironi has posted a new article that talks about the different kinds of testing you can do on your application - both on the frontend and backend.

Automated testing supports your constant effort in design and refactoring, and besides that ensures that your application actually works in a reliable and repeatable way. [...] In this article I'll describe the different categories of testing, as applied to a Zend Framework 1 application, but this classification pertains to every web application based on object-oriented programming. Since this kind of applications is obviously PHP-based, PHPUnit will be the tool of choice along with some of its standard extensions.

He looks at five different types of testing you can do on your application:

• Unit testing
• Pragmatic unit testing
• Functional testing
• Integration testing
• Acceptance testing

Not all of these can be done with PHPUnit on the backend, but they (mostly) have automated tools of their own like Selenium for frontend interface testing.

Richard Thomas has posted a script that could be used to set up a complete PHP-enabled instance of CentOS from a basic install. He's posted about it on his blog.

I compile php all the time, I am constantly installing the latest versions on my own servers for various reasons. After doing this the first dozen or so times I started creating little batch files. [...] The other day someone asked something about my setup and I had to pull open the script to remember what I had going on and he asked for a copy and hence I figure others might be interested as well.

He's shared out the file here and it installs all the usual tools you might need including MySQL support with PHP being the only thing compiled from scratch.

In this new post from Brandon Savage he looks at automated build tools and how they're more relevant now than ever in your application's lifecycle.

Build systems are just as relevant to the web (if not more so) than they are to compiled code. Build systems offer significant advantages to the development of software applications, and it is crucial that developers not take them for granted.

He suggests a few reasons to those naysayers out there as to why build processes and tools are pertinent to web development:

• Build systems make continuous integration easier.
• Build systems ensure that the same process is followed each and every time when making a release.
• With a one-step system, errors are reduced.
• Creating a build system reenforces the entire development process.
• A build system introduces formality to the release process.

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.