Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Google Code Blog
Syndicate content
News and insights on Google platforms, tools and eventsewoodhttp://www.blogger.com/profile/12341551220176883769noreply@blogger.comBlogger1423125
Updated: 6 hours 36 min ago

Introducing gRPC, a new open source HTTP/2 RPC Framework

Thu, 02/26/2015 - 19:30

Today, we are open sourcing gRPC, a brand new framework for handling remote procedure calls. It’s BSD licensed, based on the recently finalized HTTP/2 standard, and enables easy creation of highly performant, scalable APIs and microservices in many popular programming languages and platforms. Internally at Google, we are starting to use gRPC to expose most of our public services through gRPC endpoints as part of our long term commitment to HTTP/2.

Over the years, Google has developed underlying systems and technologies to support the largest ecosystem of micro-services in the world; our servers make tens of billions of calls per second within our global datacenters. At this scale, nanoseconds matter. Efficiency, scalability and reliability are at the core of building Google’s APIs.

gRPC is based on many years of experience in building distributed systems. With the new framework, we want to bring to the developer community a modern, bandwidth and CPU efficient, low latency way to create massively distributed systems that span data centers, as well as power mobile apps, real-time communications, IoT devices and APIs.

Building on HTTP/2 standards brings many capabilities such as bidirectional streaming, flow control, header compression, multiplexing requests over a single TCP connection and more. These features save battery life and data usage on mobile while speeding up services and web applications running in the cloud.

Developers can write more responsive real-time applications, which scale more easily and make the web more efficient. Read more about the features and benefits in the FAQ.

Alongside gRPC, we are releasing a new version of Protocol Buffers, a high performance, open source binary serialization protocol that allows easy definition of services and automatic generation of client libraries. Proto 3 adds new features, is easier to use compared to previous versions, adds support for more languages and provides canonical mapping of Proto to JSON.

The project has support for C, C++, Java, Go, Node.js, Python, and Ruby. Libraries for Objective-C, PHP and C# are in development. To start contributing, please fork the Github repositories and start submitting pull requests. Also, be sure to check out the documentation, join us on the mailing list, visit the IRC #grpc channel on Freenode and tag StackOverflow questions with the “grpc” tag.

Google has been working closely with Square and other organizations on the gRPC project. We’re all excited for the potential of this technology to improve the web and look forward to further developing the project in the open with the help, direction and contributions of the community.


Post by Mugur Marculescu, Product Manager

Categories: Programming

1,000 Chrome Experiments and counting...

Tue, 02/24/2015 - 19:49

Posted by Valdean Klump, Data Arts Team

Originally posted to the Google Chrome blog

In 2009, we launched Chrome Experiments to showcase the work of creative coders who pushed HTML5 and JavaScript to the limits in order to build beautiful, unique web experiences. At first, the site had only 19 experiments, but we hoped they would be a source of inspiration for programmers who made art with open web technologies. Since then, we’ve been humbled by the quantity and quality of new submissions. Today, we’ve reached a major milestone: 1,000 experiments.

To celebrate, we’ve created a special Experiment #1000 that visualizes every other experiment on the site. You can explore all 1,000 in a variety of ways, including a real-time code editor and a timeline with selectable tags. Click on the WebGL tag, for example, and you’ll see how that technology surged in popularity when it was added to Chrome in 2011.

A visualization of the first 1,000 Chrome Experiments

Along with Experiment #1000, we’ve redesigned ChromeExperiments.com using Polymer. It’s mobile-friendly, so no matter what kind of phone or tablet you have, or how you hold it, the site scales smoothly. If you’re on your phone, you can also filter the list to mobile-compatible experiments by selecting the Mobile tag.

The new ChromeExperiments.com

Looking back at the old experiments this month has been a joy. Highlights include Mr.doob’s classic Ball Pool (one of the original 19 experiments), the first WebGL experiment by Gregg Tavares (try 4,000 fish – this used to be very slow!), and Dinahmoe’s multiplayer audio toy Plink, which combines the Web Audio API with Node.js. At Google I/O in 2012, we released the first mobile experiments, including AlteredQualia’s Multitouch Toy and Dominic Szablewski’s X-Type. And each year afterward, new web technologies appeared, like getUserMedia and the Web Speech API. It’s been a wonderful journey.

Thank you to everyone who has supported the site, and most of all to the creators who have shared their work. We’re excited see what experiments you come up with next.

Categories: Programming

Retiring the Email Migration API

Thu, 02/19/2015 - 01:15

Posted by Wesley Chun, Developer Advocate, Google Apps

Last summer, we launched the new Gmail API, giving developers more flexible, powerful, and higher-level access to programmatic email management, not to mention improved performance. Since then, it has been expanded to replace the Google Apps Admin SDK's Email Migration API (EMAPI v2). Going forward, we recommend developers integrate with the Gmail API.

