in

 

GrabBag<T>

October 2007 - Posts

  • Bizarro-tive development

    Anyone familiar with Superman also knows about Bizarro, a doppelganger of Superman.  Bizarro looks like Superman, but is opposite in every way.  Instead of saving people, he kills them.  Instead of eloquent speech, he talks like Tarzan.  He's not from Earth, but from Htrea (Earth backwards, clever).  And so on.

    A colleague reminded me again of the challenges of explaining iterative development to a manager who had been living with waterfall for many years.  The timeboxing concept came through, but iterative and incremental, not so much.

    We drew our original six-month schedule on the board and chopped it up into monthly iterations, saying we would deliver at the end of each month.  We should have been more specific on what "deliver" meant, because this was what the manager then suggested:

    • Iteration 1: Envisioning
    • Iteration 2: Planning
    • Iteration 3: Development
    • Iteration 4: Refactoring
    • Iteration 5: Testing
    • Iteration 6: Stabilization

    Each iteration is timeboxed, which is good, but this is just slapping arbitrary exit points on waterfall.  Not iterative, but bizarro-tive development.  Once we explained further, this was the next suggestion:

    • Iteration 1
      • Week 1: Envisioning/Planning
      • Week 2: Development
      • Week 3: Refactoring
      • Week 4: Testing/Stabilization
    • Iteration 2 - lather, rinse, repeat

    Still not exactly what we were talking about.  True iterative development has most or all aspects happen every day, and some points in the iteration some things will happen more than others.  But we're never doing just one aspect, and slapping phases into iterations isn't iterative development, but it's what Bizarro might do.

    Posted Oct 31 2007, 01:57 PM by bogardj with 6 comment(s)
    Filed under:

  • Coding responsibly

    I just ordered Kent Beck's newest book, Implementation Patterns.  In the sample chapter online, there's a great quote at the end of the preface:

    As a programmer you have been given time, talent, money, and opportunity. What will you do to make responsible use of these gifts?

    That pretty much sums up why I started caring about the code I delivered when I started my career.  After seeing someone else's insane legacy codebase for the first time, I felt a need to learn to code responsibly.  Coding irresponsibly wastes time and money, and life's too short to waste on sloppy code.

    By the way, if you register with informIT, you get a 30% member discount that usually brings the price lower than Amazon.

    Posted Oct 31 2007, 09:39 AM by bogardj with no comments
    Filed under:

  • Oslo = MDA + SOA

    Yeah, yeah, too many acronyms.  One of the biggest challenges in large enterprises is getting all of the disparate systems and applications to talk to each other in a well-defined, agreed-upon manner.  Announced here and blogged here, it looks like Microsoft is hoping to fill some of the gaps other big players in the SOA world (like IBM) have already filled.  Here's a quote describing Oslo from Microsoft:

    Rather than having models being imported and exported and generating code, the model is the application and that breaks down the silos.

    Oslo looks to bring model-driven architecture and SOA together with WCF, BizTalk, Visual Studio and other Microsoft tools and technologies to provide a single Microsoft solution for connected and distributed systems.  For me this is good news because the other big players like IBM and Oracle are mostly or exclusively Java, so it will be nice to have an answer from the .NET side.

    Posted Oct 30 2007, 03:41 PM by bogardj with 2 comment(s)
    Filed under:

  • RSpec gone wrong

    I've seen some weird things in code comments, but with RSpec, you can take programming humor to a different level.  Don't let your customers see these, though.  Here are a few RSpec specifications gone completely wrong:

    #this crap needs to be refactored. it makes no sense.
describe QueryFacade, "when querying for opportunities" do
  it "should be refactored" do
    flunk
  end
end

    That was from Terry, here's another I found floating around somewhere:

    describe "Buffalo Bill" do
  it "places the lotion in the basket" do
  end
end

    That a Silence of the Lambs reference, folks.  And finally:

    describe "our insane customer Initech" do
  it "should stop asking for ridiculous features and make up their $%^*ing mind" do
  end
end

    Waaaay too much free time...

    Posted Oct 25 2007, 10:35 AM by bogardj with no comments
    Filed under:

  • Specifications versus validators

    Joe posed a great question on my recent entity validation post:

    I question the term Validator in relation to DDD.  Since the operation of the Validator seems to be a simple predicate based on business rule shouldn't the term Specification [Evans Pg227] be used instead?

    On the surface, it would seem that validation does similar actions as specifications, namely that it performs a set of boolean operations to determine if an object matches or not.

    For those unfamiliar with the Specification pattern, it provides a succinct yet powerful mechanism to match an object against a simple rule.  For example, let's look at an expanded version of the original Order class on that post:

    public class Order
{
    public int Id { get; set; }
    public string Customer { get; set; }
    public decimal Total { get; set; }
}

    A Specification class is fairly simple, it only has one method that takes the entity as an argument:

    public interface ISpecification<T>
{
    bool IsSatisfiedBy(T entity);
}

    I can then create specific specifications based on user needs.  Let's say the business wants to find orders greater than a certain total, but the total can change.  Here's specification for that:

    public class OrderTotalSpec : ISpecification<Order>
{
    private readonly decimal _minTotal;

