After recently using the Ruby-based s3sync tools to handle backups to Amazon’s S3 service, it seemed a good time to give the Ruby programming language a fair shake and see what all the hubbub was about. I had a little exposure to Ruby a couple years ago using a book tutorial to create a blog in Ruby on Rails, but didn’t really learn much about the language itself in that process. And having recently discovered The Dev Show podcast on the 5by5 network, it’s also possible their extreme Ruby bias started rubbing off on me!
It always helps to have a real application when learning something like a new programming language, and having recently completed an upgrade to my Perl Module for the QRZ Callbook API, it seemed that porting it to a Ruby Gem might be the perfect goal. Armed with “The Ruby Cookbook” and “The Ruby Programming Language” in my Safari Books account, and some free time during the holidays, I began.
The first problem I encountered was trying to use Ruby on Debian, the epitome of stability in my opinion, and my server environment of choice for that very reason. The Ruby package for Debian had already been installed on the system in order to use s3sync. But when trying to do something as simple as listing the remote Ruby Gems, it produced a fairly cryptic error. Researching the error eventually led to this post from one of the Debian package maintainers. The reputation of Ruby’s instability was immediately showing itself.
Compiling Ruby from source seemed the only realistic way to move on. I installed the latest version, 1.9.2. It seemed like a good idea at this point to make sure s3sync and s3cmd were still working, only now they were producing fatal errors. Research confirmed that the s3sync tools simply do not work with Ruby version 1.9.2. So I installed Ruby version 1.8.7 from source instead, and thought very seriously about abandoning the project.
Eventually I did finish and publish my new Ruby Gem and felt a little less behind the programming curve afterward. (Read: keeping up with the youngstahs) I do like the language a lot – it feels like you can accomplish many things in fewer lines than other languages, and that the code is very clean and legible. And it does seem that there’s something just plain fun about it, similar to the way OS X feels good in a can’t-necessarily-put-your-finger-on-it way. And RVM (Ruby Version Manager) appears to be a slick (and fun) way to manage an otherwise unstable version environment.
Fluency in both Perl and jQuery seemed helpful since most concepts in Perl translate fairly well to Ruby – such as the array and control structures – and the endlessly chained object oriented methods feel a lot like jQuery.
Time and energy-allowing, I’ll probably take a more serious pass at Rails; I have an application in mind. I abandoned Rails the first time when it became clear that incorporating it into our Apache-based server environment at work wasn’t realistic. This time the approach will be with an application that’s more standalone in nature. And after learning about Passenger, I have at least some confidence that maybe Rails and Apache can co-exist better than used to be the case – and it might not even be slow! We shall see…
