Update on the Austin Groovy/Grails Community

The first is that there are plans for a Grails bootcamp. It might be an all-day event on a Saturday, it might be a two-hour event at a regular meetup. So far there are not too many details.

There are also plans to make an event planning and management app for Agile Austin. It will be called Project Growler. The announcement is here, and it is on GitHub here.

I suggested that this could be used to make a beginning Grails tutorial, like Michael Hartl’s Rails Tutorial. I think the Groovy community should shamelessly copy things that the Ruby community does. They built up a strong, thriving community. Plus, a lot of developers are looking for alternatives to the MRI since it does not handle concurrency too well. Some people are looking at Elixir, some are looking at JRuby. I think Groovy would be a good fit.

Image from Wikimedia, assumed allowed under Fair Use. Section of a fragment of 2nd century Greek manuscript of an unknown romance.

Ruby Testing Archaeology

Note 2022-12-06: This is a consolidation of three posts, two posted on 2012-07-17, and one posted on 2012-07-23.


One of my frustrations with Rails is that there are few if any ‘include’ or ‘require’ statements. Now I am going to do something about it. At least something for myself.

I went through the Hartl tutorial (as do most Code Academy students, and many aspiring Rails devs). He uses RSpec and Capybara for testing. RSpec can be used for any Ruby project, while Capybara is used for web projects. I think it can be used for other Ruby web frameworks, and other testing frameworks besides RSpec.

One thing I find in the tutorial and the tests is that Hartl will just call methods and instantiate variables. I don’t always know whether he is calling something from RSpec or Capybara.

At one point, he says this: Because of subject { page }, the call to should automatically uses the page variable supplied by Capybara (Section 3.2.1). This is in refernce to the  file spec/requests/static_pages_spec.rb.

But where in Capybara does “page” come from?

You see it in code like this:

subject {page}

The “subject” method is used for the models as well:

subject {@user}

But there is no “page” model, or a “page” factory.  But it raises another question in my mind: What is “subject”?

I am pretty sure “subject” is from RSpec, either

In the Hartl specs (2nd edition) you see this (via grep -r subject * | grep page)
requests/static_pages_spec.rb:5:  subject { page }
requests/authentication_pages_spec.rb:5:  subject { page }
requests/micropost_pages_spec.rb:5:  subject { page }
requests/user_pages_spec.rb:5:  subject { page }

In the Hartl tutorial, at say, like http://ruby.railstutorial.org/chapters/filling-in-the-layout#sec:pretty_rspec, he says
Because of subject { page }, the call to should automatically uses the page variable supplied by Capybara (Section 3.2.1).

So where does “page” come from? I am looking around the Capybara docs, and on http://rubydoc.info/github/jnicklas/capybara/file/README.md I see this:
Full reference: Capybara::Node::Matchers

Capybara has a rich set of options for querying the page for the existence of certain elements, and working with and manipulating those elements.

