Posted:
author photo
Brendan
author photo
Antonio
By Brendan O’Brien and Antonio Fuentes, Google Developer Team

Today we reached another milestone in our efforts to provide infrastructure and tools to make it easier for developers to use Google APIs: we have released the Google APIs Client Library for JavaScript in Alpha. This client library is the latest addition to our suite of client libraries, which already includes Python, PHP, and Java.

This compact and efficient client library provides access to all the Google APIs that are listed in the APIs Explorer. The client library is also flexible, supporting multiple browser environments including Chrome 8+, Firefox 3.5+, Internet Explorer 8+, Safari 4+, and Opera 11+. In addition, the JavaScript client library supports OAuth 2.0 authorization methods.

You can load the client library using the following script tag:

<script src="https://apis.google.com/js/client.js?onload=CALLBACK"></script>

Loading an API and making a request is as easy as executing:

gapi.client.load('API_NAME', 'API_VERSION', CALLBACK);

// Returns a request object which can then be executed.
// METHOD_NAME is only available once CALLBACK runs.

var request = gapi.client.METHOD_NAME(PARAMETERS_OBJECT);
request
.execute(callback);

You can use the APIs Explorer to check all the methods available for an API, as well as the parameters for each method. For instance, use the above syntax with the plus.activities.search method of the Google+ API to query activities:


<!DOCTYPE html>
<html>
 <head>
 </head>

 <body>
   <script type="text/javascript">

function init() {

 // Load your API key from the Developer Console
 gapi.client.setApiKey('YOUR_API_KEY');

 // Load the API
 gapi.client.load('plus', 'v1', function() {
     var request = gapi.client.plus.activities.search({
         'query': 'Google+',
           'orderby': 'best'
           });

     request.execute(function(resp) {
         // Output title
         var heading = document.createElement('h4');
         heading.appendChild(document.createTextNode(
resp.title));
         var content = document.getElementById('content');
         content.appendChild(heading);

         // Output content of the response
         if (!resp.items) {
           content.appendChild(document.createTextNode(
'No results found.'));
         } else {
           for (var i = 0; i < resp.items.length; i++) {
             var entry = document.createElement('p');
           entry.appendChild(document.createTextNode(
resp.items[i].title));
             content.appendChild(entry);
           }
         }
       });
   });
}
   </script>
   <script src="https://apis.google.com/js/client.js?onload=init"></script>

   <div id="content"></div>
 </body>
</html>

To try this yourself, sign up in the Google APIs console or refer to the documentation on acquiring and using a developer key in the Google+ API.

The Google APIs Client Library for JavaScript is currently in Alpha, which means that we are actively developing it, but wanted to get the library in your hands as soon as possible, and we welcome any feedback to make the code better. While you can use the current library to start writing code, you should use caution when writing production code as library code changes may break your application. We are working hard to upgrade this release to Beta and beyond soon, and to release even more client libraries.

To get started, visit the JavaScript Client Library documentation page. We also welcome your feedback, which you can provide using the JavaScript client group.


Brendan O'Brien is a Software Engineer for the Browser Client group at Google. Prior to working on JavaScript APIs he was a frontend engineer for iGoogle. He is passionate about JavaScript and enjoys building web applications.

Antonio Fuentes is a Product Manager for the Google API Infrastructure group. He has experience launching products in the cloud computing, infrastructure, and virtualization space.

Posted by Scott Knaster, Editor

Posted:
Author Photo
By Dan Holevoet, Developer Relations Team

A platform is more than the sum of its component parts. You can read about it or hear about it, but to really learn what makes up a platform you have to try it out for yourself, play with the parts, and discover what you can build.

With that in mind, we started a project called Au-to-do: a full sample application implementing a ticket tracker, built using Google APIs, that developers can download and dissect.

Au-to-do screen shot

Au-to-do currently uses the following APIs and technologies:
Additional integrations with Google APIs are on their way. We are also planning a series of follow-up blog posts discussing each of the integrations in depth, with details on our design decisions and best practices you can use in your own projects.

By the way, if you’re wondering how to pronounce Au-to-do, you can say "auto-do" or "ought-to-do" — either is correct.

Ready to take a look at the code? Check out the getting started guide. Found a bug? Have a great idea for a feature or API integration? Let us know by filing a request.

