Author Archives: Google Apps Developer Blog Editor

Hangouts Meet now available in the Google Calendar API



Thousands of developers use Google Calendar API to read, create and modify Google Calendar events, and quite often, these events represent meetings happening not just face-to-face but also remotely. We introduced Hangouts Meet earlier this year to give users richer conference experiences, adding video call links and phone numbers for G Suite Enterprise. Starting today, we are making it possible to access all that conference information through the Google Calendar API. With this update, developers can now:
  • Read conference data associated with events 
  • Copy conference data from one event to another 
  • Request new conference generation for an event 
The API supports all Hangouts versions.

Reading conference data 

Conference information is stored in a new event attribute called conferenceData. conferenceData provides information about the solution that was used to create the conference (such as Hangouts Meet) and a set of entry points (like a video call link and phone number). Everything the user needs to know to join a conference call is there.

To help you build even better user experiences, we also give you access to icons and user-readable labels that you can use in your products. In JSON format, conferenceData looks something like this (of course, your actual meeting IDs and phone numbers will vary):
"conferenceData": {
"entryPoints": [
{
"entryPointType": "video",
"uri": "https://meet.google.com/wix-pvpt-njj",
"label": "meet.google.com/wix-pvpt-njj"
},
{
"entryPointType": "more",
"uri": "https://tel.meet/wix-pvpt-njj?pin=1701789652855",
"pin": "1701789652855"
},
{
"entryPointType": "phone",
"uri": "tel:+44-20-3873-7654",
"label": "+44 20 3873 7654",
"pin": "6054226"
}
],
"conferenceSolution": {
"key": {
"type": "hangoutsMeet"
},
"name": "Hangouts Meet",
"iconUri": "https://lh5.googleusercontent.com/proxy/bWvYBOb7O03a7HK5iKNEAPoUNPEXH1CHZjuOkiqxHx8OtyVn9sZ6Ktl8hfqBNQUUbCDg6T2unnsHx7RSkCyhrKgHcdoosAW8POQJm_ZEvZU9ZfAE7mZIBGr_tDlF8Z_rSzXcjTffVXg3M46v"
},
"conferenceId": "wix-pvpt-njj",
"signature": "ADwwud9tLfjGQPpT7bdP8f3bq3DS"
}

And this, for example, is how you would retrieve and display conference solution name and icon:
var solution = event.conferenceData.conferenceSolution;

var content = document.getElementById("content");
var text = document.createTextNode("Join " + solution.name);
var icon = document.createElement("img");
icon.src = solution.iconUri;

content.appendChild(icon);
content.appendChild(text);
The result of the code above will look like this in the user interface:

Copying conferences across events 

Sometimes displaying information is not enough—you might want to update it as well. This is especially true when scheduling multiple Calendar events with the same conference details. Say you’re developing a recruiting application that sets up separate events for the candidate and the interviewer; you want to protect the interviewer’s identity, but you also want to make sure all participants join the same conference call. To do this, you can now copy conference information from one event to another by simply writing to conferenceData.

To ensure that only existing Hangouts conferences are copied, and to help safeguard your users against malicious actors, copied conference data will always be verified by the Google Calendar API using the signature field, so don’t forget to copy it too.

Creating a new conference for an event 

Finally, the API allows developers to request conference creation. Simply provide a conferenceData.createRequest and set the conferenceDataVersion request parameter to 1 when creating or updating events. Conferences are created asynchronously, but you can always check the status of your request to let your users know what’s happening. For example, to request conference generation for an existing event (again, your request and event IDs will be different):
var eventPatch = {
conferenceData: {
createRequest: {requestId: "7qxalsvy0e"}
}
};

