ALT.NET

ALT.NET Open Spaces Closing Day Recap

Matthew Podwysocki — Thu, 24 Apr 2008 06:20:38 GMT

In my previous post, I talked about some of the happenings from the day two experience. Day three was only a half day with only two sessions. So, it was best to make the best of times anyhow. Once again, it snowed again, rather heavily at times, so nature's cruel joke on ALT.NET.

Impromptu Sessions

One of the best sessions was an impromptu session with Jeremy Miller on the StoryTeller tool and his future plans for it. If you're not familiar with it, it is a tool used to manage and create automated testing over the FitNesse Dot Net libraries and helps in an acceptance test driven development environment. Anyhow, a number of us managed to corner him at one point during the day and sure enough he had his laptop available. From there, we were able to encourage him to work on it some more as well as learn about where to go from where it is right now. Jeremy covers more about it here. Sometimes these impromtu sessions are some of the more valuable interactions to be had at events such as these.

More Video To Be Had

It seems that almost everyone had a camera at the event. Greg Young and Dave Laribee managed to capture a bit of the sessions on video. That's a great thing because I honestly wish I could have cloned myself and gone to more sessions. Hopefully more of this will be forthcoming. Dave posted Greg Young's fishbowl conversation on Architecture Futures which you can see here.

Other videos that are on this list are from John Lam's IronRuby session, Udi Dahan with ScottGu and Chad Myers talking about Microsoft and Open Source Software and so on. You can find them at the end of Greg's video.

Software Design Has Failed, What Can We Do About It?

Scott Koon, aka LazyCoder, convened with JP Boodhoo a session on how software design has failed us. This turned into a fishbowl conversation as well since there was a lot to be said. The basic points revolved around the large amount of software failures. What causes them? Are they technological issues? People issues? Politics? Many people brought their opinions to bear, and it was interesting that the point that I brought is that at the end of the day, customer satisfaction is the metric that matters. Are we listening to them? In the Agile methodology world, customer satisfaction is the only metric. Yes, we can talk about TDD/BDD, DDD and so on, but are we actually putting software into the hands of the user that they actually want?

I'm not forgetting of course the ideals around mentoring and helping make the team stronger. Those issues are important as well. Do we do pair programming? Do we hold brown bag sessions? All of those suggestions are key to helping grow a stronger team. But, also it helps grow the team as a more cohesive unit that's not afraid to ask questions, pair up and avoid flailing.

F# and Concurrency

Roy Osherove convened a session on concurrency and functional programming as the last topic I was going to attend. When we start to deal with multi-core environments, threading issues come to bear more frequently. Are we utilizing the CPUs to the maximum or are we still just sitting on that one thread, and barely using the machine to its capacity? Those are many of the issues we face. In Software Engineering Radio Episode 14, Ted Neward talks to this very point quite frankly that multi-threaded programming is hard. There are no two ways about it. But, when we talk about functional programming, some of that is solved. Why? Immutability by default is one of the key strong points of FP. Instead, you have to go out of your way to make a value to be mutable. Is this something we'll see in C# 4.0? Spec# has something to say about it. And once again, another topic for discussion. I keep putting these things on my plate...

Anyhow, Harry Pierson and I helped run this session. Harry had some of his parsing code that he has posted on his blog to show off. I think that did the trick well to show some advanced things such as high order functions, pattern matching, anonymous functions and so on. Instead, if you wish to learn more, I'll probably cover it here in some detail, but you can check chapter 13 of Don Syme's "Expert F#" book to learn more in the mean time.

Action Items

Some action items came up from this event that I think are rather important. Because ALT.NET is a community looking to improve itself, there are naturally some things that help. Here are a few that I can think of:

Keep the conversation going
Just because the conference ended doesn't mean the conversations that started there have to.
Start a local group
After the session was done, the altdotnet mailing list came alive with people wanting to create that ALT.NET groups like I did in DC, Brian Donahue did in Philly and Jeremy Jarrell did in Pittsburgh.
Support the community
Ray Houston laid out a challenge for those who use Open Source products to donate to them. This doesn't mean only money, but time as well. Many projects are in need of some assistance, and all it takes is for someone to ask.
Challenge Assumptions and Bring Change
It was said best during the conference "If you can't change your job, change your job". Don't let these discussions that happened here just stay there. Bring them to your work place, bring change for the better. Question why things are done the way they are.

