Tips to a new django developer

A thought on security - I think #5 should be changed from

    if socket.gethostname() == 'productionserver.com':
        DEBUG = False
    else:
        DEBUG = True

to

    if socket.gethostname() == 'developmentcomp':
        DEBUG = True
    else:
        DEBUG = False

It's better practice to whitelist one box than to enable DEBUG on all computers but the production server - what if you deploy to another machine without thinking?

I generally agree with all of the tips except for using Pinax. I like the idea of Pinax, and I think it makes a great sample app if you want to see what good Django code looks like. It's maintained by top notch developers and showcases a lot of excellent reusable apps and good Django design patterns, but when it comes down to customizing a Pinax app to create something you want, it's a nightmare. The internal apps are too tightly coupled, and it takes longer to take out all the stuff you don't want than to just roll your own apps from scratch.

More pinax discussion here: http://news.ycombinator.com/item?id=764566

I'd like to add one here (and as a 'new' django developer myself take it with a grain of salt), use the save method in your subclasses of 'models.Model' to do things like computed fields and other trickery to keep your database consistent.

Otherwise you'll end up doing this in multiple places throughout your views.

If your database supports it triggers, stored procedures and functions are probably a better way of achieving most of these things.

By putting a save method in your subclass you get access to the record about to be created or updated, you can use this to lift the id field out and do tricks with it just after insertion in to the database, or you can store the value of a field that can not be easily computed during data retrieval.

I use this in an application where each page appears as a leaf in a tree to update the path to the node based on the parent node and its path.

Commented here:

http://www.reddit.com/r/django/comments/9ftbs/top_10_tips_to...

Personally, I intentionally hardcode my URLs.

This forces me to think about my URL design up front. Then, if I decided I want to change URLs later, I've got plenty of time to come to my senses and stop. Public URLs shouldn't change, so this can only ever be a problem during development where a quick `vcs diff` renders the problem practically moot.