gapi.client.calendar.events.patch({
calendarId: "primary",
eventId: "7cbh8rpc10lrc0ckih9tafss99",
resource: eventPatch,
sendNotifications: true,
conferenceDataVersion: 1
}).execute(function(event) {
console.log("Conference created for event: %s", event.htmlLink);
});
The immediate response to this call might not yet contain the fully-populated conferenceData which is indicated by status pending:
"conferenceData": {
"createRequest": {
"requestId": "7qxalsvy0e",
"conferenceSolutionKey": {
"type": "hangoutsMeet"
},
"status": {
"statusCode": "pending"
}
}
}
Once the statusCode changes to success, the conference information is populated. Finally, if you are developing a Google Calendar client, you might also want to know beforehand which of the three Hangouts solutions (consumer Hangouts, classic Hangouts and Hangouts Meet) will be used to create the conference. You can get that information by checking allowedConferenceSolutionTypes in a calendar’s conferenceProperties.

To get started, check out the documentation page for managing conference data. We can’t wait to see what you build with these new features in the Google Calendar API.

Hangouts Meet now available in the Google Calendar API



Thousands of developers use Google Calendar API to read, create and modify Google Calendar events, and quite often, these events represent meetings happening not just face-to-face but also remotely. We introduced Hangouts Meet earlier this year to give users richer conference experiences, adding video call links and phone numbers for G Suite Enterprise. Starting today, we are making it possible to access all that conference information through the Google Calendar API. With this update, developers can now:
  • Read conference data associated with events 
  • Copy conference data from one event to another 
  • Request new conference generation for an event 
The API supports all Hangouts versions.

Reading conference data 

Conference information is stored in a new event attribute called conferenceData. conferenceData provides information about the solution that was used to create the conference (such as Hangouts Meet) and a set of entry points (like a video call link and phone number). Everything the user needs to know to join a conference call is there.

To help you build even better user experiences, we also give you access to icons and user-readable labels that you can use in your products. In JSON format, conferenceData looks something like this (of course, your actual meeting IDs and phone numbers will vary):
"conferenceData": {
"entryPoints": [
{
"entryPointType": "video",
"uri": "https://meet.google.com/wix-pvpt-njj",
"label": "meet.google.com/wix-pvpt-njj"
},
{
"entryPointType": "more",
"uri": "https://tel.meet/wix-pvpt-njj?pin=1701789652855",
"pin": "1701789652855"
},
{
"entryPointType": "phone",
"uri": "tel:+44-20-3873-7654",
"label": "+44 20 3873 7654",
"pin": "6054226"
}
],
"conferenceSolution": {
"key": {
"type": "hangoutsMeet"
},
"name": "Hangouts Meet",
"iconUri": "https://lh5.googleusercontent.com/proxy/bWvYBOb7O03a7HK5iKNEAPoUNPEXH1CHZjuOkiqxHx8OtyVn9sZ6Ktl8hfqBNQUUbCDg6T2unnsHx7RSkCyhrKgHcdoosAW8POQJm_ZEvZU9ZfAE7mZIBGr_tDlF8Z_rSzXcjTffVXg3M46v"
},
"conferenceId": "wix-pvpt-njj",
"signature": "ADwwud9tLfjGQPpT7bdP8f3bq3DS"
}

And this, for example, is how you would retrieve and display conference solution name and icon:
var solution = event.conferenceData.conferenceSolution;

var content = document.getElementById("content");
var text = document.createTextNode("Join " + solution.name);
var icon = document.createElement("img");
icon.src = solution.iconUri;

content.appendChild(icon);
content.appendChild(text);
The result of the code above will look like this in the user interface:

Copying conferences across events 

Sometimes displaying information is not enough—you might want to update it as well. This is especially true when scheduling multiple Calendar events with the same conference details. Say you’re developing a recruiting application that sets up separate events for the candidate and the interviewer; you want to protect the interviewer’s identity, but you also want to make sure all participants join the same conference call. To do this, you can now copy conference information from one event to another by simply writing to conferenceData.

To ensure that only existing Hangouts conferences are copied, and to help safeguard your users against malicious actors, copied conference data will always be verified by the Google Calendar API using the signature field, so don’t forget to copy it too.

Creating a new conference for an event 

Finally, the API allows developers to request conference creation. Simply provide a conferenceData.createRequest and set the conferenceDataVersion request parameter to 1 when creating or updating events. Conferences are created asynchronously, but you can always check the status of your request to let your users know what’s happening. For example, to request conference generation for an existing event (again, your request and event IDs will be different):
var eventPatch = {
conferenceData: {
createRequest: {requestId: "7qxalsvy0e"}
}
};

