Mango12 created an interesting competition to kick off the New Year, and I decided to try it out. It’s a simple task along the lines of a code kata, and I recommend you try it yourself before looking over my solution.

Task: Compress a list of words into the shortest string that contains all words.

Test: “testing”, “ginger”, “german”, “minutes” should become “minutestingingerman”

Here is my approach: create a weighted graph connecting each term then recursively reduce the highest weighted edges.

The test to see if it works begins with four terms.

Two different edges can be reduced. The test won’t be affected by which one I choose. If I optimize this in the future, it would be prudent to check the nodes and merge the two with no other good matches.

The choice is clear this time.

After the final merge, we end up with minutestingingerman.

I started off with a test to prove that it works.

[Test]
public void ShouldCompressListOfWordsToShortestStringThatContainsAllWords()
{
    var terms = new[] {"testing", "ginger", "german", "minutes"};
    StringGraph graph = new StringGraph(terms);
    Assert.AreEqual("minutestingingerman", graph.Compress());
}

I then created a StringGraph class with weighted nodes. The Node class contain edges and a function to calculate weight when a node is added. In building the solution, I encountered a problem where I was mixing mutable and immutable methods. If I return to this in the future, I should decide which direction I want to go in. I decided to just make it work for the time being.

Since I have a myriad of classes for building the graph, I  will focus on a few important points. The solution is available here if you’re interested in trying it out for yourself.

Calculating Weight

I created a Node class that contains two generics: one for the value type and another for the weight type. To create edges, nodes are added and the weight must be calculated at that time. I decided to make the weight calculation a function that can be assigned by creator. The default function will set the weight to the default of the weight type.

public class Node<T, TWeight> : INode<T, TWeight>
{
    private List<IEdge<T, TWeight>> edges = new List<IEdge<T, TWeight>>();
    
    Func<INode<T, TWeight>, INode<T, TWeight>, TWeight> calculateWeight;

    public Func<INode<T, TWeight>, INode<T, TWeight>, TWeight> 
                                               CalculateWeight
    {
        get
        {
            if (calculateWeight == null)
            {
                calculateWeight = (n1, n2) => default(TWeight);
            }

            return calculateWeight;
        }
        set
        {
            calculateWeight = value;
        }
    }

    public IEnumerable<IEdge<T, TWeight>> Edges
    {
        get
        {
            return edges;
        }
        private set
        {
            edges = new List<IEdge<T, TWeight>>(value);
        }
    }

    public T Value { get; private set; }

    public Node(T value)
    {
        this.Value = value;
    }

    public void Add(INode<T, TWeight> node)
    {
        var edge = new Edge<T, TWeight>(this, node, 
                                        CalculateWeight(this, node));
        edges.Add(edge);
    }
}

StringGraph assigns the function which checks for the overlap at the end of the parent node and the beginning of the child node.

calculateWeight = (node, newNode) =>
    {
        int maxLength = node.Value.Length < newNode.Value.Length ?
            node.Value.Length : newNode.Value.Length;
        for (int i = node.Value.Length - maxLength; i < maxLength; i++)
        {
            if (node.Value.EndsWith(
                  newNode.Value.Substring(0, maxLength - i)))
            {
                return maxLength - i;
            }
        }

        return 0;
    };

The values generated by this function correlate with the numbers in the graphs above.

Reducing the Graph

The Reduce method is meant to determine two nodes that should be merged and create a new, smaller graph. To make my test turn green, I wrote the following method.

public StringGraph Reduce()
{
    if (nodes.Count <= 1)
    {
        return this;
    }

    var edges = from n in nodes
                from e in n.Edges
                select e;
    var edge = edges.First(n => n.Weight == edges.Max(e => e.Weight));
    
    return new StringGraph(nodes.Select(n => n.Value)
                                .Where(str => str != edge.Parent.Value && 
                                                    str != edge.Node.Value)
                                .With(edge.Combine().Value));
}

Although I didn’t put all the necessary error checking in this program, I felt it important that someone does not try to reduce a 1 or 0 node graph. I then pull up every edge, obtain the first one with the highest weight, then combine the nodes it connects.

This part of the code could use some optimization. I am creating an entirely new graph, which may be correct in a class library where immutable types are expected. However, StringGraph is far from immutable, and there is overhead from making it build up a new graph. If I wanted to generate a reduced graph without affecting the current instance, it may be better to implement cloning and a better node merging algorithm. The edges going to the parent and from the child will typically be the same.

