Book Review: Brownfield Application Development by Kyle Baley and Donald Belcham

Brownfield Application development in .Net is a book I wish I had on my bookshelf when I started programming 8 years ago.

Through a conversational tone, similar to pair programming, the authors expose both the simple and challenging aspects on not only how to work with a legacy code base, but how to start a new project ‘right’ from the beginning.

The book is cleanly divided into two sections, the first covers the organic processes of software development filled with proven practices and real world scenarios to drive points home. Also discussed are ways to communicate these ideas with your team, sponsors and customers, which is a commonly neglected topic in software development literature.

The second section shows practical code examples that clearly describe the necessary steps, techniques and designs to meet the ‘abilities’ of clean, maintainable code. Maintainability, Testability, Adaptability, Readability, Extensibility and Reversability. Another highlight is the constant referral of ‘back to the basics’ as described in the first section when some of the more challenging ideas are explained.

As with most software development books where you read once and maybe crack open again as you navigate backwards from the index, this book is one that will stay on top of your book pile.

Whether you have been programming for 30 years or a journey man, this book will be an invaluable resource.

Oh, those pesky semi-colons!

I have a great fascination on the origin of things, whether it is the current set of books I am reading about early American history₁, or the various nostalgic videos on the beginnings of Microsoft, or even the posts by Andy Hertzfield on the early beginnings of the Mac. C is a language that has that same nostalgic appeal to me as well. It's the pre-pre cursor to C#, the language I actually get paid to write in. In life's continual twists, I am now on a team that has some applications that interface with C and C api's. Most people I mention this to reply, "ugh.. you have to learn C?!?!?" But to me, it's something to learn and since C is the predecessor to C#, it scratches my itch for learning about the origin of things.
On a recent trip to my local public library there is a shelf for free books, and to my amazement, there was a copy of Problem Solving & Program Design in C. Sarcasm aside, I couldn't understand why it was still there for my taking. In the chapter on arrays, there is a simple program on writing a stack, I added a print function to this program to list all the elements.

This code compiles, but when I ran it, I only saw the last element in the array. Hmmm...strange. I fooled around a little adding some extra printlines, check some other code snippets and I can't find what is going on!
Eventually, after a day or so, what was wrong was I had a semi-colon at the end of my for loop declaration. The C compiler accepted this code as valid code and when my program ran, the for loop looped over itself, never proceeding into my brackets until i <= *size was actually true, then only printed the 3rd element in my array!
To me, there are several thoughts I took away from this little problem.

• What a great lesson to enforce really reading your code before you execute.
• An increased appreciation for the C# compiler to not let me even make that mistake in C#. (The compiler gives you a warning.)

I would love to see what comments, if any, others have on the merits of learning C, really learning C, when your primary programming language is C#. Personally, I see merits in knowing/learning this language if not for the only habit to slow down and really read my code.

---

₁If your looking to get a nice start on early American History, I suggest the following:

• John Adams by David McCullough
• 1776 by David McCullough
• Benjamn Franklin by Walter Isaacson
• Founding Brothers by Joseph Ellis

These authors have written several additional books, but these are great primers on the subject.

Haskell - Lists

Haskell - Lists
Lists in Haskell are defined by square brackets, [].  In ghci, declaring a list is as simple as:

Prelude> [1,2,3]
[1,2,3]