gapi.client.calendar.events.patch({
calendarId: "primary",
eventId: "7cbh8rpc10lrc0ckih9tafss99",
resource: eventPatch,
sendNotifications: true,
conferenceDataVersion: 1
}).execute(function(event) {
console.log("Conference created for event: %s", event.htmlLink);
});
The immediate response to this call might not yet contain the fully-populated conferenceData which is indicated by status pending:
"conferenceData": {
"createRequest": {
"requestId": "7qxalsvy0e",
"conferenceSolutionKey": {
"type": "hangoutsMeet"
},
"status": {
"statusCode": "pending"
}
}
}
Once the statusCode changes to success, the conference information is populated. Finally, if you are developing a Google Calendar client, you might also want to know beforehand which of the three Hangouts solutions (consumer Hangouts, classic Hangouts and Hangouts Meet) will be used to create the conference. You can get that information by checking allowedConferenceSolutionTypes in a calendar’s conferenceProperties.

To get started, check out the documentation page for managing conference data. We can’t wait to see what you build with these new features in the Google Calendar API.

Committed to storage APIs, retiring Realtime API


We launched Google Realtime API in 2013 to help developers build collaborative apps using familiar JSON-based data models, while leaving the complexities of real-time synchronization to the API. Since then, we've developed other fast, flexible cloud-based storage solutions like Google Cloud SQL and Google Cloud Firestore. As a result, we’ve decided to deprecate Realtime API in favor of these new, powerful solutions.

We’re investing heavily in Google Cloud Platform, as well as Firebase—our mobile development platform—to help developers build scalable, performant applications. While these solutions aren't a direct analog to the Drive Realtime API, we're confident they can meet most of your needs:
  • Google Cloud SQL: Fully-managed database service that makes it easy to set up, maintain, manage, and administer your relational PostgreSQL and MySQL databases in the cloud. 
  • Firebase Realtime Database: Cloud-hosted NoSQL database that lets you store and sync data between your users in real-time. 
  • Cloud Firestore: We recently announced Cloud Firestore to help developers build responsive apps that work regardless of network latency or Internet connectivity. If you're curious about Firebase Realtime Database vs. Cloud Firestore, we've got you covered.
Existing Realtime API client applications will continue to work normally until December 11, 2018, but we are no longer accepting new clients of the API. After the API is decommissioned, to facilitate migration, we will continue to provide a mechanism for applications to access document contents as JSON.

More specific deprecation timelines 

We know developers and partners have come to rely on Realtime API and that migration may be a significant effort. We hope that the deprecation timelines summarized below allow for a smooth transition.


November 28, 2017
Realtime API is no longer available for new projects.1
December 11, 2018
Realtime API documents become read-only, and attempts to modify document contents using the API fail.
January 15, 2019
Realtime API is shut down, but a JSON export API remains available.
1 Projects which accessed the Realtime API prior to November 28, 2017 (including your projects listed below) will continue to function as before. All other projects, including new projects, will be blocked from accessing the Realtime API.

Migration tips 

Applications using the Realtime API will need to migrate to another data store. Our migration guide provides instructions on how to export Realtime document data and also how that data can be imported into Google Cloud Firestore. After Realtime API is shut down, we will continue to provide a means for exporting Realtime document contents as JSON.

Additional information and support 

You can read more about the deprecation in our documentation. If you have questions that aren’t answered there, see the support page for how to get help.

Gmail add-ons framework now available to all developers



Email remains at the heart of how companies operate. That’s why earlier this year, we previewed Gmail Add-ons—a way to help businesses speed up workflows. Since then, we’ve seen partners build awesome applications, and beginning today, we’re extending the Gmail add-on preview to include all developers. Now anyone can start building a Gmail add-on.

Gmail Add-ons let you integrate your app into Gmail and extend Gmail to handle quick actions. They are built using native UI context cards that can include simple text dialogs, images, links, buttons and forms. The add-on appears when relevant, and the user is just a click away from your app's rich and integrated functionality.

