Category: PHP

Learned these things the hard way, sharing if anyone might find useful.

1) Every method except the magic methods (__construct(), __call(), __get() etc) has a static scope even if you don’t explicitly declare it static . So, public function getCount() is always available, both in static and object instances. But remember, while calling in a static function, using $this will cause a fatal error.

2) Static properties are available ALWAYS through the self:: scope. That means, you can access self::$count both from static and instance scopes. This is good for sharing data between object instances.

3) Even if you declare a method static, it is available from instance scope:

PS: $this is not available if you explicitly declare a method static

Rule of thumb: Every method has a static scope (but properties don’t). Static items are available always – they’re like global properties and remains static across objects. If you explicitly declare a method static, it’ll have a static scope regardless of whether called from an instance or called statically.

The scenario is simple: You’re building an awesome php application but for some reasons you can’t use Zend Framework. You’re a ZF fan and used to depending on Zend_Db_Table variants for your ZF models. Now, thanks to the ZF’s loosely coupled nature, you can load and use ZF components in other apps quite easily. Long ago, I wrote a blog post on how to couple ZF components with Code Igniter. Today, I am going to demonstrate the use of a simple autloader to load and use Zend_Db_Table in a vanilla php app.

Here’s the source code:

First make sure, Zend Framework is in your PHP include path. You can add the location of ZF library to php.ini or use the ini_set() function to set the appropriate value for “include_path”. This is pretty simple, so I am not going to elaborate.

Now we define a simple “load_class” function. And then register it as the autoloading handler. When the script tries to interact with a class, the class name is passed to the function. The function then includes appropriate file. Zend components follow the PEAR convention of naming. So, Zend_Foo_Bar class lives in “Zend/Foo/Bar.php”. Depending on the file name passed, we convert the name to PEAR standard and include the file. Done that, we are now free to use any class from the Zend library and it’ll be automatically loaded.

Before we can define our model, we have to instantiate a database adapter. We used Zend_Db_Adapter_Pdo_Mysql which is based on the PDO driver for MySQL. The configuration is pretty simple.

Now, we extend Zend_Db_Table_Abstract to form our “worker” class which is actually a Zend_Db_Table object. We can use all the methods and features Zend_Db_Table provides in “worker”.

The rest of the code is just self explaining. I just love how flexible and extensible Zend Framework is! 🙂

Links to ZF APIs:
— Database Adapter
— Zend_Db_Table

In my last post on Gearman, I have discussed why I love this tool. In this post, I am going to share some commands and codes to get you started with Gearman.

Install Gearman:

Install Gearman PHP Extension:

Now, let’s install gearman pecl extension:

Did that work? NO! Why? Because Gearman PECL extension is still in beta mode. Unless a PECL package is “stable”, you have to mention the full channel name to force the beta installation:

Did it work? NO! Why? It asks for “libgearman”. Hell no! I can’t find that package! 🙁

Ok, don’t panick! It happens that libgearman was initially released as libgearman1 and afterwards came libgearman2 and libgearman3.

Are you on Ubuntu? Use this:

No, I am on Debian! Okay, try this:

Still no results? Use aptitude to find libgearman.

Now run the command again:

Works, right? If you get an error message regarding “autoconf” or something, Google is your best friend. If everything is okay, go ahead!

Run Gearman Daemon:
Gearman Daemon runs in the background. It matches the client request to the specific worker process. It registers worker processes and distributes the workload among them. To run it:

If you want the daemon to go verbose and help you in debugging with detailed data, use the “-vvv” switch like this:

You can change the startup parameters by editing the file: /etc/default/gearman-job-server. Don’t forget to play with the configuration a bit 🙂

Get a PHP Worker:
Let’s code a handy string processor:

So you see, I built a super useful string processor. With it’s high level of intelligence, it can echo back the string and tell you how many characters were there. When invoked, Gearman shall call the function with the $job parameter as a gearman job. The workload() method will extract parameter passed from the client.

We just defined a function, created a GearmanWorker object, connected to the default server and registered the function.

Now, how do we invoke the job? With a client:

So, what are the output? I had three terminal tabs open. One for the main gearmand with verbose mode, another for worker.php and other one for the client output. Here’s the output sequentially:

NOTES:
— For ease of demonstration, I have executed the client from a command line script, in actual live environment, you shall be calling it from a web app.

— On a remote SSH connection, you may not be able to have 3 terminal tabs open. Put an “&” after the commands to send them to background 🙂

— Use the same command to spawn as many workers as you need

Happy Gearing with PHP!