Being a nerd, I tend to like the command-line. When I'm working on my laptop at home, I tend to like listening to music. Before I discovered that mplayer had a really convenient shuffle idiom, I would invoke it thusly (to listen to all my Pavement tracks in shuffle mode):

export IFS=$'\n'
for track in $(find /mnt/upnp/MediaTomb/Audio/Artists/Pavement -name \*.mp3 | ~/bin/shuffle.py); do mplayer $track; done

And the wee shuffle script I whipped together looks like this:

#!/usr/bin/env python
# shuffle.py
 
import sys
import random
 
args = list(sys.stdin)
random.shuffle(args)
sys.stdout.writelines(args)

And here's the convenient shuffle idiom that renders my arg-shuffling script somewhat useless:

find /mnt/upnp/MediaTomb/Audio/Artists/Pavement -name \*.mp3 | mplayer -playlist - -shuffle -loop 0

JSONovich has now emerged from the Mozilla Add-ons sandbox and is available to the masses: http://addons.mozilla.org/en-US/firefox/addon/10122.

Dear Future Me,

It has been a while, hasn't it? Yes, it has[1].

Did you try to view an HTTPS/SSL URL in Lynx[2] again, only to be met, most cruelly, with the following error message?

$ lynx https://example.org/resource/[3]


Alert!: This client does not contain support for HTTPS URLs.

Well, have no fear! The lynx package, at least within the aptitude repositories for Ubuntu 8.10 (Intrepid Ibex), has no SSL support as you have just witnessed. The lynx-cur package, on the other hand[4], does! Support SSL, that is. Fix yourself thusly:

$ sudo apt-get install lynx-cur

N.B. the new lynx looks for its configuration in a different place than the old lynx, so you may need to fiddle with things if you've tricked out lynx with bells and whistles and racing stripes and nitrous boosts. Otherwise, huzzah!

Notes

1. In the future you will have evolved beyond answering your own questions, no doubt, but here in the past, in this quaint and backwards era, it is quite common to hold conversations with yourself. Or myself. But I (i.e., you) digress! (We digress in the past as well! Quite the confusing state of affairs, conversationally speaking!)
2. Do they even have Lynx in that brave new world of the future? Does the lynx species still exist? Did the polar ice caps melt and wipe out all non-domesticated felines? Inquiring, unevolved minds of the past want to know!
3. I am assuming that in the future example.org remains a reserved dummy domain.
4. I hear that in the future hands will be replaced by hooks and detachable chainsaws and the like?

JSONovich is now up to version 0.6. Recent revisions have added the following functionality:

• Reads in JSON and converts to UTF-8 for some naive Unicode handling
• Wraps long lines at the right edge of the window
• Adds a check to see if a native JSON parsing library is already loaded (as will be the case in Firefox 3.1). Uses that library if so, otherwise loads the module included in JSONovich.
• Handles JSON syntax errors more gracefully. Used to eat bad data and display nothing, but syntax errors (from the JSON parser) are now surfaced.

I've also tossed the source up on code.google.com for version control.

In the meantime, those of you who are using JSONovich can help increase its exposure by heading over to its entry at addons.mozilla.org, logging in, downloading, rating, and reviewing the extension. Reviews and ratings help get extensions "promoted" from the sandbox to the public site, which provides the ability for automatic updates when new versions of the extension are released.

Lest I be criticized for unfairly calling out former employers in my recent Burn the Walled Gardens rant, I share news that the Rutgers University Libraries have boldly ventured into the world of open source software: RUcore Open Source Development. Huzzah! Thanks to the molotov-hurling Shaun Ellis, a peacenik/code monkey/musician extraordinaire, for all of his work and for bringing this to my attention.

On the RUcore open source page you can get a list of ongoing projects, a release schedule, and a rationale for their licensing decisions (i.e., choosing GPL 3).

The first project to be released (as of 2008/12/19) is the METS-based bibliographic utility, OpenMIC:

OpenMIC is an open source, web-based cataloging tool that can be used as a standalone application or integrated with other repository architectures by a wide range of organizations. It provides a complete metadata creation system for analog and digital materials, with services to export these metadata in standard formats.

• Low overhead and infrastructure requirements
• Events-based model for management and rights documentation
• Mapping and import from standard and in-house formats
• Unicode and CJK vernacular character support

OpenMIC is a core application for the Moving Image Collections (MIC) initiative developed at the Rutgers University Libraries with funding from the Library of Congress.

I look forward to following along as Rutgers releases yet more of the tools they have developed as part of their impressive digital library infrastructure. It will be even more interesting to hear what their model will be for taking patches / commits from the broader open source community. These things do take time, even though I failed to show an appreciation for that in my original rant, but I am reminded (by Jonathan Rochkind) that it's better to take the time and get it right. I cringe a bit to say that, knowing full well how things tend to languish in committees and fall victim to analysis paralysis in academia; surely there is some middle ground? There are some very talented and experienced folks at Rutgers, so I will be excited to see them take a leadership role in this space.

Go, Scarlet Knights!

JSONovich is now in the "sandbox" over at addons.mozilla.org, where it will remain until it's been tested a bit more, and rated and reviewed by users. Until that point, it will be marked as "experimental" and will require users to login before they can download it. If any of you would like to give JSONovich a quick spin and rate/review it over at the Mozilla add-ons site, that would be solid. Once it's gotten a few reviews and I'm more comfortable about it working cross-platform and cross-version, I'll nominate it to be promoted.

Here's where it lives: https://addons.mozilla.org/en-US/firefox/addon/10122

Much obliged, folks. And thanks to those of you who have already downloaded it, installed it, tested it, left comments, or some combination thereof.

