I’ve been playing around with Spree for a couple of weeks and ran into a slightly confusing issue wrt. using a non-US Dollar currency, in my case British Pounds.

At the time of this writing, using Rails 3.1.x and Spree 0.70, the following steps will enable a ‘£’ (a pound sterling) sign to be displayed.

Add the I18n gem to your Gemfile and run bundle install:

gem 'rails-i18n'

Open a shell and cd into the config/locales folder of your Spree/Rails project. Download the British locale file:

wget https://raw.github.com/svenfuchs/rails-i18n/master/rails/locale/en-GB.yml

You’ll also need copy the contents of Spree’s British I18n file into the bottom of of your config/locales/en-GB.yml file.

Edit your config/application.rb and set your default locale to ‘British’:

config.i18n.default_locale = :"en-GB"

Create a new file in config/locales/en-GB_numbers.yml with the following contents:

---
en-GB:
number:
currency:
format:
format: "%u%n"
unit: "£"
precision: 2
separator: '.'
delimiter: ','

Spree uses the above file to set the currency settings. Be aware that Spree is currently a single currency application.

Following on from previous post on installing MongoDB 1.8.1, here are similar steps to getting Redis 2.2.4 running on Ubuntu 10.10 using an init script. The setup is intended to be used on developer desktop/laptop rather than production infrastructure.

As ever, first download and unzip Redis from here.

cd /tmp
wget http://redis.googlecode.com/files/redis-2.2.4.tar.gz
tar -zxf redis-2.2.4.tar.gz
cd redis-2.2.4
make
sudo make install

Your Redis binaries should now be located in /usr/local/bin.

To get an init script and Redis config working cleanly with this setup, download my init and config files from my Github ‘dotfiles’ repo. My init script is pretty standard. However my redis.conf sets Redis up with 1Gb of virtual memory and 20Gb of swap space – intended for general development purposes.

wget https://github.com/ijonas/dotfiles/raw/master/etc/init.d/redis-server
wget https://github.com/ijonas/dotfiles/raw/master/etc/redis.conf
sudo mv redis-server /etc/init.d/redis-server
sudo chmod +x /etc/init.d/redis-server
sudo mv redis.conf /etc/redis.conf

Before you can fire up the Redis server for the first time, you’ll need add a redis user and prep a data and logging folder.

sudo mkdir -p /var/lib/redis
sudo mkdir -p /var/log/redis
sudo useradd --system --home-dir /var/lib/redis redis
sudo chown redis.redis /var/lib/redis
sudo chown redis.redis /var/log/redis

Also, you need to activate your Redis services init script by adding it to your system’s run-level configuration. That way the service will startup during the boot sequence and stop nicely during the OS’ shutdown procedure.

sudo update-rc.d redis-server defaults

You’re now ready to launch Redis server with

sudo /etc/init.d/redis-server start

Good luck!

Installing MongoDB 1.8.1, in my case as a developer database, is easy. This blog post just itemises all the steps so that you can pretty much blindly follow along. I’ll probably use these steps myself as I seem to be doing this regurlarly

Download the 64bit Linux binaries from here and unzip the contents to /usr/local.

cd /tmp
wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-1.8.1.tgz
sudo tar -zxf /tmp/mongodb-linux-x86_64-1.8.1.tgz -C /usr/local

Setup some symbolic links.

sudo ln -s /usr/local/mongodb-linux-x86_64-1.8.1 /usr/local/mongodb
sudo ln -s /usr/local/mongodb/bin/bsondump /usr/local/bin/bsondump
sudo ln -s /usr/local/mongodb/bin/mongo /usr/local/bin/mongo
sudo ln -s /usr/local/mongodb/bin/mongod /usr/local/bin/mongod
sudo ln -s /usr/local/mongodb/bin/mongodump /usr/local/bin/mongodump
sudo ln -s /usr/local/mongodb/bin/mongoexport /usr/local/bin/mongoexport
sudo ln -s /usr/local/mongodb/bin/mongofiles /usr/local/bin/mongofiles
sudo ln -s /usr/local/mongodb/bin/mongoimport /usr/local/bin/mongoimport
sudo ln -s /usr/local/mongodb/bin/mongorestore /usr/local/bin/mongorestore
sudo ln -s /usr/local/mongodb/bin/mongos /usr/local/bin/mongos
sudo ln -s /usr/local/mongodb/bin/mongosniff /usr/local/bin/mongosniff
sudo ln -s /usr/local/mongodb/bin/mongostat /usr/local/bin/mongostat

