Tools

• Ruby >= 1.9.1
• Passenger >= 2.2.2
• Rails >= 2.3
• Mysql
• Nginx (you'll compile one before we're done)

Steps

1) Install Ruby 1.9 (see instructions for your platform)

2) gem1.9 install passenger # Assuming your using a prefix, you dont have to

3) passenger-install-nginx-module

4) add the following to your nginx config before the last }

   server {
      listen 80;
      server_name www.yourhost.com;
      root /somewhere/public;   # <--- be sure to point to 'public'!
      passenger_enabled on;
   }

5) install mysql drivers

curl -O http://tmtm.org/downloads/mysql/ruby/mysql-ruby-2.8.1.tar.gz
tar zxfv mysql-ruby-2.8.1.tar.gz
cd mysql-ruby-2.8.1
ruby extconf.rb
make
sudo make install

6) sudo gem1.9 install rails

7) rails -d mysql somewhere

8) start nginx

There are many posts about String.each, the new block shadowing and even a post or two about some of the C level changes.

However I had not seen anyone point out this little change that could affect certain meta-programming situations. Calling .methods returns a list of all the methods which a certain object or class responds to.

For the most part this is only useful in IRB. I often call

test_object.methods - Object.methods

when I can't remember a method name.

The change between Ruby 1.8 and Ruby 1.9 is that .methods now returns an array of symbols where in 1.8 it returned an array of strings. For the most part no problem, but something to be aware of. .respond_to? appears to still take either a string or a symbol, so if you're just checking an object do this:

object.respond_do(:method)

instead of:

object.methods.include?("method")

Using Synaptic

warning: it appears that the Ubuntu package is currently 1.9.0, which you don't want

Ruby 1.9 is available via the Synaptic installer.  Be sure to select ruby1.9, irb1.9 and rubygems1.9

From Source

sudo apt-get -y install libc6-dev libssl-dev make build-essential libssl-dev libreadline5-dev zlib1g-dev
tar zxfv ruby-1.9.1-p0.tgz
cd ruby-1.9.1-p0
./configure
make
sudo make install

A Little Maintance

Took a time to move this blog over to Typo. Made some design in improvements at the same time. If you're feed reader reposted all the previous articles, my apologies. If you catch something I missed let me know =-) My hope is to have both a Windows install walk through and a Linux install walk through by the end of next week.

Pre Reqs

You need XCode 3.1 or greater to install Ruby 1.9.1

MacPorts

Personally I've found using a package manager is much simpler that trying to roll you own of everything. One of the reasons this works so well for me is that I know when to give up and compile my own package. Ruby 1.9 is in MacPorts, it is stable and that is how I install on Ruby 1.9 on the vast majority of my Macs (there are 4 that I maintain btw).

  sudo port install ruby19 +mactk +c_api_docs

Variations

MacPorts has the concept of variants which are the options for your package. According to the command "port variants ruby19" there are the following availible:

  ruby19 has the variants:
      nosuffix: Don't add the 1.9 program suffix to the executables. Note: that makes the port conflict with ruby (1.8), rb-rubygems, and rb-rake ports
      c_api_docs: Generate documentation for Ruby C API
      tk: Build using MacPorts Tk
      mactk: Build using MacOS X Tk Framework
      universal: Build for multiple architectures

As you can see I like having the C API docs and using the existing MacTK framework.

By Hand

Maybe MacPorts makes you angry, you've had bad luck with it in the past or you just want to compile your own. This is a totally legitimate thing to want to do. It turns out its not hard either (knock on wood)

  curl -O ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p0.tar.gz
  tar zxfv ruby-1.9.1-p0.tar.gz
  cd ruby-1.9.1-p0
  ./configure --enable-shared --enable-pthread CFLAGS=-D_XOPEN_SOURCE=1
  make
  sudo make install
  echo 'export PATH="/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:$PATH"' > ~/.profile
  source ~/.profile
  ruby -v
  ruby -e "puts 'hello world'"

I did an install this way a few days ago. If you get stuck checkout this Gnu Screen log of the install, it may help you

The problem

Ruby 1.9 is here, but not really. Ruby 1.9 won't really be here until we are all using it, and we won't all be using it until the majority of Ruby gems are working.

What Can We Do?

Here is the idea. What if instead of trying to make every project maintainer learn all the tricks and skills needed to convert a piece of code to 1.9, we put up a little money to get one expert to work on converting gems over. Someone to work with maintainers to get their gems up to date. Someone who would gain practice as he converts gem after gem and who would dedicate real hours to making this conversion done. What if at Rubyconf this year we could go around saying "You're not still using Ruby 1.8 are you?" the same way we go around saying "You're not still using Ruby 1.6 are you?".

How?

I'm putting myself out there to be that guy. However I still need to eat and my wife would be kind of pissed if we lost our house. So I need your help too. My goal is to be able to work 20 hours a week for the next 2 months on converting gems over. To do that I would need to get 400 of you to donate $30. I don't expect that to happen over night (it would be cool though ;-) So in order to get started I'm looking to raise $3000, enough to work for 40 hours. Once that amount is raise the project will be officially on and I'll clear the time in my schedule to devote to it. Though my current plan is to start by going through the reported failures on Is It Ruby 1.9 and fixing them based on their popularity, I've put a poll at the bottom to let you tell me how I should do this. If after one month we haven't made that target I'll clear time to do work for as much as we did raise. As a good faith effort I will be converting all of the current gems I maintain in the mean time.

Is This Really Necessary?

I've been programming in Ruby since 2003. I remember the transition from 1.6 to 1.8, I was trying to learn Ruby at the time. It was painful, agonizing, and took way to long. As a community we are already doing better this time, but the faster we get on with it the faster we get all the goodness that is 1.9. Also the sooner we don't have to maintain both, and the sooner noobs won't wander around saying things like "but the documentation doesn't match, WTF?"

Should I Trust This Man?

I've got a history working with Ruby, I've done Rails full time professionally since 2005 and I run Notch8 consulting in San Diego. I'm a regular member of SDRuby. You can hear me speak on our podcast. I have a bachelor's degree in Computer Science and have worked in embedded C and Java. I really respect and love the Ruby community and I want to see it flourish. I promise to be very transparent and accountable with my actions. I am used to tracking my hours, to keeping a schedule and to being accountable to clients. In this project you, the community, are my client and so my time logs will be completely open to you. I'll be posting them each week along with blog entries and how to documents. You will know what I have worked on and how long it has taken me.