I'm continuing along with my plan to build an application on the Facebook platform. So far I've made a couple of decisions about the technology I'll use. So far I’ve decided

  • The application will be built on Amazon's Simple Storage Service (S3) and Elastic Compute Cloud (EC2) services for two reasons. The first is that it seems to be the cheapest solution out there for application hosting which can deal with large swings of traffic (if necessary). The second is that I’d like to learn about Amazon’s hosting platform and there’s no better way to learn than actually writing code.

  • The application will be built on the LAMP stack because it seems there are a lot more high quality,  cheap or free tools for building online services available for that platform than the WISC platform. 

  • It will use a Web application development framework that enables rapid Web development which is designed for the Web as opposed to having some HTTP related features being bolted on.

  • I will also use this opportunity to meet my new year's resolution of learning a dynamic programming language which is significantly different from the languages I'm most familiar with (i.e. C#, Java, Javascript).

From looking around the Web, it seems there are two language/web framework combinations that can fit the bill; Django which uses the Python programming language and Rails which uses the Ruby programming language. I haven’t done much investigation yet but so far it seems I’m leaning towards Python/Django for a number of reason

  1. There doesn’t seem to be a tutorial as comprehensive as Dive Into Python for Ruby.
  2. It’ll be easier to transfer Python programming skills to development with the .NET Framework since IronPython is now quite mature while IronRuby doesn’t seem to have gotten out of the prototype phase.
  3. I've read a lot of rants on the Web that indicate that Rails treats referential integrity within the database (i.e. foreign keys) as a second class citizen. See posts like I gave up on referential integrity, Are Foreign Keys Worth Your Time? and Rails' Ridiculous Restrictions, a Rant. On the other hand, Django seems to have built-in support for foreign keys.

I understand these aren’t the only criteria one should use when comparing Web application frameworks and there is a good rundown in Sam Newman's A comparison of Django with Rails. However these are the criteria that are important to me and it looks like it’s Python and Django for me. Unless someone out there has any other points I failed to consider?

Now playing: Shop Boyz - Party Like A Rockstar


Friday, July 20, 2007 2:59:33 AM (GMT Daylight Time, UTC+01:00)
Sorry but... what's WISC?
Friday, July 20, 2007 3:34:21 AM (GMT Daylight Time, UTC+01:00)
WISC = Windows, IIS, SQL Server, C#
Friday, July 20, 2007 5:34:19 AM (GMT Daylight Time, UTC+01:00)
Django's ORM layer is much more polished (its built on SQLAlchemy[1]), there's an actual object model behind it.

Given that you're going to spend some time refining your model, the choice is yours - Do you want to have to drop down to raw SQL the instant you do something "out of the box", or do you want code based criteria that you can manipulate.

Having used NHibernate and LINQ, I know which I prefer.

I spent some time trying to convince Rails developers that an object model was essential to grow AR, without success, I quote, "What's wrong with SQL"?

Regarding referential integrity, spot on. I had to download a hack that overrides core framework methods just to get my test suites in Rails to run, and another patch to be able to create referential integrity constraints using the migrations tool.

A patch to do same was rejected by the core team because it would "slow down unit tests". All I can say is, what the fuck are they smoking, I'll have some?

Rails is the new PHP.

Oh, and check out the Django Book [2].

[1] http://www.sqlalchemy.org/
[2] http://djangobook.com/
Friday, July 20, 2007 6:08:15 AM (GMT Daylight Time, UTC+01:00)
My advice is simply to go with what seems most natural/comfortable to you. The Python/Ruby divide is much less about language features and much more about preferred styles of getting things done -- people who've worked with both often seem to end up preferring one or the other because it "fits" the way they think and write code.

Similarly, Django and Rails differ more in philosophy than they do in functionality; the choice between them should be based on which approach ("convention over configuration" vs. "explicit is better than implicit", etc., etc.) seems more natural to you.

If you've got any questions about Django specifically, feel free to ping me via email; I'm always willing to help another old-time k5er out ;)

And a small correction to the comment above by nexusprime: Django's ORM is not built on SQLAlchemy; there's been talk of adding a compatibility layer for that, but no-one's yet stepped up with the code for it (though you can use SQLAlchemy if you like; it's just Python, after all, and Django does its best not to force things on you that you don't want). The Django ORM is a bit closer, design-wise, to SQLObject, and leans more toward the Active Record pattern while SQLAlchemy falls more into the Data Mapper school.

