Well, okay, perhaps I didn’t forget.  Given that it was April 1st when I got the e-mail, I like to give things a few days to settle down.  I am acquainted with some mischievous pranksters who would think it was a funny April Fools joke.

Thanks James and his crew for agreeing to shift from the 2nd Tuesday to the 3rd Tuesday to accommodate my travel.

Here is a zip of the code and slide deck.

Two things that suprised me:

1. That there was still that much interest in ASP.NET MVC intro talks.  I just figured that everybody knew/knows about it.  Or maybe I just spend to much time with guys who have drunk the ASP.NET MVC Flavor Aid.  Either way, I think that there were some in the crowd that will convert from WebForms to ASP.NET MVC.
2. I asked how many people wrote unit tests or developing their software using Test Driven Development was the number of people who didn’t raise their hands.  While I didn’t expect the majority of the crowd, I did expect a lot more people than I saw.  Maybe it was a quiet crowd, and people didn’t feel like saying they wrote unit tests.  Maybe I live in a bubble, and my perception of what is actually going on in the .NET world is skewed (that is to say, perhaps writing tests is the exception rather than the rule).  It did kind of make me a bit concerned, as I truly believe that TDD does help one write better software overall.

Anyway, here’s to hoping that TechDays 2010 will stop off in Edmonton.  And hopefully have a track that will focus on developer fundamentals, like TechDays had in Toronto and Vancouver.

• StructureMap
• Castle Windsor
• Ninject
• Autofac
• Unity
• Spring.NET
• And probably others that I’m missing.

Ironically, when you first start using an IoC framework, you might find that in trying to make a loosely-coupled, modular, application you end up shackling yourself to the framework you’re using for IoC.

For example, you start off using your own homegrown IoC framework, and then decide at some point in the future to use a different framework, like say StructureMap.  Going through your codebase to make these changes can be quite the exercise in pain.

There are a couple of ways to isolate yourself from this kind of situation.  I won’t get into all of them but instead will focus on the Common Service Locator. What is Common Service Locator?  Well, allow me to cut and paste some text from the web site:

"The Common Service Locator library contains a shared interface for service location which application and framework developers can reference. The library provides an abstraction over IoC containers and service locators. Using the library allows an application to indirectly access the capabilities without relying on hard references. The hope is that using this library, third-party applications and frameworks can begin to leverage IoC/Service Location without tying themselves down to a specific implementation.”

Blah blah blah – so what does all that mean?  Well, in my own words, CSL is basically a wrapper around your IoC container which separates how you  initialize/configure your IoC container from how you use it.  This separation allows you to use your IoC container without knowing anything about it.

This separation is achieved by use of adapters for the particular IoC container that you want to use.  These adapters are what do the dirty work of finding the service you need, in their own special way and totally transparent from your application code.  Currently, the Common Service Locator has adapters for StructureMap, Castle Windows, Unity, Spring.NET, and autofac.

Now, allow me an example of using the Common Service Locator with StructureMap. There is no special reason as to why StructureMap – it just happens to be what I find myself using these days.

Now, say I use the the following registry to configure StructureMap:

   1: public class DefaultStructureMapRegistry: Registry

   2: {

   3:     public DefaultStructureMapRegistry()

   4:     {

   5:         ForRequestedType<IDb4oConfiguration>()

   6:             .TheDefaultIsConcreteType<SimpleDb4oConfiguration>();

   7:     }

   8: }

In a nutshell this says that every time StructureMap is asked to provided an object of type IDb4oConfiguration, it should instantiate a SimpleDb4oConfiguration object and return that.  So, to get an instance of IDb4oConfiguration with StructureMap, I would do something like this:

   1: var db4oConfig = ObjectFactory.GetInstance<IDb4oConfiguration>();

Pretty simple, but it does kind of tightly couples me to StructureMap.  If I need/feel like/am forced at gunpoint to change my IoC container to something that is Not StructureMap, you can bet that there will be much wailing and gnashing of teeth on my part as I hunt through my code to make these changes.