    public OrderTotalSpec(decimal minTotal)
    {
        _minTotal = minTotal;
    }

    public bool IsSatisfiedBy(Order entity)
    {
        return entity.Total >= _minTotal;
    }
}

    Specs by themselves aren't that useful, but combined with the Composite pattern, their usefulness really shines:

    public class AndSpec<T> : ISpecification<T>
{
    private readonly List<ISpecification<T>> _augends = new List<ISpecification<T>>();

    public AndSpec(ISpecification<T> augend1, ISpecification<T> augend2) 
    {
        _augends.Add(augend1);
        _augends.Add(augend2);
    }

    public AndSpec(IEnumerable<ISpecification<T>> augends)
    {
        _augends.AddRange(augends);
    }

    public void Add(T augend)
    {
        _augends.Add(augend);
    }

    public bool IsSatisfiedBy(T entity)
    {
        bool isSatisfied = true;
        foreach (var augend in _augends)
        {
            isSatisfied &= augend.IsSatisfiedBy(entity);
        }
        return isSatisfied;
    }
}

    Adding an "OrSpec" and a "NotSpec" allows me to compose some arbitrarily complex specifications, which would otherwise clutter up my repository if I had to make a single search method per combination:

    OrderRepository repo = new OrderRepository();
var joesOrders = repo.FindBy(
    new AndSpec(
        new OrderTotalSpec(100.0m),
        new NameStartsWithSpec("Joe")
    ));

    Given the Specification pattern (fleshed out into excruciating detail), why can't I compose validation into a set of specifications?  Let's compare and contrast the two:

    Specification

    • Matches a single aspect on a single entity
    • Performs positive matching (i.e., return true if it matches)
    • Executed against a repository or a collection
    • Can be composed into an arbitrarily complex search context, where a multitude of specifications compose one search context
    • "I'm looking for something"

    Validator

    • Matches as many aspects as needed on a single entity
    • Performs negative matching (i.e., returns false if it matches)
    • Executed against a single entity
    • Is intentionally not composable, a single validator object represents a single validation context
    • "I'm validating this"

    So although validation and specifications are doing similar boolean operations internally, they have very different contexts on which they are applied.  Keeping these separate ensures that your validation concerns don't bleed over into your searching concerns.

    Posted Oct 25 2007, 09:19 AM by bogardj with 4 comment(s)
    Filed under: ,

  • Entity validation with visitors and extension methods

    On the Yahoo ALT.NET group, an interesting conversation sprung up around the topic of validation.  Entity validation can be a tricky beast, as validation rules typically depend on the context of the operation (persistence, business rules, etc.).

    In complex scenarios, validation usually winds up using the Visitor pattern, but that pattern can be slightly convoluted to use from client code.  With extension methods in C# 3.0, the Visitor pattern can be made a little easier.

    Some simple validation

    In our fictional e-commerce application, we have a simple Order object.  Right now, all it contains are an identifier and the customer's name that placed the order:

    public class Order
{
    public int Id { get; set; }
    public string Customer { get; set; }
}

    Nothing too fancy, but now the business owner comes along and requests some validation rules.  Orders need to have an ID and a customer to be valid for persistence.  That's not too hard, I can just add a couple of methods to the Order class to accomplish this.

    The other requirement is to have a list of broken rules in case the object isn't valid, so the end user can fix any issues.  Here's what we came up with:

    public class Order
{
    public int Id { get; set; }
    public string Customer { get; set; }

    public bool IsValid()
    {
        return BrokenRules().Count() > 0;
    }

    public IEnumerable<string> BrokenRules()
    {
        if (Id < 0)
            yield return "Id cannot be less than 0.";

        if (string.IsNullOrEmpty(Customer))
            yield return "Must include a customer.";

        yield break;
    }
}

    Still fairly simple, though I'm starting to bleed other concerns into my entity class, such as persistence validation.  I'd rather not have persistence concerns mixed in with my domain model, it should be another concern altogether.

    Using validators

    Right now I have one context for validation, but what happens when the business owner requests display validation?  In addition to that, my business owner now has a black list of customers she won't sell to, so now I need to have a black list validation, but that's really separate from display or persistence validation.  I don't want to keep adding these different validation rules to Order, as some rules are only valid in certain contexts.

    One common solution is to use a validation class together with the Visitor pattern to validate arbitrary business/infrastructure rules.  First, I'll need to define a generic validation interface, as I have lots of entity classes that need validation (Order, Quote, Cart, etc.):

    public interface IValidator<T>
{
    bool IsValid(T entity);
    IEnumerable<string> BrokenRules(T entity);
}

    Some example validators might be "OrderPersistenceValidator : IValidator<Order>", or "CustomerBlacklistValidator : IValidator<Customer>", etc.  With this interface in place, I modify the Order class to use the Visitor pattern.  The Visitor will be the Validator, and the Visitee will be the entity class:

    public interface IValidatable<T>
{
    bool Validate(IValidator<T> validator, out IEnumerable<string> brokenRules);
}

