Chris Holmes Online

If you read this blog with any regularity you know that my workplace adopted CAB a while ago. At the time we were inspecting CAB we looked at a lot of other things; we looked at IoC containers like Spring.Net, PicoContainer.Net, etc. But what we found with the CAB was that it offered more than an IoC container; it offered a whole slew of other features (EventBroker, CommandHandler, Workspaces) that made our lives easier and more productive. It gave us a consistent way to tackle repeating problems.

Today, Ayende decided to bash the Patterns & Practices team at Microsoft. He also took a shot at CAB.

All I can say is I’m terribly disappointed. Ayende’s blog comes through my aggregator and I read his posts every day. Reading his blog is interesting; I don’t always agree with what he says, but many times I do. And often his insight comes from a place of deep knowledge. That’s why I read his blog; because he knows things and doesn’t just spout off uninformed opinions.

At least, until now.

His comments on the CAB appear to come from a place of deep ignorance. They are the same comments I’ve read from other people who have taken a cursory look at the CAB and dismissed it as “too complicated”. Instead of taking the the time to actually grok the technology, they just bash it.

The CAB is a good example, I like some of the ideas there, but it comes with so much weight around it that it is not worth bothering. I can build on the same ideas in half a day and end up with a far more light wieght approach, easily testable and easier to explain to the next developer.

Not worth bothering? Maybe if bothered with, the benefits of the framework would become apparent. It’s possible that Ayende thinks it’s just a bloated IoC container not worthy to lick Castle’s boots. And that would be unfortunate because CAB is way more than an IoC container.

But the part that really puzzles me is the “weight” comment. Now, I’ll concede there’s a learning curve involved with CAB. It takes some time to grok the framework and what it is capable of doing. But once you do, it’s simplicity of use and flexibility makes it very attractive. That said, I don’t think the learning curve is what Ayende is talking about. My guess is that he’s talking about the amount of code included in the framework and the amount of code you have to write to make something work in CAB.

The amount of code in the framework doesn’t seem to me to be any more than any other framework when you take into account that CAB is doing a hell of a lot more than IoC. And the amount of code you have to write to actually make a CAB application work seems like a pittance compared to the benefits you gain from using it.

Then there’s this comment:

The stuff that they release almost always build on the naked CLR, it tries to build on top of that something to ease the pains of people who are working with that. The problem is that if you are doing that, you may be making great strides in making a developer life easier, but you are taking them in the completely wrong direction.

The wrong direction? What direciton would that be? Productive?

I don’t know where Ayende works or what sort of environment he works in, but I know he gets a lot of time to blog and maintain his own open source mock framework. Not everyone has that luxery. We have to get real work done under time constraints. We have customers who expect results yesterday. We’re in the trenches trying to implement features for customers who have unrealistic expectations about when things should get done. That’s just a fact of programming life in many business environments. It doesn’t matter how often we explain Agile to our customers, they still think in terms of deadlines and they want everything now. Anything that helps us achieve our goals is a good thing.

Tools like CAB and Enterprise Library help us achieve our goals in an expedient fashion. That’s the bottom line. They give us a consisten way solve problems.

Yes, we could sit down and write our own framework and it undoubtedly would be more lightweight than the CAB because it would serve just our purposes and not attempt to solve anyone else’s problems. But that takes time. Maybe Ayende is a supergenius ready to take the crown from Marilyn Vos Savant and that’s why he can claim to write his own CAB in half a day, I don’t know. I’d certainly like to see it; I’d like to see a lightweight CAB with all of the CAB’s features written in half a day. That would be impressive.

Mostly, though, I think Ayende just hasn’t done his homework, which seems really out of character for him. He tries to act like he has done his homework:

I am not speaking blindly here, it took me 40 minutes to repreduce the policy injection block.

This brings up a really good point: There are tools out there that can accomplish certain tasks. If Microsoft builds another tool on top of something, which tool should they choose? If the P&P guys were going to build CAB without ObjectBuilder, for instance, then what IoC container should they have used? Would it be a good idea for them to build CAB on top of Castle Windsor? Would that be an endorsement of Windsor that Microsoft would deem unacceptable? Would it be acceptable for them to build Enterprise Library using Castle Windsor?

