Roundup from the final day – summary thoughts and conclusions to follow in a separate post when I’ve had time to formulate them!
- Introduction to Bespin - Mozilla's Web Based Code Editor 8/10
Very low-key presentation that went through some of the deficiencies of the current command line environment, and a demonstration of how much better it could have been (and will be with Bespin). Another really elegant example of how much difference very small changes make, and the value of attention to detail. +1 for the demo.
- The Present and Future of Web App Design 8/10
Really enjoyable romp through the past, present and future of user interfaces. No breakthrough items, but a great presentation with no angle. Mobile (in all its forms) is the run-away winner, along with all the goodies that things like 3-D, GPS and AR will bring. Minority Report, here we come.
I didn’t really learn a lot in this presentation, other than that mobile apps don’t work very well. Apparently it’s possible to write web-apps (HTML/CSS/JS) that can access native APIs (accelerometer, camera, GPS) for most smartphones using something from phonegap.com, and HTML5 provides offline data storage. Oh, and dojo is better than jquery. Mobile is big here, and it’s clearly this year’s thing, but it seems to be still in the embryonic stage. Things like the ipad (mobile features, desktop screen-size) won’t help the confusion, but some pretty cool things are going happen in this space this year.
- RESTful Business Process Management 6/10
Dry, academic, talk that demonstrated quite nicely that terms like ‘REST’ and ‘Mashup’ do not mix with terms like ‘BPM’, ‘SOA’, etc. from a cultural point of view, if nothing else. Yes, you could build an SOA using REST services, you just wouldn’t call it SOA – and neither would you use a visual tool to do it for you. Enterprise and community are not happy bed-fellows.
One thing I did quite like was the use of the HTML ‘embedded resource pattern’ for building composite services. Embed the URI of another service in a service response and shift the burden back on to the client – exactly as HTML does with web pages, where the browser is responsible for building the composite view from all of the embedded URIs.
- Does REST need middleware? 8/10
Much better – this was a great wrap-up for the conference as a whole – how to use an existing, simple, well-understood protocol (HTTP) to satisfy some pretty complex requirements – SOA, reliable messaging, transactions etc. Really elegant solution (REST-*), and definitely something to watch. A great way to end.