Tutorial

Editor’s Note: Guest author Mark Showalter is a Senior Research Scientist at the SETI Institute. — Arun Nagarajan

In 2011 and 2012, while studying the region around Pluto with the Hubble Space Telescope, I discovered the dwarf planet’s fourth and fifth known moons. Like all new astronomical objects, they started out with rather prosaic names — “S/2011 (134340) 1” and “S/2012 (134340) 1”, or, for short, P4 and P5.

I soon found my inbox stuffed with hundreds of naming suggestions. With so much interest, it didn’t seem fair to leave the job to just a handful of scientists. Instead, we decided to let the public propose and vote on the names of Pluto’s moons.

We knew that the web servers at the SETI Institute, my research home, could never handle the bandwidth required for such a task. However, the Institute has built strong relationships with Google through our extensive use of G+, and our friends there were thrilled to let us use Google services for the demanding task. I asked my husband Frank Yellin, who works on the Gmail team, for help in setting up the forms and collecting the data. Google Forms and Google Sheets were obvious choices, but with the volume of contributions and votes we were expecting, we knew we’d need programmatic help checking for duplicate nominees, filtering out inappropriate names, and tallying the votes.

Frank is a longtime Java engineer, so he tried a Java solution first. As the votes started to pour in at the rate of several per second, however, it became clear that the program could barely keep pace. Votes were coming in almost as fast as they were being downloaded and tallied. In a panic, Frank realized it was time to learn Apps Script — in fact, time to learn JavaScript altogether.

With some help from his colleagues (“How do I split a string?” “How do I make a hash table?”), he turned the project around in a few hours. Processing that had taken tens of minutes using Java took mere seconds in Apps Script, since nothing but the results ever had to leave the data center.

We were right to be prepared. By the time we closed the write-in ballot, we had received 30,000 write-in nominees and more than 450,000 votes.

We are now using the results of the poll to support our proposal for the formal names of P4 and P5. That decision is currently in the hands of the International Astronomical Union. When the final decision is made, Pluto and Charon and Nix and Hydra will be joined by two more representatives of the ancient underworld.

Dr. Mark Showalter   profile Planetary scientist Mark Showalter is a Senior Research Scientist at the SETI Institute. His primary interest in the dynamics of planetary rings. To date, this interest has led him to discover five new moons and three new rings.

The Google I/O Developer Sandbox is an annual tradition that gives innovative developers a chance to showcase their companies and technologies to others at our developer conference. This year, 24 companies were in the Google Apps Sandbox showing the products and custom solutions they’ve integrated with Google Apps. In case you weren’t able to see the Sandbox firsthand, we want to share a couple videos from these companies to spread their knowledge and excitement with the rest of the ecosystem.

Assistly - Delivering customer service, fully integrated with Gmail

Assistly is a customer support application from small to medium size enterprises, integrated with Google Apps Single Sign-On, Gmail and social networks and available for purchase on the Google Apps Marketplace. Assistly is one of many great business applications which make the vision of 100% Web viable today.

A couple spoilers:

• 70% of Assistly users leverage Gmail
• The Google Apps Marketplace is a Top 5 distribution channel for Assistly

Cloud Sherpas - Google Apps reseller, custom app and admin tools developer

Cloud Sherpas is a Google Apps reseller that helps companies migrate to Google Apps and fully utilize the suite of web-based collaboration tools. They’ve also built SherpaTools on Google App Engine, a corporate contact management and IT administration tool for Google Apps available for purchase on the Google Apps Marketplace.

A couple spoilers:

• Cloud Sherpas has had a 3-fold increase in revenue year over year
• SherpaTools is servicing domains totalling close to 3.5 million users

We’ve also created video case studies of 17 additional companies who are innovating using other Google technologies, such as App Engine, Chrome/HTML and Android. Check out the full playlist on the GoogleDevelopers YouTube channel.

Ryan Boyd profile | twitter | events Ryan is a Developer Advocate on the Google Apps Marketplace team, helping businesses build applications integrated into Google Apps. Wearing both engineering and business development hats, youll find Ryan writing code and helping businesses get to market with integrated features.

Want to weigh in on this topic? Discuss on Buzz

A few times recently Ive been asked about retrospectives - specifically how to keep them from becoming a gripe session. Here are a few things that Ive found effective:

1. Start with the positive 

While we certainly want to talk about and address any issues, I like to talk about the positive things that have occurred during the last period before we delve into things we might want to change. I havent yet been involved in a retrospective where the list of positive things wasnt long. This helps set the tone for the rest of the retrospective.

2. Wording matters 

I still have strong memories of watching Linda Rising run a retrospective for the Agile Vancouver organizing team in 2010. The words she chose as facilitator were powerful in keeping the retrospective positive yet useful. Instead of writing down "what went well", participants were asked to complete the phrase "it was great because..." (see the full quote and story at the link above). Instead of writing down "what didnt go well", they were reminded that no process is perfect and to write down "what they would do differently the next time". This simple re-wording of the phrases is powerful.

3. Every voice is heard 

If youve met me in person or even just through this blog, you probably know my passion for silent brainstorming. Generating in silence and discussing out loud isnt just a great way to get more ideas on the table, it is also a fantastic way to make sure every voice is heard. Weve all been at retrospectives where one or more people with loud voices carry the conversation and the ideas. That isnt fun and doesnt encourage a positive atmosphere.

4. Build up Trust 

Using the 3 things above have shown themselves to be important in building up trust but sometimes you need to go a little farther. With new teams Ive found that walking through Norm Kerths prime directive can be a helpful way to eliminate blame from the discssion. They dont even have to believe the prime directive is true, they just have to act as if it is true for the period of the retrospective. I have found this pattern to be important to building up trust over time.

5. Do the (small) change

Finally, the point of all of this is to find ways to improve. If your team is having positive discussions about change and then doesnt follow through, the retrospectives become a waste of time. One simple way to make sure the change happens is to put the action items into your backlog and then start off the next retrospective by reviewing them to see if they were done and if they were helpful.

