Windows drivers for Mac come with Boot Camp installer, however they are two problems:
1. They are inside one of many installers.
2. You need to know which driver to use.

The first problem is pretty easy to solve – the installers are actually self-extracting archives, so they can extracted with WinRar. The second problem is a bit tougher to deal with and requires a bit of research, either on Windows and MacOS to try and figure out which one of the hundreds of available drivers is the right one.

Driver Details

So before jumping into recovery, and you should really do this in controlled circumstances – i.e. practice recovery, have a look at what network driver you have in Windows. Mine (15″ April 2011 MacBook Pro) looks like this:

If you are stuck and can only boot into MacOS, you look up the adapter’s details in System Diagnostics for hints about what it’s called.

Extracting Boot Camp drivers

Get hold of MacOS install DVD or download those with Boot Camp Assistant in MacOS and put them onto a USB stick. Have a browse though the driver installers(\Boot Camp\Drivers) and extract any of the ones that might sound like they contain the network adapter that you need – Intel, Broadcom and NVidia are main suspects there. In my case it was BroadcomEthernet64.exe that contained the driver in question.

Recovery

Boot into Windows Recovery CD and bring up the screen to load drivers. Navigate to the folder containing extracted driver installer and select the only .INF file there – b57nd60a.inf. You will be presented with a select driver dialog that, in the case of Broadcom, contains tons of duplicated drivers. Select second(first one didn’t work) “Broadcom 570x Gigabit Integrated Controller”.

The add driver dialog doesn’t really tell you whether or not installation was successful. You need to proceed to browse to the network location to actually find out if the driver worked. Side note: The system will not actually acquire an IP address through DHCP until you click to browse network. There is a short cut that you can take if a lot of trial and error is involved. Bring up command prompt and type in “ipconfig”. Once the driver is loaded, you will see an adapter in the command’s output.

Once the network location is available, the restore process should proceed without problems. Leave all options default (including the scary “Format partition” checkbox) – it will not overwrite MacOS partition.

Happy restoring.

So the other day I found the most useless UI detail in iPhone, and from a quick Google search, not many people found it either. It is a subtle difference in the appearance of the Shift key, depending on whether or not the word is auto-captalised or not. At the beginning of a sentence, it is slightly bolder, than if you were to press Shift yourself.

Below image demonstrates the effect:

You can easily verify this yourself by following these steps:

1. Start a new message.
2. Type in a letter – say ‘A’.
3. Press Shift.
4. Type in another letter – say ‘A’.
5. Backspace twice. You will notice the Shift key changing appearance when erasing the first letter.

Gojko Adzic, in his excellent book Bridging Communication Gap: Agile Acceptance Testing states that Waterfall projects succeed when the team has worked together before on the same kind of project a number of times and amount of discovery to be done is minimal.

And indeed, that is rarely the case. The projects that I’ve been on involved a large amount of discovery, by the teams frequently unfamiliar with the most fundamental aspects of the delivery – technology, usability, functionality and little experience working together. In my opinion, unless you have done the same thing five times over, chances are your estimate is not worth the paper it’s printed on.

There is a sentiment in the programming circles that software engineering should be a lot like other areas of traditional engineering. Yes, we have a lot to learn from those industries, but they are not immune to time and budget blowouts. Just of think of the last couple of big public infrastructure projects in your capital city that were on time and on budget.

There is one project in Sydney that has all the hallmarks of a large software project going wrong and that is Parramatta to Chatswood rail link. Surveying was complete, estimates were done, by the time the project was complete it was over budget by almost a billion dollars. After finally getting trains on the tracks it was discovered that the tunnels were a little narrow in one spot and in some trains this was causing high levels of noise. This in turn caused further delays and the need to reshuffle the train fleet.

The above example demonstrates that 100% insurance aginst unpredictable is impossible. One can always count on obstacles just popping up out of nowhere. Now, in this instance I am not advocating that the train line should be built in an agile fashion, in fact I am certin that will simply not work. However, software systems have a unique advantage over brick and mortar projects where the system is better off grown gradually over time, rather than delivered once with all the features present.

Every waterfall projects starts off with grand plans for the software to do everything under the sun. At the time when you spend a few weeks talking about what features should be in, they all seem quite achievable, and you have plenty of time, since you decide how long you need for the whole project. There alsmost is a constant factor that you need to multiply your time planning features to get the implementation time. Something in the order of 1 hour of planning gives you enough features to work for two weeks. Say 1:80. Similar to the movie Inception, if you spend a week planning features, be prepared for 80 weeks of coding.

