On PHPFreaks.com they have a new "top ten" list of signs to look out for to tell if you're dealing with crappy software or not.

Like it or not, as a professional developer, sooner or later you are going to do some customising (if you are lucky, "extending") of existing software. If you are not familiar with the software, it is good advice to look into it before accepting the job. I had to learn that the hard way. But how do you recognize crappy applications without getting knee deep into the code?

Their list of signs include:

• The software tries to reinvent the object model, or "fix" language features.
• Scattered HTML and SQL
• Multiple levels of inheritance
• In the code base, there is a directory called "core"

The PEAR blog has a quick note for users of PHP 5.3 and Windows:

Some users have reported that the windows builds of PHP 5.3 are not able to open the shipped go-pear.phar file.

If this is your situation, you can use their workaround (run the distributed phar version) or grab the non-pharred version.

Lorna Mitchell has posted the last article in her look at web services - a focus on status codes.

Unlike the other posts in this series, this one is quite specific to one type of service - REST - since it deals with status codes, specifically HTTP ones. The ideas are transferrable however and other types of service can return statuses in a similar way.

She mentions things to keep in mind in returning the codes, some of the more interesting codes as well as some typical situations where things like an error code 500 would be thrown.

Status codes are like a headline to the calling entity about what happened, and are a valuable tool in the web service toolkit.

John Lim has written up an article for the Oracle Technology Network about creating high performance systems with Oracle's Real Application Clusters (RAC) and PHP.

Running a software application that is able to work reliably through hardware and software failures is incredibly hard. [...] In this article, I will cover the network, architecture and design of our RAC application. Then I will discuss the real-world experiences and problems we experienced.

He details their RAC setup - load balancers, application servers and their RAC servers - before working through the different technologies and how they're all installed and configured to work together most efficiently.

In the next to last article of their loader series, DevShed looks at replacing some of the file loading functionality in their examples with functions from the SPL.

As I mentioned before, the Standard PHP library comes bundled with some helpful functions, such as "spl_autoload()," "spl_register_extension()" and "spl_autoload_register()" that allow you to either use a default implementation of the "__autoload()" function, or create a custom one for it.

Their example defines the extensions to use for autoloading and the name of the file/class to pull in. The rest is done automagically.