Been fun running this blog, but now it's time for me too to move back to my old blog:
http://christiangenne.blogspot.com
Hope to see you there!
And Gustaf, thank you :)
/ Christian
Sunday, August 9, 2009
Sunday, August 2, 2009
Gustaf moves to his own blog.
From now on, I (Gustaf) will post all my posts on my original blog, http://gustafnilssonkotte.blogspot.com/. I would be very (!) happy if you added that feed to your readers.
Sorry for the inconvenience.
Christian: Thank you for a very nice time buddy! :)
/Gustaf
Sorry for the inconvenience.
Christian: Thank you for a very nice time buddy! :)
/Gustaf
Tuesday, June 2, 2009
Objective-C... yet another programming language?
Just recently installed XCode on my mac in order to develop applications for my iPhone. The first thing I realized was that I needed to learn yet another programming language. Just another syntax, or does Objective-C actually bring something new?
It turns out Objective-C (which is a language derived from C, similar to C++, but still very different) has one feature I haven't seen before. First of, instead of calling a method on an object, your send a message to it. It's almost the same, but also requires you to pass along named parameters (which means more code to write, but easier to read). The new and cool feature appears when you want to send a message to an object, which should return a value, when the object turns out to be nil.
So when executing this code, as opposed to how normal programming languages handles it, it doesn't crash. It simply returns 0.0 if the expected return type is a number, or nil if the expected return type is a pointer to an object. This also works for functions returning nothing (i.e. void), sending a void returning message to a nil object will simpy do nothing.
In for example C# you always have to do null checks all over the code, in order to verify your object isn't nil.
I'm not sure I like it or not, but if you learn to think "pure Objective-C" then perhaps this can be used as an advantage! I'm looking forward to learning Objective-C further, and to adapt these new concepts!
I'll let you know when I've published my first iPhone app :)
It turns out Objective-C (which is a language derived from C, similar to C++, but still very different) has one feature I haven't seen before. First of, instead of calling a method on an object, your send a message to it. It's almost the same, but also requires you to pass along named parameters (which means more code to write, but easier to read). The new and cool feature appears when you want to send a message to an object, which should return a value, when the object turns out to be nil.
MyClass* myObject = nil;
if ([myObject getValue] == 0.0) {
// myObject getValue retuned 0, OR myObject is nil
}
So when executing this code, as opposed to how normal programming languages handles it, it doesn't crash. It simply returns 0.0 if the expected return type is a number, or nil if the expected return type is a pointer to an object. This also works for functions returning nothing (i.e. void), sending a void returning message to a nil object will simpy do nothing.
In for example C# you always have to do null checks all over the code, in order to verify your object isn't nil.
I'm not sure I like it or not, but if you learn to think "pure Objective-C" then perhaps this can be used as an advantage! I'm looking forward to learning Objective-C further, and to adapt these new concepts!
I'll let you know when I've published my first iPhone app :)
Saturday, April 25, 2009
From for loop to anamorphism
Introduction
Sometimes you want to generate a sequence of objects. This is often done using a for loop:
[Test]
public void CreateListOfFoos()
{
var xs = new List<Foo>();
for (int i = 0; i < 10; i++)
{
xs.Add(new Foo());
}
Assert.AreEqual(10, xs.Count());
}
In this post, I will show you how this code can be made more general, ultimately turning it into an anamorphism over lists.
Generalizing constructed type
First, what we want to do is to be able to create something other than a Foo. We apply ExtractVariable once and we also extract the constructor call to a lambda:
[Test]
public void ExtractMethod()
{
var times = 10;
Func<Foo>newFoo = () => new Foo();
var xs = CreateFooNumberOfTimes(times, newFoo);
Assert.AreEqual(10, xs.Count());
}
private IEnumerable<Foo> CreateFooNumberOfTimes(int times, Func<Foo> newFoo)
{
var xs = new List<Foo>();
for (int i = 0; i < times; i++)
{
xs.Add(newFoo.Invoke());
}
return xs;
}
From the above code, it’s easy to generalize on the type created. Note that we could have skipped the “constructor lambda” and instead used the “where T : new()” constraint.
[Test]
public void GeneralizeTypeForFunc()
{
var times = 10;
Func<Foo> newFoo = () => new Foo();
var xs = CreateTNumberOfTimes(times, newFoo);
Assert.AreEqual(10, xs.Count());
}
private IEnumerable<T> CreateTNumberOfTimes<T>(int times, Func<T> newFoo)
{
var xs = new List<T>();
for (int i = 0; i < times; i++)
{
xs.Add(newFoo.Invoke());
}
return xs;
}
Generalizing type for accumulator
We have now parametrized Foo to T, but wouldn’t it be possible to parametrize from “int” to A, as well? Let’s begin with breaking out the int-specific code from the for loop:
[Test]
public void ExtractForLoopLogic()
{
Func<Foo> newFoo = () => new Foo();
int i = 0; // Will be modified lots of times
Func<bool> expr = () => i < 10;
Action inc = () => i++;
var xs = CreateTUntil(newFoo, expr, inc);
Assert.AreEqual(10, xs.Count());
}
private IEnumerable<T>CreateTUntil<T>(Func<T> newT, Func<bool> expr, Action inc)
{
var xs = new List<T>();
for (; expr.Invoke(); inc.Invoke())
{
xs.Add(newT.Invoke());
}
return xs;
}
As indicated in the code, the variable “i” will be modified the closure called in CreateTUntil. Bart de Smet calls this a cruel lambda. Except that it’s quite hard to understand a lambda that mutate its outer scope, refactoring code that’s using cruel lambdas can make your code go totally bananas!
Let’s rewrite the code to use a pure lambdas instead. To do this, we need to refactor the for loop to a while loop, since the first and third “parameters” to a for loop are statements (not pure). We also parametrize from “int” to type parameter “A” instead.
Going pure and a more general constructor
[Test]
public void ForLoopToWhileLoop()
{
Func<Foo> newFoo = () => new Foo();
Func<int,bool> expr = a => a < 10;
Func<int,int> inc = i => i + 1;
var xs = CreateTUntilUsingWhile(newFoo, 0, expr, inc);
Assert.AreEqual(10, xs.Count());
}
// Now a pure method
private IEnumerable<T> CreateTUntilUsingWhile<T>
(Func<T> newT, int init, Func<int,bool> expr, Func<int,int> inc)
{
var xs = new List<T>();
int i = init;
while (expr.Invoke(i))
{
xs.Add(newT.Invoke());
i = inc.Invoke(i);
}
return xs;
}
Now we don’t have any concrete types in the method signature, except bool, which I think is ok to have there at this point. But, as the observant reader might have noticed, the constructor can’t be called with a variable argument, i.e. the accumulated value. What we need to do is to “connect” the lambdas that generates values, like this:
[Test]
public void ArgumentForConstructor()
{
Func<int,Result<Foo,int>> gen = n => new Result<Foo,int>(new Foo(), n + 1);
Func<int,bool> expr = a => a < 10;
var xs = GeneralizedCreateTWithArgsUntilUsingWhile(gen, 0, expr);
Assert.AreEqual(10, xs.Count());
}
private IEnumerable<T> GeneralizedCreateTWithArgsUntilUsingWhile<T,A>
(Func<a,Result><T,A>> gen, A init, Func<A,bool> expr)
{
var xs = new List<T>();
var i = init;
while (expr.Invoke(i))
{
var result = gen.Invoke(i);
xs.Add(result.Value);
i = result.Accumulator;
}
return xs;
}
Going recursive
Now it’s up to the generating lambda to pass an argument to the constructor or not. What’s funny with this is that if we replace the while loop to a recursive call, we come pretty close to the definition of an anamorphism over lists in the introduction of Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire by Erik Meijer et. al (link to postscript version).
[Test]
public void WhileLoopToRec()
{
Func<int, Result<Foo, int>> gen = n => new Result<Foo, int>(new Foo(), n + 1);
Func<int, bool> expr = a => a < 10;
var xs = CreateTUntilUsingRec(gen, 0, expr);
Assert.AreEqual(10, xs.Count());
}
private IEnumerable<T> CreateTUntilUsingRec<T,A>
(Func<A, Result<T, A>> gen, A init, Func<A, bool> expr)
{
if (!expr.Invoke(init))
return new List<T>();
var result = gen.Invoke(init);
return (new List<T> {result.Value})
.Concat(CreateTUntilUsingRec(gen, result.Accumulator, expr));
}
Abstracting away from bool
It seems that the only thing left to do is to abstract away the dependency on “bool” in CreateTUsingRec, but then we bump into a small problem,as you will see. What we do is to join the two lambdas into one and performing a null check inside the recursive function.
[Test]
public void MergeOnceMore()
{
int? i = 0;
Func<int, Result<int?, int>> gen = n => new Result<int?, int>(n < 10 ? i : null, n + 1);
var xs = CreateTUntilUsingRecNullCheck(gen, 0);
Assert.AreEqual(10, xs.Count());
}
private IEnumerable<T> CreateTUntilUsingRecNullCheck<T, A>
(Func<A, Result<T, A>> gen, A init)
{
var result = gen.Invoke(init);
if (result.Value == null)
return new List<T>();
return (new List<T> { result.Value })
.Concat(CreateTUntilUsingRecNullCheck(gen, result.Accumulator));
}
Writing it in F# instead
The problem with this solution is that we have lost the ability to generate ordinary non-nullable structs and that’s bad! We could easily solve the problem with writing our own MyNullable<T> which would allow both classes and structs as instantiators of the type variable, but instead of doing that, I’ll show you something similar: the option type in F#.
let rec anamorphism n f =
match f n with
| option.None -> []
| option.Some (e,next) -> e::(anamorphism next f)
> anamorphism 0 (fun a -> if a < 5 then option.Some("Bar" + a.ToString(), a + 1) else option.None);;
val it : string list = ["Bar0"; "Bar1"; "Bar2"; "Bar3"; "Bar4"]
Here, we removed the Result class and used a pair instead, together with the Option type, which is essentially the same as Nullable<T>, but without the restriction on type.
Conslusion
Functional programming is perhaps more abstract than imperative programming, but it is also seems to be more general, at least in this case. This post has only showed an anamorphism over lists, which is the simple case. Look here if you want to see a more advanced example.
Wednesday, March 4, 2009
Why you love and hate Ruby
What strikes me when programming Ruby is how simple everything is! You've got utility functions for almost everything, and writing an application doesn't take more then a few lines of code. No need to setup a project, no need to think about types. You just write code!
The downside of this, of course, is that the code easily becomes bad written, and as there are very few rules in Ruby, it isn't very easy reading others' code. This is why Ruby sometimes is classified as a "hard to lean language". There are simply too many ways of writing the same code.
I don't agree that this makes the language more hard to learn, but perhaps makes it take longer to learn the language fully. For instance, I just recently learned you can write code in the following way:
I've never seen code like that before, but it really opens up for some nice syntax!
Another feature of Ruby is that Classes are open, and everything is an object, meaning you can extend/modify classes on the fly. Even classes are objects! For example:
The syntax is almost perfect! How would you otherwise say "5 minutes ago"? That's what people often talk about when they describe Ruby. "The only truly object oriented language".
Why Ruby isn't the perfect language, IMO, is because it's too "open". There are too many ways of writing code. Writing smaller applications, or better scripts, won't take you more than a few minutes, but when you need to work on a larger project, I would definitely go with a strictly typed language, such as C#, where you have better control over your code. Also, not surprisingly, no IDE can help you writing your code, as the code is dynamically typed, and you really can't say what functions are available on an object until you actually run the code.
So, thumb up for this language when working on smaller applications. But for larger projects, I would recommend going for another one.
The downside of this, of course, is that the code easily becomes bad written, and as there are very few rules in Ruby, it isn't very easy reading others' code. This is why Ruby sometimes is classified as a "hard to lean language". There are simply too many ways of writing the same code.
I don't agree that this makes the language more hard to learn, but perhaps makes it take longer to learn the language fully. For instance, I just recently learned you can write code in the following way:
puts "Hello my friend" if userIsFriendly
I've never seen code like that before, but it really opens up for some nice syntax!
Another feature of Ruby is that Classes are open, and everything is an object, meaning you can extend/modify classes on the fly. Even classes are objects! For example:
class Fixnum
def minutes
return Timespan.new(self)
end
end
class Timespan
def ago
return Time.now - self
end
end
5.minutes.ago
The syntax is almost perfect! How would you otherwise say "5 minutes ago"? That's what people often talk about when they describe Ruby. "The only truly object oriented language".
Why Ruby isn't the perfect language, IMO, is because it's too "open". There are too many ways of writing code. Writing smaller applications, or better scripts, won't take you more than a few minutes, but when you need to work on a larger project, I would definitely go with a strictly typed language, such as C#, where you have better control over your code. Also, not surprisingly, no IDE can help you writing your code, as the code is dynamically typed, and you really can't say what functions are available on an object until you actually run the code.
So, thumb up for this language when working on smaller applications. But for larger projects, I would recommend going for another one.
Thursday, February 26, 2009
Fluent language in FsStory
A nice feature for a story runner is to be able to provide arguments in a story sentence, like this:
ATableWithNumberOfLegs 4
This example is not hard to understand, but there's some mental translation going on, since the order of the words is all screwed up. Let's try another one:
TheNumberOfLegsOfATableIs 4
Better, but still not good. First, it's longer than the previous example. Second, even if the grammar is correct, the word order is, well, unusual.. ;)
What about this?
ATableWith 4 Legs
Now we're talking!
Here's a bigger and more complete example:
Note: As far as I know, RSpec/Cucumber is the only story runner(s) that is able to use variables inside a story sentence.
The nice thing about this is that I didn't have to change FsStory itself to make it work. Not a single line. So, what's the trick?
If you split up a story sentence like this, you have to prepare the step definition code (the behind-the-scenes code) in a certain way:
let ATableWith = fun n _ -> ... do something here ...
..or if you prefer, without a lambda:
let ATableWith n _ = ... do something here ...
Then you have to define Legs:
let Legs = id
As you see, in this case, it was just a matter of discovering the usage, rather than implementing it in the language. Honestly, I had no idea of this usage when I started to write on FsStory. This is clearly one of the reasons why I like internal DSLs!
Exercise: How would you implement the step definition for the following story sentence?
given (ATableWith 4 LegsAnd 2 Chairs)
Cheers!
ATableWithNumberOfLegs 4
This example is not hard to understand, but there's some mental translation going on, since the order of the words is all screwed up. Let's try another one:
TheNumberOfLegsOfATableIs 4
Better, but still not good. First, it's longer than the previous example. Second, even if the grammar is correct, the word order is, well, unusual.. ;)
What about this?
ATableWith 4 Legs
Now we're talking!
Here's a bigger and more complete example:
[<Fact>]
let tableLegsScenario =
given (ATableWith 4 Legs)
|> whens (ICutOf 1 Leg)
|> thens (ItHasOnly 3 LegsLeft)
Note: As far as I know, RSpec/Cucumber is the only story runner(s) that is able to use variables inside a story sentence.
The nice thing about this is that I didn't have to change FsStory itself to make it work. Not a single line. So, what's the trick?
If you split up a story sentence like this, you have to prepare the step definition code (the behind-the-scenes code) in a certain way:
let ATableWith = fun n _ -> ... do something here ...
..or if you prefer, without a lambda:
let ATableWith n _ = ... do something here ...
Then you have to define Legs:
let Legs = id
As you see, in this case, it was just a matter of discovering the usage, rather than implementing it in the language. Honestly, I had no idea of this usage when I started to write on FsStory. This is clearly one of the reasons why I like internal DSLs!
Exercise: How would you implement the step definition for the following story sentence?
given (ATableWith 4 LegsAnd 2 Chairs)
Cheers!
Sunday, February 22, 2009
ImpossibleEstimation and Pomodoro Technique
Sometimes when using Pomodoro Technique I find it real difficult to estimate how long a particular activity will take, i.e., when locating a bug or find out why the webserver won't read my files.
In Pomodoro Technique, every activity should have a time estimate - how many Pomodori I think it will take. Though, this is sometimes impossible! "The problem is solved when I find the bug and since I don't know what the bug is related to, it's impossible to say how much time it will take to find it."
The solution: instead of just writing a number besides the activity, I use the less-than sign (<) before the number, indicating that I have a time-box for the activity, but that it might take less time. If I'm not done when the time-box is over, I have to ask a colleague to help me or ask my boss for extra resources - thus, escalating my problem. Then, I'm forced to have collected some data of the problem to help them to help me. The nice thing is that I still can have most of the benefits Pomodoro Technique gives me, i.e., increased focus when in a Pomodoro and possibility to get "the whole picture" during my breaks. The latter have proved to be an extra nice thing to have during hard problem-solving.
And, if a colleague comes to the rescue, we can construct another time-box, to know when to escalate it further, or at least to notify the team or the boss that we have some nasty problems at hand.
Yet, if I'm collecting metrics of my estimation skills, it is not a very good idea to track data for these bug-fixing Pomodori estimates. Put a "N/A" or a "-" in your records sheet and think for yourself: "Today was an exception, tomorrow will be a bug-free day." And don't forget to do your daily mind-map before you leave for home.
In Pomodoro Technique, every activity should have a time estimate - how many Pomodori I think it will take. Though, this is sometimes impossible! "The problem is solved when I find the bug and since I don't know what the bug is related to, it's impossible to say how much time it will take to find it."
The solution: instead of just writing a number besides the activity, I use the less-than sign (<) before the number, indicating that I have a time-box for the activity, but that it might take less time. If I'm not done when the time-box is over, I have to ask a colleague to help me or ask my boss for extra resources - thus, escalating my problem. Then, I'm forced to have collected some data of the problem to help them to help me. The nice thing is that I still can have most of the benefits Pomodoro Technique gives me, i.e., increased focus when in a Pomodoro and possibility to get "the whole picture" during my breaks. The latter have proved to be an extra nice thing to have during hard problem-solving.
And, if a colleague comes to the rescue, we can construct another time-box, to know when to escalate it further, or at least to notify the team or the boss that we have some nasty problems at hand.
Yet, if I'm collecting metrics of my estimation skills, it is not a very good idea to track data for these bug-fixing Pomodori estimates. Put a "N/A" or a "-" in your records sheet and think for yourself: "Today was an exception, tomorrow will be a bug-free day." And don't forget to do your daily mind-map before you leave for home.
Monday, February 9, 2009
[Announce] FsStory, executable stories in F#
Since Claudio Perrone's talk on Øredev, I have been thinking about what his MisBehave would look like in F#. In his talk, Claudio also mentioned Cucumber, a story runner written in Ruby. My plan was to make a lightweight DSL for writing stories in F# code, with the story parts separated from the implementation parts.
Currently, FsStory enables the developer to write user story scenarios (in Given/When/Then form) in F# code, like this:
Did you notice [<fact>] attribute just before the function definition? It is a xUnit.net specific attribute, telling xUnit.net that the function is a runnable test. So, why xUnit.net? Answer: xUnit.net is the currently the only test framework that runs static test methods, which is what F# functions compiles to.
Note: If you think that the story above is too low level to be a "good" user story, you're right, but it's just an example..
The "ATurtle", "IsRotated90DegreesToTheRight", "TurtleWalksSteps", etc, are functions that you have to implement yourself. What these functions do is not FsStory's business, except that they have the same type. It's a good thing to think about this in advance.
If you're testing something object oriented, i.e. a C# project, then you're probably have to let the functions have the type () -> (). That is, they take no argument and return void, in C# lingo. You'd also need a mutable variable to accomplish this.
It's up to the developer what library she wants to use for her assertions. In this example, FsTest was used, but she could go for NUnit or NBehave or something else. I hadn't actually tried this and do not longer think this will work. Either use xUnit.net or FsTest (which is based on xUnit.net).
Another style is to work with immutable objects. One example of immutable objects are value objects, in DDD. Immutable objects correspond well to functional programming principles. Here is an example of an implementation of a scenario when an immutable object is used in the SUT (System Under Test).
To clarify, all methods on the (immutable) turtle return a new turtle and that turtle is returned and then passed in as an argument to the next test function (by FsStory). As you might have spotted, the example uses a lambda, an anonymous functions (the "fun") instead of specifying an argument explicitly. It's a good thing to get a running story before actually implementing the logic and assertions. Using the function "id" (just returning the argument) on the right-hand side is very helpful for getting everything to run.
You can find FsStory at http://www.codeplex.com/fsstory.
Currently, FsStory enables the developer to write user story scenarios (in Given/When/Then form) in F# code, like this:
#light
open FsStoryRunner
open MutatedTurtleMovesImpl
open Xunit
(*
In order to impress my friends
As a .NET programmer
I want to draw funny fractal pictures
*)
[<fact>]
let MoveTurtleToPosition() =
given ATurtle
|> andGiven IsRotated90DegreesToTheRight
|> whens (TurtleWalksSteps 9)
|> thens (TurtleIsLocatedAt (0,9))
|> endStory
Did you notice [<fact>] attribute just before the function definition? It is a xUnit.net specific attribute, telling xUnit.net that the function is a runnable test. So, why xUnit.net? Answer: xUnit.net is the currently the only test framework that runs static test methods, which is what F# functions compiles to.
Note: If you think that the story above is too low level to be a "good" user story, you're right, but it's just an example..
The "ATurtle", "IsRotated90DegreesToTheRight", "TurtleWalksSteps", etc, are functions that you have to implement yourself. What these functions do is not FsStory's business, except that they have the same type. It's a good thing to think about this in advance.
If you're testing something object oriented, i.e. a C# project, then you're probably have to let the functions have the type () -> (). That is, they take no argument and return void, in C# lingo. You'd also need a mutable variable to accomplish this.
#light
open Turtle
open FsxUnit.Syntax
let mutable turtle = new Turtle() // turtle must have type Turtle
let ATurtle () = turtle <- new Turtle() // For reuse in same story let MovesOneStepForward () = turtle.Go() let IsMovedOneStepForward () = turtle.Position.X |> should equal 1 let RotationIs angle () = turtle.Direction |> should equal 0.0
Another style is to work with immutable objects. One example of immutable objects are value objects, in DDD. Immutable objects correspond well to functional programming principles. Here is an example of an implementation of a scenario when an immutable object is used in the SUT (System Under Test).
let ATurtle () = new TurtleImmutable()
let IsRotated90DegreesToTheRight = fun (turtle : TurtleImmutable) -> turtle.Left()
let TurtleWalksSteps steps = fun (turtle : TurtleImmutable) -> turtle.GoSteps(steps)
let TurtleIsLocatedAt (x,y) = fun (turtle : TurtleImmutable) -> turtle.Position |>
should equal (new Position(x,y)) ; turtle
To clarify, all methods on the (immutable) turtle return a new turtle and that turtle is returned and then passed in as an argument to the next test function (by FsStory). As you might have spotted, the example uses a lambda, an anonymous functions (the "fun") instead of specifying an argument explicitly. It's a good thing to get a running story before actually implementing the logic and assertions. Using the function "id" (just returning the argument) on the right-hand side is very helpful for getting everything to run.
You can find FsStory at http://www.codeplex.com/fsstory.
Friday, February 6, 2009
Trying out ruby for the very first time
So, I've made up my mind. The language of this year is going to be Ruby! The reasons are many, but mostly I feel I can use this language more in my daily work, and on a podcast over at AltDotNet about Ruby, they mentioned something like "learning ruby will make you a better C# developer". Languages like lisp and python will have to wait for at least one year!
About two weeks ago, I was out skiing with Gustaf and some friends of him. We ended up playing a lot of four in a row, a really funny and simple game. This game made me think about how to develop a min max AI, and suddenly I had written down the pseudo code for such an AI in my notebook. Here is a picture of the game is supposed to be played (from wikipedia):
Now, back home at my computer, I started digging into the ruby documentations, and after not more than a few hours I had finished the first version of the AI! Turns out Ruby isn't that hard to learn, at least not if you just want to get some basic things done. It's like writing c#, except you skip the types, and instead of writing void foo(int x) { ... } you write def foo(x) ... end, and so on...
Here is how my final version of the game looks when you run it:
and so on...
I wonder how much code can you post in a blog, without the post becoming too long? I would like to post the code as an attachment, but I'm not sure you can do that in blogger, so I'll simply put it here. To try it out, copy the code to a file, i.e. 4inarow.rb, then run it using ruby 4inarow.rb. Enjoy ;)
About two weeks ago, I was out skiing with Gustaf and some friends of him. We ended up playing a lot of four in a row, a really funny and simple game. This game made me think about how to develop a min max AI, and suddenly I had written down the pseudo code for such an AI in my notebook. Here is a picture of the game is supposed to be played (from wikipedia):
Now, back home at my computer, I started digging into the ruby documentations, and after not more than a few hours I had finished the first version of the AI! Turns out Ruby isn't that hard to learn, at least not if you just want to get some basic things done. It's like writing c#, except you skip the types, and instead of writing void foo(int x) { ... } you write def foo(x) ... end, and so on...
Here is how my final version of the game looks when you run it:
C:\Documents and Settings\Christian\Desktop>ruby 4irad.rb
Run against ai (A), another player (P) or let two AIs play against eachother (X)
A
Enter AI 1 level (1 to 5):
3
Enter name of human player (default Human 1):
---------------
|0 1 2 3 4 5 6|
---------------
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
---------------
AI 1 (3) played: 3
---------------
|0 1 2 3 4 5 6|
---------------
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | |O| | | |
---------------
Human 1, make your move:
2
Human 1 played: 2
---------------
|0 1 2 3 4 5 6|
---------------
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | |X|O| | | |
---------------
AI 1 (3) played: 3
---------------
|0 1 2 3 4 5 6|
---------------
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | |O| | | |
| | |X|O| | | |
---------------
Human 1, make your move:
and so on...
I wonder how much code can you post in a blog, without the post becoming too long? I would like to post the code as an attachment, but I'm not sure you can do that in blogger, so I'll simply put it here. To try it out, copy the code to a file, i.e. 4inarow.rb, then run it using ruby 4inarow.rb. Enjoy ;)
$debugEnabled = false
def debug(text)
if $debugEnabled then
puts ">>> " + text
end
end
class State
attr_reader :cols, :rows, :player, :winner, :lastPlayed, :isFull
Player1 = "Player 1"
Player2 = "Player 2"
def initialize
@cols = []
(0..6).each { @cols << [] }
@rows = []
(0..5).each { @rows << Array.new(7, nil) }
@player = Player1
@winner = nil
@isFull = false
end
def deep_copy
return Marshal.load( Marshal.dump( self ) )
end
def to_s
return "---------------\n" +
"|" + (0..6).to_a.join(" ") + "|\n" +
"---------------\n" +
@rows.reverse.collect{|row| "|" + row.collect{|r| if !r then " " elsif r == Player2 then "X" else "O" end}.join("|") + "|"}.join("\n") + "\n" +
"---------------"
end
def canPlay( i )
return @winner == nil && @cols[i].length < 6
end
def play( i )
if canPlay i then
rowIndex = @cols[i].length
@cols[i] << @player
@rows[rowIndex][i] = @player
@lastPlayed = i
switchPlayer
updateWinner
updateIsFull
end
end
def updateIsFull
for p in @rows[5]
if !p then return end
end
@isFull = true
end
def findWinner( row )
for i in 0..(row.length-4)
p = nil
n = 0
for j in 0..3
rp = getPlayed(row[i+j])
if rp.class != Fixnum then
if !p then
p = rp
elsif p != rp
p = 0
break
end
if rp != 0 then
n += 1
end
end
end
if p != 0 and n == 4 then
return p
end
end
return nil
end
def updateWinner
for row in getAllRanges
p = findWinner row
if p then
@winner = p
end
end
end
def switchPlayer
if @player == Player1 then
@player = Player2
else
@player = Player1
end
end
def getPlayed(cell)
c = cell[0]
r = cell[1]
col = @cols[c]
if r >= col.length then
return r - col.length + 1
end
return @cols[c][r]
end
def posValid( c, r )
return c >= 0 && c <= 6 && r >= 0 && r <= 5
end
def getDiagonal( c, r, dc )
d = []
while posValid( c, r )
d << [c, r]
c += dc
r += 1
end
return d
end
def getAllDiagonalsRanges
diags = []
for r in 0..5
diags << getDiagonal( 0, r, 1 )
end
for c in 1..6
diags << getDiagonal( c, 0, 1 )
end
for r in 0..5
diags << getDiagonal( 6, r, -1 )
end
for c in 0..5
diags << getDiagonal( c, 0, -1 )
end
return diags
end
def getAllColsRanges
return (0..6).collect{|c| (0..5).collect{|r| [c, r]}}
end
def getAllRowsRanges
return (0..5).collect{|r| (0..6).collect{|c| [c, r]}}
end
def getAllRanges
return getAllColsRanges +
getAllRowsRanges +
getAllDiagonalsRanges
end
end
class Node
attr_reader :state, :children, :isLeaf
def initialize( state, player )
if !player then
raise "player is nil"
end
@state = state
@isLeaf = true
@children = {}
@player = player
end
def getPoints( row )
points = 0.0
for i in 0..(row.length-4)
p = nil
n = 0
divider = 1
for j in 0..3
rp = @state.getPlayed(row[i+j])
if rp.class == Fixnum then
divider *= rp
else
if !p then
p = rp
elsif !rp then
elsif p != rp
p = nil
break
end
if rp then
n += 1
end
end
end
if p then
blockPoints = calculatePoints n / divider
if p == @player then
points += blockPoints
else
points = points - blockPoints
end
end
end
if points.infinite? then
debug "Found winner: " + points.to_s + ": " + row.join("|")
end
return points
end
def calculatePoints( n )
return n.to_f**3 / (4 - [n,4].min)
end
def nodePoints
points = 0.0
for row in state.getAllRanges
p = getPoints(row)
if p != 0 then
#debug row.collect{|r| if r then r else " " end}.join("|") + " " + p.to_s
end
newPoints = points + p
if newPoints.nan? then
raise "points + p == NaN: points=" + points.to_s + " p=" + p.to_s
end
points = newPoints
end
#puts state
#puts "Points: " + points.to_s
return points
end
def allChildPoints
return children.values.collect {|child| child.totalPoints}
end
def isMyTurn
return state.player == @player
end
def totalPoints
if @totalPoints then
return @totalPoints
end
p = nil
if @isLeaf then
p = nodePoints
else
if isMyTurn then
p = allChildPoints.max
else
p = allChildPoints.min
end
end
if !p then
raise "nil points returned"
end
@totalPoints = p
return p
end
def grow
if @totalPoints then
#puts "Gah, totalPoints is set"
@totalPoints = nil
end
if @isLeaf && !@state.winner
#debug "Growing leaf: " + self.to_s
for i in 0..6
if @state.canPlay i then
childState = @state.deep_copy
childState.play i
child = Node.new(childState, @player)
children[i] = child
end
end
@isLeaf = false
else
for child in @children.values
child.grow
end
end
end
def findNodeWithState( state )
if state.lastPlayed then
return @children[state.lastPlayed]
else
return nil
end
end
def to_s
return "Played: " + @state.lastPlayed.to_s + " Points: " + totalPoints.to_s
end
end
class AIPlayer
def initialize( level, name )
@level = level
@name = name
end
def to_s
return @name + " (" + @level.to_s + ")"
end
def selectBestNode
# Add some randomness
bestChild = nil
bestChildCount = nil
for child in @node.children.values
#puts child.state
#puts child.totalPoints
if !bestChild then
bestChild = child
bestChildCount = 1
else
if child.totalPoints > bestChild.totalPoints then
bestChild = child
bestChildCount = 1
elsif child.totalPoints == bestChild.totalPoints then
bestChildCount = bestChildCount + 1
if rand(bestChildCount) == 0 then
bestChild = child
end
end
end
end
#Just to make sure
if !bestChild then
raise "bestChild is nil"
end
debug "Best points: " + bestChild.totalPoints.to_s
@node = bestChild
end
def play(state)
if state.lastPlayed then
debug "Finding last played node"
@node = @node.findNodeWithState(state)
@node.grow
end
debug "Finding the best node"
selectBestNode
@node.grow
state.play @node.state.lastPlayed
end
def setupGame(state, player)
@node = Node.new(state, player)
debug "Creating min max tree (" + (7**@level).to_s + " nodes)..."
(1..@level).each{ @node.grow }
end
end
class HumanPlayer
def initialize(name)
@name = name
end
def to_s
return @name
end
def play(state)
puts @name + ", make your move:"
begin
toPlay = gets
if toPlay == "q\n" then
exit
end
toPlay = toPlay.to_i
if !state.canPlay toPlay
puts "Can't play " + toPlay.to_s + ". Select another:"
selectOther = true
else
state.play toPlay
end
end while selectOther
end
def setupGame(state, player)
end
end
def runGame
puts "Run against ai (A), another player (P) or let two AIs play against eachother (X)?"
gameType = readline.strip
case gameType
when "A", "a"
player1 = createAIPlayer
player2 = createHumanPlayer
when "P", "p"
player1 = createHumanPlayer
player2 = createHumanPlayer
when "X", "x"
player1 = createAIPlayer
player2 = createAIPlayer
else
puts "Invalid input: #{gameType}"
exit
end
players = [player1, player2]
state = State.new
player1.setupGame(state, State::Player1)
player2.setupGame(state, State::Player2)
while (!state.winner && !state.isFull)
for player in players
puts state
player.play(state)
puts player.to_s + " played: " + state.lastPlayed.to_s
if state.winner then break end
end
end
if state.winner
puts state
puts "Winner: " + state.winner.to_s
elsif state.isFull
puts state
puts "Draw!"
end
end
$aiCounter = 0
def createAIPlayer
$aiCounter = $aiCounter + 1
name = "AI " + $aiCounter.to_s
puts "Enter " + name + " level (1 to 5):"
level = readline.to_i
return AIPlayer.new(level, name)
end
$humanCounter = 0
def createHumanPlayer
$humanCounter = $humanCounter + 1
defaultName = "Human " + $humanCounter.to_s
puts "Enter name of human player (default " + defaultName + "):"
name = readline.strip
if !name || name == "" then
name = defaultName
end
return HumanPlayer.new(name)
end
def runTests
state = State.new
state.play(3)
state.play(3)
state.play(4)
state.play(4)
state.play(5)
state.play(5)
state.play(6)
#test getPlayed
if state.getPlayed([3, 0]) != State::Player1 then raise "getPlayed doesn't work" end
if state.getPlayed([3, 1]) != State::Player2 then raise "getPlayed doesn't work" end
if state.getPlayed([3, 2]) != 1 then raise "getPlayed doesn't work" end
if state.getPlayed([3, 2]).class != Fixnum then raise "getPlayed doesn't work" end
#test findWinner
winningRow = (3..6).collect{|c| [c, 0]}
if !state.findWinner(winningRow) then raise "findWinner doesn't work. winningRow=" + winningRow.to_s end
#test state.winner
if state.winner == nil then raise "winner should be set" end
puts "All tests ok"
end
runGame
#runTests
Monday, February 2, 2009
BDD using NBehave + Rhino Mocks AMC
Update: I found an old blog post by Aslak Hellesøy (the main developer behind Cucumber) that touches on this subject.
Some time ago, I investigated what BDD is all about. In essence, it's TDD with a twist. For example, the word "test" implies that we're testing what someone (we?) already made, but TDD says we're going to write the tests before the actual implementation of the unit of code. Somewhat, the word "test" has a direction backwards, while "should" has a direction forward. Hence, "should" is more comprehensive to use when describing and specifying the future. Makes sense?
What I'd like to show you is a piece of code I wrote to see how NBehave's story runner could work with Rhino Mocks' Auto Mocking Container[1, 2].
Now a question pops up: since we have only specified and tested the first (top-level) interaction, what about the rest of the interactions? I think this is a good question that leads us further down the rabbit hole.
A written user story comes from a dialogue with a person with domain knowledge. Hopefully, after some discussion, we have understood some of the moving parts of the domain problem the customer wants us to solve. Let's assume that we want to implement a single feature at a time, a couple of questions arise: should we start top-down or bottom-up? And how far "up" should we go, i.e. should we start with the UI or the domain model, if we choose a top-down approach?
If we choose to start with the domain model, then I think the above way of specifying the behavior looks nice. The key question is where the classes in the story come from originally. I have no easy answer for that. Of course they should originate from the domain problem, but how? "The model is the code - the code is the model", but it probably takes a while to "get it right". Maybe code like the above could help us to see if we have understood the problem in the first place?
Now back to the question: "what about the rest of the interactions"? We have ensured that the class which is in "the center" of the particular interaction chain (the player turn) lives in a faked world (a small board and a player near go) and we finally assert that when something happens (player passes 'GO') then some state has changed (the player gets money). The nice thing is that we now know more about what functionality the dependent classes should provide. For example, IBoard needs to have a method GetIndexForPlayer and if there is a class implementing that interface, then a NotImplementedException is probably thrown from that method, in order to compile. Next step could be to start thinking on that particular method and choose to either write a mocked unit test or an "ordinary" unit test.
Of course, real acceptance tests are also needed, but the purpose and scope of those tests are quite different. At least that's what I think.
What do you think?
Some time ago, I investigated what BDD is all about. In essence, it's TDD with a twist. For example, the word "test" implies that we're testing what someone (we?) already made, but TDD says we're going to write the tests before the actual implementation of the unit of code. Somewhat, the word "test" has a direction backwards, while "should" has a direction forward. Hence, "should" is more comprehensive to use when describing and specifying the future. Makes sense?
What I'd like to show you is a piece of code I wrote to see how NBehave's story runner could work with Rhino Mocks' Auto Mocking Container[1, 2].
[Story, Test]When this test is run with ReSharper, the test passes and outputs the story with indentation. Nice! (Except the "mockery has started" part of the story..)
public void GetMoneyWhenPassGO()
{
// Set up and initialize
var mocks = new MockRepository();
var container = new Rhino.Testing.AutoMocking.AutoMockingContainer(mocks);
container.Initialize();
// Resolve and obtain references
IPlayerTurn turn = container.Create<PlayerTurn>();
IBoard board = container.Resolve<IBoard>();
IPlayer player = container.Resolve<IPlayer>();
turn.AddPlayers(new List<Player>() {player});
// Story begins here
var story = new Story("Player recieves money when passes 'GO'");
story
.AsA("Player")
.IWant("to recieve money when I pass 'GO'")
.SoThat("I can buy things that generate money");
story
.WithScenario("Normal play scenario")
.Given("A board with 4 squares", () => Expect.Call(board.NumberOfSquares).Return(4))
.And("a player near 'GO'", () => Expect.Call(board.GetIndexForPlayer(player)).Return(2))
.And("mockery has started", () => mocks.ReplayAll())
.When("player passes 'GO'",() => turn.PlayerSequence(player, 3))
.Then("the player earns $4000", () => player.AssertWasCalled(x => x.Credit(4000)));
}
Now a question pops up: since we have only specified and tested the first (top-level) interaction, what about the rest of the interactions? I think this is a good question that leads us further down the rabbit hole.
A written user story comes from a dialogue with a person with domain knowledge. Hopefully, after some discussion, we have understood some of the moving parts of the domain problem the customer wants us to solve. Let's assume that we want to implement a single feature at a time, a couple of questions arise: should we start top-down or bottom-up? And how far "up" should we go, i.e. should we start with the UI or the domain model, if we choose a top-down approach?
If we choose to start with the domain model, then I think the above way of specifying the behavior looks nice. The key question is where the classes in the story come from originally. I have no easy answer for that. Of course they should originate from the domain problem, but how? "The model is the code - the code is the model", but it probably takes a while to "get it right". Maybe code like the above could help us to see if we have understood the problem in the first place?
Now back to the question: "what about the rest of the interactions"? We have ensured that the class which is in "the center" of the particular interaction chain (the player turn) lives in a faked world (a small board and a player near go) and we finally assert that when something happens (player passes 'GO') then some state has changed (the player gets money). The nice thing is that we now know more about what functionality the dependent classes should provide. For example, IBoard needs to have a method GetIndexForPlayer and if there is a class implementing that interface, then a NotImplementedException is probably thrown from that method, in order to compile. Next step could be to start thinking on that particular method and choose to either write a mocked unit test or an "ordinary" unit test.
Of course, real acceptance tests are also needed, but the purpose and scope of those tests are quite different. At least that's what I think.
What do you think?
Friday, January 16, 2009
The small things: Fisher Space Pen
I got this pen from my girlfriend as a christmas gift. It's a Fisher Space Pen and I'm very happy for it!
I believe that it's really worth investing in the cheap stuff you use daily, like pen and paper (though, in this case my girlfriend did the investment, but that's another story). Of course, that's assuming that you use pen and paper. You really should - pen and paper are great tools!
Subscribe to:
Posts (Atom)