Tuxicity - Rails

Mactag with FSSM

2010-10-14T00:00:00+00:00

When I first released Mactag I got a question about automatic updating of TAGS-files when changing file contents. Today Mactag can do this, with a little bit of help.

First, you need Mactag version 0.4.0 and the fssm Rubygem. The new version of Mactag includes a rake task called mactag:server. Calling this will start a server that listens for file changes in the project.

With the server started, changes to project files, creation of new files and removal of files will trigger Mactag to update, create or remove the corresponding TAGS-file.

Your editor however needs to be aware of TAGS-files changes. I created an Emacs script called Mactag.el that makes sure find-tag have the correct TAGS-tables before lookup.

Mactag - Ctags for Rails

2009-12-12T00:00:00+00:00

Ctags allows you to follow tags (of functions, variables, macros, whatever) to their definitions. If you do your Rails development in an editor that supports Ctags you might have been manually setting the TAGS-file up in your projects. To create a TAGS-file in my Rails projects, I always created a rake task.

Finally, I got tired of this and decided to write up a Rails plugin to do it. The result is Mactag. Mactag gives you a DSL to create a TAGS-file for your Rails projects.

An example configuration (config/mactag.rb) might look like this:

Mactag::Table.generate do
  app "app/**/*.rb", "lib/*.rb"

  plugins "thinking-sphinx", "whenever"

  gems "paperclip", "authlogic"
  gem "formtastic", :version => "0.9.7"

  rails :except => :actionmailer, :version => "2.3.5"
end

When this is set up you just run the builtin rake-task and the TAGS-file will be created for you.

$ rake mactag

See README at Github for a brief howto. And the documentation for detailed information.

Authlogic Password Reset Tutorial

2009-12-08T00:00:00+00:00

I just released a tutorial on how to reset a lost password in Authlogic.

Check it out: https://github.com/rejeep/authlogic-password-reset-tutorial

Testing user privileges with Shoulda

2009-11-24T00:00:00+00:00

It is really easy to test controllers with Shoulda. But testing a site that have users, administrators, reporters, etc… is a pain if you don’t do a little bit of customization yourself. It’s not hard to test that a user has to be an admin to visit a page, but if the tests are not kept DRY, this will end up in a big mess.

A while ago I used to do something like this to test that a visitor must be logged in to visit a page.

class PostsControllerTest < ActionController::TestCase

  context "on GET to :new" do
    context "when logged in" do
      setup do
        login_as_user

        get :new
      end

      should_assign_to :post
      # etc...
    end

    context "when not logged in" do
      setup { get :new }

      should_not_assign_to :post
      # etc...
    end
  end

end

This is nothing but true pain. It takes a long time write and the tests are hard to read. Specially if the same thing is tested for all REST actions, or more.

Finally, I got tired of testing like that and wrote this little piece of code, that nowdays saves both my fingers and eyes:

class ActiveSupport::TestCase

  def self.should_require_user(action, &block)
    context "#{action} when not logged in as user" do
      setup { instance_eval(&block) }

      should_respond_with :redirect
      should_redirect_to("the login path") { login_path }
      should_set_the_flash_to "You must be logged in to access this page"
    end
  end

  def self.should_require_no_user(action, &block)
    context "#{action} when logged in as user" do
      setup do
        login_as_user

        instance_eval(&block)
      end

      should_respond_with :redirect
      should_redirect_to("the root path") { root_path }
      should_set_the_flash_to "You must be logged out to access this page"
    end
  end

  def self.should_require_admin(action, &block)
    context "#{action} when logged in as a non admin user" do
      setup do
        login_as_user

        instance_eval(&block)
      end

      should_respond_with :redirect
      should_redirect_to("the login path") { login_path }
      should_set_the_flash_to "You must be an admin user to access this page"
    end
  end

end

Put this in a file named whatever you find appropriate and put it in test/shoulda_macros. I call mine security.rb. Then change the tests to suit your application.

The code defines three methods, which are all obvious, but I show one example of each below.

should_require_user

Remake of the test above.

class PostsControllerTest < ActionController::TestCase

  should_require_user("on GET to :new") { get :new }

  context "on GET to :new" do
    context "when logged in" do
      setup do
        login_as_user
       
        get :new
      end
       
      should_assign_to :post
      # etc...
    end
  end

end

should_require_no_user

User can not be logged in to visit the new action.

class UserSessionsControllerTest < ActionController::TestCase

  should_require_no_user("on GET to :new") { get :new }

  context "on GET to :new" do
    setup { get :new }

    should_assign_to :user_session
    # etc...
  end

end

should_require_admin

User must be an admin to visit the index action.

class AdminControllerTest < ActionController::TestCase

  should_require_admin("on GET to :index") { get :index }

  context "on GET to :index" do
    context "as an admin" do
      setup do
        login_as_admin

        get :index
      end

      should_assign_to :secrets
      # etc...
    end
  end

end

That is one line of code to say that you must be logged in as a user, an admin or not logged in at all to visit an action.

But, is this code really DRY?

In all the examples, the exact same get request is specified at two places. Luckely, Ruby lambdas can help refactor this.

class AdminControllerTest < ActionController::TestCase

  request_get = lambda { get :index }
  
  should_require_admin "on GET to :index", &request_get

  context "on GET to :index" do
    context "as an admin" do
      setup { login_as_admin }
      setup &request_get

      should_assign_to :secrets
      # etc...
    end
  end

end

The only thing left that is not DRY, is on GET to :index . However, this is not as easy to refactor as one might think. One option is to change the shoulda extention and skip the first argument.

class ActiveSupport::TestCase

  # ...

  def self.should_require_admin(&block)
    context "when logged in as a non admin user" do
      setup do
        login_as_user

        instance_eval(&block)
      end

      # ...
    end
  end

end

And then put the should_require_admin part, in the on GET to :index context, like this.

class AdminControllerTest < ActionController::TestCase

  request_get = lambda { get :index }
  
  context "on GET to :index" do
    should_require_admin &request_get

    context "as an admin" do
      setup { login_as_admin }
      setup &request_get

      should_assign_to :secrets
      # etc...
    end
  end

end

However, this will instead force you to repeat as an admin which is my opinion is worse since you have to do it once for each action an admin is required.

IE and MIME-types

2009-11-23T00:00:00+00:00

I’m using Paperclip for a site where a visitor can upload an image. The supported image types are gif, jpg and png.

So I created this Paperclip model validation:

validates_attachment_content_type :image, :content_type => [ 'image/jpeg', 'image/png', 'image/gif' ]

But of course something had to not work in Internet Explorer. Not obvious how a browser can affect something to fail on the server side. It turns out that IE translates the MIME-types a bit different than what other browsers do.

FORMAT          MIME-IE          MIME-OTHER
png             image/x-png      image/png
jpeg            image/pjpeg      image/jpeg

So the “correct” Paperclip validation for gif, jpg and png images would then be:

validates_attachment_content_type :image, :content_type => [ 'image/jpeg', 'image/png', 'image/gif', 'image/x-png', 'image/pjpeg' ]

Reload record into memory

2009-10-07T00:00:00+00:00

Lets say we are creating a simple blog. The blog has posts and each post can have many comments:

class Post < ActiveRecord::Base
  has_many :comments
end
 
class Comment < ActiveRecord::Base
  belongs_to :post
end

Lets also say that on the posts index page, all posts should be listed, and for each post the number of comments. To make this efficient lets add counter cache in posts for the number of comments. First a comments_count:integer column must be added in the posts table, and then the comments model has to be updated like this:

class Comment < ActiveRecord::Base
  belongs_to :post, :counter_cache => true
end

Now to the interesting part. Lets create a test for it:

context "a post" do
  setup { @post = Factory(:post) }
 
  context "gets a new comment" do
    setup { @comment = Factory(:comment, :post => @post) }
 
    should_change("the post comments count", :by => 1) { @post.comments_count }
   end
end

So, If we have a post. And then create a comment to that post. Then the post comments_count should increase by one. This seems like a good test. But it will fail because the comments_count was not expected to be zero, but was. Why is that? Testing this in the console will make the comments_count update correct.

Thinking about it, it’s kinda obvious why it fails. This is what happens in the test: A post is created and then fetched from the database into memory. Then the same thing happens with a comment. When the comment record is saved, it makes sure that the post comments_count is updated in the database. Thats right, in the database. Above I said that a post was read into memory. So the post the test is working with, is in memory. But the comment only updates the post in the database.

So what needs to be done is to update the post from the database, before checking the comments_count. Thankfully there’s a nice method in ActiveRecord that helps with this, called reload. Lets update the test to use reload, and then run it again. And what do you know, it passes. Here’s the working test:

context "a post" do
  setup { @post = Factory(:post) }
 
  context "gets a new comment" do
    setup { @comment = Factory(:comment, :post => @post) }
 
    should_change("the post comments count", :by => 1) { @post.reload.comments_count }
  end
end

So whenever you update a record from another. Make sure to reload the record from the database to get the changes in to memory.

Replace newlines with commas

2009-10-06T00:00:00+00:00

Background

Note! If you’re only interested in the solution, read the Solution section at the end.

I had a companies table with more than 2M rows. And for each company I wanted to set a column, should_index, based on some conditions. There was no way I could write this in pure SQL (at least not with my knowledge), so I created a simple rake task:

namespace :companies do
  task :update_should_index => :environment do
    Company.find_in_batches do |companies|
      # ...
 
    end
  end
end

Running this took forever, so I wanted to avoid doing this again. I knew that the companies table was not going to change, so I thought I’d create a SQL-script and run it on the other environments and computers that was working on the project. So I wanted to dump all company ids that had should_index = 1:

$ echo "SELECT id FROM companies WHERE should_index = 1;" | mysql -u user -p -D database > ids.sql

Then all I had to do was to create a simple update query like this with the ids in the file:

> UPDATE companies SET should_index = 1 WHERE id IN (1, 2, ... , n);

Pretty simple! Except that the ids.sql file contained more than 100 000 lines of ids. Emacs usually is really good at these kind of things, except that 100 000 lines was to much. So I had to figure out a way to convert from:

To:

2334, 45345, 2342, 23434, ...

Solution

I tried a little bit of sed and awk. But it turns out that the winner by far was tr:

$ tr '\n' ', ' < ids.sql > ids_with_commas.sql

Thats it! Now I have a nice SQL-script that takes just a few seconds to run.

Send inline attachments in Rails

2009-09-08T00:00:00+00:00

I was looking for a way to send inline attachments in emails. This way you can for example add your logo to an email.

Unfortunately there seems to be no easy way of doing this. After some googleing I found a ticket for this with a patch that I got working.

For some reason the core developers did not accept the patch. So I decided to make a plugin of it so that I easy could use it in my own applications. The plugin is available at Github if you have the same problem.

Latest version of Autotest fails

2009-07-22T00:00:00+00:00

The lastest version of Autotest introduced some trouble for be.

First I had trouble even starting Autotest. The solution was to install rails-autotest:

sudo gem install rails-autotest

Then however I was having another trouble using Redgreen. I got this error:

no such file to load -- autotest/redgreen (LoadError)

Turns out that the require in .autotest has taken a turn. Changing from:

require 'autotest/redgreen'

to:

require 'redgreen/autotest'

did the job.

Shoulda requires a database record

2009-06-03T00:00:00+00:00

I fell into a trap today when creating some tests using Shoulda.

I had a user model and for that a test. In the user model I had this validation:

validates_uniqueness_of :email

and in the test this:

should_validate_uniqueness_of :email

But weird enough I got this failure:

1) Failure:
test: User should require case sensitive unique value for email. (UserTest)
[/usr/lib/ruby/gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/assertions.rb:50:in `assert_accepts'
/usr/lib/ruby/gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/active_record/macros.rb:88:in `__bind_1243608769_500830'
/usr/lib/ruby/gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/context.rb:253:in `call'
/usr/lib/ruby/gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/context.rb:253:in `test: User should require case sensitive unique value for email. ']:
Can't find first User

I even got it when I changed the :case_sensitive option.

Turns out that Shoulda requires there to be a record in the database. So by just creating a record I got rid of the failures:

Factory(:user)

Update

In recent versions of Shoulda this is solved by defining a subject block:

class UserTest < ActiveSupport::TestCase
  subject { Factory(:user) }

  should_validate_uniqueness_of :email
end

Action By Name

2009-04-30T00:00:00+00:00

How many blogs have I read lately, where the authors first words are: “It’s been a while since my last post”. I can not do anything other than the same, because it has been a while.

To the point. I’m working on a Java project in school right now. Coming from a long time development in Rails, I got tired of all the typing and asked myself: Where did all the “It just works” go? And I came to the conclusion that there is none, or very little. So I took matters in to my own hands and created a somewhat Rails like functionality for controllers.

As all Rails developers know, or at least should know, the controller is determined by params[:controller] and the action by params[:action]. So what I did was something similar, only that you in Java can not pass params, as you can in Rails.

By name

Basically how it works is that when you create a controller you extend ApplicationController, that in turn extend ActionController. Example with one save method (or action).

public class SomeController extends ApplicationController
{
  public void save()
  {
    // Do the saving...
  }
}

Then say we want to call that method when a button is pressed. By extending ApplicationController it is as simple as this:

JButton save = new JButton("Save");
save.addActionListener(someController);
save.setName("save");

Almost like in Rails. You specify controller and action, and then Rails does the rest. Now when you click the save button, the method save in SomeController will be called automatically. Easy, right? Or, at least as easy as it can be in Java.

Method Missing

After a while I was assigned a task and doing it I discovered some limitations. The task was to create a menu, in which you could switch between all different languages. Adding a new language to the application is as easy as putting a YAML-file in a directory (À la Rails). So I created the menu dynamically from all yml-files. I also created a controller named LanguageController, that should receive actions when the language should change.

I discovered that to make this happen, I had to create one method in the controller for each locale (sv, en, fi, etc…). And that was clearly not an option. So in ActionController I added some new functionality. Most of you Ruby and Rails developers know it. I’m talking about method-missing.

How it works is simple. If there’s no method in the controller, with the same name as the component, the method methodMissing in ActionController is called. So in my case it was as simple as in LanguageController override methodMissing and implement the language switching.

Interesting

If you want to know more. Read the few lines of code and it’s many lines of comments. It’s at Github. There’s also a simple example included.

Share named scopes in Rails

2009-01-04T00:00:00+00:00

In a project I’m working on we have chemicals that belongs to a department and a department has many chemicals:

# app/models/chemical.rb
class Chemical < ActiveRecord::Base
  belongs_to :department
end

# app/models/department.rb
class Department < ActiveRecord::Base
  has_many :chemicals
end

In our project we use named scope extensively. This is an example:

# app/models/chemical.rb
class Chemical < ActiveRecord::Base
  belongs_to :department

  named_scope :belongs_to_department, lambda { |department| { :conditions => { :department_id => department } } }
end

With this scope all chemicals that belongs to a department can be fetched with:

Chemical.belongs_to_departments(department)

But, chemicals was far from the only model belonging to a department. People for example, were this scope also came in handy.

# app/models/person.rb
class Person < ActiveRecord::Base
  belongs_to :department

  named_scope :belongs_to_department, lambda { |department| { :conditions => { :department_id => department } } }
end

Works fine, but now that same code is in two models. This way of doing things is bad and we need to find a way to refactor this in order to make our code DRY. So the scope needs to be shared through all models that belongs to a department (and needs that scope), and that with our code still DRY.

This is usually achived by including a module in the models, as it is in this case. But since sharing a named scope is very common, I want to have them nicely structured.

So in lib, I have a folder named named_scope. And in that folder, all modules with common named scopes are. To get extra nice structure I create a module called NamedScope:

# lib/named_scopes/named_scope.rb
module NamedScope
end

Now I create the module that will hold the common department scope. And that can be done using self.included:

# lib/named_scopes/department.rb
module NamedScope::Departments
  def self.included(base)
    base.class_eval do
      named_scope :belongs_to_departments, lambda { |departments| { :conditions => { :department_id => departments } } }
    end
  end
end

So now in my models I can include that module:

# app/models/chemical.rb
class Chemical < ActiveRecord::Base
  include NamedScope::Departments

  belongs_to :department
end

# app/models/person.rb
class Person < ActiveRecord::Base
  include NamedScope::Departments

  belongs_to :department
end

Now I can, with a DRY code and a nice structure, do this on both models:

Chemical.belongs_to_department(department)
Person.belongs_to_department(department)