A Lot of Tech, A Little Fashion & Food and #&@#!3@ Opinions

Lowercase Lambdas in an Uppercase World

2011-05-11T14:42:00.000-07:00

While I use upper camel case across the board in my development as mentioned in this post. There is an exception and that is with the use of lamdas. Now, I'm not sure as of what version, but at least Resharper 5.1.3 can enforce lower case naming.

1) In Visual Studio click Resharper > Options

2) In the Options dialog select C# Naming Style

3) Select Override common settings. The custom naming rule for lamdas doesn't exist in the common naming styles.

4) Click Advanced settings

5) Click Add, which wil bring up

The two critical options to select are the Lambda parameter in the Affected Entities listbox and the all_lower option under Name Style. Et Viola! You will no longer get squiggles under your lambdas.

Drop the Hungarian Leftovers

2011-05-11T00:03:00.000-07:00

It might seem a little absurd to you, but my Resharper naming conventions are configured like this.

That's right. I don't prepend 'I' to interfaces, use camelcase for local variables, underscores on private members. I use none of those Hungarian leftovers. On top of that I don't prefix user controls with lbl, txt or drp etc. I don't think any of it is needed. Do you? Why?

Worthy Mentions From Boise Code Camp

2011-02-27T13:06:00.000-08:00

Yesterday, February 26, I attended Boise Code Camp 2011, which had some delectable sessions. Dr. Amit Jain's eloquent introduction to map reduce engaged the audience and provided just enough setup to understand Marissa Hollingworth's, a BSU masters student, application to Last.fm's business. Another worthy mention was Ryan Riley's session on F# on the Web.

Transforming the Bowling Kata Part 1

2011-01-31T00:51:00.000-08:00

Recently Uncle Bob blogged on what he is calling The Transformation Priority Premise. The idea he is exploring, as I understand it, is that certain code changes should have a higher priority than others so as not to lead you to impasses or large code changes in your TDD cycles.

In this series of posts I'm going give Uncle Bob's ideas a shot on the bowling kata. For those not familiar with the kata it calls for scoring ten-pin bowling. Now Bob's premise calls for us to select tests that prefer changes higher on his list of transformations. The highest ranked transformation is

{} -> nil

for which we can write the following test

Given a gutter ball on the first bowl
When scoring
Then the total score is zero

[TestFixture()]
public class given_a_gutter_ball_on_the_first_bowl
    : ContextSpecification
{                 
    [TestCase(0, 0, TestName = "then the score is zero")]
    public void when_scoring(int Bowl, int ExpectedTotal)
    {            
        var Game = new BowlingGame();
 
        Game.Bowl(Bowl);
 
        Assert.AreEqual(ExpectedTotal, Game.Score());
    }
}

I believe this is the simplest test that I can write for the transformation. However there is a more complex test that I could have written. The scoring of an an entire game of gutter balls. Now I immediately wonder, "Which test should I implement?" For the sake of exploring the premise I'll select the more complex of the two.

