Kata - Game Of Life

Quinn Gil -

NOTE: This was written about a year before posting; months before I stumbled on the MicroObject style.

This kata is Conway's Game of Life. It's a simple set of requirements.

The universe of the Game of Life is an infinite two-dimensional orthogonal grid of square cells, each of which is in one of two possible states, live or dead. Every cell interacts with its eight neighbours, which are the cells that are directly horizontally, vertically, or diagonally adjacent. At each step in time, the following transitions occur:

  1. Any live cell with fewer than two live neighbours dies (referred to as underpopulation or exposure).
  1. Any live cell with more than three live neighbours dies (referred to as overpopulation or overcrowding).
  2. Any live cell with two or three live neighbours lives, unchanged, to the next generation.
  3. Any dead cell with exactly three live neighbours will come to life.

Apply the above rules simultaneously to every cell in the seed — births and deaths happen simultaneously, and the discrete moment at which this happens is sometimes called a tick. (In other words, each generation is a pure function of the one before.) The rules continue to be applied repeatedly to create further generations.

This is the kata recommended for a Code Retreat. I've held off doing it for a few months now. I've thought it'd be a complex beast to implement given the diversity it produces. Which helped holding off on it.

Earlier this week we did a Code Retreat; which I didn't get to attend ALL of... But I did 3 sessions.
I'm getting my own thing from the code retreat; but I'll be getting a lot from the Game of Life Kata.
I'm working with the collegue that ran the code retreat; and has done them a large number of times to push myself via the intentional practices on this kata.
It allows simplicity in the code; but I don't want simplicity. I want to work on becoming a better XP Gardner (deal with it). I want to have pointed out and mercilessly mocked (it's the other side of ruthless refactoring for a close team) where I can improve. Where I've taken a refactor too far. Should I have these 10 tiny methods; or since they're only called once, should they be inlined? It's a discussion and a judgement call; and I can't make those in isolation.

I am doing the kata solo; while like most things; it'll be better paired. But it gives me the opportunity to do hyper-intentional practice. My big task to work on is breaking things down into the smallest... AND simplest. As I'm getting better at Object Oriented Design (OOD), TDD, and Simple Design, I start to jump to ... abused versions of those. Overcomplicating things to make everything OOD.

This is good, though. I can't get better if I'm not doing it wrong. This is where the discussion and conversation about what I do (and I'll be doing SO MANY) in a kata is strong and weak. Or; in a few cases, confusing.

I think my next itteration of the kata will be forcing myself to slow down. Space out a test and the implementation. It'll be slow and painful; but ... I think sometimes I need to slow down. Working is the lowest bar; and sometimes in the first 2 itterations, it's what I accepted.

I don't have a lot on the kata itself at the moment.
I need to extend it a bit to include criteria for the world; and ticking, ect. Right now; it requires extending the 4 rules to get every cell to evolve.
I don't think this is required for the Code Retreat; but for continuing; it'll be nice to have a specified rule I can abide by.

This has been an excellent kata, but I'm still trying to solve the problem. I haven't gotten to the problem being a lie. Once I'm there, this will be a very different experience.

It's not much - I've pushed the code here.

As my laptop is now at 1% - I'll end for now.