Wrapping it Up

I'm glad to have been a part of this event in Seattle. It couldn't have been with a better bunch of people who are willing to better themselves, challenge themselves and their assumptions and bring change to the developer community. There was a lot to learn this past weekend and each conversation brought up a new angle. Until next time...

ALT.NET Open Spaces, Seattle Day 2 Recap

Matthew Podwysocki — Tue, 22 Apr 2008 23:14:41 GMT

In my previous installment of recapping the events from ALT.NET Open Spaces, Seattle, I covered pretty much the opening ceremonies as it were. The weather was definitely interesting the entire weekend. Who would believe that we had snow, hail and rain for most of the time we were there in the latter half of April? Mind you it didn't stick, but if you believe in God, there is something to be said of ALT.NET coming to town.

Coverage Galore

Jeffrey Palermo was gracious enough to capture the opening ceremonies on video for all to see. Here are some of the videos and they are well worth watching. Really gives you an idea of how to run a good Open Spaces. Doc did a wonderful job as a facilitator for the event. And yes, that's me in the black coat in the background setting up for the event.

ALT.NET Open Spaces, Seattle - Part 1
An introduction by Doc on the meaning of Open Spaces
ALT.NET Open Spaces, Seattle - Part 2
More introduction and the suggestion of topics. Everyone who submitted topics had to get in the middle of the room and declare their topic of interest.
ALT.NET Attendees - Why Did You Come to ALT.NET?
Jeffrey interviews various attendees such as the some Microsofties (Scott Guthrie, Harry Pierson, Glenn Block, Don Smith), CodeBetter guys (Greg, Jeremy, JP Boodhoo, Ian Cooper), Scott Bellware, the Israelis (Udi, Roy, Justin and Ayende), Martin Fowler, John Osborn, Jim Shore, etc on what ALT.NET means to them and why they came.

Dave Laribee also has a ton of video as well. Most recently, the Fishbowl conversation about the polyglot programmer has been posted here. The debate starts with Jeremy Miller, Ted Neward, Charlie Calvert, Scott Hanselman and others. Really good conversation posted.
So, as you can see from the videos it was a pretty diverse crowd. And, hey, we managed to get all of 5 women there too! Peter Laudati posted the schedule here which was initialed by all who wanted to see that particular discussion.

IronRuby Session

Since John Lam wasn't around on Friday for the topic submittal, I so graciously put his name in for him. Luckily he agreed so we were good to go for the first session. We didn't have any canned presentations which is nice. Instead, John focused more on how far IronRuby has yet to go. It was interesting that he is using the Rubinius specs in order to validate IronRuby. Also of note, it was pretty cool to see that Spec# has been used for the IronRuby compiler.

Covering Spec#

Unfortunately, the functional programming talk that I planned with Dustin Campbell was put right along side the Spec# talk, so I had to make a choice. I picked Spec# as it was the first Open Spaces they had done. As I said before, one of the major things I wanted to talk about was Spec# at ALT.NET. Both Greg Young and I were pretty interested in getting Rustan Leino and Mike Barnett to show off the technology to the masses. And what better way than to show a bunch of geeks like us this technology. Anyhow, Mike and Rustan did a really good presentation to show off Spec# to a mass audience. For those not familiar with Spec#, I did a whole series on this on my old blog here. Basically, the intent of Spec# is to provide Design by Contract specifications in your classes and have that exposed to the outside world. So, no more guessing about the preconditions, postconditions and invariants of your system, instead, we can be pretty explicit about it.

The problem that they are facing is that Spec# is not just an additive to the C# compiler, instead it's a separate compiler that is compliant with the C# 2.0 specification. The problem is that C# 3.0 introduces a few more items, albeit mostly syntactic sugar for the most part, and yet Mike is really one of the only guys doing the Spec# compiler. So, making it C# 3.0 compliant is a pretty daunting task. Instead, a future focus is on making language neutral pieces available to all .NET languages just as we saw briefly in the System.Core.dll assembly under the Microsoft.Contracts namespace. The point of inviting them was to help bring their cause to a wider audience. Anders Hejlsberg and Mads Torgersen need to put this on their mind as to how to incorporate, and I'll make sure it's widely known.