The first “ln -s” above sets up a handy symbolic link between the versioned mongodb folder and its unversioned counterpart. When 10Gen release updates, say version 1.8.2, all you need to do is download, unzip, and link the ’1.8.2 mongodb folder’ to the unversioned folder and ‘hey presto’ everything should just work.

To get an init script working cleanly with this setup, download mine from my Github ‘dotfiles’ repo. Please note – my init script enables journaling and the REST interface (on line 51).

wget https://github.com/ijonas/dotfiles/raw/master/etc/init.d/mongod
sudo mv mongod /etc/init.d/mongod
sudo chmod +x /etc/init.d/mongod

You’ll need to add a mongodb user and prep some folders

sudo useradd mongodb
sudo mkdir -p /var/lib/mongodb
sudo mkdir -p /var/log/mongodb
sudo chown mongodb.mongodb /var/lib/mongodb
sudo chown mongodb.mongodb /var/log/mongodb

Also, you need to activate your MongoDB service’s init script by adding it to your system’s run-level configuration. That way the service will startup during the boot sequence and stop nicely during the OS’ shutdown procedure.

sudo update-rc.d mongod defaults

Lastly to launch MongoDB

/etc/init.d/mongod start

Good luck!

UPDATE: Since April 6 Ubuntu now has prefabbed packages containing MongoDB 1.8.1, maintained by 10Gen. See the instruction below.

I develop on numerous systems every day, specifically a MacBook Pro running Snow Leopard, a Dell laptop running a Ubuntu VM and a shedload of cloud-based Ubuntu servers. I want to be able to develop across all those systems using the same setup.

Now for years I’ve been a TextMate junkie. Its an amazing editor, ’nuff said, but it only runs on one of the systems I work on daily and I’m done with Java-based IDEs. I know that there’s enough people out there getting similar productivity out of a highly-customised Vim-based setup.  So today I decided to switch to Vim.

I want the same keystroke-commands, shortcuts, aliases, and environment wherever I might wander. I want to log on to a new machine and configure my environment on the new machine by typing one or two commands at the shell prompt.

Here’s how its done.

Github Magic

The configuration settings are tracked and shared via a public repo on Github. Here’s my ijonas/dotfiles repo. So whenever I get access to a new system I simply type the following:

git clone http://github.com/ijonas/dotfiles.git

which will create a dotfiles folder in the home directory.

The dotfiles folder contains copies of all the important ‘shell’ rc-files that setup paths, aliases, and environment variables:

The dotfiles folder contains

• bashrc – which is pretty skinny and only loads the contents of the three files in the bash/ subfolder.
• gemrc – contains  some defaults for the Ruby gem package manager.
• gvimrc – contains graphical vim defaults, currently empty.
• rvmrc – defaults for the Ruby VM manager.
• ssh/config – host config for ssh, shortening those pesky ec2 hostnames etc.
• vim – the plugins folder for Vim.
• vimrc – default properties used by Vim, GVim, and MacVim alike.

So the trick now

is to have the system recognise these files and use their contents. Here’s how from your $HOME folder:

ln -s $HOME/dotfiles/bashrc $HOME/.bashrc

ln -s $HOME/dotfiles/gemrc $HOME/.gemrc

ln -s $HOME/dotfiles/gvimrc $HOME/.gvimrc

ln -s $HOME/dotfiles/rvmrc $HOME/.rvmrc

ln -s $HOME/dotfiles/vimrc $HOME/.vimrc

ln -s $HOME/dotfiles/vim $HOME/.vim

ln -s $HOME/dotfiles/ssh/config $HOME/.ssh/config

So you see, simple… fetch a repo from Github, and create a whole bunch of symbolic links. So when you make changes on any of your systems you can push those changes to Github and pull them down to others. One caveat, you need to make the repo public, otherwise you’re going to have to copy your SSH keys all over the place.

Next stop: Vim !

Vanilla Vim is hard work. You need to customise it for your own nefarious needs. Install GVim on Linux and MacVim on SnowLeopard. I use Homebrew package manager on the Mac, and so should you. Installing MacVim is easy

