DjangoCon Europe 2011: Day 2

Note: Sorry for the long delay in DjangoCon Europe 2011 posts, but now I’ve finally found some time again to put my notes and impressions to posts :-)

After some cocktails, more burgers and even more beer and far less sleep, the second day had as much variety to offer as the first one with talks about Celery, multilingual content, fighting the n+1-query-beast and much more.


Who cares about Zope?

First thing in the morning Martijn Faassen gave a keynote about what Django and its community could learn from the problems and issues the Zope community had over the years. The points that probably stuck the most with me was the huge amount of circular dependencies Django’s core has right now and also that Django still has to work harder on integrating with the whole Python community. It took quite some time for Django to once again embrace the whole package and component mentality and right now some parts of it seem to be stuck in 2006 when it comes to best-practices.

Bitbucket - Lessons learnt

Next was Jesper Noehr with a keynote’ish kind of talk about what Bitbucket learnt over the years. His main lessons were:

  • Stay idiomatic. Don’t work against the core components and architecture of Django or you will most likely build in some roadblocks for when the next update comes around. It also makes introducing new co-workers to the project much easier since you can just give them the Django documentation to read.

  • Things change and you should have a way to deal with these changes. Keep only a very small part of your architecture fixed (like using Django and building on top of Linux) and leave the rest as flexible as possible so that you can, for instance, move from one storage provider to another easily.

  • Work with the opensource community by (1) using as many reusable components as possible and (2) also giving code back.

  • Be transparent and humble. Bitbucket has a great history of communicating the reason behind outages and what is done to resolve them.

Continuous integration and continuous deployment

After a short break, Szilveszter Farkas gave a talk on how continuous integration, testing and deployment is done at Prezi. The core of their current development style is that there are no longer feature branches but just one master branch where all development happens. The usual counter argument here would be that this makes implementing larger features problematic. The way Prezi is doing it, though, is with feature flags using Gargoyle. This also makes performance testing simpler since you can emulate A and B by just flipping some switches.

For internal stage deployment and continuous integration Jenkins is used.

unjoinify

Next came a very low-level talk by Matt Westcott which dove into some of the problems you might face if you’re working with more complicated model structures, and especially the n+1 query problem for nested data sets. In order to save you from going sown the raw SQL route he wrote unjoinify.

He also invited everyone to compare unjoinify with Simon Willison’s django-queryset-transform.

Celery

Right after lunch it was Markus Zapke-GrĂ¼ndemann’s turn to give an introductory talk about Celery and how to handle asynchronous operations with it. He also gave some examples on how Celery can be integrated easily with Django by using django-celery.

Reusable apps using “Eight Spaces”

Next in line was Klaas van Schelven and he introduced a set of patterns and tools that are used at Legalsense to make customization of reusable applications easier. The core methodology here is that views and models are dynamically generated within an application class so that they can be replace without breaking other parts.

Some aspects of this kind of try to solve the same kind of problem as the app-loading GSoC project by Arthur Koziel which is currently in its final stage of development.

Core developers panel

… with Andrew Godwin, Alex Gaynor, Jannis Leidel, Idan Gazit and Russell Keith-Magee talking about the past, present and future of Django and answering tons of community questions. For me, personally, the most interesting part was about what should perhaps get incorporated into core. One of these ideas was multilingual content (which was also the topic of the next talk).

Another big one was that there are now at least temptative plans for a redesign of the admin with even the thought going around that it might not necessarily be part of core (at least at first).

The Django ORM and multilingual database content

Basically continuing part of the discussion in the core developer panel was Jonas Obrist’s presentation about multiple approaches to translate database fields and django-nani in particular. He also went into quite some details regarding the differences and pros and cons compared to other approaches like having a single table for all translations or using language-specific columns right next to the original columns into the same table.

django-nani’s data model basically places an additional table next to the orignal model model which then holds the translatable fields and a reference to the language as well as the “original” model that contains the non-translatable field. So, in a sense, you have one database row per translation. Personally, I also see this approach as the most promising one and I know that it works since I’ve already worked with it in other systems. Now, I just want to see it work with Django :D

Integration the Enterprise using Django

Sadly I completely missed everything of Ed Crewe’s talk on how to integrate different enterprise frameworks and systems using Django.

Lightning talks

comments powered by Disqus