Lists can be of any length, indeed you can type in the following (although I wouldn't recommend it!)

Prelude> [1,2, .. ]
[1,2,3,4,5,6,7,8,9,10,11,12....]

To create an empty list, type the following:

Prelude> []
[]

Lists must be all the same type, if we try to declare a list with the following, we will get an error

Prelude> [1,3,5,7,"nine"]

<interactive>:1:7:
No instance for (Num [Char])
arising from the literal `7' at <interactive>:1:7
Possible fix: add an instance declaration for (Num [Char])
In the expression: 7
In the expression: [1, 3, 5, 7, ....]
In the definition of `it': it = [1, 3, 5, ....]

What the interactive session is telling us here is there is a type incompatibility between Num and [Char] and suggests some possible fixes.
Operating on Lists
To concatonate two lists you use ++

Prelude> [1,2,3] ++ [4,5,6]
[1,2,3,4,5,6]

To add an element to a list use the cons operator :

Prelude> "Nate" : ["Bill","Ted","Stephen"]
["Nate","Bill","Ted","Stephen"]

List Comprehensions
List comprehensions are really a thing of beauty, although, the Haskell Wiki labels them as syntatic sugar.  I think they add an element of beauty and simplicity.  Comprehensions follow the basic syntax₁:

[ e | q₁ .., q_n], n >=1
where the q₁ qualifiers are:

1. generators:  p <- e, where p is a pattern of type t and e is an expression of type t
2. guards: an expression that evaluates to a bool
3. local bindings: provide new definitions for use or subsquent generators or guards

Here's an example of how to generate a list of all even numbers between 1 and 50 using comprehensions:

Prelude> [ x | x <- [1 .. 50],even x]
[2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50]

Granted, you can accomplish the same thing using arithimetic sequences:

[2,4 .. 50]

But take a look at how to solve Project Euler question #1 with list comprehensions:

Prelude> foldr (+) 0 [x | x <- [1 .. 999],x `mod` 3 == 0 || x `mod` 5 == 0]

Breaking down this line into parts,
Prelude> foldr (+) 0 [x | x <- [1 .. 999],x `mod` 3 == 0 || x `mod` 5 == 0]
x <- [1 .. 999] is a generator, it's using an arithimetic sequence to get all the numbers between 1 and 999.
Prelude> foldr (+) 0 [x | x <- [1 .. 999],x `mod` 3 == 0 || x `mod` 5 == 0]
x `mod` 3 == 0 || x `mod` 5 == 0 is a guard or predicate.  Only when this expressions is true is it "passed" to the new list.
Prelude> foldr (+) 0 [x | x <- [1 .. 999],x `mod` 3 == 0 || x `mod` 5 == 0]
x is the new list of all the numbers between 1 and 999 that satisfy the predicate.  Then, x becomes part of the last expression, the foldr function.
foldr, or reduce, applys the the operator + in this case to the seed value 0 and each element in the list.

---

Learning Haskell

Why am I learning Haskell?
There are several different answers, but there are a few that stick out more than others.  While I was learning F# and making my way through ProjectEuler problems, I was getting frustrated with running into type issues.  Here I was looking at some beautiful, clean and consice code, and then watching it get all cluttered up with F#'s casting syntax.₁
Another reason is when I finally solved a Euler problem and quite proudly submitted my solution, I would browse the other F# solutions and became dissapointed with what some others where submitting.  I was looking at F# syntax, but it was all procedural style.
F# is a great language and I really enjoy writing with it, and will continue.  However, I wanted to learn functional programming on a language that doesn't allow me to break the rules.
Getting Started with Haskell
I am using the GHC implementation, which can be downloaded here.  With the download you get three components:

• ghci - an interactive interpreter
• ghc - compiler
• runghc - runs Haskell programs as scripts

My examples will be in ghci, but I'll note when I switch.  My development environment is a Mac, so the command window is the bash shell.
After installing Haskell, launch Terminal and type in ghci:
$ghci
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude>
Once the ghci is loaded, we see several libraries being loaded, ghc-prim, integer and base. Details on these packages can be found here.
The Prelude> prompt means the prelude library is loaded, sort of shorthand for the prelude 98 standard.  Like other Unix shells, what you see for the prompt is configurable, but I"ll leave the default.
One of the more import things to remember when you are starting is, :? This will list commands available from the prompt.  To execute an operating system or shell command, type in :! So to see what directory you are, type in
Prelude> :!pwd
/Users/nathanhoellein/HaskellProjects
To change directories, you need the :cd command.
Prelude> :cd ./ch03//
Prelude> :!pwd
/Users/nathanhoellein/HaskellProjects/ch03
Another command that's interesting is
:browse
It lists all names loaded by module.
Interactive Haskell

The ghc interpreter functions just like the F# interactive console, you can type in code snippets and perform arithmetic, except you don't have to end each line with ;;.
You can perform calculations using infix or prefix syntax:
infix:
Prelude> 2 + 3
5
prefix
Prelude> (+) 2 3
5
Integers can be large, see what happens when you want to know what 2 ^ 100 is:
Prelude> 2 ^ 100
1267650600228229401496703205376
Whereas in F#, you have to use doubles and you get a little different output:
> 2.0 ** 100.0;;
val it : float = 1.2676506e+30
What I find pleasing is you can see F#'s roots, the keyword "it".
The "it" variable sort of holds on to the last expression that was evaluated.
Prelude> 2 ^ 100
1267650600228229401496703205376
Prelude> it
1267650600228229401496703205376
We see the same in F#:
> 2.0 ** 100.0;;
val it : float = 1.2676506e+30
> it;;
val it : float = 1.2676506e+30
Other arithmetic stuff within Haskell:
Prelude> 2 - (-8)
10
Prelude> 2 + (-8)
-6
And booleans:
Prelude> True || False
True
Prelude> True && False
False
Like basic algebra, order of operations matter:
Prelude> (1 + 3) ^ 4
256
Prelude> 1 + (3 ^ 4)
82
That's a nice start for now, next post I'll cover lists.

---

₁ - Yeah, I know it's really the .Net runtime

Test faster with Tools

With the release of TestDriven.Net version 2.16, you can now run your F# unit tests within Visual Studio. Prior to this version, I would execute my unit tests via NUnit-Gui, or xUnit's command line utility. Both tools are wonderful for handling unit tests, but like most, if not all programmers, I am lazy. I was getting very tired of switching windows. I even wrote my own small testing harness, here but I still had to fuss around with switching windows.

I do realize that all it took was a simple keystroke combination of alt-tab, but waiting for my machine to re-paint the windows and the tools to re-load the new assembly became tiresome. To add to my laziness, in order to run my tests when in C#-ville, I assigned keystokes TestDriven.Net run tests method, I didn't even have to use the mouse! Resharper is another tool I use when I am programming in C#-ville, although Resharper has not yet made it way in to the F# world, there are still parts of the tool you can use. Consider the blank F# page, when you start a new project. All you get is:

#light

Not much here to get you started. So I created a ReSharper Live Template called "fixturef".

When I press the tab key, I get the following:

Viola! I don't have to type any of the setup structure to get my base Test Fixture!

Wait, there's more!

I also created another ReSharper Live Template, called "ftest":

When I press tab:

Viola! All I have to do at this point is type the rest of my test methods name.

By now, I know you're now asking yourself, "it can't possibly get any lazier", but oh yes, it can!

When I actually have to type some code to get a unit test ready to run, I got tired of having to reach the 10 inches for my mouse and perform a series of point-and-click operations. TestDriven.Net provides commands that you can assign keyboard shortcuts to. In Visual Studio, go to the options screen and select Keyboard. In the command name text box, start typing TestDriven. There are a series of commands to invoke TestDriven.Net. I assigned the ctl-alt-shift-T keystroke to the TestDriven.Net.RunTests command.

So now when I have a test to run, I can press ctl-alt-shift-t and invoke TestDriven to run my tests. No more window switching, or mouse-clicking!

You get a nice message in the status bar of Visual Studio, letting you know the status of your test run.

Oops, one test failed, all I have to do is use the ctl-tab keys to switch between documents in Visual Studio and I see the results of my tests in the Output window.

Enjoy my laziness!

Wow – What a trip. F#, C#, TDD, COBOL and enlightenment

Life truly has a fantastic humbling ability. A few months ago I was in the midst of a deep dive, swimming in the goodness of F#. I had all sorts of wonderful ideas on future blog posts. I was treading in a veritable pool of functions, records, pattern matching, currying; all while not getting bogged down in semi-colons and missing curly brackets! I was on top of the world.

Then life reminds you what is truly important, my wife and I were blessed with our 3rd child at the end of May. What a wonderful addition to our family. So after one month of anxiety waiting for the baby to arrive and then another two months of interrupted sleep, burping, changing diapers and worrying about poop, (those of you with kids understand!) my thoughts never strayed too far the pool. So here I go, with a great big cannonball, I splash back into the blog waters. It was during those few months out of the pool, when my only concentration on coding was in C#-ville from 9 to 5, several statements of a profound nature crept into my head. I have been long since spoiled on the benefits of Test Driven Development (TDD); write a test, write some code, make the test pass, refactor, run tests - beautiful simplicity.

As simple as that is, one of my co-workers would always write extra code; code that was not needed to make the tests pass. He could not bring himself to just write the simple code that made the test pass. I would always ask the question, why did you write that? The test would still pass if that block was not there.

His reply was always, "We'll need it soon." Rather than argue, because he would be right, and delete the code he had written, we would go on our way and complete the task at hand. (By the way, when teaching TDD to someone new, deleting code that has no coverage is a great way to enforce the rule that you shouldn't write any code that is not a result of a test!)

So one day, our group was having a small discussion while taking a break from coding and talking about past jobs and different languages we knew. This guy mentioned he programmed COBOL for several years prior to migrating to java and C#. While I snickered and mentioned my own experience with COBOL; a mere two semesters in college and a professor that couldn't code, he laughed and said, "you had to be careful about your code, if you had a bug, you could crash the entire system for everyone". So after my casual chuckling, I repeated his statement and added something to the effect of, "wow, I would have surly pissed of a lot of other developers, my code is always buggy, I rely on tests to find them, not the final run." As soon as I said that, the little light switch in my head clicked and I then realized why our coding styles were so different, why he just couldn't write the simple code and trust the tests.

Being faced with the situation of crashing an entire mainframe, COBOL developers, at least this one, had to make sure the code was sound before submitting your code to the queue. Comparatively speaking, if I crash my system, 1 person is down for a little while, but if you take down an entire mainframe region, there's a little more impact. (I am not picking on COBOL developers here, it's just part of the story.)

Compare that to TDD, where my mindset is, "hey, if I refactor this chunk of code into a method, these two other block are the same, and could be made a delegate. Let's try that!" Or, things like "I don't like that switch statement, lets make it a dictionary". Compile, Run Tests…. oops, the entire test fixture fails, oh well, ctl-z.

This tantalizing story leads me up to these few points:

Profound statement #1: TDD is an incredible gift. Having a series of unit tests gives you the confidence and comfort to try really crazy things with your code. It also gives you the ability to enforce some of the higher level design patterns to make your code truly awesome; open closed principle, single responsibility, Liskov substitution principle, to name a few.

Profound statement #2: TDD has made me lazy. I let my tests find my bugs.

Profound statement #3: TDD has made me confident. I realize that this statement might conflict with statement #2, but mixing of these traits just makes me smile. If my QA tester finds a bug, I can write a test to re-produce the issue and can guarantee that bug will not surface again.

Profound statement #4: You need productivity tools like ReSharper and TestDriven .Net. Not to sound like a commercial for ReSharper, but man, that stuff is like crack! When you combine those tool suites, with your IDE, you can do really fun things when pairing like "mouse free Thursday's". Once you learn all the keyboard shortcuts within an IDE, you realize the mouse is a distraction. The speed, fluency and pace you can write, and refactor code triples when you are not fumbling around with that little pointy arrow. You find that your thoughts are focused on your end goal and not scrolling through your code looking for those pesky syntax problems like missing curly bracket or missing semi-colon. And yes, it is a bad habit to rely on the compiler to tell you were that missing semi-colon is!

So now here's my disclaimers.

1. I have respect for COBOL programmers, my intent here was to not poke fun at them.
2. I am not pushing ReSharper or TestDriven.Net, those are the tools we use. There are productivity tools out there. ( If Dustin Campbell reads this, I'll have already heard the groans when I mention ReSharper!)
3. Mouse-Free Thursdays is an awesome experience. While pairing, each developer unplugs their mouse, only for Thursday and only while coding. After a few MFT's, you find you are a much more efficient coder.

F# Pattern Matching

After my last post on the sample F# test runner, I realized I missed a post on one of the critical constructs F# has to offer; pattern matching. Pattern matching does exactly what it sounds like, matches patterns.

let action x = 
     match x with
     | "Red" -> "Stop"
     | "Green" -> "Go"
     | _ -> "I don't know"

In this example, when I pass the colors Red or Green to the action function, it returns the matching value. If I were to pass blue to the function, I would get back "I don't know".

> action "Red";; val it : string = "Stop" > action "Blue";; val it : string = "I don't know"

Notice the "_" at the end, it is a wildcard and it makes this pattern match exhaustive. If I didn't include the _, F# would complain I had an incomplete match. You do have to be careful of where you put your wildcard character. The following function would create a scenario where the "Green" match statement would not be evaluated:

let action x = 
     match x with
     | "Red" -> "Stop"
     | _ -> "I don't know"
     | "Green"  -> "Go"

This control structure should seem very familiar to anyone coming from the C language family. Indeed, the action function could be written as an if..else statement or a switch statement in C#:

   public static string Action(string color)
        {
            if (color == "Red")
            {
                return "Stop";
            }
            else if( color == "Green")
            {
                return "Go";
            }
            else
            {
                return "I don't know";
            }
        }

You can include conditions within your matches, take the following function:

let isEven x =
     match x with
     | _ when x % 2 = 0 -> true
     | _ -> false

With conditions however, you need to have a catch all. If I were to change the above function to read like this:

let isEven x =
     match x with
     | _ when x % 2 = 0 -> true
     | _ when x % 3 = 0 -> false

the complier would complain of an incomplete pattern match. With pattern matching you can decompose structured values. This example breaks down the tuples for the match.

let isCubeEven x =
     match x with
     | _ when snd x % 2 = 0 -> (fst x,true)
     | _ -> (fst x,false)

This function returns the following in fsi:

> isCubeEven (3,9);; val it : int * bool = (3, false)

The example "isCubeEven" highlights two features of what makes F# exciting. First, notice that I didn't need to explicitly annotate any of my variables with types? The F# complier inferrs that x is a tuple because of the way I use it within my function. And second, the fst and snd functions that let me easily work with tuples to get the first and second values. Pattern matching becomes really powerful when you combine it with rec, the keyword for recursive functions. Take this function for adding up the numbers in a number:

let rec sumDigits x y =
    match x with
          | x when x = 0 ->  y
          | x -> sumDigits (x / 10) (x % 10) + y

This particular function I wrote to solve some of the Project Euler problems. With this function y accumulates the running summed value and x gets chopped up from right to left.

> sumDigits 123456789 0 val it : int = 45

When you combine the rec keyword and pattern matching, the possibilities are infinite. Take the fold_left function from the F# list namespace:

let rec fold_left f s l = 
     match l with 
     | [] -> s 
     | (h::t) -> fold_left f (f s h) t

The fold_left function takes a function f, a seed value s, and a list l. The match uses the list processing keys to get the first element h and remainder of the list t. Then calls itself with the same function, the result of the function applied to the seed value and the first element and the rest of the list. Pattern matching also works great on records, here's a great post on that by Mike Gold. Question and comments are welcome!