Patrick Steele

Looking Forward to 2010

Yes, the first month of 2010 is almost gone and I'm just now getting around blogging about the past year and the year ahead.  I guess time management should be on my to-do list for this year? The CodeMash Website One of the coolest projects I've worked on in 2009 was the CodeMash website .  Brian Prince and Jim Holmes asked SRT if they wanted to help design a new website for CodeMash.  Brian will be the first to admit that he's an evangelist first, a developer second and a web developer third.  They gave us pretty much free reign to come up with a new idea as well as the freedom to implement the solution however we wanted. We worked with a Inner Circle Media to help plan the new look and feel of the site.  They deserve kudos for the new look.  On the back-end, I used ASP.NET MVC 1.0 along with SQL Server, Linq2SQL and Castle Windsor for my IoC container.  We also integrated with the existing Sharepoint installation for sponsor maintenance, news and session submissions.  User registration was all done in SQL. This was a great learning project.  Registering for a conference is usually a simple process (from the registrants standpoint).  On the back-end, when you're dealing with varying registration costs (based on the current date), discount codes, PayPal, and other things, it can get pretty complicated.  A large suite of unit tests helped us catch a lot of stuff in the beginning, but a few bugs slippped through.  Luckily, nothing major! I want to also thank fellow SRT developers Marina Fedner and Ben Barefield .  Marina helped me out on the user registration portion and Ben was responsible for the REST feed that we all used for our mobile CodeMash applications . Stepping Down from GANG After being involved with the Great Lakes Area .NET Users Group (GANG) for many, many years (webmaster, VP and this last year as President), I did not run for re-election.  There were some other projects I was taking on and last year's vice president David Giard was willing to take the reigns of the group.  Dave did an amazing job last year as VP and is continuing to do great things with GANG in 2010 .  I'll still be around to help out from time to time, but Dave is the man in charge now! VSM's C# Corner After helming Visual Studio Magazine's C# Corner for a number of years, Bill Wagner decided he wanted to devote his time to other things.  He offered my name as a possible successor!  I talked it over with him and VSM Editor in Chief Michael Desmond.  Everything fell into place and I'm now honored to be following in Bill's footsteps as a VSM author.  My first column has been published ( Interface-Based Programming in C# ) and I've got some positive feedback so far.  My next article is in-process and I have to have the first draft done by February 1st or I'll be on someone's naughty list (and it won't be Santa's!). Microsoft C# MVP I was pleasantly surprised on January 1st to receive an email from Microsoft telling me I've received an MVP award for my C# and community work in 2009.  Thanks to Microsoft and other community members I work closely with! 2010 Plans One of the big conferences for 2010, CodeMash , has already come and gone.  It was a great conference and you CAN NOT beat the price.  The amount of content and learning available is unheard of for the price you pay.  I'm already looking forward to CodeMash 2.0.1.1. In February, I'll be attending the MVP Summit in Redmond.  A great chance to get in touch with new technologies, talk with Microsoft reps and mix it up with other MVP's. Michael Eaton is already planning this year's Ann Arbor Give Camp .  I've offered my assistance again this year and will post more on this even as it gets closer. Speaking: I'd like to do more speaking this year.  While I usually get compliments on my presentations, I'm very hard on myself.  I may be a good speaker, but I want to be a great speaker.  That will come with practice.  I've got some idea's for presentations on topics I'm passionate about (specifically, Inversion of Control and Mocking). I'm really looking forward to 2010! Technorati Tags: SRT , MVP , CodeMash , 2010

Use Dependency Injection To Simplify Application Settings