I can see why P&P builds their own pieces: they don’t want to rely or endorse 3rd party OSS.

The fact that P&P has built their own tools, like ObjectBuilder and the Policy Injection Block, seems like an unfair reason to condemn the whole Enterprise Library. Like saying, “one aspect of this thing sucks, so the whole thing is useless to me.”

Of course, that’s pretty Ayend’s modus operandi. If something is of no value to him personally, it must suck. Even his buddy Roy Osherove had to call him out on that behavior lately.

But what’s more baffling is this comment:

When looking at the stuff that the P&P produce, I see things that are extremely complex to their purpose, hard to use and maintain, and don’t really add any value to me from where I stand today.

When I read Ayende say that the P&P’s tools are “extremely complex” and “hard to use” I almost can’t believe it. Ayende is a smart guy. So how come he can’t grok Enterprise Library and the simplicity of the tools?

My guess is that this all has to do with familiarity. And every single one of us programmers is guilty of this behavior: we learn the tools we like, and when something else comes along, if it’s not immediately apparent that it is simpler and easier to use (even though it may be) then we dismiss it. And I’m just as guilty of this as Ayende is.

It took me a while to grok exception management and logging using Enterprise Library. For a long time I considered using some other tools, but because I’m stubborn I decided to keep at it until I had it figured out. And at first EntLib did seem complex and hard to use. Then the light bulb went on on my head and I got it. And holy cow, is it ever easy to use. It’s not complex at all; it’s not hard to use. It just has – like many things in life – a learning curve.

At the end of the day this all boils down to productivity. Ayende’s suggestion is often: cobble together your own solution. But why should everyone have to reinvent the wheel? What is wrong with P&P coming along and saying, “Hey, we see this common problem, we’ll provide a solution. You don’t have to use it, but if you don’t want to take the time to build your own, go ahead and use this.”

How many developers need a framework like CAB? Judging from the message boards and downloads, I’d say a lot. Ayende wants to build is own in half a day. Great, he solve his problem, but what about everyone else who still has the same problem? Will Ayende solve all of our problems?

The solutions from P&P may not be perfect. And when they’re not, we are free to choose a different path. But I find it really difficult to fault them for providing solutions that help developers be more productive.

And I find it disturbing that someone as smart and respected as Ayende would stoop to bashing P&P and making claims like, “I can build on the same ideas in half a day and end up with a far more light wieght approach”. That comes off sounding rather ignorant (and insulting), especially to those of us who have grokked the CAB and use it every day.

I guess, more than anything, I’m just jealous of Ayende. I wish I were as smart and fast as he is. Because I know it would take me a lot longer than half a day to build a framework like CAB that had all of the features that CAB has. And that is why we elected to use the CAB; because when my boss asked me how long it would take for me to build a simliar framework, I didn’t say half a day, I said a lot longer. So to be productive we turned to the CAB.

I’m just jealous; I’m too slow and dumb.

Zombie movies have forever been the comedy of the horror film industry. Few other genres have produced so many unintentionally funny moments or as many lines of bad dialog as zombie films. That was until recently, when director Danny Boyle unleashed his harrowing tale of a virus outbreak on the isle of Great Britain in the summer of 2002. His film, 28 Days Later, redefined what zombie films were capable of; it showed us that such films actually could be scary and real.

Boyle’s zombies were not the slow, plodding flesh eaters of movies past, but instead Rage infected humans gone berserk, with a speed and agility equal to their uninfected prey. His vision was rooted in reality; a virus was unintentionally let loose by a band of do-good animal activists, and 28 days later the city of London is discovered abandon and devoid of life by a head trauma patient who must have been mistaken for dead in a hospital ward. The film follows this man, Jim, played then by little-known Cillian Murphy, as he finds other survivors and attempts to understand what has happened to his world. The movie was filmed using video, and has a raw, gritty edge to it. It feels real, and we accept it without any questions asked. There’s no campy dialog, no silly monsters, and the whole thing feels very frightening and possible.