Gmail Add-ons are easy to create. You only have to write code once for your add-on to work on both web and mobile, and you can choose from a rich palette of widgets to craft a custom UI. Create an add-on that contextually surfaces cards based on the content of a message. Check out this video to see how we created an add-on to collate email receipts and expedite expense reporting.

Per the video, you can see that there are three components to the app’s core functionality. The first component is getContextualAddOn()—this is the entry point for all Gmail Add-ons where data is compiled to build the card and render it within the Gmail UI. Since the add-on is processing expense reports from email receipts in your inbox, the createExpensesCard()parses the relevant data from the message and presents them in a form so your users can confirm or update values before submitting. Finally, submitForm() takes the data and writes a new row in an “expenses” spreadsheet in Google Sheets, which you can edit and tweak, and submit for approval to your boss.

Check out the documentation to get started with Gmail Add-ons, or if you want to see what it's like to build an add-on, go to the codelab to build ExpenseIt step-by-step. While you can't publish your add-on just yet, you can fill out this form to get notified when publishing is opened. We can’t wait to see what Gmail Add-ons you build!

[Q&A] Behind the scenes with Lucidchart: building new diagramming add-on in Google Slides


You might have seen that we recently announced new Google Slides add-ons. We worked closely with several technology partners to build these new add-on solutions to help speed up workflows. 

One partner, Lucidchart, worked closely with Google to create a new integration that brings added diagramming functionality to Slides. We sat down with Tim Winchester, engineering lead at Lucidchart, to learn more about how his team built the new Lucidchart add-on for Slides.

Tell us about the Google Slides add-on you built for Lucidchart. 

We built it as a sidebar add-on that allows users to insert diagrams directly into Google Slides from within Slides (instead of having to export diagrams from Lucidchart). You can also create a new Lucidchart diagram from within Slides, and simply select “Back to Slides” once you’re finished creating your diagram in the Lucidchart editor. You can modify an existing diagram by clicking “Edit” within Slides. This option will direct you to the Lucidchart editor so you can revise as needed. Once you’ve finished revising, or any time you know a diagram has been updated in Lucidchart, select the refresh button from the Lucidchart Diagrams sidebar.

What prompted you to create your add-on? 

Specifically, how did you envision your add-on would improve user experience? Lucidchart is a visual communication platform, but we know our users sometimes need to have their diagrams available in other places. One of the most popular uses for Lucidchart is in presentations, so an add-on for Slides was a natural fit.

Tell us about how you built your solution. 

Since we already had existing add-ons for Docs and Sheets, this project was less about building from scratch and more about adapting what we already had, then doing rewrites as needed. We started by abstracting app-specific functionality of our existing add-ons into a pluggable IntegratedApp interface. We then implemented the interface for Slides using the new SlidesApp API. Once we had reached feature parity, we created a few new additions, such as a “Refresh All Inserted Diagrams” button, which users could find more easily than a top bar menu entry.



At the same time, the Lucidchart add-on was undergoing a major UI overhaul, which was the most challenging and time-intensive part of the project. Because we liked the results of the UI update in Slides, we refactored the add-on code to make it more generalizable, then ported it back to our Docs and Sheets add-ons.

Did anything surprise you during the build? 

As a security measure, the sidebar iframe can only render elements within its borders, so we couldn’t simply throw a <div> into the center of the screen in client code. Instead, we had to fire an event that the Apps Script backend would handle to create a modal dialog, using printing scriptlets to add whatever data we needed into the dialog’s HTML. Thus, any JS object sent from the sidebar to a modal has to be serialized and deserialized in the process, which means that the sidebar cannot directly detect any events emitted by the modal.

Do you have any code snippets that you can share? 

Because we have multiple Google Apps Script add-ons that share lots of functionality, it was very useful to concentrate app-specific code and strings into a wrapper object (called IntegratedApp), which we then referenced elsewhere in the codebase instead of calling SlidesApp directly. So, in the click handler for the insert button, instead of writing this...
SlidesApp.getActivePresentation()
.getSelection()
.getCurrentPage()
.insertImage(image);