public class Order : IValidatable<Order>
{
    public int Id { get; set; }
    public string Customer { get; set; }

    public bool Validate(IValidator<Order> validator, out IEnumerable<string> brokenRules)
    {
        brokenRules = validator.BrokenRules(this);
        return validator.IsValid(this);
    }
}

    I also created the "IValidatable" interface so I can keep track of what can be validated and what can't.  The original validation logic that was in Order is now pulled out to a separate class:

    public class OrderPersistenceValidator : IValidator<Order>
{
    public bool IsValid(Order entity)
    {
        return BrokenRules(entity).Count() > 0;
    }

    public IEnumerable<string> BrokenRules(Order entity)
    {
        if (entity.Id < 0)
            yield return "Id cannot be less than 0.";

        if (string.IsNullOrEmpty(entity.Customer))
            yield return "Must include a customer.";

        yield break;
    }
}

    This class can now be in a completely different namespace or assembly, and now my validation logic is completely separate from my entities.

    Extension method mixins

    Client code is a little ugly with the Visitor pattern:

    Order order = new Order();
OrderPersistenceValidator validator = new OrderPersistenceValidator();

IEnumerable<string> brokenRules;
bool isValid = order.Validate(validator, out brokenRules);

    It still seems a little strange to have to know about the correct validator to use.  Elton wrote about a nice trick with Visitor and extension methods that I could use here.  I can use an extension method for the Order type to wrap the creation of the validator class:

    public static bool ValidatePersistence(this Order entity, out IEnumerable<string> brokenRules)
{
    IValidator<Order> validator = new OrderPersistenceValidator();

    return entity.Validate(validator, brokenRules);
}

    Now my client code is a little more bearable:

    Order order = new Order();

IEnumerable<string> brokenRules;
bool isValid = order.ValidatePersistence(out brokenRules);

    My Order class doesn't have any persistence validation logic, but with extension methods, I can make the client code unaware of which specific Validation class it needs.

    A generic solution

    Taking this one step further, I can use a Registry to register validators based on types, and create a more generic extension method that relies on constraints:

    public class Validator
{
    private static Dictionary<Type, object> _validators = new Dictionary<Type, object>();

    public static void RegisterValidatorFor<T>(T entity, IValidator<T> validator)
        where T : IValidatable<T>
    {
        _validators.Add(entity.GetType(), validator);
    }

    public static IValidator<T> GetValidatorFor<T>(T entity)
        where T : IValidatable<T>
    {
        return _validators[entity.GetType()] as IValidator<T>;
    }

    public static bool Validate<T>(this T entity, out IEnumerable<string> brokenRules)
        where T : IValidatable<T>
    {
        IValidator<T> validator = Validator.GetValidatorFor(entity);

        return entity.Validate(validator, out brokenRules);
    }
}

    Now I can use the extension method on any type that implements IValidatable<T>, including my Order, Customer, and Quote classes.  In my app startup code, I'll register all the appropriate validators needed.  If types use more than one validator, I can modify my registry to include some extra location information.  Typically, I'll keep all of this information in my IoC container so it can all get wired up automatically.

    Visitor patterns are useful when they're really needed, as in the case of entity validation, but can be overkill sometimes.  With extension methods in C# 3.0, I can remove some of the difficulties that Visitor pattern introduces.

    Posted Oct 24 2007, 10:52 AM by bogardj with 10 comment(s)
    Filed under: ,

  • Dependency Breaking Techniques: Inline Static Class

    Often times I run into a class that has a dependency not on a Singleton, but a static class.  When refactoring away from a Singleton, a common approach is to use Inline Singleton.  With static classes, a slightly different approach needs to be taken because client code isn't working with an instance of a type, but rather static methods on the type itself.

    Dependency breaking techniques are used to get legacy code under test.  The goal isn't necessarily to break all client dependencies out, but just the one I'm modifying to get under test.  I'm not interested changing any of the other clients that may use this static class.  Since nothing is under test, it's too risky to make non-backwards compatible changes.

    The pattern

    Code needs access to a method or property but doesn't need a global point of access to it.

    Move Static's features to instance methods of that type.

    Motivation

    Helper methods tend to congregate into static classes with static methods.  Over time, the responsibility grows for the static class until it becomes a dumping ground to any behavior that seems relevant to the name.  The name of the static class usually is post-fixed by "Helper", "Manager", "Utility", or other generic and obtuse names.

    Eventually, this static class will have opaque dependencies of its own, where callers don't know what's happening behind the scenes when those helper methods are called.  This can wreak havoc with unit testing, especially when trying to add tests to legacy code.

    Mechanics

    1. Find the static method in the calling class and use Extract Interface to extract an interface that contains only the static method being called in the client code.
    2. Make the static class explicitly implement the new extracted interface.  The static class should have two methods with identical signatures, one a static method, one an explicitly implemented interface method.
    3. Use Move Method to move the logic from the static method to the instance method.
    4. Use Hide Delegate to delegate the static method calls to the use the instance method instead.
    5. Compile and test.
    6. Modify Client code using the static Operation method to instantiate an IStatic instance and call the interface Operation method.
    7. Compile and test.
    8. Use Extract Parameter to pass in the IStatic instance to the Client method.  If IStatic is a primal dependency, extract the parameter to a constructor argument and set the variable to a local field.
    9. Compile and test.

    Example

    In our e-commerce system, one of the pages the user is presented with is a payments page.  It is in this page that the user decides how they want to pay for their order, whether it's credit card, invoice, financing, etc.

    Not all payment types should be displayed for all carts, and there is some complex business logic that determines who sees what payment types.  There are several payment filtering strategies to encapsulate this business logic, and one type uses the user's profile to filter the payments.  Here's the strategy class:

    public class AccountFilter
{
    private readonly string[] _paymentTypes;

