Python Developer and Educator
2009-04-16
This is most likely going to be at least a three-parter, and I'm not getting into any code samples in this first one. I just wanted to give some background into the project I'm working on, so feel free to skip ahead.
As of this writing, I'm working at a company that is primarily a PHP shop. Only myself and the sys admin are in favor of introducing Python into the environment. It's an uphill battle, but we're both pretty persuasive, and in this situation I think we might have a slam dunk.
We are dealing with a lot of legacy data. A lot. We have over a hundred active clients (and many more that are inactive), each with their own MySQL database, some with multiple dbs. The formats are all over the board - they are all, at least, MySQL (some 4, some 5). Some of the databases have as many as 200 tables, most have around 80. And they're old - I've found a few that were created as far back as 2001. With data that old, I'm sure you can imagine some of the crazy table design going on. There's some normalized data, some not. Table structures have obviously evolved over to the years, with weird columns crammed in at odd places to accommodate sudden, unanticipated needs.
We are gradually migrating older dbs over to MySQL5 and taking advantage of those moves to apply some regularity, but there is so much data and we are so under-resourced that a full-scale cleanup and/or re-architecting is just not going to happen.
As big a mess as it is, there are some important commonalities - the structure of our user data tables is pretty uniform from client to client; likewise with our main content tables (news, photo galleries, that sort of thing).
So the situation is this - we have a crappy old CMS, written in PHP, that no one loves. It is nearly as old as some of those databases, and no one wants to make changes because no one here now is comfortable making changes in that legacy code. So the thing just sits there rotting.
Clearly, we need a new admin to manage all the details of our clients' sites (do you see where I'm going with this?).
Our admin is not just an internal tool. The clients we represent demand a lot of control over the content on their sites. They need to be able to enter news items, promotional copy, etc. on a daily basis. Our old CMS has a UI that can at best be called "challenging" - it's been proving to be a struggle for some outside users, most of whom are producers and management types, and not exactly power users.
So we need:
As far as I'm concerned, Django is the obvious choice. (I may be biased.)
Our business people have been pushing to outsource the project - they want to contract out for a custom CMS written in PHP. But if we go that route the cost is going to be exorbitant, and I have no doubt that we will have returned to us a pile of spaghetti code that will be a nightmare to maintain going forward.
No decision has been made on the outsourcing, so I'm currently in a race to get a demo of the Django admin set up before the VPs do something crazy.
Ultimately we'll need to have multiple admin instances, one for each client, with multiple custom groups and user access levels for each. Once I work the kinks out of one set of models, I'm looking to make them abstract classes and just inherit from them for each new client we set up. But we'll see - there are still a lot of decisions to make and problems to solve.
For now, I have an incomplete working demo on one of our dev environments, running on mod_python (I know, I know, not my choice). The good news is that now that my boss, a die-hard PHP guy, has seen how clean the code is, he's finally coming on board. It no longer sounds like one of my cockamamie schemes - now it's a viable enterprise-ish solution.
Over the next few weeks, I'll update with a step-by-step of my initial install and configuration, on the model massaging I'm doing, and how we're tackling some of the inevitable challenges.
Contact: barbara@mechanicalgirl.com