I attended my second local MSDN Event this year and while I was more interested in last month's agenda of new features in Visual Studio 2008, this month's session on IIS 7, ASP.NET 2.0 Application Services, and Security was pretty informative and touched on a few things I've been curious about, so they're always worthwhile to go even if the main agenda's subject doesn't interest you too much.  If you're in the Fort Worth, TX area, I highly recommend you attend these events so that Microsoft will know that hey, there's .NET developers west of Dallas too!  Besides, Zain is always good for a few laughs as well and he also gave a shout out to one of my favorite books, Head First Design Patterns.

If you're not familiar with the Head First series, they take a different tack than most other books in getting you to actually LEARN the material.  Using a combination of humor, casual conversational tone, and offbeat images, they're not as dry as most other technical books and so you're not forced to focus all your energy trying to concentrate on the material, it comes easily.

Since we're on the topic of books, another book I enjoyed was Applying Domain-Driven Design and Patterns: With Examples in C# and .NET.  This was my first foray into Domain Driven Design (DDD) and was a pretty big paradigm shift for me.  My mindset had always been that "data is king" and so I had been developing from the database up.  While most of the apps I do nowadays don't necessarily need the complexity of a full domain model, I find alot of the DDD concepts beneficial and so I try to incorporate some of the DDD practices such as focusing on persistent ignorant objects so I can delay working with the persistence layer as long as possible and using a ubiquitous language.  I also just recently bought a copy of the Eric Evan's original DDD tome I'm hoping to start reading soon.  The C# book I thought was a little light on the details of the why's and how's of DDD, so I wanted to go straight to the source.

I think I've rambled long enough, I'll end my post with a link to a great series of articles : Foundations of Programming.  Karl pretty much nails it on the head in the first article and all the things he mentions are things I've been incorporating into my own development practices the past few years.  These are concepts that transcend languages and make you a better "programmer" period, and not just a better ".NET programmer".

As I mentioned in a previous post, I've been wanting to use RhinoMocks for a while now but somehow never got around to it.  I finally converted some of my existing tests for a project from using hand coded mock classes to RhinoMocks and I'll never go back!

I use the Model View Presenter design pattern (or probably to be more accurate the Supervising Controller pattern) for my ASP.NET applications to promote testability (it's really a poor man's fix until the ASP.NET MVC framework goes RTM) . 

So to illustrate how much rosier life will be now that RhinoMocks has entered my life, here's a before and after of the unit test (code has been genericized).  The gist of the application is a web page that consumes a collection of Employee objects (either to use as a dropdown list or to bind to a GridView) and also needs to know if the current user has edit permissions.

First the code common to both unit tests (interfaces and presenter class):

   1: public interface IModel

   2: {

   3:     bool GetCanUserEdit(string name);

   4:     IList<Employee> GetEmployees();

   5: }

   6:  

   7: public interface IView

   8: {

   9:     bool CanUserEdit { set; }

  10:     IList<Employee> Employees { set; }

  11:     string UserName { get; }

  12: }

  13:  

  14: public class Presenter

  15: {

  16:     private IView view;

  17:     private IModel model;

  18:  

  19:     public Presenter(IView view, IModel model)

  20:     {

  21:         this.view = view;

  22:         this.model = model;

  23:     }

  24:  

  25:     public void InitializeView()

  26:     {

  27:         view.CanUserEdit = model.GetCanUserEdit(view.UserName);

  28:         view.Employees = model.GetEmployees();

  29:     }

  30: }

