"Introduction to Google DocType: An Encyclopedia to the Open Web" by Mark Pilgrim

Google DocType is basically a wiki provisioned by Google withing their Google Code site. The goal of the wiki is to document the open web. So what is the open web? Well it wasn't really a straightforward answer. Essentially, Google only really wants to capture information related to raw browsers, for instance, anything related to a vanilla install of Firefox. This means that they won't really address Flash or Silverlight, or anything else not included with Firefox. This is where the definition got a little gray, Google does want to security to be a prevalent topic, so security issues related to Flash are okay for DocType. According to the presenter, it's technically a wiki, but ultimately Google (and he) reserve the right to control and revise the content that ends up there. This is not to discourage users from contributing, I think it was more for a way to avoid some of the challenges encountered by Wikipedia. For instance, he mocked the lengthy process Wikipedia has defined for deleting a page (this page itself is about 10 printed pages long)
http://en.wikipedia.org/wiki/Wikipedia:Deletion_policy
Dictatorship aside, the content that is actually in the wiki now is extremely useful. There are thorough articles that include thorough examples of code. The only problem is that the content in the wiki is far from comprehensive. There are plenty of pages that are merely stubs of information yet to come. Google recognizes this and merely admits that DocType is a work in progress.
Some other noteworthy pieces of information from the presentation. Apparently, when the presenter was pitching the idea to fellow Googlers, their primary concern was how to prevent spam from being posted. Interesting that this is the primary concern, and quality of information isn't. To alleviate this, an automated process is put in place to find and remove spam, and after that a manual process is defined. Bottom line though, spam really hasn't been a problem up until this point. Another nice feature is that since Google is hosting this, the data is replicated across all their datacenters. And finally, the entire project (code examples included) is accessible through a subversion checkout. A very nice feature if you'd like to copy the data locally for review during a period of no Internet connectivity. Finally, Google has written thousands of JsUnit test cases to verify the information in DocType. For instance, if some information is posted about how Firefox 2.x handles colors, there are accompanying JsUnit test cases to verify that the information is correct. Mark mentioned that they actually found some very subtle bugs in browsers that have existed for years while creating their baseline of test cases.
Mark was very anti-Microsoft, and made many jokes at their expense. His operating system of choice is Debian.
You can find Google DocType at:
http://code.google.com/doctype/
In my opinion, this is a nice step by Google. Since their business is almost all web based they have great expertise in this area. I have to wonder though, how will this keep the momentum for constant updates?

"Open Source is Magic" Tech Talk with Chris DiBona

