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: http://projectblacklight.org/) for discovery, and the complex of code and system that is “Hydra”
(see http://projecthydra.org/), 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 http://sass-lang.com/)/COMPASS. 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: http://en.wikipedia.org/wiki/Ruby_on_Rails).
But the basics are that Ruby is a high-quality programming language developing
in the early 1990s and Rails is the framework (see http://en.wikipedia.org/wiki/Web_application_framework)
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 http://en.wikipedia.org/wiki/Model-view-controller) 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 (http://railsbridge.org/about) 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 http://docs.railsbridge.org/installfest/
Then you can get started with Rails using the tutorial for http://docs.railsbridge.org/intro-to-rails/
DETAILS:
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 http://docs.railsbridge.org/intro-to-rails/getting_started?back=ruby_language
- 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 http://docs.railsbridge.org/intro-to-rails/running_your_application_locally?back=add_the_project_to_a_git_repo).
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:
Post a Comment