Development Central

Two of us at work have had issues installing Developer Express components in Visual Studio 2008. We get “Cannot Register Toolbox Items” and have to manually add the components to the toolbox.

Apparently this is a known issue caused by the drivers for the Microsoft wireless mouse, and has been since 2008 (we’re installing the new components).

I find it hard to believe that Microsoft would not have fixed this if it were affecting all tool vendors.

As an aside, the DevX install GAC’d both the Web and XPO components that I deselected from the install.

I finally broke down and joined Twitter. Since Steve Gibson joined, I figured it was past time.

@BillSorensen

Unity 2.0 is out, and has some very nice features. Two of the coolest are InjectionFactory and Automatic Factories. Nice code samples and tutorials exist, but here’s an example of combining the two features.

using System;
using Microsoft.Practices.Unity;

namespace Unity2Example
{
  class Program
  {
    static void Main()
    {
      using (var container = new UnityContainer())
      {
        container
          .RegisterType<IService, ConcreteService>(
            new InjectionFactory(c => ServiceFactory()));

        Model model = container.Resolve<Model>();

        Console.WriteLine("\nCalling Execute...");
        model.Execute();
        Console.WriteLine("\nCalling Execute...");
        model.Execute();
      }
    }

    static IService ServiceFactory()
    {
      Console.WriteLine("ServiceFactory called.");
      return new ConcreteService();
    }
  }

  interface IService
  {
    void MakeTheCall();
  }

  class ConcreteService : IService
  {
    public ConcreteService()
    {
      Console.WriteLine("ConcreteService instantiated.");
    }

    public void MakeTheCall()
    {
      Console.WriteLine(
        "ConcreteService makes the call.");
    }
  }

  class Model
  {
    public Model(Func<IService> serviceFinder)
    {
      Console.WriteLine("Model instantiated.");

      _serviceFinder = serviceFinder;
    }

    public void Execute()
    {
      _serviceFinder().MakeTheCall();
    }

    private readonly Func<IService> _serviceFinder;
  }
}

This will display:

Model instantiated.

Calling Execute...
ServiceFactory called.
ConcreteService instantiated.
ConcreteService makes the call.

Calling Execute...
ServiceFactory called.
ConcreteService instantiated.
ConcreteService makes the call.

Essentially we’re injecting a Service Locator into our model. My use case for this was injecting an object where the object reference could change (it needed to be deserialized at certain times). This way the dependent class would always get the most current version. It turned out I already had a class that could act as a Service Locator with the addition of an interface, so I injected that instead (it seemed simpler). I think this combination may come in useful someday, though.

In C# 4.0, you can return anonymous types from methods by using the dynamic keyword.

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine(GetHello().Name);  // Works.

        var one = GetHello();
        var two = GetHello();

        if (one.Equals(two))
        {
            Console.WriteLine("They are equal!");
            // Hit - they are equal!
        }
        else
        {
            Console.WriteLine("They are NOT equal.");
        }
    }

    static dynamic GetHello()
    {
        return new { Name = "Bob" };
    }
}

Note that Equals still works as expected.

I think this will make it possible to refactor long LINQ statements that use anonymous types, breaking them up into calls to private methods. (Clearly this could be abused as well.)

Iowa Code Camp is coming up fast!

There’s also a new .NET group starting up in Iowa City.

My Chumby arrived today. It’s a tiny computer with a touchscreen and wireless capabilities. Out of the box it can play Flash “widgets” and stream music.

The cool part is that it runs Linux and can be customized. You can develop Flash widgets for it, but there are plenty of other hacks. I’ve already SSH’d into it and created a simple CGI script for its built-in web server (in vi no less!).

I want to see if I can have it show the build status of our continuous integration server at work. While I may not leave it as a permanent fixture in the office, it would be a fun project.

Update - March 25, 2010

Our company requires the use of a proxy server to connect to the Internet. No exceptions. Chumby does not support proxy servers. End of story. :(

Update - March 29, 2010

The story picks up again. :) I found this post on the chumbysphere forum, and the advice from techgermz for no authentication worked. I did a chmod +x on the script just in case, but I’m not sure if that was necessary. I didn’t try streaming music.

I’m still having a problem where the screen goes blank and the menu button doesn’t work (but the internal web server still responds) after it’s online for a couple of hours at work. I’m currently testing it at home to see if I can replicate the issue on a non-proxied WiFi network.

Our continuous integration server was running slower than usual. One of our chief IT guys figured it out; the antivirus software installed on it was set to scan all folders. Every check out, every build, every copy apparently triggered a scan. While it’s a good idea to scan the final deployment folders, exclude the rest of the folders for a significant improvement in build times.

We use TeamCity, but this is applicable to any CI software.

Thanks to Eric and Rob for this tip!

Working Effectively with Legacy Code by Michael Feathers is a key resource for anyone who has to work with less-than-pleasant code. Feathers defines legacy code as code without tests, and his main goal is to get automated tests in place. The last section of the book contains a catalog of dependency-breaking techniques to make this possible.

Examples are in Java, C++, C and C# (plus one in Ruby). C and C++ developers will likely find this book invaluable, as a number of the techniques target challenges in those languages.

The book is very readable, due in large part to the friendly writing style of Mr. Feathers. Experienced developers will smile (or perhaps shudder in remembrance) at section names like “The Case of the Irritating Global Dependency.” Most code examples are short and to the point, although it does help if the reader is conversant in at least one C-style language.

