Supporting Multiple Versions of Ruby on OSX 10.6.7

April 25, 2011

I wanted a clean way of upgrading the default ruby 1.8.7 installation on my new Mac OSX 10.6.7 host, and couldn’t locate a decent explanation. As a result I’ve spent surprisingly little time unpicking the dependencies and getting my shiny new ruby 1.9.x installation sorted. Here’s how I achieved that. (Please note you need to have XCode installed if you plan to build the ruby installation from source.)

Firstly it’s important to understand the landscape when considering this upgrade. Firstly, the existing 1.8.x ruby installation exists in the /System/Library/Frameworks/Ruby.framework location. Beneath that root folder is a Versions folder. Versions contained another folder called 1.8 (referring to the version of ruby contained therein) and a symlink by the name of Current, which pointed to that 1.8 folder.

Decision 1: Seemed like a good idea to place all my future versions of ruby in version-aware subfolders in this …/Ruby.framework/Versions folder.

Next thing to understand is that all of the key commands relating to using the ruby framework (e.g. ruby, gem, irb, erb, …) live in the /usr/bin folder. Each of these commands are symlinks to executable files within the current ruby framework subtree. The convention here can be seen in this example:

/usr/bin/ruby -> /System/Library/Frameworks/Ruby.framework/Versions/Current/usr/bin/ruby

Next thing to understand is that all of the key commands relating to using the ruby framework (e.g. ruby, gem, irb, erb, …) live in the /usr/bin folder. Each of these commands are symlinks to executable files within the

Decision 2: If I correctly install all my subsequent versions of ruby into this same location then it should be possible for me to simply modify the Current symlink in the …/Ruby.framework/Versions folder to set the active ruby version I wish to use. All /usr/bin dependencies can simply resolve to the correct subfolder beneath the frameworks root.

