Saturday, March 13, 2010

[Gd] Upcoming Wave Developer Events

| More

Google Wave Developer Blog: Upcoming Wave Developer Events

Now that the new Wave Robots API is launched, we're excited to spread the word about Wave to developers in all corners of the world. Please join us in one of the upcoming events:

Chicago GTUG Google Wave & Android Workshop
  • March 13, 9-5pm
  • Chicago, Illinois

Google Hackathon @ SXSW Interactive
  • March 14, 12pm
  • Austin, Texas

SF Wave Meetup
  • March 16, 6:30pm
  • San Francisco, CA

Novell Brainshare
  • March 23 and March 25
  • Salt Lake City, Utah

DevFest Mexico
  • April 13, All day
  • Mexico City, Mexico

EJA Melbourne Forum
  • April 21, 5pm
  • Melbourne, Australia

Posted by Pamela Fox, Developer Relations

Friday, March 12, 2010

[Gd] Google is hiring SETs

| More

Google Testing Blog: Google is hiring SETs

Drop me a resume and a brief note if you're interested in joining Google as an SET. email: Thanks -- Patrick Copeland

When we hire people we look for folks with a "testing DNA." These are people who are great computer scientists at their core, but also are very curious, love software, and are passionate about test engineering. People who have those characteristics tend to pursue challenges and continue to learn. Are you one of us? We have positions all over the US and the world.

What is a SET?
At Google, Software Engineers in Test (SET) develop test frameworks and build robust, scalable, and effective tests. SETs spend a majority of their time coding in either C++, Java, or scripting in Python. A SET is a software engineer, a core developer, who has a passion for test engineering.

How is testing done differently at Google?
  • Literally within milliseconds of a code check-in, our build process will automatically select the appropriate tests to run based on dependency analysis, run those tests and report the results.
  • By reducing the window of opportunity for bad code to go unnoticed, overall debugging and bug isolation time is radically reduced. The net result is that the engineering teams no longer sink hours into debugging build problems and test failures.
  • Development teams write good tests because they care about the products, but also because they want more time to spend writing features and less on debugging.
  • Testing teams focus on higher abstractions, like identifying latencies, system or customer focused testing, and enabling the process with tools.
  • SETs avoid becoming codependents within this system and generally do not write unit tests or other activities that are best done by the developer.
More about SETs
  • Our SET’s spend time developing code to prevent bugs. Google has a strong cultural emphasis on developers improving quality (i.e. unit tests, code reviews, design reviews, root cause analysis). We want our engineers to spend their time innovating - not fixing bugs.
  • SETs enable products to launch faster. They have great influence over internal processes and how developers write code.
  • One of Google's less understood capabilities is our massive distributed computing environment. The testing groups exploit this infrastructure to do huge amounts of work very quickly and elegantly.
  • For someone who wants to learn and grow as an engineer, the uninhibited access to the entire code base is a unique opportunity.

[Gd] Coming soon: Gmail contextual gadgets available for trusted testers

| More

Google Code Blog: Coming soon: Gmail contextual gadgets available for trusted testers

At Campfire One this week we announced that we will soon open Gmail contextual gadgets as a new extension point for developers. These gadgets can smartly draw information from the web and let users perform relevant actions based on the content of an email message, all without leaving the Gmail inbox. For instance, contextual gadgets currently available in Gmail can detect links in emails to show previews of documents, videos, photos, and more, right inside the messages.

For businesses, Gmail contextual gadgets can boost employee productivity by complementing email in a context-specific and actionable way. Appirio, a cloud solution provider, provided a demonstration of the potential of Gmail contextual gadgets and other experimental features
with their new product PS Connect:

Soon we’ll be opening Gmail contextual gadgets as an extension for trusted testing by developers. If you have a good idea for this type of gadget today, please fill out this form. And for those of you who will be attending Google I/O in May, be sure to check out our session on building Gmail contextual gadgets.

By Dong Chen, Gmail Contextual Gadgets team

[Gd] Integrating with Google Apps using Gmail contextual gadgets

| More

Google Apps Developer Blog: Integrating with Google Apps using Gmail contextual gadgets

At this week’s Campfire One event, we launched the new Google Apps Marketplace, making it easier for you to create applications that integrate deeply with Google Apps and sell them to the more than 2 million businesses and 25 million people who use Google Apps.

In addition to the many integration points currently available for Google Apps, like the Google Data APIs, we announced that we will soon open Gmail contextual gadgets as a new extension point for developers. These gadgets can smartly draw information from the web and let users perform relevant actions based on the content of an email message, all without leaving the Gmail inbox. For instance, contextual gadgets currently available in Gmail can detect links in emails to show previews of documents, videos, photos, and more, right inside the messages.

