My first dnrTV episode went live today. I am talking with Carl Franklin about dependency inversion, dependency injection, and inversion of control. I demonstrate how to build a very simple IoC container. My intent is to show developers that it isn't any thing crazy scary. I talk about how IoC facilitates decoupling dependencies and creating more easily testable software. Check it out!

dnrTV #126: James Kovacs' roll-your-own IoC container

Feedback is always welcome.

Carl and I plan to do another show focused on IoC containers in the next few weeks. Specifically we'll be talking about what a full-fledged container offers over and above the roll-your-own. If you have other IoC questions you would like answered on the next show, drop me an email.

I was going sysprep a base image of Windows Server 2008 this morning and followed my own instructions on sysprepping Windows. I went to the installation DVD and couldn't find sysprep. A quick google later and a bit of poking around revealed that sysprep is now installed by default on Windwos Server 2008. You can find it at:

c:\Windows\System32\sysprep\sysprep.exe

The experience is also streamlined considerably. Simply run sysprep.exe above and you are presented with:

Change the Shutdown Options to "Shutdown" and click OK. The system will go through the sysprep process and shut itself down. You can now create cloned servers to your heart's content simply by creating linked servers and booting the clone as originally documented here.

Recently, I'd say in the past month or so, our FeedBurner flare icon RSS feed subscriptions have been dropping like flies. We went from 25K to 12K and now today to 7K!  There's one of two things possibly going on here 1) Kyle is becoming the most hated blogger on the planet (which is one extremely popular theory over on Twitter) or 2) Something is wrong with the Feeburner, Google Reader and Bloglines relationship. I'm not exactly sure where the cause of the drop is, but I'm squarely placing the blame on FeedBurner.  1) because it is their tool that's exposing the brokenness, and b) because they have absolutely zero support.  Check out any of the treads here on this Google group, including this thread by me attempting to address the issue.

So, the quesiton is, since there seems to be zero support from Google on this, and it seems so hopelessly broken, is FeedBurner dead?

And yes, I'm pulling out the big guns, my CodeBetter Blog to try to get some resolve on this one.

As I covered earlier in my post Functional .NET - LINQ or Language Integrated Monads, I talked about using asynchronous computation expressions (monads) from C# 3.0.  Brian McNamara, of the F# team, posted back in May about using them from C#.  But since then, things have changed slightly.  Before, I showed a basic example of how to utilize the F# libraries from C#, but let's go deep under the covers to see how this actually works.

Getting Started

In order to make use of the F# libraries in our C# library, we need to add references to them.  We need the following items:

• FSharp.Core.dll
• FSharp.PowerPack.dll
• FSharp.PowerPack.Linq.dll

And then I need to open the namespaces in order to take advantage of F#:

Referencing F# Classes

As part of process of creating the asynchronous monad builders in C#, we need to create an instance of the F# class AsyncBuilder in the Microsoft.FSharp.Control namespace.  Unfortunately, the AsyncBuilder has an internal constructor, thus preventing us from creating it directly.  The other option is getting the async instance in the AsyncImpl internal class.  I think the first option is a bit more preferable.  In order to create an instance, all we need to do is invoke the constructor via reflection as a static instance.

Now that we have this, we have to realize that F# doesn't use the standard .NET delegates for functions.  Let's walk through some ways of converting back and forth.

Converting Functions

As we've noted before, F# does not use the standard Func and Action delegates that are commonly used in C# and VB.NET.  Instead, the functions in F# use the FastFunc class.  This allows for the F# compiler to better optimize the closures, especially due to the fact that these closures are quite commonly used.  Another point of difference is that there is no distinction between Func and Action delegates, and instead, for functions that return no value have the return type of Unit.  This is the optimal way of handling this, due to the fact that Void is not treated as a real type, which you've heard me complain about in the past.

In order to convert from the Func delegate to the FastFunc, we use the FuncConvertExtensions class in the FSharp.PowerPack.Linq.dll assembly.  Then we can create extension methods on our Func delegates to expose the conversion methods.  The conversion methods should look like this.

Now that the conversions have been put in place, we can turn our attention to creating the extension methods required for LINQ expressions. 

Adding LINQ Extension Methods

In order for LINQ to bind and return data, the SelectMany and Select methods must be implemented.  We need to implement these methods to return an Async<T> class for binding and returning purposes.  As part of the implementation, we need to ensure our Func delegates are converted to the proper FastFunc types.

Once the LINQ methods are added, we can turn our attention on how we might actually implement the asynchronous behavior with our given classes. 

Adding Extensions Building Primitives

In order for your classes to use the asynchronous behavior, we need to expose ways of building primitives so that we can enlist those methods that expose the Beginxxx and Endxxx signature which includes the IAsyncResult.  Also, in order to support method calls that do not, we have the ability within the asynchronous computation expressions to unblock via a new thread.

First, we need to define the method which allows us to do non-blocking calls on methods that do not support the Begin/End pattern.  In order for this to happen, we need to call an internal method to the FileExtensions class in the FSharp.PowerPack.dll assembly called UnblockViaNewThread.  Due to the fact that it is a generic method, we have to do special binding using reflection.    Once this has been created, we can now enlist functions that follow the Func<Res> signature.

Second, we need to define methods to build primitives to allow for methods that follow the Begin/End pattern using the IAsyncResult and AsyncCallback delegate.  Overloads are necessary due to the fact that methods may have return types or not.  Examples of this pattern are Stream.BeginRead, Stream.BeginWrite and so on.

Lastly, we need the ability to start the asynchronous computation expression.  This must be the first statement in any asynchronous computation expression that we write.  Let's look at how the code is implemented.

 
Now that we have the ability to add asynchronous behavior to our classes, let's implement some extension methods that encompass the behavior.

Extending Types With The Begin/End Pattern

For methods that have the standard Begin/End methods can use the BuildPrimitive methods that we defined above.  As our first example, let's implement an asynchronous WebRequest.GetResponse.  Normally in our .NET code, we have to implement the Begin/End ourselves.  Instead, we pass the methods to the BuildPrimitive method to bind.

Any method signature that follows this pattern should be able to partake.  Now what about those methods that do not follow the Begin/End pattern.  What can we do about those?

Extending Types with Non-Blocking Threads

As I mentioned previously, I want the ability to perform asynchronous operations on those methods that do not follow the Begin/End pattern.  In order to do that, I must use the UnblockViaNewThread method that was defined above.  For example, we could expose the ability to open files asynchronously as either readers or streams.  Let's define some methods to open files asynchronously.

This pattern would also apply to such things as WebRequest.Create and so on.  Now, let's bring it all together.

Bringing It All Together

What the above code does for me is allows me to count the number of hyperlinks, given a URL, in parallel.  This is a pretty simplistic example, yet works quite well for this demonstration.  Now, using our C# implementation, let's take the above code and get it to work in C#.

For each of the above, we get the following result:

Well, that works exactly according to plan.  But, using this technique, are there any downsides?

Downsides?

The asynchronous code I wrote above is pretty simple and naive.  Counting links in an HTML page is a pretty simple example with some asynchronous calls.  But, this breaks down easily if it gets more complex than this.  There are constructs that can be done in the asynchronous computation expressions in F# that cannot be done through LINQ.  For example, there are several things that cannot be done through LINQ expressions such as the following:

• if/then/else
• while loops
• try/catch/finally
• methods that return void

These above constructs don't have a 1 to 1 mapping with LINQ.  As a result, our code may have to look significantly different than the F# code that we'd write.  That of course eliminates some of the savings we may have had with our LINQ implementation. 

As you see, when combined with such things as the MailboxProcessor, the asynchronous computation expressions become a bit more powerful.  Unfortunately, LINQ doesn't support these features of conditionals, using statements and so on.  The alternative being, using the awkward syntax with converting between FastFunc and Func delegates, which negates any savings we may have had.

Wrapping It Up

As I've shown in the past posts, LINQ expressions could be used to your advantage to do more than just standard query operations.  Instead, if we start to think of them as very powerful monadic constructs, we can then think of better uses for them.  Although the LINQ expressions are limited in what they can achieve through the asynchronous computation expressions, it still gets you quite far.  I hope this exploration gets you to understand languages such as Haskell and how monads are useful.  For further information, you should check out "What is a monad, why should I use it and when it is appropriate" on Lambda the Ultimate.

