Context (Or a little bit of history)

Those who did websites in the beginning of the decade had to work with IE6, Netscape Communicator/Navigator and Opera. Some more browser introduced themselves along the years but most supported different things.

Netscape supported the blink tag (oh how I hate thee). Internet Explorer supported ActiveX and Opera was not popular enough to think about it.

We were in an era where people thought of the web as the blue “E” icon. People were not aware of browsers that much and those who had Netscape probably had it from an AOL promotion.

Since we wanted to display the same thing to every users as much as possible, people either started detecting browsers to clearly say on which browser their website is supported or they just didn’t do any checking at all!

That’s the main reason some internal web applications still display “Works better with IE6”.

Browser Detection

Browsers back then differed a lot from each other. So we had to know if we could use ActiveX or whether we wanted to piss off our users with a blink tag.

The rendering of all this of course was different per browsers.

Here is the script to detect which browsers you are running. I will not copy it here (too large) but you can see that it grows.

Once people knew which browser was running, they knew which feature was supported! So everything was perfect, right?

Not exactly. What if the feature was deprecated in the next version? What if the browser had that functionality disabled by an option? What if a new browser that your script don’t know come in? Why couldn’t he use that feature if he supported it?

This caused a lot of problem. Mostly because detecting a browser didn’t guarantee you anything beside that the user was sending you a UserAgent string that pleased you.

The browser detection was broken from the start and something had to be done to detect whether something was going to work or not. Irrespectively of the browser.

Feature Detection

Then came feature detection. The first real push for it was by Mr. John Resig himself when he posted “Future-Proofing JavaScript Libraries”. Today, jQuery allow developers to access a ton of features that would have taken individual developers months to develop and maintain. jQuery allows you to implement binding of events without knowing whether you should use attachEvent or addEventListener.

If you have the time, go see the development version of jQuery. It’s commented and will allow you to find their hacks to offer everyone the same functionalities. This allows you to manipulate the browser without having to know which one it is. It allows you to do Ajax in IE6 with ActiveX or with IE7 (or higher) with the proper object without knowing if your browser supports ActiveX.

Today, assuming everyone use a frameworks which smooth the basic differences between the browsers, the only thing you might be checking nowadays is HTML5 feature compatibility.

Introducing Modernizr

Modernizr is a library which does Feature detection and that can be tailor cut to your needs. In its complete version, it allows you to detect easily the following features (not a complete list):

• SVG/Canvas support
• Web sockets
• Web SQL Database
• Web workers
• HTML5 Audio/video
• Hash Change event
• WebGL
• Geolocation
• Much more…

Modernizr once referenced in your webpage allow you to tailor your own code to know if you should gracefully degrade some feature or not.

Here is an example on how you could use Modernizr when implementing geolocation in your application:

Modernizr.load({
  test: Modernizr.geolocation,
  yep : 'geolocation.js',
  nope: 'no-geolocation.js'
});

This simple code allows you to load a different JavaScript based upon the feature of a browser.

Modernizr offer support for IE6+, FireFox 3.5+, Opera 9.6+, Safari 2+, Chrome, iOS, Android, etc.

Conclusion

With the current quantity of browsers that supports different functionalities at various levels, we should not be implementing for specific browsers but rather for specific features. We would want those feature implemented in all browsers but with the fragmentation of the browser market, it’s just not going to happen soon.

So please, no more “This site works better with [INSERT BROWSER]”. Target a feature, test for it, and offer different (or no) implementation if the feature is not available. This will make your code cleaner and more efficient.

So stop the Browser detection madness and embrace the feature detection.

It might sound counter intuitive to some but it makes sense. So be ready for the future.

If you are using HTML5, use feature detection rather than browser detection.

Who knows about Aspect-Oriented Programming (AOP)? Common! Don't be shy! Ok, now lower your hands. My prediction is that a lot of you didn't raise their hands. So let's resume what AOP is:

Aspect-oriented programming is a programming paradigm that increases modularity by enabling improved separation of concerns. This entails breaking down a program into distinct parts (so called concerns, cohesive areas of functionality). [...]

So what does it mean truly? Well, it's a way to declare part of your software (methods, classes, assembly) to have a "concern" applied to them. What is a concern? Logging is one. Exception handling is another one. But... let's go wild... what about caching, impersonation, validation (null check, bound check), are all concerns. Do you mix them with your code? Right now... you are forced to do it.

The state of current AOP

Alright for those who raised their hands earlier, what are you using for your AOP concerns? If you are using patterns and practices Policy Injection module, well, you are probably not happy. First, all your objects need to be constructed by an object builder and need to inherit from MarshalByRefObject or implement an interface.

This is not the best way but it's been done in the "proper" way without hack.

What is PostSharp bringing?

PostSharp might be a "hack" if think so. Of course, it does require you to have it installed on your machine while compiling for it to work. But... what does PostSharp does exactly? It does what every AOP should do. Inject the code before and after the matching method at compile time. Not just PostSharp methods but any methods that is inherited from the base class PostSharp is ofering you. Imagine what you could do if you could tell the compiler to inject ANY code before/after your method on ANY code you compile. Think of the possibilities. I'll give you 2 minutes for all this information to sink in... (waiting)... got it? Start to see the possibility? All you need to do is put attributes on your methods/attributes like this:

[NotNullOrEmpty]
        public string Name { get; set; }

        [Minimum(0)]
        public int Age { get; set; }

Now look at that code and ask yourself what it do exactly. Shouldn't be hard. The properties won't allow any number under "0" to be inserted inside "Age" and "Name" will not allow any null or empty string. If there is any code that try to do that, it will throw a ValidationException.

Wanna try it?

Go download PostSharp immediatly and it's little friend ValidationAspects on Codeplex. After you have tried, try to build your own and start cleaning your code to achieve better readability.

And yes... both are Open-Source and can be used at no fee anywhere in your company.

Suggestion to CLR Team

Now, PostSharp force us to have it installed with the MSI for it to work because it needs to install a Post-Compile code injector (like some obfuscation tools). What would be really nice, is to be able to do the same thing built-in with the compiler. The compiler is already checking for some attribute already... I would love to have this "internal working" exposed to the public so that we can build better tools and, more importantly, better code.

UPDATE: I want to mention that PostSharp is NOT open-source. However is free unless you need to package it with your tool.

This must have been the most enlightening book I've ever read. It's filled with "evident" knowledge. Of course, some of them you have never thought about... but some that you just can't avoid nodding in approval.

As everyone know, I'm a .NET Developer and Uncle Bob is a Java developer (not exactly but the book have code in Java). There is some recommendation in the books that are targeted at Java developer and that don't apply to .NET.

So? If I had to tell what the book is about, what should I say?

I would say:

• Humans are good at mixing abstraction level
• Keep the variable/class/function clear and concise
• Commenting must be done with care otherwise it just clutter the code
• Refactor, refactor, refactor. A code base is never perfect but if you follow the Boy scout rule, the code base will always be better in the end
• Code should always have test and high coverage

Am I hitting the bulls eye here? What do you think?

Alright, my previous post was lot of ranting... I have to make it up. I hate ranting because it never bring any solutions, only problems. When someone is building a software, bugs will happen as true as the sun rise everyday. Sometimes it will be simple change request but there will be bug that are going to be logged in.

It's important that the user of the software has an easy way of reporting the bug. Depending on the kind of software you are building, there will be different kind of way to actually report a bug. There is 4 main kind of software that programmer works on. Open-source software, product, internal software and public web sites. They all require different kind of bug reporting due to their reach and needs.

Open-source software