It was great to see Scott Hanselman quite excited about the technology and hopefully you'll see more of it from him soon. Also, stay tuned to InfoQ for more Spec# related items as well. I intend to cover things again shortly to talk about some other new things in Spec# as well as the new release. Stay tuned for that...

ASP.NET MVC

Phil Haack and Brad Abrams hosted a discussion on ASP.NET MVC which was pretty positive overall. There has been a number, around 5% that Microsoft has been throwing out there as a number of people that would be adopting ASP.NET MVC over traditional web forms. The audience was rightly skeptical of such a number and wish that they would cut it out. Instead, it could have the effect of scaring away people from adopting this framework as their choice for ASP.NET web applications. I can totally understand that the numbers could be there due to the ISV market which make controls for ASP.NET web forms which is something that the MVC framework doesn't support. Another request was to support open source javascript frameworks better. But overall, Phil and Brad were pretty receptive and it was an overall positive experience.

Are We Innovating?

Scott Hanselman convened a talk asking "Are We Innovating or Are We Just Porting?" in which that very question was asked. If you look at the open source frameworks that exist within the .NET space, it's not hard to see what he's talking about:

JUnit => NUnit, MbUnit, xUnit.net
Hibernate => NHibernate
Spring => Spring.NET
Ruby on Rails => MonoRail
jMock => NMock, Rhino Mocks, Moq
And the list goes on...

But when you look at the list the other way around, we really don't see it going the other way. Is it because that in the Java world, frameworks weren't provided by Sun as they were for Microsoft? Or was it something else? The answer of course isn't easy and maybe it's not in the frameworks area that we need to look. For example such applications as Paint.NET is truly innovative in my opinion. I wouldn't have half the picture content on this blog as easily without it. Also, some open source blogging engines work quite well as well. So, there is innovation, but if you look to recent times, have we caught up?
To Be Continued...

DC ALT.NET Meeting 4/23/2008 - Jay Flowers and CI Factory

Matthew Podwysocki — Tue, 22 Apr 2008 04:38:51 GMT

Now that we've somewhat recovered from ALT.NET Open Spaces, Seattle, it's time for another DC ALT.NET meeting. I'm currently finishing up my wrapups for Seattle still and I'm sure I have months worth of material from there. Anyhow, this time Jay Flowers will be talking to us about Continuous Integration and CI Factory which was postponed from last month due to schedule conflicts. As always we have the first hour or whenever the conversation ends for our main topic and the rest is Open Spaces. Food will be served as well.

Below are the details for the meeting:

Time:
4/23/2008 - 7PM-9PM

Location:
2201 Wilson Blvd
Arlington, VA 22201Archstone Aparaments

Parking/Metro:
Best parking on N. Veitch St
Courthouse Metro the best bet

As always you can find out more by joining the mailing list here. Hope to see a great crowd there and to continue some of the great discussions that were held in Seattle. Until next time...

ALT.NET Open Spaces, Seattle Day 1 Recap

Matthew Podwysocki — Mon, 21 Apr 2008 02:56:16 GMT

ALT.NET Open Spaces, Seattle has come to a close. What a great time it was and it met every expectation if not exceeded them. Currently I'm in the Seattle airport waiting for my flight home which just got re-arranged. Anyhow, I'd like to wrap up my thoughts for the first day of the event.

Setting It Up

I arrived one day early for the event to make sure we were set up appropriately. I was able to meet up with Dave Laribee, Glenn Block, Scott Bellware, Jeremy Miller, Greg Young, Scott C Reynolds, Ray Lewallen, Patrick Smacchia and others. Everyone was already burned out from the MVP Summit, so I wasn't sure how well people would be for the event. But it was great to talk to Sam Gentile and I'm glad he's back in the fold with ALT.NET as he announced earlier last week here.