EMAPI v2 will be turned down on November 1, 2015, so you should switch to the Gmail API soon. To aid you with this effort, we've put together a developer’s guide to help you migrate from EMAPI v2 to the Gmail API. Before you do that, here’s your final reminder to not forget about these deprecations including EMAPI v1, which are coming even sooner (April 20, 2015).

Categories: Programming

Smaller Fonts with WOFF 2.0 and unicode-range

Wed, 02/18/2015 - 23:31

Posted by Rod Sheeter, Software Engineer

The Google Fonts and Chrome teams are constantly looking for ways to make fonts better for online content. In 2014, we deployed two big optimizations: WOFF 2.0 and unicode-range. Combined, they are reducing the size of the downloaded fonts by more than 40 percent on average. For users, that means faster download times and lower data costs!

The HTTP Archive has a graph of observed font sizes across the web, primarily in WOFF format. If we compare this to our best estimate of the savings attributable to WOFF 2.0 and unicode-range optimizations that went live in 2014, it looks like this:

WOFF 2.0 is a new font format using a new compression algorithm, Brotli, created by the Google Compression team. WOFF 2.0 responses use ~25 percent less bytes than WOFF with Zopfli.

unicode-range allows the browser to automatically select what subset(s) of the font it needs based on the particular font glyphs used on the page. In practice, we’ve observed approximately 50 percent reduction in response size on some large sites with this optimization. On average, we see unicode-range responses use ~20 percent less bytes than they would without.

So, how do you take advantage of these optimizations? The great news is, if you are using Google Fonts on your site, than you are already taking advantage of these optimizations! We’ve already done all the work to enable both WOFF 2.0 and unicode-range support for browsers that support it (see caniuse.com/woff2, caniuse.com/unicode-range) on your behalf. It’s that easy.

If you are using a different provider, or hosting the fonts yourself, then you will have to do a little bit of work to enable these optimizations:

To use WOFF 2.0, convert your fonts using a supporting editor or via the command line tools and either serve WOFF 2.0 only to supporting browsers (what we do at Google Fonts), or use a bulletproof font-face declaration similar to the following (courtesy of Font Squirrel, with svg removed):

