How Does Rake Initialise a Rails App?

Rake is apparently simple, used all over the place, and a bit fiddly. Whenever you run a rake task, the entire rails application is initialised in the background. But how? HOW?!

  1.  It’s not the namespace you’re using. Arbitrary namespaces all initialise the rails app.
  2. Therefore, somehow, somewhere, something is happening in some parent task that everything is pulling in. But what?

Well, there’s no specific mechanism in rake that I’m aware of that arbitrary tasks inherit from. So it’s either the case that there’s a mechanism I don’t know about, or it’s the case that the rake tool has been monkeypatched somehow.

The case for rake being monkeypatched seems promising. How does rake -vT know to look in lib/tasks for extra tasks? Rails configuration, that’s how. So, how do you configure rake this way? I want to start by working out where a standard rake task is defined, so I try:

rake --where db:migrate

From here, I can see that railties is responsible for the db tasks. I also try:

rake --where log:clear

and it’s clear again that railties is coming into play. I’ve got a vague idea from the name, and my own reading, that railties is some kind of glue for rails. So, let’s dig a little deeper. I’ve opened my text editor to the location of the railties gem (it’s in the path given out by rake –where log:clear), and there’s a readme. It confirms that railsties is a glue gem.

I search for all files beginning with Rake, just because I’ve got to start somewhere, and find a rakefile in lib/rails/generators/rails/app/templates/ which has the line <%= app_const %>.load_tasks. This reads like an erb template, and I’m not specifically interested save that it gives me a clue: presumably, tasks are discovered by rails using a load_tasks method. Searching for “def load_tasks” in railties reveals:

# Load the application and its railties tasks and invoke the registered hooks.
# Check Rails::Railtie.rake_tasks for more info.
def load_tasks(app=self)

I can buy that initialize_tasks is going to be where I need to start. I search for def initialize_tasks and find:

def initialize_tasks #:nodoc:
self.class.rake_tasks do
require "rails/tasks"
task :environment do
$rails_rake_task = true

require_environment!? What does that sound like it does?

def require_environment! #:nodoc:
environment = paths["config/environment"].existent.first
require environment if environment

The namespace we’re in right now is “class Application < Engine”.

I can buy that this is where the environment is getting pulled in for _something_. I don’t know whether it’s the current app I’m working on, some rails-y magic or whatever. However, this doesn’t specifically help me out right now, because I’m trying to prevent rails loading for a rake task. rake task:name will still need to know how to load the rakefile in order to make any progress, which requires that the rails app has loaded. I’ve got a little further on the path to accomplishing my goal, but I’m not quite there.


Of course, I could just be overcomplicating things and there’s simply a Rakefile in rails root. And this slurps in the application config. Curses!

Integration Testing Subdomains In Rails

There seems to be a lot of confusion about this. The tl;dr summary is that this rails commit claims that the reason this is hard “stems from the fact that subdomain is defined in ActionDispatch:Request and the test session uses Rack::Request”. The solution was to “Extend assert_recognizes and assert_generates to support passing full urls as the path argument. This allows testing of routing constraints such as subdomain and host within functional tests.”

So your code should read as:

describe "GET /index_exists" do
 it "works! (now write some real specs)" do
 get ""
 response.status.should be(200)

So that’s a solution. Let’s talk about the problems. If you search for rails integration test subdomains, the first link is for a stackoverflow question and answer that suggests the following:

def setup
 host! "" 

When I try this, I get:

No route matches [GET] “<no hostname>/path”


Slightly Surprising Class Method Interaction

I encountered something in rails today that I haven’t seen before. It was clearly a ruby feature, so I wrote up an example in ruby. It’s an attempt to access a private instance method from both a public class method and a public instance method:

You have a class:

class SimpleClass
def self.stuff
"Private method returns #{private_stuff}"

def things
"Private method returns #{private_stuff}"

def private_stuff


I expected that in both cases, I’d get the string out:

Private method returns content