Now the code for my original test fixture and the corresponding mock classes I had to hand write:

   1: [TestFixture]

   2: public class OldSchoolPresenterTestFixture

   3: {

   4:     [Test]

   5:     public void ShouldInitalizeViewWithPermissionsAndListData()

   6:     {

   7:         // Create mock classes

   8:         MockView view = new MockView();

   9:         MockModel model = new MockModel();

  10:         

  11:         // Setup mock model with fake data

  12:         model.CanUserEdit = true;

  13:  

  14:         List<Employee> testEmployees = new List<Employee>();

  15:         testEmployees.Add(new Employee());

  16:         model.Employees = testEmployees;

  17:  

  18:         Presenter presenter = new Presenter(view, model);

  19:  

  20:         presenter.InitializeView();

  21:  

  22:         Assert.IsTrue(view.CanUserEdit);

  23:         Assert.IsTrue(view.Employees.Count > 0);

  24:     }

  25: }

  26:  

  27: internal class MockModel : IModel

  28: {

  29:     private bool canUserEdit;

  30:     private IList<Employee> employees;

  31:  

  32:     public bool GetCanUserEdit(string name)

  33:     {

  34:         return canUserEdit;

  35:     }

  36:  

  37:     public IList<Employee> GetEmployees()

  38:     {

  39:         return employees;

  40:     }

  41:  

  42:     public bool CanUserEdit

  43:     {

  44:         set { canUserEdit = value;}

  45:     }

  46:  

  47:     public List<Employee> Employees

  48:     {

  49:         set { employees = value; }

  50:     }

  51: }

  52:  

  53: internal class MockView : IView

  54: {

  55:     private bool canUserEdit;

  56:     private IList<Employee> employees;

  57:     private string userName;

  58:  

  59:     public bool CanUserEdit

  60:     {

  61:         get { return canUserEdit; }

  62:         set { canUserEdit = value; }

  63:     }

  64:  

  65:     public IList<Employee> Employees

  66:     {

  67:         get { return employees; }

  68:         set { employees = value; }

  69:     }

  70:  

  71:     public string UserName

  72:     {

  73:         get { return userName; }

  74:     }

  75: }

Yuck... that's a lot of extra code just to be able to get testability.  If interfaces change, all the mock classes will also need to be updated.  While refactoring tools like ReSharper make it less painful, it's still extra code you have to maintain.  It's also pretty mind numbing to write and it's not terribly exciting.

So now let's look at the spiffy new RhinoMocks version of the unit test!

   1: [TestFixture]

   2: public class NewSchoolPresenterTestFixture

   3: {

   4:     [Test]

   5:     public void ShouldInitalizeViewWithPermissionsAndListData()

   6:     {

   7:         // Create the mock classes dynamically, no more hand coding!!!

   8:         MockRepository mocks = new MockRepository();

   9:         IView view = mocks.CreateMock<IView>();

  10:         IModel model = mocks.CreateMock<IModel>();

  11:         

  12:         Presenter presenter = new Presenter(view, model);

  13:  

  14:         // Setup test data

  15:         string userName = "Bart.Simpson";

  16:         List<Employee> employees = new List<Employee>();

  17:         employees.Add(new Employee());

  18:         

  19:         // Setup what we expect to happen 

  20:         Expect.Call(view.UserName).Return(userName);

  21:         Expect.Call(model.GetCanUserEdit(userName)).Return(true);

  22:         Expect.Call(view.CanUserEdit = true);

  23:         Expect.Call(model.GetEmployees()).Return(employees);

  24:         Expect.Call(view.Employees = employees);

  25:  

  26:         mocks.ReplayAll();

  27:  

  28:         // Run the code and verify all our expectations happened

  29:         presenter.InitializeView();

  30:         mocks.VerifyAll();

  31:     }

  32: }

Much nicer!  I've cut the number of lines of total code to pass the unit test by 1/3 by not having to write the mock classes, and I don't have to worry about maintaining all that extra code!

I have to admit, at first glance it seems strange because I'm testing the behavior of the code and not the implementation.  But upon further review, what I'm really doing is separating concerns, a good thing!  I'm testing the presenter is doing what it needs to be doing (relaying information back and forth between the view and model) and nothing else.  I can write a unit test for a concrete IModel class that implements the database calls at a later time (and by the way I'm still trying to figure out the best way to run integration/unit tests against SQL Server).