/* Generated by Font Squirrel (http://www.fontsquirrel.com) on February 2, 2015 */
@font-face {
font-family: 'lobster';
src: url('lobster-webfont.eot');
src: url('lobster-webfont.eot?#iefix') format('embedded-opentype'),
url('lobster-webfont.woff2') format('woff2'),
url('lobster-webfont.woff') format('woff'),
url('lobster-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}

To use unicode-range, the story is a bit more complicated. Due to inconsistent behavior of some older browsers, which will download all subsets regardless of whether they are required, you should serve unicode-range property only to browsers that support it fully. With that in place, cut your font into pieces as you see fit (Google Fonts uses fontTools for this), and serve multiple @font-face rules, one for each segment. You can see an example of this by looking at the CSS generated by Google Fonts for a browser which supports these features (e.g. access http://fonts.googleapis.com/css?family=Lobster with Chrome).

For more tips on optimizing your fonts, see Ilya Grigorik’s Optimizing Web Font Rendering Performance. If you try any of this let us know how it works out @googlefonts!

Categories: Programming

Reminder: ClientLogin Shutdown scheduled for April 20, 2015

Tue, 02/17/2015 - 21:17

Posted by Ryan Troll, Technical Lead, Identity and Authentication

As mentioned in our earlier post reminding users to migrate to newer Google Data APIs, we would like to once again share that the ClientLogin shutdown date is fast approaching, and applications which rely on it will stop working when it shuts down. We encourage you to minimize user disruption by switching to OAuth 2.0.

Our top priority is to safeguard users’ data, and at Google we use risk based analysis to block the vast majority of account hijacking attempts. Our risk analysis systems take into account many signals in addition to passwords to ensure that user data is protected. Password-only authentication has several well known shortcomings and we are actively working to move away from it. Moving to OAuth 2.0 ensures that advances we make in secure authentication are passed on to users signing in to Google services from your applications.

In our efforts to eliminate password-only authentication, we took the first step by announcing a deprecation date of April 20, 2015 for ClientLogin three years ago. At the same time, we recommended OAuth 2.0 as the standard authentication mechanism for our APIs. Applications using OAuth 2.0 never ask users for passwords, and users have tighter control over which data client applications can access. You can use OAuth 2.0 to build clients and websites that securely access account data and work with our advanced security features like 2-step verification.

We’ve taken steps to provide alternatives to password authentication in other protocols as well. CalDAV API V2 only supports OAuth 2.0, and we’ve added OAuth 2.0 support to IMAP, SMTP, and XMPP. While a deprecation timeline for password authentication in these protocols hasn’t been announced yet, developers are strongly encouraged to move to OAuth 2.0.

Categories: Programming

Google launches the Chinese language Developer Channel on YouTube

Tue, 02/17/2015 - 01:30

Posted by Bill Luan, Greater China Regional Lead, Google Developer Relations

Today, the Google Developer Platform team is launching a Chinese language and captioned YouTube channel, aiming to make it easier for the developers in China to learn more about Google services and technologies around mobile, web and the cloud. The channel includes original content in Chinese (Mandarin speaking), and curates content from the English version of the Google Developers channel with Simplified Chinese captions.

A special thank you to the volunteers in Google Developers Group community in the city of Nanyang (Nanyang GDG) in China, for their effort and contribution in adding the Chinese language translations to the English language Google Developer Channel videos on YouTube. Over time, we will produce more Chinese language original content, as well as continue leveraging GDG volunteers in China to add more Chinese captioned English videos from Google Developer Channel, to serve the learning needs from developers.

Categories: Programming

Control protected ranges and sheets in Google Sheets with Apps Script

Wed, 02/11/2015 - 21:00
A few weeks ago, the Google Sheets team introduced improved control over protected sheets and ranges. Developers have told us they're 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 let's see the new stuff in action. Let's 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 user's 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 user's 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
Categories: Programming

Debut your app during SxSW with Google Cloud Platform Build-Off

Tue, 02/10/2015 - 19:31

Posted by Greg Wilson, Head of Developer Advocacy for Google Cloud Platform

Originally posted to the Google Cloud Platform blog

From popular mobile apps (Foursquare) to acclaimed indie films (The Grand Budapest Hotel), some of the world’s most creative ideas have debuted at the annual SxSW Festival in Austin, Texas. For over 25 years, SxSW's goal has been to bring together the most creative people and companies to meet and share ideas. We think one of those next great ideas could be yours, and we’d like to help it be a part of SxSW.

Do you have an idea for a new app that you think is SxSW worthy? Enter it in the Google Cloud Platform Build-Off. Winners will receive up to $5,000 in cash. First prize also includes $100,000 in Google Cloud Platform credit and 24/7 support, and select winners will have the chance to present their app to 200 tech enthusiasts during the Build-Off awards ceremony at SxSW.

Here’s how it works:

  • Develop an app on Google Cloud Platform that pushes the boundary on what technology can do for music, film or gaming
  • Enter on your own or form teams of up to 3 members
  • Submit your application between 5 - 28 February 2015
  • Apps will be evaluated based on their originality, effectiveness in addressing a need, use of Google tools, and technical merit

Visit the official Build-Off website to see the full list of rules and FAQs and follow us at #GCPBuildOff on G+ and Twitter for more updates. We cannot wait to see what innovation your creativity leads to next.

Categories: Programming

Mentoring Organization Applications Now Being Accepted for Google Summer of Code 2015!

Mon, 02/09/2015 - 20:44

Posted by Carol Smith, Open Source Team

Originally posted to the Google Open Source Blog

GoogleSummer_2015logo_horizontal.jpg

Do you represent a free or open source software organization looking for new contributors? Do you love the challenge and reward of mentoring new developers in your community? Apply to be a mentoring organization in the Google Summer of Code program! The organization application period is now open.

Now in its 11th year, Google Summer of Code is a program designed to pair university students from around the world with mentors at open source projects in such varied fields as operating systems, language translations, content management systems, games, and scientific software. Since 2005, over 8,500 students from more than 100 countries have completed the Google Summer of Code program with the support of over 480 mentoring organizations. Students gain exposure to real-world software development while earning a stipend for their work and an opportunity to explore areas related to their academic pursuits during their school break. In return, mentoring organizations have the opportunity to identify and attract new developers to their projects as these students often continue their work with the organizations after Google Summer of Code concludes.

The deadline for applying to be a mentoring organization for Google Summer of Code is Friday, February 20 at 19:00 UTC (11am PST). The list of accepted organizations will be posted on the Google Summer of Code site on Monday, March 2nd. Students will then have two weeks to reach out to the accepted organizations to discuss their project ideas before we begin accepting student applications on March 16th.

Please visit our Frequently Asked Questions page for more details on the program. For more information you can check out the Mentor Manual, timeline and join the discussion group. You can also check out the Melange Manual for more information on using the website. Good luck to all of our mentoring organization applicants!

Categories: Programming

Reminder to migrate to updated Google Data APIs

Mon, 12/15/2014 - 18:00
Over the past few years, we’ve been updating our APIs with new versions across Drive and Calendar, as well as those used for managing Google Apps for Work domains. These new APIs offered developers several improvements over older versions of the API. With each of these introductions, we also announced the deprecation of a set of corresponding APIs.

The deprecation period for these APIs is coming to an end. As of April 20, 2015, we will discontinue these deprecated APIs. Calls to these APIs and any features in your application that depend on them will not work after April 20th.

Discontinued APIReplacement APIDocuments List APIDrive APIAdmin AuditAdmin SDK Reports APIGoogle Apps ProfilesAdmin SDK Directory APIProvisioningAdmin SDK Directory APIReportingAdmin SDK Reports APIEmail Migration API v1Email Migration API v2Reporting VisualizationNo replacement available
When updating, we also recommend that you use the opportunity to switch to OAuth2 for authorization. Older protocols, such as ClientLogin, AuthSub, and OpenID 2.0, have also been deprecated and are scheduled to shut down.

For help on migration, consult the documentation for the APIs or ask questions about the Drive API or Admin SDK on StackOverflow.

Posted by Steven Bazyl, Developer Advocate
Categories: Programming

Building a scalable geofencing API on Google’s App Engine

Thu, 12/11/2014 - 19:04
Thorsten Schaeff has been studying Computer Science and Media at the Media University in Stuttgart and the Institute of Art, Design and Technology in Dublin. For the past six months he’s been interning with the Maps for Work Team in London, researching best practice architectures for working with big geo data in the cloud.

Google’s Cloud Platform offers a great set of tools for creating easily scalable applications in the cloud. In this post, I’ll explore some of the special challenges of working with geospatial data in a cloud environment, and how Google’s Cloud can help. I’ve found that there aren’t many options to do this, especially when dealing with complicated operations like geofencing with multiple complex polygons. You can find the complete code for my approach on GitHub.

Geofencing is the procedure of identifying if a location lies within a certain fence, e.g. neighborhood boundaries, school attendance zones or even the outline of a shop in a mall. It’s particularly useful in mobile applications that need to apply this extra context to someone’s exact location. This process isn’t actually as straight forward as you’d hope and, depending on the complexity of your fences, can include some intense calculations and if your app gets a lot of use, you need to make sure this doesn’t impact performance.

In order to simplify this problem this blogpost outlines the process of creating a scalable but affordable geofencing API on Google’s App Engine.

And the best part? It’s completely free to start playing around.
geofencing_API_example.PNGGeofencing a route through NYC against 342 different polygons that resulted from converting the NYC neighbourhood tabulation areas into single-part polygons.Getting startedTo kick things off you can work through the Java Backend API Tutorial. This uses Apache Maven to manage and build the project.

If you want to dive right in you can download the finished geofencing API from my GitHub account.

The ArchitectureThe requirements are:

  • Storing complex fences (represented as polygons) and some metadata like a name and a description. For this I use Cloud Datastore, a scalable, fully managed, schemaless database for storing non-relational data. You can even use this to store and serve GeoJSON to your frontend.
  • Indexing these polygons for fast querying in a spatial index. I use an STR-Tree (part of JTS) which I store as a Java Object in memcache for fast access.
  • Serving results to multiple platforms through HTTP requests. To achieve this I use Google Cloud Endpoints, a set of tools and libraries that allow you to generate APIs and client libraries.

That’s all you need to get started - so let’s start cooking!

Creating the ProjectTo set up the project simply use Apache Maven and follow the instructions here. This creates the correct folder structure, sets up the routing in the web.xml file for use with Google’s API Explorer and creates a Java file with a sample endpoint.

Adding additional LibrariesI’m using the Java Topology Suite to find out which polygon a certain latitude-longitude-pair is in. JTS is an open source library that offers a nice set of geometric functions.

To include this library into your build path you simply add the JTS Maven dependency to the pom.xml file in your project’s root directory.

In addition I’m using the GSON library to handle JSON within the Java backend. You can basically use any JSON library you want to. If you want to use GSON import this dependency.

Writing your EndpointsAdding Fences to Cloud DatastoreFor the sake of convenience you’re only storing the fences’ vertices and some metadata. To send and receive data through the endpoints you need an object model which you need to create in a little Java Bean called MyFence.java.


Now you need to create an endpoint called add. This endpoint expects a string for the group name, a boolean indicating whether to rebuild the spatial index, and a JSON object representing the fence’s object model. From this App Engine creates a new fence and writes it to Cloud Datastore.

Retrieving a List of our FencesFor some use cases it makes sense to fetch all the fences at once in the beginning, therefore you want to have an endpoint to list all fences from a certain group.

Cloud Datastore uses internal indexes to speed up queries. If you deploy the API directly to App Engine you’re probably going to get an error message, saying that the Datastore query you’re using needs an index. The App Engine Development server can auto-generate the indexes, therefore I’d recommend testing all your endpoints on the development server before pushing it to App Engine.

Getting a Fence’s Metadata by its IDWhen querying the fences you only return the ids of the fences in the result, therefore you need an endpoint to retrieve the metadata that corresponds to a fence’s id.

Building the Spatial IndexTo speed up the geofencing queries you put the fences in an STR tree. The JTS library does most of the heavy lifting here, so you only need to fetch all your fences from the Datastore, create a polygon object for each one and add the polygon’s bounding box to the index.

You then build the index and write it to memcache for fast read access.

Testing a pointYou want to have an endpoint to test any latitude-longitude-pair against all your fences. This is the actual geofencing part. That’s so you will be able to know, if the point falls into any of your fences and if so, it should return the ids of the fences the point is in.

For this you first need to retrieve the index from memcache. Then query the index with the bounding box of the point which returns a list of polygons. Since the index only tests against the bounding boxes of the polygons, you need to iterate through the list and test if the point actually lies within the polygon.


Querying for a Polylines or PolygonsThe process of testing for a point can easily be adapted to test the fences against polylines and polygons. In the case of polylines you query the index with the polyline’s bounding box and then test if the polyline actually crosses the returned fences.


When testing for a polygon you want to get back all fences that are either completely or partly contained in the polygon. Therefore you test if the returned fences are within the polygon or are not disjoint. For some use cases you only want to return fences that are completely contained within the polygon. In that case you want to delete the not disjoint test in the if clause.

Testing & Deploying to App EngineTo test or deploy your API simply follow the steps in the ‘Using Apache Maven’ tutorial.

Scalability & PricingThe beauty of this is, since it’s running on App Engine, Google’s platform as a service offering, it scales automatically and you only pay for what you use.

If you want to insure best performance and great scalability you should consider to switch from the free and shared memcache to a dedicated memcache for your application. This guarantees enough capacity for your spatial index and therefore ensures enough space even for a large amount of complex fences.

That’s it - that’s all you need to create a fast and scalable geofencing API.
Preview: Processing Big Spatial Data in the Cloud with Dataflow
In my next post I will show you how I geofenced more than 340 million NYC Taxi locations in the cloud using Google’s new Big Data tool called Cloud Dataflow.
Categories: Programming

Google Cardboard: Seriously Fun

Wed, 12/10/2014 - 19:42
As simple as they are, cardboard boxes are pretty great. Maybe you transformed one into a fort or castle growing up. Or maybe your kids took last week’s package delivery and turned the box into a puppet theater. The best part about cardboard is that it can become anything—all you need is your imagination.

It’s this same spirit that inspired our team to turn a smartphone, and some cardboard, into a virtual reality (VR) viewer earlier this year. Suddenly, exploring the Palace of Versailles was as easy as opening an app. And the response was kind of delightful.

We’ve been working to improve Google Cardboard ever since. And today—with more than half a million Cardboard viewers in people’s hands—we've got a fresh round of updates for users, developers, and makers.
cardboard-500k.png
For users: more apps to enjoy, and more places to buy

There are now dozens of Cardboard-compatible apps on Google Play, and starting today we’re dedicating a new collection page to some of our favorites. These VR experiences range from test drives to live concerts to fully-immersive games, and they all have something amazing to offer. So give ‘em a try today, and download the new Cardboard app to watch the collection grow over time.
cardboard-apps-blog-mock-option2.pngExample apps for Cardboard (clockwise, from top left):
Paul McCartney concert, Volvo Reality test drive, Proton Pulse 3D game

If you don’t have a Cardboard viewer yet, you can now pick one up from DODOcase, I Am Cardboard, Knoxlabs, and Unofficial Cardboard. And of course you can always build your own (with new specs below!).

For developers: SDKs for Android and Unity

If you’ve ever tried creating a VR application, then you’ve probably wrestled with issues like lens distortion correction, head tracking, and side-by-side rendering. It’s important to get these things right, but they can suck up all your time—time you’d rather spend on gameplay or graphics.

We want to give you that time back, so today we’re introducing Cardboard SDKs for Android and Unity. The SDKs simplify common VR development tasks so you can focus on your awesome, immersive app. And with both Android and Unity support, you can use the tools you already know and love. Download the SDKs today, and check out apps like Caaaaardboard! and Tilt Brush Gallery to see what’s already possible.

For makers: tool-specific specs, and custom viewer calibration

To help bring VR experiences to everyone, we open sourced a Cardboard viewer specification earlier this year. Since then we’ve seen all sorts of viewers from all sorts of makers, and today we’re investing in this community even further.

For starters, we’re publishing new building specs with specific cutting tools in mind. So whether you’re laser- or die-cutting your Cardboard viewers in high quantities, or carving single units with a blade, we’ve got you covered.

Once you’ve got your custom viewer, we also want to help you tailor the viewing experience to its unique optical layout. So early next year we’ll be adding a viewer calibration tool to the Cardboard SDK. You’ll be able to define your viewer’s base and focal length, for example, then have every Cardboard app adjust accordingly.

For the future: watch this space, and we’re hiring

The growth of mobile, and the acceleration of open platforms like Android make it an especially exciting time for VR. There are more devices, and more enthusiastic developers than ever before, and we can’t wait to see what’s next! We’re also working on a few projects ourselves, so if you’re passionate about VR, you should know we’re hiring.

Here’s to the cardboard box, and all the awesome it brings.

by Andrew Nartker, Product Manager, Google Cardboard
Categories: Programming

Four Steps to Supercharge Deep Linking for Android Apps

Tue, 12/09/2014 - 19:12
ul {list-style-position: inside;} App deep links are the new kid on the block in Search results, and they’re picking up speed faster than you can say “Schema.org ViewAction”! For signed-in users, 15% of Google searches on Android now return deep links to apps through App Indexing. And over just the past quarter, we've seen the number of clicks on app deep links jump by 10x.

Based on feedback from developers since we launched publicly App Indexing back in June, we’d like to share with you four key steps to monitor app performance and drive user engagement:

1. Make sure you get access to Webmaster Tools
App indexing is a team effort between you (as an app developer) and your website management team. We recommend working with your webmaster to get access to Webmaster Tools to carefully track app-related issues. Here’s what’s available right now:
  • Errors in indexed pages within apps
  • Weekly clicks and impressions from app deep link via Google search
  • Stats on your sitemap (if that’s how you implemented the app deep links)
...and we plan to add a lot more in the coming months!

Any verified site owner can add a new user. Pick restricted or full permissions, depending on the level of access you’d like. Screen Shot 2014-11-13 at 22.30.47.png
2. Understand how your app is doing in search results
How are users engaging with your app from search results? We’ve introduced two new ways for you to track performance for your app deep links:
  • We now send a weekly clicks and impressions update to the Message center in your Webmaster Tools account.
  • You can now track how much traffic app deep links drive to your app using referrer information - specifically, the referrer extra in the ACTION_VIEW intent. We're working to integrate this information with Google Analytics for even easier access. Learn how to track referrer information on our Developer site.

3. Make sure key app resources can be crawled
Blocked resources are one of the top reasons for the “content mismatch” errors you see in Webmaster Tools’ Crawl Error report. We need access to all the resources necessary to render your app page. This allows us to assess whether your associated web page has the same content as your app page.

To help you find and fix these issues, we’ll now show you the specific resources we can’t access that are critical for rendering your app page. If you see a content mismatch error for your app, look out for the list of blocked resources in “Step 5” of the details dialog: apps roboted content (1).png
4. Watch out for Android App errors
To help you identify errors when indexing your app, we’ll send you messages for all app errors we detect, and will also display most of them in the “Android apps” tab of the Crawl errors report.

In addition to the currently available “Content mismatch” and “Intent URI not supported” error alerts, we’re introducing three new error types:
  • APK not found: we can’t find the package corresponding to the app
  • No first-click free: the link to your app does not lead directly to the content, but requires login to access
  • Back button violation: after following the link to your app, the back button did not return to Search results.

In our experience, the majority of errors are usually caused by a general setting in your app (e.g. a blocked resource, or a region picker that pops up when the user tries to open the app from Search results). Taking care of that generally resolves it for all involved URIs.

Be sure to visit our codelab to learn how to get your Android app indexed by Google Search. As always, if you have questions, feel free to drop by Stack Overflow or the Webmaster help forum.

Posted by Mariya Moeva, Webmaster Trends Analyst
Categories: Programming

Get your Google Drive App listed on the Google Apps Marketplace

Mon, 12/08/2014 - 18:59
The Google Apps Marketplace brings together hundreds of third-party applications that integrate and enhance Google Drive, part of Google Apps for Work, our suite of collaboration and productivity tools for businesses. To improve discoverability and increase adoption, it’s important to make your Google Drive app integration available on the marketplace.

Today, we want to share with you four easy steps to get listed immediately and enable admins to install your application for all users in their domain. For more details, check out the Google Apps Marketplace documentation.

Step 1: Open your Drive project on Google Cloud console. Turn on “Google Apps Marketplace SDK” for your project. Screen Shot 2014-08-20 at 11.50.10 PM.png

Step 2: Click the gear icon to configure “Google Apps Marketplace SDK”. Refer to Google Apps Marketplace documentation for details. In the scopes section, be sure to request the same scopes as your Google Drive application, and check the “Enable Drive extension” checkbox.

Step 3: Go to the Chrome Web Store developer console and select your published Drive application.

Step 4: Update the following line in your Drive application’s Chrome Web Store manifest, upload and publish.

"container":"GOOGLE_DRIVE"
with
“container”: [”GOOGLE_DRIVE”, ”DOMAIN_INSTALLABLE”]

You’re done! You application is now available to all Google Apps for Work customers to install on a domain-wide basis through the Google Apps Marketplace. Refer to Publishing your app documentation for details. You can access Google Apps Marketplace inside Google Admin Console and verify your newly listed application.

Please subscribe to the Google Apps Marketplace G+ community for the latest updates.
Posted by Hiranmoy Saha, Software Engine, Google Apps Marketplace
Categories: Programming

Get your Google Drive App listed on the Google Apps Marketplace

Mon, 12/08/2014 - 18:59
The Google Apps Marketplace brings together hundreds of third-party applications that integrate and enhance Google Drive, part of Google Apps for Work, our suite of collaboration and productivity tools for businesses. To improve discoverability and increase adoption, it’s important to make your Google Drive app integration available on the marketplace.

Today, we want to share with you four easy steps to get listed immediately and enable admins to install your application for all users in their domain. For more details, check out the Google Apps Marketplace documentation.

Step 1: Open your Drive project on Google Cloud console. Turn on “Google Apps Marketplace SDK” for your project. Screen Shot 2014-08-20 at 11.50.10 PM.png

Step 2: Click the gear icon to configure “Google Apps Marketplace SDK”. Refer to Google Apps Marketplace documentation for details. In the scopes section, be sure to request the same scopes as your Google Drive application, and check the “Enable Drive extension” checkbox.

Step 3: Go to the Chrome Web Store developer console and select your published Drive application.

Step 4: Update the following line in your Drive application’s Chrome Web Store manifest, upload and publish.

"container":"GOOGLE_DRIVE"
with
“container”: [”GOOGLE_DRIVE”, ”DOMAIN_INSTALLABLE”]

You’re done! You application is now available to all Google Apps for Work customers to install on a domain-wide basis through the Google Apps Marketplace. Refer to Publishing your app documentation for details. You can access Google Apps Marketplace inside Google Admin Console and verify your newly listed application.

Please subscribe to the Google Apps Marketplace G+ community for the latest updates.
Posted by Hiranmoy Saha, Software Engine, Google Apps Marketplace
Categories: Programming

Quota for Calendar API v3 now 10 times higher

Wed, 12/03/2014 - 19:52

Posted by Lucia Fedorova, Tech Lead, Google Calendar API

At Google we like to make 10x rather than 10% improvements. In this spirit, we are increasing the default quota for the Calendar API v3 by a factor of ten, to 1 million requests per day. That means your application can support ten times as many users without any need to apply for more quota.

And if you need even more free quota, you can apply for it in the developer console under APIs -> Calendar API -> Quota -> “Apply for higher quota.” We have also streamlined the process of quota handling to make sure you receive your quota as quickly as possible.

A few tips to work efficiently with your quota:

  • Use push notifications instead of polling.
  • If you cannot avoid polling, make sure you only poll when necessary (for example poll very seldomly at night).
  • Use incremental synchronization with sync tokens for all collections instead of repeatedly retrieving all the entries.
  • Increase page size to retrieve more data at once by using the maxResults parameter.
  • Update events when they change, avoid re-creating all the events on every sync.
  • Use exponential backoff for error retries.
Categories: Programming

Bandwidth challenged? Amazing Google Developer content is now available offline

Tue, 12/02/2014 - 19:56
We currently provide a robust array of content and resources online, including documentation, SDKs, and videos, that empower developers to create awesome apps and services on a variety of Google platforms. However, due to the challenge of limited Internet access in many parts of the world, many developers are not able to easily search through our vast library of content.

Today, we’re going to make a select number of resources available for download through a kit, while offline, as part of a pilot to solve the broadband challenge. As an example, you will no longer have to worry about needing to download and install the SDK over a slow or non-existent internet connection when running a code lab, or spending 30 minutes to watch a 10 minute video tutorial on the latest API due to constant buffering.

So far, we distributed more than 2,000 kits through Google Developer Groups in Sub-Saharan Africa, India and Bangladesh. Developers now have offline access to many Google SDKs, developer videos, and documentation when they need them.
devkitcds
The current pilot kit contains:
Check out this document to find out more about the offline developer kit and the many ways you can put it to use, If you are interested in piloting one of these developer kits, please get in touch with a Google Developer Group near you or follow these instructions if you are an organisation like a school, tech hub or incubator.

Posted by Chukwuemeka Afigbo, Program Manager, Developer Ecosystems
Categories: Programming

3, 2, 1 Code-in: Inviting teens to contribute to open source

Mon, 12/01/2014 - 21:00

Code-in 2014 logo

We believe that the key to getting students excited about computer science is to give them opportunities at ever younger ages to explore their creativity with computer science. That’s why we’re running the Google Code-in contest again this year, and today’s the day students can go to the contest site, register and start looking for tasks that interest them.

Ignacio Rodriguez was just 10 years old when he became curious about Sugar, the open source learning platform introduced nationally to students in Uruguay when he was in elementary school. With the encouragement of his teacher, Ignacio started asking questions of the developers writing and maintaining the code and he started playing around with things, a great way to learn to code. When he turned 14 he entered the Google Code-in contest completing tasks that included writing two new web services for Sugar and he created four new Sugar activities. He even continued to mentor other students throughout the contest period.  His enthusiasm for coding and making the software even better for future users earned him a spot as a 2013 Grand Prize Winner.

Ignacio is one of the 1,575 students from 78 countries that have participated in Google Code-in since 2010. We are encouraging 13-17 year old students to explore the many varied ways they can contribute to open source software development through the Google Code-in contest. Because open source is a collaborative effort, the contest is designed as a streamlined entry point for students into software development by having mentors assigned to each task that a student works on during the contest. Students don’t have to be coders to participate; as with any software project, there are many ways to contribute to the project.  Students will be able to choose from documentation, outreach, research, training, user interface and quality assurance tasks in addition to coding tasks.

This year, students can choose tasks created by 12 open source organizations working ondisaster relief, content management, desktop environments, gaming, medical record systems for developing countries, 3D solid modeling computer-aided design and operating systems to name a few.  

For more information on the contest, please visit the contest site where you can find the timeline, Frequently Asked Questions and information on each of the open source projects students can work with during the seven week contest.

Good luck students!
By Stephanie Taylor, Open Source Programs
Categories: Programming

Google Analytics Demos & Tools

Thu, 11/20/2014 - 18:05
As a member of the Google Analytics Developer Relations team, I often hear from our community that they want to do more with GA but don't always know how. They know the basics but want to see full examples and demos that show how things should be built.

Well, we've been listening, and today I'm proud to announce the launch of Google Analytics Demos & Tools, a new website geared toward helping Google Analytics developers tackle the challenges they face most often.

The site aims to make experienced developers more productive (we use it internally all the time) and to show new users what's possible and inspire them to leverage the platform to improve their business through advanced measurement and analysis.

Google Analytics Developers Image
Some highlights of the site include a full-featured Enhanced Ecommerce demo with code samples for both Google Analytics and Google Tag Manager, a new Account Explorer tool to help you quickly find the IDs you need for various Google Analytics services and 3rd party integrations, several examples of easy-to-build custom dashboards, and some old favorites like the Query Explorer.

Google Analytics Demos & Tools not only shows off Google Analytics technologies, it also uses them under the hood. All pages that require authorization use the Embed API to log users in, and usage statistics, including outbound link clicks, authorization status, client-side exceptions, and numerous other user interaction events are measured using analytics.js.

Every page that makes use of a Google Analytics technology lists that information in the footer, making it easy for developers to see how all the pieces fit together. In addition, the entire site is open sourced and available on Github, so you can dive in and see exactly how everything works.

Feedback is welcome and appreciated!

Posted By Philip Walton, Developer Programs Engineer
Categories: Programming

Launchpad Online for developers: Getting Started with Google APIs

Wed, 11/19/2014 - 19:00
Google APIs give you the power to build rich integrations with our most popular applications, including Google Maps, YouTube, Gmail, Google Drive and more. If you are new to our developer features, we want to give you a quick jumpstart on how to use them effectively and build amazing things.

As you saw last week, we’re excited to partner with the Startup Launch team to create the “Launchpad Online”, a new video series for a global audience that joins their cadre which already includes the established “Root Access” and “How I:” series, as well as a “Global Spotlight” series on some of the startups that have benefitted from the Startup Launch program. This new series focuses on developers who are beginners to one or more Google APIs. Each episode helps get new users off the ground with the basics, shows experienced developers more advanced techniques, or introduces new API features, all in as few lines of code as possible.

The series assumes you have some experience developing software and are comfortable using languages like Javascript and Python. Be inspired by a short working example that you can drop into your own app and customize as desired, letting you “take off” with that great idea. Hopefully you had a chance to view our intro video last week and are ready for more!

Once you’ve got your developers ready to get started, learn how to use the Google Developers Console to set up a project (see video to the right), and walk through common security code required for your app to access Google APIs. When you’ve got this “foundation” under your belt, you’ll be ready to build your first app… listing your files on Google Drive. You’ll learn something new and see some code that makes it happen in each future episode… we look forward to having you join us soon on Launchpad Online!

Posted by Wesley Chun, Developer Advocate, Google

+Wesley Chun (@wescpy) is an engineer, author of the bestselling Core Python books, and a Developer Advocate at Google, specializing in Google Drive, Google Apps Script, Gmail, Google Apps, cloud computing, developer training, and academia. He loves traveling worldwide to meet Google users everywhere, whether at a developers conference, user group meeting, or on a university campus!
Categories: Programming