[TestFixture()]
public class given_a_game_of_gutter_balls
    : ContextSpecification
{                 
    [TestCase(new[] {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, 0, 
     TestName = "then the score is zero")]
    public void when_scoring(int[] Bowls, int ExpectedTotal)
    {            
        var Game = new BowlingGame();
 
        foreach (var Bowl in Bowls)
        {
            Game.Bowl(Bowl);    
        }
 
        Assert.AreEqual(ExpectedTotal, Game.Score());
    }
}

The {] -> nil transformation will cause a failing test and the
nil -> constant transformation will get us a passing test. Now for the implementation, which, no surprise, is simple.

public class BowlingGame
{
    public void Bowl(int Pins)
    {
 
    }
 
    public int Score()
    {
        return 0;
    }
}

I don't see anymore tests that can employ the {} -> nil transormation nor the nil -> constant transformation, but I can however select a test for the constant -> variable tranformation which is

Given one bowl that knocked down five pins
When scoring
Then the total score should be five

[TestFixture()]
public class given_one_bowl_that_knocked_down_five_pins
    : ContextSpecification
{
    [TestCase(5, 5,
     TestName = "then the score is five")]
    public void when_scoring(int Bowl, int ExpectedTotal)
    {
        var Game = new BowlingGame();
 
        Game.Bowl(Bowl);
 
        Assert.AreEqual(ExpectedTotal, Game.Score());
    }
}

In this case I see only one kind of test that is selected by the highest ranked transformation I think I can apply. The resulting implementation is

    public class BowlingGame
    {
        private int PinsKnockedDown;
 
        public void Bowl(int Pins)
        {
            PinsKnockedDown = Pins;
        }
 
        public int Score()
        {
            return PinsKnockedDown;
        }         
    }

After having only two tests and performing three transformations. I have a couple of observations and questions,

1. A given transformation could have multiple tests you could write. Which test does one select?

2. If I understand the premise correctly transformations are used as a basis for selecting the next failing test. In Uncle Bob's example he uses {} -> nil transformation to get a test to fail. Is this in the spirit of premise? Once a test has been selected writing the appropriate code to get it to fail seems like an orthogonal issue. If that's true then perhaps adding {} -> constant transformation is appropriate.

3. Interestingly the second test required not only a change in the BowlingGame.Score() method, but a parallel change in BowlingGame.Bowl(). Are these parallel transformations predictable in situations where the command-query seperation principle is being applied?

4. In order to apply the premise it appears we must be able to identify tests that require transformations that have a higher priority. Does this contradict one of the intents of TDD? That is to let the tests drive the code. Are we really thinking about design when we apply this premise?

5. Are all impasses a result of problems with test selection? What kinds of impasses are signs of conceptual modeling problems? Can TDD coding impasses even be interpreted in a way that can detect modeling issues?

In part 2, I'll move forward with the kata and hopefully come closer to answering some of these questions.

TDD Katas in Interviews

2010-11-02T22:41:00.000-07:00

I've been doing a lot of interviewing in the last year, which means I have to perform the impossible task of evaluating another developers skill set. Two big questions I keep in mind when doing the technical part of the evaluation are

What will it be like to work with this person?
Where does theory meet practice?

I'm very big on concrete results so I do as much hands on interviewing as I can fit in. One tool I've started using to help answer these question is pairing on a TDD kata. Especially when someone puts TDD on their resume. Now none of the candidates I've interviewed have heard of katas, which makes it fun for me because they learn something new, which I always hope to offer someone.

Typically I structure the pairing using PPP, which works like this

Developer A writes a failing test.
Developer B makes the test pass.
Developer A & B collaborate of refactoring
Developer B writes a failing test.
Developer A makes the test pass.
Developer A & B collaborate of refactoring

Some of my takeaways are

You get a real sense of what it'll be like to work them.
Do they have real world experience?
How are they evaluating themselves?
It brings out a lot of proclivities
Does the person understand red-green-refactor?
Can they put on a customer hat on? Do they focus on important functionality? Or do they overly focus on edge cases?
How fluent are they with Resharper or DevExpress (refactoring)?

Some things I've learned for getting the most out of it are

Allow 2.5 - 3 hours.
Offer the person the option to bring their own laptop
Mac laptop keyboards can be really awkward if a person isn't used them (I own a mac)
Keep in mind you're interviewing. Don't get so engrossed that you end up doing important things for them.
Don't use contrived katas

Spring.NET Short Circuiting Validators - The Finally

2009-04-14T23:34:00.000-07:00

I really like what I do, I love the internet and love hearing other's ideas. After posting part 2 of this topic I noticed someone had actually commented on one of my very few posts. Mark Pollack suggested a great interim solution to the problem of easily configuring short circuiting validators. I say interim because the ability to do something like <v:group fastValidate=true> is planned fro Spring 2.0. Mark's solution allows me to preserve the initial rules layout that was presented in part 1. Here it is a again

    1 <objects xmlns="http://www.springframework.net"
    2          xmlns:v="http://www.springframework.net/validation">
    3   <v:group id="UserValidator">
    4     <v:group id="UserNameValidator">
    5       <v:required id="UserNameRequired" test="UserName">
    6         <v:message id="Errors.UserName.Required"  providers="UserNameError"/>
    7       </v:required>
    8 
    9       <v:regex id="UserNameMinmumComplexity" test="UserName">
   10         <v:property name="Expression" value="^.{5,20}$"/>
   11         <v:message id="Errors.UserName.MinimumComplexity" providers="UserNameError"/>
   12       </v:regex>
   13 
   14       <v:validator id="UserNameIsUnique" test="UserName" type="XXX.Infrastructure.Validation.IsUniqueUserNameValidator, XXX.Infrastructure">
   15         <v:property name="UserRepository" ref="UserRepository"/>
   16         <v:message id="Errors.UserName.IsUnique" providers="UserNameError"/>
   17       </v:validator>
   18     </v:group>
   19 
   20    .... 
   21   </v:group>  
   22 
   23  ....
   24 </objects>

His suggestion is to use IObjectPostProcessor to set the FastValidate property. Since I don't want to set the property on every ValidatorGroup I adopted a naming convention for those groups I do desire the behavior and so I can easily identify them in the post processor. For example, In the configuration above I changed UserNameValidator to UserNameFastValidator. The post processor looks like,

    1     public class FastValidatePostProcessor 
    2         : IObjectFactoryPostProcessor
    3     {
    4         public void PostProcessObjectFactory(IConfigurableListableObjectFactory factory)
    5         {
    6             string[] validatorGroupNames = factory.GetObjectNamesForType(typeof(ValidatorGroup));
    7             foreach (string validatorGroupName in validatorGroupNames)
    8             {
    9 
   10                 if (validatorGroupName.EndsWith("FastValidate"))
   11                 {
   12                     IObjectDefinition definition = factory.GetObjectDefinition(validatorGroupName);
   13                     definition.PropertyValues.Add("FastValidate", true);
   14                 }
   15             }
   16         }
   17     }

All that is left is to add the object to the configuration file something like

    1 <object type="XXX.Infrastructure.Validation.FastValidatePostProcessor, XXX.Infrastructure"/>

Thanks Mark!

Spring.NET Short Circuiting Validators - Part 2

2009-04-14T22:47:00.000-07:00

Yesterday I gave a possible solution to the problem of easily configurable short circuiting validators in Spring.NET. Several hours later another possiblity struck me. One can use the existing ValidatorGroup class with the <v:validator> tag and set FastValidate in the <v:property> tag instead using the <v:group> tag which doesn't let you set that property. The configuration would look like this

    1 <objects xmlns="http://www.springframework.net"
    2          xmlns:v="http://www.springframework.net/validation">
    3   <v:group id="UserValidator">
    4     <v:validator id="UserNameValidator" type="Spring.Validation.ValidatorGroup, Spring.Core">
    5       <v:property name="FastValidate" value="true"/>
    6       <v:property name="Validators">
    7         <list>
    8           <ref object="UserNameRequired"/>
    9           <ref object="UserNameMinimumComplexity"/>
   10           <ref object="UserNameIsUnique"/>
   11         </list>
   12       </v:property>
   13     </v:validator>
   14 
   15     <!-- ...more validators -->
   16   </v:group>
   17 
   18   <v:required id="UserNameRequired" test="UserName">
   19     <v:message id="Errors.UserName.Required"  providers="UserNameError"/>
   20   </v:required>
   21 
   22   <v:regex id="UserNameMinimumComplexity" test="UserName">
   23     <v:property name="Expression" value="^.{5,20}$"/>
   24     <v:message id="Errors.UserName.MinimumComplexity" providers="UserNameError"/>
   25   </v:regex>
   26 
   27   <v:validator id="UserNameIsUnique" test="UserName" type="XXX.Infrastructure.Validation.IsUniqueUserNameValidator, HSN.Infrastructure">
   28     <v:property name="UserRepository" ref="UserRepository"/>
   29     <v:message id="Errors.UserName.IsUnique" providers="UserNameError"/>
   30   </v:validator>
   31 
   32   <!-- ...more validators -->
   33 </objects>

Spring.NET Short Circuiting Validators - Part 1

2009-04-13T01:48:00.000-07:00

One of the features I've come to like in Spring.NET is the validation library, but it does come up short on at least one basic need. That is a straight forward way to configure short circuiting for <v:group>'s. Meaning a validator group that quits validating and returns false on the first failed validator and returns true otherwise. Out of the box if you wanted to setup a group to, let's say, validate the User.UserName property you might write something like,

    1 <objects xmlns="http://www.springframework.net"
    2          xmlns:v="http://www.springframework.net/validation">
    3   <v:group id="UserValidator">
    4     <v:group id="UserNameValidator">
    5       <v:required id="UserNameRequired" test="UserName">
    6         <v:message id="Errors.UserName.Required"  providers="UserNameError"/>
    7       </v:required>
    8 
    9       <v:regex id="UserNameMinmumComplexity" test="UserName">
   10         <v:property name="Expression" value="^.{5,20}$"/>
   11         <v:message id="Errors.UserName.MinimumComplexity" providers="UserNameError"/>
   12       </v:regex>
   13 
   14       <v:validator id="UserNameIsUnique" test="UserName" type="XXX.Infrastructure.Validation.IsUniqueUserNameValidator, XXX.Infrastructure">
   15         <v:property name="UserRepository" ref="UserRepository"/>
   16         <v:message id="Errors.UserName.IsUnique" providers="UserNameError"/>
   17       </v:validator>
   18     </v:group>
   19 
   20    .... 
   21   </v:group>  
   22 
   23  ....
   24 </objects>

However when User.UserName is validated every validator will fire. There are many reasons why it makes sense to abandon validation on the first failed validator: some rules maybe more expensive than others to evaluate, maybe executing every action due to failed rules produces less than desirable results.

The approach I took was to create a custom validator that inherits from ValidatorGroup.

    1     public class ShortCircuitingValidatorGroup
    2         : ValidatorGroup
    3     {
    4         public ShortCircuitingValidatorGroup()
    5         {}
    6 
    7         public ShortCircuitingValidatorGroup(string when)
    8             : base(when)
    9         {}
   10 
   11         public ShortCircuitingValidatorGroup(IExpression when)
   12             : base(when)
   13         {}
   14 
   15         /// <summary>
   16         /// The non-shortcircuiting validator group
   17         /// </summary>
   18         public ValidatorGroup GroupToShortCircuit { get; set; }
   19 
   20 
   21         public override bool Validate(object validationContext, 
   22                                       System.Collections.IDictionary contextParams, 
   23                                       IValidationErrors errors)
   24         {
   25             GroupToShortCircuit.FastValidate = true;
   26             return GroupToShortCircuit.Validate(validationContext, contextParams, errors);
   27         }
   28 
   29     }

As you can see the class holds a reference to the group we want to short circuit and sets the FastValidate property, invoking the behavior I want, to true. The custom validator is setup in xml for the User.UserName property like this

    1 <objects xmlns="http://www.springframework.net"
    2          xmlns:v="http://www.springframework.net/validation">
    3   <v:group id="UserValidator">
    4     <v:validator id="UserNameValidator"
    5                  type="XXX.Infrastructure.Validation.ShortCircuitingValidatorGroup, XXX.Infrastructure">
    6       <v:property name="ValidatorGroup" ref="UserNameValidatorGroup"/>
    7     </v:validator>
    8     ...
    9   </v:group>
   10 
   11   <v:group id="UserNameValidatorGroup">
   12     <v:required id="UserNameRequired" test="UserName">
   13       <v:message id="Errors.UserName.Required"  providers="UserNameError"/>
   14     </v:required>
   15 
   16     <v:regex id="UserNameMinmumComplexity" test="UserName">
   17       <v:property name="Expression" value="^.{5,20}$"/>
   18       <v:message id="Errors.UserName.MinimumComplexity" providers="UserNameError"/>
   19     </v:regex>
   20 
   21     <v:validator id="UserNameIsUnique" test="UserName" type="XXX.Infrastructure.Validation.IsUniqueUserNameValidator, XXX.Infrastructure">
   22       <v:property name="UserRepository" ref="UserRepository"/>
   23       <v:message id="Errors.UserName.IsUnique" providers="UserNameError"/>
   24     </v:validator>
   25   </v:group>
   26   ...
   27 </objects>

Unit Testing a Custom Membership Provider

2009-04-12T09:48:00.000-07:00

Wow, it's been awhile since I've blogged here. I don't want to bore you with my regret so I'll get to it. Today I was attempting to test drive a custom membership provider

    1 [Test]
    2 public void CanCreateNewUser()
    3 {
    4     TestProvider.Initialize(ProviderName, DefaultConfig);
    5     MembershipCreateStatus Status;
    6     ApplicationUser UserToSave =
    7         new ApplicationUser(CorrectUserName, 
    8                             CorrectPassword, 
    9                             CorrectEmail)
   10                          {
   11                              PasswordQuestion = ThePasswordQuestion,
   12                              PasswordAnswer = ThePasswordAnswer
   13                          };
   14     UserRepository.Expect(x => x.Save(UserToSave))
   15         .IgnoreArguments();
   16 
   17     MembershipUser NewUser =
   18         TestProvider.CreateUser(CorrectUserName,
   19                                 CorrectPassword,
   20                                 CorrectEmail,
   21                                 ThePasswordQuestion,
   22                                 ThePasswordAnswer,
   23                                 false,
   24                                 null,
   25                                 out Status);
   26 
   27     Assert.AreEqual(MembershipCreateStatus.Success, Status);
   28     UserRepository.VerifyAllExpectations();
   29 }

I hit run in my NUnit test runner and bam, I got this error

Tests.UnitTests.CustomMembershipProviderTestCase.CanCreateNewUser: System.ArgumentException : The membership provider name specified is invalid. Parameter name: providerName

At the top of the stack trace was the MembershipUser constructor so that's where I started my search. O how I love Reflector. I fired it up and examined the constructor for the MembershipUser class and spotted the following check

    1 if ((providerName == null) || 
    2     (Membership.Providers[providerName] == null))
    3 {
    4     throw new ArgumentException(
    5         SR.GetString("Membership_provider_name_invalid"), "providerName");
    6 }

There's the culprit : Membership.Providers[providerName] == null. So I tried setting the provider programmatically in my test, but the provider's collection is read only. I know that the provider's collection is populated according to what is in the web.config so I added the necessary section to the app.config of my test project.

    1   <system.web>
    2     <membership defaultProvider="CustomMembershipProvider">
    3       <providers>
    4         <remove name="AspNetSqlMembershipProvider"/>
    5         <add applicationName="UnitTests"
    6              name="CustomMembershipProvider"
    7              type="XXX.Infrastructure.Authentication.CustomMembershipProvider, XXX.Infrastructure"/>
    8       </providers>
    9     </membership>
   10   </system.web>

I reran my test and I saw green, but I wasn't totally satisfied. The one thing I don't like about this solution is I can't control what's in the providers collection on a test by test basis.

In the back of my mind I knew I could use reflection, but I was avoiding it because I really wanted to move on. I quickly poked around the Membership and MembershipProvderCollection classes with reflector knowing, like many things, that somebody has probably solved this problem. Within minutes I found Colin Bowern's post describing the same exact issue. The code below to programmatically populate the provider's collection is to his credit. Thanks Colin.

    1 private void InjectProvider(ProviderCollection Collection, ProviderBase Provider)
    2 {
    3     typeof(ProviderCollection).GetField("_ReadOnly", BindingFlags.Instance | BindingFlags.NonPublic)
    4                               .SetValue(Collection, false);
    5 
    6     Hashtable Hash = (Hashtable)typeof(ProviderCollection).GetField("_Hashtable", BindingFlags.Instance | BindingFlags.NonPublic)
    7                                                           .GetValue(Collection);
    8 
    9     if (Hash[Provider.Name] == null)
   10     {
   11         Hash.Add(Provider.Name, Provider);
   12     }
   13     else
   14     {
   15         Hash[Provider.Name] = Provider;
   16     }
   17 }

Now the top two lines of my test look like

    1 TestProvider.Initialize(ProviderName, DefaultConfig);
    2 InjectProvider(Membership.Providers, TestProvider);

And my test still passes.