Two scoops of Django book review¶

Tags: django

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.

Virtualenv

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 :-)

Apps

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.

Settings

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.

Models

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.

Views

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.

Forms

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 :-)

REST

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.

Templates

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.

Admin

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.

Testing

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

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 optimization/fixing/profiling.

Security

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

Logging

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

Django utils

A handy list of utils that Django already provides such as sluggify, strip_tags and so.

Deployment

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.