The packages provided by 10gen were easy to find and there were no problems installing them on my Ubuntu laptop.  Rather than searching the web for introductions to MongoDB, I decided to learn it from 10gen (the company who developed MongoDB).  I purchased the rough cut of MongoDB: The Definitive Guide from O'Reilly Safari.  This was the first time I have purchased a rough cut book and so far I have no complaints.  I opted for the e-book version so I could get up a running right away (I am also running out of bookshelf space).  I am 3 chapters in and so far I have no complaints.  I am concerned that the ubiquitous use of documents may cause a square peg/round hole issue, but so far I have no run into any problems.  The use of a JSON super-set makes the syntax feel very natural to me and is a huge plus in my opinion.

I will post my thoughts and experiences here as the project progresses and I learn more about MongoDB.  I love learning new things and so far MongoDB has not disappointed.

Before PHP  went OO and autoloading existed, users had little choice but to place require_once statements throughout their code to satisfy the application dependencies.  At the start of a project this was fine as the dependencies were thoughtfully mapped out and the require_once statements strategically placed.  However, as time goes on and code goes through maintenance the require_once creep starts to set in.

What do I mean by require_once creep?  I simply mean that there are require_once statements including code that doesn't need to be included.  This caused a couple of problems:

1. More code for the PHP parser to parse and thus a slower application
2. Confusing code dependencies

Now, admittedly problem 2 is not the major issue problem 1 is.  However, nothing is more frustrating than removing a innocuous require_once from a file only to have some other random file break because it was including that file and depending on that require_once.  There is an entire PHP extension dedicated to helping people solve this very problem: inclued.  I still remember Mozilla's conference talk about refactoring TikiWiki to not simply include every nearly every single library file on every single page.

To fix this problem, autoloading was introduced.  This allowed people to stop using require_once and spawned a method of pseudo-namespacing files.  One of the more popular methods of psuedo-namespacing was the PEAR standard.  This standard said to name the class based on the directory location of the class.  So if I have class in herman/awesome/Solution.php I would name the class Herman_Awesome_Solution.  This obviously gave rise to some pretty long class names, but people generally loved it as it saved them from require_once creep.

Let's fast forward to PHP 5.3.  The "use" keyword is introduced to let users alias long namespaces to a shorter name.  So I can reference the namespace \this\is\a\really\long\namespace as longns.  This is great, now I can reference a really long namespace with a single word.  All I have to do is remember to alias it.  And the aliases are descending, so if I alias a class that alias two other classes, I can use those additional aliases free of charge.

But wait, doesn't it seem like we just went full circle with naming conventions?  We started with simple class names with require_once creep, graduated to autoloading and using super long class names and are now back using simple class names with use creep.  The use creep doesn't have the performance halting side effects of require_once, but it sure seems like it can cause quite a dependency maintenance nightmare.  It may be no problem for you, but what about the guy coding next to you who really doesn't care?

I think I will stick to using the fully qualified namespace (FQN) of a class.  It will take a few more keystrokes, but it keep my dependencies cleaner.

1. Prefix a relative url path with a host.
2. Rotate a set of relative url's through a given number of cdn hosts.

We currently use Zend Framework at work, so it is only logical we use as much of the framework as possible.  The straight forward approach is to extend Zend_View_Helper_Abstract and create a few functions to fill the requirements.  There are few problems with this approach.  The first is function creep.  We know we need to prefix http://www.hautelook.com and https://www.hautelook.com, but there may be more later.  We may decide to use something like https://ssl.hautelook.com or require another subdomain like http://ftp.hautelook.com.  This would require us to create another function, write some unit tests for it and finally send it through QA.  This issue is even more compounded with the cdn rotation function.

Another problem is that we need absolute url's in some of our business logic.  We have webservices that serve up XML or JSON that contain locations to such as images or a catalog.  We want these services to take advantage of the absolute url logic too.  If we implement a view helper, then the service layer becomes coupled to the view in order to reuse the logic.

Enter PHP 5.3, functional programming and an inspirational post from Eli White.  We can use the factory method pattern and closures to meet all the requirements and isolate the parts that change.  Read these posts if you are not familiar with functional programming in PHP.

class Crimson_Url
{
    public static function absolute($host)
    {
        return function($path) use ($host) {
            return "{$host}{$path}";
        };
    }
 