    public AccountFilter(string[] paymentTypes)
    {
        _paymentTypes = paymentTypes;
    }

    public void AddPaymentOptions(ShoppingCart cart)
    {
        IPayment payment = ProfileManager.FindPaymentByType(_paymentTypes);

        if ((payment != null) &&
            (! string.IsNullOrEmpty(cart.AccountNumber)))
        {
            cart.PaymentFilters.Add(payment);
        }
    }

}

    The business has a new requirement for us: Payment types should not be filtered using the user's profile for existing quotes.  In our system, customers can save their cart as a "quote", so that the unit cost information can be "locked" for a set amount of time.  Enabling this change requires us to change the AccountFilter class.

    Being a legacy code system, the AccountFilter class has no tests defined on it.  It's our goal to make the change and add tests to verify the new requirements, and that's all.  We're not trying to add 100% unit test coverage for the AccountFilter class, just to test the changes we're making.

    Not knowing if I can unit test this class, the easiest way to see if it's testable is to try using it in a test.  Here's the behavior I want, in a unit test:

    [TestMethod]
public void Should_not_add_filter_when_basket_is_a_quote()
{
    ShoppingCart cart = new ShoppingCart();
    cart.IsQuote = true;
    cart.AccountNumber = "123ABCD";

    AccountFilter filter = new AccountFilter(new string[] { "CRD", "INV" });
    filter.AddPaymentOptions(cart);

    Assert.AreEqual(0, cart.PaymentFilters.Count);
}

    I try running this test, and it fails spectacularly.  The error I get is along the lines of "HttpContext.Current is null", so something is dependent on the ASP.NET runtime being up.

    Looking at the AddPaymentOptions method of the AccountFilter class, I notice the call to the static method FindPaymentByType on the ProfileManager class.  That method is extremely hideous, with hard dependencies on HttpContext.Current, a web service, and a database.  Instead of focusing on breaking those dependencies out, I can apply Inline Static Class and break out AddPaymentOptions' dependency on ProfileManager.  The end goal is to break the dependencies of the class I'm trying to test, not all the sub-sub-sub dependencies that may be around.

    Step 1:

    ProfileManager is a huge class, with about 100 different methods.  The only one I'm interested in is the FindPaymentByType method, so I'll create an IProfileManager interface that includes only that method, matching signature and name.

    public interface IProfileManager
{
    IPayment FindPaymentByType(string[] paymentTypes);
}

    Step 2:

    Now that I have my IProfileManager, I'll make the static class implement the new interface.  Note that the static class itself isn't marked "static", only its methods.  Additionally, I'll need to explicitly implement that method so it doesn't conflict with the existing static method.

    public class ProfileManager : IProfileManager
{
    public static IPayment FindPaymentByType(string[] paymentTypes)
    {
        // Hit web service for widget
        // Query database based on widget
        // Return database object
    }

    IPayment IProfileManager.FindPaymentByType(string[] paymentTypes)
    {
        return null;
    }
}

    I compile, and everything looks good.  Notice I didn't add any access modifiers to the new IProfileManager method, and the inclusion of the interface name prefixed on the method name.  That's how I can explicitly implement the interface, and not get any compile errors even though these two methods have the exact same signature.

    Step 3, 4:

    Now I can move the existing implementation to the new interface method, and use Hide Delegate to change the static method to call the new interface method.  I don't want to introduce duplication and simply copy over the implementation, so Hide Delegate allows me to retain backwards compatibility and save a lot of work of changing all clients to use the new method.

    public class ProfileManager : IProfileManager
{
    public static IPayment FindPaymentByType(string[] paymentTypes)
    {
        IProfileManager profileManager = new ProfileManager();
        return profileManager.FindPaymentByType(paymentTypes);
    }

