I didn’t get a chance to blog about the morning keynote by Eric Rudder, but plenty of others have, including Sam, Rocky, and Richard.

I went to hear the Don Box and Steve Schwartz breakout session on Indigo. Don wrote some Indigo code with VB.NET – I have pictures to prove it. Indigo is looking exciting – but during the presentation I became a bit distracted. I realized in a few hours I’d be giving my presentation in the same building as these people - felt a bit humbled - wondered what I had gotten myself into - and went off to do some rehearsing at the hotel.

I think my presentation went well – I had a few good comments afterwards. I guess I’ll know more when the evaluations are tallied. One tip I can heartily recommend is to have the first 5 minutes of a presentation down cold. I rehearsed my first 5 minutes endless times. I could have spoken for the first 5 minutes even if a herd of zebras ridden by scantily clad dancing girls had broken into the room and paraded around. The 5 minutes I spent operating in “automatic mode” gave me time to get used to the microphone, the lights, the audience, and got me through the sometimes awkward introductory phase. After 5 minutes I'm into the meatier part of a presentation and can just start talking about what I know.

At this point I could prepare for tomorrow’s flight by packing, or I can go join the evenings festivities.

Easy choice, this one.

I’m sitting in the keynote at VSLive! by Soma Somasegar (VP, Developer Division, Microsoft).

Interesting statistic: In February of 2002 there were 300 “.NET developer wanted” ads on monster.com, today there are over 10,000. Also interesting: in 2002 many of these ads wanted developers with 3+ years of .NET development experience. Gotta love the people that come up with those types of ads.

The Enterprise Library was plugged during the keynote, but the general thrust of the speech was to promote smart clients. I believe the success of Microsoft’s smart client push hinges entirely on ClickOnce. In my experience it’s often difficult to sell the CTOs and CIOs of the world on applications that requires IT to touch an end user’s machine. Many hold a religious like belief that browser applications are the solution to every problem, or they’ve been burned by deployment scenarios in the past. Microsoft will need to promote ClickOnce success stories to the execs more than the developers.

Yesterday was a travel day and was a little rough. Delayed flights - and I had nothing to eat the entire day. When I hit downtown San Fran I sank an entire fleet of small wooden sushi-carrying ships at restaurant called “Sushi Boat”. Yum.

I’m still poking around the common validation areas of Enterprise Library.

The ArgumentValidation class has 6 public static methods:

public static void CheckForEmptyString(string variable, string variableName) ...
public static void CheckForNullReference(object variable, string variableName) ...
public static void CheckForInvalidNullNameReference(string name, string) ...
public static void CheckForZeroBytes(byte[] bytes, string variableName) ...
public static void CheckExpectedType(object variable, Type type) ...
public static void CheckEnumeration(Type enumType, object variable, string) ... 

CheckForEmpty string has the following implementation:

I like this approach to validation. It feels much cleaner to start a method off with a handful of static method calls to validate arguments compared to starting with a handful of conditional blocks sprinkled with throw statements. The checks are explicit and readable here.

I know some people go nuts defining custom exception hierarchies – I’ve never been a big fan of that approach. The EntLib uses exception classes from the BCL, and keeps the error messages in a resource file and ready for localization. Clean. Flexible.

Most checks are in the form of if (variable == null), although there is at least one place where the code looks like: if (null == variable). I understand the reasons why we did this in C++: it was easy to mix up the assignment operator with the equality operator, but I never cared for expressions in this form and never subscribed to the practice. The C# compilers are better at warning about this subtle error, so I don't plan on ever switching either.

Next up: unit tests in EntLib. I might be looking these over during the trek to VSLive! tomorrow.

I’m not right all of the time – just ask anyone I work with! I’ve been waiting for someone to take me to task over something I’ve written badly, and this evening I was introduced to Dinis Cruiz in his post Some Comments to Misleading and False Information…”.  

Dinis makes a great point – an application domain is not a secure boundary if code is running with full trust. Unfortunately, it seems most ASP.NET shared hosting providers are running ASP.NET code with full trust. I’ve updated my article on application domains to make this point stand out.

When looking at the code for a product or library, I find I’m always drawn to look at the error handling and validation pieces. Since every piece of software has these pieces in one form or another it’s always interesting to compare and contrast the different practices and methodologies used throughout the industry. The newly released Enterprise Library, being from the patterns and practices group, obviously had some thought put into this area, so I was keenly interested to peek at the code.

Here is one of the constructors from the Enterprise Library’s ConfigurationBuilder class:

The code snippet is short, but tells a tale. It tells me I can expect the Enterprise Library to validate explicitly all the parameters I pass.

The code snippet also tells me the team made a decision to let constructors throw exceptions. Deciding to let exceptions escape from a constructor is not an easy decision, particularly in this case because the ConfigurationBuilder class inherits from IDisposable. If the constructor acquires a resource (say, opens a configuration file) and then throws - there is no object reference returned by the constructor for the client to invoke Dispose upon.

On the other hand, covering this edge condition always increases the complexity of the internal implementation, and can also make the public interface harder to use (for instance if the client has to invoke both a constructor and an Initialize method).

It's a tough tradeoff - 'simple elegance' or 'paranoid error handling'. Which do you prefer?

We know HttpApplication events like BeginRequest, AuthorizeRequest, and Error can be extremely useful for implementing functionality like URL re-writing and custom authentication schemes. We can choose to catch these events in one of two places: inside of the methods provided by Global.asax, or inside a custom HttpModule.

I favor the global.asax approach only if the logic inside the events is heavily application specific. In general, an HttpModule is the best approach for a number of reasons.

Firstly, I don’t want global.asax to become a dumping ground for code snippets that need to execute during the request lifetime. Using one or more HttpModules allows me to cleanly factor out responsibilities into distinct classes. A clean design also allows me to place the HttpModule in a class library for reuse across multiple projects.

Secondly, HttpModules are a bit more flexible since I can add them and remove them at runtime with a modification to web.config (or machine.config). A testament to the flexibility and power of an HttpModule is the ValidatePathModule released by Microsoft last year to avoid canonicalization bugs in ASP.NET (note to self: make sure the spell checker doesn’t replace canonicalization with cannibalization). Looking far down the road to the Longhorn timeframe, HttpModules will have even more flexibility in the componentized .NET-aware IIS 7.0. More details on new features in IIS 7.0 next week…

It’s difficult to say there was a beginning, really. Let’s just say it started from a singularity.

There was no space.

No time.

No reports.

In 1961, IBM put forth the first official release of the Report Program Generator (RPG) language. The universe of reporting expanded rapidly. Reams of paper began to spill onto the desks of corporate middle managers across the globe. Neatly formatted tables of numbers exploded in every direction – driven by the deafening cadence of teletype printers. 

March of 1962 is the first known use of the following phrase: “I swear, if the finance people request another report format change, I’m going to roll the paper into a ball and set it on fire in their office.” This oath continues to echo in the halls of business today.

Will it ever end?