Tag Archives: developers

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!

Startup with Google, a resource to help young companies succeed

Since 2011, Google has partnered with over 50 community organizations to help startup communities around the world flourish. Startups within those communities and spaces we run have created more than 40,000 jobs and raised more than $3.9 billion in funding. Today we’re introducing a new resource to help young companies continue to make their big ideas a reality—Startup with Google.

Ivonna Dumanyan and Gabrielle Levac are lifelong athletes. When they started playing Division 1 sports in college, they were often sidelined by injuries, leaving them isolated from their teams and forcing them to miss precious opportunities to compete after months of training. They realized these recurring injuries could be avoidable—and decided to do something about it. They developed a small, wearable device that could detect fatigue, then alert coaches and training staff of elevated injury risk.

Their device was a big hit, and soon their idea grew into Fathom AI, a startup that uses artificial intelligence to help collegiate athletes avoid injuries. Based in Durham, NC, the Fathom team works out of the American Underground tech hub space, a Google for Entrepreneurs partner. There, the Fathom team receives mentorship, training, and access to a community as well as Google resources and programming. 

Ivonna and Gabrielle are just two of the many startup founders who have taken advantage of Google's startup resources and communities to get the expertise and connections to help them grow, as well as tools like G Suite, Google Cloud, AdWords, Android and Google Play to help them build. Now, by bringing together all our resources for startups in one place with Startup with Google, we hope to make it even easier for startups like Fathom to thrive.

ft
Ivonna Dumanyan and Gabrielle Levac, founders of Fathom AI

At Startup with Google, you'll find insights from startup founders and Google teams on hiring, improving team collaboration, and raising a round of funding. Startup with Google also features our network of Campus coworking spaces, Google Developers Launchpad programs, and partner communities, which provide opportunities for founders to connect with the local community, mentors, and investors who can help them succeed.

Startup founders like Ivonna and Gabrielle have big things to accomplish. We can help them, and other founders—check out startup.google.com to find Google's resources for startups, all in one place.

Introducing Android Native Development Kit r16

Posted by Dan Albert, Android NDK Tech Lead

The latest version of the Android Native Development Kit (NDK), Android NDK r16 Beta 1, is now available for download. It is also available in the SDK manager via Android Studio.

NDK r16 is a big milestone for us, because it's the first release that we're ready to recommend that people start migrating to libc++! More on this later.

We've also updated libc++ and its related projects, so this release has improved support for C++1z. Keep in mind that until C++1z becomes C++17, everything included is subject to change.

You can find the release notes for this release here.

libc++ and libandroid_support

The NDK has a library called libandroid_support that backports libc APIs that libc++ depends on that weren't available on older releases. The reason we've been unable to endorse libc++ (as implemented in the NDK) until now has been a lack of confidence in this library. The focus of r16 was to rewrite this library for improved stability.

Since libandroid_support is now a smaller library, your app's behavior should more closely match the behavior of the system. As an example, libandroid_support previously included an alternative implementation of part of stdio. While some features got backported to ICS, it also meant that any bugs in the alternate implementation would be present on all OS releases since the bug was baked into your app. In the new version of libandroid_support, we've removed this so you'll be missing some features on older devices (almost exclusively things that no one uses, like %a support in format strings), but your apps using libc++ will be smaller and more reliable for not having these features.

Switching to libc++

So, why should you switch to libc++? First and foremost, the other STLs will not be supported going forward (this has been noted in our roadmap for quite some time). We've been using libc++ for the Android platform since Lollipop, and that's been a change that our engineers have been overwhelmingly happy with. We were able to make this transition in the platform earlier than we could in the NDK because we didn't need libandroid_support, and could instead just update libc in place.

In contrast to the other STLs currently available in the NDK, libc++ fully supports C++11, C++14, and most of C++1z! Stlport hasn't had an update since 2008, and gnustl (what we call GNU's libstdc++, to avoid confusion with Bionic's libstdc++, which isn't an STL) historically hasn't worked very well with Clang, particularly in headers that are closely tied to compiler builtins like and .

We'll most likely be making libc++ the default in the next NDK release, but for now you can opt-in if you're not using it already by following the instructions below.

Like the other STLs, libc++ is available as both a static and shared library. Which one you should use depends on your specific circumstances as described in our docs, but tl;dr use the static version if you have one and only one shared library in your application, and use the shared one in all other cases.

ndk-build

Add the following to your Application.mk file:

APP_STL := c++_shared
CMake

Pass the following when invoking CMake:

-DANDROID_STL=c++_shared

If you're using CMake via Gradle, add the following to your build.gradle:

