Last week I finally implemented something, an elementary cellular automaton with one hardcoded rule. I also added some development tools (debugger, testing framework). Not much, but I’m happy that I could see some results and now I have some base for next iterations.
Pry – debugger and powerful tool, is a popular choice for development in Ruby.
To use it, we just need to add in Gemfile this:
gem 'pry', and then this line in code where we want a break point:
require 'pry'; binding.pry
RSpec – when it comes to testing (especially in Rails apps), this is the most used framework and DSL. After adding
gem 'rspec' in Gemfile, we can generate initial config for it:
$ rspec --init create .rspec create spec/spec_helper.rb
In Sinatra default environment is “development” and since there is no config for that – all dependencies are required in every environment. In order to fix this and also
to introduce “test” environment I needed to make some configuration tweaks.
For testing, I’ve added this line on top of
ENV['RACK_ENV'] = 'test'
For dependencies, we can group them in Gemfile as described in Bundler docs.
To require gems in particular group I’ve added this line on top of
Elementary (one-dimensional) cellular automaton is really easy to code in Ruby. My first implementation has 40 lines of code. It’s a class with few instance methods. Object created from it can hold a generation in an array. Elements of an array are cells, their state is defined by integer (0 or 1). Method named “step” (no idea if it’s good name) returns new array generated basing on neighborhood of cells and some rule, in this case rule 30.
Here is the link to this class in my repository: one_dimensional.rb. I was coding using TDD but couldn’t wait to see it in action so I made a little script that uses it and prints output to the console:
Cool, isn’t it? Next time I’m going to implement dynamic rules and some integration with Sinatra app. The concept of elementary C.A. is rather easy, here are some resources that I used to understand the algorithm:
- Video: https://www.youtube.com/watch?v=W1zKu3fDQR8
- Book: http://natureofcode.com/book/chapter-7-cellular-automata/
P.S. My tests are also documentation at the same time, they describe the class and it’s methods. When I run RSpec with
format d option, I get more verbose output. I need to write tests that way, offcourse. This practice isn’t always required and sometimes is impossible but this way I don’t need to write comments in the code or any extra documentation. Well written code and tests should be enough for me or others to understand the code when looking at it later.