For businesses, Gmail contextual gadgets can boost employee productivity by complementing email in a context-specific and actionable way. Appirio, a cloud solution provider, provided a demonstration of the potential of Gmail contextual gadgets and other experimental features with their new product PS Connect:

Appirio PS Connect shows how Gmail contextual gadgets can draw data from different web applications into relevant email messages, enabling users to make faster and more informed business decisions as they go through their inbox.

Soon we’ll be opening Gmail contextual gadgets as an extension for trusted testing by developers. If you have a good idea for this type of gadget today, please fill out this form. And for those of you who will be attending Google I/O in May, be sure to check out our session on building Gmail contextual gadgets.

Posted by Scott McMullan, Google Apps Partner Lead, Google Enterprise team

[Gd] How to integrate with Google Apps and get listed on Google Apps Marketplace

| More

Google Apps Developer Blog: How to integrate with Google Apps and get listed on Google Apps Marketplace

On Tuesday we launched the Google Apps Marketplace at Campfire One and were joined by over 50 developers who built some great applications which are now available to the 2 million businesses and 25 million users that use Google Apps. We're just getting started and can't wait to see what other amazing apps are out there.

If you already have a great web app or even just an idea for one and would like to learn more about integration with Google Apps, join us for a webinar next Wednesday. We'll review the Marketplace and Google Apps APIs and answer technical and policy questions from attendees.

Integrate with Google Apps and the Google Apps Marketplace
Wednesday, March 17, 2010
9:00 a.m. PDT

This webinar will include a question and answer session. Post and vote for questions ahead of time and register for the webinar here. We hope you'll join us for this informative online event.

[Gd] App Engine Community Update

| More

Google App Engine Blog: App Engine Community Update

It's been a while since the last community update post, and you've probably been wondering what the App Engine community has been up to over the holiday period. There's been a lot of activity, so without further ado, here's your community update.

Open Source Projects

There were a lot of new App Engine Open Source projects released since the last update, for both Java and Python, and including everything from libraries to complete working apps.

gdispatch is an extension to the Python webapp framework that allows you to embed routes alongside your request handlers. SUAS is a Python library that provides straightforward authentication and session management for App Engine apps. If you're looking for a complete, lightweight framework, tipfy might be what you're looking for - it bills itself as "a cute little Python framework for App Engine which follows the basic concepts of and webapp".

The Java community has been even busier, with members releasing simpleds and Objectify, both of which provide alternative interfaces to the App Engine datastore for those of you who prefer systems designed specifically with App Engine's datastore in mind over JPA or JDO. For your unit testing needs, there's Kotori Web JUnit Runner, which allows you to run JUnit unit tests in production. Finally, appleguice provides a sample application demonstrating how to integrate Guice dependency injection with GWT and App Engine.

Interesting Apps

The last few months have also seen a plethora of App Engine based apps released, many of which provide source code so you can deploy your own, or contribute to their development. We've picked out a few that we think you'll find of interest.

JobTracker is a Python app that provides an interface to allow tracking working hours and tasks in your team, and is licensed under the APL 2.

Nimbits provides a time series service on App Engine, allowing you to record regular measurements - be they server latencies or fishtank temperatures - and process and export them via APIs or a web interface.

nxdom is an interface designed to make picking the domain name for your next project easier; it operates on lists of recently expired domains, and its Python source is freely available.

OpenShare is a new banner exchange service targeted at open source projects; it's written in Python and is available under the GPL 2.

If you're feeling nostalgic, z-machine lets you play interactive text games through a browser interface, or over XMPP. You can even save a game in one interface, and continue playing in the other. If you're inspired by this, the Parchment project implements a z-machine interpreter in pure Javascript.

Worried about your app when out and about? App Engine Watch is an Android app that lets you monitor your app's quotas from your phone.

