Multiple Versions of Ruby On Ubuntu

This post is from a time before RVM or rbenv you should check out those instead..

With Ruby 1.9 out there's the obvious possiblitity some people will want to run multiple versions of Ruby so I thought I'd share this.

My goal is to have the Ubuntu Ruby packages installed along side the most current releases of 1.8 and 1.9

First I'll install using apt to create my default ruby install.

$> sudo apt-get install ruby irb ri rdoc libruby-extras rubygems ruby1.8-dev
$> sudo gem install rake

Next I'll install the most current release packages of 1.8 and 1.9 in to /opt/ruby1.8.6 and /opt/ruby1.9.0 respectively.

Before doing that I'll make sure I have all the necessary build dependencies for both packages

$> sudo apt-get build-dep ruby1.8 ruby1.9

Next I downloaded both packages into a working directory and decompress them

$>mkdir temp; cd temp
$>wget ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.6-p111.tar.gz
$>tar -xvzf ruby-1.8.6-p111.tar.gz
$>wget ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.0-0.tar.gz
$>tar -xvzf ruby-1.9.0-0.tar.gz

Next I build each of the packages.

$> cd ruby-1.8*
$> ./configure --prefix=/opt/ruby1.8 --program-suffix=1.8.6
$> sudo make && make install
$> cd ../ruby-1.9*
$> ./configure --prefix=/opt/ruby1.9 --program-suffix=1.9.0
$> sudo make && make install

Ruby 1.8 doesn't have built in support for gems like Ruby 1.9 so we'll have to install it.

$> wget http://rubyforge.org/frs/download.php/29548/rubygems-1.0.1.tgz
$> tar -xvzf rubygems-1.0.1.tgz
$> cd rubygems*
$> sudo /opt/ruby1.8.6/bin/ruby1.8.6 setup.rb

Notice that I specified the entire path to the ruby executable while installing RubyGems for 1.8.6

The next thing I do is create some symbolic links to make life a little bit easier.

