My Code4Lib Notes: (Monday, March 24, 2014)
I did two workshops today, then really enjoyed the
discussions at a “newcomers’ dinner” (to which all were welcomed, newbies and
veterans alike (+ we had some great sushi, I even liked the octopus one of the
folks there was kind enough to let me try!)).
From dinner, I learned that both Ruby on Rails and Drupal
have similar issues and their users face similar frustrations (even though the
code-lovers out there might feel horrified that I’ve juxtaposed a proper coding
framework with Drupal, which is technically a content management system written
in a specific coding language (PHP)).
As application frameworks (Ruby on Rails, aka, Rails) and
codebases (Drupal) mature, they inevitably grow and become more complex. This
creates issues with tweaky little dependencies – differences in versions of
code are nontrivial and dependencies on other segments of code (with the
correct specific versions of those code segments) matter. That having been
said, the Rails folks will probably also be quick to remind me that their
framework is developed on principles that reduce entropy. But apparently, there’s
no eliminating it.
If you’ve ever wondered why the systems folks are scrambling
when a new version of software x comes out (and that it seems to inevitably
break things or create anomalies), it’s due to this issue. The more we demand
of our code, the more complex our code becomes. The more complex our code becomes,
the more there is to break.
It’s like having the car with power everything – windows,
locks, seats, digital readouts for the dashboard, and the like vs. having my
car – in which you have to crank down the window by hand (old school). You’re
going to run into more expensive problems than I will. My husband (or I, with
his help – reality check, he has experience with all things mechanical, far
more than I do) is likely to be able to fix the basic mechanical issues I’ll
run into, whereas you’ll be in the dealership when your dashboard goes blank and
you can no longer tell how much gas you have in the tank or how fast you’re
going (yes, I speak from experience).
But the convenience and positive user experience of those
extras makes us continue to add complexity to our systems.
So when it comes down to brass tacks, it seems that neither
the (more code4lib favored) Hydra (Rails apps on Fedora, see http://projecthydra.org ) nor Islandora (Drupal
on top of Fedora, see http://islandora.ca/ )
are painless digital repository systems, though both can provide beautiful
solutions for digital repositories. Both require staff with expertise (or staff
who are ready, willing, able (and given the time) to learn and practice until
they gain said expertise).
That’s the one thing that our library leaders too often
forget -- you can’t just choose a tool to meet complex system needs and expect
it to be painless and staffless. Moreover, though our tools are getting better,
our skillsets ALSO need to be improved to keep up. We can do more and we can do
it better, but we constantly need more training to work with them at the level
our library directors and users are seeking. The best tool implementations out
in libraryland have required code developers. Often librarians and archivists
take on this role successfully (hence Code4Lib), of course, so it’s not like
you necessarily require computer science grads to take on these projects. You
do, however, need to give your librarians and archivists who are entering those
muddy waters more support by ensuring they’re not on their own, sending them to
serious code training and professional development, and giving them both time
and space to improve their skillsets.
So our code-related needs are expanding geometrically in
complexity as our resources dwindle. This creates an inevitable tension. We
need more skilled human labor to deal with systems and technology. you can’t
get by today on one systems librarians. Today, you need digital teams /
library-technology departments.
I’ll post my notes on my 2 preconference workshops
separately:
●
Intro to Git
No comments:
Post a Comment