I arrived a few minutes late to this presentation on the account that I was eating lunch. It's funny, there was no time allotted in the schedule for lunch. We basically had to pick some time between a session to eat, so naturally, obtaining the food and consuming it took a little longer than 15 minutes. In general, the point of this presentation was to indicate why open source software is great, why google thinks it's great, and some ways that they're helping to advance the field. Something that has really been stressed throughout the conference is that Google really has built their entire foundation on free open source software. Even going back to the days of Sergey and Larry in dorm rooms, pretty much all of the software used to build Google has been open source. Chris also made the point that there is noone in the world who has not interacted with something driven by open source software, they just may not be aware of it. Aside from web searches using Google (which everyone has done in today's world right?), almost all embedded devices have C code that was combiled with the gcc (Gnu C compiler). Google itself has also done much to help further the field of open source, primarily in two methods. The first of which is releasing their custom patches to open source software back to the community. For instance, about a month ago Google announced that they will be providing the community with custom patches they wrote for MySql 4.x. Of course these patches were written by Googlers for Google optimizations, but once they were in the wild, they gained a lot of popularity and MySQL now has plans to incorporate the code into their 5.x code base.
http://google-code-updates.blogspot.com/2007/04/google-releases-patches-that-enhance.html
The second way in which Google is advancing the field of open source is with their Summer of Code efforts.
http://code.google.com/soc/2008/
Summer of Code is a way in which Google is providing college students a channel to stay involved with computer science throughout the summer, primarily through contributions to open source software projects. Google coordinates the efforts, and even awards students with monetary payment for their work. Everyone benefits.
Ultimately, Chris' point was that open source software is good for the Internet, and what is good for the Internet is good for Google.
I think that open source software really has potential in the enterprise. Finally companies are beginning to trust the open source licenses (there really aren't that many of them). Once legal departments become familiar with the licensing, I don't see why they wouldn't look forward to the opportunity to avoid the headachces that happen when processing a new license agreement for every new piece of proprietary software. Plus, it's free!

Day 2 Key note

Keynote speech by Marissa Mayer, VP of Search products and User Experience.

A glimpse under the hood @ Google

This keynote is focused on how google evolved, what search products are built and how Google handles the User Experience.

Marissa started by introducing how and why Google invited hundreds of artists and designers to design iGoogle interface. Google believes that a fraction of its users wants more than the minimalistic look of Google homepage.

Sergai created the Google home page. When Marissa asked him why he chose the minimalistic look on the home page, Sergai's answer was first, we don't have a web master and second, I dont do HTML. Its amazing the way it started and remained the same all these years supporting the founders vision. When Google first tested their home page with students from Stanford, students kept waiting for > 40s staring at the screen. Marissa asked them - "are you waiting for
something?". Then the tester replied that they are "waiting for the rest of the page to load".
Marissa revealed the complexity behind the simple home page. She believes there is no need for the end user to know what goes behind the search box.

Basically every search query is greeted by a loadbalancer which will send the query to one of the many data centers. Mixers get involved before hitting 300-400 backend search servers. Again Mixer gets involved where Ad Servers and other components get mixed up. Then the process goes thru' Google Web Servers for HTML content. This entire process goes through 700-1000 servers brining back millions of hits in a fraction of second. This is the complexity Google wants to hide from the end users.

Split A/B testing.Google conducts A/B testing to understand how users react to different designs. This testing is done in production and matrics are gathered in realtime.
Matrics could be RPM, number of hits etc. Based on the trends, Google decides on which design makes sense. Marissa gave couple of examples on the type of tests they conducted. She showed 3 versions of Google Search results, all the three looks almost same, except the white space between Google icon and the beginning of the search results. Amazingly, couple of pixels makes quite a difference in how users react to the search results. Google found that the version
with less white space is liked by many users. THis is backed by the serach results users actually clicked on. Similarly, Google tested Google Ads background color - blue vs. yellow. It found that Yellow makes sence for the ads.

There was a research conducted on the number of results should be displayed on the first page, 20? 30? 40? Google found that more search results on the page
actually generated less search querries. (The more you search, the more money Google makes.. makes sense).

Learning curve on Searching.Gogle found that over a period of time, users got educated on how to search, what to search for and how to talk to search engine to get better results.
Think 10 years out.Google believes every company should think 10 years down the line and think of how their applications, business models will evolve; and be prepared for.

Google 411:There is no reason behind this application and no relavancy to search, but at the cre of this application is the speech recognition and text to speech. Google believes this is not a 100% best solution (like any of its applications), but this application demonstrates that it could be used for video search and other media searches; and could bring more inforation to the user. Car search is something that is mentioned couple of times.

Google Language Informational SearchThis is a great story. Google spend lots of energy in building the multiple language search. Outsourced to translators, but that turned out to be a lengthy process and very unproductive...when one of Marissa's friend could produce his web page in 50 different languages. The secret is his friend used his fans to translate it for him. Google followed same approach and requested all its users to contribute to the translation. As a result, more than quarter million people contributed to tranlasting search results into 110 languages. Now Google has 140 domains.

Easter Eggs on Google

Marissa, during her grad days used an app on Linux that echos anything typed in Chef language. She used this program to convert 400+ strings and it is one of the language choices on Google Preferences. Its called Bork, bork, bork language.

Healthy disrespect for the impossible.
Marissa believes that solving search problem is impossible...but they will keep working towards it. Getting something close to 90-95% could make quite a
difference.

Google Health:This application is created to help users store the medical records in one place. Again, this is an impossible task, which Google clearly acknowledged.

20% of time:This is a culture Google employed in the company. All Google employees spend 20% of their time in doing what they like to do. Amazing work was produced with
this 20% of time rule - 50% of the Google features are produced in this time. Gmail is another example.

Overall Keynote was fantastic, lot of interesting insights into how Google operates and keeps the innovation going in the organization - still marching towards the founders vision and goals.

Software Development Methodology at Google

We had a chance to talk to a Tech Lead on Google Gears about how they develop and elevate application efficiently. His answer is simple - they do not follow any Software developmen methodology or approach. They have coding best practices. On the top of it, the hiring bar is so high, the Engineer generate good quality code and constantly find ways to improve it by peer reviews. Some parts of the organization follow scrum, but they are not crazy about it. What they believe is, less process more room for innovation.

One important thing he mentioned is, Engineers are at the top of the food chain, not project managers or marketing or product department. This allows Engineers to take decision on what and how something gets elevated.

Overall impression on the first day

Though the registration process was little bit disappointing, it looks "doesn't matter" with the Key Note speech by Vic. Google nicely managed their inefficiency in managing "quiuing".

Google is encouraging developers to build more and more apps without any constraints... that pushes the web to new levels. I think we need this. Thanks to Netscape for starting this.

I liked Android and OpenSocial tracks, where many new technologies and techniques are presented... again to encourage developers to build more and more apps.

The day ended nicely with the "After Hours" party, which showed Google's company culture... music, games, drinks, food, band, lots of information sharing...

MySpace and Gears

MySpace is a heavy adoptor for Google Gears. Looks like they used Gears effectively and took advantage of the features available in Gears. Couple of examples mentioned in the conference

1. Search feature for power user. In this scenario, someone could search for a friend in the list (trust me 0.1% of the MySpace users have > 10,000 friends. I guess they need this feature) and Gears will bring it up as the users type the criteria. This feels like Google Suggest. But powerful than that. The data is locally cached and brought up as required and the UI changes based on the requirement.
2. Message enhancements

When is Google Gears a good choice

• Our user base should have plug-in installed. Chances are... users download it, much like they download Flash plugin. Thanks to Adobe.
• If we have some control on the users and their browsers (typically corporate intranets), then we can push this plugin
• Added functionality is compelling enough to download the plugin? What will users do if the app we build requires them to download the plugin. I think the users and their behavious is changing (again, thanks to Adobe), so chances are this could become ubiquitous so we can ignore this as a requirement

We need to keep this in mind when building Gears apps

• Users may have multiple machines, we need to be cognizant of that
• Worker pool threads are great for processing on the client side
• we need to account for shared OS login scenario.

Questions? owyn@myspace.com

URLs are people too

Whatt? yes, people could use URLs to represent them. Plaxo uses this model to identify the user and pull his information using Social Graph API (+some manual crawling). These URLs use OpenID and Social Graph API.

Gears on Mobile

This is a very intersting concept Google is pushing. We felt like it is contradicting with messages by other speakers. Google Gear runs on the client side and enhances the browser capability. Think of this as a Flash plugin. With Flash plugin (please note that it is ubiquitous close of 98% on all user machines), Flash applications behave like Rich applications running on the client side. We could make this application run in offline mode if we want to. Google Gears is on the same lines. It makes the application run in offline mode and also real-time where it constantly interacts with the server and synchronizes the data on the client side. Obviously, this interaction is transparant to the end user.



What Gears do on the mobile device is, they allow us to create a native application that takes advantage of the features available on the device. Also a light weight database (SQLite) helps to store the data on the device.



The statistics say that very few people develop on the mobile browsers. Partly because of the fragmented brower market on the mobiles. In addition, mobile web apps are slow, unresponsive and blind. This actually motivated to develop Gears on Mobile devices.



Gears offer APIs like Data API, Server API, Desktop API and Storage API. There are two types of caches - Resource Cache and ManagedResourceCache. These cache mechanisms allow apps to cache majority of the data so there are less interactions over the network. This kinda makes sense...but what about the security?

OpenSocial - Session1 by pat

For any Social networking site there are couple of objectives that the owner needs to keep in mind

1. What is the objective of the social network, meaning what problem the site is addressing
2. What are the verbs...such as share/buy/sell/connect etc
3. How ca people share the object? objects such as photos like Flickr, Music like iLike etc
4. What is the incentive for the users to share these objects?
5. Who are you charging?meaning where do you get money?

- Social Graph -> Friends/Profiles/Activities

There is a book suggested by Pat. This book is written by an economist in Google, Hal Varian, 10years back. The title of the book is Information Rules.

- Pat says OpenSocial is an API focused on People&Friends, Activities and Persistance.

- There are couple of options for the social network builders. Use EC2, Joyant of Google App Engine to build the site

- Companies like Salesforce.com and Oracle are building social network sites with OpenSocial API. This is the extend enterprises are using social networks.

- Social networks fall into one of the following categories

1. Viewers + Friends
2. Owner + Friends

- In the CRM case, it is more like Customer + partners.

Rapid Development with Python, Django, and Google App Engine with Guido van Rossum

First off, most of what attracted me (Andy) to this session was the presenter. Guido is the creator of the Python programming language. Currently he works at Google, and actually refers to himself as the benevolent dictator of the Python community. Even though I don't really have much experience at all with Python, I was excited to here a presentation from such a prevalent language's creator.
Regarding App Engine in general, I really have to question Google's decision that their entry into the cloud computing world would only address web applications. With all that nasty computing power, they're only going to let developers deploy web applications on it? Why not allow raw data processing? I think this is a major drawback from their offerring in comparison to Amazon's Web Service engine. While a little more complex (and requires a credit card to start), I see much more promise in Amazon's offerring. Either way, I'll go with it that Google only intends to address the developers who need to get their application of the ground quickly, and don't want to shell out any dough or effort in obtaining another deployment environment.
Moving on to App Engine, your code (and the system itself) will only ever handle HTTP requests, nothing more or less. When you deploy your code in the cloud at Google's data centers, the App Engine framework will automatically scale the resources. As a developer, you'll never need to worry about any of the infrastructure. As the use of your application grows, App Engine's magic will handle this nastiness for you. Not unexpectedly, the development of your application happens on your desktop using App Engine's SDK. The SDK provides a one click deployment of your application to the cloud. Another interesting note is that Python is the programming language in which App Engine applications are coded. Again, this is yet another differentiator for enterprises. I'd guess that ASP/C# and J2EE are the two most prevalent platforms for web application development in the enterprise today, and obviousily the Microsoft solution has siginificantly less market share than Java. So why would Google choose Python? Maybe it integrates better with how they wanted to package App Engine and integrate with their other systems? Maybe they intentionally don't want to address the enterprise need for cloud computing? Discussions with Googlers and other conference goers throughout the day never really shed any light on this question. Maybe their reasons for offering a cloud computing solution are different from those of Amazon? Guido continued overviewing the quick development of a basic guest book application using technologies of App Engine. Nothing too exciting, and nothing really all that different from what is covered in the App Engine documentation. Well, except for one thing. Django is a Python templating framework that App Engine choose to include with its distribution. Like Python, Django is nothing new, its just something Google decided to provide with App Engine. The only thing, the version they provide is extremely old, and in fact, they recommend that you upgrade to the latest version before development! This seemed really annoying.

"An Introduction to Android" with Jason Chen - 11:15am

My (Andy) first session of the day after the keynote. Labeled a "101" session as well as being titled an introduction, I didn't really expect a lot of detail from the presentation. My expectations were not let down. The presentation wasn't really much more than a verbal overview of information that is already publicly available on the web regarding Android, with really one exception - an announcement that devices will start being shipped with Android in the second half of 2008. Never-the-less, I'll still review the information presented. Before getting into the details of Android, Jason presented a slide comparing the number of people in the world with a mobile phone versus the number of people in the world with an Internet connection. Not only was the number of people with a mobile phone basically double that of internet connection owners, but the number of mobile phone owners was even increasing at a greater rate than that of Internet connection owners. I guess his point was to reinforce the importance of a standard mobile platform, which is what Android is. Android is an entire mobile operating system. Applications for Android are written in Java, but compiled into Dalvik Virtual Machine byte code (as opposed to Java byte code which runs in the Java Virtual Machine). Contrary to the iPhone and its SDK, the Android platform is ENTIRELY open. A developer pretty much has access to anything they want on the device. Aside from being actual open source software licensed under the Apache 2, Jason described three aspects in which Android may be considered an open platform. It is open to the mobile industry, any provider or device vendor may use the platform. It is open to the user. A user of an Android phone may download any application they want and install it, and this includes replacing the primary applications on the phone like the address book! Android is open to developers as well. There was an interesting demo of application integration, specifically, a regular Google web search was made for "pizza san francisco." And just like you can try on the regular web, at te top of the results was a link to Google Maps to show the location of pizza restaurants in San Francisco. Things got interesting when the link was actually clicked. Upon clickin the link, a popup appeared, prompting the user to specify whether they would like to view the resulting page in the regular Google Maps web application, or switch over to the rich Map view client installed on the device. Jason selected the rich client, and the Android prototype seemlessly switched to the locally installed Map application. Of course there was the obligatory security slide in which Jason indicated there was plenty. Security features include process level separation, and sandbox execution of the applications. During the Q&A after the presentation, a question was posed asking if there was any mechanism provided that allows for developers to easily maintain a consistent look and feel of their application, with other Android applications. Similarly to iPhone, there is a suggested set of widgets that developers may use to achieve a consistent look and feel, but contrary to the iPhone, developers aren't forced to use these. Overall, Android looks really interesting. Seeing that the phones will start to ship right around the time that my contract with Verizon will expire, it will be a tough choice whether I get an Android phone or an iPhone. Also, one can only speculate the market penetration that Android will have. While the Open Handset Alliance will go a long way to help ensure that all the infrastructure is there to setup Android for success, it will ultimately be up to the consumer to determine its success. Can it kill the iPhone?

Key Note (Andy's take) - Client Connectivity and the Cloud

KeyNote by Vic (9:15 am) - Client Connectivity and the Cloud
Hopefully I'll be able to augment some of the points that Karun already made. Vic . started the day off presenting the keynote for the day. Right off the bat he apologized for the absurdly long registration lines. In fact, the registration lines were still very long at 9:45, when the keynote should have started about 15 minutes earlier. Finally, they just let everyone into the conference without actually checking registration, the only request was that everyone stop by the registration desk by 2pm to actually register. The actual meat of Vic's presentation presented a cycle of computing throughout the years. The cycle contrasts computing power with computing accessibility. 40 years ago or so, the mainframe presented mass computing power (for its time), but was extremely inaccessible. Users had to wait in line for their allocated slice of computing time. Once they had that slice though, they had freedom to leverage the full power of the mainframe. As technology evolved, the personal computer was born. This reversed the trend by reducing the computing power available to users, but increasing the accesibility. Everyone had one in their home, but the raw horsepower paled in comparison (relatively) to the large mainframes. Finally, we arrive in today's computing world. Expensive data centers provide enormous computing power, but only a select few developers may actually have access to take advantage of it. It's not like Joe Developer can shell out a couple million dollars to build a data center for his website that can handle a five million visits a month. Vic's point of this whole story is that cloud computing enables Joe Developer to only worry about writing his killer app, and not need to have any concern about building the infrastructure. Cloud computing provides highly accessible enormous computing power.
After concluding this story, Vic introduced Allen Hurff of Myspace to present an example how MySpace recently leveraged Google Gears. Nothing too exciting here. MySpace basically improved some searching and sorting functionality within their message center using Google Gears. Comparing the old interface with the new, there was definitely some performance increases. More on Google Gears in a later post.
Vic comes back on stage and moves discussion into the mobile world. As we know, and Vic said, there is a ton of fragmentation on the mobile platform. This fragmentation is prevalent in both the web and rich client platforms. So many devices, and many of the difference devices have their own browser implementations. There are almost no standards, or atleast standards adopted on a widespread scale. Vic introduces Steve Horowitz to introduce Google's latest work in the mobile world, and whaddayaknow, Google Android! The biggest surprise of the demo was that he had an actual device (a brandless prototype) with Android running on it connected to a 3G network. It must have been some custom network that Google had setup, but still cool to see Android actually running on a device. His demo finished with a real wow moment. Showing the Google Street View running on Android, the development team had integrated the compass aspect of the GPS chip such that when he turned around (physically) the device detected his movement and rotated the street view with his turns. Really cool.
Vic back on stage to introduce Kevin Gibbs to present App Engine. App Engine is Google's cloud computing solution, and really the answer for developers to have access to the large Google data centers to run their applications. This way, devs can solely focus on writing the application without the headaches of configuring web servers and DBMSs. More details on App Engine in a future post, but it is worth mentioning that Kevin did break the news that AppEngine was finally publicly available today. Previousily, it was only available to a select few trial users.
And the keynote went on for a couple other presenters, nothing really to note. Mark Lucovsky overviewed the latest news regarding the GData and AJAX APIs. The GData API provides a method to read and write information from Google Services such as Google Docs. The AJAX APIs provides a read only interface into other Google Services such as YouTube. Following Mark, Bruce Johnson took the stage to overview the latest news from the Google Web Toolkit shop. Most notably, the GWT Release Candidate 1.5 is available today which includes support for Java 5 features. Pretty powerful stuff, just really a niche market and hard to see how GWT could fit into the enterprise. Finally, the last Googler to present at the keynote was David Glover. David highlighted the OpenSocial platform, Google's attempt to provide an application development platform. A developer can write an application according to the OpenSocial spec, and then the app is compatible to run on any social network that supports Open Social. It's a great idea, BUT, Facebook isn't on board at this point. We'll see how far this actually goes...
Vic back on stage to dismiss everyone to the first session (and remind people who didn't have a chance to register, to register by 2pm :).

OpenSocial - Meet the OpenSocial containers

This session is for the Social networking sites that use Open Social container. Representation from MySpace to Hi5, AOL, Friedster etc talked about how they used OpenSocial platform to build the apps and widgets on their sites.

OpenSocial is a very interesting concept and is becoming popular as more and more companies are participating in building the platform. Google provided the first drop of the platform and donated to Apache and opened up the many developers. This could become a platform competing headon with Facebook API.

We may not use it directly, but the fact that the exponential growth fueled by this platform could mean many more social sites will popup.

We could use this platform to build social site for our advisors, but why would we build something from scratch? Lets give more thought to this...

Key Note Speech by Vic

Vic, VP of Engineering @ Google started the Key Note speech, which is a great kick off for the conference.

Vic revealed some important things that are remained mystery for many of the internet users... why is google getting into developing apps on the web.

2 reasons
1) Google is born on the web, it is the core part of Google and it believes that web should be moved forward.
2) Google has a revenue potential. The Open Web allows us to build rich web applications -> more users -> more uses -> more revenue.

Web is the most dominating platform. We started with Mainframes, powerful at the backend, but dumb terminals. Then we switched to PS - powerful clients, but difficult to deploy applications. Then Netscape made it easy to access applications gave birth to the web apps. Then we got into computing problem...data/complicated apps/users etc. We keep oscillating with tension between the server side and client side computing.

Google believes that web as a platform can solve many of the problems we have now.

There are 3 objectives for Google apps
1) Make the cloud more accessible
2) Keep the connectivity more persisting - Google Data API, Google Apps etc
3) Make the client more powerful - Google Gears, Mobile, web etc