We've all seen and written code that accesses data from our app.config or web.config file.  We'll throw some simple settings in there: <? xml version ="1.0" encoding ="utf-8" ? > < configuration > < appSettings > < add key ="enableLogging" value ="true" /> < add key ="startDate" value ="12/1/2010" /> < add key ="baseFee" value ="157.50" /> </ appSettings > </ configuration > And then we'll use the ConfigurationManager to pull the data out when we need it: public class Foo { public void DoSomething() { bool enableLogging = Convert.ToBoolean(ConfigurationManager.AppSettings[ "enableLogging" ]); DateTime startDate = Convert.ToDateTime(ConfigurationManager.AppSettings[ "startDate" ]); decimal baseFee = Convert.ToDecimal(ConfigurationManager.AppSettings[ "startingFee" ]); } } Now that Inversion of Control and Dependency Injection are part of my everyday development, I don't do it this way anymore.  It's messy and doesn't allow me to easily plug in different values during testing. These days, I create a simple interface for my application settings: public interface IApplicationSettings { bool EnableLogging { get; } DateTime StartDate { get; } decimal BaseFee { get; } } And create an implementation of this interface that pulls data from app.config: public class AppConfigSettings : IApplicationSettings { public AppConfigSettings() { this .EnableLogging = Convert.ToBoolean(ConfigurationManager.AppSettings[ "enableLogging" ]); this .StartDate = Convert.ToDateTime(ConfigurationManager.AppSettings[ "startDate" ]); this .BaseFee = Convert.ToDecimal(ConfigurationManager.AppSettings[ "startingFee" ]); }   #region IApplicationSettings Members   public bool EnableLogging { get; private set; } public DateTime StartDate { get; private set; } public decimal BaseFee { get; private set; }   #endregion } I register my types with my IoC container .  During production, dependency injection takes over and automatically gives me my AppConfigSettings instance.  For testing, I generate a mock IApplicationSettings.  And using these settings just got a whole lot cleaner: public class Foo { public Foo(IApplicationSettings applicationSettings) { } } Technorati Tags: .NET , IOC , Mocking , Castle Windsor , Rhino.Mocks

Unit Tests and Debug.Assert()

I recently found some code that had a couple of issues: There was a try/catch block that did a "catch(Exception e)".  And no, it didn't rethrow the exception.  See item #2. Inside the exception handler, it had the following code: catch (Exception e) { Debug.WriteLine(e); Debug.Assert( false ); } I thought long and hard on why anyone would do such a thing and I think I know why. Now, this is purely conjecture, but it does explain things.  This code was found inside a custom PropertyDescriptor – namely, the GetValue and SetValue methods both had this code.  I suspect that the Debug.Assert() was placed inside the catch block of these two methods so that no consumers of this component had to worry about possible data binding errors.  If there ever was a problem with data binding, the Debug.Assert(false) would throw up a dialog with a stack trace and some "Abort/Retry/Ignore" buttons, the user would click "Retry" and re-edit their data.  I don't like it, but since this component is used in a number of places in a data binding scenario, that's my theory. The problem for me is that I needed to fix some bugs in this custom PropertyDescriptor and this code had no unit tests.  So before I could consider modifying anything, I had to get the current behavior under test.  Obviously, I had to remove the Debug.Assert(), but, for legacy code, I still had to have that (ugly!) behavior. Since the Debug.Assert() is being used to report errors, I started by defining an interface that would be used for reporting errors: public interface IPropertyDescriptorValueErrorReporting { void SetValueError(Exception e); void GetValueError(Exception e); } I then moved the existing error handling code into a class I called "DefaultPropertyDescriptorValueErrorReporting": public class DefaultPropertyDescriptorValueErrorReporting : IPropertyDescriptorValueErrorReporting { #region IPropertyDescriptorValueErrorReporting Members   public void SetValueError(Exception e) { Debug.WriteLine(e); Debug.Assert( false ); }   public void GetValueError(Exception e) { Debug.WriteLine(e); Debug.Assert( false ); }   #endregion } I then added an overload on the constructor of this custom property descriptor to accept an IPropertyDescriptorValueErrorReporting public CustomPropertyDescriptor( string name, Type type, int index, IPropertyDescriptorValueErrorReporting errorReporting) : base (name, null ) For legacy code, the old constructor is modified to use the "DefaultPropertyDescriptorValueErrorReporting": public CustomPropertyDescriptor( string name, Type type, int index) : this (name, type, index, new DefaultPropertyDescriptorValueErrorReporting()) Finally, we change the exception handler to call our interface methods: catch (Exception e) { errorReporting.GetValueError(e); } And we do a call to SetValueError in the SetValue exception handler. Now I'm done!  I can proceed to create unit tests and I can pass in a mocked IPropertyDescriptorValueErrorReporting and set expectations that the GetValueError and SetValueError methods are called at the appropriate times.  Plus, I've also created an extension point so other applications can hook in to the error reporting and decide how to handle errors on a case-by-case basis. Technorati Tags: .NET , Unit Testing , Mocking