All the best in making your retrospectives more powerful by making them a positive experience. Feel free to add your tips in the comments.

Subscribe to Winnipeg Agilist by Email

I couldnt find a SOPA gadget for blogger, so in solidarity with all the other blackouts today here is a link to an article on why SOPA should concern you:

http://blog.reddit.com/2012/01/technical-examination-of-sopa-and.html

Here is the conclusion of that article:

"In Conclusion

It is my strong belief that both PROTECT IP and SOPA:

1. Will not stop the piracy they are targeting
2. Contain language that is highly ambiguous and extremely broad making them ripe for abuse, and
3. Introduce regulation and enforce censorship on what should be a free and open internet."

A few weeks ago, the Google Sheets team introduced improved control over protected sheets and ranges. Developers have told us theyre looking for the same power in Google Apps Script — after all, ever since we added data validation to the Spreadsheet service, programmatic control over protected ranges has been the most popular request on the Apps Script issue tracker.

Today, we are excited to give you that granular control.

With the new Protection class in the Spreadsheet service, your scripts can touch every aspect of range or sheet protection, just like in the new UI. (The older PageProtection class, which had more limited features, will be deprecated, but will stick around in case you need to work with older spreadsheets. The new Protection class only applies to the newer version of Sheets.)

Code samples

So lets see the new stuff in action. Lets say you want to prohibit anyone other than yourself from editing cells A1:B10:

// Protect range A1:B10, then remove all other users from the list of editors.
var ss = SpreadsheetApp.getActive();
var range = ss.getRange(A1:B10);
var protection = range.protect().setDescription(Sample protected range);

// Ensure the current user is an editor before removing others. Otherwise, if the users edit
// permission comes from a group, the script will throw an exception upon removing the group.
var me = Session.getEffectiveUser();
protection.addEditor(me);
protection.removeEditors(protection.getEditors());
if (protection.canDomainEdit()) {
  protection.setDomainEdit(false);
}

Or maybe you want to remove all range protections in the whole spreadsheet:

// Remove all range protections in the spreadsheet that the user has permission to edit.
var ss = SpreadsheetApp.getActive();
var protections = ss.getProtections(SpreadsheetApp.ProtectionType.RANGE);
for (var i = 0; i < protections.length; i++) {
  var protection = protections[i];
  if (protection.canEdit()) {
    protection.remove();
  }
}

Or perhaps you want to protect an entire sheet, but carve out a small hole in it — an unprotected range within a protected sheet — that others can still edit:

// Protect the active sheet except B2:C5, then remove all other users from the list of editors.
var sheet = SpreadsheetApp.getActiveSheet();
var protection = sheet.protect().setDescription(Sample protected sheet);
var unprotected = sheet.getRange(B2:C5);
protection.setUnprotectedRanges([unprotected]);

// Ensure the current user is an editor before removing others. Otherwise, if the users edit
// permission comes from a group, the script will throw an exception upon removing the group.
var me = Session.getEffectiveUser();
protection.addEditor(me);
protection.removeEditors(protection.getEditors());
if (protection.canDomainEdit()) {
  protection.setDomainEdit(false);
}

Bam! Easy. Hope you find this useful, and happy scripting!

Posted by Sam Berlin, engineer, Google Sheets

Have you ever written a particular piece of code over and over again?  Or used scripts to do something that you thought others might want to do as well?  Starting today, you’ll be able to share and reuse those scripts as libraries, right from inside Google Apps Script.

Why use a Script Library

I often write scripts which check the National Weather Service for relevant weather-related information.  This allows me to send myself an email if it’s going to rain, reminding me to bring an umbrella to work, or to annotate my spreadsheet of running workouts with the temperature of the day.

Remembering how to query the National Weather Service every time I write a script is a daunting task, however.  They have a complicated XML format that  is tricky to parse.  As a result, I end up just copying and pasting code each time.  This is not only error-prone, but also has the big disadvantage that I have to fix all of my scripts one by one whenever the Weather Service’s XML format changes.

The code I use to query the National Weather Service is a perfect use case for a library.  By using a library, I no longer have to copy and paste code in my script project.  Since logic is centralized, updates need to be applied just once.  And now I am able to share my library with other developers who can benefit from the work I’ve already done.

Writing a Library

Libraries are written just like any other Apps Script project.  A good library has a clean API which is also well documented.  Here’s a code snippet from my WeatherService library:

/**
 * Queries the National Weather Service for the weather
 * forecast of the given address. Example:
 * 
 * <pre>
 * var chances = WeatherService
 *                 .getPrecipitation("New York, NY");
 * var fridayChance = chances[“Friday”];
 * Logger.log(fridayChance + “% chance of rain on Friday!”);
 * </pre>
 * 
 * @param {String} address The address to query the
 *          temperature for, in any format accepted by
 *          Google Maps (can be a street address, zip
 *          code, city and state, etc)
 *          
 * @returns {JsonObject} The precipitation forecast, as
 *          map of period to percentage chance of
 *          precipitation. Example:
 * 
 * <pre>
 * { Tonight: 50, Friday: 30, Friday Night: 40, ... }
 * </pre>
 */
function getPrecipitation(address) {
  // Code for querying weather goes
  // here...
}

Notice how detailed the documentation is. We know that good documentation makes for a great library. So, for every library Apps Script will also auto-generate a documentation page based on the code comments using the JSDoc format.  If you want a method in your code to not be exposed to users, simply end its name with an underscore.

Saving Versions

Before code can be used as a library, a version of it needs to be saved.  Versions are a new concept in Apps Script, and they represent a snapshot of your project which won’t change even as changes are made to the script code. Versions are useful because they allow you to change your library code without breaking existing users.  Once you’re happy with the changes you’ve made, you can then save a new version. Please see the user guide for saving a version and sharing your code as a library is easy.

Using Libraries

