Five Min Tech

Speaking engagements

Dave Redding — Tue, 08 Apr 2008 03:36:37 GMT

So, you might have noticed the badges on the left. Let me give you a run down. I'll be presenting the C# Variety Show at the following places, at the following dates...feel like i'm on tour

Lansing .Net Usergroup               April 17th
Central Ohio Day Of .Net                April 19th
West Michigan Day of .Net           May 10th
Eastern Tenn. .Net User Group    June 24th

So, i'm going to be busy. I'm still waiting to hear back from the Cleveland Day of .net and a few user groups in Texas. Keep an eye out, The C# Variety show may be comming to a city near you!

Tech in 5 Minutes: Nifty C# operators that don't get much love

Dave Redding — Tue, 11 Mar 2008 15:31:43 GMT

In my travels around .Net land, I've come to know, love and exploit several denizens of the tribe of C#. Some of these have already been written about, such as Yield return and the => operator. But more recently, I've had the opportunity to educate some fellow travelers on two of the most useful, but least used operator. Those being the Comparison Operator (?:) and the Null Coalescing Operator (??).

Lets start our adventure by watching the Comparison Operator in it's natural environment. If you watch closely, it'll show you it's syntax...

bool statement ? true : false

Due to it's nature, this operator is sometimes called the Ternary operator. The reason being is that it takes 3 operands. In normal use, here is what it looks like:

CurrentBeer.Empty==True ? CurrentBeer = Wife.GetMebeer() : Me.TakeDrink(CurrentBeer);
(this can be shortened further by taking out the ==True, since .Empty is most likely a bool property)
CurrentBeer.Empty?CurrentBeer=Wife.GetMeBeer():Me.TakeDrink(CurrentBeer);

You can see how this replaces the overly verbose syntax of :

If(CurrentBeer.Empty)
CurrentBeer = Wife.GetMeBeer();
else
Me.TakeDrink(CurrentBeer);

Syntax sugar? Maybe. But it's definitely useful as a quick way to get things done. Elegant, Efficient and Desirable, three features my first girlfriend was lacking in.

But wait! Theres more! Just send me three easy payments of $29.95!

So now, lets check out the ?? operator.

The ?? operator has saved me boat loads of finger_impact_on_keyboard stress ever since the advent of C# 2.0. It's easiest to think of this operator working similar to the comparison operator above. Lets lift it's skirt real quick and have a peek at how it functions

x = ValueThatMightBeNull ?? DifferentValue;

Ok, much like the first time you played doctor, things might be confusing, but it's really simple. Basically the ?? will evaluate whether or not the thing to the left of it is null, if it is, it will evaluate and return the thing on the right. Lets just see it in action, it's easier that way...<Dear "Usually offended by my posts": Please Insert vulgar joke of your choice here>

//This is how my wife found me
Mate SuitableMate = Mate.Get(GoodLooking)??
                                      Mate.Get(AverageLooking)??
                                      Mate.Get(DoesntHaveAnAssForAFace)??
                                      Mate.Get(AtleastHeHasAJob)??
                                      Mate.Get(Dave)

If your confused, let me lighten things up for you hear. Each A = B??C statement is the equivalent of saying

If(B != null)
A = B;
else
A = C;

So when we string them together like that, it's just like saying If = null else if = null else if = null etc etc etc... So, obviously, based on our previous statement, everything up to Mate.Get(Dave) must have returned null if my wife wound up with me. I do have a job now though....so I wonder if i still would have made the cut.

There is one more benefit of using the ?? operator that I actually stumbled across. Take this code as an example:

public class DataObject
{
public NullableObject a = 1... etc
}

public class BO
{
public NullableObject Stinks= 0;

public static implicit operator BO(DataObject e)
{
return new DataObject{Stinks= e.a};
}
}

now...later on in the UI of the app (which should NOT have ANY reference to the DataObject class) if we write this code:

If(MyBo==null){Console.WriteLine("WOO HOO, You have no BO!!");}

