Posted:




We had the pleasure to talk to some of the Google App Engine team to discuss the recent launch that Dick uses the tagline as "Your apps, our servers". We get to chat with tech lead on the project Kevin Gibbs, product manager Pete Koomen, and Guido van Rossum. I don't think we need to introduce Guido!

The podcast starts out answering why Google App Engine was created, and why Python was chosen as the first language. We then hear about the work that goes into making a language hardened for the platform itself.

Of all of the APIs that we expose in the App Engine back-end, we feel that the Database API is probably the most foreign for the majority of developers. Many are used to the relational model for datastores, and our datastore is different. Kevin talks about these differences, and the ramifications that come with a schema-less store. We then delve into the practicalities of having libraries such as SQL Alchemy support GQL which is a functional subset of SQL.

What about lock-in? This was one of the big questions that came out of the community when we launched App Engine. You can see how open the team is to other solutions, and how they like seeing work such as AppDrop that shows how you can do this. The choice to make the SDK itself fully open source says a lot.

Guido discussed how the Python runtime is indeed the full language, but how some libraries are not there. He talks about the reasons behind the choices, which are mainly related to security. As time goes on more libraries that developers really need will make it into the system, often with equivalent implementations. Although a traditional file system doesn't make sense in the cloud, we could very well see a virtual file system implemented.

We go on to discuss a lot more, including:
  • What restrictions are there for serving your applications?
  • What Web frameworks are available?
  • Can you develop Web services as well as Web applications? How about gadget and widget?
  • What kind of traffic can be expect with the free accounts?
  • Can I run these applications on my domain, and integrate with Google Apps?
If you want to see more of the team and play with App Engine, come by a hackathon when it get to your neck of the woods, or hear more at Google I/O.

You can download the episode directly, or subscribe to the show (click here for iTunes one-click subscribe).

Posted:


Steve Souders, member of the performance group at Google, has released a new open source tool called Cuzillion. Steve was constantly creating sample test web pages that he used to test out theories on Web site performance. He realized that he was repeating a lot of the same steps, so why not create a tool that would enable him to build the samples quickly. Thus, Cuzillion was born.



If you take a look at the UI above, you will see that it is mimicking a Web page, with a <HEAD> and <BODY>. On the left hand side you select types of elements; such as images, scripts, CSS, and other resources. You add these elements to the mini page on the right, and then you can select that element to set more properties on it. For example, you can quickly set the domain that it is running on, which allows you to test splitting our content on domains.

We sat down with Steve and produced the video below in two parts. It starts off with him discussing the project, and then delves into a screencast of the product itself. He gives us an introduction, and then shows how he used it to solve an issue with Orkut.

Posted:


In May, we'll be holding two Google App Engine Hack-a-thons at Google's offices. The first one will be in New York, May 7th, from 10am - 6pm, and the second one in San Francisco, May 16th, 10am - 10pm. This is a great opportunity to get started on Google App Engine. You can code along with us in building an app from start to finish or you can bring your existing apps and get some help and guidance from Google engineers.

Check out the full details of these events and RSVP for either the New York Hack-a-thon or the San Francisco Hack-a-thon. Or both, if you have the frequent flier miles to spare.

Posted:


The AJAX API team just posted about using Flash and the server side to access the AJAX APIs.

This is very exciting, as it now allows you the developer to access not only Google Web Search results, but also query video, images, news, local, and other search functions. Also, this covers the AJAX Feed API which means you can get access to feeds in a normalized manner, and the new AJAX Language API to do translations and language detection.

If you step back, you can see this as a Google REST API, and some of you have wondered how it compares to the SOAP API.

I got to go to the horses mouth, Mark Lucovsky (team lead for the AJAX APIs), to discuss what this new access point is all about, and you may be a little surprised with the content.

We discuss the fact that this has actually been running for quite some time, but we now have clarified it as an official end point for your usage. This also means that it has thorough documentation, which was important as Mark talks about how some people have been using the API incorrectly.

Mark clarifies the terms of use, and you come out of this in the knowledge that his team has been attacking very different problems to the original SOAP API team. He has been ruthlessly practical, as you will understand as he talks about the problems his team are solving, and the breadth of sites that are using these APIs, including some very big names.

