I am undecided on Twitter. The jury is still out in my mind. On any given day, there are things I need to do and things I would like to do. Not taking into account family things, I read through my emails, both work and personal, read through my RSS feeds, news feeds, weather reports, IM with close friends and family, read a few credible news sources, and somewhere find time to work and research new and existing technologies. If I can get that far, that is a busy day, and that does not include family.

So where am I supposed to find time to update everyone on Twitter? How is Twitter fitting into your schedule?

You can follow me, but I am not really all that active, at least until I find more time.

I was in a design discussion today and mentioned the need for a singleton object in our solution. Further along in the discussion I was trying to find a word that describes the opposite of a singleton, but alas, I struggled to find a word that may or may not exist. I just referred to the inverse object as a "new object." As I pondered this later in the day, I considered adjectives describing the nature of objects. They can be many things, but two concepts that popped into my head to classify them were "complex" and "simple."

I started playing with the words and making them resemble singleton. "Complexton" did not sound right to me. I should mention that I was washing my hands as I was contemplating this. I lifted up my head, looked into the mirror, and thought, "SIMPLETON." The opposite of a singleton is a "simpleton."

If the opposite of a singleton is not a "simpleton," then what is it? Until I find a plausible answer, I will try and insert this new term into my next design discussion.

Duplicate code to me is wrong. Writing duplicate code to me is like using poor grammar. If I am unaware of it, I am none the wiser. However, if I knowingly use poor grammar or duplicate code, I feel bad.

After seeing too many duplications across methods in one or more classes, I decided to investigate a way to remove these. I am always looking to remove duplicate code, even code that shares similarities, I look to refator. Removing duplications is important to adapt more easily to change. When a code change is required, we should only have to make it in one place. The following article will show two relatively simple means to address this code smell, delegates and an Aspect-Oriented approach.

The example I am using in this article is seen below. It is a unit test class, StackFixture class, and it is extremely trivial. This is a typical unit test taken from Test-Driven Development in Microsoft .NET. I have added the logging functionality as an easy means to show how these types of DRY violations can occur. While the duplications in this example deal with logging, they could pertain to other, more complex, functionality as well. The approaches to removing duplications across methods in this article can work with these simple scenarios, as well as more complex ones.

Take for example this sample test case. Each test method logs a message before and after executing the test logic. This violates DRY. We want to keep our test logic in our method, but factor out the duplicate logging. Again, if we were not logging, but doing some repetitive logic, we could factor that out as well.

   1: [TestFixture]

   2: public class StackFixture : AbstractBaseFixture

   3: {

   4:     private Stack stack;

   5:  

   6:     [SetUp]

   7:     public void SetUp()

   8:     {

   9:         stack = new Stack();

  10:     }

  11:  

  12:     [Test]

  13:     public void Empty()

  14:     {

  15:         Log.Info("Starting Empty test");

  16:  

  17:         Assert.IsTrue(stack.IsEmpty);

  18:  

  19:         Log.Info("Ending Empty test");

  20:     }

  21:  

  22:     [Test]

  23:     public void PushOne()

  24:     {

  25:         Log.Info("Starting PushOne test");

  26:  

  27:         stack.Push("first element");

  28:         Assert.IsFalse(stack.IsEmpty, "After Push, IsEmpty should be false.");

  29:  

  30:         Log.Info("Ending PushOne test");

  31:     }

  32:  

  33:     [Test]

  34:     public void Pop()

  35:     {

  36:         Log.Info("Starting Pop test");

  37:  

  38:         stack.Push("first element");

  39:         stack.Pop();

  40:         Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

  41:  

  42:         Log.Info("Ending Pop test");

  43:     }

  44:  

  45:     [Test]

  46:     [ExpectedException(typeof(InvalidOperationException))]

  47:     public void PopEmptyStack()

  48:     {

  49:         Log.Info("Starting PopEmptyStack test");

  50:  

  51:         stack.Pop();

  52:  

  53:         Log.Info("Ending PopEmptyStack test");

  54:     }

  55: }

Remove Duplications with Delegates

