Not only are they supporting the bill, resitricting a free and open internet, they are also releasing false statements to try and calm down customers by saying they dropped support. On the day of this writing however they have not dropped their support officially.

No matter wether they will drop their support, i’m already looking too move my 5 domains plus hosting away from the company. If an internet company does not get how bad such a bill can, and will, be from the second they lay their eyes on it, they do not deserve any of my money.

I must say i have never had problems with their services or anything, but supporting SOPA is really a statement of complete idiocy, in which i will not partake. This is a completely selfish act on the behalf of GoDaddy imo, so they will loose me, among many others as a customer in the weeks to come…

If you too are a customer, please inform yourself about SOPA.

ubuntu php dev prep commands:

sudo apt-get install vim php5 apache2 libapache2-mod-php5 mysql-server phpmyadmin
sudo apt-get install php-pear php5-xdebug php5-sqlite php5-curl php5-svn php5-mcrypt php5-ldap phpunit
sudo a2enmod rewrite
echo 'ServerName localhost' | sudo tee /etc/apache2/httpd.conf
sudo ln -s /etc/phpmyadmin/apache.conf /etc/apache2/conf.d/phpmyadmin.conf
sudo service apache2 restart
sudo apt-get install subversion git git-svn

pear prep commands:

sudo pear upgrade
sudo pear channel-discover pear.phpunit.de
sudo pear channel-discover pear.symfony-project.com
sudo pear channel-discover components.ez.no
sudo pear install phpunit/PHPUnit --alldeps

mounting shared folder in virtualbox:

sudo mkdir /mnt/workspace
sudo chmod 777 -R /mnt/workspace
echo '[FOLDERNAME]  /mnt/workspace  vboxsf  defaults,rw 0   0' | sudo tee /etc/fstab
sudo mount -a

install sun java jdk to run PHPStorm

sudo add-apt-repository "deb http://archive.canonical.com/ maverick partner"
sudo apt-get update
sudo apt-get install sun-java6-jdk

(thx to this blog for the tip on the repo)

install openVPN support in gnome

sudo apt-get install network-manager-openvpn-gnome

I have used the contextSwitch before, but it was some time ago, and once setup you don’t have to look at it that much anymore, so I guess that’s why I forgot how it worked…
A quick reminder is to follow, including some caveats I encountered while doing the setup.

First things first, initialising the contextSwitch, which I did in a base controller:

abstract class BaseController extends \Zend_Controller_Action
{
    /**
     * Helper to get better code completion
     *
     * @var $conSwitch \Zend_Controller_Action_Helper_ContextSwitch
     */
    protected $contextSwitch = null;

    public function init()
    {
        parent::init();

        $this->contextSwitch = $this->_helper->contextSwitch();
        $this->contextSwitch
                ->setContext('html', array(
                    'suffix' => ''
                ))
                ->setAutoDisableLayout(true)
                ->setAutoJsonSerialization(true)
                ->setDefaultContext('html')
                ->initContext();
    }
}

Fairly easy, or so it seems. There are some oddities in the contextSwitch I was struggling with…

HTML context

For starters, there is no default html context available. This is very odd, since the framework is build to generate HTML pages…
This was easily overcome by just adding it. Note the use of setContext() rather than addContext(), this ensures the context is overwritten when it should exist in the future (after ZF update or someone adds it in a superclass).
I’m also setting an empty suffix, so the default .phtml files will be rendered when using the html context, if I were to set this to ‘html’, the viewRenderer would look for ‘my-action.html.phtml’

setDefaultContext()

Now this one is weird, I actually do not know if this one does anything at all… When in a sub-classed controller action method, which was requested without a ‘format’ get parameter, and I execute the following command:

$this->contextSwitch->getCurrentContext();

It just returns NULL…

Adding action contexts

When I put the above code to use, it was not working. Well, when performing an ajax request to an action, even with the ‘format’ GET parameter set to ‘html’, the contextSwitch did not disable the layout for instance.
To resolve this I added a context for the action I was testing, explicitly:

//in the correct controller
public function init()
{
    parent::init();

    $this->contextSwitch
            ->addActionContext('index', array('html'));
}

Good to go , right? hmm, wrong… Still did not do what I expected it to do, so alt-tabbed and ctrl-T to Google. The solution?

//in the correct controller
public function init()
{
    parent::init();

    $this->contextSwitch
            ->addActionContext('index', array('html'))
            ->initContext(); //init again!!!
}

init again!!!