    public static function rotate($subdomain, $host, $rotations, $protocol='http')
    {
        $current = 0;
 
        return function($path) use (&$current, $subdomain, $host, $rotations, $protocol) {
            if ($current == $rotations) {
                $current = 1;
            } else {
                $current++;
            }
 
            return "{$protocol}://{$subdomain}{$current}.{$host}{$path}";
        };
    }
}

The absolute function demonstrates how simple, yet powerful, closures can be.  The absolute function is creating a function that concatenates to strings together: a host name and a relative url.  Here is how we would use this:

$www = Crimson_Url::absolute('http://www.example.com');
$ssl = Crimson_Url::absolute('https://www.example.com');
 
echo $www('/foo.jpg'), PHP_EOL;
echo $ssl('/secure.php'), PHP_EOL;

Output:

http://www.example.com/items.php

https://www.example.com/secure.php

Take this one step further and think about how you can use the HTTP_HOST or HTTP_REFERER values from $_SERVER to make absolute URL generation almost completely automatic.

The rotate function is slightly more complex.  The $current variable is being declared in the factory method and passed by reference.  We must explicitly pass this by reference otherwise PHP will pass it by value and the value of $current will be 1 everytime.  Here is how we would use the rotater:

$cdn = Crimson_Url::rotate('cdn', 'hautelook.com', 3);
$sslCdn = Crimson_Url::rotate('cdn', 'hautelook.com', 3, 'https');
 
echo $cdn('/foo.jpg'), PHP_EOL;
echo $cdn('/bar.jpg'), PHP_EOL;
echo $cdn('/baz.jpg'), PHP_EOL;
echo $cdn('/bob.jpg'), PHP_EOL;
 
echo $sslCdn('/foo.jpg'), PHP_EOL;
echo $sslCdn('/bar.jpg'), PHP_EOL;

Output:

http://cdn1.hautelook.com/foo.jpg

http://cdn2.hautelook.com/bar.jpg

http://cdn3.hautelook.com/baz.jpg

http://cdn1.hautelook.com/bob.jpg

https://cdn1.hautelook.com/foo.jpg

https://cdn2.hautelook.com/bar.jpg

Notice how there are no problems with static variable conflicts. Each function is independent and can be used for completely different tasks.

The complete source code, with tests and documentation, can be found here: http://github.com/hradtke/crimson/tree/master/Crimson_Url

One major difference between PHP and JavaScript style closures.  Here is a typical JavaScript closure:

// start counting from some number
function counter(n) {
    return function() {
        return n++;
    }
}
 
countFrom3 = counter(3);
console.log(countFrom3());
console.log(countFrom3());
console.log(countFrom3());
console.log(countFrom3());

We can write this same function in PHP.  The main difference is the "use" identifier required for closure:

<?php
function counter($n) {
    return function() use($n) {
        return $n++;
    };
}
 
$countFrom3 = counter(3);
echo $countFrom3(), PHP_EOL;
echo $countFrom3(), PHP_EOL;
echo $countFrom3(), PHP_EOL;
echo $countFrom3(), PHP_EOL;

If you run this code, it will not work as expected: every number will be 3.  Why?  Well, the closure RFC for PHP requires that variables are only explicitly passed by reference.  That means we need to use modify the function signature:

<?php
function counter($n) {
    return function() use(&$n) { // <--- note the pass by reference syntax
        return $n++;
    };
}

Now JavaScript does not have traditional classes like PHP.  Instead, we define an object with a set of variables.  Object methods are simply variables that reference an anonymous function.  Something like this:

obj = {};
obj.add = function(l, r) {
    return l + r;
};
 
console.log(obj.add(1, 2));

Let's write that same function in PHP.  It has very similar syntax:

<?php
$obj = new stdClass;
$obj->add = function($l, $r) {
    return $l + $r;
};
 
echo $obj->add(1, 2), PHP_EOL;

If you run this you will notice that PHP complains that the object does not have that method.  In PHP, functions are not quite first class citizens.  The variable function is completely ignored and only explicitly declared method's are allowed to be called this way.  We need to modify our example to make this work:

<?php
$obj = new stdClass;
$obj->add = function($l, $r) {
    return $l + $r;
};
 
$add = $obj->add;
echo $add(1, 2), PHP_EOL;

With these nuances out of the way, you have can have a productive functional hacking session.  Have fun!

All this talk of functional language features is great, but Lithium is still in development, Zend Framework 2.0 is a ways away, you have an upcoming project deadline and you want to know how this stuff can help you now.  Easy: go read or watch JavaScript examples.  Seriously.  Watching Douglas Crockford's videos on YUI theatre or reading through ExtJS source code can give you really good insight into the power of functional language features.  The syntax may be different, but the core ideas are the same.

