Playing GOLF, hole 3

So in hole 1 and 2 we started with the most simple tests and we already implemented a standard way of iterating over a game board, which is a list of lists. Time to add some more tests and to expand our example. Before I do, though, just one little side note on the F# development environment. I regularly use functions before they exist. The F# environment constantly checks my program for these loose, non-existent functions, which slows down my Visual Studio. Kind of like the VB compiler does. This is quite annoying. I haven't yet found how I can make the F# compiler not constantly check for coding errors.

That said, on to the next test. Let's make it a little more complex and skip two live cells, but go directly to three live cells.

 [<TestFixture>] 
 type ``Given a gameboard with three live neighbour cells`` ()= 
   let gameboard =  
     [[0; 0; 0]; 
     [1; 1; 1]; 
     [0; 0; 0]] 
  
   let gameboard_after_gen_1 =  
     [[0; 0; 0]; 
     [0; 1; 0]; 
     [0; 0; 0]] 
    
   [<Test>] member test. 
    ``When I ask for generation 1, the middle cell should still live`` ()= 
     conway gameboard 1 |> should equal gameboard_after_gen_1   

This test will be red, because all cells after a first generation will be dead. We will need to add extra code to keep certain cells (those with two living neighbours) alive. Remember the code we had up until now:

 module GOL 
  
 let kill gameboard = 
   let rec kill_row new_row =  
     let length = List.length (List.head gameboard) 
     if List.length new_row = length then 
       new_row 
     else 
       kill_row (0 :: new_row)  
          
   [1 .. List.length gameboard] |> 
      List.map(fun x -> kill_row List.Empty)  
  
 let conway gameboard n = 
   match n with 
     | 0 -> gameboard 
     | 1 -> kill gameboard  