Most of the stuff I’m about to do is from the a blog post by Ant on CuMu.li, so kudos there. It got me well on my way, but I still had a few issues. The first steps worked perfect:

$ cd /usr/src
$ sudo apt-get source php5
$ sudo apt-get install build-essential debhelper fakeroot
$ sudo apt-get build-dep php5
$ cd php5-5.x.x
$ sudo vim debian/rules

In this file search for “–with-gd=shared,/usr –enable-gd-native-ttf” and change it to “–with-gd=shared –enable-gd-native-ttf”.
So far so good, but running the “dpkg-buildpackage -rfakeroot” command failed on my machine, with the following error:

# start our own mysql server for the tests
/bin/sh debian/setup-mysql.sh 1025 /usr/src/php5-x.x.x/mysql_db
Timed out waiting for mysql server to be available
kill: 65: No such process

kill: 65: No such process

make: *** [test-results.txt] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2

This is caused because the mysql server refuses to run under root, but I had to be root to be able to build the package. After googling for a while I found the solution:

$ sudo vim debian/setup-mysql.sh

In this file comment the line starting the server, and copy the command, adding the “–user=root” parameter:

# Start the daemon
#$mysqld > $datadir/run.log 2>&1 &
#add root user
$mysqld --user=root > $datadir/run.log 2>&1 &

Now the built succeeded, and after install GD worked correctly.

$ sudo dpkg-buildpackage -rfakeroot
$ dpkg -i php5-gd_5.3.5-1ubuntu7.2_amd64.deb

This should normally restart apache2, but if it does not you can do this with the services utility:

$ sudo service apache2 restart

• addition of Traits
• array dereferencing support
• $this support in closures
• indirect method call through an array

All of these might one day get an article, if I manage to do some testing, but for now I’ve only tested the closure enhancements. And with some unexpected results.

If one would create a closure inside a class, PHP5.4 will put that closure inside the same scope as a regular class method. This does not only make $this available inside the closure, but you can also access protected and private methods of said class.
I’ve put a little script together to test this:

<?php
class Test {
    public function testAccess()
    {
        echo PHP_EOL.'-- testing access from within class function '.PHP_EOL;
        $this->testPublic();
        $this->testProtected();
        $this->testPrivate();
        echo PHP_EOL;
    }

    public function getClos() {
        return function ($val) {
            echo PHP_EOL.'== Test from within closure'.PHP_EOL;
            echo $val.PHP_EOL;
            var_dump($this);
            $this->testPublic();
            $this->testProtected();
            $this->testPrivate();
            echo PHP_EOL;
        };
    }

    public function testPublic()
    {
        echo 'can access Public!'.PHP_EOL;
    }

    protected function testProtected()
    {
        echo 'can access Protected!'.PHP_EOL;
    }

    private function testPrivate()
    {
        echo 'can access private!'.PHP_EOL;
    }
}

class TestInher extends Test {
    public function testAccess()
    {
        echo PHP_EOL.'-- testing access from within class function '.PHP_EOL;
        $this->testPublic();
        $this->testProtected();
        $this->testPrivate();
        echo PHP_EOL;
    }

    public function testPublic()
    {
        echo 'accessing the overridden public function'.PHP_EOL;
    }
}

$test = new Test;
$test->testAccess();
$clos = $test->getClos();
$clos('testing closure');

$testInher = new TestInher;
$testInher->testAccess();
$clos = $testInher->getClos();
$clos('testing closure from inherited class');

Now as you would expect, line 46 will fail, because an inherited class can not access a private method of a parent. This is the output of the script with line 46 commented out:

-- testing access from within class function
can access Public!
can access Protected!
can access private!

== Test from within closure
testing closure
object(Test)#1 (0) {
}
can access Public!
can access Protected!
can access private!

-- testing access from within class function
accessing the overridden public function
can access Protected!

== Test from within closure
testing closure from inherited class
object(TestInher)#3 (0) {
}
accessing the overridden public function
can access Protected!
can access private!

The most notable lines here are 20 and 24. The former stating that $this is an object of type ‘TestInher’, but the latter $this->testPrivate() does not result in an error!
I do not know if this was intended behaviour, but will check this through the appropriate channels, an update will follow.

All in all this is a very neat improvement, that I am sure will please lots of devs, me included.

[UPDATE]

