It’s difficult to identify a single page or site on the Net as being yours. Sure, you may have your own blog or even a completely independent website, but with sites like Del.icio.us, Flickr, FriendFeed and your profiles on all these pages, you’re bound to have at least a half dozen other pages that are “yours”. So now that you’re on these services, what should you do? To get the most of them, you’ll of course need to find your buddies on these sites, and that’s where things get tough. How do you know that the John Smith on service XYZ is in fact the same John Smith that you play scrabble with? If John has linked from his web page to his user profile then it’s no problem, but what if he’s only got a link the other way around, from his user-profile page back to his web-site. You shouldn’t have to click through the dozens of profile pages to find his - let Google do the work for you through the Google Social API!

A few months ago, Google made available an API which you can use to query the social network inherent in the web, by following the “me” links or pointers from one network’s profille to another, as well as the “friend” pointers. By then giving the URL of my web site, I can find all my “other” pages on the Internet, as well as everyone else that I link to or am linked by.

Using this social graph of services, it’s easy for you to find what services you have in common with someone else to be able to link with them there. To make this easier I have a very trivial bookmarklet I can invoke when I’m on any site, which does a lookup via Google Social’s API. To use it, simply drag and drop the “Google Social API Lookup” link to your bookmarks toolbar. Click it when you’re on any blog or profile page, and you’ll do a Google Social lookup. Enjoy!

A lot of people know that I’ve been working with Selenium to automate UI tests. You can now see a few examples of how specifically we use Selenium at Google, via the publicly released Selenium-based tests used as part of the Maps API testing process.

When you’re developing a Web-based application, testing a Web UI can get quite time-consuming. Throw in the problem of having to support multiple browsers, and the complexity of AJAX, and things can get out of hand quite quickly. This is where having an automated set of UI tests can be a life-saver. Make these tests part of your CI process, and you’ll get feedback as soon as something is broken.

Often, people end up testing the UI as part of an end-to-end test. This isn’t necessarily the best way to be testing the UI, as you’re no longer able to pinpoint the location of problems to a particular layer. Is that problem you’re seeing a data-encoding issue of the HTTP request/response, the database, or the persistence API? It could be anywhere. So take advantage of that multi-tiered system design which you have. Test each layer in isolation, separate it from the other layers that it’s talking to by putting fake, mock or stub layers in place, and test that layer by pumping in events and calling methods. Check the calls appearing out of that layer to verify they’re what you expect, and you have a much more useful set of tests.