appengine

uBoggle is now appearing as the featured application on the Google AppEngine Application Gallery. Thank you for your votes, and thanks to the appgallery editors!

And I have a screenshot for proof and posterity :)

As I mentioned recently, I have been dabbling with Google App Engine for fun with some of my friends. I think we are now at a stage where we could use some more players! :)

Ladies and Gentlemen, I'm proud to present uBoggle – the best game of its kind out there! If you like games like Scrabble, you'll love uBoggle :)

We have some amazing features – such as word highlight, word meanings and board rotation – and addictive game play, so do give it a try. You can play without logging in, but if you log in, you will get access to additional features such as game history. Many more features are on the horizon, so check back often.

If you like the game, please leave a comment here. Thanks!

I've been playing around with Google AppEngine for the past two weeks, and the experience has been mixed so far. First, the good:

• really easy to build something simple and get started.
• no need to worry about scaling, backup, replication etc. I haven't verified this obviously, but at least thats the claim.
• the integration with Google accounts is nice.
• good documentation, lots of sample code available.
• dev server really helps with most of the development.
• the sort of restrictive resource usage limits (see below) forced us to think carefully about our code and heavily optimize certain operations to make them work on GAE.

And now, the bad:

• too many limits: 1 million is their favorite number. No files over 1MB, no request should take more than 1 million CPU cycles (whatever that means) and who knows what other limits they impose internally. While developing, this was the biggest barrier for us. Things would randomly fail, and then our application would be disabled for several hours.
• The dev server doesn't replicate the constraints in production. So everything would run fine and dandy locally, and the minute we upload, it would fail. Since we can only debug in production, and our application exceeded the quota every time we ran it, debugging was extremely slow and painful.
• local data store is excruciatingly slow. But this is not that critical, since it is only for testing anyways.
• even the remote data store is very flaky and slow at times. Any query involving more than a few hundred elements exceeds the quota.
• the bulk uploader is very useful, but again it is really really slow. If you want to upload anything in “bulk”, you'll have a hard time. The parameters have to be chosen carefully as well. Even for very simple data models involving 3-5 fields (mostly strings), we had to reduce the batch size to 2-4 to make it work. And despite that we got a few HTTP 500 errors while uploading.

But its been fun so far. Hopefully most of these issues will get ironed out moving forward. As for what we are building? That will have to wait for another post