The code from this post is available, as always from the Functional C# Library on MSDN Code Gallery.

you write a fairly complicated integration test to exercise some the interplay between different classes and some brand new DSL code...

and the test passes on the first try...

is the explanation:

A) You're damn good.  Clean design.  Good unit tests.  Master of the programming universe is you.

or.....

B) Your test is wrong!

While you, dear reader, ponder this question I shall now proceed to double check my test code.

As part of my talk at the Richmond Code Camp earlier in October, I had the opportunity to talk about how to implement functional aspects in C# 3.0.  This talk revolved around such concepts as from mutable to immutable, from inheritance to functional composition, and the mind shift that is required.  Part of this discussion involved very briefly a talk about monads.  It's a very misunderstood part of computer science and one of the most powerful concepts to learn.  Much like continuation passing style, this style is often maligned as a result.  But, let's work to change that.

What Is a Monad?

Monads come to us originally from category theory.  When monads applied to functional programming, they simply are a construction, given an underlying type system, embeds a corresponding monadic type system.  Simply put, the values you have become amplified values that are to be interpreted by the matching monadic type. 

The formulation of a monad comes in three parts:

1. A type construction that defines for every underlying type, how to obtain a corresponding monadic type.  If the given type in F# is 'a, then the corresponding monadic type for an Identity monad would be I<'a>.  I'll cover more of what that means below.
2. A unit function that maps the underlying type to a value in the corresponding monadic type.  In F# parlance, this maps to a Return function.
3. A binding operation of polymorphic type, in F# parlance, (I<'a>) => ('a => I<'b>) => (I<'b>).  This maps to a Bind function given your monad builder.  If you look carefully at the signature of this, you might also note that the LINQ SelectMany follows this syntax.  Gee, what could that mean?  The bind operation follows four steps:
   1. The monadic structure exposes the underlying value of type 'a.
   2. The given function is applied to the underlying value to obtain values of type I<'b>
   3. The monadic structure exposes the underlying value of type 'b.
   4. The monadic structure is reassembled over the results, given a single value of type I<'b>

Simply put, a monad, unlike your normal function results, stores function results and side-effect representations. This allows side effects to be propagated through the return values of functions without breaking the pure functional model.  This is what makes it so powerful that it is a way to manage side effects.  Given a pure language such as Haskell, this is the way that any side effecting operation should be done.  Granted, there are impure ways of doing IO, but let's not go there.

There are some good sources of information on what monads are, including some great stuff from Brian Beckman:

• Channel9 - Brian Beckman: Monads, Monoids and Mort
• Channel9 - Brian Beckman: Don't fear the Monads
• Wes Dyer - Marvel of Monads

Some examples of monads that are used frequently are such things as the maybe monad, identity monad, IO, collections and so on.  Let's move onto implementing some of these monads in .NET, whether it be F# or even C#.

Implementing in .NET

To implement the above mentioned monads, we'll take examples in both F# and C# to see that both can do the job.  Although I'll admit my preference for F#, C# can monads quite nicely using LINQ syntax.  But that sometimes means that the from and select keywords might be confusing.  But what people might not realize is that you are not limited to IEnumerable<T> inside LINQ.  Instead, you could have any backing type you want.  For example, I could have the identity type, maybe type, async type and so on.  We'll cover each one of those in detail in the following sections.

Anyhow, let's get started with the identity monad.

The Identity Monad

The easiest monad to understand is the identity monad.  This attaches no information to the underlying value, and instead only returns and transforms it. 

Implementing in F#

To implement in F#, we need to remember what's required for any monad builder.  That is the Bind, Return, Delay and Let functions.  Let's define our builder first with the given functions.

Now that our builder is defined, F# has a special way of representing monads in that you wrap them in curly braces with the given instance name of the monad builder.  In this case, I'll call it ident.

The above code allows me to define x and y and add them together.  The end result ends up being 47.  This looks pretty simple using this syntax, although this is what it ends up being behind the scenes:

As you can see, the syntax is much more simplified with the syntactic sugar that they give us.  This almost looks like LINQ in a way.

Implementing in C# 3.0

Now, what about C#?  What can we do there?  Actually, the answer is, that it's quite simple.  If you notice one thing about LINQ is the signature of the SelectMany method.  Let's look at the definition on the Enumerable class.

And if you look at the bind syntax that we used in our F# example, it's exactly the same signature.  That should tell us something that LINQ expressions can indeed be monads.  Now, let's implement the identity monad by first identifying the class and then the extension methods that make this work.

When we implement things for LINQ, we must be cognizant for the need of two SelectMany methods for various performance reasons to allow us to combine values.  Now that we've defined these methods, we can now use LINQ expressions to express our identity monad.

As above the answer comes out to 47.  Let's move onto the maybe monad.

The Maybe Monad

The maybe monad is another popular monad type.  A maybe monad is very similar to the identity, yet a value may be missing.  In F# parlance, this translates to the Option<'a> type.  Let's go ahead and implement this in F# using our given option type.

Implementing in F#

Implementing the maybe monad is very similar to the identity monad.  The only difference being is the to differentiate between some value and no value specified.  We will determine that through pattern matching, as always.

Once defined, we can now use our MaybeBuilder to define a simple use of our maybe monad.  Let's make sure we use None to denote that we are missing a value.

The result of course is "Undefined" because our y value is the None option type.  But, how might this work in C#? 

Implementing in C# 3.0

We can reuse a lot of our ideas from implementing this via extension methods.  I will go ahead and use the Option type that I've defined in my Functional C# project on MSDN Code Gallery.  From there, we can implement our SelectMany operations.

Now that we defined our binding operations, we can move onto actually using the maybe monad.  Let's use the template that we defined up above for our identity monad and craft it to use our maybes.

Once again, our result will be undefined as our y value has no real value at all.  Clear so far?  Let's move onto the List Monad.

The Collection Monad

The collection monad is another important monad type.  This monad is the heart and soul of LINQ and the way we use it to compute our lazily evaluated lists.  This monad strikes home as one of the most important to .NET developers.  Using LINQ to SQL, XML and such uses collections of various sorts to transform the data into other forms.

Implementing in F#

As before, we need to define our basic bind, let, return and delay functions in order for the monad to work in F#.  Let's define the list monad to use seq<'a>.  This way, I can lazily evaluate my results and yield them when I need to.  For the bind and result statements, I'm using a sequence expression to yield the appropriate values.

Now that we've defined our monad builder, let's implement this to add the values from each collection to each other.

Our results will be the addition of each number in each list to each other.  So, in turn, I will get 9 numbers in total with a value of 5 6 7 6 7 8 7 8 9.

Implementing in C# 3.0

To view the bind methods, simply open the Enumerable class to view the SelectMany implementations.  This will get us started in looking at a C# equivalent to the list monad we did above.  A simple representation might look like this.

And we now realize the answers between the two are exactly the same.  No special magic required for list monads.

The Asynchronous Monad

One of the most often used monads in F# is the asynchronous computation expression.  This allows us to use non-blocking calls to download resources, whether it be files, web request, WCF calls and so on.  This is where monads become really useful for .NET developers who want to explore a little outside the box in ways of thinking about monads. 

Implementing in F#

We get the asynchronous computation expressions out of the box with F#.  This allows us to easily create asynchronous computation expressions which I talked about earlier here.  But, let's look at one example of downloading the HTML from various web sites in parallel with non-blocking calls.  What might that look like?

As you can see, we're creating a request, getting the response, creating a reader, and reading all the way to the end asynchronously.  As you may note, there is a difference between let! and let.  The let! uses the Bind method whereas the let uses the Let method of AsyncBuilder.  What I'm able to do here is take three websites, and download their HTML and display within a short amount of time.  Imagine if I had to write that using IAsyncResult classes and such.  That wouldn't be ideal!  But, can C# partake in this?

Implementing in C# 3.0