A lot of projects have centered around Twitter integration, with Pulse of the Planet letting you visualize tweets in real time on a map, while Lazytweet provides a friendly interface for convincing other people to do your work for you (or doing their work for them, if you're feeling generous). Tweet Engine makes tweeting using a shared Twitter account easier by allowing you to share an account with your group without needing to give them all the account password. It's also open source - you can get the source here and deploy your own, or just use the live instance at

If that's still not enough microblogging for you, TypePad has released TypePad Motion, their open source community micro-blogging app. It's available here.


If your favorite language isn't Java or Python, that doesn't mean you're out of luck. As long as there's an implementation on the JVM, you can use it on App Engine! Several projects are improving integration between App Engine and other JVM languages.

This post discusses how to use Clojure on App Engine, while this post covers using Quercus - a PHP implementation for the JRE - with App Engine task queues. Finally, if Groovy is your language of choice, definitely give the gaelyk project a look, and if you prefer JavaScript, take a look at appenginejs.


Many bloggers continue to turn out insightful and useful posts relating to App Engine. Here's a few that caught our eye:

If all the Twitter related projects interested you, and you're wondering about implementing your own, this article on building feedertweeter and this article on using Twitter's OAuth API on App Engine are probably of interest.

There's an excellent blog post on about practical use of geohashing for geospatial apps on App Engine.

Just about everything on the gaejexperiments blog is worth a read if you're a Java coder. Recent posts cover topics such as using reCAPTCHA, using the Java blobstore API and using the task queue.

The Django-nonrel folks are showing some impressive progress - see their post on how to deal with noSQL databases, and read their blog for more information.

The wolfire blog has a great post on how AppScale helps prevent App Engine 'lock-in'. If you want to learn more, this post on the IBM developerworks site goes into more detail about AppScale.

If you want to keep up with blogs, articles, and news about App Engine, the App Engine reddit should be your first port of call. And if you want to see your own post or project up here, submit it to the reddit, or mention it in the groups!

Posted by Nick Johnson, App Engine Team

[Gd] Working with multi-regional websites

| More

Official Google Webmaster Central Blog: Working with multi-regional websites

Webmaster Level: Intermediate

Did you know that a majority of users surveyed feel that having information in their own language was more important than a low price? Living in a non-English-speaking country, I've seen friends and family members explicitly look for and use local and localized websites—properly localized sites definitely have an advantage with users. Google works hard to show users the best possible search results. Many times those are going to be pages that are localized, for the user's location and/or in the user's language.

If you're planning to take the time to create and maintain a localized version of your website, making it easy to recognize and find is a logical part of that process. In this blog post series, we'll take a look at what is involved with multi-regional and multi-lingual websites from a search engine point of view. A multi-regional website is one that explicitly targets users in various regions (generally different countries); we call it multilingual when it is available in multiple languages, and sometimes, the website targets both multiple regions and is in multiple languages. Let's start with some general preparations and then look at websites that target multiple regions.

Preparing for global websites

Expanding a website to cover multiple regions and/or languages can be challenging. By creating multiple versions of your website, any issues with the base version will be multiplied; make sure that you have everything working properly before you start. Given that this generally means you'll suddenly be working with a multiplied number of URLs, don't forget that you'll need appropriate infrastructure to support the website.

Planning multi-regional websites

When planning sites for multiple regions (usually countries), don't forget to research legal or administrative requirements that might come into play first. These requirements may determine how you proceed, for instance whether or not you would be eligible to use a country-specific domain name.

All websites start with domain names; when it comes to domain names, Google differentiates between two types of domain names:
  • ccTLDs (country-code top level domain names): These are tied to a specific country (for example .de for Germany, .cn for China). Users and search engines use this as a strong sign that your website is explicitly for a certain country.
  • gTLDs (generic top level domain names): These are not tied to a specific country. Examples of gTLds are .com, .net, .org, .museum. Google sees regional top level domain names such as .eu and .asia as gTLDs, since they cannot be tied to a specific country. We also treat some vanity ccTLDs (such as .tv, .me, etc.) as gTLDs as we've found that users and webmasters frequently see these as being more generic than country-targeted (we don't have a complete list of such vanity ccTLDs that we treat as gTLDs as it may change over time). You can set geotargeting for websites with gTLDs using the Webmaster Tools Geographic Target setting.

Geotargeting factors

Google generally uses the following elements to determine the geotargeting of a website (or a part of a website):
  1. Use of a ccTLD is generally a strong signal for users since it explicitly specifies a single country in an unmistakable way.
    Webmaster Tools' manual geotargeting for gTLDs (this can be on a domain, subdomain or subdirectory level); more information on this can be found in our blog post and in the Help Center. With region tags from geotargeting being shown in search results, this method is also very clear to users. Please keep in mind that it generally does not make sense to set a geographic target if the same pages on your site target more than a single country (say, all German-speaking countries) — just write in that language and do not use the geotargeting setting (more on writing in other languages will follow soon!).
  2. Server location (through the IP address of the server) is frequently near your users. However, some websites use distributed content delivery networks (CDNs) or are hosted in a country with better webserver infrastructure, so we try not to rely on the server location alone.
  3. Other signals can give us hints. This could be from local addresses & phone numbers on the pages, use of local language and currency, links from other local sites, and/or the use of Google's Local Business Center (where available).

