Preview: New Blog Theme

I've found a way to get a little extra time each day by chewing my food fewer times. Do you realize how much time you waste by chewing? I've cut the number of times I chew in half. Aside from the occasional choking nearly to death, it's worked great. I have loads of extra seconds everyday! 

One thing I've been doing with all that extra time is making a custom theme for this blog to match the main site. It's not done, but I would appreciate early feed back. Please compare the main side to the blog preview.

-j

Rob Conery nails it

I respect Rob Conery. He does an excellent job with his screencasts, has good blog posts, and is generally a good/helpful guy. He nails ASP.Net webforms and mvc in the same post. To be clear he, and myself, are pro-MVC. Check out my MVC Argument For Humans post if you don't believe me.

So go and read it. Here is the link again if you missed it earlier.

Scott Guthrie coming to Phoenix on May 26th 2009

Scott Guthrie is coming to Phoenix again this year. The event is on May 26, 2009 from 8am to 6pm. It's a Tuesday. I have to say the Gu is a great presenter; and there's a bonus. Glenn Block will also be presenting. He's one of the guys behind MEF. You should go learn about Glenn and MEF right now! Although I'm not familiar with him, Jaime Rodriguez is also presenting. I'm going to go read his blog myself.

The event page is here.

Barring major catastrophe, I will be there. It's always a great event. HIGHLY recommended.

UPDATE: It is free!

-j

Last Play: Null - ESPN Gamecast

I pulled up ESPN's Gamecast to follow the Cleveland Cavs game while I worked tonight. I happened to flip over to the window in time to see and capture this picture. This is fairly off topic but still, its an obvious programming error. I'd have to guess there was a null or empty field in the last update message. I typically follow with ESPN Gamecast and its gotten to be a pretty reliable service. Wasn't always, but haven't had problems with it in a year or more.

You can see a bigger version by clicking on the image.

-j

TestDriven.Net 2.20 Beta

My single most favorite Visual Studio AddIn has been updated. TestDriven.Net 2.20 beta is now available. Get it. Read about it, and you'll see why given my love for unit testing.

Updated to BlogEngine.Net 1.5

Just a technical note, we've updated to BlogEngine.Net v1.5.  Everything appears to have gone smoothly, but please let us know if you find any problems.

Interfaces For Humans

Everyone in the developed world knows what a hammer is and how it looks. We can all operate one to varying degrees regardless of the color, shape variation, or size. You swing it. It pounds nails or breaks drywall/etc. It hurts your finger when you miss and hit your hand by mistake. Pretty standard and easy to understand.

You should try to view your code in the same way. You want it to be easy to use, easy to maintain, and very understandable by the right audience. Using an interface to define what it "looks like" is how to do that. Instead of saying "this is a hammer", you are saying "this is a hammer class." That tells the user that he can swing, nail things, break things, and hurt fingers.

public interface IHammer
{
void Swing();
void Nail();
void Break();
void OwwThatReallyHurts();
}

That is an example of an interface in c# to tell us what a hammer class would look like.  It has methods (aka actions) for swinging, nailing, breaking, and getting your fingers hurt. But I don't recommend the last one. At all. So, OK, great but what good does that do? Well, we now know exactly what something does and how to use it no matter what color/shape/size it is. So let's make a couple hammers. Please notice the use of ": IHammer" in the following code, which is saying this is a hammer.

public class YellowHammer : IHammer
{
   private int swingCount = 0;
 
   public void Swing()
   {
      swingCount++; //just tracking how many times you swing this
   }
 
   public void Nail()
   {
      //thud
   }
 
   public void Break()
   {
      //bam
   }
 
   public void OwwThatReallyHurts()
   {
      throw new HostpitalException("you need reconstructive surgery");
   }
}
 
public class PlasticHammer : IHammer
{
   
private int swingCount = 0;
 
   public void Swing()
   {
      swingCount++; //just tracking how many times you swing this
 
      if(swingCount>10) throw new TopOfHammerFallsOffException("you cant really use plastic hammers, buddy!");
   }
 
   public void Nail()
   {
      //plink
   }
 
