We have a new addition at work – a server for testing and development (mercifully, my suggestion to name it “dev-ergreen” didn’t stick). There were some initial ideas for this new server, including:

• allowing staff to test out new features and upcoming versions of Evergreen; and
• providing us with a proper place to test our own enhancements and developments.

While those forward-looking objectives are still planned, the first thing I did was rather more conservative: I tested our backup recovery procedure. If our production server spontaneously combusted, how quickly would we be able to restore our services? (After e-mailing the fire department, of course.) Although we have backed up our data from day one, we had not yet tried the backup restore procedure from bare metal.

We restored our data to the development server without a hitch. While doing so, it occurred to me that this is something that open source software makes incredibly straightforward. There’s no concern about obtaining permission from a vendor to install another copy of the ILS on a second server, or moving the data from the production to the development server. Both can be running copies of the ILS without any extra money being spent on licenses. Additionally, new versions of the ILS can be tested without having to sign NDAs and obtaining vendor permission.

As a result, we now have a separate system with a copy of our production data, ready for testing by us and our staff…and I can sleep a little bit more soundly.

At my place of work, we signed up for a site-wide license to RefWorks last fall. We’ve also recently moved to Evergreen for our new ILS (press release). Naturally, there was a request from library staff to add a function in Evergreen to export citations from the OPAC directly into RefWorks.

I was happy to discover that Evergreen makes this relatively easy, thanks to SuperCat (part of Evergreen’s backend). With SuperCat and a record id, a record can be fetched in many different formats, simply by changing the URL (e.g., OPAC view vs marcxml vs MODS). This comes in handy when dealing with RefWorks.

Sending citations to RefWorks can be done with a callback. Essentially, you add a link to RefWorks’ import function page and send it your credentials, as well as a callback URL that RefWorks uses to grab the record from your ILS…in a RefWorks-supported format. The problem is that RefWorks doesn’t accept MODS, MARC, or even MARCXML. They say they accept MARC, but it’s actually what I call “MARC text” (it is described very well by Bill Dueber).

So with Evergreen, all that was needed to support Export-to-RefWorks was:

1. a new transform for SuperCat that converts MARC to “MARC text”;
2. a new SuperCat feed for the new format;
3. a button in the OPAC that links to RefWorks and provides the credentials and callback URL.

Voilà! The new “marctxt” SuperCat feed (which uses the new transform) provides the callback URL for RefWorks to grab the record and import it. I submitted a patch yesterday to address #1 and #2, above. A patch to auto-generate the info needed for #3 is forthcoming (and pretty straightforward). So Evergreen should soon support Export-to-RefWorks right out of the box.

(“Fine. Now take it off.” [SuperCat] photo created by “Allergic to Work” on Flikr, and licensed under the Creative Commons Attribution-Non Commercial-Share Alike license).

It’s the end of Week 2 at the new job[1] and it has been productive. Part of that may be because I ingested a decent amount of coffee. (I can’t get enough Bridgehead coffee and tea after being away from Ottawa for so long – I hope they expand to other cities in the near future.)

Late last week, I got Evergreen set up to act as a Z39.50 server following the instructions on the project’s DokuWiki. SRU worked fine out of the box and Simple2Zoom was easy to install and get working. I was retrieving records with yaz-client in no time.

This week, while testing the server with other Z39.50 clients, I found and fixed a bug in Simple2Zoom that was causing us some minor trouble. The first bug fixed in a new job, however small, is always very satisfying.

[1]: Okay, it’s not really a “new” job – I worked here during my co-op term last fall.

Randy Dykhuis has an article in this month’s Collaborative Librarianship in which he discusses the history of the Michigan Library Consortium’s move to Evergreen (full text[PDF]). From the abstract:

“In 2008, seven Michigan public libraries migrated to Evergreen, an open source integrated library system developed by the Georgia Public Library Service. The Michigan Library Consortium and Grand Rapids Public Library provided the support, training, networking, and system administration for the system. This article examines the reasons for implementing an open source system and the challenges to running and sustaining it.”

Today is my first day of work since completing my MLIS. As much as I wanted to work on my professional development during my two-week “vacation” between the end of school and the start of my new career, I instead spent much of my time recharging my batteries and recuperating from my final term.

Now that I’m well rested, I’m very happy to be back in the working world. I’m back to working on Evergreen but I’ll be playing more of an internal support and maintenance role in the library now, which suits me just fine. Other, non-Evergreen tasks await, too. Should be fun!

The Evergreen developers have just announced that version 1.4.0.2 has been released, along with OpenSRF 1.0.4. From the announcement:

This release adds functionality, configuration, and usability
improvements including, but not limited to, the following areas:

• Improved administrative interfaces for defining organizations and permissions
• Internationalization and localization (Armenian (hy-AM), Canadian French (fr-CA), Canadian English (en-CA), and Czech (cs-CZ))
• Multi-source Z39.50 search for staff
• Pre-overdue (reminder) notices
• SRU/Z39.50 server
• Publication date filtering in advanced search
• Preferred-language setting at both system and organizational level for search results
• Web-based batch record importer/exporter

Happily, this comes just in time for my Reading Week…

It has been nearly one month since I came back to school for my final term in the MLIS program. I have purposely front-loaded my schedule so that I can get as many assignments out of the way in the first half.

Because of this, I’ve missed a few things. Notably, the release of Evergreen 1.4 this past week caught me by surprise. But there it is! Congrats to the developers – there are some nifty new features.

Now, back to writing these two papers, preparing for a presentation, and drafting a business plan…

Today is technically the last day of my co-op placement at the NRCan Library. It has been a fantastic four months and, frankly, I’m not looking forward to heading back for my final MLIS term in January.

Not willing to let the work go just yet, I’ve put in a few longer days this week. I’ve been busy working on “transition” documentation/tutorials; and this morning, I submitted a second iteration of the Evergreen driver for VuFind. Users can now view their hold requests and their fines and the only remaining function to be implemented is placeHold (or, alternatively, the less intrusive getHoldLink).

I want to say a very big Thank You to George Duimovich for “throwing me a life preserver” and giving me the chance to work on open source projects for NRCan.

It has been a while since I started thinking of adding an Evergreen ILS driver to VuFind. After months of neglect, last week I picked up the latest version (1.0-RC1) and continued writing it up.

Currently, holdings info from Evergreen is displayed when viewing records and I’ve added support for ILS authentication. Patrons can log in and see their profile info and a list of the items they have checked out. Still unfinished is the ability for them to place a hold, view their current hold requests, and view a list of their current fines (these will be submitted shortly).

Special thanks to NRCan Library for giving me a bit of time to work on this.

Last week, I submitted a large set of updates for Evergreen’s fr-CA translation. There’s still a few more to do but the bulk of the new strings are now ready (including the new Conify and Vandelay interfaces, which are completely done).

While mucking about with the fr-CA PO files, I also opportunistically went in and did a first pass through the en-CA (English Canadian) translation. So Evergreen will now have the option to display the correct spelling of “catalogue”, “colour”, “cheque”, etc. What a relief, eh?