Even though a lot of people were tired, we had plenty of help to set up for the event. Of course the joke is that "How many ALT.NETers does it take to go to Costco?"...

Kicking It Off

One couldn't ask for a more prepared and outstanding facilitator in Steven "Doc" List. What an amazing job he did to bring the Open Spaces together. The event started with a description of Open Spaces Technology. if you're not familiar with the Open Spaces, Technology Format, here are the four basic principles:

Whoever comes are the right people
Whatever happens is the only thing that could have
Whenever it starts is the right time
When it's over, it's over

With that getting kicked off, we then laid out the pens and sticky paper to write the sessions. The idea is to write down your idea on the sticky paper and then get to the middle of the room and announce your talk that you will facilitate. Of course some subjects may be very similar and can be combined, which happened quite a bit actually.

The Sessions

I met with Mike Barnett from the Spec# team who was one of the many people I had invited to this event. Spec# as you may have figured from my blog is a passion of mine. It is one of my goals to publicize it enough and to make sure that people are aware of this wonderful technology that the product teams such as Mads Torgersen and Anders Hejlsberg notice. Anyhow, Mike went up and announced a session on Spec# and static verification. I'll cover more of that in subsequent posts again. Start your letter writing campaigns now!

Dustin Campbell also was in attendance and he and I chatted about F# and doing a session on functional programming and F#. It was going to be a great session, but unfortunately when the schedule was finalized, I couldn't possibly attend the Spec# and functional programming and F# talk. I was a little disappointed by that, but luckily Roy Osherove suggested a talk about "Concurrency and Functional Programming" which I was more than willing and able to help out on. I also pulled Harry Pierson, the new Program Manager for IronPython to help in such a session.

Since John Lam wasn't in attendance that night, I volunteered him for a session on IronRuby and the DLR which he was more than happy to oblige. We scheduled that for the first session on Saturday. I'll cover each of these in detail in subsequent posts.

The Fishbowl

From there, we went to a fishbowl style conversation in which there are a number of chairs in the middle of the room. There must be all but one of the chairs filled at any given time. Any person may in turn come and take a seat and another person must leave to keep the balance. The discussion started with Scott Hanselman, Ted Neward, Charlie Calvert and Martin Fowler talking about the Polyglot Programmer. Ted Neward couldn't be there for the whole event, unfortunately as he was also doing No Fluff Just Stuff this weekend as well with Venkat Subramaniam, Neal Ford and others. Luckily I got some time to talk to Ted about some F# related items as well as his upcoming trip to Reston, VA for No Fluff Just Stuff next weekend. So, if you're in the area and interested in seeing Ted and Venkat, that's the place to go! But anyways, the event was great and a lot of people pitched in. There are so many to name, I'd just run out of space.

To Be Continued....

Off to Seattle and ALT.NET Open Spaces, Seattle

Matthew Podwysocki — Thu, 17 Apr 2008 15:53:09 GMT

Well, the day has finally come where I'm heading to ALT.NET Open Spaces, Seattle. It's been a long time of planning for this day with all the other guys mentioned on the site. The weather's not looking so great with a possibility of snow on Saturday. Not looking forward to that part as I'm leaving sunny, beautiful Washington DC where it is around 75F or so right now.

I hope to be live blogging much of the event, well as much as I can. I you're on Twitter, you can follow me at mattpodwysocki. Looking forward to seeing everyone there!

Adventures in F# - F# 101 Part 8 (Mutables and Reference Cells)

Matthew Podwysocki — Tue, 15 Apr 2008 23:08:37 GMT

Time for another adventure in F#, covering some of the basics of functional programming and F# in particular. Today we'll manage to look more at regular .NET integration and .NET programming. With the previous efforts, we've looked more at functional programming and in turn F# specific things, but want to show that you can do anything normally in F# that you can in C#. To me, F# is the perfect all-purpose language because it can do a lot of the things C# can do, but in turn, F# can do things much more elegantly than C# can, such as Pattern Matching.

Where We Are

Before we begin today, let's catch up to where we are today:

Today's topic will be covering imperative and object oriented programming in F#. There is a lot to cover, so let's get started. But there are a few administrative things to get out of the way first.

Learning F# ala Ted Neward?

Ted Neward recently announced on DotNetRocks Episode 332 that he's in the process of creating a class for F# for Pluralsight. That should be interesting to those who are interested in this series, as well as F# in general. Right now the community is rather small, so efforts like this should be rather rewarding I would hope. Ted's a pretty brilliant guy, so I'd imagine only the best. I'm hoping more details come out soon.

Pattern Matching in C#

Part of this series is intended to bring such concepts as Pattern Matching, Currying and other Functional Programming concepts to the C# developer. After all, the more C# language evolves, the more it seems to fall into the Functional Programming category. In previous posts, I showed how to relate currying to C# and it was less elegant than F# to say the least.

But, let's look at Pattern Matching. Bart De Smet has been posting recently on his blog about bringing the beauty of pattern matching to C#. So far it's been a good six posts into it and I urge you to go ahead and take a look at this series.

But when you read the series, it's all about getting into the low level and compiling expression trees to make the same simple beauty that is F#. Sure, it can be done in C#, but nowhere near as elegant. Performance is another issue that comes to mind with these.

Imperative Programming in F#

This section I'll lay out some of the basics of imperative style programming before I get into the full object oriented approach to programming. So, we'll cover just a few topics and then I'll feel comfortable moving onto the real parts of creating classes and such. We'll cover such things as void types and mutability in this section.

The unit Type

One of the first things I forgot to mention when describing F# functions and values in the unit type. Think of this as the void type in C# that you are used to. It's the type that doesn't accept or return a value. First, let's look at the typical C# program with the void type for Hello World.

    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World");
        }
    }

Now, let's go ahead and look at it from the F# perspective.

#light

let main() =

  printfn "Hello World"

main()

As you will see when you hover over our code is that it is a unit type. That in itself isn't all that interesting. But, what we'll run into is problems when functions return a value, but we're not all that interested in them. What happens? Well, F# will complain that your return value isn't compatible with the unit type, which is essentially true. So, how do you get around that? Let's walk through a simple unit test of a Stack written in F# and unit testing with the xUnit.net framework.

#light

#R @"D:\Tools\xunit-build-1252\xunit.dll"

open System

open System.Collections.Generic

open Xunit

