Opgenorth.NET

Well, don’t let the name of the post fool you – the next EDMUG event is in November, not October,  November 4th, to be exact.  I’ll repeat the e-mail I got with the details:

Date: November 4th
Time: 5:30pm doors open, 6:00pm event starts
Location: Edmonton Room in the Stanley Milner Library
Event Title: Practical Automated Testing Dojo

As we may have eluded to in recent newsletters, we’re going to try some new style events for this year’s schedule.  In the past the lecture presentations that we’ve held have provided great content in an easily accessible format.  They also seem to have left attendees wanting for more practical and hands on exposure to the technology being discussed.  This event will be the first of those new formats that will allow you to get started with that practical experience while still receiving some guidance.

How the Dojo event will work:

At the start of the meeting (6pm in this case) we will provide a brief introduction talk on Automated Testing.  This will take up no more than 15-30 minutes and is not intended to be an in depth review of the practices involved.

After the introduction a number of volunteers who are well versed in Automated Testing will form breakout teams which attendees will be free to choose from.  Those teams will spend the majority of the remaining event time (1.5hrs plus) working through real world examples of how to write automated tests using different tools and different styles.  While there will be one person who can provide guidance, we are encouraging all attendees to spend time pair programming, watching and engaging in questions with the entire group.  Attendees should also feel free to move from one team to another as the content, styles and experiences may be different.

What, you ask, will the attendee be responsible for?  Well, our hope is that you will feel inclined to bring questions about Automated Testing and a desire to interact and learn with and from the rest of the community.  If you can, please bring your own laptop.  There will be some laptops available but they will be used in pair (or more) programming scenarios only. We will be providing a sample code base that needs many different kinds of tests added to it.  If you want the code at the time of the event, please bring a USB drive.  For those that don’t we will provide the code for download from the Edmug website after the event.

As this is our first event of this style, we are going to treat it as a learning experience and apply those lessons to the coming events.  As always, we encourage you to provide us with any feedback that you can at info@edmug.net

The Edmug Team

www.edmug.www

So, with that out of the way, it’s a pretty loosy-goosy format.  If you are going, is there anything in particular that you would like to see or do?  Some code you would like help with?  Need a laptop?  I will be there, and more than willing to help out with your questions and figured that it can’t hurt to find out in advance some specifics.  Feel free to respond to me either via comments here, or by e-mail (tom at opgenorth dot net).

At the end of my talk on Git at the Edmonton Code Camp, somebody asked if I would put the links to the various git resources up on my website.  Here they are:

• The git website, of course.
• Pro GIT – an awesome book about git.  You can either order the dead tree version, or read it online.
• Linus Torvalds talking about git.  If you’re an SVN fan-boy, or have thin skin, you might want to skip this.  “…you are ugly and stupid…”
• A fellow by the name of Bart Trojanowksi gave an awesome talk to some Ottawa ruby group.  This is long, but worth it.
• Jason Meredith, of Los Techies fame, has a three part series on git for the Windows Developer.  Jason has some other good git stuff on his blog too.

There you go, enjoy, and be distributed.

One question that has been bouncing around in my mind is what, exactly, does one have to do to be considered Agile?  Let’s look at the Agile Manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Sounds pretty simple.  I notice that there are twelve Agile principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behaviour accordingly.

The agile principles are interesting, because in a lot of ways I can see advocates of other methodologies (BDUF) saying the believe in the same thing.

Asking amongst some peers, and there didn’t really seem to be a concise definition of Agile and what you need to do to call yourself.  I’ve seen some places that will suggest that they are Agile because they stand up at meetings (or a manager wanders around once a day), avoid documentation, and have a meeting every three or four weeks that they call a “retrospective”.  So, does anybody care to offer up their thoughts on what one needs to do to be considered Agile?  I have my own thoughts, but figured I’d save them for a later blog post.

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?