externalNativeBuild {
    cmake {
        arguments "-DANDROID_STL=c++_shared"
    }
}
Standalone Toolchain

When you create your standalone toolchain, pass --stl=libc++.

The Future of libandroid_support

If you've read our roadmap, you've seen that we've planned to expand libandroid_support to backport as much of libc/libm as possible. Whenever we've spoken with people about this, we've received lukewarm responses at best. Given that this doesn't seem to be a thing that people are interested in, and that it would be something that increases library size (and therefore APK size, which is something everyone seems very interested in), we no longer plan to do this.

If we've misinterpreted your response or if we haven't heard from you and this is something you want, please let us know!

_FILE_OFFSET_BITS=64

tl;dr: Don't set _FILE_OFFSET_BITS=64 if you want to keep the behavior present in old NDKs.

Historically, setting _FILE_OFFSET_BITS=64 in the NDK did nothing. This feature was not present in the deprecated headers at all. With unified headers, the NDK now has up to date headers with support for this feature.

_FILE_OFFSET_BITS=64 is a macro you can define in your application to get support for a 64-bit off_t in 32-bit code. This works by both making off_t 64-bit (by default it is 32-bit in 32-bit code) and by implicitly replacing calls to APIs like lseek with calls to lseek64.

Support for _FILE_OFFSET_BITS=64 was not added to Android in a single release. One API, lseek64, has always been in bionic. Most APIs were added in Lollipop, and a few more were not added until later releases.

If you're targeting a release that does not support the 64-bit off_t variant of a function you are using and have set _FILE_OFFSET_BITS=64, the function will not be available. This is in contrast to the behavior for r15 and r15b (but matches r15c) where the functions were wrongly exposed with a 32-bit off_t that would be silently truncated.

Note that the 64-bit off_t APIs are still available without _FILE_OFFSET_BITS=64 under different names. For example, instead of lseek, call lseek64. Instead of off_t, use off64_t.

Finally, since this feature is new to the NDK with unified headers, if you just want to return to the pre-unified headers behavior, all you need to do is stop setting _FILE_OFFSET_BITS=64.

For more information about off_t ABI details in bionic, see the Bionic 32-bit ABI bugs doc.

Funding 75,000 Udacity scholarships to bridge the digital skills gap

Ildiko Fekete is a mother of two from Hungary, who had moved to a small town to raise her family, taking time out from her career as a literature teacher.  Earlier this year she applied for and completed an Android scholarship. As a result she has built an eco-footprint app, Greenfeet, and plans to pursue freelance developer work.

Today in Krakow, at Google Developer Days - Europe, our biggest European developer event, scholarship recipients like Ildiko will join 2000 other developers from all over Europe to learn about the newest developer technologies and improve their skills.

Despite this enthusiasm, the growing digital skills gap has lead the EU to predict that half a million ICT (Information and Communication Technologies) jobs will remain unfilled by 2020.

Last year, along with Bertelsmann and Udacity we offered 10,000 Android developer scholarships to help people like Ildiko reach their goals. We were humbled by the overwhelming demand for these courses, so I’m happy to announce that together with Bertelsmann & Udacity we’ll be offering 75,000 more people the opportunity to benefit from free developer courses.

Today, we’re opening our 60,000 Scholarships Challenge, for both absolute beginners and for existing programmers, which will include both Android and Web development courses. For more details and to apply, please see: https://www.udacity.com/google-scholarships.

Later this year, Bertelsmann will also offer an additional 15,000 Scholarships Challenge for beginners and advanced students in the field of data science. We’ll share more details on these in the coming weeks.

We hope that this initiative will help scholarship recipients get the in-demand skills needed to get a job or advance their career.

Funding 75,000 Udacity scholarships to bridge the digital skills gap

Ildiko Fekete is a mother of two from Hungary, who had moved to a small town to raise her family, taking time out from her career as a literature teacher.  Earlier this year she applied for and completed an Android scholarship. As a result she has built an eco-footprint app, Greenfeet, and plans to pursue freelance developer work.

Android Udacity recipient Ildiko Fekete's story

Today in Krakow, at Google Developer Days - Europe, our biggest European developer event, scholarship recipients like Ildiko will join 2000 other developers from all over Europe to learn about the newest developer technologies and improve their skills.

Despite this enthusiasm, the growing digital skills gap has lead the EU to predict that half a million ICT (Information and Communication Technologies) jobs will remain unfilled by 2020.

Last year, along with Bertelsmann and Udacity we offered 10,000 Android developer scholarships to help people like Ildiko reach their goals. We were humbled by the overwhelming demand for these courses, so I’m happy to announce that together with Bertelsmann & Udacity we’ll be offering 75,000 more people the opportunity to benefit from free developer courses.

