Here are some things about Ruby Strings that may have escaped your attention - if you were introduced to Ruby via Rails

Efficiency

Since Ruby scans double-quoted strings for variables and escape sequences, it’s more efficient to use single-quotes for raw strings:

@sentence = 'Jackdaws love my big sphinx of quartz'
redirect_to :index => 'action'

Pretty Please, with sugar on top …

Split your strings across multiple lines. No backslashes required (sorry, couldn’t resist that !).

sql_query = "SELECT [column]
                 FROM [table]
                 WHERE [condition]
-- sql comment goes here"

or

# Q = double-quotes, embed variables 
# q = single-quotes
sql_query = %Q{SELECT @columnname
                 FROM @tablename
                 WHERE @conditions}
# You may use [ < or (as delimiters instead of {

ASCII code

To obtain the ASCII code for a character, prefix it with a question-mark:

puts ?B
# => 66

Convert it back to a string with:

puts 66.chr
# => "B"

Concatenation

Use the << operator to concatenate strings. Where += or + create a new copy, << appends to an existing string. Hence, it is more efficient:

existing << " end"

Instead of:

existing += " end"

(source)

Index a string with a regexp

You can test a string like this:

email = "spamandbakedbeans@skit.org"
if email[/@/]
  puts "I found the first @"
end

And this replaces the first match

string = "jackdaws love my big sphinx of quartz"
string[/a/] = 'A'
# => jAckdaws love my big sphinx of quartz

This replaces the second match

string = "jackdaws love my big sphinx of quartz"
string[/(j).+(z)/, 2] = "Z"
# => jackdaws love my big sphinx of quartZ

Remember, the regexp matches the entire string

Convert hex to integer (sort of)

Given a string representation of a hexadecimal, String.hex returns the corresponding integer:

puts "0x7b".hex # you can omit 0x if you wish
# => 123

Multiply a string

puts "<br />" * 3
# => "<br /><br /><br />"

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.

I found a nice guide (view as a pretty pastie) to deploying rails, mongrel and nginx on an Ubuntu Feisty Fawn Server. Its not verbose, but it is pretty helpful if you’re deploying your first rails app.

Be sure to customize it to your requirements.

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.