Saturday, March 29, 2014

Notes from Monday, March 24, 2014 Code4Lib

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 ) nor Islandora (Drupal on top of Fedora, see ) 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: