Saturday, March 29, 2014

Preconference: RailsBridge: Intro to programming in Ruby on Rails (Code4Lib 2014 – Monday, March 24, 2014)

Keep these 2 concepts in mind:
     software is eating the world (and libraries are no exception)
     the web is eating software (ditto)
Ergo, it’s worth the pain/joy/effort of wrapping your mind around things that might seem difficult to understand. Remember, you don’t have to grasp it all the first go ‘round, but awareness of developments in the world of code is crucial to libraries. If you don’t understand why, email me and I’ll do my best to convince you.

I kept hearing all of the hype about Ruby on Rails. At last year’s (2013, Chicago) Code4Lib Conference, it became clear to me that, Ruby on Rails (shorthanded as writing Rails apps) is the hotness in coding among library technology rockstars.
It’s heavily used by libraries doing some of the best discovery layer and digital collections work through the use of Ruby gems (i.e., "plugins") like “Blacklight” (see: for discovery, and the complex of code and system that is “Hydra” (see, which uses Blacklight in a typical setup.
I should add that even the Drupal community may leverage Rails apps to output cleaner and more compact (thus more performant & easier-to-maintain) CSS through the use of SASS (see They don’t use Rails for the actual sites’ rendering, but in the work on themes that leverage that SASS/COMPASS combination.
So what is Ruby on Rails? Wikipedia can explain it better than I can (see: But the basics are that Ruby is a high-quality programming language developing in the early 1990s and Rails is the framework (see that uses Ruby as the basis for developing web applications. (Developing for the web in the 2010s is a kind of software development, so we are truly writing “applications” or “programs” that we deliver through the web browser or mobile applications).
Anyhow, bottom line, Rails is showing up everywhere now (and probably has been for a very long time in some crowds, but it’s busting out all over the libraries with developers “in the know” about these things).
Although it’s open-source like other scripting languages used to build websites, Ruby on Rails was designed in a way that most traditional software programmers can respect - a more “correct” way to write code. There are some characteristics that make it this way and I’ll list the first ones I noticed - it’s bee, object-oriented at its core since Day 1 (as opposed to some other languages commonly used by web/software developers such as PHP) and uses the best practice MVC (Model-View-Controller, see structure (which is being using by some super-popular n(ewer Javascript frameworks, like Angular.js, which I hope to post about more sometime since there was a great presentation at C4L about these JS frameworks).
Why does this matter? The result of working with such code is a more easily tested, high quality web application than you might see working with some other forms of web coding. Theoretically, even as you iteratively improve your web app/site, if it’s built like this, it’s less likely to break.
Now, I’m no computer scientist, so correctness and elegance in code, while they sound like good ideals, aren’t my top priority. And there are lots of details here that I’m not fully conversant in. But the bottom line was that - given the growing interest in and use of - Rails apps in libraries, I figured that I should at least take an introduction to programming in Ruby on Rails and begin to grok some Rails essentials.
So this year I decided to take the RailsBridge: Intro to programming in Ruby on Rails preconference session. It follows a very specific tutorial that anyone can use, but we had the advantage of being led through it by experts.
In fact, there’s a group called RailsBridge (  that worked to get more women involved in the open-source project. They’ve developed an excellent, easy-to-follow, well-tested curriculum that is maintained by volunteers and run workshops to get people involved with Ruby on Rails
You start with the multistep installation process - Installfest, it’s called by RailsBridge. You can find it at
Then you can get started with Rails using the tutorial for
The first bit of the tutorial introduces you to use of “Interactive Ruby” - a console wherein you can immediately see on-screen the results of the commands you are sending. F you test it with some math, see how it just works. Then, you learn how to set variables and how to use math with them; how variables can be arrays (multiple values in a list), how to add and remove array elements; how to discover what type (class) the variable you’re working with is (e.g., string, array, fixednum); how to list the methods available to members (“instances”) of a given class; how to chain methods togeher; how to use each to loop through and puts to print out something and a new line to the end; and how to make your own method & use it.
The second part of the tutorial, called “Getting Started” - at - no longer uses the Interactive Ruby, but has you writing & working with Ruby on Rails as you would for a regular web application. That means a website that has some interactive programming. In this case, the “suggestotron” exercise.
In the tutorial, they have you build out the site’s shell, then create a Git repository to track the work that you’ve done with your work, but we skipped that step, and I don’t really have time to explain it here. You’ll have to check out my notes on the Git intro workshop when I publish them.
Instead, we skipped to running the rails server to be able to see our work (this step starts at
So what we do is create a database-backed website, in which interactions can “automatically” update/change the database’s contents. There’s a ton of important concepts that are touched on here. If you don’t know what we mean by a database-backed website, take some time to understand what it means and why it matters. Then, you’ll see the power of web applications. The interaction of the web with stores of information is what makes it powerful, as you can imagine. Rails does this in a way that seems at first blush, too easy to be true. (my other hand-written db interactions, e.g., PHP/ASP have required some important and specific code that has to be dealt with carefully in order to protect the database from being hacked while allowing the necessary interactions to write to it so that information can be stored, edited, and removed, as needed).
The tutorial is excellent, so if you’re interested in this, I’d recommend you try going through it. I will give you a couple of warnings, because I know that even I get overwhelmed by things like this:
  • ·         recognize that a good bit of the battle to understand is characterized by recognition of the language used around it – all the weird terminology here signifies deeper concepts, but the terminology itself at first feels unfamiliar and off-putting; At first, you probably won’t understand the concepts, you’ll just have to feel comfort with the terms and then start wrestling with the concepts.
  • ·         The act of working through the tutorial, though it will at first be a kind of rote exercise, in which you just follow directions, is designed to help you understand the concepts behind the terms. Eventually, it will.
  • ·         Just don’t panic, feel overwhelmed, and think you “can’t”. Because you can. You don’t have to be the quickest in the world at picking this stuff up. You don’t have to be as quick as anyone. Give yourself a pat on the back for not only every successful step you take, but everything you learn, even if it’s what doesn’t work (eventually, you’ll come to realize your mistake, but you may not for a while… working through the mistakes and finding solutions, even if it means starting a step over again or blowing things up, is part of the process). Having the courage to try something new and hard to you is always a good thing and worthy of reward.
  • ·         Take breaks when necessary, but always return, never give up.
  • ·         When you understand enough, teach someone else. The act of teaching will further your learning.

No comments: