Chapman's Coding Corridor

YAGNI Abuse

2009-03-08T22:10:00.001-04:00

YAGNI "You Ain't Gonna Need It" is one of those principles I usually say I hate. Truthfully, I suppose I don't hate the YAGNI principle, I think I typically hate when people try to pull it out in a discussion/argument. I feel that sometimes people use YAGNI either as an excuse to write poor code or as an excuse for why they don't need to improve as a developer.

Somewhat recently, Jeremy Miller wrote a post titled "A Quck Example of YAGNI / Simplest Thing Possible In Action" which completely annoyed me. I think it got under my skin so much because of how highly I view Jeremy. I spoke with some people after a recent Great Lakes Area .Net User Group meeting about this. To be fair, after that post and after my discussions Jeremy did make a second post titled "Update on the YAGNI Episode" where he explains that he was wrong in the prior post. I probably should have written this post earlier.

In Jeremy's original post he discusses an argument he had with another member of his team regarding how to build a simple web layout which included a 2x2 arrangement of panels which will hold various content. Jeremy uses YAGNI to argue that this layout should be done using an HTML table with 2 rows and 2 columns. It's relatively simple, it works, why try to complicate things? He argued that this was the simplest thing to do which would satisfy the current requirement.

To me, this shows that Jeremy is not an expert at HTML design, and was trying to use YAGNI to defend it. I think there should be a new principle for Jeremy, and for others trying to use YAGNI. Let's call it "Use What You Know". Maybe we could call it WYK or something like that. Jeremy knows how to lay out web sites using tables. If he's working on a project where he needs to lay out panels, that's probably what he should do. However, in cases where someone else on the team understands a superior approach which allows more flexibility to be replaced in the future, that's what they should use.

To me, YAGNI needs to be about features, not the technical approach. The technical approach needs to be clean and easily replaceable. This is a big reason why I'm such a big fan of the Single Responsibility, Open-Closed and the Inversion of Control principles. When used correctly these principles, not meaning to exclude many other solid principles, result in maintainable and easily replaceable code. Code which follows these principles is not necessarily hard to write (sometimes it does involve some different ways of thinking), and it doesn't typically take any more time, but the benefits really pay off when you actually do "Need It" and have to change a piece of your software. In cases before I have written extremely simple services which work for the current functionality only to require that they be fully replaced with more advanced functionality in the future. This is fine, simply swapping out that service for the newer service was a simple switch which didn't require breaking the rest of the application.

That's how YAGNI should be used. Only build the functionality that you need, but leave it easy to enhance or even replace.

In many cases I feel that developers use arguments against Inversion of Control, or the Open-Closed principle because of YAGNI. They argue you don't need that flexibility. You don't need to replace your services easily. It's a simple application, it works without it, why are you pushing this? To me that's using YAGNI to fight continuous improvement. As developers we should strive to constantly hone our craft. We should always look to find ways to better do our job. It's the same argument I make all the time. Doing things the "clean" way is usually not more work, or more time consuming than the "quick and dirty" way. However, not understanding how to do it cleanly, does result in it being significantly easier and faster to do things the "quick and dirty" way.

Getting back to the "Use What You Know" point. I'm not advocating that every time a problem comes up you research what the cleanest way is to do it. I'm advocating that you find time to learn about new approaches to solving software development problems before you have to use it on the job. The employer typically requires fast turn around on the software problems you face. Deliver the solution that you know how to deliver. That gives the employer or customer the solution that works the fastest and for the least cost. However, if we could have spent earlier months learning new techniques and solutions, the employer could receive superior products while developers are able to enjoy working on a cleaner code base.

Ideally you find employers that allow for time up front for you to lean and continuously improve. That way when the problem comes you are better suited to solve it with a larger toolbox. Some employers do not allow time for this, and instead developers are forced to improve on their own time. Regardless, I would advocate that we all put in the extra effort to learn on our own time. The ones with employers that pay for this time are lucky, but that doesn't let the rest of us off the hook.

Spoke at GANG

2009-03-03T20:53:00.001-05:00

I finally gave my talk at GANG. I was originally scheduled to speak in September (Speaking at GANG), but came down with food poisoning which prevented me from talking. That same talk, an Introduction to Rhino Mocks, was made last month in February.

I really enjoyed giving the talk. The crowd was great, and overall I had a good time. I hope others enjoyed the talk and were able to learn about how Rhino Mocks may come in handy with their software testing needs.

At the end of the talk I said I would post my example application online. I have decided to place the file on savefile.com. You will have to put up with an ad in order to download the file. Download the sample here.

In the near future, I plan to post in detail about some parts of the application application. If readers would like an explanation of any piece in particular, please leave a comment on this post.

Speaking At GANG

2008-09-03T07:54:00.001-04:00

I'm going to be speaking at the Great Lakes Area .NET User Group in Southfield on September 17th. I will be giving a talk about Rhino Mocks, and the how, when and why to use it.

I am still putting the presentation together, so if you will be in the area and would like me to cover something specific, leave a comment. Even if you won't be attending, let me know if you think there are points which would be helpful for the people there.

Why I Am Sick Of Hearing About Deferred Execution

2008-07-21T18:06:00.002-04:00

Since the announcement of LINQ we've heard plenty about "deferred execution", this term that has appeared like its some sort of LINQ magic feature. Personally, I think I need to come up with my own term and claim it's something awesome too. I'm really tired from hearing about it.

On Wednesday, July 15th I went to a Great Lakes Area .NET Users Group talk by Bill Wagner where he was talking about Extension Methods and how to make proper use of them. Now, don't get me wrong, I have a lot of respect for Bill. I don't mean to criticizing Bill in any way. So Bill, if you read this, I really don't mean any disrespect by this. It was simply your use of the term that made me recall my feelings on this topic.

Bill was doing a demo where he showed various LINQ extension methods and showed that by making use of these extension methods we were able to harness the power of DFERRED EXECUTION!

The first example Bill showed was Enumerable.Range(Int32, Int32) where it returns an IEnumerable<Int32>. Bill then shows that when he calls the Take() extension method it only iterates through the first x of the items in the range, not the full list of items identified by the range. Ok yes, this is true. We didn't have to create a new list and populate it with a million items, just to pull the first 5 items.

Bill later went on to discuss how if you use a LINQ query with variables, you can change those variables after you have defined the query. His code looked something like the following:


var range = Enumerable.Range(0, 1000000);

var maxValue = 40;

var items = from r in range
            where r < maxValue
            select r;

var takenItems = items.Take(30);

maxValue = 20;

foreach (var i in takenItems)
{
  Console.WriteLine(i);
}

Now yes, you define your LINQ query, change your variable after the fact and then consume that class. Yes, it takes into account the change in your variable. Yes, this occurs after you defined your query, so deferred execution is a term that makes sense.

Ok, I'll give in a bit, I'm ok with the term, but not the way its talked about. The magic isn't LINQ, and understanding what is going on is not just about understanding LINQ. It's the fundamentals of how LINQ works which people should really understand.

I'm going to say this one more time before I move on "Deferred Execution is not a LINQ feature". It's a closure feature/implementation pattern.

First let me try to explain the implementation pattern piece by creating my own "Deferred Execution" code which works exactly the same way as as the Range method Bill demonstrated. (Note that this is not necessarily built with production quality in mind).


public class MyRange : IEnumerable
{
    private class RangeEnumerator : IEnumerator
    {
        private int? _current;
        private bool _complete = false;
        private readonly int _minValue;
        private readonly int _maxValue;
        
        public void Dispose()
        {
            
        }

        public bool MoveNext()
        {
            if (_current == null)
            {
                _current = _minValue;
                return true;
            }
            
            if (_current < _maxValue)
            {
                _current += 1;
                return true;
            }
            else
            {
                _complete = true;
                return false;
            }
        }

        public void Reset()
        {
            _current = null;
            _complete = false;
        }

        public int Current
        {
            get
            {
                if (_current == null || _complete)
                {
                    throw new InvalidOperationException();
                }

                return _current.Value;
            }
        }

        object IEnumerator.Current
        {
            get
            {
                return Current;
            }
        }

        public RangeEnumerator(int minValue, int maxValue)
        {
            _minValue = minValue;
            _maxValue = maxValue;
        }
    }

    private readonly int _from;
    private readonly int _to;

    public IEnumerator GetEnumerator()
    {
        return new RangeEnumerator(_from, _to);
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }

    public MyRange(int from, int to)
    {
        _from = from;
        _to = to;
    }
}

That's actually really simple code isn't it? There is nothing revolutionary in that code. Any one of us could have implemented that in C# 1.0.

Now, let's look at a case with closures. LINQ internally is using closures (via lambda expressions) to perform its queries. So lets say I write my own closure.


var range = new MyRange(0, 1000000);

var maxValue = 40;

Func expression = i => i < maxValue;

maxValue = 20;

foreach (var i in range)
{
    if (!expression(i))
    {
        break;
    }
    else
    {
        Console.WriteLine(i);
    }
}

Huh, wouldn't you guess it, it also shows this magical LINQ "deferred execution" behavior.

So what's the point of all this? One, I'm probably too easily set off on topics like this. Second, we shouldn't look at "deferred execution" as some sort of LINQ magic but rather a pattern that can provide us many benefits with our own code. Deferred execution allows us to enhance performance and flexibility of our applications. This is something we can all make use of in our algorithms, even if we aren't utilizing LINQ.

And in regards to the Extension method talk by Bill, I really enjoyed it. It was simple enough for people to learn about new C# 3.0 features. You talked about it well and gave good examples. I'm just frustrated that people seem to write this stuff off as magic even though they are simple concepts. Plus, this term seemingly just appeared with LINQ even though the concept has been around for a long time.

Subtle Bugs When Dealing With Threads

2008-07-12T10:05:00.001-04:00

Pop quiz, what's wrong with the following code?


public void Unsubscribe()
{
	if (_request != null)
	{
		ThreadPool.Enqueue(() => _service.Unsubscribe(_request));
	}
}

public void Subscribe(string key)
{
	Unsubscribe();

	if (!String.IsNullOrEmpty(key))
	{
		_request = new Request(key, handler);
		ThreadPool.Enqueue(() => _service.Subscribe(_request));
	}
}

Does everyone see the issue? There is a critical bug in the above code which isn't always readily apparent.

Try to find it...

I actually wrote code like this today (same concept, different implementation) and immediately saw some serious defects. Honestly, I'm lucky the issues popped up right away, these sorts of things tend to not appear right away, but jump up to bite you at a later point.

In this case the issue is the use of closures. When using a closure it copies the fields from outside the lambda expression into the expression meaning that my use of _request from within the lambda is actually the same reference that exists outside the lambda expression. So in the above case the Unsubscribe lambda gets executed on a new thread (from the pool) but by the time it actually executes the _request has already been changed.

In this case, you're actually unsubscribing from a request that most likely hasn't even been subscribed yet. And to top it off you haven't unsubscribed from the old request yet either. Obviously the above is a race condition where the exact output isn't guaranteed. There is a chance it works perfectly (though doubtful with a true thread pool). There is a chance the new request is subscribed first and then immediately unsubscribed as well.

The simplest way to resolve this issue is by changing the variable which is captured from one which is shared between both closures to one that is unique to each closure. As shown here:

public void Unsubscribe()
{
	if (_request != null)
	{
		var localRequest = _request;
		ThreadPool.Enqueue(() => _service.Unsubscribe(localRequest));
	}
}

