Now online: “Klaar in vier jaar”: a Dutch-language site to accompany a book designed to help PHD students plan their studies. My first Django site, though the interface work is all Javascript.

It has been an interesting experience working with Django. At first I was feeling frustrated at “how little” it provided. In time, I came to realize that what it in fact does is propel you very quickly to the core of your design and doesn’t get in your way (as advertised ;). Which is actually a very strong aspect of a framework — it kind of disappears and leaves you to solve the actual details of your design. When I then needed to make use of things the framework provided, it was quite straightforward.

In one case, I was puzzling over a particular “detail”: People should be able change the start and end dates of their calendar. In most situations, there would be no problem: someone simply adds a few months to the end, and the interface is reloaded to show the extra space. However, I was stuck on what to do if people change the dates of their calendar (say remove 12 months) so that some items might “fall off” (i.e. go out of range). I spent a lot of time planning and then starting to implement the code: to check for, and possibly adjust or delete the events that fall outside the range, and then making new templates to “step” the user through a process of being warned and accepting changes. After a night’s sleep (not very satisfied with where things were going) I woke up, still unhappy about the code. Then suddenly a much simpler solution hit me: simply reject any dates that might cause the problem, and leave it to the user to clean up / move the dates, no risk of screwing up the data, and much more transparent to the user. A new energy propelled me back to the computer (which actually isn’t very far away)…

With a renewed focus, it also became clear how different parts of the blob of code I had written each fit neatly into different places in the framework: a custom class to to the model classes, validation code on the Calendar form, and finally the code for the actual CalendarEdit view. In each case the code seemed to melt down to compact pieces that locked “solidly” into the various places the framework offered. The resulting form not only worked, but even suggested solutions to different issues (helping out for instance when a new calendar is initially created).

More and more I start to see how frameworks work as condensations of practice, and can enjoy the strangely indirect sense of communication or community with that practice in my own stumbling discovery of some well worn path.

The project code is GPL.