Using a library only takes a few steps. To be able to use a library, the owner of the library must share the library and its project key with you. You can follow these instructions to then use a library. To use this National Weather Service library, please visit this page for project key.

Useful Features of Libraries

Script Libraries come with three interesting features.

1. Documentation - In the Script Libraries dialog, you can click on the title link to navigate to documentation page for the library. See example of a generated documentation.
2. Development Mode can be used to test changes to a library without saving a new version. See our User Guide for more details
3. Autocomplete in Script Editor - Typing in the editor will auto-complete your library function names.

Interesting Libraries You Can Use

To get started on using Script Libraries, you can find a list of useful libraries contributed by two of our top contributors - James Ferreira and Romain Vialard. You can also find a detailed user guide on managing versions and libraries. We hope you enjoy using libraries.

Gustavo Moura Gustavo has been a Software Engineer at Google since 2007. He has been part of the Google Docs team since 2009. Prior to that, he worked on AdWords. In his free time he plays soccer.

The Google Apps Marketplace is a storefront for Google Apps customers to discover, purchase, deploy and manage web applications which are integrated with Google Apps. These applications are typically used from desktops and laptops, but many vendors on the Apps Marketplace have also optimized the experience for their users who are on-the-go. There are several different strategies for enabling a mobile workforce, and each requires a different approach to authentication and authorization.

Lightweight: Synchronize Contacts, Calendars and Docs with Google Apps

Google has written applications and synchronization clients to help ensure that the core Google Apps data is available to users on their mobile devices, whether they’re on their mobile phones or tablets. By storing contacts, dates and documents from your application in Google Apps using the application APIs, you can leverage these features to provide a mobile view for your users.

Since you’re only accessing the application APIs on your web application’s server, and the user has already linked up their mobile device to their Google account, there are no special techniques for authentication and authorization when using this lightweight approach.

Standards-based: Build a mobile-optimized web application

With the latest advances in HTML5 web technologies such as offline and local storage, it’s possible to build mobile interfaces for business apps which are full-featured and accessible to users on many devices. The primary goal in building the mobile web application is to optimize the user experience for different input devices, form factors and limitations in network availability and bandwidth.

Because the application is in a web browser, most of the changes to implement are in the frontend-- HTML, JavaScript and CSS. User authentication and data authorization continue to use the same OpenID and OAuth technologies as are used for the desktop/laptop version of the application.

Device-custom: Build native companion apps for mobile devices

Does your application need access to hardware-specific APIs which are not available in a web browser, or do you feel a great user experience can only be achieved using native code? Several Apps Marketplace vendors have built native applications for popular mobile platforms like Android and iOS. Although it takes considerably more effort to build multiple native applications to cover the major platforms, these vendors can also take advantage of the additional distribution channels offered by mobile stores.

Authentication and authorization are often challenging for developers building native mobile applications because they cannot simply ask users for a password if their app supports single-sign on to Google with OpenID. We recently published an article describing a technique using an embedded webview for accomplishing OpenID authentication in mobile apps. This article includes references to sample code for Android and iOS.

Many Project Management applications, like Manymoon, store important dates on Google Calendar. These dates are then available on mobile devices.

GQueues has a HTML5 mobile app. Their founder has written about why they used this technique.

Native applications, such as the OpenID Sample Store displayed, can use an embedded webview to authenticate users.

Ryan Boyd   profile | twitter | events Ryan is a Developer Advocate on the Google Apps Marketplace team, helping businesses build applications integrated into Google Apps. Wearing both engineering and business development hats, youll find Ryan writing code and helping businesses get to market with integrated features.

Want to weigh in on this topic? Discuss on Buzz

This post is prepared by Nina Gorbunova, Teamlab Office Marketing Manager

About Teamlab Personal
Teamlab Personal is a suite of online document editors free for individual use. Weve recently implemented two way integration with Google Drive and would like to share our experience.

Why Google Drive integration
Many of our users connect Google Drive to Teamlab, and we wanted to reach more by being in the Chrome Web Store. The availability of Google Drive SDK and Google Drive API helped us fit it all together. We thought: if a user can connect a Google Drive account to Teamlab Personal, why not build a return path? In the eyes of users, it is an enhancement of their Drive accounts. They get an opportunity to process documents using high formatting quality in browser and to make one more step away from desktop apps.

Integration goals
From the technical side, here is what we wanted to do:

• Integrate Teamlab editors and viewers with Google Drive.
• Provide co-editing opportunities.
• Enable file conversion and creating new files in the common Office Open XML format.
• Enable users to login with Google to use Teamlab Personal.

Five steps to achieve two-way integration

1. We registered with Google’s developer console, added our project and connected the Drive API and Drive SDK to the app.
2. Then we needed to decide what scopes our app needed to access the Google Drive API. We chose the minimal set, ample for us to access the files to edit without trespassing the user’s privacy (most users are not likely to provide full access to 3rd party apps)
   
   
3. Because we work with traditional office apps, we chose docx, xlsx and pptx formats as default file extensions for our app. We also added secondary formats: ppt, pps, odp, doc, odt, rtf, txt, xls, csv, ods, mht, html, htm, fb2, epub, pdf, djvu.
4. The current listing for the pre-existing app, we modified the code and added the following to the manifest: "container" : "GOOGLE_DRIVE","api_console_project_id" : "YOUR_APP_ID". Once a user installs Teamlab Personal app from Chrome Web Store, it automatically connects to their Google Drive account.
5. Finally, Teamlab Personal uses OAuth 2.0 for authorization and file access. The application processes requests for creating and opening files.

How it works
As soon as youve installed Teamlab Personal from the Chrome Web Store, the integration automatically activates. Now, you can choose the Teamlab icon when creating new and editing the existing documents.


If the user selects the Teamlab editor as the default, .docx, .xlsx and .pptx files are opened in Teamlab automatically. For other documents, we create a copy in Office Open XML format which will be saved on Drive alongside the original.

Requests processing at personal.teamlab.com