More Improvements

There are other improvements that can be made. I’m not currently detecting and removing nodes that represent inner strings, and there are likely better algorithms for NP problems. This four string example is rather simplistic, and there is much more ground that can be covered. Give it a shot and create your own solution, or improve upon the one I’ve presented. Be sure to tell me your approach in the comments!

Static constructors should be private: a pretty simple rule to follow and one most .NET developers are forced to do. So why do I bring it up? During a webinar earlier today, I demonstrated the new static constructor mocking capabilities in JustMock. I decided to offer that piece of advice because non-private static constructors are a security flaw. However, I was in a C# project, and it’s impossible to use a non-private static constructor anyway.

It’s rare that I need to use static constructors, and I was lacking an example of one with an external dependency. In fact, that’s something I would try to avoid. So, I needed to find a real world example to show why this feature is useful. I did a quick search and found this code analysis entry on MSDN: If a static constructor is not private, it can be called by other code. This is a breaking security issue. I filed this info away and continued my search for a dependency in a static constructor.

I should have read a little further. The article also states: “This rule is enforced by the C# and Visual Basic .NET compilers.” For the vast majority of .NET developers, this rule is irrelevant. Having never had an inclination to make a public static constructor, I failed to realize that I was giving inconsequent advice.

If you’re coding in a language that does support non-private static constructors, please realize the security risk involved. If you are instantiating dependencies in your static constructor, consider a different approach. If one isn’t feasible, JustMock has your back for testing the class.

Functions have a given number of arguments which define the arity of the function. The process of producing another function by setting any number of arguments to a function is known as partial application. C# developers are most familiar with this concept by calling one method from a more specific method, thereby adhering to the DRY principle.

For an example, I have decided to name the div operator with a Divide method.

public static double Divide(double x, double y)
{
    return x / y;
}

I could then use partial application to create an Inverse method, fixing the first argument to the Divide method as the value 1.

public static double Inverse(double y)
{
    return Divide(1, y);
}

This adheres to the DRY principle since the details to the Divide method may change. Perhaps I will choose to use a math library in the future, and the Inverse method is a more specific version of the Divide method, so changes should affect both places.

The context most people hear about partial application is with functional programming. Methods are procedures or functions associated with a class, and that’s why many functional techniques are applicable in the object-oriented world. In C#, most people associate functional programming with anonymous functions, so let’s see how we can use partial application with it.

Func<double, double, double> div = (x, y) => x / y;
Func<double, double> inv = y => div(1, y);

Using partial application with lambda expressions was straightforward. First, I defined a div function. Then, I defined an inv function, calling the div function with 1 as its first argument. There is something to be desired here… it feels like partial application should be built into the language somehow. If you call div(1), it should apply the argument and return a reduced function. Since C# doesn’t support this, we will have to use what tools we have available to build something similar.

public static class FuncExtensions
{
    public static Func<T2, TResult> Apply<T, T2, TResult>(this Func<T, T2, TResult> func, T arg1)
    {
        return arg2 => func(arg1, arg2);
    }
}

I wrote an extension method to apply the first argument to a binary function (you can fill in the rest). This cleans up the original code.

Func<double, double, double> div = (x, y) => x / y;
var inv = div.Apply(1.0);

The compiler cannot expand the type to match the extension method, so it is necessary to specify a double when passing the argument. However, it is now possible to use an implicit type declaration since the method returns a Func with one less generic parameter.

I believe I explained clearly why you should care about this when it comes to methods, but it may be less clear why you need this when it comes to anonymous functions. You may be defining functions in the same manner you are doing methods, and you are attempting to not repeat yourself. What I think may be a more compelling case is that sometimes you need to pass functions with a specific signature, and the best way to achieve that signature is to apply known information. This is powerful in systems that dynamically create and consume functions (business rules), and it simplifies the passing of data as functions carry requisite values.

Partial application is a useful tool, and you’ve likely used it without realizing it.

The term ‘arity’ evokes images of complex differential diagrams that requires a graduate degree to understand, but the concept itself is rather simple. Arity is a value that represents the number of arguments a function takes. Does your method accept a single argument? Then it’s arity is one. Does it accept two arguments? Then it’s arity is two. Simple.

So it’s simple: a method’s arity is identical to its number of parameters? Not so fast! Arity refers specifically to arguments. Arguments are the values you pass into a method or function. A parameter typically expects you to pass a value to it when you call a method, but it’s possible that the value has been defaulted.

