Yipit Django Blog: Sharing Everything We’re Learning | Hacker News Reader

Yipit Django Blog: Sharing Everything We’re Learning

tech.yipit.com

55 pointskek18 comments

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 :)

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

> It's always a challenge to get more posts out

And you say that before you have even one content post out?!

I'm not holding my breath...

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.

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!

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?

There is no comparison to South. South is used for migrating table schema, not backing up.

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

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.

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.

First post on how Yipit handles Django Settings is up: http://tech.yipit.com/2011/11/02/django-settings-what-to-do-...

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

Can anyone recommend any similar existing resources?

I always liked Jacob's http://www.slideshare.net/jacobian/django-in-the-real-world-...

It is great! Unfortunately, it can't be downloaded from SlideShare, although you can from here: http://toys.jacobian.org/presentations/2009/oscon/real-world...

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://www.djangobook.com/en/2.0/chapter12/ (under "Using Different Settings for Production") and https://code.djangoproject.com/wiki/SplitSettings ...

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.

We just posted on how Yipit handles settings: http://tech.yipit.com/2011/11/02/django-settings-what-to-do-...

Reply on news.ycombinator.com