Lessons learnt as a Ruby Programmer playing with Google AppEngine

I suppose I should write a detailed post at some point about this. But here are a couple of notes from working intermittently on Talk.org in the last couple of weeks.

First of all Python is definitely not Ruby. It is very different in many ways. So just accept that and get on with it. Ruby still puts a much larger smile on my face than Python does, but that might be inexperience.

Secondly Django is not at all like rails, even though most python guys seem to claim it is. Pylons seemed much more rails like. However I decided to stick with Django as it’s always good to learn something new.

The best resource I found for getting started was this example project Wuzhere that was demonstrated at Google IO. It is really a great guide to get your head around structuring your project. In particularly coming from Rails, I learnt way more just reading through this code than reading various tutorials on the web. A key piece of code to simplify your life as a rails guy coming over to Django is their view.py class, which acts kind of like a rails render method.

You should use the Django Google App Engine Helper if you are doing Django which is described in this little tutorial. However the approach to laying out your application taken by the Wuzhere developers seemed more logical to me than the approach suggested by the Google App Engine helpers.

Generally speaking I like the AppEngine design. The models are great even if they require you to think a bit differently about the design of your data model. I don’t see a clever way of doing callbacks on the models like with activerecord, but I suspect that something similar would be possible with clever use of Decorators

I would like to say though that while I am still a novice at Django/Python it does seem to me that there are design decisions in both that I’m not quite happy about. Once I’ve worked more with it I’ll see if I still feel that way and can formulate it a bit better.