ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
PHPCR on Doctrine DBAL
So I have noticed that people don't like it when I talk about all the cool stuff Jackrabbit can do. Many people are still scared of running Java stuff in production which I guess is to be expected since PHP shops tend to .. guess what .. PHP. So in this post I just want to talk about all the cool features we have ready to use in the pure PHP Doctrine DBAL based implementation of PHPCR. Just to say it again: PHP, no Java. So first up the implementation with all its features works with MySQL, PostgreSQL and SQLite. Given that we started with MySQL we ended up relying on few specific MySQL behaviors. These are all gone now, so adding another RDBMS is likely just a half days work, maybe a day if you look at the code base for the first time, then again the relevant code to edit are just a few places in two classes (Jackalope\Transport\DoctrineDBAL\Client and Jackalope\Transport\DoctrineDBAL\Query\QOMWalker). At any rate the implementation essentially gives you a tree document store on top of an RDBMS with support for references and so called node types allowing you to optionally add constraints to your document structure. Documents can have any number of properties which can choose from a wide set of datatypes like string, integer, date, url and binary. You also get both an OO and string based query API.
So what is the CMF good for?
The last blog post was just notes on the feedback I got as a reaction to a moment of frustration on twitter. People had asked me to summarize the feedback and this is what I did in that blog post. But I realize now what is more relevant is that the CMF team needs to more clearly explain that we are not trying to go head on against the likes of Drupal, Typo3 or eZ Publish but why our work still might matter for to others. The people that are interested in the CMF are developers that have realized that while they have needs to maintain dynamic content on a website, none of the current crop of CMS solutions were really a good basis to solve the needs of our clients. Drupal and friends provide a bazillion features and if your clients for the most part simply need a subset of these features, then by all means use one of these CMS solutions as you and your clients are not in our target group. Obviously we would love it if we could also provide these bazillion features, but realistically it would take us years to catch up. We see our target group among those where their clients need isn't a subset of the offered features; rather where it is necessary to do a custom implementation of the bulk of the features. Today any project that has "content management needs" is build on top of some CMS even if they don't deliver any of the key features. As a result the final solutions end up bastardizing these CMS, creating a lot of pain for the developers and needless constraints for their customers. We want to be "disruptive technology" in the way Clayton Christen described in his book the Innovators Dilemma.
Symfony2 CMF and the lack of contributors
So the other day I was ranting on twitter that there are very few contributors for Symfony CMF. Actually I should qualify this. Surprisingly we have quite a few people helping on the low level architecture pieces like PHPCR. For the inline editing the IKS project is ensuring a healthy doze of development pushing [create.js http:://createjs.org] etc. But on the Bundle level there is very little happening. This to me is quite puzzeling since thanks to our sandbox and the fact that PHPCR ODM for the most part work exactly like the ORM and Mongo ODM, any Symfony2 developer should feel right at home. Lets ignore for now the classic response of "no time", people replied pointing out various reasons like maybe A) the community just need something simpler, B) Drupal and ezPublish are already providing what they need C) they have already developed something RDBMS based in house because the CMF wasn't ready or D) there isn't even documentation to get started. So let me quickly respond to each point.
OSX vs. Thinkpad
So in the summer of 2007 I switched from Windows to OSX which also meant switching from Thinkpad to Macbook Pro. While there were some details I liked on the Macbook Pro, like the at the time quite innovative magnetic design on the lid latch, overall I was sad to not be able to use a Thinkpad. So it also came that my first Macbook Pro had to repaired 3 times in total. Despite having bought the insanely expensive AppleCare this meant having to drop off my laptop for several days (usually 5 business days) or paying an "express service" charge. In general I believe Macbook's to be pretty decent, but not as sturdy as Thinkpads (starting with the availability of spill resistant keyboards). More over they tend to skip on connection options and are overpriced. Then again I really don't care about the price that much. I use my laptop for pretty much everything, from work to DJing to private use. But the fact of the matter is I wish I could still be using Thinkpads. BTW I do appreciate the design of both Thinkpads and MacBooks in their own way. Despite all of that I was and still am very happy with OSX. At the time of the switch the Linux desktop was certainly not ready for home use.
Taking a breather to sort out my future
So when you are a programmer life is good. You can kind of work from where ever you want (home/office/nature ..), constantly get to work on new and exciting stuff (well if you want that is) and you can choose from an entire planet offering you jobs that by and large pay pretty well. Personally I have been additionally very lucky in having found Liip. Now this sentence sounds a lot like the beginning of a note on my immediate departure from Liip, where I thank them and then state that I needed a new challenge lala. However this blog post isn't about making a decision to leave Liip public. Its about me trying to figure out what I want to do in the future. I am very certain that there is no other web agency on the planet I would rather work for than Liip.