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/