type Stack<'t> = class

  val elements : LinkedList<'t>

  new() = { elements = new LinkedList<'t>() }

  member x.IsEmpty

    with get() = x.elements.Count = 0

  member x.Push element =

    x.elements.AddFirst(element:'t)

  member x.Top

    with get() =

      if x.elements.Count = 0 then

        raise (InvalidOperationException("cannot top an empty stack"))

      x.elements.First.Value

  member x.Pop() =

    let top = x.Top

    x.elements.RemoveFirst()

    top

end

[<Fact>]  

let PopEmpty () =

  let stack = new Stack<string>()

  Assert.Throws<InvalidOperationException>(fun () -> stack.Pop() |> ignore )

The real interesting part you should pay attention to is the last line. As you can see, I am using the forward operator to indicate that I really don't care what the function returns, just that I'm interested in that it executes. This is most likely during such functions that have some sort of side effect to them. I could also use the ignore function instead of the forward operator such as this:

[<Fact>]  

let PopEmpty () =

  let stack = new Stack<string>()

  Assert.Throws<InvalidOperationException>(fun () -> ignore(stack.Pop()) )

This is very helpful in these cases where we really don't care about the return value, instead want to mutate the state of our given object, such as removing a value from a collection and so on.

Mutables

As I said in many posts before, by default all "variables" by which I mean values in F# are immutable. This is a standard in functional programming and all in the ML family. You can easily redefine a value by using the let keyword, but not actually mutate its state. But, since F# is a multi-purpose language on the .NET platform, mutable state can be had. To take advantage of this, mark your value as mutable. Then to change the value, just use the <- operator to reassign the value. Below is a simple example of this:

#light

let mutable answer = 42

printfn "Answer is %i" answer

answer <- 8

printfn "Answer is %i" answer

A key difference from the reassignment is that you cannot change the value type. Whereas I can redefine answer by keep using the let keyword, I can only keep my answer in this above example of the int type.

This can also apply to record types as well where you can change the fields. In the last installment, we talked about record types. Well, by default there as well, the fields for the record type are immutable. But, as with before, that can be changed. I of course like to caution people that mutable state takes a lot of the value proposition away from the side effect free programming that you gain with F# by default. But, nevertheless, you can still do it as noted below:

#light

type Person = { FirstName : string; mutable LastName : string; mutable IsMarried : bool }

let friend = { FirstName = "Courtney"; LastName = "Cox"; IsMarried = false }

friend.LastName <- "Cox-Arquette"

friend.IsMarried <- true

What I was able to do was define a Person record and change a couple of fields while using the <- operator and defining the fields as mutable. Yes, I could have used some scientific calculation or something, but this was easy.

Reference Cells

The last thing I want to touch on in this post is reference cells. You can think of these much as pointers in other languages or reference types. These of course can be of any type. The idea behind using these is to make updating fields as easy as possible. As with mutable fields, you cannot change the type once it has been assigned. To use these, you need to remember three basic operators

ref - Allocates a reference cell
:= - Mutates a reference cell
! - Reads the reference cell

Below is a quick example of mutation through reference cells:

#light

let x = ref 2

x := !x + 25

printfn "%i" !x

What the code example above lets me do is define a reference to the number 2. Then I can change that reference by reading the current x value and adding 25. Then I mutate the existing x value with the result.

Conclusion

This is just meant to be a brief overview to some imperative programming constructs that you might see in .NET, Java, C, C++ and so on. F# is a first class language all the way with constructs that support these things as well as your normal functional programming constructs. I hope we get to cover some of this at ALT.NET Open Spaces, Seattle at some point because I'm sure a lot of people will be interested. Until next time...

ALT.NET on DotNetRocks and the Community

Matthew Podwysocki — Tue, 15 Apr 2008 18:12:09 GMT

Dave Laribee and Jeremy Miller recently recorded an episode on DotNetRocks and was just posted today. Episode 333 "It's the ALT.NET Show" can be found here. It's a great show that explains ALT.NET for those who may not really know what it is outside of some of the arguments on the altdotnet mailing list. This includes discussions on open source frameworks, agile practices, refactoring and so on.

It's great to see the reaction from this show at least from my perspective. To see the job we're doing from Josh Holmes, Glenn Block, me and others from within to reach out and also present ideas and bridge the gaps. It's been very rewarding to be a part of that.

We're only just a few days away from ALT.NET Open Spaces, Seattle. All of those who are attending should have received a notice of such this morning. I'll be arriving in Seattle on Thursday afternoon to help set up for the event so if anyone wants to hang out beforehand let me know.

Bringing It To The Community

Anyhow, this weekend I did my best to bring some of those ALT.NET practices to the CMAP Code Camp and we had a pretty good turnout. This time I talked about refactoring to patterns, dependency injection and inversion of control containers. I'm hoping to do the same for the Northern Virginia Code Camp coming up on May 17th. Brian Donahue has been rather successful doing so with the Philly Code Camps as well. That reminds me that I'm coming up there in mid-May to do an F# session. Should be a fun time.

Unity Community Contributions and Interception

Matthew Podwysocki — Fri, 11 Apr 2008 23:35:05 GMT

Now that Unity has been released into the wild, there has definitely been a bit of interest swirling around it. One of my key wants for a good IoC container is basic interception capabilities. My criteria for evaluating a container usually comes down to the following:

Configurability (XML, DSL, Code)
Dependency Resolution, usually opinionated
Lifetime Management (Per Thread, Pooled, Singleton, Transient, etc)
Extensibility for Interception

So, I realized that Unity was missing some of these things in the first go around. Since Unity was built on top of ObjectBuilder2, a next generation version of the often maligned ObjectBuilder which also included some sample DI containers and a flexible interception model. Today's post will cover that and a bit more. I realize that I still am working on a post of AOP in the Enterprise and Spring.NET which is coming soon.

Where We Are

But, before we begin today, let's see what we've already covered in the past:

Unity 1.0 Released into the Wild
Unity 1.0 released and available on MSDN. Unfortunately, registration is required...
IoC and Unity - Configuration Changes for the Better
Covers the configuration changes to allow for better parameterization for constructors
IoC and Unity - The Basics and Interception
Talking about the basics of IoC containers and the interception models
IoC Container, Unity and Breaking Changes Galore
Covers the breaking changes made from the old Unity drop to the new one
IoC Containers, Unity and ObjectBuilder2 - The Saga Continues
Managing instances and parameter mapping resolution
IoC and the Unity Application Block Once Again
Setter Injection versus Constructor Injection and PostSharp4Unity
IoC and the Unity Application Block - Going Deeper
Constructor Injection and comparing Unity with Castle Windsor
IoC and the Unity Application Block
Covering ObjectBuilder and Unity Application Block

Now that we've look at the history of this series, let's go ahead and get started.

Unity Contributions

Since Unity was released last Friday, there has been a community effort much like the ASP.NET MVC Contributions, MVCContrib, called Unity Community Contributions. This project is intended to fill in the gaps where the community feels that Unity can be extended, much like most other IoC containers. As I stated above, one of those crucial things that I thought was missing was taking the ObjectBuilder2 Interception model and applying it towards Unity. I wasn't interested as much in the Policy Injection Application Block, although nice, is a bit heavyweight for the basic operations I would like. Instead, the OB2 would suffice for most things that I'd want with a container. So, that led me to another topic...

ObjectBuilder2 Interception == Unity Interception?

Since I was particularly motivated to see the OB2 Interception model pushed into Unity, I decided to give it a go myself. For the most part, I was successful in a way, but I wasn't using the right extensibility model. From that point, I got in contact with Scott Densmore, a PM within the Patterns & Practices group and one of the authors of ObjectBuilder2 along with Brad Wilson. From that point, he was able to take the original OB2 Interception model and fit it nicely into the Unity extensibility model. The code is now available on the Unity Community Contributions and you can find those commits by Scott here.

So, let's take a look at what it entails. As I tell most people, you learn the most about the software with good unit, I mean behavioral tests where I can really grok the intent of the code much better than most documentation. I encourage most people to do the same. I'd rather stay away from those projects that don't have tests to back up their work.

Like I said before, ObjectBuilder2 had several ways of intercepting calls. There are several interception strategies worth mentioning:

Virtual Method interception
Interface Method interception
.NET Remoting interception (MarshalByRefObject)

From that, you have two ways of registering your interest for interception:

Intercept via code
Intercept via attributes

Now that we've laid down the basics, let's take a look at some of the unit tests. You'll notice that xUnit.net was used for the unit tests. Yes, I know, I've mentioned it a few times lately. Anyhow, let's look first at virtual method interception.

Before we get started on that, in order to perform interception, we need to implement the IInterceptionHandler interface. For the unit tests, this will be used to record the various actions that happened during the interception process. But you can imagine it to do any number of things such as logging, transaction management, security and so on. Any of those cross cutting concerns, really.

    public delegate IMethodReturn InovkeHandlerDelegate(IMethodInvocation call,

                                                        GetNextHandlerDelegate getNext);

    public delegate InovkeHandlerDelegate GetNextHandlerDelegate();

    public interface IInterceptionHandler

     {

        IMethodReturn Invoke(IMethodInvocation call,

                             GetNextHandlerDelegate getNext);

     }

 } 

   public class RecordingHandler : IInterceptionHandler

    {

        readonly string message;

        [InjectionConstructor]

        public RecordingHandler()

        {

            message = "";

        }

        public RecordingHandler(string message)

        {

            this.message = string.Format(" ({0})", message);

        }

        public IMethodReturn Invoke(IMethodInvocation call,

                                    GetNextHandlerDelegate getNext)

        {

            Recorder.Records.Add("Before Method" + message);

            IMethodReturn result = getNext().Invoke(call, getNext);

            Recorder.Records.Add("After Method" + message);

            return result;

        }

    }

We have the ability through the Invoke method to do things before the method as well as after. Should we need to modify values before the method is called, we can go ahead and do so. Now that we looked at that, let's get to some unit tests. First off, let's look at interception through just code. I like this approach as opposed to attributes due to not cluttering the domain model and making it more configurable at run time.

            [Fact]

            public void InterceptViaCode()

            {

                Recorder.Records.Clear();

                IUnityContainer container = new UnityContainer();

                container.AddNewExtension<InterceptionExtension>();

               container.Configure<IInterceptionConfiguration>().InterceptVirtual<SpyVirtual>
                   (typeof(SpyVirtual).GetMethod("InterceptedMethod"), new RecordingHandler());

                SpyVirtual obj = container.Resolve<SpyVirtual>();

                obj.InterceptedMethod();

                obj.NonInterceptedMethod();

                Assert.Equal(4, Recorder.Records.Count);

                Assert.Equal("Before Method", Recorder.Records[0]);

                Assert.Equal("In Method", Recorder.Records[1]);

                Assert.Equal("After Method", Recorder.Records[2]);

                Assert.Equal("In Non-Intercepted Method", Recorder.Records[3]);

            }

public classSpyVirtual

            {
public virtual void InterceptedMethod()

                {
Recorder.Records.Add("In Method");

                }

public void NonInterceptedMethod()

                {
Recorder.Records.Add("In Non-Intercepted Method");

                }

public virtual void ThrowsException()

                {
Recorder.Records.Add("In Method");
throw new Exception("This is my exception!");

                }

            }

As you see above, we can simply register our interest through the registration of the InterceptionExtension and then set up the configuration through the IInterceptionConfiguration. From that point, we then say which kind of interception we want whether it be virtual, remoting or interfaces. We specify the method we want to intercept by name.

You can also do the interception through the use of attributes. From this point, we need to decorate our methods with the attribute and the particular interception handler we want to use. We need to be aware of which interception strategy we're using as well when we decorate our classes. You can intercept methods as well as property accessors by decorating the get or set. Below is a simple example of a virtual interceptor registration.

             public class SpyVirtualAttributes

            {

                [VirtualIntercept(typeof(RecordingHandler))]

                public virtual void InterceptedMethod()

                {

                    Recorder.Records.Add("In Method");

                }

            }

I'm not going to post all of the tests, but I want to give you an idea of the power of this. It's still early in the process and there is some cleanup still going on. But, I encourage you to pick up the source, read it, grok it, give it a try and give feedback.

Conclusion

As you can see, the extensibility model of Unity works in that we can add interception to Unity. So, we can start thinking about moving our cross cutting concerns to these layers should we so choose if Unity is your container of choice. There are plenty of containers out there to choose from, so it's best to give them all a try and pick one based upon features, programming style, and heck, maybe even licensing. I'll be showing some of this stuff off tomorrow at the CMAP Code Camp, so if you'll be at my 1PM session, be prepared. Until next time...

RockNUG IoC Container Presentation Wrapup

Matthew Podwysocki — Thu, 10 Apr 2008 22:10:21 GMT

I want to thank the fine folks at the Rockville .NET Users Group (RockNUG) and Dean Fiala for giving me the opportunity to speak last night. It was a record crowd last night, so I'm glad that people were interested in Loose Coupling, Design Patterns, Test Driven Development, Behavior Driven Development and Inversion of Control containers. I hope everyone got some good information, and if not interested in using containers, design patterns and such, at least know they exist and have their use. Based on the feedback I've already received, it was warming and why I like presenting at user groups, so that both of us can learn.

Once again, I'd like to plug my DC ALT.NET group that I run. Our next meeting is scheduled for April 23rd and the topic will be Continuous Integration with Jay Flowers. We'll announce the location shortly for our group. You can go ahead and sign up for our mailing list here.

Anyhow, here are some resources that can help point you in the right direction. This includes articles, blogs and such that I find will be useful in your journey to better understand these things:

After my CMAP Code Camp session over the weekend, I will go ahead and post my slides and code samples for your enjoyment. So, if you're in the Columbia, MD area this weekend and haven't signed up, go ahead and do so. Hope to see a great crowd there!