The text suffers from the occasional typographical error, which I found distracting.

Developers who do not see value in automated tests may find little of interest in this book. If you don’t fall into that category, order your copy today!

With all the discussions of software craftsmanship and SOLID principles lately, I’d like to list the guidelines (not absolute rules!) I find most useful. These are listed in order of importance, highest to lowest.

Key Principles and Practices of Software Development

1. Never stop learning. Strive for continuous improvement everywhere. Be passionate about your profession.
2. Source control. Unless you like writing novels in the sand. Check in frequently (but compile and test first). Learn to use branching effectively.
3. DRY (Don’t Repeat Yourself). Remove duplication every chance you get.
4. OOP. Encapsulate. Resist the lure of procedural code. Favor composition over inheritance. Also be aware of alternatives, such as functional programming.
5. TDD (Test-driven development/design). Automated unit testing of classes in isolation is the most useful practice I have learned in the last ten years. Many other practices build on this. Test-first is a major aid to designing usable APIs (you’re eating your own dog food). TDD requires training and practice, but it is a skill worth acquiring.
6. Refactoring. Keep improving code quality. Requires tests to do properly. Make one small change at a time, then test. Best done with automated tools. Leave the “campground” cleaner than you found it.
7. Single Responsibility Principle (SRP). “…a class or module should have one, and only one, reason to change.” – Robert C. Martin, Clean Code. If you end up with small, focused methods and classes that are easy to understand, you’re probably doing it right.
8. Favor simplicity. The goal is not to show how clever you are.
9. Know your domain. Gather clear, testable requirements before you start coding. Get frequent feedback from customers, domain experts, and other developers. Do not “go dark.”
10. DI / IoC (Dependency Injection / Inversion of Control). Decouple your classes and make dependencies explicit to support SRP and testability. Interfaces are your friends.
11. Automate routine tasks. Continuous Integration (CI) is a great example of this. Computers excel at performing repetitive tasks; developers don’t.

Frequent Anti-patterns of Software Development

1. Technical Debt. You will not clean it up tomorrow. Do it right, now. Your future self will thank you. “You can make very short-term gains (days or weeks) by deliberately sacrificing quality, but the cost – human, business, and technical – is enormous.” – Kent Beck, Extreme Programming Explained
2. Premature Optimization. Favor maintainable code over fast code. If you must optimize, profile first to find the bottlenecks.
3. Copy and paste coding. Instead, DRY and refactor to remove duplication.
4. Deploying code that’s not in source control. If everything you need to build and debug the current production version isn’t checked in, you have a sword hanging over your head.
5. Not Invented Here. Avoid reinventing wheels. Rolling your own security/encryption code is particularly unwise. Also consider the source; copying and pasting untested code from the Internet carries risks. Finally, insure the solution is a good fit.
6. Zealotry. Few methodologies work for every team on every project. Consider other viewpoints. Be open to change. Even methodologies evolve.
7. Large classes and long methods. See Martin Fowler’s book Refactoring.
8. Singleton Pattern, static classes, and other forms of global data and/or tight coupling.
9. Not understanding exceptions. Error codes and null return values can lead to unstable code. “A good rule of thumb is that if a method does not do what its name suggests, it should be considered a method-level failure, resulting in an exception.” – Jason Clark, Cwalina & Abrams’ Framework Design Guidelines
10. Unit tests that are really integration tests. Not that there’s anything wrong with integration tests, but you need to understand the difference.
11. Excessive comments. If your code expresses intent, comments are often superfluous. And why comment out sections of code that’s under source control? Just delete it!
12. Using the wrong tool for the job, such as parsing HTML or XML with Regular Expressions. Also, dismissing a tool (such as Regular Expressions) entirely because some developers misuse it.

Remember that the right answer is often “it depends.” Almost everything is a trade-off. Use your own judgment. Think!

Thanks to everyone who reviewed my initial draft, and to Robert ("Uncle Bob") Martin for inspiration.

Comments are welcome.

I have a great deal of respect for “Uncle” Bob Martin. He’s done a tremendous amount to bring professionalism and craftsmanship to software development. I’ve heard him speak, and he definitely knows more than I do. But in this one small area of programming, I think he’s off-target. Decide for yourselves.

Dependency Injection Inversion (Uncle Bob)

Some of the follow-ups:

Poor use of DI versus need for DI (Jimmy Bogard)

Dependency Injection Inversion Rejection (Davy Brion)

Constructor over-injection anti-pattern (Jeffrey Palermo)

I agree most closely with Jimmy Bogard on this (Davy Brion makes some good points too). In Jeffrey Palermo’s post, I side with Alwin in his comment - why not just pass an interface to the factory?

EDIT: Here’s a nice rebuttal to Jeffrey Palermo’s post that discusses better alternatives to Alwin’s solution:

Rebuttal: Constructor over-injection anti-pattern (Mark Seemann)

EDIT: Another response to Uncle Bob:

Rejecting Dependency Injection Inversion (Ayende)

EDIT: And another related post by Mark Seemann:

Dependency Injection Inversion in .NET

EDIT: Yet another interesting post by Mr. Seemann (I think I’ll pick up his book):

Refactoring to Aggregate Services