..were going to get a compiler error. The reason being, as far as I understand (hopefully commenter's can expand on this) is that when you compile that statement, the compiler is doing type checking against the objects used in the class your checking for null in. In other words it checks to see if anything is returning null from within the class. Now, since the operator takes a type of DataObject, the complier expect you to have a reference to that class...if you don't, then *Poof* no compile.

Now, to get around this, we can write...

SomeoneElsesBo = MyBo??(MyBo = new BO());

....And the compiler is happy.

Hell, we can even put these two operators together, check this out:

Mate SuitableMate;
Step Next_Step_In_Life = ((SuitableMate = Mate.Get(GoodLooking)??
                                                                                Mate.Get(AverageLooking)??
                                                                                Mate.Get(DoesntHaveAnAssForAFace)??
                                                                                Mate.Get(AtleastHeHasAJob)??
                                                                                Mate.Get(Dave)) == Dave?SobQuietly():null)??(Step)PartyItUpWOOT();

I'll leave you with this. The best places I've found to use the ?? operator is in returning data base fields where the value might be null, here is a quick example and the best way I've found to implement the ?? solution

//First i check to see if the value from the db is DBNull.value
//Dr = DataReader
//Do = Data Object with nullable Types

DO.ValX == DBNull.Value?null:(Int32?)dr[0]
//If you don't get the ? reference after the Int32, no worries, It's a nullable type, and I'll post about it soon.

The reason I do this, is so I can keep the actual DB value in my DataObject, which is supposed to be a true reflection of my data. Later on, in the actual business object, where I don't accept Nullable types I can say this.

BO.ActualValX = DO.ValX??-1;

And Bada-Bing, I'm good to go. Later on, i can pass either -1 or even null back into the DB and repeat this cycle when retrieving my data, it works, and i don't have any logic, other than conversions from DBNull, in my Data Object class.

Tech in 5 Min: TDD: Code, Your Way

Dave Redding — Tue, 11 Mar 2008 15:29:29 GMT

We've all heard the buzz acronym TDD. But has anyone actually put these things to use in a practical way? I know of a couple of guys who have, but for the most part, a majority of developers tend to shy away from this new fangled gadgetry. The main reason, I believe, is that it can be difficult to justify a learning curve when:

A solution in a current ver. of code exists

Management is on your ass to just "Get it done"

Open source projects are a natural contraceptive

Now that I've stated the obvious, lets get on with it.

Requirements, everyone gets them, no one knows how to write them and they are usually so vague that you can tell someone has a huge ass their trying to cover. The biggest pains when it comes to requirements are, the acceptance of a "Moving Target" as part of business, and flaky UI designs in the document. Honestly, does Barbara, the manager of the mail room, really know what the hell a number spinner is or is she just a control freak who needs a coke and a bottle of horse ex-lax to work that stick out?

To put it bluntly, Requirements define the business logic that needs to go into the app. They are not justification for the app, that should have been done long ago. Neither are they "Screens" or "Mockups". Those get done by someone who actually (supposedly) knows what their doing. That may be you, it may not, depends on your shop. Either way, they don't belong in the document.

So, what do these obvious statements have to do with TDD?

Lets start at the top. Typically, in non-TDD terms, when you get the requirements, you start coding. Sure, you look at whats needed, pick out the sticky algorithms and look for logical objects, but ultimately, the first thing you write is:

Namespace Giveme
{
    public class Beer
    {
        public int AndWomen()
         {

Your mileage may vary, but typically you start writing code intended for production right away. And when the boss man speaks, you refactor refactor refactor. What happens after several refactors? Well, for one you've lost an easy way to CYA because none of your code matches the original requirements, it all matches what Boss man said. So now your left, holding the bag while Barbara and the Boss man say "We did our part, the developer is taking to long". At this point you get the "Talk" from someone who has no clue what it is you do, but by god, they know how to manage!

Enter TDD. It may not cover your ass completely, but it may slightly, depends on how big an ass you are. Plus, you'll get your work done a whole lot faster. I know what your thinking...that writing unit tests is as painful as sitting the wrong way on a pineapple (is there a right way?), and it can be. Typically we've been introduced to unit tests by means of testing after development, which goes something like this

Manager: TDD is shiny. Bob, go write unit tests for all our legacy code
Bob: OK, but that will take me several months to complete
Manager: Nonsense, your just making sure working code works, Now, Kiss the ring and get me a pineapple. Then I expect 150% code coverage by tonight!

So Bob goes off and attempts to generate unit tests around the existing code. The existing code has some pretty complex methods which must be refactored out in order to test, so more tests are written. Come to find out the refactored methods need to be refactored again, and again and again....and new objects must be created. This cycle can (and in most cases does) create unstable code. This is what makes developers climb the bell tower, or have the sudden urge to become postmen (if you didn't get that last joke, just move along).

OK, so say your starting a new project. You've learned that unit testing after the fact leads to A LOT of re-factoring, and is a code destroying monster. So you want to avoid that at all costs. The solution? Write your tests first, get them out of the way. The simplest form of TDD is:

Write Test

Fail Test

Write Code to pass test

Pass test

Refactor to nice code

Go To : 1

Otherwise known as

1.) Red
2.) Green
3.) Refactor

So here is how it helps you. (I'm diggin' the numbered lists today)

1.) Unit Tests are tied to the requirements
2.) Writing tests first ensure you write ONLY the functionality you need
3.) 1 + 2 = quickly written solid code .