Next I downloaded the latest source distribution from somewhere, in my case I used the 1.9.2 source from here ( After downloading and unpacking into a temporary folder, I then executed the following commands from the root of the ruby source folder structure:

  1. sudo mkdir /System/Frameworks/Library/Ruby.framework/Versions/1.9.2/usr to create the new version subtree root.
  2. ./configure –prefix=/System/Frameworks/Library/Ruby.framework/Versions/1.9.2/usr to instruct the make utility to use my new installation folder for the deployment of the newly compiled binaries.
  3. sudo make && make install to create my new subtree and binaries beneath my newly created target.
When all that is done, assuming it goes OK, you will have all the necessary ruby executables in the subfolders beneath …/1.9.2/usr location but your system will still be set to use the ‘Current’ version which in my case was the pre-installed 1.8.7 version.
Final thing to do is to re-link the …/Ruby.framework/Versions/Current link to the 1.9.2 folder. I simply executed the following from the …/Ruby.framework/Versions folder:
  1. sudo unlink Current
  2. sudo ln -s 1.9.2 Current
When I now run my ruby commands – they report the correct version of 1.9.2. When and if I decide to revert to another version I can simply modify this Current link, and that can be made even easier with some alias’s and other bash helpers.

Installing Metric_Fu on Centos/Red-Hat Linux

July 22, 2009

To gain the benefit of integrated code-quality analysis within my continuous integration process for my Ruby projects, I’ve been integrating the excellent Metric_Fu package by Jake Scruggs. I’ve now completed an installation on OS-X, CentOS and Red-Hat where I had some quirks to resolve on CentOS and RedHat. This post provides my view on the best install procedure I can offer.


First the underlying OS package pre-requisites…

sudo yum install libxml2           => v2.6.26-
sudo yum install libxml2-devel     => v2.6.26-2.1.2
sudo yum install libxslt           => v1.1.17-2
sudo yum install libxslt-devel     => v1.1.17-2
sudo yum install ImageMagick       => v6.2.8.0-3.el5.4(see note)
sudo yum install ImageMagick-devel => v6.2.8.0-3.el5.4

Note the version of the ImageMagick package I have installed. There is a version depenency here with the rmagick gem which is installed in the next section. As far as I can see, for this version of the ImageMagick package, you must install the v1.x gem. As such I installed the highest version of the gem v1.15.17 below the v2.x.x baseline. If you have later versions of this ImageMagick package then I believe you can avoid this particular issue.

The TrueType Fonts dependency…

The rmagick gem has an installation dependency on the the presence of a set of true-type fonts in the base OS installation. On both the CentOS and RedHat installs I have done, this issue has been present. So before we go ahead and install the gems, we need to rectify this issue.The dependency relates to the presence of the /usr/share/fonts/default/TrueType folder which needs to be created with the following steps. (Note – you don’t need to install these fonts if you already have TrueType fonts installed – in which case skip to the next section).

yum install rpm-build wget
rpm -ivh cabextract-1.2-1.i386.rpm 
rpmbuild -ba msttcorefonts-2.0-1.spec
rpm -ivh /usr/src/redhat/RPMS/noarch/msttcorefonts-2.0-1.noarch.rpm
cd /usr/share/fonts/default
ln -s /usr/share/fonts/msttcorefonts/ TrueType

Now the Gems…

Then install the gems:

sudo gem sources -a
sudo gem install jscruggs-metric_fu

Note at this point one of the installed depenencies, the ‘flog’ gem at v2.1.2, has an issue that will prevent it from running. I have explicitly modified the following file to get this to work:

vi /usr/local/lib/ruby/gems/1.8/gems/flog-2.1.2/bin/flog

Change the line: flogger.flog_files ARGV to flogger.flog ARGV and save the file. This is only a quick-n-dirty solution to get the flog integration to work within metric_fu.

sudo gem install reek
sudo gem install roodi
sudo gem install gruff
sudo gem install rmagick -v 1.15.17

When these gem installations complete you’re now ready to play with Metric_Fu. For more information on next steps refer to this article about some more version specific fixes or Jakes Metric_fu home.

Ruby Code Quality and Metric_Fu

July 9, 2009

I’ve been putting together a continuous integration framework for my Ruby projects and was very pleased to find the great work by Jake Scruggs ( ) by the name of Metric_Fu. On the whole this aggregation of tools covers all the key ‘quality’ bases and generates some elegant graphical reports that can be simply published alongside other build artifacts in CruiseControl.rb for example. On the whole the installation is very simple, but I hit some issues with the code and had to apply some class method overrides to get it to work.


My base environment is OSX 10.5.7, Ruby 1.8.6, Gem 1.3.3. I installed the gems jscruggs-metric_fu (1.1.1), rcov (, flog (2.1.2), flay (1.3.0), reek (1.1.3), roodi (1.4.0) and Saikuro (1.1.0). Following the instructions at I was complete in short order, and ran the rake task as per the example.

The first problem I hit was a method naming issue where the a Flog#flog_files method was being called which didn’t exist in the versions I was using. I ended up with a quick-n-dirty fix which involved amending the /gems/flog-2.1.2/bin/flog script to remove the call to flog_files, replacing it with the correct method name flog:

flogger = options
flogger.flog ARGV

Second problem I hit was some floating point and divide-by-zero issue in the MetricFu::Generator#round_to_tenths method. I don’t profess to understand the core issue here, but the value of ‘NaN’ was appearing in the calculation – so I added a ‘very’ primitve override to filter this condition (elegance is not my middle name I you hadn’t realised already):

module MetricFu
  class Generator
    def round_to_tenths(decimal)
      decimal=0.0 if decimal.to_s.eql?('NaN')
      (decimal.to_i * 10).round / 10.0

Next I hit an issue with rcov not returning any results into the dashboard? I checked this out and located an error in the rcov.txt file generated as part of the execution. This simply informed me that the rcov commandline generated within the metric_fu rcov generator class was incorrect. After a little experimentation I worked out that the –include-file parameter was the issue…so I again redefined the problematic class method in my Rakefile to remove this issue:

Module MetricFu
  class Rcov
    def emit
        FileUtils.rm_rf(MetricFu::Rcov.metric_directory, :verbose => false)
        test_files = FileList[*MetricFu.rcov[:test_files]].join(' ')
        rcov_opts = MetricFu.rcov[:rcov_opts].join(' ')
        output = ">> #{MetricFu::Rcov.metric_directory}/rcov.txt"
        #PROBLEM: `rcov --include-file #{test_files}  #{rcov_opts} #{output}`
        `rcov #{test_files}  #{rcov_opts} #{output}`
      rescue LoadError
        if RUBY_PLATFORM =~ /java/
          puts 'running in jruby - rcov tasks not available'
          puts 'sudo gem install rcov # if you want the rcov tasks'

Next I hit a problem when modifying my declared MetricFu::Configuration object to change the location of the outputs of the analysis, to reduce the pollution in my project folder hierarchy (yep…I probably do have some deeper issues). I had added the following lines to the sample provide by Jake: do |config|
  config.base_directory = ENV['CC_BUILD_ARTIFACTS'] || 'quality'
  config.scratch_directory = File.join(config.base_directory, 'scratch')
  config.output_directory = File.join(config.base_directory, 'output')
  config.data_directory = File.join(config.base_directory, '_data')

With this new folder structure I also had to add a tweek to the Saikuro configuration entry in the same sample, to make sure the Saikuro outputs are picked up by the report aggregator. Without this tweek I was just getting a blank Saikuro template page offered by Metric_Fu:

(Ignore the space between the colon and the ‘o’ – it’s giving me smilies for some reason)

config.saikuro  = { : output_directory => 
                              File.join(config.scratch_directory, 'saikuro'), 

This change caused a failure in the MetricFu::Graph#generate method – which on closer inspection appeared to be hardwired in expecting a depth of 3 folders in the locations specified for these outputs? So again I re-declared this class in my Rakefile to make the specific change necessary to support any level of nesting. This fixed the problem and my folder feng-shui returned to equilibrium…mmmmmmm.

Module MetricFu
  class Graph
    def generate
      puts "Generating graphs"
      Dir[File.join(MetricFu.data_directory, '*.yml')].sort.each do |metric_file|
        puts "Generating graphs for #{metric_file}"
        #PROBLEM: date = metric_file.split('/')[3].split('.')[0]
        date = metric_file.split('/').last.split('.')[0]
        metrics = YAML::load(
        self.clazz.each do |grapher|
          grapher.get_metrics(metrics, date)
      self.clazz.each do |grapher|

So my installation of metric_fu works perfectly now and I’m very impressed with the output it’s providing so long as I don’t dwell too much on the fact that it’s telling me my code quality is somewhere between criminal and insane !!!

I hope these notes may help others experiencing similar frustration in trying to get the install working…and again my thanks to Jake Scruggs for this piece of goodness.

Cheers all !

Bridlington Beach Rugby 2009

June 30, 2009

Post tournament Winoes

Originally uploaded by Wertster

Our veteran team of ex-ex players, affectionately known as the Leeds Winoes, made another showing at the Brid beach-tag tournament on the 27th June. We made a close 3rd place behind West Leeds (2nd) and Bridlington-A (1st) in a great competition. Next stop is our first ‘international’ in Biarritz, France on the 25th July when we take on the best of the European circuit. Might have recovered by then.

Validating XML with Schema in Ruby

October 10, 2008

I posted a long time back about my troubles in finding a way of performing schema validation in ruby (see Ruby and Xml Schema). At that time I was using REXML and only able to perform well-formedness checks based on basic structural integrity, but had no way to take an XSD and validate an instance document.

I’m pleased to say that there is a way to do this now, namely libxml-ruby. It’s available as a gem (gem install libxml-ruby) and the process is pretty simple:

  document = LibXML::XML::Document.file(@xml_filename)
  schema =
  result = document.validate_schema(schema) do |message,flag|
    puts message

I’ve found this to be a very neat piece of code for dealing with the kind of schema integrity checking I’m looking for, and as I blend this with a number of other java-based parses using the Ruby Java Bridge I get a pretty good, consistent perspective on validity.

Ruby Wrapper for WS-I Analyzer tools

August 19, 2008

I’ve been developing some scripting to enable me to assess the integrity of integration artifacts created across a range of development teams in large scale SOA integration programmes. One of the most basic forms of assessment is the WS-Interoperability (WS-I) analysis of WSDL, to identify any specific non-compliances at grass-roots. (I can hear the RESTian hordes tooling up to brow-beat me into submission as I type this….and YES I understand, YOU don’t like WSDL, nor do I, but they DO exist so I’m gonna analyse em ! Right – now that’s out of the way on with the WSDL baiting…).

There’s a set of java/c# tools out there from the clever folk over at WS-I ( which are already used informally within our organisation, and I’ve created a ruby-based wrapper for this. It’s not mature enough to be packaged as a Ruby Gem, and it does rely on an installation of the java tools in some folder on your machine – but the following ruby source does allow you to spin up objects in your Ruby code and kick it to analyse your WSDL artifacts without being exposed to java code. In line with my usual train-of-thought programming style and my few months of Ruby exposure, it’s not pretty but it works well enough to be parked for a while… Usage is pretty simple. The analyzer object can be initialised once and used thereafter to manage the analysis of many discrete WSDL resources. With each call to WSIAnalyser.analyze_wsdl() the first parameter is a file: or http: URI to a WSDL, and the second is a path/folder into which the outputs from this analysis will be placed. In any given WSDL the analyzer iterates through every <definitions/services> node, creating a report for each node. The outputs (in the output folder) are:

  1. A copy of the WSDL source
  2. A copy of the WS-I Tools configuration file generated by this script, one per <definitions/service> element in the source
  3. A WS-I analysis report generated by the underlying WS-I tool – one per <definitions/service> element in the source WSDL
a.analyze("", "c:/dev/wsdloutputs")
a.reports.each_pair do |r,s|
puts "WSDL [#{a.wsdl_uri}] Report [#{r}] Status [#{s}]"

The source:

WSI_ANALYZER_CONFIG_TEMPLAGE = %{<?xml version="1.0" encoding="UTF-8"?>
<wsi-analyzerConfig:configuration name="WS-I Basic Profile Analyzer Configuration" xmlns:wsi-analyzerConfig="">
<wsi-analyzerConfig:description />
<wsi-analyzerConfig:assertionResults type="all" messageEntry="true" failureMessage="true"/>
<wsi-analyzerConfig:reportFile replace="true" location="xxxxxxxx">
<wsi-analyzerConfig:addStyleSheet href="" type="text/xsl"/>
<wsi-analyzerConfig:testAssertionsFile />
<wsi-analyzerConfig:wsdlElement type="port" parentElementName="" namespace="" />
<wsi-analyzerConfig:wsdlURI />

#As we are modifying the path environment variable, we need to ensure that the correct delimiter is used

#This must be changed to point to the physical root of the wsi-installation
WSI_HOME_VAL = "c:/dev/wsi-test-tools"
WSI_JAVA_OPTS_VAL = " -Dorg.xml.sax.driver=org.apache.xerces.parsers.SAXParser"
WSI_TEST_ASSERTIONS_FILE = "#{WSI_HOME_VAL}/common/profiles/SSBP10_BP11_TAD.xml"
WSI_STYLESHEET_FILE = "#{WSI_HOME_VAL}/common/xsl/report.xsl"
WSI_EXECUTION_COMMAND = "#{WSI_JAVA_HOME_VAL}/bin/Analyzer.bat -config "


class WSIAnalyzer
VERSION = "1.0.0"

attr_reader :wsdl_uri
attr_reader :wsdl_name
attr_reader :wsdl_source
attr_reader :analyzer_config_uri
attr_reader :analyzer_config_source
attr_reader :wsdl_namespace
attr_reader :wsdl_service_name
attr_reader :wsdl_port_name
attr_reader :workspace
attr_reader :report_filename
attr_reader :wsi_approved
attr_reader :wsdl_service_declarations
attr_reader :reports
attr_reader :errors

def initialize
@log.level = Logger::DEBUG
#Check the installation location to ensure the wsi-test-tools are installed on the host
if not File.exists?(WSI_HOME_VAL)
@log.fatal("Unable to locate WSI-Test-Tools installation at [#{WSI_HOME_VAL}]")
return nil
#Ensure environment variables are in place
@log.warn("No WSI-Test-Tools environment variables present [#{WSI_HOME_TAG}]")
rescue => ex
@log.error("Unable to initialise WSIAnalyzer: Ex #{ex.message}\n"+ex.backtrace.join("\n"))
return nil

def analyze_wsdl(wsdl_uri, workspace)
@wsdl_name=segments.first"Analyzing WSDL[#{@wsdl_name}] from URI[#{@wsdl_uri}] in workspace [#{@workspace}]")
#obtain the wsdl source
#obtain key wsdl attributes required to create ws-i configuration
#There may be more than one pass to make here so iterate
@wsdl_service_declarations.each_pair do |svc, port|
#create dynamic ws-i configuration"Excuting WS-I analysis for WSDL [#{@wsdl_name}] Service[#{svc}] Port[#{port}]")
create_dynamic_wsi_config(svc, port)
#execute the analysis
rescue => ex
@log.error("Unable to analyze WSDL [#{@wsdl_uri}]: Ex #{ex.message}\n"+ex.backtrace.join("\n"))
return false


def execute_wsi_analyzer
#Now kick the external WSI script to generate a report
commandline="#{WSI_EXECUTION_COMMAND} #{@analyzer_config_uri}""Execution WS-I Analyzer with shell [#{commandline}]")
#Verify if a report has been created
if(not File.exists?(@report_filename))
@log.warn("No report file [#{@report_filename}] produced by WS-I Analyzer")
else"Scanning for WS-I summary status...")
if dom.elements["report/summary"].nil?
if not dom.elements["report/analyzerFailure"].nil?
#A failure code has been identified in the report doccument
@log.warn("WSDL [#{@wsdl_name}] WS-I Failure Report [#{msg}] ")
@errors << msg
#Summary status is passed (not sure if summary can be failed/error
end"WS-I Approval Status [#{status}] for WSDL [#{@wsdl_uri}]")
#Add a report summary to the list of reports
rescue => ex
#Unable to acquire status - treat report as invalid/missing
@log.error("Unable to complete WS-I Analysis of [#{@wsdl_name}]: Ex #{ex.message}\n"+ex.backtrace.join("\n"))

def create_dynamic_wsi_config(svc, port)
#cdom.elements.each do |e|
# puts e.inspect
#end"WS-I configured to report to [#{@report_filename}]")
#Now write the configuration file into the workspace of the artifact
open("#{@analyzer_config_uri}",'w'){ |f| f << cdom.to_s}"Written dynamic WS-I config into [#{@analyzer_config_uri}]")
rescue => ex
@log.error("Unable to generate dynamic config for WS-I: Ex #{ex.message}\n"+ex.backtrace.join("\n"))

