Ben’s and my Rails vs Django OSDC paper is now up on Google Docs. Please have a read, and, if you have any feedback, leave a comment here, or get in touch via the email addresses at the bottom of the paper.
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 |
Comments
Thanks for putting this together.
Nice work Alan. This is obviously a pretty volatile topic and from my admittedly brief reading you have done a good job maintaining NPOV.
Implicit in this report is the assumption that you each reached the same level of software quality for the two different implementations. A tricky one. You probably want to provide some motherhood statements to justify why this might be the case.
I'm not entirely sure the development times for each of the frameworks are sufficiently meaningful to warrant inclusion. The differences in development time could easily be explained by differences in your relative experience with the frameworks. Or one of you could be more productive because they have a 24" widescreen LCD monitor and the other a blurry 15" CRT. Or any number of other factors.
It would be interesting to see how each of you approached the task using the other framework, and compare the results, not just in terms of time to get up to speed but also quality of output, etc.
I think you should explain why you chose not to implement the schema migration code for the Django implementation. Without this the comparison is not exactly apples-for-apples. After all, the Rails implementation had to implement an admin interface that was not provided by the framework.
I would also like to see some discussion of operational considerations: how are these applications deployed on a typical hosting provider. I use the Rails-based Typo blogging engine and there are significant issues with respect to deploying this in a production environment. Things like CPU, RAM, network, and database usage are the main concerns. (I wouldn't be surprised if both frameworks lost out severely to PHP in these respects but that's another article perhaps :)
I hope people still want to come to see you present :)
Richard: the presentation is going to based on the paper, of course, but I think we'll make it worth people's time to turn up.
Alastair: thanks for taking the time to comment.
Alas, any informal, one-on-one comparison is dodgy, and this paper is no exception. I'll edit the paper to set expectations a bit better!
Yes, we'd have loved to have dug a bit more deeply and got some more metrics, but it's the same old story - not enough time or money! Still, I think the paper provides some useful material to fuel the debate.
Looking forward to hearing you sing the praises of Rails and Ben enthuse about Django!
Hey, I'm looking forward to the presentation :)
Rails supports Unicode with 1.2. And it's very easy to learn Ruby if you know python or vice versa. You can decide on rails vs. django on a per project basis.
I especially liked this "Safely store your work.
Online storage and auto-save mean you needn't fear local hard drive failures and power outages.".
Have you ever noticed how often Google and its servers glitch? how many times did they change their policies and algorithms? I do not trust this "company" and their "wish" to make our lives easier - it is simply another step to access to the data of the resources. In my opinion.
Plus you can use gettext with Rails too:
http://manuals.rubyonrails.com/read/chapter/105