After looking at the code again I realised it’s just intended behavior, as it would be exactly the same thing as adding this method to class Test:

    public function sameAsClosure()
    {
        echo PHP_EOL.'== Test from within sameAsClosureFunction'.PHP_EOL;
        echo $val.PHP_EOL;
        var_dump($this);
        $this->testPublic();
        $this->testProtected();
        $this->testPrivate();
        echo PHP_EOL;
    }

From inside the scope of the parent class we can access its private methods, and if we were to extends it, we can also call the public sameAsClosure() method from any scope.

If you are running Ubuntu or any other Debian based Linux chances are that you’re having trouble playing flash in your browser. The install is just unwieldy, because adobe does not have very good linux support and all… The regular version I installed from Adobe Labs gave white squares over the video where stuff was moving a lot, or where buttons are present. Today I stumbled upon the solution for my troubles. It comes in the form of an easy FireFox extension that deletes the Flash plugins you have installed wrongly, and downloads+installs the correct one, in addition some configs are mended so everything runs perfectly.

Link to the extension: https://addons.mozilla.org/en-US/firefox/addon/flash-aid/
Does exactly what it says on the box! Flash videos are going quite nice now on my Ubuntu 10.04

PS: I have tried this with FF4 without any problems, even though the page does only say 3.5 atm.

They also publicise the fact that there are EU servers now, but I’m not sure if that’s actually a new thing… anyway, I wanted to make sure I was in on the goodness.
A one sentence google got me there right away, the server is upgrading for free as I’m typing.
go get yours here, your hosting will be upgraded within the 72 hours.

As you can see in the github repo, there’s a library folder Ctrl, which will contain only namespaced classes. ZF can load these automatically through the following line in the app.ini file:

autoloadernamespaces[] = "Ctrl"

The first file we’ll look at is the interface for a service: lib/Ctrl/Service/IService.php

<?php

namespace Ctrl\Service;

interface IService
{
    static function getType();
    static function factory(array $options = array());
    function getOptions();
}

For creating services it they will implement a factory method, which accepts an array of options. These options can later only be retrieved.
The getType() function will allow us to retrieve the fully qualified class name without having to work with string, which will make the code more maintainable.

On this interface the abstract service class is built: lib/Ctrl/Service/Service.php

<?php

namespace Ctrl\Service;

abstract class Service implements IService
{
    protected $_options = array();

    public function __construct(array $options = array())
    {
        $this->_setOptions($options);
        $this->init();
    }

    /**
     * Constructs a Service instance
     *
     * @param array $options
     * @return Ctrl\Service\Service
     */
    public static function factory(array $options = array())
    {
        $class = self::getType();
        return new $class($options);
    }

    protected function _setOptions(array $options)
    {
        $this->_options = $options;
    }

    public function getOptions()
    {
        return $this->_options;
    }

    public static function getType()
    {
        return get_called_class();
    }

    protected function init() {}
}

This is a pretty simple implementation but it will do for now. What this allows us to do is call the service from anywhere using the factory method:

$logService = Log_Service_Test::factory(array('logDir' => '/var/log'));
$logService->archiveLogbook(array('file' => 'errors.log'));

In the github repo, you can also find an action controller extension which adds a servicebroker to controllers. The service broker will allow to configure a service and retrieve stored services easily, while at the same time provide functionality to create custom services. That component is still somewhat of a work in progress, so maybe there will be an post about it later on… I’ll give you a little taste of what is going around at the moment of writing:

public function testServicesAction()
{
    //old way, stil lpossible of cource
    $service1 = Log_Service_Test::factory(array('test' => 'my first service'));

    //calling service for the first time will set the options
    $service2 = $this->_services->getService(Log_Service_Test::getType(), array('optionsTest' => 'viaBroker! > these options will be set'));

    //calling second time will return the previous instance
    $service3 = $this->_services->getService(Log_Service_Test::getType(), array('second' => 'viaBroker! > these options will be ignored'));

    //so $service2 === $service3 and has the options as defined in the call to create $service2

    //requesting a service through the getLocalService method will skip the internal register and will always create
    //the service with the options passed, this instance will not be saved by the broker
    $service4 = $this->_services->getLocalService(Log_Service_Test::getType(), array('third' => 'viaBroker! --local'));
}

So it’s a start, but not sure if this is a good way of doing it…

Consider the following class:

class MyClass
{
    public function getData()
    {
        $degrees = '10';
        $minutes = '45';
        $seconds = '16';
        return array(
            'int' => 1,
            'float' => $degrees + ($minutes/60 ) + ($seconds/3600 ),
            'string' => 'myString'
        );
    }
}

