This is the text of a talk that I gave at the NN/LM Greater Midwest Region tech talk on January 29, 2016. It has been lightly edited and annotated with links to articles and other information. The topic was “Emerging Technology” and Trisha Adamus, Research Data Librarian at UW-Madison and Jenny Taylor, Assistant Health Sciences Librarian at UIC LHS in Urbana presented topics as well.
Welcome to the Disruptive Library Technology Jester. From here you can browse the musings and visions of a library technologist as he walks the fine line between the best of the library profession on one side and the best of technology on the other.
One of the features of Jaspersoft Reports is the ability to include static graphics — logos, for instance — in the completed reports. These graphic files are normally listed in the JRXML configuration file by reference — meaning that what is stored in the configuration is a file name and not the graphic itself. Most times the configuration file and the ancillary graphics files are uploaded to a JasperReports Server for execution. In the environment that I’m working in, CollectionSpace, the report generator is embedded in the application without the JasperReports Server endpoint. The JRXML files must be compiled into the application, which makes keeping track of the ancillary graphics files somewhat troublesome.
Ideally, I would like to embed the graphics into the JRXML file itself, similar to what is done in with the data URI schema in HTML and CSS files to reduce the connection latency between client and server. This is possible, but the instructions and hints you find out on the internet to do it are out of date or incomplete. The instructions below are correct for Jaspersoft Studio version 6.2.0.
For the past few months I’ve been working on a project to migrate a museum’s collection registry to CollectionSpace. CollectionSpace is a “free, open-source, web-based software application for the description, management, and dissemination of museum collections information.”1 CollectionSpace is multitenant software — one installation of the software can serve many tenants. The software package’s structure, though, means that the configuration for one tenant is mixed in with the code for all tenants on the server (e.g, the application layer, services layer, and user interface layer configuration are stored deep in the source code tree). This bothers me from a maintainability standpoint. Sure, Git’s richly featured merge functionality helps, but it seems unnecessarily complex to intertwine the two in this way. So I developed a structure that puts a tenant’s configuration in a separate source code repository and a series of procedures to bring the two together at application-build time.
Last week I was at the NISO Forum: The Future of Library Resource Discovery with a great group of colleagues as we challenged ourselves to think about the role of discovery services in the information-seeking habits of our patrons. In the closing keynote, I was projecting what library resource discovery interface might look like five years from now, and I was weaving in comments and ideas that had bubbled up in the in-person conversation and the Twitter channel. And yes, I did wear a jester’s cap for the presentation.
Included below is the text of the presentation as intended to be given on October 6, 2015, at the Mt. Washington Conference Center in Baltimore, Maryland. (I did stray from the text in a few places, but not in any significant way.) At the bottom is a postscript based on a conversation I had afterwards about the role of mobile devices in library resource discovery.