The new functional feel of PHP seems to have started a trend towards a unified constructor.  This has been a common practice in the JavaScript community for some time.  The great thing is that the PHP array is very similar to the JavaScript object.  In fact, the JSON extension to PHP makes them completely interchangeable.  Here is a quick example of one unified constructor implementation in PHP:

<?php
 
$p = array(
    'a' => 'hi',
    'adder' => function($n) { return $n + 1; },
    'c' => 3,
    'd' => new stdClass
);
 
class base {
    function __construct(array $params)
    {
        foreach ($params as $key => $value) {
            $this->$key = $value;
        }
    }
}
 
class foo extends base { }
 
$foo = new foo($p);

I have a bunch of ideas (some great, some maybe not so great) that I plan on implementing using lambda functions and closures. I will be adding new components to my Crimson library and discussing them here.

I first attempted to mock Zend_Db_Table_Row using PHPUnit's _getMock method.  This proved to be an exercise in futility.  I did not want the class to connect to the database to verify whether or not the columns were valid.  After a few frustrating hours, I started to wonder how Zend was unit testing Zend_Db_Table_Row.  So I downloaded the full version of the latest Zend Framwork and started poking around.  I stumbled upon My_ZendDbTable_Row_TestMockRow hiding away in ZendFramework-1.9.5/tests/Zend/Db/Table/_files/My/ZendDbTable/Row/TestMockRow.php.  I will not go into what was done to make it a usable mock, but I will show you how to use it.

<?php
 
require_once 'PHPUnit/Framework/TestCase.php';
require_once 'tests/Zend/Db/Table/_files/My/ZendDbTable/Row/TestMockRow.php';
 
class TestMockRowTest extends PHPUnit_Framework_TestCase
{
    public function testRowHasIdValue()
    {
        $data = array(
            'data' => array(
                'first_name' => 'Herman',
                'last_name' => 'Radtke',
                'email' => 'herman@example.com'
            )
        );
 
        $row = new My_ZendDbTable_Row_TestMockRow($data);
        $this->assertEquals('Herman', $row->first_name);
        $this->assertEquals('Radtke', $row->last_name);
        $this->assertEquals('herman@example.com', $row->email);
    }
}

Creating a mock row object is much like hardcoding an array.   Define an array that has a single key 'data' that contains an array as a value.  Inside this array, the database column name is the array key and the database column value is the array value.

That class works great for mocking a single row object, but I still needed a solution for multiple row objects.  I expected to find a class similar to My_ZendDbTable_Row_TestMockRow for the purposes of testing Zend_Db_Table_Rowset, but none existed.  Fortunately, it took only a few minutes to create my own.  All one has to do is specify the name of the row class for the rowset class to use.

<?php
 
require_once 'PHPUnit/Framework/TestCase.php';
require_once 'library/Zend/Db/Table/Rowset/Abstract.php';
require_once 'tests/Zend/Db/Table/_files/My/ZendDbTable/Row/TestMockRow.php';
 
class ZendDbTableMockRowset extends Zend_Db_Table_Rowset_Abstract
{
    protected $_rowClass = 'My_ZendDbTable_Row_TestMockRow';
}
 
class RowsetTest extends PHPUnit_Framework_TestCase
{
    public function testConstructor()
    {
        $rowset = new ZendDbTableMockRowset(array(
            'data'=> array(
                array(
                    'id' => 123456
                ),
                array(
                    'id' => 123457
                ),
                array(
                    'id' => 123458
                ),
                array(
                    'id' => 123459
                ),
                array(
                    'id' => 123460
                )
            )
        ));
 
        $id = 123456;
        foreach ($rowset as $row) {
            $this->assertTrue(($row instanceof My_ZendDbTable_Row_TestMockRow));
            $this->assertEquals($id, $row->id);
            $id++;
        }
    }
}

The array passed to the mock rowset has a similar structure to the one we used above.  The only difference is that we have multiple arrays, inside the 'data' array, each representing one row.   For testing purposes, I created an 'id' field.   I normally would not ever use an artificial key field inside a business logic class since that value is very dependent on the database.

I created a ZendDbTableMockRowset class in my projects test/mocks directory so I can use it in multiple test files.  I also copied My_ZendDbTable_Row_TestMockRow into the test/mocks directory so I would not be dependent on the external tests from Zend Framework.  Now mocking Row or Rowset objects is just as fast as mocking arrays.