Note that we do not use locational meta tags (like "geo.position" or "distribution") or HTML attributes for geotargeting. While these may be useful in other regards, we've found that they are generally not reliable enough to use for geotargeting.

URL structures

The first three elements used for geotargeting are strongly tied to the server and to the URLs used. It's difficult to determine geotargeting on a page by page basis, so it makes sense to consider using a URL structure that makes it easy to segment parts of the website for geotargeting. Here are some of the possible URL structures with pros and cons with regards to geotargeting:

Subdomains with gTLDs
eg:,, etc.
Subdirectories with gTLDs
eg:,, etc.
URL parameters
eg:, ?country=france, etc.
pros (+)
- clear geotargeting
- server location is irrelevant
- easy separation of sites
- legal requirements (sometimes)
pros (+)
- easy to set up
- can use Webmaster Tools geotargeting
- allows different server locations
- easy separation of sites
pros (+)
- easy to set up
- can use Webmaster Tools geotargeting
- low maintenance (same host)
pros (+)
(not recommended)
cons (-)
- expensive (+ availability)
- more infrastructure
- ccTLD requirements (sometimes)
cons (-)
- users might not recognize geotargeting from the URL alone (is "de" the language or country?)
cons (-)
- users might not recognize geotargeting from the URL alone
- single server location
- separation of sites harder
cons (-)
- segmentation based on the URL is difficult
- users might not recognize geotargeting from the URL alone
- geotargeting in Webmaster Tools is not possible

As you can see, geotargeting is not an exact science (even sites using country-code top level domain names can be global in nature), so it's important that you plan for the users from the "wrong" location. One way to do this could be to show links on all pages for users to select their region and language of choice. We'll look at some other possible solutions further on in this blog post series.

Dealing with duplicate content on global websites

Websites that provide content for different regions and in different languages sometimes create content that is the same or similar but available on different URLs. This is generally not a problem as long as the content is for different users in different countries. While we strongly recommend that you provide unique content for each different group of users, we understand that this may not always be possible for all pages and variations from the start. There is generally no need to "hide" the duplicates by disallowing crawling in a robots.txt file or by using a "noindex" robots meta tag. However, if you're providing the same content to the same users on different URLs (for instance, if both "" and "" show German language content for users in Germany), it would make sense to choose a preferred version and to redirect (or use the "rel=canonical" link element) appropriately.

Do you already have a website that targets multiple regions or do you have questions about the process of planning one? Come to the Help Forum and join the discussion. In following posts, we'll take a look at multi-lingual websites and then look at some special situations that can arise with global websites. Bis bald!

Written by John Mueller, Webmaster Trends Analyst, Google Switzerland

[Gd] Introducing the Google Wave Extensions Gallery

| More

Google Wave Developer Blog: Introducing the Google Wave Extensions Gallery

We've just rolled out an initial version of our extensions gallery: simply look for "Extensions" in the navigation panel of Google Wave. The gallery is intended to make it easier for users to discover the fun and useful extensions you all are building with the Google Wave APIs.

The gallery is simply a set of waves containing extension installers (the puzzle pieces). The first wave, "Read me first" contains an introduction to extensions and how to use them. In many cases, those particular waves won't maintain their read/unread status in Google Wave preview; we're working on this. Beyond that, we have some design improvements in the works, but we wanted to get this out there to get feedback and help users find your extensions.

As a tip, you can also use the waves in the gallery to share a direct link to your extension's installer with other Google Wave users -- simply open the installer and copy-and-paste the URL (note: the panel arrangement and search query are included in the URL, but can easily be edited out).

While you're building your extensions, if you'd like them to be included in the gallery, please be sure to submit them for review. You may also want to check out Mashable's Google Wave API Challenge.

We look forward to seeing what you come up with -- especially with the new Google Wave robots API (v2).

Posted by Dan Peterson, Product Manager, Google Wave

Thursday, March 11, 2010

[Gd] Microdata support for Rich Snippets

| More

Official Google Webmaster Central Blog: Microdata support for Rich Snippets

Webmaster Level: All

HTML5 is the fifth major revision of HTML, the core language of the World Wide Web. The HTML5 specification includes a description of microdata, a new markup standard for specifying structured information within web pages.

Today, we’re happy to announce support for microdata for use in rich snippets in addition to our existing support for microformats and RDFa. By using microdata markup in your web pages, you can specify reviews, people profiles, or events information on your web pages that Google may use to improve the presentation of your pages in Google search results.

Here is a simple HTML block showing a section of a review of “L’Amourita Pizza”:

<h1>Review: L’Amourita Pizza</h1>
Written by Bob Smith
Jan 15, 2010
Rated <b>4.5</b> - Excellent

Here is the same HTML with microdata added to specify the restaurant being reviewed, the author and date of the review, and the rating:

<div itemscope itemtype=””>
<h1>Review: <span itemprop=”itemreviewed”>L’Amourita Pizza</span></h1>
Written by <span itemprop=”reviewer”>Bob Smith</span>
<time itemprop=”dtreviewed” datetime=”2010-01-15”>Jan 15, 2010</time>
Rated <b itemprop=”rating”>4.5</b> - Excellent

Microdata has the nice property of balancing richness with simplicity. As you can see, it’s easy to add markup to your pages using a few HTML attributes like itemscope (to define a new item), itemtype (to specify the type of item being described), and itemprop (to specify a property of that item). Once you’ve added markup to a page, you can test it using the rich snippets testing tool to make sure that Google can parse the data on your page.

As with microformats and RDFa, the vocabulary that we support -- including which item types and item properties are understood by Google -- is specified in our rich snippets documentation as well as on Marking up your content does not guarantee that rich snippets will show for your site; Google will expand the use of microdata markup gradually to ensure a great user experience.

To get started, here are some helpful links:

Written by Siddhartha Chattopadhyay, Kavi Goel, Ramanathan V. Guha, Pravir Gupta, Othar Hansson

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 5.0.342.3 for Windows, Mac and Linux platforms

This release improves stability and fixes some known crashers (such as Issues: 370353767437567)

Known Issues
  • All:  Form auto-fill is not enabled by default (Issue 37466) - Fixed on Trunk
  • Windows: Browser crashes on quiting with Authentication dialog opened (Issue: 37698)  - Fixed on Trunk
  • Linux: Chromium Bookmark Sync Not Working (Issue: 36460)
More details about additional changes are available in the svn log of all revisions.

You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

Karen Grunberg
Google Chrome

[Gd] Does Your Browser Behave?

| More

Chromium Blog: Does Your Browser Behave?

Last June, we launched the Sputnik JavaScript conformance test suite, a comprehensive set of more than 5000 tests. Today we're releasing a test runner for Sputnik, that allows you to easily run the complete test suite from within your browser.

Sputnik touches all aspects of the JavaScript language defined in the 3rd edition of the ECMA-262 spec. In many ways it can be seen as a continuation of and a complement to existing browser conformance testing tools, such as the Acid3 test. While we are always focused on improving speed, Sputnik is not about testing how fast your browser executes JavaScript, but rather whether it does so correctly.

Since we released the Sputnik tests as an open source project, the most requested feature has been the ability to run the tests in a browser, and we are excited to launch that functionality today. The new test runner lets you run the tests from a single URL and quickly see the results in your browser. This makes it easier both for users to see how well their browser conforms to the JavaScript spec, as well as for browser makers to find bugs and incompatibilities.

You can also use Sputnik to compare browser conformance. For example, below is an experimental plot that compares five popular browsers and which we hope to update as new stable versions of the browsers are released. We created this chart by running Sputnik in each of the five browsers and then plotting each browser such that the fewer tests a browser fails the closer it is to the center and the more failing tests two browsers have in common the closer they are placed to each other. In this example, when running Sputnik on a Windows machine, we saw the following results: Opera 10.50: 78 failures, Safari 4: 159 failures, Chrome 4: 218 failures, Firefox 3.6: 259 failures and Internet Explorer 8: 463 failures.

When we first released the Sputnik test suite we noted that to be compatible with the web you sometimes had to be incompatible with the JavaScript spec. Since then a new version of the spec, ECMAScript 5, has been released. Besides introducing a number of new language features, ECMAScript 5 changes how many existing features are defined to bring them in line with how they are used on the web. We are updating the Sputnik tests to reflect those changes so that 0 failures would mean not only compatibility with the spec but also compatibility with the web.

We are excited to see the efforts on conformance testing by other browser makers. For example, where Sputnik tests the language features in ECMAScript 5 which were also present in ECMAScript 3, Microsoft's es5conform project tests the new language features that were added in ECMAScript 5.

Incompatibilities between browsers remain one of the biggest challenges for web developers. We hope that giving users and browser vendors an easy way to test their browser will help promote browser robustness and compatibility across the industry.

Posted by Christian Plesner Hansen, Software Engineer

Wednesday, March 10, 2010

[Gd] Windows Beta Update

| More

Google Chrome Releases: Windows Beta Update

The Google Chrome Beta channel for Windows has been updated to

This release fixes a few UI and installer issues:

More details about additional changes are available in the svn log of all revision.