In my experience, the first round of testing comes at a time where only half of the features intended for delivered are implemented and in turn half of those are buggy. At this time the project is kicked into a whole new phase – what I call Defect Driven Development.

Defect Driven Development (DDD for short – Hi Eric Evans :) ) is where developers only work on high priority defects as identified by QA and Business Analysts. This is really a fundamental shift in the rhythm of the project. At this point the releases to testing become closer (usually around two weeks between them), development becomes more focused and features are starting to get culled.

Come to think about it, these are all hallmarks of agile software projects:

• Prioritisation of features on nearly daily basis
• Close iterations
• Cutting scope
• Releasing with minimal set of features

I find this stage of the project the most exciting. I could be “in the zone” for days, churning out fixes and features. Some people find it stressful and annoying – to each their own. There is,however, one difference to a proper agile project – reduced responsibility on behalf of the developers. I found that “Let the testers find bugs” attitude quite common. After all, if it’s not in the bug system – you don’t have to do it.

What I found the most interesting is that inadvertently, teams slip into what Agile proponents have been advocating for a good decade now. What I would like to see is recognition that there is something natural about the above qualities of software development and integrating those practices into the project from the get go.

Just in case you are still wondering, here is a very detailed explanation of these devices are supposed to be saving you money and how they actually aren’t.

The story and the website have all the hallmarks of a scam. Here are a few:

• Most of the ACA is testimonials. The kind of testimonials that are never (sarcasm) used by snake oil salesmen.
• The Oz Power Saver website has nothing but a contact form. Not device information, how it’s supposed to work, where to buy it, regulatory information etc.

My understanding of Power Factor correction from nlcpr website really boils down to this:

Capacitors can be used to intercept the reactive power from inductive motors, and return it to the source on the next cycle. However, if the capacitors are at the service entrance or utility panel, they will do nothing to reduce I2R losses in the wiring between the panel and the motor. In order to eliminate line losses, the power factor correction device must be mounted at the inductive load.

This means that whilst a power factor correcting device can save you money by lowering current and reducing heat losses in the wiring of your house (in the order of cents per year), mounting it at the meter does nothing. This is where Oz Power Saver can be called out to be absolute 100% scam.

The default out of the box setup for doing the above is not too tricky, however Team Build has stricter test pass criteria, so it is important to get both coverage and SpecFlow features with non-implemented steps to not return any errors.

Code coverage for MS Test projects

Problem: Collecting code coverage data.

Once your solution has at least one MS Test project, there will be a .testsettings file created. Double click it and go to Data And Diagnostics > Code Coverage(Check Enable) > Configure. Select your projects and you are good to go.

Once that is done, every time a test is run, code coverage data will be collected. To show the results, simply click the Show Code Coverage Results button in the Test Results window.

Coverage for ASP.NET MVC projects

Problem: ASP .NET projects cause a test run error that looks this:

Cannot initialize the ASP.NET project 'Project'. Exception was thrown: The web site could not be configured correctly; getting ASP.NET process information failed. Requesting 'http://localhost:5803/VSEnterpriseHelper.axd' returned an error: The remote server returned an error: (500) Internal Server Error.

The problem, as I understand it, is to do with misconfigured Development Web Server (Cassini) that does not properly expose a helper handler for profiler to collect code coverage data. Not ever having used ASP .NET MVC specific features in MS Test (like [UrlToTestAttribute]), I simply removed all those attributes and removed that project from test coverage.

Next, in order to collect code coverage I simply added the MVC project DLL and the problem went away. By default, code coverage does special handling for MVC projects to instrument them as websites (which also causes the web server to start up and slow down the test run). If you then add the MVC project’s DLL, it’ll run with no issues.

SpecFlow features

Problem: SpecFlow features with non-implemented steps fail build. When a step in a feature is not implemented, the default implementation makes the test inconclusive. This is fine when run locally, but will fail a Team Build build.

There are a number of solutions that I have profiled before settling on adding @ignore attribtue to every feature that hasn’t been implemented.

1. Set Team Build to not fail build on unit test fail. I rejected this as there shouldn’t be a state where there are failing tests in a build. If a build fails, the culprit will have more incentive to fix a failing build than a simple statistic from TFS saying x per cent of tests are failing.

