Opgenorth.NET

The past week I’ve been dabbling with an open source program called Open Dental – mostly trying to see if can get it to compile under Mono, and running under Linux.  I figure that this would be a good opportunity to and work with a cross platform application.

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.

Recently, on one of the mailing lists I subscribe to, a member starting bashing .NET. A bit curious as to why there was this strong hatred of .NET, I posed a simple question:

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.

Why I love NHibernate:

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".

This Saturday past we had the Edmonton Code Camp.  I’d say things went pretty well.  It’s my understanding that some 80 people showed up to hear a variety of topics.  I kicked off the day in "Track #2" with a Introduction to Test Driven Development.  For those who are interested in my presentation / code, you can download it here.

On a project that I’m currently involved with, I’m using NHibernate and a persistance-ignorant domain. Today NHibernate threw me a "You may not dereference an collection with cascade="all-delete-orphan"" error. This kind of had me confused for a bit. What this error means is this: When you have a parent-child relation in your domain, say something like this:

public class Parent

{

     ISet<Child> _children;

}

You can’t do something like this in the parent class:

_children = new Set<Child>();

NHibernate gets angry with this and throws the aforementioned error.  It does this because the collection object that NHibernate was tracking is now gone.

What you need to do is something like:

_children.Clear();

The collection object that NHibernate is tracking is still around, so NHibernate can figure out how to persist the collection of child objects.

For those who are interested, I put the PowerPoint slides and code from my Intro to Test Driven Development and Unit Test talk at Desert Code Camp 2007 here.

The presentation is in PowerPoint 2007.  If you need me to convert it to another format (PowerPoint 2003, OpenOffice Impress), let me know.

Yesterday I was house-bound looking after a sick eight year old boy.  To help pass time, I decided to play around with my chronograph (to clarify: in this context a chronograph is a tool to help you measure the velocity of projecticles, i.e. bullets).  I happen to own a Shooting Chrony Beta Master, which you can, in theory, hook up via a serial port to your computer, download the velocities of up to 60 shots, and use that data to help you with building up some ballisitic tables for your firearm and hand-loaded ammunition.

The only problem is that the software that Shooting Chrony sells sucks.  It was probably okay ten or twelve years ago, but by today’s standards it’s lacking.

I figured that it would be neat to try and figure out how the Shooting Chrony software communications with the actual chronograph.  Typically serial port communications isn’t to complex, but figuring out what is happening on the wire isn’t necessarily the easiest thing.

To help me, I used Eltima‘s Serial Port Monitor.  This handy little application allows you to see all the traffic on a given serial port, in both directions.  You can even save a log of the traffic for later analysis.  Pretty handy little tool, well suited for just this kind of thing.

So, I started up Shooting Chrony’s application, started up Serial Port Monitor, and proceeded to download the velocities from my last trip to the range.  I then spent some quality time dissecting the log of the traffic generated, and figured out what commands I need to send to download the velocities from the chrony.  A couple more hours inside VS2008, and I had a quick and dirty WinForms app that would download the data from the chrony and display it in a simple text box.

It’s nothing fancy, but it does the trick.  The next step is to parse this data into a more meaningful format, persist it somehow, and then do a self-taught crash course in exterior ballistics for my own home grown .NET ballistics program.

Of course, I’ll try to keep this compatible with Mono. 

I just pulled this handy tip from the Rhino.Mocks mailing list:

If you would like to see more details of the expectations that you are recording and matching, try adding this in your test setup:

RhinoMocks.Logger = New TextWriterExpectationLogger (Console.Out)

You should then see all the logging messages in the Output window of Visual Studio.

(or, DataRowView How I Hate Thee)
Recently I had to enhance an ASP.NET 2.0 GridView on a Web Form.  Basically, the idea is that, if a certain field in the grid was false, I would strike-through all the text in that row.  It seems simple enough: just use the RowDataBound event of the GridView control and  apply the formating.  Wanting to make this as testable as possible, I thought that perhaps some sort of decorator class would do the trick, something like:

myGridView.RowDataBound +=

    delegate(object sender, GridRowEventArgs rowEventArgs)

    {

        InventoryPartVendorGridRowDecorator gridRowDecorator =

            new InventoryPartVendorGridRowDecorator(rowEventArgs.Row);

        gridRowDecorator.Decorate();

    }; 

Then, using the dynamic duo of NUnit and Rhino.Mocks, I would be able to test my decorator class independent of my web application.  I thought I could mock out the GridViewRow and a DataRowView, and be on my merry way.  Life would be good.  And it would have been, until the wretched DataRowView entered into the picture.

DataRowView sits pretty high up on the inheritance tree, doesn’t have any interfaces that are meaning full in this context, and it’s constructors are internal.  So, it proved to be pretty difficult to mock. 
To explain what I did, I will first show you my unit test:

[Test]

public void Decorate_InactiveVendor_TextDecorationLineThrough()

{

    MockRepository mockery = new MockRepository();

    GridViewRow mockGridViewRow = mockery.CreateMock<GridViewRow>(1, 1, DataControlRowType.DataRow, DataControlRowState.Normal);

    Hashtable dataRowViewDataItem = new Hashtable(1);

    dataRowViewDataItem.Add("Active", false);


    using (mockery.Record())

    {

        Expect.Call(mockGridViewRow.RowType)

            .Return(DataControlRowType.DataRow)

            .Repeat.Once();

        Expect.Call(mockGridViewRow.DataItem)

            .Return(dataRowViewDataItem)

            .Repeat.Once();

        mockGridViewRow.Style

            .Add(HtmlTextWriterStyle.TextDecoration, "line-through");

    }

    using (mockery.Playback())

    {

        InventoryPartVendorGridRowDecorator gridRowDecorator =

            new InventoryPartVendorGridRowDecorator(mockGridViewRow);

        gridRowDecorator.Decorate();

    }

} 

Notice what I did; I created a Hashtable and have my mockGridViewRow.DataItem return that.  In otherwords, I’m not mocking DataRowView at all, I just cut it out of the picture.  Then inside inside my InventoryPartVendorGridRowDecorator class I had to put this method:

private bool IsVendorActive()

{

    object val;

    object dataItem = _row.DataItem;

    // HACK [TO070508@1149] Because we can't mock DataRowView, we do this. 

    if (dataItem is DataRowView)

    {

        val = ((DataRowView) dataItem)[ActiveColumnName];

    }

    else if (dataItem is IDictionary)

    {

        val = ((IDictionary) dataItem)[ActiveColumnName];

    }

    else

    {

        val = null;

    }

    if (val == null)

    {

        throw new NullReferenceException("Could not find the field 'Active'.");

    }

    return TypeHelper.ConvertToBoolean(val, true);

} 

As you can see, what I ended up doing was sticking in a little "adapter" into my decorator.  Not pretty, but it works.

What would others do in this situation?

Ever have a need to convert some VB.NET code to C# (or vis versa)?  Telerik has a online code converter that seems to do the trick.