brew install macvim

After installing MacVim, you’ll find it hard to find. Typing “macvim” on the shell prompt results in “command not found” messages. The best solution I found was to setup a bash function. Its a one-line found in my dotfiles/bash/aliases file and looks like this:

function mvim { /usr/local/Cellar/macvim/HEAD/MacVim.app/Contents/MacOS/Vim -g $*; }

This results in a “mvim” alias being available on the shell prompt, i.e. you can type ‘mvim README’ to edit a file in MacVim.
We’re almost done… Before you start customising Vim, you need to prepare your Vim environment in a similar Git-based fashion. In particular you need to install the pathogen plugin for Vim. You’re best best is to watch the “synchronizing plugins” vimcast and follow its guidelines.

Now go cherry pick from the other excellent screencasts available on Drew Neil’s excellent Vimcasts.org site.
Also: If I’ve missed anything out, please post a comment and I’ll expand on anything that needs expanding.

After having used Apache Builder for a week and extracted our Warbler-code into a bonafide extension, I’m sharing it with the community under the fetching name Barbler.

Barbler integrates itself between the build and packaging stages of the Apache Builder lifecycle and makes calls into Warbler to automate WAR-file creation. Now Warbler does a really good job for packaging standalone Rails apps. Unfortunately I needed something more integrated into our application build process, that pulls in our Spring Framework-based Java code, Scala code, and Rails application and produces a single WAR-file containing all dependent libraries, Rails code, XML deployment descriptors and Java class files. Apache Builder does everything other than the Rails-packaging. Barbler steps to provide that missing step.

Create a barbler.rb file in your project folder, which also contains your buildfile and copy the following contents into it:

# Barbler
# is an Apache Builder extension to integrate the JRuby Warbler gem.
# For tips on how to use Barbler checkout http://www.denofubiquity.com/ruby/barbler/
#
# This code is licensed under the Apache License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0.txt)
# Please distribute Barbler code with this code intact.
# (c) Ijonas Kisselbach 2009

require 'warbler'

module Barbler
  include Extension

  first_time do
    # Define task not specific to any projet.
    desc 'Warbles Rails sourcecode tree into a staging folder'
    Project.local_task('warble' => 'build') { |name| "Warbling #{name}" }
  end

  before_define do |project|
    project.task('warble'=>project.task('build'))
    project.group ||= project.parent && project.parent.group || project.name
    project.version ||= project.parent && project.parent.version
  end

  # To use this method in your project:
  #   warble(:rails => path_to(:rails), :tasks => [:app, :public])
  def warble(*args)
    options = args.pop
    rails_path = options[:rails]
    warble_tasks = options[:tasks]

    # Define the warble task for this particular project.
    Rake::Task.define_task 'warble' do |task|
      # get all the important components from the Rails GUI into the staging directory
      puts "Warbling #{rails_path}"
      Dir.chdir(rails_path) do
        warble_cfg = eval(File.open("config/warble.rb") {|f| f.read})
        Warbler::Task.new(:war, warble_cfg)
        warble_tasks.each {|task| Rake::Task["war:#{task}"].invoke}
      end
    end
  end

end

class Buildr::Project
  include Barbler
end

Add the folllowing line to the top of your buildfile:

warble(:rails => path_to(:rails), :tasks => [:app, :public])

You can then define your warble task using the following line

warble(:rails => path_to(:rails), :tasks => [:app, :public])

whereby the first parameter is a path string to where your Rails code is located. You may locate your code in src/main/rails in which case you’d use

warble(:rails => path_to(:source, :main, :rails), :tasks => [:app, :public])

The second parameter is the list of Warbler tasks that you’d like to have executed. See the Warbler documentation for more help, or check out the Warbler source code – it’s very readable.

At Vamosa we’re big fans of the Java Virtual Machine. It allows us to use the right tool for the job and deliver a high-quality consistent product for our end-users, whilst still getting the most of our developers. For years we were a .NET and Java shop. Our GUI developers would work in Visual Studio writing a C# application that via SOAP webservices would talk to the Java-backend. In June 2008 we decided to abandon our .NET Desktop GUI and redevelop and expand its functionality, delivered to the end-user’s browser using HTML+CSS+JavaScript from our Java-backend.

