cloud-test

Go Version 1 now on App Engine

Wednesday, March 28, 2012

Today, with the release of Go 1, a stable version of the Go language, libraries and tools, we're releasing a new Google App Engine SDK for the Go runtime.
Go is a statically typed, compiled language with a dynamic and lightweight feel. With Go you get the efficiency benefits of being close to the machine–your programs compile to native code–with the productivity and quick turnaround of a scripting language. Go apps are easy to write, start fast, and run fast. There has never been a better way to build scalable high-performance cloud applications.

The Go runtime provides clean, idiomatic Go APIs for the popular App Engine services (Blobstore, Datastore, Memcache, and so on) and a straightforward development process. As with the Python and Java SDKs, Go apps can be tested locally with the development server and, most convenient, the development server automatically compiles your Go code, so to test a change all you need to do is to refresh your browser.

The Go 1 SDK also brings improvements and bug fixes. It uses the new Go 1 time API throughout the SDK, provides a MultiError type for error handling in batch operations, and supports Datastore Cursors and the XMPP and Log services. See the release notes for the details.

Although the Go App Engine runtime is still in experimental status for now, the language stability offered by Go 1 is a major milestone. To learn more about Go 1, see the announcement post at the Go blog and the wealth of documentation at golang.org.
- Posted by the Go and App Engine Teams

App Engine 1.6.4 Released

Tuesday, March 27, 2012

App Engine’s march of progress continues with another release that’s full of new features, system improvements, and bug fixes. As we spring forward into pre-Google I/O season, we’re keeping our focus on product polish and this release is a shining example.

System Wide Changes

Logs - Now that the new settings for log storage have been available for one month, logs over the limit you specify will be deleted.

Datastore Index Stats - The Datastore Statistics page in the Admin Console now displays the storage used by your Datastore Indexes in addition to your Datastore Entities.

Blobstore Migration - The Datastore Migration tool now includes an experimental option which allows you to migrate your Blobstore objects during the migration process from M/S to HRD. We strongly encourage all applications to migrate to HRD.

Datastore Backup to Google Cloud Storage - In 1.6.3, we launched backup and restore to Blobstore, and in this release we’ve added the ability to backup your data to Google Cloud Storage.

Memcache viewer - We’ve introduced the ability to view Memcache statistics and examine memcache entries by key.

Serve objects from Google Cloud Storage - You can now serve blobs directly from Google Cloud Storage as well as Blobstore.

Runtime Changes

Threads - Both Java and Python now offer background threads when running on backends as an experimental feature. Additionally, we’ve added the ability to use threads for frontend requests in Java to match Python 2.7.

Datastore Framework Changes

NDB for Python - The NDB API has graduated from experimental and is now a fully supported feature. This next-generation datastore API improves data modeling and querying and has been built from the ground up to support an asynchronous computing model.

JPA 2 and JDO 3 for Java - We have made significant improvements to App Engine’s DataNucleus plugin. This experimental release of version 2.0 of the plugin adds support for JPA 2, JDO 3, and contains over 40 bug fixes. Check out the full release notes here.

And that’s not all, you can read about all the new features and bug fixes in our release notes (Python, Java). Send all your feedback to our Google Group, and if you have coding questions, find help from us and other talented developers on Stack Overflow.

- Posted by the App Engine Team

App Engine Community Update

Thursday, March 22, 2012

One of the best things about App Engine is our lively developer community. This week, we’re officially moving technical and development questions to Stack Overflow and retiring the language-specific App Engine Google groups. With this week’s move, we wanted to take a moment to highlight some of the best ways to engage with the community.

Technical & Development Questions
For technical and development questions big and small, add the google-app-engine tag to your App Engine questions on Stack Overflow. You can also join our hangouts or office hours to talk directly with App Engine team members.

Google+
Many community and team members are active on Google+, using the #appengine hashtag. Our weekly community updates and chats with App Engine community and team members are a great source of tips and tricks and to learn more about what our community members are up to.

Google Groups
For general discussion about the platform, use the Google App Engine group.

Happy coding!

- Posted by the App Engine Team

Using the updated Google Prediction API in App Engine applications

Thursday, March 15, 2012

Although we can’t reliably compare its future-predicting abilities to a crystal ball, the Google Prediction API unlocks a powerful mechanism to use machine learning in your applications.

The Prediction API allows developers to train their own predictive models, taking advantage of Google’s world-class machine learning algorithms. It can be used for all sorts of classification and recommendation problems from spam detection to message routing decisions. In the latest release, the Prediction API has added more detailed debugging information on trained models and a new App Engine sample, which illustrates how to use the Google Prediction API for the Java and Python runtimes.

To help App Engine developers get started with the prediction API, we’ve published an article and walkthrough detailing how to create and manage predictive models in App Engine apps with simple authentication using OAuth2 and service accounts. Check out the walkthrough and let us know what you think on the group. Happy coding!

- Posted by the App Engine Team

App Engine 1.6.3 Released

Tuesday, February 28, 2012

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

Announcing the General Availability of the Python 2.7 Runtime for App Engine

Monday, February 27, 2012

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)

The BugSense hybrid app: experiences using Clojure on Google App Engine

Tuesday, February 7, 2012

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.

Google Cloud Platform Blog

Go Version 1 now on App Engine

App Engine 1.6.4 Released

App Engine Community Update

Using the updated Google Prediction API in App Engine applications

App Engine 1.6.3 Released

Announcing the General Availability of the Python 2.7 Runtime for App Engine

The BugSense hybrid app: experiences using Clojure on Google App Engine

Don't Miss Next '17

Free Trial

GCP Blogs

Labels

Archive

Feed

Subscribe by email

Company-wide

Products

Developers