Happy hacking!


Dan Holevoet joined the Google Developer Relations team in 2007. When not playing Starcraft, he works on Google Apps, with a focus on the Calendar and Contacts APIs. He's previously worked on iGoogle, OpenSocial, Gmail contextual gadgets, and the Google Apps Marketplace.

Posted by Scott Knaster, Editor



Posted:
Author Photo
By Navneet Joneja, Product Manager

Google Cloud Storage is a robust, high-performance service that enables developers and businesses to use Google’s infrastructure to power their data. Today, we’re announcing a new feature that makes it even easier to control and share your data.

Per-Bucket Default Object ACLs

Customers building a wide variety of applications have asked us for an easier mechanism to control the permissions granted on newly created objects. Now you can define your access control policy for a bucket once by specifying a Default Object ACL for any bucket, and we’ll automatically apply that ACL to any object without an explicitly defined ACL. You can always override the default by providing a canned ACL when you upload the object or by updating the object’s ACL afterwards. This mechanism simplifies wide variety of use cases, including data sharing, controlled-access data sets and corporate drop-boxes.

New buckets without Default ACLs

After analyzing how customers use our service, we’ve also decided to make a few small changes to the behavior of buckets that have no explicit default object ACL. Effective today, new buckets are created with an implied project-private default object ACL. In other words, project editors and owners will have FULL_CONTROL access to new objects, and project viewers will have READ access to them. This change better aligns the default behavior with how our customers use storage. You can change a bucket’s default object ACL at any time after creating the bucket.

Existing buckets have an effective default object ACL of "private", and they will continue to work as they always have until and unless you specify a new default object ACL for them.


Navneet Joneja loves being at the forefront of the next generation of simple and reliable software infrastructure, the foundation on which next-generation technology is being built. When not working, he can usually be found dreaming up new ways to entertain his intensely curious one-year-old.

Posted by Scott Knaster, Editor

Posted:
Author Photo
By Monica Tran, Google I/O Team

After Google I/O 2011, you consistently told us you wanted more time to attend sessions, visit our partners in the Developer Sandbox, and meet 1:1 with the engineers behind Google’s developer platforms and APIs. We recently received an unexpected opportunity to extend Google I/O to three days, so as we announced on our +Google Developers page, we are moving the conference to June 27-29, 2012. It will still take place at Moscone Center West in San Francisco.

Google I/O 2012
June 27-29, 2012
Moscone Center West, San Francisco


In the meantime, be sure to brush up on your coding skills. They’ll come in handy when the new application process opens in February. That’s all we can tell you for now, but we’d advise against making travel arrangements until then. Continue following us at our Google Developers page on Google+ to be the first to get #io12 updates!


This post supersedes our previous Save the Date announcement. Please update your calendars: Google I/O will be coming to Moscone Center in San Francisco on June 27-29. We will be responding to FAQs via our thread on Google+.


You might remember Monica Tran from I/O Live or one of our eight Google Developer Days around the world. This year, she’s back to lead the charge on Google I/O 2012.

Posted by Scott Knaster, Editor

Posted:
Author Photo
By Scott Knaster, Google Code Blog Editor

Earlier this week, our Google Maps API got a great new feature. When you build an application with the Maps API, you can now enable users to draw on the maps. There are tools for various shapes, so your users can draw circles or boxes to highlight locations, just like they would with physical maps. And to be even more like physical maps, users can use the tools to approximate drawing a coffee cup stain or a big crinkle.



Speaking of physical things, here’s one that exists in the real world, but barely makes a dent. Researchers in California have created what they say is the world’s lightest material. The material has a density of 0.9 mg/cc and is light enough to sit atop the fluff on a dandelion, although that usage seems impractical.

Finally, for weekend fun, take a look at this peer-reviewed paper entitled "A Vicious Cycle: A Cross-Sectional Study of Canine Tail-Chasing and Human Responses to It, Using a Free Video-Sharing Website". It will make you want to spend more time on YouTube, in the name of science.


Fridaygram is our weekly nerdy attempt at fun for developers. Fridaygrams have Google things, science stuff, and sometimes, Easter eggs.


Posted:
Urvang
Vikas
Jyrki

