Re-Starting a Blog for the Very Third Time

How to pick the right font 

The better part of year has passed since I bothered to blog. Shameful. Writing is important for so many reasons; the most important to me is that you don't really know something until you've tried to explain or teach it to someone else. In the case of my blog, that might be a conversation to myself, but that is beside the point. I need a fresh start.

Starting a new blog requires a lot of decisions to be made. First, I'm a coder, a programmer, a writer of software. Do I roll my own blog engine? It's easy. The first Rails cast I ever saw shows DHH spitting out one in 15 minutes. It'd be easy and relatively fun. I could use Rails. I could use Nancy. I could use Microsoft ASP.NET MVC. The options are limitless, when you have the source code.

The downside to that is that Blogger is a really nice platform. I also have a small number of posts tied to the Blogspot url. Some of them don't completely suck. I was even mentioned by Phil Haack once. It'd be sort of lame losing the Blogspot address. So I decided to stick with Blogger. I might revisit that decision. However, I did determine that a redesign was essential.

I'm not a good designer (yet!). So I decided I'd do the next best thing, which is to keep the design simple. It isn't as good Hanselman's redesign, but I'm happy with it. One day, I'll either hire a designer or gain enough skill to pull a beautiful design like this off. There are some tweaks I still need to make with column layout, background images, and general layout. Baby steps.

One element I did spend some time on was the typeface. I had recently listened to This Developer's Life: Typo that reminded me how important layout and typeface can be to a design. The pod cast features a great interview, as always, with Bill Hill. He's always inspirational to listen to. I chose the serif-font Palatino, as a variant of Georgia. Mainly because I wanted to be a little different from all the sans-serif/Arial blogs out there. Check out CSS Font Stacks to assist you in picking the right font stack. It's appealing, to me, but then again I may have Comic Sans'd it.

Creating a NuGet Package

NuGet is a package manager for .NET that was recently released by Microsoft as a CTP. This library is similar to gems or cpan or similar libraries in other languages. I decided to try my hand at creating a HelloWorld package.

First I needed a package. My original idea was to create something useful enough to contribute to the public feed of NuGet packages. I started by creating the Shelf library, which is a small set of extension methods. Notably, I created the Each<T> method that extends IEnumerable<T>. It takes an Action<T>, invoking the action for every item in the sequence. It's a trivial and small library at the moment, but imagine it is something useful and complicated. The library itself isn’t the point here.

Create the package “manifest” (my term).

<package>
  <metadata>
    <id>shelf</id>
    <version>2010.1203.2330.42313</version>
    <authors>Kwak</authors>
    <description>Shelf is a library of common extension methods</description>
    <language>en-US</language>
  </metadata>
  <files>
    <file src="Shelf\bin\Release\*.dll" target="lib" />
    <file src="Shelf\bin\Release\*.pdb" target="lib" />
  </files>
</package>

The documentation says the files element is optional. It seems I didn’t discover the “convention” they were speaking about in the documentation. I needed it.

I ran the command-line tool nuget.exe passing it the pack command and the package manifest. It spat out the packaged file (BTW, you can use just about any zip tool to browse the contents of the package).

There are couple of different ways to deploy the package. Submitting your package for inclusion in the public feed is one option. You can put the file on any accessible URL. The NuGet source includes a “Server” utility. Until my library grows to a point where it’s not laughably trivial, I opted for just putting it in my file system and pointing the package manager to folder. Phil Haack has a great post explaining the deployment options.

So with my package (shelf.2010.1203.2330.42313.nupkg) located in my local packages folder, anytime I want to make use of the shelf library, I simply go to the package manager console and type

Install-Package shelf

NuGet goes off, makes sure it has the latest package, adds the package folder to my source if it doesn't already exist, downloads (copies) the assembly, and adds the reference to the project.

Here are some of the references, I’ve found useful:

• Scott Hanselman’s walkthrough.
• Phil Haack’s aforementioned post on deployment options.
• The NuGet Documentation and CodePlex site.

Conclusion: Piece of cake and terribly useful for consumers of your library.

Mercurial .hgignore File for .NET Projects

I’m currently using Mercurial, and find myself starting out with this as a base .hgignore file.

glob:bin/*
glob:TestResults/*
glob:obj/*
glob:*.suo
glob:*.user

Configuring SpecFlow to Work with MSTest

Add a reference to TechTalk.SpecFlow and then put this in an App.config file of the MSTest project:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow"/>
  </configSections>

  <specFlow>
    <unitTestProvider name="MsTest" />
  </specFlow>
</configuration>

Visual Studio 2010 Styles

If you haven’t checked out Studio Styles yet, please go do so. An improved version of the old Is Your IDE Hot or Not (the old site seems to have fallen into disrepair). Studio Styles is one of those well-executed, brilliant ideas, that has you saying, “Why didn’t I think of that?”

I spent some time creating a version of my favorite color scheme. It’s called Distant Stormy Shore.

It’s based on the work by Thomas Restrepo on the Distant Shores color scheme.

Please download and give me a “Hot” rating if you like it.

Yet Another FizzBuzz

As interesting as I could make it.

private static string FizzBuzz()
    {
      var fizzBuzzMap = 
        Enumerable
          .Range(1, 100)
          .Select(num => MapToFizzBuzz(num));

      return String.Join("\n", fizzBuzzMap.ToArray());
    }

    private static string MapToFizzBuzz(int num)
    {
      if (num % 15 == 0)
        return "FizzBuzz";
      if (num % 5 == 0)
        return "Buzz";
      if (num % 3 == 0)
        return "Fizz";
      return num.ToString();
    }

Before, I lost interest.

Dependency Injection and the Controller Factory in ASP.NET MVC

This is a re-post from the older blog. I’m retiring that blog address and this is one of those posts that I refer to when setting up a new project.

Using an IoC is one of those things that can take a time or two to understand where it fits in and how it’s useful. Once you cross the energy barrier, it’s a color in your palette you can’t imagine missing.

Imagine having a QuestionController that takes an interface called DomainRepository. The job of any concrete implementation of the DomainRepository will be to fetch various domain entities from a backing store.

public class QuestionController : Controller
{

  private DomainRepository _repository;

  public QuestionController(
	DomainRepository repository)
  {
    _repository = repository;
  }

  public ActionResult Index()
  {
    ViewData.Model = _repository.AllQuestions;
    return View();
  }

}

This is a perfect place to use an IoC container to provide build a concrete implementation and all of it's dependencies

The gotcha is that ASP.NET MVC, by default, requires its controllers to have default constructors. Luckily, ASP.NET MVC uses a ControllerBuilder to instantiate the controllers using a ControllerFactory. This is an extension point where we can provider our own factory, one that uses the IoC of choice to resolve the controller.

You'll need a class for the new controller factory. This is a minimal implementation that doesn't make use of the MVC 2 requestContext parameter

public class StructureMapControllerFactory : DefaultControllerFactory
{
  protected override IController GetControllerInstance(
	RequestContext requestContext, 
        Type controllerType)
  {
    return 
	ObjectFactory
	.GetInstance(controllerType) as IController;
  }

}

In your bootstrapper, or in the Global.asax.cs, make the ControllerBuilder use the new controller factory

ControllerBuilder.Current
	.SetControllerFactory(
          new StructureMapControllerFactory());

Also, in the bootstrapper, or in the Global.asax, setup your container. This is using StructureMap's 2.6.1 syntax

ObjectFactory.Initialize(factory =>
{
  factory
    .For<DomainRepository>()
    .Use<NoSqlDomainRepository>();
});

These are the minimal steps required to get the ASP.NET MVC web application ready for use with an IoC (e.g., StructureMap).