DataStore Latency II

As promised Google went on an data store overhaul today.

One good thing is that there was no significant application disruption during the maintenance period, except of a short write-only read-only period that was pre announced by App Engine team.

Second good thing is that judging by my appls average response time the results are excellent.

This is also depicted in Datastore Status Page, which for historical reasons I am attaching here.

From the picture we can see that after around 03:30 PM when maintenance finished datastore latency dropped dramatically, also we do not see any spikes (well not until the time I write this - fingers crossed).

So lets keep the picture here and see how today's maintenance will affect App Engine on the long run.

Meanwhile I can see a change in Python's average response time which seems a little elevated but more steady than before.

Kudos to the App Engine team for the work they have done during the weekend  to minimize potential problems.

DataStore Latency

There is a lot of talk going on in technical blogosphere regarding App Engine's elevating datastore latency lately. Google has acknowledged the issue and respondend here and promised a fix within a couple of weeks.

The problem does affect the applications running in app engine as you can see from one of my Appls Site performance charts as plotted by Google Webmasters tools:
The explanation given by App Engine's team above is that this is the result of rapid growth rate of App Engines usage during past few months and I do believe this explanation.
The problem is that it also happened while Google announce App engine for Google Appls. My point of view is that App Engine should hold from expanding to new areas till all technical problems, outstanding issues and features promised in the road map get materialized. But then again who am I to tell Google what to do ?.
By the way an interesting but rather naive view has been written in App Engines mail-group about DataStore Latency affecting SEO.
One of the contributors there seems to believe  that  "But it could also happen nothing too because google detects that your site runs on their service" i.e. Google search could possibly will not penalize for been slow applications running on App Engine since these are running on Google's infrastructure.
Well I can tell you this can't happen since it defies search's main purpose to "provide best results for the user" besides I do not believe search results and serps can change that much within couple of weeks time (caffeine is just designed to target this delay).

MultipleChoiceField Django field with select multiple

Yesterday I was trying to find a way to use MultipleChoiceField Django field along with a CheckboxSelectMultiple Django widget for an input form that contains some tags used in an App Engine model field.

There is an excellent solution described in ( better-way-to-use-djangos-selectmultiple-in-google-app-engine-for-a-listproperty/) except that it relies on

google-app-engine-django package which is a nice package bridging App Engine db models and Django models.

But ... for this particular case I needed a light solution with a very small footprint and a minimum of imports.

It was more easy than I though.

First define our input choices and respective labels : tagChoises = ( ('Tag 1', 'Economy'), ('Tag 2','Geograpy'))

Then define your form item: tags = forms.MultipleChoiceField(required=False, choices=tagChoises , widget=forms.CheckboxSelectMultiple)

The form now displays the check boxes which a user can fill.

Problem is, if a user selects multi tags only the one is returned for saving into the db and since this value is a unicode string while a list of string values is expected it results in an form error.

Solution: intercept the retrurned value in Request Handler post this is a UnicodeMultiDict .

It turns out that getall method of this class returns a list of the selected strings so last item of code : self.request.POST['tags']=self.request.POST.getall('tags' ) makes the trick and posted values are ready to be put.

I know this is an ungly hack but still it is ok for situations where the complete Django package is an overkill.

MapReduce Support for GAE

It seems Map Reduce support is coming to App Engine although no official anouncement yet, except what is available on code's Wiki page (http://code.google.com/p/appengine-mapreduce/wiki/GettingStartedInPython)
Well done App Engine team !

10 things we do not love in Ubuntu 10.4

There was an article on techrepublic today titled "10 things you'll love about Ubuntu 10.4"

And what about those 10 things we do not love in Ubuntu 10.4 ?

Well ... make it just 1 - moving the window controls to the left  I think it is a damn wrong move since It creates a lot of confusion especially to new users converting from Windows and quite a lot of ambiguity since some windows still have window controls on the right i.e. Chrome browser.

Of course you can move the controls back to the right using the configuration editor but this is not a solution for newbies.

I believe Canonical's first priority should be targeting Windows users coz there are much more  of them  and more easy to convert compared to Mac users.

Google Maps API quotas and App Engine

There is a lot of talk in various forums that I follow about Maps API quota limits.
To summarize: there is a limit of  2500 requests per day per requesting IP (see: http://code.google.com/apis/maps/faq.html) , if your application issues those requests from any server you can reach this limit quite fast. The situation is much worst if your application is based in GAE then it has to share those quotas with any other application in GAE that happens to use the same  API since all those applications are served from a limited number of google IP's making the API useless.
So far so bad except ...  there is a solution, delegate the job to the client using JSON & JS. This way :
a) quotas are calculated against your user's IP and more probably than not he will never exceed those.
b) you offload some workload from your server.
c) save some bandwidth.
Practically  I can't see a scenario where we can't use client side, since whatever we do we have to use the results only in connection with a Google map according to Maps TOS para 10.12 (unless of course you opt for the premier edition).

Happy Birthday

It was two years ago today that I have started developing in App Engine, been one of the first 10000, when it was released to the first 10000 developers.
Since then I have spent a lot of days and nights (well ...  mostly nights) working with App Engine having seen it advancing to its present form, something I do not regret.
On this occasion I must express my many thanks to the wonderful App engine team for their efforts and the support they give to developers.
http://googleappengine.blogspot.com/2010/04/happy-birthday.html