Posted:

Posted by Amir Shevat, Google Developers Launchpad Program Manager

With new events, improved courses and an expanded mentorship network - Startup Launch is now Google Developers Launchpad. We’re changing our program name to emphasize how you can use our resources as a launch pad to scale and monetize your app business. Read on to learn about our upcoming events and how you can apply to participate.

Events: Launchpad Week goes global

Launchpad Week, Launchpad’s weeklong in-person bootcamp for early-stage apps, continues to expand, with new 2015 programs planned in Munich, Mexico City, Helsinki, Bogota, and Sydney, to name a few. We’ll also regularly host these events in Tel Aviv, London, Berlin, and Paris.

We kicked off Launchpad Week in Bengaluru, India and Bordeaux, France last month. 32 startups and 80 experts from these communities gathered at Idiom Design Center and Le Node for a week of product, UX, and technology sprints designed to help transform ideas into validated, scalable businesses.

Featured startups from Bengaluru included iReff, an app that helps pre-paid mobile users find the best recharge plan for their specific needs. In Bordeaux, Google Developer Expert David Gageot volunteered as a tech mentor, helping startups “ship early, ship often” through testing and continuous integration.

Events: Google Developers Summits

For later-stage startups, we’re providing some of the best tech experts to help optimize apps for Material Design, Android TV, and Google Cast at two-day Google Developer Summits. At an event in Buenos Aires, Argentina, last week, we had participants such as game developer Etermax, the team behind Trivia Crack. Similar events happened in Kuala Lumpur, Bangkok, and Bengaluru this month, and we’re looking forward to inviting more startups to this program in London, Tokyo, Tel Aviv, and New York in 2015.

Products: Your app, powered by Google

In 2014, we helped over 5,000 developers in 170 countries get their ideas off the ground by providing the infrastructure back-end that allows developers to build incredible products. For example, our program delivered software architecture reviews and Google Cloud Platform credits to help entrepreneurs in the program build businesses that scale with them. Check out how Fansino is using Google Cloud Platform to let artists interact with their fans.

We’ve also expanded our product offer for early-stage startups to include AdWords promotional offers for new accounts. Whatever your monetization plan, we’re making it easy to get started with tools like the new In-app Billing API and instruction from the AdMob team.

Courses: Upskilling you and your app

Starting this month, we’ll offer a virtual curriculum of how Google products can help your startup. We’re kicking things off with new Launchpad Online videos covering Google Analytics - are you observing how your users use your app? How do different promotional channels perform?

The series continues in April 2015 with AdMob products, and will expand with instruction in implementing material design and conducting user research later in the year.

If you can’t wait, we’ve also built courses together with Udacity to take your technical skills to the next level on topics, including Android, Java, Web Fundamentals, and UX.

Apply to get involved

Apply to Google Developers Launchpad program to take advantage of these offers - g.co/launchpad. Here’s to a great launch!

Posted:

Posted by William Denniss, Product Manager, Identity and Authentication

Over the past few years, we’ve publicized that ClientLogin, OAuth 1.0 (3LO)1, AuthSub, and OpenID 2.0 were deprecated and would shut down on April 20, 2015. We’re moving away from these older protocols in order to focus support on the latest Internet standards, OAuth 2.0 and OpenID Connect, which increase security and reduce complexity for developers.

The easiest way to migrate to these new standards is to use the Google Sign-in SDKs (see the migration documentation). Google Sign-in is built on top of our OAuth 2.0 and OpenID Connect infrastructure and provides a single interface for authentication and authorization flows on Web, Android and iOS.

If the migration for applications using these deprecated protocols is not completed before the deadline, the application will experience an outage in its ability to connect with Google (possibly including the ability to sign in) until the migration to a supported protocol occurs. To avoid any interruptions in service, it is critical that you work to migrate prior to the shutdown date.

If you need to migrate your integration with Google:

If you have any technical questions about migrating your application, please post questions to Stack Overflow under the tag google-oauth or google-openid.

1 3LO stands for 3-legged OAuth: There's an end-user that provides consent. In contrast, 2-legged (2LO) correspond to Enterprise authorization scenarios: organizational-wide policies control access. Both OAuth1 3LO and 2LO flows are deprecated.

Posted:
Since we introduced add-ons for Google Docs, Sheets, and Forms last year, our developer partners have brought a world of new features to millions of users. Still, administrators for Google Apps domains (and developers!) kept asking for two things:


So, if you’ve built (or are thinking of building) a Google Docs, Sheets or Forms add-on, then be sure to make your add-on available in Google Apps Marketplace today.

Posted by Saurabh Gupta, product manager, Google Apps Script

Posted:

Posted by Carol Smith, Google Open Source team

Originally posted to the Google Open Source blog

If you’re a university student looking to earn real-world experience this summer, consider writing code for a cool open source project with the Google Summer of Code program.

Students who are accepted into the program will put the skills they have learned in university to good use by working on an actual software project over the summer. Students receive a stipend and are paired with mentors to help address technical questions and concerns throughout the course of the project. With the knowledge and hands-on experience students gain during the summer, they strengthen their future employment opportunities. Best of all, more source code is created and released for the use and benefit of all.

Interested students can submit proposals on the website starting now through Friday, March 27 at 19:00 UTC. Get started by reviewing the ideas pages of the 137 open source projects in this year’s program and decide which projects you’re interested in. Because Google Summer of Code has a limited number of spots for students, writing a great project proposal is essential to being selected to the program — be sure to check out the Student Manual for advice.

For ongoing information throughout the application period and beyond, see the Google Open Source Blog, join our Summer of Code mailing lists or join us on Internet relay chat at #gsoc on Freenode.

Good luck to all the open source coders out there, and remember to submit your proposals early — you only have until March 27 to apply!

Posted:

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:

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.

Posted:

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:

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:

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:

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.