Enough of me talking, let's listen to Mark:



Hear more from Mark on the AJAX APIs, Vadim on accessing the APIs outside of AJAX, and Derek on advanced development using AJAX Apis at Google I/O.

Posted:


Google Developer Days 2008, a set of one-day developer events, are back and will take place in locations around the world. We've designed these events for developers with strong coding backgrounds, so that we can discuss our APIs, developer tools and applications.

We'll host Google Developer Day in these locations:
  • Yokohama, Japan (June 10)
  • Beijing, China (June 12)
  • Taipei, Taiwan (June 14)
  • Sydney, Australia (June 18)
  • Mexico City, Mexico (June 23)
  • Sao Paulo, Brazil (June 27)
  • London, UK (Sept 16)
  • Paris, France (Sept 18)
  • Munich, Germany (Sept 23)
  • Madrid, Spain (Sept 25)
  • Milan, Italy (Oct 21)
  • Prague, Czech (Oct 23)
  • Moscow, Russia (Oct 28)
If you're based in the US, we encourage you to come to Google I/O, on May 28-29 in San Francisco.

At Google Developer Day, our engineers will share their inside knowledge on our developer tools and APIs, including Android, OpenSocial, and AppEngine. In many locations we'll do deep dives into code and conduct hands-on codelabs.

We've posted detailed information for our early dates and will be adding more information for other locations soon. If you're a developer, we encourage you to sign-up for a Google Developer Day at a nearby location. Hope to see you there.

Update: Corrected the September 23rd event location from Hamburg, Germany to Munich, Germany.

Posted:


Today, we're excited to open up a developer sandbox for iGoogle. The sandbox includes support for OpenSocial, a common API designed to let you easily build social applications that run on a growing number of web containers. The iGoogle OpenSocial container also supports canvas view, allowing developers to build powerful and feature-rich full-page applications for iGoogle's tens of millions of users.

To get started, please begin with the documentation and examples on the iGoogle developer website. The site includes detailed information about iGoogle and a guide to incorporating the new social features.

Watch as Jake walks us through the sandbox and shows how to build a basic gadget.



Sign up for access to the developer sandbox and keep up-to-date with our new iGoogle Developer Blog.

Happy coding!

Posted:




The big buzz continues to revolve around our Google App Engine launch. We are seeing a host of applications being developed, and were even pleasantly surprised to see people port the APIs allowing you to run App Engine code elsewhere, such as appdrop.com.

One interesting feature to the App Engine which you may not have noticed, is the integration with Google Apps. Not only can you tie an application to your domain (allowing you to have myapp.mydomain.com instead of myapp.appspot.com) but you can restrict access to the given application to only members of your domain. If I ran a company on Google Apps, this would be a nice addition. I could see the small business apps that I need running there.

Jeff Scudder then released a new version of the Google data Python client library which has support for Google App Engine and the Contacts API. If you want to use this in your Google App Engine application you simply need to set gdata.service.http_request_handler = gdata.urlfetch to make sure your requests have a path out!

Google Docs offline, and Gears

I was on the road, speaking about Gears and the Open Web in Europe last week, and it was perfect timing to be mixing with the community as Google App Engine came out and I could talk to that too. We also had a few things to talk about with Gears.

We have been getting lots of questions surrounding our stance with the various standards out there, so Aaron Boodman put down our thoughts on the matter in a piece called Gears and Standards. It talks about how we are working with HTML5, and the direction that you will see Gears going. I think it is incredibly exciting to see people realise how Gears is a lot more than "offline", and is actually an open source way to teach browsers new tricks.

Brad Neuberg talked about just that as well as new features in Gears, and tools to help you get your work done, such as PubTools. He also discussed our first Google Gears for Mobile application, done by the Picasa Team. Now the blokes in London can show off pictures of their kids as they slow poke through the city down in the tube.

The biggest news of all though was the launch of Google Docs offline. If you have ever been in the situation where the internet goes flaky right when you just need that bit of info in document, no more. Now you have the option to save docs locally on your computer, so you can access them no matter where you are.

If you would like a refresher course on how to get started with Gears check out Ben Lisbakken's new screencast.

Fun with Maps

The Geo side of the house continued to output great content, including a series of Geo Developer content:
  • Quick & Dirty KML Creation: With Mano Marks, Pamela Fox, and Christiaan Adams
    A demonstration of creating KML visually in Google Earth & Google Maps, and using Spreadsheet Mapper 2.0
  • Creating Custom Maps: With John Coryat
    A comparison of various ways of overlaying data in the Maps API and an in-depth explanation of creating tile layers and custom map types
  • GigaPan In-Depth: With Randy Sargent & Ted Morse
    A demo of the GigaPan panorama-browsing website and KML files, plus a technical explanation of PhotoOverlay
  • Dynamic KML: With Mano Marks & Brian Hamlin
    An exploration of using dynamic queries from KML, using the NetworkLink, httpQuery, and viewFormat elements, plus a demo of a PostGIS-generated NetworkLink
  • Mars, Moon, and Sky Map Types: With Noel Gorelick
    A talk introducing the non-Earth Maps API map types, plus cool demos of other types of projections used with planetary imagery
  • Mapping the Votes: With Michael Geary
    A whirlwind tour of what it took to create the Elections 2008 Map/Mapplet/Gadget, including SHPfile conversion, Javascript optimization, centroid calculations, Twitter updates collection, Mapplet API tricks, and more.
  • Google API Talks - Android, KML, Google Maps, Gadgets
    A series of 5-minute talks by various developers and Googlers given before Geary's presentation, including an intro to Gadgets/Mapplets.

They were also happy to announce that KML is now a standard, and owned by the Open Geospatial Consortium. We have seen a lot of other sites consume and produce KML, so this is a great step.

Finally, a great new feature was added to Google Maps. You can now check out traffic patterns in the future. If you have a commute the following morning, you can check out an estimate of how stuck you will be based on past experience. Obviously, it can't determine if there will be any crashes or anything like that :)

And there's more...

To finish up, a few other interesting items of the week:

I hope you had a great week. Remember that our big developer event Google I/O is now just a few weeks away! We have a few posts from presenters who will be at the event to give you a little look at the content, but the best part will be having the community together to talk in the open.

Posted:


Bob Lee is a Software Engineer at Google, currently leading up the charge on the core Android APIs. He is also one of the founders of the Google Guice project, and was the interviewee on the very first Google Developer Podcast on the topic.

He also just created a little fun application called Twubble that helps you find potential friends and followers on Twitter. The Twitterati are all over this application, and Biz Stone of Twitter even attributed it as one of a handful of reasons that have driven the rise in followers recently.

This is Bob's first GWT application, so I wanted to sit down and talk to him about why he built the application, his experience with GWT, how he integrated with Twitter, and any other nuggets of information that I could get out of him.

Please, listen in to our conversation, and let us know if you have any questions in the comments:

Posted:


Developers speak lots of languages, not just English and C++. We know that you use Google Code from all over the world, and we understand that the love of a good API is universal.

We're excited to announce that developer content on Google Code is now available in five new languages: Chinese, Japanese, Portuguese, Russian, and Spanish. Many of our pages, such as the site directory and landing pages for the various APIs have already been translated. You will also find that some of the deeper technical documentation, such as the Chart API and Maps API, has also been translated where appropriate. Where we haven't translated the content yet, you will continue to see the English version of the site.

We'll be working to keeping this content up-to-date, and we're looking forward to adding more support for languages and APIs throughout the year.

Update: Corrected to read "in five new languages." The sixth language, of course, is English.

Posted:


This post is one in a series that previews Google I/O, our biggest developer event in San Francisco, May 28-29. Over the next two months, we'll be highlighting sessions and speakers to give Google Code blog readers a better sense of what's in store for you at the event. - Ed.


We recently launched the Google Visualization API, which lets you access multiple sources of structured data that you can display with a large number of different visualizations. The API also provides a platform that can be used to create, share, and reuse visualizations.

For structured data, a big part in making information useful is enabling the visualization and analysis of the data in various ways and manners so we can gather insights from it. From the novice user to the highly trained professional, a chart often provides more insight, faster than any table of data does. Yet the process for matching data to a visualization is still laden with barriers. Integration with specific visualizations is very often an arduous process and finding the right provider of the visual package you need is hard.

