google

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 :)

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

Google Reader offers several options for sorting feed items. After having played around with the “auto-sort” for several months now, I am reverting back to “Sort by newest”.

The problem is that the auto-sort mode is a little too simplistic. Here's what it does in their own words:

The general idea behind auto-sort is good, but unfortunately the execution hasn't evolved at all to become smarter. For instance, some blogs I read haven't been updated in a while. And I'm really not interested in the stuff they wrote some months back. So I never read those few old posts and yet they continue to hang around at the top of my feeds, which gets annoying quickly.

Ideally, the auto-sort should also take into account my reading trends (they obviously collect all this data, so might as well use it). In my case, what I really want the auto-sort to do is this: if there are some old posts and I'm consistently choosing not to read them, then perhaps they don't need to be raised to the top any more. If I need to find them, I can always do so. In fact, I wouldn't even mind if the old posts were raised to the top of the list once in a while.

An even smarter auto-sort will also take into account my reading habits. If there's an infrequently updated blog that I read religiously, then I definitely don't want to miss even an old post, no matter what. Similarly, old posts from an inactive blog that I have stopped following should be given less weight.

How do you sort your feeds?

I've always felt a little sorry for Yahoo! (and I find it ironic that even for such a statement, I need to use the exclamation point). They always seem to be living in the shadow of Google, some times to no fault of theirs. Sure, they have made their share of mistakes, but I think the tech circles, and particularly the media give Y! much less credit than it deserves. And thus I've been following the Microhoo saga with some interest, and with a feeling of resignation (full coverage).

It would be sad if the merger/acquisition does go through (which I think it will, eventually). Meanwhile, while the long drawn battle plays itself out, I can't help but wonder why Y! failed to leverage some of its really valuable assets. Honestly, some of their assets have incredible value in them. To some extent I do blame the media (or Yahoo's PR). I don't believe that Google does all the innovation, nor that all their products are superior to the competition. But still, even if someone in Google sneezes, it gets Dugg and Slashdotted and every one just goes hyper. In this post I'll discuss some of these issues.

First off, some of the good stuff (I'm not going to mention the usual suspects like Y's traffic numbers or their share in the web-mail and IM markets):

• Yahoo! is a major supporter and contributor in Hadoop: an open source implementation of Google's MapReduce. Complaints of Yahoo playing catch up and “too little too late” apart (I will address them in another post), I do think this is a timely and much needed development, both for Yahoo and the industry in general. A cursory look at the list of places using Hadoop is enough to give an idea of the kind of enabler this platform is. An entire community and several other projects are mushrooming around Hadoop including HBase, Pig (bad name if you ask me) and Hypertable. Google might have the largest, most efficient MapReduce and BigTable implementations, but their implementations are just that – theirs, and extremely closely coupled to their infrastructure. Opening up such a platform for others and building a healthy community around it is I think a Good Thing.
• Yahoo! Developer Network: This crew has churned out some remarkable products (such as YUI and YSlow) as well as some really well organized guidelines (such as the Design Pattern library).
• Finance: the competition is not even close.
• Flickr and Del.icio.us
• Yahoo! Mobile: I have yet to get on the mobile Internet bandwagon, so I really have no first hand experience here. But I've heard that Yahoo products have much better support across a wide variety of devices compared to the competition. In fact, until the Java based GMail reader came out, the mobile version of GMail's web interface was quite lacking.

That said, I feel there are two main areas Y! needs to work on if they want to get back in the game:

• Brand image: Y! needs to work on how they are perceived externally as well as internally. I feel that people who work at Y! themselves don't believe in the company, or have the feeling it is somehow not as good as or not as cool as other companies. A lot of Google's brand image comes from the attitude of its employees, and the work culture. Ditto for Microsoft.
• Streamlined products: Yahoo! Maps and Mail are good applications, but they are far too bloated. Even on my reasonably powerful dual-core desktop, these applications feel sluggish and drive the CPU to saturation which is just not acceptable. In comparison, offerings from Google feel much leaner, load quicker and are more responsive.

In the end, the company that remains competitive and offers the best value to its customers and shareholders will prevail. And I feel that a combined Microsoft-Yahoo entity will not make the space any more interesting. On the other hand (as many fear) I think it might kill and certainly slow down innovation that might otherwise have happened. If Yahoo! can somehow manage to stay afloat on its own, it will at least be a little more exciting. So come on Yahoo! dikha de (translates to “show us”)!!