Bleed for speed - Rob Spectre¶

Tags: django, djangocon, python

He started with a little history lesson. The sea battle of mobile bay. The admiral (Faragut) ordered the ships straight through the minefield (called “torpedoes” at the time). “Damn the torpedoes, full speed ahead”. And it worked.

What does this to have to do with Django? Well, “damn the torpedoes, full speed ahead” feels a bit like how rapid prototyping feels afterwards. He’s often involved with hackathons. Lot of quick coding in limited time with a lot of people. He learned a lot about his tools that way (and he often used Django).

There’s a time to make a distinction between production and prototype. Sometimes it is better to just try something with a prototype. Throw-away code.

Aaargh! Throw-away code?!? We never throw code away. But it is something we must learn. It is good to let go once in a while. Let your code go. It isn’t yourself, it is just some code.

The danger is that prototype code is put into action as production code. With some work, this danger can be prevented.

What about Django? Django is the best for prototyping. For rapid prototyping, Django is better than micro-frameworks like Flask that might seem better at first glance. Here are some reasons:

• Django was build for rapid prototyping. It originated at a newspaper! 24 hours to build something.

• It is flexible. It was build to bend. He can prepare something for the other people programmign with him and get them going and still keep the code in reasonable shape.

• Us. The strength of Django is the community that supports it. Stack overflow questions and answers. The django websites. Books like two scoops of Django (see my review). That’s not something you have with many other frameworks!

  Tip: read especially chapter 2 and 3 of the two scoops book.

  One thing he’d add to the book is stuff like fabfiles and makefiles. Handy for rapid prototyping.

Use stuff that’s available. For instance Django’s staticfiles app for grabbing together all the css/js/png. Whether it is in one directory or split out over multiple apps. It also helps with production.

Also look at brunch for setting up your javascript app’s structure. It works well with Django.

Deployment: you need to show your prototype. Heroku is very quick for prototypes. (He mentioned that they have a data center in Europe now in case you need it).

Deployment: use chef. Lots of recipes. You could also use Salt if you’re more into Python. Also lots of stuff available. Both take a while to learn, but it is a very good investment.

Configuration management is an extremely useful skill. Do it well.

Tastypie is the quickest way to get a REST api out of your Django. It is the best for rapid prototyping. Another good one is django-rest-framework. It will take a little bit longer to set up, but once done you’re working with actual Django views. And django-rest-framework’s browseable API is very helpful when you’re working with a couple of others

Social auth connectors: everyone makes one and there are way too many half-working ones. He’s got two that he can recommend. django-social-auth is very complete. The other is django-allauth for when speed is important for you.

If you don’t want to play fair to others during a hackathon: use celery. It is very unfair to use celery, python and Django. The combination with Django is pretty OK to set up. You can do a lot what others cannot do easily. So use it for rapid prototyping. (Regarding setting it up: there are good chef recipes for it).

TEST. Yes, even during a hackathon. He doesn’t advocate full test driven development. It is a balance. But the errors that kill you during a hackathon are the errors you make twice. So, for instance, test that all your views simply return a 200 Ok. This already helps prevent a lot of problems.

Look at AngularJS. Even if you don’t use the framework itself. Why? It has a great javascript test runner. Good for testing while rapid prototyping.