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

https://medium.com/cs-math/f29f6080c131

by misiti3780 • 13 years ago

378 154 13 years ago

medium.com

famousactress3• 13 years ago

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!

apendleton2• 13 years ago

The article recommends using MongoDB as a primary data store, so South wouldn't be applicable (and that's specifically addressed).

conesus2• 13 years ago

Actually, I use South to manage data migrations (as opposed to schema migrations) in MongoDB. That way I can ensure that I've run the same data migrations on all of my dev and prod databases. Just a `./manage.py migrate` and every developer is caught up.

mrtron• 13 years ago

Am I the only one left who finds south more trouble than it is worth?

misiti378010• 13 years ago

i think it is the best solution out there right now ... someone had a kickstarter recently to replace it, but I can't seem to find that info via google right now ...

akarambir2• 13 years ago

When I started using South, I was much in awe and loved its ease. But as time passed migrations became completed and south soon came to its knees.

dbla2• 13 years ago

I'm working on a tool for better schema migrations as well. Currently it only supports MySQL but more RDBMS's coming soon: http://devjoist.com

famousactress3• 13 years ago

The only one? No, I'm sure not. In the vast minority? I'd suspect so :)

South is pretty obtuse to learn and definitely has it's warts and issues, which Andrew seems well aware of and wants to fix so check out the kickstarter link below!

That said, our project has over three hundred tables, a couple thousand migrations, and I've been very happy with it compared to the systems I've rolled myself in the past. I'm certainly unaware of an alternative that holds a candle to it, assuming Django's ORM.

pico3032• 13 years ago

I came to Django & South after using ActiveRecord and Rails migrations for years, and it drove me nuts. Not trying to cause a big argument, but why the big push in the Python community to model database tables via object properties/fields? I seem to recall SqlAlchemy does something similar.

tocomment• 13 years ago

I totally agree with you. I just export the SQL and see what tables need to change.

metaphorm3• 13 years ago

South can be troublesome, but what's your alternative? never make changes to your schema? do it painstakingly by hand from the psql command line? just suck it up and use South, warts and all. its still really good, even though its not perfect.

tomlu2• 13 years ago

Maybe if you're working on your own. If you're in a team (where each member has her own local DB) and multiple environments for testing, staging, preproduction etc. I'd say you're going to want some sort of scripted migration.

kingrolo• 13 years ago

My workflow is to only add south to the project when required. To begin with I use a bash script which trashes and rebuilds the DB each time I wish to. Data which needs to survive this gets dumped to fixtures (using another bash script).

archivator2• 13 years ago

Are class based views really any good for anything outside of CRUD? I've found the documentation (and, more importantly, rationale) lacking. Generally, when I try and use them, I spend more time figuring out how to customise than when I write "normal" views.

famousactress3• 13 years ago

I should be specific. I never use the built in Django views. I'm sure they're great but I don't like that much magic and I moved to class based views later in a project.. those seems easier in a clean-room build.

I do, however use class based views that I've built myself. We extend them and add mixins and I much prefer all of this to the decorator soup that is the alternative.

tomlu2• 13 years ago

I don't know about class based views - each time I've tried to use them they've started out nice and convenient then slowly turned into an over-engineered mess as my requirements got more complicated. I think I prefer the control and simplicity of function-based views even if there's a bit more duplication.

apendleton2• 13 years ago

> 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.

misiti378010• 13 years ago

sorry - i did forget to mention nginx should be in front of everything managing all requests + serving static content.

misiti378010• 13 years ago

updated article

antihero• 13 years ago

nginx+uWSGI emperor mode is such a nice setup.

tinco• 13 years ago

Did you ever try using Passenger (nginx) to run your WSGI app instead of Gunicorn+nginx? Seems like it would be even less of a hassle to run.

(I work at Phusion, and am not a Django guy, just curious)

misiti378010• 13 years ago

if this question was for the author, my answer is no.

falsedan2• 13 years ago

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

glenjamin• 13 years ago

I have to disagree strongly with your point 6.

I'm working on a large app at the moment where all hostnames are the same regardless of environment, and the only way to switch envs is via a proxy. It's a massive pain.

Keep environments mostly similar, but always make sure you can configure locations of the app itself and its various external resources separately on staging, test and development platforms.

falsedan2• 13 years ago

> I'm working on a large app at the moment where all hostnames are the same regardless of environment, and the only way to switch envs is via a proxy. It's a massive pain.

One of our projects works like this, it sucks.

For per-host app location, we set X-HTTP-Script-Name in the nginx location block and extracted it in WSGI middleware like http://flask.pocoo.org/snippets/35/

