Since my foray into python a couple of months ago, I've been enjoying branching out into new languages.
I had pitched the concept of a link resolver router for the state universal catalog to a committee I sit on (this group talks about SFX links in the 856 tag and whatnot). The problem with making links for a publicly available resource point to your institutional resolver is just that. It's pointing your your
institutional resolver, despite the fact that your audience could be coming from anywhere. This plays out even greater in a venue such as a universal catalog, since there's not really a "home institution" to point a resolver link, anyway. OCLC and UKOLN both have resolver routers, and OCLC's certainly is an option, but I don't feel comfortable with the possibility that all of our member institutions might have to pay for the service (in the future). My other problem with OCLC's service is that you can only belong to one institution and I have never liked that (especially as more and more institutions have link resolvers).
So, in this committee I mentioned that it would be pretty simple to make a router, and since I was having trouble getting people to understand what exactly I was talking about, I decided to make a proof-of-concept. And, since I was making a proof-of-concept, I thought it'd be fun to try it in Ruby on Rails.
Now, a resolver router is about the simplest concept possible. It doesn't really do anything but take requests and pass them off to the appropriate resolver. It's a resolver abstraction layer
, if you will. I thought this was a nice, small project to try to cut my Ruby teeth on. There's a little bit a database, a little bit of AJAX. It's also useful
, unlike making a cookbook from a tutorial or something.
It took about three days to make this
After you pick your resolver (Choose a couple! Add your own!), you'll be taken to a page to choose between your various communities for appropriate copy.
I chose this particular citation because it shows the very huge limitation of link resolvers (if you choose Georgia Tech's resolver and Emory's resolver, for instance); despite the fact that this is freely available
, it does not appear in my resolver. That's not really the use case I envision, though. I am thinking more of a case like my co-worker, Heather, who should have access to Georgia Tech's collection, Florida State's resources (she's in grad school there), Richland County Public Library (she lives in Columbia, SC), and the University of South Carolina (where her husband is a librarian). The resolver router alleviates the need to search
for a given citation in the various communities (indeed to even have to think of or know where to look within those communities).
Sometime later this winter, I'll have an even better use case. I'll keep that under wraps for now.
Now, my impression of Ruby on Rails... For a project like this, it is absolutely amazing. I cannot believe I was able to learn the language from scratch and implement something that works (with this amount of functionality) in such a short amount of time. By bypassing the need to create the "framework" for the application, you can just dive into implementation.
In fact, I think my time to implementation would have been even faster
if the number of resources/tutorials out there didn't suck out loud
. Most references point to these tutorials
to get you started, but they really aren't terribly helpful
. They explain nothing about why
they are doing what they are doing in them. I found this blog posting
to be infinitely more useful. Her blog in general
is going in my aggregator, I think.
When it comes to learning Ruby, this is a masterful work of art
... but... not terribly useful if you just want to look things up. I recommend this
Anyway, I am so impressed with Ruby on Rails that I am planning on using it (currently) for "alternative opac project
", which is now being code named "Communicat". More on this shortly (although I did actually develop the database schema today).