Now enter the Common Service Locator.  First, let’s take a peek at some interfaces for CSL.  First an interface:

   1: namespace Microsoft.Practices.ServiceLocation

   2: {

   3:     public interface IServiceLocator : IServiceProvider

   4:     {

   5:         object GetInstance(Type serviceType);

   6:         object GetInstance(Type serviceType, string key);

   7:         IEnumerable<object> GetAllInstances(Type serviceType);

   8:         TService GetInstance<TService>();

   9:         TService GetInstance<TService>(string key);

  10:         IEnumerable<TService> GetAllInstances<TService>();

  11:     }

  12: }

The IServiceLocator is an interface that your application will use when it requests something from your IoC container.

Another thing that CSL provides is a static class that your application would use to use a current IServiceLocator to request services.  That static class looks something like:

   1: namespace Microsoft.Practices.ServiceLocation

   2: {

   3:     public static class ServiceLocator

   4:     {

   5:         public static IServiceLocator Current { get; }

   6:         public static void SetLocatorProvider(ServiceLocatorProvider newProvider) {};

   7:     }

   8: }

So, now lets see how we would request the default implementation of the IDb4oConfiguration service using CSL.  First, we would initialize CSL:

   1: var registry = new DefaultStructureMapRegistry();

   2: var container = new global::StructureMap.Container(registry);

   3: var smServiceLocator = new StructureMapServiceLocator(container);

   4: ServiceLocator.SetLocatorProvider(() => smServiceLocator );

What is going on here? Allow me to provide a quick line by line explanation:

Line 1 we instantiate a new StructureMap registry.  We then feed that registry to a StructureMap container in line 2.  With line 3, we see that StructureMap container is then fed to the StructureMapServiceLocator, which is the SM adapter for the Common Service Locator.  Finally, with line 4 we provide a lambda that CSL will use to fulfill future requests for services.

Now when our application wants to get an instance of IDb4oConfiguration it just politely asks CSL:

   1: var db4oConfig = ServiceLocator.Current.GetService<IDb4oConfiguration>();

Pretty simple and clean, eh?  Now, when radical group the Foundation for Unity as the Dominate IoC Container sneaks into your cube and forces you at the point of a nerf gun to switch to Unity, you can do so with minimal disruption to your application. With a properly layered application, it would be as simple as coding a new UnityConfiguration layer and then using that instead of your StructureMapConfiguration layer on application startup.

Now, granted this is pretty trivialized example.  There are other ways to solve this problem, but CSL does seem to take are of the grunt work for you so that you can just get going with things.

If you using a unit testing framework such as NUnit, you’re no doubt familiar with the [Ignore] attribute.  (Note:  I haven’t used MbUnit in a while, but I’m pretty sure that all this applies there as well.) For those who aren’t, when you adorn your [Test] with this attribute, then your test runner should pay no heed to this particular [Test].  Instead of going green or red, your test turns up as yellow in your test runner. At first blush, this seems handy – rather than deleting a failing or broken test you can have it [Ignore]d, much like your typical computer geek at a high school dance before the punch get’s spiked. Now you can deal with the wayward test on your own time with the pesky failure cluttering up your CI build (you do have a CI build box set up, right?).

Please bear with me while I submit to you: This isn’t a good idea. This is a bad idea. An ugly idea. The kind of bad, ugly idea than even Belcham-esque quantities of scotch couldn’t make pretty. Why? Well, the whole point to having a unit test is to test something. If your test is failing, that means something is broken.  You should be addressing the cause of the failure and dealing with the problem now. Covering up the failure with some attribute kind of defeats the purpose of having the unit test in the first place. I mean, really, if you had open, festering lesions on your skin would you just cover them up with a band-aid and pretend nothing was wrong?  Odds are you’d go to a doctor and get that checked out.

Alternately, perhaps the test isn’t valid anymore: your application has changed/evolved and the code that you were testing isn’t around anymore. Then, get rid of the test! Delete it from your test fixtures, and don’t look back.

Granted the world we live in is not black and while.  Sometimes we’re working on things, and we only want tests to run when it is explicitly asked to run.  To handle this scenario, NUnit provides the [Explicit] attribute.  This is a kinder, more gentle kind of ignore.  This instructs NUnit to only run the test when it is told to run the test.  If you add a comment to the attribute, then it helps those going through the build log understand why the test is being run.  However it is still possible to run the test if desired.

[Explicit("This test takes a really really really long time to run so we don't want to run it in this test suite every time")]

[Test]

public void My_very_important_test()

{

    // Test valuable things here

}

I know some people are going to protest my advice. So I will offer up this one last piece.  If you are going to [Ignore] a [Test] then please take advantage of the fact that you can add a comment to the Ignore which will show up when NUnit ignores the test:

[Ignore("This test is ignored as I wish to incur the wrath of Cthulhu (or his proxy)")]

[Test]

public void My_very_important_test()

{

    // Test valuable things here.

}

Now when your CI server runs your unit tests, you will have a nice friendly message that will inform others as to why the test is not running.

Castle Monorail has been around for much longer, three years or so?  It’s still listed as a release candidate on it’s website, but I’d say Monorail is suitable for production.  Currently, I am not aware of any projects in the Edmonton that are based off this framework.

I guess this is anecdotal evidence that you won’t get fired for sticking with Microsoft.

The two frameworks have quite a few similarities.  IIRC, in Austin last fall Scott Guthrie did mention that the ASP.NET MVC framework was influenced to some degree by Monorail.

Regardless, it’s good news.  Personally, I like both frameworks, and would prefer either of them to Web Forms.  YMMV.

For example, Kyle Baley did post on how to how to use the format code to get rid of regions. His techique is a bit unrefined – his revolutionary, dogmatic zeal he will clobber all regions and do nothing else – but still handy.   Myself, I’m a bit more compulsive / fussy when it comes to the layout of my code. Not only do I want regions gone, but I want the code to appear in a certain order. Lucky for me that Reformat Code does this for me. Here is the Type Member Layout pattern I use. If you want to use it, just paste it into the type member layout window in Resharper.

What this will do, when you ask Resharper to Reformat Your Code, is the following: Remove all regions Sort your code, with the following order:

• any COM Interop interfaces
• public delegates
• public enums
• constants (sorted alphabetically)
• fields (sorted with readonly first, and alphabetically)
• static constructors
• constructors
• properties (sorted alphabetically)
• methods (sorted alphabetically)
• anything else (sorted alphabetically)

For the sake of brevity, I’m not giving a detailed breakdown of the Type Member Layout Pattern syntax. Well, brevity and the fact that I’m not 100% certain on a lot of it and don’t want to unintentionally say something wrong. I do believe that the format is pretty straight forward, so you look at it and make your own adjustments.

However, to give you an example. Imagine for a moment that you wanted to surround any interface methods in a #region. First off, don’t tell Kyle. Might be a good idea not to mention it to David Laribee while you’re at it. Secondly, add the following snippet:

<Entry>

  <Match>

    <And Weight="100">

      <Kind Is="member"/>

        <ImplementsInterface/>

    </And>

  </Match>

  <Sort>

    <ImplementsInterface Immediate="true"/>

      <Kind Order="property method"/>

      <Readonly/>

      <Name/>

  </Sort>

  <Group>

    <ImplementsInterface Immediate="true" Region="${ImplementsInterface} Members"/>

  </Group>

</Entry>

What this will do is, for each member of your class that is part of an interface implementation (the whole part), sort it by it’s name (the part), and surround them with a #region (). If you look at my Resharper Patterns with Interfaces sample, you can see by the position with in the element that the interface #region will appear at almost the end of your *.CS file. I hope now that this will appease your inner obsessive compulsive self.

According to their website, Open Dental has been supported under Linux since v4.7.  Here are some notes of my efforts so far.

You will need Mono v1.2.5.  It seems that there is a problem with the Linux binary installer ( a known bug that will be corrected in 1.2.6).  I used the OpenSUSE 10.2 VMWare image which had a 1.2.5 install all set up.  That solved my problem of getting a current Linux distro with the most recent version of Mono.

There is a website for getting Open Dental to run under Ubuntu, and instructions on how to compile on Linux.  I couldn’t get the application to compile under Linux using those instructions.  I suspect that they are a bit out of date.  What I ended up doing was compiling the application in VS2005, setting the build to LinuxRelease.  I then copied the binaries over to my OpenSUSE VM, and ran Open Dental.