--Orit Mazor, Google Chrome Team

[Gd] Publish your scripts to the Apps Script Gallery

| More

Google Apps Developer Blog: Publish your scripts to the Apps Script Gallery

Today, we are excited to make Google Apps Script available to everyone. Some of you may already be familiar with Google Apps Script within Google Apps, but in case you are new to it, Google Apps Script provides a powerful and flexible scripting environment that lets you automate actions across your spreadsheets, sites, calendars, and many other services.

An important new feature of Apps Script is a script gallery, where developers can easily publish their scripts to make them accessible to everyone. You can find the gallery by going to Insert and then selecting any Google spreadsheet.

Recently, the Google Apps team in New York put together a Movie Night script to help us easily figure out which movies were playing nearby and vote for our favorites - you can read more about it here.  Let’s take a closer look at how the script works and how we published it to the new Apps Script Gallery.

We start by bringing up the script editor from a spreadsheet (Tools -> Scripts -> Script editor...).

The first step is to fetch a list of movies playing in a given area at a given time.  We use the Google search results for a movie query as follows:

varresults = UrlFetchApp.fetch(''+
             zipcode +'&dq=movies&sort=1').getContentText();
vardoc = Xml.parse(results,true);

We can then use Apps Script’s handy Xml service to parse the results.  The next step is to send an email to our friends asking them to vote.  This is the slightly tricky part:

  1. In the spreadsheet, select Form -> Create a form to open the form creation window.
  2. Add two questions, one titled “Movie”, and the other “Attendee” - we don’t care too much about any other text as it will all be replaced by the script at run-time.
  3. Close the form creation window.
  4. In the spreadsheet, select Form -> Go to live form, and copy the ‘formkey’ parameter from the address bar.
  5. Open the script in the editor, and insert the ‘formkey’ into line 2 of the script.

Phew!  That was the tricky part.  In summary, we just created a form for the spreadsheet, but instead of using that form directly, we’re going to use a form that is dynamically generated by the script.  However, we still need the special key to correctly route submissions to the spreadsheet (and to validate those submissions).

After that, we can put together a list of recipients by calling the contacts service and reading the Gmail ‘Friends’ group:

varcontactGroup = ContactsApp.findContactGroup(’System Group: Friends’);
varpeople = contactGroup.getContacts();
Lastly, we put the movie thumbnails and descriptions in the email body - tailored to each recipient, so that we’ll know who voted:

