This collection of work notes is mostly about the changes, successes, and triumphs of my work on the GVSU Libraries web presence. But not everything goes smoothly. Here are a few things I screwed up on this week, how I fixed them, and how I’m trying to prevent things like this in the future:
When I first redesigned our link resolver with the 360Link Reset script, I used a custom link that Serials Solutions had embedded into our default link resolver template to send folks to Document Delivery. The link was simply an OpenURL, but it was all nicely formatted and it made life easier (for me) to use it. As the number of other libraries using the script continued to increase, the lack of out-of-the-box support for this common workflow from link resolver to requesting an article became a headache. So when I rewrote the script a few weeks ago, I added custom OpenURL support for document delivery and citation managers, mostly to make it easier for other libraries to use the script.
I tested it a lot, but, as I later learned, not enough. I sort of broke OpenURL requesting from the link resolver to Document Delivery.
The script first scrapes the existing page for citation information, and then takes those goodies and puts them in a (mostly) proper APA citation. The thing is, to prevent citations from having stray punctuation marks when certain values weren’t set, I added the appropriate punctuation to the values themselves, so that the variable date wouldn’t just read “1996-03-01” or “3/10/2001” or “1987”, but would have parentheses: (1996-03-01), (3/10/2001), and (1987).1 Now, I was using these same values for the OpenURL to request items through Document Delivery (and for citation export). In Document Delivery, then, Illiad would show “(1987)” as the date value instead of just “1987.” (And RefWorks would add the punctuation to your citation record, too.) While a person reviewing the request can easily read both as 1987, the computers that process our requests aren’t prepared to handle the punctuation. And so RapidILL and even OCLC requests were failing because to a computer, a parenthesis is not a valid date character.
I pushed a new change to the code live this morning that fixed the issue, and hereby publicly apologize to Vicki for all the extra work she had to do over the past few days because of a few stray punctuation marks! (I owe you a coffee.)
Sometimes when I’m testing code on my local machine, I’ll make changes happen in the code of a page so I can quickly see the results of a particular “if this, then that” test. Yesterday while working on a few bugs in my Request Button Magic script, I was trying a new test to identify whether an item was either Reference material or in our Special Collections (and in which case it should not be requestable).2 If the test was successful, I had the script change the color of the item record listing to red. I hadn’t gotten the test quite right, but I committed my changes to our version control software so I could run to a meeting.
That’s the right thing to do. But out of habit, I immediately pushed those changes up to Github, and then deployed the code to the catalog. So for about 12 hours, the catalog had no request buttons and the text for every listing was red. This was a big issue!
This morning I fixed the issue right away (and fixed the original bugs at the same time). But it was a good reminder to me to watch out for reflexive workflows. Another public apology to everyone who needed a request button yesterday or didn’t want to see red text on an OPAC screen! (And thank you to the four folks who reported it to me right away: Vicki, Deb, Sara, and Donna - I owe you all coffees!3)
It’s one thing to publicly acknowledge that you screwed up, but I’m going to put a few things into place to try to avoid big problems like this in the future.