GMail New Mail Notification Feed

Just discovered GMail has this feed for new mail notification. It's perfect for me. I use Thunderbird as my RSS reader (the best RSS reader IMHO, so naturally integrated with email). So it can't be easier to just add that feed to it. I know there is a GMail notification applet for Windows. But I prefer standard browser or email-based approaches by a large margin.

Changing URL without Reloading in Browser

I have thought about changing the URL bar (location) in the browser without reloading so that the currently displayed dynamic page can be recreated later on without the user having to follow the same navigation path to get there. We already use this feature in Yahoo Map and Google Map. This also fits the REST model. I haven't had time to find how to do it (well, because the need has not actually appeared yet). Today this post provided the solution: location.hash. Then the URL becomes the URL that will reproduce the page rather than how we landed here.

A9 OpenSearch

A9's OpenSearch tries to do to search what RSS does for content: aggregation/syndication. You can use it to integrate your own local search results with A9. So when users search on A9, your own custom search results also show up (as a tab for example). Very interesting.

Recombinant Components

Another excellent post from Carlos E. Perez. A lot of food for thought.

NetKernel Revisited

Manageability has a post today about NetKernel which discusses the most interesting ideas of it. It provides me some food for thought in addition to what I discovered upon my first around of minimal investigation. I really wish I had time to dig deep into NetKernel and build an application with it to feel the difference.

Scripting Languages for Java Compared

Comparison here. Rhino (JavaScript on Java) seems to be the overall winner. It was on the top of my list already.

Fail Fast and Debug Fast

Martin Fowler's blog has a great post today on the technique of failing fast. I have the following comments to add:

1. Many times I am split in whether to fail fast or slow in my own coding. Some times I choose fail fast, some times fail slow. Now I think I am always going to choose fail fast. This post has clear arguments for it that I completely agree out of my own experience.
2. I have been trying myself to include as complete information as possible in an error message to help pinpoint the cause, which has proven to be very helpful. The post advocates the same.
3. Most developers think the debugger is our best friend. It's not. Using debugger is a very slow way of finding what's exactly is going on when something goes wrong. The quickest way is a stack with enough information (such as 1) a synopsis of the situation and 2) the values of local variables). The former I always try to include in the exception I raise. The latter cannot be done automatically. If you cannot figure out the cause of the problem by the former, it's when you will need the debugger but then you need to reproduce it.

The quickest way of debugging is always you see the stack and the synopsis, you know immediately what's wrong and you fix it without having to reproduce it in the debugger. Fail Fast is one good technique that helps you do that.

Selenium, UI Test Framework Driven by JavaScript

Selenium is a very interesting UI testing framework using JavaScript to drive the tests.