See you there.
I might even see one or two people at my talk, if I'm lucky. Though since I'm clashing with Simon Willison, I don't expect many.
BTW, we still need more session chairs. Don't be shy!
Congratulations to everyone involved in getting Django 1.0 out of the door. Great job.
Buy a book from Apress (such as the superb Definitive Guide to Django) and you can get the PDF version for a fiver, so you can keep a copy on your laptop when you are on the road.
What a great idea. I don't want only the PDF - I much prefer to read the dead tree edition. But you can't carry dozens of chunky tech books around with you, so I want the PDF too. Clearly I shouldn't have to pay full whack twice, but the fiver that Apress is asking seems fair.
I wish O'Reilly did this.
Welcome to the Guardian, Simon! I only wish I'd still be there when you started, but I'll be gone by then. :-(
I was well aware that Adrian Holovaty is a very big name in the Python world. He's one of the two original developers of Django (my personal favorite web-app development framework) about which he's written the book. He's since used it to power some very cool mashups; chicagocrime.org and everyblock.com, amongst others.
What I didn't know is that he's also well known and regarded by forward-looking journalists. Emily Bell's introduction to his talk at the Guardian set me straight.
Adrian's talk was inspiring, both to the few techies in attendance and to most of the journalists, who made up the bulk of the audience. His central idea is that we should ensure that the information that the journalists have collected is stored in a structured way wherever possible. It's hard, skilled work gathering that valuable information, but full use is not being made of it. If it were stored in a structured fashion (rather than just in the text of a story; in a "blob" as Adrian put it) it could be made use of in many different ways.
A great example of this is Faces of the Fallen. The information here is gathered by the journalists, but it can be explored in many different ways; by age, birthplace, all sorts of things.
Another interesting strand to Adrian's talk was the automated collection of data. The Washington Post runs a congressional voting record site, almost all the data for which is collected automatically. everyblock.com is another example of this kind of thing.
Explorability is crucial. Think how often you get stuck in the Wikipedia, 'cos there are just so many interesting links to follow. You go in to read one article, and find yourself with half a dozen tabs open all containing apparently unrelated corners of the 'pedia that you've stumbled upon, all of which you want to read. Don't you want your site to be like that?
Jemima Kiss has written up Adrian's talk better than I ever could here: Future of Journalism: Adrian Holovaty's vision for data-friendly journalists. Well, she is a pro.
Then, after work, Adrian, Julia and I headed off to Le QuecumBar for some disappointingly inauthentic Gypsy Jazz.
One of the most interesting things about the GAE to me is the non-relational data store. I've blogged only recently about my doubts about that approach.
A friend of mine from the big G go back to me about this. "To answer your question about what's wrong with a real database, the datastore is all about scalability. The API trades off flexibility with access paths and transaction boundaries for the ability to store terrifyingly huge volumes of data, while serving a bazillion concurrent accesses.
Compared to an RDBMS, I find this style of data storage requires a bit more thought and design up front. However, almost every RDBMS based app I've ever written has required me to go back and optimise my schema and queries any way, so overall, schema-related work is about the same. Not having SQL does make running arbitrary reports and so forth more difficult."
Hmmmm. Now, coming from Google, this bears thinking about. Scalability as an issue I can see. We do have to put in a lot of work to keep guardian.co.uk performant, and it's almost all at the database, fiddling with schema and queries level. Much to think about...
Other people's thoughts on this; Google Datastore and the shift from a RDBMS and Google AppEngine, BigTable and why RDBMS mentality is harmful.
More on the GAE:
- Google App Engine for developers
- Analysis: Google App Engine alluring, will be hard to escape
- Google App Engine: The good, the bad, and the ugly?
Loads of stuff in the blogsphere about the Google App Engine, unsurprisingly, some of it even worth reading.
- Ruby fanboys throw their toys out of the pram. You will be assimilated. Mwahahahahaha!
- Python is the new BASIC
- Tomato tracking. "It’s going to be the world’s greatest web application." ;-)
- Django on Google App Engine in 13 simple steps. Nice getting started tutorial.
- Experimenting with Google App Engine. "The lack of SQL is actually refreshing." ... "I am impressed. The App Engine team has done a fantastic job, and I think they have already changed the way I do hobby projects."
So, it's looking good, though I'm still concerned about lock-in. It's not just the Datastore API which locks you in - that's probably fairly east to emulate - but also the Authentication and Authorization API, which looks much trickier.
Update: As Ade says, you certainly don't have to lock yourself in to GAE's Users API.
The Python blogsphere has been exploding with the news of the Google App Engine today. And fascinating it is too - free hosting for Python web apps, Django included. With the might of Google behind it, this will push Python big style. Take that, Rails hype!
I'm a bit uneasy about the datastore, though. Not only does this gut any existing Django app, it also any means that any app that you write that persists data (read - non-toy) will be bound to the GAE API. What's wrong with a real database?
Naturally, I've signed up already. ;-)