We spend 7months hacking away trying to get Google Web Toolkit to behave before abandoning ship a month ago and switching to Rails. We already had some success building a MRI-based RubyOnRails application called Vamosa Check and Fix. Our GUI developer pool was loving the ease of web development that comes with Rails, and really hated the total lack of productivity from GWT (worthy of a separate post).

Meanwhile I was experimenting with Scala – IMO the Java language reinvented for the 21st century. So there we were steaming ahead with JRubyOnRails, old-skool Java Spring-based code, and sexy-new Scala code. Three languages, one set of JVM byte code. So how do you build and package all this code ???

Your options are:

• Apache Maven – horrible for legacy projects that don’t build according to Maven doctrine.
• Apache Ant + Ivy – might be an option to you.
• Apache Buildr – JRuby-based build system

For us, Apache Buildr had the best fit because its a DSL based-on Rake, which happily runs on JRuby. It provided the dependency management that kept us coming back to Maven (and quickly running away again). It’s JRuby/Rake-based allowing for tight integration with Warbler, the JRubyOnRails WAR-packaging gem. And lastly there’s not a shred of XML in sight. Its a DSL, so the buildfile has a nice declarative feel to it, yet can be modified quickly using some standard Ruby-syntax to provide branching and looping. All the other build systems use XML, and then try and retrofit branching and looping, eg. using elements.

Today we have all our source code in the following folder structure:

project
src
|-- main
|   |-- java
|   |-- resources
|   |-- scala
|   `-- webapp
`-- test
|-- java
|-- resources
`-- scala

rails
|-- app
|-- config
|-- db
|-- doc
|-- lib
|-- log
|-- nbproject
|-- public
|-- script
|-- test
|-- tmp
`-- vendor

and our Apache Buildr buildfile in the root of the project tree looks like this:

require 'buildr'
require 'buildr/scala'
require 'rubygems'
require 'warbler'

# define the version of the Vamosa product
VERSION_NUMBER = '3.0.0'

# define repositories from which artifacts can be downloaded
repositories.remote << 'http://www.ibiblio.org/maven2/'
repositories.remote << 'http://scala-tools.org/repo-releases'  # define artifacts that are not available from remote repositories  artifact("javax.jms:jms:jar:1.1").from(file("libs/javax.jms.jar"))  # define the artifacts that the project depends on  SCALA         = group('scala-library', 'scala-compiler', 'axiom-dom', :under=>'org.scala-lang', :version=>'2.7.5')
SCALATEST     = [ 'org.scala-tools.testing:specs:jar:1.5.0','org.scalatest:scalatest:jar:0.9.5']
XUNIT         = ["junit:junit:jar:4.4", "org.dbunit:dbunit:jar:2.2.3", "org.mockito:mockito-all:jar:1.7" ]
JDBC_DRIVERS  = ["mysql:mysql-connector-java:jar:5.1.6"]
HIBERNATE     = [ "org.hibernate:hibernate-core:jar:3.3.2.GA",
  "org.hibernate:hibernate-annotations:jar:3.4.0.GA",
  "org.hibernate:hibernate-commons-annotations:jar:3.3.0.ga",
  "org.hibernate:hibernate-search:jar:3.1.0.GA",
  "org.hibernate:hibernate-ehcache:jar:3.3.2.GA",
  "org.hibernate:jtidy-r8:jar:20060801",
  'c3p0:c3p0:jar:0.9.1.2',
  'commons-collections:commons-collections:jar:3.2.1',
  'commons-lang:commons-lang:jar:2.4',
  'net.sf.ehcache:ehcache:jar:1.6.2',
'javax.persistence:persistence-api:jar:1.0']
# DELETED FURTHER ARTIFACTS FOR SAKE OF BREVITY...

