There are some example usage and instructions on how to install PHP_BitTorrent over at the project page on GitHub.

I have also done some more work on the BitTorrent tracker part of the project which is available in a separate branch (not a part of the 0.2.0 release). Feel free to play around with it and don’t hesitate to send me a pull request if you have improvements for it.

Read all about it over at VG Tech.

I will continue to write on this blog, but if you are interested in web technologies be sure to checkout VG Tech as well.

Traits is a mechanism for code reuse in single inheritance languages such as PHP. A Trait is intended to reduce some limitations of single inheritance by enabling a developer to reuse sets of methods freely in several independent classes living in different class hierarchies. The semantics of the combination of Traits and classes is defined in a way, which reduces complexity and avoids the typical problems associated with multiple inheritance and Mixins.

There are some nice examples over at the RFC, and I will provide another example in this post.

But first, to be able to play with this we need to build PHP. It’s the usual ./configure; make; make test; dance so it should not pose too many problems. The make test step is optional, but every time you skip that step, God creates another Perl programmer, so please, make test. If you run into any problems building PHP you will have to look elsewhere for answers. I won’t cover that in this post.

Now that you have built PHP, lets start writing some code.

When working on a framework (or something else for that matter), you will most likely need to introduce parameters for some of your classes, be it database adapters or a storage adapter. All these classes will most likely have the following methods:

• setParams(array $params)
• getParams()
• setParam($key, $value)
• getParam($key)

The implementation of these methods will most likely be the same. If you put the actual implementation of these methods in many classes you’re not DRY anymore. Since PHP does not support multiple inheritance you will have to make a base class with the implementation of these methods, and have other classes ultimately extend this base class. Now you are relatively DRY, but this solution is not optimal(and sometimes not possible at all).

Enter traits, the newest superhero on the PHP street, or something like that.

Now, I’ll create two classes that needs to support parameters; Cogo\Database\MySQL and Cogo\Storage\Filesystem. They will each extend Cogo\Database and Cogo\Storage respectively that will have the parameter-related methods.

<?php
namespace Cogo;

abstract class Database {
    private $params;

    public function __construct(array $params) {
        $this->setParams($params);
    }

    private function setParams(array $params) {
        $this->params = $params;
    }

    public function getParams() {
        return $this->params;
    }

    protected function setParam($key, $value) {
        $this->params[$key] = $value;
    }

    public function getParam($key) {
        return (isset($this->params[$key]) ? $this->params[$key] : null);
    }

    protected function someDatabaseRelatedMethod() {
        // ...
    }

    abstract protected function someOtherDatabaseRelatedMethod();
}

<?php
namespace Cogo\Database;
use Cogo\Database;

class MySQL extends Database {
    protected function someOtherDatabaseRelatedMethod() {
        // ...
    }
}

<?php
namespace Cogo;

abstract class Storage {
    private $params;

    public function __construct(array $params) {
        $this->setParams($params);
    }

    public function setParams(array $params) {
        $this->params = $params;
    }

    public function getParams() {
        return $this->params;
    }

    public function setParam($key, $value) {
        $this->params[$key] = $value;
    }

    public function getParam($key) {
        return (isset($this->params[$key]) ? $this->params[$key] : null);
    }

    protected function someFilesystemRelatedMethod() {
        // ...
    }

    abstract protected function someOtherFilesystemRelatedMethod();
}

<?php
namespace Cogo\Storage;
use Cogo\Storage;

class Filesystem extends Storage {
    protected function someOtherFilesystemRelatedMethod() {
        // ...
    }
}

As you can see the parameter-related methods are almost the same. The difference is that the Cogo\Database class wants to have its set methods private and protected.

One possibility would be to create a base class for the parameter handling, and have the two abstract classes extend that one, but because multiple inheritance is not possible in PHP it’s easy to grind to a halt using this solution. In the end you might end up with a huge base class with loads of logic simply because it has some logic that you want to share across many other classes.

The base class would also have to have private on the set methods since you can’t override a method with a stricter visibility, only the other way around.

