All posts by Adrian Schlegel

JSDay & PHPDay 2012 Verona

From May 16th to May 19th the latest edition of jsDay and phpDay took place in Verona, Italy. Both are two-day conferences, the first one centered around JavaScript, the second around PHP (obviously). They are organised by the community (Grusp) which means they are much more focused on technology than on marketing. A number of Liipers were attending one or both conferences and some where even giving talks.


JsDay directly started with a mindblowing talk by Mark Boas (The slides can be found here). He demonstrated his technique called “hyperaudio” which he uses to enhance audio content on the web with semantic information. Doing so he makes the audio content both crawlable by bots and accessible by visually impaired people. Also this technique gives great possibilities in terms of user interaction: It gets possible to highlight the currently spoken words, to spool exactly to a certain word or to switch the language of an audio file while it is playing.

Another highlight of jsDay clearly was JavaScript messiah Douglas Crockfords Keynote. He spoke about the functionality of our brain and why it makes it so hard for us to step away from subjective criteria when it comes to programming style.

In general the trends in the JavaScript world are all around emerging technologies like in browser data storage, 3D CSS transformations and the yet not mature native audio / video handling. A big topic was node.js which had a handful of talks devoted to it. Another trend in the JS microcosmos is the movement from simple libraries to ingenious JavaScript frameworks, as client heavy applications grow more and more complex.


There have been a lot of interesting talks by people from the PHP community. The spectrum of talks covered a lot of ground, from highly technical aspects like how to build PHP extensions to more social or organisational aspects with talks about agile workflow and team communication. Below you find a list of the most remarkable talks:


As always at conferences, a lot of interesting talks also happened at the infamous ‘hallway track’ and at the social events where we met many interesting people from all Europe and the states. The conference was really well organised by Grusp and the talks were well balanced.

team phpDay

At the social event on the phpDay we made a picture of all attending Liipers. Unfortunately Mirco wasn’t around so Derick Rethans (!!) kindly agreed to play the body double for him :-)

The next jsDay/phpDay will take place again next year from May 16th to 19th. We really recommend to go to at least one of the conferences if not both. If you go you’d do well to reserve some time to visit the beautiful city of Verona.


Unfortunately, during the end of our stay two major incidents occurred in Italy which shocked the whole country. Our thoughts go out to all the people affected by those tragedies.

Behat hackday

A few days ago, we held an open hackday on doing Behaviour Driven Development (BDD)  with Behat at Liip Fribourg. It was the opportunity for the handful of participants to get a first grip on Behat and explore some aspects of BDD through it.


BDD is an interesting practice for agile web developers, it ideally allows the formalization of the acceptance criteria of a story through scenarios written in Gherkin, a domain specific language that is human writable and machine readable. An archetypal Gherkin feature with one scenario (from Behat documentation):

Gherkin Scenarios are composed of steps, and subordinated to features. Scenarios can be tagged, to later specify which subset to test, or to put constraints on their testing. The actual semantic of steps is implemented in Contexts (PHP Classes).


Sylvain and Thomas started integrating Behat in one of their existing Symfony2 project. They appreciated the effectiveness and the ease of use of Behat+Mink to test form interaction, and the BehatBundle for Symfony2 which made integrating Behat into Symfony2 a breeze. They outlined that the first steps to implement are the ones specifying the role of the user: “As an editor …”. At the moment this is not used during the test but it could be interesting to use this feature to authenticate the user before running the test.

Donato mainly tested the Mink SahiDriver against’s project bundle and, outside Symfony, on a simple FuelPHP based application. In both cases the Behat+Mink+Sahi combo proved to be very handy and ran smoothly. The tests with Sahi were run successfully with both Firefox and Chrome.

Adi played with remoting sahi in order to start tests inside a virtual machine but have them executed in the browser on a remote system for testing with different browsers on different OS.

Lukas aimed at testing Ajax requests. He outlined the limits of testing asynchronous process through Behat.

Timo and Benoît focused on the product owner interests in the system. They went through some existing sprint review protocols (made of demo scenarios) and analyzed how much of them could actually be transformed into Behat features and scenarios. They found out that currently Behat, through Mink and the various browser drivers, allows to test only for content presence, and some browsing and navigation interactions. Still a lot more standard steps might need to be provided to test for the presence of document header elements, element attributes, element styling, element metrics, document validation, mouse hovering, scrolling, element visibility …

Conclusions, open questions

BBD and Behat are certainly the easiest way to introduce test-driven development on a project.