# now lets do some work
platforms = ["mysql", "oracle", "mssql", "db2"]
platform = "mysql"
desc 'Enterprise Content Governance Platform'
define 'ContentMigrator' do
  project.version = VERSION_NUMBER
  project.group = 'com.vamosa'
  manifest['Copyright'] = 'Vamosa Ltd. (C) 2003-2009'
  compile.options.target = '1.5'

  compile.with HIBERNATE, SPRING, COMMONS, LOGGING, CONTENT_PARSER, QUARTZ, J2EE_API, SCRIPTING, SOAP, JFREE_CHART, JAVASSIST, LUCENE, XALAN
  test.with XUNIT, SCALATEST
  test.using :scalatest

  # get all the important components from the Rails GUI into the staging directory
  Dir.chdir("rails") do
    puts "Changed current directory to: #{Dir.pwd}"
    warble_cfg = eval(File.open("config/warble.rb") {|f| f.read})
    Warbler::Task.new(:war, warble_cfg)
    Rake::Task['war:app'].invoke
    Rake::Task['war:public'].invoke
  end
  puts "Changed current directory to: #{Dir.pwd}"

  # package it up
  package(:war, :file => _("target/#{id}-#{VERSION_NUMBER}-#{platform}.war")).tap do |task|
    task.include 'war/*'
    task.include "src/main/resources/#{platform}.session-factory.xml", :as=>'WEB-INF/session-factory.xml'
    task.include 'src/main/resources/jboss.jms-context.xml', :as=>'WEB-INF/jms-context.xml'
  end
end

The key things we like about this setup are:

1. Easily handling dependency artifacts like the Sun API jars locally. For example we store javax.jms.jar in our Git source repo, in the projects libs/ folder and then point to it using artifact(“javax.jms:jms:jar:1.1″).from(file(“libs/javax.jms.jar”)).
2. Integrate Warbler tasks and cherry-pick the ones you want to run, such as in our case just war:app & war:public but e.g. not war:xml because our web.xml is stored in src/main/webapp/WEB-INF instead.
3. Its Ruby so we can use loops & branching such as:

%w(mssql mysql oracle db2).each do |platform|
  package(:war, :file => _("target/#{id}-#{VERSION_NUMBER}-#{platform}.war")).tap do |task|
    task.include 'war/*'
    task.include "src/main/resources/#{platform}.session-factory.xml", :as=>'WEB-INF/session-factory.xml'
    task.include 'src/main/resources/jboss.jms-context.xml', :as=>'WEB-INF/jms-context.xml'
  end
end

Apache Buildr isn’t perfect. There are still some weird annoyances around resolving transitive dependencies, i.e. when hibernate.jar in turn depends on commons-logging.jar. But if you find yourself missing commons-logging.jar its easily added.
If something doesn’t work they way you think it ought to, you can easily dig into Buildr’s very readable Ruby code, something I couldn’t do with either Maven or Ant, and either customise it or find a quick workaround. You don’t have this black-box barrier between your buildscript and its output.

UPDATE: A nicer way of integrating Warbler and Buildr can be achieved using my Buildr extension, Barbler.

Two technologies are currently capturing my imagination, JRuby and Terracotta. JRuby is simply for my purposes the most effective language to tackle most of my computing challenges. Terracotta allows me to take those problems and solve them on large clusters of cheap servers in clouds such as those provided by Amazon EC2.

Getting started with JRuby+Terracotta requires a bit of trial and error as its not as well documented as good old Java+Terracotta. The only post you’re likely to find is one by Jonas Boner (see below). During subsequent revisions of both Terracotta as well as JRuby, the example had stopped working. These files bring that example update to date for JRuby 1.3.1 and Terracotta 3.0.1.

You can download the revised source code from my github account. You will need installs of both JRuby and Terracotta with JRUBY_HOME and TC_HOME pointing to the base folders of both products respectively, e.g.

export JRUBY_HOME=$HOME/java/jruby-1.3.1
export TC_HOME=$HOME/java/terracotta-3.0.1

Once these environment variables have been setup you can start a Terracotta server, followed launching multiple clients by typing:

./chat.sh

Background

The key to fixing the example was fixing the java.lang.NoClassDefFoundError: com/tc/object/event/DmiManager, caused by the references to com.tc.object.bytecode.Manager in the terracotta.rb file:

WRITE_LOCK = com.tc.object.bytecode.Manager::LOCK_TYPE_WRITE
READ_LOCK = com.tc.object.bytecode.Manager::LOCK_TYPE_READ
CONCURRENT_LOCK = com.tc.object.bytecode.Manager::LOCK_TYPE_CONCURRENT

Replacing the above fragment with:

WRITE_LOCK = 2
READ_LOCK = 1
CONCURRENT_LOCK = 4

