I've never been much of an early adopter, so now that Silverlight is dead and cold and has been for a while, it seems appropriate for me to blog about it. More specifically, I'd like to write about the chore that is INotifyPropertyChanged and how to make practically all the grunt work go away.

(Actually, I'm not sure that Silverlight is completely dead yet. It may be that Microsoft won't be pumping much fresh blood into its veins, but that's not quite the same thing as being dead. A technology isn't dead as long as there's a market for it and all that jazz. Assuming that there are some kinds of applications (such as rich line-of-business applications) that are easier to build with Silverlight than HTML5 given the toolsets that are available, I think we'll find that Silverlight hangs around to haunt us for quite a while. But that's sort of a side issue. It doesn't really matter if Silverlight is dead or not, the issue of tackling INotifyPropertyChanged is interesting in and of itself.)

So INotifyPropertyChanged is the hoop you have to jump through to enable Silverlight views to update themselves as the view models they bind to change. It's hard to envision not wanting the view to update when the view model changes. So typically you'll want all the properties you bind to, to automatically cause the view to refresh itself. The problem is that this doesn't happen out of the box. Instead, there's this cumbersome and tiresome ritual you have to go through where you implement INotifyPropertyChanged, and have all the setters in your view model holler "hey, I've changed" by firing the PropertyChanged event. Brains need not apply to do this kind of work; it's just mind-numbing, repetitive plumbing code. It would be much nicer if the framework would just be intelligent enough to provide the necessary notifications all by itself. Unfortunately, that's not the case.

Solution: IL weaving

Silver.Needle is the name I use for some code I wrote to do fix that. The basic idea is to use IL manipulation to automatically turn the plain vanilla .NET properties on your view models into view-update-triggering properties with the boring but necessary plumbing just magically *there*. Look ma, no hands!

If you're unfamiliar with IL manipulation, you might assume that it's hard to do because it's sort of low-level and therefore all voodooy and scary. But you'd be wrong. It might have been, without proper tools. Enter the star of this blog post: Mono.Cecil. Mono.Cecil is a library for IL manipulation written by Jb Evain. It is so powerful, it's almost indecent: you get the feeling that IL manipulation shouldn't be that easy. But it is, it really is. It's a walk in the park. And the power trip you get is unbelievable.

Of course, since I rarely have original thoughts, Silver.Needle isn't unique. You'll find that Justin Angel described a very similar approach on his blog, more than two years ago. He uses Mono.Cecil too. So do the Kind of Magic and NotifyPropertyWeaver projects, which might be worth checking out if you actually wanted to use something like this in your project. But as always, it's much more fun and educational to roll your own!

Disclaimer: it is fairly easy to shoot yourself in the foot when you're meddling with IL directly. I accept no liability if you try to run any of the code included in this blog post and end up injecting IL into your cat, or causing your boss to fail spectacularly at runtime, or encountering any other unfortunate and grotesque mishap as a result of doing so. You have been warned.

Viewable properties

To do the IL manipulation, we need a way to distinguish between properties to tamper with and properties to leave alone. We'll refer to the former as viewable properties because, you know, they're able to work with a view?

Silver.Needle gives you two options for indicating that a property is viewable. The first option is to opt-in for individual properties on a class, by annotating each property with the Viewable attribute. The second option is to annotate the entire class as Viewable, and optionally opt-out for individual properties on that class using the Opaque attribute. In either case, the class is considered to be a "view model", with one or more viewable properties that notify the view of any changes.

So the task solved by Silver.Needle is to perform the IL voodoo necessary to make sure that the output of the C# compiler of this pretty lean and neato code:

...is the same as the output generated directly when compiling this cumbersome and clumsy mess:

We start by using Mono.Cecil to look for types that contain such properties. It's a simple matter of 1) loading the assembly with Mono.Cecil, 2) iterating over the types in the assembly and 3) iterating over the properties defined for each type. Of course, if we find one or more "view model" types with properties that should perform view notification, we must proceed to do the necessary IL manipulation and write the changed assembly to disk afterwards. The meat of the matter is in scanning an individual type and doing the IL manipulation. We'll come to that shortly. The surrounding bureaucracy is handled by the NotificationTamperer class.

There's not much going on here worth commenting upon, it's just the stuff outlined above. I guess the only thing worth noting is that we need to add a reference to the Silverlight assemblies, so that Mono.Cecil can resolve type dependencies as necessary later on. (For simplicity, I just hard-coded the path to the assemblies on my system. Did I mention it's not quite ready for the enterprise yet?)

The interesting stuff happens in the TypeTamperer. You'll notice that the TypeTamperer works on a single type, which is passed in to the constructor. This is the type that may or may not contain viewable properites, and may or may not end up being tampered with. The type is represented by a Mono.Cecil TypeDefinition, which has collections for interfaces, methods, fields, events and so forth.

The TypeTamperer does two things. First, it looks for any viewable properties. Second, if any viewable properties were found, it ensures that the type in question implements the INotifyPropertyChanged interface, and that the viewable properties participate in the notification mechanism by raising the PropertyChanged event as appropriate.

Let's see how the identification happens:

As you can see, the code is very straight-forward. We just make sure that the type we're inspecting is a class (as opposed to an interface), and look for viewable properties. If we find a viewable property, the HandlePropertyToNotify method is called. We'll look at that method in detail later on. For now though, we'll just note that the property will end up in an IDictionary named _map, so that the ReallyTamperWith method is called, triggering the IL manipulation.

For each of the view model types, we need to make sure that the type implements INotifyPropertyChanged. From an IL manipulation point of view, this entails three things:

• Adding interface declaration as needed.
• Adding event declaration as needed.
• Adding event trigger method as needed.

Silver.Needle tries to play nicely with a complete or partial hand-written implementation of INotifyPropertyChanged. It's not too hard to do, the main complicating matter being that we need to consider inheritance. The type might inherit from another type (say, ViewModelBase) that implements the interface. Obviously, we shouldn't do anything in that case. We should only inject implementation code for types that do not already implement the interface, either directly or in a base type. To do this, we need to walk the inheritance chain up to System.Object before we can conclude that the interface is indeed missing and proceed to inject code for the implementation.

This is still pretty self-explanatory. The most interesting method is TypeImplementsInterface, which calls itself recursively to climb up the inheritance ladder until it either finds a type that implements INotifyPropertyChanged or a type whose base type is null (that would be System.Object).

Implementing the interface

Injecting code to implement the interface consists of two parts, just as if you were implementing the interface by writing source code by hand: 1) injecting the declaration of the interface, and 2) injecting the code to fulfil the contract defined by the interface, that is, the declaration of the PropertyChanged event handler.

The code to add the interface declaration is utterly trivial: you just add the appropriate type to the TypeDefinition's Interfaces collection. You get a first indication of the power of Mono.Cecil right there. You do need to obtain the proper TypeReference (another Mono.Cecil type) though. I've created a helper class to make this as simple as I could as well. The code looks like this:

Mono.Cecil comes with a built-in TypeSystem type that contains TypeReference objects for the most common types, such as Object and String. For other types, though, you need to use Mono.Cecil's assembly resolver to get the appropriate TypeReference objects. For convenience, TypeResolver defines properties with TypeReference objects for all the types used by TypeTamperer.