...we write this.
IntegratedApp.insertImage(image);

And then we keep the app-specific implementation in our IntegratedApp object (abridged for clarity):
var IntegratedApp = {
// direct mapping to function
createAddonMenu: SlidesApp.getUi().createAddonMenu.bind(SlidesApp.getUi()),

// wrapper to create consistent behavior across apps
insertImage: function(image) {
return SlidesApp.getActivePresentation()
.getSelection()
.getCurrentPage()
.insertImage(image);
},

// app-specific strings
phrases: {
docType: 'Slide',
name: 'Google Slides',
nameWithDocType: 'Google Slides Presentation'
}
};

This technique allows us to keep the same UI code and business logic across apps; we only need to change the implementation of the IntegratedApp object. So in Sheets (for example), our IntegratedApp.insertImage() function becomes:
insertImage: function(image) {
var sheet = SpreadsheetApp.getActiveSheet();
var cell = sheet.getActiveCell();

sheet.insertImage(image, cell.getColumn(), cell.getRow());
}

What advice would you give other developers looking to build similar add-ons? 

If you are planning to develop multiple similar add-ons that mainly differ in the G Suite app with which they integrate, you should find this technique of reducing the overall code amount by isolating duplicative code immensely useful.

After completing the first add-on, creating another add-on for a new G Suite app is just a matter of updating a new copy of IntegratedApp to work with the new app; the rest of the codebase can be commonly shared. In our case, it means that the updated UI was easily added to our Docs and Sheets add-on after we completed the Slides add-on.

Learn more about how you can create your own Slides add-ons or choose from a number of publicly available APIs to customize your G Suite applications. If you’re interested in becoming a Google Cloud technology partner, you can also join our partnership program.

Generating Google Slides from images using Apps Script



Today, we announced a collection of exciting new features in Google Slides—among these is support for Google Apps Script. Now you can use Apps Script for Slides to programmatically create and modify Slides, plus customize menus, dialog boxes and sidebars in the user interface.

Programming presentations with Apps Script

Presentations have come a long way—from casting hand shadows over fires in caves to advances in lighting technology (magic lanterns) to, eventually, (in)famous 35mm slide shows of your Uncle Bob's endless summer vacation. More recently, we have presentation software—like Slides—and developers have been able to write applications to create or update them. This is made even easier with the new Apps Script support for Google Slides. In the latest G Suite Dev Show episode, we demo this new service, walking you through a short example that automatically creates a slideshow from a collection of images.
To keep things simple, the chosen images are already available online, accessible by URL. For each image, a new (blank) slide is added then the image is inserted. The key to this script are two lines of JavaScript (given an existing presentation and a link to each image):

var slide = presentation.appendSlide(SlidesApp.PredefinedLayout.BLANK);
var image = slide.insertImage(link);

The first line of code adds a new slide while the other inserts an image on the new slide. Both lines are repeated for each image in the collection. While this initial, rudimentary solution works, the slide presentation created doesn't exactly fit the bill. It turns out that adding a few more lines make the application much more useful. See the video for all the details.

Getting started 

To get started, check the documentation to learn more about Apps Scripts for Slides, or check out the Translate and Progress Bar sample Add-ons. If you want to dig deeper into the code sample from our video, take a look at the corresponding tutorial. And, if you love watching videos, check out our Apps Script video library or other G Suite Dev Show episodes. If you wish to build applications with Slides outside of the Apps Script environment and want to use your own development tools, you can do so with the Slides (REST) API—check out its documentation and video library.

With all these options, we look forward to seeing the applications you build with Google Slides!

Back to school with enhancements to the Classroom API



Google Classroom makes it easy for teachers and students to use the edtech tools they love, and that’s not just limited to Google tools. With the Classroom API, hundreds of developers have built integrations with Classroom that make it easier for admins and teachers to manage classes, share content and more.