Everything else is hardcoded to use 'http://localhost/service_name/foo & nginx proxies to the appropriate resource. Obviously, this doesn't work for non-HTTP services!

hcarvalhoalves4• 13 years ago

> 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

This. I'm tired of Django projects not being packaged/released correctly, and deploy scripts that simply git clone in production (yiikes).

hoov2• 13 years ago

I'd take it one step further. Why do they have to be packaged as sdists at all? Why not bdist_egg?

subleq2• 13 years ago

Could you go into some more detail about what being 'packaged correctly' means? What's wrong with a git clone deployment, why is deploying as a package better, and how does one implement it correctly?

taude2• 13 years ago

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.

Luyt• 13 years ago

You're also using Flask? I wrote a short piece about roughly the same subject as the author of the original article uses for Django. Running Flask behind gunicorn and nginx, monitored by supervisord:

http://www.michielovertoom.com/freebsd/flask-gunicorn-nginx-...

taude2• 13 years ago

Yes, using Flask. I need to write why we chose it over Django....but mostly becasue we're using Mongo and once you're down the path of not using the Django ORM, what's the point? Also, it seems like there's dozens of articles on "how to structure" your large Django projects, so you don't even get good guidance about it out of the box.

I'm running mine under NGINX->uWSGI....but might be switching to Gunicorn. (I'm still researching our path to production).

spamizbad• 13 years ago

> 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.

conesus2• 13 years ago

I use aggregation queries regularly and it's amazing. My MongoDB database has 4k ops/sec and I run an aggregation query to count averages, sums, and splits on a name (to get averages and sums for each of two dozen groups) for about 10K rows every 5 minutes. Not a huge amount, but this is on a db that is performing a ton of work. Also, I should mention that you should probably run your aggregation queries on your secondaries.

misiti378010• 13 years ago

i agree - the aggregation framework seems solid - much better performance than map-reduce

pvnick• 13 years ago

