Pages

Showing posts with label CodeRetreat. Show all posts
Showing posts with label CodeRetreat. Show all posts

Saturday, March 31, 2012

Coding in the Clink - Another Success!

Today I again had the privilege of attending a Coding in the Clink , this time number 6. This was my third visit to Marion Correctional Institute. (Read about my first visit and my second visit.) The last time I went was June 2011. Since then, the Java Guys have definitely continued to improve, in TDD, pairing, and Java. And as before, the guys were curious, hard working, and fun to be around.

As always, Dan Wiebe did a great facilitation job, and this time added new twists. He had us break from CodeRetreat tradition in a couple of significant ways (besides the fact that prison lunch never qualifies as "something good, catered"): 
  • No GoL, instead Mancala  (We were all surprised at what a challenging problem Mancala is, given the fairly simple rules. I think it's more interesting than GoL.)
  • Instead of deleting our code after each round, we left it there for the next pair. And he asked us to not pair with the same person twice, and not work on the same code twice

In round 2, when I sat down at someone else's code for the first time, it took most of that round just for me and my pair to make sense out of what was there. (Most pairs experienced this too.) I found that each subsequent code base I visited was easier to understand (and most other devs found this too). It was cool to sit down to each subsequent code base and find something better than I had previously sat down to.

For our final round, everyone agreed to go back to the workstation where we started. I'm not sure there was any consensus around that experience. For me, I was sad to find there weren't many more tests 5 hours later than when my pair and I first left it. (Which seems odd, given the experience of improving codebases we had up until the last round. Maybe I was having some bias when looking at "what they did to my code"?)

I'll close with the logo for today's event, as created by one of the inmates, Mark Roberts:

Tuesday, January 25, 2011

I'm hot on Rails, git, and CodeRetreat

Now that I'm back from CodeMash, where I attended an overview session called "Rails 3 from A to Z", I'm excited about taking a deeper dive into Rails. My first exposure to Ruby was the excellent Ruby Koans PreCompiler session at CodeMash 2010. I didn't complete all the koans at that session, and I didn't follow up and finish them afterward (although I was bitten again by the koan bug when I helped Dianne work on her Scala Koans PreCompiler session during Six Weeks of Scala), but now that I've completed Rails for Zombies, I'm totally going to go back and finish the ruby koans. Maybe before that, I'll finish another Ruby tutorial I started, TryRuby.org. It leads you through lessons and has you enter your answers at a command prompt. After that, I will probably go on to RailsTutorial.org (as recommended at the end of Rails for Zombies.) They have a free tutorial book online and they sell a pdf version and tutorial screencasts.

And after that, I've found a series of interesting articles on programming Rails on Apple's website:
And somewhere among all that, I'll want to learn the Twitter API, as I have an idea for a site related to Twitter.


Another CodeMash 2011 session that I've taken to heart is the awesome Git Immersion. While my department at work uses Subversion, I've started keeping my experiments in a git repository. And since so Ruby (and other projects) use git and/or github, it will be good to be familiar with git.

And finally, I'll be attending the 2nd Anniversary CodeRetreat in Ann Arbor this Saturday, Jan 29. This will be number 5 for me. Come join us!


Monday, March 29, 2010

My Venture into JBehave via Conway's Game of Life

Having used Conway's Game of Life (CGoL) at several CodeRetreats* to practice Test Driven Design (TDD), I thought I would revisit it when I took my first steps into Behavior Driven Development (BDD) with JBehave.

I downloaded JBehave 2.5 and refreshed my memory of the GoL rules:
  1. Any live cell with fewer than two live neighbours dies, as if caused by underpopulation.
  2. Any live cell with more than three live neighbours dies, as if by overcrowding.
  3. Any live cell with two or three live neighbours lives on to the next generation.
  4. Any dead cell with exactly three live neighbours becomes a live cell.
What I love about using GoL for learning BDD is that the rules are practically already written as Given-When-Then scenarios. Just minor tweaks (including changing to the US spelling of neighbor) gave me:
  1. Given a live cell with fewer than two live neighbors, Then the cell is dead.
  2. Given a live cell with more than three live neighbors, Then the cell is dead.
  3. Given a live cell with two or three live neighbors, Then the cell is dead.
  4. Given a dead cell with exactly three live neighbors, Then the cell is alive.
All that's missing is a "When". All 4 rules have the same "When", which is "When I calculate the next generation". Taking that into account, I get:
  1. Given a live cell with fewer than two live neighbors, When I calculate the next generation, Then the cell is dead.
  2. Given a live cell with more than three live neighbors, When I calculate the next generation, Then the cell is dead.
  3. Given a live cell with two or three live neighbors, When I calculate the next generation, Then the cell is dead.
  4. Given a dead cell with exactly three live neighbors, When I calculate the next generation, Then the cell is alive.
Since any given rule could only have 9 different cases (0-8 alive neighbors) I decided that, rather than deal with the logic of "less than"/"fewer than"/"exactly", I would spell out every specific condition that meets a rule.

JBehave expects scenarios to have separate lines for Given, When, and Then. Rule #1 can be completely expressed as:

Scenario:
Given Rule 1: alive cell with 0 neighbors
When I calculate the next generation
Then the cell should be dead

Scenario
Given Rule 1: alive cell with 0 neighbors
When I calculate the next generation
Then the cell should be dead

I've written the variables in the scenario in bold here. That will become more clear later. I inserted "Rule 1" into the given just to make it easier to know what rule I'm on when a scenario fails.

I wrote scenarios for every condition for all 4 rules (it came out to 18) and put them in a file named "i_can_calculate_the_next_generation". JBehave requires scenarios be named all lower case with words separated by underscores. You can see all the scenarios and all the source code in my github repo for this project.

(If you're a Windows developer and you don't like the idea of files without extensions, I found a blog post that showed a customization that allowed JBehave to read ".scenario" files instead of files with no extension, but I decided not to bother with that for this first experiment.)

Once I have my scenarios written, it's time to code. JBehave requires that the class corresponding to the scenarios be the same words, but camel-case, and without underscores, so I created ICanCalculateTheNextGeneration.java

The entire class is:
import org.jbehave.scenario.Scenario;

public class ICanCalculateTheNextGeneration extends Scenario {
public ICanCalculateTheNextGeneration(){
super(new RuleEngineSteps());
}
}
Now for the meat of the code, starting with the implementation of RuleEngineSteps:

@Given("Rule $ruleNum: $aliveVal cell with $aliveCount neighbors")
public void aliveOrDeadCellWithPossiblySomeAliveNeighbors(int ruleNum, String initialLiveState, int numberOfAliveNeighbors){
ruleEngine = new ConwayRuleEngine();
cell = new Cell(initialLiveState.equals("alive"), numberOfAliveNeighbors);
}

@When ("I calculate the next generation")
public void iCalculateTheNextGeneration() {
ruleEngine.CalculateTheNextGeneration(cell);
}

@Then ("the cell should be $resultingAliveState")
public void theCellShouldBe(String expectedAliveState){
String actualAliveState = "alive";
if (!cell.isAlive()){
actualAliveState = "dead";
}
Assert.assertEquals(expectedAliveState, actualAliveState);
}


Look for a moment at how variables are used between the scenarios and the code. Remember I had: "Then the cell should be dead"? Look at the corresponding @Then in the code:
@Then ("the cell should be $resultingAliveState")
public void theCellShouldBe(String expectedAliveState){
Whatever I want as variable in the scenario, for example dead above, I name a variable starting with "$" in the attribute line and use the same name (without "$") as the parameter to the method.

Cell.java is basically only setters and getters. ConwayRuleEngine.java is where the business logic lives (Excuse the pun). Initially, CalculateTheNextGeneration() will do nothing.

When I run ICanCalculateTheNextGeneration.java as a JUnit test in Eclipse. I get a red bar. In the console I see:
(i_can_calculate_the_next_generation)
Scenario:
Given Rule 1: alive cell with 0 neighbors
When I calculate the next generation
Then the cell should be dead (FAILED)
and other failures. All that's left is the implementation of the business logic, which I'll leave as an exercise for you. (Or you can look at my code).

Once I got my code working, I refactored it. I've tried to reduce duplication and make the code very clean. I'd appreciate any comments you have.

Finally, I invite you to check out the Agile Skills Project, a non-commercial, community-based project which aims to establish a common baseline of the skills an Agile developer needs to have, skills possibly including TDD and BDD.

---------------------------
*A plug for CodeRetreat if you're not familiar with it: Patrick Welsh and Corey Haines have created a kind of one-day coding dojo that gives software developers who want to improve their craft a chance to practice agile skills like Pair Programming and TDD. We do 40 minute iterations on Conway's Game of Life, have mini-retrospectives, throw out our code before the next iteration, and have a retrospective of the whole event at the end of the day. CodeRetreats have been held in Java and Ruby (that I know of) and in several countries. If you haven't been to one, I encourage you to go to one.



Monday, January 11, 2010

Grand Rapids CodeRetreat ... but it's in Ruby

I'm a big fan of CodeRetreat. Besides being a fun day, it's a great way to practice agile things like: pair programming, supportive environment, software craftsmanship, TDD, retrospectives, courage, and so on. I think they are great events for both aspiring Agilists and experienced Agilists.

I read Jeremy Anderson's blog post about an upcoming CodeRetreat in Grand Rapids. I was all set to go when I read that it will be held in Ruby, and since I haven't used Ruby, I was discouraged. As much as I'd like to try it, I'm not sure how much time I'll have in my schedule before then.

Then I found TryRuby. It offers an interactive Ruby prompt and a follow-along tutorial, right in your browser! And there's another tutorial I found, Ruby in Twenty Minutes .

So I guess I'll have to revisit the sessions I planned to attend this week at CodeMash 2010 and see if there are beginner Ruby sessions. Perhaps, between them and some extra work during downtime, I'll pick up enough Ruby to feel comfortable attending the Grand Rapids Code Mash next month.

Sunday, November 15, 2009

CodeRetreat 12-5-09 LeanDog

I'm looking forward to attending CodeRetreat 12-5-09.
It's a free event, sponsored by and held at LeanDog. If you aren't familiar with the idea of a Code Retreat, as promoted by my friend Patrick Wilson Welsh, take a look at his description here.

Briefly, it's an event where agile software developers get together and pair program several solutions to a practice program, with the goal of honing our craft and furthering learning and discussion (Think software kata.) The event hits 5 of the 7 agile skill pillars proposed by the Agile Developer Skills Project:
* Collaboration
* Supportive Culture
* Confidence
* Technical Excellence
* Self-Improvement

I attended the previous LeanDog CodeRetreat and it was great! Lots of talented developers, great practice and learning, tech talks and a party-like atmosphere.

LeanDog's location is amazing. Their website describes says:
Our office is floating in downtown Cleveland right next to the U.S.S. Cod (a WWII Submarine), the Burke Lakefront Airport, and the Rock and Roll Hall of Fame. We are located on a converted steamship, the Keasarge, that was formerly known as Hornblower’s Barge and Grill. The restaurant setting remains and offers open spaces that are perfect for practicing Agile. Our location gives a great view of the skyline of the city we support.

We'll be coding in Java again, but if you want to learn or practice pairing and you don't know Java, don't let that stop you. That was my situation last time and it was still a great experience!