About: ME!

Welcome to, my name is Gabriel and I will be your host for this journey into insanity.

I’m currently system’s developer for Fusions, producing PHP code, maintaining systems and develop automation techniques (think puppet, vagrant, jenkins and packer) to streamline development and deployment.

I am formally a dev-op for Go MAD Thinking, dev-op being a combination of tech op and developer, I developed software as well maintained infrastructure.

I maintain an open source deployment platform with an api built on Ruby on Rails and a front end in JS and HTML.

I also contribute to various open source projects in my spare time, mainly focused on PHP. I had written my own markdown website handler but now I use jekyll and github pages.

My work projects have consisted of Fusions, D & A, Support Rebel, iCheev, Think Leicestershire, Go MAD Kids and currently lead developer on the corporate administration site for iCheev.

You can find me on twitter, github, LinkedIn, stackoverflow. If you see the username gabriel403 somewhere, it’s probably me.

My main languages are PHP/RoR/ with oodles of JQuery, Bootstrap and Dojo JS as well.

I’m a graduate of De Montfort University, gaining a 1st class degree with honours in software engineering.

It seems fairly standard that at this point I should show you what I look like, so here is my foot:

my foot

Blog Posts:

A Howto on Converting SVN repos to Git

link 22 Sep 2013

ZF2 Forms, Annotations and Composed Objects

link 14 Apr 2013

ZF2 Custom Form Element

link 29 Mar 2013

Inversion of Control: Service Locator & Dependency Injection

link 14 Oct 2012

Factories an Invokables in ZF2

link 11 Oct 2012

Zend Skeleton Application And G403Translator: Db Driven Translation

link 27 Aug 2012

Zend Skeleton Application and the ZFC User Module

link 15 Jul 2012

Blog Introduction

link 07 Jul 2012

Readme Changes File

link 23 Jun 2012

A Howto on Converting SVN repos to Git

22 Sep 2013

One of our major projects at GoMAD Tech is currently stored in SVN but is soon moving to git.

It really consists of multiple smaller projects, however they’re all stored in a single SVN repository. With SVN’s subdirectory access this was never a problem, but when parsed into Git these need to be seperate repositories.

We also need to remove unnecessary branches, we have a standard layout of trunk, branches/development and branches/hotfix branches with trunk becoming the master branch. As well as a whole bunch of tags in the tags directory, these need to become normal git tags.

One of the things we need to remember is to adjust the author names and emails for commit messages. So we need to pull the commit authors out of svn and tweak them.

svn log --xml | grep -P "^<author" | sort -u | perl -pe 's/<author>(.*?)<\\\/author>/$1 = /' > users.txt we can then edit this file to make the entries look like this  

gabriel.baker = Gabriel Baker <>
shabbir.hassanally = Shabbir Hassanally <>

After fixing the authors we can start reading out the svn commits and parsing them into git ones, lucky git has this built in (remember to install git and git svn)

git-svn clone --authors-file=users.txt --no-metadata -s ProjectInGit

So now we have a local repo with history still intact, but we’re missing proper gittags and branches.

gabriel@svn:~/ProjectInGit$ git status
# On branch master
nothing to commit (working directory clean)
gabriel@svn:~/ProjectInGit$ git branch
* master
gabriel@svn:~/ProjectInGit$ git tag
gabriel@svn:~/ProjectInGit$ So we need to parse those out and create first our tags:

git for-each-ref refs/remotes/tags | cut -d / -f 4- | grep -v @ | while read tagname; do git tag "$tagname" "tags/$tagname"; git branch -r -d "tags/$tagname"; done

And we have:

Deleted remote branch tags/2.0.0 (was 7dea8c7).
Deleted remote branch tags/2.1.0 (was 5b7a0cc).
Deleted remote branch tags/2.1.1 (was a1f7702).
gabriel@svn:~/ProjectInGit$ git branch
* master
gabriel@svn:~/ProjectInGit$ git tag

And then we create our branches:

git for-each-ref refs/remotes | cut -d / -f 3- | grep -v @ | while read branchname; do git branch "$branchname" "refs/remotes/$branchname"; git branch -r -d "$branchname"; done

Deleted remote branch development (was 28cd707).
Deleted remote branch hotfixes (was 81b7b4b).
Deleted remote branch trunk (was fe2b690).
gabriel@svn:~/ProjectInGit$ git branch
* master

No point keeping the trunk branch now we have master

gabriel@svn:~/ProjectInGit$ git branch -D trunk
Deleted branch trunk (was fe2b690).
gabriel@svn:~/ProjectInGit$ git branch
* master

Then we can add our new remote and push our branches and tags to it

git remote add origin
git push origin --all
git push origin --tags

And now we have you repo, converted from SVN to Git and hosted on Github. Enjoy!

ZF2 Forms, Annotations and Composed Objects

14 Apr 2013

How to combine multiple annotated entity derived forms into a single form.

So you’re using the data mapper pattern, just for awesomeness. You’re also using annotated entities being parsed into forms, since in most cases your entities are in a one to one relationship with your forms.

However you do occasionally need forms that are made up of multiple entities.

you could create a new entity with all the bits in and then parse them into seperate entities for persisting.

However it’s easier to create a new entity using multiple @Annotation/ComposedObject annotations, this gives us unified validation and can get the seperate entities easily from the outer entity.

Here we have the factory for creating the form. Form Factory:

 1 <?php
 3     'WelcomeMessageForm' => function ($sm) {
 5         $msg = new Model\WelcomeMessage;
 7         $fc =  new Model\LicenceContent;
 8         $msg->setFutureMessage($fc);
10         $cc =  new Model\LicenceContent;
11         $msg->setCurrentMessage($cc);
13         $builder = new \Zend\Form\Annotation\AnnotationBuilder;
14         $form = $builder->createForm($msg);
15         $form->bind($msg);
17         $form->get('current_message')->setObject(new Model\LicenceContent);
18         $form->get('future_message')->setObject(new Model\LicenceContent);
19         return $form;
20     },

When using ComposedObject, the composed objects are parsed into fieldsets within the form. By doing the setObject calls on the fieldsets in the factory, this allows the form to iterate through the composed objects in a ‘populated’ main entity to populate values in the form.

WelcomeMessage Entity:

 1 <?php
 3     namespace Module\Model;
 4     use Zend\Form\Annotation;
 5     /**
 6      * @Annotation\Hydrator("Zend\Stdlib\Hydrator\ClassMethods")
 7      */
 8     class WelcomeMessage
 9     {
11         /**
12          * @Annotation\Hydrator("Zend\Stdlib\Hydrator\ClassMethods")
13          * @Annotation\ComposedObject("Module\Model\LicenceContent")
14          */
15         protected $current_message;
17         /**
18          * @Annotation\Hydrator("Zend\Stdlib\Hydrator\ClassMethods")
19          * @Annotation\ComposedObject("Module\Model\LicenceContent")
20          */
21         protected $future_message;
23         public function getCurrentMessage()
24         {
25             return $this->current_message;
26         }
28         public function setCurrentMessage($currentMessage)
29         {
30             $this->current_message = $currentMessage;
31             return $this;
32         }
34         public function getFutureMessage()
35         {
36             return $this->future_message;
37         }
39         public function setFutureMessage($futureMessage)
40         {
41             $this->future_message = $futureMessage;
42             return $this;
43         }
45     }

Here we have a simple ‘super’ entity composed of 2 other objects (in this example, both the same type).