You're right, it doesn't yet support collection-level locking (https://jira.mongodb.org/browse/SERVER-1240).

dangoldin• 13 years ago

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.

dshap3• 13 years ago

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

Bockit3• 13 years ago

Specifically for me, pipeline fits into django's collectstatic way of doing things. And because of this it works fantastically with django-storages as well. My projects are set up so that `python manage.py collectstatic` trawls all my apps static folders, compiles everything if required (r.js, sass) and uploads any changes to an S3 bucket. And in development it compiles over the wire (except r.js, we let requirejs do the async loading thing in development).

dshap3• 13 years ago

Ditto regarding everything up until your last sentence - it is a pretty great setup.

What do you mean it "compiles over the wire" in development? In development, pipeline just renders individual js/css tags for each of your static files, un-compiled...

coolsunglasses2• 13 years ago

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

mcintyre1994• 13 years ago

I've been expecting to use Celery in a project I'm working on, could you explain why?

coolsunglasses2• 13 years ago

Celery is a PITA and over-complicated for the problem it solves.

hobb0001• 13 years ago

Celery is brittle. If you stop a celery service, odds are, it will either not stop at all or leave stray child processes running.

It is not transactional, at least not with a MongoDB back-end. If you stop a celery service, any tasks that were in progress may or may not complete, but none of them will be picked up again when you resume.

No prioritization of queues or tasks. It is possible to set up separate services that handle different queues, but that's a PITA and there's still no guaranteed order of processing.

the_cat_kittles3• 13 years ago

considering the infrastructure that has built up around celery and particularly its use with django, i dont know why you wouldn't- care to explain?

dbarlett• 13 years ago

Pinterest replaced Celery and RabbitMQ [1] with their fork of pyres [2], presumably because it's 1/100th the codebase but does what they need to.

[1] http://highscalability.com/blog/2013/4/15/scaling-pinterest-...

[2] https://github.com/pinterest/pyres

fduran• 13 years ago

nginx with uwsgi is also an excellent alternative imho

pindi2• 13 years ago

> 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.

the_cat_kittles3• 13 years ago

might also be worth noting that django-tastypie is the defacto standard for REST apis, and sends and returns json (among many other serialization formats) very easily. This obviously doesn't work for all ajax cases, but its extremely useful nonetheless.

scott_w• 13 years ago

I would recommend Django Rest Framework. It gives you more fine grained control. We just use the serialisers for example.

lifeisstillgood• 13 years ago

I would guess complex objects - containers, or strange databasey stuff.

The way to deal with is __complex__ as a method on the object and recurse through asking the complex method to return nested simpler python types.

danellis• 13 years ago

__complex__ is for converting to a complex number.

davesque2• 13 years ago

yeah, danellis is right. don't use __complex__ for that. it's for complex numbers:

http://docs.python.org/2/library/functions.html#complex --and-- http://docs.python.org/2/library/cmath.html

peterhunt2• 13 years ago

json.dumps() can be dangerous if used on your raw domain data. You should specify the exact schema being sent down to the client so you don't accidentally leak something (this can happen very easily in Python)

jaegerpicker2• 13 years ago

yep, I build response objects ( my own term, not great but it describes what they are ) that are basic subsets of the object that I want to serialize to json. That way I'm sure only the fields that I really want to send are making it out.

pindi2• 13 years ago

Well, not dangerous so much as will fail with a "Model instance is not JSON serializable" message. So of course you'll need to construct the list/dictionary representation of your data manually. A good framework can help with that, but this isn't something that's solvable in the general case with just a response subclass without risking data leaks as you stated. (The other option in the original post makes this mistake, making both suggested options insecure)

streblo2• 13 years ago

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

Bockit3• 13 years ago

Would you mind expanding on the issues you have with pipeline? I use pipeline at the moment and beyond a couple of small things (mainly working with vendor apps) I'm really happy with it, but I'm open to the idea that it's because of what I don't know than because it solves every problem.

streblo2• 13 years ago

Mostly with setup and configuration. Configuring it to work the way I expected required a lot of digging through documentation/code/blogs/fudging around. I don't like it when I have to do that, for a number of reasons -- a. I'm lazy and I don't like spending a lot of time doing upfront configuration, b. when something doesn't come with sensible defaults pre-configured, I assume I'll do something wrong and it'll have non-obvious but bad consequences.

I had this problem with django-compressor as well (but more with configuring 3rd party asset compilation). I usually recommend people use webassets via django-assets. It's easy to configure and very feature-ful.

elithrar• 13 years ago

> (there still isn't a sprockets-esque one-catch-all solution for django like in the rails world)

This is definitely a little frustrating. I'd kill for a solution that handles minification, versioning & can upload to S3/etc. You can pass things through boto to get to s3, but the rest requires a bit of fiddling.

I've seen a few solutions that come close, but then they have extremely odd versioning systems. I should just fork something so I can add an ISO8601 timestamp to my CSS & JS; which I like because having granular dates helps when debugging front-end issues.

jdunck4• 13 years ago

> I'd kill for a solution

Would you code for one? I, too, am sorry that we don't have a thing like asset pipeline. I'm pretty sure it would be welcome...

kevinastone• 13 years ago

What have you tried? Because staticfiles + django-storages + django-compressor sounds like it can handle that use case.

jdunck4• 13 years ago

Regarding 15 - if you want that behavior, you'd be better off with using your own model subclass:

  class ValidatingModel(Model):
    def save(self, *args, **kwargs):
      self.full_clean()
      super(ValidatingModel, self).save(*args, **kwargs)

Then inherit from that everywhere.

Signals have a not-insignificant overhead. They are most useful for tying together code that comes from different places. (If you want to do full validations on 3rd-party app models, then you might this signal approach, but it might also be a bug in the app that the hook isn't just there for you.)

windexh8er• 13 years ago

I'd maybe also suggest pythonbrew since you win by getting the exact version of Python you want and virtualenv is packaged up nice with it.

emddudley• 13 years ago

> Virtualenvburrito will help you set it all up.

Is it just me, or is it a little absurd to have a wrapper for a wrapper to a Python module?

zwass• 13 years ago

I think the author recognizes that as well, hence the name.

amccloud• 13 years ago

pip freeze has always been horrible for me. I've been better off managing my requirements manually.

Spiritus• 13 years ago

At least managing multiple files is a pain.

I've had to resort to

    $ vimdiff <(pip freeze) requirements/prod.txt

You can't just do "pip freeze > requirements.txt" like you see on every tutorial. I wish there was a better way to do this.

And I would also like to only display without dependencies. Say I "pip install X", which depends on Y and Z as well. Then later I want to delete X, so I just "pip uninstall X", but I will still have Y and Z.

tracker12• 13 years ago

Just responding to #16, it may be best to manage your static/client assets using NodeJS with grunt... It's not in the django chain, but may be worth calling the external. Node seems to be at the leading edge of JS & CSS tooling.

It's worth noting that I'm a pretty big NodeJS fan and am even using grunt via node for building the client bits in my latest .Net project at work. It's pretty sweet, though some addons are broken since the new grunt version.

crucialfelix3• 13 years ago

I've switched to this method as well and recently removed django-compressor. Better to have a tool that is used and improved by many, not just django people.

In the top level of my project I have a makefile so make assets runs grunt and collects static.

My grunt also runs jslint so it will halt if there are errors.

flexterra• 13 years ago

#16 is one of the biggest pains we had to deal with but I think we now have a good solution for now.

We use brunch.io a node.js build tool. It handles concatenation and minification of CoffeeScript, Stylus and Handlebar templates for us but it can work with almost any front end technology out there. A cool thing is that we can use require within out CoffeeScript files and that allows us to better organize code into modules.

Brunch even provides file watching capability so when we save a stylus or CoffeeScript file it will update the browser without a reload.

In our setup we compile everything to our django static folder so when we collectstatic, files get uploaded to s3.

One thing that was a bit a tricky and something that we have to make better is cache expiration of files. For now we are appending static files with a few characters from the current commit hash (app.css?e2232 something like that), while this is pretty effective we've found some cache systems that ignore it. The next step is to rename files before uploading to s3 (app-e2232.css).

I agree that this might be a bit too complicated for most apps but in our case (getblimp.com) we have a pretty heavy JS app and we really need to take advantage of all the "better" front end tools available.

I will be willing to contribute to FOSS project to solve this issues once and for all on the django/python side. BTW I think that file watching is better than compiling on every reload during development. In our experience (many js files) request on the development side took seconds and became very frustrating.

overshard• 13 years ago

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.

xaritas• 13 years ago

The guy who wrote django-compressor fairly recently released a library to address the settings.py problem, django-configurations https://django-configurations.readthedocs.org/en/latest/

It uses classes to define your settings, and you can use inheritance to override and mixins to augment your bits of configuration. I usually have a "CommonSettings" class, with a few others extending it (Production, Development, etc.). At runtime the correct class is set based on an environment variable (you have to add a line or two to manage.py and wsgi.py to start the magic).

Anyway, it doesn't seem that popular but I've enjoyed using it (and done so without problem).

akoumjian• 13 years ago

How is Django not an MVC framework? I'm not being snarky, just curious.

steveklabnik• 13 years ago

MVC means a ton of different things. Django itself does not use "MVC" to describe itself: https://docs.djangoproject.com/en/dev/faq/general/#django-ap...

> If you’re hungry for acronyms, you might say that Django is a “MTV” framework – that is, “model”, “template”, and “view.” That breakdown makes much more sense.

the_cat_kittles3• 13 years ago

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)

metaphorm3• 13 years ago

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)

taylorfausak• 13 years ago

That's true about Django apps, but this post doesn't describe a Django app. It describes a Django project.

mhahn• 13 years ago

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.

misiti378010• 13 years ago

this is actually on my todo list, i saw this video by zac holman a while back:

http://zachholman.com/screencast/vagranception/

and have been meaning to mess around with it ever since

Pxtl• 13 years ago

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.

misiti378010• 13 years ago

~ 2 years and a lot of pinot noir ....

bryanh• 13 years ago

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.

jdunck4• 13 years ago

My recc after a lot of heavy use is: RabbitMQ for the queue, Redis for the result store.

RabbitMQ for the result store is madness.

misiti378010• 13 years ago

why not just use redis for both - just curious ?

derengel• 13 years ago

Is mongodb a good choice for CRUD apps also?

jaegerpicker2• 13 years ago

depends on the actual app use. Simple in and out low traffic crud? It's probably not worth the extra effort. MySQL is still a great product that has and will continue to serve billions of web requests and just cause NoSQL is a new kid on the block doesn't mean that everything should use it.

That said if you are storing data that is really just documents, Mongo or another document db is likely a good choice. For example if you storing interrelated performance measurements (like in a factory setting ) Mongo would likely not be the best choice but say in a setting like an app for applying for a job or registering for events ( natural document data segments ) a document db would work well for modeling the domain I'd think.

neo2001• 13 years ago

It really depends on the nature of you application, but raw speaking... probably you'll regret using mongodb as your primary database at some point.

tuxidomasx• 13 years ago

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.

jvm• 13 years ago

I think he's actually saying gunicorn was simpler than Apache. I've also found that to be true (anecdotaly).

deepakprakash• 13 years ago

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/

pydanny• 13 years ago

Correction: It's not by "pydanny", it's by "pydanny" and "audreyr". She just doesn't do the whole Twitter/HN/blog thing as much as me. Seriously, do you think I could write a section including code that discusses "the impossible condition of too much chocolate". ;-)

Seriously, between the two of us she's the better coder, taught me LaTeX, and knows Strunk and White. I just write what I think and let the grammar experts fix it. :P

shavenwarthog2• 13 years ago

Seconded. My investment in "Two Scoops of Django" has repaid itself many, many times over. Concrete "best practices" book.

scottrb• 13 years ago

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.

falcolas• 13 years ago

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.

dhaivatpandya• 13 years ago

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.

wikiburner• 13 years ago

I'm somewhat new to Django, and I'm just curious if Heroku is the best solution out there for Django? I've heard some good things about Gondor, and apparently it's more tailored for Django apps, but I'd be curious to know what the HN consensus is on Django hosting that won't collapse on you if you get HNed/Reddited.

jordanmessina• 13 years ago

> 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.

Yes, fat models are the way to go. This is just a good rule of thumb for any MVC framework. I feel like no framework docs actually explain this. Newbies end up shooting themselves in the foot because they don't understand the reason for separation or understand where logic should be implemented.

mercurial2• 13 years ago

That's very debatable, and pretty rails-specific, IMHO. Conventional wisdom in other ecosystems is instead to have a business logic layer between your controller and your persistence layer. I've always found this to be good advice, as it makes the code more testable and makes reasoning about manipulating different models in the same operation easier.

Iterated• 13 years ago

I started reading about Django recently so this is a noob question, but what's the controller in Django? All I've seen with with a lot of code is models, views, and templates. It's kind of annoying how tutorials talk about MVC but it doesn't seem like an MVC framework.

Also, if I want a user to input numbers to do calculations, where does the computationally heavy code go?

edavis2• 13 years ago

Django is close to an MVC framework but not exactly an MVC framework. This link (https://docs.djangoproject.com/en/1.5/faq/general/#django-ap...) describes the difference better than I ever could.

davesque2• 13 years ago

For most intents and purpose, "controllers" from so called MVC frameworks are referred to as "views" in Django.

The article that edavis mentions does make one good point, which is that the term "view" was chosen to emphasize the notion that the python callback function (or object) sets up a view of the data represented by the models. I think there's something good in this choice of words. I find the terms "view" and "template" more intuitively meaningful than the corresponding "controller" and "view".

One important, substantive difference that I'm aware of between controllers in many MVC frameworks (probably not all) and views in Django is that a lot of MVC frameworks map requests to controller actions through URL traversal, whereas Django offers a more hands-on approach with URL confs.

Also, whereas controllers are often implemented through classes in MVC frameworks, views in Django may be implemented through any callable object which accepts a request and returns a response.

As far as where your code should go, it probably depends on what kind of data the user is entering. If the data must be persisted in the database somehow, such as with transactions in a bank account, then the code that crunches the numbers would probably be in a method on a "BankAccount" or "Transaction" model class. If it's data that only really needs to persist for the user's individual browsing session, then it's probably safe to put the code that works on it in a view. Django limits what kinds of things you can do in its templates (thankfully), so you probably won't have much luck putting your computation code in a template.

Camillo2• 13 years ago

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.

edavis2• 13 years ago

Not sure when it was added, but is this what you were after? https://docs.djangoproject.com/en/1.5/topics/db/sql/#perform...

Camillo2• 13 years ago

Yes, that looks like it should do the job. Thanks!

SoftwareMaven• 13 years ago

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.

crucialfelix3• 13 years ago

I've used buildout for years but I'm now moving away from it. I've enjoyed it though, and I wouldn't recommend against it.

Several issues:

the buildout process is long and monolithic and not conducive to minor adjustments. I'm using ansible now and its much better for just changing one setting on an nginx config file or settings file and reloading. I chatted with the author of buildout and he said he was building to an rpm and then mounting that as his means to do a live deploy.

I often wished I had virtualenv, so many things work well with it. for instance python-vim and sublime lint / rope like to have a virtualenv to get the python paths. also ctags is happier if I can just enter the virtualenv and run it.

there may be a recipe for that but I never found one that worked nicely.

tracker12• 13 years ago

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.

mathias_10gen• 13 years ago

Actually, as of 2.4 there is an experimental text search feature built-in: http://docs.mongodb.org/manual/core/text-search/. While it is no Lucene (and is still considered experimental) it does provide simple tokenizing, stop-words and stemming.

schrijver• 13 years ago

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

nnq• 13 years ago

> 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...

edanm• 13 years ago

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.

unwind• 13 years ago

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

boerni1234• 13 years ago

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

smogzer• 13 years ago

Replace all comments with: Use web2py instead of django

domrdy• 13 years ago

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.

Judson• 13 years ago

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`.

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

Related Stories