Opgenorth.NET

Every developer, no matter how experienced, has to dig in and fix bugs.  This is, in my experience, the typical cycle:

1. bug is reported
2. bug is assigned to developer
3. developer thinks the bug is fixed
4. developer marks bug as resolved
5. tester checks to see bug is fixed, but it isn’t.
6. tester reopens bug, assigns it back to developer
7. back to step number two.  Repeat until developer (or tester) climbs to the top of a 307 foot administrative building with high-powered rifles to demonstrate USMC-worthy marksmanship.

Now, even if you aren’t into the whole Lean Software development philosophy (i.e. eliminating waste), you can probably appreciate that it can be pretty wasteful of time and patience every time that #6 happens, so please indulge me as I elaborate on some of the finer points of bug reporting.  Now, where I say “bug reporter”, I typically mean somebody who is in a QA role – their job is to find bugs and report them.  This doesn’t always have to be the case though.

If you check out most open source projects, you will often find rules/guidelines for reporting bugs.  In the case that doesn’t exist then perhaps the following might be of use: When you log a bug, be explicit, and give lots of details.  Don’t be lazy.  If it’s hard to duplicate your bug, then odds are it either won’t get looked at, or won’t be fixed properly.  And when it doesn’t get fixed properly, there will be a lot of churn.

At the very least, when reporting a bug you should provide:

• A detailed description of the problem.  Note the emphasis on problem.  Odds are you don’t have the solution, so don’t bother.  Let the programmer figure out the solution.  For example:  Using version 3.1415 of the application on 28-July-2009, I was expected a date to be calculated a certain way based on some values.  The application didn’t crash, but the correct date was not calculated.
• What you expect to happen.  If you have some sort of formal spec, repeat it here, and cite how to find the spec.  i.e.  According to Page 1054, in section 1095.4.3.2 the new date is to be calculated as follows :  add the value of  ((a – b)- 10) /2 (rounding down) to the date Y for a new date of Z.
• What actually happened.  i.e.  Using these values a=300, b= 150 and Y of 1-Sep-2009 I expected that the new date Z should be 2-Oct-2009
• A step-by-step description of HOW to duplicate the bug.  This means explaining in excruciating detail HOW the programmer can duplicate what your reporting, i.e.
  • Go to the URL http://myproblem.com/is/here
  • Click on the text box next to the label “Value A:” and enter a value of 300
  • From the drop down list by “Value B:” and click the value 150 from the drop down list
  • Use the tab key to navigate to the “Calculate new date” button.
  • Hit Enter
  • The text box by the “New Date:” label now has the date of 4-July-1943.  I expected 2-Oct-2009.
• How the developer can get a hold of you.  This comes in handy when for some reason the developer can’t duplicate your bug or doesn’t understand what you were doing.

When the developer flags the bug as resolved and it turns out not to be fixed, don’t just re-open the bug with curt “This is still broken”.

Ah, but now aren’t I the smug developer – shifting my inability to quickly resolve a bug to the poor reporting capabilities of my tester.  I’m pretty ungrateful too.  I mean, somebody took the time to test out my application, and then enter a bug like “I tried to calculate the new date and it didn’t work.  Please fix”.  Well, fear not – there is a lot developers should be doing as well, but that is the subject of a later post.

Of course, the key part in all of this is COMMUNICATION.  Don’t be afraid, as someone reporting a bug, to actually talk to the developer.  Nothing really beats face-to-face communication (or a phone call) if things seem unclear. Odds are you won’t have an empty whisky bottle thrown at you.  Most likely the personal grooming standards of the developer will be higher than that of a middle age serf during the Black Plague.  In theory, as a tester, you’re on the same side as the developer trying to fix the bug.

Well, it’s coming up on fall, which is traditionally the time of year for the Edmonton Code Camp.  It seems that there is still a spot or two left for speakers, so if you’re in Edmonton why not think of something programmy and give a talk.  Doesn’t have to be .NET – anything that is related to software development will do.

Anyway, I’ve put my name down for a talk at ECC.  There are several options available for me and I’m not sure which one to go with.  So, I figured that perhaps a straw poll would help me decide.  Feel free to add a comment about which topic you’d prefer:

1. Intro to ASP.NET MVC.  This wouldn’t be my own presentation.  This will be one of the sessions at TechDays in Calgary (this November). 
2. Introduction to git.  Git is an open source, distributed version control system.  I’ve been dabbling with it off and on for the past little while, and am growing rather fond of it.
3. Introduction to programming on Android.  Again, another thing I’ve been dabbling in for the past couple of months.  Given that the talks are only about an hour or so, this might be a bit rushed, but could still be of interest.