Google Gears
- Extends the power of the browser
- Google believes HTML5 is the way to go... and it is full supportive of that
- Google built a relationship with Myspace and MySpace is a user of Google Gears which make the site much more powerful that ever.
- Google Gears use the power of the client PC. users need to install something on their desktops


Android
- Complete stack
- Allows mobile operators and device manufacturers to take advantage of the OS to build a powerful mobile devices
- Android features feel more like iPhone. This is a great advantage for other companies to take advantage of the Android to build powerful apps.
- We saw a demo where Maps view was built and the phone essentially becomes a camera and we can see 360 degree view of the streets. This is an amazing feature.

Business value
- More and more users are expecting a rich application on the phone because, mobile phones do not have faster networks yet.


Overall the key note speech was great. Lots of insights into what Google is about to do with the development community to move the web to a direction that is beneficial for all users.

Questions - vicg@google.com

Arrival (at the airport)

We got to the airport in one piece and on time. More to come once we're in the air.

This is a running commentary on Google IO conference.

Please see the conference details here http://code.google.com/events/io/

AJAX & JavaScript

APIs & Tools

Maps & Geo

Mobile

Social

Code Labs

Tech Talks

Fireside Chat

.

8:00am - 9:30am

Registration Breakfast

.

9:30am - 11:00am

