Dutch Django meeting in Amsterdam, part one¶

Books I read and liked: recommendations - Wim Feijen¶

Just some good books. Too many to list in a summary :-)

Either “the big moo” or “purple cow” by Seth Godin. Just read one of ‘em.

No bullshit guide to management.

Eckart’s notes: real nice, read it when interesting about expanding but staying small.

Four hour work week by Ferriss. Ignore lots of things. Become an expert. Don’t answer the phone but design a system that deals with it. Best explanation available of the pareto principle available.

Getting real.

Inmates are running the asylum.

New venture, starting up: about writing business plans.

Code complete.

Principles of beautiful web design. Wonderful for designers.

Homepage usability by Nielsen.

Integrating XHTML validation with unit tests - Erik Romijn¶

Tag soup is normally inconsistently parsed. All sorts of problems if your html isn’t valid. You are going to forget to validate and re-validate your pages once in a while.

So integrate it in your unit tests! xhtml is proper xml and it has a DTD, so you can validate it automatically.

How? Download the DTD and hook it up in your tests with etree.DTD and friends and test every view. If you have an error, you’ll get an XMLSyntaxError out of your testcases right away!

Throw away Flatpages, meet Fiber - Dennis Bunskoek¶

They needed something CMS-like, but didn’t find something that was easy enough. In the end they made one themselves that provides files, pages, images, etc. They did reuse existing apps (or they integrated parts of them, I wasn’t sure).

It complements a project, it doesn’t take it over. Simple menus, front-end editing, simple textual text-based templates. Front-end editing especially is essential to make the site easy for their clients.

Real nice: you have a list of existing content on the left hand side that you can drag into placeholders on the page. For instance dragging your standard company address somewhere.

Note to self: try it out! It might be easier to integrate with our existing sites than django-cms, which we’re using now. It will be released later this month.

Bugfixes and Beyond - Jannis Leidel¶

Django 1.3 was supposed to be just a bugfix release. They’re still trying to convince everyone that it is a bugfix release. But really nice feature requests crept in anyway. But no mayor changes like full nosql support, for instance.

There are a lot of changes. 1330 changed files, for instance. Way more than in previous releases, which means that a lot of cleanup went on under the hood. Good work.

Some highlights that Jannis appreciates most:

Class based views. This one went through lots of iterations. Views as classes instead of “just” functions will really change what developers see as a view. Moving from functions to classes will help Django move to a better style of views. The currently used function-style look more like MVC controllers than classic MVC views, actually.

Classes come with the full glory of object oriented programming. One Django-related snag was the urls.py. You have to watch out with passing a class into your url conf: is it a class? Is it an instantiation? It is supposed to be a callable, technically. So they enforce a ClassName.as_view() syntax which solves it.

They moved lots of generic views to class based views. One of the advantages: you can mix and match them a bit. The same with your own views: you can make a nice custom view library this way!

Logging. Having a better way of configuring logging in Django is helpful. The standard python logging module does its job, but configuring is traditionally a bit of a pain. Nice for Django: an AdminEmailHandler that sends to addresses in the ADMINS settings.

Static files. This used to be the django-staticfiles app (see blog entry. (I mentioned it once in a lightning talk in a previous meeting). Django by tradition didn’t include much in the way of proper css/javascript handling.

When building pinax, they discovered that the MEDIA_* settings were horribly overused and intermingled: user-uploaded data combined with static css/js/image files. A huge pain in the ass. So in pinax, they figured out a way to handle it properly in the settings.py.

The staticfiles support in django core is actually a quite cleaned-up version of the original django-staticfiles app.

The usage is pretty simple. Just like your templates/ directory, you have a static/ directory that works in pretty much the same way. A collectstatic management command collects all the static files from all your apps.

Caching. Caching is a pretty much recent thing. The new implementation allows multiple cache backends. Handy when you want most of your cache in memcache, but a couple of specific items in a separate persistent cache, for instance. Also new: you can have versions in your cache. The use case is that you can keep serving old cache results even when readying the deployment of your new code version.

Internationalization. Everyone has problems with it. The new version allows comments for translators. Also in the templates. That helps a lot! Note that transifex, launchpad and the other mayor translation tools all respect those comments. And you have contexts that makes it easier to keep track of where those translations will be used: “month names”, “settings dialog”, etc.