However, it turns out these are different. The instance variable version returns the output as expected. The class method?

undefined local variable or method `private_stuff' for SimpleClass:Class (NameError)

So, class methods cannot access private instance methods.

The rule in general is that a private method cannot have an explicit receiver. I am left wondering if a class method has an explicit receiver, and I’m just not seeing it.

Edit: hah! I was wrong in my supposition about an explicit receiver. The issue is that class methods are defined in the eigenclass, which is a step in the inheritance hierarchy above the current class and as such cannot access private methods in the current class.

This brings up the richer point: can a public instance method be accessed from within a class method? I’m betting on no.

Improving My Testing

I spent a good portion of today looking at integration tests.

In the normal course of things, a website undergoes integration tests from an external source; in my career it’s something like selenium for external testing of a website, and faraday for testing a RESTful API.

I’ve been thinking a lot, though, about where selenium fits into the test cycle. There’s a kind of test that I’ve seen selenium used for a lot, but is not its strong point, and that’s testing simple workflows: does /blogpost/new contain a title string, or does /index contain a sign_in link? Selenium _can_ do these things, but I think its real strong suit is complex scenarios: can I log in, then create a blog post, then assign the post to a calendar date, then make sure that the calendar picker doesn’t let me assign two posts to a date, and so on. Lots of steps, each of which takes you further into the application.

Simple stuff like checking if the front page is actually present can absolutely be covered by selenium, but it seems like I see two problems:

  • selenium tests take a real time to maintain, even for relatively simple changes.
  • selenium can be integrated into the build system, but it’s hard to integrate it into the testing cycle in such a way that developers get feedback before committing their code.

I wanted to solve both of these, and in rails it looks like the built in integration test stuff really solves both in a neat way. It sits there, between the unit test stuff and the full blown complex testing scenarios, providing a simple to maintain, integrated set of tests that nonetheless can be very useful.

Here’s a few downright useful tests I put together with a hand from a couple of guys with more UI experience than I have. Start by generating the integration test:

rails generate integration_test blogs

Now, here’s a neat set of simple tests:

class BlogTest < ActionDispatch::IntegrationTest
  test "browse index" do
    get "/"
    assert_response :success
   assert_select "h1"

  test "browse new page" do
    get "/blogs/new"
    assert_response :success
   assert_select "input"
  test "Find some specific field" do
    get "/blogs/new"
    assert_response :success
    assert_select "div.field"
  test "Find some specific text area" do
    get "/blogs/new"
    assert_response :success
    assert_select "textarea[name='blog[body]']"

If you’ve already installed capybara, the syntax is a little different but not bad:

 describe "GET /blogs" do
   it "works! (now write some real specs)" do
   # Run the generator again with the --webrat flag if you want to use webrat methods/matchers
   visit new_blog_path
   fill_in "Title", with: "Jamandbees' awesome blogness"
   fill_in "Body", with: "Jamandbees writes about sadness"
   click_button "Create Blog"
   page.should have_content "Blog was successfully created."
   page.should have_content "blogness"

That’s literally all there is to some very basic integration tests in rails.

I’m a professional QA resource; my idea about QA is that a QA person should know and understand the stack they’re working with as well as the developers understand it, and be able to comment  effectively and, yes, write code in the same language the developers are working in. As a QA person working in rails, I have known the full stack back to back in a basic way, sufficient to be able to sit down, read code with developers and comment upon it with them. If you can’t code review the codebase, there are entire stacks and oodles of bugs you cannot find.

I gave a presentation today about integration testing in rails and got clearance to start writing some of the basic integration tests that will improve our codebase. I can write these, have them integrated in the build and be confident that my (frankly, excellent) team of colleagues in development will be able to maintain them. I think that when an application is still young and in flux, having the QA person write tests and developers easily maintain them is a good balance for the team.

Finally Improving My jQuery

Taking a break from rails tonight to go through the peepcode video on jQuery. The advice I had from a pal is that jQuery is easy and separate enough from javascript that it can be learned by itself. I’m not certain I agree just right now, but it’s definitely a big eye-opener.

The big take home point for beginners here seems to be learn the following:


is a wrapper function. It serves mainly to take an argument, and make a jquery methods available on that argument. For example:


will wrap the someId element on a page inside jQuery and make jQuery methods available:


The other thing is that you’re going to be doing a lot of finding elements, so learn your bloody selectors! The jQuery documentation on selectors contains a bunch of jQuery specific stuff. Otherwise, I’ve been mostly learning them via writing selenium automation tests at work. 

I have a ton of documentation to research on test the rails view for a talk I’m leading tomorrow. Wish me luck!



Finally Improving my Rails

I’ve known bits and bobs about rails for years, but I’ve never sat down and tried to force myself to be a front-to-back rails developer. It seems weird to say that, because I’ve actively loved the ruby language for years and rails has been something I’ve made a living from supporting before, but my jobs have pulled in non-rails directions (windows, perl, learning vmware, networking, linux systems administration, more perl, more vmware, then lots of security and networking). Combine that with a wonderful relationship, lots of independent interests and it’s been hard to get time together to sit down and focus on rails by itself.

I’m newly single, though, and slimming down my interests a little and I’ve got time to be pursuing some stuff I’ve had on the back burner for a long time. The first of these is forcing myself into learning rails more thoroughly, from soup to nuts.

I’ve had a few ideas for a trouble ticket application to help at work, so I decided to start by making a simple rails app that will track tickets. Each ticket is an idea I’ve had for improving the app itself, so it’s useful from day one and immediate utility tends to keep the interest.

My immediate problem stems from having written a simple test:

test "Only high priority items are returned." do
tickets = high_priority_tickets
tickets.each do |ticket|
assert(ticket.priority =~ /^high$/)

I’m making the assumption here that I can write some method high_priority_tickets which will return all tickets with a priority of high. I don’t know where to put it, though!

I’m making the bet that it goes in the model for two reasons:

  • the model provides data for the controller/view
  • unit tests in rails are designed to test the model, integration tests are designed for the controller (c.f.

Still, it’s these kinds of small decisions I’ve not had to make before. It’s exciting getting to see my own rough edges.

Proc and Lambda and Block (oh my)

Something neat about  ruby is the equivalence of procs, lambdas and blocks. Take a quick look here:

foo = do |x|
puts "In a proc. X is valued at #{x}"
output -- "In a proc. X is valued at 24"

Pretty simple. Much like an UnboundMethod object, you have to call the proc with call. It can have variables supplied to it with the slide operator ||, or it can inherit the same from the surrounding scope:

x = 1
foo = do
puts "In a proc. X is valued at #{x}"
x = 25
puts "#{x}"
-- outputs 25

A lambda is an alternative proc syntax. Instead of explicitly creating a proc object, you get an anonymous one still bound to a variable:

bar = lambda { |x| puts "In a lambda. X is valued at #{x}"}
--- output "In a lambda. X is valued at 32"

Now, let’s take a look at a block. First, we define a method that yields to a block:

def runnable
puts "Inside runnable."
puts "Still inside runnable."


Now, we call the method with the same “do” keyword we already used for the proc:

runnable do
puts "I am a block."
--output: Inside runnable.
I am a block.
Still inside runnable.

Much as you can insert anywhere inside a scope, so you can also insert yield inside a scope and define the proc on-the-fly in a block. Compare the syntax of yielding a variable to that of using a variable with a Proc:

def runnable
puts "Inside runnable."
puts "Still inside runnable."
runnable do |x|
puts "#{x}"
output -- 42

This allows an associated block to use a variable set within the method. What’s neat, though, is that we can see that the method that yields has a key difference to a Proc: it cannot see into the external scope:

x = 1
def runnable
puts "Inside runnable."
puts "Still inside runnable."
runnable do
puts "I am a block."
--output - this code fails with an error.

There’s a scope defined by the method, and the variable x is different inside that method than outside of it. 

All this is documented in a github repo: — feel free to look through the history and goof around.

conway update

I got half way into Conway and haven’t picked it back up yet. 

The first problem conceptually as that I was stuck thinking about coordinates and coordinates and how does a cell know it has a neighbour and coordinates and neighbours?!

The solution came to me while I was on the bus, going down a beautiful canyon. The cell is a class. It cares about how many neighbours it has, so that it knows whether it is alive, dead or unchanged. 

The world tracks the position of the cells. The information the cell needs is how many neighbours it has. Not its own position, not how big the world is.

I need to write  a world for my cells to live in. Then I’d like something to output graphical information to. I think an ncurses UI would be fine first.

I should upload this to github or something.



Ideas Ideas Ideas.

Well, daily coding failed as a project. I don’t know whether it’s a discipline issue, or an interest issue, but trying to come up with artificial ways to keep progressing skill can be hard.


I’m updating my freebsd vm. I like keeping it around as a standard platform for writing ruby and for testing my code on. If it works on mac os, deploy to FreeBSD and verify it still works. If it does, yay! Whilst doing this, I’ve been trying to come up with a program-y project.

I have a couple of ideas that I’m batting around. Log parsing, message passing over a socket, having worker drones which report back to a central reporting facility. Solved problems, sure, but ones I’m interested in solving myself. Thinking about old problems that I want to re-solve, it hit me that I can write Conway’s game of life.

The rule set isn’t hard to implement, but I’d like to have a UI element too. This means either implementing a command line output with ncurses or whatever, or bringing up a window and drawing to it. Both of which seem very cool. I may even try both.

This seems like a good idea somehow.

Fewer, More Flexible, Options

I had a weird situation at work today. I have a script which runs for a specific amount of time:

script.rb --time 360

I had to add an option to make it run, then sleep, then run, then sleep, and so on. But I also still had to support the total time option.

The first thing I did was come up with a working model inside the code to support “run, then sleep, then run, then sleep”. I decided on a multidimensional array:

timeArray = [[100, 200], [150,300], [10,30]]

And I iterated over each:

timeArray.each do |timeArray|
timeToRun = timeArray[0]
timeToSleep = timeArray[1]

Now that was out of the way, I came up with comma-separated-semicolon-delimited strings as a way of specifying this on the command line:

script.rb --runandsleep 100,200;150,300;10,30

I called split on a semicolon first to give me a bunch of arrays containing each comma delimited string, then split on the comma and cast to integers using .to_i:

timesToRun = runAndSleepArgument.split(";")
timesToRun.each do |runAndSleepString|
sleepAndRunTimes = runAndSleepString.split(",")
runTime = sleepAndRunString[0].to_i
sleepTime = sleepAndRunString[1].to_i

All’s well and good, but what if the combination of run and sleep are specified with the total run time?

script.rb --time 150 --runandsleep "30,30;60,60;90,90"

I flopped back and forth for a while. I could preparse the –runandsleep time and if it was greater than the –time then refuse to run. That’d solve it. I could just run for the greater of the two times.

But what if someone enters:

script.rb --time 10000 --runandsleep "30,30"

I could run for 30, sleep for 30, then run for 9940. That had a decent solution.

The problem in my mind here is that I know what these kinds of things are like. I added a command line flag to this script (which is used a lot) called –destroy, because it called the destroyAllHumans function which reset a database. Within a week, the developers and QA were talking about how they were running with DESTROY or not with DESTROY and how it impacted things. As such, I know that the flags enter peoples’ heads. They get inside.

If the flag is non-intuitive, the person using the script is irritated. If the flag is intuitive, the person using the script thinks in terms of the flag.

So I solved the problem thus. You can specify:

script.rb --time 300

or you can specify:

script.rb --time "100,50;100,30;10,100"

Both of the syntaxes really specify a total run time, so why make them different? The script becomes better because it has fewer, more flexible, options.