The Gearman project has been slowly migrating from C to C++. This migration has gone under the radar due to the popularity of Cent OS 5 and given gearmand version of 0.14. This version of gearmand worked with any version of pecl/gearman and there was never any compelling reason to upgrade gearmand. That changed with the release of pecl/gearman 1.0

The Standard PHP Library (SPL) is a powerful set of tools that are often overlooked. It is very common to see an SPL talk at conferences, but those talks usually just introduce each SPL class to the audience without giving some real world examples. I am going to show you a real world example on how to use SPL FilterIterator in an ecommerce website.

I read a really good post from Vic on his move away from ORM frameworks. I did not agree with everything he said though and wanted to start a discussion. Unfortunately, there is no way to leave comments on his blog. The next best thing is to post it here.

Gearman is one of my favorite technologies to use. So much in fact that I recently decided to take over the maintenance of pecl/gearman. While asynchronous tasks are a great feature, I find the ability to run multiple tasks in parallel to be much more useful. One of the biggest shortcomings of this approach was that uncaught worker exceptions would be treated as a successful completion of a job. I used to wrap all my workers in a generic try/catch block to prevent this from happening.  With the latest commits to pecl/gearman, I can now use the exception callback to properly track the exceptions.

Coding standards are religious in nature, ranking high on the list near vim vs emacs.  Paul Reinheimer woke up many in the twitterverse with a simple post:

The gearman job queue is great for farming out work.  After reading a great post about Poison Jobs, I limited the number of attempts the gearman daemon will retry a job.  This seemed fairly straight-forward to me: if a job fails, then the gearman daemon will retry the job the specified number of times.  I learned the hard way that it was not that simple.  There is specific criteria the gearman daemon follows in order to retry a job.

In my last post, I argued that the best way to start developing functional PHP applications was to code review some JavaScript projects.  I think this is a good place to start as most web developers have written some JavaScript at one point during their career.  I briefly mentioned that the array is pretty similar to the JavaScript object too.  However, if you start hacking away at PHP based on JavaScript's functional syntax, you will quickly run into some problems.

It has been said that all languages, over time, implement a dialect of lisp.  PHP appears to be no exception. 

If you separate your business logic from your data access logic, the last thing you want to do is make your business logic unit tests reliant on the database.  This is normally not a big deal: retrieve the data, store it in an array and pass it off to the class with the business logic.  Mocking the data for the unit test simply requires you to hardcode from array information in the test.  However, I recently ran into a case where I wanted to pass Zend_Db_Table_Row and Zend_Db_Table_Row objects to the business logic and mocking them was not so easy.

I was writing some code today and not using Test-Driven development.  The reason was that I did not have a good understanding of what I was writing, so I decided to write some of the guts before writing the tests.  In the process of writing the guts, I recognized that I was paying very close attention to how I was going to later test each of the methods I was writing. I was paying especially close attention to the Law of Demeter.   The idea behind the Law of Demeter is to keep units of code distinct from one another. So how did this relate to my code?  To put it simply, my business logic methods did not use get methods.

A while back I wrote a post about using Facebook's Thrift.  One comment asked me to post the PHP client used to connect to the C++ server I was demo'ing.  Most of the client is boiler-plate code generated by Thrift, so I chose to omit it at the time.  Here it is:

Phing is a PHP port of Java Ant.  It is a great tool to use in development.  It standardizes a lot of build scripts you would have to maintain internally.  Unfortunately, examples seem to be lacking.  As a quick introduction to Phing, I will show how you can check all your php scripts for syntax errors.

The Zend Framework ships with SOAP functionality and one especially neat class called Zend_Soap_AutoDiscover.  This class uses a comment docblock to auto-generate a WSDL at runtime.  I won't go into the details how it works here, but you can check the Zend Framework documentation for an example.  When using this class at work, I noticed the WSDL would not always generate correctly.  After a lot of digging around, I found the cause: eAccelerator.

There is a new magic constant in PHP 5.3: DIR. This new constant does not actually do anything new. It replaces the use of dirname(FILE) that is commonly found code using prior PHP versions.

Using non-relative URL's during early development can alleviate a lot of growing pains. This may seem counter-intuitive at first, but hear me out. We all learned long ago to stop hard-coding the domain name into the href attribute of an anchor tag. Instead, we used relative URL's such as '/index.php' to make our code much more portable. However, relative URL's become a pain point when trying to scale your website. Let's review some common scenarios that can be averted with some proper planning.

Brandon Savage has a great series of posts on using exceptions in PHP.  Unfortunately, he does not introduce the SPL exceptions into the discussion.

The namespace operator in PHP 5.3 is a backslash (). One of the criticisms of this operator is that the code starts to look like directory paths on Windows. The added side benefit of this is that spl_autoload() knows how to autoload classes that use a namespace style that matches the directory layout.

When I began taking over the web development project at work, I noticed a developer using a lot of static members and methods in his class definitions. His explanation was that it was an optimization he used to improve performance. Unfortunately, he had no metrics to back the statement up. So I set out to do some of my own.

Stefan Esser gave a presentation on Secure Programming with the Zend Framework at the 2009 Dutch PHP Conference. While the presentation was good, one thing that bothered me was the way authentication was being handled.

I started using the phpDocumentor for Vim (PDV) script written by Tobias Schlitt.  Very quickly I found a bug with one of the regular expressions used to parse apart the class definition.  Tobias does not seem to be maintaing this plugin anymore, so I decided I would fix the bug and submit a new version to vim.org.  I packaged up the new version of the script and went to update the PDV page on vim.org only to find out I can't.  There isn't even a mechanism for me to post a comment.

At work we were using VIM for all editing, except PHP.  Back when the decision was made to use PHP for all web development, consultants told us we needed an IDE that offered all kinds of tools that VIM lacks.  So we shopped around for IDE's and eventually bought Zend Studio licenses for everyone.  Today those licesnses are collecting dust.  Even with the feature rich toolset of Zend Studio, and other IDE's, none seem to satisfy our need like VIM does.

At work I maintain a handful of custom PHP extensions.  When someone reports a problem with one of the extensions, I want to fire up gdb right away and see exactly what is going on.  In order to do this, I build a custom php binary with debugging enabled.  I leave this binary inside my home directory so as not to affect my installed production php binary.  I should now be able to rebuild my custom extensions now with debugging enabled and start debugging.  But wait, the configure script rejects the flag.