Personally, I’m leaning more towards #2 or maybe #3.  What do you think?

One of the nice things about Dependency Injection is that it can really help write a more flexible, modular application.  These days, it seems that there is no shortage of choice in the .NET community when it comes to IoC frameworks:

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

Update November 20th:  Well, a quick search of StackOverflow.com, and it turns out that I’m not exactly alone in this matter.  According to this post (and Grant in the comments of this post), in versions of IE < 8, one must use the click event, and not the change event.

I ran into an interesting issue today.  I don’t really know the answer, but I figured I would blog about it so that I don’t completely forget it.  While I highly doubt the two readers of my blog (my brother and sister) have any idea of what I’m talking about, I’m sure that eventually somebody (smart) will stumble upon this via Google.  What will happen in that case is anybodies guess, but I digress…

I had some JavaScript (note that I’m using jQuery too):

   1:  $(document).ready(function() {

   2:      $('#myCheckbox').change(myCallBackFunction);

   3:  }

   4:  

   5:  function myCallBackFunction() {

   6:     // unwrap protein strings and cure cancer in parallel on a single core system

   7:  }

For the sake of completeness, here is a sample HTML snippet to go with the above jQuery:

<input id="myCheckBox" type="checkbox"  >

Now, in FireFox 3, when you clicked on the checkbox, myCallBackFunction gets executed (as I would expect).  However, in IE7, that doesn’t seem to happen.  This has me stumped.

Now, at work, I asked "Who is an expert in Javascript and jQuery?".  Crickets chirped.  Dead silence.  A tumbleweed rolls on by.

I then asked "Who wants to make Tom look stupid?" – everybody jumps at the opportunity.  Go figure.  Anyway, back to our exciting tale.  To get around this, I couldn’t rely on the collective brainpower of myself and my co-workers to figure out what the problem is.  Instead, we deduced that it is better to go around the problem and try something different.  I had  to use the click event like so:

$('#myCheckbox').click(myCallBackFunction);

This works in both IE7 and FireFox 3 – not sure why.

Based on my past experiences with things, I’m sure it’s something I’m doing (or not doing).  Going over my past experience, I’m sure it won’t be me who figures out what I’m doing wrong.

Lately I’ve been experimenting with TypeMock Isolator,  and it’s new AAA syntax.  For the past two years I’ve been a diehard Rhino.Mocks kind of guy, but figured that it’s time to check out other tools.  Anyway, I had a situation where a unit test of mine was failing when I ran it with TestDriven.NET, but would pass when I ran it using the unit test runner in Resharper 4.1.

Usually when I develop, I write individual tests and then run individually with TestDriven.NET and collectively with Resharper.  In this case, as I was writing one unit test, it kept failing with TestDriven.NET.  At first I thought it was just me being stupid (always a good place to start), and then I was worried that perhaps the documentation for TypeMock was to blame.  So, I sent a email to Avi at TypeMock, mostly expecting confirmation of my stupidity.

Turns out the problem in this case was pretty obscure one (to me).  At home, I do my development in a VM running Windows 2008 64 bit.  When Resharper runs your unit tests, it does in a 32 bit process.  TD.NET, on a 64bit OS,  runs as a 64 bit process.  If you get TD.NET to run as a 32 bit process, then your tests will run fine under TD.NET.

To do so, from the Visual Studio 2008 Command Prompt, change to the directory that you have TD.NET installed in.  Then use corflags:

corflags /32bit+ ProcessInvocation.exe

Note that it’s probably best to do this when logged in as the Administrator.

I will say that I was happy with the support I got from the guys (Avi, Gil and Ohad) at TypeMock.  Given the fact that we’re about a half a world apart (western Canada vs. Isreal), they provided prompt, excellent support.  My thanks to them.

I know it’s hard to beat my shocking announcement from a couple of days ago, but I feel that this one is even more important:  Mono 2.0 has been released.  Read the full details, go forth, and code.

Note:  I originally wrote this post on August 23, 2008.  As things change with the book NHibernate in Action, I will be updating this post and resetting the date. 

I’d like to take a break from boring you two readers of my blog about my experience with Linux and VMware, and take a moment to annoy you with a rant.  Diversity is the spice of life after all.

This little remonstration of mine is about the Manning Early Access Program (MEAP).  Well, specifically just  one book.  I’ve got my eye on a couple of other books available with MEAP to see how they pan out before considering the whole "early access" useless.  Anyway…

It’s been over a year ago that I "bought" a copy of the book NHibernate in Action.  I did so because I want a bit dissatisfied with the documentation for NHibernate 1.2, and thought that the book would help me.  I wasn’t an NHibernate virgin/noobie, but I did need some help with a couple of things, and I really didn’t have a large network of NHibernate masters to turn to for help.

I was disappointed when I saw that the book wasn’t in print yet.  Then I was happy to see that I could order the book, download a PDF, and the hardcopy would be sent to me when the book went to print.  Given that, in the summer of 2007 it was expected NHibernate in Action would be in print in late 2007, I thought it was reasonable to pay the money up front, and get the finished product mailed to me a couple of months later (I like to have hard copies of my books).

Well, here we are now, a year later.  As of September 9th, 2008 writing, summer of 2008, the softbound print date for NHibernate In Action is schedule for December, 2008.  Since I downloaded my PDF of the book in August of 2007, there has been a total of one updated PDF.

Now, I can understand when deadlines get missed, and stuff is late.  But, I think that, with a technology book, being over one year late is inexcusable.  A lot happens in one year in the programming space:  NHibernate 2.0 is now in Alpha.  What will be released first, NHibernate 2.0 or the printed copy of a book on NHibernate 1.2?  NHibernate 2.0 is now available.

I think the money spent on the PDF was worth it, but I honestly feel I got hosed on the cash I paid out for the hardcopy.

I just can’t help but feel that the extra money I paid to get a hardcopy of NHibernate in Action would probably have been better spent using the bills to make little origami swans, ducks, and platypuses and then floating them out to sea.

I will be watching a couple of other books of interest to me on MEAP.  But, in all honesty, I don’t think I will be buying any more books in this fashion until Manning Publications does something to restore my faith in their Early Access Program.  I still my get the PDF’s if I have an immediate need for them, but I can’t see purchasing a book in this manner anymore.

Updated August 25, 2008:  NHibernate 2.0 has been released

Updated September 9, 2008:  I see that the softbound print date has changed from November, 2008 to December, 2008.

Updated September 19, 2008:

Well, I just got the following e-mail from Manning publications:

Dear NHibernate in Action MEAP customer,

NHibernate in Action is almost ready! The last updates have been submitted,
the technical review is complete, and all chapters are in final production.
Some of you have been working with the MEAP for over a year, but we expect
the final ebook to be released in just over a month, with the print book to
follow shortly thereafter.

We appreciate your participation in the MEAP and especially all the valuable
feedback you provided in the Author Online forum. Your excellent comments
helped shape the final book.

To thank you for your patience, we’d like to offer you a $15 Manning Gift
Certificate to use for any print, ebook, or MEAP at Manning.com. Just enter
"_____" in the Promotional Code box when you check out. The Gift
Certificate will expire October 1, 2008.

Happy reading,

Manning Publications

(Note:  I removed the promotional code from the e-mail and added emphasis on the expiry date)

I guess this is some sort of attempt at placating us for unacceptable amount of time this book has taken.  Is it just me, or does anybody else see the irony in them thanking us for our patience with this book by telling us to hurry up and use the $15 Manning Gift Certificate?

One of the biggest discussions that I typically get when I try to introduce things like NHibernate (i.e. OSS) on a new contract goes like this:

"We’re a bit reluctant to use that because it will introduce more code into our code base that isn’t ours. Because it’s OSS, there’s no support, and if there was a bug in it, we’d have to maintain it ourselves. That being case, we’d rather just write our own code, because that way we know what is going on with it and can maintain it better. We don’t want to have to figure out somebody elses code."

There are variants of this argument, but the basic tenent is the same: we don’t want code from others (note that NHibernate here is just an example, this criteria seems to be invoked frequently when suggesting OSS products). For some reason "internal code" (code written by employees or contractors working for a company), is deemed more maintainable and supportable than "external code" (code from 3rd parties, such as OSS projects).

As a consultant, I find huge flaw in this argument for one very simple reason: my mere presence on a client site is a sign that they have some tolerance to code that "isn’t theirs". My typical engagements involve me coming in, writing code, and then moving on. I guess I’m kind of like an IT gyspy that way, but with out the gaudy fashion sense and the ability to place curses on those who cross me.

Anyway, the odds are VERY good that I will have to go through some sort of hand-off procedure at the end of my contract. In a perfect world, this would be an in depth session with an employee of the company, closing of any knowledge gaps of the code I was working on.

Typically, this involves explaining the architecture of my code, how to configure it, how to deploy it, etc. Even when I work on teams, there is still some sort of knowledge transfer about my specific parts of the code, with the more general architecture/configuration/deployment knowledge being disseminated over the course of the contract.

Realistically, this isn’t a very in depth or detailed process: usually it just involves some high level descriptions, nothing in detail. In fact, often this is usually just a formal acknowledgement that somebody has saddled with the responsibility of looking after my code now that I’m gone, and they know where to find the files. Formal documentation consists primarily of a README, or maybe a few pages in a Word document.

Realistically, the knowledge that has been passed on is seldom enough to quickly allow someone to solve even the most simple bug. So guess what: the code was created internally, but you now have to deal with all the issues that you used to exclude OSS projects:

•   There is no support – you will have to fix all bugs yourself.
•   At a very low level, you don’t know what is going on so you have to figure out the code yourself.

Maybe I’m biased, but in a lot of cases, I find OSS products easier to work with. Typically there are a lot of forums, mailing lists, and other users that I can ask questions of when I get stuck. Not so much with internal code. In many cases, even the people who wrote the code aren’t helpful, often for reasons as simple as the code was written a year ago and they haven’t used it since. In fact this very reason (failing memories) can make internal code more like external code over time.

Before we finish up, let’s just beat down the "…no support…" argument right now. With mininal effort, I can find commerical third-party support agreements for the bulk of the OSS products I currently use. And from what some would perceive to be reputable vendors – these aren’t fly by night organizations. As well, regardless of support or not you will need to maintain a bug regardless of external or internal code. You will have to assign someone to figure out what is being done with issue, and possible devise a work around – this is a constant no matter if the code is internal or external.

You don’t want external code? Odds are that you’ve already go some. Why start splitting hairs because is OSS?

So last night I installed Visual Studio 2008 RTM on my laptop.  This was a clean install – I did not have any beta versions of VS2008 installed.  When I went to try and do anything in VS2008, I kept getting the message ‘Visual Studio has encountered an unexpected error.".  This error happens when I try to do anything, including VS2008.  The only way to close VS2008 was using Task Manager.  Most annoying.

A quick search, and I see that JP Boodhoo has the same problem.  The comments on JP’s blog seems to point to VisualSVN as being the culprit.  I uninstalled VisualSVN, and everything seems to be working again.  So, the problem was the add-in.  I then installed a new version of VisualSVN (v1.3.1), and VS2008 seems to be working again.

As an side, I see that the is now a VisualSVN Server utility (free) from the guys that make VisualSVN.  It looks like we now have a GUI tool for managing our SVN repositories.

Lately I’ve come to the conclusion that stored procedures are more of a specialist’s tool than a generalist.  To me, stored procedures are the kind of thing you use when you need to optimize your data access, or you have to do something DB specific.  Sure, I’ve seen lots (and written lots) of stored procedures to do the basic CRUD (mostly in SQL Server, but also in PostgreSQL). These days though, I almost think that one doesn’t need stored procedures for the basic CRUD, only for specific and special cases.

Right Tool for the Right Job
My logic for this is pretty simple: OR/M tools are pretty good these days.  I’m going to single out NHibernate in this case, as that is what I’ve got the most familiarization with.  They way I see it, NHibernate will do as good a job with the basic CRUD stuff as I will rolling my own stored procedures.  Factor in a code generation tool like MyGeneration, and you’re getting a DAL out the door pretty fast.

Separation of Concerns
With the CRUD neatly rolled up into an NHibernate DAL, one can then keep business logic where it belongs:  in code (specifically a business tier) and not in the database.  One of the pitfalls with stored procedures is that sometimes business logic leaks into them.  If you ask me, business logic doesn’t belong in your database.

Maintainability
Need to debug a stored procedure?  That usually isn’t as fun or as easy as debugging code.  This is doubly so if you’ve got a good battery of unit tests to back your code.  Many times I’ve run into a situation when a change to a stored procedure requires re-compiling the application and updating the database.  I find that it’s nice when you can remove one of those steps.

Specialization
As a consultant, over the past few year, I’ve had to work with a variety of RDBMS’s:  SQL Server, Oracle, MySQL, PostgreSQL, and Microsoft Access (Jet) to name a few.  Each of those, if they do happen to have facilities for stored procedures, has their own way of doing so.  A tool like NHibernate relieves me from learning the intricacies of all these databases.  I can send my time concentrating on things like architecture, business rules, and user interface knowing that NHibernate has my back for my DAL. 

I’d be curious to hear what others think.