public void Subscribe(string key)
{
	Unsubscribe();

	if (!String.IsNullOrEmpty(key))
	{
		_request = new Request(key, handler);
		var localRequest =_request;
		ThreadPool.Enqueue(() => _service.Subscribe(localRequest));
	}
}

However, what I really want to solve this type of problem going forward is to develop something which is process aware, much like the Saga in NServiceBus. Of course my goal is not to be a long running, persistable process like the Saga in NServiceBus, but the process portion is what I'm looking at.

StackOverflow.com, Uh oh?

2008-06-18T21:07:00.001-04:00

So I mentioned in my last post that I have began listening to podcasts. I have a lot of respect for both Jeff Atwood (Coding Horror) and Joel Spoelsky. So when I saw they were working together on a new project and publishing their conversations regarding their new product, I figured I had to listen. Now, they've posted around 9 episodes now, but I've only had a chance to listen to the first couple so far.

Honestly, I'm a bit concerned by what I heard. In their first episode I felt like they gave Microsoft technology based developers a really bad name. Now it may well be largely true (which is probably part of my concern), but I wish there were more resources to correct this bad name, rather than encouraging it.

Basically, during the podcast you will hear something along the lines that Microsoft technology developers basically resort to the Google-Copy & Paste programming development. Microsoft technology developers are called pragmatic in that they don't care what the right solution is, or how clean it is, or well it works so long as it does work.

Now, I'm not saying that using google to find answers to interesting problems is a bad thing. I'm not even saying that if you ever copy and paste code you're a bad developer, but ideally the developer is learning from the blog post instead of just finding something which seems to work and moves about their business. Honestly, typically these samples you find in blog posts are not thorough enough for a true production deployment. The point of these postings should be to educate people about new concepts, not try to do their job for them.

Stackoverflow.com from what I gathered wants to be the place to replace google as the first place where you search for doing your job. Now they stated their goal is to be the first hit on google for all of your searches, but really I think they would be happier if you went straight there instead of google.

Now Stackoverflow is not Microsoft specific, it is meant to appeal to developers on all platforms. However, they seem to be looking at the Microsoft centric market as their main target. Honestly, I think these guys will be successful. They both have large followings, and I think there is huge demand for systems that can essentially do their jobs for them. I just wish it appeared to be a more helpful resource that helped developers grow, instead of just allowing them to get by.

This all being said, the podcast is worth checking out. These are two extremely intelligent people, and by listening to these podcasts you essentially get a look inside their heads and how they think. I don't have to agree with Stackoverflow.com, or the topic which they discuss, I'm still able to learn from it while I listen. To both Joel and Jeff, thank you for posting your phone conversations as podcasts, it has been a great learning experience for me.

Deep Fried Goodness

2008-06-18T21:00:00.001-04:00

So I realize I'm going to look like a bit of a sellout based on my procrastinating, but I really meant to write this earlier. With my newly purchased iPhone and my increased amount of travel, I've recently started listening to Podcasts. I honestly never saw the point before. I rarely get an hour where I can really listen to a podcast. I have always thought of reading as being a simpler and more effective mechanism for learning. However, while traveling (especially on a plane) I find that a properly timed podcast can provide a lot of information that otherwise I wouldn't be able to consume.

I saw that Keith Elder (and Chris Woodruff) had a new podcast called Deep Fried Bytes, and I figured I may as well see what it is. I'm actually one of those people that first met Keith because I recognized his picture from his blog. Not knowing really what was good for pocasts (besides the obligatory Hanselminutes and DNR) I figured it was worth a shot.

After listening to their episode on interview war stories I was really impressed. They had some really intelligent people talking about interviewing. This was a topic, which I have to admit, was not something that immediately peaked my interest. But what you find is that when many smart people sit down to have a talk, something good will result. Now, after I picked myself up off the floor from hearing a C# MVP call the using keyword "Obsolete", I realized that they have a winning format.

Plus honestly, Keith Elder is the kind of guy where he doesn't need to have anything good to say. The way he talks and presents himself can be entertaining almost regardless of the topic. If you listen to podcasts I recommend you go try these guys out. If you don't listen to podcasts, I recommend giving them a shot anyway.

As for my contribution to the topic at hand, I suppose I had a little bit of a war story. From an interviewing side I do remember talking to one guy who's resume really looked great. He had all sorts of great items written down from projects he had worked on in the past. While inquiring about these items it became more and more clear that this person really didn't understand the concepts which he had written he had previously implemented. After a few questions trying to get this candidate to talk about items on his blog he eventually answered that he had nothing to do with those tasks. They were all completed by other people and he didn't understand how they worked. He then apologized for writing misleading (or factually incorrect) items on his resume, and we ended the interview.

As an interviewee. I just remember the Microsoft interview I had. When I was graduating from Case Western Reserve University I had an on-campus interview with a representative from Microsoft. I wanted to be a programmer since I was a small child (maybe 12 or 13 years old) and working for Microsoft was always a dream for me. I had seen their campus (my family lived in Portland, OR at the time, and we saw their campus while visiting the Seattle area), and everything seemed like the perfect opportunity for a young geek in love with software. From my interview, I really only remember a single technical question which I was asked. Now keep in mind I wasn't claiming to be an expert at C or any other language at the time. I had some professional experience working in VB.NET Beta, as well as some experience in developing relatively simple applications in C, C++, Java, PHP, Basic, Perl and the early versions of C#.

Anyways, he asked me "What is the fastest way to reverse a string in C?". Ok, well I am familiar with C, and I'm familiar with how strings work in C. I understand pointers, and pointer arithmetic, and immediately I think this must be pointer arithmetic. Well, before I could even start talking about my response he says "Ohh, and it doesn't use pointer arithmetic.". Uh ohh, at that point I pretty much froze. I didn't know what to do. I'm not a C expert. I haven't written any C code in a while, let alone overly complex C code, and I need to know what the fastest way to reverse a string is in that language? Well, lets just say the rest of that apparently didn't go over so well, and I wasn't asked any other technical questions. I probably didn't handle the curve ball so well, but that was that.

I still remember how dumb I felt when I later learned just how many people from one of my classes landed jobs at Microsoft. While in a class my senior year I remember the professor asking who was going to work for Microsoft, and there must have been at least 30 hands in the room that went up. The said part of it to me too was I WAS the curve buster in that class. I remember taking a test where the curve was so bad that a 68 became an A, yet I had scored a 98. I was trying to figure out where I went wrong at that point. Oh well, that's just how it goes.

Well, enough about me and my interviewing war stories, you need to go have a listen to Deep Fried Bytes.

--John Chapman

Been Gone

2008-05-30T09:16:00.001-04:00

I just wanted to make a post so people knew I was still alive. I've been extremely busy over the past two months. I haven't forgotten about this blog, and I really want to get back to writing. I really want to get further on the Sudoku series.

Lately I've been focusing on architecture of a Model-View-Presenter based WPF application. The current complexities which are being analyzed is that users will have many duplicate views open at the same time, each working on a different item. So picture 40 or more edit windows open on the same time, some for different items, some for the same items. Some have similar child widgets, some have different child widgets. Screens still need to talk to each other, but they have to talk to the appropriate screen. Oh, and btw, performance is absolutely crucial on this app.

The standard Model-View-Presenter samples you see really don't address these issues. Typically there is one main form which acts as a shell, and there is one region where a given view can live. Not here, that view can be in any number of places, and there can be any number of them. It makes the problem a bit more complex. We have some solutions, but I can't really discuss them here.

But after looking at the standard Model-View-Presenter samples, it make me feel more strongly that I really need to find the time to get back to the sudoku series, and hopefully I can produce a well documented series about why each choice is made.

Sorry for the delay. I will be back.

--John Chapman

New Adventures

2008-04-03T07:58:00.001-04:00

I was originally going to write this on Tuesday, but I realized that with it being April 1st, people may have thought I was joking. I have decided to leave Ryder. Tomorrow, Friday April 4th will be my last day.

I have found an opportunity to work as an independent contractor building an application dealing with a domain that I am very passionate about. I can honestly say that the application I'll be working on is one that I would love to use myself. How often do we get to say things like that as developers? I figured this was an opportunity I had to take.

Ryder has served me very well. I first started at Ryder at the end of 2004. I've had the chance to work with some great people. I've also had the chance to interact with people of all levels in the company. There were people at Ryder that took good care of me, helping obtain 24" monitors (to replace 17" CRTs for most people) to increase productivity as well as state of the art development machines. I'll miss working with them.

I worked on the LMS team at Ryder, which is probably the largest externally facing application at Ryder (don't quote me on that). I do know that they are backfilling my position, so if you are looking for a new adventure yourself, send them your resume.

--John Chapman

Sudoku Part 5: A Look At The UI Architecture

2008-03-15T18:15:00.002-04:00

Part 5 has been a long time coming. Originally, the plan was to present an entire UI in this post, which I've come to realize is simply not feasible.

I have been attempting to learn WPF as part of this exercise. Learning an entirely new UI framework while putting together this piece has proven a little bit difficult, and as a result the progress of the application has slowed significantly. So for the rest of these pieces, I'll try to break down the UI further to show the choices I make while it's being developed and why.

Today, we're going to take a look at the architecture I plan to use for the WPF sudoku game and why. We're going to take a look at my simple implementation of MVP (Model-View-Presenter). We're going to take a look at the advantages of a MVP architecture and how that fits with our goal of utilizing Behavior Driven Development to build our application.

Architecture Description

In Part 1 (Defining The Solver Behavior) I mentioned that we would be using Castle Windsor in this project. One of the great things about Windsor, and really any good inversion of control framework, is that you can minimize the invasion of container logic in your code via nested dependency injection. What I mean by this, is that you can use the container to resolve a single service and it will automatically populate all dependencies for all children. From our perspective, this will mean that the container logic can be restricted to just the UI, resulting in one less dependency throughout the application.

From previous parts we never made explicit use of Windsor, but rather we defined our inner dependencies via our available constructors. For example, our RecursiveGenerator that we built in Part 4 took an ISolver in the constructor which will instruct Windsor to automatically populate the appropriate implementation for our generator. This process is known as Constructor Injection.

I mentioned that we'll be using a Model-View-Presenter based architecture for our Sudoku game. The Model-View-Presenter obviously breaks down to three pieces. There are many variations of the MVP pattern (See Jeremy Miller's Build your own CAB series for some awesome overviews of various techniques), but the way we will use it for our purposes can be described as follows:

View - The portion of the application that actually displays data to the user as well as listens for user input. Such as watching for button presses or mouse movement. For this application we will be using WPF for the view.
Presenter - Handles the UI behavior logic. For example the view will show the data to the user, but the presenter will determine what data should be shown to the user and how it should be formatted. Also, while the view listens to see if a mouse moves, or a button is clicked, how that action is handled belongs to the presenter. So it would be possible for our game to have many "New Game" buttons on the view, but it would defer the appropriate actions to the presenter to determine what should happen when any of those buttons are pressed.
Model - Handles the data which the presenter operates on. This would typically represent the description of the business domain which is being solved by our application. In our case this will represent the data needed to track the game which is being played, such as the puzzle which is being worked on, the current status of the solution which the user is building as well as supporting information such as the game clock or at least the time when the game was started.

So, why go through all of this? Especially for an application which seems as simple as a sudoku game? Well, first of all, we are doing this as an exercise, not necessarily the exact application. Secondly, and far more importantly, this separation of concerns allows us to keep logic more closely aligned to a purpose, and allows us to have fully testable behavior. By moving our presentation behavior from the XAML "code-behind" to a separate presenter object, we can test our presentation without the need for an actual UI. This is a major advantage over the old fashioned applications. We can now have a lot more faith that our application behaves as expected via our automated testing.

