Terry’s Worklog

In LibraryFind 0.9, the UI has been enhanced to include a number of small niceties (things that have been flowing into the 0.8.x branch — but are enhanced in 0.9).  Things that you will find in LibraryFind 0.9 is Cover Art (which can be pulled from Open Library, Google or Library Thing [Open Library is the default]) as well as links to full text documents currently available in Google and Open Library.  It’s all part of making it easier for users to get access to full-text, online resources.

(Screenshot with coverart):

–TR

A number of changes that will be present in LibraryFind 0.9 will be UI related.  One of those changes will be seen in the Advanced Search page.  The layout of the page has been changed significantly to make it easier for users to specify specific (or combined) queries, as well as make it easier for users to select the materials that they want to query.

–TR

During the past development cycle, one of the most often requested items by our students and faculty has been the ability to watch a query for an extended period of time.  In 0.9, this will be possible.  At any point, a user can create an RSS feed of a specific search and add it to their feed reader.  At this point, that output looks like the following:

–TR

One of the main UI complains with the 0.8.x branch of LibraryFind relates to what happens after the user searches.  Since LibraryFind must collocate all the search results together before display, what happens as the user waits (or doesn’t happen) has been an admitted weakness of the program.  That will change in 0.9.  In 0.9, users will see what’s being queried, number of results, and have the option to kill the search at any time and view the results that have already been found.  One additional benefit of this method has been in terms of thread lock.  In 0.8.x, a single mongrel instance is locked until a query is completed.  This is because the interface never refreshes, but waits for the query to complete.  In 0.9, the UI uses micro-queries, hitting the server for short periods of times, allowing mongrels to answer a quick request and then move on.  A quick comparison:  In 0.8.x, a single query typically takes approximately takes 6-10 seconds to complete (depending on # of targets queried).  In the previous model, a single mongrel thread is locked for the entire duration of this query.  In 0.9, the average query on the server is 0.005 seconds.  While the 0.9 interface makes more queries to the server, these are separate queries, allowing the server to better manage how its pack of mongrels are used and eliminating the thread locking that would take place during queries. 

While the UI may change slightly as I finalize the 0.9 interface, here’s a snapshot of what this looks like now:

If you have questions about this, or other LibraryFind development, just give me a holler.

–TR

See: http://libraryfind.org/node/91 for information on what that entails.  LibraryFind 0.9 is on track for the first of the year.

–TR

The boys got me out of the house this weekend and we picked up our tree.  They’d been itching to get the presents laid out.  Of course, the other person happy to see the tree is the cat.  He seems to believe that we brought this tree in the house just for him, because he’s been climbing all over the tree (though, he hasn’t taken any of the ornaments off yet).

–TR

(he’s hard to see, but the cat is in here)

I know that its a little early, but the boys are excited.  Today, we got a little bit of snow (enough that the boys get off of school tomorrow) and they say that it won’t get above freezing all week — so it maybe sticking around. 

I’ve never, ever had a white Christmas, so we are all crossing our fingers.

–TR

As I’ve been working on 0.9, I’ve been trying to migrate few odds and ends into the current 0.8 branch so that I can move them into production faster on our end.  To that end, I’ll be posting an updated to LF by the beginning of next week.  These updates will include:

1. Update to the Harvester (this will make it a bit more fault tolerant) as well as allowing harvesting of sets (currently) and root level oai providers (not provided currently).  This change required significant changes to the search component as well that deals with the harvested materials.
2. Auto-detection of namespaces (for oai and sru — needed for libxml)
3. Removed rexml dependencies for opensearch component
4. Frozen gems for oai, sru and opensearch into vendor directories (and have added that to the environment.rb file)
5. Prep code for solr/ferret decision.  I’ll be adding support to use either ferret or solr as your backend indexer for harvesting for 0.9, but some changes are being made to make this easier.  Ferret provides an integrated rails solutions, while solr would provide a hosted index option.
6. In addition to this, some changes to the libxml module have deprecated a call being used in the oai gem (maybe the sru gem).  I’ll take a look at both this week and update appropriately [as well as keep backworks compatibility if possible]

Something else, we are starting to work with mod_rails.  This allows apache to manage the rails environment — eliminating the need to run rails through packs of mongrels (or other specialized serving mechanism).  I’ll write up something on our experiences for others that might be interested in this approach.

–TR

So, over this past year, I’ve watched the Beaver’s Football team go from awful (Stanford and Penn State) to great (USC) to inspired as they ran through the Pac-10.  In fact, like many season ticket holders, I was making my Rose Bowl plans because, well, all we had to do was beat a very flawed Oregon team in the Civil War — which…didn’t happen.  Instead, it was 3 1/2 hours of pain as the Beavers teased me throughout the game before ultimately losing.  So sad.

Well, I have a friend that thought I needed some cheering up.  So, he sent me this joke.  Here it is… 

How do you make Beaver Cookies?
Beat well for 3 1/2 hours and then take out of big bowl.

Funny — well, no.

–TR