The Django web framework’s versatility is sometimes used for evil, and this is sometimes grounds for, in the words of The Simpsons Jasper Beardly, “… a paddlin’”.
1. Using sqlite in production. That’s a paddlin’.
This is because it is a f*cking pain to do database migrations with, as South’s ability to recover from failed migrations is hamstrung by lack of DDL support. Use Postgresql or MySQL (maybe MariaDB?).
2. Ignoring STATIC_URL and using MEDIA_URL for everything. That’s a paddlin’.
Static media is for your css/js and site wide image files. They (hopefully) don’t change too often and for the most part they get cached downstream. User Media is what gets uploaded to the site in fulfilment of some function that your site provides. It might be user profile pictures, or pdf files, or whatever file your users may be providing. Mixing the two and only using MEDIA_URL for everything provides headaches because:
- You can’t use the collectstatic command to move your files into place when updating in production (this includes getting static files from your applications). You’ll have to make your own command, or do it manually.
- Separating user files and static files will make any downstream caching easier (e.g. telling Cloudflare to cache/not cache a particular url pattern). Otherwise your user media is going to be getting cached across the interwebs.
- If you ever put a delete_file() method in place somewhere and something goes wrong, say farewell to site.css.
And symlinking around Django’s inbuilt protection - oh you best believe that’s a paddlin’.
3. Using flatpages for everything
Using flatpages for everything means:
- Much more difficult to get context onto a page (hello custom template tags).
- You can’t version control page changes, as it’s all held in your database.
- All edits need to be made via django admin… in production (unless of course you want to make local edits and perform an export/import dance).
- The 404 fallback middleware seems like a longwinded method of producing a page
I would prefer that no one uses flatpages, but can see their use in giving clients a rich text editor in the admin that also updates a page.
4. Doing major point Django upgrades without reading the changelog.
No established projects should need to “upgrade” their version of Django, and for most projects you can’t just change the major point release of your Django installation by simply running “pip install -U django”. Without changes to align with the new Django api your project will break.
5. Not upgrading for minor point releases
Whilst major points upgrades should be considered carefully before being undertaken, minor point releases should be basically be done as a matter of policy. None of the Django API will change, and potentially site threatening bugs will be addressed. Not upgrading, especially for security releases, is bad for you and your customers.
6. Starting new projects using Apache and mod_wsgi.
No longer is Apache and mod_wsgi the recommended way of deploying your project. Projects like Gunicorn and uWSGI are simpler to integrate with virtual environments and are cheaper in both memory and cpu.
7. Not using virtualenv
Virtual environments are now considered to be such an integral part of Python that they are included in the standard library . They make dependency management and multiple site deployment much easier.
8. Not using version control and/or editing the site live in production
You will make a mistake one day, your site will break and you will be unable to pinpoint what caused it. Then you will call me, and I won’t be angry, just disappointed.
Without version control it will be very difficult to get back to a working version of your site, and if this happen in production then your failure (both initial damage, and inability to fix it) will be getting broadcast to the world.
9. Other web development paddlin’s
- Loading 5 versions of jquery (all overwriting each other). You only need one version, probably in the 1.9 series.
- Loading all of bootstraps css for the single form that you use bootstrap styling on. Download the less and only compile the modules that you need.
- Table based layouts. Seriously?
- Letting Django serve your static media
- Writing blog posts when you have real work to do.
And finally: all hail The Simpsons for this meme.