Additionally, MVP does not force us to be tied to the WPF view. It would be possible for us to re-use the same model and presenter in a WinForms application (or potentially silverlight and other web-based frameworks) with no change, only a different view. This will be considered out of scope for the time being.

WPF Implementation

First off, I want to make a disclaimer. I am not a WPF expert. If there is a better way to implement this in WPF, I would love to hear about it. I'm learning WPF as I go with this sample application.

My first idea was to create a base class which would initialize the appropriate presenter for that view. I quickly ran into a bit of a problem with WPF. It's valid to create your own base class instead of Window, but it adds a lot of complexity to the XAML, and Visual Studio didn't seem to appreciate it too much.

Since I only needed the base class to resolve the appropriate presenter via my container, I figured it would be ok to just have the convention of every view calling a static Initialize method. This keeps the XAML simple, and only adds one extra line of code to all views.

Application Implementation

I chose to initialize Windsor in the Application class, which is where the static Initialize also lives. The Application class looks like the following:

public partial class App : Application, IContainerAccessor
{
 public static IWindsorContainer Container { get; private set; }
 
 IWindsorContainer IContainerAccessor.Container
 {
  get
  {
   return Container;
  }
 }
 

 protected override void OnStartup(StartupEventArgs e)
 {
  InitializeContainer();
  base.OnStartup(e);
 }

 private void InitializeContainer()
 {
  Container = new WindsorContainer(new XmlInterpreter());
 }

 public static void InitializePresenter<T>(T view)
 {
  Presenter<T> presenter = Container.Resolve<Presenter<T>>();
  presenter.Wireup(view);
 }
}

Note that this is as far as our container needs to go into our sudoku application. When the application first starts we need to initialize our container based on the application configuration file. The InitializePresenter method is what we expect every view to call when the view is initialized. The type paramter (T) is the interface type which the view itself implements. That is the view that the appropriate presenter will use in order to interact with the view. The Presenter<T> will server as the abstract base class for all presenters. So in this case we're asking Windsor to locate and instantiate the appropriate presentation logic for our particular view. Once the presenter is located we call the base class method Wireup which tells the presenter to begin observing any events exposed by the view. This would also be the time that the presenter could perform any initialization logic. The Presenter base class looks like the following:

public abstract class Presenter<T>
{
 public T View { get; private set; }

 public void Wireup(T view)
 {
  View = view;
  Initialize();
 }

 protected abstract void Initialize();
}

The View implementation would then contain the following:

protected override void OnInitialized(EventArgs e)
{
 base.OnInitialized(e);
 App.InitializePresenter<IBoardView>(this);
}

Where obviously in this case the view implements the IBoardView interface. Our appropriate presenter implementation would be defined as:

public class BoardPresenter : Presenter<IBoardView>

To wrap up our initial implementation we would need to configure our Windsor Container in our configuration file as follows:

<configuration>
  <configSections>
    <section name="castle"
        type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />
  </configSections>

  <castle>
    <components>
      <component 
        id="generator" 
        service="Sudoku.Bll.Generator.IGenerator, Sudoku.Bll" 
        type="Sudoku.Bll.Generator.RecursiveGenerator, Sudoku.Bll" />
      <component 
        id="solver" 
        service="Sudoku.Bll.Solver.ISolver, Sudoku.Bll" 
        type="Sudoku.Bll.Solver.RecursiveSolver, Sudoku.Bll" />
      <component 
        id="boardpresenter"
        lifestyle="transient" 
        service="Sudoku.UI.Presenter`1[[Sudoku.UI.Views.IBoardView, Sudoku.UI]], Sudoku.UI" 
        type="Sudoku.UI.Presenters.BoardPresenter, Sudoku.UI" />
    </components>
  </castle>
</configuration>

In this case our presenter would have an IGenerator parameter in its constructor which would tell Windsor to construct the defined generator, which we've already seen requires a solver implementation. Therefore these three specific components are necessary to fully configure our Windsor container for this example. One item to note is that we have specified a lifestyle of transient for our presenter. This is to signify that every presenter should have its own containing class (since the state of the associated model will matter), whereas our generator and solver services have no defined state and can safely be use the default lifestyle of singleton.

At this point we have the basics defined for a Model-View-Presenter application in WPF. We are using Castle Windsor to manage our dependencies. Our View has no knowledge of our presenter implementation, and the presenter has no knowledge of our view implementation. All aspects are configurable and easily changeable. Plus, since our presenter does not know our view implementation it has opened the door to potential porting to an alternative UI framework.

In the next iteration I hope to examine the needed behavior of our presenter and potentially the implementations which satisfy that behavior.

--John Chapman

Sudoku Part 4: Implementing A Generator

2008-02-03T08:08:00.000-05:00

Sudoku Part 0: Introduction
Sudoku Part 1: Defining The Solver Behavior
Sudoku Part 2: Implementing A Solver
Sudoku Part 3: Defining The Generator Behavior
Sudoku Part 4: Implementing A Generator

In our last segment (Defining The Generator Behavior) we looked at the specifications required to generate new Sudoku puzzles. It turned out that from a specification standpoint, there were not many expectations that we placed on the generator. We basically just want a solvable sudoku puzzle. We didn't much care how it worked, or what the puzzle looked like, so long as the result was uniquely solvable.

Algorithm

Today, we're going to create our very first sudoku solver using a similar technique as the one we used to actually solve the puzzle. We're going to develop what I call the RecursiveGenerator.

In order to generate our puzzle, we'll first fill all board pieces with a valid sudoku value. While we're filling in each piece we'll ensure that we never create an invalid board. Meaning that at no time will we have a board with duplicate row values, column values or region values. We'll utilize a recursive algorithm very similar to the RecurisveSolver we developed previously.

Now that we have a fully populated sudoku board with no duplicate row, column or region values, we'll start removing values from random pieces. In order to do this we'll create a list of all pieces on the board and then assign a random double value to them and sort the list. We'll iterate over the list removing that piece's value from our board until our ISolver implementation reports that our board is an invalid puzzle. At this time we'll put back the last piece we removed and consider the puzzle generated.

Test Class Implementation

Our test class to test our generator implementation is only minimally more complex than the solver implementation we used in an earlier section. Because this generator we built has a dependency on an ISolver we need to provide an implementation which we have already tested so that our generator can operate successfully. For this we're obviously going to use our already tested RecursiveSolver implementation. Note that while it would be possible to use a different type of solver (or notably a mock solver), doing this would most likely require significant changes to the tests which we are running, and this is not an exercise we're yet willing to go through.


[TestClass]
public class When_RecursiveGenerator_Generates_A_Puzzle : When_A_New_Puzzle_Is_Generated
{
  public When_RecursiveGenerator_Generates_A_Puzzle()
    : base(new RecusiveGenerator(new RecursiveSolver()))
  {

  }
}

Notice that the only new twist to this code is that our constructor for RecursiveGenerator must now takes an implementation of ISolver.

RecursiveGenerator Source


public class RecusiveGenerator : IGenerator
{
  private Random rand;
  private ISolver solver;

  public RecusiveGenerator(ISolver solver)
  {
    rand = new Random();
    this.solver = solver;
  }

  public Puzzle Generate()
  {
    Puzzle puzzle = new Puzzle();
    
    //fully fill a puzzle with valid pieces
    GeneratePiece(GetMinimumPosibilityPiece(puzzle), puzzle);

    //now remove random values until the puzzle is no longer
    //uniquely solvable.

    SortedList<double, Piece> sortedPieces = new SortedList<double, Piece>();
    foreach (Piece piece in puzzle.Pieces)
    {
      sortedPieces.Add(rand.NextDouble(), piece);
    }

    Piece lastPiece = null;
    Value? lastValue = null;

    try
    {
      foreach (double key in sortedPieces.Keys)
      {
        lastPiece = sortedPieces[key];
        lastValue = lastPiece.AssignedValue;
        lastPiece.AssignedValue = null;
        solver.Solve(puzzle);
      }
    }
    catch (DuplicateSolutionFoundException)
    {
      //when we reach the point of a duplicate solution
      //we need to put the last value we stripped off back.
      lastPiece.AssignedValue = lastValue;
    }
    
    return puzzle;
  }

  private bool GeneratePiece(Piece piece, Puzzle puzzle)
  {
    if (piece == null)
    {
      return true;
    }

    HashSet<Value> potentials = CalculatePotentials(piece);

    do
    {
      piece.AssignedValue = null;

      // if there are no potential values for this piece then
      // we have reached the end of the line.
      if (potentials.Count == 0)
      {
        return false;
      }

      piece.AssignedValue = potentials.PopRandomItem();
    } while (!GeneratePiece(GetMinimumPosibilityPiece(puzzle), puzzle));

    return true;
  }

  private Piece GetMinimumPosibilityPiece(Puzzle puzzle)
  {
    Piece minimumPiece = null;
    int minimumPossiblities = Enum.GetValues(typeof(Value)).Length + 1;

    foreach (Piece piece in puzzle.Pieces)
    {
      int possibilities = CalculatePotentials(piece).Count;
      if (!piece.AssignedValue.HasValue && possibilities < minimumPossiblities)
      {
        minimumPossiblities = possibilities;
        minimumPiece = piece;
      }
    }

    return minimumPiece;
  }
  
  private HashSet<Value> CalculatePotentials(Piece piece)
  {
    HashSet<Value> potentials = GetPossibleValues();

    potentials.IntersectWith(GetSolutionValues(piece.Column));
    potentials.IntersectWith(GetSolutionValues(piece.Row));
    potentials.IntersectWith(GetSolutionValues(piece.Region));

    return potentials;
  }

  private HashSet<Value> GetSolutionValues(IEnumerable<Piece> pieces)
  {
    HashSet<Value> values = GetPossibleValues();
    foreach (Piece piece in pieces)
    {
      if (piece.AssignedValue != null)
      {
        values.Remove(piece.AssignedValue.Value);
      }
    }

    return values;
  }

  private HashSet<Value> GetPossibleValues()
  {
    HashSet<Value> values = new HashSet<Value>();
    foreach (Value val in Enum.GetValues(typeof(Value)))
    {
      values.Add(val);
    }
    return values;
  }
}

Notice that a lot of this code is very similar to that of the solver. This could probably be refactored, but for now we'll leave as is.

Again, what do we have to show for our hard word? Our green lights of course!

Notes

For those readers with a keen eye, something may seem less than optimal regarding the approaches we took here in this section. We'll get in to what those may be and what we can do about them in future segments after we have built a UI to be able to show these generated Sudoku puzzles.

Sudoku Part 3: Defining The Generator Behavior

2008-01-27T17:18:00.000-05:00

Sudoku Part 0: Introduction
Sudoku Part 1: Defining The Solver Behavior
Sudoku Part 2: Implementing A Solver
Sudoku Part 3: Defining The Generator Behavior
Sudoku Part 4: Implementing A Generator

In part 1 (Defining The Solver Behavior) we examined how Behavior Driven Development could assist us in defining the specifications of a small portion of our application. Today we're going to take the same approach, but instead we're going to tackle the Generation portion of a Sudoku puzzle instead of the solving of the puzzle.

We're going to resume our conversations with our domain expert, and see what types of behaviors this new piece of functionality should include.

Needed Behavior

Just like last time, we'll have simple questions and simple answers which will later drive how we create and define our behavior based unit tests.

