Anglet Beach Rugby 2009

July 27, 2009

The morning of the big day

Originally uploaded by Wertster

The Leeds Winoes travelled to the amazing coastal venue of Anglet near Biarritz in the South of France this weekend to take part in one of the best beach-rugby events of the year. After an amazing effort we made it through to the second round before crashing out and retreating to the beer tent. What an unforgettable experience and what an amazingly well organised event. Can’t wait for next year.


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.

New Earswick Tag Rugby Tournement July 2009

July 14, 2009

winoes at York July 2009

Originally uploaded by Wertster

Our merry band of rugby-bandits descended onto the turf at our latest tag-rugby tournament in York on the 11th July, hosted by New Earswick RLFC. With a low turn-out we got to work and had a great time, winning out overall in what was a really good natured day. Hopefully we’ll get a bigger turn-out next year. Looks like our next stop is now the Winoes Tour to the Anglet Beach Rugby Festival in Biarritz on the 25th July, where we’ll joust with our French cousins in the shadow of what I hear is a well stocked beer tent.

The CI, TDD and OO Love Triangle

July 14, 2009

I would not describe myself as a purist in any aspect of my life, least of all my software engineering practices. I’ve been re-establishing myself as a coder after a long while in the more abstract realms of architecture and design, and on the return-path I’m seeing things in a somewhat different light, and I think it’s an interesting observation hence this post.

Object Orientation was an approach I previously adopted to partition my problem-space into a group of components – so I could start hacking, rather than putting on the ‘everything is an object and so is its mother’ spectacles. I never quite got my head around why colleagues and ‘real developers’ would sit for hours debating the 99th level of object decomposition and whether an object had to be so fine-grained it should actually contain no code?

My return journey to the world of software development has intersected with new (I say ‘new’ given I was a full-on hacker in the mid 90’s so this is new to me) and emerging trends around Continuous Integration and Test Driven Development and I have to say these intersections have made a huge impression on me to the extent that I’m now passionate about the benefit brought about by these techniques. Maybe I’m so pro-CI and pro-TDD because I lived through the appalling software engineering practices of the 80’s and early 90’s, or may be it’s just because it makes so…much…sense.

So to my point. Continuous Integration has a simple benefit. You know when your code-base has been tainted. The more frequently you get to know that the better. I’ll avoid quoting the scientists who waffle about cost exponentials for fixing defects today versus tomorrow blah. No – it just…makes….so….much….sense ! I didn’t need a PhD in chin rubbing to work that out.

Next Test-Driven Development. Right this one took time, just a little time to get my head around, even though I was convinced that CI was the way to go no questions asked. I found myself asking the stereotypical questions like “won’t I be 50% productive if I spend half my time writing tests for the code I am writing?”. Let me just pause while I give myself 10 lashes for being so narrow-minded. THWACK, THWACK, THWACK, THWACK, THWACK, THWACK, THWACK, THWACK, THWACK, THWACK…and one for luck THHHHHWACK!!  So it’s a natural inclination to feel like test-cases are just code that you’d traditionally throw into the code-base, but when you consider the fact that you’re actually building inherent certainty into the code-base at every step of the way the lightbulb goes on in a big way. When I sat back and appreciated that I wouldn’t have to run huge amounts of code to verify and exercise a small method I just changed it….just….makes….so…much….sense. All the regression testing scenarios I was carrying round in my head ! The lack of repeatability in my approach to testing !! The gradual feeling of dread that I’d become used-to, after deploying a stable version of code, in case I had to, god-forbid, change it at some point??! It all cries out for an inherent approach that means you lock-down every function you implement as you implement it – such that you can purge all that baggage from your poor little cranial-walnut. It….just….makes….so….much…sense. I was soon a TDD convert, but only at that point did it strike me like a bolt from the blue…finally my life made sense….finally I could truly embrace the love-triangle of CI->TDD->OO.

The effectiveness of my CI/TDD regime relied totally on the level of granularity I could descend to with my class definitions, and the simplification of each and every function to it’s thinnest possible form.  Real fundamental Object Orientation finally became the underpinning foundation – notice I place it in that underpinning role – as I’ve only now seen OO as an enabler for the ‘common-sense’ and ‘value-adding’ techniques of CI and TDD. I’m a little weird that way – but I found my way into rigorous OO not via the brain-washing from the chin-rubbing ranks of “my object is more objecty than yours” brigade, but instead through the simple realisation that I can squeeze ever more value from my CI/TDD framework if I force my test-cases into finer and finer levels of granularity (within reason of course, I aint lost my roots yet !! )

So there you have. CI drives me to TDD. TDD drives me to appreciate why OO should exist, NOT vice versa…

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 !