Here's how it works. First off, before writing any code for production at all, you break down your requirements into subsections, and then break those down. so on and so forth. Once your at the smallest bit of requirement (determining how much beer it would take for individual A to take individual B home in this instance), then you write a unit test that specifies how your method will act and look from the outside:

public void BeerGogglesTest()
{
       //We really should atleast have a container class
       BarFlys bf = new BarFlys();

        //What we expect the method to return given the inputs
       double expectedValue = 20;

       //Test constants
       //We'll talk about the whole "Mock" thing in a second.

       int Dave= new MockPersonDave();
       int DavesWife=new MockPersonDavesWife();

       double BeersAlacContent = 7.5;

        //Here we check
        double HowManyBeers = bf.NumberOfBeers(BeersAlacContent, DavesWifes,Dave)

        //Here we assert the value we received was the value we expected
        Assert.IsEqual(expectedValue,HowManyBeers);
}

So...now you compile that. Yes, before writing any more code. Of course the test fails with a few exceptions. Your first task, get rid of those exceptions. With TDD, your essentially coding to your implementation, or API. Similar to coding to an interface. So every bit of your application comes down to ,"Write enough code, just barley enough, to legitimately pass the test"(notice i said Legitimately, so all you smart asses who would return 20 every time need a lesson pineapple-fu). In our scenario above, we would need to implement a public BarFlys class with one and only one method. That method would only take the 3 parameters listed. Don't worry about extensibility or any fancy OOP crap yet. That will come in time....maybe.

public class BarFlys

{
    public double NumberOfBeers(double AlacConsistancy, IPerson p1, IPerson p2)
    {
           double p1DesireToLeave = CalculateDesire(p1.InitialInhibition,p1.alacholConsumed,p1.tolorance);
           double p2DesireToLeave = CalculateDesire(p2.InitialInhibition,p2.alacholConsumed,p2.tolorance);

           return Math.Sqrt((p2.CalculateDesireAbility(p1) + p2.DesireToLeave)/p2.tolorance)*p2.CommonSense
    }
}

As an important aside, we must have already written tests for CalculateDesire in order for this to be a valid test run. We'd want to test it in the same manner we are testing "NumberOfBeers." If we didn't test those method first, then we may end up skewing our test results if there is a failure in one or both of them. Meaning NumberOfBeers would fail, but only because a Dependant method failed.

Once you pass that test, you move onto the next test. And continue on until you have a nice little set of tight, solid code. After wards, you begin to refactor. But, at this point, refactoring isn't about design changes. Your design has already been defined by your tests. Instead, you can focus on the real things, like optimizations and readability.

So, what are these "Mock Objects" I was going on about earlier? Well, Mocks can warrant their own blog post in- and-of themselves. But here are the essentials. A mock object works just like a bottle of O'Dules or Coors Light, it's a fake implementation of a real solid object. Take this for example: You need to develop the front end to a website that runs exclusively off of web services. However, like most developers, the guy working on the services was hit by a bus or married a super model (your choice, i for one vote bus, that still leaves me the opportunity to meet this super model turned on by developers).

Management has threatened to stop paying you if you don't get off your ass and start writing that front end. The Solution? "Mock" the web services. Essentially, your going to write an object that mimics the behavior and implements the interface of what the web services are supposed to look like. Your also going to have those mock objects return data in the same format that the web services would.

Now, granted, it didn't take that many beers when I first met my wife. However, I think her common sense had some environmental issues to contend with, like she just saw dirty dancing or some other chick flick. Either way, I beat the odds :)

Tech in 5 minutes: Overloading Operators is Nifty!

Dave Redding — Mon, 05 Nov 2007 17:36:33 GMT

