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
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.
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.
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.
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).
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!
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.
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.
Protection
PageProtection
// 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); }
// 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(); } }
// 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); }
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:
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.
Posted by Carol Smith, Open Source Team
Originally posted to the Google Open Source Blog
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!