Today, we’re opening our 60,000 Scholarships Challenge, for both absolute beginners and for existing programmers, which will include both Android and Web development courses. For more details and to apply, please see: https://www.udacity.com/google-scholarships.

Later this year, Bertelsmann will also offer an additional 15,000 Scholarships Challenge for beginners and advanced students in the field of data science. We’ll share more details on these in the coming weeks.

We hope that this initiative will help scholarship recipients get the in-demand skills needed to get a job or advance their career.

Funding 75,000 Udacity scholarships to bridge the digital skills gap

Ildiko Fekete is a mother of two from Hungary, who had moved to a small town to raise her family, taking time out from her career as a literature teacher.  Earlier this year she applied for and completed an Android scholarship. As a result she has built an eco-footprint app, Greenfeet, and plans to pursue freelance developer work.

Android Udacity recipient Ildiko Fekete's story

Today in Krakow, at Google Developer Days - Europe, our biggest European developer event, scholarship recipients like Ildiko will join 2000 other developers from all over Europe to learn about the newest developer technologies and improve their skills.

Despite this enthusiasm, the growing digital skills gap has lead the EU to predict that half a million ICT (Information and Communication Technologies) jobs will remain unfilled by 2020.

Last year, along with Bertelsmann and Udacity we offered 10,000 Android developer scholarships to help people like Ildiko reach their goals. We were humbled by the overwhelming demand for these courses, so I’m happy to announce that together with Bertelsmann & Udacity we’ll be offering 75,000 more people the opportunity to benefit from free developer courses.

Today, we’re opening our 60,000 Scholarships Challenge, for both absolute beginners and for existing programmers, which will include both Android and Web development courses. For more details and to apply, please see: https://www.udacity.com/google-scholarships.

Later this year, Bertelsmann will also offer an additional 15,000 Scholarships Challenge for beginners and advanced students in the field of data science. We’ll share more details on these in the coming weeks.

We hope that this initiative will help scholarship recipients get the in-demand skills needed to get a job or advance their career.

Source: Education


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.

Dance Tonite, an ever-changing VR collaboration by LCD Soundsystem and fans

Sometimes beautiful things happen when worlds collide. In 2002, LCD Soundsystem mashed together electronic dance music and punk rock—an unlikely pairing that brought fun and humanity to two genres that had moved away from their experimental beginnings. I’ve always admired the band’s combination of minimalism, honesty, and contagious energy—and today I’m pleased to introduce Dance Tonite, a VR collaboration celebrating LCD Soundsystem’s latest single, “Tonite.”

dance_tonite_blogpost_img1.gif

Dance Tonite takes an exuberant, unexpected approach to virtual reality. It’s a dance party. And it’s also a dance viewing party. In it, you go from room to room experiencing a series of dance performances created entirely by fans. All choreography was recorded using room-scale VR setups, which use headset and controller tracking to reflect your physical movements in your virtual environment. Instead of just mirroring your movements, we turn your room-scale VR kit into a DIY motion capture tool; if you have one, you can add your own moves to the party.

This video might help to explain.

Individual performers in Dance Tonite are represented by simple moving objects—just a cone and two cylinders. Even though they’re all represented by the same basic shapes, the experience captures the idiosyncrasies of each person's movements. The constraints encourage creativity and diversity, while the overall experience expands and changes with each new contribution.

dance_tonite_blogpost_img2.jpg

Dance Tonite was designed to work across different devices. If you have Daydream View, you’re on stage watching the performance move around you.

dance_tonite_blogpost_img3.png

If you happen to have a room-scale VR headset, go on and add your moves to the experience.

dance_tonite_blogpost_img4.png

And if you don’t have a VR headset, not to worry. You can still watch the experience from a bird's-eye view with the ability to click on any performer's head to see it from their perspective.

dance_tonite_blogpost_img5.png

Dance Tonite uses WebVR, a new open standard that brings high-quality VR content to the web. That means that you can enter the experience through a single URL–no apps or downloads needed. As developers, we were able to create a scalable experience using web infrastructure and a single codebase.

Dance Tonite was directed by artists Jonathan Puckey and Moniker, in collaboration with the Data Arts Team— a specialized group within Google exploring the ongoing dialog between artists and emerging technologies. If you’d like to learn more about how this project was made, we’ve released the code open source. You can also read about our process and learnings using an experimental technology (WebVR) in a new medium (VR).