Using traits, this can be solved in a more elegant fashion. Traits also support changing visibility of the methods defined in the trait, so Cogo\Database can keep its private and protected implementations. Here is how the trait can look like:

<?php
namespace Cogo;

trait ParamsHandler {
    private $params;

    public function __construct(array $params) {
        $this->setParams($params);
    }

    public function setParams(array $params) {
        $this->params = $params;
    }

    public function getParams() {
        return $this->params;
    }

    public function setParam($key, $value) {
        $this->params[$key] = $value;
    }

    public function getParam($key) {
        return (isset($this->params[$key]) ? $this->params[$key] : null);
    }
}

Notice that the trait now contains all logic regarding parameters (including the $params property and the constructor). The RFC states that:

Since Traits do not contain any state/properties …

This seems to work after all. The RFC was created a while ago and it no longer matches the actual implementation 100% obviously.

Now that we have a trait with the logic we want in both our abstract classes, let’s use it:

<?php
namespace Cogo;

abstract class Database {
    use ParamsHandler {
        setParams as private;
        setParam as protected;
    }

    protected function someDatabaseRelatedMethod() {
        // ...
    }

    abstract protected function someOtherDatabaseRelatedMethod();
}

<?php
namespace Cogo;

abstract class Storage {
    use ParamsHandler;

    protected function someFilesystemRelatedMethod() {
        // ...
    }

    abstract protected function someOtherFilesystemRelatedMethod();
}

As you can see we have replaced the implementation of the parameter methods from both abstract classes with a couple of use statements. In the Cogo\Storage class we have used the methods from the trait as-is, which means they are all public. In the Cogo\Database class we have changed the visibility of two methods to match the initial implementation. We have now managed to keep ourselves DRY, as well as not creating a base class that the two abstract classes extends.

This is just a simple example of how to use traits. They can do loads more, and there are issues like for instance conflict resolution which is not mentioned in this post at all. I will probably post more examples of traits (and perhaps other 5.4 features) later on. In the meantime you should read the RFC, and try it out for yourself.

You will find all the code mentioned in this post over at my php-traits-examples repository at GitHub. Feel free to play around with it, and if you have other examples on how to use traits please fork the project and send me a pull request so I can include it (and learn from it).

Consider a class method looking like this:

class Database {
    public function insertData($hash, Image $image) {
        $data = array(
            'hash' => $hash,
            'name' => $image->getName(),
        );

        $this->getCollection()->insert($data, array('safe' => true));
        $image->setId((string) $data['_id']);

        return true;
    }

    // ...
}

The Image class is just some custom class, and the getCollection() method returns a property set in the class (so I can inject mocked versions of the collection and not depend on MongoCollection).

As you see from the code above the insertData() method changes the first parameter (it adds an _id element that is set to an instance of MongoId). The problem with testing the above method is that when mocking MongoCollection you can’t make it add the _id element to the passed array, so the test fails because of an E_NOTICE that says:

Undefined index: _id.

I tried to solve the problem by using Mockery (a simple but flexible (and awesome) mock object framework by Pádraic Brady) like this:

public function testInsertData() {
    $id = MongoId();
    $idAsString = (string) $id;
    $image = \Mockery::mock('Image');
    $image->shouldReceive('setId')
          ->once()
          ->with($idAsString)
          ->andReturn($image);
    $image->shouldReceive('getName')
          ->once()
          ->andReturn('some name');

    $collection = \Mockery::mock('MongoCollection');
    $collection->shouldReceive('insert')
               ->once()
               ->with(\Mockery::on(
                   function(&$data) use($id) {
                       $data['_id'] = $id;
                       return true;
                   }), \Mockery::type('array'));

    // The object we want to test with
    $database = new Database;
    $database->setCollection($collection);
    $database->insertData($hash, $image);
}

When running the above test I get the following error:

Parameter 1 to {closure}() expected to be a reference, value given

This is because Mockery uses the call_user_func_array function to call the closure given to \Mockery::on(), and that function does not support references. PHPUnit also uses this function internally for its mock objects.

The description of MongoCollection::insert() in the PHP manual looks like this:

public mixed MongoCollection::insert ( array $a [, array $options = array() ] )

