Compound Thinking

Roomate wanted for PloneConf in DC

After some last minute wrangling of schedule, and other commitements, I’m going to PloneConf in October in hopes of furthering the python web development ecosystem’s cross-framework collaboration a bit more.

But lodging in DC is more than expected, so if anybody’s interested in sharing a room with me it would help make this less unaffordable for me. I’ve got a nice hotel booked through priceline, and would love to have a good roommate to help share the costs. If interested send me e-mail at my gmail address (mark dot ramm), or leave a comment here.

I’m really looking forward to connecting to some of the Plone folks, and to learning more about how things work in the Plone world of 2008.

UPDATE:

Roomate found. Thanks everybody!

DjangoCon (Part 2)

As I mentioned in my last post, I did a talk at DjangoCon a couple weeks ago, which has proved to be a little bit controversial in some circles (though the biggest critics are people who admit they didn’t actually watch it).

To see the part of the talk I’m talking about in this post jump forward to about minute 19 of the talk.

My previous post talks about almost all of the stuff that I consider controversial, and is basically an argument from history that very-large monolithic code-bases can get into trouble, and cause community fragmentation by separating out those who use “monolith x” from those who don’t. This is particularly true when the monolith is not particularly modular internally. This was the case for Zope 2 and Django seems to be following them down that path to some extent.

But today, I’d like to shift focus from the past to the present, and from social lesions to a famous bumper sticker I’m pretty sure most of us have seen:

SHIT happens

But since I don’t want to be too negative, let’s rephrase that:

GOOD shit happens

And I’m actually not interested in how great the django core-dev team’s drinking abilities are, or how wonderful their social lives are.

I’m interested in the good shit that’s relevent to making developing web applications better, so perhaps we could use this bumper sticker:

Innovation Happens

Django’s dev team has done some great stuff, that has shown that there’s lots more that can be done to make web developmet easier for python programmers. But at the same time not everybody uses Django and lots of problems that Django is currently trying to solve have already been solved by other people.

This argument isn’t really mine, it’s an argument made in the book Innovation Happens Elsewhere by Ron Goldman & Richard P. Gabriel. In the book they argue for using open source software so that you can harness the innovation that’s happening elsewere.

But even for Django, which is open source there’s no cornering the market on innovation, so we could say:

Innovation Happens Everywhere

It’s happening in Django, and outside of Django. It’s happening wherever there are smart people who want to make things better.

Here’s a quote form Goldman and Gabrial’s book:

Silly as it sounds, this is the brutal truth:

Regardless of how smart, creative, and innovative
you believe your organization is,
there are more smart, creative, and innovative people
outside your organization than inside.”

Innovation Happens Elsewhere

But, Django has a policy that they do not depend on anything else. This means that they have to reproduce all the innovation that happens elsewhere in the python web community in order to keep up. Perhaps this is OK, I mean Django is big, and they are innovating themselves, at least that’s the argument that some are making.

I think it’s a bit short-sided though, there’s a lot going on in TurboGears, repoze, SQLAlchemy, Pylons, Zope, etc. And all of those people are starting to work together more and more. They are recognizing that WSGI and reusable libraries makes python web development more flexible than ever before. If anybody thinks web development 10 years from now will look much like it does today has their head in the sand.

In the talk I just mentioned a few limitations in Django that people mentioned in Saturday’s talks. And I took one smart person outside the django community, Mike Bayer, and showed what he’d already done to solve those problems.

• Beaker: Mighty+Beaker solved the dog-piling problem with caching in django’s cache layer
• Beaker: encrypted cookie sessions (actually this one was done by Ben Bangert)
• SQLAlchemy: Batched commits (the unit of work pattern)
• SQLAlchemy: Multiple database support
• SQLAlchemy: Horizontal partioning (AKA, sharding)

Of course there are lots of others, who are also doing lots of innovative things that solve problems Django users have right now. And there’s no technical reason Django and the Django developers can’t use that stuff.

What this means for Django

My fundamental argument in this section of my talk is that Django users should start taking advantage of things that the rest of the python development community has been building. Just because Django has a no dependency policy doesn’t mean you should. And it would help the whole community to grow if Django components were easily decoupled from the framework as a whole.

I would love it if the Django ORM could be used outside of Django in an easier way — it’s a very powerful and flexible “Active Record” style ORM — I’d even go so far as to say that with it’s generative query syntax, and the recent queryset refactoring work it’s the best and most thoroughly documented Active Record type ORM in python today. But installing it and using it requires installing Django, and dancing an interesting (though not particularly complicated) configuration dance.

More on the third part of my talk which focuses on the future of Django coming later this week.