With the interface declaration in place, we need to provide an implementation (otherwise, we get nasty runtime exceptions).

Herein lies a potential hickup which might lead to problems in case the implementer is exceedingly stupid, though. Since Silver.Needle is a proof-of-concept rather than a super-robust enterprise tool, I don't worry too much about such edge cases. Nevertheless, I try to play nice where I can (and if it's easy to do), so here goes: The issue is that the view model type might already have a member of some sort named PropertyChanged, even though the type itself doesn't inherit from INotifyPropertyChanged. If it actually is an event handler such as defined by INotifyPropertyChanged, everything is fine (I just need to make sure that I don't add it.) The real issue if there is some other member named PropertyChanged, say, a property or a method. I can't imagine why you'd want to do such a thing, but of course there's no stopping the inventiveness of the sufficiently stupid programmer. To avoid producing a weird assembly that will fail dramatically during runtime, Silver.Needle will discover the presence of a malplaced, ill-typed PropertyChanged and give up, leaving the type untampered (and hence not implementing INotifyPropertyChanged).

Adding the event handler is a bit more work than you might expect. If you inspect the IL, it becomes abundantly clear that C# provides a good spoonful of syntactic sugar for events. At the IL level, you'll find that the simple event declaration expands to this:

• A field for the event handler.
• An event, which hooks up the field with add and remove methods.
• Implementation for the add and remove methods.

It's quite a bit of IL:

The bad news is that it's up to us to inject all that goo into our type. The good news is that Mono.Cecil makes it fairly easy to do. We'll get right to it:

Here we add the field for the event handler, and we create an event which hooks up to two methods for adding and removing event handlers, respectively. We're still not done, though - in fact, the bulk of the nitty gritty work remains.

That bulk is the implementation of the add and remove methods. If you examine the IL, you'll see that the implementations are virtually identical, except for a single method call in the middle somewhere (add calls a method called Combine, remove calls Remove). We can abstract that out, like so:

It looks a little bit icky at first glance, but it's actually quite straightforward. You just need to accurately and painstakingly reconstruct the IL statement by statement. As you can see, I've left the original IL in the source code as comments, to make it clear what we're trying to reproduce. It takes patience more than brains.

The final piece of the implementation puzzle is to implement a method for firing the event. Again, Silver.Needle tries to play along with any hand-written code you have. So if you have implemented a method so-and-so to do view notification, it's quite likely that Silver.Needle will discover it and use it. Basically it will scan all methods in the inheritance chain for your view model, and assume that a method which accepts a single string parameter, returns void and calls PropertyChangedEventHandler.Invoke somewhere in the method body is indeed a notification method.

Should Silver.Needle fail to identify an existing notification method, though, there is no problem. After all, it's perfectly OK to have more than one method that can be used to fire the event. Hence if no notification method is found, one is injected. No sleep lost.

In case no existing notification method was found, we need to provide one. We're getting used to this kind of code by now:

This produces IL for a NotifyViewableProperty method just like the one we wrote in C# in the "hand-implemented" PersonViewModel above.

Injecting notification

With the interface implementation and notification method in place, we finally come to the fun part - injecting the property notification itself!

Unless you're the kind of person who use ILSpy or ILDasm regularly, you might wonder if and how it will work with auto-properties - properties where you don't actually provide any body for the getters and setters. Well, it doesn't matter. Auto-properties are a C# feature, they don't exist in IL. So you'll find there's a backing field there (albeit with a weird name) that the C# compiler conjured up for you. It's just syntactic sugar to reduce typing.

What about get-only properties? That is, properties that have getters but no setters? Well, first of all, can they change? Even if they're get-only? Sure they can. Say you have a property which derives its value from another property. For instance, you might have an Age property which depends upon a BirthDate property, like so:

In the (admittedly unlikely) scenario that the BirthDate changes, the Age will change too. And if Age is a property on a view model that a view will bind to, you'll want any display of Age to update itself automatically whenever BirthDate changes. How can we do that? Well, if we implemented this by hand, we could add a notification call in BirthDate's setter to say that Age changed.

It feels a little iffy, since it sort of goes the wrong way - the observed knowing about the observer rather than the other way around. But that's how you'd do it.

Silver.Needle does the same thing for you automatically. That is, for get-only properties, Silver.Needle will inspect the getter to find any calls to getters on other properties on the same object instance. If those properties turn out to have setters, notifications to update the get-only property will be injected there. If those properties are get-only too, the process repeats itself recursively. So you could have chains of properties that depend on properties that depend on properties etc.

To do this correctly, the injection process has two steps. First, we identify which properties depend on which, second, we do the actual IL manipulation to insert the notification calls.

So, first we identify dependencies between properties. In the normal case of a property with a setter of its own, the property will simply depend on itself. (Of course, there might be other properties that depend on it as well.) So for each property with a setter, we build a list of dependent properties - that is, properties that we need to inject notification calls for. Note that while we only do notification for properties tagged as Viewable, we might inject notification calls into the setters of any property on the view model, Viewable or not. (In the example above, you'll notice that BirthDate is not, in fact, tagged Viewable. When the setter is called, it will announce that Age changed, but not itself!)

The code to register the dependencies between properties is as follows:

So you can see that it's a recursive process to walk the dependency graph for a get-only property. You'll notice that there is some code there to recognize that we've seen a certain property before, to avoid infinite loops when walking the graph. Of course, it might happen that we don't find any setters to inject notification into. For instance, it may turn out that a viewable property actually depends on constant values only. In that case, Silver.Needle will simply give up, since there is no place to inject the notification.

When we have the complete list of properties and dependant properties, we can do the actual IL manipulation. That is, for each affecting property, we can inject notifications for all affected properties.

There are two possible strategies for the injection itself: simple and sophisticated. The simple strategy employed by Silver.Needle is to do notification regardless of whether any state change occurs as a result of calling the property setter. For instance, you might have some guard clause deciding whether or not to actually update the field backing the property - a conditional setter if you will. Perhaps you want to write to the backing field only when the value has actually changed. Silver.Needle doesn't care about that. If the setter is called the view is notified. I believe this makes sense, since the setter is the abstraction boundary for the operation you're performing, not whatever backing field you may or may not write to. Also, I reckon that it doesn't *hurt* much to do a couple of superfluous view refreshes.

It would be entirely possible to do something a little bit more sophisticated, though - I just don't think it's worth the effort (plus it violates encapsulation, doesn't it?). If we wanted to, we could use a simple program analysis to distinguish between paths that may or may not result in the view model altering state. Technically, we could take the presence of a stfld IL instruction (which stores a value to a field) as evidence for state change. We could even throw in a little bit of data flow analysis to see if the value passed to the setter was actually on the stack when to the stfld was executed. In that case, we'd interpret "property change" to mean "some field acquires the value passed to the setter", which may or may not seem right to you. So it could be done, within reason.

Notice, though, the appeal to reason. It's easy to come up with a setter which results in an observable state change without ever calling stfld. For instance, you could push the value onto a stack instead of storing it in a field, and have the getter return the top element of the stack. Sort of contrived, but it could be done. Or you could pass the value to some method, which may or may not store it somewhere. So you see, it's hard to do properly in the general case. Hence Silver.Needle keeps things simple, and says that the view should be notified of property change whenever the setter is called. That way, we might do a couple of superfluous notifications, but at least we don't miss any.

Now we just need to figure out where to inject the notification calls. Obviously it needs to be the last thing you do in the setter, to ensure that any state change has actually occurred before we do the notification (otherwise we'd refresh the view to show a stale property value!). That's easy if you have a single return point from your setter, somewhat harder if there are are several.

You could of course inject notification calls before each return point. That would give the correct semantics but is a bit brutish and not particularly elegant. Instead, Silver.Needle will essentially perform an extract method refactoring if there is more than one return point. The original body of the property setter is moved to a new method with a name derived from the property name. The property setter is then given a new body, consisting of a call to the new method, followed by necessary notification calls. Nice and tidy.

A third alternative would be to wrap the body of the setter in a try block and perform notification in a finally block. Yes, that would mean that notifications would be given even if an exception is thrown during the execution of the setter. Would that be a problem? No. Why not? Because you shouldn't throw exceptions in your setters. Again, if you have complex logic in the setters of your view models, I have a meme for you: "View models, you're doing it wrong".

So, implementation-wise, we need to support two scenarios: with or without refactoring. In either case, we end up with a setter that has a single return point preceeded by notification calls. As usual, it's pretty straight-forward to do the necessary alternations to the body of the setter using Mono.Cecil. Here's the code:

The code isn't too complicated. The MethodDefinition passed to InjectionNotification is the setter method for the property, and propNames contains the names of properties to notify change for when the setter is called. In case of multiple return points from the setter, we perform a bit of crude surgery to separate the method body from the method declaration. We provide a new method definition for the body, with a name derived from the name of the property. While in Dr Frankenstein mode, we proceed to assemble a new method body for the setter. That body consists of three instructions: push the this reference onto the stack, push the value passed to the setter onto the stack, and invoke the new method we just created out of the original method body.

Now we know that the setter has a single return point, and we can inject the notification calls. We just need to loop over the properties to notify, and inject a trio of 1) push this, 2) push property name and 3) invoke notification method for each.