2. Create a test list and white list the unit tests that should be run during Test Build (by specifying the list name as part of Team Build configuration). This is fairly robust in the way that adding a new feature and not disabling it will not fail the build, however the overhead of having to add every unit test that you write to the list is too much. Chances are, developers won’t do it simply because there is nothing guiding them to have to do it.

3. Disable all SpecFlow tests from test list editor. As with above approach, the overhead of opening up test list window and marking a SpecFlow test as disabled makes for a bad team process. Also, the test lists tend to get unwieldy as the number of them grows and because disabled tests are referenced explicitly from withing the .vsmdi file, removed test will stay there and will pollute the view.

4. My preferred way. Use SpecFlow @ignore attribute to disable the feature/scenario. The advantage over the above approach is that the fact that the feature is disabled lives in the feature file, not in the .vsmdi file. The business analysts still need to mark them them disabled, but the amount of friction is slightly less to make the process workable.

In Order to get SpecFlow unit test generator to spit out attributes, you will need to edit specflow.exe.config to look like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow"/>
  </configSections>

  <specFlow>
    <unitTestProvider name="MsTest.2010" />
  </specFlow>
</configuration>

In conclusion

Hopefully, with these simple tips, you will be able to fine tune your CI environment using TFS to eliminate the little niggling things that take hours(days, in the case of MVC coverage issues) to resolve.

So, as part of my training, I have been running to the gym in Saturdays sometimes – about a 10 km round trip. On one of those trips I decided to pop into the Harvey Norman, which is an electronics store, and grab a Turbine Head for my vacuum cleaner.

The reason I wanted one of these is because two giant border collies make the carpet in our house gets real hairy real fast.

The store had the vacuum attachment that I was after but it was a lot bigger than i anticipated. I thought it would fit into my backpack, but it was at least twice the size of it. So I ran back home carrying it in my hands. I must have looked ridiculous :) but I got there in the end.

Of course, the Turbine Head didn’t fit. I took it back to the store and the salesperson apologised profusely, which he shouldn’t have, because I could have easily looked at the box and figured out that it doesn’t fit my model. He got on the phone to Dyson and had me talk to them. The Dyson person said that the turbine head for my model is generally not available from retail stores and I have to order it from them. Fair enough, at that point I wanted to give them my credit card number to which the Dyson person said no need, I already paid for it at Harvey Norman.

Mildly confused I got off the phone thinking that Dyson and Harvey Norman will work out who pays for what between themselves and relayed the conversation to the salesperson. He got confused as well, thinking that what they did was offer it to me for free, as he would give me a refund. That surely didn’t make sense to me as that means Dyson is sending me a free $130 part.

At point we got on the phone to Dyson again to figure out what’s happening. Long story short, they are sending it to me for free. Just because I wanted it. Unbelievable. Let me stress that the part didn’t not originally come with my vacuum, it was an optional accessory. Let me also stress that Dyson full well knew that my vacuum didn’t come with a turbine head as I gave them its serial number.

The thing arrived in the mail merely two days after I spoke to them and I am still somewhat shocked that they would just send this $130 part to me for free. In my books, this makes Dyson the most awesomest company in the world.

So how does that make my Dyson a better smartphone than iPhone 4? Well, by now we all know about iPhone 4 antenna brouhaha. My take on this is that the issue is real but fairly insignificant, depending on where you are. It took Apple, however, weeks of media assault, not helped by Steve Jobs’ snarky emails to finally offer the crappy $30 bumper cases for free to the iPhone 4 customers.

Now, there is a gulf of difference between the $30 phone case (which probably costs 30c to manufacture) and a $130 vacuum head (which probably is worth $10-20). Not only that, the vacuum did not have a design flaw, it was simply the wrong implement for my particular case. Yet Dyson sent it to for free, for no other reason than I wanted it. Unlike Apple, who had to bow in to the pressure of Consumer Reports with the whole free bumper thing.

So there, if Dyson was in the market of making phones, I would buy one instead of Apple’s counterpart. Oh and from preliminary testing the turbine head totally works on our carpets.

Today I had to convert a binary expression to a lambda and then use in a where clause on a collection. Easy enough, I thought, make an ExpressionLambda, compile it, substitute it into the where clause, no worries.

This is the first cut of the code:

public class ClassWithProperties {
    public string Prop { get; set; }
}

