For an agile web developer two frameworks are available for quick and easy deployment of a new website: Ruby on Rails for the Ruby fans and Django for the Python fans. These two tools should provide the same functionality and as someone who’s been working on two projects for the last month, each using one the frameworks, I have had the experience of starting from scratch on both of them and trying to learn both in parallel (or at least one right after the other without acquiring more experience in one and becoming biased for one over the other). So what has this experience taught me?

Deployment
It is very easy to start an application using both Rails or Django:
rails myapp vs. django-admin.py startproject mysite
even though one is wordier than the other it is pretty simple to start the project with all the directories and files needed automatically generated.

Starting the Server
This task is as simple as the previous one:
ruby script/server vs. python manage.py runserver
in both cases there is a call to the language in use, then passing a command. In Rails’ case the command is an executable found in the “script” directory whereas in Django’s case the command is an argument passed to the Python manager.

Configuration
Both frameworks provide a place to configure the application. Rails provide an entire directory to configure the database setup and the Rails environment whereas Django provides a settings.py file where all the configurations can be present but also provides the option of having a config directory for multiple personalized configurations.

Updating the Database
Yet another simple task:
rake db:migrate vs. python manage.py syncdb
In this case we notice that with Rails the call is actually to “rake” whereas for Django it is still consistent with the previous format. But we’ll see that Rails is also consistent where “rake” is called for everything relating to the database.

Creating Models
Where some of the differences begin:
With Rails you create one application that can have multiple controllers, models and models and link to each other using ruby script/generate * (where the * differs depending on what needs to be generated).
Whereas in Django you create multiple applications which each has its own models and views using python manage.py startapp myapp

Documentation
It seems that Rails is more widely used which results in more available resources online for documentation and help. None the less, the Django documentation site is very extended and provides sufficient help.

The Dirt
In the case of Rails I started the project from scratch by first following with the example in the book Agile Web Development with Rails, Third Edition and then applying what I learned to the project I was working on. Whereas in the case of the Django project, I was put on it late in the development process and tried to learn the language and at the same time understand what was already done on the project. My experience with both has been limited and what I have found is that the Rails magic seems to be the difference maker for most people. The majority are not comfortable with that “unknown” but I have seen some magic done with other languages like Java, although it is not the same type but in either case there is something in the background that is doing some sort of work for the programmer. And I have become comfortable with such a setting and because I have seen a bit of how programming languages interpreters work I understand and appreciate the Rails magic.

Even though I was more productive using Rails than I was using Django, which may have influenced my opinion about them, I am still willing to give Django a chance. Both are great tools for developing web applications in an agile manner. My recommendation though, if I have to make one, will go for Ruby on Rails, just because I was more comfortable with it.

Recently, the Newport News, Virginia Open eGov system was released. Using the Plone content management system, the system is designed for governments to install, out of the box, a website which also includes specialized departmental infrastructure. Newport News has also made the system available under the GPL; it can be found here.

I found this quotation from their Lessons Learned document interesting: “The adoption of new technology is an iterative process of innovation and learning…” While they did not use the actual term, it seems that the team which developed Open eGov utilized an agile approach to software development. Agile development does not mean a harem scarem approach to development; the team said that they spent a significant amount of time conducting research on best practices and content management systems before undergoing the customization necessary to launch Open eGov.

We are interested to see if this product gains traction. It is part of the PloneGov project, which, while claiming members in 20 countries, does not have an apparent member list, or much reach. I think that if the Newport News staff wants to extend their reach for the product, they’ll need to answer some questions:

• How can they increase citizen participation in these sites? I see surveys, but there is no way to comment
• How to spread the word about the availability of this product? The product is, from appearances, targeted at local governments.
• Is the Plone/Python/Zope package the best one to facilitate widespread adoption? The community of developers is much smaller than of other developers. Naturally, Scott Stults, our resident Plone and Python expert, believes it’s the right answer and could be seen dancing with joy when shown the Newport News announcement.
• Why not put the project into a system that allows user contribution to it? How a developer contributes to the Open eGov project is not particularly clear. Perhaps this is an intentional result of the lack of desire to be the gatekeepers of others’ contributed code.

Seeing Open eGov is certainly, to us, a positive development. Now, we’ll see what happens next. Building a great open source platform is just one part of the puzzle; developing a vibrant open source community is another kettle of fish.

Thanks to our friend James Walker at EzGov Europe for pointing this article out to me!