Ruby is a 30 year old programming language designed and developed, primarily, by Yukihiro Matsumoto. It is a scripting language, meaning that code is interpreted vs. compiled. It is my favorite scripting language and it powers the Crux Web Application Server.
It is not without its share of quirks. No programming language is immune from that. That said, its set of quirks doesn’t bother me and is easily outweighed by its rich syntactic feature set and its ability to write very expressive code.
For example, suppose you want to write a programming loop which will emit “Hey, guys!” 10 times. In the C language, you will write something similar to the following:
for (int i = 0; i < 10; i++) {
printf("Hey, guys!\n");
}In Ruby, you could write the following:
10.times { puts "Hey, guys!" }What’s especially nice is the ability to make use of pre-packaged software libraries, called gems, and/or write C code for those tricky technical bits and write a Ruby/C glue layer. For me, it’s a top-notch blend of quick scripting with a down-and-dirty technical capability.
Everyone Has a Big But
– Pee Wee Herman
Ruby is not popular, at least not as popular as Python. Ruby is primarily known as the language which drives “Ruby on Rails”, a web application framework used to build interactive web sites. It was through Ruby on Rails and my work with the Tewksbury Special Education Parent Advisory Council (SpedPAC) where I learned about Ruby and was able to see through the integration to understand that Ruby was a great language in its own right.
But again, it’s not as popular, partly due to this successful near-seamless association with Ruby on Rails. No one talked about Ruby as a standalone language and I think, in my humble opinion, it hurt its reputation as very good, expressive productive programming language.
The primary side effect of this relative obscurity is that many, many Linux distros don’t ship with an up-to-date version of Ruby. My Orange Pi 5+ SBC supports a pretty modern version of Ubuntu Linux, 22.04. The version of Ruby that was bundled in this distro was 3.0.2p107; the current version is 3.4.1, a version 4 years newer. What this means is that I have to install the latest version of Ruby myself.
Not So Fast There, Rabbit
– Yosemite Sam
The good thing about programming languages, and technology in general, is that it changes and improves with every change (mostly, we all have our sob stories). Ruby is no different. However, when things change, old stuff stops working, which is more than just a little annoying.
Shiny!
– Malcolm Reynolds
Pre-packaged Ruby code modules are called “gems”. Other languages may call them libraries, but the concept is the same. Why have everyone write their own version of something that works? (Aside: well because of stupid “software patents” and the like, but I digress…)
There is a central repository of Ruby gems at https://rubygems.org. It contains everything from software utilities that have been downloaded millions of times to half-baked ideas and schemes. It’s awesome. But, what if you and/or your organization want to build gems for private use, but house them on your own web site? Well, there is a gem for that. It’s called geminabox.
Geminabox is a Ruby gem that allows web sites that have Ruby code execution capability to build a web site which houses and manages gems. Now, it’s not trivial to use. When doing Ruby development, you will have to add your site’s URL to a list of gem repositories, usually it’s just the one listed above, but it works like a charm. Your Ruby development environment will have access to both public and your private gem repositories and you can write some really sweet software.
That is, unless a Ruby language upgrade breaks the geminabox gem. Yup, geminabox is incompatible with Ruby 3.3+. I found this out during the great DreamHost Infrastructure Dumpster Fire last year. Awesome.
There are ways to fix this.
One: wait for the gem to be upgraded. Well, according to the statistics at rubygems.org, the code hasn’t been touched since 28-Jun-2022. I’m not holding my breath.
Two: fix it myself. Well, I’m gonna. Eventually. But not right now.
Three: only install Ruby 3.2. As much as this would fix this particular problem, I don’t want to hamstring my other Ruby projects just b/c the gem repo can’t do its job.
Four: There is a fourth way to handle this and it’s what I did on the Brick Mill and Mill #6 sites to get the rubygems sites there up and running. I installed RVM.
Wicked Shiny
– Me in a Firefly Universe
RVM stands for Ruby Version Manager and it is a tool that manages multiple Ruby system installations on one machine. I’m not the first person who has hit software version incompatibilities and this tool was built to handle these sorts of issues in the Ruby ecosphere. Once RVM is installed, you can install different versions of Ruby onto your system via the rvm utility and then manage which one you and/or the service user is using. You need a gem repo running on your site, install Ruby 3.2.x. You want latest and greatest: install 3.4.x. You want to use an experimental Ruby run-time which relies on .NET technologies, aka IronRuby, you can install that, too. With multiple versions installed and managed, each user can select from the available versions as its primary version when running specific pieces of software. You can even go back to the system default if you need to.
So today, I’m installing RVM on Huron, my Orange Pi 5+ system. As it turns out, RVM installation is different on Ubuntu systems, of course. That said, it seems to be working.
Epilog: Fresh Rubies
The rvm utility is smart enough to find pre-built software. For my system, there was nothing newer than 3.0. That said, you can use rvm to build new stuff.
I told rvm to install 3.2.8 via the command-line: rvm install ruby-3.2.8. Nothing pre-built was found, so it’s building directly from source. The htop screenshot below shows the work being distributed across the 4 performance cores (5-8):
This is going to take a while…