What is the result when a new puzzle is generated?

No column should have duplicate values
No row should have duplicate values
No region should have duplicate values
The puzzle should be uniquely solvable.

Really, that's it. We don't care too much about how the puzzle is generated, or what it looks like (at least at this point), so long as the puzzle itself can be solved.

Notice, that making the puzzle solvable would actually be quite a tricky requirement if we had not already built a Sudoku solver in part 2 (Implementing A Solver). Lucky for us, since we have a fully tested solver which we have proven works we can plug that implementation in to our behavior tests for the generator in order to verify the output. Note that really any implementation of an ISolver will suffice for our purposes, since our behavior tests are actually written against the interface and not any particular implementation.

The BDD Style Specifications

We're going to write our test class (or specification) in much the same way we did before. We try to match the discussion with the domain expert as close as we can, and then write relatively simple tests which we can use to ensure our implementations provide the correct behavior.


[TestClass]
public abstract class When_A_New_Puzzle_Is_Generated
{
 protected Puzzle puzzle;
 private IGenerator generator;
 private ISolver solver;

 protected When_A_New_Puzzle_Is_Generated(IGenerator generator)
 {
   this.generator = generator;
   this.solver = new RecursiveSolver();
 }

 [TestInitialize]
 public void Initialize()
 {
   puzzle = generator.Generate();
 }

 [TestMethod]
 public void No_Column_Should_Have_Duplicate_Values()
 {
   foreach (Column col in puzzle.Columns)
   {
     List<Value> foundValues = new List<Value>();
     foreach (Piece piece in col)
     {
       if (piece.AssignedValue.HasValue)
       {
         Assert.IsFalse(foundValues.Contains(piece.AssignedValue.Value));
         foundValues.Add(piece.AssignedValue.Value);
       }
     }
   }
 }

 [TestMethod]
 public void No_Row_Should_Have_Duplicate_Values()
 {
   foreach (Row row in puzzle.Rows)
   {
     List<Value> foundValues = new List<Value>();
     foreach (Piece piece in row)
     {
       if (piece.AssignedValue.HasValue)
       {
         Assert.IsFalse(foundValues.Contains(piece.AssignedValue.Value));
         foundValues.Add(piece.AssignedValue.Value);
       }
     }
   }
 }

 [TestMethod]
 public void No_Region_Should_Have_Duplicate_Values()
 {
   foreach (Region region in puzzle.Regions)
   {
     List<Value> foundValues = new List<Value>();
     foreach (Piece piece in region)
     {
       if (piece.AssignedValue.HasValue)
       {
         Assert.IsFalse(foundValues.Contains(piece.AssignedValue.Value));
         foundValues.Add(piece.AssignedValue.Value);
       }
     }
   }
 }

 [TestMethod]
 public void The_Puzzle_Should_Be_Uniquely_Solvable()
 {
   Assert.IsNotNull(solver.Solve(puzzle));
 }
}

Sudoku Part 2: Implementing A Solver

2008-01-15T20:01:00.000-05:00

Sudoku Part 0: Introduction
Sudoku Part 1: Defining The Solver Behavior
Sudoku Part 2: Implementing A Solver
Sudoku Part 3: Defining The Generator Behavior
Sudoku Part 4: Implementing A Generator

In the previous posting (Defining The Solver Behavior) we discussed the needed behavior in order to build a working Sudoku solver. Today we're going to build our first implementation of a solver which exhibits the previously described behaviors.

Algorithm

For the first solver I took a relatively simple approach. It's not quite a brute-force solver, but it is close. I call the first implementation the RecursiveSolver, since it solves the puzzle using a recursive algorithm.

In order to solve the puzzle we'll first analyze the board position to determine the number of candidate values for each puzzle piece. The set of candiate values will be the full list of values minus the set of values in the piece's row, minus the set of values in the piece's column and then minus the set of values in the piece's region.

Once we have computed the candidate values for each piece, we'll record the piece with the fewest candidate values. We'll then loop over the candidate values in a random order calculating the piece with the minimum candidates given that move and continuing the process.

If we find a board position where there are no longer any pieces without an assigned value we know we have found a solution. If we have already recorded a value solution and we find a second board position we know we have found an invalid position.

If we found a board position where there is a piece with 0 potential values, we know we have traversed a path which will not lead to a solution.

If we traverse all possible paths of the puzzle and can not find a solution, then we know we have an unsolvable puzzle as our algorithm would have examined every possible choice a solver could make.

Broken into steps our algorithm looks like the following:

Find The Piece With The Minimum Number Of Candidate Values
If A Piece Is Found With No Candidate Values, Return Without Solution
If No Pieces exist with Candidate Values Return the Solution We Are Done
Loop Over Each Candidate Value
Assign the Value to the Solution
Return To Step 1 Given The New State
If We Found A Solution, Verify That We Have Not Previously Found A Solution
Loop To Step 4 Until No Other Candidates Are Available
Return The Solution If It Was Found

Test Class Implementations

In the last installment we created abstract behavior tests since we did not have a specific implementation of a solver. We had a set of behaviors we wanted all potential solver implementations to exhibit. So first we need to create concrete test classes which inherit from our abstract ones.

First, let's look at what we need to do for the case when a puzzle is solved:


[TestClass]
public class When_RecursiveSolver_Solves_A_Puzzle : When_A_Puzzle_Is_Solved
{
 public When_RecursiveSolver_Solves_A_Puzzle()
   : base(new RecursiveSolver())
 {

 }
}

That's pretty simple isn't it? Now, this works fine with the MSTest tool, I have not actually verified that this technique works in other .NET unit testing frameworks, but I believe it does. We rely on inheritance to pull all of our expectations from our base test class.

We can continue this pattern for all other behavior cases as well. Take special note to the fact that we are constructing the instance of the solver we want to test in the constructor of the test class. This is needed since our base class takes an ISolver to use for its test cases.

Solver Source

Now let's look at the good stuff. What does the solver code look like?


public class RecursiveSolver : ISolver
{
 private Random rand;

 public RecursiveSolver()
 {
   this.rand = new Random();
 }

 #region ISolver Members

 public Solution Solve(Puzzle puzzle)
 {
   Solution solution = new Solution(puzzle);

   solution = SolvePiece(FindMinimumCandidatePiece(solution), solution);

   return solution;
 }

 #endregion

 private Solution SolvePiece(Piece piece, Solution solution)
 {
   //when the provided piece is null we know there are no remaining
   //pieces to be filled in indicating that the puzzle is solved.
   if (piece == null)
   {
     return solution;
   }

   //we clone the current solution to ensure that we always provide
   //later steps with the same configuration.  Otherwise once the item
   //recursed the values within the soultion reference would have changed.
   solution = (Solution)solution.Clone();
   Solution returnSolution = null;
   Solution foundSolution = null;
   HashSet<Value&*gt; candidates = CalculateCandidates(piece, solution);

   //loop over all possible choices for this piece.  If we finish
   //looping and no slution was found the earlier steps will have
   //a null solution indicating the path was incorrect.
   while (candidates.Count > 0)
   {
     solution.Values[piece] = candidates.PopRandomItem();
     returnSolution = SolvePiece(FindMinimumCandidatePiece(solution), solution);

     if (returnSolution != null)
     {
       if (foundSolution != null)
       {
         throw new DuplicateSolutionFoundException("Provided puzzle is invalid.");
       }
       foundSolution = returnSolution;
     }
   }

   return foundSolution;
 }

 private Piece FindMinimumCandidatePiece(Solution solution)
 {
   Piece foundPiece = null;
   int minimumCandidates = 10;

   foreach (Piece piece in solution.Puzzle.Pieces)
   {
     if (!solution.Values.ContainsKey(piece))
     {
       HashSet<Value> candidates = CalculateCandidates(piece, solution);
       if (candidates.Count < minimumcandidates)
        { 
          minimumCandidates = candidates.Count;
          foundpiece = piece; 
          
         //If we found a piece with only 1 candidate we can stop looking
         //since 1 is the minimum possible candidates for a valid piece.
         if (minimumCandidates == 1)
         {
           break;
         }
       }
     }
   }

   return foundPiece;
 }

 private HashSet<Value> CalculateCandidates(Piece piece, Solution solution)
 {
   HashSet<Value> candidates = new HashSet<Value>((Value[])Enum.GetValues(typeof(Value)));
 
   candidates.ExceptWith(GetAssignedValues(piece.Column, solution));
   candidates.ExceptWith(GetAssignedValues(piece.Row, solution));
   candidates.ExceptWith(GetAssignedValues(piece.Region, solution));

   return candidates;
 }

 private HashSet<Value> GetAssignedValues(IEnumerable<Piece> pieces, Solution solution)
 {
   HashSet<Value> values = new HashSet<Value>();

   foreach (Piece piece in pieces)
   {
     if (solution.Values.ContainsKey(piece))
     {
       values.Add(solution.Values[piece]);
     }
   }

   return values;
 }
}

Notice that there is actually a lot of logic within this solver. While it could be argued that some of this logic deserves its own behavior class, at this time I'm going to consider it premature optimization, and leave it for future refactoring.

For example the ability to calculate potential values isn't something which is specific to a solver, or at least this solver. This could be usable elsewhere. If/When it becomes valuable to break it out we'll do it.

Also of note is the PopRandomValue method on the HashSet<>. PopRandomValue is obviously an extension method here, just don't tell anyone! This method randomly selects an item from the Set and then removes it from the set so it won't be selected next time. The implementation is as follows:


public static class HashSetExtension
{
 private static Random rand;

 static HashSetExtension()
 {
   rand = new Random();
 }

 public static T PopRandomItem(this HashSet<T> set)
 {
   List<T> list = new List<T>(set);
   T item = list[rand.Next(0, list.Count - 1)];
   set.Remove(item);
   return item;
 }
}

What do we have to show for all of our effort? Well a pretty screen with lots of green of course!

Notes

Note that we could have included additional behavior tests regarding how this particular solver should behave. At this time I don't deem it necessary since our only real requirements is that the solver gives valid solutions when one is available, and reports when no solution is available.

As previously mentioned we could break apart some items of this solver into multiple solvers. We'll investigate those possibilities at a later point.

Look for the next section where we'll discuss our Sudoku puzzle generator!

-- John Chapman

Sudoku Part 1: Defining The Solver Behavior

2008-01-05T09:34:00.000-05:00

Sudoku Part 0: Introduction
Sudoku Part 1: Defining The Solver Behavior
Sudoku Part 2: Implementing A Solver
Sudoku Part 3: Defining The Generator Behavior
Sudoku Part 4: Implementing A Generator

In the introduction I talked briefly about my goals for this series. I wanted to create both a Sudoku generator which could generate puzzles for both myself and a theoretical automatic solver. There are many places to find such tools on the internet, but my goal was to use this as an exercise to show how someone could use various techniques and tools such as Behavior-Driven Development and the Castle Windsor Project. Today, we'll start with Behavior-Driven Development.

Needed Behavior

What are we trying to accomplish Here? Let's start with the Sudoku Solver first. Let's pretend that I am having a conversation with a customer who is asking me to write this Sudoku solver for them. Let's also say that I am not familiar with sudoku puzzles. First the customer explains to me that a Sudoku puzzle is a 9x9 grid with 9 3x3 sub-regions within the grid where each cell can hold a value from 1-9. He also explains that the puzzle begins with some of the cells (or pieces) already filled in for us, and the rest is for the solver to fill in.

So we have the following dialog:

