

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

======
outotrai
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?

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

~~~
dmoho
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?

~~~
jksmith
Even then, I'd rather see:

DEBUG = socket.gethostname() == 'developmentcomp'

if DEBUG then...

------
thomaspaine
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
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?

------
jacquesm
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
I think that the preferable way of doing this is using signals.

------
ubernostrum
Commented here:

[http://www.reddit.com/r/django/comments/9ftbs/top_10_tips_to...](http://www.reddit.com/r/django/comments/9ftbs/top_10_tips_to_a_new_django_developer/c0clzux)

------
snprbob86
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
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".)