Well, I hope my faithful readers (all 2 of you!) enjoyed my introductory foray into RhinoMocks and as I continue to use it more, I'll post more meatier and juicier examples.  I'm still giddy I don't have to hand code mock classes!

I recently moved to Keller, Texas which is actually the first city ever to get Verizon's fiber optic service, FIOS.  My street originally wasn't wired for it, so I had to make do with 10mb DSL with a local company.  When Verizon notified me FIOS was finally available for my house, I jumped on it.  I've now had it for a couple of months and I haven't had a single outage, and check out my speed below!

The reason I bring this up is because I noticed Scott Hanselman just posted about getting FIOS tv and in an earlier post, he actually ditches his DD-WRT router and goes with the Actiontec router Verizon provides.  Like him, I refused to give up my Buffalo router flashed with DD-WRT but a couple of weeks ago, I replaced DD-WRT with Tomato because I was having wireless connection issues in my living room.  While the signal remained strong according to Windows XP, my throughput was less than 1mb.  I replaced DD-WRT with Tomato hoping it would solve the issues, and it did. 

But after I read Scott's blog, I decided to give the Actiontec a try and it actually surprised me with the amount of features available.  Everything I used DD-WRT for (QoS primarily), the Actiontec provided.  Not only does it seem faster than the Buffalo with DD-WRT/Tomato firmware, the wireless signal seems to be alot stronger as well with nary a deadspot in my living room.

So I guess the moral of this story (aside from showing off my swanky broadband connection) is don't be a software/hardware snob.  My initial resistance to using the Actiontec was because I figured it was generic junk that ISP's provide for their users, and that the freeware DD-WRT and Tomato firmwares (with source code available) were superior products.  This is akin to only using open source .NET software tools and refusing to use Microsoft provided ones even if maybe... just maybe... the Microsoft version may be better! 

I thought I'd write up a quick post about my background and why I'm starting this blog.

I first got introduced to agile development methodologies a couple of years ago by a new co-worker.  I still remember him explaining this new fangled test driven development, design patterns, iterative development, paired programming, and I was thinking "Huh?".  Fast forward a few months later and I had drunk the Kool Aid and was converted for good.  Since then I've been consuming as much OOP and agile development information as possible.

I now work as part of a small development team where I have the opportunity to guide us to do things the Right Way™ and help shape the team into a top notch band of agile ninja coders.   The previous regime was a typical chaotic cowboy coding environment.  I've been here a little bit less than 3 months and we've already setup a development lab, started doing weekly iterations, created a story board with story and task cards, engaged in some paired programming, and had our first try at Planning Poker.

To be sure, there's alot more left to do but I really like the steps we are taking.  So this blog will serve as a historical document of our journey so that others may learn from our trials and tribulations.

I attended my first Fort Worth .NET User Group (FWDNUG) meeting last night which featured an ASP.NET MVC presentation by Ben Scheirman. I've been on the FWDNUG mailing list for a couple of years but had never attended a meeting until yesterday.  All I can say is I've been missing out!  The presentation was highly informative and touched on some other topics that the typical .NET developer isn't exposed to, ie. mocking with RhinoMocks and using Inversion of Control with Windsor.

I've been wanting to use RhinoMocks for a while (I've been handcoding my mock classes so far, yes... sad) and seeing it being used up close has convinced me to make the leap.  So expect to see more posts about my adventures in RhinoMocks.

So I finally decided to do something with the swanky domain name I registered a few months ago and start up a software development blog like all the other cool kids. 

I ended up hosting for an insanely cheap price at reliablesite.net (I'm not expecting much traffic yet so we'll see if they live up to their name if this ever takes off!) and am currently using BlogEngine.NET as my ASP.NET based blogging engine.  I considered Das Blog and SubText but BlogEngine.NET seemed to be the simplest to implement, and since I don't know if I'm even going to devote alot of time to this blog, I figure I'd KISS! 

I do feel dirty though since I downloaded the source code for all three blog engines and BlogEngine.NET was the only one without unit tests... this blog definitely is off to an ironic start!