What happens when the puzzle is solved?

All cells should be assigned a value.

No column should have duplicate values.
No row should have duplicate values.
No region should have duplicate values.

The customer explains to me that if the solution meets the provided criteria we are guaranteed of a valid solution for the given puzzle. But then I start thinking. Is it possible to be given a Sudoku puzzle which has many possible solutions? I think that if I don't place any pieces, clearly there would be many possible solutions. So this leads to the following:

What happens when a puzzle has multiple solutions?

The puzzle should be reported as invalid.

Ok, so now I know what happens if a puzzle has many solutions, but what if the puzzle has no solution.

What happens when a puzzle has no solution?

There is no solution for the puzzle.

Ok, so my customer gave me a pretty weird look on that one, but there is nothing wrong with asking right?

Note that my customer has not told me any specifics about how he or she would like the puzzle to be solved, only that the puzzle should be solved and what the result of a valid solved puzzle would be.

Letting The Behavior Drive Our Development

Ok, so now I'm back in the office, ready to begin work on the Sudoku solver for my customer. Where do I begin? This is where the Behavior-Driven Development (BDD) comes in to play. Behavior-Driven Development is basically a Test-Driven Development (TDD) technique where your tests are designed around the needed behaviors of your software. This should result in tests which are far easier to refactor, since most changes results in complete removal or replacement of tests instead of removing pieces of a method based test.

Additionally by wording your tests in such a way that it portrays the resulting behavior of the software, the results of the tests become easy for our customers to read to understand how the software is working.

Let's look at the resulting unit tests to show what I'm talking about. First lets look at solving a valid puzzle. (*Warning* These tests are currently written in MSTest, I will most likely change to NUnit or mbUnit before releasing the entire source code.)


[TestClass]
public abstract class When_A_Puzzle_Is_Solved
{
  private Sudoku.Solver.ISolver solver;
  private Puzzle puzzle;
  private Solution solution;

  public When_A_Puzzle_Is_Solved(Sudoku.Solver.ISolver solver)
  {
    this.solver = solver;
  }

  [TestInitialize]
  public void Initialize()
  {
    CreateSolvablePuzzle();
    solution = solver.Solve(puzzle);
  }

  private void CreateSolvablePuzzle()
  {
    puzzle = new Puzzle();

    puzzle.Rows[0][1].AssignedValue = Value.Five;
    puzzle.Rows[0][2].AssignedValue = Value.Four;
    puzzle.Rows[0][7].AssignedValue = Value.Two;
    puzzle.Rows[1][0].AssignedValue = Value.Three;
    puzzle.Rows[1][3].AssignedValue = Value.Four;
    puzzle.Rows[2][0].AssignedValue = Value.Seven;
    puzzle.Rows[2][3].AssignedValue = Value.Eight;
    puzzle.Rows[2][6].AssignedValue = Value.Three;
    puzzle.Rows[2][7].AssignedValue = Value.Five;
    puzzle.Rows[3][1].AssignedValue = Value.Seven;
    puzzle.Rows[3][2].AssignedValue = Value.One;
    puzzle.Rows[3][5].AssignedValue = Value.Five;
    puzzle.Rows[3][8].AssignedValue = Value.Three;
    puzzle.Rows[4][0].AssignedValue = Value.Six;
    puzzle.Rows[4][3].AssignedValue = Value.Three;
    puzzle.Rows[4][5].AssignedValue = Value.Eight;
    puzzle.Rows[4][8].AssignedValue = Value.Nine;
    puzzle.Rows[5][0].AssignedValue = Value.Five;
    puzzle.Rows[5][3].AssignedValue = Value.Nine;
    puzzle.Rows[5][6].AssignedValue = Value.Four;
    puzzle.Rows[5][7].AssignedValue = Value.Seven;
    puzzle.Rows[6][1].AssignedValue = Value.Eight;
    puzzle.Rows[6][2].AssignedValue = Value.Five;
    puzzle.Rows[6][5].AssignedValue = Value.Four;
    puzzle.Rows[6][8].AssignedValue = Value.One;
    puzzle.Rows[7][5].AssignedValue = Value.Three;
    puzzle.Rows[7][8].AssignedValue = Value.Six;
    puzzle.Rows[8][1].AssignedValue = Value.Six;
    puzzle.Rows[8][6].AssignedValue = Value.Eight;
    puzzle.Rows[8][7].AssignedValue = Value.Nine;
  }

  [TestMethod]
  public void All_Pieces_Should_Have_A_Value()
  {
    foreach (Piece piece in puzzle.Pieces)
    {
      Assert.IsTrue(solution.Values.ContainsKey(piece));
    }
  }

  [TestMethod]
  public void No_Column_Should_Have_Duplicate_Values()
  {
    foreach (Column col in puzzle.Columns)
    {
      List<Value> foundValues = new List<Value>();
      foreach (Piece piece in col)
      {
        Assert.IsFalse(foundValues.Contains(solution.Values[piece]));
        foundValues.Add(solution.Values[piece]);
      }
    }
  }

  [TestMethod]
  public void No_Row_Should_Have_Duplicate_Values()
  {
    foreach (Row row in puzzle.Rows)
    {
      List<Value> foundValues = new List<Value>();
      foreach (Piece piece in row)
      {
        Assert.IsFalse(foundValues.Contains(solution.Values[piece]));
        foundValues.Add(solution.Values[piece]);
      }
    }
  }

  [TestMethod]
  public void No_Region_Should_Have_Duplicate_Values()
  {
    foreach (Region region in puzzle.Regions)
    {
      List<Value> foundValues = new List<Value>();
      foreach (Piece piece in region)
      {
        Assert.IsFalse(foundValues.Contains(solution.Values[piece]));
        foundValues.Add(solution.Values[piece]);
      }
    }
  }
}

Notice how closely these tests match the above dialog I had with the fictional customer. Anyone, including the customer should be able to read that test fixture (especially how it formatted in a proper runner) and verify that the behavior is correct. Plus, the test methods themselves are very short, easy to read and verify.

Behavior-Driven Development works by you first defining the scenario. The scenario becomes the test class itself with the test initialization being the place where we place our objects in to the appropriate state for our scenario. Each method then becomes a validation of what happens in a given scenario. The methods and class names are then written out as words so it easy to tell what behaviors are being tested.

Note that the initialization logic of this test builds a valid Sudoku puzzle and then asks the solver to solve it. As proof of a valid solution I have provided the puzzle and the associated solution in red below.

There are a few things which need to be explained in this code.

