DjangoCon AU was one of two “mini-confs” preceding this year’s PyCon Australia in Hobart. I picked DjangoCon (over the OpenStack mini-conf which also ran today) because I’ve never used Django seriously before. I wasn’t looking for a Django tutorial or anything, since I have skimmed it in the past and I’m very familiar with other frameworks, but I was hoping to be exposed to enough code and Django specifics that I could still follow along while being exposed to something new.

In reality it didn’t work out that way; the talks covered some very basic general concepts (“unit testing is important!”), and some very Django-specific utilities which I did not understand, but none of the talks hit that middle ground I was hoping for.

Below are some brief notes about the material covered in each talk.

Alex Gaynor’s keynote

• very simplified history of where the web has come from
• an interesting comparison of the state of web development in 2005 when Django was coming to prominence (“database-driven applications”), web development in 2009 when Django was already mainstream, and web development today
• deployment is one thing which has evolved drastically since 2005, but Django is not necessarily taking advantage of the latest advances

Jacob Kaplan-Moss: Porting to Python 3

• Python 3 is a real thing that ordinary developers can take seriously now
• it is now a viable option to write code targetting Python 3 only, or targetting Python 3.3+ and Python 2.6+ using a single code base with six
• Django supports Python 3 now, but needs developers to start porting their third-party extensions to Python 3

Greg Turner: FeinCMS

• very quick skim of how FeinCMS applications are structured [I feel like this part assumed a bit too much knowledge from the audience]
• FeinCMS provides some interesting tools which strike a balance between completely customisable content (which leads to “content editors” breaking site layout) vs. completely inflexible layout which does not meet expectations of the modern web
• “New York Times Snowflake”?

Russell Keith-Magee: Testing

• testing with Django fixtures is unmaintainable: no clear link between pieces of random JSON test data and data required by a particular test
• factory_boy makes it easy to set up test data at the start of each test [we have built an eerily identical system for populating test data in Beaker]
• mock makes it easy to replace real services with fake ones by monkey-patching

Simon Meers: Django utilities

• lots of miscellaneous Django utilities [which I did not understand the purpose of, due to my lack of Django experience]

Tom Eastman: back-ends with Django

• HTTP caching mechanisms are useful, but nobody uses them properly
• only recently started testing rigorously but is already a “zealot” for testing
• strict TDD is not necessary, but you must ensure every test fails before the fix and passes after
• continuous integration and code reviews are always worthwhile and useful
• it’s important to test failure modes and exception handling blocks
• page-level abstraction for Selenium/WebDriver testing is helpful [I disagree on this]

Curtis Maloney: REST API libraries for Django

• comparison of the (mis-)features of three “REST” API libraries for Django: TastyPie, Django REST Framework, and the author’s django-nap

Dylan Jay: Plone and Pyramid

• a quick overview of what Plone is [which was useful for someone like me who has never touched it]
• when to use a CMS (like Plone) vs. a framework (like Django)
• “customisation cliff”: making simple customisations (anticipated by the developers) is easy, but difficulty increases once the customisations deviate too far from the constraints of the system
• Pyramid is a “micro-framework” which takes some ideas from Zope/Plone