Having made the decision in early May to spend the summer building a replacement for Quahog, the next question was what to replace it with.
Back when I first started at Carthage, I decided that Coldfusion would be a good choice for me and the students who would be working with me. It looked like an easy language to learn, and I had enough to learn at that point and figured that training a stream of students would be easier with something that is inherently easy to learn. Surprisingly enough, that decision proved to be a good one. I say surprisingly because I had so little to base it on at that point that it was little more than a shot in the dark. But it worked out very well for us. Mike, Chris and I have done quite a few cool things with Coldfusion, including Quahog.
So when it came time to decide how we would build a replacement for Quahog, Coldfusion was clearly in the running. Given our history, it would have been the quickest way to go. But this is a college we're working for – an institution dedicated to education and all that, so I'm always open to taking new paths. And knowing that Chris and Ivan would be graduating in December and entering the job market, I wanted to give them a chance to flesh out their resumes with something that would capture more attention than yet another Coldfusion application. The prospect of having something a little sexier of their resumes ended up being a significant factor for me.
So, Coldfusion was a contender, but our prior experience ended up counting against it, simply because we had "been there, done that."
Ruby on Rails is on everybody's radar screen, so it naturally was a contender. Actually, last summer I had Chris rebuild our alumni directory and class notes application in Rails, so we had one decent-sized, honest-to-God deployed Rails application under our belts.
But what else? What other frameworks should we consider?
Ivan has done some impressive things with PHP, and he had heard about Symfony, a Rails-like framework written in PHP. That was added to the mix of contenders.
I came across a very timely presentation by Sean Kelly (http://oodt.jpl.nasa.gov/better-web-app.mov) in which he goes through several web development frameworks. Long story short, we added Django to the list.
We literally put a checklist on a whiteboard in our office and started making notes.
As I mentioned, doing yet another Coldfusion app wasn'tvery appealing. The same "been there, done that" thing dragged PHP-Symfony down eventually.
Rails and Django were left standing. Rails is older. We own Rails books. There is Rails training. Rails, Rails, Rails – it's everywhere. There will probably be a Rails channel on cable TV before too long. But Django is really what we're looking to do. We're building a CMS more than a web application. Ruby is cool. Python is cool. Chris has done the one Rails project, but really either framework and either language will be enough of a learning experience for all of us.
Is Django far enough along? Do we really want to build a project with code coming out of Subversion? In all honesty, I had never gotten code out of a cvs before, ever. That felt pretty bleeding edge to me.
I knew that Django was the right tool for what we were going to do, but I wasn't sure if it was done enough. I had decided that we should use Rails, even though I really wanted to use Django. I also realized that I wasn't going to be doing much coding this summer, and so I left the decision up to Mike, who picked Django.
My reaction to Mike's choice settled it for me – I realized that while I was pretty apprehensive about whether Django was done enough, even more strongly I felt that we were going the right way.