

Yipit Django Blog: Sharing Everything We’re Learning - kek
http://tech.yipit.com/2011/10/17/announcing-the-yipit-django-blog-techniques-best-practices-lessons-learned/

======
famousactress
As someone also doing production Django for a web-app (as opposed to a
news/content site) I'm thrilled to see a team committed to posting lessons-
learned... but I'm always suspicious of "We're gonna post lots of great stuff
here.. you know, soon." So hopefully you start coughing up the content.
Looking forward to it :)

~~~
AdamN
It's always a challenge to get more posts out but we're committed to it :-)

~~~
gurraman
It really is a challenge. Maybe you could create a small buffer of articles.
The size of the buffer would depend on how often you're going to post, but
enough to last you a week or two. Everything in the buffer should be ready to
publish so that you can always post something interesting at the intended
rate. Even if you're _dead-set_ on posting _that thing_ on Friday, you'll be
surprised to learn how hard it can be to find the time and motivation when
your servers are melting, a critical bug has been exposed in your software and
you're (non-blog-writing) friends come in, swinging two cold beers in each
hand.

------
wafos
This is great. I'm always looking for more django resources outside of the
excellent docs, but there just doesn't seem to be a ton of up-to-date stuff
out there.

Hopefully you can keep it up!

------
genieyclo
Have you all ever taken a look at Django-DBBackup?

<http://pushingkarma.com/projects/django-dbbackup/>

What is your opinion on it? Compared to South?

~~~
yummyfajitas
I don't get it - what does django-dbbackup offer over 4 lines of bash:

    
    
        outputfile=/tmp/database_`date +%Y_%m_%d`.sql.gz
        pg_dump fashiondb -U fashionuser | gzip > $outputfile
        s3cmd --config ~/.s3cfg put $outputfile s3://mybucket
        rm $outputfile

~~~
gurraman
Well, code to restore the database from a backup for one. It also seems to
track form which server backups were created.

I haven't looked, but it might also, in the spirit of Django, be "database
agnostic" and allow you to import data across DBMSs. You'd still need to keep
some things like uploaded files in sync though.

~~~
yummyfajitas
Restoring is another 6 lines of bash:

    
    
        s3cmd --config ~/.s3cfg get s3://BUCKET/database_$1.sql.gz
        gunzip database_$1.sql.gz
        sudo -u postgres dropdb DBNAME
        sudo -u postgres createdb -O DBUSER DBNAME
        sudo -u postgres psql DBNAME < database_$1.sql
        rm database_$1.sql
    

But I suppose being database agnostic would be handy - it would make switching
from mysql to postgres easier.

------
vacanti
First post on how Yipit handles Django Settings is up:
[http://tech.yipit.com/2011/11/02/django-settings-what-to-
do-...](http://tech.yipit.com/2011/11/02/django-settings-what-to-do-about-
settings-py/)

------
bryanh
Excellent, I have high hopes for this being a resource for real world Django.
You guys have my eyes and ears!

------
samg
Can anyone recommend any similar existing resources?

~~~
gregsadetsky
There's "Django Best Practices", which was discussed two months ago (although
it doesn't seem like it grew a lot since): <http://lincolnloop.com/django-
best-practices/>

HN discussion: <http://news.ycombinator.com/item?id=2936364>

Any effort to assemble "field" knowledge around Django would be great. For
instance, I was looking for best practices for splitting settings.py
(separating dev, test and prod-specific configs). If anybody's interested, I
went through: [http://stackoverflow.com/questions/88259/how-do-you-
configur...](http://stackoverflow.com/questions/88259/how-do-you-configure-
django-for-simple-development-and-deployment) ,
<http://www.djangobook.com/en/2.0/chapter12/> (under "Using Different Settings
for Production") and <https://code.djangoproject.com/wiki/SplitSettings> ...

~~~
Encave
My normal settings structure is as follows:

    
    
      * settings/__init__.py
      * settings/base.py
      * settings/development.py
      * settings/staging.py.
      * settings/production.py
      * settings/credentials.py
    

This allows me to have a base settings file which the others inherit from, and
all settings are tracked in git apart from passwords which are stored in
credentials.py.

Unlike some other approaches, installed apps are just defined once (in the
base), but apps can be added/removed for each environment.