Bob Martin’s Clean Code Tip of the Week #10 was “Avoid Too Many Arguments.” That seems fair enough, but why is it that you hear things like “functions rarely have an arity greater than one.” There are two primary issues at play here.

1. Function inputs can be represented as composite types so that every argument is reduced to one.

2. Functions can be curried so that functions have one argument and returns another function (which has one argument and continues until the full chain is unraveled).

When closures occur, number one is sure to follow to capture the variables used within the lambda expression. The important thing to note is that although the compiler is taking care of the closure, human readers of the code are still experiencing many arguments. Uncle Bob’s tip should still be followed.

Number two is a powerful language feature, but it suffers from the same issue as above.

Lower arity also occurs when side effects from other external sources (such as system variables) are resulting in affected out with fewer arguments. This is undesirable, but sometimes necessary.

As always, keep your code readable and maintainable. Strive for lower arity, but don’t let it break you. Besides, I’d rather you call it “binary” than “arity 2.”

A few professors from Stanford University are performing an experiment in distributed education by offering three computer science classes for free. There are many educational materials out there if you want to learn, but this is a good way to push yourself and be graded on your work. If you want to check it out without committing, the basic level version is like the advanced but without the test taking.

My goal in doing this is to learn about subjects with which I have little familiarity. Therefore, I am skipping out on the Introduction to Databases class. I will be participating in the Machine Learning and Artificial Intelligence classes. I find these subjects fascinating but have not studied them in depth. To aid in my efforts, I will be using the two reddits focused on these subjects: r/mlclass and r/aiclass. The great thing about having over 50,000 people taking part in a class is the extremely large study groups you get from it.

I signed up for the advanced versions of the classes, but I may have to switch to basic if it’s too much to handle on the road. DevReach is coming soon, and I will be flying to Bulgaria to take part in the fun.

Some of the code for the AI class has been ported to C#. I’ll be translating the original Java and using C# language features as I go, so I may be adding to the library of stuff that already exists.

If you’re joining these classes and want to do a hangout with others in the class, add on me Google+.

In Implementation Patterns by Kent Beck, he mentions a use of inheritance that can be particularly troublesome: parallel hierarchies. He uses an example of this from an insurance system.

As shown in the image above, each subclass from one hierarchy requires one from the other hierarchy. This leads to class explosion! As you can imagine, it’s even worse when there are more than two hierarchies interacting in this manner.

Here’s how the skeleton C# code for the example might look:

public abstract class Contract
{
    public Product Product { get; protected set; }
}

public class InsuranceContract : Contract
{
    public InsuranceContract(InsuranceProduct product)
    {
        this.Product = product;
    }
}

public class PensionContract : Contract
{
    public PensionContract(PensionProduct product)
    {
        this.Product = product;
    }
}

public abstract class Product
{
}

public class InsuranceProduct : Product
{
}

public class PensionProduct : Product
{
}

Kent’s team was able to get around this by restructuring Contract to only use Product without worrying about specific versions.

Generics can alleviate some of this issue.

public class Contract<T> where T : Product
{
    public T Product { get; protected set; }

    public Contract(T product)
    {
        this.Product = product;
    }
}

public abstract class Product
{
}

public class InsuranceProduct : Product
{
}

public class PensionProduct : Product
{
}

There may be need for variations in the types of Contract, in which case a subclass can be created. However, there may be times which functionality needs to be created on a case by case basis or calculations are being determined based upon formulas in an external source. This can be solved a number of ways. Here’s an example I created using delegates and IronPython.

public class ContractFactory
{
    public Contract<T> CreateContract<T>(T product) where T : Product
    {
        ScriptRuntime py = Python.CreateRuntime();
        dynamic rules = py.UseFile("rules.py");            
        var contract = new Contract<T>(product);
        contract.CalculatePremium = p => rules.CalculatePremium(p);
        return contract;
    }
}

public class Contract<T> where T : Product
{
    public T Product { get; protected set; }
    public Func<T, double> CalculatePremium { get; set; }

    public Contract(T product)
    {
        this.Product = product;
    }
}

You will sometimes end up with parallel inheritance hierarchies as inheritance can be a good representation of the relationship between objects. These relationships can naturally fall into this pattern. However, you should nip it in the bud if the classes start to grow as they can easily become cumbersome. Always consider what changes between the classes and consider moving the responsibility elsewhere.