The only downside to this is that syslog commonly has a limit of 1024 characters per message.  You can change this, but you have to recompile the kernel.  This is especially frustrating when an uncaught exception gets logged.  The log message looks something like this:

PHP Fatal error:  Uncaught exception 'Zend_Db_Statement_Exception' with message 'SQLSTATE[HY093]:
Invalidparameter number: no parameters were bound' in /some/path/to/Zend/Db/Statement
/Pdo.php:234Stack trace: #0 /some/path/to/Zend/Db/Statement.php(320): Zend_Db_Statement_
Pdo->_execute(Array)#1 /some/path/to/Zend/Db/Adapter/Pdo/Mysql.php(572): Zend_Db_
Statement->execute(Array) #2 /some/path/to/Zend/Db

If you have used Zend_Db_Statement you have probably seen this error message.  If not, it simply means that too few variables are being specified or one of the variables is null when trying to bind all the variables to the placeholders in a SQL statement.  Do you see the problem with this log message though?  It gets cut off way before the stack trace provides any hint as to what code caused it.  If I am using automated testing, it may be very difficult to tell what actually caused the exception.

To get around this, I wrote an exception handler to split the stack trace into separate messages.

SQLSTATE[HY093]: Invalid parameter number: no parameters were bound Strack Trace:
PHP 0. _execute /some/path/to/Zend/Db/Statement.php:320
PHP 1. execute /some/path/to/Zend/Db/Adapter/Pdo/Mysql.php:572
PHP 2. query /some/path/to/Zend/Db/Table/Abstract.php:1509
PHP 3. _fetch /some/path/to/Zend/Db/Table/Abstract.php:1325
PHP 4. getDooDads /some/path/to/application/default/models/DooDads.php:112
PHP 5. getAction /some/path/to/application/default/controllers/DooDadsController.php:15
PHP 6. init /some/path/to/Zend/Controller/Action.php:133
PHP 7. __construct /some/path/to/Zend/Controller/Dispatcher/Standard.php:262
PHP 8. dispatch /some/path/to/Zend/Controller/Front.php:946
PHP 9. dispatch /some/path/to/html/index.php:23

Now it is very clear that I need to add some more validation to my DooDads model.

The code is on github here.  I am able to just drop it in to any project I am working on and get more verbose logging via syslog.

I have never had a problem with the lack of canonical version numbers, but I can see why companies who have used CVS or subversion for a long time would be wary of getting rid of them.  Morgan explains how to use the git describe command to generate canonical version numbers.  I have used git for a while for personal projects and at HauteLook, but have never used this command.  I thought this was a great solution to a problem a lot of companies face when trying to migrate from subversion to git.

Morgan's comment:

git describe –tags –long

This gives you a string like (in the case of one of my projects)

2.1pre5-4-g675eae1

which is formatted as

{last reachable tag name}-{# of commits since that tag}-#{SHA of HEAD}

This gives you a ‘canonical version number’ (spelling corrected) that is monotonically increasing by commits, and unique across multiple repositories of development. If we’re all on the same HEAD, it will return the same value. If we all share the same most-recent-tag, but have different commits, the SHA will be different.

Assume we have a person class.  The class constructor takes the persons full name and we have a getter and setter for the full name.

<?php
class Person
{
    protected $fullName;
 
    public function __construct($fullName)
    {
        $this->setFullName($fullName);
    }
 
    public function setFullName($fullName)
    {
        $this->_fullName = $fullName;
    }
 
    public function getFullName()
    {
        return $this->_fullName;
    }
}

There is also a method that parses apart the persons full name into separate parts. The naive approach:

    public function parseFullName()
    {
        $nameParts = explode(' ', $this->getFullName());
        ...
    }

This code works fine, but think about how we will write a test for this function.  We have to first set the full name using a setter so the parseFullName method can retrieve that value with a getter.  This violates one of the principle rules of unit testing: testing individual units of code.  If there is a bug in the getter or setter functions, they may inadvertently affect my test.  This is a very real issue when using the magic __get and __set methods. It also means more work to setup your tests because you have to keep in mind an order of operations when testing.

The better approach:

    public function parseFullName($fullName)
    {
        $nameParts = explode(' ', $fullName);
        ...
    }

Notice how the parseFullName function is being told what to parse rather than asking what to parse.  This subtle change now allows us to truly test this individual unit of code with the least amount of outside environment interaction.