MackelWhat?

Windows 7 Phone Development

2010-10-04T12:22:00.000-04:00

Well, I'd like to win a free phone, so as Scott Hanselman says on his website, here's my attempt to win a phone with almost no effort ;-)

Here's to winning.

Google Voice

2009-03-27T11:10:00.004-04:00

I'm setup with Google Voice now. It's a very nice service. I think it's going to radically transform how the phone works. As a simple example, try giving me a call with the enclosed Google Voice gadget I've just put in the side panel. It will call your phone, then connect back to me via their servers. A nice way to provide connectivity without having to advertise your number. I can't wait to see the pricing for this service. It obsoletes normal voicemail (since it provides a decent transcribed version of the voice mail). The management of voicemail is the same as email is in gmail.

NHibernate.MappingException: Unknown entity class

2009-01-07T13:19:00.002-05:00

I spent an hour finding and fixing a problem that should have been much faster last night. This post is to make sure I don't forget what I learned :-) I’m experimenting with NHibernate, and specifically the FluentNHibernate functionality. I was trying to get a test running, and I kept getting the error: “NHibernate.MappingException: Unknown entity class BLAH” (where BLAH was the persistable class I was building) during the mapping setup of the test.

I dug all over the place (assuming I had a typo in a namespace or some other stupid thing like that), and couldn’t find the problem until I ran Reflector on the assembly that held the mappings. Only then did I notice that the mapping class was grayed out (in other words, I’d failed to make the map public -- in fact when I created the class, I failed to set accessibility at all so it was set to the default accessibility of internal). Once I set access to the class to public, the test ran as expected, and I was able to finish setting things up.

public class BLAHMap : ClassMap<BLAH> {

public BLAH() {...}

}

I’m sure this is in the docs somewhere, but the bottom line is: don’t forget to make mapping classes public. The other takeaway from this is that it’s good to have multiple ways of looking at something – reflector showed the problem because it had a different way of displaying information that wasn’t visible just by looking at the editor.

Live Writer Test Post

2008-06-10T17:25:00.002-04:00

Microsoft just released a technical preview of the newest version of Windows Live Writer. Since this has a couple of features I’ve really been looking for, I’m going to try it out. If it works well, I’ll start using it for all my (very infrequent) posts. I apologize in advance for all the random content – I just want to try out the new features to make sure they work how I want them to.

Here’s a picture:

Here’s a table:

Heading 1	Heading 2
Row 1 Column 1	Row 1 Column 2

Here’s a map (our old house in Tucson):

Here is a video:

Emily's Birthday

Here is a code snippet:

            1: using System;

           2: using System.Collections;

           3: using System.Reflection;

           4:  

           5: namespace ExternalDSL {

           6:   public class DslExecuter {

           7:     private readonly Hashtable parameters = new Hashtable(StringComparer.InvariantCultureIgnoreCase);

           8:  

           9:     public void AddParameter(string name, object parameter) {

          10:       parameters[name] = parameter;

          11:     }

          12:  

          13:     public object Invoke(ActionExpression expression) {

          14:       object obj = parameters[expression.Left];

          15:       if (obj == null)

          16:         throw new InvalidOperationException("Could not find parameter with name: " + expression.Left);

          17:       MethodInfo method =

          18:         obj.GetType().GetMethod(expression.Operator,

          19:                                 BindingFlags.IgnoreCase | BindingFlags.Instance | BindingFlags.Public);

          20:       if (method == null)

          21:         throw new InvalidOperationException("Could not find method operator " + expression.Operator + " on " +

          22:                                             expression.Left);

          23:       ParameterInfo[] methodParams = method.GetParameters();

          24:       if (methodParams.Length != 1)

          25:         throw new InvalidOperationException(expression.Operator + " should accept a single parameter");

          26:       object converted;

          27:       Type paramType = methodParams[0].ParameterType;

          28:       if (paramType.IsEnum)

          29:         converted = Enum.Parse(paramType, expression.Right, true);

          30:       else

          31:         converted = Convert.ChangeType(expression.Right, paramType);

          32:       return method.Invoke(obj, new object[] {converted});

          33:     }

          34:   }

          35: }