First, I chose to use an enumeration for puzzle values as a way to limit the values of the puzzle. This actually looks very lame when I read it, having the names of numbers represent the numbers themselves, and it may be refactored at a later point, but for now it helped me ensure no 0s or 10s showed up (although I have learned that enumerations are pretty lame and nothing stops you from assigning an invalid integer value to the enumeration, but that's a post for another day).

Second, notice that I used an interface for my solver, not a specific solver. The reason for this is really simple. I don't know at this point how the puzzle will be solved, only what the result of a solver should be. It doesn't matter how the internal solver works at this point, provided it sticks to the interface and this root behavior.

I also made the choice to make the Puzzle class and a separate Solution class. Basically this just allows a puzzle to remain free of solution information and would theoretically allow someone to make Puzzle classes persistable and not have to worry about updating a puzzle while creating a solution for it.

Now that we have our behaviors defined for what happens with a valid puzzle, lets move on to the other cases which were discussed in the dialog with the customer.


[TestClass]
public abstract class When_A_Puzzle_Has_Multiple_Solutions
{
  private ISolver solver;
  private Puzzle puzzle;

  public When_A_Puzzle_Has_Multiple_Solutions(ISolver solver)
  {
    this.solver = solver;
  }

  [TestInitialize]
  public void Initialize()
  {
    CreateInvalidPuzzle();
  }

  private void CreateInvalidPuzzle()
  {
    puzzle = new Puzzle();

    puzzle.Rows[4][4].AssignedValue = Value.Five;
  }

  [TestMethod]
  [ExpectedException(typeof(DuplicateSolutionFoundException))]
  public void The_Solver_Should_Report_An_Invalid_Puzzle()
  {
    solver.Solve(puzzle);
  }
}

Note that in this scenario, many valid sudoku boards could be created when only one piece is filled in. As such we are saying that whenever a puzzle with many solutions is provided we expect any solver to throw an exception.

I'm not actually a big fan of this approach, but I did it anyways here. Basically checking for duplicate solutions is something which I think would actually be useful for business logic. Therefore I for see cases where I could wind up using this exception for flow control, which I am opposed to. However, since at this point I just need a failure it works fine, and I can always refactor it later.

There is still one case remaining from the solver discussion:


[TestClass]
public abstract class When_A_Puzzle_Has_No_Solution
{
  private Puzzle puzzle;
  private ISolver solver;

  public When_A_Puzzle_Has_No_Solution(ISolver solver)
  {
    this.solver = solver;
  }

  [TestInitialize]
  public void Initialize()
  {
    puzzle = new Puzzle();

    puzzle.Rows[0][0].AssignedValue = Value.Five;
    puzzle.Rows[0][1].AssignedValue = Value.One;
    puzzle.Rows[0][2].AssignedValue = Value.Three;
    puzzle.Rows[0][3].AssignedValue = Value.Two;
    puzzle.Rows[0][4].AssignedValue = Value.Nine;
    puzzle.Rows[0][5].AssignedValue = Value.Four;
    puzzle.Rows[0][6].AssignedValue = Value.Eight;
    puzzle.Rows[0][7].AssignedValue = Value.Seven;
    puzzle.Rows[0][8].AssignedValue = Value.Six;
    puzzle.Rows[1][0].AssignedValue = Value.Eight;
    puzzle.Rows[1][1].AssignedValue = Value.Two;
    puzzle.Rows[1][2].AssignedValue = Value.Seven;
    puzzle.Rows[1][3].AssignedValue = Value.Five;
    puzzle.Rows[1][4].AssignedValue = Value.Six;
    puzzle.Rows[1][5].AssignedValue = Value.One;
    puzzle.Rows[1][6].AssignedValue = Value.Three;
    puzzle.Rows[1][7].AssignedValue = Value.Four;
    puzzle.Rows[1][8].AssignedValue = Value.Nine;
    puzzle.Rows[2][0].AssignedValue = Value.Nine;
    puzzle.Rows[2][1].AssignedValue = Value.Six;
    puzzle.Rows[2][2].AssignedValue = Value.Four;
    puzzle.Rows[2][3].AssignedValue = Value.Seven;
    puzzle.Rows[2][4].AssignedValue = Value.Eight;
    puzzle.Rows[2][5].AssignedValue = Value.Three;
    puzzle.Rows[2][6].AssignedValue = Value.One;
    puzzle.Rows[2][7].AssignedValue = Value.Two;
    puzzle.Rows[2][8].AssignedValue = Value.Five;
    puzzle.Rows[3][0].AssignedValue = Value.Six;
    puzzle.Rows[3][1].AssignedValue = Value.Five;
    puzzle.Rows[3][2].AssignedValue = Value.One;
    puzzle.Rows[3][3].AssignedValue = Value.Three;
    puzzle.Rows[3][4].AssignedValue = Value.Seven;
    puzzle.Rows[3][5].AssignedValue = Value.Nine;
    puzzle.Rows[3][6].AssignedValue = Value.Two;
    puzzle.Rows[3][7].AssignedValue = Value.Eight;
    puzzle.Rows[3][8].AssignedValue = Value.Four;
    puzzle.Rows[4][0].AssignedValue = Value.Two;
    puzzle.Rows[4][1].AssignedValue = Value.Eight;
    puzzle.Rows[4][2].AssignedValue = Value.Nine;
    puzzle.Rows[4][3].AssignedValue = Value.One;
    puzzle.Rows[4][4].AssignedValue = Value.Five;
    puzzle.Rows[4][5].AssignedValue = Value.Six;
    puzzle.Rows[4][6].AssignedValue = Value.Seven;
    puzzle.Rows[4][7].AssignedValue = Value.Three;
  }

  [TestMethod]
  public void No_Solution_Should_Be_Provided()
  {
    Assert.IsNull(solver.Solve(puzzle));
  }
}

Note that for this scenario I took the puzzle from Part 0 which proved to be unsolvable and used it as my test puzzle.

Hopefully this gives you a good idea of how to define your behaviors. In the next post we'll look at creating concrete tests for an actual implementation of a solver that exhibits the behaviors we discussed here. Note that we discussed the behavior unit tests first since when developing with Behavior-Driven Development, the behavior tests come first!

--John Chapman

CodeMash 2008 Here I Come!

2008-01-02T20:36:00.000-05:00

Well, it's official I've gone and registered for CodeMash 2008! I'm really looking forward to this conference. If anyone who reads this is going to attend let me know, maybe we can meet up at some point.

These are just some of the interesting topics I'm looking forward to.

LinqTo: Implementing IQueryProvider (Bill Wagner)

Has anyone out there taken a look at what it takes to implement your own Linq provider? It's a major pain in the rear! Now, I don't know to what depths Bill will go, but any good overview would really be helpful. For this session I'm not really looking for a good how to implement guide, since I doubt I'll ever work on my own custom Linq provider, but really it's more to help me get a better grasp of how Linq is working under the covers to help myself in consuming it!

Putting the Fun into Functional with F# (Dustin Campbell)

Ok, so I've kind of been watching the boat sail on all of the popular dynamic languages. I've dabbled in the past with python, but only very slightly. I've written a modest amount of javascript to get the hang of the ideas behind it, but I think a good solid introduction to the up and coming dynamic first class citizen of .NET is in order. Let's get a good introduction to all of the fuss. I should have enough of python to follow along with the presentation. Again, this isn't something I plan to use on a day to day basis, but rather just help me understand how the other half lives, and help me to understand why I make the choices that I do.

Introduction To Behavior Driven Development (Andrew Glober)

This one concerns me a little bit with the introduction tag, but I'm starting to become a big fan of Behavior Driven Development or (BDD). Any additional insight in to the thought processes which it takes to implement it properly would be beneficial to me. Plus the fact that it is being shown for a Java implementation might help me to think a little bit out of the box while implementing BDD myself in the C# world.

Story-Driven Testing (Jim Holmes)

This one basically belongs with the prior item. It's just an area which I want to learn more about. I believe this one should have a .NET focus (not that it is even necessarily for the topic).

Introducing Castle (Jay R. Wren)

Castle is one of those projects I've grown to enjoy. I still won't use some parts of the project (like ActiveRecord), but that is also the beauty of Castle. You don't have to. You take the pieces you want. I've grown to enjoy Microkernel/Windsor and while I've never actually used MonoRail, it actually makes a lot of sense to me. The Microsoft MVC framework actually helped me realize just how good of an MVC framework already existed for the .NET platform. So, while the term Introducing may be a slight put off, there is still a chance to see some items in a different light. Plus, I've met Jay in the past, and he's a sharp guy. I would like to see a full presentation on what he has to say about the subject.

Introduction To Workflow Foundation (Keith Elder)

On this one I don't really mind the Introduction part. I really don't know much about implementing WF. I understand you need to run the engine yourself, and I've seen the GUI used to create workflows, but really I don't know much beyond that. It's something which has seemed like it would provide benefits to me and my projects in the past, but I haven't ever gotten enough expertise to know for sure if it was something to invest in or not. Hopefully this will help me down that path.

Rails: A Peek Under The Covers (Brian Sam-Bodden)

I'm going a bit in to the deep end on this one. I understand only the absolute minimum of Ruby, yet who hasn't heard of Ruby on Rails? This may give a better oversight regarding why it has become such a popular framework. I'm familiar with the ideas behind what the Rail framework offers, but seeing how it works with Ruby should be interesting.

And this is just a short list. I haven't actually checked to see what the times are for these sessions, lets just hope I am able to get to all of them.

Hopefully I'll see you all at CodeMash!

--John Chapman

Sudoku Part 0: Introduction

2007-12-30T09:44:00.000-05:00

Sudoku Part 0: Introduction
Sudoku Part 1: Defining The Solver Behavior
Sudoku Part 2: Implementing A Solver
Sudoku Part 3: Defining The Generator Behavior
Sudoku Part 4: Implementing A Generator

It's been a while since my last post here. Part of the reason it has been so long is the fact that I traveled for the holidays, making it more difficult to make time to update this blog.

While traveling I break out sudoku (and other similar puzzle games) to help the time go by on the way to my destination. As a programmer I tend to take any problem I'm solving and analyze it as if I was developing a program to solve the problem for me. This isn't generally something I follow through on, but rather just a mental exercise where I wonder about the what ifs.

While working on a Sudoku puzzle I thought, as fun as solving this puzzle is, writing an algorithm that solved it in the same manner that I do would be even more enjoyable. Better yet, there may be many ways to build a sudoku solving algorithm. I also thought that in order to make an enjoyable sudoku solving algorithm I would also need to create a sudoku generating algorithm. Again, I thought there may be potential for many algorithms.

This time it got me thinking. Sudoku is fun, maybe this would be a good platform to introduce some topics. I have spent some time reading about Behavior-Driven Development (BDD), and would like to introduce an example of it on my blog. This seems like a good candidate. Most people are familiar with the puzzles. Secondly, I would also like to use this as an example for how to use a Dependency Injection framework. The fact that I hope to be able to generate multiple algorithms would seem to enforce the use of such a tool here.

I plan to make this a multi-part series as there are too many topics to cover to justify a single blog post. I am currently investigating this program now, so don't blame me if it takes a while to write the entire series.

Initial Thoughts

When I was first thinking about these problems on the Plane I thought a sudoku generator would be relatively simple. Well I can now say with confidence that it is not. The algorithm I formed in my head went something like the following:

Divide the board in to rows, columns and regions, matching the general rules for the game.
For each row, column and region create a set of Sudoku values (1-9) which are valid to be used for that grouping.
Loop over all pieces of the board
For each piece take the intersection of the valid values from this pieces row, column and region
Randomly select a value from the remaining values, assign it's value to the piece and then remove it from the list of valid values for the pieces row, column and region.
Once a valid board is created, randomly select a piece on the board to clear the value from
Continue randomly removing values until the puzzle is no longer uniquely solvable, and re-add the last removed value.

This seemed like a reasonable algorithm to me. It seemed that there would always be a choice for valid values seeing as all previous pieces used valid values. I guess I just assumed that while placing pieces there would always be remaining valid pieces until you finished the puzzle. To my initial surprise, this algorithm failed on step 5 every time. The generator kept kitting situations where there were no valid values which could be placed on the current piece.

See the below example of the result of my algorithm. Note that there is no valid value which can be placed in the next box, even though all previous entries were entirely valid. According to the row of the piece the value should be 4. Yet 4 is invalid for that piece's column and region. So clearly 4 will not work there. Any value besides 4 will cause an issue for the row. This algorithm clearly doesn't work.

With that experiment I'm pretty much back to the drawing board. I do have a few ideas on algorithms that should work, but my goal with this is to have at least two working sudoku generation algorithms. So far I'm at least enjoying the hunt for a working algorithm. I would like to create at least one solution on my own, but at some point I may have to break down and look for some assistance.

--John Chapman

UI: Good Use For Extension Methods

2007-12-16T12:59:00.001-05:00

Ok, this is a little weird for me, but I think I just had my epiphany. I think I have finally converted in to an Extnsions Methods believer! I know, first there was C# 3.0 Extension Methods? A Good Idea? and then there was Reserving Judgement, but now I have found where I really, really like them.

How many of you have written a class like this:


public class Person
{
   private string firstName;
   private string lastName;

   public string FirstName
   {
       get { return firstName; }
       set { firstName = value; }
   }

   public string LastName
   {
       get { return lastName; }
       set { lastName = value; }
   }

   public string GetFullName()
   {
       return LastName + ", " + FirstName;
   }
}

I don't know about you, but I feel dirty every time I write something like that. To me this is display logic, and now it's polluting my business objects! This really smells to me. This smells so bad that I prefer to put a method on my page which does the formatting for me. But the problem is that people are used to this sort of syntax. They expect this to be how they format that class.

How do we satisfy both sides? Keep the presentation logic out of the business layer, yet keep the interfaces clean? Enter Extension Methods!

In order to solve this problem I would now create a new static class in my web assembly (UIHelper possibly, or another name that fits). This new class would look like the following:


public static class UIHelper
{
   public static string GetFullName(this Person person)
   {
       return person.LastName + ", " + person.FirstName;
   }
}

Now you can take the GetFullName method out of the Person class and use the extension method in your UI layer instead. The class will still work exactly the same way from a UI perspective, except when working within the Person there will no longer be a GetFullName method.

The Person class now looks like this:


public class Person
{
   private string firstName;
   private string lastName;

   public string FirstName
   {
       get { return firstName; }
       set { firstName = value; }
   }

   public string LastName
   {
       get { return lastName; }
       set { lastName = value; }
   }
}

Just make sure you add the using directive to the namespace which contains the UIHelper class on your page (or add an Import directive to your aspx file). Your code on the page now looks like the following:

This is actually the happiest I've been with any use of extension methods when you control the class which is being extended.

--John Chapman

Are Developers Lazy?

2007-12-16T06:27:00.000-05:00

I have been watching the ASP.NET 3.5 Extensions with great interest. Of special note is the MVC framework that Microsoft is adding to ASP.NET. If you haven't heard anything about this framework I recommend you go take a look at the posts Scott Guthrie has made starting with this one. I'm really excited about the potential enhancements which are offered with this new framework. Yes, I know Monorail is nothing new, but something has always kept me from adopting it.

Of particular interest with the Mvc framework is the ability to easily test the majority of your UI code. This is something which today is near impossible. Plus, who hasn't been frustrated with the quality of the HTML which are generated by the ASP.NET WebForms? Finally a way to take real control of your web pages while still using the ASP.NET pipelines (or at least what is remaining of it).

What has really caught me by surprise though is the amount of complaining people are doing regarding the ControllerActionAttribute. Basically with the Mvc framework in order to expose an action from a controller (an action basically equates to the way a given URL interacts with the controller) you need to mark it with the ControllerActionAttribute. This is the default policy which Microsoft provides, and you can change it if you want to go through the many steps involved in re-working some of their components.

Developers have been seemingly outraged by this. Instead most developers (at least the ones who speak the loudest) seem to say that any public method on the Controller should automatically be considered a controller action meaning all public methods of a controller should be publicly accessible via a URL. Now, I may be in the minority here, but having public methods exposed from a URL is actually pretty scary, and I actually like explicitly specifying which methods are exposed to a URL and which are not. Not because I wouldn't be able to tell with just public methods, and not that I wouldn't be able to use it properly, but just from a sense that many developers mistakenly write public methods when they should not be public. A developer may not realize what the "magic" is which is taking place. By making it specific it takes very little time, and then there is far less chance of mistakenly exposing parts of the application that have no business being exposed.

Is it really that much work to mark a property as [ControllerAction]. I don't get it. It takes half a millisecond, and then everything is clear. After all, we do this same sort of thin with all of our unit testing frameworks don't we? Why not just automatically treat every public method of a test fixture as a test unless otherwise marked? The argument seems to hold there as well. I understand other Mvc frameworks have worked in this way where an attribute wasn't needed, but so what? Is it that we're lazy, or is it that we are resistant to change? If we're resistant to change, then it seems like this whole argument is moot since this Mvc framework is a big change already.

Maybe instead we're resistant to change so complaining ensues for a couple of months before we realize that there are actually benefits on the other side and then we quiet down for a while?

The really interesting part to all of this is that the people complaining about the attribute are the same people who complain about the designer and drag & drop "programming". Admittedly, I am also one of those people who hates the designer. This means that when it comes to writing their pages they aren't being lazy. They are taking great care of the final output and look of their application.

So if being lazy is not a problem while writing the HTML for your web pages (or views as I should say with Mvc), then why is assigning an attribute such a big deal?

--John Chapman

Visual Studio 2008 Test Result Cleanup!

2007-12-12T19:59:00.000-05:00

I don't know how many other people used the MSTest (Unit Testing capabilities of Visual Studio 2005 Team Edition) but those test results really pile up after a while.

We currently have 525 unit tests on our current project. At one point in time I noticed that my disk space was running low on my development machine. I had no clue how so much space could evaporate so quickly. I started doing quick checks on different folders that I thought could be problematic. I eventually found my way to our solution folders. We typically have multiple branches loaded on our local machine, but I never thought we wrote enough code to justify a 20+ Gig project folder. Further investigation led me to a folder known as TestResults. I found out that Visual Studio was keeping the results of every unit test run I ever did.

Don't get me wrong, I love the ability to review past test runs to see where one failed. I really enjoy the ability to create bugs directly from the results of the test where the associated result is attached to the bug for the assigned developer to review (assuming it wasn't the assigned developer that noticed the failing test). But keeping a history of these files was really adding up!