Welcome back to our newest installment of Tech in 5 minutes. Today were going to discuss the age old question that every modern family has to confront:

Excellent point...however, not today, I meant this one.

Special Huggings...yeah in my world that means:

Kid k = mom + dad;

OR Kid k = (mom + alcohol) + (dad+ alcohol)

So now I will be your doctor of love and teach you to make kids. Not only that, but we can illustrate all the major aspects of life via operator overloading, Like The first job, The first Beer Bong, Getting 80% notes on Guitar Hero 2, How to make Peanut Butter-Saltine-Jalapeno pepper snacks, And of course...Puberty (If that rant doesn't seed the search engines, I don't know what will). Hell! we can even calculate the chances of toast falling on the carpet butter side down, and give it a score on the triple half gainer it does on the way down.

Lets get started with the whoopie:

            Man stud = new Man();
            Woman chick = new Woman();
            Alcohol a = new Alcohol();

            Whoopie whoopie = null;
            while (whoopie == null && !stud.IsPassedOut)
            {
                if (stud.studlyness > chick.standards)
                {
                    whoopie = stud + chick;
                    Kid k = (Kid)whoopie;
                    if (k != null)
                    {
                        stud.studlyness.Huavos = 0;
                    }
                }

                    stud += new Beer();
                    chick += new Daquiri();
            }

Pretty accurate eh? So how does it work? Simple. Operators are just basically methods with a single character (Read: Lazy Developer) name. They give us that convenient syntax, but there really is no fundamental difference between

Whoopie whoopie = stud + chick;

And

Whoopie whoopie = stud.Addchick(chick);

Alright, enough alredy, here is how you'd overload that Binary operator:

public static Whoopie operator +(Stud s, Chick c)

//since the + operator shouldn't (but does, remember it is basically JUST a static method)
//care about order of values to be operated on go ahead and overload the reverse method signature

public static Whoopie operator +(Chick c, Stud s);

Now, you can stick either of these methods in either the Chick or Stud class, or one in each. if you try to do both, you'll wind up with an ambiguous reference, since the operator won't know which classes method to call. This is handy since it's a compiler error instead of catching it at runtime. I mean, how embarrasing would it be for Your app to say "Cannot add Man and Woman". It would probably bring up questions about your *ahem* preferences. And if you worked with the same guys I do, you'd hide under your desk,behind the computer. On the flipside, you'd learn how to write code without a monitor. But I digress.

Ok so we can make whoopie, But how do we know to make whoopie? Well simple. The studs studlyness hast to exceed the woman's *Standards*. But, since that will most likely NEVER happen off the bat, you have to get some Alcohol involved. so lets check out the '+=' which actually ends up just being a Binary + operator (Meaning it takes 2 parameters) the '=' part of the operator means we Have to return the same type that were operating on. so this:

stud += new Beer();

can be read as:

stud is = to stud + a new beer in him();

GET THIS MAN A BEER!!!

which ever one gets the point across to you.

we overload this one just like we did with Whoopie:

public static Stud operator +(Stud s, Alcohol a);
{
    s.Studlyness ++; //Same rules as the +=
    return s;
}
public static Stud operator +(Alcohol a, Stud s){return s+a;}

public static Woman operator +(Woman w, Alcohol a)
{
    w.Standards --;
    return w;
}
public static Woman operator +(Alcohol a, Woman w){return w+a;}

In my code, I overloaded these operators in the Alcohol class, It really doesn't matter where you do it, so long as you do it in one of the classes being operated on.

So, standards are lowering, "Confidence" is growing, so how do we know when enough is enough? Well, one of two things have to happen, the guy passes out from drinking to much liquid courage, or they finally his Studlyness surpasses her standards and they find a quite spot in the back of someone's car and act like teenage rabbits on spring break. So, it's easy to check for passed out-y-ness, but what about checking to see if the liquor is working and through a thick set of beer goggles "He could be the one...". Well, we simply check. overloading the '>' operator is just like overloading the '+' operator, with the caveat that, when you overload an operator like '>' or '<=' you HAVE to have the complementing '<' and '=>'. this makes sense right? You cant have a > without a <, that would be fricking crazy!! I mean, it's almost like a 'WT' without the trailing 'F'. The overload looks almost identical to the one for the '+' except you HAVE to return bool (it is a boolean operator afterall).