$> sudo ln -s /opt/ruby1.8.6/bin/* /usr/local/bin
$> sudo ln -s /opt/ruby1.9.0/bin/* /usr/local/bin

Now test things a bit to make sure everything makes sense

$> which ruby
# /usr/bin/ruby
$> gem env
# ....
# GEM PATH: /var/lib/gems/1.8
# ....

$> which ruby1.8.6
# /usr/local/bin/ruby1.8.6
$> gem1.8.6 env
# ....
# GEM PATH: /opt/ruby1.8.6/lib/ruby/gems/1.8
# ....

$> which ruby1.9.0
# /usr/local/bin/ruby1.9.0
$> gem1.9.0 env
# ....
# GEM PATH: /opt/ruby1.9.0/lib/ruby/gems/1.8
# ....

A couple of things to watch out for:

• Make sure you don't have any RubyGems environment variables set. They're not needed for any of this and most likley will mess something up.
• Don't install any gems until after you create your symbolic links or the executable commands may clobber each other.
• You have to specify the full path to an executable gem because they don't play nicely with program suffixes. So for example '/opt/ruby1.8.6/bin/rake' will do what you expect but just typing 'rake' may not.

One last little tidbit. I'm not sure if the Ubuntu RubyGems packages deal with fixing up the $PATH yet? Regardless the fix is easy; add this little bit of code to the bottom of your ~/.bashrc file

if [ -d /var/lib/gems/1.8/bin ]; then
PATH=/var/lib/gems/1.8/bin:"${PATH}"
fi
export PATH

Customizing Debian Packages

Debian's packaging system makes it really easy to modify packages if you want to. In this little howto I modify ffmpeg to add MP3 support but the process can easily be adapted to any package.

First create a work directory and drop down into it. This is just to make cleanup easy.

$> mkdir temp; cd temp

Then make sure the ffmpeg build dependencies are installed

$> sudo apt-get build-dep ffmpeg

Then download the source package

$> apt-get source ffmpeg

Then install the extra (codec) libraries we're adding support for

$> sudo apt-get install liblame-dev libfaad2-dev libfaac-dev libxvidcore4-dev

Then drop down into the ffmpeg source directory

$> cd ffmpeg*

Now you will have to edit the first line of the the debian/changelog and modify the package version. If you don't system updates will want to 'replace' your modified package. The first line should look something like this:

ffmpeg (3:0.cvs20070307-5ubuntu4) gutsy; urgency=low

. You will want append something at the end of the part in parentheses. In my case I use:

ffmpeg (3:0.cvs20070307-5ubuntu4-mg1) gutsy; urgency=low

It's my initials followed by a revision number.

Once you've modified the change log you can build the package but before we do we set an environment variable used by the build scripts that indicates we want the 'risky' libraries included.

$> DEB_BUILD_OPTIONS=risky && fakeroot debian/rules binary

Now we just need to install the packages. The packages were placed up one directory during the build process so we just move up and install.

$> cd .. && sudo dpkg -i *.deb

Now we just clean up after ourselves

$> cd .. && rm -rf temp

The Generational Divide in Copyright Morality

There's an interesting (but not surprising) article in the New York Times about differences in perspective between the coming generation and the current in regards to intellectual property.

This of course created plenty of conversation on Slashdot (most of it half baked) but still enough motivation to get me to post this....

It's simply impossible to prevent sharing of media. I mean literally impossible! There's nothing you can do to stop it (unless you have a dooms day device in your garage?).

All the effort spent trying to stop it is literally wasted!

It seemed to me from both the NYT article and Slashdot comments people felt these kids should feel guilty, like they're doing something wrong? The reality is these kids realize our outdated views on Copyright have NO (you read that right 'NO' ) value in today's world.

They understand that we're all better off when information is shared freely and they also understand there's no practical way to differentiate media from other types of information. They are correctly choosing to accept shared media as a consequence of free information exchange.

They also I'm sure realize the impact this will have on their futures. I'm sure they understand that the media industry is a service industry and that they will have to live off the work they do (not the work they've already done) in the future.

So even though everyone from the article and Slashdot seemed to imply these kids just don't get it. I think it's just the opposite. They are the ones that really do get it!

Ruby Syntax Highlighting On Blogger

It turns out that creating syntax highlighted source in blogger is not difficult even if it's not convenient

The first step is to find an application that can syntax highlight and convert your code to HTML. I choose to hack together a quick little script on top of the Syntax library (the code's below)

require 'rubygems'
require 'syntax/convertors/html'
convertor = Syntax::Convertors::HTML.for_syntax "ruby"
puts convertor.convert(File.read(ARGV[0]))

Now when ever you want to make a post just choose 'Edit Html' in the composer and insert the output from your formatter application.

Depending on on your formatter you may need to add it's CSS to your Blogger template.

A Caching Current User Method Call

Quite a while back when I first seen RailsCast Episode #1, I implemented a current_user method exactly as it's presented in the video. The problem with this method is that it assumes that the user_id session variable is always set, obviously this is not always the case.

This snippet addresses the problem

class ApplicationController < ActionController::Base
  def current_user
    session[:user_id] ? @current_user ||= User.find(session[:user_id]) : nil
  end
end

Sharing Code...

Edit: I've since changed my mind about this. See this post.

I was spending time refactoring some of the crufty code in KanbanOnRails and got stuck thinking about the best way for me to share code? Clearly Blogger is not it!

I think for the time being I'll just use a snippet service like http://snippets.dzone.com/

Bazaar Workflow Examples

I was poking around the Internet and found an excellent article describing various workflows using Bazaar (or any distributed VCS really) and thought it was worth sharing.

KanbanOnRails' Meta-Project

My current work related project is KanbanOnRails.

It's home page contains pretty much every thing you could want to know about the project but doesn't explain the meta-project at all. So I thought I'd do that here...

It turns out that I've stumbled into using a rather odd assortment of tools and services to manage this project, but it's working well, so I thought I'd share the recipe here.

I'm using Bazaar for revision control, Launchpad for project managment and Google Docs for most of the actual content.

There's really only two SCM tools out there that I would consider using right now; Bazaar and Git. I'm firmly sold on distributed SCM and from what I've seen so far these two have the brightest future.

I've decided to use Bazaar for this project and to try Git out on the next.

Distributed SCMs work best if you have some public web space available to share branches, with, mine's here.

I've generally preferred using Trac for project management in the past, it's a fabulous tool, but this time I wanted a third party host that could provide a permanent home for the project. That really only left me with one choice, Launchpad, which natively uses Bazaar. Currently none of the other project hosting services; SourceForge, RubyForge, Google Code, etc... support any form of distributed SCM.

I would of prefered a good reliable (free) public wiki for content hosting but wasn't immediately aware of one so I decided to use Google Docs. This is the most likely part of the recipe to change if Google's Wiki is ever released or I find a good alternative.

The end is really, really near

A lot of people have been predicting the demise of the major record labels for a long time and of course we all new it was inevitable but I've never thought the time had arrived, until now!

Big name backed independent distribution efforts like the one at http://niggytardust.com will be huge financial successes and convince all the fence sitting artists that this is the right way to go.

This of course will starve the big labels of talent, not that they could recognize it even when they did find it, and slowly drive them out of business.

It's about time!

Why Participate?

Today I was asked a question that went something like this....

“Why should we participate in a Free Software project if it's possible for our competitors to benefit from our efforts?”

I wasn't really comfortable with the answer I provided at the time so I'm going to take a second stab at it....

"You'll get better results at less cost choosing Free Software than you will from proprietary software and maximizing the benefits of Free Software can only be achieved through participation in the community."

Of course you can choose not to do this and stick with proprietary solutions or maybe even sit on the fence and be a passive Free Software consumer but that doesn't stop your competitors from doing the smart thing and maximizing the potential of Free Software.

The right choice is to use the best tools at your disposal in the most effective manner you know how and hope that your competitors are not smart enough to do the same.

Of course in most cases, today, it's unlikely that your competition will have come to understand the benefits of Free Software yet, so you'll have a considerable head start in learning how to effectively participate in the Free Software community.

In fact I'll even go out on a limb and say that the concept of Free Software is so foreign to most businesses and the benefits of using it so great that it could be a decisive advantage to any business able to grok it.