static void ExpressionCrashes() {

    var expr = Expression.Equal(Expression.Property(Expression.Variable(typeof(ClassWithProperties)), "Prop"), Expression.Constant("value2"));

    var props = new[] { Expression.Parameter(typeof(ClassWithProperties)) };
    //Throws <variable '' of type 'SOCSTest.ClassWithProperties' referenced from scope '', but it is not defined>
    var lambda = Expression.Lambda<Func<ClassWithProperties, bool>>(expr, props).Compile();

    var items = new List<ClassWithProperties> { 
        new ClassWithProperties{Prop = "value1"},
        new ClassWithProperties{Prop = "value2"},
        new ClassWithProperties{Prop = "value2"}
    };

    //Should return <"value2", "value2">
    items.Where(lambda);
}

The expression is a basic one – it calls an equality comparison on a property off an object and a constant. It is equivalent to this:

value.Prop == "value2"
//Where value is a parameter of type ClassWithProperties

Googling for this exception and just general expression and lambda stuff kinda hints at people having the same problem as I am but with no fast solution. It was Jon Skeet’s answer to question I didn’t understand on StackOverflow that finally put me onto the right track.

In order to compile a lambda from an expression, you need to provide all instances of ParameterExpression that appear in the expression tree when creating a lambda expressionn (i.e. when calling Expression.Lambda<T>(Expression, params ParameterExpression[])). The Expression engine will not match types and names parameters in an expression – as far as it’s concerned different instances of ParameterExpression are discrete parameters.

Rewriting the above code yields something that doesn’t crash:

static void ExpressionWorks() {
    var variable = Expression.Variable(typeof(ClassWithProperties));
    var expr = Expression.Equal(Expression.Property(variable, "Prop"), Expression.Constant("value2"));

    var props = new []{ variable };
    var lambda = Expression.Lambda<Func<ClassWithProperties, bool>>(expr, props).Compile();

    var items = new List<ClassWithProperties> { 
        new ClassWithProperties{Prop = "value1"},
        new ClassWithProperties{Prop = "value2"},
        new ClassWithProperties{Prop = "value2"}
    };

    //Returns <"value2", "value2">
    items.Where(lambda);
}

As you can see, we reused the instance variable in both expression declaration and Expression.Lambda call. Everything works fine now.

Getting the parameters from Expression at runtime

My situation was such as that I had to deal with an already created expression. So I couldn’t simply take the variable parameters that are used to create an expression and reuse them when creating a lambda. The solution was to traverse the expression tree and get a list of all the ParameterExpression instances that are contained in the expression and pass those to Lambda function.

Luckily, ExpressionVisitor API provides an easy way to achieve this. All you have to do is inherit from ExpressionVisitor and implement one function to trap all the goodies we need:

public class ParameterVisitor : ExpressionVisitor{

    List<ParameterExpression> m_Parameters;

    public IEnumerable<ParameterExpression> GetParameters(Expression expr) {
        m_Parameters = new List<ParameterExpression>();
        Visit(expr);
        return m_Parameters;
    }
        
    protected override System.Linq.Expressions.Expression VisitParameter(System.Linq.Expressions.ParameterExpression p) {

        if(!m_Parameters.Contains(p))
            m_Parameters.Add(p);
            
        return base.VisitParameter(p);
    }
}

We can even create an extension method to hide all complexity of creating a lambda:

public static Func<TSource, TResult> CreateLambda<TSource, TResult>(this Expression expression) {
    var visitor = new Bluecap4.Core.Expressions.ParameterVisitor();
    var parameters = visitor.GetParameters(expression);
            
    return Expression.Lambda<Func<TSource, TResult>>(expression, parameters).Compile();
}
//Usage
static void ExpressionWorks() {
    var expr = Expression.Equal(Expression.Property(Expression.Variable(typeof(ClassWithProperties)), "Prop"), Expression.Constant("value2"));

    var items = new List<ClassWithProperties> { 
        new ClassWithProperties{Prop = "value1"},
        new ClassWithProperties{Prop = "value2"},
        new ClassWithProperties{Prop = "value2"}
    };

    //Returns <"value2", "value2">
    items.Where(expr.CreateLambda<Func<ClassWithProperties,bool>>());
}

Nullable is a value type

It’s a struct that can be null. The only reason why int? intVal = null; compiles is because C# compiler supports nullable types. You cannot define the same kind of struct yourself.

