No description, website, or topics provided.
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
bin
lib
spec
.editorconfig
.gitignore
.remarkrc
.rspec
.rubocop.yml
.ruby-version
CONTRIBUTING.md
Gemfile
Gemfile.lock
LICENSE
README.md
Rakefile
STYLE.md
notes.md

README.md

General Assembly Logo

Ruby Lab Day: Code Retreat

Objectives

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.

Instructions

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 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. Many-to-one (30 minutes)
  9. Free-for-all (60 minutes)
  10. 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.

Code Retreat

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 explains the goals of a code retreat in Cleveland Code Retreat Introduction on Vimeo.

Conway's Game of Life

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:

Alt Conway's 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.

Rules

At each step in time, the following transitions occur:

  1. Any live cell with fewer than two live neighbors dies, as if caused by underpopulation.
  2. Any live cell with more than three live neighbors dies, as if by overcrowding.
  3. Any live cell with two or three live neighbors lives on to the next generation.
  4. Any dead cell with exactly three live neighbors 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.

Here is a visual representation of what is happening:

population-dynamics-in-conways-game-of-life-and-its-variants-9-728

Tips & Tricks

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 onscreen.

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.

Bonus

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.

Additional Resources

License

  1. All content is licensed under a CC­BY­NC­SA 4.0 license.
  2. All software code is licensed under GNU GPLv3. For commercial use or alternative licensing, please contact legal@ga.co.