One of the primary questions the movie raises is this: Did the Rage virus mange to infect the entire world, or just Great Britain?

28 Weeks Later, the follow up by director Juan Carlos Fresnadillo, answers that question. But 28 Weeks Later does much more than attempt to cash in on the success of its parent film; it takes the story that Danny Boyle created and catapults it down a new path that is just as frightening, thrilling and visceral as its predecessor. Fresnadillo deserves a lot of credit for not only staying true to the world, story and directorial style of Boyle, but for creating a sequel that is actually better than the original, something very few sequels can lay claim to.

28 Weeks Later starts off with perhaps the best opening ten minutes of any film this year; it’s intense and frightening and instantly forces us to brace ourselves for what is to come. We realize immediately there will be no easing into the gruesome truth of this world. Fasten your seat belts and get ready to ride.

After the opening we’re given a small montage that brings us through the events of the past 28 weeks; through the spread of the Rage virus, the subsequent death of the “infected” as they starve, the pronouncement that Great Britian is safe from the virus, and up to the present time, where a US based military operation is overseeing the reintroduction of humans into Britain. Families are reunited and people start to make some attempt to return to normal, all the while the threat of the virus remains because so little is known or understood about it.

But this wouldn’t be a zombie film if life returned to normal, now would it?

Somewhere along the way things go bad. I can’t say what happens without revealing a small twist that Fresnadillo injects into the franchise, but it’s a welcome twist that furthers the story. Violence ensues, with many zombies, lots of blood and quite a bit of fear and panic.

What is surprising about the movie is how well it works for a sequel without two key ingredients: the previous director and cast. This is a totally different film, helmed by a new director and complete with a new cast. Well, I say new but they aren’t; 28 Days Later was a story about one group of people coping with the Rage virus in their corner of London. 28 Weeks Later deals with the same virus, only much later. It makes total sense that the original cast is nowhere to be found, because this is a different story. But Fresnadillo does such an amazing job that we feel like we never left the other film. The continuity between the two movies is amazing.

What makes the film work are the same ingredients that made the original work: The zombies are fast, aggressive and deadly. They strike fear instantly. The setting makes them dangerous in the extreme, and survival is paramount. And because it’s all based on a very nasty, fast-traveling virus, it feels realistic. It becomes easy to suspend any disbelief while watching this movie, and that makes the horror of it all the more terrifying. The cast is great and believable, and we feel their fear and pain every step of the way. Fresnadillo paces the film just as well as Boyle did in the original, if not better; there’s not a wasted frame in the whole thing and we feel like we need to catch our breath just watching.

Sequels so frequently disappoint; they often lack the magic of their predecessors, or they lack the writing/casting/directing to make them work properly. Quite often we’re fed sequels that do little more than exploit a name brand for cash purposes (Ocean’s 12). Thankfully, 28 Weeks Later does not fall into this category. If anything, it surpasses the benchmark set by the first film.

Here’s hoping that if there is a 3rd installment in this franchise its as good as these two films have been.

One of the common problems that people run into when developing CAB applications is how to handle a “global” ToolStrip commands or EventBroker events, and have only the active view respond to that command/event. There have been a myriad of solutions presented on the CAB message boards over time, but none of them have solved the problem very well. Until recently, our shop had not been forced to addressed this problem. Then it hit us in the face as well when we wanted to put an “Undo” button on the ToolStrip and have the active view respond. Faced with this problem we set about solving it. Here’s our solution, and I think it’s pretty slick.

There’s two core elements to this problem:

• Tracking the active view when it changes
• Querying for the Active View against the current view when responding to an event or command

To solve the first part of the problem requires a couple of things:

• A service to track the “active view”
• A way to make each view unique, so that it can be tracked in the first place.

Making Views Unique

This is the key part to the solution. We have our views inherit from a base View class. This view class implements an interface called IView. The IView interface exposes one property: A Guid. This is the heart and soul of solving this problem.

public interface IView
{
    Guid Guid { get;}
}

The implementation of the View is very simple. The constructor just creates a new Guid when the view is created.

