Coffee|Code : Dan Scott, Caffeinated Librarian Geek

Archive of OCLC WorldCat Policy as posted 2008-11-02

I noticed last night (Sunday, November 2nd, 2008) that the new and much-anticipated / feared OCLC WorldCat Policy had been posted. As far as the clarified terms went, I was willing to give them the benefit of the doubt until they were actually posted. I was first alerted to the freshly released policy by Terry Reese's initial analysis and was fascinated by the discussion in the comments.

Then I noticed this morning on the AUTOCAT mailing list ("OCLC New Policy down after one day?") that the new policy had been pulled and replaced by

We are reconsidering some aspects of the policy. More information will be available in the near future.

Very interesting. That's not even enough time for most interested parties to read the policy and provide feedback.

Luckily, I made use of Zotero last night to capture a snapshot of the freshly released policy. So here, for your pleasure, is the archived version (retrieved Sun 02 Nov 2008 10:24:15 PM EST according to Zotero - and how sad a statement is that about my life that I'm cruising the library 'nets on Sunday evenings?) of the OCLC policy that had been posted and then was immediately yanked. I'm hoping that this helps informed discussion lead towards a reconsidered policy that reflects direct input from OCLC contributors.

Full disclosure: my library is not an OCLC Member library, not from any ideological stance but because I haven't had time to contribute records yet. Kind of busy with the Evergreen thing, you know? But we pay for WorldCat and some other OCLC services and intend to become members. On a personal note, I think we would best be served by a plurality of services developed using the metadata to which all of the OCLC Member institutions contribute.

Dear Dan: why is using Flash for navigation a bad idea?

I received the following email late last week, and took the time to reply to it tonight. I had originally been asked by a friend to help diagnose why his organization's site navigation wasn't working in some of his browsers. I noticed that the navigation bar was implemented in Flash, and suggested that the Flash be replaced with plain old HTML, CSS, and perhaps some JavaScript as Flash for navigation is generally a bad idea. My friend's response last week was:

Dan, I would be interested to know why the flash is a bad idea. ...Our [website] designer seems to think otherwise.

Uh-oh: getting into it with the designer via proxy can't be good. But here's what I wrote in response - feel free to set me straight if I've gone off-track:

Jakob Neilsen said it best back in 2000 - and all of his concerns still hold up: http://www.useit.com/alertbox/20001029.html

To which I would add several more reasons:

Flash is not a native part of the Web, it's a third party browser plug-in; HTML + CSS and arguably JavaScript are the core parts of the Web. Anything as basic as navigation should not have to rely on a third-party plug-in to function.
How do you expect a person using a screen reader (due to visual impairment) to navigate through the site? With HTML/CSS/JavaScript, they can tab through the links on the page; with Flash, they hit something that forces them to use the mouse.
Until very recently, Google could not navigate through Flash to crawl pages - and even now it's capabilities are subject to some limitations (http://googlewebmastercentral.blogspot.com/2008/06/improved-flash-indexing.html).
On breaking the Web experience - if you try to right-click on the Flash navigation, you don't get the option to open the link in a new tab or window, or add a bookmark to the page that link represents. And I bet the links would work for you everywhere
For the paranoid, Flash is a proprietary format and therefore requires you to trust that the content that is being served up isn't doing something nefarious while appearing innocuous. A small percentage of people use plug-ins like NoScript to block Flash content and only enable Flash for specific pages when necessary. Having to enable it for navigation is annoying.

If your designer really, really wants to keep the Flash experience, the least they could do would be to put a plain HTML navigation menu inside the <noscript>...</noscript> section rather than the "Get Flash!" thing that currently appears.

For the paranoid: deleting Flash local storage objects

I'm reasonably careful about the cookies I accept from Web sites - I don't want companies to be able to track every site I visit, for example, so that they can build a nice little profile about me. It's for the protection of the companies more than anything else: someone there might die of extreme boredom following the trail of "Evergreen", "Linux Weekly News", "Python docs"...

However, I recently learned about Flash "local storage objects" (LSO), which are similar to browser cookies but capable of storing much richer information and also completely inscrutable in terms of the effectiveness of Adobe's security model. Is Flash really capable of preventing a Flash application running on microsoft.com from accessing an LSO from mail.google.com? I certainly don't know, and as Flash is a closed-source application it's hard for anyone except for the developers at Adobe to know--but I bet there are people extremely motivated to find out. (Insert obligatory "See? Closed source sucks!" comment here.)

So, in my crude attempt to prevent too much garbage accumulating due to the occasional YouTube video or NBC Saturday Night Live skit that I might watch, I've added the following rules to my cron entries to delete my entire set of LSOs every four hours:

5 ∗/4 ∗ ∗ ∗ rm -fr /home/dan/.macromedia/Flash_Player/#SharedObjects 
5 ∗/4 ∗ ∗ ∗ rm -fr /home/dan/.macromedia/Flash_Player/macromedia.com/support/flashplayer/sys/

You Windows users can probably do something similar, but I haven't bothered to track that down yet. Sorry.

An Evergreen track at the OLA SuperConference 2009?

Just poked at the OLA SuperConference 2009 schedule (January 28 - 31, 2009) and found four sessions listed that are all about Evergreen. Wow! Check this out:


Date	Time	Title	Description (may be abridged)	Presenters
Thursday, January 29	9:05 am	It.s Just a Little Bit of Programming Isn.t It?	Follow the progress of the Library @ Mohawk.s development of the open source ILS Evergreen. Hear the trials and tribulations and learn from the mistakes and successes that have occurred along the way . we are truly a learning organization on this project. We went live in summer 2008 . come and hear about where we.ve been, where we are and where we hope to be soon.	Robert Soulliere, Systems Librarian; Cynthia Williamson, Collection & Access Librarian, Mohawk College of Applied Arts and Technology
Thursday, January 29	3:45 pm	Project Conifer: Evergreen library system for Ontario Universities	Find out how the Evergreen open source library system, originally developed for a public library consortium, is being adapted for academic libraries by three Ontario universities. Discussion will focus on the challenges, successes and mistakes (err, .learning opportunities.) of the project.	John Fink, Digital Technologies Development Librarian, McMaster University; Dan Scott, Systems Librarian, Laurentian University
Friday, January 30	9:05 am	Evergreen exposed: hacking the open source library system	Join an Evergreen developer on a tour of the architecture and source code of the Evergreen library system [...] Get ready to get your hands dirty with Evergreen . this will be a session filled with code!	William Erickson, Vice President, Software Development & Integration, Equinox Software Inc; Dan Scott, Systems Librarian, Laurentian University
Saturday, January 31	10:40 am	Multilingual Language Issues of Open Source ILS	Discover the Chinese version of Evergreen along with various multilingual issues related MARC standards, encoding, indexing, searching, and sorting especially associated with Chinese language.	Jason Zou, Systems Librarian, Lakehead University; Guoying (Grace) Liu, Systems Librarian, Leddy Library, University of Windsor

I was responsible for the sole Evergreen presentation at OLA SuperConference 2008 - it's awesome to see a lot more people jumping in this year! I'm keenly anticipating this conference - we'll have to set up at least one Evergreen "Birds of a Feather" session.

Evergreen: deOSSification of library software

In a few minutes I'll be giving a talk with John Fink at the Free Software Open Source Symposium at Seneca College on Evergreen: an enterprise-strength OSS solution for library ossification. I'm jazzed!

Here are the slides: (ODP format) (PDF format).

Boss me around, s'il vous plait

My place of work, Laurentian University, is looking for a new Director of the J.N. Desmarais Library. The call for applications closes October 30th. I think our library has done some impressive work (participating in the food security project for the Democratic Republic of Congo, building the Mining Environment Database), are doing some pretty interesting things (Project Conifer), and have the potential to do a lot more. Our outgoing director has laid the groundwork for his successor to take Laurentian University's libraries to even more exciting destinations.

On the chance that you haven't heard about this opening, and would be interested - or perhaps you know someone who might be interested and would be a good candidate - I'm going to attach the full job posting below. One heads-up: Laurentian is a bilingual (French / English) institution, and candidates would be expected to be bilingual.

Laurentian University – Director of the Library and Archives – effective July 1, 2009

Laurentian University is committed to serving the needs of Northern Ontario and its English-language, French-language and First Nations communities, and to extending its student recruitment into other areas of Canada. Laurentian’s recent major accomplishments include the establishment, with Lakehead University, of the first new medical school in more than 30 years in Canada, the introduction of 6 new PhD programs, the construction of new residences and a building custom-designed to house the B.Ed. program, establishment of a new Faculty of Management, and increasing success attracting research funding, all within a vibrant bilingual milieu that appreciates the past and is building toward the future. Please consult www.laurentian.ca for more information.

The Director of the Library and Archives will be an innovative leader who will build on the momentum of the Libraries’ information technology services, operational systems and capabilities, and provide strategic direction in accordance with the Strategic Plan approved by the Laurentian University Board of Governors.

The ideal candidate will be a respected academic who will bring dynamic vision and academic administrative experience, and who will be able to function in both English and French. The candidate will have a Masters’ of Library Science from an ALA accredited library school or equivalent institution plus at least five years experience in library administration, including planning, personnel, budget, policy development and services. The candidate will have the ability to view issues from an organization-wide perspective and to contribute effectively to collaborative projects within and outside the institution. The candidate will have knowledge of trends in higher education and information technology that affect acquisition, management, storage and dissemination of print, multi-media and electronic resources. Experience in writing grant proposals and effectively administering such grants would be a strong asset.

Laurentian University is committed to employment equity, welcomes diversity in the workplace and encourages applications from all qualified individuals including women, members of visible minorities, aboriginal persons and persons with disabilities. All qualified candidates are encouraged to apply; however, Canadians and permanent residents will be given priority.

Should you want to learn more about this unique leadership opportunity, e-mail Susan Silverton, Vice-President, Academic (Anglophone Affairs) at ssilverton@laurentian.ca or forward your CV, a letter of introduction and the names of three referees in confidence, to Linda Mainville, Assistant to the Vice-Presidents, Academic, Laurentian University, Ramsey Lake Road, Sudbury, Ontario P3E 2C6

Access 2008 hackfest report: Zotero vs Evergreen

Update: 2008-10-07 As of changeset 10774, the detailed record view in Evergreen's dynamic catalog is now recognized by Zotero.

I really like Zotero. And it works really well with Evergreen's current "basic search" because it embeds unAPI links that enable Zotero to consume MODS representations of the underlying bibliographic records and generate a complete citation based on that.

However, Zotero doesn't work with Evergreen's current "dynamic search" interface - which is a problem, because it is the default search interface. Evergreen embeds a link to the unAPI server, and fills in the unAPI link via an AJAX call after the underlying XHTML has been loaded - but it seems that Zotero doesn't recognize that the DOM has been changed by the AJAX event and never discovers the unAPI link. So... I had submitted a challenge to Hackfest to fix this, because I really want to be able to use Zotero with Evergreen when Project Conifer launches.