A new internal build of Telerik JustMock was recently released with several new features and fixes.

What’s New

• Support of Raise event and ability to mock explicit interface implementation in Future Mocking.
• Ability to do Mock.AssertAll(foo) /foo.AssertAll() [when Telerik.JustMock.Helpers is used] that will assert all the arrange regardless of MustBeCalled specified.
• Make Single Parameter Declaration in Returns optional.
• Support of up to 16 parameters similar to .NET 4.0 in Returns and DoInstead Delegate.

What’s Fixed

• InOrder is not working as expected when applied on setups with similar member.
• Support of manually creating instance of nested type.
• For stub it should be possible to set property value multiple times.
• Failed to create instance EntityFramework.ObjectResult due to exception in intercepting non generic IListSource member from generic Table.
• Problem mocking Microsoft.Exchange.WebServices.Data.EmailAddressCollection.GetEnumerator() - fails with TypeLoadException.
• Resolve Nested mock setups from TestInitalize for final / static methods.
• Exception when intercepting generic constructor using profiler for Constructor.Mocked switch or Sealed class.
• Null reference in ReturnsColleciton for class with List or Colleciton base.
• Auto arrange property getter for stub when already invoked but not arranged.

I plan on posting a more comprehensive article soon (on blogs.telerik.com) detailing the changes. Tell me what you want to see in this update or in the future and I will work it in! Keep in mind that the roadmap for mid-Fall includes support for Silverlight mocking with profiler, HttpContext mocking in nested classes, and improvements to Fluent Assertions. I will be covering these in the webinars and blogs leading up to the 2011 Q3 release of JustMock.

When reading Steve Smith’s articles on enums on ASP.NET Alliance and his blog, I couldn’t help but think of a different approach to the issue. I’ve seen, used, and coded the enum class pattern before (and it works well), but we have new language features today to encourage reuse and empower true enums. I am going to show you techniques that won’t require significant changes to your code if you have an existing base of enums.

First, let’s start off with the Role enum Steven introduced:

public enum Role
{
    Author = 1,
    Editor = 2,
    SalesRepresentative = 3,    
    Secret = 4,
    AnotherSecret = 5,
    Manager = 6
}

It’s a straightforward enum with its ordinal values defined. The original code was retrieving a list of names. I contend that this shouldn’t be limited to one particular enum. I created an EnumList class to turn any enum into an IEnumerable<T>.

public class EnumList<T> : IEnumerable<T> where T : struct
{
    public EnumList()
    {
        if (!typeof(T).IsEnum)
        {
            throw new ArgumentException("Generic parameter must be enum");
        }
    }

    public virtual IEnumerator<T> GetEnumerator()
    {
        return Enum.GetValues(typeof(T)).Cast<T>().GetEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return ((IEnumerable<T>)this).GetEnumerator();
    }
} 

**UPDATED** Paulo Morgado reminded me that I could just call GetEnumerator().

This is merely hiding the necessity of calling Enum.GetValue(typeof(T)).Cast<T>(), but it makes for friendlier tests.

[TestMethod]
public void ShouldCreateValidListAndReturnFirstValue()
{
    var roles= new EnumList<Role>();
    Assert.AreEqual(Role.Author, roles.First());
}

When displaying enum values, it may be requisite to flag a value to not display, or to show a better description than the value itself. We can use attributes to achieve this. A description attribute is provided in System.ComponentModel. I created the Visible attribute.

