Tips to a new django developer

http://blog.dpeepul.com/2009/08/31/top-10-tips-to-a-new-django-developer/

by rama_vadakattu • 17 years ago

109 16 17 years ago

blog.dpeepul.com

outotrai• 17 years ago

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

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

    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?

jonknee• 17 years ago

You're right. Another handy way to do this is to keep debug as False and use middleware to show the debug error if you're logged in as an admin or from an IP that matches in INTERNAL_IPS:

http://ericholscher.com/blog/2008/nov/15/debugging-django-pr...

Sort of the best of both worlds.

jksmith2• 17 years ago

Please, for the love of conciseness, never assign a boolean based on an if statement.

dmoho• 17 years ago

What if the assignment to the boolean was only one of the things you wanted to execute based on the result of the if statement?

aichcon• 17 years ago

How would you rewrite it?

pvg• 17 years ago

An odd thing thing about this piece of advice is that it contradicts a lot of the previous advice which is 'don't hardcode stuff' This pattern is questionable for another reason - basing the app's configuration on some other, largely unrelated configuration (in this case, that of the network) can lead to elusive and annoying bugs. Configuration problems are much easier to debug when an application is told what its configuration is rather than trying to magically divine it from its environment.

thomaspaine• 17 years ago

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

rama_vadakattu• 17 years ago

Very valid point.One thing which i would like to mention is the idea is really powerfull and pinaxproject has just started.I think it really takes quite an amount of time for the project to get maturity. I think still we need to put more thought on the below questions...........

1.How can we easily plug/unplug the django apps?

2.How easily can we customize a single app effectively?

ubernostrum• 17 years ago

Commented here:

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

jacquesm• 17 years ago

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.

slig• 17 years ago

I think that the preferable way of doing this is using signals.

snprbob86• 17 years ago

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.

gurraman• 17 years ago

I try to make reusable applications of most everything I "know" that I'll be using more than once or twice. Permalinks and named URLs are pretty handy when you do not use the same URLs across different projects.

(EDIT: Added "Permalinks and" before "named URLs".)

Tips to a new django developer

Related Stories