Brian Turnbull and Nick Plante each had excellent presentations for the New Hampshire Ruby Rails Group’s first meeting on the third Monday of the month, our new “regular meeting day.” (We won’t be having a December meeting, however; have a happy Kwanzaa, Hanukkah, Christmas, Saturnalia, Winter Solstice or non-denominational generic shopping holiday of your choice.)
Brian was up first, and talked about rvm, the Ruby Version Manager (slides here: http://www.slideshare.net/bturnbull/rvm-nhruby-nov-2009). RVM doesn’t just allow you to have multiple versions of ruby on your machine; you’ve always been able to do that with side-by-side installs or linking or aliases or other kludges. RVM can be found at https://rvm.io/ and can be installed as a Gem, from the Git repository or as a tarball. It’s not Ruby code, actually, but shell scripts, and it allows not just switching of the current active version of ruby, but much more interestingly, the entire set of gems associated with a version! Multiple gemsets can be assigned an alias that lets you group your gems by function or project or client. RVM also provides a facility to dump the list of gems from one version or gemset and load it into another, allowing you to test out the migration of an existing system to a new version with much less hassle. Finally, rvm also lets you invoke multiple versions serially, passing them a command like “rvm 1.86, 1.8.7, 1.9.1 rake spec” where rvm will run all your tests on multiple versions and report results, even in JSON if specified. This could be the core of a really simple Continuous Integration (CI) server in a single line of code!
Brian cautioned that rvm is early in its development cycle (current as of last night was 0.0.79) and changes are coming fast and furious, but it’s worth taking some time to keep track of this very interesting development!
Brian also mentioned that rvm has some extensions to work with Bundler. Nick mentioned that Bundler, a project from Yehuda Katz (core contributor to both Ruby and jQuery) , is slated to become the default means of managing gems in Rails 3.0. Here’s a good link to learn more: http://yehudakatz.com/2009/11/03/using-the-new-gem-bundler-today/
Nick Plante was up next, with his presentation on EC2 for Rails Development (http://zapnap.github.com/presentations/ec2-rubber/#0). Nick talked about the evolution of deployment of Rails (or Rack) solutions, moving from very painful to much easier with the introduction of Capistrano (http://www.capistranorb.com/). He reviewed how simple it was to deploy an application with Capistrano, and then talked about the power of the Amazon Web Services (AWS) http://aws.amazon.com/ and Cloud Computing in general. Capistrano is focused on general deployment to a server, but the new add-on, Rubber (http://github.com/wr0ngway/rubber), extends that to work with elastic computing resources like AWS’ Elastic Compute Cloud (EC2). We walked through the basics of the install-configure-deploy scenario and then “Insert Demo Here.” – he did it. Defying the Demo Gods (who had already tortured Brian a bit), Nick grabbed a copy of RedMine (http://www.redmine.org/) from GitHub, did the couple of minor configuration items needed to make it work locally (creating the session key, copying the sample database config to the live one, setting it to use SQLite3 locally and running db:migrate) and then set it up for deployment: first invoking Capistrano (doing some configuring) and then Vulcanizing (how else would you make rubber) the installation, then deploying it to a brand-new AWS instance. The steps flew by lightening-fast: the Amazon instance was up and running a minute after being invoked, then took a couple of minutes to install and configure Apache, Passenger, MySQL, the Redmine application, and sftp the development directory files to the instance. Within a few minutes, Nick could browse the machine and see the running application as well as ssh into the box and make any changes. There are innumerable options, of course, but they are all accessible by reviewing the configuration files and the source to tune it to your particular needs.
While we waited for the installation to complete, I brought up some of the customer’s concerns and practitioner’s insights from last Thursday’s MonadLUG meeting on Cloud Computing and we talked about how those applied. I expressed concerns about how persistent data storage worked, since the cloud images were considered ephemeral. Nick pointed out that the instance, while running could have a local database and it could be in a master-slave replication arrangement with either another instance (within the AWS, there aren’t bandwidth charges) or a hosted or local machine. Also mentioned was the Amazon Relation Database Service (RDS), which can provide a MySQL database instance with backups. So, there are lots of options.
Thanks to Brian and Nick for excellent presentations as well as organizing the meeting and bringing the pizza, to Tim and the folks at RMC Research for providing the excellent facilites and to all eleven who attended and participated in the meeting.
Remember, no Ruby meeting meeting in December. Stay tuned for a January announcement.