validates_presence_of :purpose : Tag rails, everything about rails

Comatose bug when creating pages in migrations

Tue, 27 Oct 2009 22:27:00 +0000

Comatose is a micro CMS, easy to embed in your Rails app, ideal when the customer wants to update her FAQ once in a while. I work on a few projects where comatose is integrated, and it's been the second time now that one specific problem has given headaches to me and my colleagues. Time to document the solution.

Comatose has a hierarchical structure. All the pages are children of the comatose root page, which is usually not in use. This root page is created by the migration AddComatoseSupport. When we add comatose to a project, we usually create another migration, where some child pages are created and populated (because the customer usually already knows what pages she wants). This can look like this:

root = ComatosePage.find_by_title('Home Page')
faq = ComatosePage.create(:title => 'FAQ', :author => 'System', :body => "Text goes here.", :parent_id => root.id

All will be fine if you run the AddComatoseSupport migration first, and then the other one. If you run both of them in one go, all will look correctly first, too. But then - try to access the application and you get "a nil object when you didn't expect it!" A look in the database will tell you that your root page and your FAQ page are both there - but the slugs (needed to access the pages) are nil. Why is that?

The answer: The class ComatosePage gets overwritten in the AddComatoseSupport migration, to make sure the comatose root page can be created (they are invalid without parent_id). But if you have another migration following this one, where you create a couple of comatose pages, they still are instances of that overwritten class. Especially the before/after filters from the original ComatosePage aren't evaluated. In those filters the slug fields are meant to be populated, so they are nil.

First soluton: Define a class ComatoseRootPage instead, so you won't override anything.

Second and much easier solution: Remove the class redefinition altogether, for the root page just do

ComatosePage.new(...).save(false)

See on github.

Unfortunately the comatose project is not updated very often, so this bug is still unsolved in the generated migrations.

Snippets for cucumber

Sun, 25 Oct 2009 21:53:00 +0000

In every project I use cucumber (that means, always) there are a few things that I keep reinventing, or I spend a lot of time searching for them in other projects. Here are some of them. They aren't all written by me, but maybe my coworkers like to use this as a reference, too?

When you upgrade to the current cucumber (0.4.2) from an older version some steps will fail, because cucumber doesn't examine the whole html anymore. You can still check the raw html with these steps:

Then /^I should see "([^\"]*)" in the source$/ do |text|
  response.body.should match(/#{text}/)
end

Then /^I should not see "([^\"]*)" in the source$/ do |text|
  response.body.should_not match(/#{text}/)
end

Want to test sorting in one step?

Then /^I should see "([^\"]*)" before "([^\"]*)"$/ do |first, second|
  response.body.should match(/#{first}.*#{second}/im)
end

Sometimes you want to click a link in a specific div:

When /^I buy "([^\"]*)"$/ do |title|
  product = Product.find_by_title(title)
  field_by_xpath("//div[@id='buy_product_dialog_product_#{product.id}']//input").click
end

Or you want to test what happens when you delete a specific object:

When /^I press "Delete" for comment "([^\"]*)"$/ do |comment|
  tag = Comment.find_by_title(comment)
  field_by_xpath("//form[@id='delete_comment_#{comment.id}']//input[@type='submit']").click
end

With this you can check for a string that's within a tag with a specific id:

Then /^I should see "([^\"]+)" in "([^\"]+)"$/ do |content, css_id|
  response.body.should have_tag("##{css_id}", content)
end

Use this regex to check for something within a given tag:

Then /^I should see "([^\"]*)" within a (\w+) tag$/ do |text, tag|
  response.body.should match(/<#{tag}[^>]*>[^<]*#{text}[^<]*<\/#{tag}>/)
end

Cucumber 0.4.2 auto-generates webrat_steps.rb including a step to save the current page and open it in the browser. Just in case not everyone knows this step by now:

Then /^show me the page$/ do
  save_and_open_page
end

Things I learned recently

Sat, 24 Oct 2009 21:12:00 +0000

Doing client work for Upstream, I recently had the pleasure of pair programming with fabulous Pat Allan for a month. Here are a few of the things I learned.

Pair Programming is a good thing (not that I haven't known that before). Here is yet another good article about pairing if you aren't convinced yet. Next to improved concentration, keeping each other from getting stuck in stuff, I like the sharing of best practices, Textmate short cuts, syntax tricks etc.
Instead of writing "puts" in, after and before blocks that don't act as expected, use ruby-debug. It's really easy, and gives you so much more information about your situation. Just do:
```
sudo gem install ruby-debug
```
And in your code, at the place you want to examine:
```
require 'ruby-debug'
debugger
```
Then restart script/server with the --debug option. It stops when the line where you put 'debugger' is reached. You can directly call variables to explore their values. The basic commands are:
- n - next
- s - step into method
- c - continue to breakpoint
Read the source code of the gems you're using. If you are not sure how to do something with the gem, the actual code is often more informative than documentation. Lachie Cox describes in his blog how to set up a Textmate shortcut with which you can access all your gems without any typing.
Rubular is a nice app to test regular expressions in your browser.
I have never used RCov before. Of course it doesn't mean too much, but having a test coverage of 97,7% feels good, I can tell you. A Code to Test Ratio of 1:2.7 is not bad either.
The RCov gem has moved to Relevance, read here how to set it up for an RSpec/Cucumber environment.
And finally, I got convinced that it's good to have a blog ...

Here we are!