varemailBody = "";
for(variinmovies) {
 // add the image, title etc to emailBody (as HTML)
varaddresses = getFriends_();
for(variinaddresses) {
 var email = email_header + form_key + emailBody + email_footer;
 MailApp.sendEmail(addresses[i],"Movie tonight?", "", {htmlBody: email});

Check out the documentation and get started building your scripts - we look forward to seeing your gallery submissions.  To share your masterpiece with the world, select Share -> Publish Script...from the script editor - it's that easy!

Also, for those attending Google I/O this year, be sure check out the Google Apps Script talk on the Enterprise track.

Posted by Nikhil Singhal, Google Apps Script Engineer

[Gd] Dito Directory integration with Google Apps

| More

Google Apps Developer Blog: Dito Directory integration with Google Apps

Editor's Note: This post was written by Jim McNelis and Vinay Thakker of Dito, a provider of Google Apps deployment, training, integration, and support services, and makers of Dito Directory. We invited Dito to share their experiences building an application for the Google Apps Marketplace on top of Google Apps utilizing some of our APIs. You can meet Dito at Google I/O May 19 - 20 in San Francisco where they will be in the Developers Sandbox.

The Google Apps Marketplace is a great sales channel that allows us to market our products to millions of Google Apps users. Dito Directory for Google Apps is just the first step for Dito's custom application development on Google technologies like Google App Engine, Google Apps APIs, and Google Web Toolkit. We are excited that Google is now providing us with an advantageous delivery platform for 3rd party apps.

Dito, an IT solution provider specializing in Google Apps, was founded in 2007 by brothers Jim and Dan McNelis to help small and medium sized business enhance their IT infrastructure with cloud-based solutions. Since then, upwards of 40% of our customers have found us on the Google Apps Marketplace, so it was a logical choice to list our application there as well.

The Google Apps Marketplace allows domain administrators to install Dito Directory with a couple easy clicks, making the purchase as painless as possible. Dito Directory uses OpenID for user authentication, which means no additional login is necessary. Once installed via the Marketplace, Dito Directory becomes accessible instantly for Google Apps users via Google's universal navigation.

Dito Directory was developed as a result of customer demand for better contact management. We make it easy to import your existing contacts in bulk via the Google Spreadsheets API, which polls an admins spreadsheets and allows them to easily import existing contacts. As with all of our interactions with user and company data, we leverage 2-legged OAuth for authentication and OpenID for single sign-on. This allows our application to safely and securely access your information without the risk of compromising it to 3rd parties.

Sometimes, Google Apps users need more direct access to a domain shared contact's information. With the "Copy to My Contacts" feature in Dito Directory, admins and users can copy any domain shared contact to their personal contacts, instantly. If a users contacts are synced with their mobile device, the contact will show up on their device nearly as fast. Dito Directory interacts directly with a users contacts via the Contacts API.

Enough about the what and the why...let's talk about how we developed Dito Directory. For that, Vinay Thakker, our Google App Engine-eer, is going to give you his perspective.

Leveraging Google scalability

A week before the launch, we decided to gut the app and start fresh. Despite my successes with application architecture in the past, there was one big thing, from a developer's standpoint, that I didn't like with our first attempt:

It didn't scale well.

Of course, I mean that in terms of adding features to it, since App Engine effortlessly handles the load distribution and scaling for us. As the client-side of our app grew, its statefulness became exponentially more difficult to manage. Most of our widgets needed to know about the state of other widgets. Generally, for UI elements, we do this using events. The number of event handlers required to obtain complete state communication in the application grows like the graph of a factorial with each additional widget (no kidding, it's painful).

My initial design was the bomb, though. So, why change?

The ease of using GWT makes developing event handlers a breeze, so in the beginning you may not realize what you're signing yourself up for. You can make a monstrous improvement by centralizing your event bus. In doing this, you should consider using the command pattern design. It's benefits are ridiculously awesome, and how you would implement it is probably better to be left to Wikipedia to explain, since that's what I would paraphrase.

Browser history and state related issues

The second big thing that helped us was when we decided to account for browser history. You have to do this from the beginning of your design, but the good news is it's freakin' easy to implement. I'll show you how in a minute, but first let me mention that implementing GWT's History class is a forcing function for state in your application. By virtue of implementing history across our application, we solved 91% of our state-related issues. On top of that, the user gets their beloved back and forward browser buttons back, as well as some other cool stuff, like the ability to bookmark and link to states of Directory. Using GWT's built-in History class is a two-and-a-half step process. Here's how you do it:

Step 1: Create a class that implements the HistoryListener interface. It's really just one function, onHistoryChanged, in which you tell the app how it should render itself, based on the incoming state. Make it short; have your main class that does onModuleLoad implement HistoryListener.

public class MyApp implements EntryPoint, HistoryListener

public void onModuleLoad()
public void onHistoryChanged(String historyToken)
}// MyApp

Step 2: Tell the History class that you have a class that wants to listen to changes in the History state. Let's do this in onModuleLoad(). Also, you can choose to fire off the current history state so your onHistoryChange method from above gets called on load. If it makes sense for your app, force it into an initial state, also shown here.

public void onModuleLoad()
if (History.getToken().isEmpty())


Step 2.5: This isn't really a step. This part belongs to all of the development you would have been doing anyway. This is where you actually add code to your onHistoryChanged method to make it do something useful based on the state.

public void onHistoryChanged(String historyToken)
if (“myInitialState”.equals(historyToken))
// render the app appropriately for this state.
// this state is accessible at thisPage.html#myInitialState
if (“myOtherStateName”.equals(historyToken))
// render it another way..

You can see how this would force state on your app. You'll find that in a lot of cases, you will be able to use traditional anchor links where you might have otherwise created a new Java function and binded it to the onClick event of some object or widget.

Cool stuff. Let us know what you think, or ask Vinay a question, email

Tuesday, March 9, 2010

[Gd] Integrate, Publish, Sell - The Google Apps Marketplace

| More

Google Code Blog: Integrate, Publish, Sell - The Google Apps Marketplace

The Google Apps Marketplace, announced this evening at Campfire One, allows you to publish applications which integrate with Google Apps and sell them to more than 2 million businesses. Listing your integrated cloud app on the Google Apps Marketplace enables it to have seamless OpenID-based single sign-on with Google Apps, OAuth-authorized access to Google Apps data and makes it easy for customers to access your application from Google Apps' universal navigation bar.

There are three simple steps for a Google Apps Marketplace application:
1) Have or create a cloud application and host it on the platform of your choice
2) Integrate your cloud app with Google Apps using available APIs
3) Create a manifest file describing your application and list it for sale on the Marketplace