(obligatory disclaimer: I'm the release manager for Django, and work for the company which originally developed it. Measure an appropriate dose of salt to take with anything I say)
James Bennett
Friday, July 20, 2007 6:35:11 AM (GMT Daylight Time, UTC+01:00)
Great to see you decided to go with an S3/EC2 solution, Dare! Smart choice!

For what its worth, if you want to play around with a fairly complete [EC2/Mono/C#/XSLT 2.0 + AtomPub + Python + memcached + S3] solution let me know and I'll point you at the proper SVN repository.
Friday, July 20, 2007 6:58:07 AM (GMT Daylight Time, UTC+01:00)
If you decide to go ruby route then you should check out Ruby in Steel, it is a great ruby development for Visual Studio (you can use there debugging feature)

ruby programing book from Pragmatic studio,

ruby on rails screencasts, (this is a great resource)

Other rails tutorial,
Friday, July 20, 2007 7:11:44 AM (GMT Daylight Time, UTC+01:00)
Dare, don't get caught up in the Ruby on Rails hype or enjoy a world of obscure language features and lack of any useful documentation. Python is well documented, fast and as you have said - portable to .NET.

Django is one of the most well thought out web frameworks out there - give it a go.
Friday, July 20, 2007 7:37:20 AM (GMT Daylight Time, UTC+01:00)
1. http://phrogz.net/ProgrammingRuby/ (or google "pickaxe online")
2. jruby
3. http://agilewebdevelopment.com/plugins/foreign_key_migrations
Friday, July 20, 2007 8:25:20 AM (GMT Daylight Time, UTC+01:00)
I'm a Rails person, but steering way clear of any comments on that front. I will say that the Foreign Key issues are largely MySQL's fault - any MySQL-centric environment seems to fall prey to the same problem. Lot's of PHP frameworks with similar issues. I guess that not very long ago the MySQL party line was that transactions slow you down.

I am curious though about how you plan to manage your data.

Last time looked at EC2 it had some problems because the provided storage was volatile - everything is lost on restart. There are a couple of projects that back MySQL onto S3, but they can have some latency issues in the real world. That was a deal breaker for my project, but I use S3 for image storage in another project and it is awesome.
Friday, July 20, 2007 8:57:41 AM (GMT Daylight Time, UTC+01:00)
My apologies if I caused any confusion by stating Django's ORM was based on SQLAlchemy - I'm not sure how I came to that incorrect understanding.

But I stand behind my claims regarding the Rails issues I mentioned:

Current API docs for migrations (no FK support): http://api.rubyonrails.org/classes/ActiveRecord/Migration.html

Link to plugin required to add FK support to migrations:


Ticket on RI-safe unit tests:


Friday, July 20, 2007 10:17:58 AM (GMT Daylight Time, UTC+01:00)
We used Python + TurboGears for LouderVoice and have been very happy with it.

The richness of libraries for Python compared to Ruby means that there is nearly always an existing solution for a problem.

TurboGears has a different philosophy to Django. It pulls together best-of-breed components like CherryPy, Kid, SQLObject (in V1.0) into a consistent whole rather than building from scratch like much of Django.

When newer better components come along (Genshi for templating or SQLAlchemy for ORM) and it makes sense, they integrate them.

Whilst sometimes this can look like a moving target, it does mean that you have an ever evolving improving product that is not reliant on the development efforts of one small team but on those of multiple domain-expert teams.

The plans for TG v2 are even more radical where they aim to work very closely with Pylons which is the third of the three main Python web frameworks.

Friday, July 20, 2007 2:17:34 PM (GMT Daylight Time, UTC+01:00)
Ruby book: http://www.ruby-doc.org/docs/ProgrammingRuby/

I don't have much Rails experience but I find the Ruby language to be more "natural" and consistent than Python.

Another thing in Ruby's favor is IDEs. Specifically, I’ve been playing around with NetBeans and its support for Ruby and Rails is quite impressive:

I think it's the best free Ruby IDE environment out there.

As for Ruby on .NET, it will get there. Both MS and externals are working on it:
Friday, July 20, 2007 4:21:28 PM (GMT Daylight Time, UTC+01:00)

Restating what others have said above, both Python and Rails are both great platforms to build your Facebook application. nothing is 100% perfect, so draw up a list of pros/cons of each based on the needs of your app, and choose the one whose cons you can deal with the best.

We are building massive Rails apps on EC2 and S3. One of the caveats here is that you need to have at least two instances of your app running on EC2 and continuously back up to S3, lest an instance goes down and there is zero access to your app. Also, tools like RightScale (full disclosure - they are a partner of ours) provide a great auto-scale and management platform as well.

Another factor is experience of the development team. If you have people (or are doing it yourself), then choose the language and Web framework that has the least amount of learning curve. Our developers have backgrounds in PHP and Java (and I also have VB.NET) and have found Ruby and Rails easy to add to the toolbox.

I am a little confused on one point - you say you are going with a LAMP stack, but want to be able to port it over to Windows? If you don't have to deal with the licensing issues or the cost of the tools, why move to Windows? Keep it Linux :).

Good luck with whatever you choose.

Here are some links to good Ruby/Rails books:

Friday, July 20, 2007 5:00:16 PM (GMT Daylight Time, UTC+01:00)
I also prefer doing my app development in TurboGears, mostly because SQLAlchemy is the best ORM and because I like the design decision of returning a dict from my methods instead of a rendered template. Makes it really easy to add a decorator and get json/SOAP output instead of/in addition to html.

That being said, TG is going through a transition phase at the moment, so I'd skip it if you're starting a project right now and go with Django if you choose Python over Ruby. I feel the individual components aren't as strong as the ones used in TG/Pylons but the Django guys do a great job of integrating them.
Friday, July 20, 2007 6:05:15 PM (GMT Daylight Time, UTC+01:00)
@Toby: Foreign keys work fine under MySQL 5.
Friday, July 20, 2007 7:49:59 PM (GMT Daylight Time, UTC+01:00)
RE: Choosing a framework

I agree wholeheartedly with the argument that Django and Rails (Python and Rails) are both suitable frameworks (languages). I, too, investigated both, and ultimately chose Rails. It suits me better, I think. To each his own, eh?

RE: Foreign keys and Rails

I'm just going to guess, but it may be that there isn't support for foreign keys in Rails because not all of the databases one can use with Rails supports foreign keys. But that doesn't mean you can't do foreign keys in Rails! In the migration files, you can easily do something like:

def self.up
create_table :table1 do |t|
t.column :column1, :string, :null => false

create_table :table2 do |t|
t.column :table1_id, :int

add_index :table2, :table1_id

execute "alter table table2 add constraint fk_table1 foreign key (table1_id) references table1 (id)"

And it is trivial to add a helper function to do that for you, so you can reduce it down to

foreign_key :table2, :table1_id, :table1

And if you put that function in a library and symlink it, it's also trivial to add it to all of your Rails projects.

Disclaimer: This is based on the assumption that we are following the "convention over configuration" mantra, which I do.

Saturday, July 21, 2007 12:16:36 AM (GMT Daylight Time, UTC+01:00)
I'm the owner of a small consulting company focused on rails, so I'm a little biased (btw, I'm a former k5 member as well)

If you know python, I would stick with it for a facebook app. Facebook does some weird things like translating all requests into posts. That breaks quite a few of the idiomatic ruby conventions. On top of that, redirects can be problematic and some of the configuration for deploying a facebook app on rails can be a little painful.

I'm sure we'll get those issues worked out eventually, but I don't think facebook on rails is a good place to learn rails.

We're deploying a large client application on facebook next week, so it can be done. It just isn't as easy as the typical rails app.

Sunday, July 22, 2007 10:55:55 AM (GMT Daylight Time, UTC+01:00)
More Django/Rails comparisons:
Sunday, July 22, 2007 10:00:11 PM (GMT Daylight Time, UTC+01:00)
A note worthy Ruby learning resource is
Why's (Poignant) Guide to Ruby

I wrote a short review a while back:

All the best on the project.

Monday, July 23, 2007 10:52:34 PM (GMT Daylight Time, UTC+01:00)
Python? You should see my pythons! I'm fucking huge! I would body slam your doughy ass in a second, Dare.
Sunday, July 29, 2007 5:02:08 AM (GMT Daylight Time, UTC+01:00)
I think you're deciding between two excellent choices. After spending many years with C++, C# and Java, I switched over to Ruby on Rails about a year and a half ago, and I couldn't be happier. The difference between the above 3 languages and either Ruby or Python are much greater than between Ruby and Python.

Regarding Ruby documentation and tutorials, "Agile Web Development with Rails" and "Programming Ruby" are both excellent and were really all that was needed to become very proficient in developing web apps in Ruby on Rails. I recently picked up "Ajax on Rails", and have been able to put together some impressive code quite quickly. Rails integration with the Prototype and Scriptaculous libraries is great. Foreign keys work great in MySQL 5. I spent a lot of time with complex ORM code (loved Hibernate before I found Rails), and moving to Rails was a breath of fresh air. I don't feel I've lost any effectiveness, and my productivity has soared.

I expect the languages will have more longevity than the frameworks, so I'd suggest spending enough time in both Python and Ruby until you develop a strong preference for one over the other. They have a lot of overlap, but it seems people do tend to prefer one over the other, and joy in programming is important. Blocks, open classes, etc. do it for me :)
Saturday, August 4, 2007 10:38:14 AM (GMT Daylight Time, UTC+01:00)
Are there any good unbiased opinions on which scales better, rails or django?
Comments are closed.