private Guid _guid;

public View()
{
    InitializeComponent();

    _guid = Guid.NewGuid();
}

public Guid Guid
{
    get { return _guid; }
}

Tracking The Active View

Each view now has a unique identifier. The next step is to create a service to track the active view:

public interface IUIService
{
    void SetActiveView(object view);

    bool IsActiveView(object view);
}

The service implementation is listed here:

public class UIService : IUIService
{
    private Guid _activeViewGuid = new Guid();

    public void SetActiveView(object view)
    {
        if (view is IView)
        {
            IView eView = (IView)view;
            _activeViewGuid = eView.Guid;
        }
    }

    public bool IsActiveView(object view)
    {
        if (view is IView)
        {
            IView eView = (IView)view;
            if (eView.Guid == _activeViewGuid)
            {
                return true;
            }
            else
            {
                return false;
            }
        }
        else
        {
            return false;
        }
    }
}

Activating The View

With a tracking service and a unique Guid you finally have a way to identify views. The next step is to set the active view when it is displayed in a Workspace.

What you have to do here is wire-up a Workspace’s SmartPartActivated event. Somewhere in your code you’re going to have a view that contains a DockWorkspace, or a TabWorkspace, or some other workspace. In the sample application I use a TabWorkspace because this seems to be a common workspace that prompts this problem for users.

public EmployeeTabWorkspaceView()
{
    InitializeComponent();
    EmployeeTabWorkspace.TabPages.Clear();
    EmployeeTabWorkspace.SmartPartActivated += new
    EventHandler(
    EmployeeTabWorkspace_SmartPartActivated);
}

void EmployeeTabWorkspace_SmartPartActivated(object sender,
WorkspaceEventArgs e)
{
    _presenter.SetActiveView(e.SmartPart);
}

When the Workspace shows a view this event is fired. We delegate the call to the Presenter but you don’t have to do it this way; you could inject the UIService into this view and handle it directly.

The Presenter then sets the active view via the service:

private IUIService _uiService; 

public EmployeeTabWorkspaceViewPresenter(
[ServiceDependency] IUIService uiService)
{
    _uiService = uiService;
}

public void SetActiveView(object smartPart)
{
    _uiService.SetActiveView(smartPart);
}

Every time the TabWorkspace activates a view or has a new view added to it, this event wil fire and the UIService will set it as the active view.

We’re almost done.

Answering The Call

The final step is to answer the question: How do we utilize the Guid and the UIService to handle a command or event?

In the EmployeeViewPresenter of the sample application I have two ToolStripItems: Print and Undo.

Pressing the Print button causes an employee’s name to be printed in a ListView. Pressing the Undo button causes the ListView to Clear() itself. There is only one of each button on the ToolStrip, but there are three copies of the same EmployeeView and Presenter listening for these Commands.

To determine which view should respond to the call they each query the UIService to determine if their view is the active view.

[CommandHandler(CommandNames.Print)]
public void Print(object sender, EventArgs e)
{
    if (_uiService.IsActiveView(View))
        View.PrintEmployeeName(_employeeName);
}

Only the active view’s Guid will match, and thus only the proper presenter’s code will execute. That’s it; that’s all there is to it. Enjoy!

The topic of wolves came up during a discussion at my work yesterday. Wolves can be a touchy subject; there is definitely a polarizing effect. During the course of the conversation, my boss relayed a sound bite from an “activist” person he knows. He said:

There has never been a documented case of wolves killing a human being in North America.

That seemed bogus to me given the nature of wolves, so I decided to Google it. Turns out as of 2006 that’s no longer true.

But that’s not what made me shake my head…

When I got home I had to mow my lawn, and when you’re spending an hour cutting grass you’ve got a lot of time to think. I started thinking about the argument to defend wolves when I came to this thought:

Defending wolves with the argument that they have never killed a human is akin to defending radical Islamic terrorists because they’ve never been able to detonate a nuclear weapon on US soil. Just because it hasn’t happened doesn’t mean the intent isn’t there.

I just cross my fingers that wolves don’t get religion…