The line that needs to be altered is the one where we prepend (cons in F# terms) the number 0 with the new_row parameter. In stead of always consing 0, we will need to calculate which number needs to be consed. To do this calculation we will also need some notion of the row and cell index for which we need to calculate this value, so this needs to be added somehow as well. The row index can be send along via the List.map function at the bottom. The cell index can be calculated from the length of the new_row parameter up until now.

If we add the notion of a row_index, the code will look like this (changes are marked in red):

 let kill gameboard = 
   let rec kill_row row_index new_row =  
     let length = List.length (List.head gameboard) 
     if List.length new_row = length then 
       new_row 
     else 
       kill_row row_index (0 :: new_row)  
          
   [1 .. List.length gameboard] |> 
     List.map(fun x -> kill_row x List.Empty)  
   

If we add a calculation of a new_cell_value for a certain cell index, it will look like this:

  
 let kill gameboard = 
   let calc_next_cell_value x y =  
     0 
   let rec kill_row row_index new_row =  
     let length = List.length (List.head gameboard) 
     if List.length new_row = length then 
       new_row 
     else 
       let new_cell_value = 

            calc_next_cell_value 

            (length - (List.length new_row)) row_index 
       kill_row row_index (new_cell_value :: new_row)  
          
   [1 .. List.length gameboard] |> 

      List.map(fun x -> kill_row x List.Empty)   

As for the calc_next_cell_value function, let's do this as naively as we did before. Implement just enough to make the test pass. I first tried it this way, using the build in Item function to get an item from a list:

 let calc_next_cell_value x y =  
   let current_cell_state = gameboard.Item(y).Item(x) 
   let number_of_alive_neighbours =  
     gameboard.Item(y).Item(x - 1) + 
     gameboard.Item(y).Item(x + 1) 
   if current_cell_state = 0 then 
     0 
   else if current_cell_state = 1 && 
     number_of_alive_neighbours = 2 then 
     1  

   else 0 

This might work, but the compiler seems to need type information concerning the list you get once you execute Item(y) on it (it is needed to resolve the Item(x) call). Adding this type information however, was not something I wanted to do. So instead of adding a type to the gameboard parameter, I wrote my own functions to get at a certain cell.

 let cell x y = 
   nth x (nth y gameboard) 
 let calc_next_cell_value x y =  
   let current_cell_state = cell x y 
   let number_of_alive_neighbours =  
     cell (x - 1) (y) + 
     cell (x + 1) (y) 
   if current_cell_state = 0 then 
     0 
   else if current_cell_state = 1 && 
     number_of_alive_neighbours = 2 then 
     1 
   else 0  

The nth function is written as a recursive function on the list and it actually adds some boundary checking. Once we go out of bounds (our n is bigger than our list length or smaller than 1), we always return 0. If we stay in bounds, we check if n is 1, this means we can return the head of the list. In all other cases, we decrement n and execute the nth function on the tail of the list.

 let rec nth n list =  
   if n > List.length list then  
     0 
   else if n < 1 then  
     0 
   else if n = 1 then  
     List.head list 
   else 
     nth (n - 1) (List.tail list)  

To make this implementation of the nth function more visible, suppose our list is as follows: [1; 2; 3; 4; 5] and we ask for the third element. The bottom else case will get executed. The nth function is called again with an n of 2 and a list of [2; 3; 4; 5] (the tail of the original list). Again the bottom else statement will be executed, which will call the nth function again with a n of 1 and a list of [3; 4; 5]. This time the n parameter equals 1 and the head of the list will be taken, which has the value of 3. This again is a very commonly used pattern when working with lists in functional languages.

But this implementation of nth actually keeps the problem of the compiler complaining about the type we get when executing the function (it is more or less the same problem we had with the Item(y) call). F# is quite strict in working with types. And this was one of the primary problems I had while implementing the Game Of Life. Where as a language as Scheme (from which I ripped the solution) doesn't bother with types, F# does. And if you execute the nth function as follows: (nth y gameboard), you actually want a list at a certain index in a list of lists. And if you execute the nth function again for the x parameter, you actually want the cell at position x in a list of integers. So one time you are operating on a list of lists and the next on a list of integers. F# doesn't like that. So, to solve this problem I added another function,to get the nth row in a list of lists.

 let rec nth_row n list = 
   if n > List.length list then 
     [] 
   else if n < 1 then 
     [] 
   else if n = 1 then 
     List.head list 
   else nth_row (n - 1)(List.tail list)  

This function looks very similar to the nth function, with the difference that it explicitly tells the compiler it will return something of the list type.

On the calling side, I changed the code to this:

 let cell x y = 
   nth x (nth_row y gameboard)  

The entire implementation now looks like this:

 let rec nth_row n list = 
   if n > List.length list then 
     [] 
   else if n < 1 then 
     [] 
   else if n = 1 then 
     List.head list 
   else nth_row (n - 1)(List.tail list) 
  
 let rec nth n list =  
   if n > List.length list then  
     0 
   else if n < 1 then  
     0 
   else if n = 1 then  
     List.head list 
   else 
     nth (n - 1) (List.tail list) 
  
 let do_generation gameboard = 
   let cell x y = 
     nth x (nth_row y gameboard) 
   let calc_next_cell_value x y =  
     let current_cell_state = cell x y 
     let number_of_alive_neighbours =  
       cell (x - 1) (y) + 
       cell (x + 1) (y) 
     if current_cell_state = 0 then 
       0 
     else if current_cell_state = 1 && 
       number_of_alive_neighbours = 2 then 
       1 
     else 0 
   let rec kill_row row_index new_row =  
     let length = List.length (List.head gameboard) 
     if List.length new_row = length then 
       new_row 
     else 
       let new_cell_value = 
         calc_next_cell_value 
         (length - (List.length new_row)) 
         row_index 
       kill_row row_index (new_cell_value :: new_row)  
          
   [1 .. List.length gameboard] |> 
     List.map(fun x -> kill_row x List.Empty)  
  
 let conway gameboard n = 
   match n with 
     | 0 -> gameboard 
     | 1 -> do_generation gameboard  

You might have noticed I also changed the name of the kill function to do_generation. Refactoring this was needed!

And this is actually already the main part of our Game Of Life. The only thing that still needs to be added, are some more calculations for the alive count of a cell and some extra rule checks for keeping cells alive or killing them off, and off course the ability to calculate more than 1 generation.

I will add all of those at the next hole.

Playing GOLF, hole 2

The first hole of playing GOLF, involved the first most simple tests one could write for Conway's Game Of Life. In this next post we will add tests for a gameboard with life cells (actually just one life cell for now). For this I created a new TestFixture, so all tests are nicely separated in the ReSharper runner.

 [<TestFixture>] 
 type ``Given a gameboard with 1 live cell`` ()= 
   let gameboard =  
     [[0; 0; 0]; 
     [0; 1; 0]; 
     [0; 0; 0]] 
   let dead_gameboard =  
     [[0; 0; 0]; 
     [0; 0; 0]; 
     [0; 0; 0]]

 
   [<Test>] member test. 
    ``When I ask for generation 0, should not change gameboard`` ()= 
     conway gameboard 0 |> should equal gameboard 

   [<Test>] member test. 
    ``When I ask for generation 1, the life cell should be dead`` ()= 
     conway gameboard 1 |> should equal dead_gameboard  

The example above immediately adds two new tests. The first one will be green immediately using the current implementation, this is why I didn't bother to split this example up. The second test, however, will not pass. The current implementation simply returns the gameboard as is and doesn't yet alter it. We need to implement our conway function further to make this test turn green. This is the code, I will explain it part by part, so it's not too overwhelming if you've done little to no F# coding.

 module GOL 
  
 let kill gameboard = 
   let rec kill_row new_row =  
     let length = List.length (List.head gameboard) 
     if List.length new_row = length then 
       new_row 
     else 
       kill_row (0 :: new_row)  
          
   [1 .. List.length gameboard] |> List.map(fun x -> kill_row List.Empty)  
  
 let conway gameboard n = 
   match n with 
     | 0 -> gameboard 
     | 1 -> kill gameboard 
   

This is actually quite a naive way of implementing the red test case. For making a first generation, we kill off the entire gameboard. I did this on purpose, because this way, you can see the basic way you can use for working with lists, or better, lists of lists in our case. The gameboard is actually a list of lists, so if we want to do some operation on it, we do this list per list (or row per row). This basic implementation is also the most simple implementation you can give, to make the test pass.

As for the starting point of our conway function, which you can find at the bottom of the example code, I used F#'s feature of pattern matching. This is actually something very powerful and looks a lot like a switch case in regular programming languages. Except that pattern matching in F# is more like a switch case on speed, since it gives you more opportunities. In this example the speed is still a bit missing, we just have two cases up until now, a 0 and a 1 case. For the 0 case we just return the gameboard as is. For generation 1 we kill off the gameboard.

As for the kill function, the actual starting point is the bottom line with the List.map in it (the other lines represent an inner function, but more about that in a while). This tells the compiler to execute the function kill_row for the input we give it. This input is actually a list of integers of 1 up until the length of our game board (which is the number of rows in it).

The kill_row function is an internal function of the kill function. This has the advantage that the gameboard input parameter is accessible and we can use it to calculate the length of one row. For this we take the first row, using List.head and of this we take the length, with List.length. This calculation of the length is something that will be done only once, not for each recursive call.

The input parameter for kill_row is an empty list. Item per item in a row, we will prepend the number 0 (kill off one cell) to this list. This process continues until we get a row of all zero's that has the same length as the length of one row of our game board (the length variable). And since the input for the List.map function is a list (one of integers), each resulting row will be put in this list. We actually transform a list of integers into a list of rows (where each row is again a list of integers).

This might seem an unusual way of working, but is actually quite a common pattern of iterating over lists and building new lists in a functional language. It takes some getting used to as well. And from time to time it just looks weird, since most of us are used to doing this with loops.

This implementation also made our tests green, so on to hole number 3.

Playing GOLF, hole 1

A while back I started with the idea of writing the Game Of Life test first using F#. I already blogged some about this, but this week I finally found the time to actually implement all this from start to finish. I did start all over again though, since my last post didn't really contain a functional starting point. And I did give it some tries to get the code right and I also took a peek at the Scheme implementation that can be found at this link (hey, it's been five years since I've done functional programming, I am allowed to make mistakes and to see what others have done). So it is quite possible that there are similarities between my implementation and the Scheme version. There is also an F# version that can be found at that site, but it's implementation uses a bit too many nested for loops for my liking.

First of all, I rewrote my first test. The idea of having cells that know how many living neighbours they have, was nice at first, but with this implementation I wanted to start of with a gameboard of all dead cells. For my first most simple test, I started of with: If I have all dead cells, than after zero generations all cells should still be dead.

 namespace GolF.Tests

 
 open NUnit.Framework 
 open FsUnit 
 open GOL 

 [<TestFixture>] 
 type ``Given a dead gameboard`` ()= 
   let gameboard =  
     [[0; 0; 0]; 
     [0; 0; 0]; 
     [0; 0; 0]] 

   [<Test>] member test. 
    ``When I ask for generation 0, should not change gameboard`` ()=  
     conway gameboard 0 |> should equal gameboard  

To make the test compile I added the conway function, which just returned a string (I didn't want to make the test green, yet).

 module GOL 

 let conway gameboard n = 
   "test"  

This made the test compile, but off course it was still red.

To make the test pass, I altered the conway function a bit.

 let conway gameboard n = 
   gameboard  

Plain and simple. Implement the most simple thing to make the test turn green.

So, time to add a second test: If I ask for generation 1 of a dead gameboard, the gameboard should still be dead.

   [<Test>] member test. 
    ``When I ask for generation 1, gameboard should still be dead`` ()= 
     conway gameboard 1 |> should equal gameboard  

This test actually immediately passes with the current implementation, but it is a good test to have around once we start adding the actual code of calculating generations.

That's all for the first hole of playing GolF, on to the second one.

Book review: Professional F# 2.0

In one of my last posts I wrote about a F# application written test first. While working on this application I read the book 'Professional F# 2.0' from Wrox. Personally I believe the Wrox books are most of the time the best books you can find on a subject, especially their 'Professional' series.They go very deep into each subject and give you all the details you need to know. So here is what I think about the Professional F# book, by Ted Neward, Aaron Erickson, Talbott Crowell and Rick Minerich.

The book begins with an extensive explanation of the different F# language constructs you can use. The same explanation you would get in a typical C# book, in fact. While this section gives you all the necessary language details: what types look like in F#, how certain constructs, like ifs and whiles, need to be written. It lacks, however, the basic explanation of how a language like F# should be used. As a reader you don't get much of a clue why these kinds of constructs might be useful. The few points where you do get some extra info on the style in which to write F# code, a reader without any knowledge of functional programming, will be nonplussed about why certain things are done in a certain way. That really is a shame, because I think a lot of readers will drop off once they see the extensive differences in language constructs they need to overcome when coming from a more traditional language.

I was hopeful though that in 'Part III: Functional Programming' there would actually be some good information about how to program using a functional style. But alas, again the author goes on and on about language constructs, what functions look like and how you write them, not how you use them properly. Some more advanced topics also come into play, like closures. Not that this is so extremely advanced, but it is a concept you don't hear every day, you use it quite often, though, even in C#, but you don't always think of it as being a closure. The explanation the author gives for the closure concept, however, is quite difficult to understand, up to the point where I had to use Google to get the right explanation. Same goes for the principle of currying, which, in my opinion, is explained the wrong way.

As for the F# language itself, it adds quite a lot of special constructs you do need to get used to. Especially when writing your first F# program, be sure to have a language reference nearby. For such a reference, this book is ideal. It explains all the little tidbits you need to know. But still, in my opinion, F# adds a lot of unnecessary language constructs. When you are, for instance, defining a recursive function, you are obliged to use the rec keyword, otherwise the compiler won't allow you to call yourself. Coming from a Lisp kind of language, this adds noise to your code (although I have to admit Scheme has its own weird language constructs).

Since this book was quite a disappointment for me, I would gladly like to guide you to some other useful resources:

• The MSDN library will not be of much help. It will give also you a lot of info about the language, as this book does, but it doesn't say much about the programming style to use. What you can find on the MSDN site, however is how to get started setting up your first F# project in Visual Studio. This was something I struggled with in the beginning of programming F#, how a project is structured.
• Tryfsharp: This site by the Microsoft research team lets you go through an interactive tutorial in which you can immediately try out different examples in an F# interactive console. In their tutorial they explain all the important F# constructs that are different from the other programming languages you come across (without too much other explanatory crap that you do not need to know). The examples given are also quite easy to follow (with some small exceptions). The examples given were also quite close to the examples you will find in introductory books on functional programming style. This site is based on the book 'Programming F#' by Chris Smith (O' Reilly). I actually good much better information on this site than in the Wrox book.
• fsharp community samples: These can be found at codeplex. You can find some samples here, but also quite some links to other resources and blogs. Good starting place, if you ask me.
• F# wikibook: Explains not only the basic concepts, but also some advanced topics such as advanced data structures in F#, which, after you've gone through the introductory stuff are quite useful.

With all this material I now hope to get a better Game Of Life written. I will probably throw away what I already have and not try it with a class, but with only functions. We'll see where this ends.

Playing GOLF

Qframe recently held a bootcamp where all employees were invited to follow sessions on all kinds of things. One of those was a code retreat in which we tried to implement as much of the Game Of Life as possible in 45 minutes time, while giving ourselves a couple of restrictions (implement this without using if statements, implement this test first, ...). We redid this exercise a couple of times and during the last go, I and some colleagues gave ourselves the restriction of using a completely different language than the one we are used to. So we tried implementing this in F# (hence the name GOLF: Game Of Life in F#). I must say, we didn't get very far, but ever since I have been playing with the idea of finishing this exercise. In this post you will find my experience in trying this.

First of all, I must admit, I do have some experience in functional programming. This doesn't mean however I am a bright and shining light in functional programming (all but). But I have used Scheme for a year at university and I still know what a car and cdr are, what a REPL loop is, and so on. On the other hand, I am pretty sure that in the GOLF exercise I made some very big errors in functional programming and I hope you, as a reader, are a bit forgiving for those. One thing that's new to me is the fact that I can mix a functional style with objects. So, feel free to comment on the code, since I do want to learn from my mistakes!

To get started I needed an F# project. I choose to use an F# Library project, since I wanted to start with all the logic of the game first, a fancy user interface can be added later. This type of project gives you two files, a Module1.fs file, in which to place your code and a Script.fsx file, in which you can write code to informally test your F# program. Since I am going to use a unit testing framework to test the F# code, I removed the .fsx file.

Another thing you need to be aware of when writing F# code, is the order in which you place your files. They are processed in order by the F# compiler, so make sure a type (or function, or whatever) is known by the compiler before you use it. This sort of looks like the behaviour you have with a C++ compiler, where you need the correct include statements to let types know each other. A C# programmer doesn't need to worry about this, since all types within the same project know each other.

After the basic project setup, I wanted to write this application test first. So after some Google research I found a couple of unit test libraries you can use with F#. In fact you can use the NUnit framework if you want to, but I choose to use FsUnit, which adds a more natural style of writing tests for F# (and uses NUnit to annotate its tests). Since the FSUnit project is hosted on nuget, installing it, was quite easy (install-package fsunit and you're done). The nuget package also adds a .fs file that gives you some example test cases to get started. I didn't go into the effort at first to place my test code in a second F# library project. I can still do this later on. I did place the test code in a second .fs file (after the Module1.fs file).

Ok, so on to writing my first test. I started simple in saying that when I create a new Cell in the Game Of Life, it shouldn't have any neighbours. F# has the notion of namespaces, you can add those at the top of your file. If you want to use functionality from other libraries (like NUnit, FsUnit and the module1 file I am writing tests for), you need to add an open statement for each. This is actually similar to writing using statements for namespaces you want to use. After this you can place your first test class. in my case this class is called ''Given a new cell''. This naming style is handy when looking at your tests in a test runner. F# (or FsUnit, I actually don't know which) permits spaces in the class name, as long as you surround it with quotes. Beware though, these are two single quotes that start at the top left corner and end at the bottom right corner (they do NOT go straight down, look for them on your keyboard!). Since this is a test class, you need to decorate it with the TestFixture attribute.

 namespace GolF.Tests 
  
 open NUnit.Framework 
 open FsUnit 
 open Module1 
  
 [<TestFixture>]  
 type ``Given a new cell`` ()= 
   let cell = new Cell() 
  
   [<Test>] member test. 
    ``when I ask how many neighbours it has, should answer 0.`` ()= 
       cell.numberOfNeighbours |> should equal 0  

The actual test creates a new Cell class, which I still need to implement, I am working test first. And after that you can find my first test. Again, I use the fact that you can place an entire sentence between those funky quotes. The test is annotated with the Test attribute and I also indicate this test method as being a member of the test class. Beware though that F# does a lot of its parsing based on indentation, so indenting in the correct way is really important. After I wrote my first test, the F# compiler was actually complaining about the ``when I ask how many neighbours it has, should answer 0.`` sentence, which I found strange. The FsUnit example file, with the same sort of syntax, compiled just fine. After some really hard looking at the two files, I found out that before the sentence there is not only a tab, but also a white space, which is very easy to miss.

With this test written, it was time to get it compiling, meaning I had to provide a Cell type with a numberOfNeighbours member.

 module Module1 
  
 type Cell =  
   val numberOfNeighbours : int 
   new() = { numberOfNeighbours = 0 } 

This immediately made my test green, which actually isn't good practice, but I'll ignore that for now.

Time to add some more tests. I will finish this little application during the next weeks and will post some more about my findings during that time, until we get a finished Game Of Life example. I hope this short post will be enough to get you started in F# projects for now.

NDC 2011

Last week some colleagues and I went to the NDC conference in Norway.

Apart from the weather, which was crappy, it was an awesome conference. I've seen some great talks and am looking forward to watching some of the talks I missed (because I was in another session) online. I also went home with some new great ideas for books I want to read:

• Introducing HTML 5, by Bruce Lawson and Remy Sharp. They gave the HTML 5 talks during the second day of the conference in a small and very crowded room. They convinced me even more of the amazing things you can do for web pages with the new upcoming standard. It was a relieve as well to hear someone from the Opera browser team talking about HTML 5 instead of the standard Microsoft talks I heard thus far. 
• Test-Driven JavaScript Development, by Christian Johansen. Too bad his talk was given simultaneously with Rob Ashton's (Document databases with ASP.NET MVC), Kevlin Henney and Anders Norås's (Introducing The FLUID Principles) and Hadi Hariri's (Dynamic in a Static World). I went to this last session, which was very good. It gave me some ideas and examples of more things I can start doing with dynamic. I would really like to try to get a DSL written with it (I would probably start off by copying a Ruby example, since it is not easy stuff). The talk about the FLUID principles was very good as well, my colleagues went to that one and it is one of the talks to catch on rerun, once they put the videos up. I did follow the talk about the SOLID principles, which was nice to refresh again. I went to the RavenDB by Example talk on day  3 of the conference. It was a good thing the speaker also mentioned some of the problems he had with a document database, having to rethink the design of your data as opposed to relational databases.
• The Joy of Closure, by Michael Fogus and Chris Houser. I didn't get to catch any of the Closure and F# talks and it would be nice to get up to speed with this. Also something to watch on rerun and see what we can do with it
• 97 Things Every Programmer Should Know, by Kevlin Henney and 97 Things Every Software Architect Should Know, by Richard Monson-Haefel. I only went to Kevlin's talk about the 101 things he learned in architecture school, which was light, but enlighting. His other two talks apparently were very good as well, as my colleague went to those.
• Specification By Example, by Gojko Adzic. His talk wasn't so good, but I think a lot can be learned from this book. One thing I will really remember from the conference is the multiple question marks that speakers had with BDD, DDD and agile. While they are all good techniques, they have their flaws and the software community really needs to figure out how we can do these things even better. Gojko's post on his blog about one of these talks really explains the problem a bit as well. He also mentioned our Cronos colleagues from iLean in his talk, which I think was pretty cool. And he is also one of the creators of cuke4ninja, a port of cucumber for .Net.

Apart from those books and talks I already mentioned, I also followed some of the talks on mobile development. The ones about multi platform development were really informative. The MonoTouch and MonoDroid projects have moved from Novell to Xamarin and are planning on a next release in the coming months. Biggest take-away there was: use the latest MonoTouch and MonoDroid builds for now and switch to the Xamarin builds once they are published. Jonas Follesoe's talk on this topic was great, if you're doing mobile, catch it on rerun! 

I also really liked the AOP talks given by the PostSharp people. They have a great framework for doing AOP, which is really powerfull and which gives you a lot of cool features for keeping your code nice and, well, sharp. They also mentioned some other AOP frameworks, which I think is a nice gesture, since they are not the only ones out there.

The CQRS talk by Fredrik Kalseth was inspiring as well, although he only mentioned one part of CQRS. It was explained really well and can be used as a basis on future projects. I also learned in his talk that JetBrains have a Ruby IDE which I didn't know about. As I look at their site now, I see they're also working on an Objective-C IDE. 

So, all in all, a very good conference, which I hope to catch again next year, and hopefully without the rain. I learned a lot and have now a whole lot of stuff to read and learn even more about. Too bad there's only 24 hours in a day (of which I really need 9 to sleep, since I'm a sleepy head).

Thanks as well to my colleague, Guy, for providing some very nice pictures. You can find the entire collection here.