Themes from FOWA 2008

I've been at the Future of Web Apps 2008 in London for the past couple of days. Video and slides should be on that site somewhere but here are some themes I picked out from the sessions I attended...


Scaling and messages

Joe Stump, Digg, and Blaine Cook (ex-Twitter) talked about languages and scaling.

1. Write your app so it will scale out across boxes.


2. Use queues where possible - when you get a web request which needs some processing, stick the job in a queue and respond immediately to the request. Then process the jobs queue on a dedicated machine which doesn't serve web requests. Basically, scaling things well happens in the architecture, not the language or platform.

Then, Matt Biddulph (Dopplr), talked more about messages. Again, a quick response is important to the user who submitted the request, but probably not to other users; as Matt said "Does it matter, right now, to other users?". Parts of your app will run at different speeds so run stuff in the background and use messaging between processes. He had a nice Dopplr example where for every request to the site the code creates a new message on the queue with details of the logged-in user, the requested url and the response time. Later, if he wants to monitor the system he plugs into that queue and watches what's happening - it's cheap to throw stuff out onto the queue so you might as well do it.

Finally, Blaine again, with another session looking at XMPP/Jabber for real-time messaging - "The texture of the web changes when it becomes real-time". He summarised XMPP/Jabber as persistent, bi-directional, asynchronous, lighter-weight than http and with guaranteed server identity. I didn't realise that Yammer (a Twitter-like service) uses Jabber - it does a PubSub subscribe when you load the page and then uses a Javascript library to do dynamic updates in the activity stream. He concluded that it's early days and currently XMPP gives comparable performance to HTTP, but it should get much better.


Open tech and the social stack

David Recordon from SixApart did a good overview of open technologies for the social web. Here's his stack...

1. ID and profile - OpenID and hCard


2. Discovery (what apps and services do I use) - XRDS-Simple


3. Authorisation - OAuth


4. Relationships and contacts - Portable Contacts and XFN


5. Activities - ATOM + something more?


6. Gadgets - OpenSocial

The Portable Contacts API looks interesting - it's RESTful, uses JSON and allows you to query, update and sync contacts. The Activities layer is interesting but also seems to be the least developed, we need better ways to describe and encode actions of the form: "actor/s verb social-object [context][time]". MySpace, Yahoo, Google and Plaxo are all starting to use this stack so use these standards because it makes it easier for developers to build for your platform. David mentioned pinax, which I hadn't heard of before. It's an open source social software platform based on Django, must go and check it out.


Our future

Tim Bray ripped up his talk at the last minute to talk about the recession and the forthcoming financial situation. There won't be any large capital expenditures in your company so it's good times for an agile approach, open-source and the cloud (avoiding lock-in). And for individuals - build something for yourself (it's what you know best), don't be religious about technology and publish on the web - whether it's code, writing, photos whatever - put your stuff out there. And my favourite - you don't have to be a designer or a developer. You can be both.

Finally, Gavin Starks from AMEE gave a call to arms. AMEE's aim is to aggregate all the energy data on Earth including emissions, methodologies and consumption data.

His main suggestion: Build things to save the Earth.

For your app: Use virtual servers and the cloud. Write energy efficient code - optimise and refactor it so you use less energy. Maybe the energy use of a site be one of its performance metrics? Think about "slow cook computing" - how quickly do you really need the result? And do more function, less form - how much energy do all the processor cycles for that Flash app take?

What should we build? Make things that encourage less use. Make things that encourage low-energy behaviour. Encourage smarter movement (like Dopplr). And switch if off, or get it to switch other things off.

And a triptych of self-awareness...

1. Make your app self-aware of it's energy consumption


2. Make your app's users self-aware of the app's energy consumption


3. Make your users self-aware of their own consumption

And finally, measure and visualise all this information.

Lots of this often seemed quite orthogonal to the rest of the conference and the room had emptied out a bit before the session started, which was a shame because it was a good talk. But judging by the questions at the end the remaining audience made up for it in commitment, enthusiasm and intelligence. Let's hope it's enough.