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?

(Note:  this article is pretty dated, and used IntelliJ 8.  I plan a follow-up covering IntelliJ 9)

So I have this semi-fancy Google Android Dev Phone 1.  Lately I’ve been devoting part of my spare time to learning about programming for Android (the OS of the phone).  Google (probably because they didn’t ask for my opinion and/or input) decided to use Java as the lingua franca for Android programming.  If you ask me – and I know you will – they should have used C# and Mono (I might be a bit biased here).  Luckily, years ago I had done Java programming, so I wasn’t that intimidated by the use of Java on Android.

The first big question that every developer faces is which IDE?  There are a few Java IDE’s out there, but if you ask me the only ones worth considering are Eclipse and IntelliJ.  The documentation for Android points you to using Eclipse.  Eclipse is a good IDE.  However, back in the day when I was getting paid for Java development, my employer got us all copies of IntelliJ, from JetBrains.  I liked it.  I like it enough that if I landed a contract tomorrow that involved Java, I’d buy me a copy of IntelliJ.

So, all that being said, I figured I’d give IntelliJ a spin as I travelled down the stack-trace of Android programming.  Here are my observations, in general:

1. There is an Android plug-in for IntelliJ.  Now, you might believe that development on the Android plug is dead.  Not true.  The plug-in is undergoing active development – it just seems to be kind of slow
2. I found the installation of the Android plug-in for IntelliJ far easier than for Eclipse.  Just download the most current release, and then unzip to your plugins folder in your IntelliJ installation.  With Eclipse, it is simple, but not when the documentation is wrong.
3. The IntelliJ plug-in is simple, and seems to get the job done.  It’s a bit to simple at this time, if you ask me.  The ADT for Eclipse provides a far richer dev-centric experience for Android coding.  For example there are designers to help you with laying out your form, a lot more control over starting up the Android emulator, and better tooling for hooking up the debugger to either the emulator or an app running on the physical phone.
4. Being a Resharper junkie, I found that IntelliJ was more natural for me to use.
5. I didn’t run into to many problems when I was trying to use/convert Eclipse project with IntelliJ. This is good, because the vast majority (all?) projects I’ve seen are all Eclipse based.

So, my conclusion at the end of the day, is that I’m going to stick with Eclipse for my Android development.  There just seems to be less friction at the moment if you’re using Eclipse.  In a couple of months maybe I revisit IntelliJ and see what’s new with it and Android development.  However, at this time, I’d like to really concentrate on learning the Android SDK, and it seems simplest to me right now with Eclipse.

Over the Easter long weekend, I experience my own resurrection of sorts.  On Thursday just before Easter I noticed that my NAS, a Thecus N3200 Pro with three Seagate Barracuda 7200.11 drives in a RAID5 array, was beeping and displaying a “RAID degraded” message.  I didn’t worry about it to much, as it was late on Thursday, and I figured I was safe/okay with three drives in a RAID5 array.

So, the next morning I check things out.  Turns out all was not well in Whoville.  While check the RAID config, I saw that two of the three drives had “warnings” associated with them.  This was Not Good.  Two out of three failing HDD in a RAID5 array is A Bad Thing.  A bit of Googling and conversing with the vendor who sold me the NAS (note- I’ve got no problems with them, Hard Data has always been great for me for the past six or seven years) and it seems that there is a firmware upgrade for my particular trio of NAS drives.  Luckily, I managed to get all my critical stuff off the NAS, so I’m not to worried about data loss. 

So, I pull the drives, apply the firmware update, and try to rebuild. The NAS will not let me create a RAID5 array.  So, I pull the drives one by one, and then proceed to check them out in a computer.  Turns out that the two drives that had the warnings were okay, but the third drive, that was “warning-less” is toast.  What is wrong with it I’m not sure, but the BIOS on the computer won’t recognize the drive after boot up.  Had to RMA the drive back to Seagate. 

So, now I sit, alone in my room, without my NAS.

Figured I was due to spend some time setting up a Linux VM and learning how to program my Android Dev Phone 1.  Eclipse is what is recommended, so I thought I’d give that a try first.  So, with the help of Suse Studio, I quick built myself a VM with Java 1.6 (Aside:  I love Suse Studio, I can provision a VM in minutes).  I figured it would be pretty straight forward.  The docs on the Android Developer site for installing ADT plug-in seem pretty straight forward and simple, and I remember Eclipse having a very rich ecosystem of plug-ins that were easy to install (something I wish Visual Studio had – hint, hint Microsoft).

However, I ran into some hiccups with the provided documentation.

The first annoying one was item #4 in the list for Eclipse 3.4.  You’re directed to enter the location https://dl-ssl.google.com/android/eclipse/ for the location of the ADT plug in.  This did not work for me.  The location I had to use was  https://dl-ssl.google.com/android/eclipse/site.xml.  There is a chance https might not work for you, then use http://dl-ssl.google.com/android/eclipse/site.xml.

After overcoming that hurdle, I tried to do the Hello World sample.  This did not work out so well – Eclipse crashed.  Turns out that the default packages for Eclipse provided by OpenSUSE doesn’t have the Web Standard Tools, which is a requirement for using ADT.  So, I went back and uninstalled Eclipse, and download the tarball from the Eclipse website.  Then I installed and setup the ADT plug.

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.

After a bit of tinkering, I managed to provision my ADP1 setup without a SIM card.  A bit of google, and here is what I did:

1. Download the Android SDK.  In my case, I unzipped it to C:\android-sdk-windows-1.1_r1.
2. Connection the phone via the USB cable to my computer.  When the phone asks for a device.
3. You’ll get the new hardware dialog, when prompted for the drivers, you’ll need to specify the location.  The Android SDK has the drivers, in my case they were at C:\android-sdk-windows-1.1_r1\usb_driver\x86.
4. Once you have the drivers installed cd to c:\android-sdk-windows-1.1_r1\tools.
5. Type adb devices.  This should list all the Android devices that you have connected.  If you don’t see any devices listed, then you have a problem.
6. Type adb shell.  This will direct your commands to your ADP1
7. Now while at the adb shell, su to root, then : 
8. cd /data/data/com.android/providers.settings/databases/
9. sqlite3 settings.db
10. INSERT INTO system (name, value) VALUES (‘device_provisioned’, 1);
11. .quit
12. Reboot the phone
13. adb shell
14. am start -a android.intent.action.MAIN -n com.android.settings/.Settings

Once all that is done, you should be enable to use your ADP1 as if you had a SIM card in it (we’ll except for the phoning part).

Useful link:  FAQ: Unlocking/Activating a G1 or ADP1 Without A Sim Card.

After an uneventful flight from YEG to PSP, I’m settled in with my family.  After spending some time with beer at the pool, I’m sitting down with my Android Dev Phone 1 that I ordered last week (ship to PSP).

First impressions:  it seems like a nice phone, and I like the fact it has a keyboard.  I don’t have a SIM card to help with provisioning the phone, so all I get is this message saying "No SIM in phone" and "Emergency call".A quick search on Google tells me that how to get around this and use WiFi.  So, that’s my task for tonight.

Tomorrow we’re heading to the farmer’s market at the College of the Desert where I hope to refresh my collection of quality shirts.

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.

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.