And that's it, really. We're done. Mission accomplished, view model complete.

Of course, to make things practical, you're gonna need a build task and a Visual Studio template as well. I'll get to that some day.

Consider the following problem:

The field vole can have up to 18 litters (batches of offspring) each year, each litter contains up to 8 children. The newborn voles may have offspring of their own after 25 days. How many field voles can a family grow to during the course of a year?

Of course, unless you're a native English speaker, you might wonder what the heck a field vole is. I know I did.

This a field vole:

I'm not really sure if it's technically a mouse or just a really close relative, but for all our intents and purposes, it sure is. A small, very reproductive mouse.

So, do you have an answer to the problem? No?

To provide a bit of background: this problem was presented to a class of fifth graders. Does that motivate you? Do you have an answer now?

If you do, that's great, but if you don't, you probably have a whole litter of questions instead. That's OK too.

You see, the father of one of those fifth graders is a friend of mine. He emailed this problem to a rather eclectic group of people (including some with PhDs in matematics). Between us, we came up with a list of questions including these:

• What is the distribution of sexes among the voles?
• What is the average number of voles per litter? And the distribution?
• How many voles are gay?
• How many voles die before they reach a fertile age?
• How many voles are celibate? Alternatively, how many voles prefer to live without offspring? (Given that voles don't use prophylactics, these questions yield equivalent results.)
• Will ugly voles get laid?
• What is the cheese supply like?
• Are there cats in the vicinity?

And so on and so forth. Luckily, the fifth grade teacher was able to come up with some constraints for us. Of course, they were rather arbitrary, but perhaps not completely unreasonable:

Each litter contains exactly 8 new voles, 4 females and 4 males. No voles die during the year in question.

That's great! Given these constraints, we can get to work on a solution.

First, we make the arbitrary choice of associating the offspring with the female voles only. The male voles will be counted as having no offspring at all. While perhaps a bit old fashioned, this greatly simplifies our task. (Of course, we could just as well have opted for the opposite.)

Now we just need to count the offspring of female voles. Since we know that the offspring function is purely deterministic, this isn't too hard. Given a certain number of days available for reproduction, a female vole we will always yield the same number of offspring. (As if women were idempotent!)

To calculate an answer, we can write a small program.

The F method calculates the total number of offspring for a female vole as a function of how many days it has lived. If you call F with an input of 365 days, you'll find that the answer is 55,784,398,225. That's a lot of voles.

How does the algorithm work, though? Well, we assume that we start with a single newborn female vole that has 365 days available to produce offspring (with the first litter arriving after 25 days). Then the number of offspring is given by:

F(365) = 1 + 4 * F(340) + 4 + 4 * F(320) + 4 + ... + 4 * F(0) + 4

Of course, you can factor out all the 4's, like so:

F(365) = 1 + 4 * (F(340) + 1 + F(320 + 1 + ... + F(0) + 1)

And that's pretty much what the code does. In addition, it uses a cache, so that it won't have to calculate a value twice.

As you might imagine, the kids weren't really expected to come up with a solution to this problem. Instead, they were supposed to think about recursion and reasonable constraints. Which are noble things to teach kids, for sure. More of that, please.

Nevertheless, I still think the problem kinda sucked. Even if the kids were able to come up with reasonable constraints, they wouldn't have the tools at hand to produce an answer. Pretty demotivating, I'd say.

My friend's son was unfazed and cool about it, though. In fact, he was content and confident that the tree structure he started drawing would yield the correct answer, if only he had a sufficiently large piece of paper. How cool is that?

I mentioned cURL in passing in the last blog post. In case you haven't heard of it: it is a super-useful tool you can use to issue HTTP requests from the command line (and a whole slew of other stuff). Just thought I'd jot down a quick note on how to use it to play around with the pix-it HTTP handler.

It's a breeze, really. So effortless! If you've installed cURL and vim (and added them to your PATH), you can do the whole command-line ninja thing and never take your fingers off the keyboard. Fiddler is a bit more -uh- fiddly for in that respect.

Here's the work flow in it's entirety. Repeat as necessary.

The previous blog post introduced PixItHandler, a custom HTTP handler for ASP.NET. The handler responds to HTTP POST requests containing a JSON description of a 8-bit style image with an actual PNG image. Provided you know the expected JSON format, it's pretty easy to use a tool like Fiddler (or cURL for that matter) to generate renderings of your favorite retro game characters. However, while you might (and should) find those tools on the machine of a web developer, they have somewhat limited penetration among more conventional users. Web browsers have better reach, if you will.

So a challenge remains before the PixItHandler is ready to take over the world. Say we wanted to include a pix-it image in a regular HTML page? That is, we would like the user to make the request from a plain ol' web browser, and use it to display the resulting image to the user. We can't just use an HTML img tag as we normally would, since it issues an HTTP GET request for the resource specified in the src attribute. Moreover, we lack a way of including the JSON payload with the request. We can use another approach though. Using JQuery, we can issue the appropriate POST request with the JSON payload to the HTTP handler. So that means we're halfway there.

We're not quite done, though. We still need to figure out what to do with the response. The HTTP response from the PixItHandler is a binary file - it's not something you can easily inject into the DOM for rendering. So that's our next challenge.

Luckily, a little-known HTML feature called the data URI scheme comes to the rescue! Basically, data URIs allow you to jam a blob of binary data representing a resource in where you'd normally put the URI for that resource. So in our case, we can use a data URI in the src attribute of our img tag. To do so, we must base64-encode the PNG image and prefix it with some appropriate incantations identifying the text string as a data URI. Base64-encoding is straightforward to do, and there are JavaScript implementations you could steal right off the Internet. Good stuff.

You might think I'd declare victory at this point, but there's one more obstacle in our way. Unfortunately, it seems that JQuery isn't entirely happy funnelling the binary response through to us. Loading up binary data isn't really the scenario the XMLHttpRequest object was designed to support, and so different browsers may or may not allow this to proceed smoothly. I haven't really gone down to the bottom of the rabbit hole on this issue, because there's a much simpler solution available: do the base64-encoding server side and pass the image data as text. So I've written a BixItHandler which is almost identical to the PixItHandler, except it base64-encodes the result before writing it to the response stream:

Problem solved! Now we can easily create an HTML page with some JQuery to showcase our pix-it images. Here's one way to do it:

Not much going on in the HTML file, as you can see. Three innocuous-looking div's that aren't even visible yet, that's all. As you might imagine, they are just placeholders that our JavaScript code can work with. That's where pixit.js comes in:

As you can see, we define the basic outline for a space invader as static JSON data in the script. For each of the div tags, we hijack the color code inside and use that to override the color for the space invader. Then we issue the POST request to our brand new BixItHandler, which has been configured to capture requests aimed at the bix.it virtual resource. The response is a base64-encoded PNG file, which we then insert into the src attribute of an img element that we conjure up on the fly.

And how does it look?

So-called custom HTTP handlers can be incredibly useful. It's almost laughably easy to write your own handler, and it enables some scenarios that might be difficult, cumbersome or inelegant to support otherwise. It's definitely something you'll want in your repertoire if you're an ASP.NET programmer.

In essence, what a custom HTTP handler gives you is the ability to respond to an HTTP request by creating arbitrary content on the fly and have it pushed out to the client making the request. This content could be any type of file you like. In theory it could be HTML for the browser to render, but it typically won't be (you have regular ASP.NET pages for that, remember?). Rather, you'll have some way of magically conjuring up some binary artefact, such as an image or a PDF document. You could take various kinds of input to your spell, such as data submitted with the request, data from a database, the phase of the moon or what have you.

I'm sure you can imagine all kinds of useful things you might do with a custom HTTP handler. On a recent project, I used it to generate a so-called bullet graph to represent the state of a project. If you use ASP.NET's chart control, you'll notice that it too is built around a custom HTTP handler. Any time you need a graphical representation that changes over time, you should think of writing a custom HTTP handler to do the job.

Of course, you can use custom HTTP handlers to do rather quirky things as well, just for kicks. Which brings us to the meat of this blog post.

This particular HTTP handler is inspired by the phenomenon known as Post-It War, show-casing post-it note renderings of images (often retro game characters). Unfortunately, I'm too lazy to create actual, physical post-it figures, so I figured I'd let the ASP.NET pipeline do the heavy lifting for me. I am therefore happy to present you with a custom HTTP handler to produce 8-bit-style images, using a simple JSON interface. Bet you didn't know you needed that.

The basic idea is for the user to POST a description of the image as JSON, and have the HTTP handler turn it into an actual image. Turns out it's really easy to do.

We'll let the user specify the number of coarse-grained "pixels" in two dimensions, as well as the size of the "pixels". Based on this, the HTTP handler lays out a grid constituting the image. By default, all pixels are transparent, except those that are explicitly associated with a color. For each color, we indicate coordinates for the corresponding thus-colored pixels within the grid.

So, say we wanted to draw something simple, like the canonical space invader. We'll draw a grid by hand, and fill in pixels as appropriate. A thirteen by ten pixel grid will do nicely.

We can glean the appropriate pixels to color black from the grid, which makes it rather easy to translate into a suitable JSON file. The result might be something like:

Is this the optimal textual format for describing a retro-style coarse-pixeled image? Of course not, I made it up in ten seconds (about the same time Brendan Eich spent designing and implementing JavaScript, or so I hear). Is it good enough for this blog post? Aaaabsolutely. But the proof of the pudding is in the eating. So let's eat!

We've established that the user will be posting data like this to our custom HTTP handler; our task is to translate it into an image and feed it into the response stream. Most of this work can be done without considering the context of an HTTP handler at all. The HTTP handler is just there to expose the functionality over the web, really. It's almost like a web service.

Unfortunately, getting the JSON from the POST request is more cumbersome than it should be. I had to reach for the request's input stream in order to get to the data. Once you get the JSON, however, the rest is smooth sailing.

I use Json.NET's useful Linq-to-JSON capability to coerce the JSON into a .NET object, which I feed to the image-producing method. The Linq-to-JSON code is pretty simple, once you get used to the API:

You might be able to do this even simpler by using Json.NET's deserialization support, but this works for me. There's a little bit of fiddling in order to allow for the optional specification of a background color for the image.

The .NET type looks like this:

The Pixel type simply represents an (X, Y) coordinate in the grid:

Creating the image is really, really simple. We start with a blank slate that's either transparent or has the specified background color, and then we add colored squares to it as appropriate. Here's how I do it:

That's just about all there is to it. The entire HTTP handler looks like this:

Warning: I take it for granted that you won't put code this naïve into production, opening yourself up to denial-of-service attacks and what have you. It takes CPU and memory to produce images, you know.

Of course, as always when using a custom HTTP handler, we must add the handler to web.config. Like so:

Note that we restrict the HTTP verb to POST, since we need the JSON data to produce the image.

Now that we have the HTTP handler in place, we can try generating some images. A simple way to invoke the handler is to use Fiddler. Fiddler makes it very easy to build your own raw HTTP request, including a JSON payload. Just what we need. Let's create a space invader!

All we need to do is add the appropriate headers and the JSON payload.

The image only includes the headers for the request, but Fiddler also has a text area for the request body, which is where you'll stick the JSON data.

The PNG-file returned by our HTTP handler looks like this:

Nice!

Of course, we could create more elaborate images, using more pixels and more colors. For instance, the following JSON could be used to evoke the memory of a certain anti-hero named Larry, hailing from the hey-day of Sierra On-Line.

The result?

You might say "that's a big file to create a small image", but that would be neglecting the greatness of the Laffer, and his impact on a generation of young adolescents.

Iterators, man. They're so much fun.

I've messed about with IEnumerable<T> a little bit before, even in the short history of this blog, but I don't feel like I can say I've done so in anger. Sort of the litmus test to see if you've grokked lazy evaluation is to implement an infinite sequence of some sort, wouldn't you agree? Until you do that it's all talk and no walk. So I thought I'd rectify that, to be a certified IEnumerable<T>-grokker. You in?

We'll start gently. The simplest example of an infinite sequence that I can think of is this:

   1, 2, 3, 4, 5...

You're absolutely right, it's the sequence of positive integers!

There are actually two simple ways to implement an IEnumerable<int> that would give you that. First off, you could write the dynamic duo of IEnumerable<int> and IEnumerator<int> that conspire to let you write code using the beloved foreach keyword. As you well know, foreach over an IEnumerable<T> compiles to IL that will obtain an IEnumerator<T> and use that to do the actual iteration. (I was going to write iterate over here, but that sort of presupposes that you've got something finite that you're stepping through, doesn't it?)

Anyways, first implementation:

An alternative implementation would be this:

This is simpler in terms of lines of code, but it requires you to understand what the yield keyword does. So what does the yield keyword do? Conceptually, yield gives you what is known as a continuation. In essence, it allows you to jump right back into the code where you left off at the previous step in the iteration. Of course, the best way to find out what is going on under the hood is to look at the IL. If you do that, you'll see that what the C# compiler actually does is conjure up an IEnumerator<int> of its own. This generated class essentially performs the same task as our handwritten IncrementingEnumerator.

Unsurprisingly, then, the end result is the same, regardless of the implementation we choose. What Incrementer gives you is an infinite sequence of consecutive positive integers, starting with 1. So if you have code like this:

That's going to print the numbers 1 through 10. And since there's no built-in way to stop the Incrementer, it's fairly important to break out of that loop!

That's not terribly interesting, though. Although it might be worth noting that at least it consumes little memory, since the IEnumerable<int> only holds on to a single integer at a time. That's good. Furthermore, we could generalize it to produce the sequence

   n, 2n, 3n, 4n, 5n...

instead (without exciting people too much, I guess). We could even provide an additional constructor to enable you to set a start value k, so you'd get the sequence

   n+k, 2n+k, 3n+k, 4n+k, 5n+k...

Still not excited? Oh well. There's no pleasing some people.

Let's implement it anyway. We'll call it NumberSequence and have it use a NumberEnumerator to do the actual work, such as it is (it isn't much):

You'll notice that I got a bit carried away and implemented IComparable<NumberEnumerator> as well, so that we could compare the state of two such NumberEnumerator instances should we so desire.

A completely different, but equally simple way to create an infinite sequence is to repeat the same finite sequence over and over again. You could do that completely generically, by repeating an IEnumerable<T>. Like so:

So you could write code like this:

And of course the output would be:

   Hello
   dear
   friend
   Hello
   dear
   friend
   Hello
   dear
   friend
   Hello

Now you could put a finite sequence of numbers in there, or just about any sequence you like, in fact. Including, as it were, an infinite sequence of some sort - although that wouldn't be very meaningful, since you'd never see that thing starting over!

So yeah, we're starting to see how we can create infinite sequences, and it's all very easy to do. But what can you do with it?

Let's turn our attention to an archetypical academic exercise: generating a sequence of prime numbers. Now as you well know, prime numbers aren't as useless as they might seem to the untrained eye - there are practical applications in cryptography and what have you. But we're not interested in that right now; we're going for pure academic interest here. Let's not fool ourselves to think we're doing anything useful.

A well-known technique for finding prime numbers is called the Sieve of Eratosthenes (a sieve, of course, being a device that separates wanted elements from unwanted ones). In a nutshell, the Sieve of Eratosthenes works like this:

You have a finite list of consecutive integers, starting at 2. You take the first number in the list and identify it as a prime. Then you go over the rest of the list, crossing out any multiples of that prime (since obviously multiples of a prime cannot be other primes). Then you take the next number in the list that hasn't been crossed out. That's also a prime, so you repeat the crossing out process for that prime. And so on and so forth until you're done.

Here's a simple example of the primes from 2-20.

   2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20

The number 2 is a prime! Cross out all the multiples of 2.

   2  3  X  5  X  7  X  9  X 11  X 13  X 15  X 17  X 19  X

The number 3 is also a prime! Now cross out all its multiples:

   2  3  X  5  X  7  X  X  X 11  X 13  X  X  X 17  X 19  X

And we keep going for 5, 7, 11, 13, 17 and 19. As it turns out, all the multiples have already been covered by other prime-multiples, so there are actually no more numbers being crossed out. But algorithmically, we obviously need to go through the same process for all the primes.

Now, a problem with the Sieve of Eratosthenes as it is formulated here, is that it presupposes a finite list of numbers, and hence you get a finite list of primes as well. We want an infinite list, otherwise surely we won't certify. Luckily, it is possible to adjust the Sieve of Eratosthenes to cope with infinite lists of numbers. There's a very readable paper by Melissa O'Neill that shows how you could go about it. The trick is to do just-in-time elimination of prime-multiples, instead of carrying out the elimination immediately when the prime is found.

Essentially, we maintain an infinite sequence of prime-multiples for each prime we encounter. For each new number we want to check, we check to see if there are pending prime-multiples (i.e. obvious non-primes) matching the number. If there are, the number is not a prime (since we're looking at a number that would have been eliminated in the finite Sieve of Erastosthenes). The number is discarded just-in-time, and the eliminating sequence(s) of prime-multiples are advanced to the next prime-multiple. If there is no matching prime-multiple in any of the sequences, the number is a brand new prime. This means that we need to add a new infinite sequence of prime-multiples to our collection. In other words, we're aggregating such sequences as we go along. Luckily, they each hold on to no more than a single integer value (See, I told you that was useful. And you wouldn't believe me!)

Now how do we keep track of our prime-multiple-sequences? A naive approach would be to keep them all in a list, and just check them all for each candidate number. That wouldn't be too bad for a small number of primes. However, say you're looking to see if a number n is the 1001th prime - you'd have to go through all 1000 prime-multiple sequences to see if any of them eliminate n as a candidate. That's a lot of unnecessary work! What we really need to do, is check the one(s) with the smallest pending prime-multiple. Using a priority queue to hold our sequences makes this an O(1) operation. Unfortunately, the .NET framework doesn't contain an implementation of a priority queue. Fortunately, the C5 Generic Collection Library does. So we'll use that.

Here, then, is how we could implement an IEnumerable<int> that represents an infinite sequence of primes:

An interesting thing to point out is that the prime-multiple sequence doesn't have to start until prime*prime. Why? Because smaller multiples of the prime will already be covered by previously considered primes! For instance, the prime-multiple sequence for 17 doesn't have to contain the multiple 17*11 since the prime-multiple sequence for 11 will contain the same number.

Now this implementation is actually pretty decent. There's just one thing that leaps to mind as sort of wasted effort. We're checking every number there is to see if it could possibly be a prime. Yet we know that 2 is the only even number that is a prime (all the others, well, they'd be divisible by 2, right?). So half of our checks are completely in vain.

What if we baked in a little bit of smarts to handle this special case? Say we create a PrimeSequence like so:

The OddPrimeEnumerator is actually quite similar to the naive PrimeEnumerator, except three things:

1. It needs to start at 3 instead of 2, since we already yielded 2 in the PrimeSequence.
2. It needs to skip every other number, so it uses 2 as an increment instead of 1.
3. The MoveNext method can no longer assume that n <= the smallest pending prime-multiple. In fact, it may very well have skipped past a prime-multiple.

Note that we must go out of our way a little bit to handle the case where we skip past a prime-multiple. Hence the code is microscopically uglier, but we cut our work pretty much in half. But of course, it's tempting to go further. We check an awful lot of multiples of 3 as well, you know? And of 5? What if we could just skip those too? Turns out there's a well-known optimization technique known as "wheel factorization" that allows us to do just that.

Here's a 2*3*5 wheel (well, the three first layers of it, anyway). Note that it starts at 7, which is the first prime we're not including in this wheel factorization.

The green "spokes" of the wheel represents sectors where you might find a prime number. The big red areas you don't even have to check, because they contain only multiples of the first three primes.

Obviously then, the wheel allows us to rule out a great deal of numbers right off the bat. The numbers not filtered out by the wheel are checked in the normal way. According to O'Neill, there are quickly diminishing returns in using large wheels, so we'll restrain ourselves to a small wheel that takes out the multiples of 2, 3, and 5.

Now how do we implement this wheel in our code? Well, clearly the wheel can be represented as another infinite sequence, with the characteristic that it repeats the same pattern of numbers to skip over and over again. Well gee, that sounds almost like a broken record, doesn't it? (You'd think I planned these things!)

Say you wanted to create an infinite skip sequence corresponding to the wheel shown above. This code would do nicely:

Now we can use the skip sequence to create a sequence of prime candidate numbers. We'll call it a WheelSequence for lack of a better term.

Now we can replace our original naive PrimeEnumerator with one that uses wheel factorization to greatly reduce the number of candidates considered.

This particular implementation uses a wheel that pre-eliminates multiples of 2, 3, and 5, but obviously you could use any wheel you want. Note that the only difference between this implementation and the OddPrimeEnumerator is in the choice of IEnumerator<int> for prime number candidates. The rest is unchanged.

Of course, to use this thing, we must first manually yield the primes that we eliminated the multiples of. Like so:

That just about wraps it up. I should point out that the current implementation doesn't really give you an infinite sequence of primes. Unfortunately, the abstraction is all a-leak like a broken faucet since the pesky real world of finite-sized integers causes it to break down at a certain point. In fact, for the current implementation, that point is after the 4.792th prime, which is 46.349. Why? Because then we start a prime-multiple sequence at 46.349*46.349, which won't fit into the 32-bit integer we're currently using to store the current value. Hence we get a overflow, the prime-multiple sequence gets a negative number, and it's all messed up. We really should put an if-statement in there, to return false from MoveNext if and when we overflow, effectively terminating our not-so-infinite-infinite sequence.

Of course we could use a 64-bit integer instead, but keep in mind that we're really just buying time - we're not fixing the underlying problem. C# doesn't have arbitrary-sized integers, end of story. Nevertheless, 64-bit integers will give you primes larger than 3.000.000.000. I'd say it's good enough for an academic exercise; or as I like to put it, large enough for all impractical purposes.

Do I certify?

Ignorance can hurt you for weeks and months, by forcing you to go through inefficient, mundane and - here's the main thing - unnecessary hoops to accomplish every-day, common-place things. Like launching Visual Studio with administrative rights.

First off, I use Launchy to do pretty much anything (and you should too). Certainly I use it to launch Visual Studio. Every day. Thanks to Launchy, I don't have to take my spidery fingers off my lovely keyboard at all. No feeding that gluttenous RSI monster by entering mouse-pointing mode. I just hit ALT+SPACE (to bring up Launchy), type "10", press ENTER and Visual Studio is on its way. (Launchy has figured out that when I type "10" I really mean Visual Studio 2010.) Total of five keystrokes. Good stuff, not much room for improvement there.

Here's the catch, though: Sometimes you need to launch Visual Studio with administrative rights. How do you launch an application with administrative rights? Why, you right-click on the short-cut and choose "Run as administrator", of course.

Suddenly I'm tossed out of my stream-lined keyboard-centric work flow, and forced to go chasing that pesky mouse. Ouch.

For days and weeks and months I suffered through that, growing ever-so-slightly more annoyed each time. Finally I couldn't take it anymore and invested the five minutes it took to find a solution. Turns out it's facepalm-inducingly simple to fix.

See, there's a little checkbox you can tick off, which says that the shortcut should launch the application as administrator. To find the checkbox, choose Properties for the shortcut and click the Advanced button. You'll see this:

So that really fixes the issue at hand right there. However, I wanted to keep the ability to launch Visual Studio as non-administrator as well, since most of the time I don't need the administrative rights. And you know, when launching as administrator, you have to pause to jump through the UAC hoop. Luckily, you don't need a mouse to do that, but still.

So I ended up cloning the shortcut, which is is located at C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Visual Studio 2010. The clone has the same name as the original, with an "a" (for "admin") tacked on at the end.

Now I can hit ALT+SPACE, type "10a", press ENTER, wait a second or two for the UAC to pop up, confirm the launch, and Visual Studio 2010 is on its merry way, running as administrator. Like so:

Good stuff, at last.

You'd think that, as a professional computer user, I'd have all kinds of fancy tricks up my sleeve to help me command the dang thing. But I don't. Maybe I should, but I don't. In fact, using Launchy is my one claim to power-user-dom.

Launchy is a magical software artifact that allows you to translate thoughts to computer commands. The thoughts travel at light speed through my hands directly into the CPU. No kidding.

A more mundane description would be that it allows you to launch applications using the keyboard alone, optionally passing in parameters to the application as well (the official label being "an open-source keystroke launcher"). Therein lies great power.

Launchy runs in the background on my computer, listening for me to hit ALT+SPACE. This brings up an innocuous prompt, floating on top of any applications, in the middle of my screen:

When the prompt pops up, I'll do one of three things:

1. Type the name of an application.
2. Type a command.
3. Type the path of a folder.

It might not look like much, but it is actually incredibly empowering. In fact, I feel severely limited when I'm using a machine without Launchy, like I'm trapped in a slow motion movie. It's so ingrained my workflow that I'll invariably hit ALT+SPACE followed by some command every now and then. Of course, this has arbitrary effects on the machine, since Launchy isn't there to capture the keystrokes following ALT+SPACE. (When that happens, I recoil into the fetal position out of fear that I've unwittingly triggered some fatal process on the computer. Luckily I never have. I guess hitting a few letters and possibly a TAB doesn't have much potential for wreaking havoc.)

Anyways, let's take a look at each item in the list in turn.

Type the name of an application

Actually, I won't do that. I'll write some shorthand that Launchy is clever enough to interprete as an application name. For instance, I'll type "ff" to launch Firefox. (Yeah, I know that "fx" is the official abbreviation. I also don't care.) It looks like this:

Sometimes, I won't hit ENTER directly - instead I'll hit TAB and type in some more text first. The extra text will be interpreted as a parameter to the application. For instance, I can type "ff TAB http://www.launchy.net" to go to the Launchy website.

Type a command

That's really just half the story. I'll type in the name of a command, followed by TAB and some text. I use this mostly for search (and quick web navigation in general, see below). I launch a Google search by typing "g TAB search term". For instance, to dig up some info on Windows Phone 7 and the MVVM pattern, I'd do this:

Launchy comes with "Google" as a pre-configured search option, but I've shortened it to "g" since it's such a common task. The command will launch my default web browser and display the list of search results.

There are a bunch of other built-in search options as well, such as "Amazon", "YouTube" and "Wikipedia". I've added a few of my own as well, including "img" (which does a Google image search), "tlf" (which does a lookup based on a phone number using the GuleSider service) and "dokpro" (which is a Norwegian dictionary).

I also use a teeny-tiny but oh-so-useful hack to use Launchy and Google to navigate quickly to whatever web site I want: "j TAB search term". The letter j is a mnemonic for "jump". I've configured it in Launchys options pane (which you can bring up after right-clicking on the prompt):

As you can see, the j command is really just Google's "I feel lucky" search (which is the regular search plus a query string option of "btnI"). I don't really use it for searching per se, though. I use it to navigate to something without typing the actual URL. Maybe I don't remember the exact URL, or maybe I'm just too lazy to type it in.

For example, say I want to navigate to Pluralsight's web site. The actual URL is http://www.pluralsight-training.net, but I tend to forget that. Instead I type "j TAB pluralsight", which takes me right there:

This launches my web browser and takes me to the Pluralsight web site, essentially using Google as a redirecting proxy.

Type the path of folder

This is nothing fancy, but still pretty useful. To bring up any folder, just start typing in the path. Launchy will help by performing autocomplete, so I typically just have to type a few letters of each part of path. This should sum it up nicely:

So that's it. A small bag of tricks to be sure, but what tricks they are! (Of course, you could go much further with Launchy if you're so inclined. You could use it to maintain a TODO list, send messages to twitter, or even update the status of an issue in JIRA.)

 

 

I’m a big proponent of the NoORM movement. Haven’t heard of it? That’s because it doesn’t exist. But it sort of does, under a different name. So-called “micro-ORMs” like Simple.Data, dapper and massive all belong to this category. That’s three really smart guys (unwittingly) supporting the same cause as I. Not bad. I’d say that’s the genesis of a movement right there.

Unsurprisingly, NoORM means “not only ORM”. The implication is that there are scenarios where full-blown object-relational mapper frameworks like nHibernate and Entity Framework are overkill. Such frameworks really go beyond merely addressing the infamous object/relational impedence mismatch (which is arguably irreconcilable), to support an almost seamless experience of persistent objects stored in a relational database. To do so, they pull out the heavy guns, like the Unit of Work pattern from Martin Fowler’s Patterns of Enterprise Application Architecture (One of those seminal tomes with an “on bookshelf”-to-“actually read it” ratio that’s just a little too high.)

And that’s great! I always say, let someone else “maintain a list of objects affected by a business transaction and coordinate the writing out of changes and the resolution of concurrency problems”. Preferably someone smarter than me. It’s hard to get right, and it in the right circumstances, being able to leverage a mature framework to do that heavy lifting for you is a huge boon.

Make sure you have some heavy lifting to do, though. All the power, all the functionality, all the goodness supported by state-of-the-art ORMs, comes at a cost. There’s a cost in configuration, in conceptual overhead, in overall complexity of your app. Potentially there’s a cost in performance as well. What if you don’t care about flexible ways of configuring the mapping of a complex hierarchy of rich domain objects onto a highly normalized table structure? What if you don’t need to support concurrent, persistent manipulation of the state of those objects? What if all you need is to grab some data and go to town? In that case, you might be better served with something simpler, like raw ADO.NET calls or some thin, unambitious veneer on top of that.

Now there’s one big problem with using raw ADO.NET calls: repetition (lack of DRYness). You basically have to go through the same song-and-dance every time, with just minor variations. With that comes boredom and bugs. So how do we avoid that? How do fight repetition and duplication? By abstraction, of course. We single out the stuff that varies and abstract away the rest. Needless to say, the less that varies, the simpler and more powerful the abstraction. If you can commit to some serious constraints with respect to varity, your abstraction becomes that much more succinct and that much more powerful. Of course, in order to go abstract, we first need to go concrete. So let’s do that.

Here’s a scenario: there’s a database. A big, honkin' legacy database. It’s got a gazillion stored procedures, reams and reams of business logic written in T-SQL by some tech debt nomad who has since moved on to greener pastures. A dozen business critical applications rely on it. It’s not something you’ll want to touch with a ten-foot pole. The good thing is you don’t have to. For the scope of the project you’re doing, all you need to do is grab some data and go. Invoke a handful of those archaic stored procedures to get the data you need, and you’re done. Home free. Have a cup of tea.

Now what sort of constraints can we embrace and exploit in this scenario?

1. Everything will be stored procedures.
2. It’s SQL Server, and that’s not going to change.

As it turns out, the second point is not really significant, since we’ll need database-agnostic code if we’re going to write tests. The first one is interesting though. We’ll also assume that the stored procedures will accept input parameters only. That’s going to simplify our code a great deal.

Let’s start by introducing a naive client doing straight invocation of a few stored procedures in plain ol' ADO.NET:

So you can see, there’s a great deal of duplication going on there. And obviously, as you add new queries and commands, the amount of duplication increases linearly. It’s the embryo of a maintenance nightmare right there. But we’ll fight back with that trusty ol' weapon of ours: abstraction! To arrive at a suitable one, let’s play a game of compare and contrast.

What varies?

• The list of input parameters.
• In the case of queries: the data row we’re mapping from and the .NET type we’re mapping to.
• The names of stored procedures.
• The execute method (ExecuteReader, ExecuteScalar, ExecuteNonQuery). We’re gonna ignore DataSets since I don’t like them. (I’ll be using my own anemic POCOs, thank you very much!).

What stays the same?

• The connection string.
• The need to create and open a connection.
• The need to create and configure a command object.
• The need to execute the command against the database.
• The need to map the result of the command to some suitable representation (unless we’re doing ExecuteNonQuery).

There are a couple of design patterns that spring to mind, like Strategy or Template method, that might help us clean things up. We’ll be leaving GoF on the shelf next to PoEAA, though, and use lambdas and generic methods instead.

I take “don’t repeat yourself” quite literally. So we’re aiming for a single method where we’ll be doing all our communication with the database. We’re going to channel all our queries and commands through that same method, passing in just the stuff that varies.

To work towards that goal, let’s refactor into some generic methods:

So we’ve bloated the code a little bit – in fact, we just doubled the number of methods. But we’re in a much better position to write new queries and commands. We’re done with connections and usings and what have you. Later on, we can just reuse the same generic methods.

However, we still have some glaring duplication hurting our eyes: the three execute methods are practically identical. So while the code is much DRYer than the original, there’s still some moisture in there. And moisture leads to smell and rot.

To wring those few remaining drops out of the code, we need to abstract over the execute methods. The solution? To go even more generic!

So basically the solution is to pass in a function that specifies the execute method to run. The other execute methods can use this to get their stuff done. Now that we have our single, magical do-all database interaction method, let’s make make things a bit more reusable. We’ll cut the database code out of the client, and introduce a tiny abstraction. Let’s call it Database, since that’s what it is. In fact, for good measure, let’s throw in a new method that might be useful in the process: ExecuteRow. Here’s the code:

ExecuteScalar is pretty straightforward, but there are a few interesting details concerning the others. First, ExecuteReader derives a map from IDataReader to IEnumerable from the user-supplied map from IDataRecord to T. Second, ExecuteNonQuery doesn’t really care about the result from calling DbCommand.ExecuteNonQuery against the database (which indicates the number of rows affected by the command/non-query). So we’re providing the simplest possible map – the identity map – to the Execute method.

So the execution code is pretty DRY now. Basically, you’re just passing in the stuff that varies. And there’s a single method actually creating connections and commands and executing them against the database. Good stuff.

Let’s attack redundancy in the client code. Here’s what it looks like at the moment:

Actually, it’s not too bad, but I’m not happy about the repeated chanting of new SqlParameter. We’ll introduce a simple abstraction to DRY up that too, and give us a syntax that’s a bit more succinct and declarative-looking.

This is basically a sponge for parameters. It uses a little trick with a get-indexer with side-effects to do its thing. This allows for a simple fluent syntax to add parameters to a DbCommand object. Let’s refactor the generic Execute method to use it.

The refactoring ripples through to the other execute methods as well, meaning you pass in a Func instead of the parameter array. Now the interesting part is how the new abstraction affects the client code. Here’s how:

Which is pretty much as DRY as it gets, at least in my book. We just grab the data and go. Wheee! Where’s my tea?

The other day, I stumbled across this post, describing how .NET developers are alledgedly misuing DateTime.Now. The gist of it is that we are using DateTime.Now in cases where DateTime.UtcNow would be more appropriate, for instance when measuring runtime performance. The difference between Now and UtcNow is that the former gives you local time, whereas the latter gives you "universal" or location-independent time. It turns out that Now is one or two orders of magnitude slower than UtcNow; the reason being that Now has to derive the local time by calculating an offset from universal time depending on locale. Clearly, this is unnecessary work if all you're going to do is calculate the time elapsed between two points in time. Based on this, the author of the blog post argues that using Now when you could have used UtcNow is wrong.

I'm of two minds about this issue. My gut reaction was that, "gee, that's really unimportant". Or to borrow a phrase from one of my co-workers, "I would look for performance optimisations elsewhere". So Now is much slower than UtcNow. I didn't know that, but then again I don't think it's a big deal. Performance doesn't matter until it does - that is, when something is perceived as unacceptably slow by a user. Of course, the post includes the mandatory contrived example, showing how the difference between Now and UtcNow matters when current time is sampled a million times in a tight loop. Yup. EVERYTHING matters when you're doing it a million times. (Especially if you do it on some thread where there's a user waiting in the other end.) Nevertheless, I find it entirely plausible that in a practical scenario, there would be other things you needed to do a million times besides getting the time, which just might dwarf the demonstrated performance difference. Put it another way: I estimate there's something like a one-in-a-million chance that you're actually going to be in a real world situation where this is going to be a problem. Now for that one guy in Duluth, Minnesota who actually has to get the current time - and nothing else - a million consecutively for some business critical routine, it's going to matter if he knows about the performance difference between Now and UtcNow. I hope he does. For the rest of us, not so much.

On the flip side though: now that I know, I'll never again use Now if I can use UtcNow instead. Isn't that ironic? I've just claimed that this has no practical implications whatsoever, and yet: In the future, whenever I'm doing some relative measurement of time, it's UtcNow all the way. Unless it's StopWatch, which is usually much more convenient (and uses UtcNow under the hood by default). After all, there's no reason to waste clock cycles on purpose. Heh.

Lurking underneath this rather trivial matter, though, is a somewhat deeper issue. Which is: should I have known?

Isn't it negligence on my part that I was unaware of the performance implications of using Now instead of UtcNow? After all, I'm a professional developer, right? I've heard Uncle Bob's sermons about craftmanship and I'm a believer. My employer pays me good money each month to produce the best code I'm able to. In turn, my employer's customers rely on the quality of that code. And I've put my share of Now's in there, you know? Without needing to. Superflous work. Burnt cycles. UtcNow would have been just fine. Not that it matters, performance-wise, in any way, shape or form - if and when I've written sluggish code, it's not because of Now - it's because I've chosen a suboptimal algorithm or data structure at some key point in the application. Still: the right thing would have been to use UtcNow unless I needed local time, dammit! And I've plunged ahead, unwittingly using Now instead, all due to my incomplete knowledge of the .NET framework. Isn't that sloppy?

As you can imagine, I'm totally going to exonerate myself on this issue. No, I should not have known! I mean, I could have known, it would have been nice if I would have known, but I don't think I should have known. You see, programmers work in a constant state of partial, incomplete understanding. This is not an anomaly, it's the name of the game. Modern software is just too large and complex to make it feasible to grok it all unless you're L. Peter Deutsch or something. And you probably aren't. This certainly goes for the vast .NET framework. According to this post, version 3.5 of the .NET framework contained 11417 types and 109657 members. Complete understanding is not only unattainable, it's also economically unsound to aim for. Since program understanding is a slow and costly process, your efforts should be focussed on understanding what is needed to solve the problem at hand. You need just enough program understanding to implement a feature or fix a bug or whatever you need to do. Just-in-time program understanding is a lean and pragmatic approach that allows you to get things done. (Note that I'm not advocating programming by coincidence here. Clearly you have to understand, at some level, what the code you're invoking does. But you do so at the appropriate level of abstraction. You shouldn't have to fire up Reflector every time you're using an API function.)

If anything, it's an API design issue. (Blaming it on Microsoft is always a safe bet!) When using an API, you try to map the problem you need solved onto the members of the API. You scan the available properties and methods, and conjecture a hypothesis regarding which one will fulfill your need. In doing so, you reach for the simplest-sounding potential match first. Only when that doesn't work for you do you consider the next most plausible candidate. You can think of this as API affordance - the API will invite you, through it's vocabulary, to try out certain things first. If you need Foo to happen and the API supports methods Foo() and FrobnitzFoo(), you're going to try Foo() first. Right? Only when the plain Foo() fails to Foo as you'd like it to will you try FrobnitzFoo() instead. I'm sure you can see the parallel to Now/UtcNow. Since Microsoft gave the straight-forward simplest name to the property that gives you local time, that's what developers reach for, even when they just need a relative timestamp. It's pure economics. And lo and behold! it works, because for all but the poor schmuck in Duluth, Now gets the job done just fine. The hypothesis is never falsified. (Of course, that guy from Duluth is going to end up an enlightened schmuck, because for him, the hypothesis will be falsified - he's going to get burned by the relatively slow implementation, probe around the DateTime API, maybe even crank out Reflector, and eventually find that "hey, I should be using UtcNow instead". And he'll be good to go, and all smug about it to boot.)

Of course, we can speculate as to why Microsoft used the name 'Now' instead of something like 'LocalNow', which would have been more precise. Is it accidental? Due to negligence or incompetence? Probably not. Now is broadly applicable and good enough in all but the most extreme scenarios. It can be used successfully both for showing local time to the user (which is usually the right thing to do), and for measuring runtime performance (even though it's not the optimal choice in the latter case). I think they did it very deliberately. And I don't think it's a bad thing. If Microsoft made a mistake, it's that Now is a property. In general, the rule is that properties should be instantenous. According to the MSDN documentation, a method is preferable to a property when "[it] performs a time-consuming operation, [that is] perceivably slower than the time it takes to set or get a field's value". Arguably, then, Now should really have been Now(). That would have provided a subtle hint that getting the current time isn't free. And these long posts about DateTime.Now wouldn't have been written at all.