By Jyrki Alakuijala, Vikas Arora, and Urvang Joshi, Software Engineers, WebP Team

Cross-posted with the Chromium Blog

In September 2010 we announced the WebP image format with lossy compression. WebP was proposed as an alternative to JPEG, with 25–34% better compression compared to JPEG images at equivalent SSIM index. We received lots of feedback, and have been busy improving the format. Last month we announced WebP support for animation, ICC profile, XMP metadata and tiling. Today, we introduce a new mode in WebP to compress images losslessly, and support for transparency – also known as alpha channel – in both the lossless and lossy modes.

With these new modes, you can now use WebP to better compress all types of images on the web. Photographic images typically encoded as JPEG can be encoded in WebP lossy mode to achieve smaller file size. Icons and graphics can be encoded better in WebP lossless mode than in PNG. WebP lossy with alpha can be used to create transparent images that have minimal visual degradation, yet are much smaller in file size. Animations compressed as GIFs can use animation support in WebP.

New lossless mode

Our main focus for lossless mode has been in compression density and simplicity in decoding. On average, we get a 45% reduction in size when starting with PNGs found on the web, and a 28% reduction in size compared to PNGs that are re-compressed with pngcrush and pngout. Smaller images on the page mean faster page loads.

New transparency mode

Today, webmasters who need transparency must encode images losslessly in PNG, leading to a significant size bloat. WebP alpha encodes images with low bits-per-pixel and provides an effective way to reduce the size of such images. Lossless compression of the alpha channel adds just 22% bytes over lossy (quality 90) WebP encoding. Smaller alpha overhead means richer images on webpages.

You can find a more detailed compression study for these modes here and sample images in the WebP-Gallery. The bit stream specification has not been finalized, and the encoding and decoding implementations have not yet been optimized for processing speed. We encourage you to try it out on your favorite set of images, check out the code, and provide feedback. We hope WebP will now handle all your needs for web images, and we're working to get WebP supported in more browsers.


Dr. Jyrki Alakuijala is a Software Engineer with a special interest in data compression. He is a father of five daughters, and sings in the Finnish Choir in Zürich. Before joining Google, Jyrki worked in neurosurgical and radiotherapy development.

Vikas Arora is a Software Engineer with a special interest in signal processing and data compression. Before joining Google, Vikas worked in the VLSI domain developing digital and analog signal simulators.

Urvang Joshi is a Software Engineer, especially interested in image processing, machine learning, and computer vision. He is also a table tennis and chess enthusiast.

Posted by Scott Knaster, Editor

Posted:

By Michael Bolin, Open Source Engineer

Cross-posted from the Open Source at Google blog

(CSS is for programming, not for pasting.)

When the Closure Tools were first released a little over two years ago, they gave web developers the ability to organize and optimize their JavaScript and HTML in a new way. But there was something missing, namely, a tool to help manage CSS.

You see, the nature of CSS runs contrary to the DRY principle that is exhibited in good software engineering. For example, if there is a color that should be used for multiple classes in a stylesheet, a developer has no choice but to copy-and-paste it everywhere because CSS has no concept of variables. Similarly, if there is a value in a stylesheet that is derived from other values, there is no way to express that because CSS also lacks functions. Common patterns of style blocks are duplicated over and over because CSS has no macros. All of these properties of CSS conspire to make stylesheets extremely difficult to maintain.

To this end, we are excited to introduce the missing piece in the Closure Tools suite: Closure Stylesheets. Closure Stylesheets is an an extension to CSS that adds variables, functions, conditionals, and mixins to standard CSS. The tool also supports minification, linting, RTL flipping, and CSS class renaming. As the existing Closure Tools have done for JavaScript and HTML, Closure Stylesheets will help you write CSS in a maintainable way, while also empowering you to deliver optimized code to your users. We hope you enjoy it! Please let us know what you think in the discussion forum.


Michael Bolin is an Open Source Engineer at Google.

Posted by Scott Knaster, Editor

Posted:
Author Photo
By Esteban de la Canal, Software Engineer

We launched Google Swiffy in July. Swiffy enables you to convert Flash SWF files to HTML5. One of our main aims for Swiffy is to let you continue to use Flash as a development environment, even when you’re developing animations for environments that don’t support Flash.

