Computers In Libraries, Day 1 Keynote - David Weinberger

The wonderful David Weinberger, Co-Director of the Library Innovation Lab (http://librarylab.law.harvard.edu/) at Harvard University and author of Too Big To Know; Everything is Miscellaneous: The Power of the New Digital Disorder, & Co-Author of The Cluetrain Manifesto, gave a rousing keynote on "hacking the library" to start out the 29th annual Computers In Libraries conference this AM at the Washington Hilton. You can review it now at http://www.infotoday.com/cil2014/.

(And, yes, in case you're wondering, the keynotes are -- tech gods willing -- livestreamed for free at the Information Today website - http://www.infotoday.com/cil2014/live.asp)


Because the theme of this year's conference = "hacking the library", David identified the why and what we mean by hacking the library. The why includes the cuts in library budgets occurring along with the call to raise the value proposition the library offers. David noted that we're talking about "white hat hacking", which is about adding value (vs. "black-hat" hacking, which is value negative). He mentioned that the type of value-adding (hacking) measures he's citing are easier than ever now due to increasing move toward open access resources, engagement lifecycle, and the power of the network.

While libraries were always portals to information, in the past they had exclusive importance. Today, the network itself is the portal and it allows people who connect with one another around any topics. The network even allows today's readers (library users or not) to connect directly with authors. The value of information itself is determined by the cultural uptake of the materials. In the past, average people were left out of the important conversations and such conversations were held behind closed doors. In the new networked ecosystem, libraries are wondering where they fit in and how they can get into the game. Often, librarians want to resume the position we traditionally held, of being the sole/primary information portal for a community.

The reality check for libraries seeking to return to that portal to the community's information is that libraries can't be everything to everyone. The Swiss army knife, for example, is a hack that anticipates a number of items that an individual user might need. But that hack isn't scalable. The Swiss Army knife is born of anticipation -- the idea that you might possibly need item x, y, or z, that it includes. In the pre-digital world, the publisher was a gatekeeper who only allowed a small percentage of potential titles to be published. Only those that offered mass (read: profitable) appeal were produced.

In the web world, there is no more gatekeeping - all potential titles can be published. But what adds value is the added weight of majority recommendation, for example. Items are filtered forward on the web, not filtered out. When you "curate" materials online, you are filtering those materials you which to guide users to, but the users can also go outside of your walled garden and find other materials. The curation just makes the user's path to the materials more straightforward.

Traditionally, libraries, too, have had to filter their work with physical collections. We acquire items to build collections, then catalog, shelve, circulate, and build services around them. We do that in one way, not in all possible ways. Even as we digitize materials and decide which metadata to capture / how to map existing metadata, we are filtering. David then spoke about their digitization of materials from the Tibetan Buddhist Center. There was no element in the traditional metadata schemas for the "reincarnation of" information.

So how do we build a future that isn't guided by the impossible goal of perfect anticipation? There are 3 paths:

1. The Library as Platform: you have the library as portal, as one applciation/one service, but also you offer up open data, e.g., anonymized usage data, bib data, user reviews, annotations - upon which other folks - many of them web developers, for example, civic-minded or otherwise - can build tools. Much more value can be extracted from our resources when we feed our data out in ways that others can use and manipulate. Since the library is not the only source of information in a networked world, the community doesn't have to come to you or approach in the way you imagine.

-- enables people to access this data as though it's local - so you as a library don't have to figure out which & only which services we provide; we want 14 & 15 year olds around world to do this
-- successful platforms offer up APIs (Application Programming Interfaces - http://en.wikipedia.org/wiki/Application_programming_interface) to allow others to use their data e.g., Facebook, New York Times, Internet Archvie, OpenLibrary, Data.gov, DPLA

Harvard's Innovation Lab provides LibraryCloud - http://librarycloud.harvard.edu/ - offers up open data - an API with all 13 million bibliographic records in Harvard Libraries. Built on top of that, for example, is a visualization tool that allows you to see the coverage of topics in Harvard's libraries. It's called Stacklife - http://stacklife.harvard.edu/

David notes that a well-done platform should not only add community engagement but should also add that community-provided data back into the system. He also mentioned the Harvard Labrary design project http://lj.libraryjournal.com/2013/05/buildings/lbd/looking-through-the-labrary-lens/ that reimagined the future of the library. Additionally, he pointed listeners to another interesting experiment - the Awesome Box - http://awesomebox.io/ - which helps library patrons recommend books through simply returning those books to an "awesome box" next to the more traditional library return box.



2. Linked Open Data (see http://en.wikipedia.org/wiki/Linked_data). David says that we can start to build core library systems with linked open data. Linked open data describes the types of relationships between data, so that computers can map meaning. It allows data to be mashed up to move their value beyond the boundaries of the rich siloes that we've been building all of these years. He mentioned the linked data for libraries project (http://library.stanford.edu/news/2013/12/stanford-cornell-harvard-libraries-awarded-grant-linked-data-project)


3. Build graphs. David talked about Facebook as a social graph and how the knowledge graph at Google builds the informational box sometimes seen on the right-hand side of the search engine results page (for example, if you search on Theodore Roosevelt). Google uses an algorithm to automatically create a meaningful representation of information on the topic you've searched. He mentioned that libraries should be the place that people come to hack their own library experience. We need to hack the future, how we address the future, and to move ahead. Relationships are crucial to this enddeavor, supported by the values of community and openness. Building a graph would allow us to provide an infrastructure of knowledge online where [libraries] are not nearly as present they should be, he pointed out.

Though roads may be built to take you just one way and we may never give up on roads, we also need to allow people the freedom to wander off the road, as needed, by offering them the library. Finally, David called on us to live "with less anticipation and more possibilities"

For more David Weinberger:
www.johotheblog.com



self@evident.com

Twitter @dweinberger

David Weinberger

Finally, it was suggested that if we liked the keynote, we should go to the Tues. evening program ("Extreme Makeovers & Mindshifts: People & Places" - 7:30pm, International Ballroom East).

Why & How to Learn Git

For a while now, I’ve needed to really just wade through git (see: http://git-scm.com/) . to that end, I took the Code4Lib preconference workshop on Git.

Why?

First, all the cool kids are using it.

But seriously, many of the people who are working on projects that matter to me in the world - open-source projects in particular - use git (and often have links to their publicly accessible code repositories) on github. So if you want to take advantage of, build upon, or work collaboratively in an open-source software development project, you usually use git.

git is version-control software.

What that means is that git saves information about changes you’ve made in the code that you’re writing. This way, you track your progress and/or roll back to earlier code states (e.g., if new work you’ve done has the unintended consequence of introducing a bug). It also allows you to compare versions so if that dreaded bug introduction occurs, you can zoom in on where it may have arisen. It creates a record - a kind of documentation - with each commit of the code, moreover, so you can leave little notes for yourself (or, if working collaboratively with others, for them) as to why you’ve made a change. This way, even if you don’t touch the code you’ve worked on for a long time, you’ll be able to recall why you made certain design/development decisions.

Traditionally, you worked with git using a command-line interface. It’s very easy to work with command-line in either Macs or linux machines and not have a certain kind of funkiness that can occur in today’s Windows machines. But even in Windows machines, you can work with Git via command line. Also, there are graphical user interfaces for git. But if you’re doing the type of code work that benefits from git usage, you’ll probably eventually have to get more comfortable working in the command-line. That’s just a heads up.

Never forget, working in the command-line builds character (bonus points if you learn something like command-based vi/vim for editing files on your machine). Plus, all of the “cool kids” are doing it. And imagine how empowered you’ll feel as you grow more comfortable in the high-tech environment of textual displays. You’ll feel all old-school hipster-ish.

But seriously, when it comes to git use - you might ask why it’s taken off. Well, there is a style of code development common in website work today that is “agile” and “iterative”. This means that feature sets are designed in small pieces and the coding is done in short cycles by teams. Using version control systems like git makes that workflow easier to manage. It also makes collaboration with other code developers easier to manage than it otherwise might be.

Git, you see, is a distributed version control system. I don’t really care to get too far into this because while I think I understand the difference between centralized, local, and distributed version control systems, I didn’t rise up through the ranks of computer programming and I don’t want to describe these systems incorrectly. But the bottom line is that you can get a copy of a code repository on your local machine to do development work. You can do so by making your copy a separate “branch” from the original/”pristine” codebase. This makes it easier to develop off of the original codebase at the same time as someone else is, too, on their own branch.

Anyhow, there are much better explanations out there than I am providing. But suffice it to say. git is worth learning for librarians who are moving into the world of code (and many of you should at least try to do so).

Git project documentation & videos - http://git-scm.com/doc

Github offers a basic setup guide at https://help.github.com/articles/set-up-git

Basic git commands for git can be found in this “simple” site (there’s also a link to a cheatsheet here) - http://rogerdudler.github.io/git-guide/

About heated debates on how to use git http://readwrite.com/2014/04/03/git-three-most-heated-debates#awesm=~oAu2iixc2DohLB

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: 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.

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 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 Programming with Ruby on Rails

●     Intro to Git