Symfony2 is full of ESI love. ESI aka Edge Side Includes are a standard for reverse proxy caching which can significantly boost performance. What is even nicer is that ESI really goes well with RESTful API's, which is one reason why I am pushing REST in the Symfony2 world. I must admit that until recently I was totally ok taking short cuts, but I am now being to realize that the short cuts I was taking actually hurt in many ways. So I am warping my mind to be more RESTful. But at the same time I also see great potential in ESI which needs some additional mind bending .. or actually maybe not.

Well I should say, as an experienced developer I am pretty much all around happy with Symfony2. There are some things I do not like, some that are a bit tedious, but nothing that is horrible and, this is key, I can fix pretty much anything I do not like. Moreover with supervision any half way decent developer can be productive quickly. I would say 1-2 days pair programming to be able to stand on their own for 93% of the tasks during development. So from the POV of Liip I am happy we made the choice to go with Symfony2. Its awesome.

Back when I was developing MDB2, I loved my unit tests to help me ensure that changes actually worked across different RDBMS (versions). It was also a great way to identify issues by having users run the test suite. Actually I guess I wasn't really "unit testing" since I was actually always running against a real database. Fast forward until today. In my current project we are aiming for 100% code coverage. Well we are not afraid of using @codeCoverageIgnore for super trivial stuff and yes I know that there is more to good tests than just coverage. At the beginning we actually unit tested everything. So this meant writing lots of mock object boiler plate code for Controllers for example. Pretty soon it became clear to me that we weren't unit testing API's, due to all this mocking we were actually testing the implementation.

Back when we first launched ResolutionFinder.org we of course already had many ideas for improvements. This is now the first big push to add these to the site. Of course since then we have even more ideas, but this is still a big jump forward. The main thing we added was the ability to not only search for clauses (aka sections within UN documents), but also documents themselves. Here I was hoping to be able to use the patches for FieldCollapsing for solr, but it turns out they are not yet ready for facetting. So in the end I just added another index just for document searches.

A while ago I posted about some issues I ran into trying to use 3rd party controllers as well as in my own controllers when supporting multiple output formats. I was dreaming of a world where the controllers could for the most part be totally oblivious to how they would be rendered. I have been talking to Jordi for a while now about adopting an "Agavi-Light" approach by adding a simple view layer that would enable users to easily support different formats without having to mess with their controllers yet still being able to handle stuff like redirects, encoding to JSON, XML or generating PDF's or images. After an intensive work session which lasted about 5 hours (thank you Liip for hackday budget to do this sort of stuff on company time) plus a much deserved lunch break we had pushed the results on to github.