   public void Break()
   {
      //tap
   }
 
   public void OwwThatReallyHurts()
   {
      throw new PansyException("it doesnt hurt that much. its just a plastic kids toy.");
   }
 
}

So now you have two hammers, and you know exactly how to user them. BUT. They don't behave exactly the same. One is plastic and one is a nice, solid yellow hammer. The plastic one falls apart if you swing it too many times, and the metal leaves a mark if you hit your fingers. At this point, its all obvious to me that this is good and useful, but I don't know that everyone sees it that way. Since the goal is to explain it simply and clearly, Let's look an example of how to use it.

IHammer hammerInstance = new YellowHammer();

hammerInstance.Swing();
 
IHammer hammerInstance = new PlasticHammer();
hammerInstance.Swing();

You see in the above code you can do the same thing with both hammers. It doesn't matter if one is yellow and one is plastic. Now let's get a hammer without paying attention to what kind, and then use it.

IHammer hammerInstance = MyHammerStore.GetNewHammer();
hammerInstance.Swing();

The magical MyHammerStore gave us a hammer. Since we know how to use a hammer, we just use it. It just works. If all you care about it swinging the hammer, then you don't care what it looks like; just that you can swing it. This is an oversimplified example which hopefully makes the principle easy to understand. How, why, and when to use it would take more time to explain. To give you an idea of a real-world-like scenario, imagine you are writing a school grading application. You will want to save a grade for a student. Your code might look a little like this:

IStudent student = MyClass.GetStudent(studentID);
student.SaveGrade("history class", "A+");

You don't care what the student class looks like, just that you can save the grade on the student record. You don't care where or how its saved; only that it is saved and you can look it up later. Simple. Easy to understand and use. Done.

references

• http://msdn.microsoft.com/en-us/library/87d83y5b(VS.80).aspx 
• http://msdn.microsoft.com/en-us/library/aa260635(VS.60).aspx

Guess What I'm Reading

So I mentioned on Twitter that I was reading Ayende's DSL with Boo book, and I recommend it. I thought it fair to mention what I'm reading now that I've finished it. Without looking at the picture to the left, can anyone guess? Hint: It's related to the work I'm currently doing with an existing application. Yeah, you guessed it. Brownfield Application Development in .Net by Kyle Baley and Don Belcham. How'd you know? I'm really busy so I'm not making quick progress; even my leisure reading is on hold.

I'm not sure, but I'm guessing that one or both of the authors have worked with or trained with JP Boodhoo because he's already been mentioned. I like that it's putting together a reasonable argument why Brownfield isn't that bad. Even lays outs some reasons why its actually a good situation. The first chapter is free so you can sample it yourself.  Also, Manning emails coupons all the time so let me know if you're thinking of buying. 

-j 

TDD And Design Observation

This isn't part of the 'for humans" series; it's just an observation from my current work. I'm in the middle of some brownfield development (enhancing or adding to a program that already exists and is actively developed). So the application I'm working with doesn't really support unit testing. All the pieces are too tightly tied together, but we are working on it as we go. For example, I just added some code that looks a little like this:

[code:c#]

public interface IState
{
  bool IsConfigured {get;}
  void ClearState();
}

[/code]

 Using this interface I can test some of the code that uses it. It's nice because my unit tests tell me if it works and I don't have to run the whole app. Plus I get the benefit of being able to work on whatever part I want to: middle layer, UI, data layer. It's nice to be free.

However, I have to write lots of code that goes right into the rest of the app that I can't test easily. Something like this:

[code:c#]

public class Import
{
  void ImportStuff ()
  {
    IState state = GetTheCurrentState();
    if(state.IsConfigured) RunImport();
  }
}

[/code]

With that I have to start the whole app and test it manually, which also means I have to build some rudimentary UI to execute that code. This is called top-down design when you are basically writing UI and top level features before writing middle layer, business rules, and data layer code. It doesn't lend itself to a good design and maintainability. For whatever reason, it just occured to me that developing that way tends to force you into it, which also leads to more pain points in the application.

Test Driven Design definitely has the advantage here. More Freedom, more fun, better code. Trust me.

-j