When starting working with Zend Framework 2, it’s common to copy the skeleton and put your controller definitions in module.config.php like this:
'controllers' => array(
'invokables' => array(
'Application\Controller\Index' => 'Application\Controller\IndexController',
'Application\Controller\Blog' => 'Application\Controller\BlogController',
The controllers keyword is picked up by the ControllerManager which is an instance of the ServiceManager which means that it creates the controller instance for you when the dispatcher needs it.
When moving a project into Vagrant, I realised that I needed the vagrant guest to share my OS X’s VPN.
I’m using a separate IP address within a private network like this:
config.vm.network :private_network, ip: "192.168.101.101"
So, after some Googling, I added this provider configuration setting:
config.vm.provider :virtualbox do |vb|
vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
and now my VM is sending data over the VPN. Note that this will not work when using the Vagrant’s public_network setting though.
I’ve been playing with Vagrant over the last few days, using Ansible to provision it. These are some notes to remind myself for next time and are very disjointed!
Configuring Vagrant to provision using Ansible is easy enough:
config.vm.provision "ansible" do |ansible|
ansible.playbook = "provisioning/playbook.yml"
I had a problem writing to the cache directory in my vagrant project due to file permissions. Fortunately Jeremy Kendall has already solved this problem in his Vagrant Synced Folders Permissions article.
I’ve been thinking recently about using immutable objects for some of my model-layer entities. That is, an object that cannot be changed once it is created.
Immutable objects have a number of benefits including the fact that they are much easier to understand, simple to use and very easy to test. The main motivation for me is that an immutable object is very predictable as it’s state doesn’t change. This means that any calculated properties can be done once on creation. This is interesting as one application that I’m currently working on has a lot of calculated properties and it’s a source of bugs when one property changes and all the dependent calculations aren’t always done.
I was having a discussion on IRC about use statements and whether they improved code readability or not.
Consider this hypothetical code:
$cache = new \User\Service\Cache();
$mapper = new \User\Mapper\User($cache)
$form = new \User\Form\Registration($mapper);
// other code
$cache = new Cache();
$db = new User($cache)
$form = new Registration($mapper);
The first snippet is completely unambiguous at the expense of verbosity. Those longer class names make it a little hard to quickly parse what it going on. The second is clearly less cluttered, but is at the expense of ambiguity. Exactly what class is User? I would have to go to the top of the file to find out. Should I use aliases? If so, how should I name them?
On the 26th January, I fell off a skateboard, dislocating & fracturing my left elbow. A trip to A&E that Sunday resulted in hospital admittance on Monday and surgery on Tuesday.
This was the first time I’ve been admitted to hospital for an overnight stay and I found the whole process fascinating, but not something I ever want to repeat. I also can’t say enough good things about the staff at Worcester Royal Hospital. Everyone I interacted with was friendly, helpful and competent.
I recently had a requirement to create a zip file from a number of files created within my application.
As it has been years since I last had this problem, I had a look around and discovered that PHP 5.2 has the ZipArchive class that makes this easy. Continue reading
One feature that piqued my interested in the Apigility skeleton application was development mode. From the README:
Once you have the basic installation, you need to put it in development mode:
php public/index.php development enable # put the skeleton in development mode
As 2013 finishes, I continue my tradition of showing off some photos that recap my year. Last year I discovered that I didn’t take many photos at all, so this year I’ve published at least one photo every day! A lot of them were rubbish, but a good number are shots that I’m very pleased with. Continue reading