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.

A little more than a half year ago I announced my retirement from PHP core. Since then I have directed my focus elsewhere like Symfony2 and not the CMF project. I do not regret the decision. The main reason to step down was that it was just a too taxing up hill battle to move PHP towards a more open and transparent development process against the inner circle who preferred things to stay as they were back when PHP was by far not as popular or relied upon. This is what I had to say back then:

Since about 4 weeks I have really started using Symfony2, in development for a work project no less. Kinda crazy seeing its still in pre-alpha phase, but I think its a great platform today and I know its going to be the best soon aka once we have a stable release. But in these 4 weeks quite a few things have popped up that I like to see addressed. Most things aren't really about writing code, but figuring out how things should be. The kind of stuff that is hard to fix on your own. At the same time there are not yet that many people to collaborate with, so I think I will have to accept that not all things will get an answer right here, right now. Also a lot of it is pondering best practices, aka documentation. To keep an overview I figured I should make a little list, since right now I just have a ton of flagged emails. Also I might entice some people to follow up on stuff on my list at the same time.