To speed up the development process, we’ve built the Swiffy Extension for Flash Professional. The extension enables you to convert your animation to HTML5 with one click (or keyboard shortcut). The extension is available for both Mac and Windows, and it uses Swiffy as a web service, so you’ll always get our latest and greatest conversion. Information about the conversion process is shown within Flash Professional.

screen shot

You can download the Swiffy Extension from the Google Swiffy site. We hope it will streamline your workflow when you use Flash and Swiffy to produce HTML5 animations. Please let us know how well it works for you via our feedback page.


Esteban de la Canal is a Software Engineer on the Swiffy team. He also enjoys game development, particularly weird-looking snake-like games in Flash.

Posted by Scott Knaster, Editor

Posted:
Author Photo
By Justin Smith, Senior Product Manager

UPDATE 11/14: After considering the feedback and timing, we have decided to delay the launch of the changes described in this post. The new date for these changes is December 7th, 2011. Once again, we expect these changes to have minimal impact. If you have any questions or comments, please post on the OAuth 2.0 Group. We will be actively monitoring that group and will work to respond quickly.


Original post:

In the coming weeks we will be making three changes to the experimental OAuth 2.0 endpoint. We expect the impact to be minimal, and we’re emailing developers who are most likely to be affected.

We will be releasing these changes on December 7, 2011. This post describes the changes, their impact, and how they can be mitigated.

Change #1: Error responses for client-side web applications

The first change relates to the way errors are returned in OAuth 2.0 client-side web applications. It does not impact server-side, native, or device flows.

The current behavior of the OAuth 2.0 endpoint in certain error conditions is to return the error to the application as a query string parameter, for example:

https://www.example.com/back?error=access_denied.

The OAuth 2.0 specification indicates that the error should be returned in the fragment of the response. We are updating our OAuth 2.0 implementation to support the most recent draft of the specification. As a result, we will be changing the way we return errors to applications in the client-side flow.

As an example, today an error returns to your application as

https://www.example.com/back?error=access_denied. After this change, it will be returned as

https://www.example.com/back#error=access_denied.

There is no mitigation for this change, so your application will have to handle these types of errors in client-side script.

Change #2: Offline access as a separate parameter

The second change impacts the OAuth 2.0 server-side flow only. It does not impact client-side, native, or device flows. For context, this flow consists of the following steps:
  1. Redirect the browser to the Google OAuth 2.0 endpoint.
  2. The user will be shown a consent page.
  3. If the user consents, parse the authorization code from the query string of the response.
  4. Exchange the authorization code for a short-lived access token and a long-lived refresh token.
Once your application has obtained a long-lived refresh token (step 4), it may access a Google API at any time. This means server-side applications do not require the end-user to be present when obtaining new access tokens. We’re calling this type of access offline.

The client-side flow, in contrast, requires the user to be present when obtaining an access token. This type of access is called online.

With this change, we will be exposing online and offline access as a separate parameter that’s available only in the server-side flow.

When your application requests offline access, the consent page shown to a user will reflect that your application requests offline access and your application will receive an access and a refresh token. Once your application has a refresh token, it may obtain a new access token at any time.

When your application requests online access, your application will only receive an access token. No refresh token will be returned. This means that a user must be present in order for your application to obtain a new access token.

If unspecified in the request, online is the default.

A mitigation for this change is described at the end of this post.

Change #3: Server-side auto-approval

This change also impacts the OAuth 2.0 server-side flow only.

In the current implementation of OAuth2, every time your application redirects a user to Google, that user must give explicit consent before an authorization code is given to your application. As a result, sending a user through the flow another time requires them to see the consent screen again. Most applications don’t do this, but rather use the existing server-side flow as it was intended: a one-time association (import contacts, calendar operations, etc.) where the result is a refresh token which may be used to obtain new access tokens.

The behavior is changing to the following:
  • Users will only see the consent screen on their first time through the sequence.
  • If the application requests offline access, only the first authorization code exchange results in a refresh token.
To put it another way, consent will be auto-approved for returning users unless the user has revoked access. Refresh tokens are not returned for responses that were auto-approved.

The next section describes how to mitigate this change.