The Google Visualization API aims to solve many of these problems. The API is simple to use, making integration quick and painless. Its openness makes it appealing because once a visual component is written it can be used on any supported data source. That means both the visual developer and the data source owner benefit.

By involving the wider developer community we can create a huge inventory of visual applications that fit every need. Just a few weeks after launch, developers have already created interesting visualizations like the piles of money gadget, organizational chart and motion chart.

At Google I/O, our senior engineers will teach you how to quickly and easily write an application using the Google Visualization API. We will work together to build a simple gadget and we will go over the the fine issues and potential pitfalls so you can save yourself even more time when you start writing your own applications over the API.

We also highly recommend you attend the "Advanced Gadget and UI Development Using Google AJAX APIs" session. With the combination of the two, you will have the toolset to making world-class visual applications and gadgets.

We look forward to seeing you at Google I/O in May. In the meantime, come visit us and join the budding, yet growing community using the API.

Posted:


We just concluded tonight's Campfire One, where we launched a preview release of Google App Engine, a way for developers to run their web applications on Google's infrastructure. We're still processing the videos from the event, which will be up shortly.

To learn more about Google App Engine, check out the documentation or read the team's announcement on the Google App Engine Blog.

Posted:


This post is one in a series that previews Google I/O, our biggest developer event in San Francisco, May 28-29. Over the next two months, we'll be highlighting sessions and speakers to give Google Code blog readers a better sense of what's in store for you at the event. - Ed.

Ever since Ajax reemerged to create new exciting Web applications, we have seen a lot of growth in the ecosystem. Who would have thought that the universe would have expanded from richer browser applications to mobile, embedded, widgets, and desktop platforms. You can program it all with the same HTML, CSS, and JavaScript that you know and .... maybe love.

We are excited about what 2008 brings for Ajax applications, and look forward to diving into the action with our session at Google I/O.

At its core we seem to have performance in various very different forms.

Application Speed

We are seeing a lot of focus on making your applications perform well. With leaders like Steve Souders, we have seen how small tweaks to our front end engineering can leave to an improved perceived performance of our applications, which leads to a better user experience. At Google, I have seen first hand, how important latency is to applications, and I am excited to see this trend expanding to the community as a whole.

One part of the puzzle is the browser itself. With new browsers such as IE 8, Firefox 3, and Safari 3.1 come improved performance across the board. We can learn how to make the browsers optimize their downloads in parallel, JavaScript and DOM execution speed.

With some of the features in Gears, such as the Worker Pool, we have also seen significant improvements in performance as you allow the execution to happen outside of the usual browser pipeline.

Even tests like Acid3 have performance benchmarks built-in.

Productivity

Shortly after Ajax was coined, we saw a proliferation of Ajax libraries. Most started out as simple wrappers on top of XMLHttpRequest, but they have grown over time to handle cross browser issues (e.g. hide and abstract differences), with lots of work making DOM manipulation easier. The recent trend has been to move to a CSS based model, lead by jQuery, where you attach behaviour all through CSS selectors.

We have a scientific methodology to determine which library is for you, after extensive research, and just because this is Google I/O do not presume that it always returns GWT!

User Experience

The reason that Ajax took off in our minds isn't due to any magic in XHR, but because it brought a revolution to the user experience of Web sites. Suddenly you could build highly interactive applications, instead of the archaic redraw Web. Imagine a desktop application that redrew the entire application every time you caused an event (such as a mouseclick).

This is where the state of the art continues to thrive. How can we improve the user experience of Web applications? There are many popular applications that showcase new methods, and plenty of bad ones to learn from too.

Standards

HTML 5 is moving along nicely. Understanding the parts and pieces to this world is a glimpse at the future. There are many features that have you saying "at last!", and we will delve into all of these. Gears also fits into the HTML 5 picture, so we can talk to various initiatives in the standards space.

We hope to get a chance to chat with you at the conference!

Posted:


This post is one in a series that previews Google I/O, our biggest developer event in San Francisco, May 28-29. Over the next two months, we'll be highlighting sessions and speakers to give Google Code blog readers a better sense of what's in store for you at the event. - Ed.

