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.
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!).
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 book.
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
mixins.
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.
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.
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 optimization/fixing/profiling.
“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
logger.exception().
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.
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.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):
