New on the Developer Tutorials blog today is this look at handling background processes from your PHP script:

You've checked and double checked the integrity of user input, and you're doing some serious processing. There's only one problem: it's too slow. There's a simple solution: forking your processing script, and running the code as a background process asynchronously. It can email your user when it's done: they'll wait. In this tutorial, I'll show you how to get started with background processes in PHP.

Akash gives examples of the three keys to background processes - starting the script via an exec, talking to the process by passing additional parameters and including code to monitor the state of the background process via something like a MySQL "sessions" table that the script writes to.

Frustrated by the trouble he's having finding a really good PHP developer to fill a few positions, has posted about this process he's been going through - the good, the bad and the downright ugly - of trying to find those right, qualified folks.

During the last six month or so, I've been looking to hire a PHP programmer for at least three companies. I have spoken to quite a few people on the phone, reviewed a bunch of resumes, and even interviewed a few. Out of all those candidates I recommended to hire exactly zero.

Some of the "roadbumps" he experienced along the way include the interviewees inability to write down code without a computer and them giving either the wrong or no answers to simple, common knowledge computing questions. So, he came up with a list of what he calls the "roots of the problem". Included in the list are things like:

• PHP is an ugly language
• PHP is rich with secondary reasons
• PHP is getting mature
• PHP avoidance

Also be sure to check out this response from Nick Jenkins to Leonid's post.

UPDATE: Leonid has also posted a follow-up post with a few corrections and clarifications of the original post.

In a recent post to his blog, Brian Moon talks about the experience he's had with using PHP on Apache 2 with a threaded MPM at Dealnews.com.

Well, first, what is an MPM? It stands for Multi-Processing Module. [...] The most commonly used threaded MPM is the Worker MPM. In this MPM, you have several processes that run multiple threads within it. This is the one I will be talking about.

He goes on to describe the "huge memory savings" that using the module got them - using the worker process to increase the child capacity of the Apache instance. He recommends keeping it simple when compiling a server to work with the worker functionality and mentions how it can also help with serving static pages right along side the dynamic ones (without a second server!).

Check out the post for a few more tips.

Sebastian Bergmann points out a new feature that PHPUnit (the popular PHP unit testing tool) now has - parallel_test_execution allowing for each test to execute on a separate PHP process.

The advantages of this include full test isolation and the fact that a test can now cause a PHP fatal error or even a segmentation fault of the PHP interpreter without interrupting the test execution.

He does mention, however, that it can cause a bit more overhead for larger testing suites since it needs to create a new process (complete with memory usage) for each running test. There are also coding issues that could be thrown off by this option (he gives an example of an inheritance issue with eZ Components).

He also notes some of his thoughts on how to control/configure the process (like in a configuration file) and via an "@isolated" notation to make it easy to do it dynamically.

The Symfony project has posted an announcement about the start of the official release process for the framework's latest branch - Symfony 1.1.

As the features for symfony 1.1 are quite finished now, it's time to move on and start the release process.

They've made two new branches in preparation to get things ready - one for the release itself and the other for the release's documentation. Users wanting to use the latest stable, still point to /branches/1.0. Those wanting to test this upcoming release, use /branches/1.1.

On the lighter side of the language, Antony Dovgal has posted ten commandments that PHP developers should follow including:

• Thou shalt obey the Release Master.
• Thou shalt not forget to add comments to thy code, especially if the code is tricky.
• Thou shalt not fix a bug only in one of the branches unless it did not exist in the others.
• Thou shalt discuss all new features in internals@.

IMO it's time to make the development process more organized. This is my version of what I would like to see as an official set of rules for PHP community.

Tony Bibbs is fed up with the framework hype that's been going on in the PHP community for a while now and has posted about some of this frustration on his blog. More specifically, how there seems to be this misconception as to the point of them and their place in the web development world.

What nobody seems to want to talk about is the fact that frameworks, be it in PHP, Java, .NET or even Python, have a bunch of valueless rhetoric around them. Their value is often discussed in terms of coolness and how easy it was to learn. If you are talking to a manager-type, balding, high strung, concerned about his or her budget you will quickly learn they could care less. Their focused is on the business. The bottom line. Achieving results. So let's talk in tangible terms on how a framework in any language should be evaluated and how it directly addresses the needs of the business.

He goes on to talk about how frameworks can't fix things like "crappy software development practices" or how they can't immediately save you time (but can in the long run). Most importantly, though, he's compiled a list of things you should keep an eye out for when starting the move towards a framework for your development. The list includes things like:

• Does the framework fit well with your SDLC? Do you even have an SDLC?
• Does your framework allow your better developers to excel and innovate new ways to address a business problem? If the framework only handcuffs your better talent you may find keeping them around near impossible.
• Can you choose not to use parts of your framework to work around performance bottlnecks? As an example, some frameworks don't even give you the ability to issue raw SQL to the database? Using tools like an ORM adds a layer of abstraction that slows performance and sometimes you will need to squeeze out every bit of performance you can. Your framework should facilitate this, not hinder it.

Check out the rest of the post for the other four on the list.

WebReference.com has an excerpt posted from one of Packt Publishing's latest PHP-related offerings, "PHP Oracle Web Development: Data processing, Security, Caching, XML, Web Services, and Ajax" (by Yuli Vasiliev). This specific chapter talks about XML-enabled applications and how PHP fits into the mix.

Both PHP and Oracle provide comprehensive support for XML and XML-related technologies. Practically, this means you can perform any XML processing either with PHP or inside an Oracle database. [...] This chapter explains how to effectively use XML techniques and technologies available in PHP and Oracle when building XML-enabled PHP/Oracle applications.

They cover the processing of XML in PHP/Oracle apps (including the SAX, DOM and SimpleXML methods), working with XPath and processing the XML in the other half of the two - Oracle's XML processing functionality.

Check out the Packt website for more information on the book.

PHPBuilder.com has posted part two of their look at combining Ajax and PHP. They take things a step further than last time and look at the actual communication between the script and the server.

AJAX and PHP 5 both have powerful features for processing and using an XML document. XML is a method of formatting data often for communication purposes between different computer systems. In this article, we will show you how to access an XML document with AJAX!

They create a script that can load the XML information from a file and echo it back out to the waiting client script. They also include the other half - the client-side javascript that grabs the XML information, parses it, and pushed it into a javascript object for easy access.

New from Iain Dooley on the Working Software website today is his look at working with threading in PHP including forking and communication between the processes.

I recently wrote a little application that dumps a file across a forwarded port. [...] So when I first wrote it, I didn't know what I was doing and had never written socket code before, so it was a big procedural mess. Naturally I was keen to separate out my socket class into it's own package but this presented a problem: the controlling process needed to check the status but how could I decouple the process that instantiated the socket class from the socket code itself

So, he set about working up his class, hitting a few barriers along the way:

• Copy On Write issues with how PHP handles the variable for the forked process
• Interprocess Communication using Sockets using the socket_create_pair function
• a "Curious Interlude" about why you can share sockets between two processes

There's a example of it in action - a setup with a child process that's all set to count up and respond back with the current number to the managing script.