The Immense Value of Failure

2008-05-14T22:35:00.004-04:00

A number of years back, I had the (dis)pleasure of developing software that had to interface with systems managed by a remote team that was paralyzed by the fear of failure. There was so much fear over making any wrong decision, that failure was guaranteed. The desire to “not be wrong” drove intense “Big Design Up Front” (BDUF) discussions and over-large meetings to “build consensus” and “get buy-in” that slowed progress to a crawl on good days, and moved the project backwards on the (frequent) bad days. It made even trivial decisions painful. This delayed the project to the point that it was eventually cancelled. The desire to not fail had let to failure.

I can see two root causes for this problem:

A Dysfunctional Work Environment: Anyplace fear is a major behavior-inducing factor.
An Incorrect View Of Mistakes: A belief that being making any wrong decision will cause permanent harm.

I’m only going to talk about #2 today – I’ve had several thoughts about this subject. #1 would be a topic for another article, but it’s not what I’m interested in right now. My premise is that just about every “good” thing we have in the world today came about because of a whole bunch of mistakes. For every system we have that works well, there are a nearly infinite number of them that failed for some reason, and which led the next person/team to try something slightly better. This failure (aka progress) is extremely valuable. This insight leads to two points:

No real discoveries were ever made without significant effort and trials. Edison with the light bulb. Newton with the laws of motion. Einstein with the general theory of relativity. There was a great show on PBS a long time ago called “The Ring of Truth” hosted by Phillip Morrison that went into great detail on this historically recurring theme.
A “good” mistake is small enough and made quickly enough that fixing it is not difficult and it teaches about the problem.

An often used analogy for project development is driving. When I get in the car, I usually know pretty much where I want to go. I don’t know what traffic will be like, so I’ll have to adjust for it along the way. I also don’t know if I’ll have to adjust for road construction, weather conditions, a flat tire, etc. All of those things get fed into the course corrections I make as I’m MOVING towards my destination. I could spend a long time working out a plan for each of these contingencies before I left, but even if I did, there are certainly things I would have forgotten, and would still have to adjust to. I’m not advocating doing NO planning beforehand, but doing “just enough and no more”. Of course the amount of planning should vary in direct proportion to the uncertainty of the terrain, and the size of the trip.

So, getting back to a project perspective, my belief is that every team should use the following loop:

Iterate
Fail Early
Fail Often
Learn From Small Successes & Save Them
Be willing to say “I Don’t Know”, but be willing to find out.

Being an “agile” team provides many of these tools. Small iterations keep you from getting hurt too bad along the project. They also allow direction changes to come from stakeholders (although I’ve never seen an actual stakeholder remain a part of an agile team long term – the stakeholders I’ve seen have always assigned a second-rate proxy after the first couple of iterations). The tests written during development and keep the successes alive and in the knowledgebase. They also encourage the “I don’t know” behavior.

The bottom line is that we should be justifiably proud of our failures, much in the same way we are of our successes – as long as we’ve learned the lesson those failures are trying to teach.

There are a few quotes regarding this topic that I really like:

Samuel Smiles

It is a mistake to suppose that men succeed through success; they much oftener succeed through failures. Precept, study, advice, and example could never have taught them so well as failure has done.

We learn wisdom from failure much more than from success. We often discover what will do, by finding out what will not do; and probably he who never made a mistake never made a discovery.

Mohandas K. Gandhi

Freedom is not worth having if it does not connote freedom to err.

Robert F. Kennedy

Only those who dare to fail greatly can ever achieve greatly.

Robert Frost

The best way out is always through.

Word 2007 Test Post

2008-05-14T21:02:00.007-04:00

This is a post to see how things look when posting from Word 2007. If this works out ok, I'll be using this for my publishing from now on.

Photo Test

This is a picture of my extended family on my Mom's side (Anderson). My Grandpa Anderson is standing in the middle of everybody. I'm the little boy standing up on the far right side. This was taken in the late 60's sometime. I'm sure one of my sisters will tell me exactly when it was :-)