I found myself deleting the old test runs from this folder every so often. Then something really interesting happened today. I tried running my full suite of tests after loading the solution in Visual Studio 2008. A message box appeared stating that my old test runs will be deleted since I will be over the maximum of 25 historical test runs. It made me agree to the deletion of these items and also told me that the number was configurable in the Tools > Options menu!

Now, maybe this feature existed in 2005, but I could never find it. This turns out to be one of those features that isn't really advertised, isn't major but just made me happy. For some reason it's the little things that seem to get me excited. It seems like this would have been so simple to leave out, yet they took care of it anyway.

Good job on that one Microsoft! You just made my life a little easier.

--John Chapman

Open Source Rocks!

2007-12-10T20:17:00.000-05:00

I've recently began seriously investigating mocking frameworks (See NMock and Rhino Mocks specifically). I've looked at mock frameworks before, but I was quick to dismiss them. I never really saw the benefit. I honestly don't think I really understood what they were used for.

At first I thought maybe it was used to automatically create my business objects so that I would have full object graphs in memory. This is something we use a lot to perform mapping file tests, it turned out the tools didn't really fit for this purpose, and I pushed them aside.

Now, I spent some time again wondering if I missed the big picture when I looked before. After all this was years ago that I last researched mock frameworks. While the NMock interface seemed pretty clean to me I didn't like the use of strings. Rhino Mock's ability to use strongly typed method calls was a deal sealer. How could I use a weakly typed mock framework when a popular strongly typed variety exists?

I've decided that mock frameworks come in handy while performing unit tests which would otherwise use external resources. Previously I always skipped testing these methods and moved as much of the business logic to methods which had no outside dependencies. I've finally seen the light and embraced the mock frameworks for what they were truly intended.

If you haven't looked at Rhino Mocks, I strongly recommend you do! Let's take a very simple example to see the power of this tool! This is a totally contrived example, so don't blame me if it is unrealistic. Let's say you have a dependency on an external pricing service which finds the best available price for a given product in your companies purchasing department. Let's define the needed interface as IPricingService


public interface IPricingService
{
  decimal GetPrice(Product p);
}

A very simple service for sure. Given any product it will return the current price which we can pay for that product. We'll use this service in our AddDetail Method of our Order class. See the Order, OrderDetail and Product implementations below. Note I use public fields for brevity only.


public class Product
{
  public int Id;
  public string Name;
}

public class Order
{
  private IPricingService pricingService;

  public IList<OrderDetail> Details
      = new List<OrderDetail>();

  public Order(IPricingService  pricingService)
  {
      this.pricingService = pricingService;
  }

  public OrderDetail AddDetail(Product product, int quantity)
  {
      OrderDetail detail
          = new OrderDetail(
              product,
              quantity,
              pricingService.GetPrice(product));

      Details.Add(detail);
      return detail;
  }
}

public class OrderDetail
{
  public Product Product;
  public int Quantity;
  public decimal Price;

  public OrderDetail(Product product, 
      int quantity, 
      decimal price)
  {
      this.Product = product;
      this.Quantity = quantity;
      this.Price = price;
  }
}

Now our job is to test the AddDetail method which we see above. Well we don't want to rely on an actual pricing service which would use in production, so instead we will resort to our trusty Rhino Mocks framework to fill in a fake implementation. Now we can test 100% of the code in our Order without worrying about external dependencies. This helps keep our unit tests focussed as well as allows us to improve our code coverage.


[TestMethod]
public void AddDetail()
{
  MockRepository mocks = new MockRepository();
  Product p = new Product();

  IPricingService pricingService
      = mocks.CreateMock<IPricingService>();

  Expect.Call(pricingService.GetPrice(p)).Return(15.50M);

  mocks.ReplayAll();

  Order order = new Order(pricingService);
  OrderDetail newDetail = order.AddDetail(p, 20);
  Assert.AreEqual<decimal>(15.50M, newDetail.Price);
  Assert.AreEqual<int>(20, newDetail.Quantity);

  mocks.VerifyAll();
}

Take special note of the MockRepository, the CreateMock method and the Expect builder. Expect basically tells the framework that it should expect a call to the method provided in the Call() and to expect it for the specified parameter. When the mock receives that call that the provided parameter it should return the value 15.5 as the price.

ReplayAll is a bit confusing, but basically this tells Rhino Mocks to stop using the method calls for recording instead use it to return the results we configured and to track the calls which are made.

After we have called ReplayAll we make our method calls and assert that the new order detail was created correctly and added with the appropriate price which was returned by the pricing service. VerifyAll tells us that our expectations we created before replaying were met (such as expecting a call to the GetPrice method with a parameter of p.

If I didn't want to set expectations for method calls I could have opted for the SetupResults class instead of Expect class.

This is just the tip of the ice berg regarding the framework. If this peeked your interest, you owe it to yourself to take a deeper look.

If you're like me and you saw the Expect.Call() taking an execution of the method you expect a call for you asked yourself "How the heck did he do that?" When I first tried it I was blown away that it worked. I tried to come up with ideas of how it worked.

This is one of the true beauties of open source software. I can satisfy my own curiosity! After playing with the framework I downloaded the source code to check it out. The final implementation wasn't actually that complex. Basically the proxy object which the mock framework creates tracks what the last method call was and what parameters were provided to the method call. So the Call() method doesn't really do anything except return the options for the last method call which was made. The fact that it is provided as an argument to Call() is complete ignored! I view this as genius. It's really thinking out of the box in a way that I'm not so sure I would have come up with. Being exposed to code that works in different ways that I think allows me to expand my mind and come up with solutions to my own problems I may not have previously come up with.

I've also spent a considerable amount of time reviewing some of the NHibernate code. This is after all how I was able to write such a specific performance test regarding the performance of NHibernate accessors after all. I used just the specific NHibernate pieces I needed.

As software developers we are unbelievable lucky to be living in such a day and age where such great software code is available for free for us to learn from. I recommend to everyone interested in really improving their skills find an open source project which revolves around something you are interested in and take a look. There is tons of great stuff out there! We should all take advantage.

Lastly, I just want to thank Oren Eini (aka Ayende Rahien), this Rhino Mocks framework he created is truly awesome.

--John Chapman

Linq to Sql: The Good, The Bad & The Bottom Line

2007-12-09T20:07:00.000-05:00

I promised my take on Linq to Sql a few days ago. I have spent some time over the past couple days playing with Linq to Sql connected to the AdventureWorks SQL Server sample database.

I have a lot of experience working with NHibernate so you may see some comparisons throughout the post.

Overview

Most everyone who is likely to read this post probably knows what Linq to Sql is. For those that don't, Linq to Sql (and really Linq in general) has been one of the most talked about (Once we found out Linq to Entities wasn't going to ship with Visual Studio 2008) and hyped features of Visual Studio 2008 and the .NET 3.5 framework.

Linq to Sql is actually a big shift for Microsoft. Linq to Sql is Microsoft's first production quality Object Relational Mapper or O/RM for short. They may have tried in the past with products such as ObjectSpaces, but this is the first tool to be released as a completed tool. O/RM tools exist to try and solve the Object-relational impedance mismatch which basically says that most applications are developed in object oriented programming languages these days yet the data which they operate on is typically stored in a relational database. This process of moving data between the objects and relations and vice versa is described as the impedance mismatch. There are obviously many fundamental differences between data stored in a relation and data stored in our objects.

Traditionally Microsoft has endorsed using DataSets to solve this problem. DataSets are essentially a relation based object in your object oriented programming language. Essentially it would allow you to work with your data in your application as relational data. The problem with this? You fail to take advantage of object oriented application design and the advantages it brings to you. Typically these programs have little testability and a significant amount of duplication. As such many O/RM tools became popular (although far less so than if Microsoft had endorsed them) such as NHibernate, LLBLGen Pro, Vanatec OpenAccess, Wilson ORMapper, EntitySpaces, eXpress Persistent Objects and many others (apologies to any I didn't list).

Note that Linq to Sql isn't necessarily a direct competitor to NHibernate or the other above listed O/RM tools for the .NET framework, that is Linq to Entities (AKA ADO.NET Entity Framework). Linq to Sql is more of an introduction to the O/RM world.

The Good

The Linq query language itself

The Linq query language is just awesome. It really is a joy when you start to work with it. It can quickly become a pain because it is complex, but then it makes you realize just how powerful it is. I have never seen a query language that is quite so rich. Basic queries are very simple to write and understand, yet it also provides functionality for very complex queries.

Plus, the queries are strongly typed so now there is much less to worry about when refactoring your business objects as compile-time checks are now available for your queries. Note that even with stored procedures, if you change a column in a table referenced by a stored procedure, it won't inform you that you just broke a stored procedure. Likewise stored queries in your applications will not inform you if you change a property name or column either.

For fun see the following blog post: Taking LINQ to Objects to Extremes: A fully LINQified RayTracer. This is not something you woudl actually do, but it does help reinforce just how powerful Linq really is.

Better Naming Conventions Than NHibernate

While working with Linq to Sql I felt that the methods on the context were easy to understand and more intuitive than the NHibernate equivalents. For example, when you want to save your changes to your database NHibernate says Flush whereas Linq to Sql uses SubmitChanges. But the big advantages are Linq to Sql's InsertOnSubmit vs NHibernate's Save as well as Attach versus NHibernate's Update or Lock methods.

I can't tell you how many times I've explained how the Save, Update and Lock functionality for NHibernate works. Most people seem to think that they need to call these methods to cause a database operation to take place. They assume Save = Execute Insert NOW, and Update means execute an update NOW! Then they use Flush for good measure because someone told them too. The Linq to Sql naming convention seems to imply that that is not quite what is going on.

Simple to Get Started

It didn't take me very long to get up and going with Linq to Sql. While I'm not the biggest fan of the Object Relational Designer, it sure is easy to use and fast to build basic object graphs. Someone who is not familiar with O/RM tools should be able to have objects mapped to database tables in a matter of minutes. This could work very well for simple RAD applications. This process really couldn't be much simpler.

Superior Optimistic Concurrency Support

My apologies to any O/RM tools out there that have as good concurrency support as Linq to Sql, I just know I prefer the flexibilty offered by Linq to Sql over NHibernate's. Now, that being said NHibernate's concurrency has always worked fine for me, it's just nice to have additional options.

First, when a ChangeConflictException is thrown it includes a ton of information such as the entity involved, the columns involved and allows your code to recover from it. Linq to Sql will also let you configure if you want to catch all change conflicts or fail as soon as the first conflict is found. These are features, which to my knowledge, NHibernate does not support.

Plus, this is basic but Linq to Sql has native support for SQL Server timestamp columns. This allows you to ensure that you know of all updates even if it occurs outside the scope of Linq to Sql. For some reason NHibernate still does not support this type of column. Instead it rolls its own version column.

Resolving stale data with RefreshMode allows for many options when re-syncing your objects with the database. Again, I just like the options.

Superior Stored Procedure Support

If you have a wealth of stored procedures, rest assured they are easy to use from Linq to Sql. Just drag (I do feel dirty using that word) the stored procedure from the server explorer to the methods list in the object relational designer and you will see a new method on your associated context which directly calls that stored procedure. To your code it looks the same as any other method.

Note it is also possible to write your Linq to Sql CRUD through stored procedures. This is also a relatively simple process.

The Bad

Very Basic Object Support

This is actually the killer here. Linq to Sql is a very basic O/RM and does not support many of the object oriented concepts sophisticated applications are likely to use. Just a few of the missing features are:

No Inheritance
No Value based objects (IE NHibernate Components)
No Timespan support (A huge problem for the Logistics field I work in)
Collections limited to EntitySet (which isn't even a real Set)

Where is the Dictionary support at least?

No SaveOrUpdate Equivalent

This forces more persistence knowledge to a lower level requiring that all code which associates an object with a context must know if it already exists in the database or not. This basically just adds extra checks in your code which should not be necessary. Sometimes it can seem a bit dirty to check if an object already has a primary key or not yourself, it seems like logic which doesn't belong within the application itself.

GUI based Drag & Drop

Yes, I know you can use a seperate mapping file, much like you can with NHibernate, but this isn't realistic. If you don't use the designer, you don't get the code generation. If you don't get the code generation you are responsible for writing all of the many Hooks in your objects that Linq to Sql needs. Folks, these objects are quite dirty. At least with NHibernate your objects are complete persistence ignorant (aka POCO aka Plain Old CLR Object) meaning they look clean and usable for more than just NHibernate. Therefore using anything besides the designer isn't very feasible.

The big problem here though is that your entire object graph needs to live in one diagram and the code behind these objects winds up in a single code file by default. This just isn't acceptable for applications of any size. Diagrams which contain 20-30 objects would be a major pain here, let alone applications that have hundreds. For large applications this just wouldn't fly.

Relationships Aren't Interface Based

All of the associations to related objects are handled with EntitySet and EntityRef. Whereas with NHibernate you have the ISet and just the object type you expect. This basically forces the Linq to Sql references on your object, decreasing the ability for unit testing your objects in my opinion. I also don't like the persistence based decencies on my objects.

Transaction API is Goofy

For whatever reason you need to handle all explicit transactions outside of the Linq to Sql context. You have to create and the commit it outside the context while supplying the transaction to the context while it is in use. Linq to Sql implicitly uses transactions for all calls to SubmitChanges, but you would think it would be possible to begin new transactions via the context, and then commit or roll them back through the context as well.

The Bottom Line

Really, I have only touched on a brief overview of Linq to Sql here. The important question I ask myself is, "Would I use this framework?". Well, it's a bit of a difficult question. If I was writing a small application which I knew would not grow in to a large one and my object model would be simple enough for the limited object support, yes I would use it. I could get up and going very fast, and I enjoy working with the context interfaces.

However, if I was working on a larger application (really doesn't take much to be too large for what I would do with Linq to Sql), or one which I thought had potential to adjust and grow over time, I would skip Linq to Sql and look for my trusty NHibernate.

So really, it would only be used for a very small subset of problems out there that I would try to solve.

All of that being said, I think Linq to Sql is very important to the .NET development community. Microsoft has historically tried to pretend that O/RM tools didn't exist and to do any development except their DataSets or repetitive patterns was crazy. Now that Microsoft has a framework to endorse it should greatly expand the exposure to such technologies in the .NET development community. I think overall this is a good thing, and will result in overall superior developers.

My only concern with this introduction is that people may get the idea that O/RM tools are nice, and get you up and going fast but fall flat on their face once you try to do anything advanced and then you need to resort to the same tools you used all along. This was actually a very common opinion by people I talked to about NHibernate a few years ago. They had heard of others using O/RM tools (not NHibernate specifically) and how they just don't handle advanced things, they are only good for simple things.

With Linq to Sql I hope developers become exposed to O/RM and become curious about other tools such as NHibernate when Linq to Sql is too simple for what they need instead of grouping all O/RM tools together as being too simple and idealistic.

I'm actually excited about the potential of the .NET development community now that more people will be exposed to O/RM. Long live O/RM tools, you have been lifesavers for me!

--John Chapman

More on Extension Method Judgment

2007-12-09T11:19:00.000-05:00

Just another tidbit from my last post Reserving Judgment. I was reading Scott Guthrie's latest post on the ASP.NET MVC framework (ASP.NET MVC Framework (Part 4): Handling Form Edit and Post Scenarios), and noticed that he showed a tool which was using extension methods in much the same way Greg Young was describing. See Scott's use of the ASP.NET MVC HTML Helpers.

What can I say, I actually kind of like how they work in that scenario.

Reserving Judgment

2007-12-09T10:06:00.000-05:00

I have been very quick to put down certain pieces of the .NET 3.5 framework (reference prior post on extension methods and partial methods), most specifically extension methods and partial methods. I'm not quite ready to give in on partial methods yet, they still just seem like a tool used to make code generators slightly easier, but I think I'm ready to reserve judgment on extension methods now.

I still think extension methods are dangerous and are going to be subject to blatant misuse. That being said, I think I need to keep an open mind regarding the potential uses for extension methods. Note that I'm referring to the use of extension methods entirely within code that you control.

I recently read a blog post by Greg Young titled A Use For Extension Methods where he basically stated that there are a lot of people out there that share my kind of viewpoint. He also wanted to show one possible way where extension methods could be used. He basically showed that extension methods were useful in controlling the context of intellisense when using a fluent interface for a pseudo-builder pattern. I call it pseudo since really there is only one type of available builder.

Basically his extension method looks like the following:


                         public class Builder
                {
                }
                 
            
             public class Create
              {
                  public static Builder New = new Builder();
              }
          

            public static CostBuilder Cost(this Builder s)
              {
                  return new CostBuilder();
              }

So now when you call the Create.New you'll only see the builders which are in the namespaces which you referenced in your using directives.

Fair enough, upon seeing this I thought it seemed interesting, but went in to my pessimistic anti-extension method mode and came up with my usual answer, why not just do this:


public class Create
              {
                  public T New()  where T : new()
    {
        return new T();
    }
              }

But upon reading this, it's pretty lame isn't it? It's basically a generic factory that doesn't new anything, why not just call new CostBuilder().DoStuff().DoMoreStuff()?

But Greg's interface is a bit cleaner than what I am offering. It's not that extension methods are really needed here, it's just that it can actually make your code a little cleaner and slightly easier to read (when working on large projects), which is something I didn't expect to say regarding extension methods.

Maybe I need to wait this one out for a year to see what kinds of things developers come up with while using extension methods.

--John Chapman

C# Type Inference But Still Strongly Typed

2007-12-08T19:15:00.000-05:00

I have spent considerable time today reviewing Linq and more specifically Linq to Sql. I'm currently working on a blog post where I'll go in to the details of what I think the pros and cons of Linq to Sql are as well as my overall opinion. In case you couldn't guess it I'll be using NHibernate for my comparisons, after all it is what I'm familiar with.

While reviewing some things I ran in to the following compile time check. It was very simple for me to resolve, but I wonder if it will cause developers to fall in to traps. Especially those developers who have some experience with weakly typed languages such as Javascript.

Take a look at the following code I wrote:


AdventureWorksDataContext context = 
    new AdventureWorksDataContext();

var orders = from po in context.PurchaseOrderHeaders
           select po;

if (chkUseDate.Checked)
{
  orders = from po in orders
           where po.OrderDate > dtOrderFrom.Value
           select po;
}

orders = from po in orders
       orderby po.OrderDate ascending
       select new
       {
           po.PurchaseOrderID,
           po.RevisionNumber,
           po.OrderDate,
           po.ShipDate
       };

Does anyone see what is wrong with the code above and why it failed to compile?

The compile-time error was:

Cannot implicitly convert type 'System.Linq.IQueryable<AnonymousType#1>' to 'System.Linq.IQueryable<BLL.PurchaseOrderHeader>'. An explicit conversion exists (are you missing a cast?)

After seeing that I immediately realized that I tried to use an object which type inferred to return PurchaseOrderHeader objects to return anonymous type objects instead. You can't just change a reference to be of another type in C# 3.0, hence the strong typing, I should know better.

But honestly, with the whole var keyword, I wasn't really thinking about it. It was a minor slip up, but I wonder how many developers will fall in to that trap. I think some developers may have seen the var keyword before in Javascript and they may have used it in the fashion I just did.

That being said, I have been enjoying my time with Linq today. I should have a post up within the next few days with more details.

P.S. If you're wondering what is going on with the 3 step linq ueries above, that's how you write dynamic queries in Linq. Simply reference the previously defined query in your new linq query in order to further restrict the query which you are building. Keep in mind that writing a linq query doesn't perform any operations. You have to either enumerate over the values of the query or call a method on the query like ToArray(), ToDictionary(), Select() etc...

If you're curious how to resolve the issue above you just need to declare a new variable for the last query to store the new type. var results = <Linq expression> would work just fine.

--John Chapman

Solution Folders To Group Projects

2007-12-08T16:49:00.000-05:00

While reading Scott Guthrie's blog today I stumbled upon one of his links of the day for december 8th entitled Big Solutions Can Be Organized Using Solution Folders which is at the .NET Tip of the Day web site.

Actually, this is really cool. Am I the only schmuck who didn't realize this was possible? I have used Solution Folders in the past, but it was always to group files which were not part of the actual build process. For example we always had a Libraries folder which contained the third party dlls which need to be referenced to build the project. This way all a developer needs to do to build the project is to download the latest source code, and the solution will automatically download the needed referenced assemblies. Plus any upgrade we do to a third party dll automatically propagates when someone gets latest.

But the ability to place projects within the folders to group them together? This will actually be very handy for us. At work our current solution has 33 projects, and truthfully it is growing! Being able to group the projects which are similar or somehow related will really come in handy for us.

Why didn't I realize this sooner?

--John Chapman