By the end of this, students should be able to:

• Pair with other developers under a variety of constraints.
• Explain the value of team communication in their own words.
• Solve a problem in multiple ways by "spiking".
• Choose an implementation strategy for a problem using lessons learned from spikes.

This code retreat will consist of several pairing rounds. Try to pair with someone new each time. For each round, you and your pair will work on implementing Conway's Game of Life in ruby (see below). After each round we will hold a quick retrospective to share our experiences with each other.

After a brief introduction, we will whiteboard the rules. Then, we'll complete the following activities. Each activity will be followed by a retro and a break.

These times are subject to, and most likely will change.

1. Caveman Coder (45 minutes)
2. Navigator-Driver (30 mintues)
3. Silent Coder (15 mintues)
4. Flat Files (30 mintues)
5. Sandi's Rules (30 minutes)
6. Git Happens (30 minutes)
7. Hot Potato (30 minutes)
8. Free-for-all (60 minutes)
9. Retro of the Day (15 minutes)

Before we get started, let's review the purpose of a code retreat and understand the problem we'll be solving.

A code retreat is a day-long intensive practice, focusing on fundamentals. Pairs of programmers tackle the same problem multiple times under different constraints. The constraints are chosen to emphasize the value of modern development practices like test-driven development, pair programming, patterns, and iterative development.

Corey Haines expalins the goals of a code retreat in Cleveland Code Retreat Introduction on Vimeo.

The Game of Life, also known simply as Life, is a cellular automaton devised by the British mathematician John Horton Conway in 1970.

Visualization of the Game of Life:

The "game" is a zero-player game, meaning that its evolution is determined by its initial state, requiring no further input. One interacts with the Game of Life by creating an initial configuration and observing how it evolves.

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 neighbors, 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, 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.

The initial pattern constitutes the seed of the system. The first generation is created by applying 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.

You are not expected to finish the exercise in any particular round.

Even though your solution should work with an infinite grid, it can be beneficial to start with a large, finite grid. Your solution should work for a grid of at least 80x80 cells.

You may want to solve the problem for an infinite grid, but initialize the game with a finite grid so it can be displayed on screen.

Your solution should work with any arbitrary starting arrangement of dead and alive cells. Try initializing each tile randomly with either an alive or a dead cell.

The hardest part might be getting started. Decide what class you want to use to represent cells or tiles. Then, start adding small features to your class one at a time.

For pairing exercises, try using one computer, and pass it between yourself and your pair. Work together and in sequence. You and pair should not be working in separate files at the same time.

If you're looking for extra challenge or practice once you've completed the above, try pairing with someone using the following constraints:

• Small methods. No methods longer than four lines.
• No mutation of state allowed. Once a variable is assigned, it cannot change.
• No conditionals. Do not use if/else and friends.
• No loops.

If you have a working solution you like, post it to GitHub. It's great for employers to see you tackling such a classic problem. Work with a classmate to refactor your code using SOLID and The Rules of Simple Design.

• Screencast: Coding Conway’s Game of Life in Ruby the TDD Way with RSpec
• A few git tips you didn't know about
• Fork A Repo - User Documentation
• Syncing a fork - User Documentation

Source code distributed under the MIT license. Text and other assets copyright General Assembly, Inc., all rights reserved.