Mitigation of offline access (#2) and auto-approval (#3) changes

If you want to keep the existing behavior in your server-side applications, include the approval_prompt=force and access_type=offline parameters in an authorization code request.

For example, if the following is a target URL for obtaining an authorization code today:
https://accounts.google.com/o/oauth2/auth?
client_id=21302922996.apps.googleusercontent.com&
redirect_uri=https://www.example.com/back&
scope=https://www.google.com/m8/feeds/&
response_type=code
You can maintain the current behavior by changing the target URL to:
https://accounts.google.com/o/oauth2/auth?
client_id=21302922996.apps.googleusercontent.com&
redirect_uri=https://www.example.com/back&
scope=https://www.google.com/m8/feeds/&
response_type=code&
access_type=offline&
approval_prompt=force
You may start including these parameters in authorization code requests today.

Questions?

If you have any questions or comments, please post on the OAuth 2.0 Group (https://groups.google.com/forum/#!forum/OAuth 2.0-dev). We will be actively monitoring that group and will work to respond quickly.


Justin Smith is a Product Manager who works on authentication and authorization technologies at Google. He enjoys woodworking, cycling, country music, and the company of his wife (not necessarily in that order).

Posted by Scott Knaster, Editor

Posted:

By Ju-kay Kwek, Product Manager

(Cross-posted on the Google App Engine Blog and the Google Enterprise Blog.)

Rapidly crunching terabytes of big data can lead to better business decisions, but this has traditionally required tremendous IT investments. Imagine a large online retailer that wants to provide better product recommendations by analyzing website usage and purchase patterns from millions of website visits. Or consider a car manufacturer that wants to maximize its advertising impact by learning how its last global campaign performed across billions of multimedia impressions. Fortune 500 companies struggle to unlock the potential of data, so it’s no surprise that it’s been even harder for smaller businesses.

We developed Google BigQuery Service for large-scale internal data analytics. At Google I/O last year, we opened a preview of the service to a limited number of enterprises and developers. Today we're releasing some big improvements, and putting one of Google's most powerful data analysis systems into the hands of more companies of all sizes.
  • We’ve added a graphical user interface for analysts and developers to rapidly explore massive data through a web application.
  • We’ve made big improvements for customers accessing the service programmatically through the API. The new REST API lets you run multiple jobs in the background and manage tables and permissions with more granularity.
  • Whether you use the BigQuery web application or API, you can now write even more powerful queries with JOIN statements. This lets you run queries across multiple data tables, linked by data that tables have in common.
  • It’s also now easy to manage, secure, and share access to your data tables in BigQuery, and export query results to the desktop or to Google Cloud Storage.

Michael J. Franklin, Professor of Computer Science at UC Berkeley, remarked that BigQuery (internally known as Dremel) leverages “thousands of machines to process data at a scale that is simply jaw-dropping given the current state of the art.” We’re looking forward to helping businesses innovate faster by harnessing their own large data sets. BigQuery is available free of charge for now, and we’ll let customers know at least 30 days before the free period ends. We’re bringing on a new batch of pilot customers, so let us know if your business wants to test drive BigQuery Service.


Ju-kay Kwek is a Product Manager for Google BigQuery Service.

Posted by Scott Knaster, Editor

Posted:
Author Photo
By Scott Knaster, Google Code Blog Editor

One of the most rewarding aspects of working on neat technology is when you can make a difference in the real world. Our Custom Search team has been collaborating with U. S. agencies to produce a job search engine for use by returning military veterans. This is especially cool because today is Veterans Day in the U. S.


Once you’ve seen the customized job search engine, I hope you’ll be inspired to use Custom Search or some other interesting technology to make a difference with your own projects. And speaking of interesting projects...

Wan and exhausted, a team of six men emerged last week from a mock spacecraft after spending almost a year and a half on a simulated trip to Mars. The six lived in windowless capsules in Moscow for 520 days to see how they would react to the confinement.

One physiologist, a trainer, a surgeon, and three engineers made up the diverse crew, who were said to be in good health at the end of the mission. Their virtual trip to Mars qualifies as either a really grueling job or a bizarre vacation.

Wonderful as the simulated Mars mission was, it can’t compete with this classic video – especially today. Have a great weekend!


Wondering what this post is doing on Google Code Blog? Once a week, on Friday, we lighten up and have a little fun, posting curious, clever, and interesting bits and pieces. One more thing: we hope you find one not-so-hidden date-appropriate message in this post.

Posted:
Author Photo
By Stephanie Liu, Developer Relations, Startup and Community Outreach

We announced a partnership with Startup Weekend today that will support budding entrepreneurs all over the world.

If you’ve never experienced a Startup Weekend before, it’s an intense 54 hour event where excited entrepreneurs (developers, designers, product and business folks) get together on a Friday afternoon, pitch ideas, form into teams, then feverishly hack on a prototype application to demo on Sunday night. It’s an energizing event, where strangers become teammates overnight, and the focus is on doing instead of talking.

We love the spirit of these weekends – it’s the spirit of entrepreneurship and creation, and at the heart of it all are developers. That’s why we’re working with our local developer communities (Google Technology User Groups) and Startup Weekend to host pre-Startup Weekend bootcamps on relevant Google tech (like App Engine, Android, and Chrome/HTML5, with more to come).

Find a Bootcamp or Startup Weekend coming up near you! You can also join your local GTUG.


Stephanie Liu joined Google in 2005, and has worked with a variety of products, including AdWords, Google Video, and YouTube. She's currently focused on outreach programs to early stage tech startups, as well as growing and supporting Google's developer community (gtugs.org),

Posted by Scott Knaster, Editor

Posted:
Author Photo
By Nicolas Garnier, Developer Relations Team

A few of us from Developer Relations will be going around EMEA in the next few months to meet with developers and talk about some Google Apps technologies for developers.

This tour will start with Ryan Boyd and Michael Manoochehri speaking about different Google Apps topics at Google Developer Days in Tel-Aviv and Berlin, and a GTUG meeting in Munich.

Then I will be giving an Apps Script talk at the Barcelona Developers Conference followed by a series of Apps Script Hackathons in France (multiple locations), Zurich, Munich and Dublin.

For more information about the tour and to register for these events, please visit the Google Apps EMEA Developer Tour website.



We plan to organize many other Google Apps events close to you in the near future. Look for updates on the Google Apps EMEA Developer Tour website or keep an eye out for further announcements on this blog.


Nicolas Garnier joined Google’s Developer Relations in 2008 and lives in Zurich. He is a Developer Advocate focusing on Google Apps and Web APIs. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.

Posted by Scott Knaster, Editor

Posted:
Author PhotoBy Nicolas Garnier, Developer Relations Team

Cross-posted on the Google Apps Developer Blog

In March, we announced that all of the Google Web APIs adopted support for OAuth 2.0. It is the recommended authorization mechanism when using Google Web APIs.

Today, we are announcing the OAuth 2.0 Playground, which simplifies experimentation with the OAuth 2.0 protocol and APIs that use the protocol. Trying out some requests in the OAuth 2.0 playground can help you understand how the protocol functions and make life easier when the time comes to use OAuth in your own code.


Selecting the APIs to authorize

With the OAuth 2.0 Playground, you can walk through each step of the OAuth 2.0 flow for server-side web applications: authorizing API scopes (screen shot above), exchanging authorization tokens (screen shot below), refreshing access tokens, and sending authorized requests to API endpoints. At each step, the Playground displays the full HTTP requests and responses.


exchanging tokensExchanging the authorization code for a refresh token and an access token

The OAuth Playground can also use custom OAuth endpoints in order to test non-Google APIs that support OAuth 2.0 draft 10.

configuration

OAuth configuration screen

You can click the link button to generate a link to a specific Playground state. This allows quick access to replay specific requests at a later time.

Generating a deep link to the playground’s current state

Please feel free to try the OAuth 2.0 Playground. We are happy to receive any feedback, bugs, or questions in the OAuth Playground forum.



Nicolas Garnier joined Google’s Developer Relations in 2008 and lives in Zurich. He is a Developer Advocate focusing on Google Apps and Web APIs. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.

Posted by Scott Knaster, Editor

Posted:
Author Photo
By By Greg D'Alesandre, App Engine team

Three and a half years after App Engine's first Campfire One, App Engine has graduated from Preview and is now a fully supported Google product. We started out with the simple philosophy that App Engine should be "easy to use, easy to scale, and free to get started". And with 100 billion+ monthly hits, 300,000+ active apps, and 100,000+ developers using our product every month, it's clear that this philosophy resonates. Thanks to your support, Google is making a long term investment in App Engine.

When we announced our plans to leave Preview earlier this year, we made a commitment to improving the service by adding support for Python 2.7Premier Accounts, and Backends as well as several changes launching today:
  • Pricing: The new pricing structure announced in May (and updated based on feedback from the community) will now be reflected in your bill starting Nov 7.
  • Terms of Service: We have a new terms of service, including a 3 year deprecation policy, effective today.
  • Service Level Agreement: All paid applications on the High Replication Datastore are covered by our SLA.
We are holding a series of App Engine Office Hours via Google+ this week for anyone with questions about how this new pricing impacts your application. The list of times can be found on the Google Developers events page, with links to join the hangout while the office hours are scheduled. Also, please don't hesitate to contact us at appengine_updated_pricing@google.com with any questions or concerns.

You can read the full details of our release on the App Engine blog. We'd like to thank you for investing in our platform for the last three years. We look forward to what the future will bring.


Greg D'Alesandre is now the Senior Product Manager for App Engine after coming back from riding the Google Wave in Sydney. And he's obsessed with chocolate, no, seriously, obsessed.

Posted by Scott Knaster, Editor

Posted:
Scott
Monica

By Scott Knaster and Monica Tran, Google Developers Team

Did you know that 722 Googlers contributed to Google I/O in big ways and small in 2011? And that by the end of our Google Developer Day world tour, we will have sent 195 speakers around the world? Or that a team of 22 technical writers crafts all of the documentation you see at Google Code? It really does take a village, and that village includes you. So starting today, you can add our Google Developers page to your circles on Google+ to meet the people behind the products and platforms.


Our Google Developers page will be your primary source for updates from our platform teams, in addition to exclusives on events, behind-the-scenes Hangouts, and maybe banter on new API tweaks or even the latest YouTube sensation. It’ll also be the first place to get info on Google I/O 2012 (including I/O Live and I/O Extended), so we encourage you to get a head start by setting up your Google+ profile and adding Google Developers to a circle.

We’ve got an exciting lineup for you in the coming weeks, so keep checking back as we share our circles, announcements about Google I/O, and get our Google+ page rolling. And in case you’re wondering about Google+ Pages or want to create your own page, read more on the Official Google Blog.


Scott Knaster is a Technical Writer and is editor of the Google Code Blog. He has every issue of MAD magazine, which tells you something about him.

You might remember Monica Tran from I/O Live or one of our eight Google Developer Days around the world. This year, she’s back to lead the charge on Google I/O 2012.

Posted:
Author Photo
By Rania Hadi, MENA Outreach Manager

We had an awesome time at g|egypt last year, and we are excited for version 2.0. Following back-to-back g|days in Dubai and Jordan, we’ll be holding our next g|day in Cairo, Egypt, from December 11-13.

Last year we had great sessions, and this year will be even more packed with all things Google. Each of the three days will have separate tracks, focusing on various audiences: Day 1 is for Business Professionals, Entrepreneurs, & Students; Day 2 is for Webmasters & IT Professionals; and Day 3 is for Developers & Programmers. The sessions will be more advanced this year, so brush up on your AdWords skills, your App Engine coding, and your Google+ knowledge. The more you show, the more likely you’ll get an invitation. We’re even having specific sessions for Android/Mobile application developers this year.
g-egypt logo
We’ll also be bringing back your favorite Googlers. They’ll be around to interact with you, answer questions, and brainstorm. We’ll have more updates and details to share on our site, but for now, be sure to register. We have a limited number of seats so the stronger your application, the more likely you are to receive a spot at g|egypt 2.0. We’ll send invitations to those who are accepted by December 1st, 2011.

If you still have doubts, check out recent g|uae & g|jordan 2.0 photos for a sneak peek of the fun that awaits!


Rania Hadi has been with Google since 2004 and now works on Outreach in MENA. She focuses on building relationships and promoting Google technologies with the developer and tech communities.

Posted by Scott Knaster, Editor