Tag Archives: coderetreat

Facilitating the Global Day of Coderetreat 2013 in Amsterdam

On the 14th of December 2013 – the Global Day of Coderetreat was held at ZilverlineI have experience with coderetreats and also organised one at the 7th of january in 2012, and the GDCR12.

This time I both hosted and facilitated this event. This means that besides practical stuff I also did the talking which I will explain further in this post. This was the first time I did this and I’d like to share how it was. If you want to get an impression of the day you can have a look at this slideshow.

A big thanks to Bob Forma and Diana Sabanovic who helped me with the hosting aspects throughout. This enabled me to mostly focus on facilitating.

I was anxious, especially since last years GDCR was very well done. Back then I had a great experience and I was not sure if I could give the participants the same experience. Yet, I wanted to do this: I just love sharing knowledge and give people something to learn or think about.

After attending the GDCR Facilitator Training by Jim Hurne, I had a clear image of how I wanted the participants to experience the Coderetreat: People having fun, learning from each other and the constraints given.

Thats it.

Continue reading

Stuff I’ve learned #02

Some time has passed, and I’ve learned new stuff again:

  • Updating a single gem is not done with ‘bundle update <gemname>’ but in fact with ‘bundle update –source <gemname>’. See this post for more info on that.
  • Mailbox (iOS) is a really neat mail program. I really love this ‘remind me later’ stuff which keeps my mailbox clean and keeps me from writing these reminders myself in the Calendar app.
  • With CTRL-F2 you can get focus on the menu bar in any mac app. (more keyboard shortcuts here)
  • With JSONLint you can easily verify JSON.
  • In Ruby you can actually create a Hash using brackets with key, value order. Ie like: Hash[“myKey”, “value”, “myOtherKey”, “myOtherValue”]. The [] is a class method.
  • I am really happy that we spent time creating a ‘load dump from environment X into my dev environment’ so we can easily test migrations and fix lots of bugs beforehand (instead of having to solve issues while deploying to an environment).
  • When using ZShell and you want to issue a rake task you cannot pass parameters with [] (ie rake myjob[someparam] won’t work). You need to use single quotes around the jobname + its parameters. Ie: rake ‘myjob[someparam]’ works.
  • You can download free, legal, VM’s to test IE versions on different versions of Windows (here)
  • You can create your own events with SDL using User events., as is done here
  • The Global Day Coderetreat 2013 will be held at the 14th of December and we (at Zilverline) host one!

Thx to Sander for his tips about MailBox and ZShell.

Working with legacy code – how to start & reveal intent

Recently I posted my opinion about regression. Regression bugs are likely to occur on projects with a lot of legacy code. I consider legacy code as untested code.

At the legacy coderetreat we used a small codebase (you can find it here). With that codebase we exercised in sessions to improve the code. The nice thing is that this is very similar with your daily job. You open up a project and you have to make changes in code you haven’t seen before and do not understand.

In order to get a better understanding you can use various techniques. I have practiced them with the legacy coderetreat and also applied this at work. In this blog post I’d like to share my experiences. Btw: If you haven’t experienced a coderetreat yet, join one. Just like kata’s, they are really worth your time (and more fun)!

Step 1: Get a sense of what is happening
Before we can do anything, we have to understand what we need to change and how it has impact on the system. One way to find out is to simply execute the code. You could just run the application, or… you could try to write a simple unit test executing the ‘main method’ you think that should be ran. Poke around with the parameters, and see what happens.

I prefer writing Characterization tests. The benefit is that while I am trying to understand what is happening, I am also building a safety net. Writing a Characterization test goes like this:
– create new test
– do some setup
– run specific piece of code (method) you want to try out
– check outcome / read state
– create assertion to make it pass with the outcome

When I don’t know what it actually does, I call my tests ‘monkey‘. Once I know the behavior with the given input, I rename the test to what the behavior is. Example:

[sourcecode language=”java”]
package com.adaptionsoft.games.uglytrivia;

import org.junit.Assert;
import org.junit.Test;

import static org.hamcrest.core.Is.*;
import static org.junit.Assert.*;