The decision to make Nullable<T> a value type actually makes sense if you think about it. Calling its member methods and properties will always succeed, i.e. NullReferenceException will never be thrown. This gurantees that HasValue never throws a NullReferenceException.

Comparison to null

Under the hood, the compiler, in fact translates comparison to null to a call to HasValue. The below MSIL demonstrates that:

    .locals init ([0] valuetype [mscorlib]System.Nullable`1<int32> 'value',
           [1] bool hasvalue,
           [2] bool hasvalue2)

    //int? value = null;
    IL_0001:  ldloca.s   'value'
    IL_0003:  initobj    valuetype [mscorlib]System.Nullable`1<int32>
    //bool hasvalue = value.HasValue;
    IL_0009:  ldloca.s   'value'
    IL_000b:  call       instance bool valuetype [mscorlib]System.Nullable`1<int32>::get_HasValue()
    IL_0010:  stloc.1
    //bool hasvalue2 = value != null;
    IL_0011:  ldloca.s   'value' //loads a variable onto evaluation stack
    IL_0013:  call       instance bool valuetype [mscorlib]System.Nullable`1<int32>::get_HasValue() //calls HasValue
    IL_001b:  stloc.2 //Stores the result in location 2 (hasvalue2)

As you can see the generated IL for hasvalue = value.HasValue and hasvalue2 = value != null are identical.

null Assignment

Also from above code you can see that assigning null to a nullable value is the same as calling the parameterless contructor (which all value types have).

Ternary operator

C# compiler also does special things with ternary operator for nullable types. The following code compiles:

int? nullableIntVal = 4;
int intVal = nullableIntVal ?? -1;

The above is just syntactic sugar for calling HasValue and if it’s true calling GetValueOrDefault(). The compiler actually generates a temporary variable to call HasValue off in both Release and Debug modes. Not sure why that is. Below code illustrates the equivalent C# code to what the compiler generates for ternary operator.

int? nullableIntVal = 4;
int? temp = nullableIntVal;
int intVal = temp.HasValue ?? temp.GetValueOrDefault() : -1;

Summary

Nullable<T> is a special value type that has support from C# compiler to allow the following:

• null assignment – under the hood: calling defualt constructor.
• null comparison – under the hood: calling HasValue property.
• ternary operator ?? – under the hood: calling HasValue and conditionally GetValueOrDefault.

Application

The application in question is a fairly normal case of a business DSL where the domain rules are expressed in XML and the compiler generates an application for different platforms (web, mobile web, PDA, WPF). Code is written in C#, tested with MbUnit v.3 and NMock2.

This particular class parses XML and generates JSON to be later consumed by ExtJS library. The JSON is a declaritive form of the control that users will eventually see. This control is complicated and has many options. Hence the fatness.

Enter the unit tests

Now, unit tests are touted to be great for refactoring. They are. The usual approach is to write the tests, make sure they pass, then refactor and make sure the tests don’t break. Well, I want to take it one step further and let the writing of the tests guide the refactoring.

Thoroughly unit tested code tends to have really good code smells. This is mainly due to fact that in order to test all aspects of a large block of code, you must isolate all of its constituents. This is evident in all projects that are written in a TDD way. They are all very modular and modular is good(I think :-) ).

So my goal here is just simply write the unit tests and see where it takes me. I would imagine that just by making the code testable, it will become a little bit better.

I never invisaged this to become a full blown article, but now that I am here, lets introduce some numbers to make this more scientific. I will be using Microsoft Team Studio Analysis Tools throughout the process. Here is a snapshot of what the class looks like at the start:

As you can see the Build method is too big – 250 lines. This is bad. It’s one of those DoIt methods that does everything.

First refactor

Alright, lets get cranking. Straight away I noticed that I was reading a particular bit of XML and making decisions based on the node contents. This particular functionality has already been abstracted away in another class, so I might as well use that class. So I just refactored that without writing any tests before or after. That’s pretty naughty :)) Lets make it proper and rip this code into another function so we can test it.

Starting from the top of the method I am looking at a bit of code that parses an atribute and calls a method that is defined in the base class depending on whether or not the attribute exists.

Base class dependency

Now refactoring that into a method is not a problem, the problem is isolating the call to the base class. There is case to be made for having the base class contain all the dependencies that are required for all of its subclasses, however, just by skimming the code it looks like a lot of the methods there are simply in one place for convinience. So this could potentially be a case of Inheritance vs. Composition. Lets start off by abstracting this particular method into an interface and have our base derive from the interface. Then in our derived class we access that method through a reference to the interface, not implicitly.