{
    public class VisibleAttribute : Attribute
    {
        private readonly bool visible;

        public bool Visible
        {
            get { return this.visible; }
        } 

        public VisibleAttribute()
        {
            this.visible = true;
        }

        public VisibleAttribute(bool visible)
        {
            this.visible = visible;
        }

    }

I then set the appropriate attributes on the enum values.

public enum Role
{
    Author = 1,
    Editor = 2,
    [Description("Sales Representative")]
    SalesRepresentative = 3,
    [Visible(false)]       
    Secret = 4,
    [Visible(false)]
    AnotherSecret = 5,
    Manager = 6
}

Here’s where we can begin empowering enums. All enums can be given extension method to retrieve the value of the attribute.

public static class EnumExtensions
{
    public static bool IsVisible(this Enum value)
    {
        var visible = value.GetType()
                           .GetField(value.ToString())
                           .GetCustomAttributes(typeof(VisibleAttribute), false)
                           .Cast<VisibleAttribute>()
                           .FirstOrDefault() ?? new VisibleAttribute(true);

        return visible.Visible;                  
    }

    public static string Description(this Enum value)
    {
        var description = value.GetType()
                               .GetField(value.ToString())
                               .GetCustomAttributes(typeof(DescriptionAttribute), false)
                               .Cast<DescriptionAttribute>()
                               .FirstOrDefault() ?? new DescriptionAttribute(value.ToString());

        return description.Description;
    }
}

The great thing is that these methods work for every attribute. EnumExtensions is a helper class, but we treat these methods as belonging to the enum value.

The original post was interested in displaying friendly names which consists of only those values that are visible. In addition, we want to use the description instead of the value if it is available. This can be achieved by writing an extension method for IEnumerable<Role>.

public static class RoleListExtensions
{
    public static IEnumerable<string> DisplayFriendlyNames(this EnumList<Role> list)
    {
        return list.Where(role => role.IsVisible())
                   .Select(role => role.Description());
    }
}

This allows the test to pass, which proves that only visible descriptions pulled from the list of roles.

[TestMethod]
public void DisplayFriendlyNamesShouldBeVisibleAndFullyDescriptive()
{
    var roles = new EnumList<Role>().DisplayFriendlyNames().ToArray();
    Assert.AreEqual(4, roles.Length);
    Assert.AreEqual("Author", roles[0]);
    Assert.AreEqual("Editor", roles[1]);
    Assert.AreEqual("Sales Representative", roles[2]);
    Assert.AreEqual("Manager", roles[3]);
}

There are strengths to creating classes based on an enum. The approach I demonstrated should only be used when it is desirable to add a little functionality to enums across the board. Create classes for anything more complex. It is possible to go overboard with the extension methods and completely mimic a class from an enum… if you find yourself doing this, perhaps a class would be more appropriate.

One of the things previewed at the BUILD Day 2 Keynote was ASP.NET MVC 4, and Microsoft wasted no time in releasing a preview for developers to begin using.

I haven’t gone through the preview entirely, but there are a couple of features I should note. First, the default template actually looks good now.

I’m not a UI designer, and for my custom websites I always feel like it somehow looks rather plain. With this template, I at least feel as though my site doesn’t look dated.

Another really cool feature is bundling and minification. It’s incredibly easy to find yourself dropping in a CSS or JavaScript file and forgetting to link them in the layout file. We tend to expect it to work by convention, and the unwary developer can be caught off-guard when it doesn’t work that way. This is no longer the case. Dropping a CSS or JavaScript file in configurable locations (typically Content or Scripts) causes them to be automatically picked up and minified to preserve bandwidth.

There are many more features such as better support for mobile websites and asynchronous controller methods. Browse the release notes to see what you can expect from ASP.NET MVC 4!

Windows 8 brings a style of applications familiar to us using Windows Phone known as Metro. Although Metro Windows Phone apps were built in Silverlight, many predicted the demise of Silverlight since early previews of Windows 8 focused solely on HTML5 support. The keynote of the BUILD conference dispelled this notion by presenting us a full picture of the applications supported in Windows 8.

Windows 8 supports applications that run on Windows 7. It also supports the new style of applications even using HTML5 and JavaScript. This will open the doors to developers with skill sets not traditionally associated with the Windows developer. Accessing essential resources such as printers and services is provided over the WinRT APIs. Since the next version of the .NET framework is 4.5, it is likely that these APIs will be provided in assemblies that operate on top of the .NET 4 assemblies.

It’s interesting to note from the diagram that Silverlight is listed under supported Desktop apps, but only XAML is used under Metro style Apps. I’m not sure if this means the Silverlight brand is being dropped, Silverlight and WPF are both supported, or if metro XAML apps represent a new technology. I suppose we will discover this as the BUILD conference progresses.

Like the Windows Phone, applications can be distributed by the new Windows Store. This looked very similar to what we already have on create.msdn.com. The site to presumably sell applications in the future and to get info in the present is dev.windows.com.

Windows 8 introduces many terms such as charms. If you want to be able to talk to the talk, take a look at Windows 8 Features and Terminology. I recommend watching the entire keynote of the BUILD conference, but if you don’t have time, Todd Anglin shares the Top 10 Moments from BUILD Day 1 Keynote. Finally, keep up with the sessions through the Channel 9 site.

On another note, I just realized I will have 100 hours of videos to watch by the end of the week. Good luck!