LibraryToGo

Open source integrated library system (ILS) built with Ruby on Rails on a threaded stack. It treats patron experience and search as its core competency while supporting day-to-day operations.

The project’s name is not final.

Goals

LibraryToGo will have all critical features of an ILS, but re-imagined from an outsider’s perspective. In particular, it provides a web-based management system (without restrictions on licensing, user accounts, or record quantities) that allows a userbase to interact with data through abilities and permissions they have been granted.

Koha v 3.8 is the reference list of features and performance. LibraryFind is a reference for implementation and design considerations.

LibraryToGo will be developed using contemporary open source practices and seek maintainability. Code will be covered and tested. The deployment will be effortless. Dependencies will be reasonable and integrated with version control and/or software packaging services.

Installation

1. Use your OS package manager (Homebrew recommended, on OS X) to install GCC
2. Install RVM
3. Use RVM to install the zlib, ncurses, readline, openssl and iconv packages
4. Use your OS package manager to install PostgreSQL, Sphinx (with PostgreSQL support), and ImageMagick
5. Use RVM to accept and install this repository’s .rvmrc file
6. Use Bundler to install the Rubygems for this repository
7. Create config/database.yml from config/database.example.yml and edit it for values on your system
8. Use Rails to initialize your databases with bundle exec rake db:setup and bundle exec rake db:test:clone

Testing

This codebase supports the Test Driven Development methodology. Use bundle exec guard start to watch your filesystem while making changes.

This codebase can provide code coverage analysis. Use COVERAGE=true bundle exec rake spec to run the full spec suite with metrics reported in /coverage/index.html.

Design

Modules (planned)

• Circulation — checking materials out and in, by staff and patrons
• Cataloging — includes serials
• OPAC — public-facing website
• Admin — management of various high level records and configurations

Considerations

• User privacy is important, as what they view, search for, and circulate is sensitive information
• High read throughput with infrequent updates (caching is important)
• State machine transitions for inventory objects
• User groups authorized to implement and override the business rules
• Business rules in centralized configurations
• Users need persistable and replaceable authentication tokens, as ID cards get lost
• This facilitates in-real-life operations; (almost) everything relates to timings and quantities

Privacy concerns

• all personally-identifying information is assumed wholly private; only the least amount of information shall be exposed through public posts like comments and reviews
• aggregate counts are generally not sensitive (n-many times a record has performed x-many actions) and can be stored with their parent record
• any record that serializes users’ actions should be sensitive (reads should be restricted to privileged users) and the structure of this serialization allows class-level restrictions

Feature TODOs

• Dublin Core — https://en.wikipedia.org/wiki/Dublin_Core
• search — Sphinx and Thinking Sphinx; specifically, faceted search
• taggings — acts-as-taggable-on
• automation and notifications — sidekiq
• admin cms
• moderation, acquisition queues
• import and export — FasterCSV? (MARC and Dublin core)
• circulation
• i18n
• reporting and visualization — ruport, googlecharts
• image processing — rmagick
• backups
• check out
• check in
• holds

Features integrated

• users and authentication — Devise
• user roles — simple, roll-your-own
• abilities granted to roles — cancan
• pagination — will_paginate
• scheduling — clockwork
• testing — Guard dispatches RSpec through spork

Feature wants

• payment integration
• comments — Disqus?
• ratings
• patron cards
• QR codes
• microformats