Keynote: Client, Connectivity, and the Cloud - Vic Gundotra, Vice President, Engineering

.

11:15am - 12:15pm

State of Ajax: The Universe is Expanding (Room 1)

Google Guice 101 (Room 4) Resource Bundles and Linkers in Google Web Toolkit (Room7) Extend the Reach of your Google Apps Environment with Google APIs (Room 9)

Flash API for Google Maps (Room 5) From Mashups to Mapplets (Room 6)

An Introduction to Android (Room 3)

OpenSocial: A Standard for the Social Web (Room 2)

Painless Python for Proficient Programmers Part I (Room 8)

.

12:00pm - 2:00pm

Lunch Available (sessions continue)

.

12:30pm - 1:30pm

Spice up Your Web Apps with Google AJAX APIs (Room 4) Leveraging Web 2.0 Design Patterns For Enhanced Accessibility (Room 5)

Rapid Development with Python, Django and Google App Engine (Room 1) Faster-Than-Possible Code: Deferred Binding with GWT (Room 7) YouTube on Your Site (Room 9)

Harnessing StreetView, Static Maps, and other new additions to the Google Maps API (Room 6)

Building an Android Application 101 (Room 3)

Meet the OpenSocial Containers (Room 2)

CODE LAB PART 1 (lasts until 2:45pm) Getting Started with Google App Engine - On Your Mac (Code Lab 1) Hands-On Google Gears: LocalServer, Database, & PubTools (Code Lab 2) Building an OpenSocial application, focus on client side APIs (Code Lab 3)

