Amazon EC2 introduced two new features recently: Elastic IP addresses and Availability Zones. With these two much awaited features, I strongly believe that cloud computing has arrived. If you haven't started using EC2 yet  because you thought cloud computing was too bleeding edge and unreliable for your liking, it's time to take a second look. If you have been using it, but were seriously worried about not having a phone number to call when an instance goes down, your calls have just been answered.

Elastic IP addresses are loosely equivalent to round robin DNS addresses/ multiple A records for a domain. In some ways it's even a step ahead because you don't need to worry about wrongly cached DNS entries and propagation. Clients continue to send requests to the same IP address and once the request enters the EC2 network, it's mapped to a different server.

Availability zones are analogous to having multiple co-locations/ data centers. The idea is that a network/power outage (or in even more extreme cases physical calamity) won't mean that your application is completely down -- an isolated set of servers in a different co-location/ data center continue to serve requests.

These two features are very important because they make up for the inherent reliability issues with cloud computing instances and take cloud computing a step closer to being a serious alternative to conventional server infrastructure.

Cloud computing has the potential to make reliable web scale infrastructure a commodity available to everyone, as opposed to an exclusive expertise available with a few large companies. And that means companies can focus on building applications without losing sleep over infrastructure reliability and scalability issues -- a huge step forward.

Tags: amazon ec2, infrastructure., scaling, tech, web

Jeffrey McManus has written an awesome post about why the Y! Maps API is better than that of brand X here. It is a fun read, read it even if you don't give a damn about Y! or maps or brand X or web services.

Hope ye all have checked out my featured app. Here are a few more that make use of the Maps API ( from the mailing list )

• http://api.maps.yahoo.com/Maps/V1/AnnotatedMaps?appid=bayview53207&xmlsrc=http://www.gobayview.com/map_yahoo/rss.php


• http://api.maps.yahoo.com/Maps/V1/AnnotatedMaps?appid=vinceeats&xmlsrc=http://lucidit.com/test/sideways.xml


• http://api.maps.yahoo.com/Maps/V1/AnnotatedMaps?appid=artlungmaps&xmlsrc=http://sandiegobloggers.com/newmap/data.xml.php

Its simplicity is making it quite popular, already!

Tags: tech, webservices, yahoo

You can read all about the API here: http://developer.yahoo.net/maps. Being a part of this has been the one of most satisfying moments professionally, so far. The fact that this happened on the same day is no co-incidence. Being a part of this race makes the whole thing more challenging and enthralling. Gopal did submit a story on the Y! Maps API to slashdot. Never mind the slashdot crowd, I read slashdot for the comments :D.

By the way, the Grease monkey script that I wrote is a featured app on http://developer.yahoo.net. You can read instructions on how to use it here. You can download the script here. This is my first Grease monkey script and I am absolutely in love with it. I hope to make more additions so that it would use all the features of the API.

This is the mailing list for the maps web service API.

The API works with all geoRSS compliant feeds. You can get an appid from here and construct a request: http://api.maps.yahoo.com/Maps/V1/AnnotatedMaps?appid=< Your_AppId_Goes_Here >&xmlsrc=< Geo_RSS_Feed_Goes_Here>.

You are welcome to modify my script to make it work for other sites that you think could use the Y! Maps API. If you think there are any such, let me know.

If you have any feedback on the Y! Developer Network or the maps API in general, this is the place to go.

Have fun!

Tags: tech, webservices, yahoo
Current Mood: satisfied
Current Music: key strokes and random hallway chatter in office

While we are on the topic of programming puzzles, this is one I am really fond of. It's simply because this was the first one I tried to write and failed, more than a few times. I was only a couple of months into C ( the first programming language I learnt ) and this one really made me pull my hair apart. Makes me laugh when I look back :) Here we go!

Problem: Find the largest monotonically increasing subsequence ( contiguous elements ) of a given sequence.

( Hint )

( The solution )

Tags: programming, python, tech
Current Mood: demotivated
Current Music: ramta jogi

Whatever code you write, you always write it better if you write it again. This has never failed to be true in my case. Very often I have been happy to have deleted programs (by mistake) because they have been so much better on the second run.

Coming to the point, Swaroop took part in the Google Code Jam ( don't ask me why I didn't, I honestly don't know) and gave me what he thought was the toughest question of the second round.

Now I have Gopal for company to hack around ( boy! am I happy ) and we decided to try some XP on it. No marks for guessing which language we chose - python of course. Ya now I know, GCJ had only C++ and Java :P

The concept of pair programming, at least the way we tried it, is very simple. Two people take up a problem simultaneously and try their own approaches in parallel. In sometime, it becomes evident that one approach has a better chance of succeeding than the other, and then you sit together and write code further. It does work really well, in most cases.

Being not at all new to programming contests ( that's how I got my job @ Y! - through a programming contest ) I know a damn and dirty way of solving any problem you give me - game trees and recursion. The philosophy is very simple - "When in doubt, use brute force". Put more technically, at any point in a problem, you have a finite number of paths you can follow. If you follow all of them at every point ( use recursion ), you will cover all possible solution paths. This is hopelessly inefficient as it is O(n^n) and uses recursion, but there has hardly been a problem it cant solve. There are some problems you can only solve that way, the 8 queens problem for instance. Then you do what is called alpha pruning and reduce the number of trees. Will post on it sometime.

So this problem got solved too, and Gopal and I got together and optimised and reduced the execution time from 65 seconds to 3.5 seconds as it often happens with alpha pruning - some branches of the tree just need not be there.

Coming back to my original point, the solution I had was way better the second time around: I solved the same problem today evening in 20 minutes writing 25 lines of python code using good old for-loops and it has sub second execution times even in python!

It makes me feel silly now that I ever tried to use recursion for this.

As they say, hindsight is always 20-20!

( The problem and the solution )

Tags: programming, python, tech
Current Mood: geeky
Current Music: pal