Feeling a bit bold I tried to change the insertData() method above to pass an instance of stdClass instead of an array to MongoCollection::insert(). Why? Objects in PHP-5 are all references, so I might be able to get Mockery to work without having to specify &$data in the closure. It’s not documented, but hey, you never know without trying right? Here is the new version of insertData():

public function insertData($hash, Image $image) {
    $data = new stdClass;
    $data->hash = $hash;
    $data->name = $image->getName();

    $this->getCollection()->insert($data, array('safe' => true));
    $image->setId((string) $data->_id);

    return true;
}

The only change I made in the test method was to change the closure I give to \Mockery::on() from:

function(&$data) use ($id) {
    $data['_id'] = $id;
    return true;
}

to

function($data) use ($id) {
    $data->_id = $id;
    return true;
}

and voila, the test works! The part about giving an instance of stdClass to MongoCollection::insert() is not documented, and I’m not sure if it’s a feature that’s going to stay implemented.

At first I tried to solve this using the built in mock objects in PHPUnit, but since they clone the objects used in the mocks the trick above would not work anyway as the change would not be made on the correct reference.

And thats that!

Pirum is a simple and nice looking PEAR channel server manager that lets you setup PEAR channel servers in a matter of minutes. Pirum is best suited when you want to create small PEAR channels for a few packages written by a few developers.

First you will need to install Pirum. This can be done via pear:

christer@aurora:~$ sudo pear channel-discover pear.pirum-project.org
Adding Channel "pear.pirum-project.org" succeeded
Discovery of channel "pear.pirum-project.org" succeeded
christer@aurora:~$ sudo pear install pirum/Pirum
downloading Pirum-1.0.0.tgz ...
Starting to download Pirum-1.0.0.tgz (11,732 bytes)
.....done: 11,732 bytes
install ok: channel://pear.pirum-project.org/Pirum-1.0.0

If your PEAR environment is set up correctly you should now have an executable called pirum. Run the command to see what it can do:

christer@aurora:~$ pirum
Pirum 1.0.0 by Fabien Potencier
Available commands:
pirum build target_dir
pirum add target_dir Pirum-1.0.0.tgz

The first thing you want to do is just choose a target directory for where you want to have your channel along with the packages served by the channel. Create the target directory and add a file called pirum.xml inside it that will be used by pirum when building the channel. The file can look like this:

<?xml version="1.0" encoding="UTF-8" ?>
<server>
  <name>pear.starzinger.net</name>
  <summary>Starzinger PEAR channel</summary>
  <alias>stz</alias>
  <url>http://pear.starzinger.net/</url>
</server>

This is the pirum.xml file I used when setting up pear.starzinger.net. Most tags are self descriptive except for the <alias> tag. That is the “shortcut” users can use when querying your channel. If you look at how I installed pirum above you can see that I used the “pirum” alias in the install command. The Starzinger PEAR channel uses “stz” so when querying the channel you can just do:

christer@aurora:~$ pear list -c stz
Installed packages, channel pear.starzinger.net:
================================================
Package        Version State
PHP_BitTorrent 0.0.1   alpha
SqlDiff        0.0.3   beta

Now that the pirum.xml file is in place, run the following command to build the channel:

christer@aurora:~$ pirum build /var/www/pear
Pirum 1.0.0 by Fabien Potencier
Available commands:
pirum build target_dir
pirum add target_dir Pirum-1.0.0.tgz

Running the build command:
INFO   Building channel
INFO   Building maintainers
INFO   Building categories
INFO   Building packages
INFO   Building releases
INFO   Building index
INFO   Building feed
INFO   Updating PEAR server files
INFO   Command build run successfully

Now you will need to setup apache to have a host pointing to the newly created channel. This can be done for instance via a regular VirtualHost setup:

<VirtualHost *:80>
        ServerName pear.starzinger.net
        DocumentRoot /var/www/pear
</VirtualHost>

Now, when browsing pear.starzinger.net you will see something like this:

Now you just need to add some packages. As an example I will add a couple of packages that I have on my own PEAR channel:

christer@aurora:~$ pirum add /var/www/pear SqlDiff-0.0.3.tgz
Pirum 1.0.0 by Fabien Potencier
Available commands:
pirum build target_dir
pirum add target_dir Pirum-1.0.0.tgz

Running the add command:
INFO   Parsing package 0.0.3 for SqlDiff
INFO   Building channel
INFO   Building maintainers
INFO   Building categories
INFO   Building packages
INFO   Building package SqlDiff
INFO   Building releases
INFO   Building releases for SqlDiff
INFO   Building release 0.0.3 for SqlDiff
INFO   Building index
INFO   Building feed
INFO   Updating PEAR server files
INFO   Command add run successfully

And then another:

christer@aurora:~$ pirum add /var/www/pear PHP_BitTorrent-0.0.1.tgz
Pirum 1.0.0 by Fabien Potencier
Available commands:
pirum build target_dir
pirum add target_dir Pirum-1.0.0.tgz

Running the add command:
INFO   Parsing package 0.0.3 for SqlDiff
INFO   Parsing package 0.0.1 for PHP_BitTorrent
INFO   Building channel
INFO   Building maintainers
INFO   Building categories
INFO   Building packages
INFO   Building package PHP_BitTorrent
INFO   Building package SqlDiff
INFO   Building releases
INFO   Building releases for PHP_BitTorrent
INFO   Building release 0.0.1 for PHP_BitTorrent
INFO   Building releases for SqlDiff
INFO   Building release 0.0.3 for SqlDiff
INFO   Building index
INFO   Building feed
INFO   Updating PEAR server files
INFO   Command add run successfully

Now, take a look at the pear channel again in your browser:

The current version of Pirum (1.0.0) does not support anything other than building the channel and adding packages. If you for instance want to remove a package you added by mistake you will need to manually remove files from the get directory in your channel dir, and re-build using pirum. Lets try to remove the PHP_BitTorrent-0.0.1 package:

christer@aurora:~$ cd /var/www/pear/get
christer@aurora:/var/www/pear/get$ rm PHP_BitTorrent-0.0.1.tar PHP_BitTorrent-0.0.1.tgz
christer@aurora:/var/www/pear/get$ pirum build /var/www/pear
Pirum 1.0.0 by Fabien Potencier
Available commands:
pirum build target_dir
pirum add target_dir Pirum-1.0.0.tgz

Running the build command:
INFO   Parsing package 0.0.3 for SqlDiff
INFO   Building channel
INFO   Building maintainers
INFO   Building categories
INFO   Building packages
INFO   Building package SqlDiff
INFO   Building releases
INFO   Building releases for SqlDiff
INFO   Building release 0.0.3 for SqlDiff
INFO   Building index
INFO   Building feed
INFO   Updating PEAR server files
INFO   Command build run successfully

If you take a look at the channel in your browser now you will see that the package has been removed:

The next version of pirum will support removing packages via the pirum command (contributed by yours truly).

And thats that!

To install simply do:

christer@aurora:~$ sudo pear channel-discover pear.starzinger.net
Adding Channel "pear.starzinger.net" succeeded
Discovery of channel "pear.starzinger.net" succeeded

if you haven’t already added the channel, and then:

christer@aurora:~$ sudo pear install stz/SqlDiff-beta
downloading SqlDiff-0.0.2.tgz ...
Starting to download SqlDiff-0.0.2.tgz (13,038 bytes)
.....done: 13,038 bytes
install ok: channel://pear.starzinger.net/SqlDiff-0.0.2

Read more about SqlDiff on the project page over at github.com.

Currently the tool only supports the XML format created by MySQL’s mysqldump (with the -X option). The tool is extensible so if anyone out there wants support for some other database as well, feel free to fork the project and send me a pull request.

More information (installation and usage) can be found on the project page at github: https://github.com/christeredvartsen/sqldiff

The package is available from my pear channel(pear.starzinger.net). Register the channel using the following command:

christer@aurora:~$ sudo pear channel-discover pear.starzinger.net
Adding Channel "pear.starzinger.net" succeeded
Discovery of channel "pear.starzinger.net" succeeded

And then you can install the package using:

