I spent yesterday at the Australian Google Developer Day 2008 at Wharf 8 in Sydney. It was an interesting event to attend and I met up with some great people. Like most events there were both positives and negatives:
- Good turnout, lots of interesting people to meet and chat with (big shout out to delic8genius, dcw303, stuandgravy, garthk and Dr Yogesh).
- Great food and drink.
- Great keynote session with cameos from a bunch of different developer advocates and product managers who gave us interesting peeks at their developer products.
- Lots of nice new additions to Google Maps API, the Google Earth API was especially sexy.
- The Android keynote demo was cool, especially the Compass feature that allowed StreetView to track the physical movement of the mobile device.
- The App Engine sessions got me interested in using IronPython as it has a syntax similar to Ruby and might even be compatible with App Engine (the App Engine guys weren't sure about this one).
- The event was free (as in beer).
- No caffeinated soft drink. Negates all the good food and drink. Coffee lovers were looking for better sources of that beverage too. It would have paid off to hire a decent coffee stand for the day and allowing delegates to pay for it themselves.
- Nobody mentioned how to access the wifi network (I talked to the events manager and Alan Noble was supposed to in his keynote speech ... hehe).
- Audio bleedover between sessions, the Blue and Green rooms shared a flimsy wall that allowed sound through, particularly annoying when in the back of the Blue room.
- Presentations became less interesting as the day wore on. The first OpenSocial session was a complete bore, basically a project report.
- I missed the code labs, but up to that point the last 2 sessions had been both very short, using only half the time allotted. Remember the Milk forgot to turn up to explain how they use Google Gears, so that explained why their sessions was short. I spent that time tweeting and mingling, but would have preferred more content.
- It's all Beta. Many of the most interesting things mentioned are still unavailable, that's probably unavoidable at this sort of event, but it was a bit galling to hear yet another "this is only in prototype" explanation.
- It started too late, 10am is a ridiculously late time to start, mind you, I enjoyed playing Halo 3 on the XBox 360 they nicked from Google's Sydney office. It also ended late at 6:30pm, which meant I missed the last 2 sessions (mostly code labs). I might have stuck around, but my wife had a prior commitment I needed to be home for.
- The event took a whole day (as in working day), but really only offered half a day's worth of content.
You can check out the #gdd08au tag for the tweets from the conference. I was a bit lonely there for a while, but it eventually took off.
OpenSocial was the big disappointment for me, the material we were shown in the sessions I attended covered client-side gadgets, hardly an exciting line of development especially given the increasingly popular view that most social mini-applications are no more than viruses. Two thirds of the first session was spent looking at differences between v0.7 and v0.8 - only after we were all bored to death did the presenter ask how many were already using the API, and then only 3 hands went up! Perhaps I should have hung around for the Apache Shindig session to see server-side details, but the first session was too boring for it to earn more of my attention.
The App Engine sessions were the surprise bonus for me. Firstly there was the news that Python is only the first language they intend to support (star this support issue to see C# supported). Then I realised that Python reminds me of Ruby, a lot. Nice.
The best bit about App Engine was that we had good speakers, Tom Stocky (leader of the product managers that work on Google's developer products) and Brett Slatkin (an engineer on the App Engine team). They made it very easy for us to understand what App Engine was all about, and particularly why we should care about it (it makes it easy to start an app for free, and then scale it easily if it takes off).
The discussion about App Engine's Bigtable datastore was gold, especially the coverage of some basic issues that frequently catch out relational database developers (namely there is no count kept of the table). This really brought home to me the smarts behind data shards (which I might blog about soon) as well as providing us with the 'right' way to handle problems like global counters and list paging. This is core to Google's success and they obviously have some great lessons to share with the developer community about how to build scalable web applications.
Tom and Brett had very strong messages (repeated often) about how much they value the privacy of your data and code, and an awareness that for App Engine to take off they must make it as easy for people to get data out of the system as into it. Clearly if you design your applications to fit App Engine you will find it relatively easy to get started on any distributed LAMP hosting platform, although you will need to build some of the infrastructure bits for yourself - like Bigtable. However the premise is that if you build up your application on App Engine then you avoid the sort of scaling problems Twitter has experienced.
I missed most of the first Gears presentation (I was stuck in OpenSocial's yawn-inducing first session), but the 10 minutes I did catch was interesting. They made the point that Gears was all about unlocking the capabilities of the client machine, not necessarily working offline (although Google Docs seems to support this just fine!). This includes utilising the client's power to process data (searching, sorting and indexing) and accessing client information (such as geolocation information).
The MySpace presentation on how they have used Google Gears was very interesting. They handle roughly 160 million messages a day, fortunately they do not have Twitter's distributed messaging model, but it still is a huge number to handle. Each of their physical databases handles about 1 million users, with approximately 1 Terabyte of data in each. A big issue for them is how to enhance the messaging experience for users with large numbers of messages (some have hundreds of thousands). Offering searching and sorting is an obvious feature, but one they cannot easily handle given there large volume of users and messages.
MySpace's solution was to offer Google Gears to users with over 5,000 messages (soon they will lower the limit to 2,000 messages). For these users Gears could locally store their messages, indexing them on the client machine and then enhancing the (online) website so that searching and sorting could be offered. For these users the page data would be drawn from a mix of their standard online datastores and the local one - providing much faster response times, and putting less load on the MySpace servers. They are also looking at how to help users with large numbers of friends (some have 1 million+ friends!)
However implementing Gears was obviously not a trivial change, and I would hesitate to recommend it unless:
- It was inside a corporate environment (where you have strong control of client machines); or
- There was a very well funded business case for moving processing off the server architecture; or
- The functionality of offline access or geolocation was key to your application.
Remember the Milk was going to turn up for the second half of this sessions, but for some reason were not there (and AFAIK no announcement was made about their absence - maybe they were busy at Apple's Worldwide Developer's Conference?). They are an Australian startup that offers a free and simple To Do list function for users anywhere. They have been quite popular globally (half a million users) so it would have been interesting to see what they did different to MySpace (update: they have blogged about using Gears and it sounds like they use it for offline access, would have been very interesting).
Overall I'd give this a 7/10, and I would definitely go again, but I expected Google would do better. It goes to show how hard it is to run a good conference, especially when expectations are so high.
UPDATE: Got the hashtag wrong, it's now correct.