ORM frameworks are black magic
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.
Code Freeze Fun at HauteLook
I wrote a blog post listing some of the things I have been doing during code freeze at HauteLook. HauteLook is hiring developers for PHP, JavaScript and iOS positions. If you live in the Los Angeles area and are interested check out the careers page.
Testing PHP 5.4RC1
I wrote a quick blog post on HauteLook's Tech blog about testing PHP5.4 RC1 for HauteLook's ecommerce web application.
Please Do Not Interface the PHP World
This started out as a quick response to a blog post titled Interfacing the PHP World by Lukas Kahwe Smith, but it quickly turned into a blog post of its own.
I think common interfaces would be bad for PHP. I find it ironic that a comment made by Stephen is advocating a Java-like dictatorship to move PHP forward. PHP is much more successful and widely used than Java. It is Java should be learning from PHP, not the other way around. PHP is an ugly language with a mish-mash of syntax and conventions that makes the code not very pretty (especially compared to Python). PHP's only saving grace is that it actually gets things done. And luckily, for PHP, that is all that really matters.
Caching, logging and http clients may seem like simple things to standardize, but the mere fact that there are so many differing implementations is proof that they are not so simple. This reminds me of the SimpleCloud framework that tries to standardize the different cloud APIs: there is nothing simple about it! Furthermore, trying to standardize things can kill innovation and creativity. I fear the community will reject a new way to do things on the basis that the code does not implement the standard PHP interfaces. The Lithium framework, which takes a very different approach to frameworks, might not even exist if these interfaces were around a few years ago.
The most progress comes about when people reject or ignore the so called "truths" that surround them. The recent PHP fork is evidence of this. Forking PHP was a huge "no no" (despite the ironic fact that PHP is open source). That fork sparked both change and debate and had a positive effect. The author of the fork had tried to play by the rules setup by the PHP internals team and got nowhere. It was only when he decided to publish a fork that people (particularly those in internals) actually started paying attention.
This notion of interoperability between frameworks is just like trying to achieve nirvana. It is good to try, but never truly attainable. Look at PDO, a (supposedly) "lightweight, consistent interface for accessing databases in PHP". Except that it doesn't work with any of the NoSQL databases. One may argue that PDO is for SQL databases only, except that no one even considered that fact when it was being written. Simply read http://us2.php.net/manual/en/intro.pdo.php and it makes no mention of being SQL only. It assumed that SQL was all there was at the time of writing. The SQL-99 standard was the gospel for databases. This is the danger in defining standard interfaces. The advent of NoSQL made PDO largely irrelevant. The same fate will happen to any standard interface that we come up with today.
I encourage freedom the create new things. I don't want all of my frameworks playing by the same rules. If they are all using common interfaces, then we might as well merge all of the frameworks because the competition is over. Instead, let the adoption rate of the framework be the measure of success. I believe this is why PHP has been so successful. Rasmus has the courage to not try and define or predict what PHP needs. He lets the people using PHP decide what they need. This is in stark contrast to other people in internals that try to exert control of the process and define rigid rules and policies. PHP is not a purely procedural, object oriented or functional language. It is a mashup of all kinds of concepts and ideas. The cool thing is that it works.
Gearman Worker Exception Handling in PHP
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.
How PHPUnit saved HauteLook a lot of duckles
Yesterday I tweed that a phpunit test prevented a very expensive error at HauteLook. I had shared the details internally, but after receiving some positive twitter feedback I decided to make the story public. I am of the opinion that unit tests are a worthwhile investment. Knowing full-well that some people are very skeptical of unit tests, I think it is important to have real world examples of unit tests paying valuable dividends on that investment.
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.





