All programming languages have warts. That is, there were certain decisions made about a language that are less than ideal. Some people are driven to remove these warts from the language in an attempt to make the language better. I think this is done with the best intentions, but can often have negative consequences. JavaScript is a good example of a language that has a lot of warts. Despite all these warts, JavaScript is a very useful language and has seen a huge rise in popularity. I feel PHP is the same way. It has bad parts, but there are so many good parts that we need to celebrate those good parts. Here are a few things off the top of my head:

Arrays

I think the array is the single most powerful and useful part of PHP. The PHP array is the Swiss Amry knife in my programming toolkit. I have written applications in a number of other software languages and I have yet to find anything else more useful. The best part about arrays is that they just work. I don't have to decide ahead of time between a list or a map. The PHP array is to data structures as NoSQL is to SQL. Better still is that PHP core uses them all over the place. Results from the database: arrays. Parsing a json POST from the client: arrays. They are ubiquitous in PHP in both core and userland. I cannot say enough good things about PHP arrays.

Web Ready

PHP is web ready. I do not mean that PHP is easy to integrate into a webserver. PHP is easy to integrate, but I think a lot of languages do a good job of integrating to webservers now. I mean PHP is built for the web. It is so easy to create an HTML template and pass the data to it. I think Mustache and Twig are great. That being said, I do not have to decide on a templating language in order to get up and running. Everyone understands HTML.

I do think this is feature is getting less important as the web develops. I write a lot of API's and send almost everything to the client via json. However, they are still tons of websites out there are that are not platforms and need to serve up HTML.

Streams

Streams are the best kept secret in PHP. Most people do not even realize they are using streams when they are interacting with file systems or networks. I wrote a plugin to push messages to the Phergie IRC bot in less than an hour using streams. They are a really powerful abstraction that is used all over PHP.

Type Juggling

For the most part, a web application is just a bunch of strings. HTTP is all strings, most database adapters return strings and all output is strings. PHP handles all of this and removes all kinds of boilerplate code from my applications. I think PHP has the most sensible implementation of juggling too. Yes, they are some problems with large integers that are represented as strings. It is by no means perfect. However, I think the PHP zval has saved me orders of magnitude more hours than pain.

For all the warts, there is plenty of beauty in PHP. I still enjoy writing web applications using PHP and focus my time using the parts of PHP that work really well.

I wish the gearadmin output was a little nicer to read. The raw dump of the telnet output leaves the data a little cryptic.

Turns out we need to tweak a default configuration settings to get this all to work. Open up your .vimrc and add the following line:

let g:debuggerMaxDepth = 3


That depth means you will be able to view the contents of a triply-nested array. That seemed like a sensible default to me. Now you can evaluate or get the property of any variable like normal.

Once the depth is set there is no way to change it during a debug session. You have to close the existing XDebug session, update the value and start a new session. I plan on changing this in a future release of the plugin.

I find myself using the client functionality of the gearman tool most often. If I am tasked with creating or updating a gearman worker I want to test that the worker actually works. The code that sends a job to the worker is normally part of the web application and I don't want to dig through the application trying to figure out what I need to do send the job out. I could just create a simple php script that creates a client and sends the job over, but the gearman tool already does this.

Example of using gearman as a client:

I use the gearman program as a worker less often. It is still useful for creating a simple worker to test my client code against. I can write my client code without a fully functional worker if the client code is not expecting a complex response.

Example of using gearman as a worker:

The gearman tool comes with the standard options for specifying a specific host and port. There are a number of other options that may be of use in specific circumstances. I encourage you to read them over by typing "gearman -H" on the command line.

Declaring a global functions in a gearman worker script may not seem like a big deal, but these things have a way of catching up to you. I personally ran into this when I suggested that HauteLook start using GearmanManager to manage the gearman workers. A side affect of this is that all gearman worker scripts now run in the same instance of PHP. There were a number of occasions when workers would fail to load on production because of the global naming conflicts.

I prefer to use register anonymous functions with my gearman workers. This keeps them out of the global scope and puts the logic right next to the worker registration call. This makes hard to test the logic inside the anonymous function, but I never test that logic. I treat the functions I register with gearman as controllers. I pass the workload off to a model class that is fully unit tested.

Here is a nice example:

I would update the Gearman examples on php.net, but I think a lot of people are still using PHP 5.2 (or even earlier). Providing multiple ways of registering the workers may confuse people too. Maybe next year.

