Wurfl Symfony2 Hackday

Every 10th of the month, Liip employees have the opportunity to take part in hackdays. On Thursday a few people from Bar team (Penny, Alain, Laurent and Lea) had a hackday to try and create a Symfony2 bundle to wrap the Wurfl crowd sourced open data project for Mobile Device recognition. Wurfl itself is a set of device definitions in XML, with various libraries around it providing an API to the data.

Unfortunately it wasn't a success, and by the end of the day we had to admit defeat.  However, we learned a lot and had fun doing it!

Our main goal of the hackday was to get it to a point we could use it in the project we're working on at the moment.  To do this, we identifed the following tasks:

• Create the bundle
• Write a Symfony2 database storage backend for the library
• Make the library somehow respect the bundle configuration
• Create a helper that would just return a boolean for mobile or not
• Write a command that could be used to update the device definitions
• (If we had time) create a route to wrap around the library webservice.

The first problem we encountered was that there were two php libraries and we didn't really know which one to use.  The first, wurfl nphp, is written by Luca Passani, who is the founder of the project. The second, Tera-wurfl seems to be the de-facto PHP library, and is even linked to from the main wurfl site as the php/mysql library. Confusing!

We had a look at both of them and in the end we chose Tera-wurfl.  That was mostly because it was on github and nphp seemed to still use cvs, which made it harder to integrate.

The first thing we did was split into pairs.  Penny and Laurent started trying to tackle the database side while Lea and Alain tried to find a way to write a configuration class and get the library to use it.

Here's a summary from each person:

From Laurent

Why we failed

• tera-wurfl is not a modular lib, but a monolith that works just like it was meant to be working
• not enough time spent on comparing wurfl/teraWurfl
• a more iterative process could have shown the 2nd point earlier and at least not fail the whole stuff

What we learnt

• go iterative the more possible. even on a 1 day project
• spend more time doing research before coding
• hackday can be super frustrating, but it's great to have the possibility to experiment on things like this (out of any budget/customer pressure)

From Alain

Why we failed

• Wrong expectations: we thought we could just wrap the TeraWurfl API, but there were different issues:
• Loading: the classes are not namespaced, and neither prefixed
• There are underscores in the classnames (not symfony2-compliant)
• The update command is meant to be used over a webserver and to get parameters as GET-params (which we can't provide, since we want to use it over the commandline)

What we learnt

• We can't (easily) use the TeraWurfl API in Symfony2
• Never assume how a API looks (on the other hand: checking that was part of our hackday)

Possibilities for future:

• Try Wurfl (instead of TeraWurfl)
• Just use the XML file from Wurfl and write the API ourselves

From Lea

Why we failed

• Our decision to work with an existing library and the choice of the library we ended up working with was not done carefully enough. Maybe we even chose based on the wrong criteria. We should have started with having a careful look at what exists and if and how well that can be used in a Symfony 2 bundle.
• Although, we wouldn't have discovered some problems at that time because no one was very experienced in writing symfony 2 bundles (with external libraries). E.g. I wouldn't have thought that it might be such a pain to have Symfony properly loading classes of external libraries. Because of underscores in classnames and because the symfony class loader expects to have a PEAR-like project structure for non-namespaced projects and hence replaces underscores with directory separators, it just didn't find the classes to be loaded. We could have created a service for every needed class, but that would have been quite ugly.

What we learned

• Symfony makes quite some assumptions about how projects look like, e.g. that they are either namespaced or have a PEAR-like project structure. For other “types” of projects you can load the classes by creating services for everything you need, but depending on how many classes you need, that's becoming quite ugly/painful.
• some libraries are good to use as they are, but they're not meant to be integrated into something else
• even if someone already implemented the thing you need, you should carefully evaluate if it really fits your needs. if not, it might be easier to implement it yourself.
• Hackdays are awesome, even if you don't reach the goals you've defined

From Penny

Why we failed

• We should have spent much more time evaluating the libraries to find out which would be easier to wrap around
• It really seemed like we probably picked the wrong library, it was very difficult to integrate

What we learned

• A lot more about the restraints inside Symfony2 about the way things must be
• Hackdays are fun!

In the end, we did publish how far we got on github, so if someone wants to pick it up and continue with it, they're welcome to it, but we didn't get it into a state we could really use for our project in a day.