The Google Apps Marketplace launched with more than 50 applications from companies like Intuit and Atlassian, with more coming soon from companies like NetSuite and SuccessFactors. We hope you'll join them by integrating with Google Apps and selling your applications on the Google Apps Marketplace to our more than 25 million users and 2 million businesses.

For more information on the Google Apps Marketplace, please see our post on the new Google Apps Developer blog. You can also dive into the details of how to sell your application in the Google Apps Marketplace by visiting our Developer Programs site and technical documentation. And if you'll be at Google I/O this year, you can learn first-hand from the team in the Google Apps sessions on May 19-20 in San Francisco.

Check out the Campfire One announcement on YouTube:

By Ryan Boyd, Google Apps Marketplace Team

[Gd] Reach New Customers: Integrate with Google Apps in the Google Apps Marketplace

| More

Google Apps Developer Blog: Reach New Customers: Integrate with Google Apps in the Google Apps Marketplace

At tonight's Campfire One, we launched the Google Apps Marketplace, to make it easier for you to create applications that integrate deeply with Google Apps, and give you access to our more than 2 million businesses and 25 million Google Apps users.

App integration is accomplished using existing standards such as OpenID, OAuth and Atom Publishing Protocol. The purchase experience is a simple "Add it now" button that streamlines provisioning and data authorization steps for admins, and it gives end users a link to your app in their Google universal navigation bar for one click access and single sign-on.

So what does it take to offer an integrated app for sale in the Google Apps Marketplace?
1) Have or create a business-related cloud application, on the hosting platform of your choice
2) Integrate your cloud app with Google Apps by:
3) Create a manifest file which will drive your app installation flow and subsequent life cycle (URLs for setup, configuration, support and login, as well as which Google Data APIs the application requires), pay a $100 one-time listing fee, and submit it.

Once your application is approved it is easily discoverable by the millions of Google Apps customers. And in return for a streamlined purchase and install process, and integration features exclusive to installable apps, we ask to share 20% of your revenue from new customers. Our billing service, coming soon, is designed to be flexible enough to accommodate both established developers and brand new startups, and will automatically manage the Marketplace's revenue share fees. It will enable users to buy directly from the Marketplace using their existing Checkout account, and offer a unified bill for all purchases. Until this service is available, you can use your existing billing and payment mechanism for your app. For more details on how revenue sharing will work and when it will become a requirement, see the marketplace billing policy.

More than 50 developers have already integrated their apps with Google Apps and have made them available in the Google Apps Marketplace. We hope you will join them and we can't wait to see what new & innovative applications you will bring to the market. And if you're also a Google Apps customer, check these great apps out.

If you haven't already, watch the Campfire One event on YouTube:

Posted by Steve Bazyl, Google Apps Marketplace Team

[Gd] YouTube Direct for Mobile, and Other Updates

| More

YouTube API Blog: YouTube Direct for Mobile, and Other Updates

Since launching YouTube Direct last November, our team has been hard at work adding new functionalities, fixing bugs, and answering developer's questions. We wanted to take a momentary break from all that to share some updates.

Separate from but related to the main YouTube Direct project are two other Google Code projects: video capture and YouTube Direct upload applications for the Android and iPhone operating systems. These two projects are basic implementations that we hope will inspire organizations to add video capture and YouTube Direct upload functionality to their Android or iPhone applications.

We've been gradually, and quietly, checking in various bug fixes and enhancements to the current release's Subversion repository on Google Code. One recent change is especially important, as it adds support for the new video page URLs that will start becoming more common. Periodically, we package the current release into a new "tagged" release, and generate release notes summarizing what's new. If you haven't updated your YouTube Direct codebase recently, we strongly suggest that you read the release notes and perform a sync with our code repository. Starting with the next YouTube Direct release, we will send email announcements to the low-traffic, announce-only Google Group. We recommend that all developers using YouTube Direct sign up to the group — actually, all YouTube API users should sign up to receive periodic important notifications.

Many organizations, in addition to our launch partners, have deployed YouTube Direct on their websites since our launch, and we wanted to highlight a few here.

Gannett rolled out a company-wide initiative in honor of Black History month, in which they ask people to interview civil rights heroes via video. Al-Jazeera invited the community to share their thoughts and experiences around Hajj, the annual Muslim pilgrammage to Mecca. And if you have news videos around any of the big stories of the day, ITN News wants them. Even Tufts University is using YouTube Direct to solicit personal videos from the community called "You, in One Minute".

As always, the best resource for developers looking to embed YouTube Direct functionality on their website is our Getting Started Guide. If you have any technical questions about YouTube Direct, our YouTube API Developer's Google Group is the place to turn.

-Jeff Posnick on behalf of the YouTube Direct Team