When a file is opened or created on Google Drive using the Teamlab Personal application, the handler gets the request with the following parameters: "ids" ("folderId" if case of file creation), "action", "userId" and "code". The "code" parameter is used to get the authentication token via OAuth 2.0 protocol (with the help of the request to https://accounts.google.com/o/oauth2/token with the "client_id", "client_secret", "redirect_ur parameters", and the additional "grant_type=authorization_code" parameter from the developer console). The received token is used in the subsequent requests. The "ids" parameter is the file to be opened identifier which is sent to the https://www.googleapis.com/drive/v2/files/ address in JSON format. The returned "mimeType" and "downloadUrl" are used to get the file content. Thats all what is needed to open the document file in Office Open XML format (.docx, .xlsx or .pptx) in Teamlab.

Files in other formats are converted to the corresponding Office Open XML format and a copy is saved to the Drive folder prior to opening. In this case the "downloadUrl" is used to get the original file. The file is saved with the help of the POST request to the https://www.googleapis.com/upload/drive/v2/files address. In this request the "ContentType" is set as "multipart/related; boundary=boundary" and the request body contains the file information placed before the main request content.

Request code:

string CreateFile(Stream content, string fileName, string mimeType, string folderId, string accessToken){
    var bytes = Encoding.UTF8.GetBytes(
        "

--boundary

Content-Type: application/json; charset=UTF-8



{"title":""
        + fileName + "","parents":[{"id":"" + folderId + ""}]}"
        + "

--boundary

Content-Type: " + mimeType + "



");

    var tmpStream = new MemoryStream();
    tmpStream.Write(bytes, 0, bytes.Length);
    content.CopyTo(tmpStream);

    bytes = Encoding.UTF8.GetBytes("

--boundary--

");
    tmpStream.Write(bytes, 0, bytes.Length);

    var request = WebRequest.Create("https://www.googleapis.com/upload/drive/v2/files?uploadType=multipart");
    request.Method = "POST";
    request.Headers.Add("Authorization", "Bearer " + accessToken);
    request.ContentType = "multipart/related; boundary=boundary";
    request.ContentLength = tmpStream.Length;

    var buffer = new byte[2048];
    int readed;
    tmpStream.Seek(0, SeekOrigin.Begin);
    while ((readed = tmpStream.Read(buffer, 0, 2048)) > 0) {
        request.GetRequestStream().Write(buffer, 0, readed);
    }
    return request.GetResponse().GetResponseStream();
}

Conclusion
The "Works with Google Drive" label does its magic indeed. We strongly recommend other developers build a Chrome Web Store app, as the results are clear and valuable. We had a high jump in installs (see the graph below) after we completed our integration. Teamlab Personal website traffic doubled and we received more than enough of users’ feedback – great impact for further development.


About the author
Nina started her career at Teamlab in 2011 as an intern. She is now a Senior Marketing Manager at Teamlab Office.

Last month, we launched the Google Tasks API, which received a very warm welcome in the developer community. Google Tasks stores tasks that users enter via Gmail, their mobile device, calendar, or iGoogle homepage. The Google Tasks API provides developers with a powerful set of API endpoints for searching, reading, and updating Google Tasks content and metadata.

To help all of you get started using the Google Tasks API, we wrote a new hands-on tutorial: Getting Started with the Tasks API on Google App Engine. In this tutorial, you will learn how to:

• Create a simple App Engine app using the Google APIs Client Library.
• Provide Google Tasks users a mechanism to authorize your app to access their tasks.
• Make authorized requests to the Tasks API.

By the end of the tutorial, you’ll have an App Engine app that creates a stylized list of tasks for a specific user delivered from the Tasks API:

Check out the tutorial and ask any questions you have in the Google Tasks API forum.

Johan Euphrosine profile | twitter | events Johan joined Google in 2011 as a Developer Programs Engineer based in Zurich. He is currently focusing on App Engine and Google Apps APIs. Before Google, Johan was providing development services as a Freelancer around FLOSS.

Want to weigh in on this topic? Discuss on Buzz

For a while now, many of you have been asking for a better way to access data to build apps that integrate with Gmail. While IMAP is great at what it was designed for (connecting email clients to email servers in a standard way), it wasn’t really designed to do all of the cool things that you have been working on, which is why this week at Google I/O, we’re launching the beta of the new Gmail API.

Designed to let you easily deliver Gmail-enabled features, this new API is a standard Google API, which gives RESTful access to a user’s mailbox under OAuth 2.0 authorization. It supports CRUD operations on true Gmail datatypes such as messages, threads, labels and drafts.

As a standard Google API, you make simple HTTPS calls and get your responses in JSON, XML or Google Protobuf formats. You can also make these calls from standard web languages like Java and Python without using a TCP socket, which means the API is accessible from many cloud environments that couldn’t support IMAP.

In contrast to IMAP, which requires access to all of a user’s messages for all operations, the new API gives fine-grained control to a user’s mailbox. For example, if your app only needs to send mail on behalf of a user and does not need to read mail, you can limit your permission request to send-only.

To keep in sync, the API allows you to query the inbox change history, thereby avoiding the need to do “archaeology” to figure out what changed.

Finally, a huge benefit is speed. While there’s still some tuning to be done (“beta” - remember?), results from our tests and feedback from pre-release developers suggest that the new Gmail API is delivering dramatic performance improvements over IMAP for web application use cases.

Check out the launch video and get started with samples, tutorials, and API references at https://developers.google.com/gmail/api/. We can’t wait to see what you build.

Posted by Eric DeFriez, Gmail Extensibility Team. As a technical lead for Gmail APIs, Eric works to make it easy for developers to build on top of Gmail.

Editors note: This post was written by Richard Wallace of Atlassian. This is part one of a two-part series on Atlassians recent development for the Google Apps Marketplace. Atlassians JIRA Studio is a hosted software development suite, combining Subversion source control, issue tracking, wiki collaboration, code reviews and continuous integration. JIRA Studio is now integrated with Google Apps and is featured in the Google Apps Marketplace - a great tool for development teams using Google Apps. This series explores some of what Atlassian worked on, and what they learned along the way.

Part 1: Nine cool things you can do with the JIRA Studio Activity Bar

By now you have probably heard about the Google Apps Marketplace and JIRA Studio integration. If not, the short version is that Google has created a place for users of Google Apps to sign up for third party hosted SaaS offerings and have them fully integrated with their Google Apps domain. Google was kind enough to ask Atlassian if we would be interested in integrating our hosted agile development suite, JIRA Studio, for their initial offering, and we thought it would be an awesome opportunity. So, if you purchase JIRA Studio through your Google Apps account you get issue tracking and project management, a wiki, source code repository and review system, and (optionally) a continuous integration server configured out of the box, using the same user accounts as your Google Apps for authentication.

However, we decided that just stopping at Single Sign On (SSO) integration, while cool, wasnt enough. Google provides a rich set of APIs for accessing your Google Apps data, so we wanted to provide a better experience for anyone who purchased JIRA Studio. So, while a team in Sydney worked on the authentication integration bits, a second team worked on the "cool" features. A few of the more obvious cool things were Google Doc macros in the wiki, attaching Google Docs to JIRA issues and so on. But we wanted something that would really stand out.

The one Google App that we hadnt found a way to integrate yet was Google Talk. Someone suggested implementing a chat client similar to the one you get in Gmail that would appear on every page in Studio. We quickly came to realize it didnt need to be limited to just chat, it would also have tabs showing various bits of information from JIRA Studio and Google Apps. And so the JIRA Studio Activity Bar was born.


The feature we delivered does a lot. With the JIRA Studio Activity Bar a user can see:

1. all the recent activity going on in Studio - whos working on what issue, who committed what and how long ago
   issues assigned to you
2. what reviews you need to do
3. recent builds
4. favorite wiki pages
5. unread mail in your Gmail inbox
6. recent Google Docs
7. any upcoming events on your Google Calendar
8. and chat with anyone with a Google Talk or Jabber account

All without leaving the JIRA Studio environment.

Initial planning

Our initial estimate for implementing this feature was, "a lot of work". Im pretty sure we underestimated. The immediate question that jumped out at us and continued to bother us during development was, "How can we scale this?" Instant messaging is typically done with a persistent connection to the chat server. That way the server can "push" messages to clients when theyre sent. Thats what makes it "instant." To do the same with a browser wed need to use some Comet techniques for maintaining a connection between the browser and server. In Java apps, this typically means a thread will be blocked waiting for something to do. It was immediately obvious that this just wouldnt scale very well. For a Studio instance with 30-50 users, we could expect at least that many threads to be tied up all the time.

How do we scale?

So we started looking at how we could do non-blocking I/O in Java apps. Fortunately, most Java app servers have some form of non-blocking, asynchronous I/O capabilities these days. Unfortunately, they have different APIs for using those capabilities since Servlet 3.0 implementations arent yet wide spread. To make matters worse, we werent sure exactly what container we were going to wind up deploying to.

You see, JIRA Studio runs on Virtual Machines on Contegix hardware. This is to keep all the customer data separate and secure. Each Studio instance is allocated a specific amount of memory so that Contegix can properly load balance instances for maximum utilization of their hardware. Studio, before adding the Google Apps integrations, was already starting to get closer and closer to exceeding that memory limit.

How will it be deployed?

At first, we had hoped to develop the Activity Bar as a plugin to one of our apps. Because of the way servlets are wrapped in our plugin system this proved to be impossible as there is no way to access any of the container-specific methods for doing asynchronous I/O. Our next thought was to deploy it as a separate webapp. We could do that simply with a minimal web server like Jetty or Grizzly. We debated whether the app would meet the limited memory footprint even with the most minimal web server we could find, since the JVM by itself would take up 40-50MB of memory. The final thought was that we would deploy the Activity Bar webapp in one of the existing containers alongside JIRA, Confluence, Crowd or Bamboo. Even that decision was destined to change.

So, amidst all this uncertainty, which ironically couldnt be cleared up until we had something to deploy, what was a developer to do? Well, the same thing we always do. Abstract, abstract, abstract. Atmosphere was built exactly to solve this problem. By using its APIs you can run on any of the myriad of containers with asynchronous I/O support and not have to worry about the details. Even better, it integrates well with the Jersey library for building RESTful services, making it even easier to use! And to top it all off the developers are quick to patch and release bug fixes as they are found. We certainly couldnt have completed this project as quickly as we did without Atmosphere, so I want to give a big thanks to Jean-Francois for all his help.

Early days

And so we set out to develop the chat backend as a separate web application, to be run on an as-yet-undetermined container using Atmosphere to abstract away the details of doing asynchronous I/O. In pretty quick order we were able to get logging in to Google Talk, fetching the buddy list, message sending and receiving, and handling presence updates all working.

We naively did this using the HTTP streaming form of Comet techniques. This worked well for a while until we started doing some more tests and added error handling. At this point two nasty problems reared their ugly heads: 1) you couldnt really do any error handling if the connection failed, 2) if the initial connection succeeded but timed out after a while, there wasnt much we could do to detect that. This was due to the fact that the connection with the browser was maintained in an iframe. When the server needs to send a message to the browser, it simply spits out a <script> tag containing a call to a JavaScript function to handle it. Well, there is really no way of determining the HTTP responses status code of an iframe. That meant that when a connection problem occurred, there would be little we could do to handle it. As for the second problem, we might have created an onload event handler such that when it was invoked it would remove the iframe and create a new one to receive notifications. The two problems, combined, however, made us realize that HTTP streaming just isnt a great solution, so we set out to implement long polling instead.

Looking back, while HTTP streaming wasnt the best solution for us, it wasnt an entirely bad way to start. We avoided issues like storing notifications between polling requests that we otherwise would have had to deal with and we were able to get the UI development going with real live data while the migration to long polling was being done. It was also good because it made us confident that yes, this really would work and we could pull it off in the short time frame we had been given. While it wasnt the best solution, it was a good way to get started and the migration to long polling wasnt all that difficult or disruptive because we had a good foundation to work from.

Not too surprisingly the application tabs were the easiest bits to get working. For pulling data from JIRA, Confluence, Crucible and Bamboo we just had to request feeds for the data we wanted and parse and display them. Since all JIRA Studio apps come from http://yourcompany.jira.com, we didnt have to worry about any same origin policy issues and SSO took care of our authentication needs. The Google Apps data was a bit harder to come by because we did need to worry about the same origin policy and authentication.

As luck would have it, the other features that were being worked on as part of our integration work took care of all of that very nicely. To allow a user to see a list of Google Docs in Confluence and pick a document to attach to an issue, the integration team had developed plugins for the Atlassian applications that acted as proxies to the actual Google Data APIs. Authentication is handled using OAuth, which is setup automatically between your JIRA Studio instance and Google at the time you sign up. With those feeds available to the Activity Bar, it was a simple matter of fetching and parsing them to display your Google Docs, upcoming Google Calendar events and unread messages in your inbox.

By Richard Wallace, Atlassian

Now its just a matter of rolling it out, right? Not quite. Part 2 of this series talks through a few other hurdles we had to jump over (or crash through) to get ready for launch.

Search engines have been using structured data for years to understand the information on web pages and provide richer search results. Today, we are introducing schemas in emails to make messages more interactive and allow developers to deliver a slice of their apps to users’ inboxes.

Schemas in emails can be used to represent various types of entities and actions. Email clients that understand schemas, such as Gmail, can render entities and actions defined in the messages with a consistent user interface. In the case of Gmail, this means that the emails can display quick action buttons that let users take actions directly from their inboxes, as in the following screenshot:

Using schemas to add quick action buttons to the emails you send is easy. All it takes is adding some markup to your HTML emails, together with your regular content, in one of the supported formats - Microdata and JSON-LD.

As an example, the following JSON-LD markup can be used to define a movie and the corresponding one-click action to add the movie to your queue:

<script type="application/ld+json">
{
  "@context": "schema.org",
  "@type": "Movie",
  "name": "The Internship",
  ... information about the movie ...
  "action": {
    "@type": "ConfirmAction",
    "name": "Add to queue",
    "actionHandler": {
      "@type": "HttpActionHandler",
      "url": "https://my-movies.com/add?movieId=123",
      "method": "POST",
    }
  }
}
</script>

Gmail renders the markup above with a button labelled “Add to queue” next to the email subject line. When the user clicks on the button, Gmail sends a POST request to the url specified in the action handler. Your app has to handle these requests and respond to the email client with an appropriate HTTP response code (200 for successful requests, 400 for invalid requests, etc.).

Schemas in emails currently support four different types of actions - rate/review, RSVP, one-click action and goto link - and we plan to add more types moving forward. We are collaborating with a number of partners who will launch their integrations in the coming weeks, making the messages they send more useful and interactive for Gmail users. For example, Esna is using this to inform users of missed calls and provide them with a one-click button to be called again, while Seamless is implementing the rate/review action to collect feedback about restaurants.

Other partners who are already implementing schemas in email today include both Billguard, Concur Technologies, Docusign, HelloSign, Insight.ly, Mailchimp, myERP, Netflix, OpenTable, Orangescape, Paperless Post, Spotify, SugarCRM, and Tripit.

To learn more about all supported entities and actions and to find out how to get started with schemas in email, visit http://developers.google.com/gmail.

Claudio Cherubino   profile | twitter | blog Claudio is an engineer in the Google Drive Developer Relations team. Prior to Google, he worked as software developer, technology evangelist, community manager, consultant, technical translator and has contributed to many open-source projects. His current interests include Google APIs, new technologies and coffee.

Agile Documentation. These two simple words represent a common question and concern for professionals who are new to agile. Many IT professionals who work in traditional environments are accustomed to spending a lot of their time carefully crafting documents to support the planning, requirements, and design of their project. They are often measured and compensated by their abilities to communicate ideas through documentation. After spending much of their career perfecting their communication skills through MS Word, Visio and MS Project, it is natural for them to wonder how projects can be successful without significant investment in documentation. Since one of the common early misconceptions about agile development is that documentation is no longer needed, you can understand how agile adoption would cause them to be concerned about both their careers and their projects.

For those who share this concern, let’s start by considering the following quote from Jeff Patton:

“Documents we write communicate our good thinking. You can write one without thinking. You can communicate good ideas without a document.” – Jeff Patton (Jan. 19, 2011 - twitter)

Before you sit down to write your next document, ask yourself these two questions:

1. Do I use the process of creating a document as a vehicle for good thinking? If so, what other ways could be used as a vehicle for good thinking?

2. Do I use documentation as a means of storing and then transferring good ideas to other team members (current and future)? If so, what other ways could be used to store and transfer those ideas?

In part II I’ll talk about some additional guiding questions and suggestions to help you make decisions on when and how to use documentation in agile projects. Before you read that post, please consider Jeff’s words and the questions above as you think about the place documentation may or may not have on your project.

Editors Note: This post was originally published on the Google Enterprise Blog. We decided to re-post it here as we think itll be interesting to readers of the Google Apps Developer Blog.

Google Apps is designed to provide a secure and reliable platform for your data. Until today, Google Apps administrators had to sign requests for calls to Google Apps APIs using their username and password (this is called ClientLogin Authorization).

Yet sharing passwords across sites can pose security risks. Furthering our commitment to make the cloud more secure for our users, today we are pleased to announce support for OAuth authorization on Google Apps APIs.

There are several advantages to using OAuth instead of the username/password model:

• OAuth is more secure: OAuth tokens can be scoped and set to expire by a certain date, making them more secure than using the ClientLogin mechanism.
• OAuth is customizable: Using OAuth, you can create tokens that scripts may only use to access data of a particular scope when calling Google Apps APIs. For instance, a token set to call the Email Migration API would not be able to use your login credentials to access the Google Apps Provisioning API.
• OAuth is an open standard: OAuth is an open source standard, making it a familiar choice for developers to work with.

The Google Apps APIs that support the OAuth signing mechanism are:

1. Provisioning API
2. Email Migration API
3. Admin Settings API
4. Calendar Resource API
5. Email Settings API
6. Audit API

OAuth support for Google Apps APIs is another step towards making Google Apps the most secure, reliable cloud based computing environment for organizations. To learn more about OAuth support and other administrative capacities launched in Google Apps this quarter, join us for a live webinar on Wednesday, September 29th at 9am PT / 12pm EST / 5pm GMT.

Administrators for Google Apps Premier, Education, and Government Editions can use OAuth authorization for Google Apps APIs starting today.For more information about the OAuth standard, visit http://oauth.net.

Posted by Ankur Jain, Software Engineer

Want to weigh in on this topic? Discuss on Buzz

Editor’s Note: Guest author Steve Webster works at Dito. Dito has developed applications such as Dito Directory which is available in the Google Apps Marketplace.

When composing Gmail conversations, the auto-complete feature allows us to see our matching personal contacts as we type and quickly make our contact selections. This time-saving feature can be duplicated when creating Google Apps Script applications. For instance, if you design an application that requires sending emails, you can leverage this auto-complete feature by using a personal contact list.

Defining the Requirements

By observing the behavior while composing Gmail conversations, we can define the requirements of our application.

1. As the user begins typing, a list of matches based on first and last name and email address need to appear under the text box. In other words, the user can begin typing the contacts first name, last name, or their email address.

2. If the desired contact email is listed at the top of the matching list, the user can simply press the Enter key to select it.

3. Another option is to click on any of the contacts in the list.

4. Just in case the user would like to enter an email that is not in their contact list, they may enter the email and press the Enter key.

As an added feature if the email is not formatted correctly, then the invalid email is ignored and not selected. For our application when emails are selected, they will be compiled in a separate list on the right where only the email address is stored. If an email is selected by accident, the user can remove the email by clicking on it.

Designing the Application

The application was designed to mimic the behavior of composing Gmail messages. By doing so, the application avoided the use of buttons, providing an improved user experience.

1. Apps Script Services

The Apps Script’s Spreadsheet Service was used to store a user’s contact data. The Ui Service provided the application interaction with the user, and the Contacts Service was leveraged to gather all the user’s contacts. You may apply a Google Apps domain only filter for the contacts by changing the global variable to “true” in the script.

2. Visualize the Layout

Before writing code, the layout was sketched out to include a text box, some space beneath to list matches, and an area to the right to display the selected emails.

3. Choose your widgets

A text box widget was chosen to allow email entry, and two open list boxes were leveraged to display contact matches and selected emails. List boxes provided the use of click handlers to process email selections.

4. Challenges

To mimic the Gmail auto-complete behavior, the text box needed the ability to handle both keystrokes and a pressed Enter key. To accomplish this, a KeyUpHandler calls a function to identify contact matches via a search. The same function used an e.parameter.keyCode == 13 condition to determine when the enter key is pressed.

//create text box for auto-complete during email lookup in left grid
  var textBox = app.createTextBox().setName(textBox)
                   .setWidth(330px).setId(textBox);
  var tBoxHandler = app.createServerKeyHandler(search_);
  tBoxHandler.addCallbackElement(textBox);
  textBox.addKeyUpHandler(tBoxHandler);
   ...
function search_(e){
  var app = UiApp.getActiveApplication();
  app.getElementById(list).clear(); 
  var searchKey = new RegExp(e.parameter.textBox,"gi");
  if (searchKey == "") app.getElementById(textBox).setValue();
  var range = sheetOwner.getRange(1, 1, sheetOwner.getLastRow(), 2).getValues();
  var listBoxCount = 0;
  var firstOne = true;
  for (var i in range){
     // if first/last name available, display name and email address
     if (range[i][0].search(searchKey) != -1 || range[i][1].search(searchKey) != -1){
       if (range[i][0].toString()){
          app.getElementById(list).addItem(range[i][0].toString()+
           .. +range[i][1].toString(), range[i][1].toString()); 
          var listBoxCount = listBoxCount + 1;
       } else { // else just display the email address
          app.getElementById(list).addItem(range[i][1].toString()); 
          var listBoxCount = listBoxCount + 1;
       }
       if (firstOne) var firstItem = range[i][1].toString();
       var firstOne = false;
     }  
  }
  // set the top listbox item as the default
  if (listBoxCount > 0) app.getElementById(list).setItemSelected(0, true);
  // if enter key is pressed in text box, assume they want to add
  // the email that’s not in the list
  if (e.parameter.keyCode==13 && listBoxCount < 1 && searchKey !== "") { 
  ...

As this application shows, Apps Script is very powerful. Apps Script has the ability to create applications which allow you to integrate various Google services while building complex user interfaces.

You can find Dito’s Email Auto-Complete Script here. To view a video demonstration click here. You can also find Dito Directory on the Google Apps Marketplace.

Posted by Steve Webster, Dito

Want to weigh in on this topic? Discuss on Buzz

As we build out a new platform and APIs for developers, we find it helpful to create our own applications to try it out. It helps us validate and influence the design based on direct experience using the APIs. In the case of the Google Apps Marketplace, we needed a real application to integrate with Google Apps. We decided to build SaaSy Voice -- a web-application for handling the phone system for small and medium businesses. For the call features we used Twilio, a cloud based voice communications provider.

Ive posted the images from the session "Look before you leap - Agile readiness assessments done right" at Agile2010.  The images are here http://tinyurl.com/26bwlzw.

Some of the images are blurry in my browser (IE), but if you Save As to your computer then you get more detail (not sure why).  If there are any images you need more detail on, let me know - I still have all the originals.

I started the day with Mary Poppendiecks talk "Leaders Workshop: Making Change Happen and Making it Stick" which was based on the following book: Switch: How to Change things when change is hard. The talk was split into 3 parts. First you need to Motivate the Elephant, then you need to Direct the Rider, and finally you need to Shape the Path.

Mary suggested that in order to Motivate people, you need to treat them like volunteers. You need to treat them like they could leave at any time. A quote from Peter Drucker: "They need, above all, challenge. They need to know the organizations mission; believe in it, they need to see the results". As our table discussed this concept, we were able to easily relate to our own stories of leading youth at church or in boyscouts. I think this would be a great way to be treated and I can see how it would translate into energized and passionate employees. A volunteer team has to be engaged or they will disappear.

The purpose of Directing the Rider is to provide clear direction. One of the ways to do this when change is difficult is to find the bright spot. When you are having trouble implementing a change, look for some small success and then duplicate it. She gave a great example about post-it notes. When 3M first made the post-it notes, they could not sell them. They test marketed them in several locations and they only sold them in one ("the bright spot"). It turns out that the sales rep in Richmond Virginia decided to give them away and once he did everyone wanted one. 3M then followed this model in other locations and now post-it notes are a household item (and a valuable agile tool!). So, to direct the rider in difficult situations, find instances of success and clone it. A book that she references is: Positive Deviance: Influence: The Power to Change Anything"

Finally, she suggests Shaping the Path by looking at the long term and allowing local decision making. You also need to find ways to make the desired change the path of least resistance. "Change will only stick when the path of least resistance is the path of change." IBMs move towards agile was used as an example. Instead of forcing agile, they allowed it to succeed in smaller teams and then sold and promoted those successes. Soon, everyone wanted to do it.

In summary, to encourage change in a team when it is difficult a) treat your team as volunteers b) find the bright spot and clone it and finally c) make the desired change the path of least resistance.