Quite simply, we can remove our method duplications using a delegate, in this case, the System.Action delegate. Thanks to Ayende for helping me understand this option. We create a method, TestMethod (as shown below), and add it to our StackFixture class. The method takes two strings (string beforeMessage and string afterMessage) and the Action delegate, representing the test method logic. We will call this method within our test cases.

   1: public void TestMethod(string beforeMessage, string afterMessage, Action action)

   2: {

   3:     // before

   4:     Log.Info(beforeMessage);

   5:     

   6:     // invoke our method

   7:     action();

   8:     

   9:     // after

  10:     Log.Info(afterMessage);

  11: }

Then, in our tests, we replace the following test method...

   1: [Test]

   2: public void Pop()

   3: {

   4:     Log.Info("Starting Pop test");

   5:  

   6:     stack.Push("first element");

   7:     stack.Pop();

   8:     Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

   9:  

  10:     Log.Info("Ending Pop test");

  11: }

With the same method using our delegate approach.

   1: [Test]

   2: public void Pop()

   3: {

   4:     TestMethod("Starting Pop test", "Ending Pop test",

   5:                delegate

   6:                    {

   7:                        stack.Push("first element");

   8:                        stack.Pop();

   9:                        Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

  10:                    });

  11: }

We can replace each of our test methods with the same TestMethod using the System.Action delegate. It will then easy to omit our before and after strings replacing them with "action.Method.Name," or some other intelligent logic to determine what to log.

This approach works well, but delegates are often difficult to understand. If this solution suits your needs, make sure the implementation is easily maintainable. What is nice about this approach is how simple it is. There is no need to reference any assemblies outside of the .Net framework, i.e. no third party dependencies.

The Aspect-Oriented Approach

Aspect-Oriented Programming (AOP) is an entirely different animal. It certainly deserves more than just a blog post. Please read more about it online. This article will not explain the details of AOP.

If you are reading this, welcome back. I will assume you are now familiar with AOP. There are several options for AOP frameworks. Some frameworks I have used are Spring.net, Castle Project, and PostSharp. The former two provide IoC capabilities as well. I suggest using a well-supported framework, one with community support and frequent updates. Investigate for yourself, there are several nice options available.

AOP with Castle DynamicProxy

Hamilton Verissimo put together a good sample using Castle's DynamicProxy. It is a nice, clean implementation.This worked fine for me and would work well in other situations. However, in my scenario, if I were to use this approach, I needed to have each of my test classes extend from MarshalByRef. In addition, I would need to modify the underlying NUnit framework to create my proxies in order to provide advice. Since I could not do the latter, or did not want to investigate, I searched for other AOP options.

The DynamicProxy aproach to solving your AOP needs is a great option. It just did not work in my situation, only because NUnit executes each of my methods. I would need to somehow intercept the creation of my test class, create a proxy of it, and execute the test methods on it.

AOP with PostSharp

Gael Fraiteur's PostSharp is a great option for AOP needs. It is extremely clean and easy to use. It is the simplest AOP framework I have used. I suggest watching Gael's video tutorial.