page.has_selector?(‘table tr’)
page.has_selector?(:xpath, ‘//table/tr’)

page.has_css?(‘table tr.foo’)

After some googling and some digging, and it looks like “page” is part of the Capybara::DSL module:

It looks like it returns a Capybara::Session object.

At some point I will make a separate page or post with just the methods that pop out of nowhere, and whether they are RSpec or Capybara.


I made some progress on this.

If something is a class, like “page” in the Hartl tutorial (like on say spec/requests/static_pages_spec.rb)
you could just do

puts "Here is page.class: #{page.class}"

which would give you

Here is page.class: Capybara::Session

I don’t know why I didn’t think of that before.

In that file he also calls some voodoo methods. In before do he has:

sign_in FactoryGirl.create(:user)


visit users_path

sign_in and visit are methods. You can get these by doing this:

meth = self.method(:sign_in)
puts "Here is method of sign_in: #{meth.owner}"
meth2 = self.method(:visit)
puts "Here is method of visit: #{meth2.owner}"

or you could do that on one line each like this:

puts "Here is method of sign_in: #{self.method(:sign_in).owner} "
puts "Here is method of visit: #{self.method(:visit).owner} "

Which will give you:

Here is method of sign_in: Object
Here is method of visit: Capybara::DSL

Granted, getting “Object” is not too helpful. But it is some progress.

Someone on the Rails core team has a post about finding methods here.


In two previous posts, I wrote about my frustrations with methods in Rails tests that just seem to float in space and appear out of nowhere, and that the Hartl tutorial mixes RSpec and Capybara, and that it would be nice to know which is which.

In the last post, I wrote that sometimes when you try to find which class contains a method you get “Object”, which is not very helpful.

puts "Here is method of sign_in: #{self.method(:sign_in).owner} "
puts "Here is method of visit: #{self.method(:visit).owner} "
Here is the output:
Here is method of sign_in: Object
Here is method of visit: Capybara::DSL
The “sign_in” method is from one of the tests in the Hartl tutorial. I was explaining this to someone about an hour ago, and I realized why self.method says that  “sign_in” is part of the “Object” class: Because it is not defined in a class. In the application, Hartl defines it in a module, but in the tests it is simply defined in a file that contains neither  a class or a module.

In the root of the Rails tutorial app, you can run a grep command to find that method:

grep -rn 'def sign_in' *
This will give you the following result
app/helpers/sessions_helper.rb:3:  def sign_in(user)
spec/support/utilities.rb:3:def sign_in(user)

So here is the file spec/support/utilities.rb:

include ApplicationHelper

def sign_in(user)
  visit signin_path
  fill_in "Email",    with: user.email
  fill_in "Password", with: user.password
  click_button "Sign in"
  # puts "Here is method of click_button: #{self.method(:click_button).owner} - "
  # Sign in when not using Capybara as well.
  cookies[:remember_token] = user.remember_token

As I stated, in app/helpers/sessions_helper.rb the method is in a module called  SessionsHelper


Image from Pericopes Book of Henry II, an 11th century manuscript housed at Bavarian State Library, webpage information here, image from World Document Library, image assumed allowed under Fair Use.


Frustration Learning Ruby/Rails

I am still going through the Rails Tutorial. I am starting to have some issues with Ruby. It seems like there are methods in files that just float in space and land in your class.

For example, in the tutorial we make a class that inherits from ActiveRecord:: Base. It uses a method called “validates”, that as far as I can tell is part of ActiveModel:: Validations:: ClassMethods. I figured out that the “Methods” frame at the Ruby On Rails site has all the methods for all the classes and modules. Which is good, because the User class does not mention the ClassMethods module. I cannot figure out from the documentation that an ActiveRecord:: Base class can see/use the methods in ActiveModel:: Validations:: ClassMethods.

I posted this on LinkedIn, and I got a couple of responses. One guy’s answer involved looking through the source code, and seeing what classes are visible via the $LOAD_PATH variable. Granted, I posted that I looked through the source code, but I would prefer some way to know what methods are available without diving through the source code. I would like to get the answer via the docs. Another answer said that “the ActiveModel module is part of the ActiveRecord module”. Once again, I cannot find anything in the docs that tells me that. This second person referred me to the “Programming Ruby” book. Perhaps that page has the answer (I will read it later).

Another example is the tests use a method called “have_selector”, which from Googling I conclude is part of the Webrat gem. The test files have “require ‘spec_helper'” in them, and there is a spec/spec_helper.rb file in the project. But none of the test files say anything like “require webrat”.

In Java, every method must be part of your class, inherited from  a parent, or part of a class that you explicitly import. It seems like in Ruby imports can be “chained” (for lack of a better term). Perhaps the spec_helper.rb file starts a chain that at some point refers to a file in the webrat gem. But I would prefer that every file that uses “have_selector” say that it is using webrat, not something that calls webrat somewhere else.

Perhaps I should have gone through a Ruby tutorial before trying a Rails tutorial. Sometimes I like to know something more about a method, but I am sometimes having a hard time finding out where the method is from. Right now I feel like I have to go down a rabbit hole to find something.

Image from Wikipedia, assumed allowed under Fair Use.


Going through Rails Tutorial

I am making some progress with the Rails Tutorial. I installed Ruby with RVM. RVM added one of my accounts to the “rvm” group, but not my main account. So I added that and for the most part things have been good.

I was having some issues installing the heroku gem. I kept getting permissions problems. I am not too clear why, since I was using an account in the “rvm” group. Then after starting another Rails app, I figured out a way: Add “gem ‘heroku’, ‘1.20.1’” to a Gemfile in a project, run “bundle install”, and I got heroku.

An interesting fact: When I used the gem for the first time, I had to enter my heroku password on the command line. I was able to copy and paste a complex password into GNOME Terminal. I did not know it was possible to copy and paste things into a terminal when it prompts for a password. I always assumed you had to type it in. I think I have used terminals where passwords did have to be typed in.

Image from Wikimedia, assumed allowed under Fair Use. Image from the Vatican Virgil, a 5th century manuscript of poems by Virgil.


Update on Rails Tutorial

I am still going through the Rails 3 Tutorial by Michael Hartl. I am not implementing the examples as I go through it; I am reading it on the CTA as I go to and from work. I will implement them when I am done. I am able to follow most of it. I have done Java programming for several years, and I have also used Grails, so a lot of it was close to something I had done before.

Chapter 4 is a devoted to Ruby. There were a few small things in that chapter that I did not quite get. I have been going to the Chicago Ruby Meetups for a while, and I have not seriously dived into Ruby before this. So far I have been able to follow it. The only thing that I am not always clear on is that I am not always clear whether a class or method is part of Ruby, Rails or RSpec. A lot of times he will say where the classes and methods come from, but I think that if someone has little knowledge of Ruby or the Rails ecosystem it can be a bit confusing.

So far, I think it is a pretty good book.

At the most recent Chicago Ruby Hack Night, I met Obie Fernandez, the founder of HashRocket. He wrote an intro to the book. I asked him to sign my copy.

Image from Wikimedia, assumed allowed under Fair Use. Image from the Vatican Virgil, a 5th century manuscript of poems by Virgil. Note: Some images may contain spoilers.