Lumen: A port of Blacklight to Scala and the Play framework

I’ve done some work the past two years using Blacklight, a great discovery interface for Solr with a lot of library catalog features. It’s quality software with years of work invested in it by some very smart people.

Over time, “the Ruby way” of doing things, as well as “the Rails way,” has bugged me more and more. Things like the use of naming conventions for hooks, passing arrays and hashes around in lieu of actual data structures, the varying use of hashes and OpenStructs, the ability to monkey patch, the difficulty of looking at a method and not being able to tell what its arguments are or can be, the need to go digging around in the source code of a gem to figure out how certain APIs are dynamically created because those methods can’t get automatically documented by tools like rubydoc or yard. These things often make life easier when you’re writing new code and trying to do it quickly, but they create nightmares when you try to refactor stuff or upgrade gem dependencies.

The last few months, I’ve been slowly porting Blacklight to Scala and the Play framework. I’m calling this new project Lumen.

Scala is a powerful statically typed, compiled language that permits you to mix object-oriented and functional paradigms, and it allows you to take advantage of the enormous ecosystem of existing Java libraries. It also incorporates some of the innovations of the last two decades of dynamic languages that make programmers happy. I think it’s a language that privileges software quality over rapid development.

So far, Lumen has been a hobby project to learn Scala, so I’ve approached it in a less disciplined fashion than I otherwise might. This means there are lots of TODOs scattered throughout, and style/design inconsistencies as I’ve learned better ways to do things but haven’t always gone back to change things everywhere. That’s life when you’re noodling around in your spare time. Lumen is largely an experiment right now, but I hope it will eventually grow into a full-featured, production-quality piece of software. We’ll see.

You can check out a demo here:

Upgrading the Touchpad on a Thinkpad x240

This is a stock photo of a Thinkpad x240, stolen from the interwebs:


This is my own x240, which I bought back in January 2015.


If you know about Thinkpads, you probably noticed the difference right away. The x240 (and other models that year) suffered from an incredibly crappy buttonless touchpad. It’s so bad that it’s barely usable. Clicking is ridiculously inaccurate: there’s so much travel that the mouse pointer moves during a click, and there are no buttons to use instead. There were so many complaints that Lenovo replaced it with a better one in the next year’s lineup.

This weekend I finally got around to upgrading it with a touchpad replacement part for the x250. It cost $32 on ebay. This modification is popular, so you can find info about it scattered around in forums and such. I followed the instructions on this page, How to change an x240 trackpad, as it’s one of the clearest ones out there. I couldn’t find much info about the author, whose name appears only as “Michael” on that blog.

Some notes and tips from my experience:

1) Michael’s picture shows a set of wires connected to the touchpad along its side, but mine didn’t have them.

2) The touchpad sits in a well, held in place with adhesive tape, so to remove it, you just pry it off. The problem is that it’s hard to reach “under” the entire touchpad assembly, which is sort of like a sandwich with layers. I ended up partially prying off the top layer before I could get to the bottom and pry the whole thing from the case. Needless to say, this bent the touchpad.

I couldn’t figure out a way to avoid effectively destroying the old touchpad. But since it was so crappy, it was also somewhat satisfying.

3) Detaching and re-attaching the small ribbon cable from/to the underside of the touchpad is VERY tricky. The end of the ribbon is held in place to the connector on the touchpad by a thin black “latch” sitting just behind it. You CANNOT just yank the ribbon out. (This took me a while to figure out!) Lift the black latch, and the ribbon will slide from the connector easily. When connecting it to the new touchpad, tuck the ribbon end securely into the connector, then flip the latch down to lock it in place.

4) At first, the new touchpad wasn’t being recognized by the machine. It worked after I re-seated the ribbon in the connector and also reset the BIOS (as shown in this video: stick a paper clip end into the tiny hole beside the battery and press for 20 seconds). I should have tried those things separately, but got a bit too excited. So you may or may not have to do a BIOS reset.

So far so good. The new touchpad is definitely a big improvement. There’s much less click travel using the pad, and it feels snappier. I really like having the buttons.

The only quirk is that the surface of the touchpad now sits just a hair higher than the palm rest. It’s probably slightly more likely for my hand to accidentally brush it while typing, as compared to the original touchpad, but only time will tell for sure.

It feels like a totally different computer.

“Proxy mode” added in refine_viaf 1.4

