So after I nearly missed breakfast, the Twisted folks announced their involvement with the Software Freedom Conservancy. This is a different route than Django choose by making a Django Software Foundation, but the same, I think, in spirit. As for practice, I don't know enough about the laws involved to really say much else. But this guy does:

Van Lindberg

Van Lindberg gave an hour-long presentation on copyright and patent law, and how it relates to open-source projects. He did a lot of things right. He brought in game theory, showed cost/benefit matrices, generally tried to defend theoretical basis behind both copyright laws and explaining the growth of open-source.

But ultimately, programmers are a hard group to talk about copyright to, because, on one hand, we are "knowledge workers." At the same time, we are far more intimately aware with just how stifling copyright and patent laws are, and how little they really initiate the innovation that the laws are supposedly in place to help us.

The Leapfrog folks looked cool with their nosetests t-shirts - but marketing? Eh. Four-letter word, just commonly misspelled.

SQLAlchemy 0.4

SQLAlchemy continues to to be totally awesome. I knew a good number of the things Mike Bayer went over, but some parts (the new declarative layer, more straightforward join definitions) that's looking more and more impressive.

This makes a SQLAlchemy hook for Django even more interesting. There's a Django-sqlalchemy BoF tomorrow that I'll be checking out.

Data Persistence

Sean Talyor described the various key-object persistent mapping modules available in the stdlib. After listing half-a-dozen ways, he recommended shove instead. Meh.

One interesting thing he showed is versioning with dictionaries. I like it. Since keys just have to be immutable, a tuple of two strings, or of a string and an integer, is usable as a dictionary lookup, but the versioning is the first useful use of that that I've seen.

Also: What is it with everyone using 2-space indentation? django-tagging does it, to my horror, and it's on a lot of slides. I can almost sympathize with the presenters trying to preserve screen space but - if you're releasing code publicly - use 4 spaces. Period... no one should have to say this in 2008. I kinda wish Guido had just done away with all the inconsistency and locked the interpreter to 4 spaces in Py3k.

One issue here is that Sean is describing the database functionality being added on by middleware. I'm wrapping is not good as an API... for reducing boilerplate, yes, but for adding functionality, I don't think so. Provide hooks instead. Then again, IDKWITA.

Reusable Django Sites

This is a presentation I've been wanting to see for a while, as I had some issues with packaging lifeunit well.

James Bennet really cleared up a lot. A Django app should be a standalone Python package. James pointed out the way to get apps written well:

  • Do one thing, do it well
  • Don't be afraid of doing multiple apps
  • Write for flexibility
  • Build to distribute

Like many of the best presentations, his was mostly common sense, but things that are easy to overlook.

One application per feature is something that I need to be doing better. If you encapsulate a data model, and it's behavior, then you get an application. We use forms and templatetags to communicate to the lingua-franca, HTML and HTTP. And then it's up to the site maintainer to integrate their own templates, and we're golden.

I might actually be able to use django-registration and django-profiles immediately. I too have been guilty of trying to do everything in one Django application. Wow, I feel like refactoring during the presentation. So much code, so little time.

Another good point is that even with things like WordPress, you eventually end up with a plugin layer anyway. In other words, Django can be thought of as a standard, well-designed plugin layer. Some applications are included - users, admin, so on - but they're just the default 'plugins'.

Writing good Django code is just writing good Python code. And writing good Python code is just is just writing good code. Use common sense, sensible defaults, provide hooks, make your application as pluggable as Django itself.

Don't hardcode anything in your function, whether it be form classes or url redirects or maybe even models; pass them in as keyword args with your values as defaults. Again, straightforward, but I know I certainly don't follow it well enough.

He also mentioned that the Django tutorial actually teaches a very bad habit with regards to the application packaging - I still have this habit. But at least I'm aware of it and can remedy it as time permits.

I totally saw Zed Shaw and... DHH! I was on my way to another talk so I didn't stop to say hi, but I'm hoping to sometime today.

Web2Py... hmmm

I first saw web2py some time ago, when it was called Gluon. I'm not planning to use it myself - too web-based - but it is a lot more capable and complete than I had been aware. Still, I think it fits a fairly small niche - the interface is a very-toned-down ZMI, and the fact that it has it's own ORM, templating language, and dispatcher means that adoption is an all-or-nothing thing.

Lightning Talks

Very impressive GeoDjango, a bunch of company shilling... some funny malfunctions as well.

Django BoF

I caught the tail end of the Ellis BoF and the whole Django BoF. We got a lot of polling of backwards-incompatible changes from Jacob - judging from what he was asking about, there are some interesting changes coming down the line. I've also learned that I need to check out newforms-admin and queryset-refactor, um, soon.

We went out to somewhere afterwards... not really uptown Chicago, but some place on the Blue line that I don't remember immediately. Apparently, one of the guys with us was none other than Captain Crunch. Yes, that Captain Crunch. That is just too cool. I'm still not over it.

Also, I owe someone for pizza. (I don't remember your name... Email me if if it was you.)