LAMPlights Personal anecdotes from my experiences using the LAMP stack

25Jan/120

Using the Gearman Tool For Rapid Development of Clients and Workers

Gearman comes with a few tools that make development and testing easier. The gearman program creates boilerplate clients and workers. The gearman program comes default with the gearmand package. Do not confuse gearman with gearmand. The gearmand daemon is what manages the queue, clients and workers. The gearman program is a tool to quickly create simple clients and workers. The options for gearman can be slightly confusing, so I will go through a set of examples on how to use them.

24Jan/120

Registering Functions With Gearman Workers

The Gearman examples on php.net are a great primer for groking how the Gearman client and worker interact with each other. One gripe I have is that the examples declare global functions for the worker to register. I feel this leads develpers down the wrong path. With PHP5.3, there is an easier solution though: anonymous functions.

23Jan/120

The Painful Gearman Upgrade Path

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

15Dec/110

SPL FilterIterator in the real world

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.

9Dec/110

PHP Gearman Bootstrap Script

Writing the scaffolding for gearman workers is a pretty trivial task using the pecl/gearman extension. Keeping that scaffolding consistent between all the gearman workers in your application can get tough. I created a script that will remove the boilerplate gearman code and allow gearman worker scrips to simply be function definitions.

9Dec/110

PEAR channel created

I finally got around to creating my own PEAR channel. I am hosting it on github using Pirum to manage the channel. The channel is located at http://hradtke.github.com/pear/. So far I have a single package in then channel: gearboot. I will be writing more about gearboot shortly.

Tagged as: , , No Comments
2Dec/111

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.

Tagged as: , , , , Continue reading
22Oct/119

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.

20Aug/110

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.

14Jul/113

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.