public class GameTest {

@Test
public void isPlayableReturnsFalseWhenInitialized() {
Game game = new Game();
assertThat(game.isPlayable(), is(false));
}

@Test
public void isPlayableReturnsTrueWithTwoPlayers() {
Game game = new Game();
game.add("Stefan");
game.add("Niels");
assertThat(game.isPlayable(), is(true));
}

@Test
public void monkey() {
Game game = new Game();
game.add("Stefan");
game.add("Niels");
game.roll(5);
// no idea yet what happens, need to look into roll method to get a clue
}

}
[/sourcecode]

So this gives me a rough idea what is happening, and it gives me a suite of tests.

It is important that you focus on black box tests. Try not to bother about the internals. If you are deep-stubbing in your test setup then try to think of a different way to approach the problem. Sometimes it is not possible to do black box testing, only then you need to do white box testing. In these cases deep-stubbing is often needed. Deep stubbing indicates a design problem: your class is bothered with internal states of other objects. You can reduce this by applying Tell Don’t Ask.

Step 2: Reveal intent.
This is even less invasive (actually it is not invasive at all if done well) than the small refactorings I have blogged about in the past.

To reveal intent:
– go through the code, find magic numbers and strings. Introduce constants for them with descriptive names
– find method names that do not describe well their behavior, and rename them. Try to keep the name about behavior, and if it does more then one thing, concate these behaviors with “And”.
– do the same for variables

This may sound trivial, but it really enhances the understandability of the code. As a bonus your understanding of the code is increased a lot, and all you did was renaming things and perhaps introduced a few constants. Let me show you how much it matters:

Can you find things to improve in this code?
[sourcecode language=”java”]
if (roll % 2 != 0) {
isGettingOutOfPenaltyBox = true;

System.out.println(players.get(currentPlayer) + " is getting out of the penalty box");
places[currentPlayer] = places[currentPlayer] + roll;
if (places[currentPlayer] > 11) places[currentPlayer] = places[currentPlayer] – 12;

System.out.println(players.get(currentPlayer)
+ "’s new location is "
+ places[currentPlayer]);
System.out.println("The category is " + currentCategory());
askQuestion();
} else {
[/sourcecode]

What about this?
[sourcecode language=”java”]
if (roll % 2 != 0) {
isGettingOutOfPenaltyBox = true;

System.out.println(players.get(currentPlayer) + " is getting out of the penalty box");
places[currentPlayer] = places[currentPlayer] + roll;
if (places[currentPlayer] > PLACE_BEFORE_STARTING_PLACE) places[currentPlayer] = places[currentPlayer] – MAX_PLACES;

System.out.println(players.get(currentPlayer)
+ "’s new location is "
+ places[currentPlayer]);
System.out.println("The category is " + getCurrentCategoryForCurrentPlayerOnPlace());
askQuestionAndRemoveFromQuestionFromDeck();
} else {
[/sourcecode]

This method name is called “roll” initially. If you would sum up all its behavior it would be more like:

[sourcecode language=”java”]
public void movePlayerAmountRolledAndAskQuestionOrWhenInPenaltyBoxIfUnevenRolledGetOutOfPenaltyBox(int roll) {
[/sourcecode]

Who would ever accept such a long method name? I would, but it should trigger something. This method name tells you there is way too much going on in one place. And, since the method is public, we communicate to other classes what this thing is doing.

It is ok to rename multiple times. The longer you work with the code, the better you understand it. When the method names do not reflect their real intent, make it clearer and improve their names. Communicating what the code actually *does* is important, make it explicit. especially if the method name violates conventions (ie, a getSomething() method that is not getting a property, but does more than that.)

It is very tempting to extract expressions and methods
Before you do this. Make sure you have the Characterization tests and integration tests in place. The tests will tell you if you have broken something while refactoring using extract method or extract conditions into variables. Yes, even such small refactoring’s could cause bugs.

Here an example, take this expression:
[sourcecode language=”java”]
if (rolled % 2 != 0) {
[/sourcecode]

Which you could turn into (extract into variable):

[sourcecode language=”java”]
boolean isUnevenRoll = roll % 2 != 0;
if (isUnevenRoll) {
[/sourcecode]

Or extract method:

[sourcecode language=”java”]
if (isUneven(roll)) {
[/sourcecode]

I prefer (automated!) extract method over extracting into variables. The main reason is that extracting into methods introduce very small pieces of code that you can re-use. You could eventually even find that the methods are not particularly bound to the current class’ behavior and move them out of this class into a new class. With variables this is much harder to see and refactor.

With these two steps, we could have brought the code we had earlier into a state like this:

[sourcecode language=”java”]
if (isUneven(roll)) {
isGettingOutOfPenaltyBox = true;

System.out.println(getCurrentPlayer() + " is getting out of the penalty box");
moveCurrentPlayer(roll);

System.out.println(getCurrentPlayer()
+ "’s new location is "
+ places[currentPlayer]);
System.out.println("The category is " + getCurrentCategoryForCurrentPlayerOnPlace());
askQuestionAndRemoveFromQuestionFromDeck();
} else {
[/sourcecode]

Conclusion
When working with legacy code, it is of importance to understand the code before making changes. In order to understand the code we can use introduce constants or rename methods to make the code reveal its intent. Using Characterization tests we can fixate the current behavior and label it in our tests names. Then, once we have this test suite, we can start using small refactoring’s like extract method or extract variable to make conditionals reveal their intent.

When creating a test suite, creating mostly black box tests will help us in the future when refactoring opposed to white box tests. Sometimes white box tests cannot be avoided.

Without any tests we can already have more insight in what is happening. With a test suite we can more safely start refactoring.

More about coderetreats
I have been greatly inspired by the legacy code retreat day, where we could experiment more in our spare time. Just like the previous time I have learned a lot, and I am convinced that others will benefit from this as well. Therefor I have decided to lend a hand and offer to organize and facilitate a coderetreat myself at the end of this year. Stay tuned!

The difference between TDD and Test First Development

Recently I promoted to do TDD, instead of “Tests First” development. Some people asked me what the difference is between them. In both cases we write tests first right?

So what is the difference?

I believe the difference is this:

Test First decribes your solution. TDD describes the problem

The difference could probably be explained best when using the coderetreat I had organized at the beginning of this year. Within this session I had experienced a great example to tell the difference between Tests first and TDD. To clarify the difference in this blog, we will be writing an implementation of Conway’s Game Of Life. It has the following rules:

  1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.
  2. Any live cell with two or three live neighbours lives on to the next generation.
  3. Any live cell with more than three live neighbours dies, as if by overcrowding.
  4. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

And it looks like this:

Image

Game Of Life in Action - Image from Wikipedia

Your assignment:

Write code that implements to the four rules above. It should be possible to apply these on an infinite grid

Test First describes your solution:
So the rules talk about “cells” and in your mind you’re already trying to solve this puzzle. In fact, I bet you’re already thinking about some array to put this matrix of cells into. Using a matrix we can easily determine neigbours and solve this puzzle…

We start with the first rule: “Any live cell with fewer than two live neighbours dies, …“.

We know it needs neighbours, so we need some boilerplate for that right?

The first test looks like this:

[sourcecode language=”java”]
public class CellTest {

@Test
public void mustReturnTrueWhenAlive() {
Cell cell = new Cell(1,0);
Assert.assertTrue(cell.isAlive());
}

}
[/sourcecode]

Since we’re doing TDD (atleast we think it is, we’re actually doing Tests First…), we need to create this Cell class to make it compile.

[sourcecode language=”java”]
public class Cell {

private long x, y;

public Cell(int x, int y) {
this.x = x;
this.y = y;
}

public boolean isAlive() {
return true;
}
}
[/sourcecode]

Before we can do anything with counting the number of neighbours, we need to determine what a neighbour is. Since adjecent cells are counted as neighbours, we start writing tests for this:

[sourcecode language=”java”]
@Test
public void mustReturnTrueWhenNextToAnotherCell() {
Cell cell = new Cell(1,0);
Cell adjecent = new Cell(1,1);
Assert.assertTrue(cell.isAdjecent(adjecent));
}

@Test
public void mustReturnFalseWhenNotNextToAnotherCell() {
Cell cell = new Cell(1,0);
Cell adjecent = new Cell(3,3);
Assert.assertFalse(cell.isAdjecent(adjecent));
}
[/sourcecode]

And along with it the code:
[sourcecode language=”java”]
public class Cell {

private long x, y;

public Cell(int x, int y) {
this.x = x;
this.y = y;
}

public boolean isAlive() {
return true;
}

public boolean isAdjecent(Cell adjecent) {
long diffX = Math.abs(adjecent.getX() – x);
long diffY = Math.abs(adjecent.getY() – y);
return diffX == 1 || diffY == 1;
}

public long getX() {
return x;
}

public long getY() {
return y;
}
}
[/sourcecode]

Wait, stop, halt!

If the above sounds familiar, then I’ve got news: This is not TDD

Lets get back to the original question, what did we try to implement? Ah, it was the question:

“Any live cell with fewer than two live neighbours dies, as if caused by under-population”,

So where is the corresponding test for that?…

In fact, we have already three tests and a bunch of code, and we still are not able to answer the question.

What we’ve done so far is write tests first in order to prove a solution we already had in our minds. We did not let the tests guide us to a design. In fact, we already had a design in our heads and made the tests conform to those.

Lets do it in TDD, for real…

So how is it done ? – Test Driven Development

With a clean slate, we start over. And we start with the first rule:

“Any live cell with fewer than two live neighbours dies, as if caused by under-population”

So we create a test (we call it Test, because we do not think about Cells yet, in fact, we are only thinking about this very question).

[sourcecode language=”java”]
@org.junit.Test
public void anyLiveCellWithFewerThanTwoLiveNeighboursDies() {
int neighbours = 1;
Assert.assertTrue(neighbours < 2);
}

[/sourcecode]

So what does this do, it basically returns true when neighbours is lower than two. We do not call methods yet, we simply have our implementation within the test itself. In this phase, we already had Red (non compiling), Green (compiling and green test). On to refactor. How to get it more descriptive? We could do something like this:

[sourcecode language=”java”]
@org.junit.Test
public void anyLiveCellWithFewerThanTwoLiveNeighboursDies() {
int neighbours = 1;
boolean shouldDie = neighbours < 2;
Assert.assertTrue(shouldDie);
}
[/sourcecode]

Do we need to do anything else? Certainly! But the essential rule is there already. It is one simple statement, no neighbour checking yet. And in fact, we will not need it to implement the four rules! Lets continue. I am serious, we will not modify the above code yet. We have yet to implement the other rules. Lets pick the second:

“Any live cell with two or three live neighbours lives on to the next generation.”

We have actually two cases here, for two and three live neighbours. Lets start with two:

[sourcecode lang=”java”]

@org.junit.Test
public void anyLiveCellWithTwoNeighboursLivesOn() {
int neighbours = 2;
boolean shouldLiveOn = neighbours == 2;
Assert.assertTrue(shouldLiveOn);
}

[/sourcecode]

Not that much different is it? How about we add the third test for the second rule:

[sourcecode lang=”java”]

@org.junit.Test
public void anyLiveCellWithThreeNeighboursLivesOn() {
int neighbours = 3;
boolean shouldLiveOn = neighbours == 3;
Assert.assertTrue(shouldLiveOn);
}

[/sourcecode]

The total test class looks like this now:

[sourcecode language=”java”]
public class Test {

@org.junit.Test
public void anyLiveCellWithOneThanTwoLiveNeighboursDies() {
int neighbours = 1;
boolean shouldDie = neighbours < 2;
Assert.assertTrue(shouldDie);
}

@org.junit.Test
public void anyLiveCellWithTwoNeighboursLivesOn() {
int neighbours = 2;
boolean shouldLiveOn = neighbours == 2;
Assert.assertTrue(shouldLiveOn);
}

@org.junit.Test
public void anyLiveCellWithThreeNeighboursLivesOn() {
int neighbours = 3;
boolean shouldLiveOn = neighbours == 3;
Assert.assertTrue(shouldLiveOn);
}
}
[/sourcecode]

We have done some little TDD cycles already. We started describing the problem domain, and we added the minimum amount of code to make this work. We did not yet start write any production code yet. Now one of the most important steps in TDD should be taken: Refactor. (Remember it is Red – Green – Refactor!)

With the third test, we clearly see duplication. The shouldLiveOn can be extracted to a method. Lets do that:

[sourcecode language=”java”]
import org.junit.Assert;

public class Test {

@org.junit.Test
public void anyLiveCellWithOneThanTwoLiveNeighboursDies() {
int neighbours = 1;
boolean shouldDie = neighbours < 2;
Assert.assertTrue(shouldDie);
}

@org.junit.Test
public void anyLiveCellWithTwoNeighboursLivesOn() {
int neighbours = 2;
Assert.assertTrue(shouldLiveOn(neighbours));
}

@org.junit.Test
public void anyLiveCellWithThreeNeighboursLivesOn() {
int neighbours = 3;
Assert.assertTrue(shouldLiveOn(neighbours));
}

private boolean shouldLiveOn(int neighbours) {
return neighbours == 3 || neighbours == 2;
}
}

[/sourcecode]

We could refactor out the neighbours var to a constant, which should give us even smaller tests.

At this point we have now our first method which could eventually be moved out of the test class into some other class (we have yet to think of a name for). As you can see, the design of our code is being driven by the tests. So this may like trivial and like ‘cheating’. In fact, as I see it we are actually answering the real questions. We tend to write code for stuff we cannot possibly be sure of that it is correct. Did you see any line say that the Game of Life in this situation should be on a 2D grid? What if it would be 3D? What if we did not know yet if it would be 2D or 3D?

This sounds a lot like real-life isn’t it? Where your customer does not always know exactly what he wants.

Another good thing is, we can implement all rules like this. Eventually we end up with a test class that contains several methods. From there on we can think of a logical way to group them. Methods grouped together will form classes. We tend to group methods logically. When we define the problem domain we know better what classes should exist. Again, our tests drive the design. Instead of the other way around.

Here is an impression how the four rules implemented might look like:

[sourcecode language=”java”]
package com.fundynamic.coderetreat;

import org.junit.*;

public class Test {

public static final int StarvationThreshold = 1;
public static final int OverpopulationThreshold = 4;
public static final int MinimumRevivalThreshold = 3;
public static final int MaximumRevivalThreshold = 3;

@org.junit.Test
public void liveCellShouldDieIfLessNeighboursThanStarvationThreshold() {
int amountNeighbours = StarvationThreshold;
Assert.assertEquals(false, livesOnToNextGeneration(amountNeighbours));
}

@org.junit.Test
public void liveCellShouldDieIfNeighboursEqualToStarvationThreshold() {
int amountNeighbours = StarvationThreshold;
Assert.assertEquals(false, livesOnToNextGeneration(amountNeighbours));
}

@org.junit.Test
public void liveCellShouldLiveIfTwoNeighbours() {
int amountNeighbours = StarvationThreshold +1;
Assert.assertEquals(true, livesOnToNextGeneration(amountNeighbours));
}

@org.junit.Test
public void liveCellShouldLiveIfThreeNeighbours() {
int amountNeighbours = 3;
Assert.assertEquals(true, livesOnToNextGeneration(amountNeighbours));
}

@org.junit.Test
public void liveCellShouldDieIfFourNeighbours() {
int amountNeighbours = 4;
Assert.assertEquals(false, livesOnToNextGeneration(amountNeighbours));
}

@org.junit.Test
public void liveCellShouldDieIfEightNeighbours() {
int amountNeighbours = 8;
Assert.assertEquals(false, livesOnToNextGeneration(amountNeighbours));
}

@org.junit.Test
public void deadCellShouldReviveIfMinimumRevivalThreshold() {
int amountNeighbours = MinimumRevivalThreshold;
Assert.assertEquals(true, revivesInNextGeneration(amountNeighbours));
}

@org.junit.Test
public void deadCellShouldReviveIfMaximumRevivalThreshold() {
int amountNeighbours = MaximumRevivalThreshold;
Assert.assertEquals(true, revivesInNextGeneration(amountNeighbours));
}

@org.junit.Test
public void deadCellShouldNotReviveIfLessNeighboursThanMinimumRevivalThreshold() {
int amountNeighbours = MinimumRevivalThreshold -1;
Assert.assertEquals(false, revivesInNextGeneration(amountNeighbours));
}

@org.junit.Test
public void deadCellShouldNotReviveIfMoreNeighboursThanMaximumRevivalThreshold() {
int amountNeighbours = MaximumRevivalThreshold +1;
Assert.assertEquals(false, revivesInNextGeneration(amountNeighbours));
}

private boolean livesOnToNextGeneration(int amountNeighbours) {
return amountNeighbours > StarvationThreshold && amountNeighbours < OverpopulationThreshold;
}

private boolean revivesInNextGeneration(int amountNeighbours) {
return amountNeighbours == MinimumRevivalThreshold;
}
}

[/sourcecode]

But you did not even get to any cell? How is this any good?

It is true that cells play a role in the Game of Life eventually. But they do not play a role in answering the four questions. In fact, what are cells? We might be talking about squared cells, but perhaps you want to write your 3d version of it. Or you might want to use hexagons. If you put the rules logic into a cell, it gets very hard to modify your code because you have put too much responsibility in one class.

TDD prevents you from doing this.

Also, if you started with using Cells and the matrix and all that. I would wonder how you would implement the last rule (reviving cells). How would you solve this problem?

Bottom line

Writing tests before your production code is not the same as TDD. It is about how your tests drive your design. Only then you can say if you are doing TDD or actually are just writing tests proving your own solution you have thought about before-hand.

It is hard to not think ahead of your design, and instead trust on our tests to let the design emerge itself. This requires practice. Practicing this can be done in coderetreats for instance.

First coderetreat of 2012 in Amsterdam – Retrospective

At the end of 2011 I started organizing a coderetreat. It started on twitter around October. I’ve also posted about it in my last mini blog. The original event can be found here.

If anyone was interested, they could sign up (max 25 people) for free. All you needed to do was bring your best humor and if possible a laptop with your preferred dev environment set up. (Its not hard to organize one, check here if you’re interested)

If you want to know more about what a coderetreat is, click here. Even better: join a coderetreat somewhere near you and experience it. It is way better than just reading about it 🙂

Honing the craft together

Coderetreat

Lets start with a management summary:

It was awesome!

It reminded me of my experience with the bowling game kata last year. Since you’re repeating the exercise over and over again, you will find different approaches. Even better, because you’re switching pairs, you will have a different mindset literally to approach the problem presented by the coderetreat. Instead of writing a bowling game, you will be working on Conway’s Game Of Life.

The most notable things of that day where:

  • In the very first session we where let ‘free’. We could approach this problem how we wanted. Me and my pair where able to implement the first three rules. However we where not able to implement the fourth rule. Our design was not easy enough to revive dead cells. (gosh, this reminds me of the bowling game code kata first attempt…)
  • The second session we got to choose from different constraints. I picked the “no conditionals” one, because I can get my methods under 4 lines without pain. Programming without no conditions is a whole different story though.
  • The third session with ‘only check in within 2 minutes, else revert everything’ was an eye opener! It really forced you into thinking how to make all (baby) steps. Hence, I am using this at work now and it really works. I commit 10 times more often. Although I don’t make the 2 minute mark yet at work (5 minutes is easy though now).
  • The fourth session was fun, as we where able to implement *all rules* (opposed to the first session), but without the code we had implemented in the first session! We totally isolated the behaviour (this session was called “tdd as if you meant it”) and it blew our minds.

Will I attend more coderetreats? You bet! Just need to take a look at the list of events and pick an appropiate one. If I attend one, I will let you know (on twitter surely, perhaps on this blog).

If you want to know how it looked like, click here to see som pictures of the coderetreat.

I loved the coderetreat, and I’ll surely organize one again in the future. I would recommend anyone who loves his profession to join a coderetreat and practice. You’ll learn new things for sure!

How hard can it be, right? 😉