Here’s a rake task to list TODOs in all *.rb files under a Rails application’s app directory, and another to open them in VIM (or your preferred editor):

require File.expand_path(File.dirname(__FILE__) + "/../../config/environment")
 
namespace :todo do
  desc 'List TODOs in all .rb files under app/'
  task(:list) do
      FileList["app/**/*.rb"].egrep(/TODO/)
  end
 
  desc 'Edit all TODOs in VIM' # or your favorite editor
  task(:edit) do
      # jump to the first TODO in the first file
      cmd = 'vim +/TODO/' 
 
      filelist = []
      FileList["app/**/*.rb"].egrep(/TODO/) {|fn,cnt,line| filelist << fn}
 
      # will fork a new process and exit, if you're using gvim
      system("#{cmd} #{filelist.sort.join(' ')}") 
  end
end

Put the above code in a .task file under lib/tasks/, and invoke them with rake todo:list, and rake todo:edit respectively.

Sample Output of rake todo:list:

app/models/xxxx_transaction.rb:13: # TODO: rewrite this ...
app/controllers/membership_controller.rb:98:  # TODO: raise an exception

Goldberg is a great plugin for user/role authentication, with simplistic CMS features and an administrative interface. It wraps itself around your application without adding a single line of code to it.

The Dark Con

But for a plugin that makes authentication so easy, testing really sucks. To boot, a goldberg-enabled application is currently very unintuitive to deploy (more on that in a separate post).

Once goldberg is installed, your functional/integration tests will fail because goldberg intercepts all url requests and redirects you to /goldberg/auth/login. Fret not, here’s what to do.

Loading Goldberg’s data into the test environment

Goldberg provides two handy rake tasks:

• rake goldberg:dump_bootstrap which dumps your goldberg specific data to yaml files under vendor/plugins/goldberg/db/
• rake goldberg:load_bootstrap loads the data, from the yaml files that dump_bootstrap created, into your current database environment.

Dig into the second task and you’ll see that it uses a GoldbergMigration.load_bootstrap method.

Add this to both your functional and integration tests:

def setup
  GoldbergMigration.load_bootstrap
end

This loads the goldberg-specific data into your test environment. (of course, you need to dump it at least once using rake goldberg:dump_bootstrap !)

Integration Tests

In your integration tests, add the above code to your setup method, and use the below code in your test methods.

def test_index
 
    get "/goldberg/auth/login"
    assert_response :success
    post "/goldberg/auth/login", :login => {:name => "yourusername", :password => "yourpass"}
    follow_redirect!
    assert_response :success
 
    # do your testing here
    get "yourcontroller/index"
    assert_response :success
    assert_template "yourcontroller/index"
end

Functional Tests

Put the following into your setup method and they’ll run fine.

def setup
    get 'goldberg/auth/login' # otherwise @request.session will be empty
    @ouruser = Goldberg::User.find(:first, :conditions => 'name="yourusername"')
    Goldberg::AuthController.set_user(@request.session, @ouruser.id)
end

The downside to this is that calling GoldbergMigration.load_bootstrap for every test method slows down your tests, as it reads the .yml files from disk everytime. Awful, I know. But I can’t find a better way.

Don’t forget

Before you run your tests, don’t forget to create the proper goldberg tables in your test database: run ‘rake RAILS_ENV=test goldberg:plugin_migrations‘. Also, I am assuming you have used goldberg’s admin interface to create a user to test with - you have, haven’t you ?

Live Free and DRY Hard

For my project, I created two helper methods in test_helper.rb called goldberg_setup and goldberg_migrate. The first method has the single line (GoldbergMigration.load_bootstrap) and the second one has the code that the functional tests require.

For those who know not

The goldberg plugin, currently at version 0.2.1, is under active development, and the authors are active at the Goldberg community forum.

Thanks to unclecheese whose travails preceded mine.

Well, this is weird.

I wrote a rake task to import data from a csv file (output from a legacy system) into my development database for testing. The catch was that I wanted to extend my model class by adding a custom method only in the rake file.

require File.expand_path(File.dirname(__FILE__) + "/../../config/environment")
 
class Customer < ActiveRecord::Base
  def my_custom_method
  end
end

But here, for some reason, rake tries to define a _new_ activerecord model, not redefine the existing model I’ve written. So, what I tried was to precede the class definition with:

c = Customer.new # which really goes to waste

and it worked ! Rake now recognizes that I’m trying to add a method to my existing rails model !

Today I discovered the following Rails oddity.

Models created in a test fixture don’t have their created_at attributes auto-updated. They need to be specified like this:

created_at: <%=Time.now.to_s(:db)%>

Thanks to toretore on #rubyonrails (irc.freenode.net) for this tip.

Dreamweaver CS 3 has a facility to rearrange inline styles in a <style> tag. Well, here’s a utility that does the opposite: it converts css in style tags to inline css. Yeah, I hear you. Why would anyone want to do that ?!

Sending HTML Newsletters is a nightmare. Most of the email clients, bar Eudora Light, support css. However, not all properties are supported, and Gmail, one of the major web-based email clients, supports only inline styles.

You need Ruby, and Hpricot installed to run this. Duh, it runs on windows too !

EDIT: fixed a bug & added NOTES

Here’s the code:

#!/bin/env ruby
# style2inline.rb - v0.2
# http://tech.bytefull.com
 
# NOTES:
# CSS must not contain any comments
# the last attribute-value pair must end in a semi-colon, example:
#  a {font-family: Verdana; font-size: 18pt;}
 
# uncomment this if you have hpricot installed as a gem
# require 'rubygems'
require 'hpricot'
 
def style_to_inline(filename)
  doc = open(filename) {|f| Hpricot(f)}
  css = ""
  elems = doc.search('head/style')
  # combine the content of all style tags
  elems.map {|x| css << x.inner_html}
  # remove the style tags - we don't need them in our output doc
  elems.remove
  # collapse all newlines
  css.gsub!("\n", " ")
  # Regexp by Nick Franceschina
  # http://regexlib.com/REDetails.aspx?regexp_id=916
  dec_block = '((\s*([^,{]+)\s*,?\s*)*?){((\s*([^:]+)\s*:\s*([^;]+?)\s*;\s*)*?)}'
  regexp = Regexp.new(dec_block, Regexp::IGNORECASE)
  results = css.scan(regexp)
  results.each do |res|
    res[0].split(',').each do |css_sel|
      doc.search(css_sel.strip).each do |elem|
        if elem.elem? # added in version 0.2,
                      # to avoid operating on a Hpricot::Text element
          if elem[:style] then
            # append to the existing style information
            elem[:style] = elem[:style] + res[3]
          else
            # add a style attribute
            elem[:style] = res[3]
          end
          # we don't need the class attribute
          elem.remove_attribute(:class)
        end
      end
    end
  end
# output
  File.open("s2i_#{filename}", 'w') {|file| file.write(doc) }
end
 
ARGV.each {|x| style_to_inline(x)}

Invoke it with ruby style2inline.rb [FILENAME], and it will output a file of the same name prepended with ’s2i’, e.g s2i-filename.html.