Cellular automaton #3 – Get to coding

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.

More setup

Debugging

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

gem_pry

Testing

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

There is good RSpec documentation and guidelines on the web.

Environment groups

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 spec/spec_helper.rb:

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 config.ru:

Bundler.require(:default, ENV['RACK_ENV'].to_sym)

Implementation

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:

Results:

rule_30

Rule 90:

rule_90

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:

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.

rspec_format

Advertisements

One comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s