tank.

We started writing Dynamo in PHP using the CakePHP framework. Initially, we didn’t really have a plan, so I started on some pages and news functionality, showed it around, got input, went back, made some changes and the whole process would start again. We were basically prototyping. We would get ideas like the pages screen then implement it while writing loads of “throwaway code” only to move things around again later.

This all got developed over quite a few iterations. I came up with the idea for sections so that you can “mount” some of your content on a url on a per-site basis and assign it a template (out of a pool of templates assigned to a “skin”). All the thinking happened while we were developing, so we backtracked quite often and rethought big pieces of functionality.

Eventually I realized that CakePHP’s templates (which are actually just PHP code) won’t cut it. We might allow some power users to edit their own templates or we might partner with some other company or designers and give them their own account with admin rights so that they can add sites and make their own skins and templates. Therefore, I had to look at a templating solution. I was hoping that someone somewhere made something like a “cross-platform templating language” that is implemented in PHP and also Python in case we decide to rewrite the backend later, but didn’t find one.

Basically I realized that once we have many sites each with their own skins there is no turning back - it would be too much work to change. I eventually started writing my own basic templating engine (based off Vemplator), but realized it was a lot more work than I initially thought. In general I couldn’t figure out how to make the code scale as we add more features and sites, so I started to feel a bit uneasy. I was losing sleep.

At some stage I got pulled in to help develop SASIX. This took a while and gave me time to think a bit about Dynamo. After SASIX launched, I gave Dynamo’s codebase one look and basically informed everyone that I’m rewriting it in Python using Django. I just don’t like PHP enough to bother trying to fix it up - for reasons I would rather not repeat here. Also, I’ve been using Python for some pet projects and “non-production” code here and there for a while now and even though I initially discovered it long ago, I’m still in love. I’ve also been following Django’s progress with envious eyes for the past year.

I think starting from scratch was a good idea. The PHP based codebase was already getting a bit messy. In part because we kept chopping and changing things, because PHP code has the tendency to get messy and also because in certain places the “one service that powers lots of accounts and different highly ‘template-able’ sites” didn’t easily map to the CakePHP framework. I hacked the framework here and there but they just become unmanageable. Certain parts of the code really could benefit from the language features in Python and also features inside Django - particularly the excellent ORM code, the url mapper, middleware and various handy shortcuts and utilities. The fact that I know exactly what features are important and we already worked out how we want it to work certainly helps as well.

The Python codebase now already has most of the features the PHP version had and in some cases even a few more. Everything just feels nicer, cleaner and more organised. I feel like I can scale the code and add features without worrying about breaking backwards compatibility and I’m very sure that the skinning/templating “system” will not come back and haunt me a few months down the line. I’m convinced that Python more closely maps to the way I think.

Soon I’ll be blogging more about what parts of Django I’m using, what parts I decided not to use (notably the admin interface and the authentication and sites frameworks), how the system fits together, what thinking went into it and all that.