    IPayment IProfileManager.FindPaymentByType(string[] paymentTypes)
    {
        // Hit web service for widget
        // Query database based on widget
        // Return database object
    }
}

    Now my static method delegates to the instance methods, and no other clients are affected by this change.  Again, it's not my goal to fix every client dependency on this static method, only the one I'm changing.

    I compile and test, but my initial unit test is failing as it's still calling the static method.

    Step 6:

    Now that I have an interface to depend upon instead of a static method, I'll change the client code to use the interface instead of the static method.  It looks much like the code inside the Hide Delegate of the static method:

    public void AddPaymentOptions(ShoppingCart cart)
{
    IProfileManager profileManager = new ProfileManager();
    IPayment payment = profileManager.FindPaymentByType(_paymentTypes);

    if ((payment != null) &&
        (! string.IsNullOrEmpty(cart.AccountNumber)))
    {
        cart.PaymentFilters.Add(payment);
    }
}

    I create a variable of type IProfileManager, instantiate it to a ProfileManager instance, and use the IProfileManager.FindPaymentByType method instead of the static method.  I compile and test, but my unit test still fails as I still haven't fully extracted the dependency on the ProfileManager, but that will be taken care of shortly.

    Step 8:

    I have two options, I can either pass in the IProfileManager as in the method call or I can pass it in through the constructor.  I prefer to pass dependencies through constructors over method parameters, because I like a clear separation between queries, commands, and dependencies.  Additionally, if I'm using an IoC container, I can wire up these dependencies a little more easily.  I'll use Preserve Signatures [Feathers 312] and Chain Constructors to keep the original constructor, as there are still quite a few clients of my AccountFilter class that I don't want to change:

    public class AccountFilter
{
    private readonly string[] _paymentTypes;
    private readonly IProfileManager _profileManager;

    public AccountFilter(string[] paymentTypes)
        : this(paymentTypes, new ProfileManager()) { }

    public AccountFilter(string[] paymentTypes, IProfileManager profileManager)
    {
        _paymentTypes = paymentTypes;
        _profileManager = profileManager;
    }

    public void AddPaymentOptions(ShoppingCart cart)
    {
        IPayment payment = _profileManager.FindPaymentByType(_paymentTypes);

        if ((payment != null) &&
            (!string.IsNullOrEmpty(cart.AccountNumber)))
        {
            cart.PaymentFilters.Add(payment);
        }
    }
}

    So I did a few things here:

    • Add a new constructor that took an IProfileManager, and created the backing field for it
    • Make the other constructor call the new one, passing in a new ProfileManager, which is what existing code would do
    • Make the AddPaymentOptions method use the field variable instead of a local variable

    What this code allows me to do is pass in a different IProfileManager instance in my test methods to verify my behavior.  I don't really care what the ProfileManager does, all I care about is what it tells me.  Somewhere down the line, I have an integration test that puts the two together, but until then, my unit test will suffice.  Here's my final unit test, which fails for the reason I want it to fail, because the assertion fails:

    [TestMethod]