Added note @ 9:10 5/14/2008 - MS Word 2007 isn't going to cut it as a Blog editor. I tried posting this from Word, and the image didn't make it, I also had several sections below where I had code fragments and other formatting things embedded in this post. None of them worked as I expected them to. Looks like I'll keep using the online editor for posting for the near term. If anybody has found something better, please let me know in the comments.

Sharing A USB Drive On XP / Vista

2008-04-15T09:25:00.009-04:00

I recently needed to share my USB hard drive on the network, and had a lot of problems making it consistently available as a share. After trolling around on the internet, I found the answer -- since this took a while to find and debug, I'm documenting it here.

In regedit, find the key in HKLM (HKey Local Machine):

\System\CurrentControlSet\Services\LanmanServer\Parameters

Set the parameter IRPStackSize to a value 3 higher than it currently is, and reboot. You may have to do this more than once. If this key doesn't exist, create a DWORD key and set the value.

On the two systems I did this to, I ended up with values of 17 and 18.

The Parable of Everybody, Somebody & Nobody

2008-04-15T08:58:00.005-04:00

I need to attribute this, but this story popped into my head last night. I believe I heard it in church about 30 years ago (man, it's embarrassing to say that)...

All the people wanted to get back to Heaven, and there were many tasks to perform to get there. Everybody was sure that Somebody would do the work. Anybody could have done it, but was waiting for SomebodyElse to do it. Somebody got angry because it was Everybody’s job. Everybody got angry because he thought that Anybody or SomebodyElse should do it. Somebody said that she thought it was already done, but didn't bother to check.

Finally the day of reckoning came. Everybody fought to be first in line for the rewards. Somebody was crying because SomebodyElse was pushing and giving cuts. Nobody was patiently waiting for her turn.

Nobody was the only one who made it into Heaven. She was the only one that did the tasks that Everybody, Somebody, and SomebodyElse should have done.

The Moral: Don't Procrastinate. Don't let Nobody be rewarded for things YOU can do.

Small Teams

2008-04-15T08:37:00.004-04:00

My wife and I went to the "Engineering Open House" at NC State with my son Richard last Saturday. They had many cool things on display, and there were a lot of people there. Richard is very interested in doing something technical, but isn't sure what yet.

The most interesting thing that I did there was spending about a half hour talking with Grayson Randall who designed the Lone Wolf autonomous vehicle that NC State entered into the DARPA Urban Challenge contest. Grayson is a really interesting guy and has a lot of cool stories to tell. I was asking him about the development process and team they used to produce the control and management software for the 9 dual core computers they have embedded in the trunk of their Lotus plus the 4 single board computers they have in the front of the car. He said that there were 6-9 people who spent a couple of years developing this software, with various teams implementing hardware at the same time.

Having been involved in systems design, I can know how hard it is to develop both hardware and software at the same time, so getting it all running is amazing all by itself. The point that sticks out to me most of all though is that a small motivated team can accomplish more than a large one in nearly all cases.

As teams grow beyond single digits two things happen:

Inertia kills agility. Too many people are too hard to switch quickly. With small teams a quick meeting can convey the essence of the change. Large teams take exponentially larger amounts of time and effort to simply communicate.
Inertia kills motivation. This is obviously not true in all cases, but in the teams I've seen, there is a direct relationship between the motivation of the team and the size of the team. I've seen too many cases on large teams where "everybody thought somebody would fix it".

Note that I'm not saying that small teams are the only ones that can succeed. Simply that in my experience, small teams are more likely to.

Hosted Services

2008-04-08T09:57:00.004-04:00

First Amazon created EC3, now there's Google App Engine. I think companies providing 3rd party hosting environments are in for a tough time in the future. It's going to be tough to compete on volume / size / price. They're going to have to provide niche features that Amazon / Google don't have.

For developers and startups, I think this is a Very Good Thing.

New Blog Elements

2008-03-27T21:52:00.002-04:00

If you're reading this in an aggregator, you won't be able to see this, but on my blog home page, I've added a few new interesting time wasters. Specifically:

Visitor Map - This is from ClustrMaps and shows how few readers I actually have :-)
Recent Interesting Sites And Articles - This has three things:

Recently "Shared" Google Reader Items
Recently "Starred" Google Reader Items
Recent del.icio.us Links

So for all those times you don't have anything better to do, you can see what I'm looking at...

Google Apps

2008-03-27T21:32:00.002-04:00

I've recently setup a couple of my domains with Google Apps, and I'm very happy with it. 6G+ of email space per account, 10G+ of space per domain for wiki stuff, and lots of document and spreadsheet goodness all around. You can check out either http://start.mackelprang.com or http://start.mackelprang.org to see what's there.

The main site for me will be the mackelprang.com one (http://www.mackelprang.com). The mackelprang.org site will be used for the "family at large".

Setting up the domains was a very painless experience compared to what it would take doing it at a hosting site. I've migrated nearly all of my local hosting dependencies to my Google Apps sites, and I'm very pleased. I'll keep you up to date as things progress.

Starting Up. Again.

2008-03-27T21:28:00.002-04:00

So Andy tells me he wants to blog again, and guilts me into joining him. I have a lot of article topics pending, so I'm going to spend a couple of hours a week getting them out here. Hopefully I'll be more diligent this time than last...

How Many Digits In That Number?

2006-12-04T15:23:00.000-05:00

This is the first article in a series of “interesting things I’ve found that I haven’t seen used elsewhere”. This will discuss a technique I used a couple of times in college when writing contrived software for CS and EE assignments.

One of the assignments I had required formatting numbers for output. For the algorithm I was using, it was important to know how many digits were in an integer number before I output it. This would make the formatting significantly easier than not knowing ahead of time. In thinking about how to do this, I realized there were several ways to do this. The first was to find modulo 10 and divide by 10 until the number was 0. This figured out the length, and found the individual parts of the number nicely, but it started from the least significant digit and worked up. I wanted something that would go the other direction.

I remembered my algebra class, and the log (base 10) function. I remembered that if log x = n, 10^n = x. In thinking about this, I realized that the ceiling of log x is the number of digits in x. In other words, since log 12345 =4.something, 12345 has 5 digits. This meant I could code something like the following:

int GetLength(int num) {

return ceil(log(num));

}

And could print out the digits of the number like this:

for(int j=GetLength(num); j>0; j--) {

cout < num / 10^j;

num \= 10^j;

}

So for base 10, it worked really well. The epiphany occurred when I needed to do the same thing with binary (base 2), octal (base 8), and hexadecimal (base 16) numbers. It turns out that this algorithm is extensible to arbitrary bases. To get that, we just have to make a couple of minor changes:

int GetLength(int num, int base) {

return ceil(log(num)/log(base));

}

int num = 12345;

int base = 2;

for(int j=GetLength(num, base); j>0; j--) {

cout < num / base^j;

num \= base^j;

}

There are a couple of special cases that you have to take care of when using this. Specifically:

Negative numbers – you need to make sure to pass positive numbers into the digit counter. Logs of negative numbers aren’t real, and most math libraries don’t handle them well.
Fractional numbers – for numbers with decimal places, this technique doesn’t work right. To make them work, you’d have to decide on how may decimal places you want, multiply by that number to start, then put the decimal point in the “right” place when emitting the value.
Digit representation – for bases greater than 10, you’d need a mapping to handle the digits to output. In the example given above (with no digit mapping), the cout will emit a “13” instead of a “D” as expected for a hexadecimal conversion. Some kind of simple digit mapping scheme would have to be added to take care of this case.

USB Drive Adapter

2006-11-02T21:33:00.000-05:00

Like any true geek, I have a bunch of old hard drives laying around my office. It's a pain to install them in a system just to copy data to them or to get data from them, but this week I bought a very cool device from NewEgg. It's a small square adapter that has hard drive plugs around three of it's sides. One adapter for 2.5 inch laptop drives, one for 3.5 inch normal system drives (which also works in CD/DVD drives), and another for SATA drives. There is a power supply for the drive motor, since many 3.5 inch drives draw more that USB can supply. It's a BYTECC BT-300 USB 2.0 to IDE/SATA Adapter, and it's less than $25 at NewEgg.

This will make migrating stuff between computers a breeze. I wish I would have thought of this first.

I Code Like A Rock Star!

2006-10-18T13:43:00.000-04:00

Originally Posted On: DATE: 10/07/2005 11:27:57

Today I was working with one of my office mates on reproducing a problem reported at a field site. He had already gotten the source from the tip, built, and tested it, and then added a test case to demonstate the problem we were seeing in the field. The conversation went something like this:

Him: "I added the test, and it all works."
Me: "Really? That change should have caused a failure. Let's take a look."
We looked at the code, and sure enough, the test that should fail was in the test case.
Me: "This is really strange..."
I added a fail(...) to the test case, and it still didn't cause any failures.
Me: "This is really bothering me..."
I added a compile time error to the test case, and the compiler did complain this time.

Finally, we looked in the test suite (this is a fairly old class that's still using NUnit 1.x) and found that the suite wasn't including this test class. We added the class to the suite, and the failures happened in the way we were expecting. We then backed all the cruft we had just added to the test class back out, and worked on the problem from the beginning. It was very disconcerting to be able to add errors to the test class but not have them show up.

Two lessons I learned from this episode:

Don't Take Short Cuts. There's a great article on The Three Rules Of TDD by Bob Martin. We should not have added anything to a class that wasn't really being called. There are ways to validate that the classes are actually included. This problem would be alleviated by using NUnit 2 somewhat, since the tests there are tagged instead of named, and the Suite class is unneeded.
Don't Trust Anything. Whenever something smells wrong, there's probably a good reason. Start with the simplest thing (like - is the editor, the compiler, and test running all pointing at the same place?) and work up in complexity to find where things start to stink. Then iterate around there until you find the problem.

Another One Bites The Dust

2006-10-18T13:40:00.003-04:00

Originally Posted On: DATE: 09/18/2005 10:59:45

When I was in high school in the early eighties, a friend of mine (David Jackson) told me that there were hidden lyrics in a song by the rock group Queen. I didn't believe him, so he put my copy of the LP (we had vinyl LP records then) on my record player, and turned the record backwards by hand. On the song "Another One Bites The Dust", there were some very interesting lyrics. Take a listen to both versions and see if you can hear what I thought I heard in the backwards version. (Note that before you listen to any of this that this song is (c) Queen, and I have no rights to it whatsoever. I'm just making an interesting observation about a 5 second snippet of it.)

Here's the snippet I'm talking about played normally.
Here's the exact same snippet played backwards.

To me, it sounds like the backwards version says "it's fun to smoke marijuana" several times. Now that you think I heard that when I listened to it, listen to the backwards version again. Did the things I heard affect what you heard? There are a couple of interesting thoughts here:

If it really says that, how did the guys in the band manage to make it say that?
If it doesn't, how much does your expectation that something will say something affect what you actually hear?

Personally I can imagine a bunch of guys messing around with audio equipment, trying to find something to write a song about and finding out that "i like to smoke marijuana" sounds like "another one bites the dust" backwards, and using that in a song.

In the end, it doesn't really matter. I seriously doubt that there's any subconscious decoding that will take lyrics backwards, and put them in your memory, and further, I still think that the song is a fun song.

Excellent Fowler Article

2006-10-18T13:07:00.000-04:00

I saw an excellent article by Martin Fowler today. It hits the nail on the head of why it's so hard to do something new even though it has a very good chance of being easier/better than how we do it today. This was my experience in learning Test Driven Development.

Automatically Dismissing The Unhandled Exception Dialog

2006-10-10T13:11:00.000-04:00

On our build system, we were having two problems. First of all, there was a smoke test that was throwing an unhandled exception. Second of all, the .net framework was presenting a dialog to ask the user what to do about the exception. In the spirit of fail fast, this was causing a big problem for the entire build, since we normally don't have somebody staring at the build box, expecting to give user input. It's very important that the build box be headless and input-less. It's OK to have a management console like CruiseControl to request builds, but there should never be an interactive dialog.

I googled for an answer on how to automatically dismiss the dialog, and finally found the answer. Essentially, all you have to do is modify the registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\ .NETFramework\DbgJITDebugLaunchSetting

and change it's value to 1. This will allow the process throwing the unhandled exception to terminate with a stack dump with no user interaction.

Upgrading From NAnt 0.84+ to NAnt 0.85 rc4

2006-10-06T16:16:00.000-04:00

I converted our nightly and integration builds from NAnt 0.84 (with some local mods) to NAnt 0.85 rc4 today. Overall, the upgrade was pretty painless. There were several changes that I had to make to our build file to make it work, plus there were many warnings that I wanted to remove after trying things out. Here's the list of things I did:

Copied the support dlls from the NAnt contrib project into the nant/bin directory. This was required for several support tasks and attributes. It also makes it easier to upgrade the build file later since everything will be available.
Copied support tasks created locally into the nant/bin directory. These tasks were still compatible with the new version of NAnt, and didn't even require a rebuild.
Used to have to set an environment variable with inline C# code, but we can now take advantage of the setenv command. This even speeds up the build slightly since the dll that sets the env. variable doesn't have to be compiled and loaded.
Changed all includes and excludes to include and exclude respectively. There were many filesets in the build file. This was by far the most common change. This was not required, but removed many warnings.
Changed all user in vssget and vsslabel to username. Again, this was not required, but generated deprication warnings.
Had to add some code to ensure the write-only bit was off before touching some files to change the timestamp (this was necesssary because of making sure IIS saw the webservice files as new). This was a required change due to some new behavior in NAnt.
Used to have some code to remove a service before we installed it for Smoke Tests. With the newer NAnt (in the contrib project), there is a service::is-installed() check we can use. This eliminates severa lof the warnings we used to get on our Smoke Tests. This was a nice enhancement made possible by the new check.
In our nunit2 tasks, we formerly used haltonerror attributes. These are now "failonerror".
In our Acceptance Tests, we formerly only used the basedir attribute. With the newer NAnt, we now need to set both the basedir and workingdir attributes. This is necessary only for programs that expect data/config files to be in the executable directory. If running a program that takes no input, this would not be necessary. This was a required change to allow the tests to run.
All of the nunit (aka Nunit1) test suites are tagged as depricated, and generate warnings in the build logs. I like this because it will encourage us to upgrade those tests over the next while.

Google Reader Update

2006-09-29T23:02:00.000-04:00

Google has updated their RSS reader. I liked what they had before, but the new features are pretty cool. They had "starred" items (i.e. items you wanted to keep track of for later which you can see in the sidebar of this blog, but now there's a new feature called "shared" items. This is like a poor man's plagaristic blog. You can even add an rss feed for your shared items.

Overall, I'm very happy with it. I tried several readers before going with Google's. I normally use two or three different computers each day, so it's really nice to have all my feeds synced.

Check it out if you're looking for a reader.

Windows Live Writer Test Post

2006-09-28T12:46:00.001-04:00

With images no less!

This picture or Richard was from summer camp last July. I believe this was on the Nantahala river.

VMWare Appliances

2006-09-20T23:03:00.000-04:00

I've installed the (free) VMWare server on my development server at home and I frequently use a couple of their appliances on it. Specifically:

Twiki - This is an awesome idea to be able to install and use TWiki without all the hassles of getting it going on a server. Especially if your server is Windows based. This appliance already has Samba installed, so getting files on and off the box is very simple, as are backups. It also sets itself up with a netbios name, so connecting to it is cake.
Helix - This has Trac installed along with subversion. Two very nice tools for managing development. I'm currently only using subversion (since Trac is a little over the top for what I do by myself).

I've installed the Twiki appliance at work, and converted some fairly old (2+ year old version of Twiki) data to the new appliance. This took about 3 hours in all to do.

Overall, I'm very happy with this tool as a solution.

Tests Don't Save You From Being Stupid

2006-09-20T22:41:00.000-04:00

Originally Posted On: DATE: 08/29/2005 04:18:31

A couple of weeks back I worked on adding some new capabilities to a software system at work called the `listener'. Essentially, this software receives socket messages (events), assembles, parses (from various protocols), generates `model' events, and passes these off to a subsystem to let various business logic handlers deal with the events and do interesting things with them. The piping internal to the system to move events around includes (among other things) the Visitor Pattern, which is normally very explicit about not being able to handle a new type if a new type has been added.

The capabilities I needed to add depended on creating a new event type that the visitor pattern would pass to the appropriate handler on the back end (like visitor patterns do). I built the acceptance test, ran it, watched everything fail as I expected, then got into modifying the interfaces to force the creation of the new event type, and force the various implementations to implement a `visit' method for the new event. All of this went swimmingly, and after working for about three or four hours, I had the whole system back together with new UT's for the classes that needed changed, and with the original AT that started the whole thing working.

So, I had added about 50 UTs, and about 3 ATs and everything looked copacetic. I took the finished code off to run it on a test system with real data.

It didn't work.

After spending a couple of hours digging through the logs, tests, and finally the code, I found that when we built the system, we had added a base class beneath some of the implementations of the visitor for some reason. This base class provided default behavior for unknown types coming in. Since this base class was embedded in the plumbing, the default handler was taking the new event type, and wasn't letting it get to the endpoint implementation, so the new event wasn't being handled. Once I found that, I found several tests that I had missed on the first pass through the system that would have pointed out these problems, but I had glossed over them.

If I knew then what I know now, I'd:

Make sure that if I'm using Visitor, I make the compiler warn me about problems. The fact that I'm using Visitor means that I'm SURE I'll be adding new types. Let the compiler do its job when the types aren't wired up correctly.
If there is a compelling reason to stick a base class in there (i.e. a default visit handler), add a test that does reflection to count the number of visit types between the end point implementations and the interface. This might be a little hairy, but the 2-3 hours spent will save me several times in the future.
If you're in a situation like this, and the base class is causing you pain, remove the base class.

It was a good learning experience. It just points out once again that hindsight is awesome.

Kent Beck / Alan Cooper Smackdown

2006-09-20T22:26:00.001-04:00

Originally Posted On: 08/22/2005 09:11:55

I read a very interesting article today. One of the most interesting things I've read in the last several months. I completely agree with Beck that the XP methodologies would work best and provide a nice process for solving the difficult problems of software development, but my experience has been that getting a "customer" is one of the most painfully difficult things there is. In my experience, it's NEVER been successful for more than a few weeks. I had lunch with some XPers from GSK (GalaxoSmithKline) a couple of weeks ago, and their experience mirrored mine.

Computer Science Challenge List

2006-09-20T22:13:00.000-04:00

Originally Posted On: 06/20/2005 03:05:45

Several years ago, I found a document called Challenges for Theoretical Computer Science. It describes a bunch of 'challenges' that haven't been solved in the computer science area. The information written in this list is 5+ years old now, and it's amazing how many items on the list are still outstanding. I don't claim to be able to understand all of the challenges (like 'Make Quantum Computing a Reality'), but there are a lot of them that apply directly to TDD methodoligies (like 'Software Specification'). It would be interesting to track this list (or one like it) over many years.

I think it's useful to take a step back every once in a while and see where we've come, and where we're headed. A couple of useful things can come out of it:

Correction/Validataion of your current course.

Realization that most problems have been around longer than our recognition of them, and that some smart people may have spent time thinking about them.

Insight into a problem outside of your current vicinity can give a great new angle on your immediate problem.

New product ideas. You may have the insight to solve some problem that nobody else has.

Mickey Mouse Show

2006-09-20T22:06:00.000-04:00

Originally Posted On: 06/17/2005 04:22:42
Rob Selph commented to me that he liked the name of the blog, but that I should explain a little about the name. My name is Mark Mackelprang, and with a last name like that, the blog name is pretty natural. Growing up, it was intimidating to learn to spell an 11-character surname, so my older sister came up with a nice mnemonic trick to do it. I just so happens that there are also 11 characters in the name "Mickey Mouse", and it just so happens that the cadence and flow of the letters is very similar if you sing the Mickey Mouse Club Theme Song with the letters of my last name (What's the surname we adore that's made for you and me? M - A - C - K - E - L - P - R - A - N - G...). It's how I learned it, how my wife and kids learned it, and it's how I teach people I meet now to remember to spell it. Songs are amazing tools for learning things.

Namespace Refactoring

2006-09-20T21:34:00.000-04:00

Originally Posted On: 06/16/2005 12:05:04
Over the last week or so, I've spend some time refactoring some namespaces in the C# codebase at work. There were some things that had just been languishing in the wrong
place for a long time. We had a few days to spend cleaning up things that we normally have to live with, so this is one of the things we decided to fix. Like any other refactoring, NS refactoring shouldn't change any system functionality, but just improve the overall design. It's a lot like renaming a class, and maybe it boils down to the exact same thing in the end. Luckily, this codebase is well covered with tests. We have unit tests (class level functionality), acceptance tests (system or subsystem level functionality), and smoke tests (installation functionality).

This process would have taken many times longer with much higher risks without the tests. Even with these tests, there was plenty of pain to feel. I'm a sharing kind of guy, so here's what hurt:

File Names: Don't ever use a object type for any part of a configuration file, log (thanks to Andy Sipe for the catch here) file, etc. For the actual code itself, there isn't a problem since all you have to do is rename the file. Whenever the config or logfile depends on the namespace, however, there are several locations you have to go to fix things up again. This bubbles through the system, and clear up to the install process. For upgrades, there will be difficulties merging from old to new when configuration file names change from version to version. For me, it helped to think about the fully qualified type as a unique ID in the db. Whenever that ID is used for something other than identity, trouble follows. The same is true for types. The rule here is name all files after their intended use, not after their location or namespace.

Object Identifiers: We used a persistable object layer to insulate the code from the db in the system. When we implemented the object identifier subsystem, we had the object ID's generated from the type of the object. This means that we had an OID table in the database, with type names in one of the columns. This makes the design very resistant to NS refactoring, since it would require a db upgrade to change the code. We ended up putting a mapping layer in the OID layer that takes a type and returns the "name" of the OID object to use. For now, we're using the "old" OID names to prevent an immediate database upgrade. In a future refactoring, that's another thing we'll want to fix.

Configuration File Locations: Use the "once and only once" (DRY) principle ruthlessly when setting up config files. We use VSS (don't start with me) and had originally shared various files between all of the projects that needed them. After going through the process of NS refactoring, I believe the correct way to do this would be to store any shared configuration files in a single location, then make it part of the build process (NAnt) to copy the configuration file from the one location to the test location before running the test. For files that are used only once, put them where they're used, but if they ever become shared, spend the time to put them in the single location, and change the build/test to get them there.

Tests: Don't even try to do this over a large set of files without good tests around them. The unit tests aren't really useful for this refactoring. The compiler tells you most of the errors that are at this level. The acceptance tests are good since they pull all the parts of the system together, but they can be fairly long running (some of ours take many minutes to run). The best tests for this kind of refactoring are the smoke tests. These validate the installation for the various end products, and generally only take a few seconds to run for each one (plus file copy & startup time).

Conclusion: Overall I think this kind of maintenance should be a regular activity. Company names change, the overall design change. Failure to update the NS is another "broken window" or "smell" that Andy Hunt and Dave Thomas mention in their Pragmatic Programming book.

Trying out Blogger...

2006-09-19T15:30:00.000-04:00

Instead of hosting my blog on my home computer, I'm seriously thinking about simplifying things and using Blogger. We'll see how hard it is to import everything into it before I make any permanent decisions...