and the whole example springs to life. My next problem to solve is that of Rubifying the Workmanager examples from chapter 11 of the “Definitive Guide to Terracotta” book.

Useful Links

• Clustering JRuby with Terracotta
• Incoming Revolution: Clojure + Terracotta
• My github pages

Tech Meetup is coming to Glasgow on April 22nd.

There are a ton of events for entrepreneurs to meet investors and bankers and VC’s but let’s face it, we’re tech, so let’s talk about tech. No name badges, no business models, just the growth of our eco-system and the advance of our tech – be it web apps, software, mobile apps, hardware, games… There’s an overlap across many of these and it’s always interesting to hear what people are hacking together, know about or have worked on before.

TechMeetup is just that – a space for everyone to meet up, talk about some of the cool stuff we’re doing, or get help on our projects from others.  It’s been running in Edinburgh for several months, with a good turn out, nice folks and great speakers – held together with the magic of pizza and beer.

On the 22nd April, Tech Meetup Glasgow will start and it’d be great to have you along.  Three excellent speakers are lined up, covering a variety of topics – from running a ticketing startup, to an introduction to developing for Android. Kick-off is at 7pm in Room M329 of the James Weir building on Stratchlyde University’s campus.

With your help and feedback, we are going to work hard to make this functional for everyone around us – a monthly event to allow you to share news, demo the technologies and projects that excite you, meet people with complimentary skillsets that may want to help out, and generally get to know others in the tech community.

So if that sounds good to you, be great to see you there.  Bring yourself, your experiences and your opinions with you.

Sam, Ijonas & Heidi.

Lastly, visit our site http://www.techmeetup.co.uk for a backgrounder on TechMeetup including past talks.

Amazon’s EC2 is rightly so the best thing since sliced bread. All of our hosted services at Vamosa run off EC2. Getting our Ubuntu instances provisioned these days is easily achieved using Capistrano, but when we were still get familiar with ‘cap’ it wasn’t always the case.

Amazon EC2 uses private/public keys files for root user authentication but you want to use those credentials as infrequently as possible. As RubyOnRails users, we are used to setting up a deploy user which we use to run Apache 2 and Phusion Passenger under. We use that same deploy user to connect to our github repositories and pull in code updates. All pretty much standard stuff.

When we using off-the-shelf Ubuntu 8.0.4 AMIs we couldn’t find any nice Capistrano recipes to setup that initial deploy user and enabling key-based login to that deploy user using our own personal keys.

The following recipe does just that:

  desc "uploads id_rsa.pub to the EC2 instance's deploy users authorized_keys2 file"
  task :bootstrap_deploy_user do
    system "ssh -i #{aws_private_key_path} root@#{domain} "groupadd admin""
    system "ssh -i #{aws_private_key_path} root@#{domain} "useradd -d /home/#{user} -s /bin/bash -m #{user}""
    system "ssh -i #{aws_private_key_path} root@#{domain} "echo #{user}:#{password} | chpasswd""
    system "ssh -i #{aws_private_key_path} root@#{domain} "usermod -a -G admin deploy""
    system "ssh -i #{aws_private_key_path} root@#{domain} "mkdir /home/#{user}/.ssh""
    for key in ssh_options[:keys]
      system "cat  #{key}.pub | ssh -i #{aws_private_key_path} root@#{domain} "cat >> /home/#{user}/.ssh/authorized_keys2""
    end
    system "ssh -i #{aws_private_key_path} root@#{domain} "chown -R #{user}:#{user} /home/#{user}/.ssh""
    system "scp -i #{aws_private_key_path} config/deploy_sudoers root@#{domain}:/etc/sudoers"
  end

You’ll need to setup Capistrano variables as you can see to make this work. My .caprc file contains the following definition:

set :aws_private_key_path, "/Users/ijonas/.ec2/ec2keypair.pem"

Our config/deploy.rb contains the following variables:

set :use_sudo, false
set :user, 'deploy'
set :password, 'xxxxx'
set :application, "yyyyy.vamosa.com"
set :domain, "yyyyy.vamosa.com"
set :deploy_to, "/var/www/apps/#{application}"

The approach is a little bit ‘hackish’ but it works for EC2, and keeps your Capistrano setup as close as possible to the best-practice.