In the afternoon I went to Hacker Chick and Dawn Cannans hands on presentation "Better Story Testing through Programmer-Tester Pairing". We had fun doing developer/tester pairing of acceptance tests in FitNesse and Java. I learned a few new FitNesse tricks and also that I havent lost all my dev skills. I played the dev role and our team was the first to complete the assigned task, beating some notable names in the room <cough>Brian Marick</cough>. The session also re-inforced ATDD and gave me some ideas Id like to incorporate into a future presentation.

Also, I missed Janet Gregorys talk this morning on the Dance of QA in agile, but I managed to talk to her this evening at the mixer. She gave a quick summary of her talk and how she related it to dance. Agile team members need to be like contestants on "So You Think You Can Dance". On the show, hip-hop dancers learn other dance styles like ballet and vice versa. Similarly, agile team members (including QA) need to improve their skills in all of the disciplines in a project team. An interesting thought.

Thanks to everyone - a great first day.

In other news, Bob Payne is now following me. #Stalker.

Back in March, we launched the Google Apps Marketplace and turned Google Apps into a platform for your apps using Google’s Data APIs, OpenID-based identity management, and universal navigation. We also gave you a sneak preview of Gmail contextual gadgets, an extension mechanism that allows developers to intelligently trigger their application within Gmail. Gmail contextual gadgets bring your app directly into the inbox where users spend most of their day, giving your app powerful new functionality and enabling greater user engagement.