One popular way that applications integrate with Classroom is by re-using Classroom rosters—teachers can import their classes with a click and students don’t have to have a new login. Today, we’re making it easier for developers to keep rosters in-sync between their apps and Classroom by launching real-time notifications of changes.

Now, an application can now receive roster changes for a domain, or for an individual course. Powered by Google Cloud Pub/Sub, a state-of-the-art messaging service for passing information between applications, developers no longer have to poll various Classroom API endpoints for changes, which gives teachers and students a more seamless experience. If a new student joins or leaves a Classroom class, that roster change can be automatically applied across applications.

How Flat Education syncs rosters in real-time 

Flat Education, a collaborative music notation app, uses the new updates to instantly update class rosters. Before, when teachers and students accessed the Flat Education application, it would poll the Classroom API for changes and then make updates, delaying data. Now, roster data can be refreshed instantly.
With today's Classroom API update, applications can sync roster data instantly. When a new student joins Google Classroom (bottom left), the student is instantly added to the corresponding music class in Flat Education (top right).

We’re also making the Classroom API more comprehensive with additional enhancements so you can:
  • Create and update announcements. Last year, we launched the ability for external applications to access and create assignments and questions. This update gives applications access to all the posts in Classroom. 
  • Create and update individualized posts. Earlier this year, we made it possible for teachers to post to individual students in Classroom and now, applications can do the same programmatically. This is especially helpful for applications that help teachers differentiate and individualize learning.
For more details on what you can build with the Classroom API, check out the documentation. You can also ask questions (or answer them!) on StackOverflow using the google-classroom tag, and report bugs or feature requests via the issue tracker.

Lastly, let us know what you're building using the #withClassroom hashtag on Twitter or Google+.

Monitoring the Apps Script issue tracker…with Apps Script



Apps Script is just as popular inside Google as it is among external users and developers. In fact, there are more than 70,000 weekly active scripts written by thousands of Googlers. One of our many uses for Apps Script at Google is to automate and monitor our internal issue tracker.

Your business depends on Apps Script...so does ours 

In spring of this year, we migrated our G Suite issue trackers to a new system based on our internal tracker. This carries a lot of benefits, including improving our ability to track how issues reported from outside of Google relate to bugs and features we’re working on internally. We also have an internal Apps Script API that talks to our issue tracker, which we can now use to work with issues reported from outside of Google.

As soon as the migration was finished, we put Apps Script to work monitoring…itself. Now we have a script in place that monitors Apps Script issues as they are reported and upvoted on the public tracker. When we see an issue that’s having widespread or sudden impact, the script generates an alert that we can then investigate. With the help of our large, active community of developers, and leveraging Apps Script, we’re now able to identify and respond to issues more quickly.

There’s no substitute for independent monitoring, and our Apps Script-based approach isn’t the first or the last line of defense. Instead, this new script helps us catch anything that our monitoring systems miss by listening to what developers are saying on the tracker.

If you see something, say something 

Please help us keep Apps Script humming! When you notice a problem, search the issue tracker for it and file an issue if it's new. Click the star to let us know you’re affected and leave a comment with instructions to reproduce, along with any other relevant details. Those instructions and other details help us respond to the issues more effectively, so please be sure to include them.

Happy scripting!

Stackdriver Logging for Google Apps Script is now available


Google Apps Script has always provided a simple logging tool—the Logger service—to help developers better test their scripts. This works for many simple use cases, but developers need other ways to log messages and errors, particularly when:
  • Troubleshooting or analyzing scripts across multiple executions
  • Working on a script or add-on with multiple users 
  • Looking for trends or insights about their scripts and users
To make Apps Script a friendlier environment for developers, we are announcing general availability of a new integration with Google Stackdriver. This is in addition to the pre-existing Logger service, which is still available.

Using Stackdriver Logging in Google Apps Script

Log messages can now be sent to Stackdriver Logging using the familiar console.log(), console.info(), etc. functions. You can also instruct Apps Script to log messages and stack traces for all exceptions, which also become available for analysis in Stackdriver Error Reporting by simply checking a box. No need to add a single extra line of code.