The first thing I needed to do, besides downloading and installing PostSharp, is to add two references to my project, PostSharp.Laos and PostSharp.Public. After that, I create a simple class extending OnMethodInvocationAspect, called LoggingMethodInvocationAspect.

   1: [Serializable]

   2: public sealed class LoggingMethodInvocationAspect : OnMethodInvocationAspect

   3: {

   4:     private ILogger log;

   5:  

   6:     public LoggingMethodInvocationAspect(ILogger logger)

   7:     {

   8:         log = logger;

   9:     {

  10:  

  11:     public override void OnInvocation(MethodInvocationEventArgs eventArgs)

  12:     {

  13:         // before

  14:         log.Info("OnInvocation Before proceed");

  15:  

  16:         // invoke

  17:         eventArgs.Proceed();

  18:  

  19:         // after

  20:         log.Info("OnInvocation After proceed");

  21:     }

  22: }

At this point, all we need to do is apply our aspect on target methods. The "AttributeTargetMembers" attribute can use wildcards. This tells the AOP framework to only intercept those methods in the "MathService" class that start with "Test." Below is the sample where I specify the target assembly, target type (class or classes to intercept), and target methods to intercept. There are many features beyond what I am showing so do further investigation.

   1: [assembly: ClassLibrary.SampleInterfaces.LoggingMethodInvocationAspect(

   2:     AttributeTargetAssemblies = "ClassLibrary.UnitTesting.Sandbox",

   3:     AttributeTargetTypes = "ClassLibrary.UnitTesting.Sandbox.MathService", 

   4:     AttributeTargetMembers = "Test*")]

Finally, my StackFixture class now looks something like this. Notice that the duplicate logging logic is now removed and each test method is prefixed with "Test" in the method name. This is so that PostSharp can filter what methods to intercept.

   1: [assembly: ClassLibrary.SampleInterfaces.LoggingMethodInvocationAspect(

   2:   AttributeTargetAssemblies = "ClassLibrary.UnitTesting.Sandbox",

   3:   AttributeTargetTypes = "ClassLibrary.UnitTesting.Sandbox.MathService", 

   4:   AttributeTargetMembers = "Test*")]

   5:     

   6: [TestFixture]

   7: public class StackFixture

   8: {

   9:     private Stack stack;

  10:  

  11:     [SetUp]

  12:     public void SetUp()

  13:     {

  14:         stack = new Stack();

  15:     }

  16:  

  17:     [TearDown]

  18:     public void TearDown(){}

  19:  

  20:     [Test]

  21:     public void TestEmpty()

  22:     { 

  23:         Assert.IsTrue(stack.IsEmpty); 

  24:     }

  25:  

  26:     [Test]

  27:     public void TestPushOne()

  28:     {

  29:         stack.Push("first element");

  30:         Assert.IsFalse(stack.IsEmpty, "After Push, IsEmpty should be false.");

  31:     }

  32:  

  33:     [Test]

  34:     public void TestPop()

  35:     {

  36:         stack.Push("first element");

  37:         stack.Pop();

  38:         Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

  39:     }

  40:  

  41:     [Test]

  42:     [ExpectedException(typeof(InvalidOperationException))]

  43:     public void TestPopEmptyStack()

  44:     {

  45:         stack.Pop();

  46:     }

  47: } 

The end result, a StackFixture test class with duplicate logging logic removed. The PostSharp AOP framework post-processes the compiled assembly and inserts itself, easily providing points of interception.

The PostSharp approach does involve a third-party dependency, but I feel like it is cleaner than the delegate approach. Gael informed me future versions of PostSharp will provide a more configurable solution than adding the [assembly ...] reference for the aspects, perhaps an XML configuration option. This can be done today, but involves some work.

Whether you use delegates, AOP, or some other approach, remove duplicate code wherever possible. I am happy to use either approach in my projects. There are tradeoffs to either solution, so investigate for yourself.

It is nice to be able to apply the Vista themes and sidebar personalizations (eye candy) to a Longhorn environment. This site appears to be thorough on the topic of Converting your Windows 2008 Server to a Workstation.

This article got me started with enabling the "aero" theme, Windows Server 2008 "Aero Enabled" Workstation Edition.

While installing Notepad2 on my Longhorn box (WindowsServer2008) I ran into an issue with overwriting the original notepad due to a lack of permissions. I found Matt Berther's article which helped me understand what files needed to be overwritten for use in Vista. While I ran into similar problems in Vista, I did not write down my steps, so when it came time to rebuild my Longhorn development environment, I battled the same issues.

Vista and Longhorn both have increased security measures.  Overwriting a system file like notepad.exe is more involved. While I can see their need for this added security, I do find it annoying. Regardless of whether or not you are installing Notepad2, as in this article, or you just need to reassign ownership of a file in Vista or Windows Server 2008, I hope this article helps alleviate some of the pain.

In following the article on overwriting notepad.exe with notepad2.exe, I first came across the issue of granting full control rights for this file to my logged in user. Since I have had to figure this process out more than once now, I am deciding to document it, with wonderful screen-shots.

While granting full control to the administrator, I was alerted with the following dialog.

In order to overwrite a file, like notepad.exe, we need to give the administrator "Full control." In order to do this, we need to change ownership of the file from "TrustedInstaller" to "Administrators." TrustedInstaller, by default, has full control, while the admin account does not.

Right click the target file, click Properties.

Click on the security tab. You should see the "Administrators" account, by default, with read and execute permissions only.

Click on the "Administrators" account, seen above, then click on "Advanced" as pictured below.

Next, we need to select the account for which we wish to edit owner permissions. Select the "Owner" tab. We should see "TrustedInstaller" highlighted as the current owner.

Click the "Edit..." button to change the owner of the file. The owner settings dialog should appear. Select the "Administrators" account, and click "Apply." After clicking apply, there should be a prompt as shown below.

Finally, click "OK." Then click "OK" to close the owner dialog. Click "OK" to save and exit the "Advanced Security Settings for <YourFileName.extension>."

Next, we want to allow "Full control" for the admin account. After closing the last dialog, we should still see the properties dialog for our file (the original dialog view, the second screen-shot in this series). Select the "Administrators" account, and click "Edit."

Give our "Administrators" account full control by enabling the checkboxes.

When you click "Apply" to apply these changes, the following prompt should be displayed. Click "Yes" to apply these changes to to grant full control to the administrator account.

At this point, the ownership of this file should have changed from the default "TrustedInstaller," to the "Administrators" group. For me, I can now overwrite this notepad.exe file with the more useful notepad2.exe.

I hope this article helps. Until Vista and Longhorn become second-nature, I know I will be referencing this.

What happened to my ReSharper type completion functionality? "Alt+enter" recently stopped showing up for me. I checked around everywhere looking for a setting that enables type completion. The image below shows no ability to use a shortcut to provide type completion.

After looking around and finding nothing, finally a co-worker mentioned clicking "Apply" again. Sure enough that worked. If you come across this problem, access your ReSharper options, ReSharper -> Options -> Environment -> General. Then click "Apply" and see if that resolves it.

Finally, it is back, in all its glory.

My wife and I send each other articles to read on parenting, since we are both the proud parents of our first child, a six month old baby girl. As I was reading the latest article my wife emailed me, I could not help but draw similarities to caring for developers on an engineering team.

Now before everyone gets excited, the following blog post is not meant to compare developers to babies by any means. I am pointing out some similarities in how leaders should tend to and care for their development team, just as parents or caregivers we would care for a child. Basically, we invest time to nurture and care for them because we want them to be successful.

The article, What Every Baby Needs to Thrive, highlights eight steps every baby needs to thrive. For example, the first one is, "Show your love." What I have done is take this step and draw similarities to how this would apply to the success of a development team. This exercise can transcend outside of development teams to other teams, but this is a blog focused on engineering.

I have not altered the steps provided in the article. Each step and how they can be applied to a development team can be seen below.

Step 1. Show your love

How to Apply: Acknowledge them, give them praise, constructive criticism, tone of voice, genuinely care for their progress, listen to them, coach them, help them help themselves.

Step 2. Care for your child's basic needs

How to Apply: Give them the knowledge and tools necessary to be successful, provide training opportunities for them to take advantage. Rest them, don't just sprint them month after month without a break. A well rested employee is more productive. Reward them when they have done well, instruct them when they have not. Show them what it means to be a good developer. Provide a welcoming team atmosphere, lead the culture promoting it, and provide frequent feedback.

Step 3. Talk to your child

How to Apply: Communicate openly and frequently, listed and hear them, ask them how they are, what they are doing, learn how to help them.

Step 4. Read to your child

How to Apply: Present to them, demonstrate and show them what you know, teach them skills that they will learn to admire and achieve so they may help themselves.

Step 5. Stimulate all his senses

How to Apply: Give them a broad range of experiences, don't just stick them in one technology or one facet of a project. Teach them all the parts of the project. See where there interests and skills develop. Groom them for future development in several areas.

Step 6. Encourage new challenges

How to Apply: Encourage them to raise their bar higher, step out of their comfort zone, teach a class, present a session, develop leadership skills. Teach them to teach others. Train the trainer.

Step 7. Take care of yourself

How to Apply: Lead by example, if you are not well rested (on top of your game), it becomes difficult to instill this sense amongst the team. Continue your education to grow and lead. Find time for yourself away from the team.

Step 8. Find good childcare

How to Apply: Develop a good team atmosphere. Who do you want your developers to emulate? Find mentors, get them training, pay for good speakers, find the right conventions. Encourage them to care for each other, to present to each other, to respect one another.

Obviously employees are different than family, but there are similarities. You cannot fire family, and you do not interview them before they arrive (in some cases I guess). Like leading a horse to water, you can only do so much for you developers to be successful. It is ultimately up to them to take advantage of the situation. If your horses refuse to drink and it hurts the team, then turn them into glue.

Thanks to my wife for sending me this article. My guess is that she never would have thought I would apply it to a development team. This agrees nicely with the sprint board we keep in the house for chores and duties. That reminds, we are overdue for a sprint planning session for the month of April.

The NHibernate FAQ
Craig Neuwirt
Hibernating Rhinos