One of the nice things about the Zend Framework is that most of its libraries can be used either from within the framework or as stadalone bits of code which can be seamlessly integrated into non-Zend applications.  Zend_Cache is no exception and can be used to quickly apply caching solutions to common performance problems.  If you are new to caching, or wondering what caching is, it is simply a technique by which something is stored to avoid running the same code over and over again.  For example, if you have a query that is going to be launched time and time again and the result is not going to vary, we can cache it and run it only once, retrieving the cached result until the cache expires thus saving the database a lot of stress.

The hardest part to understand about Zend_Cache is its collection of frontends and backends.  Since the aim of this article is to provide an introduction into quickly deploying a caching solution I will not cover all the options, but they are perfectly covered in the Zend_Cache framework documentation.  However, once we go past the tricky names we can see that a frontend is merely a way to specify what we want to store in cache, and a backend they to specify how.

Zend_Cache can store virtually anything from php objects to pages or functions and, out of the box, supports storage "mediums" such as filesystem, Sqlite, Memcache or Apc among many others.  Again, the documentation provides full reference, but for the purpose of this tutorial we will concentrate on the Core frontend (a generic container of text) and the File backend.  Why?  Because it is the most widely available solution and a good way to get started with Zend_Cache.  If you are interested in other options please comment and I will address them.

Now let's see a simple instantiation of a cache object:

$frontendOptions = array(
    'lifetime' => 3600, // cache lifetime of 1 hour
    'automatic_serialization' => true
);
$backendOptions = array();

$cache = Zend_Cache::factory('Core',
                             'File',
                             $frontendOptions,
                             $backendOptions);

Let's take a look at what we've done.  First, we've defined the option values that will define the behavior of the frontend.  In this case we've given the cached items a lifespan of one hour and we've set the automatic serialization option to true which guarantees the Core frontend becomes a pretty safe container of virtually anything.  Secondly, we've defined the option values for the backend.  In this case I've left it empty since default values are the most generic and work fairly well.  Otherwise, we can change where the files containing the objects are stored, whether they should be locked, whether there should be read control etc...  And finally we create the cache object using the Zend_Cache factory method.  Voilà!  Now let's take a peek on how it's used:

if (!$obj = $cache->load('Object_Expensive_To_Generate')) {
    $obj = new ObjectThatIsExpensiveToGenerate();
    $obj->overloadDatabaseWithExpensiveQueries();
    $obj->hogTheCpu();

    $cache->save($obj, 'Object_Expensive_To_Generate');
}

Woohoo!  Now we only get to go through the painful process of generating an ObjectThatIsExpensiveToGenerate once an hour.  Now let's take a peek at what we've done...  If the object has not yet been cached, or it has expired, the condition in the if clause will return true, and hence start generating and instance of the object.  However, if it has been cached it will skip the if altogether and leave us with a perfectly functional $obj at the other side without going through all the hassle and thus saving valuable resources.  If we do enter the conditional though, the last thing we do is to put the object in cache so we can safely retrieve it for the next hour.

And now that we've finished this brief introduction into Zend_Cache and caching in general, it's time to apply it or to delve deeper and explore what this powerful class has to offer!

The first step in using the Google Analytics API to retrieve insightful data into your PHP application is logging in.  To this end we will use Zend Framework's Gdata libraries which get rid of much of the hassle by providing a comprehensive set of classes and functions that cover most of the GA API needs. The mechanism is simple: you boot up a connection client, use it to open a feed and use that feed to retrieve the necessary reports from GA.

$email = 'some@email.com';    // The email that identifies the Google Analytics Account
$password = 'xXxXxXxXx';      // The Google Analytics account's password

$client = Zend_Gdata_ClientLogin::getHttpClient($email,$password, 'analytics', null, 'curl-accountFeed-v2', null, null, 'https://www.google.com/accounts/ClientLogin', 'GOOGLE');
$feed = new Zend_Gdata_Gapps($client);
$response = $feed->get('https://www.google.com/analytics/feeds/data?ids=ga:13962678&dimensions=ga:browser&metrics=ga:pageviews&filters=ga:browser%3D~%5EFirefox&start-date=2009-01-01&end-date=2009-12-31');
$xml = $response->getBody();

And now, in the $xml variable holds the raw XML with the data from the report so you can collect it and use it in your app!

If we were to argue about what are the most useful things that have come into modern PHP, Exceptions would be one of the first things that would come to mind, and it's still one of the features that most amateur developers tend to leave aside.  However, adequately used, Exceptions give total control on what happens within your application, and most specifically when things go wrong which is when it is most important to try and keep things in check.  Out of the box, Exceptions provide limited but useful information, mainly a message, an error code and some background information on what was being run at the time... but with some skillful plumbing we can get a lot more juice our of them.  Enter the Custom Exceptions!

In fact, Exceptions are meant to be simple in their simplest form.  This way they can provide a clean and reliable set of tools with which we can construct some pretty mean guards to keep our applications in check.  Only we know what's going to go on in our application, and only we know what it's going to take to keep everything in shape!  Most of the time, we know when things can go wrong and how they can go wrong and hence it is easy to protect and correct, but it's when things go unexpectedly wrong that custom exceptions come in very useful as they can give very precise information on exactly where the issue is, and its nature.  To this end, it is important that each possible source of conflict be uniquely labeled and identified in a way that will take us directly to the source of the problem.  An excellent way to achieve this is to relate each class to a unique exception class, and give every single possible problem a unique ID.  Take a simple example:

try {
    Database::connect();
    $user = new User($id);
    $valid = $user->login($password);
}
catch (DatabaseException $e) {
    $errorMsg = 'There was a database problem';
}
catch (UserException $e) {
    if ($e->getCode()==1) $errorMsg = 'The user doesn't exist';
    elseif ($e->getCode()==2) $errorMsg = 'User and password don't match';
    else $errorMsg = 'An error has occurred, our devlopment team has been notified';
}

In this case, the error codes are very simple and provide little information, but they can be tailored to be a little more detailed, even if they can only be numerical strings.  A quick example of this would be to imagine an application being run in different environments, and in which different exceptions can be assigned a "criticality factor" which would decide how bad he exception is and wether the application can continue.  In this case we can divide the numerical error into three parts which would provide necessary information: the first three would indicate the environment, the next three would specify how bad the error is and the last three the ID of the actual exception being thrown.  Therefore an exception with code 003001028 would tell us that Exception 28 has been thrown in environment 3 with a '1' criticality factor.  Hence we can decide if we want to continue executing the script or jump to the 'site down' page, and which server's logs we have to fetch to see what was going on at the time.