Controller Action:

 1 <?php
 3     public function welcomeAction()
 4     {
 5         //get id from session
 6         $licence_id = $this->zfcUserAuthentication()->getIdentity()->getId();
 7         $viewModel = new ViewModel();
 8         $form      = $this->getCustomiseService()->getWelcomeMessageForm();
 9         if ($this->getRequest()->isPost()) {
10             $data = $this->params()->fromPost();
11             $form->setData($data);
12             if ($form->isValid()) {
13                 /* @var $entity \Module\Model\WelcomeMessage */
14                 $entity = $form->getData();
16                 /* @var $curMsg \Module\Model\LicenceContent */
17                 $curMsg = $entity->getCurrentMessage();
19                 /* @var $ftrMsg \Module\Model\LicenceContent */
20                 $ftrMsg = $entity->getFutureMessage();
22                 $this->getCustomiseService()->updateWelcomeMessage($licence_id, $curMsg, $ftrMsg);
24             }
25         }
26         $form->setHydrator(new \Zend\Stdlib\Hydrator\ClassMethods);
27         $entity = $this->getCustomiseService()->getWelcomeMessage($licence_id);
28         $form->bind($entity);
29         $viewModel->setVariable('form', $form);
30         return $viewModel;
31     }

Here we have a simple action for validating and saving a form, and for also fetching a ‘populated’ entity from the db.

And that’s it, we have a main object made out of 2 composed objects, the 2 composed objects are parsed into fieldsets in the main form. You can retrieve and set/populate the values of the composed objects easily.

ZF2 Custom Form Element

29 Mar 2013

Quick walk through on creating a simple custom form element that just echos out the value.

I recently needed a way to output plain text as part of a form, that would take a value just like a normal form element would. It’s very similar to something I needed to do in ZF1 and it always weirds me that ZF doesn’t include something like this by default.

We need 4 files to add our new element:

  • The form element
  • The view helper for the element
  • An override of the generic FormElement view helper
  • A Module.php to add our element to the view helper config

I’ve been putting things that tend to be site wide in the application module, or seperate them into another module to be added at the vendor level.

This is our form element, we don’t do anything fancy, it’s just declaring the type.

 1 <?php
 2     namespace Application\Form\Element;
 4     use Zend\Form\Element;
 6     class PlainText extends Element
 7     {
 8         protected $attributes = array(
 9             'type' => 'plaintext',
10         );
11     }

This is our view helper, very basic, just returns the value rather than parsing it into some fancy html

 1 <?php
 3     namespace Application\Form\View\Helper;
 5     use Zend\Form\View\Helper\AbstractHelper;
 6     use Zend\Form\ElementInterface;
 8     class FormPlainText extends AbstractHelper {
10         public function render(ElementInterface $element) {
11         	return $element->getValue();
12         }
14     	public function __invoke(ElementInterface $element = null) {
15     		return $this->render($element);
16     	}
18     }

Here we override the generic FormElement helper so that generic rendering methods, such as $this->formRow will work with our new element.

 1 <?php
 2     namespace Application\Form\View\Helper;
 4     use Application\Form\Element;
 5     use Zend\Form\View\Helper\FormElement as BaseFormElement;
 6     use Zend\Form\ElementInterface;
 8     class FormElement extends BaseFormElement
 9     {
10     	public function render(ElementInterface $element)
11     	{
12     		$renderer = $this->getView();
13     		if (!method_exists($renderer, 'plugin')) {
14     			// Bail early if renderer is not pluggable
15     			return '';
16     		}
18     		if ($element instanceof Element\PlainText) {
19     			$helper = $renderer->plugin('form_plain_text');
20     			return $helper($element);
21     		}
23     		return parent::render($element);
24     	}
25     }