def extract_target_elements
#Need the servicename, portname and other stuff from the wsdl
#Get the DEFINITIONS/SERVICE/ attribute
#TODO: Need to ensure I can handle a WSDL with multiple SERVICE/PORT combinations
dom.elements.each("definitions/service") do |servicenode|
#@wsdl_port_name=dom.elements["definitions/service/port"].attributes["name"]"Extracted Namespace[#{@wsdl_namespace}] Services[#{@wsdl_service_declarations.inspect}] from WSDL")
if @wsdl_service_declarations.size<1
raise "No Service elements [definitions/service] detected in WSDL [#{@wsdl_name}]"
rescue => ex
@log.error("Unable to extract WSDL markers for WS-I: Ex #{ex.message}\n"+ex.backtrace.join("\n"))

def acquire_wsdl
@wsdl_source = open(@wsdl_uri).read "Acquired WSDL [#{@wsdl_uri}] [#{@wsdl_source.length}] bytes of WSDL"
rescue => ex
@log.error("Unable to acquire WSDL [#{@wsdl_uri}]: Ex #{ex.message}\n"+ex.backtrace.join("\n"))

def configure_environment

#display WSI environment variables
unless ENV["OS"].nil?
unless ENV["OS"].downcase.index("windows").nil?
#Now add the path segments
WSIClasspath.each do |val|

Powered by Qumana

Ruby and XML Schema…??

December 18, 2007

So there I was looking for the REXML::Document.validate_with_xsd() routine, persuading myself that it must be there somewhere, when suddenly I came to the realisation that it wasn’t ! Eh?!

I then happened upon numerous blogs and chat threads clearly explaining why the collective conscience of ‘Ruby’ had thus far deemed XML Schema unfit for inclusion in this ever expanding scripting language, because….well XSD is crap! Woo hoo I’m glad that was settled so convincingly !

Excellent I thought, if only I were working in an idealogical vacuum where XML Schema had been out-lawed years ago, but sadly no, the primary currency of integration in my world is XML declared primarily with XSD and supporting semantic information. I might not ‘like’ it, but it’s there….so I need to exploit it to avoid reinventing it….don’t I ? Or else what did I miss?

I noted with interest the justification that to effectively use XSD within Ruby, and make sense of a document validator revolving around schema, I’d have to write just as much reactive code as I would have to do if I just coded the document-specific validation routines by hand. Hmmm…not sure….I think ‘I’ would write a lot MORE code if I attempted to do that…than say the seasoned hackers who’re making such assertions with their zen-like-one-ness with the syntax.

REXML gives a structural integrity validation in a single line of code:

But whilst this gives me a warm feeling that I’m not parsing an alien binary artefact, it doesn’t give me much of an insight in terms of whether my structurally intact XML document actually manifests any of the rules/constraints laid out in the existing XSD’s that my organisation uses to declare at least some apsects of the XML validation logic.  So why not just add an additional routine to provide a yes/no – ahead of all the deep and meaningful reasons as to which constraint has got the n-th degree of infringement….? So what would be the problem in offering another root level operation such as:


I know there are answers – such as ‘well extend REXML yourself and submit it!’ or ‘use another language such as..err…Java!’, so no points for phoning in with those, but I’m just perplexed that such a mainstream component as XML Schema, even at it’s most basic level, has been forceably ejected by the Ruby community thus far…

I emphasise I don’t see XML Schema as a shining light of pragmatism, but nor do I see the value in completely ignoring one of the primary currencies in a mature integration lanscape…