Things I Wish I Had Known About Django Development Before Starting My Company

12. Use `pip freeze` to keep a list of your requirements, and keep that requirements list in your repo. Use virtualenv and virtualenvwrapper to keep your environment clean from other environments. Virtualenvburrito (https://github.com/brainsik/virtualenv-burrito) will help you set it all up.

13. You almost never need to write bash scripts. Use django management commands to write scripts that interact with your application. Use fabric and a fabfile to do deploys. Use something like chef or puppet to do machine configuration. Your bin/ folder will turn into an unmaintainable mess very quickly.

14. Use south. Yes, it's obtuse, but it gets the job done.

15. Use a pre_save hook on all of your models to do full_clean for validation before anything goes to the database. This will save you from cleaning up your data later.

    from django.db.models.signals import pre_save

    def validate_model(sender, **kwargs):
        if 'raw' in kwargs and not kwargs['raw']:
            kwargs['instance'].full_clean()

    pre_save.connect(validate_model, dispatch_uid='validate_models')

16. If you're writing a javascript-heavy application, consider all of your options for static asset management before you get too deep. I've used django-compressor, django-pipeline, webassets, and django-gears. None of them are perfect solutions (there still isn't a sprockets-esque one-catch-all solution for django like in the rails world), so consider the pros and cons before you make a choice.

edited for formatting

> Django does not have a built in JSON HTTP response, so you are going to have to either man up and roll your own (good luck)

Am I missing something? What's wrong with:

   return HttpResponse(json.dumps(data), mimetype='application/json')

Wrap it up in a convenience function and you're done.

The JSONResponse class suggested automatically implements JSONP, which is extremely dangerous. Consider a view on /accounts/info which returns some information about the currently logged in user. A malicious site could embed

  <script src="http://example.com/accounts/info?callback=someFunction">

and access the account information of any user logged into your site. JSONP is a technique to bypass the same-origin policy in appropriate cases; don't just blindly apply it everywhere or you're giving up the protection of the policy.

> Use Gunicorn instead of Apache for your webserver

This is strange advice; while you can use gunicorn as a front-facing webserver, the gunicorn docs strongly recommend against doing so. In a typical deployment scenario, then, gunicorn and Apache would occupy different levels of your stack, with one running your WSGI app and the other exposing it to the world. The advice ought probably to be "Use gunicorn+nginx instead of Apache+mod_wsgi," and indeed, lots of people do make that recommendation about Django deployment.

1. package your python code as a sdist (except setuptools is too hairy so nevermind), keep your deployment scripts & configs in a separate repo or orphan branch

3. use nginx to reverse-proxy WSGI to Gunicorn over a unix socket

6. don't have per-environment config in your app, use the same config in all environments and configure each host with aliases/proxies to consume the appropriate resources (use local_settings.py for local development on your workstation & exclude it from your package)

7. use native operating system service management (systemd, upstart, launchd)

10. use munin if your app can withstand a CPU spike every 5 minutes, use ganglia/graphite/collectd otherwise

Solid list! For most of those bullets I definitely had the 'Oh wow, should have done this sooner' moments. I'd add:

- use South (right away!)

- Class Based Views

- (not django specific) use virtualenvs!

I wish there was something like this for rails - well written, concise and keeps the newbies away from things that'll hurt them. In particular, some major pain points:

1. Use rbenv or rvm. Half the problems I notice with beginners stem from installing rails with apt-get or something.

2. Your controller is meant to be simple glue between model and view - if you're putting tons of code in there, you're doing it wrong.

3. Unit test. A lot. This is especially good for beginners because you often make little errors when you're starting out.

4. Unit testing isn't enough. Functional testing is important too.

5. Learn about your hosting provider. Specific to Heroku, if you're on the free plan, every dyno spin-up takes absolutely forever if you don't have a steady stream of visitors.

Watch out for these Celery gotchas:

1. Tracking tasks status in SQL will result in a lot of queries! (Even when using Redis/RabbitMQ as brokers.)

2. Crontab style tasks are great... until they take a long time to complete and Celery kills them. And then you're back to regular crons (and there is nothing wrong with that).

3. Use UTC everywhere! New projects get this by default, but don't make this mistake.

This is indeed a solid list.

The most comprehensive best-practices resource of Django I've come across by far is "Two Scoops of Django"[1] by "pydanny"[2]. Its absolutely worth the $17.

[1]: https://django.2scoops.org/ [2]: http://pydanny.com/

An item I'd like to add to Python development in general is to use virtualenv. If you're doing multiple Django projects this is a must have.

One of those tools that you start off thinking isn't useful but quickly turns into a must have.

> Use Gunicorn instead of Apache for your webserver [...] This assumes NGINX is managing all incoming requests and serving static content.

Why not just go nginx + django the usgi way? Now you have friendly tutorials and docs for this like https://uwsgi.readthedocs.org/en/latest/tutorials/Django_and... . Maybe I'm weird or I've never worked on large enough apps, but I fail to get what the shiny unicorn and gunicorn bring useful tot the table...

> 10gen has added the aggregation framework, full-text search, collection-level locking, etc.

Mongo has collection-level locking? I thought there was some preliminary work to support it in 2.2 (It just does database-level locking for now), but it's still unsupported. Source: https://jira.mongodb.org/browse/SERVER-1240

Also, I wouldn't recommend using any of the aggregation stuff unless its for infrequent ad-hoc stuff or scheduled tasks during slow periods.

I don't see a monitoring system there? Something like Supervisor is great, but who watches the watcher? I prefer Nagios, but that's just because I'm used to it. Even it is better than nothing.

If you want something a bit more distributed (read less prone to single points of failure) than Supervisor, check out pacemaker. Very powerful and useful for keeping resources alive in any sized cluster.

Don't use celery use: https://github.com/binarydud/pyres

This may sound strange, but when I first started doing python stuff with Django, I spent WAY too long trying to figure out the best project directory layout. To me, Django should generate a "pretty-good" directory layout, much like `rails new`.

My supreme thanks to the author for writing this and to all those who have submitted additional items to the list in the comments here. I'm writing my first few Django apps in series and have found this bits of advice to be very valuable.

I haven't used Jammit before, but I highly recommend checking out django-pipeline for the same purpose: https://github.com/cyberdelia/django-pipeline

your django app doesn't look like a django app.

the basic premise of the django defaults is that app modules are pluggable and self-contained. all of the static assets, templates, model code, view code, migration files, management commands, etc. related to a particular app should go in that app's folder (which is treated as a Python module with its own __init__.py file). conventionally the app's folder is a first child descendant of the top level project directory (i.e. its in the same directory as manage.py)

The main thing I wish I had known is that the ORM is rather limited (or, at any rate, it was too limited for my app), and while you can use raw SQL, it won't let you get model objects out of your own queries, which makes it impossible to integrate with the rest of your app that uses the ORM [1]. The first thing I'd do if I had to use Django again would be to eschew its ORM and use SQLAlchemy instead.

[1] This was a few versions of Django ago; if they fixed this since then, I welcome corrections.

Thing #1 for me, by a long shot:

Deploy to Heroku (or similar). Saves a ton of headaches, saves boatloads of time/money, and for most startups in the early stages, is well worth the tradeoff.

I decided to dive into bootstrap.py/buildout for my current project. So far, it has done a reasonable job of keeping the directory structure clean as well as keeping dependencies under control. The nice thing is that there are recipes for most important things, and adding other new recipes (oh, I need to install and have access to coffeescript) are very straightforward.

I see it as a build step before fabric or puppet would take the output and deploy it.

This list is somewhat dependent on the size and complexity of the project. For a small or simple project, many of these points might not matter.

For example, if Apache can handle your traffic just fine, why spend time replacing it with gunicorn? Or if you never really migrate your database ever, why waste time fiddling with South?

Just a gentle reminder to take into consideration the present and future needs of your project to avoid needlessly adding complexity to it.

I like the ideas on directory structure. I've been working in Flask and I spent way too much time thinking about my directory structure.

I had to double check the title because I thought he said Django and all the advice seemed to match my Rails experience and not my Django one, also, this may be a bit nitpicky, but Django isn't really an MVC Framework nor is it a CMS. You can only really call it a web framework as it has elements of these items but isn't the same:

1. The right directory structure, the default use for the media folder is supposed to be using for stuff uploaded through your app, not the files you develop, your static files should go in static and your compressed files should go in media as they are dynamically generated or in your global "static" folder that is pointed to from your web server. You should also have different settings.py files on a per-situation basis. Your development servers, staging, and production environments will probably all have different settings because at the very least development will have `DEBUG = True` and production `DEBUG = False`.

2. This is fine even though it seems wonky to use it for cron jobs to me.

3. This is fine too but I personally use nginx+uwsgi w/ emperor mode.

4. Up to you on this one, there are some nice Django branches that support key-value store databases but don't use the standard Django with key-value databases because it is 100% built around RDBMS.

5. Only piece of advice I agree with completely.

6. As partially discussed in #1 by me. I don't like his override method. I think an import of a base settings into production.py and development.py is cleaner.

7. Supervisor is good here but also if you use uwsgi in emperor mode instead of the suggested gunicorn it can handle the same task saving you an extra install and configuration.

8. Django very clearly has a nice Mixin for JSON responses in the docs or you can build a nice easy API using Tastypie: https://docs.djangoproject.com/en/1.5/topics/class-based-vie...

9. It's up to you if you want to use Redis, I don't personally need it for all the suggested things and I like how well memcached works with Django out of the box for caching.

10. Munin is great! I'm often too lazy to set it up and am fine reading log files.

11. This drove me to write this long comment... I actually get really annoyed when people try to mix in items from other stacks when there are many solid solutions already that don't force you to install another entire stack. Django has django_compressor which works great in this situation (https://github.com/jezdez/django_compressor) and a quick Google search will find many other similar solutions that won't require you to install Ruby to work with your Python web app.

Source: 6 years of developing Django apps and doing everything that was suggested here and more.

Just want to point out that MongoDB doesn't have full text search perse, but it can do nested array indexes... If you want stubbing/phoneticization you need to do it as part of your input, and part of your search logic... if you front your queries with a service then it is easy enough to do.

I tried various asset management tools but prefer having grunt manage all frontend related things. Node projects seem to be better tailored for this. Especially stuff like linting and watching for code changes, plus having a js based config file for people that don't speak python.

nginx with uwsgi is also an excellent alternative imho

using a settings module, requirements directory and environmental variables makes alot of sense (outlined in two scoops of django at https://django.2scoops.org/, a good book)

"Use named URLs, reverse, and the url template tag": For Javascript URL handling use sth. like that https://github.com/version2/django-js-reverse

That is an impressively long lost of tools to pick up and get running professionally on top of being a web newbie. Hat tip to that man.

solid list, I would also add that it is extremely useful (I would argue necessary) to use vagrant (http://www.vagrantup.com/) to manage your development environment.

Why does this page break "space" for paging down (in Firefox 20.0.1, Windows 7)?

Replace all comments with: Use web2py instead of django

Is mongodb a good choice for CRUD apps also?

off-topic, this _Medium_ platform seems to mangle all outgoing urls…