Matthew Podwysocki's Blog
Architect, Develop, Inspire...
-
IoC Containers, Unity and ObjectBuilder2 - The Saga Continues
namespace UnitySamples
-
Coming to Terms with Behavior Driven Development
A while ago, I posted about Behavior Driven Development (BDD) while using the NBehave, and I think I went too far into the tool without going into the whole thought process instead. I've had a series of these blog posts in my head but have been fighting writers block in order to get them out the door.
BDD Introduction
Anyhow, there has been a lot of discussion around BDD lately on the altdotnet mailing list around the definition and applicability of BDD in regards to Test Driven Development (TDD). Subsequently, this led to forming a new group on Google Groups about Behavior Driven Development. It's great to see the community start to gain momentum and talk about it more. I've been following Dan North, Joe Ocampo, Scott Bellware, JP Boodhoo and Dave Laribee on this for a while, but now to come to a centralized place for that knowledge sharing has been invaluable. I've seen too many times that there is a high noise to information ratio out there and we need to clarify a few things before it can really take hold.
Getting back to the subject at hand, if you're unfamiliar with BDD, you should check out Dan North's explanation here. There are a good number of links inside to whet your appetite. To put things succinctly, BDD aims to bridge the gap between Domain Driven Design and Test Driven Development.
Dave Astels, also has a great video on Google Video on BDD you can find here. It's a great video which talks about how TDD differs and evolved from BDD. It also delves into the subject of rSpec, the BDD framework in Ruby. Very worth your time to check it out.
Dave's summation of BDD comes down to the following bullet points:
- Don't talk about Units in regards to Unit Testing, instead talk about Behaviors
- All software we write has behaviors
- There should be no correlation between public methods on a class and test classes
- Structure your tests around the behavior of your application
- Put emphasis on behaviors (How do I get it to do what I want it to)
- Get rid of state based testing and look at interactions instead
- Get rid of tests and instead use specifications of behavior (specs)
- Get rid of assertions and instead set up expectations
I agree with Jimmy Bogard, that going to TDD to BDD in one fell swoop by just renaming your tests. Instead, we should focus on those interactions between the systems and less on the physical implementations of the code. We should also focus on the expectations inside our code as well. Mocking and the use of Rhino Mocks or your other mocking framework will do nicely in here. Brian Donahue also has some nice stabs at BDD as well here, here and here. If you're up in the Philly area soon, Brian will be making the rounds doing BDD presentations...
Dave Laribee has also put some thought into BDD as well with a particular set of classes he has written to help with BDD that you can check out here. Also if you've paid attention to the BDD mailing list on Google Groups, you will note that Scott Bellware also has a framework up on Google Code called SpecUnit which is an extension to NUnit to support naming conventions of BDD inside of the xUnit type frameworks. Very cool ideas coming out!
Wrapping It Up
I encourage you to join the BDD list, read the links, and learn more. I find it's a more intuitive way of proving the behavior of your application (Note that I didn't say test). I find that it bridges the gap between Domain Driven Design and Test Driven Development quite handily especially in regard to using the ubiquitous language. It's important that naming and ubiquitous language comes into play when using BDD, because you can share your specs and they should be able to read them as well. It's a great gap between user stories and the code you write. If you need help with user stories, check out Mike Cohn's User Stories Applied book. Anyhow, I hope you found this useful as an introduction to some of my many upcoming BDD posts.
-
Adventures in F# - F# 101 Part 3
#light
-
IoC and the Unity Application Block Once Again
namespace UnitySamples
-
Thinking Inside the Box and Premature Optimization
At the last DC ALT.NET meeting, there was a good discussion regarding premature optimization. Anything that involves this brings me to a rather famous quote by a great computer scientist, Donald Knuth which states:
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."Don't Think Five Steps Ahead
The context of the conversation revolved around how when you learn a new language, you have a tendency to think inside the box and try not to prematurely optimize the code, instead, just meet the original intent of what you were trying to do as quickly and efficiently as possible and make it conform to the specification. For example, one person there was a .NET guy who knew nothing of Java until put on a project recently where it was exclusively used. This forced him to think more clearly about the problem and not just throw design patterns, caching solutions and so on. When we are familiar with a language and all of its nuances, it sometimes gets the better of us, and we start throwing frameworks in there that have done things for us in the past just because they seemed appropriate then. It rang very true for me as well when I did my first Ruby on Rails application and I saw that I didn't need to bring in X framework or Y framework and my solution did just fine without it. In fact, I thought it was a stronger piece because I didn't clutter it with frameworks and instead solved the direct domain problem at hand first.
It kind of reminds me of a conversation I once had with a developer which went like this:
Me: Why did you use x for this piece?
Him: Because it's always worked for me in the past.
Me: What problem does it solve? Did you have that problem this time around?
Him: Well, no, I was just thinking five steps ahead
So, basically what we can infer from this conversation is that the pain point just hadn't been hit yet. Instead, reflexively, we have a tendency to throw these things in there because at one point, for one particular project, we felt that pain. That's not to say that optimization is a bad thing, but once we start doing it, we need concrete measures for what the optimization is trying to fix and how well it does it. Another part to consider is how easy is it to read.
ADD with DDD
Some of the guidance for this can be traced back to Domain Driven Design. With this, you pay more attention to the model, the ubiquitous language and so on, and the frameworks in turn will come into play. Instead, many people put their frameworks first and try to get the domain model to fit around it. They are distracted by shiny things with their ADD to put the domain model first and then the frameworks. I know I've been guilty of it in the past and it's been a learning adventure when I was earlier in my career.
I'll be back next with a real technology post on IoC, Unity and all that, so stay tuned. Until next time...
-
IoC and the Unity Application Block - Going Deeper
namespace UnitySamples
-
Adventures in F# - F# 101 Part 2
Update: Added more topics
I know it's been a little bit too long since I began this series from when I continued, but plenty of distractions came up along the way. I intend to go a little deeper today into what functional programming means and why you should care. As always, check out my previous post on the matter here.
Getting Sidetracked
Last night at the DC ALT.NET meeting, Craig Andera and I discussed Lisp, F# and functional programming as a whole. His language of the year was Lisp and I thought that was an interesting choice of the language to learn, but when you think about it, most good things in programming lead back to SmallTalk and Lisp... I had been hearing a bit about IronScheme, the IronLisp rewrite, so of course I had to check it out. Maybe this will be one of my future languages to learn, but I had enough exposure during my college years to last a little bit, so it's on the plan anyways.
Basic Introduction
So, just in case you missed the idea of functional programming and what it means, I have a few posts on where you should start here:
But, if you really want the condensed version, Bart de Smet has a really nice introduction on functional programming in a series, although incomplete, which you can read here:
Now that I take it you have read that and caught up, let's continue onto today's part.
The Joys of Currying
Where we left off last time was just dealing with the basics of functions and the fact that they are treated as values much like any other "variable". Now let's get into a popular topic among functional programming, a concept called Currying. The term was invented back in the earlier days of functional programming after the early logician Haskell Curry. He's so good in fact that he got not only a functional programming style named after him, but a language named after him with Haskell. If you listen to the DotNetRocks Episode 310 with Simon Peyton-Jones, you can learn more about that.
Anyhow, the basic idea of Currying is to take a function with multiple arguments and transform it into a function that passes in only one argument, with the other arguments specified in the Currying function itself. So you can think of it as a function that calls another function and returns a function. You can think of it also as being a partial function. So, let's actually get down to it and write some F# code to show how to do this:
#light
let n = 10
let multiply a b = a * b
let multiplyByFive = multiply 5
let result = multiplyByFive 4
printfn "result = %i" result
So, what I accomplished above is that I had a function called multiply that takes two arguments, a and b. Then I created a currying function called multiplyByFive which curries the multiply function by supplying a five value. Then I can call the multiplyByFive curried function with a 4 and sure enough the result is 20.
As always, I'm always curious on how it looks through .NET Reflector to see how F# does its magic. So, let's crack that open and take a look. First let's look at the tree of Reflector to see what it creates for us:
Now as you can see, it created the multiply function. Then we also have a multiplyByFive FastFunc function. The functions get stored in the namespace free area and yet the main function gets placed elsewhere. Now, let's look at the function implementation itself.
From what you can see, it created a SampleFile class because I created a SampleFile.fs to create the curried functions.
For those of you who are C# buffs, well, you can also do the same in C# with the new anonymous function type, System.Func in .NET 3.5. Mads Torgersen, the C# Program Manager, noted on his blog quite a while ago asking the question, "Is C# Becoming a Functional Language?". This post was pretty great and it's unfortunate that he doesn't blog as much as he does. Remember kids, this isn't as pretty as F# because it's not what C# is really good at, but slowly but surely, functional programming paradigms are slowly seeping into C#.
namespace CSharpCurriedFunctions
{
public static class CurriedFunctionExtensions
{
public static Func<A, Func<B, R>> Curry<A, B, R>(this Func<A, B, R> f)
{
return a => b => f(a, b);
}
}
class Program
{
static void Main(string[] args)
{
Func<int, int, int> multiply = (a, b)=> a* b;
Func<int, Func<int, int>> curriedMultiply = multiply.Curry();
Func<int, int> multiplyByFive = curriedMultiply(5);
Console.WriteLine("result = {0}", multiplyByFive(4));
}
}
}
If you're interested more in doing this with C#, I would suggest you head over to Dustin Campbell's blog and read the post about The Art of Currying. For those who want to learn more, well, Dustin should be at ALT.NET Open Spaces, Seattle and hopefully will submit an F# topic for us to get our heads around.
How useful is this in C#? Well, time will tell, but you could imagine having some search criteria for your repository using curried functions to "overload" with values. Anything is really possible, but as you can see, it's a lot cleaner in F# and that's where it really shines.
The Odd Tuple
When specifying arguments to any given function, you can specify them without parentheses much as you would in VB.NET should it be a subroutine. This is really helpful if you want to enable currying and such. But, you can also specify them as a tuple. For the math illiterate among you, that simply means a sequence of objects of a specified type. This you must put within parentheses. This makes you supply all arguments at once. A simple example of this would look like this:
#light
let add (a, b) = a + b
let result = add(3, 4)
printfn "result = %i" result
Pretty simple example and of course the result would be 7.
Where is the Returns Department?
As you may have noticed from the functions from above, I never really did specify any return type or return statement. Implicitly behind the scenes, F# does that for you. Basically when you define a function, you should indent with a tab and the last assignment becomes your return value. The return is implicit right after the indenting is ended. So, let's take a simplistic view of this:
#light
let addThings a b =
let c = a + b
sprintf "result = %i" c
let result = addThings 3 7
print_string result
As you may notice, when using the light syntax (#light), you cannot indent, instead just use two spaces and that should suffice. Anyhow, you may note, I was doing a simple addition and then my final assignment becomes my return value, which is using the sprintf function, which to you C buffs out there, should look familiar.
Conclusion
I've got a lot more on this topic quite frankly and still just covering the basics of your first F# program. There is so much to learn on this, but these are the basic building blocks you need to make that leap into functional programming. It's becoming more interesting year by year as our languages such as Ruby, C# and so on continue to drive towards functional programming, so it's important to grok the fundamentals. Next time, I hope to cover some recursion stuff, functions, lists and even operators (the really fun stuff). Until next time...
-
DC ALT.NET Wrapup and CI Factory
Well, due to the weather beyond our control, the crowd was a bit smaller than expected at the February meeting of DC ALT.NET. It seems people panic in the Washington DC area if there is even a hint of moisture in the air or a snow flake hits the ground. It was a smaller crowd, yet passionate and I'd rather have that then a big crowd that wasn't involved at all. We had such people as Craig Andera, Jay Flowers, Kevin Hegg among others who attended. But the topics were great talking about functional programming, with Craig and Lisp and me with F#, continuous integration, the complexity of .NET and what's coming down the line, Domain Driven Design and managing complexity in projects. Not once did a laptop nor PowerPoint show its head, instead just passionate people talking about technology and ways of thinking.
I want to thank the people at Stelligent and Jay Flowers for making this happen. It couldn't have been better timing as he just released version 1.0.1 of CI Factory yesterday. If you aren't aware of this product, I've blogged about it in the past here. What it does is it creates an out of the box CI environment which is really important to have in an agile environment. Even teams as small as one person can benefit greatly from continuous integration.
Tools supported by CI Factory include:
- NAnt
- MbUnit
- FinalBuilder
- InstallShield
- MSBuild
- MSTest
- NCover
- NDepend
- Simian
- Subversion
- VSS
- VSTS
- Windows Installer XML
- Xenocode Postbuild
-
Lang.NET Videos Now Available
As you may have seen from previous posts, I have been covering Lang.NET and some of the interesting things that came from it. I've always been interested in compilers, DSLs and such, and I hope you found them interesting as well. I covered it these posts here:
- Adventures in Compilers - Building on the DLR
- DSLs, Compilers and the Irony of it All
- Ruby.NET is dead, long live Ruby.NET
- Lang.NET and Rolling Your Own
-
Final Reminder - DC ALT.NET Meeting 2/20 - 7PM
As posted previously here, the DC ALT.NET February meeting will be held tomorrow, Wednesday, February 20th, 2008 from 7-9PM. Stelligent has been really kind to provide the facility and the food/drinks.
Since we're following the Open Spaces Technology route, we don't have set speakers right now, but that may change over time. We've been discussing some of the topics for the meeting:
- Design By Contract (DBC) and Spec#
- Aspect Oriented Programming and Castle Windsor
- NHibernate Design Patterns and Implementation
Time and Location:
Tuesday, February 20, 2008 7:00 PM
Stelligent Incorporated
Global Headquarters
11495 Commerce Park Drive
Reston, VA 20191
So, bring your topic for discussion and bring your passion!
