I [replied to the email] with some suggestions (and my consulting rate) attached, and we had a little email exchange about some improvements that could fit in with the existing setup, both of the hardware and of the team skills. Then I started to think ... he probably isn't the only person who is wondering if there's a better way. So here's my advice, now with pictures!

She's broken it up into a few different sections to make it a bit more easily digestible:

• A "starting point" where there's a development, staging and live environments
• Using source control to manage code
• Branching for effective coordination
• Integration of automated deployment

She also mentions other "bonus points" like making a build server, documentation generation and Javascript/CSS minification.

In case you haven't heard the news, the PHP project released version 5.4.0 last Thursday. Naturally, I decided it was time to install and give it a try. I chose to install to a clean and bare-bones CentOS 6.2 virtual machine using VirtualBox. I did this for two reasons: 1) I wanted a clean environment for the build, and 2) I wanted to play with CentOS. At the time of this writing, there are not yet any official CentOS RPMs for PHP 5.4, so I had to build PHP from source. What follows are the notes I took during the installation and build process. I hope you find them helpful.

His instructions cover the full process:

• Installing the CentOS operating system
• Creating a non-root user
• Setting up the network for local access
• Installing the packages for PHP (via yum)
• Grab PHP 5.4 and compile it
• Testing out the web server with a sample phpinfo file

He includes a lot of extensions in his installation, some you may not need like pspell, tidy, calendar, ftp or xsl.

I developed an exercise for applicants. They must use an open source framework to make a simple bulletin board. It requires account creation, login, thread creation, message creation, unread message indication per thread, and logout. Every applicant is given this exercise after passing an initial test. The initial test is a simple disqualifier and is not challenging for anyone not lying on their resume.

There's some great discussion in the comments about things like the suggested time limit, opinions on other methods that could yield the same results, thoughts on the validity of even taking the test based on the level of the job. The popular opinion, though, is that it's too much work for an applicant to go through unless there's a very specific need. As one commentor put it:

Most of the excellent programmers will have jobs. Those that don't will probably have several options (unless you're in a very small market) for where to work. When it comes down to applying to the place that wants you to spend a bunch of your own time on their application, or some other company... They'll go with some other company.

Before getting into the original post, I wanted to a comment made in his edit with an apology for the original post coming across as more of an "irritated user" than an unopinionated observer.

PHP's development process has been broken for a long time, and the failures of that process have swelled since the first ripples began to appear many years ago. [...] This is no surprise given the very fluid history of PHP though, and the lack of any sustainable processes may have even been one of the key things that allowed PHP to evolve so quickly into one of the most used programming languages in the world. But that early success doesn't make the PHP development process any less broken.

He covers a few points where he has issues with the PHP project including the release management, test coverage and recent issues with bugs in releases. He gives suggestions on how things could be made better - a detailed release process, a voting process for new features and a emphasis on good code and tests in the core. He also notes that he thinks more contributors in the mix isn't the solution. While it's encouraged to join the project, he suggests that the current core development group are the ones that should work the hardest on making things better.

Be sure to check out the comments for some great responses from the PHP community - both for and against the statements from the original post.

A commonly identified bottleneck arises when dealing with large, 'expensive' data. This is commonly seen when an application posts a large volume of well structured data to the API (that some process must be carried out upon), before some form of structured receipt is then returned as a request response. [...] Analysing such a request tends to show high PHP CPU usage with lower database consumption. [...] The structured nature of data exchanged via an API means that we can, relatively simply and reliably, divide the submitted data and process it simultaneously with the help of a great tool called Gearman.

He walks you through the entire process including his initial thoughts on what the system should be and how it should behave when the requests are made. He shares the code he used to implement the system - a simple worker that processes part of the request and returns the results. The command-line calls to run the worker manually for testing are also included.

In the previous post we saw how we can generate a screenshot from a url. In this post we will see how we can create a color palette of the screenshot (or any other image for that matter) using PHP and GD. This can be useful if you need to quickly get the color scheme of a website or a image. Below are a few example images and their palettes generated using the program.

With the help of his code it's as easy as a call on a GetMostCommonColors object (get_color) to return the hex codes for the values found most. Also included in the post is a sample snippet showing how to pull the details from the file and output it in a grid similar to this.

The reason this has been relivant in the last two weeks is two fold, first off, my slow and sometimes painfull Pman.Core and Pman.Base). It seemed like an ideal time to write some generic code that can solve both issues.

He mentions the usual method of generating numerous emails and sending them to a remote SMTP server, but points out that there's a better way. You can take advantage of queuing and batch sending techniques and, the way he decided to do it for mtrack, using queue tables and a backend runner (a cron job) that uses proc_open to send out multiple emails at once. You can see the code for it here.

Image processing in PHP is a necessary evil but is needed more often than not in just about every web application. With the various preferences in image processing libraries (think ImageMagick, GraphicsMagick and GD) it is difficult to find a library that provides a unified object oriented interface as well as implementing the general tasks in a simplistic fashion. Imagine is an open source image manipulation library built with PHP 5.3 that implements an object oriented interface to ImageMagick, GraphicsMagick and GD

Mike gives a quick sample script that uses SPL autoloading to pull in the classes as they're needed (with the "imagineLoader" method) and make a basic thumbnail from a PNG file.

From Wil's post:

I need a word for several engineers working on the same project that isn't 'team'. Why? Because most engineers working on the same project aren't working together as a team. This is why I believe in process patterns. Note: I didn't say that I believe in processes, because I don't. [...] You name a methodology, and I don't believe in it. But I do believe that there are some process patterns that can dramatically improve team productivity.

These patterns are things that are common to several of the processes common to software development - like backlogs, test driven development, etc - but don't have to be considered as something that only comes with XP or Scrum and shouldn't be used outside them. There's even a whole other site dedicated to defining these patterns and where the ideas came from. Oh, and don't forget to add Wil's new word to your vocabulary - "hackle", two or more engineers working together on one project (not necessarily as a team).

The Apache Zeta Components project is currently discussing how to adjust the old eZ Components release process to the ASF guidelines. During this discussions, quite some ideas came up on how the process could be optimized. This brought my interest to how users of PHP libraries would actually like to obtain library code for their projects. I will publish the raw results of the survey later, so all of the PHP libraries and frameworks can benefit. So please take some minutes and fill out the form!

The survey itself is embedded in his blog post, so you can fill it out right there on the same page. It asks questions about currently used libraries, preferred install methods and deployment methods. If you'd like a more direct link, you can go here.