The release of pecl/gearman 1.0 included a fix to the exception handling of gearman workers. An uncaught exception would go unnoticed by the gearmand server before pecl/gearman 1.0. The only way to work around this was to catch all exception and explicitly return a failure code to gearmand. I fixed this by making by detecting an exception with the pecl/gearman code and sending a special exception message to the gearmand server. Unfortunately, the API for sending the exception message was introduced in gearman 0.21.

I did not think much of the new gearmand requirement when fixing this bug. Since that time I have been introduced to the painful upgrade process of gearmand. I think this pain is mostly felt by those using Linux distributions with long term support. The first hurdle to get over is the fact that gearmand 0.21 requires the boost 1.41 libraries. A default Cent OS install only provides boost 1.39 libraries. There was a 3rd party that provided boost 1.41 libraries for Cent OS, but they used a non-standard installation directory. After some experimenting, I did find a fix: http://groups.google.com/group/gearman/msg/12bcc13691e132ae.

The good news is that upgrading to Cent OS 6 makes compiling gearman much easier with the inclusion of boost 1.41 libraries by default. The next problem comes when trying to submit a patch. Cent OS 5 comes with aclocal 1.9 and the gearman project requires aclocal 1.11. Again, upgrading to Cent OS 6 makes life easier as it comes with aclocal 1.11 by default. I learned the hard way that the gearman project also requires autoconf 2.64, but Cent OS 6 only provides autoconf 2.63. The 2.64 version of autoconf provides a macro named m4_ifnblank which is required to build the configure script used to compile gearman. You can see me answer my own question here: https://answers.launchpad.net/gearmand/+question/185592 regarding the autoconf issue.

These build issues have made it tough for users to upgrade to the pecl/gearman 1.x line. I think I will be forced to maintain the pecl/gearman 0.8.x line for some time with bug fixes as users struggle to get gearmand 0.21 on their Cent OS 5 servers. I have definitely learned to do more research on migration paths before requiring a newer dependency version.

This is a pretty common use case and I am sure most people would write the logic something like this:

There is nothing logically wrong with this code. It is a very readable and easy to understand way to write it. With the rise in popularity of JavaScript and other functional languages, some of us may take a different approach. Using the underscore framework (available for both PHP and JavaScript), you could also write it like this:

The use of a callback function should be familiar to anyone with at least a basic knowledge of JavaScript. The callback function is evaluating each item in the iterator to true or false. The major drawback to both of the code snippets is that the logic for determining whether or not an item is sold out is not able to be re-used. The use of procedural code in the first example and the use of an anonymous function in the second example also make it hard to test. We can improve the second example by not using an anonymous callback:

Now I can re-use this function and easily test it. We can use SPL FilterIterator in a very similar way to the functional example:

Now my logic for what constitutes a soldout item is isolated in a class. This coincides with the object oriented principle of "encapsulate what varies". I think the biggest stumbling block for using SPL is that it just seems too heavy. You might be wondering why you should go to the trouble of creating a new class to perform such a simple task. The procedural example above is faster to write. Some of us might be tempted to use the functional example with an anonymous function because it feels more "expressive". Now consider what happens when the ecommerce system introduces returns. The new formula for determining a soldout item is now:


availability = (purchased - sold) + returned


This isn't some hypothetical example, it actually happened. It was real easy to update the logic to handle returns and make sure the tests passed.

The last decision you have to make is whether or not to put the logic in a database query. If there is a huge performance boost by writing the logic into the query, it may be worthwhile. A query is still testable, but you have to setup some test data in the database in order to test it (which means you probably won't do write the test for it). It is harder to re-use queries, so the business logic for determining sold out items may be duplicated over a number of queries too. You also might want to consider what happens if you decide to alleviate the database load by putting the list of items for sale in a cache (like APC or memcache).

The SPL classes, especially FilterIterator, really start to shine when dealing with a dataset outside of our control. More and more platforms are becoming service based and we have no control over how the data comes back. Especially when you consider something like the Twitter API timeline response and trying to filter out any tweet that starts with "RT".

In order to make development of the gearman workers easier, I created a script to startup the gearman worker in a similar manner to the GearmanManager. The major benefit is that any sort of error or exception is shown right on the terminal screen. No digging through logs wasting time tying to figure out what happened. If you have logging already setup, it is now trivial to add a stdout writer to the logger when running php in cli mode.

One of the biggest complaints I heard from fellow developers was that they had a hard time trying to figure out if the worker actually received the job from the client. I added a logging to stdout that signals when a job is received and what a job is finished.

I setup a pear channel to make installation real easy. For installation instructions and some examples check out the github page page: https://github.com/hradtke/gearboot