Myself and a colleague have just managed to waste away a good couple of hours trying to figure out Autotests strange ’style’ mechanism to add the ability to test in the way Jay Fields explains using UnitRecord.

You can grab our plugin to enable UnitRecord when using Autotest below:

http://svn.soniciq.com/public/rails/plugins/iq_autotest

By default, running autotest in the Rails directory will run the unit tests. To run the functional tests, do: AUTOTEST='functional' autotest

I hope this saves some people some time!!

We are looking for a Ruby on Rails, XHTML & CSS Developer to join our team at SonicIQ. Head over to 43folders job board to view our ad.

These are exiting times with projects like Propel’r in the pipeline, along with the ever-growing opportunities for new and interesting client projects.

If you are a highly motivated developer and can see yourself in a Ruby on Rails position in sunny (sometimes) Bournemouth, UK then apply at 43folders.

To view the coverage of your plugins using Rcov, first install the rcov gem with sudo gem install rcov, then copy and paste the following onto the end of the Rakefile inside your plugin directory:

require 'rcov/rcovtask'
 
desc 'Measures test coverage using rcov'
namespace :rcov do
  desc 'Output unit test coverage of plugin.'
  Rcov::RcovTask.new(:unit) do |rcov|
    rcov.pattern    = 'test/unit/**/*_test.rb'
    rcov.output_dir = 'rcov'
    rcov.verbose    = true
  end
 
  desc 'Output functional test coverage of plugin.'
  Rcov::RcovTask.new(:functional) do |rcov|
    rcov.pattern    = 'test/functional/**/*_test.rb'
    rcov.output_dir = 'rcov'
    rcov.verbose    = true
  end
end

You can now simply run rake rcov from inside your plugin directory which will generate an rcov directory with the results. Open rcov/index.html (if you are on OSX this will open automatically) in a browser to view the results.

Thanks to Mike Clark for his Rcov rake task for Rails which this task is based on.

Update (11-11-08): Changed code to use the RcovTask class.

John Nunemaker posted a handy tip on setting up autotest to work with Growl

I use this all the time now however I didn’t like the ugly smilies (call me shallow if you like). I used Wolfgang Bartelme’s Smily Devkit to make a couple of PNG’s slightly more pleasing to the eye.

The zip file can be downloaded here: autotest_images.zip

Update 17-08-07: Added ‘pending’ image for RSpec as requested by Aslak Hellesoy

Following my previous post, below is a modified version of John Nunemaker’s ‘Renaming RHTML to ERB’ to take into account the format in the extension, and handle the RJS issues I was having.

namespace 'views' do
  desc 'Renames all .rhtml views to .html.erb, .rjs to .js.rjs, .rxml to .xml.builder and .haml to .html.haml'
  task 'rename' do
    Dir.glob('app/views/**/[^_]*.rhtml').each do |file|
      puts `svn mv #{file} #{file.gsub(/\.rhtml$/, '.html.erb')}`
    end
 
    Dir.glob('app/views/**/[^_]*.rjs').each do |file|
      puts `svn mv #{file} #{file.gsub(/\.rjs$/, '.js.rjs')}`
    end
 
    Dir.glob('app/views/**/[^_]*.rxml').each do |file|
      puts `svn mv #{file} #{file.gsub(/\.rxml$/, '.xml.builder')}`
    end
 
    Dir.glob('app/views/**/[^_]*.haml').each do |file|
      puts `svn mv #{file} #{file.gsub(/\.haml$/, '.html.haml')}`
    end
  end
end

Update

Added haml conversion.

It seems that on edge revision 6502 and later, the way that view file extensions has changed considerably.

I couldn’t work out why my tests were breaking when doing an xhr request to a new action which had a respond_to block setup for both html and js. It was returning the html instead of the rjs??

It turns out (after tearing my hair out for over three hours) that Changeset 6499 changes things in such a way that the normal new.rjs naming will not get picked up on an xhr request, you now need to add the request format to the extension before the template type i.e. new.js.rjs

This seemed a little odd at first but I am guessing it means you could have a new.js.erb file which is pretty cool as you could achieve the same as Dan Webb’s MinusR plugin.

What does seem a little odd is that a new.rjs will get picked up if you don’t give a respond_to at-all (I don’t know if this is a “feature” or a bug).

I’m am hoping that this may save someone some time.

Dan Benjamin recently updated his very helpful article entitled “”Building Ruby, Rails, Subversion, Mongrel, and MySQL on Mac OS X”:http://hivelogic.com/narrative/articles/ruby-rails-mongrel-mysql-osx”.

I don’t know about anyone else but compiling software is not one of my favourite pastimes. As I’ve been chopping and changing macs lately I thought I’d write a couple of shell scripts to get things right before running anything on my nice new (freshly installed) MacBook Pro.

Prerequisites

There are a couple of prerequisites in addition to what’s on Dan’s “”What’s Needed”:http://hivelogic.com/narrative/articles/ruby-rails-mongrel-mysql-osx” list before running the scripts. The first is that you must have MySQL installed as referenced in Dan’s article, and the second being the following:

Ensure you have the following line at the end of your ~/.bash_login file:

export PATH="/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:$PATH"

You can add this by typing nano ~/.bash_login then copy and paste the above line into the end of the file. Once this is done, hit ctrl-x to exit, answering ‘y’ to “do you want to save changes” prompt.

The scripts

There are two scripts, 01_osx_rails.sh and 02_osx_image_tools.sh and the following will explain how to use them.

Creating your development environment

The first script will install everything in Dan’s article along with the following gems that I use frequently:
* rails version 1.1.6 for support of older rails apps
* bluecloth
* redcloth
* sqlite3-ruby
* ferret
* ZenTest
* redgreen

Right… here we go:

(please read the licence before running these scripts as although they have been tested on a clean install of Tiger, I can’t take any responsibility if something breaks)
# Download 01_osx_rails.sh to your desktop
# If you don’t wish to install all of these gems then open the file in a text editor and comment out the relevant lines with a hash.
# Open a new terminal window and type the following:

cd ~/Desktop
sh 01_osx_rails.sh

That’s it, you should now have a fully working development environment.

Image tools

I use a couple of image tools on my system, GD and ImageMagick (with RMagick). If you wish to install these tools and the related libraries, run the following:

(This script hasn’t been tested as much as the previous one so use at your own risk. If anyone has any bug fixes then please post a comment)

cd ~/Desktop
sh 02_osx_image_tools.sh

We’re done

Please let me know if I’ve missed anything obvious.

I hope this helps anyone else out there with Compilaphobia!

Last Friday, a couple of us from SonicIQ went to the first RoR eXchange hosted by Skills Matter.

It was a great day with some interesting talks from:

• Chad Fowler
• Tom Locke
• Paul Battley
• James Cox
• Damien Tanner
• Ben Griffiths
• Eleanor McHugh

Chad Fowler - Quick and Dirty Clean: Well factored Rails

Chad kicked off with a talk on “Quick and Dirty Clean: Well factored Rails”. For me it was one of those talks where you think “If only I heard this 6 months ago!”. The reason I say this is that a great deal of what he was talking about, we now implement on a day-to-day basis, but we have gotten there the hard way through making the mistakes that he mentions.

He talks about never using instance variables in views, I love that someone has confirmed this as I find it generally bad practice. For a while now we have been replacing them with helpers giving much more flexibility when the controller logic changes.

One great point that was made, was that SQL should never be used in controllers, not even in :order options. I have to admit, in the past I have done this a lot but the suggestion of custom finders in the model are a much better alternative and it keeps with the whole Skinny Controller, Fat Model idea.

One thing I really must get into the habit of using are association proxies for has_many and such like. Chad showed some great examples of this.

If you’re anything like me, you like to keep database columns in a reasonably logical order. In my case I generally keep primary keys as the first column, then content columns, then special usage columns, then foreign keys e.g.

id
name
description
created_on
updated_on
account_id

Now, say I added a ’slug’ column with a migration:

def self.up
  add_column "projects", "slug", :string
end

That’s fine, I have my new column but it’s after my foreign keys:

id
name
description
created_on
updated_on
account_id
slug

What’s it doing down there? I want it after the ‘name’ column! …wouldn’t it be nice if you could specify an :after option for add_column.

We can make this possible by monkey patching the add_column method at the top of our migration file (I will make this into a plugin when I get time):

module ActiveRecord
  module ConnectionAdapters # :nodoc:
    module SchemaStatements
      def add_column(table_name, column_name, type, options = {})
        add_column_sql = "ALTER TABLE #{table_name} ADD #{quote_column_name(column_name)} #{type_to_sql(type, options[:limit], options[:precision], options[:scale])}"
        after_column = options.delete(:after)
        add_column_options!(add_column_sql, options)
        add_column_sql << " AFTER #{after_column}" if after_column
        execute(add_column_sql)
      end
    end
  end
end

This lets us do the following:

def self.up
  add_column "projects", "slug", :string, :after => 'name'
end

Which gives us:

id
name
slug
description
created_on
updated_on
account_id

Much better… this may seem a little petty, however as your tables get more and more columns it makes things much easier to follow.

Please note: I have only tested this with MySQL

Update: this is now a plugin and can be downloaded here

One thing that annoyed me when I first started using Rails at 0.14 was that I was forced to put my .css files in a ’stylesheets’ directory and my .js files in a ‘javascripts’ directory.

Previous to Rails I would put .css files in a ‘css’ directory and .js files in a ‘js’ directory (call me old fashioned). I use the following code in my application helper to allow me to do this:

module ApplicationHelper
  def javascript_path(source) compute_public_path(source, 'js', 'js') end
  def stylesheet_path(source) compute_public_path(source, 'css', 'css') end
end

Just incase anyone else has the same niggle.

Update 29-11-08: for Rails 2.2, see new post.