Notice the hard-coded values as strings, as if they are coming straight out of a file or database. Not that it makes any difference for this example.
If we now know the solution to the calculation beeing made, we can write a unit test. We can do this because our test environment is fully controlled per test, so we know exactly what values are sent to the class. (Allthough they are just hardcoded here for simplicity):

class MyClassTest extends PHPUnit_Framework_TestCase
{
    public function testGetData()
    {
        require_once 'MyClass.php';
        $subject = new MyClass();

        $expected = array(
            'int' => 1,
            'float' => 10.754444444444,
            'string' => 'myString'
        );
        $actual = $subject->getData();

        $this->assertEquals($expected, $actual);
    }
}

Running the unit test will result in the following:

There was 1 failure:

1) MyClassTest::testGetData
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array
 (
     [float] => 10.754444444444
     [int] => 1
     [string] => myString
 )

/test/TestClass.php:20

So PHPUnit tells us the 2 arrays are not equal, but it can not tell us what is wrong with it… This is of course a strange quirk brought to you by the marry world of floating point precicion. The PHP Manual also makes this clear by stating: “So never trust floating number results to the last digit, and never compare floating point numbers for equality.”
This problem can be fixed in several ways, these 2 will both result in a valid Unit Test:

1: change the line where the number is hard-coded to the equal calculation used in the class:

        //change this
        $expected = array(
            'int' => 1,
            'float' => 10.754444444444,
            'string' => 'myString'
        );
        //to this
        $expected = array(
            'int' => 1,
            'float' => 10 + (45/60) + (16/3600),
            'string' => 'myString'
        );

2: alter the result by rounding it

        $actual = $subject->getData();
        //add this line
        if (array_key_exists('float', $actual)) $actual['float'] = round($actual['float'], 12);

There are a couple of other options to get this test working like extending PHPUnit to check value types and acting accordingly. Best way is to put this in a custom assert method which you can use when you know there can be floating point troubles.
Another solution might come from using the BC Math Functions, allthough I’m not sure about this one…

There are a couple of basic programming rules or guidelines you can to follow to make your system works, following them will make your system better in multiple disciplines:

• easy to extend or add features
• consistent API, easy to understand for new developers
• highly testable, and thus robust
• …

The basic points on the agenda to accomplish such a system are:

• keep logic separated, in this case: request, business and persistence logic
• keep functional logic separated from object creation logic
• work with interfaces where possible

Now this is all quite high level, just to give a quick overview. Next up is a more in depth look at how this will translate to the structure of the application.

To keep the logic separated

Specific logic will be assigned to an appropriate place where they can do there thing. Sounds easy enough.

The request logic will be handled by the Controllers:
Controllers take in request data and validate it, and determine whether to redirect or display output, and in the latter case, the format of the output. If a controller wants to perform any action related to business or persistence logic it consults the service layer.

The business logic will be handled completely by the service layer:
Most MVC frameworks in the PHP landscape use fat models, who combine persistence logic with business logic. Although the persistence logic is delegated to a database abstraction layer beneath the models in most implementations, this approach still creates a high coupling between business and persistence logic. (P.S.: And if the model’s aren’t stuffed with both business and persistence logic, your controllers are probably bloated with request and business logic)
The business logic will be extracted into a service layer, which leaves the model with only getters and setters, and some persistence logic which it further delegates.

The persistence logic will be delegated to a database abstraction layer, there are plenty around, the goal is to be able to use any with the service layer, but there will be a specific focus on Zend_Db_Table and Doctrine ORM.

Extract object creation logic

This is a widely practiced art, the factory method, abstract factory pattern and registry pattern are found all over Zend Framework. It makes for easy configuration and dependency injection. In creating factories and registries, the ZF naming will be used, e.g.: Service::factory() or $this->_serviceBroker.
This will benefit the code in both usability, consistency, and testability. It creates a consistent API for the developers, and makes dependency injection easy when writing unit tests. Working with interfaces and abstract classes will help a lot in this area.
Abstracted object creation also means high configurability, the factories creating the objects, can access the configuration and can perform actions on objects before they are released to be used. For instance if you ask a factory to create a UserService, you can configure the factory to subscribe a logger that reacts to certain events the UserService raises.

Side note

PHP 5.3 brings some nice new features to the party like late static binding which is really a godsend for creating abstract factories or implementing factory methods. If you’ve have it available, and are working with any factory patterns, be sure to check it out.