ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
On predictable PHP release cycles
There is currently a vote going on to include Zends Optimizer+ opcode cache into PHP core. I am very happy with finally adding an opcode cache to the core distribution if only because it then forces to actually ensure that there is a working opcode cache together with every new release. What troubles me though is that its being proposed very late in the game for PHP 5.5, therefore causing a likely delay of 5.5 of at least about 2 months in the best case scenario if it were included. The other option of including it in 5.6 does not seem to be as popular at this point. This saddens me quite a bit since I believe that predictable release cycles would carry several advantages. First and foremost it will ensure that developers that propose a new feature will have a better idea of when their feature will be part of a release. This can encourage developers to actually bother with sharing code and it also prevents developers from getting disgruntled if their feature is deemed not yet ready for the upcoming release or even more importantly prevents half baked solutions from being pushed in just to prevent an unknown further wait time. Furthermore it makes it easier for PHP end users, especially larger frameworks and application maintainers, to plan their releases. Finally it poses the chance that distributions will better schedule the freeze time for PHP versions, rather than the current rather random choice they tend to do.
Liip is where I want to be!
This summer I took 2 months off to figure out what I want to do in the coming years. After over 5 years in Switzerland it seemed prudent to take a step back from the daily routine to ponder things. I wrote a lengthy blog post about the options I was considering a while back and as I never really gave an update on the results I just wanted to point out that I decided to stay with Liip. I wrote up a long blog post about what I did during those 2 months over on the Liip blog. Just wanted to post this since I have been asked quite a bit by people about this.
First up a disclaimer. I don't think I have any answers to offer and I must admit I will probably not actively do much to help improve the current situation. However I do believe it would be great if this would become a non topic but I acknowledge that there is a problem. Like many I don't see myself as part of the problem, maybe I am wrong there. In general the Symfony2 scene is quite un-diverse, at least when it comes to gender. I don't remember ever seeing a women present on a Symfony2 topic at a conference. I think the only one that I have heard speak on Symfony2 is Lorna. Alvaro mentioned that at deSymfony there was a presentation by a female speaker. That being said, skimming over the top 100 contributors I don't see a single female name. Actually just going by memory I don't remember a single PR from a female contributor. I would be surprised if there wasn't at least one, likely there are quite a few. Not remembering is actually quite ok imho, because its not the most memorable thing about a PR what the gender of the contributor was. But I am quite sure that the number of patches from women is a tiny tiny part. I sure hope that the numbers in my head aren't skewed by women preferring to contribute with a male name because they are worried a female name would cause issues.
Back when PHP5 came along in many ways it meant a new stepping stone for PHP. To some extend this was caused by the fact that it was impossible to write E_STRICT compliant code that also worked on PHP4, since initially using "var" for properties didn't pass strict mode. As a result many people used this as an excuse to start over and I think overall this led to higher quality code, since the community had evolved from the skill set, but was held back by the legacy baggage. Then when PHP 5.3 came around with namespaces, it had a similar "cleansing" effect. So evolution was done partly by burning bridges. What is interesting is that with composer I see a process in the community of equal impact, yet instead of burning bridges, its building them.
Wanted: content negotiation library
So a while back I wanted to add native support for API versioning to FOSRestBundle. While working on this I began to realize that this would really require supporting proper content negotiation. Note that while there is a spec for how to express the preferences of the client, there is no spec on "negotiating" between what the client wants and what the server has to offer. My current implementation is rather simple .. well simple is probably a euphemism for "incomplete to the point of being more than half wrong". I began to search and didn't really find any decoupled library for PHP that could do the job. I then stumbled over mod_negotiation and thought that it would make a lot of sense to use their algorithm as I simply assumed that it would have gotten a fair bit if scrutiny preventing me from doing something stupid. More over it could also mean that we cut optionally allow users to leverage this apache module instead of our PHP implementation to improve performance. Now that idea sat there for a while until the Drupal guys brought up the topic again. I told them my idea and work began doing exactly this but unfortunately isn't moving forward as quickly as needed to make the December feature freeze of Drupal 8. There are two new people willing to work on this, but its still unclear if things will get ready in time. Since I know we are not the only ones who need this in the PHP community, I am sending this out as a rally cry to work on this together.