Dance Tonite was directed by artists Jonathan Puckey and Moniker, in collaboration with the Data Arts Team— a specialized group within Google exploring the ongoing dialog between artists and emerging technologies. If you’d like to learn more about how this project was made, we’ve released the code open source. You can also read about our process and learnings using an experimental technology (WebVR) in a new medium (VR).

See you at Dance Tonite. Remember to dance like nobody’s watching.*

*Millions of people are watching.

It must be nice to have Hamilton on your phone

HAMILTON fans got a treat last Friday when the team behind the broadway hit released … Wait for It … an app! Available on Android and iOS, the app lets you enter the #Ham4Ham lottery more easily and has fun features for the biggest HAMILTON fans out there. It was also one of the first apps to be built with Firebase, Google’s mobile development platform to handle the backend and infrastructure, as well as Flutter, a new UI toolkit to make it easy and fast to build high-performance, modern, beautiful apps for iOS and Android.

To learn more about how the app was built, and why the HAMILTON team chose to use Flutter and Firebase, we sat down fan to fan with Mike Karns, HAMILTON’s director of social media, and David DeRemer from POSSE, who helped build the HAMILTON app.

Seth: What made you decide to build and launch a mobile app?

Mike: We’re always looking for opportunities to create a unique experience for the HAMILTON community, whether or not they’re able to be in the theatre each night. This app expands our presence in digital space and brings fans closer to HAMILTON.

How did you decide which features to include?

Mike: It started as a way for people to enter the HAMILTON lottery, and we brainstormed more ideas from there. Because HAMILTON has broken the confines of normal Broadway scope and audience, we’ve been able to build a really diverse fanbase in terms of age, location, etc. So all of our ideas served the purpose of giving those fans ways to connect with HAMILTON in more real ways.

David: It was all about providing access. HAMILTON is in such high demand, yet so many people love it and it’s so important from a historical and artistic perspective. How do make sure the HAMILTON community doesn’t feel like an exclusive club that requires thousands of dollars to be in? That’s ultimately what the lottery is for, and we’re improving the experience. Before you had to go the website every day and re-enter your info—now you can get a reminder and then enter in one tap.

Then there are the other features like shareable stickers with lyrics and HAMILTON emojis, #HamCams (HAMILTON-themed photo filters), a merch store, and exclusive content from cast members that make it even more fun. We wanted to go beyond the lottery and keep things interesting for someone who might have tickets to see the show a year from now. And we’ve got a lot of ideas for more features to make sure it’s still compelling even in five or seven years.

Hamilton App.png

How did you decide to use Flutter to build and manage your app?

Mike: We knew we’d have to build this app quickly, while also making sure that HAMILTON was accessible to everyone. To democratize the brand, there was never any question that we’d have to build an app that was available on both Android and iOS.

David: That’s why we decided to use Flutter, a new modern, reactive UI toolkit that is portable across iOS and Android. Flutter allows us to have a less complicated codebase, which means we can be more efficient and keep parity between platforms.

Because Flutter is new, this was also a unique opportunity to collaborate with Google to improve the Flutter SDK. We provided a lot of feedback and bug reports throughout the development process! The result is something really unique—I don't think there are many other apps that use this technology yet. And not too many companies would have had the willingness to work with us and take a risk like that. It really ties into the HAMILTON idea of not throwing away your shot! By the way, developers can even find some HAMILTON easter eggs in the Flutter documentation.

And what about Firebase?

David: Firebase was also a critical component building a great app for our fans. With Firebase, we didn’t have to worry about setting up and maintaining servers. Instead, we were able to spend more time designing beautiful UIs and testing new interactions. In addition, a key feature of the app is the ticket lottery, which offers fans a chance to get tickets to the constantly sold-out HAMILTON show. We used Cloud Functions for Firebase to help coordinate the lottery workflow between the mobile app, custom business logic, and partner services.

What does success look like for you?

David: The lottery is the number one feature, so if the lottery works better, that will be a success. Success is also determined by the percentage of people have an issue and how many bugs are there, and if it scales. And I just hope that it helps fans connect to HAMILTON.

Mike: Lin-Manuel Miranda frequently says to his fans, "Here, I made this for you...". We’ll feel that we've accomplished our goal when fans everywhere are using this app to share their passion for the show in a different ways.

Finally, we couldn’t let you go without asking. What is your favorite HAMILTON character, song or quote?

David: One of my favorite characters is the King of England, he he cracks me up. I know it’s a weird choice, but the way they portray him is incredibly clever and funny. His “awesome, wow” line is my favorite.

Mike: Aaron Burr's line "I am inimitable, I am an original," most exemplifies the work my team and I try to do every day with HAMILTON. Our challenge is to create content and products that live up to the level of what Lin has created.

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.