public void Should_not_add_filter_when_basket_is_a_quote()
{
    ShoppingCart cart = new ShoppingCart();
    cart.IsQuote = true;
    cart.AccountNumber = "123ABCD";

    string[] paymentTypes = new string[] { "CRD", "INV" };

    MockRepository repo = new MockRepository();

    IProfileManager profileManager = repo.CreateMock<IProfileManager>();

    using (repo.Record())
    {
        Expect.Call(profileManager.FindPaymentByType(paymentTypes))
            .Return(null);
    }

    using (repo.Playback())
    {
        AccountFilter filter = new AccountFilter(paymentTypes, profileManager);
        filter.AddPaymentOptions(cart);
    }

    Assert.AreEqual(0, cart.PaymentFilters.Count);
}

    I use RhinoMocks to pass in a mock IProfileManager, and test-driven development to add the functionality desired.  I broke the dependency of the class under test away from the ProfileManager static method, and was able to preserve existing functionality.  By preserving existing interfaces and functionality, I can eliminate much of the risk involved in changing legacy code.  I got my changes in, was able to test them, and kept out of the rabbit-hole that a larger refactoring would have thrown me into.

    Posted Oct 19 2007, 05:50 PM by bogardj with 2 comment(s)
    Filed under:

  • Smart Tag shortcut key

    Ever notice that little red bar show up sometimes in while coding in Visual Studio 2005?  It shows up after making certain changes to code, such as renaming methods, fields, or types that need to be imported:

    That little red bar (did you miss it?  Look closer!) brings up a helpful context menu that has some nice refactorings/editing commands.  Unfortunately, to get the menu to show up with your mouse, you have to bring the mouse down from above onto that little bar that's about 10 pixels wide.

    That's extremely annoying, and I've often missed many times trying to hit that little bar.  Couple that with the fact I don't like to use the mouse while coding, and it's even more annoying.

    Luckily, VS 2005 has a nice shortcut combination to bring that menu up: Ctrl+.  After that combo, the menu shows up:

    Now you can just hit "Enter" and it performs the highlighted command.  For ReSharper users, "Ctrl+." is to Visual Studio as "Alt+Enter" is to ReSharper.  I'm probably the last person to know this shortcut, but it's nice for the few times I prefer Microsoft's helper menu over ReSharper's.

    Posted Oct 19 2007, 03:23 PM by bogardj with 2 comment(s)
    Filed under:

  • Some Domain-Driven Design resources

    Eric Evans' book may be the definitive resource, but there's quite a lot of supporting information on print and on the web.  For those looking to start looking at what all the DDD buzz is about, or just wanted to catch the next acronym wave, here's a list of resources for domain-driven design:

    Publications

    Articles/Blogs/etc

    Personally, I'd start with the InfoQ article, then flush out that with the rest of the books.  For most other questions, the Yahoo group is a great resource as are plain old Google searches.

    Posted Oct 19 2007, 09:35 AM by bogardj with 2 comment(s)
    Filed under:

  • Myth of the isolated production fix

    While in WCF training this week, I heard once again the argument why config files are great - your IT staff can change them without a recompilation.  Sounds great right?  But what exactly does this imply?

    Sure, there's no recompilation, but do the changes get tested?  I can't imagine someone modifying the production environment without testing those changes first.  If something goes wrong, who's fault is it?  It's the application team's responsibility to ensure a tested, reliable application, but they're not the ones making this change.

    How exactly does this change happen?  Does the IT staff manually edit the configuration files?  What happens if they make a mistake?

    Flirting with disaster

    Statements like that, "change without a recompilation", absolutely makes me cringe, as it usually implies that these changes are small, isolated, easy, and therefore don't need to be tested.

    The problem is that making configuration changes can sometimes lead to unexpected behavior changes because something we didn't anticipate is dependent in some way on the configuration file.  Even if the development team is consulted about these changes, how can they say with confidence the change is small or isolated without actually testing those changes?

    Every change, no matter how small, that could potentially affect the behavior of the system, needs to be tested in a variety of systems and environments.  Automated deployments to, and testing of, clones of production environments gives the team confidence in their changes.  Anything else is a wild and potentially hazardous guess.

    A responsible SCM process

    The first step in any reasonable SCM process is continuous integration.  Until the build is repeatable, automated, and tested, the team can't have much confidence in the reliability or quality of a build.  Even small production fixes should start at this phase, as there's never any guarantee a configuration change doesn't affect business logic without regression testing.

    After a CI build and possibly a nightly deployment, we typically have a set of gated environments where builds are put through more and more tests until they are certified as production-ready.  Only builds labeled as production-ready are allowed to be promoted to the production environment.  Although every build in CI processes might be labeled "production-ready", sometimes longer regression tests need to occur before certifying a build ready for the next environment.

    But why are small changes allowed to subvert this process?  The only time this process should be allowed to be subverted is in the event of a critical failure, and the business is losing money because of downtime.  If it takes three weeks for a build to move through the pipeline, that's three weeks where the business is losing money.  The only time we compromise on the quality of the build is when we absolutely have to push it out right away (i.e., in hours).

    That's not to say testing doesn't happen, but it happens in a targeted area.  After the hotfix is pushed out, we still go through the gated promotion process, just to make sure we didn't miss anything.  We might even throw out the changes in source control for more sound fixes.  That hotfix is still considered suspect and isn't treated as production-ready, but temporary.

    Refuse to compromise values

    Hotfixes are a rare occurrence and must go through a promotion process themselves, where the severity of the bug must have a certain level of negative effect on business.  The temptation to push out lower severity bugs through hotfixes becomes higher when a few successful hotfix deployments occur.  The business asks "well, if it was that easy, why don't we do that all the time?".  This is just playing production roulette, and eventually it will catch up to you.

    I don't feel terrible occasionally compromising on practices when the urgency of a hotfix requires it, but it's important for the team never to compromise on their core values.  When hotfix patches are demanded on a regular basis, the team should learn to say "no", push back, and volunteer a more responsible approach.

    Posted Oct 18 2007, 08:10 AM by bogardj with 2 comment(s)
    Filed under:

  • Ruby-style loops in C# 3.0

    This post was originally published here.

    Ruby has a pretty interesting (and succinct) way of looping through a set of numbers:

    5.times do |i|
  print i, " "
end

    The results of executing this Ruby block is:

    0 1 2 3 4

    I really love the readability and conciseness of this syntax, just enough to see what's going on, but not a lot of extra stuff to get in the way.  In addition to the "times" method, there's also "upto" and "downto" methods for other looping scenarios.

    Some slight of hand

    With extension methods and lambda expressions and C# 3.0, this form of loop syntax is pretty easy to do.  Not really a great idea, but at least an example of what these new constructs in C# 3.0 can do.

    So how can we create this syntax in C#?  The "times" method is straightforward, that can just be an extension method for ints:

    public static void Times(this int count)

    Now this method shows up in IntelliSense (when I add the appropriate "using" directive):

    Now that the Times method shows up for ints, we can focus on the Do block.

    Adding the loop behavior

    Although I can't declare blocks in C# 3.0, lambda expressions are roughly equivalent.  To take advantage of lambda expressions, I want to give the behavior to the Times method in the form of a delegate.  By declaring a delegate parameter type on a method, I'm able to use lambda expressions when calling that method.

    I didn't like passing the lambda directly to the "Times" method, so I created an interface to encapsulate a loop iteration, faking the Ruby "do" block with methods:

    public interface ILoopIterator
{
    void Do(Action action);
    void Do(Action<int> action);
}

    Now I can return an ILoopIterator from the Times method instead of just "void".  Now the final part is to create an "ILoopIterator" implementation that will do the actual looping:

    private class LoopIterator : ILoopIterator
{
    private readonly int _start, _end;

