I would make a horrible framework developer.  Why?  Because I don’t have the patience to put the effort into making my code backwards compatible (unless I really, really have to).  Thankfully, the developers of CakePHP are not like me.

I just had cause to take an old client site that was built on CakePHP 1.0.x and move it over to a new platform with some upgrades in functionality.  Since we are most likely going to be developing a bunch of new features on the site I felt it was important to go ahead and upgrade the cake core libraries to the recently-released 1.2 — a task I was dreading from the moment I thought it.

But, surprise surprise, the whole ordeal wasn’t an ordeal at all.  In fact was incredibly easy because the Cake devs made it a point to include backwards compatibility. As a result a lot of my legacy code could remain in place to be upgraded gradually.

Take for instance the following gem.  I was a rough and tumble Cake developer back when I first wrote this and this format was actually never really acceptable in the first place, but it worked in 1.0.x:

$this->Order_frame->findAll();
// correct way to access the order_frames table: $this->OrderFrame->findAll();

// in view
echo $orderFrames['Order_frame']['type'];
// correct way to access the data: $orderFrames['OrderFrame']['type'];

Now, having used Cake for a couple of years I know the error of my ways. But, to my surprise, when I ran this legacy code locally on a fresh 1.2 core it worked. Huh? There was no way they would still support this ancient syntax! Heck, I dont think they ever supported it, really.

Anyways, this is a long way of showing my appreciation to the CakePHP devs for building the framework with all the legacy code out there in mind.

The latest spat between the rails elite and php elite is over a recent blog post by DHH, Mr. Moore gets to punt on sharding.

His argument can be summed up in a quote found in the comments:

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil”

- Donald Knuth

Basically, don’t jump into complex sharding/horizontal scaling techniques if you really don’t have to (yet).

Of course, Terry Chay has to take this opportunity to insert the fact that he works at a big company with tens of millions of daily page views and that vertical scaling is idiotic, blah blah blah.  (looks like he took down his blog post or I would link to it).

For every speaking engagement in which I’ve saved someone from a huge architectural misconception, DHH is probably creating 10 more future programmers who will make the mistake.

Damn, as a PHP developer I really want to like the PHP ‘Elite’ but this guy just doesn’t get it.  He works at his big desk at a big company and speaks at big PHP conventions and doesn’t have a clue what it takes to bootstrap a business from the ground up.

*UPDATE* – It appears Terry’s post got published before he could finish his thoughts.  He’s responded with the rest of it in the comments.  It’s a lot more well thought-out than what got published – so give it a read!

DHH’s point was that when your development team can fit in a VW Beetle you are going to cause a lot more trouble pre-optimizing with complex setups than simply relying on vertical scaling for as long as you can.

Forget who he is or what programming language he uses, that’s just damn good advice for anyone trying to bootstrap a startup.