Painless Python for Proficient Programmers Part II (Room 8)

Google Data APIs (Fireside Chat)

.

1:45pm - 2:45pm

Taking Large-Scale Applications Offline - Lessons Learned from Google Docs (Room 1) Can We Get There From Here? (Room 4)

Building Scalable Web Applications with Google App Engine (Room 2) Creating a Google Data API Client (Room 9)

The World's Information in Context (Room 3)

Anatomy & Physiology of an Android (Room 7)

Apache Shindig: Make your Social Site an OpenSocial Container (Room 5) OpenSocial - Scaling and Analytics, Nuts & Bolts (Room 6)

CODE LAB PART 2 (continued from above)

Open Source is Magic (Room 8)

Google Desktop APIs (Fireside Chat)

.

3:00pm - 4:00pm

Google Gears and MySpace - an Exploration of Powering Search on the Client (Room 1) Secure Collaboration - How Web Applications can Share and Still Be Paranoid (Room 4)

Using GWT to Build a High Performance Collaborative Diagramming Tool (Room 3) Under the Covers of the Google App Engine Datastore (Room 6)

Map Mashups Session (Room 2)

Google Gears for Mobile: Power Up your Mobile Web App (Room 7)

URLs are People Too - Using the Social Graph API to Build a Social Web (Room 5)

CODE LAB PART 1 (lasts until 4:15) Getting Started with Google App Engine (Code Lab 1) Hands-on YouTube: Creating an Application with the YouTube APIs using Google App Engine (Code Lab 2) Hands-On Maps API: Basic & Advanced (Code Lab 3)

Underneath the Covers at Google: Current Systems and Future Directions (room 8)

OpenSocial (Fireside Chat)

.

4:15pm - 5:15pm

Improving Browsers in New Ways: Gears++ (Room 1) Surprisingly Rockin' JavaScript and DOM Programming in GWT (Room 2)

Working with Google App Engine Models (Room 3) Authenticating to Google Data Services (Room 9)

Maps and Geo Session (Room 6) Parsing and Generating KML with Google's KML Library (Room 7)

OpenSocial at MySpace (Room 4) OpenSocial Across Containers (Room 5)

CODE LAB PART 2 (continued from above)

Introduction to Google DocType: an Encyclopedia of the Open Web (Room 8)

Google Web Toolkit (Fireside Chat)

.

5:30pm - 8:30pm

Birds of a Feather

.

6:00pm - 10:00pm

After Hours Party

.

*All sessions are on a first-come, first-serve basis at the time of the session

.