Quite often there is a fear that surrounds open source tools and frameworks.  For most shops the deciding factor against open source software is the apparent "risk" that is associated with a framework/tool that is not attached to any business entity.

In this post I want to share an interaction that occurred this last weekend to show you that the open source ecosystem is alive and very healthy.  And while I won't go so far as to say the "risk" doesn't exist (you have to come to that conclusion on your time when your own fears are allayed) I do hope that this post puts some of those fears to rest.

Saturday morning before I went off to work there was a question posted to the RhinoMocks mailing list (for those who don't know RhinoMocks is an open source mocking framework).  Before the end of the day the problem was resolved to a satisfactory conclusion.  The "solution" (I put in quotes because there appears to be a bug but at least now we know there is a bug...hence "solution").  The result is not as important as the events that transpired to reach that conclusion below is the timeline.

12:22 AM - Kenneth posts the problem he is encountering

6:53 AM - I respond on the mailing list back to Kenneth with my findings and let him know that I will get some experts in DynamicProxy involved

6:56 AM - I enlisted the help of Krzysztof Kozmic on twitter (Krzysztof is a committer on DynamicProxy by Castle as has a great tutorial series on Dynamic Proxy)

8:38 AM - Fellow Devlicious blogger Tuna Toksoz (also a committer on the Castle project) hopped on the case and reported his findings

9:22 AM - Krzysztof responds to Tuna's findings reporting back on the root cause

10:23 AM - Kenneth reported back with feedback of Tuna's fix

Ultimately, as I mentioned earlier the fix was that it was found that RhinoMocks "relies on the buggy behavior, hence the error" (Krzysztof's words).  Again the result here isn't what is important but rather the journey.  Often people fear the support ecosystem around open source software but the exchange above and the players involved should give you some bit of confidence in the support of open source.  It is worth pointing out that all of this happened on a Saturday, something you'd pay a premium for in a closed source model.

Whatever your roll in the software world is, one aspect you have to consider when choosing any solution is risk.  The traditional thought has been that with commercial software the support would be better when backed by a reputable name.  I think the exchange showcased above demonstrates that support for open source software can compete (and potentially surpass) support that any commercial piece of software could offer.  Keep that in mind the next time you are evaluating commercial software versus open source software.

After two successful iterations of the Iowa Code Camp it only seems fitting to have a third.  This third version will held May 2nd in Cedar Rapids, Iowa at Kirkwood Community College continuing the trend that Iowa Code Camp will move to serve its constituents all over the state.  I'd like to thank my former employer Geonetric for coming through in the clutch and helping out with securing/sponsoring a great location.

I want to echo the call for speakers that fellow coordinator Greg Wilson recently put out:

NOTE:  I do apologize that due to logistical issues with securing the location and date this call for speakers is coming much later than normal.  We, as leaders, have been working since early January on several possible locations/dates and just received confirmation on the final facility yesterday.  Please help us in getting the word out to as many potential speakers as possible as fast as possible.

Topic ideas:

We are looking for 4 basic types of sessions:

1)  We are welcoming non-.NET centric topics.  Hopefully, we can have another full track of "alternative" stuff.  Java, 'nix, Mac, Drupal, open source, etc.

2)  Beginning 100-level sessions targeted towards students and/or developers from another technology.  Things like:  LAMP Programming 101, Getting started in the .NET world, What college doesn't teach you, Developing Java with Eclipse 101, User Interfaces 101

3)  Nice, meaty .NET sessions - The core of any code camp

4)  Audience driven sessions.  We are planning to have various format sessions of experts that the community can ask questions to.   We need volunteers to be in the sessions as "experts".  We have various discussion groups (fishbowl, open topics, etc.) and may try some 1 on 1 help-them-with-their-code type of stuff.

