I found this really enlightening post and presentation on Python vs. Ruby from a Python guy, Gary Bernhardt. Gary first talks about some features of Ruby that violate the “Zen of Python.” He only presents 5 violations, but you can see for yourself that Ruby does violates most of this “Zen.” Then Gary goes on to discuss he likes about Ruby, namely RSpec and Cucumber. Then he points out that these cool packages are possible because Ruby allows you to violate the “Zen of Python.” It is the very thing that he dislikes that makes the things he likes possible!

After watching the presentation, I have pretty much the exact same feelings as the presenter and yet, as of now, I’d rather work in Ruby. I love the ideals of Python especially “one obvious way to do it” which is not at all the case with Ruby. I can’t stand the idea that a framework is mucking with the base functionality of the language behind my back like Rails does. But these are the very influences that have lead to a Ruby community that focuses on BDD which in practice is what I enjoy.

As I mentioned in my last post, I’ve been trying to get some unit testing going so that I can keep focused and gain a higher level of comfort with the code I’m writing. I started by trying move a business method that had crept into the model and put it in its own business class. To test the new business class I tried to use Mock to imitate the behavior of the data model, but I couldn’t find a way to get it to mimic the behavior of a Query object which is both indexed and has methods on it. I did learn that Django fixtures were supported by app-engine-patch. In fact, I learned that most of the ./manage.py functionality works. I had incorrectly assumed that app-engine-patch only allowed you run a Django app on App Engine server, not that it could be used like standard Django. After writing a test for the new business class, I created a fixture to support the test. Well, the test kept failing even though it should have passed. I did some digging, and it seems that the models in the fixture that have relationships aren’t getting loaded. I’ve got a question out to the list to see if this is actually the case, but I can’t think of another explanation.

So, I didn’t actually get any unit tests working, but while writing the test I noticed that there were model classes in my view as well as the database classes in my controller and business logic in my models. So now I’ve got it all cleaned up and the code appears to be working (no tests though). I keep seeing what kind of tests I can write and maybe someone will fix the problem with models with relationships in fixtures.

I started working through the Lift getting started guide and other documentation and I’ve come to the conclusion that a lot of the benefits of using Lift aren’t applicable to the project. The project is a Facebook app and I have a little experience writing those with Django and Google App Engine. All the nice CRUD, AJAX, JSON, Comet, etc. integration isn’t going to help me. Also, there aren’t a whole lot of examples of using Lift with Facebook. In fact, my biggest concern with using Lift would be the lack of documentation. There is “The Lift Book” but this is more a guide to what Lift can do and how to do it. There are a few tutorial floating around, but the ones I found were out of date and incomplete. I’ve come to realize that I learn best by working through examples and there just aren’t enough of those to make me want to move forward with Lift.

I’ve decided to go with Django on Google App Engine for this project. It’s somewhat familiar ground and will allow me to focus more on building the app rather than learning a framework and language. Although I’m not well versed enough in Django, Python, Google App Engine, and Facebook to believe I won’t learn a whole lot.