public static bool operator >(Studlyness studfactor, Standards impossabledream)
{
            //I'm reading on functional programming so i'm TOTALLY in the mood to use
            //these logical operators instead of a standard if/else statement.
            //the & is a logical AND. Meaning that Both sides of the operator have to
            //evaluate to true. to return true (True,True = true, True,False = False, False,False = false)
            return (studfactor.StudFactor > impossabledream.reqStudFactor) & (studfactor.IncomeFactor > impossabledream.reqIncomeFactor);

}
public static bool operator >(Standards impossabledream, Studlyness studfactor){return studfactor>impossabledream;}

then just do the same for the '<' operator:

public static bool operator <(Studlyness studlyness, Standards standard)
{
            //Same as above, this is the Logical OR operator, this retuns true if either
            //side of the operator is true
            //so True, False = True, True,True = true, False,False = false;
            return (studlyness.StudFactor < standard.reqStudFactor) | (studlyness.IncomeFactor < standard.reqIncomeFactor);
}

public static bool operator >(Standards standards, Studlyness studlyness){return studlyness<standards;}

Ok...so now that our beloved, drunk couple can make Whoopie, we need to see what the outcome is. Quite simply, we need to see if the guy is going to loose his Huavos. So, lets just cast. Overloading the implicit casting operator is similar to overloading the other operators. The difference is that this is a Urinary operator (Meaning it only takes one parameter) and either the return type or the parameter have to match the enclosing type (IE if your overloading the casting operator inside the whoopie class either the parameter or the return value have to be of type whoopie). You also have to state that this is an Implicit operator:

    public class Whoopie
    {
        public static implicit operator Kid(Whoopie e)
        {
            Random TimeForKid = new Random();
            int i = TimeForKid.Next(0, 100);
            if (i >= 50)
                return new Kid();
            else
                return null;
        }

}

As you can see, the "Operator" is essentially the return type. Now, I did something here that you may not want to do without implementing a tryCast() method that may return null. But for the sake so simplicity (read: Lazy Developer) I didn't.

That's all there is to making whoopie. I suggest you check out the MSDN Article on operators to see what's available to override and what's not. If you would like my source code let me know. I have a little console app that I wrote to demonstrate all that stuff up there.

So, now that your well equipped for both the developer world, and the real world. Why not stop by our next AADND meeting at the SRT world headquarters in Ann Arbor and give me your feedback face to face. If anything you'll get some valuable FREE training in ASP.Net Caching from the one and only Steven Smith of AspAlliance.com fame and fortune.

Join me for the next time when we discuss how to make Beer Bongs out of bits of a garden hose and F# or something else equally as interesting.

Tech in 5 minutes: The Abstract Factory Pattern

Dave Redding — Thu, 28 Dec 2006 19:41:00 GMT

In the sprit of the coming New Year, I thought I’d bring you all this little egg of wisdom. By egg I mean code and by wisdom I mean code I could write before I got hammered.

When I go out with the Wife to drink, (Yes she can do more than fill the fridge and get me beer….hell, half the time she doesn’t even get me the beer, I have to get off my ass and do it myself!) We like to drink as much as possible, not only that, but we love to sample every brewery possible. We have a few requirements, for one there has to be a bathroom.... if you whip it out in public, you get thrown in jail, and that kinda puts a stop to your celebrating depending on how you get your kicks. Another one is that they must serve at least one standby beer (Sam Adams for me, Michelob Light for the wife) and one beer we’d like to give a try.

The problem that we find on nights like New Years is that after a few bars (maybe fewer for me than the wife)....we don’t know what the hell their serving, if we walk in and just ask for a Beer, who knows what we’d get!

By now you’re probably saying “Dave, you promised me tech, and patterns and stuff, but so far all I’ve seen is how you like to drink”. To that I say: calm the hell down, I’m getting to it. I’ve got to set the stage here for Christ sakes.

If we could make the world a more program friendly place, I’d say we could implement a Factory Pattern here. Basically where I have a bar, it produces beer, I drink the beer, and all is well. If you remember from my last example we had a beer class that inherited from a Drink class. Something like this:

public abstract class Drink : FridgeCrap

{

    public abstract void Consume();

}

public abstract class Beer : Drink

{

    public override void Consume()

    {

        Console.WriteLine("Glug glug glug.... mmmmmm beer.");

    }

}

Like I said earlier, I ‘m not going to be able to order just a plain “Beer” from the bar, so that class must be marked abstract. Now if I want specific beers, its simple right?