Being a UI engineer, I usually expect the features I implement to have a little bit more visual interaction than a little green icon. However, while my team and I were implementing Google Docs Offline, the challenge was just that: how make the offline experience work seamlessly while just adding one icon.



Building Docs Offline was quite a challenge, and we pushed Gears to its limits to accomplish it. To give an idea of some of the complexities, Google Docs is one application that is comprised of 3 editors (documents, spreadsheets, and presentations) and 1 file management UI running across two domains (docs.google.com and spreadsheets.google.com). The domain challenges alone were significant challenges in our design - we are fully utilizing multiple cross-domain workers to synchronize documents, capture resources, and authenticate users.

Oh yeah, and did I mention that any of the servers can be running any version of the code and fall over at anytime?

Getting all of this to "just work" for users was tough, but necessary for a great user experience.

Wondering how you can take your applications offline? I'll be discussing all these issues in-depth at this year's Google developer conference, Google I/O. Come by and learn how to get your app its very own little green syncing icon.

Posted:


On the heels of hi5's OpenSocial launch, this Sunday, the 6th of April, BT is hosting an OpenSocial Hackathon at BT Centre in London. This is an ideal opportunity to get started building apps with OpenSocial, or come and get a hand with an app you've already built. In addition, you'll be able to talk with engineers from Hyves, MySpace, Netlog, studiVZ, XING, and Google.

The event will kick off at 11:00am, though doors will open at 10:00am with a light breakfast. Full details are available here, or you can directly RSVP here.

Posted:




I had the pleasure of taking a trip back to my home land of England to meet up with the team behind the Google Gears for Mobile product.

As someone who loves Web development, it is an exciting proposition to be able to use the Web platform to be able to develop applications on the mobile.

This release enables you to use the Gears 0.3 APIs on Windows Mobile devices. With this new version, not only do you have access to the Database, LocalServer, and WorkerPool APIs, but you can also create desktop shortcuts. Considering the disconnected nature and latency issues inherent to the mobile networks, these APIs allow you to deliver more responsive applications that can hide some of the problems.

Today, we saw the release of a new mobile version of Picasa Web Albums that uses these features. I got to sit down with Joe Walnes, tech lead of the mobile Picasa team. Joe and his team built both the Gears-enabled version of Picasa for the phone as well as the iPhone version that allows you to sit on the Tube and still flip through your family photos.

Joe tells us about his experience building the Gears application.



I have also put together an audio podcast consisting of interviews with not only Joe, but other members of the Gears team.

First, I talk to Charles Wiles, the Product Manager of the Google Gears for Mobile team. He gives us a high level view of the project in general, and this launch in particular. We also discuss the native abilities of Gears on the mobile, widget platforms, and future Gears developments.

Second, we hear from two engineers on the project, Dave Burke and Andrei Popescu. They go into detail on the platform, how you architect mobile Web applications, how you develop and debug applications, new APIs such as the Location API, and how Android fits in to the picture.

Finally, we hear again from Joe Walnes.

I am really excited about the prospect of building rich mobile applications using Web based technology.

You can download the episode directly, or subscribe to the show (click here for iTunes one-click subscribe).

Posted:


The goal of the Google Data APIs is to give developers a consistent (and familiar) way to integrate with Google products. At their heart is Atom and the Atom Publishing Protocol, and we've created extensions on top of those open standards to add features like specifying a calendar schema or authentication protocol.

We've always intended for the Google Data APIs to be open and reusable, and today we've taken an extra step to make that intention clearer. We're giving a no-charge, royalty-free license to any patents we have that you would need to implement Atom, AtomPub, or any of our extensions. The official way to do this was via an intellectual property disclosure to the IETF and the patent license now linked from the Google Data APIs docs.

We hope this will encourage sites who want to expose APIs for things like photos, videos, calendar, or contacts to reuse our schemas where they can, rather than reinventing the wheel. Doing so will make it easier for developers who are integrating with multiple sites or porting over an existing app to a new site.

To learn more, check out the Google Data APIs Blog or dive into the patent license itself. Also, be sure to register for the Google I/O conference. I'll be giving a talk there about Google Data APIs, and there will be opportunities for deeper discussions and direct interaction with the engineering team.