One of true value of BDD lies in the ecosystem of scenarios steps provided out-of-the-box: only with a broad spectrum of steps covering most aspects of browsing will Behat be effectively usable for a PO.

BDD empowers the product owner, but he still has to closely collaborate with developers when writing acceptance criteria: the syntax has to be respected, the PO may not know how to test for an element presence, etc.

It is yet undecided how BDD concepts match agile concepts. A user story will be covered by many scenarios, but should a Gherkin feature represent only one user story? or should we rather use tags and match features to epic stories or even code parts (Symfony2 bundles)?

Despite the shortcomings or difficulties in the Javascript and XHR area we’re planning to get started with BDD in an existing project as of mid-December. It will be a slow start and we will grant ourselves some learning time. Depending on how practical the approach will prove in our context, we will not limit ourselves to new user stories, but also describe a number of existing features and get them tested this way.

Packaging solution for (php-)projects

At Liip we have been relying on Debian and RedHat packages to deploy our web applications for some time now. For this we created or in some cases adapted some project/framework-specific solutions:

The existing solutions work very well but they’re also very specific. Since we don’t really want to reinvent the wheel for every new project/framework we decided to start looking for a more generic solution. The prerequisite was that it had to support Debian and Red Hat packages.

With fpm, by Jordan Sissel, we found a solution that can create either Debian or Red Hat packages. Basically, fpm just takes all the files inside a directory and creates a package from that.

Since the layout of the application in a development environment is usually different from the production system (on a dev environment you might have the project files in your home directory whereas in the production environment they should end up in /var/www/projectname) there was still some work involved beside running fpm. But we wanted something that was automated as much as possible: developers should only need to setup packaging once and after that they would only have to execute a simple command to build packages.

For this reason we decided to build a set of wrapper scripts around fpm. With these scripts, you just need to create a configuration file that defines the layout on the target system and some package parameters. Once you created the configuration file, a simple command creates a Makefile for you. After that, building your package is as easy as typing “make” in your project directory. What is really nice with this packaging solution it’s that it’s a) easy to use and b) platform-independent (for Debian packages at least) since you can use fpm on any platform you want.

We made the scripts available on github so other people can benefit from them. To help people get into it and demonstrate some of the possibilities of this solution, we created a demo project that you can try to package and deploy. If you just want to build Debian packages you can just install fpm and you should be good to go (it even works on OS X, so you don’t need a Debian machine to create packages). For rpm packages you unfortunately still need rpmbuild.

Tags: , ,

LEAP2A upgrade for Mahara

LEAP2A is a standard for interoperability of e-portfolio systems. It is an Atom based format that allows export and import of e-portfolios. Recently the 2010-07 version of the specification has been released.

In 2009 version 2009-03 of the LEAP2A specification was implemented in Mahara 1.2. This work was done by Penny Leach and Nigel McNie working for Catalyst IT and it was a joint project between Catalyst, the University of London Computer Center (ULCC), Glasgow University and JISC.

Because of her involvement in both the Mahara and the Moodle community, Penny was the ideal person to add LEAP2A support to Moodle which was done in 2009.

For the latest version of the specification JISC generously offered to fund the necessary work to upgrade Mahara. In an effort to distribute the knowledge about LEAP2A in Mahara, Liip decided to sponsor the introduction of a developer to the Mahara LEAP2A implementation. For this reason I got the chance to work with Penny on the upgrade of LEAP2A in Mahara. The goal was to be ready for the 1.3 release of Mahara.

During the time we were working on the LEAP2A upgrade we were in continuous contact with Simon Grant who works for JISC. He provided invaluable help for tons of detail questions and was a great help during testing. Thanks also go to the Mahara community and especially Andrew Nicols from Lancaster University Network Services who helped with testing as well.

We managed to commit all the necessary changes before the feature freeze and< on friday 10.09.2010 Mahara 1.3 was officially released including the updated LEAP2A version. Penny in the meantime also backported the changes to Mahara 1.2 in anticipation of the 1.2.7 release, so that all Mahara versions with LEAP2A support will be up-to-date with the latest specification. She also updated Moodle to support LEAP2A version 2010-07.

With this another step has been taken towards improving interoperability of e-portfolio systems.

I greatly enjoyed working on Mahara and it was interesting to learn a bit more about the inner workings of LEAP2A. Talking to Simon Grant, I was also pulled in by his enthusiasm and dedication to improve interoperability between e-portfolio systems.