    public LoopIterator(int count)
    {
        _start = 0;
        _end = count - 1;
    }

    public LoopIterator(int start, int end)
    {
        _start = start;
        _end = end;
    }  

    public void Do(Action action)
    {
        for (int i = _start; i <= _end; i++)
        {
            action();
        }
    }

    public void Do(Action<int> action)
    {
        for (int i = _start; i <= _end; i++)
        {
            action(i);
        }
    }
}

public static ILoopIterator Times(this int count)
{
    return new LoopIterator(count);
}

    I let the "LoopIterator" class encapsulate the behavior of performing the underlying "for" loop and calling back to the Action passed in as a lambda.  It makes more sense when you see some client code calling the Times method:

    int sum = 0;
5.Times().Do( i => 
    sum += i
);
Assert.AreEqual(10, sum);

    That looks pretty similar to the Ruby version (but not quite as nice), but it works.  Compare this to a normal loop in C#:

    int sum = 0;
for (int i = 0; i < 5; i++)
{
    sum += i;
}
Assert.AreEqual(10, sum);

    Although the "for" syntax is functional and about the same number of lines of code, the Ruby version is definitely more readable.  Adding additional UpTo and DownTo methods would be straightforward with additional ILoopIterator implementations.

    Feature abuse

    Yeah, I know this is more than a mild case of feature abuse, but it was interesting to see the differences between similar operations in C# 3.0 and Ruby.  Although it's possible to do these similar operations, with similar names, this example highlights how much the syntax elements of the static CLR languages can get in the way of a readable API, and how much Ruby stays out of the way.

    Posted Oct 15 2007, 08:44 PM by bogardj with no comments
    Filed under:

  • Fluent interface endgame

    This post was originally published here.

    In a conversation on BDD on the altnetconf message board, the topic switched to language-oriented syntax in the CLR, to which Scott notes:

    When IronRuby gets here, I think we should at least stop and consider the value to the community of encouraging them to try do language-oriented specification with tools and programming languages that don't quite hit the mark.

    Or maybe we should be turning our focus to Boo or IronPython for achieving the solubility in specification code that we can't have in C# and VB.

    I've felt this for quite a while now, though I have reservations about focusing on Boo's Specter or IronPython for the time being.  My response was:

    I think there's an assumption among anyone developing language-oriented tools in CLR using extension methods, fluent interfaces, etc. that it's all a poor man's substitute for the clearer syntax that Ruby inherently provides. Once IronRuby hits some sort of beta/RC status, I don't see much point at all continuing to try to wrestle a pig into a yoke while the farmers laugh "use an ox you moron".

    I do like the readability the Boo macros provide, but I'm always reminded of that scene from King of the Hill when Hank meets his new neighbor Khan (who is from Laos) for the first time:

    Hank: So are you Chinese or Japanese?
    Khan: No, we are Laotian.
    Bill: The ocean? What ocean?
    Khan: From Laos, stupid! It's a landlocked country in Southeast Asia
    between Vietnam and Thailand, population approximately 4.7 million!
    Hank: ... So are you Chinese or Japanese?
    Kahn: D'oh

    As someone who wants to use BDD more, Specter looks like a promising CLR tool, but as a proponent of BDD, Boo might set the bar too high when there's only Chinese or Japanese in the greater community. Then again, if curly-braces dilute a concept that is supposed to lie very close to the conversations BDD starts with, maybe it's better to draw a line so the value isn't diminished.

    I don't really have any answers yet. Make it pure or make it accessible, tough choice...

    Again, I don't have anything against Boo, but I just don't know how successful these efforts will be once IronRuby comes out.  For example, why should I care about the Boo Build System when I can use Rake in Visual Studio when IronRuby ships?

    Until these languages are officially supported by Microsoft, they are for the most part eliminated as an option for one reason or another, whether it be company policy, lack of adoption, or just apathy for learning a new language.  Once they are supported, I will happily ditch my fluent interface and extension methods for a true natural-language friendly programming language.

    Posted Oct 13 2007, 10:07 PM by bogardj with no comments
    Filed under:

  • Double-edged sword of InternalsVisibleTo

    This post was originally published here.

    I've had some conversations with both Joe and Elton lately about the InternalsVisibleTo attribute.  From the documentation, the assembly-level InternalsVisibleTo attribute:

    Specifies that all nonpublic types in an assembly are visible to another assembly.

    This attribute was introduced in C# 2.0, and allows you to specify other assemblies that can see all types and members marked "internal".  In practice, all assemblies are signed with the same public key, and you'd specify that the unit test assembly can see that assembly.

    • MyProject.Core -> has the "InternalsVisibleTo" attribute defined in the AssemblyInfo.cs file, pointing at the below assembly
    • MyProject.Core.Tests -> is signed with the same public key as the Core assembly

    Notice that the "Core" project knows about the "Tests" project, but the actual project dependency is the other way around.  It's definitely better than using reflection to access private members for testing, but there are some definite pros and cons with this approach.

    Pros

    • Allows your test libraries to access internal classes and methods for additional testing and coverage
    • Keeps your public API limited to what you want to publish
    • Provides greater flexibility for internal refactoring and backwards compatibility
    • Reduces the surface area of your public API

    Cons

    • Easily abused, so things usually marked "private" are now marked "internal"
    • Potential loss of encapsulation
    • Decision about what should be public could be wrong
    • Essentially two levels of "public" visibility that have to be managed
    • Enforces bi-directional dependencies between assemblies

    Personally, I always felt like marking something "internal" was cheating just a little bit, and I have trouble deciding when to make something internal or not.  But unless you're delivering a public, published and documented API as part of your product, using the "InternalsVisibleTo" attribute would probably be overkill.

    However, if you are delivering an API, you should consider using this attribute to keep a high level of coverage and reduce the surface area the API for your customers.  You could try starting by making everything "internal", then shape the public API based on specific use cases.

    Posted Oct 12 2007, 05:08 PM by bogardj with no comments
    Filed under:

  • Dialing up quality

    This post was originally published here.

    Quality is not a light switch, it can't be flipped on overnight, or even in six months.  Although the term "quality" differs from person to person, I rather like James Shore's description of Quality With a Name.  He defines quality as having a great design, and that a great design is easy to change.

    Furthermore, he concludes:

    Great designs:

    • Are easily modified by the people who most frequently work within them,
    • Easily support unexpected changes,
    • Are easy to modify and maintain,
    • and Prove their value by becoming steadily easier to modify over years of changes and upgrades. 

    Now that your team agrees on what great design is, reality sinks in when they go back to the monolithic flying-spaghetti-code-monster system and see how far away they are from great design.

    Great design and high quality can be achieved, but it takes many individual victories to reach the final goal.  A team can dial up quality, one principle/practice at a time, until the team and the system are one smoothly running machine.

    Low hanging fruit

    So how do we decide where to begin?  The easiest is the low hanging fruit, pain points that affect developers every day.  Here's some common pain points/smells I run in to:

    • Everyone is afraid to get the latest version
    • "It works on my machine" is your team's mantra
    • Every source code file has at least 3 different coding styles
    • It takes forever to reproduce a defect locally
    • No one knows if the defect is still fixed next week, month, or six months from now

    And the list can go on and on.  Once pain points are found, take the top pain point and set a goal to tackle it in the next week or month.  Then schedule a brown-bag lunch to show the problem, how you tackled it, and the principles that led you to these actions.

    Show the value

    When I want to correct some of these quality issues, I can't tackle the issue in one fell swoop.  Often new ideas have to be introduced a little at a time, where I prove the value as I go.

    I can't force unit tests or pair programming on a team if no one sees the value.  If I try it out, show the value, then team members will start to come onboard.

    A plan of action might be:

    1. Automate the build locally
    2. Automate the build of the latest version on a build server
    3. Remove all warnings
    4. Add some automated tests to reproduce a defect
    5. Get these automated tests running with the nightly build
    6. Introduce unit tests on new code, running with the nightly build
    7. Introduce some key FxCop rules where we're seeing the most varying coding styles
    8. Gradually introduce other FxCop rules to hit other pain points

    Once initial buy-in for values like "feedback" and "maintainability" happens in your team, it's that much easier to introduce other practices that enforce those key values.  Perfect quality is never achieved, but as my dentist told me, excellence is the pursuit of perfection.

    Baby steps to excellence

    It's easy to get discouraged trying to get 100% test coverage on a legacy app.  A better intermediate step is to get 80% coverage on the class or classes that have the most defects.  Lessons learned from that experience can then be applied to the rest of the app.  But if we tried to tackle the entire system all at once, we wouldn't get far enough to realize the value, and the team would discard the value as impossible to achieve.

    By taking small steps toward realizing our goals, dialing up quality one step at a time, we can create a pattern of success take the system to a level of quality that otherwise would not have been imagined to be possible.

    Posted Oct 12 2007, 04:30 PM by bogardj with no comments
    Filed under: ,

  • ALT.NET-itis

    This post was originally published here.

    Has anyone else that attended ALT.NET feel under the weather this week?  I was fine before the conference, then felt like crap afterwards.

    I have a feeling that it was because of the germ-sponge getting passed around at the closing session:

    Martin holding the orange plague-dough

    It was orange at the beginning, but quickly took a brown hue as it went around the room.  I'll bring some rubber gloves next time...

    Posted Oct 11 2007, 01:55 PM by bogardj with no comments
    Filed under:
More Posts Next page »
Copyright Los Techies 2007. All rights reserved.
Powered by Community Server (Commercial Edition), by Telligent Systems