Rails Chronicles – Part 2

Before you read any further: This is the second in a series of posts intended to capture how I went about learning how to create Web apps using Rails. I thought it might be interesting to look back in a few months and see all the things I got wrong and didn’t understand about Ruby and Rails when I started out. So, if you’re looking for enlightenment about Rails, you’re in the wrong place. I’d recommend you head over to Michael Hartl’s Ruby on Rails Tutorial: that’s the site that really got me started.

Test first

Chapter 3 of Michael Hartl’s Rails Tutorial introduces you to testing within Rails development. I’ve known about test-driven development (TDD) for a long time, but I’ve never actually done it. So I was looking forward to finding out how you write tests for something you’ve not built yet.

To be honest, not only have I never written tests before writing the code, I’ve never written tests full stop. In all my years of writing software programs (I wrote my first program, in BASIC, in 1989, then worked my way through C, Visual Basic for Applications, JavaScript, Perl and PHP) I’ve never actually written a test in software to test software I’ve written. So, this feels like a step up from my hacky habits towards a modicum of semi-professional rigour.

RSpec

RSpec (the R is for Ruby, Spec for Specification) is a Ruby package that lets you use a simple grammar to create specifications for software you intend to build. You can then test the software against the specification. The process goes something like this:

The above is from Behavior-driven testing with RSpec by Bruce Tate, which is a good tutorial on RSpec if you want to stray from Michael Hartl’s tutorial for a while.

Fixing the ANSICON warning

When I ran the RSpec tests for the first time (section 3.2.2 of the Rails Tutorial):

$ bundle exec rspec spec/

it worked but the output text included the message:

 *** WARNING: You must use ANSICON 1.31 or higher (http://adoxa.110mb.com/ansicon) to get coloured
 output on Windows

This sounds serious but it only means your console (in my case MINGW32 running bash – which came when I installed git from GitHub) isn’t displaying the colours it could be displaying.

If you want to fix this:

1. Go to http://adoxa.110mb.com/ansicon/ and download ANSICON 1.40.
2. Unzip the downloaded zip file.
3. Open a command console as Administrator (i.e. type cmd into the start menu, right-click cmd.exe and choose Run as Administrator).
4. cd to the location of the unzipped files
5. You’ll find subdirectories called x86 and x64. On a 32-bit machine go into the x86 directory. On a 64-bit machine go into the x64 directory.

6. If you want to see command syntax enter:

   ansicon.exe -h

7. To install ANSICON, enter:

   ansicon.exe -i

Autotest and Growl

The tutorial describes using Autotest and Growl to run tests and notify you when your test completes by displaying a summary of the test results. The good thing about using Growl is that, you can kick off a suite of tests and then go away and do other things in Windows while the tests run. When they finish, a message is displayed on top of all other windows.

I’m still pretty hazy about exactly what Autotest does and doesn’t do. As its name suggests it obviously runs tests automatically, but I’ve yet to figure out why tests get triggered when you save changes to some files but not others. However, it’s very handy for something to be sitting waiting for you to change certain files and, when you do, checking the file to make sure you haven’t contravened any of the definitions in your specification. You do this by opening a dedicated console window, entering:

$ autotest

and then just leaving the window open in the background so that the autotest process keeps running and will run your tests as you work on your Rails project.

I set up Growl by following Michael Hartl’s instructions (plus the instructions he cross-refers to for Windows users):

$ gem install autotest -v 4.4.6 $ gem install autotest-rails-pure -v 4.1.2 $ gem install autotest-standalone $ gem install autotest-growl

Download and install Growl for Windows from:

http://www.growlforwindows.com/gfw/ 

Create a .autotest file as follows:

$ gvim ~/.autotest

Containing the single line of text:

require 'autotest/growl'

Of course if you want to use Growl to notify you the results of tests you’ve got to start it first. In Windows 7 just enter growl in the Start menu search box and then press Enter when Windows finds the Growl program. I suppose if you were working on Ruby all the time and regularly running tests you could set up Growl to start automatically when Windows starts.

When you start Growl it displays a message telling you it’s running, but that’s all it does. It’s just waiting for a notification to display. Growl lives in the system tray. You can click it and change the setup options:

I’m not entirely sure what added Autotest to the list of applications. It wasn’t there at first but one of the command-line commands must have added it.

After setting up Growl when you start Autotest:

$ autotest

and your tests complete you get a sound and a visual notification telling you whether your tests passes or failed. I chose the notification style called Visor which slides down from the top of the screen:

No DRb server is running

If, when you run autotest (or when you just run bin/rspec spec), you get:

No DRb server is running. Running in local process instead ...

it means Spork isn’t running.

Spork is a gem that you put into the Gemfile for your project. It contains a Distributed Ruby (DRb) server that enables Ruby programs to work with other Ruby programs by sending/receiving messages via the DRb server. So one Ruby program can use a method that’s defined in another Ruby program running on the same computer, or on a computer somewhere else on the network.

More about Distrubuted Ruby here: http://ruby.about.com/od/advancedruby/a/drb.htm

You need to associate your Ruby program with Spork. The setup instructions for Spork are described in the tutorial here: http://ruby.railstutorial.org/chapters/static-pages#sec:spork

To start Spork, open a new console window for the purpose, navigate to your project directory and enter:

$ bundle exec spork

You can then go back to your other console window and run autotest and it should complete the tests in less time, because it’s not having to load so much stuff (Spork has preloaded that stuff and is sitting waiting for connections).

Switching Web server from WEBrick to thin

Rails comes with the lightweight WEBrick Web server that you can use for testing pages – as described in the Rails Tutorial. However, I had a few odd little niggles with it, and it seemed very slow, so I switched to using an alternative called “thin”. To do this you need to install the eventmachine and thin gems.

Note: You need a particular version of eventmachine for thin on Windows.

1. At the command line, change directories to your project directory.

2. Edit the Gemfile file within the project directory to:

   group :development do   …   gem 'eventmachine', '1.0.0.beta.2'   gem 'thin' end

3. Then run:

   $ bundle install

4. You can then start the server like this:

   $ rails s thin

   Or, to redirect it’s output to a file and detach the process from the bash shell:

   $ rails s thin >> thin_output_log.txt &

Solving the ssh.exe problem

After initially using GitHub without any problems, when I tried to update GitHub a few days later I discovered that this was no longer working.

Whenever I tried to do anything involving a connection to GitHub – even just ssh git@github.com – I got a message saying: ssh.exe has stopped working.

After much fruitless Googling, uninstalling and reinstalling Git for Windows, disabling anti-virus, etc. I finally discovered the fix, which is to set the file properties of ssh.exe and ssh-keygen.exe (in the Git/bin directory) so that they run in either Windows XP or Vista compatibility mode (either will do).

I presume this is because I’m running 64-bit Windows 7. But I’ve no idea why it worked fine when I installed it initially.

Bizarrely, after restarting Windows I seem to have to go through this process again, even though the settings indicate that it should run in compatibility mode. It appears to be necessary to go to this tab in the Properties dialog box for these files and click OK to force this mode to be used.