This is what it looks like now:

class Builder {
   public DoStuff(string blah){
      //impl
   }
}

class GridBuilder : Builder{
   public void Build() {
      var elem = Element.GetAttribute("Blah");
      DoStuff(blah);
   }
}

Let’s tweak it as described in the previous paragraph:

interface IBuilder {
    DoStuff(string blah);
}

1
class Builder : IBuilder {
   [Obsolete]
   public DoStuff(string blah){
      //impl
   }
}

class GridBuilder {
   
   IBuilder _Builder;
   
   public GridBuilder() {
     _Builder = this;
   }
   
   public GridBuilder(IClientBuilder b) {
            m_ClientBuilder = b;
    }
   
   public void Build() {
      var elem = Element.GetAttribute("Blah");
      _Builder = DoStuff(blah);
   }
}

So what I have done is put that DoStuff into an interface and marked the implementation as Obolete. This is more out of convinience to get the compiler to show me where else this method is being used. Turns out this was the only case where it was used in GridBuilder. I could have just as well used text search, but hey, if there is a fancy compiler feature, why not use it? Notice that I also added a dependency constructor so I can compose GridBuilder in a unit test.

Let's make a unit test for this use of DoStuff. As I am doing that I realised that my base class is in a different assembly and required some code duplication from another test project to make the test not crash. The fact that I had to do that is a pretty bad, but my copying the common setup file and including it in my test project is even worse. We can come back to that later, lets concentrate on what we are doing now. Might as well use the Obsolete attribute to remind me to refactor the unit test later on.

Finally, I can test Build

So, after a long time setting up GridBuilder's dependencies I am finally here - the test runs. Lets review what I've achieved so far and have a peek at the metrics. So here is the summary of what was required just to make the test run:

• Two instances of referring to the base class have been abstractes into two interfaces.
• Found a bug where if a required element is present but contains no nodes the builder crashes.
• The test creates a total of three mock objects with a total of five Stubs and one Expect.
• The test needs to pass in an Xml element with two elements and one atribute.
• Found a small refactoring job that is not really related to the unit testing aspect of this excercise.

Code metrics:

So I didn't get anywhere as far as most metrics are concerned, in fact I almost went backwards, if anything. Let's keep going. So now I have a unit test that runs the Build method lets keep trying to test more and more parts of it.

Before I go on, I would like to emphasize the fact that I had to create lots of mocks and pass in lots of dependencies just to make one method not crash. Here is the unit test. Definitely too much for ONE method:

        [SetUp]
        public void Setup() {
            m_Mocks = new Mockery();
            m_Settings = new InlineBuilderSettings {
                Compiler = m_Mocks.NewMock<IWebCompiler>(),
                ComponentName = "Test"
            };
            //Used by setup method
            Stub.On(m_Settings.Compiler).GetProperty("ServerCompiler").Will(Return.Value(null));
            Stub.On(m_Settings.Compiler).GetProperty("ServerType").Will(Return.Value(typeof(Data.ServerAplication)));
        }
        
        [Test]
        public void BuildShouldCallRequireComponentWhenViewAttribute() {

            var iClientBuilder = m_Mocks.NewMock<IClientBuilder>();
            var iBuilder = m_Mocks.NewMock<IWebBuilder>();

            Builder builder = new Builder(iClientBuilder, iBuilder);
            m_Settings.Element = 
                new XElement("Grid", new XAttribute("View", "test"), 
                    new XElement("Source", new XAttribute("View", "DataTest")),
                    new XElement("Fields"));

            Expect.Once.On(iClientBuilder).Method("RequireComponent").With("test", m_Settings.Element).Will();
            Stub.On(iClientBuilder).Method("GetComponentInfo").Will(Return.Value(new ComponentInfo()));
            Stub.On(iBuilder).Method("AddConfig").Will();
            Stub.On(m_Settings.Compiler).Method("AddInclude").Will();
            
            builder.Setup(m_Settings);
            builder.Build();
        }

Realistically, in order to complete the build process we need all those dependencies. That's pretty fundamental. However, it should be possible to reduce the amount of dependencies ONE method has.

Next refactor

My next target was a reasonably self contained code block that I did "Extract Method" method on. Two more unit tests. Slight improvement in maintainability and complexity.

Next one is a big sucker. This block produces about 5 output objects that are dumped to JSON later on. I actually moved to another two classes. One to perform the build and another to store the output.

Good improvement on all counts. Lets keep splitting the Build method and writing tests for it. As I am doing this I decided to make the GridBuilder a namespace within a project. There are a number of classes in it by now, might as well contain them in a folder.

Day later.

I have somewhat abandoned refactoring GridBuilder as I found a whole bunch of other tightly coupled classes. The unit tests have proven to be a great tool exposing those dependencies. They also become usefull when the refactoring becomes non-trivial - i.e. goes beyond just moving a block of code out of a method.

This is what the class looked like once I finished with it:

Now that I ran out of time that I gave myself for this task I think I have a few notes for future.

• Parsing an XML collection is ugly and tends to get messy when things need to be addded to the inner loop. I think for this scenario I would need some sort of visitor pattern implemented so that you could add things to the inner loop without having to alter the loop itself.
• Having implicit dependencies (like a dependency on a property of an actual dependency) totally breaks the unit tests. A situation where you create one mock and then have its method return another mock is a bit ridiculous.
• A unit test for a monstrous method will too be monstrous. There is almost 1-to-1 relationship between how fat the method is and how fat its unit test is. I think that if one aims to make unit test simpler, the code under test will in turn become simpler.

I would like to start off by comparing programming languages to spoken languages. Most will agree that the comparison is fair. Programming languages bear most hallmarks of real life languages. There is syntax, grammar, dictionary, there are historical reasons for why the language the way it is, etc. Generally speaking one is most fluent in their native tongue and could deal with a couple of others. Similarly in programming you have your native language – C family, VB, Pascal, Ruby, Python, Perl, hieroglyphics(PHP) etc.

My native language is Russian and that’s what I grew up with. From a reasonalby early age I learnt English and was reasonably fluent in it as a second language. I would like to equate this SECOND language to your FIRST programming language. The similarity, for the sake of this post, is that you think in your native language and translate it into code. The process, as those who speak other tongues would know, is similar. You form what you want to say in your head, translate all the words into the other language, rearrange the sentence if the target language requies so and then produce the output.

As with a second spoken language, writing programs eventually becomes second nature. Enter third (spoken) langague, e.g. French, that I learned in school. I found that my brain was stuck in this binary Russian/English mode and I could not add French to the mix, so my French was coming out very English like.

This is the problem I am facing with F#. It is SO compltely different that my C/C++/C#/Whatever-happy brain does not accept it. If comparing to spoken languages, it’s even further away from C than French is from English. It’s more like Japanese, where both the alphabet and the mindset are different.

So, coming back to the point of this dribble. I like words. I like the explicitness of procedural languages. I think it tends to follow how one thinks. if statements, while statements, assignment, parameter passing – they are all very logical.

My biggest hurdle understanding F# is the fact that the same syntax can be used for instantiation and matching. For example defining a function that takes a tuple with two members:

let func (a, b) = printfn "a: %d, b: %d" a b;;

The syntax is the same as when you define a tuple:

let tuple = (4, 5);;

Wheres a, say C++ would do something like this:

Tuple<int, int> = new Tuple<int, int>(4,5);

void func(Tuple<int, int> tuple) {
}

F# seems to just use all these symbol operators for everything and I just can’t let go of my attachment to words. List.Add is logical, [4;5;]@[6;7] is less so, especially considering that the operands cound be either values or lists.

Speaking of words, here is some lingo that you will undoubttedly come across as you learn a functional programming language. The list is not complete and some words are not simple definitions, but quite complex concepts – like combinators – those will make your head hurt extra good :))

• High Order Function – Function that can take functions as parameters and/or return a function
• Curried function – High Order Function that binds one or more of the parameters to a predetermined value and returns a function that takes less parameters.
• Purity – Functions not having side effects – i.e. the function produces an output without chnaging the input or modifying state somewhere else. This normally invoves using immutable data structures and combinators.
• Cons operator (::) – Adding an element to the beginning of the list.
• Strictness – Evaluating parameters to the function before the function is evaluated.
• combinator – High order function that has no free variables. Short version is that this function only operates on its parameters, not any other functions or values defined elsewhere.
• Memoization – Remembering the result of a slow running function for future use (Caching).
• Imperative programming – “normal” programming – i.e. Procedural, Object Orientated, etc.