ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
PHP adopting branching kicking and screaming
I remember that back when I was co-RM for PHP 5.3 one of the very painful parts was the crying and moaning about the commit freezes we put into place while packaging up a new release. The reason being we were on CVS, if people kept committing while a release was being tested it would effectively prevent any sort of QA. Obviously we could have just tagged at the start of the QA process, but pretty much every time build fixes were necessary, if you then also throw in normal commits it wouldn't work at all. So we usually reserved about 2 days where no commits were allowed. Since there is no truly reliable way to inform people there would frequently be one or two commits still, but it was somewhat manageable. However it obviously made it quite annoying for people to work in this time interval. Either commits had to be delayed or someone had to remember to merge the change from HEAD once the commit freeze was over.
Short HipHop blurp
Well we all have read the announcement and chatted, twittered or whatever about it. I agree thats its cool this is being open sourced. I do fear however this means that there is no one less company looking after APC (mainly leaving just Yahoo then?). For now I think this is mainly interesting for "researchers" willing to work on improving the compatibility and more importantly the workflow around HipHop. I do not expect that anyone can really get a meaningful return on investment who makes this their business anytime soon (unless they can sell people on the hype), besides FB of course.
Wanna help out on wiki.php.net?
Recently I have devoting my attention towards other projects like djtechtools.com and un-informed.org/un-i.org away from php.net. That is not to say I have stopped following whats going on or that I do not care anymore. Its just that I feel that I can make more of a difference in these other projects. Also it might just be sort of a phase thing. I am sure one day I will become focused on php.net stuff again. Until then I hope others will pick up the slack and make sure that PDO gets love, at people diligently follow up on todo items mentioned on internals and that someone else picks up wiki.php.net and takes care of some regular maintenance stuff. Like there is a new version of dokuwiki out that fixes some issues, adds some features and adds PHP 5.3 support. If you are interested drop me a line or submit a comment. Who ever sticks around for a while and gives the wiki some love will obviously get commit access with that ever so shiny @php.net email alias.
Symfony? I like it!
Like I mentioned in my last blog post, we have a company internal framework that is quite advanced thanks to the various symfony components we have integrated. Its other main advantage is that it can do a lot with very little code. The net benefit of this is that it's extremely easy to learn and debug. Especially the last point can be somewhat painful with symfony since inheritance trees tend to be quite large and things get delegated to other objects etc. However once you start getting a hang of where things are, symfony is very powerful indeed. The other day we had a little hackday at Liip where we wanted to write a little google maps app. The idea was to have different kinds of markers shown on the map which when clicking on them would both load some data into the classic GMap marker bubbles as well as some additional data into a div below. Furthermore, the markers should be filterable. We choose symfony 1.4 as the basis, mostly because we wanted to learn a bit more about symfony, but also we felt that some of the module generation tools could help us get off the ground faster.
Learning the path of dependency injection
We are currently in the process of updating our company internal framework okapi to use several of the symfony components. The service container component seems to be the one that poses the biggest challenges since there are several conceptual issues to address. As such I am looking for other implementations of the service container to see how things work there. I have posted this on the symfony-components mailinglist a while back, but got no reply (probably because the list wasn't really announced properly), so I am reposting this in my blog to reach a larger audience, but also to bring some attention to the components mailinglist. I guess most of my concerns are not really all that much about dependency injection but the service container approach that symfony provides to make dependency injection use a bit more convenient. We have managed to somewhat answer our questions, but some still remain open: Where to keep the SC instance? How to deal with shared instances that need to be reloaded? How to deal with Service container caching and auto regeneration?