• A new Experimental feature called Traffic Splitting lets you send a percentage of your traffic to different versions of your app. Traffic can be split based either on IP or on cookie.


• When an email is sent either from a user of a Google Apps domain from a request originating on that domain, or from an app administrator with an account on a Google Apps domain, a DKIM signature will be automatically applied to the email.

Read More

Our second release of this year will have you leaping into action to start using the new features immediately. What could be more exciting than a feature to support A/B testing on your app? Or DKIM signing when you send email from your Google Apps domain? This release has plenty of exciting changes to keep you busy on your extra day this year.

1.6.3 Platform Changes:

• A new Experimental feature called Traffic Splitting lets you send a percentage of your traffic to different versions of your app. Traffic can be split based either on IP or on cookie.


• When an email is sent either from a user of a Google Apps domain from a request originating on that domain, or from an app administrator with an account on a Google Apps domain, a DKIM signature will be automatically applied to the email.

1.6.3 Admin Console Changes

• Billed applications can now specify the amount of storage used for logs and the duration of time these logs are stored (default is 90 days) as well as view the currently stored amount in the Admin Console. The first gigabyte of logs storage is free and additional storage will be charged at $0.24/G/month. These settings are now available, but additional storage will not be charged for at least 4 weeks, at that point any logs beyond the configured amount will be deleted.


• You can now manually shut down an instance in the Instances view of the Admin Console.


• The Logs Viewer for each request now provides a link to the instance that served that request (as long as the instance is still active).

These are just some of the highlights in 1.6.3. As usual, our release notes for Python® and Java® contain the full list of all the new features and bug fixes, so be sure to check out all the exciting things we’ve been working hard to release this past month.




Posted by the App Engine Team 

The Python 2.7 launch cake

Posted by Chris Ramsdale, PM Python 2.7 Runtime for App EngineRead More

A few months ago we announced an experimental version of the the Python® 2.7 runtime for App Engine. Since then we’ve been hard at work fixing bugs and adding optimizations. Today we’re happy to announce that this runtime has graduated from Experimental status and is a fully supported feature of App Engine. To get started, download the latest App Engine SDK for Python and check out the Getting Started Guide.

We think the Python 2.7 runtime for App Engine is a great step forward for our developers.  First, it allows applications to take advantage of concurrent requests, allowing you to build more performant and efficient applications. If your application wasn't fully utilizing the CPU, chances are that you'll be able to use concurrent requests to reduce the total number of instances and serve more with less.

We've also added some of the most highly requested libraries: PIL, NumPy, and lxml are all part of the Python 2.7 runtime. These three libraries alone have been requested nearly 2,000 times. Check out our updated list of supported libraries and let us know what libraries you would like us to add (be sure to add the tag ‘[Python Library]’ to the summary).

Whether you’re looking to migrate an existing application or build a new application, the Python 2.7 runtime is ready to go.

If you have any questions or comments send them to the App Engine group. We'd love to hear from you.

The Python 2.7 launch cake

Posted by Chris Ramsdale, PM Python 2.7 Runtime for App Engine

(Python and the Python logos are trademarks of the Python Software Foundation)

Today’s post comes to us from Jon Vlachogiannis and Panos Papadopoulos, founders of BugSense, a mobile error analytics service. We hope you find their insights on using Clojure on Google App Engine informative. Read More

Today’s post comes to us from Jon Vlachogiannis and Panos Papadopoulos, founders of BugSense, a mobile error analytics service. We hope you find their insights on using Clojure on Google App Engine informative.

BugSense is a cross-platform error analytics infrastructures for mobile devices. BugSense uses Google App Engine to power its backend, processing more than 1.6 million daily errors, generated by more than 45 million devices around the world. Chances are one of the applications installed on your smart phone (like SoundCloud or Trulia) is already using BugSense.

The Problem
Lots of our clients want to optimize and protect their mobile apps (through code obfuscation) using ProGuard. ProGuard creates more compact code, resulting in faster transfer across networks, faster loading, and smaller memory footprints. On top of that it makes programs and libraries harder to reverse-engineer.

However, because the Android Market doesn't automatically de-obfuscate of stack traces from ProGuard-ed apps, developers who want to analyse errors from their apps must get the stack trace from the Market, format it and use ProGuard locally. The whole process for just a single error could take more than 3 minutes, so we decided to add support for ProGuard to BugSense to make debugging easier and faster.

The Solution: Clojure and Python
The main data-serving portion of our app is written in Python, our language of choice, but ProGuard is an open source project in Java. For easier development, we ported parts of ProGuard to Clojure, a dynamic language belonging to the Lisp family that runs on the JVM. This allows us to “beat the averages” by exploiting all the great features that a LISP language offers (such as macros  and exploratory programming). Using Clojure and having access to a vast number of Java libraries assisted us in tackling the difficult problem of de-obfuscation, with great results.

Once we were done, we deployed using AppEngineMagic and now it's trivial (one click) for our users to de-obfuscate their stacktraces. Now we have the best of two worlds: Python for serving data and Java/Clojure for doing calculations, all in the same Google App Engine application. And it scales automatically and runs even faster than running ProGuard on your laptop!

Practically, that means that we can have a heterogeneous app on Google App Engine so that we can keep programming in our favourite language, Python, but still harness the tremendous wealth of Java libraries using Clojure. Running a hybrid app on App Engine is trivial since they share the same resources task queues, Datastore, and memcache.

However, because our app is implemented in multiple languages, we need to start two different local instances (one for Python and one for Clojure). We use a combination of mocks for both of the instances in order to emulate the hybrid app and their interaction in a local environment for development and testing.

Google App Engine, a success factor
We started as a two-developer startup and our product rapidly became popular across the world. Building on Google App Engine helped us focus on product development and forget about infrastructure and administration, thus enabling us to focus more on our customers' needs. (And sleep tight at night.) Furthermore it helped us to keep costs low and iterate quickly.

To learn more about BugSense, check out our website. If you have comments or questions about this post or just want to reach out directly, you can find us at +jonromero or +bugsense.