And finally we add our bits to the module configuration

 1 <?php
 2     namespace Application;
 4     use Zend\Mvc\ModuleRouteListener;
 5     use Zend\Mvc\MvcEvent;
 7     class Module
 8     {
10         public function getViewHelperConfig()
11         {
12             return array(
13                 'invokables' => array(
14                     'formelement'       => 'Application\Form\View\Helper\FormElement',
15                     'formPlainText'     => 'Application\Form\View\Helper\FormPlainText',
16                 ),
17             );
18         }

Now when we declare our forms we can add a plaintext form element

 1 <?php
 2     $form->add(array(
 3         'type' => 'Application\Form\Element\PlainText',
 4         'name' => 'start_date',
 5         'attributes' => array(
 6             'id' => 'TrialStart',
 7         ),
 8         'options' => array(
 9             'label' => 'Trial Start Date',
10         ),
11     ));

And jobs done, you could add a second element which also renders a hidden field along with the plain text if you need the value being submitted too.

Inversion of Control: Service Locator & Dependency Injection

14 Oct 2012

Quick notes for dependency injection vs retrieving from service locator, this is mainly for zf2 but the basics apply elsewhere.

Inversion of Control

IoC is a way of getting modules or objects into the right class when they’re needed, the instantiation of an object is abstracted away from the class requiring it, in a way that makes duck typing a practical reality.

Dependency Injection

DI is, in it’s most basic form, the process of inserting dependencies(obj b and c) into the object requiring them(obj a) without that object(obj a) needing to know how it happened.

 1 <?php
 2 	$a = new A(new B);	//constructor injection
 3 	$a->setC(new C);	//setter injection
 5 	class A
 6 	{
 7 		public __contructor(B $b) {
 8 			$this->b = $b;
 9 		}
11 		public setC(C $c) {
12 			$this->c = $c;
13 		}
14 	}

In ZF2, the dependency injection is implemented as a depenedency injection container, Zend/Di, it relies on reflection to ascertain what objects are required for the construction of a particular object. Configuration is set up so that when Zend/Di is required to construct a certain object, it knows that it either needs to pass instances of certain other objects to the constructor or to call a ‘set’ function for that dependency. e.g. obj a requires obj b and obj c, the __construct function signature calls for an object of type b and there is a setC function whos signature calls for an object of type C. Objects B and C may require further dependencies that can be configured to be injected as well.

This can be considered as an implicit way of injecting dependencies.

Service Locator

SL is in essence a way for the object(obj a) to get it’s own dependencies without having to rely on an external source to set them for it. Rather than instantiating them itself an SL is injected into the object(obj a) and that is used to fetch the dependencies.

Classic Service Loctor

 1 <?php
 2 	class A
 3 	{
 4 		public __construct(ServiceLocator $sl) {
 5 			$this->sl = $sl;
 6 		}
 8 		public getC() {
 9 			if ( !is_set($this->c) ) {
10 				$this->c = $this->sl->get('c');
11 			}
12 			return $this->c;
13 		}
14 		public getB() {
15 			if ( !is_set($this->b) ) {
16 				$this->b = $this->sl->get('b');
17 			}
18 			return $this->b;
19 		}
20 	}

In ZF2, we use the Zend/ServiceManager(SM) as an implementation of the service locator pattern, in the SM we set a key to be an instance of an object, if the object being constructed itself has no dependencies that’s the end, however if it does have dependencies then we use a factory or an invokable to pass the sm to an inteligent object that then gets further dependencies from the SM. e.g. obj a relies on obj b and obj c, we pass a factory to the SM as the way of instantiating a, in this factory the sl is passed into it and the factory uses the sl to retrieve instances of obj b and obj c which are used to construct obj a and the new instance of obj a is returned.

SM Invokable

 1 <?php
 2 	class A
 3 	{
 4 		public function __invoke(ServiceManager $sm) {
 5 			$b = $sm->get('b');
 6 			$c = $sm->get('c');
 7 			$a = new A($b);
 8 			$a->setC($c);
 9 			return $a;
10 		}
11 	}

This can be considered an explicit way of injecting dependencies.

DI vs SL

Di is a bit easier to set up, as it just requires a lot of writing configs, it’s also less magical as all the deps for a class are in front of your face in the config files, however Zend\Di is a lot more magical than the classical version of it, as it does require a lot of reflection (which may be cacheable) to work out how to get the dep into the class, this can be costly on resources in large classes.

On the other hand Zend/ServiceManager uses individual closures or factories to retrieve the deps for instantiating the service requested, and these deps could need further factories for further deps etc requiring a further coder to piece through more and more classes(factories or closures) to understand all the deps being used but you get the service when you need, if in some circumstances you don’t need the dep you don’t ask for it and you save some resources, with DI you will always have all deps in place, whether you use them or not.

Also as DI is configured as deps for a class, if multiple places require the same dep you’d have to configure each, whereas with SL you’d just ask for it and it’d already be available without extra configuration.

Factories an Invokables in ZF2

11 Oct 2012

These are just some quick notes really, just for some future reference, mostly concerned with the differences as they pertain to invokables and factories in Zend/ServiceManager.


An invokable is simply a class that can be instantiated, it doesn’t normally require any deps and can just be instantiated when needed, like controllers normally have no dependencies that are required during construction nor any deps required after construction and before the object can start work, even if they’re set via setters.


If your dependency is dependent on other objects that need fetching before the object will work properly, even if these are set via setters rather than during construction and inteligent object, in this case a factory, is the way to go. A factory can be a closure straight in the config (but this stops caching), in the module.php or as concrete classes. These classes are either invokable via __invoke or implement the FactoryInterface.


 1 <?php
 2     'service_manager' => array(
 3         'factories' => array(
 4             'something' => function ($sm) {
 5             	$se = $sm->get('somethingelse');
 6             	$s = new Something($se);
 7             	return $s;
 8             },
 9         ),
10     ),

Factory object

 1 <?php
 2     'service_manager' => array(
 3         'factories' => array(
 4             'something' => 'SomethingFactory',
 5         ),
 6     ),
 8     class SomethingFactory implements FactoryInterface
 9     {
10         public function createService(ServiceLocatorInterface $sm)
11         {
12            	$se = $sm->get('somethingelse');
13            	$s = new Something($se);
14            	return $s;
15         }
16     }

Invokable factory

 1 <?php
 2     'service_manager' => array(
 3         'invokables' => array(
 4             'something' => 'SomethingFactoryInvokable',
 5         ),
 6     ),
 9     class Something
10     {
11         public function \__invoke(ServiceLocatorInterface $sm)
12         {
13            	$se = $sm->get('somethingelse');
14            	$s = new Something($se);
15            	return $s;
16         }
17     }

The concrete class way is best when you’re doing some fairly substantial work. You can either implement the FactoryInterface and then the createService method (which takes a servicelocatorinterface object) or just make the class invokable by implementing __invoke (which also takes the sm in). You can then retrieve other objects from the servicemanager (invokables or factories) and then return an instance of some object, of a singluar type per factory, as a result.

And that’s it!

Zend Skeleton Application And G403Translator: Db Driven Translation

27 Aug 2012

I recently had need to do some translations with ZF2, the current state of ZF2 means that you can only load translations from files so I decided to take this oppertunity to experiment with creating my own module for doing it.

DASPRiD had already had a bash at creating something for this but unfortunately it didn’t work, I was able to take the code and work with it to produce this module.

There’s a generic Zend Skeleton Module which I cloned locally and created my own GitHub repo for storing the final product. It’s also published in Packagist so it’s dead easy to install.

So first we fork or clone the ZendSkeleton Application and then checkout a new branch to work on
we edited the composer.json to get the latest version of ZF2 and also to fetch our G403Translation module
composer.json file

Then we get composer to install our modules for us composer install command

After that we set up our db and user and imported our SQL that’s in the for the module sql Here we’re using custom table names, the default assumed within the module are zend_locale and zend_translate_message.

Then we set up the db connection within the code itself db connection config file
this file is within config/autoload/ and also another file for setting up the translator, as with all configs this can be done in a module config or in the config/autoload/ directory in this example inside the autload config translator config file

We then insert some data into the tables

locale table messages table

And we can see the change in our Zend Skeleton Application from Original ZSA to New ZSA

Tah dah!

To learn a bit about plurals read here.

Zend Skeleton Application and the ZFC User Module

15 Jul 2012

So I’ve been playing a lot with zf2 recently and inspired by EvanDotPro’s post on getting things working using pure git, I thought I’d throw one up using composer+git.

So after forking the Zend Skeleton Application I got one with working with it locally, I cloned the remote repo and checked out a new branch for playing with zsa cloning

I then edited the composer.json file to fetch ZfcUser which in turn fetches ZfcBase like this zsa composer.json editing

I then proceeded to get composer to install Zend Framework as well as the other dependencies list (zfuser etc) composer install

And it all worked lovely, using just php’s inbuilt webserver. phps webserver zsa initial load

I then added the new modules to application configuration application config for new mods. You may be thinking there’s some trickery going on the get zf-commons/zfc-user loading as ZfcUser, and you’d be right zfc trickery

And then I set up the sqlite db using the schema that comes with ZfcUer sqlite schema setup and added the file for local database configuration db config

The next time I ran the webserver I was able to navigate to /user and get to a lovely login page.

zfcuser login page

It was all just that easy to get going!

Have a look on github

Blog Introduction

07 Jul 2012

I thought it was appropriate that the first blog post on my new blog (apart from the changelog) was about how I developed my blog!

I’ve been meaning to write my own blog for a while now, I’ve never been fully happy with Wordpress. I was going to try and produce one with Zend Framework 2, node.js, Python, CouchDB, whatever fancy is currently on my mind. Whilst moving my blog between various VPSes, looking for the cheapest and best, I managed to lose my database backups.

So I was without a blog for a few months whilst I was deciding what to do, then I came upon a blog post by Matthew Weier O’Phinney describing how he created a markdown to html converter using Zend Framework 2 and his own custom ZF2 blog module. I liked his approach of just rendering html and also leaving commenting up to a dedicated system.

However I didn’t feel the need for using a full framework, so I started developing my own simple no framework blog.

I made the choice to use markdown to create the blog posts as they are somewhat easier to read than html, I used the markdown extra library. The GenerateAll file instantiates the renderer which loops through the markdown files checking for a corresponding properties file to pull some more information for the blog post. If it doesn’t exist a default properties file is generated and saved. The markdown and properties file are kept seperate as I find it easier to free type the post without interference. The markdown and properties files are parsed into html using heredocs stored in a template strings file.

The properties file has properties for categories and tags which will later be parsed for category links and a tag cloud.

By running the renderer on the local machine and using git for the deployment it reduces resources on the live server by only having static html being rendered. Using git remotes also makes deployment a breeze, I can commit/render/test locally, then deploy to the remote webserver(s) and finally to github for storage.

Readme Changes File

23 Jun 2012

A simple PHP driven blog using mark down parsed into html and rendered statically.

Content is written in markdown files in the Post folder, if extended properties are needed these can be placed in a php file of the same name which extends the Post abstract, if this is not provided it will be generated and initially set post created time as time() and the blog entry title as the filename. Running the GenerateAll.php file will parse the markdown files and render them into static html files inside the content directory.

It will also create the central index.html with all blog entries listed shown in brief as well as a list of links on lhs to individual blog entries.

Requirements: PHP5.4 on the rendering system. Simple HTML server for hosting the site.



  • Added beta blog


  • twitter feed on front page
  • Font’s hosted locally


  • Reworked directories to seperate out the posts from the rendered html from the rendering library to potentially move the rendering library into it’s own repo
  • Added gitignore for caps dir and handler.php
  • Added isPublished with default to false in the post abstract
  • Reworked markdown and markdown extra classes into PSR-0 compliance
  • Made paths in config relative to base path and used getcwd for them
  • Converted markdown php4 style constructors to php5
  • Fluent interface for renderer


  • Changed krsort to ksort


  • Reworked disqus into single articles only
  • Tweaks to css


  • Responsive CSS
  • Initial attempt at disqus


  • Added disqus commenting system
  • Moved disqus’ js loading to an onclick
  • Added some codesniffer stuff


  • Reworked backend to be more object oriented
  • Reworked backend classnames to use namespaces
  • Removed template files and converted to static strings & heredocs using properties
  • Added some basic phpdoc
  • Added some basic configuration
  • Renamed the content dir to Content
  • Centralised generation into a single script and moved generation files into a single Renderer file
  • Posts now sort by date of creation in descending order
  • Post titles are now read to create links, and also header inside the post
  • refs inside individual entries now return to main page to go to anchors

  • Replaced hardcoded directory refs to config refs


  • Reluctantly added abstract properties file associated with the markdown files.
  • Added properties file generator
  • Implemented psr-0 autoloader
  • Renamed markdown directory to Post directory
  • Added more UI work, logo, css, reworked links
  • Reworked generator


  • Reworked include system for main page.
  • Added links to blog post on side bar.
  • Improved some ui.


  • Initial work done on markdown parsing into html.


Contact Details

Gabriel Baker +44 7894 387832

Personal Statment

I am an open source software architect, specializing in PHP.

I am currently project lead for various projects at GoMAD Technology, the technology arm of GoMAD Thinking, including the administrative website for iCheev.

I’m a passionate open source advocate producing various modules to ease the use of Zend Framework 2, as well as my own website/blog, making use of various open source tools, such as Michelf’s PHP Markdown Extra and GitHub for hosting. I blog on various PHP/JS related topics and present talks on various subjects.

Work Experience

Placement Year

During my placement year at university I started as a junior web developer working for Go MAD Thinking, working on iCheev, I quickly became the server administrator handling SVN, access control, testing and live servers as well as deployment.

I also introduced the trac bug tracking system which we’ve used to track the development process of new features as well tracking bugs from discovery to fixed.

Post Graduate

After graduating I went back to working for the same company as web developer/server administrator. I started working with more languages such as C#.NET and ruby.

Jenkins CI

I also worked to integrate our provisional suite of unit tests into a more continuous solution by the introduction of Jenkins CI to routinely run our increasing suite of unit tests. I then progressed to using Jenkins CI to automate our deployment through the testing stages and finally to the live deploy.


As a frequent contributor to open source projects, most of them through github I introduced the company to git and championed the use of git as our vcs, finalising with a presentation on git, github and gitflow to the majority of the company upon which the decision was taken to move forward with git. We are now in transition from subversion to git on github.


After discovering the wonders of puppet and vagrant (and how github use puppet to set up their local dev machines (I stole the name)) and how well they could be combined I started work on a project to enable our devs to spin up vagrant instances to use as dev servers. I also produced configurable puppet scripts that would reproduce our various development projects, with all server dependencies, with minimal fuss. This allowed rapid deployment of our projects to new nodes as needed. This also freed the devs and allowed them to use any combination of operating system and hardware they wished whilst still running their development on the vagrant boxes which would replicate a common environment. Extra vagrant boxes were generated to enable developers to replicate different environments from our ‘edge’ development server all the way to production, all on VMs on their local machine. This also lead to new technologies being implemented as puppet scripts allowing easy deployment amongst developers and then on servers, as the puppet scripts don’t need to run on a virtual. This also enabled writing puppet scripts to set up brand new or newly reinstalled machines with all the programs a dev needs.


I work in my spare to help on the PHPCI project. This is a PHP based continuous integration server, with plugins for various PHP tools, such as PHPUnit, Mess Detector, Code Sniffer, PHP-CS-Fixer and lots more. It works with local and remote respositories, including building on demand and when pushes to github/gitlab happen.


Most of my open source code can be viewed in my github account, these include full modules for ZF2 DB Sessions PHP Based CI Server, doing bug fixes and code for ZF2 itself, as well as working on my projects to try out the various other programming languages out there, including a kanban board written in Node.js Kaizen Kanban, using redis as a backend.