christer@aurora:~$ sudo pear install stz/PHP_BitTorrent-alpha
downloading PHP_BitTorrent-0.0.1.tgz ...
Starting to download PHP_BitTorrent-0.0.1.tgz (8,037 bytes)
.....done: 8,037 bytes
install ok: channel://pear.starzinger.net/PHP_BitTorrent-0.0.1

The project is hosted at github.

I went to this talk hoping to get some more information about MongoDB combined with object persistence. It turned out that the system Stefan was supposed to talk about was not yet finished, so instead he talked about generic ways of achieving object persistence. I believe parts of the code that he used in his slides is taken from the system he was supposed to talk about.

He also mentioned a couple of nasty tricks that should never be used in production, like creating an instance of a class without running the constructor (using unserialize) and making private and protected properties accessible using Reflection.

Lazy loading was also mentioned which is very important when dealing with ORM systems. Most of the techniques he talked about was pretty straight forward and included nothing new.

484 Days of PHP 5.3 and What Have We Done (And Learned)? by Ralph Schindler

This talk was about some of the new features that came with php-5.3, like:

• __invoke magic method
• late static binding
• closures
• namespaces

Of these features I have only used late static binding and closures. While I do get the point of using namespaces I had not found a good use for the __invoke method until this talk! I use Zend Framework for some private projects and some things that have annoyed me with the view scripts is how the view helpers are invoked. Usually you just do something like:

<?= $this->someHelper( ... ) ?>

With the __invoke magic method you can call an object directly as if it were a function, as long as it has implemented the __invoke method of course:

<?= $someHelper( ... ) ?>

Not a big difference but this is only one example of where to use it.

Late static binding is especially nice when it comes to the singleton pattern. Now you can have an abstract singleton class that other singletons can extend, and you don’t have to copy&paste the getInstance() method all over the place. The abstract class can be implemented like this:

abstract class SingletonPattern {
    static protected $instance = array();
    protected function __clone() {}
    protected function __construct() {}
    static public function getInstance() {
        $className = get_called_class();
        if (!isset(static::$instance[$className])) {
            static::$instance[$className] = new static;
        }

        return static::$instance[$className];
    }
}

Other classes can then become singletons by just extending this class:

class SomeClass extends SingletonPattern {}
class SomeOtherClass extends SingletonPattern {}

To create instances of these classes you do:

$object = SomeClass::getInstance();
$otherObject = SomeOtherClass::getInstance();

Best Practices in deploying PHP applications by Shahar Evron

This talk included some interesting ways of deploying code on production servers. From the simplest svn up on a working copy in production, to more complex techniques such as rpm packages and rsync. At work we mostly use working copies on production servers which makes it very easy to update and to roll back to older revisions if the update causes problems. We also use rsync but mostly for static content, and not PHP code. We have a pretty simple setup so no need for complex deployment routines.

Shahar also mentioned deployment scripts that can be created and used if many manual operations is needed to update the codebase on your production servers. The deployment script should also support rollbacks whenever possible.

Unit testing after Zend Framework 1.8 by Michelangelo van Dam

Michelangelo talked about how to organize and test Zend Framework applications. I also learned that PHPUnit-5.3.0 introduced support for using an xml formatted mysqldump file for use with the database extension. I’ll be sure to try that out pretty soon! Other important tips was some pretty obvious (but good) ones:

• Test the most critical parts of the application first
• Make sure to write tests after bugs have been fixed
• Learn about exploits against other sites and make tests for them so that your site is safe

Memcached, the Better Memcache Interface by Ilia Alshanetsky

I did not learn much new stuff in this talk. At work we use the old Memcache extension, but I have already written some components that use the new Memcached extension, so hopefully we will be able to try that out pretty soon. There are some interesting features in this extension, like result and read-through cache callbacks. If you have a pool of servers you also have the opportunity to map certain keys to specific servers as opposed to just storing a key value pair on a random server in your pool.

Other than that the new extension behaves much like the old Memcache extension.

And that was that. The first day of the conference have been very good! Talked to some talented people and listened to even more talented people. Looking forward to more talks tomorrow!