Dan on the GAE changes. "I am now thinking in terms of running my code on x number of servers, which is totally what I didn’t want to be thinking about."

New in 1.4.0: "The Channel API creates a persistent connection between your application and Google servers, allowing your application to send messages to JavaScript clients in real time without the use of polling. This is useful for applications that are designed to update the user about new information immediately or where user input is immediately broadcast to other users."

"The Python SDK's datastore implementation operates by storing the entire contents of your development datastore in memory." "The new local datastore implementation fixes both these issues by rewriting the datastore stub to use SQLite as a backend." Try the beta now. (docent's memory usage when running a local copy of the full DB was... painful.)

"I made some new things." Aaron talks about some of the lovely little new views onto Flickr (Contacts Who've Faved, Things I Can't Face, etc) that he's built on Google App Engine. It reminds me I should maybe go back to thinking simple, not thinking complicated.

New in Google App Engine: "Datastore Query Cursors / No more 1000 result limit / Reduced error rate with Automatic Datastore Retries / AppStats RPC instrumentation library." Good stuff. Should let me fix some things with docent too...

Google App Engine gets prototype OAuth support. One to look at, I suspect.

"FlickrApp is a simple base class to use with Google App Engine (GAE) packages that allows you to use Flickr as a Single Sign On (SSO) provider and validation service" which should save me writing a bunch of boilerplate every time I start a new app. (A well tested version for Twitter would be nice...)

"gae2django is a Django helper application that provides an implementation of Google's App Engine API based on pure Django. The helper makes it easier to re-use applications originally designed for Google's App Engine environment in a Django environment." Handy for avoiding lockin (which seems to be attracting folk to Heroku).

"You can now set a daily budget for your app that represents the maximum amount you're willing to pay for computing resources each day." "In 90 days we will be reducing the free quota resources. We believe these new levels will continue to support a reasonably efficient application serving around 5 million page views per month, completely free." Win some, lose some...

'No more "High CPU Requests"! App Engine Apps were once allowed no more than 2 CPU-intensive requests per minute. We've made some adjustments to the way we handle requests, and have eliminated this limitation altogether.' More on the GAE-becoming-production-ready front, then.

Background tasks and task queues, XMPP and receiving email, oh my! Handy stuff, when it shows up (possibly for Google IO in May?)

How to get dev-appserver to bind to a specific interface, rather than 127.0.0.1, which can be handy if you want to do local testing (the author wants it for IE debugging).

How to use the ReportLab PDF generation library with Google App Engine. Summary: it works out of the box, except it tries to make a file, so stop it doing that and you're good to go.

This seems to be a consistent source of App Engine criticism; basically, "I don't see the point of giving up my RDBMS just for (alleged) scalability". The comments do a good job of pointing out that, actually, RDBMSes just leave you with the pain of partitioning later. Mind you, my perspective's a bit odd, given how rarely I use persistent local data. (He's right about background tasks though.)

I think I should be paying more attention to the GAE blog, if I'm missing interesting/important things like this: "System Status Site that monitors the latency and uptime ... new Quota Details Dashboard ... [and] a sneak peak at our upcoming billing feature" (Yes, I've subscribed now.)

This pretty much mirrors my experience with App Engine; well documented, and trivially easy to deploy to. I've not used custom domains, so I've not run into the problems Paul found, but even so, he concludes, "App Engine is pretty much perfect for apps like this, and I can see me using it a lot more in the future..."

Yet another get-out route for GAE. Not for me, at the moment, because I'm not using Django, but still, probably worth a bookmark and a read.

Apparently the state of the art in Django-on-App Engine packages (as opposed to, say, google-app-engine-django or - horrors - following the article on the App Engine site itself).

A Google App Engine-hosted web-based front end to the App Store, which used to be accessible only though iTunes - and therefore not bookmarkable, etc, etc. There's no details of who's behind it, which is perhaps understandable, but also a shame.

Video and slides from a talk a while ago on how to build good apps on Google App Engine. Covers profiling and has a version of the "email on error" recipe. (I've read the slides but not watched it.)

Once I figure out how to get email working (pesky 'has to be an admin' nonsense) I might add this. Mind you, I already get quite good visibility on errors. There's more useful stuff on the site, too.

Does what it says in the title. I'm not sure I'll use exactly this, mind.

Something to do if I want sparklines in my app, perhaps.

"The Google App Engine quota system is fundamentally broken. You cannot have a cloud solution that 'intelligently' takes sites down, essentially making every site running on it into a Twitter at the height of its troubles" "This isn't Google Toy Engine, it's Google App Engine"

A collection of tips for various things to do with Google App Engine, which is kind of handy.

"The appengine-utilities project is for people who have needs not supplied by the Google App Engine environment by default. It includes such features as sessions for preserving data across multiple page views" So far, fairly useful.

Background processing requirement on a GAE project? This will help you use S3+SQS to handle it. (Hmm, too many acronyms there perhaps.)

"IMG·2·JSON is a simple Google App Engine python application which extracts metadata from images and returns the results as a JSON string. " Could be handy, perhaps. Impressive use of GAE too.

"The Reasonably Smart Platform is a Platform-as-a-Service based on JavaScript and Git, allowing for computing-in-the-cloud for the web that works the way web-developers work" Alpha, and documentation light, but worth watching, hopefully.

Sounds like Brad Fitzpatrick is trying to get this off the ground. "basically, we'll be statically linking in a hardened, customized libperl to a C++ application, disabling all Perl dynamic loading" amongst other things.

"AppDrop is simply a remote installation of the App Engine SDK, with the user authentication and identification modified to use a local silo instead of Google Accounts" On github. So much for lockin?

I've been wondering if Simon Wardley would comment on App Engine, and he does. His comments on the SDK match what Tom and I have said: you can deploy to your own colo from the SDK. There's your exit strategy. (You do lose single sign on.)

"Amazon's services were like a breath of fresh air while so far, Google's has filled me a dread I dare not name." Michal Migurski compares the tabula rasa of EWS with Google's App Engine. Interesting.

A good overview of Google's App Engine from Brady Forrest at O'Reilly.

Well, this is a bit of a surprise. The Finnish lifestreaming web app that Google bought is moving to their App Engine scalable platform. Hmm.

Lots to digest here, but it looks like this - not Mashup Editor - is what I wanted half a year ago when I had an app to migrate from Zimki. Notable: Django; local dev; not-SQL database; free (for now) then micropayments.