I (greg@solidDONTSPAMMErockstable.com) need to know as soon as reasonable who is interested in speaking.  Please let me know if you are definite or tentative, and what you intend to speak on.  (Title/Description/Bio)  I will be making the final schedule of speakers and tracks in mid-April.  we already have more than 10 speakers committed, so please respond soon.  If we have more speakers than sessions, we will work (per topic) on a first come/first served basis.

Like most code camps this camp will be free to attendees.  It is through generous sponsorship from companies and vendors that make these code camps possible. If you are interested in sponsoring an aspect of the code camp please let me know ASAP and we can see what can be worked out.

If you are within a few hours drive, I encourage you to attend. It should be a great day of learning and exploring together. I hope to meet some of the readers of this blog at the camp.  Enough talk, go register now before all the spots fill up.

I don't want to be a wet blanket, but someone's got to put a stop to the IoC love fest going on out there.  An Inversion of Control (IoC) container , for those of you were aren't yet familiar, allows you to retrieve instances of objects at runtime.  A relatively common solution to a common problem. In the .NET world there is no lack of choices of IoC containers:

• Castle's Winsdor/MicroKernel
• StructureMap
• Spring.NET
• AutoFac
• Ninject
• Unity
• Funq

(I won't go fully into IoC, but If you'd like more resource you can read Martin Fowler's article on the subject or post specific questions in the comments or contact me through.  Read on, there is value here in this post for you.)

Let me state clearly now, IoC containers are a means to an end and NOT a feature of your application. The goal is to have loosely coupled applications, IoC containers help get you there, but you can absolutely have a loosely coupled application without an IoC container (see the Gang of Four creational patterns).

Occasionally I'll hear some comment about IoC and how great a certain container is or how an application would be so much better if another, sexier, container was used.  Here are some recent tweets that illustrate:

• Man i love #StructureMap, always finding new things i can do, and have fun doing them
• really need to look at structuremap, but we''ve invested a lot into castle with our own facilities/resolvers/etc
• Ninject is da bomb!
• Switched from Windsor MicroKernel to Ninject in 10KLOC project in < 1 hour by creating a little proxy. Now to complete the conversion.
• It is a talk on Castle Windsor so i guess Ninject will not do.
• Can't imagine why somebody would use Ninject beside the fact that it's PURE AND UTTER AWESOME. Yeah! Ninject FTW.

Some of the statements above are probably innocuous, but some rub me slightly the wrong way.  Specifically the two comments above about switching from one container to another. There are probably times when the choice of one container over another makes sense, but I would bet that these scenarios are the exception and not the rule.

Choosing one container over another won't make your application a success, the architecture, or lack there of, will have far more of a say on your application than will your container choice. As yoda might say, "The container you choose does not a good app make".

Inspired by Bullshit Bingo I've created ALT.NET Bingo for you next ALT.NET conference, Twitter conversation, or blog reading session.  It's simple:

1. Get your card! http://is.gd/oA0A
2. Every time you hear a word, you mark it off.  If you get bingo you stand up and shout, "WATERFALL!!"

Happy playing!

If you're serious about testing before long you'll bump into the need to do some mocking. You can of course chose to write your own mocks but that is hardly time effective or trivial.  More than likely you'll want to use a framework, but how do you choose between the most popular options?

There's been some discussion on Twitter between myself and Daniel Cazzulino (@kzu), the creator of Moq (pronounced "Mock-you" or just "Mock"), a newer and popular .NET mocking, about mocking frameworks and what goes into choosing a mocking framework.  Daniel and I share a passion in mocking and by extension testing.  As the creator of Moq, I hold him in very high regard.

The discussion centered around some work that Andrew Kazyrevich has been doing recently.  Andrew is passionate about mocking.  As such he's created an open source project which compares the "big dawgs" of .NET mocking frameworks.  In his introductory post he explains the intent, which is message I support and want to help spread:

I've started a small open source project. It provides a unified set of tests written against Moq, NMock2, Rhino Mocks and Typemock Isolator, so that you can easily compare the frameworks and make an informed decision when picking one up.

In Andrew's most recent post he compares the execution time of the various frameworks.  My response on the RhinoMocks mailing list was terse but sincere:

Curious about speed in your tests, is the a first level concern when choosing a testing framework?

Daniel answered the question in a tweet:

IMO, API design, usability and expressiveness is a much more valuable comparison. #moq is not optimized for runtime perf.

To which I responded:

I would also throw in documentation, discoverability, and community into your equation.

So, fine blog reader, I have a question for you.  If you are using a mocking framework, what are your first-level concerns when you chose your framework?  For those who have yet to utilize a framework, what will you base your decision on when you do choose?

• Execution Speed
• API Design
• Usability
• Expressiveness
• Documentation
• Discoverability (possibly coincides with API Design)
• Community
• Other?

About a month ago Ayende posted his thoughts on the Maturity Model found in Open Source Projects.  Ayende's method for determining maturity is simple:

From my point of view, there is a very easy model for the maturity of an Open Source project. Look at the answers in the project's mailing list. The questions do no matter.

The model is simple, the higher the percentage of answers given by non project members, the more mature the project is.

I thought of this today when I came across the group info page for the RhinoMocks and saw the statistics for this month.  I was struck by how low on the list Ayende is:

You can see here that Ayende is tied for #5 on the list.  (Yes that's me on the list, but that's beside the point.)  In two polls (poll #1, poll #2) done over the last two years Roy Osherove has found RhinoMocks to be the #1 mocking framework of those polled.  I believe it is safe to say at this point that RhinoMocks is mature.  Measured with Ayende's method above and the data for this month's RhinoMocks group, I'd say that RhinoMocks is quite mature.  Ayende, the project creator/owner, sits at #5, which is pretty good.

Being familiar with open source I wanted to explore the maturity idea a bit further in depth on some other projects.  I posted on twitter a question about what open source projects people are using.  I wanted to take a few projects that are out there and explore a little bit to see if Ayende's assertion was in fact correct.

Other Projects

(Note: I am only exploring projects which have groups on Google.  These projects are in no particular order.)

jQuery

Members: 15487

(Note the absence of John Resig)

Castle Project

Members: 795

(Note the absence of Hamilton Verissimo)

NUnit

Members: 204

(While I would rank NUnit as "mature" Charlie Poole is the top answerer, which does not match Ayende's method)

MbUnit

Members: 353

(The findings in NUnit are not isolated, Jeff Brown, the MbUnit lead, is the top answerer)

NHibernate

Members: 1434

(This is where I started to douby my original hypothesis.  I did not expect to see project owners so high up on the list for such a seemingly mature project.  However NHibernate has a learning curve to it that may hinder would-be helpers from ever getting to the point where they can confidently answer questions regularly on the framework.)

FluentNHibernate

Members: 301

(Again project owner is top answer, by a long margin here).

StructureMap

Members: 209

(This one again surprised me a bit, especially given the work that I know Jeremy has done with documentation)

MvcContrib

Members: 302

TestDriven.NET

Member: 184

(Owner and creator, Jamie Cansdale, clearly the favorite)

Spark (Mvc View Engine)

Members: 83

(Owner and creator, Louis DeJardin, sits atop the #1 position)

Conclusion

When I started to dig, I wasn't sure what I find.  In many cases here the project owner is sitting right at or near the top of the top answerer list. Still, I think Ayende's original assertion is somewhat correct, however more has to be considered.  For example, a very well documented framework may lead to questions being asked that are rather difficult and therefore a larger number of questions answered by project founder may not really prove anything.  In other cases there may be a framework which is widely used but users don't feel compelled or comfortable answering questions for that group, for any number of reasons.  Ultimately any notion of what presumed before exploration was blasted to bits.

These projects above are not fringe projects, they're relatively mainstream for a certain sector of the .NET crowd.  If you haven't checked out any of these projects (admittedly I did not attempt to introduce them at all) I would encourage you do so.  One thing is for certain judging from the numbers above, these projects are viable, strong, and have a good following.

What do you think of the figures above?  Is Ayende right?  What strikes you about the projects and their discussion groups?

I have a penchant for taking "unsolvable" computer problems and getting to the bottom of them.  Often times this means I'm exploring the contents of a memory dump, that is, all of the data held in RAM of the process you're inspecting.  When I got started in this area about 2+ years ago I found Tess Fernandez's blog blog was a great resource.  In fact I've blogged about Tess and WinDBG before.  Her blog is one of my favorites when it comes to debugging and troubleshooting .NET applications (web or otherwise).

Debugging and troubleshooting is a skill I think too many developers lack.  By debugging and troubleshooting I don't mean stepping your way through code.  I mean, "Holy Crap our production app is failing and we don't know why," kind of debugging.  I think debugging is so valuable that I used to ask specific questions about it during interviews.  Too many times I could ask questions and see the developer try to answer, but often it was easy to see that if this was a real world scenario and not an interview question, they would have long ago thrown up their arms in defeat.  Computers are predictable, they don't "decide" anything, they're told what to do. If you understand that you're a step ahead of the average developer when it comes to debugging and troubleshooting.

Earlier this week DotNetRocks interviewed Tess Fernandez, an escalation engineer with Microsoft.  She's Tier 2 support. In other words, when you have a problem and call Microsoft you get Tier 1 support.  Then "when thinks get too sticky" she comes to the rescue. 

(I'd like to take a moment and have you consider the types of problems she gets.  The typical engineer will encounter many issues over their career.  I'm sure you've had them.  I've had them.  However, I typically will peruse articles, blog posts, and forum posts to find the answers I look for.  When faced with a problem, how many times have you ever resorted to calling Microsoft? Me? Zero. So imagine for a moment that you've not found an answer on any of the typical resources and have called Microsoft.  You're working with their Tier 1 support but they can't seem to help you.  It as it this point that you get a person like Tess.  She's smart.  She know .NET like I know Mt. Dew).

If you're sitting at a desk download the podcast and listen now:

• MP3: http://perseus.franklins.net/dotnetrocks_0427_tess_ferrandez.mp3
• WMA: http://perseus.franklins.net/dotnetrocks_0427_tess_ferrandez.wma
• WMA Lo-Fi: http://perseus.franklins.net/dotnetrocks_0427_tess_ferrandez_lo.wma
• iPod: http://perseus.franklins.net/dotnetrocks_0427_tess_ferrandez.m4b

A few months ago I blogged about how we're using the single responsibility principle in our application at work.  I'm going to make an effort here to write more "Real Life" content.  Often when a developer read principles or ideas in books, there is disconnect between what he/she is reading and how an implementation would look in the real world.  The goal of these "Real Life" scenarios is to show areas where I feel I've reaped some benefit from following a specific pattern or practice.  This does not mean that my implementation is the only way or always "book correct".  The goal is to act as a bridge (quite possibly a old rickety bridge) between the book knowledge and the real world.

Moving along...

One of the purported benefits of OOP has always been the abundant reuse of code.  However, in my experience many applications fail to realize any amount of reuse beyond copying and pasting between applications.  To really take advantage of code reuse you have to have small, concise pieces which you can rearrange in order to make a new behavior.  As a side note, and I want this be clear, many of the principles of good software development, ie. SOLID, go hand-in-hand.  You can't do one without the other and the benefits of one cannot be fully realized without the implementation of the others.  You'll notice that a few sentences ago I said "small, concise pieces".  A light bulb may have gone off in your head thinking "Single Responsibility Principle", and if it did, bonus points for you.

The key to code reuse is to build your components in a very focused way.  By doing so, you can add functionality by combining different pieces of you application.

Consider the following code used to authenticate a user into a site:

   1: protected void btnSubmit_Click(object sender, EventArgs e)

   2: {

   3:     string Username = Server.HtmlEncode(txtUsername.Text);

   4:     string Password = Server.HtmlEncode(txtPassword.Text);

   5:     int nUserID;

   6:  

   7:     if (Username != "" && Password != "")

   8:     {

   9:         using (SqlConnection cnn = new SqlConnection(connectionString))

  10:         {

  11:             using (SqlCommand cmd = cnn.CreateCommand())

  12:             {

  13:                 cmd.CommandText = "usp_Login";

  14:                 cmd.Parameters.AddWithValue("@Username", Username);

  15:                 cmd.Parameters.AddWithValue("@password", password);

  16:                 

  17:                 using(SqlDataReader reader = cmd.ExecuteReader())

  18:                 {

  19:                     if (reader.Read())

  20:                     {

  21:                         nUserId = Convert.ToInt32(reader[0]);    

  22:                     }

  23:                 }

  24:             }

  25:         }

  26:         

  27:         if (nUserID > 0)

  28:         {

  29:             // if the user has checked the box

  30:             // store his information so he doesn't have to log in again

  31:             if (cbRememberMe.Checked)

  32:                 FormsAuthentication.SetAuthCookie(nUserID.ToString(), true);

  33:             else

  34:                 FormsAuthentication.SetAuthCookie(nUserID.ToString(), false);

  35:  

  36:             BusinessLogicLayer.User objUser = new User(nUserID);

  37:  

  38:             // store session variables for later reference;

  39:             Session["UserID"] = nUserID;

  40:             Session["Username"] = objUser.Username;

  41:             Session["Password"] = objUser.Password;

  42:             Session["AccessLevel"] = objUser.AccessLevel;

  43:             Session["AccessLevelName"] = Enum.GetName(typeof(Utilities.AccessLevel),objUser.AccessLevel);

  44:  

  45:             Response.Redirect("~/admin/admin.aspx");

  46:         }

  47:         else

  48:         {

  49:             View = Views.Failed;

  50:         }

  51:     }

  52: }

While the code above is functional, it does way too much.  In this button click event there are:

• Call to database explicitly
• logic to set an authorization cookie
• Some session variables being set

Imagine for a moment that you now want to implement a new piece of functionality, user impersonation.  In order to accomplish this with the path of least resistance, which developers commonly take, would be to copy/paste all of the login logic to another UI event somewhere else in the site.  The issue copy/paste development is that any future change to the login logic has to be copied again or else the impersonation feature isn't really impersonating a users experience.  The insidious nature of copy/paste development is that while often it works, it creates a brittle application.

In a recent application we were wanting to add user impersonation.  Below is an example of an implementation of user impersonation.  Adding the feature to the application was gleefully simple.  The ease in adding impersonation was due entirely to the proper granularity in our application components.  Seriously, this is all the code it took:

   1: public ActionResult ImpersonateUser(int id)

   2: {

   3:     var authService = Container.Resolve<AuthService>();

   4:     var userRepository = Container.Resolve<UserRepository>();

   5:  

   6:     var userToImpersonate = userRepository.GetById(id);

   7:     if (userToImpersonate != null)

   8:     {

   9:         authService.SignIn(userToImpersonate);

  10:     }

  11:  

  12:     return RedirectToAction("Index", "Home");

  13: }

I did not know we were going to want user impersonation for this application when we started.  However because we developed the site with certain principles in mind, we were able to reuse pieces of code in ways not originally intended for added behavior.  As you can see from the code above, there are no "clever hacks" or tricks to get impersonation to work.  The beauty of the code above is that if we change the implementation of "SignIn(user)" all appropriate areas will follow the same rules since all areas use the same code.

As I'm closing I want to challenge those of you who have read this far to stop yourself the next time you find yourself copying code from one location to another.  Is there an abstraction or component you're overlooking?  Think about the long term and ask if you're really making the wisest decision for the long term health of your application.  It will be through this introspection and honesty that you'll find areas where you can write smaller component which will allow you to realize the oft spoken benefit in OOP of code reuse.