Browser/Javascript Integration Testing with Ruby

• Jessie Keck, Stanford University, jkeck at stanford dot edu

It's near impossible to build a rich web application without javascript. We have a lot of great patterns to follow, such as progressive enhancement, to make sure our rich web applications are usable, accessible, and testable. However; when javascript is involved the possibility exists that bugs can be introduced that won't get caught by most unit and integration testing frameworks.

This is where Watir (pronounced water) comes in. Watir can be used with popular ruby testing frameworks like RSpec and Capybara. This talk will show how to use the combination of these tools to write RSpec tests using Watir to spin up an application in a variety of browsers, navigate the application, and make assertions about the page using Capybara.

Tests using Watir are written in ruby but they don't necessarily need to test ruby application. You can test any application that you can point a browser at, so there are a wide variety of potential uses for tests written with Watir.

• Esme Cowles, UC San Diego Library, escowles AT ucsd DOT edu
• Matt Critchlow, UC San Diego Library, mcritchlow AT ucsd DOT edu
• Bradley Westbrook, UC San Diego Library, bdwestbrook AT ucsd DOT edu

Slides, Video

REST IS Your Mobile Strategy

• Richard Wolf, University of Illinois at Chicago, richwolf@uic.edu

Mobile is the new hotness ... and you can't be one of the cool kids unless you've got your own mobile app ... but the road to mobility is daunting. I'll argue that it's actually easier than it seems ... and that the simplest way to mobility is to bring your data to the party, create a REST API around the data, tell developers about your API, and then let the magic happen. To make my argument concrete, I'll show (lord help me!) how to go from an interesting REST API to a fun iOS tool for librarians and the general public in twenty minutes.

Download the video

How to be an effective evangelist for your open source project

• Bess Sadler, Stanford University Library, bess@stanford.edu

The difference between an open source software project that gets new adopters and new contributing community members (which is to say, a project that goes on existing for any length of time) and a project that doesn't, often isn't a question of superior design or technology. It's more often a question of whether the advocates for the project can convince institutional leaders AND front line developers that a project is stable and trustworthy. What are successful strategies for attracting development partners? I'll try to answer that and talk about what we could do as a community to make collaboration easier.

Download the video

The Care and Feeding of a Crowd

• Shawn Averkamp, University of Iowa, shawn-averkamp at uiowa.edu
• Matthew Butler, University of Iowa, matthew-butler at uiowa.edu

After a low-tech experiment in crowdsourced transcription grew into a surprisingly successful library initiative and demanded new commitments to user engagement, we found ourselves looking for a more efficient and user-friendly solution. We customized CHNM’s Scripto community transcription tool and various other Omeka plugins to develop a new site: DIYHistory.

We often receive questions about the technical side of both platforms, usually (to our dismay) from libraries who already assume they don't have the IT resources to pursue their own crowdsourcing initiatives. But we found that the software makes up only half of the recipe for success. Do you have compelling content? A long-term commitment to engaging with your users? Are you ready to promote your project far and wide? If so, then deploying a crowdsourcing initiative may be easier than you think.

Hands off! Best Practices and Top Ten Lists for Code Handoffs

• Naomi Dushay, Stanford University Library, ndushay@stanford.edu

Transition points in who is the primary developer on an actively developing code base can be a source of frustration for everyone involved. We've tried to minimize that pain point as much as possible through the use of agile methods like test driven development, continuous integration, and modular design. Has optimizing for developer happiness brought us happiness? What's worked, what hasn't, and what's worth adopting? How do you keep your project in a state where you can easily hand it off?

Download the video

Hybrid Archival Collections Using Blacklight and Hydra

Slide presentation

Citation search in SOLR and second-order operators

• Roman Chyla, Astrophysics Data System, roman.chyla AT (cfa.harvad.edu|gmail.com)

Citation search is basically about connections (Is the paper read by a friend of mine more important than others? Get me a paper read by somebody who cites many papers/is cited by many papers?), but the implementation of the citation search is surprisingly useful in many other areas.

I will show 'guts' of the new citation search for astrophysics, it is generic and can be applied recursively to any Lucene query. Some people would call it a second-order operation because it works with the results of the previous (search) function. The talk will see technical details of the special query class, its collectors, how to add a new search operator and how to influence relevance scores. Then you can type with me: friends_of(friends_of(cited_for(keyword:"black holes") AND keyword:"red dwarf"))

Evolving Towards a Consortium MARCR Redis Datastore

Slide presentation

n Characters in Search of an Author

• Jay Luker, IT Specialist, Smithsonian Astrophysics Data System, jluker@cfa.harvard.edu

When it comes to author names the disconnect between our metadata and what a user might enter into a search box presents challenges when trying to maximize both precision and recall [0]. When indexing a paper written by "Wäterwheels, A" a goal should be to preserve as much as possible the original information. However, users searching by author name may frequently omit the diaeresis and search for simply, "Waterwheels". The reverse of this scenario is also possible, i.e., your decrepit metadata contains only the ASCII, "Supybot, Zoia", whereas the user enters, "Supybot, Zóia". If recall is your highest priority the simple solution is to always downgrade to ASCII when indexing and querying. However this strategy sacrifices precision, as you will be unable to provide an "exact" search, necessary in cases where "Hacker, J" and "Häcker, J" really are two distinct authors.