The question I asked is that can we take advantage of the F# asynchronous computation expressions in C#?  The answer, surprisingly is YES!  I had the opportunity to talk to F# developer, Brian McNamara, on this very subject.  Back in May, he posted a quick example of using the F# libraries from C#.  There is a bit of work required to do this, but it pays off handily.  I'll cover the exact details in my next post of how to do it.  But, in the mean time, imagine if we could download HTML from three websites simultaneously using LINQ?  Here's what the code that does exactly that looks like.

How simple is that?  Well, we have to put some backing to some of these methods in order to make them asynchronous, and I will cover exactly what that is in the next post.

Wrapping it Up

What about such things as the IO monad?  Well, that's more of a language construct that is enforced by the compiler.  I would like to see something similar to this in F# going forward, so that we could better manage our side effects.  Using such technologies as Spec# to statically verify the behavior is important.  But, once again, that's another post.

I hope I helped to alleviate some of the confusion around monads.  More importantly, I hope you know more of how and when to use them.  In the next post, I'll follow up with the actual implementation of the asynchronous computation expressions in C# 3.0.  Giving us the ability to have parity with F# is really powerful and attests to the power of LINQ (and monads of course).  Stay tuned!

Have just started a new project and my first task is some Silverlight thingamajig that I'm sure I'll go on about ad nauseum in the coming weeks. But first, let's talk about some ReSharper settings.

My very first check-in in the code base was a ReSharper code style settings file. This is a way of allowing everyone on the team uses the same settings. The documentation for this feature is here though it's a little out of date. To the right is a screenshot from version 4.1.

This is somewhat important for me because I have some different ideas about whitespace than most people. And I don't want to impose my will on someone else. (At least not so crudely.) Nor do I want to alter my own personal projects just because everyone else likes to have all their code scrunched up together so that parentheses and curly braces essentially take the place of spaces and you need a &*%$ Little Orphan Annie Decoder Ring to parse out the actual meaning of these god-forsa--...

Ummm...let's just say I'm a little set in my ways and move on...

By default, your ReSharper settings are global across all projects. The two other settings are: a) Shared across the team, per solution, and b) Not shared, per solution, stored in a file.

Both are very useful in teams where developers work on more than one project, such is the case here. The other obvious example is open-source projects. Here's a quick run-down of each.

Shared across the team, per solution

Here, the code style settings are stored in a .resharper file in the same folder as the .sln file. This is ideal for a non-intrusive way to enforce coding standards on a project. Developers download the source and go. They may not even know it's using a shared code style.

MvcContrib uses this mechanism to enforce standards. I'm not on the new project because I've added .resharper files to my global SVN ignore list and I'm too lazy to change it. Plus, I'm not quite sure how it works between ReSharper 4.0 and ReSharper 4.1. I.e. is it able to manage users that use 4.0 and others that use 4.1? And what happens when one user changes the settings inadvertently? As an example, I just updated to the latest MvcContrib, opened it up, and now I have MvcContrib.4.1.resharper checked out for some reason.

So instead, we're using the next option.

Not shared, per solution, stored in a file

With this option, you explicitly tell ReSharper where the settings are stored. It requires a little more work to set up. Unlike the previous option, the developer needs to go into the ReSharper settings and physically select this option and navigate to the file. It takes an absolute path, not a relative one.

I'm guessing that this is because the settings to tell ReSharper which option to use are stored in the .resharper file, which as I've mentioned, we're not including in source control.

Both options give you the ability to set standards like naming conventions, spacing, and, theoretically, how to re-order methods, fields, and properties within your class. I say theoretically because this particular one (under Type Members Layout) seems a little eccentric. I had to import the settings from the code style file, then shut down and restart the solution for them to take. And when I make changes to this section, they aren't always reflected in the settings file.

None of this guarantees that your code will be consistent. After all, not everyone may have ReSharper. Also, I'm pretty sure the settings to auto-format are machine specific so someone could turn them off and then you have to rely on them to do an explicit auto-format before they check in. Furthermore, it appears that formatting profiles are also machine-specific, so even if you create one that runs through all your rules, re-orders things, and otherwise cleans up when you press Ctrl+Shift+Alt+F, that won't get propagated to anyone else's machine.

Kyle the Styled