public class SamAdams : Beer

{

    public override void Consume()

    {

        Console.WriteLine("Mmmm, refreshing, filling and a great aftertaste...");

    }

}

public class MichelobUltra : Beer

{

    public override void Consume()

    {

        Console.WriteLine("Really....why not just drink water? You'll probally get buzzed faster :)");

    }

}

Fantastic. So now I have my required beers. Now like I said, each bar is going to have its own beers, so we need a few more classes:

public class BarA_stout : Beer

{

    public override void Consume()

    {

        Console.WriteLine("Goes down smooth, nice frothy head. Goes great with a burger.....i want a burger!");

    }

}

public class BarB_liteAmber : Beer

{

    public override void Consume()

    {

        Console.WriteLine("Great with wings, has a nice amber color and is an easy drink to have over conversation!");

    }

}

public class BarC_Crap : Beer

{

    public override void Consume()

    {

        Console.WriteLine("Holy shit, this must be budwiser...we need to get the hell out of here, they probally spiked my Sam with water!");

    }

}

public class BarD_JagerBomb : Beer

{

    public override void Consume()

    {

        Console.WriteLine("Wow....they lied, this ain't just beer..... One more round please!");

    }

}

Ok, so we have our beers (the names kinda gave away the punchline did’nt they?). Now all we need are a few bars to serve them up to us!

public abstract class Bar

{

    public Beer GetSamAdams()

    {

        return new SamAdams();

    }

    public Beer GetMichUltra()

    {

        return new MichelobUltra();

    }

    public abstract Beer GetHouseBeer();

}

public class BarA :Bar

{

    public override Beer GetHouseBeer()

    {

        return new BarA_stout();

    }

}

public class BarB : Bar

{

    public override Beer GetHouseBeer()

    {

        return new BarB_liteAmber();

    }

}

public class BarC : Bar

{

    public override Beer GetHouseBeer()

    {

        return new BarC_Crap();

    }

}

public class BarD : Bar

{

    public override Beer GetHouseBeer()

    {

        return new BarD_JagerBomb();

    }

}

Now, it’s not just good programming practice to have that abstract bar there, oh no. Remember how I said that I after a bar or two, I’d probably have no idea where I was? The problem here is that, if I want the house beer from BarC, I have to know that BarC is serving it. Great for going out for lunch, bad when you’re drunk and looking for another beer. So enter the Abstract Bar Factory. We’ll just put a static method that helps with making the decision on where to drink, or more importantly, tells us where to drink.

public abstract class Bar

{

    private static int BarCounter = 0;

    private static Bar[] itenerary = new Bar[4]

                                    {

                                        new BarA(),

                                        new BarB(),

                                        new BarC(),

                                        new BarD()

                                    };



    public static Bar GetNextBar()

    {

        if (BarCounter >= itenerary.Length)

            BarCounter = 0;

        return itenerary[BarCounter++];

    }

    public Beer GetSamAdams()

    {

        return new SamAdams();

    }

    public Beer GetMichUltra()

    {

        return new MichelobUltra();

    }

    public abstract Beer GetHouseBeer();

}

Excellent, now, my Wife and I just need to drink the beer.

public class DaveAndWife

{

    private Random beerTolorence = new Random();

    public DaveAndWife()

    {

        int trips = beerTolorence.Next(4, 20); //thats alot of beer!

        for (int i = 0; i < trips; i++)

        {

            WeWantBeer();

        }

    }

    public void WeWantBeer()

    {

        Bar currentBar = (Bar.GetNextBar());

        //For the wife

        currentBar.GetMichUltra().Consume();

        //for me

        currentBar.GetSamAdams().Consume();

        //for us to try

        currentBar.GetHouseBeer().Consume();

      }

}

Note the simplicity here! We don’t care where were drinking. If it’s on the itinerary, were going to drink there! And best of all, I don’t need to keep track of where to go next or where we’ve been. Abstract Factories are great for getting drunk, just remember that and you’ll be OK.

Now, if you have any ideas for any future topics you’d like me to cover in a 5 minute tech. Let me know via comments or email. But if you want to be really suave, come to the Ann Arbor .Net meeting on Jan.10^th where we’ll be having the project manager for Windows Workflow, Matt Winkler , speaking on...... Windows Workflow! And while your there you can meet me and drop me your suggestion. I might even give you something (stop snickering!).

Dave.