In Stackdriver, logs are kept for 7 days for free, and the premium tier offers 30-day retention. Powerful search and filtering are available to quickly find log entries by text content or metadata, and developers can also choose to export logs to BigQuery, Cloud Storage, and Cloud Pub/Sub for further analysis, long term conservation, and custom workflows.

Log messages and errors are reported for all users of a script, with a unique but obfuscated identifier assigned to each user. This means log entries can be aggregated anonymously per user, for example allowing developers to count unique users impacted by an issue or analyze user behavior, but without logging users’ personally identifying information.


Developers get some of these aggregated analyses for free. In the Stackdriver Error Reporting tab of the developer console, you can see recurring errors and the numbers of users impacted. You can even subscribe to receive an email alert when a new type of error is detected.


How developers are using Stackdriver Logging

Developers of scripts and add-ons have started to rely more on more on this new logging capability. Romain Vialard, creator of Yet Another Mail Merge, a popular Google Sheets add-on, is using Stackdriver Logging to time the execution of his add-on, exporting data to BigQuery to perform aggregations and analyze trends. Read this tutorial to learn how to export logs to BigQuery and run queries to analyze how users are interacting with your script.

Stackdriver Logging is one of the ways we’re making Apps Script a more manageable platform for developers. We hope that it and other features coming soon make Apps Script developers more productive and their scripts, add-ons and integrations more robust.

You can read more about how to enable and use the Stackdriver integration by reading Apps Script’s logging documentation.

About the authors 

Romain Vialard is a Google Developer Expert. After some years spent as a consultant, he is now focused on products for G Suite (formerly Google Apps) users, including add-ons such as Yet Another Mail Merge and Form Publisher.

Paul McReynolds is a Product Manager at Google focused on Apps Script and G Suite Marketplace. Previously a startup founder and CTO, Paul believes that the easy things need to be easy or the hard things don’t get done. At Google, he's excited to be a part of the company that makes solving problems for business fun again.

Editor's note: Yet Another Mail Merge and Form Publisher are not created, sponsored, or supported by Google.

Introducing the Slides API Codelab



Last fall, we launched the Google Slides API. Since then, partners, developers and others have been building apps and tools to programmatically create slides that work across desktop and mobile, like the ever popular md2googleslides.

We recently released the Slides API Codelab, which walks you through an example of using Google’s BigQuery and Slide APIs to analyze 3.5 million repositories and create a “Top 10 OSS licenses” presentation. The codelab is a great exercise for learning the Slides API, especially if you have an interest in big data, automating the creation of presentations or open source.
Preview of our Slides Codelab

Getting started with the Slides API Codelab 

To get started, clone the repo. After running the starter script, you’ll find that creating a presentation is divided up into contained steps. These “TODOs” are shown when running the sample app in the start directory.
-- Start generating slides. --
TODO: Get Client Secrets
TODO: Authorize
TODO: Get Data from BigQuery
TODO: Create Slides
TODO: Open Slides
-- Finished generating slides. --

To query GitHub, BigQuery has a public dataset all ready just for you! BigQuery allows you to query massive datasets on Google’s infrastructure in seconds. On bigquery.cloud.google.com, you can explore BigQuery’s public datasets or upload your own. In this codelab, we’re interested in open source licenses, so we'll query public repos on GitHub and grab their licenses.
WITH AllLicenses AS (
SELECT * FROM `bigquery-public-data.github_repos.licenses`
)
SELECT
license,
COUNT(*) AS count,
ROUND((COUNT(*) / (SELECT COUNT(*) FROM AllLicenses)) * 100, 2) AS percent
FROM `bigquery-public-data.github_repos.licenses`
GROUP BY license
ORDER BY count DESC
LIMIT 10
Our GitHub Open Source Licenses Query
With an infinite number of public and private datasets out there, imagine all the data you can analyze with BigQuery and all the slide decks you can auto-generate with the Google Slides API! The goal of the Slides API Codelab is to get you up-to-speed quickly using both. For issues or questions regarding the Slides API or this codelab, ask us a question on GitHub or Stack Overflow.

We can't wait to see what you build.