Writing debuggable code
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:

This got me thinking about why I prefer to write code the way I do. I figure most people choose a standard because they are of the opinion that a certain style of coding is more readable and less error prone. Others are forced to by the community they want to develop in, such as PEAR or Zend Framework. I choose my standard for one reason: debug-ability.
Patching a bug in a pecl extension
In my last post I explained how to build a development version of a pecl extension. Now we will go through the bug lifecycle in the pecl/memcache extension. Besides writing the actual C code to fix the bug, it is considered a best practice to write a test that verifies the bug has been fixed. I will use PECL bug #16442 - memcache_set fail with integer value as an example, even though it is already been fixed.
Building php pecl extensions
My last post I explained how to efficiently checkout the php svn repository. Now we need to start building pecl extensions and even php itself. I prefer to use Cent OS for my linux needs and naturally use rpm's to track all my packages. This means I have a stable version of php installed with all the various extensions that I could want. Rather than messing with this stable version, I am going to build a custom debug build of php in /usr/local. I say "debug", because this build of php will use the --enable-debug option to allow easy debugging using gdb. Since I am doing pecl extension development, I don't want to build the trunk version of php. I want to build my pecl extensions against the most recent stable version of php to isolate environmental issues as much as possible.
Working with the PHP source tree
The svn repository for PHP is rather large. Trying to checkout the entire repo is both time consuming and wastes a lot of space. Most people, including myself, are only concerned with a subset of the repository. One of the advantages svn has over git is the ability to do partial checkouts of the repository. I am going to borrow from an old email Rasmus sent that details how to do a partial checkout of the PHP source code.
Retrying Failed Gearman Jobs
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.
PECL memcache 3.0.6 released
I just released pecl/memcache version 3.0.6 in PECL. This is another set of changes to try and stabilize the new 3.0.x version. Please view the ChangeLog for a list of bug fixes.
Bootstrapping PHPUnit tests
I just recently stumbled upon PHPUnit's --bootstrap flag. I used to bootstrap each of my unit tests using a require statement at the top of the file. I always found this very tedious, but did not want to write some script to wrap each unit test. The --bootstrap flag solves this problem quite nicely.
Stop Inverted Reuse
Reuse is a term often used amongst developers. It usually carries with it a positive connotation and a developer writing reusable code is seen as a good thing. I think there are a lot of developers who have a completely different understanding of what code reuse means. When I talk about code reuse, I am talking about reusing logic within the code. Based on code reviews, it seems the most common definition of reuse is: anytime a function or method is used by two or more callers. This definition fails to realize the true meaning of reuse and can lead to problems. In the name of "reuse", I have noticed some developers group common code at the application level by creating functions or methods that solve some pseudo-generic problem. I call this type or reuse inverted reuse.
Updating PHP Documentation
I sometimes help update the PHP documentation. I have not done it in a while since I started maintaining pecl/memcache. However, there was a recent bug submission where I felt the documentation for pecl/memcache should be updated. A lot of work has been done to the documentation tools since I last updated documentation. I went to http://doc.php.net for a quick primer on how to generate some new documentation output so I could test my changes and found the documentation for generating documentation a little hard to follow.
PHP and apache install errors
I compile a few different versions of PHP on my development server. Every once in a while I run into a problem with PHP installing correctly with apache.
The error looks something like this:
Installing PHP SAPI module: apache2handler
/usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp5.la /usr/local/apache2/modules
/usr/local/apache2/build/libtool --mode=install cp libphp5.la /usr/local/apache2/modules/
cp .libs/libphp5.lai /usr/local/apache2/modules/libphp5.la
cp .libs/libphp5.a /usr/local/apache2/modules/libphp5.a
ranlib /usr/local/apache2/modules/libphp5.a
chmod 644 /usr/local/apache2/modules/libphp5.a
libtool: install: warning: remember to run `libtool --finish /home/flumpy/temp/php-5.0.2/libs'
Warning! dlname not found in /usr/local/apache2/modules/libphp5.la.
Assuming installing a .so rather than a libtool archive.
chmod 755 /usr/local/apache2/modules/libphp5.so
chmod: cannot access `/usr/local/apache2/modules/libphp5.so': No such file or directory
apxs:Error: Command failed with rc=65536
.
make: *** [install-sapi] Error 1
I immediately start googling for a solution to this problem and get caught up in the symptoms. The real problem is that there is a typo in the configure line. In my most recent case, I had a '-' instead of a '--'.