We are excited to announce that the Gmail contextual gadgets API is available to all Google Apps Marketplace developers today. You will be able to use our predefined email context extractors to contextually trigger your gadgets within Gmail. In the future, you will also be able to write custom context extractors; sign up here to take a peek.

The contextual gadgets that you write can be bundled into manifests and listed on the Apps Marketplace. Google Apps domain administrators can deploy your gadgets to their users with a few clicks. As with all new APIs, we will keep this one in Labs as we enhance these gadgets.

Several apps featuring Gmail contextual gadgets are launching on the Marketplace today, with more on the way. To check out their integrations and read our full announcement, visit our post on the Google Enterprise Blog. To get started with building these contextual gadgets, visit the developers guide.



We are hard at work adding even more extension points to Google Apps to enable a richer integration experience for developers and a more seamless user experience for Google Apps customers. Stay tuned!

Posted by Umesh Patil, Gmail Contextual Gadgets Team

Update: Docs are now live!

We are currently rolling out a change to the organization of existing resources in collections in Google Docs. This change is completely transparent to users of the Google Docs web user interface, but it is technically visible when using the Google Documents List API to make requests with the showroot=true query parameter or specifically querying the contents of the root collection. In order to understand this change, first read how Google Docs organizes resources.

The change involves Google removing those resources from a user’s root collection that already exist within another collection accessible to the given user. That is, if “My Presentation” is currently in root and in the “My Talks” collection, after this change it will only exist in the “My Talks” collection.

We are making this change in order to make the organization of resources less confusing for API developers. This change allows clients to know that a resource either exists in root or in some collection under root. Clients can still retrieve all resources, regardless of which collections they’re in, using the resources feed.

The change is rolling out gradually to all Google Docs users over the next few months.

Developers with further questions about this change should post in the Google Documents List API forum.

Russ Jorgensen LinkedIn Russ Jorgensen joined Google in 2010 and is responsible for supporting and enhancing APIs which third-party applications can use to access and manage users collections of Google Docs. Prior to working at Google, Russ was an embedded software engineer for 22 years at Bell Labs building telecommunications products such as PBXs and wireless communication systems.

My students are just loving the interactive e-books that Ive been making lately!  The interactive elements really help to keep them engaged with the non-fiction text.  And of course, they love reading the books on the smartboard - the large pictures are so much easier to see!


The book has great information text about MLK Jr., as well as questions to test for comprehension.  When they get the question correct, it cheers for them!  They just love it! Click the picture above to check out the book on Teachers Pay Teachers.  Or... be one of the first two people to comment and Ill email it to you for free!