sane-default boilerplate to avoid repeating yourself each time you start on a new Django project.
Django comes with a lot of batteries included, but it takes some time
to set them up. And usually, the initial few steps are always the same.
We can refactor these into a boilerplate empty Django project, and use
it as a base for new projects, instead of starting from scratch each
time.
That’s what I did with DJ Skeletor. It’s an empty, relocatable (ie. uses no hardcoded paths) Django project, set up to my liking and with a few Django apps that I use in virtually all projects (impatient? jump directly to the examples).
There are several ways to handle this in Django. I prefer the following:
The app usually defines a white-list of client IPs for which to be shown. As I’m not on a static IP, I find it more useful to have the toolbar show all the time when in development environment, and never when in production.
Besides logging the exceptions, Sentry can also catch normal logs you create with Python’s
DJ Skeletor is open source and is available on GitHub. Feel free to use it or base your own boilerplate on it – if you do, please share your thoughts in the comments.
If you need a clean, well designed (but definitely not unique or artistic) user interface for your HTML app, I heartily recommend Bootstrap, created and open sourced by the fine folks at Twitter.
If you do need to make a proper, unique design, again no need to start from zero: use HTML5 boilerplate which takes care of a myriad little gotchas for you; and there’s a mobile option as well.
from http://senko.net/en/django-quickstart-skeleton-project/
That’s what I did with DJ Skeletor. It’s an empty, relocatable (ie. uses no hardcoded paths) Django project, set up to my liking and with a few Django apps that I use in virtually all projects (impatient? jump directly to the examples).
Django settings
Default Django settings organisation is rather simplistic – it’s just one file. But as soon as you deploy the project to somewhere else than the computer you’re writing it on, you’re going to have at least two sets of settings: development and production.There are several ways to handle this in Django. I prefer the following:
- Settings module is split into several submodules and lives in
settings/
directory. - Settings that are the same for both development and production live in
settings.base
module. - Development-specific settings are provided by
settings/dev.py
, and production-specific settings are insettings/prod.py
; a symbolic linksettings/local.py
points to the one that should be used in a specific environment. - The
settings
module importssettings.base
andsettings.local
Database
A test SQLite database is set up for the development environment. The database file is configured to betest.db
in the project root by default.South
South is an awesome Django app for handling database schema migrations (ie. table/field changes when you modify your models). If you’re using a database with Django, you want to use South as well.Django Debug Toolbar
Django Debug Toolbar is very handy for inspecting what happens when you request a page from Django. It lists things such as SQL queries executed (including how long did they take and why they were executed), signals, logging, exception, request params, etc. I use it all the time for finding and fixing suboptimal database queries.The app usually defines a white-list of client IPs for which to be shown. As I’m not on a static IP, I find it more useful to have the toolbar show all the time when in development environment, and never when in production.
Sentry
Sentry helps with exception logging and viewing for your Django project. It can handle multiple Django installs where the logs can be managed from a single place, or it can be used on a per-project basis. The latter is how it’s preconfigured in DJ Skeletor.Besides logging the exceptions, Sentry can also catch normal logs you create with Python’s
logging
system. This is also preconfigured in DJ Skeletor.Example
Enough talk, let’s see some action. First, we’ll create a virtual environment (you do use virtualenv, right? if not, you should) and install prerequisite packages: virtualenv --no-site-packages myenv
cd myenv
source bin/activate
pip install django django-debug-toolbar south django-sentry
Next, we’ll clone the boilerplate project: git clone https://github.com/senko/dj-skeletor.git myproject
cd myproject
Let’s activate the development environment and prepare the database: cd settings
ln -s dev.py local.py
cd ..
python manage.py syncdb
python manage.py migrate sentry
All done, let’s run it! python manage.py runserver
See? Piece of cake. With boring initial set-up out of our way, we can focus on building an awesome web site or app.DJ Skeletor is open source and is available on GitHub. Feel free to use it or base your own boilerplate on it – if you do, please share your thoughts in the comments.
Bonus: HTML boilerplate
If you’re a programmer and couldn’t design if your life depended on it, it’s useful to have the user interface boilerplate handy as well.If you need a clean, well designed (but definitely not unique or artistic) user interface for your HTML app, I heartily recommend Bootstrap, created and open sourced by the fine folks at Twitter.
If you do need to make a proper, unique design, again no need to start from zero: use HTML5 boilerplate which takes care of a myriad little gotchas for you; and there’s a mobile option as well.
from http://senko.net/en/django-quickstart-skeleton-project/