And, as with every other Hackfest I have attended, I end up working on my own challenge. In discussing the problem with William from canadiana.org and Walter Lewis from Knowledge Ontario, I described how the dynamic interface doesn't use any templating (apart from entity substitution for localization support), that there wasn't really any way to inject content server side into the underlying XHTML, and that I really didn't want to have to dig into the guts of Zotero to enable it to parse the DOM after events had completed. William asked "so you can't even do a server side include?", which ended up breaking the problem wide open - because yes, we already use server side includes to identify which DTD to load for localization purposes.

Step 1 was to modify the detailed record display to put the unAPI link template in place, and to modify the Apache configuration to pass in hardcoded values for each of the SSI variables. A quick test and - it didn't work. Uh oh.

That led to much scratching of the head. Was Zotero getting tripped up by the masses of XHTML elements in the dynamic template that are simply hidden? Did it give up after trying to parse 100K or so of content? Were there differences in the content types being served up by Apache? The next step was to compare the content of the "basic search" output against the "dynamic search" output - and that led to one seemingly innocent difference.

The unAPI server link in the "basic search" output included an absolute link to the server, while the corresponding link in the "dynamic search" output used a relative link to point to the root of the server. I didn't think that would be a problem, but eliminating variables is always good - and when I tested with a hardcoded server link, the Zotero hint icon lit up and the mystery was solved. Between enabling the record unAPI link to appear in the static XHTML via SSI and changing the unAPI server link to use an absolute value, Zotero and Evergreen could work together in harmony.

I haven't committed the fix for this yet to the repository, as I haven't finalized the exact SSI incantations that will be needed to embed the record ID in the unAPI link. But now you know the solution, and could tackle the problem yourself if you get tired of waiting for me and feel inspired. And once the problem is fixed, I'll update the post to let you know what version of Evergreen carries the fix.

Oh, and my hackfest report slides are attached, in case anyone cares.

Access 2008 presentation: Project Conifer report

On Friday, October 3rd, I had the honour of presenting the progress of Project Conifer with my colleague John Fink to my peers at Access 2008. Project Conifer is the effort to bring the Evergreen open source library system to a consortium of academic libraries in Ontario (Algoma, Laurentian, McMaster, Northern Ontario School of Medicine, and Windsor).

I'm just going to link quickly to the slides for now, as I'm a little bit brain-dead after the conference. John led off the talk with an overview of what Conifer is all about and why we were motivated to tackle such a large project - he has posted his slides via the SlideShare thingy. Editorial comment: I really enjoy John's presentation style and content. He's a hard act to follow!

And then I rambled on with an overview of the ups and downs of the project so far, the resources we have invested in the project, our progress towards our target go-live date (May 2009), and some sneak previews of the goodies that are included in the any-day-now-if-I-would-just-stop-going-to-conferences-and-apply-myself-for-a-few-days-dangit Evergreen 1.4 release. Well - they're not really sneak previews, because of course you could check the code out of the repository and built it yourself - but it's so much easier when somebody else already has it running, right?

Anyway, my slides are available in both OpenOffice.org Impress format and PDF.

Software Freedom Day 2008 - Sudbury

I opted to do something out of the unusual (for me) this year when I learned about Software Freedom Day; I signed up to organize an event in Sudbury. Given everything that was already on my plate, it was pure foolishness to do so - but it was also important to me to try and pull together people in Sudbury with an interest in open source and free software. I'm hoping that this is just the first of many such events.

Did I mention that trying to organize an event in an academic environment during August and early September is madness? I was incredibly fortunate to land three excellent guest speakers on very short notice.

Keynote: Open Source and Open Learning

Dr. Rachel Ellaway, Assistant Dean of Education Informatics at the Northern Ontario School of Medicine, kicked off the event and instantly repaid all of the effort of putting together the whole event. In just one hour, she:

eloquently introduced the four freedoms of free software,
mapped the continuum of free software from public domain to closed source,
situated the academy and publicly funded institutions in the same philosophical category as open source,
posited that in education the process of learning was more important than the product,
introduced MIT's OpenCourseWare effort to make most of their course materials (syllabus, readings, lecture notes, assignments, and projects) freely available online,
discussed the problems of learning objects from the 80's and 90's that are now locked away in binary files that simply won't run on today's computers - and an effort named BoneYard that she is involved in to convince the rights holders to donate the source code (be it COBOL or BASIC or anything) behind these learning objects to a repository so that others can reuse the underlying algorithms and breathe new life into the objects,
questioned the continuing faith in "contact hours" as the gold standard for academic service when one hour spent developing a scenario for a virtual learning environment could engage students in multiple hours of active learning
wondered whether our institutions could move towards open administration and governance models

... all in an entertaining and engaging style. Sudbury and the Northern Ontario School of Medicine are lucky to have Dr. Ellaway in our midst.

Moodle course management software

We were also fortunate to have Dr. Rick Danielson, Full Professor in the School of Human Kinetics, on hand to discuss the history of course management software at Laurentian University and his own experiences with Ilias and Moodle. While on sabbatical in 1998, Dr. Danielson piloted the use of WebCT at Laurentian for course management and lead the creation of a purchasing consortium to license WebCT for more than 40 institutions across Ontario. A few years later, Dr. Danielson switched his personal WebCT server to the open source alternative Ilias coure management system; and, shortly after that, to Moodle. At the time, Ilias did not offer a module that supported online quizzes, and Dr. Danielson was also won over by Moodle's more refined interface. For Dr. Danielson, the choice between using the university's WebCT instance and Moodle running on his own server is all about control, saving money, and being lazy:

He craves control over his teaching environment and independence from central IT, and running his own Moodle server gives him that.
He watched the license fees for WebCT rise as it was acquired first by ULT and then by Blackboard, and doesn't mind that he has to spend some money on his own server because Moodle itself is freely redistributable
He was happy to work hard to learn how to install and administer Red Hat Linux, Apache, MySQL, and PHP in order to run Moodle - now he can be lazy because it simply works.

Dr. Danielson's talk was full of tangents and insider stories about the history of the university and Northern Ontario - quite entertaining and quite irreverent. He did a good job conveying the spirit of the early adopter of new technology to the audience, and in answer to the question of whether Laurentian's next course management system should be WebCT, he said Tuum est ("It's in your hands!").

Given that UQAM successfully automated the conversion of over 90% of their WebCT courses to Moodle (laziness is a virtue, remember), and given that we are facing a migration from WebCT to something else (the product name does not even appear on Blackboard's Web site), I hope that Laurentian will seriously consider Moodle. I have asked to be part of the evaluation committee for the next course management system here, as I want to ensure that we can provide much better integration between our library systems and our learning systems than we have today. I know that Evergreen will give us the flexibility we require on the library side; we need to ensure that we have a course management product with the flexibility that we need on the other side - and finally, we need the people willing to make the integration between the systems work and to demonstrate to faculty how they can easily take advantage of that integration.

ParaViewGeo - open source visualization from MIRARCO

The third guest speaker was Robert Maynard, lead developer for ParaViewGeo at E2VO, a subsidiary of MIRARCO. ParaViewGeo is a customized version of ParaView by KitWare. The BSD license used by ParaView gives E2VO the right to modify the software and redistribute binary versions of it without redistributing the source code; however, E2VO does plan to make most of their additions and customizations available, and has been pushing patches back to the upstream product.

Robert showed a number of screenshots that demonstrated how ParaViewGeo could transform basic two-dimensional diagrams into much richer three-dimensional visualizations. For example, ParaViewGeo can read AutoCAD files and do a far better job of displaying three-dimensional figures. Also, a CD of data produced for the Discover Abitibi initiative included a proprietary application with a license that timed out after one year, but ParaViewGeo was able to read and display the data in more detail than the original application was capable of.

Perhaps as interesting as the product was the insight that Robert provided on their software development process. Robert described how, due to a lack of students with software development skills in the Sudbury region, he opted to lead a three-week software development boot camp for their student developers starting from extremely basic principles ('let's open a file and write to it'), motivating them to achieve via competitive gaming techniques and tangible rewards ('whichever team successfully completes this problem first gets free lunch today'), group learning techniques (all seven team members worked in one large room; when a programmer hit a road block, Robert would demonstrate the solution on a projector so that all the team members could learn at once), and leading by example (Robert was always the first person in the room and the last person to leave).

Project Conifer: Open Source Academic Library System

I gave a presentation on Conifer, of course. Project Conifer is the effort to bring Evergreen to the Ontario academic libraries for Algoma University, Laurentian University and partners, McMaster University, Northern Ontario Health Integration Network, and the University of Windsor. I'm the project manager for Conifer and one of the core developers for Evergreen, so I can't possibly not talk about it on Software Freedom Day. As regular readers of this blog already know plenty about Conifer, I won't recap much here. The audience was quite impressed with the upgraded user experience that Evergreen offers out of the box over our current system, and sensed the potential for a system like this to offer integration with course management systems, integration with our inter-library loan system, and even the simple pleasures of direct physical borrowing between participating institutions.

I was also given the perfect excuse to purchase an iTouch with library or Conifer funds. One of the audience members asked if the dynamic interface supported the iPhone or iTouch, as they would like the ability to search for books or journals while in the stacks. I had to answer that I did not know, not being in possession of such a device, but was able to assert that Opera Mobile on my Windows Mobile cellphone worked extremely well. The audience member then tried out their own iTouch and determined that the interface was at least able to support search - but clearly I need to do a deeper investigation

Artificially enhanced research : free software and fantastic research

This was my mostly-demo session, which probably would have been better delivered earlier in the day while both audience members and myself were fresher, but somebody had to have the last slot in the session. I presented a few free software tools that I thought would be of interest to researchers:

LibX browser toolbar for Laurentian University: I showed that while the LibX toolbar is handy as a quick way of searching our catalogue, it's much more about embedding quick access to our library resources within your browser. I quickly got off on a tangent, however, as I was showing the Google Scholar "magic button" and had to explain what Google Scholar was, how it differed from regular Google, and answer the faculty member's question about whether he should send students to our subject databases page or to Google Scholar (my answer: "Well, both!").
Zotero research plug-in for Firefox: while LibX got their attention, Zotero got the audience buzzing. Just a quick demonstration of capturing a set of citations from a Wikipedia page, adding a note, taking a snapshot of the Wikipedia page, organizing research into folders, adding tags, and searching in full-text through your captured materials (optionally filtering by tag) was enough to get most of the people in the room interested. Zotero makes research fun - students will want to do research just so they can play with Zotero!
LU|ZONE|UL institutional repository : by this point, I was running out of time, so I tried to quickly link back to Dr. Ellaway's discussion of open access and funding agencies' new requirements to deposit articles and datasets in institutional repositories. However, after pointing out that Laurentian has actually had an institutional repository in production for over a year, one faculty member asked why we should care about depositing articles if we have access to the article through our electronic journal subscriptions? I'm not as good at answering this question as I probably should be; my answer was that it's a means of making that content available to researchers at those institutions that don't have a subscription to that journal; and that it's a means for our institution to have direct access to our own researchers' output without necessarily having to continue to pay annual licensing fees to access that ouput. I also pointed out some of the opportunities that alternate publishing formats like institutional repositories make possible; Guy Gaudreau's book Les hauts et les bas de la vie des mineurs de Kirkland Lake would not have been published with the striking colour charts he was able to include in the fully-digital version he contributed to LU|ZONE|UL - nor would he have had the ability to publish each chapter as it was finished and use the feedback to improve the rest of the book or to reissue corrections to that chapter.
Finally, I mentioned our library's quick lookup laptops which now run on Linux LiveCDs for stability, robustness, environmental friendliness, and budget purposes. They're an open source experience that our library members use on a daily basis without any apparent problems; they "just work".

So... to sum up, I believe the event was well worth the effort. We had approximately twenty participants with a mix of undergraduate and graduate students, faculty, librarians, and members of the public (including one fellow who drove all the way from North Bay to attend!). Now that I know what I'm doing, and now that we have a better idea of the interested parties on campus, I believe that we will be able to build a bigger event next year. I don't think I would hold it on a Saturday again, even if that's when Software Freedom Day is officially scheduled, because students and faculty really value their weekends. And I hope that we have more events - perhaps smaller, perhaps less formal, and perhaps more frequent - throughout the year.

Finally, I want to thank the team of people at the J.N. Desmarais Library that helped me to make this event possible, in no particular order: Leïla Saadaouai, Dorothy Robb, Christine Guerra, Noella Cliche, Ashley Thomson, and Joscelyne Meilleur. Your efforts were certainly appreciated by our participants today.

Heating up Evergreen search

So, after loading 3.7 million records into the Project Conifer test server, we have found that search can be slow. Not really a big surprise, because I've spent very little time tuning the database beyond running a VACUUM FULL and tweaking just a few parameters. But one of the extremely useful hints that Mike Rylander gave me about PostgreSQL a long time back is that it relies primarily on file system caching to cache access to data, from the reasonable perspective that your file system already knows which files are being accessed most often. PostgreSQL's data is stored in files that map back to individual tables and indexes; unlike some other database systems that I've worked with, you don't dedicate system memory specifically to caching those database files (hello, DB2 buffers!); instead, you just trust the file system to know what's best.

That caching approach works great on a system that's in production and getting a steady stream of queries reflecting what users actually search for on a day to day basis. However, if you've just loaded a test system, then it doesn't have much opportunity to cache and the first dozen (or hundreds, or thousands!) of queries will be slow as your database goes out and loads up files from disk. Even worse, if you have a system like ours where backups have temporarily been set up as "tar czf /backups/backup.tar.gz /", then on a nightly basis your file system cache is going to be filled with all kinds of irrelevant data.

So what are we to do? Well, actually, another extremely useful hint that Mike Rylander gave me was to just run the pertinent data files through /dev/null to load up the file system cache. On the surface, it seems like a dirty hack, but it's a smart one, and we can even make it elegant. Let's walk through the process:

You need to know where your data files are. You (or your system installer) will have created a PostgreSQL cluster. In my case (on Debian Etch), I can find it at /var/lib/postgresql/main/base. Then, by running "du -hs /var/lib/postgresql/main/base" I can see that one of our databases (represented by a directory name that's just an integer - "16385") weighs in at 60GB. That's our 3.7 million record baby. If you run an "ls" command on that directory, you'll see that it's filled with hundreds of files of differing sizes, most of them with just plain integers for their names. This is where the data is stored.

You need to know the base filenames that you want to use to warm up the file system cache. For my first stab at this, I decided to warm up the cache with the full-text search indexes, as I know those are frequently used by Evergreen's search. To figure out the base filenames for these indexes, we can query PostgreSQL's catalog of its own objects:

evergreen=# SELECT relfilenode, relname, relpages
evergreen-# FROM pg_class WHERE relname LIKE '%vector%';
 relfilenode |                   relname                    | relpages 
-------------+----------------------------------------------+----------
      648864 | authority_full_rec_index_vector_idx          |    59282
      649137 | metabib_title_field_entry_index_vector_idx   |    29766
      649149 | metabib_author_field_entry_index_vector_idx  |    20125
      649161 | metabib_subject_field_entry_index_vector_idx |    23481
      649173 | metabib_keyword_field_entry_index_vector_idx |    90709
      649185 | metabib_series_field_entry_index_vector_idx  |     8682
      649210 | metabib_full_rec_index_vector_idx            |   452980
(7 rows)

relfilenode is the basename of the files that we want to load into the file system cache.

The maximum size of your file system cache cannot be more than the physical RAM installed on your system, so you'll want to tally up the size of the index data files to ensure that their total is less than the total amount of your physical RAM. Note that in the example from our system, below, I'm using "*" because database objects with lots of data will be split between multiple files with extensions like ".1" and ".2" in sequential order:
```
# cd /var/lib/postgresql/main/base/16385
# du -hs 649185* 649210* 1065608*
68M	649185
1.1G	649210
1.1G	649210.1
1.1G	649210.2
1.1G	1065608
1.1G	1065608.1
1.1G	1065608.2
842M	1065608.3
# du -hs 649207*
1.1G	649207
1.1G	649207.1
1.1G	649207.2
467M	649207.3
```
Adding all of this up, we're getting close to the 16GB of RAM installed on our database server. If we add any more data, we will want to add more RAM to the system.

Now we warm up the cache by outputting the contents of each file into /dev/null.

# cd /var/lib/postgresql/main/base/16385
# cat 648864* > /dev/null
# cat 649137* > /dev/null
# cat 649149* > /dev/null
# cat 649161* > /dev/null
# cat 649173* > /dev/null
# cat 649185* > /dev/null
# cat 649210* > /dev/null

After running through this relatively simple exercise, searches were definitely much snappier on our test system. I plan to automate the process so it runs after every one of those cache-killing backups. If there is interest, I could package it into a simple Perl script that other sites could use to assist with their testing - or to help warm up the file system cache after a large data load, for example.

Academic reserves for Evergreen: request for comments

I've posted a second revision of the "academic reserves" requirements RFC. I'm not looking to boil the ocean with the first iteration of academic reserves for Evergreen (that's what third-party systems like ReservesDirect and Ares are for), but I am hoping that by engaging the community in a discussion we can ensure that we build something that satisfies the core set of requirements for academic institutions in the area of reserves. My lack of familiarity with what other institutions with more capable systems, or with local workarounds or third-party reserves systems installed, makes me nervous that I'm missing something obvious. So if you feel like weighing in on the discussion, please address your comments to the Evergreen General mailing list, add a comment here, or send me email if you prefer to keep your comments private.

The biggest change in the second revision of the RFC is the inclusion of a base set of requirements for electronic reserves. For physical items alone, the requirements expressed in the RFC go far beyond the capabilities of the ILS we currently use at Laurentian; getting even basic support for electronic reserves in Evergreen would be a huge win for us when we migrate.

That said, I'll probably start working on implementing a subset of the requirements real soon now; it should be easy enough to make a course correction should something significant turn up during the second round of comments.

(unofficial) bzr repositories for Evergreen branches

I wrote a long blog post about the distributed version control workflow that the two Laurentian students working on Evergreen (Kevin Beswick and Craig Ricciuto) are using successfully this summer, only to lose the post to a session timeout and my own lack of caution (note to self: if writing directly in the browser text field, CTRL-A CTRL-C before hitting preview!). So the gist of the blog post was:

bzr, with the bzr-svn plugin, works quite well for cloning and updating from a centralized Subversion repository like Evergreen's; just watch out for memory consumption issues due to memory leaks in the Python bindings for Subversion (fixed in the development version of bzr-svn)
there's no compelling reason for Evergreen to move to a different version control system; it's easy to use a distributed version control workflow with the Evergreen Subversion repository as-is
you can tar up a bzr branch and untar it where ever you like and "bzr up" will immediately happily work (which is how I worked around the severe memory constraints on this server that ended up repeatedly running into the Linux out of memory killer when I was trying to create a bzr-svn checkout from scratch)
it's a hell of a lot faster to check out or branch from a bzr repository than it is from a Subversion repository, so if you're going to take this approach set up one clean bzr repository using bzr-svn and check out or branch from that using bzr, rather than repeatedly using bzr-svn to create new branches

To enable you to get a bzr repo of Evergreen quickly, I've set up (unofficial, of course, but updated hourly) bzr repositories of the most useful Evergreen branches as follows:

Evergreen trunk
Evergreen acq-experiment (acquisitions and serials branch)
OpenSRF trunk

Enjoy!

eIFL-FOSS ILS workshop on Evergreen, day one

The following summary is taken almost directly from an email I wrote to one of the would-be participants who was, sadly, prevented from making it to Yerevan due to travel complications. I meant to clean this up earlier and post it, but have not yet found the time - so I might as well just post it as is with most names obfuscated and possibly some additional editorial comments. Those who are new to installing and configuring Evergreen might find this useful; and reading through it, I remembered a few challenges I planned to tackle

Shortly after I arrived on Monday, I was able to try out the install of Evergreen 1.2.1.4 that A. and G. from the Fundamental Science Library (FSL) had completed with only two email exchanges with me. I was very happy to see that they had successfully completed the install! There was only one minor problem with the structure of the "organizational unit" hierarchy that I had to fix. After that, we confirmed that we were able to import bibliographic records from Z39.50 and attached call numbers and copies to those records. Finally, we tried searching for the records in the catalogue and were delighted to see that everything was working as we had hoped. That allowed me to sleep well on Monday, in preparation for the first day of the workshop on Tuesday.

After the introductions of the workshop participants on Tuesday, I gave the introduction to Evergreen presentation and Henri Damien Laurent of BibLibre demonstrated Koha. Both Henri Damien Laurent and I showed our respective library systems running with an Armenian interface, thanks to the translation efforts of Tigran! Then we broke into separate Koha and Evergreen groups to work together on our respective library systems. Of the attendees of the workshop, E. was the most interested in migrating his library (with 40,000 volumes) to Evergreen. A., from one of the 29 branches of the American University of Armenia (AUA), also attended most of the Evergreen session. Even though his institution is mostly interested in Koha, he wanted to be able to compare the two systems. Albert's colleague S. attended the Koha training session so they would be able to compare their experiences later. Our group also had R. from the Netherlands and A., G., and A. from FSL -- apparently Tigran is considering running Evergreen as a union catalogue, so his IT people are very interested in learning more.

Our first exercise was to model the organizational unit hierarchy using the configuration bootstrap interfaces in the /cgi-bin/config.cgi. We began by drawing the hierarchy on a whiteboard. The "Yerevan Consortium" represented the Evergreen system as a whole; we added the FSL, MSU, and AUA systems as children of the Yerevan Consortium, and then added specific branches as children of each of these systems. While we were creating this hierarchy, I showed the participants how the organization unit type defines the labels used in the catalogue as well as the respective depth in the hierarchy for each type.

We then ensured that the systems and branches in the hierarchy had the right types, and that the types were defined with valid parent-child relationships. We found a few types that were children of themselves, which causes a problem in searching. There was also some confusion about the role of types to organization units, resulting in the creation of types with labels like "FSL" rather than "Library System". After a few minutes of explanation and working through correcting the exercises, I think the participants were better able to understand the relationship between types and organization units.

After we were satisfied with the structure of the organization unit hierarchy, I ran the autogen.sh script to update the catalogue and staff client representations of the hierarchy. Well, first I demonstrated how search in the catalogue will quickly be broken if you do not run the autogen.sh script

Our next step was to register new users with the Evergreen staff client. This helped introduce the participants to the staff client, as well as giving them a quick introduction to some parts of Evergreen that still need to be localized to allow regional variations on postal code formats, telephone numbers, and forms of identification. The default Evergreen staff client still enforces American conventions, but fortunately I have had to create patches for Evergreen to support my own country's standards so I can assure you that it is relatively easy to change or remove these format checks. In the future, it would be wonderful to include a localization pack for each locale interested in using Evergreen that supports regional variations on date formats, phone number patterns, etc. The participants were pleased with the feedback mechanism in the staff client that summarized all of the remaining problems with the current patron record (missing address, invalid phone number, etc) and made it easy to switch between screens without losing any of the data they had already entered.

Once we had registered new users for each of our branches, we went to work importing new bibliographic records and attaching call numbers and copies to those records. This gave us a good opportunity to see how changing the scope of a search in Evergreen from "Everywhere" down to a specific branch changes the search results, and demonstrated how the organization type labels are displayed in the catalogue. As an aside, I should point out that in Evergreen 1.4 (due by the end of this summer), the labels are internationalized so that different labels can be displayed depending on the locale in which you are using the catalogue or staff client. Good news for those of us who work in bilingual or multilingual libraries!

Now that we had records with copies attached and patrons registered in our Evergreen instance, we were able to use the catalogue's "My Account" features to try out features like sharable bookbags, account preferences, and the account summary. Users also have the ability to specify their own user names and to log in with those instead (which means that they can simply remember their unique nickname rather than, say, a 14-digit barcode).

The first feature that the participants discovered, of course, was the strong password enforcement feature. When a patron is registered, the system automatically generates a random 4-digit password; however, this is not considered to be a safe password, so when they log in they are forced to change it to a longer password containing both numbers and letters.

At this point, we also discovered a data validation bug: in the staff client, it is possible to enter a user barcode that consists of letters and numbers. However, in the catalogue, user barcodes containing letters are considered invalid and the system will not even attempt to log that user in; it simply rejects the barcode. I plan to ask E. to report this bug to the Evergreen mailing list; it would be an excellent outcome of the workshop if participants felt comfortable reporting problems to the mailing list, and reporting this problem in particular would help improve the quality of Evergreen.

Things were going reasonably well, but we noticed that the system was running into a problem if you tried to edit a bibliographic record after you had already created or imported the record. I had rather fortunately already experienced this problem (it is a result of different behaviour regarding XML namespaces between different versions of LibXML2) and knew that it had been fixed in 1.2.2.1. So rather than trying to fix the problem with the installed version of 1.2.1.4, I decided to try upgrading our Evergreen system to the recently released 1.2.2.1 to demonstrate to the participants that the upgrade process was fast, reasonably well documented, and not nearly as complicated as the install process. This was, by the way, something Randy had urged me to do, so I blame him for the subsequent problems we experienced (hah!).

The first problem is that the change from 1.2.1.x to 1.2.2.x requires the installation of a new Perl module from CPAN (JSON::XS). This is not much of a problem in itself, as the module is very easy to install and compile; however, given our internet connection I had to wait a long time for the CPAN repository metadata to be downloaded. The participants were still able to use the system while this was happening, but we ended up hitting the coffee break still waiting for CPAN to finish. (As an aside, Irakli and I were discussing the possibility of having the eIFL-FOSS coordinators investigate setting up local mirrors of FOSS resources like CPAN to speed up access to frequently used resources).

When we returned from the coffee break, the JSON::XS install had finished but the participants were having problems searching and using the staff client. I checked the logs (using the "grep ERR /openils/var/log/*" command to start with) and saw that our database connections were dying for some reason. On a hunch, I checked the system logs ("dmesg") and discovered that the Linux "out of memory (OOM) killer" had started killing random processes to try to free up memory. It was killing the PostgreSQL processes, the Evergreen processes - anything! I was lucky, because I had been reading about the OOM on Linux after hearing about a Linux user that had run into a similar problem, and knew that the way to disable the OOM was to prevent Linux from overcommitting memory to processes in the first place. Wondering why our system had started running out of memory in the first place, I ran "free" and saw that it had been set up with no swap space; I confirmed this by running fdisk to see that there were no swap partitions. Here, however, I made a mistake. I ran "echo '2' > /proc/sys/vm/overcommit_memory" to prevent Linux from overcommitting memory to new processes and to prevent the OOM killer from killing any more random processes. But this also meant that I was immediately unable to launch any new programs - so I could not safely shut down PostgreSQL and Evergreen, and we had to turn the power off to the system.

Fortunately, the system started up cleanly again (hurray for journalled filesystems) and I was able to complete the upgrade before the rest of our hands on session for the day was finished. A few things that are missing in the current upgrade instructions:

You have to compile the new version of Evergreen. The easiest way to do this is to copy install.conf over from your previous version of Evergreen and run "make config" to ensure that all of the settings are still correct, then run "make" to build the new version of Evergreen.
Very important: Before installing the new version of Evergreen, you must prevent the database schema from being completely recreated or it will destroy any data that is already in your system. One way of doing this is, during the "make config" step, to list all of the Evergreen targets except for openils_db. I am simply incapable of remembering all of those targets, so my dirty workaround is to open Open-ILS/src/Makefile in an editor and modify the "install: " make target by removing the "storage-bootstrap" make target. What we really need is an "upgrade" target for "make config" that simply installs everything except for the database schema.
Confirm that the new version of Evergreen has been installed by running the srfsh command "request open-ils.storage open-ils.system.version".

For tomorrow (today, by the time you receive this), A. and G. are going to create a swap file to enable the system to swap memory to disk if need be; the system has 1 GB of RAM, which is enough for a small Evergreen system but when one is compiling programs at the same time as running Evergreen swap space really is necessary. This was a very good lesson learned for all of us!

E. also interested in learning more about basic Linux administration. His institution currently runs on an entirely Windows infrastructure, so the requirement to learn Linux is a fairly high hurdle. I'm hoping that the eIFL-FOSS list will be a good resource for him to start that journey. He has also asked to go over the step-by-step instructions for installing Evergreen, so I'm considering starting that in a VMWare session so that we can run through the steps. Our major goal for tomorrow is to migrate some data from FSL's legacy system into Evergreen. Wish us luck!

Editorial comment: The combination of Armenian and Russian MARC records refused to load into the Evergreen 1.2.2.1 system, but on the flight home I confirmed that they loaded perfectly and were searchable on my Evergreen development system. As the development version will become this summer's 1.4 "internationalization" release, we are in good shape.

Editorial comment 2:On the second day, while running in circles trying to figure out why the records were refusing to load into the 1.2.2.1 system, I decided to try the #openils-evergreen IRC channel. Yerevan is 9 hours ahead of the Toronto/Atlanta time zone, so at noon Yerevan time I was hardly expecting any of the current core Evergreen developers to be online - yet, to our amazement, Mike Rylander responded. This was a pretty convincing demonstration to the attendees that the core developers really aren't far away or hard to contact at all.

Get out of jail, go free, part I

As Mark Leggott mentioned in Vendor to Open Source ILS in 1 Month #1, I had the pleasure of assisting the migration of the University of Prince Edward Island library system from Unicorn to Evergreen. A little over a year ago, in discussing the business case for open source library systems, I stated that one of the problems we faced with migrations is that the license for a proprietary system often inhibits openly sharing of information about how to export data from those systems in machine-usable formats. Thus, the open source library community needs to encourage the development of "migration ninjas". Little did I know that I would soon join the guild of ninjas and become deadly and silent, and unspeakably violent(1)(2).

As a result, I have created a utility script that should be of assistance to SirsiDynix Unicorn or Symphony sites who are interested in exploring the possibilities offered by other library systems. The rather dryly named "export_unicorn.pl" script was added to the Unicorn API repository as entry # 228 today under a GPL v2 license(3). As the script uses the Unicorn/Symphony API, however, I am sadly (to the best of my knowledge) not free to simply share the script with anyone. Therefore, to gain access to the script you must be an API-certified Unicorn or Symphony customer. Still, by making an export script available to SirsiDynix customers that provides the raw data in a relatively standard output format, it should ease the effort required by the migration ninjas for open source systems to massage the data into the needed input formats, and to avoid the tetsu-bishi scattered by the proprietary systems in defence of "their" data(4)(5).

Barenaked Ladies, "The Ninjas". Their website is horrible Flash and JavaScript overkill but damnit Jim, they're musicians, not webmasters; the "Snacktime" album is especially recommended if you have kids.
Although I have to say I'm nowhere near as violent as Mike Rylander, who with his PostgreSQL-fu can carve seemingly any piece of data into the shape needed for import into Evergreen.
Thanks to Mark Leggott for insisting that I retain copyright over the scripts created during the UPEI migration and for allowing me to share those scripts in the appropriate avenues. It's another weapon (shuriken? ninja-to?) in the migration ninja arsenal.
This data does, after all, belong to the libraries who license a library system, but at least one company reportedly has a pattern of repeatedly removing interfaces that enable easy machine-readable access to library data...
I find myself being thankful that Unicorn does provide an API for generating machine-readable data exports; all that it cost our library was a week of my life and the associated training fees and travel expenses

Introduction to Evergreen at eIFL-FOSS ILS workshop

I was in Armenia last week, leading a workshop on open source library systems along with Henri Damien Laurent from BibLibre. My charge was to introduce Evergreen and lead participants in two days of hands-on experience with the system; Henri took on the same task for Koha. I cannot say enough good things about our host for the workshop, the Fundamental Library of the National Academy of Sciences of Armenia headed up by Tigran Zargaryan; nor can I offer enough compliments to Randy Metcalfe on his skills in ensuring that everything ran smoothly; nor can I express how rewarding it was to meet representatives of so many different countries and how much I enjoyed their company! I look forward to helping the pilot sites succeed with their implementations.

So, for the short term, I'll simply link to the "Introduction to Evergreen" presentation that I gave at the start of the workshop in OpenOffice and PowerPoint formats (as I promised to the participants). In the next day or two I plan to post a summary of the workshop activities; some of the lessons learned; and where I think I'll focus my attention next.