A refine_viaf user recently commented that she would like to get Library of Congress IDs for the name candidates in OpenRefine, instead of VIAF IDs.

It would be ideal if the name IDs for LC and other sources could be additional fields in the JSON data returned from refine_viaf, which you could then extract using some GREL code. Unfortunately, OpenRefine doesn’t allow you to access additional fields on name candidate objects.

So I’ve created a separate “proxy mode” that returns IDs used by source institutions themselves, rather than the VIAF IDs. To use proxy mode, add a reconciliation service in OpenRefine using this URL format instead of the usual URL:

One quirk is that OpenRefine will create broken hyperlinks for a few sources (at the moment, these are BNC, BNF, DBC, and NUKAT). This is due to the fact that the IDs in these URLs don’t match the name record IDs, which is a requirement for the hyperlinking mechanism to work properly.

In short, you can now use refine_viaf to reconcile “directly” against the name authority records of VIAF’s source institutions, which should be useful to many people.

Goodbye, Sublime Text?

When one of my coworkers started using Sublime Text about a year ago, I was intrigued. I played with it and found it to be a very featureful and speedy editor. I wasn’t compelled enough to make the switch from Emacs, though. (You’ll pry it from my cold dead hands!) But I really liked the fact that you could write plugins for it in Python.

So for fun, I gradually ported my emacs library, which integrates with a bunch of custom development tools at work, to Sublime Text. It works very well, and the ST users in the office have been happy with it. Although I don’t actually use ST regularly, I’ve since been following news about its development.

What I discovered is that many of its users are unhappy with the price tag and dissatisfied with the support they received via the forums. So much so, in fact, that there’s now an attempt to create an open source clone by reverse engineering it. The project is named lime.

I learned about this with very mixed feelings. There’s a good chance the project will take off, given how much frustration exists with ST. Of course, the trend is nothing new: open source software has been supplanting closed source commercial software for a long time now. But this isn’t Microsoft or Oracle we’re talking about; it’s a very small company, charging what I think is a reasonable amount of money for their product. While they undoubtedly could do more to make their users happier, I imagine that they probably can’t do so without hurting what I imagine are pretty slim profit margins. That, or not sleeping ever again.

It’s not news that making a software product is much less viable than it used to be. Where money is made, it’s increasingly through consulting and customization, but one wonders about the size of that market.

It’s generally a good thing that open source has “socialized” software development: technology has enabled communities of programmers to contribute and collaborate on a large scale, in a highly distributed fashion, to create good quality software available to all, taking it out of the profit equation. The problem is that the rest of the economy hasn’t caught up with this new kind of economics.

I don’t mean to sound dramatic: there are many jobs out there for programmers, of course. But it saddens me that if you want to try to create a product to sell, it’s simply not enough to have a good idea anymore, in this day and age. It has to be dirt cheap or free, you have to respond to every message immediately, and respect every single feature request. Between the open source world and the big software companies that service corporate customers, there is a vast middle ground of small companies that is quickly vanishing.

Disabling the Open Sans font in the Twentytwelve wordpress theme

This seldom-updated blog uses WordPress, which for the most part works very well for my purposes.

I happened to view it using the Google Chrome browser today and noticed a font problem in the Twentytwelve theme. The links in some of my posts were running right up against the text preceding them. Here’s a screenshot:


Notice how there’s no space between “do” and “multiple dispatch” (the second link).

This only happens in Chrome. In Firefox, it looks fine. It appears that using the “Open Sans” font causes Chrome to render the text inside a hyperlink with an improper amount of spacing beside it in some cases (not all).

I wanted to fix this for Chrome but keep the Open Sans font in other browsers, since I like it better than the other sans serif fonts. After a bit of playing around, this is the cleanest way I came up with to accomplish this.

Step 1) Create a child theme. I made a directory called “twentytwelve-jeff” in the wp-content/themes directory and created a style.css file, per the WordPress instructions, that looks like this:

Step 2) Create a functions.php file in that directory, with the following contents:

The code looks for Chrome in the user agent header; if it finds it, it removes the “custom-font-enabled” css class from the body tag, which had been added by the stock twentytwelve theme. Note the priority level; the default is 10, so we set our priority to 20 to ensure this filter runs after the one in the base theme.

Using a child theme avoids making changes to the twentytwelve theme, which is desirable, since any updates would overwrite your changes. You should be able to update twentytwelve and the above child theme should still work.