Baking with CakePHP
No, I’m not entering into the world of culinary blogging, rather this is a narrative of my experience in porting SlideShowPro Director to the CakePHP framework.
Feelin’ geeky? Read on…
What’s a framework?
Wikipedia has a nice article on the subject, with this opening paragraph:
In software development, a framework is a defined support structure in which another software project can be organized and developed. A framework may include support programs, code libraries, a scripting language, or other software to help develop and glue together the different components of a software project.
Typically, when setting out to develop a piece of software, you have to start from scratch, building even the most mundane things in whatever programming language you have chosen. This has two major drawbacks. First, those mundane things take time. Second, mundane or not, you still have to maintain those portions of your code.
One solution to these problems is to build these things once, then reuse them in all of your projects. In effect, that would be a mini-framework of sorts. Frameworks simply build on this idea, generically adding components that a large number of users find necessary for software development. The end result is that instead of starting on the mundane things, you can jump right into the meat of a project because the foundation is already built.
Why a framework?
Beyond the reasons above, one thing that became increasingly worrisome for me was our maintainable lines of code (MLOC from here on out). Director was initially written entirely by me, from the ground up. That meant that every line of code was my responsibility, and as Director grew, new features and bad organization on my part caused our code to start to bloat pretty bad. By version 1.0.7, Director had somewhere in the area of 8,000 lines of PHP code, and all of them were MLOC.
A move to a framework does not necessarily mean your total lines of code (TLOC) will decrease, quite the contrary (as we will see in a few paragraphs). However, even as the TLOC increases, your MLOC decreases because the framework’s code is not your responsibility (at least not directly), rather it is maintained by the community of developers that keep it going. You just have to ensure you are using the most recent, stable version of the code available.
Another compelling reason for the move was Director was not (and still is not) my day job. When you are working on something off hours, you really need to be as efficient as possible for the sake of your offline life. Because maintaining Director had become cumbersome, new development came screeching to a halt as all my time was spent on maintaining existing features.
Why CakePHP?
My experience with frameworks began almost 2 years ago, when I stumbled across Ruby on Rails. Almost immediately I was hooked, so much so that we began converting all of our PHP apps at work to Rails (a move that is now complete). I was suddenly left with only one PHP project: Director. The more I worked in it, the more I longed to go back to Rails where things were just ‘easier’.
However we could not abandon PHP with Director, as it is a distributable program that is installed on the end user’s server. Switching to Rails in this case would have caused sales to plummet, as PHP is nearly ubiquitous on web servers of our target customer.
So, my focus sharpened to the growing list of PHP frameworks available. CakePHP stood out for two reasons. One, it was initially built as “Rails for PHP”, and although much has changed since then, it was easy to get up on my feet without having to relearn terminology and best practices. Second (and this was huge), CakePHP works on both PHP 4 (4.3.2+) and PHP 5 while most other PHP frameworks support only PHP 5. Just as a switch to Rails would have cost us sales in droves, so would suddenly limiting our target platforms to those who only had PHP 5. By my very non-scientific observations, I would say two-thirds of our customers are still on some flavor of PHP 4.
The Process
As with a lot of other things, getting started was the hardest thing. It can be pretty daunting to be sitting in front of 8,000 lines of code, knowing you have to somehow move them all into this new system. But you have to realize that not all of this code is going in, after all the point is to pare down this code to a fraction of its’ former self. Once I got started, things began to fall into place and the modular nature of Cake made it easy to spot and centralize replicated code. Thanks to a working holiday over Thanksgiving in the US, It only took me about a week of work to port. In coming posts, I will talk about some of the things that tripped us up and how we got around them.
One little tidbit I will share now: Take caution before adding daring new features while porting to a new framework. I made the mistake of also revamping our uploading process while making the move, and while it was worth it in the end, we really should have focused on one at a time as many headaches befell me in the process.
The Results
Like I said before, prior to the migration Director had 8,000 TLOC and 8,000 MLOC. After the migration, the TLOC was nearly double at 15,000. However, our MLOC had fallen to a paltry 2,000 lines. That is a 75% reduction in MLOC. What’s that mean in the long run? It means much less time maintaining and much more time focused on extending and improving our feature set.
The Cons
Moving to a framework is not all gummie bears and rainbows, there are things to consider.
First, there will always be parts of the framework you never use. We certainly don’t use all of Cake’s resources, but that’s ok with me. If it isn’t mine to maintain, I’m not too worried about it. It did increase the size of Director (a new install consumes about 2 MB on the server, as opposed to about 1.1 MB before), but with today’s hosting plans that isn’t much of a concern.
Another cautionary tale you hear about frameworks is that you are now dependent on those leading the particular framework you are using. While this is true, CakePHP is developed and maintained by a lot of different people and if you so wish you can contribute code yourself. If it doesn’t make it in to the framework, just pop it in as a plugin.
Conclusions
In the end, we are more than pleased with the decision to go with CakePHP. We only had to change one minor requirement that affected less than 1% of our user base, before we had only required PHP 4.3.0 and now we require 4.3.2. Director still works on Linux, Unix, Mac or Windows servers. Being able to hit all those deployment targets without forking the code was a big accomplishment in my eyes.
Look for more posts soon on my experience with CakePHP, and thanks to all who contribute to the CakePHP project.
Interesting case study. Maybe you want to add it to the “case studies” section of the bakery?
Comment left on January 6th, 2007 at 2:37 am LinkOh, I forgot something. On your product site you write the requirement is MySQL (3.23.23+). Cake needs at least MySQL version 4.x as it uses joins.
Comment left on January 6th, 2007 at 5:15 am LinkAh, thanks for the heads up. Perhaps the manual should be amended? I wonder though if any of our finds are actually triggering joins, something to look into…
I’ll also look into posting this to the Bakery, thanks for the comment(s)!
Comment left on January 6th, 2007 at 12:29 pm LinkFirst, there will always be parts of the framework you never use. We certainly don’t use all of Cake’s resources, but that’s ok with me.
The nice thing with Cake is that it only loads up what you use.
Congrats on the move - let us know how things go!
Comment left on January 8th, 2007 at 11:30 am LinkI was oh-so pleasantly surprised when I unzipped the first beta for this release and saw it was built on Cake! I’ve been working in CakePHP for a while, and it was interesting and very educational to see how you accomplished some things in the code.
Not to mention that it’s a fantastic app. (I’ve been a user since it was just “SSPAdmin”)
Comment left on January 8th, 2007 at 1:43 pm LinkWow-wow! I find this fascinating, as it does address a very real concern - TLOC/MLOC - in a very clear and concise way. And it features a program that I’ve been enjoying and strongly endorsing to all my design clients!
To think that, when a client now asks if a framework is necessary or good, I can point to the SSP Director that they already have and say, “LOOK!!” - I like that.
Thanks, Brad, for a great set of tools and some truly useful information!
-Toby Parent
Comment left on January 9th, 2007 at 10:03 am Linkhttp://www.tobytheballoonguy.com/
I am not able to bake can anyone plz help me soon.i just dont understand where i went wrong
C:\xampp\php>php bake.php -c:\xampp\htdocs\hramil\cake\
Could not open input file: bake.php
-Tahmeed
Comment left on June 19th, 2007 at 4:59 am Link@Tahmeed, what version of cake Are you using? I don’t have a bake.php in the version I’ve got, but I just use the command line for baking.
Comment left on July 29th, 2008 at 3:16 am Link