The browser as a platform

Google certainly know how to draw attention. They've even created a comic for dramatic effect to present their new browser. I remember it took a couple of hours to read it because it was constantly timing out because of the immense buzz-generated load on the servers.

Now after things have calmed down a little, there was a need to have a sober look at Chrome's competitor: Firefox. There was even an article explaining why Mozilla won't change their Gecko rendering engine with Webkit, the engine used in Chrome.

I'm not saying that Firefox is a better browser, but I think ArsTechnica is onto something. In my humble opinion (I hate abbreviations outside of chat), the fact that XUL can make it so much easier to write extensions is a key factor in its success. Even Steve Yegge mentions, half-jokingly, that Firefox is trying to be Emacs, and if it manages to edit files, he would dump Emacs (and if you know Steve Yegge, he lives for Emacs). Extensibility is again a key criteria here.

So now even Google has announced that Crome will support extensions. It will surely need them if it is to compete with Firefox.

I noticed a trend with my personal computing lately. I am using a very thin OS on an USB stick, which is 25-30MB (compressed). A lot of this is due to Firefox, and my externally kept profile is comparable to the OS size- mostly due to addons. Many of these addons are applications in their own right, comfortably using the networking capabilities of Firefox. Here are some of the extensions (some I use, some I don't), which are more like standalone applications than extensions to Firefox' functionality:

• SamePlace
an XMPP instant messenger, which won the Extend Firefox 2 contest

• TwitterFox
a Twitter client

• FireFTP
an FTP client

• mozImage
an image viewer

• Firefly
a file manager

I'm not even mentioning diffent mail checkers, bookmark synchronizers, etc. Is there a tendency towards extensions which are more independent from the functionality of the browser?

Eventually, the browser is just a platform, an OS of sorts, another abstraction layer to make networking transparent for your Web-enabled apps.

Test Driven Development Best Practices for C#

As I have mentioned before, my company has recently started to use the Test Driven Development style of programming. In order to help us write testable code, I came up with this simple list of best practices for making our C# code base more testable. (Some of the links refer to limitations of Rhino Mocks, a mocking framework for C#, but the rules apply more generally as well.)

To maximize the testability of code, follow these rules:

1. Write the test first, then the code. (PRIME DIRECTIVE!)
   Reason: This ensures that you write testable code and that every line of code gets tests written for it.
   
   
2. Design classes using dependency injection.
   
   See: Intro to Rhino Mocks (see "Creating Testable Web Applications" section) and Dependency Injection Article
   Reason: You cannot mock or test what cannot be seen.


3. Separate UI code from its behavior using Model-View-Controller or Model-View-Presenter.
   
   Reason: Allows the business logic to be tested while the parts that can't be tested (the UI) is minimized.
   
   
4. Do not write static methods or classes.
   
   See: Intro to Rhino Mocks (see "Creating Testable Web Applications" section) and Rhino Mocks Limitations
   Reason: Static methods are difficult or impossible to isolate and Rhino Mocks is unable to mock them.
   
   
5. Program off interfaces, not classes.
   
   Reason: Interfaces can be easily mocked using Rhino Mocks and other mocking frameworks.
   
   
6. Isolate external dependencies.
   Reason: Unresolved external dependencies.
   
   
7. Mark as virtual the methods you intend to mock.
   See: Rhino Mocks Limitations
   Reason: Rhino Mocks is unable to mock non-virtual methods.