Lightweight ramblings

I was happily mocking away with Mocha, then I passed a stub to a case statement at which point I was a little flummoxed.

The Ruby documentation clearly states that the ‘when’ in a ‘case’ statement uses the ‘===’ method for comparing the subject so I couldn’t work out why something like the following wasn’t working:

# Code
class A; end
 
def foo(instance)
  case instance
    when A : 'an A instance'
    else 'not an A instance'
  end
end
 
# Test
a = stub_everything
a.stubs(:===).with(A).returns(true)
assert_equal 'an A instance', foo(a)

So I had a little play around in irb and found the following:

class A; end
a = A.new
a === A #=> false
A === a #=> true

This revealed that I was actually stubbing the wrong side of the operator, I changed this to the following and voila!

# Code
class A; end
 
def foo(instance)
  case instance
    when A : 'an A instance'
    else 'not an A instance'
  end
end
 
# Test
a = stub_everything
A.stubs(:===).with(a).returns(true)
assert_equal 'an A instance', foo(a)

Looks obvious now but certainly wasn’t at the time!

There is loads of documentation and posts on Git out there so this is more of a note to self as I keep forgetting the steps to setting up a remote repository and doing an initial ‘push’.

So, firstly setup the remote repository:

ssh git@example.com
mkdir my_project.git
cd my_project.git
git init --bare
git-update-server-info # If planning to serve via HTTP
exit

On local machine:

cd my_project
git init
git add *
git commit -m "My initial commit message"
git remote add origin git@example.com:my_project.git
git push origin master

Done!

Team members can now clone and track the remote repository using the following:

git clone git@example.com:my_project.git
cd my_project
git-track origin

Note: the ‘git-track’ command is a bash function we use to save manually editing the .git/config file (add the following to your ~/.bash_profile file as outlined by darkliquid):

function parse_git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1/'
}
function git-track {
  CURRENT_BRANCH=$(parse_git_branch)
  git-config branch.$CURRENT_BRANCH.remote $1
  git-config branch.$CURRENT_BRANCH.merge refs/heads/$CURRENT_BRANCH
}

h4. Bonus

To have your terminal prompt display what branch you are currently on in green, add the following to your ~/.bash_profile:

function parse_git_branch_and_add_brackets {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\ \[\1\]/'
}
PS1="\h:\W \u\[\033[0;32m\]\$(parse_git_branch_and_add_brackets) \[\033[0m\]\$ "

I generally make a point of not unit testing private methods however in some circumstance I find it necessary to do so. One example of this is when a class method is to be documented in the API of a library, only for use when declaring a descendent class (the Rails validates_* macros could be private for example).

Testing of private instance methods has already been documented by Jay Fields, however testing private class methods requires a little more work:

class Class
  def publicize_private_class_methods
    saved_instance_methods = (class << self; private_instance_methods.sort; end)
    saved_instance_methods.each { |method| public_class_method method }
    yield self
  ensure
    saved_instance_methods.each { |method| private_class_method method }
  end
end

This allows you to do the following:

class Foo
  class << self
    private
 
    def foo
      'bar'
    end
  end
end
 
Foo.publicize_private_class_methods do |klass|
  assert_equal 'bar', klass.foo
end

The same would work for protected methods by changing all instances of the word ‘private’ with ‘protected’.

All this could probably be merged into the original method by Jay, however I will leave that as an exercise for the reader.

In the years I have been working with Rails I have generally been happy to follow the conventions that it enforces. There is one that just doesn’t sit right with me and that is the decision to store .css files in a ‘stylesheets’ directory and .js files in a ‘javascripts’ directory as I prefer ‘css’ and ‘js’ directories (call me old fashioned).

Achieving this in Rails 2.2 involves changing a couple of constants. I may submit a patch with a config hook for this as it feels a little dirty changing the constants directly. Add the following lines to your environment.rb file.

ActionView::Helpers::AssetTagHelper::StylesheetAsset::DIRECTORY = 'css'.freeze
ActionView::Helpers::AssetTagHelper::JavaScriptAsset::DIRECTORY = 'js'.freeze

So, after switching from Subversion to Git approximately a month ago, how has it been?

Well, what can I say, all the hype is deserved. Git makes things like branching, merging and tagging something that I no longer have to think about.

At first I wasn’t completely sold on the idea of keeping multiple copies of entire repositories on multiple machines as I keep my Photoshop originals etc. all in the repositories and feared it would take forever for the initial checkout (clone in Git). I have actually found completely the opposite in that by having the entire repository on my development machine (whether it be my office or laptop machine), the time that I save switching branches i.e. not having to checkout another branch remotely etc. far outweighs the initial “pull” time which is in fact extremely fast.

This is a very boring post considering it’s the first in over a year but hey, I have to start somewhere.

Since upgrading to Leopard, even on clean installs, it decides to show system files such as /usr /bin /etc etc. To re-hide these files use the following:

sudo /Developer/Tools/SetFile -a V /bin

The -a means “set attributes” and the V means make in(V)isible (obviously!?). You will need developer tools installed from the Leopard disc for this to work.

h3. Why so long since the last post?

The reason for not posting in such a long time is that I was running on a broken Typo install for ages with no time to fix it. I have now moved to WordPress as it has grown up a little since I last used it. I will be porting the Lucid theme and adding features at some point, in the meantime the Typo version is still available as a download.

Call me a cynic, but posts like this one on the Surfin’ Safari blog worry me a little. Let me explain…

I don’t know if anyone remembers back to the days of Netscape 4 and Explorer 3.5? – It was a time of table based layouts and browser sniffing. Each browser had it’s own “feature” set and this resulted in hacks galore, for example Netscape had “Layers” but Explorer didn’t, Explorer had feature X but Netscape didn’t.

Along came Web Standards and the likes of Jeffrey Zeldman fighting for a standards based approach to web development. Over a decade on, it looks like were finally getting there as even Microsoft slowly start to get things right with IE7.

As cool as the CSS Transform stuff looks, I can’t help but think we’re stepping right back into 1995.

What does everyone else think?

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”:http://blog.jayfields.com/2007/09/rails-how-we-test.html using “UnitRecord”:http://unit-test-ar.rubyforge.org/.

You can grab our plugin to enable “UnitRecord”:http://unit-test-ar.rubyforge.org/ when using “Autotest”:http://rubyforge.org/projects/zentest below:

“http://svn.soniciq.com/public/rails/plugins/iq_autotest”: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”:http://soniciq.com. Head over to “43folders job board to view our ad”:http://jobs.43folders.com/job/6a5255713e8351a5eb2efef7805b7629/?d=1.

These are exiting times with projects like “Propel’r”:http://propelr.com 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”:http://jobs.43folders.com/job/6a5255713e8351a5eb2efef7805b7629/?d=1.

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”:http://clarkware.com/cgi/blosxom for his “Rcov rake task for Rails”:http://clarkware.com/cgi/blosxom/2007/01/05#RcovRakeTask which this task is based on.

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