Two scoops of Django book review
I took the train from Utrecht (NL) to Warsaw today. I only had to change in
Amersfoort (NL) and Berlin (DE), so it was a pretty direct connection. 12
hours of train time (which I enjoy). So that’s enough time to read through
two scoops of Django, the Django book by
Daniel Greenfeld and Audrey Roy! Here’s my review.
The summary: buy the book and learn a lot. For the longer version, I’ll
simply go though my notes I made for each chapter.
- Coding style
- The book starts off good, in my opinion, because it tells you to write good
and neat code. PEP8. Good not-too-short variable names. And it got me
thinking by advocating explicit relative imports (“from .models import
SomeModel”). That’s what’s good about this book: Daniel and Audrey
state preferences and tell you best practices and sometimes those best
practices won’t be your best practices. Or you didn’t know
something. Anyway, it gets you thinking; which is good and enjoyable.
- Hey, virtualenv in chapter two! Nice. Here, like in the rest of the book,
I noticed they point a lot at existing documentation and don’t provide
much explanation. No virtualenv explanation here, for instance, just a
pointer to the
official docs. It is not necessarily bad, probably even good, but it is
something to keep in mind. You’ll have to do some work yourself (which
will make you retain the knowledge you gain better anyway!).
- Project layout
- I got tickled here. Directories three levels deep? Especially having urls
and settings in a subdirectory within a directory with the very same name
(the name of the project)?
Two chapters later, the settings seem to be moved to a settings/
directory, so mayhap I looked at an older beta version of the book :-)
- The gospel that a Django application should do one thing only is repeated
here, which is a very, very good thing. I completely agree. Advice like
this is what makes it a good book. You get a good mindset out of the
- The idea to have a directory settings/ with a base.py and then
production.py, dev.py, reinout_dev.py and so looks OK.
I use a different setup and this proposed one looks better. Half the chapter
is about enviroment variables as a means of keeping things like
SECRET_KEY and database passwords out of the settings. Yep, that can
work. My opinion is that you can also keep it in the settings, provided
you keep your code non-public. If you use environment settings, you still
need to store the data somewhere. You won’t type it in by hand, will you?
There’s no real suggestion in the chapter to solve this, though the
solution of course depends on your chosen setup (and there are too many
different kinds of setups to provide a single right answer). Nice touch is
the clean suggested ImproperlyConfigured error when a enviroment
variable is missing, this shows the care that went into the book.
- Hey, I learned something new! I didn’t know about auto_now and
auto_now_add on DateTimeFields! That’s what I read books like this
for: getting hints like this.
- Reminder for myself that I took out of these chapters: put less code in
views.py. And I ought to look at django-braces for handy Class Based View
- Hm. I probably ought to use forms much more. Especially for those spots in
my code where I just take two or three variables directly from the GET
or POST and stuff it in some query... Why not use a small form, just
for the form validation? Much safer that way and I’d use more of what
Django gives me! Again something in the book that educates me :-)
- It took me a while to spot the difference between the two views that are
shown at the start. It turns out that one is a view on the collection of
items and the other a view on one single item. The first has list+add, the
second view+edit+delete. The names just don’t make it clear. I think this
chapter is a bit too short. On the other hand, perhaps one extra paragraph and
two better class names would be enough.
- Flat is better than nested. Solid advice not to go overboard with blocks
and template inheritance. Oh, and TEMPLATE_STRING_IF_INVALID is
handier than I thought for template debugging as you can add a %s to
the string, which shows you the failed expression. This tip is going to
help a lot.
- They say that the admin should only be used for site admins, not for end
users. It is just as easy and probably better to make a couple of quick
edit pages or dashboards for your customers.
- Third-party apps
- There are lots of apps you can use. Look at http://djangopackages.com. Did
you know it was written by the same people that wrote this book? Now you
know why you should read the book.
- Most of my favourite/essential packages are mentioned: coverage.py,
factory_boy, mock. And the tip to zap the tests.py file and replace it
with a tests/ subdirectory full of test files is correct.
- Documentation is mandatory. Even when installation is done with a fabfile
or with chef, tell it anyway in the installation docs. And describe what
the goal of the app is. Etc. Documentation is mandatory.
- Performance tuning
- Debug toolbar: yes. Hey, but I didn’t know yet about django-cache-panel to
see what happens in the cache. Sounds handy. This chapter also whacks me
on the fingers a bit as I have almost done nothing with sql/db level
- “Always use https”. And lots of other good tips. And, for me, the reminder
to use forms (or rather, form validation) more for better security.
- Good that the book mentions logger.exception('Something went wrong'),
as it logs the message at ERROR level and automatically includes the
traceback. No more weird exc_info-like stuff, just
- Django utils
- A handy list of utils that Django already provides such as sluggify,
strip_tags and so.
- Gunicorn and mod_wsgi. Personally, I’m happy with gunicorn (when run
behind supervisord). Nice isolation. Nice mostly-transparent restarts
when things barf.
- Getting help
- Good thing: they tell you to do your homework before asking for help in
the usual channels. Very good.
I’ve got one big gripe with the book. There’s probably a good reason for the
omission, but I’m missing setup.py. Telling to use a certain
requirements.txt in some README is a poor substitute for Python’s
automatic dependency handling. This is not only good for apps you want to put
on PYPI, but also for your own packages.
All in all: valuable book, buy it!
Daniel and Audrey are at Djangocon in Warsaw, so if you’re there say them “hi”
to thank them for the book.