Now, Open Dental uses MySQL 5 for a database backend.  The problem that I ran into next is that the database script that is provided to setup the database is for a very old version of Open Dental (like v3.x).  Open Dental is supposed to be smart enough to update the database to the correct version.  However the DB upgrading process seemed to keep crashing.

What I ended up doing was installing the trial version of Open Dental.  This created a database for me.  Once I had a database, the application seemed to run.

A curious thing is that when I would try to run Open Dental on Windows, using Mono 1.2.5.2, the application crashes.  No such problems running under Linux though.

What is wrong with .NET?

The answer I got back somewhat suprised me:

I guess the standard reply is, what is right about .NET?  .NET was invented so that M$ could provide software as a service. You would end up with a minimal OS on the disk, and no applications. When you turned your computer on, it would download whatever applications you needed, or did so on demand; if your subscription was paid up.

That was the PR on .NET when it first came out, to my best recollection.

Your PC was useless, unless your subscription was up to date. Again, as far as I remember, this was the original intention of .NET. It doesn’t look like things progressed quite the way they were supposed to.

I felt, that given the opinion was largely based on an erroneous perception, that I should respond:

Yes, the original PR campaign around .NET was a bit of a disaster, if you ask me. It did more to confuse people than anything. You’d mention .NET, and some people would think you were talking about the programming/software development environment, some people thought you were talking about the next version of Windows, and yet others still thought that you were the service concept that was mentioned. And lets just quietly agree to push Passport into a dark pit along with Microsoft "Bob".

These days, when people speak of .NET, they are speaking of the software development platform – i.e. the tools to write software. The concept of .NET as a Microsoft service faded away a while ago.

Now, I will admit that I might have a bit of a bias. My OO programming started with Clipper (using ClassY), then C++, then Java. And when .NET came out in beta, I switched to that.  I’ve also dabbled a bit using OO in Perl.

In the 5+ years I have been using .NET, the only "subscription" I have paid is for my MSDN subscription, and that I have only paid for since I started consulting. I have written .NET applications without having an MSDN subscription. I know of people that write .NET applications using nothing fancier than emacs. In fact, I know of people that write .NET applications without Windows or using anything from Microsoft. I have never had, nor heard of, anyone having their custom applications "expire" because their "subscription" was unpaid. .NET doesn’t force any downloads on you – that is Windows Update.

Using .NET is no different that using Java, IMO. The basic concepts behind each are almost the same. There are pros and cons to each, but in the end it comes down to your preferences (or that of your client). I’ve worked at places that use both. The .NET camp does borrow a lot from Java, many Open Source Java tools have been ported to .NET. Many of the software engineering principles that the Java camp adopted years ago are finally start penetrate into the .NET world.

So, if you ask me what is right about .NET, I’d say that for many software applications, it’s a good choice. I can write web application, Windows applications, Windows services, daemons, and web services. I have have a good set of libraries that allow me to concentration on what I need to get my job done, and not spend so much time on "plumbing" – unless I want to.

I can use the same language for each every application, or I can use one of the many languages that are supported by .NET (C#, VB.NET, Java, C++, Python, Ruby, Perl, PHP, FORTRAN, COBOL, and a large, large, list of others). I can share my .NET components with each other, regardless of the language I use. I can (and have) also share my newer .NET components with my older Delphi/VB/C++ applications. Thanks to Mono, you can now run your .NET applications on platforms other than Wintel. 

So, for developing software applications, pick your poison. .NET is definitely a viable choice.

I am rather please by the fact that a database schema change involving the creation of six new tables, three one-to-many relationships, and a many-to-many relationship (which includes a sort order on the join table) can be taken care of inside of seven easy hours.  It probably would/could have been less, but I crafted the HBM and class files by hand and had a few typos which hide themselves well.  This also included the time it took to create some quick integration tests to ensure that CRUD is working.

Now, of course, there are other changes to the domain that need to be done to deal with these new tables, but NHibernate frees me from paying a significant "database tax".