I use the Adobe AIR-based Twhirl as a Twitter and identi.ca client on my Ubuntu box. Twitter recently made some changes to their authentication API, apparently, which prevented Twhirl from connecting as of version 0.8.6. The fine folks over at Twhirl pushed out 0.8.7 in a jiffy but it included some AIR 1.5 dependencies. The problem was that Adobe AIR for Linux only comes in 1.0 and 1.1 versions.

I was a tad frustrated that such a seemingly minor Twitter API upgrade resulted in a fundamentally different (and broken) version of Twhirl, but I couldn't fault them for trying to respond quickly. I followed the twhirl user on Twitter when this went down, and I was pleased to find out that they've whipped up a special AIR 1.1 Twhirl client for us Linux users.

I ran into some problems trying to install the client. The first problem I ran into was due to a corrupt download. If the file is less than 997K or so, you should try to download it again. If Firefox fails you, there's always wget. Want to make sure you've got a good file? Run unzip against it (an .air file is a .zip file underneath its raincoat). If it succeeds, you're golden.

The other problem was an old version of Adobe AIR. You want adobeair_linux_b1_091508.bin installed, not adobeair_linux_a1_033108.bin. Here's how you "upgrade" AIR from the alpha to the beta (1.1) and get Twhirl 0.8.7-air11 installed:

1. sudo adobeair_linux_a1_033108.bin -uninstall
2. sudo apt-get remove adobeair-enu (This step was not necessary on another box I tested. It could be that the original box I tried these steps on was munted up.)
3. This may be optional! Clean out /opt/Adobe Air/, ~/.adobe/AIR/, and /root/.adobe/AIR/. Note that this step will wipe your settings for all your AIR applications.
4. Download the AIR 1.1 beta for Linux
5. adobeair_linux_b1_091508.bin (Some report that Firefox and other browsers must be closed during this step, but I couldn't reproduce that.)
6. Download the latest AIR 1.1 Twhirl for Linux
7. Then navigate to the twhirl-0.8.7-air11.air via Nautilus and double-click it.

Worked for me, at least.

Issue five of the code4lib journal is out. This issue looks to be just as good as the past four issues, but I'd like to highlight one article in particular: the column by Kansas State's Web Development Librarian, Dale Askey: We Love Open Source Software. No, You Can't Have Our Code.

Librarians are among the strongest proponents of open source software. Paradoxically, libraries are also among the least likely to actively contribute their code to open source projects. This article identifies and discusses six main reasons this dichotomy exists and offers ways to get around them.

If you're at a library doing open source software, or if you think you're doing open source software, or if you're considering jumping into the fray, you would do yourself, your institution, your users, and the open source community (whatever the heck that is) a great, great service by reading this column. Srsly.

I've worked in academic libraries where open source was given lip service the likes of which Jimmie Walker would envy and yet, well, show me the code already!

See, here's the thing, if you're doing open source, or think you're doing open source, it is necessary that you release code to the public under an open source license. The public includes your institution, your partner institutions, all of academia, random hackers in East Kaboomistan, and everyone else; if you make code available to partners only, that's not open source; that's multi-institutional closed source. It's a walled garden with teleportation devices leading to other walled gardens. And we're tired of hearing about your damned azaleas. We want to see them, and take cuts from them, and grow our own, and contribute some back to you.

Releasing code is necessary to claim you're doing open source, yes, but it is not sufficient. There is some value in just throwing code over the wall. Sure, once the code is out there you've satisfied a definition or two and you can go off and pat yourself on the back and do the happy Ewok dance and maybe some more grant funds will come your way. But if you want to add value to your involvement in open source, and add value to user-facing services built upon open source software, and add value for the vast community of open source developers champing at the bit to get at your code and make it better and work with you towards crafting a shiny, happy world, for goodness' sake, Mr. Gorbachev, tear down that wall. Stop the madness; no more "just fork it because it wasn't invented here." Take commits from the world. There's the value in open source.

Do we get this? I hope we get this. None of this is new. Some of us in libraries have been banging the open source drum for nearly a decade, some even longer. The rhythm is a well known one, but the drum quite apparently needs yet more beating. And louder beating. Thank you, Dale, for keeping the beat. Now, if only this rhythm section had a bassist.

JSONovich is a Firefox extension that pretty-prints and colorizes JSON.

Feedback is welcome.

There must be a better way of viewing pretty-printed JSON from Firefox than this. (EDIT: Hail, JSONovich!)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#!/usr/bin/env python
# ~/bin/jsonhandler.py 
# Take some JSON from a file or stdin, format it, output to a tempfile, 
# open in EDITOR
 
from __future__ import with_statement
import os
import sys
import simplejson
import tempfile
 
EDITOR = "/usr/bin/gedit"
 
if __name__ == "__main__":
    if len(sys.argv) == 2:
        # if invoked as jsonhandler.py {FILE}
        json = open(sys.argv[1])
    else:
        # if JSON is piped in (e.g., from Firefox, 
        # or cat {FILE} | jsonhandler.py)
        json = sys.stdin
    json = simplejson.load(json)
    # the with_statement is kind of gratuitous but I like it
    with open(tempfile.mktemp('.json'), 'w') as jsonfile:
        simplejson.dump(json, jsonfile, indent=4)
    # all of that and gedit doesn't even highlight JSON
    # I have emacs highlighting JSON but this generates a "stdin is not 
    # a tty" error, so EDITOR is not set to emacs
    # xemacs works a little better, but I need to click:
    # "Options > Syntax Highlighting > In this buffer" every time, despite 
    # saving to custom.el, so EDITOR is not set to xemacs
    # Very annoying!
    os.system("%s %s" % (EDITOR, jsonfile.name))

And then I set ~/bin/jsonhandler.py as the action for application/json in Edit | Preferences | Applications.

Yuck. Help?