Open-source software are normally better with 2 kind of bug reporting. The first is an actual bug reporting tool that is linked to a source control software like Google Code or Codeplex. The other kind is a discussion list/forum. The first one is to actually report bug and the second one refer more to actual support by the community. It might sound confusing but they both highlight bugs as the consumer have a way to contact the project leader or contributors to the project.

Examples includes: Firefox, Moq, BlogEngine.NET

Product

Product are either websites or actual executables that are sold to consumers. Since they don't display the source and especially not their bug lists, they need a way for the consumer to actually report their bugs. Since products are normally backed by a company with staffing, bug reporting can go from the simplest form to a complicated bug submission tools. Sometimes, the integration of the bug report are even more advanced. Some software even catch crash in the software and send them when the software can successfully restart. Whatever the way the bugs are caught, company should always offer a free way of sending bug report even if it's through a support@example.com kind of email.

Examples include: FogBugz, Copilot, StackOverflow, Apple Mac OSX

Internal Software

Those are whole different kind of game. Those are software that you are hired to build for another company or that you build for your own company. Those kind of software mostly stay internal and are never going to be released into the wild. Those includes, CMS, ERP, wiki, etc. Those are normally what most developer will face. Direct contact with the user about the bugs, Team System for the bug reporting (or any other kind of bug reporting software used internally). The bug list is internal and new bugs are often reported by a direct email. phone call or a conversation with the program manager/architect/team lead/developer.

Websites

Websites normally don't have specific bug reporting system. Most websites works or the user leaves. The main bug reporting system in those system is heavy logging for any errors that happens and IIS logs for anything that doesn't go through the .NET runtime. However, some websites that offer service might offer some way to report bugs but they are  the exception... not the rule.

Examples include: StackOverflow

Conclusion

Bug reporting is not what you want your user to use (unless you are selling bug reporting software). However, when a user is seeking to you to report a bug, you must offer them a painless process to report bugs. Without this, you will only be able to find out bugs from other forums where people are complaining(if you have a large user base) but mostly, you will never get any notice that the software doesn't work as planned.

So please... if I want to report a bug... make my life easy and make it a process that don't take more than a few clicks.

Thanks

A month or two ago I had to built a component that had to analyse a string a return some information out of it. The best result for this was a Regular Expression and I was sure. So I started writing what kind of input would be valid and which one should not be allowed.

When I started writing this code, I already read many blog posts about it and wanted to give it a try. Since I wanted a simple scenario which would easily be applied, when I had to parse this string I knew I had a simple problem to which I could apply it.

If anyone has ever worked with regular expressions, it is widely known that it's easy to make something match. However, it's really hard to make it match what you want and not what you don't want. For proof of that, try seeing how many regular expression there is to parse a phone number. The non-matches is as important as the matches.

So I started a test project and added my first test. The test was to test the perfect scenario. Of course the test didn't even compiled. I then proceeded to create the missing classes and made the test compile. Of course, all the class had the following inside them:

throw new NotImplementedException();

This ensured that the test "went red". I then proceeded to implement the minimum necessary to make it pass and make it "go green". And I kept on rolling until it worked in all my specified cases. Sometimes, previous tests went and failed. Sometimes, everything stayed green but I kept on going.

For experienced TDD-er it's common and normal. But for me, it was weird. I made sure to follow EXACTLY what it said. When it said "minimum necessary to make it pass", I made sure that I returned a constant if I could or proceeded to create/modify the regular expression as needed. And as I kept increasing my amount of test, the constant all went away, the regular expression got more precise and every time that I broke a test I came back to fix it. It's a weird feeling but when I gave my class for usage, it was working as perfectly as it could.

So why the ruckus? Because since I wrote this piece of code, I haven't seen one bug report. The code is perfect for what it is doing. When a bug will come my way, I'll try the TDD-er way of doing thing. Add a test that reproduce the bug and fix my code to make sure it works on all test.

Result of everything? One bug ridden class, 20 something tests and one developer who learned the essence of TDD.

I would love to get my teeth on more complex code now.