Code4Lib

I am very excited to be attending Code4Lib’s upcoming conference, taking place in May in Buffalo. It will be my first return to an in person conference since the before the pandemic. I am excited about all of it: the train ride to Buffalo, staying in a hotel, the conference sessions, the socializing. There is something exceptionally normal about the whole thing that really, really appeals to me after all of these months of confinement.

I’m sure the presenters will be great, the sessions will be valuable, and so on. But mostly I’ll just be happy to be there.

Posted in conference | Comments closed

Self-taught

A very democratic trait amongst programmers is that they are generally very open to people who are self-taught. I assume this is because the typical yardstick of a good programmer is what they can produce with code, not their credentials. In some respects, this is very meritocratic, and in theory you can do well if you are willing to put in the work. In practice, though, there are lots of reasons why programming is very inequitable and very inaccessible, but I won’t go into those here; others have documented these problems very well.

For those who do want to teach themselves, it is unfortunately not always obvious how to proceed. This blog has documented some of my challenges with this in the past. In my experience, being a self-taught programmer tends to produce uneven knowledge, usually with big gaps. But the good news is that, in programming, this is often fine. There is no real possibility of knowing everything, even in a very cursory way. What counts is expertise in your niche. (Personally, I have probably lingered a bit too long on the broad, almost meaningless topic of “web development”, rather than specializing more sooner, but that’s a topic for another post.)

The message I want to convey here is that if you want to learn programming on your own, you can. Not only that, but you can become a very good programmer just by teaching yourself. Programming is not the meritocracy that it sometimes pretends to be, but teaching yourself can still be a rewarding thing to do.

Posted in learning | Comments closed

Widgets

Library websites often include widgets of various sorts. Hours widgets, chat widgets, and so on. Often these are built by outside vendors, and plopped into library pages by librarians. The intention, I suppose, is to provide functionality that the librarians may not want build themselves.

I have contradictory feelings about widgets. First, the bad things:

  • Widgets are usually not custom-built and therefore are often visually inconsistent with the page on which they are found. For this reason, they are often unintentionally conspicuous. Having multiple widgets on the page only amplifies the inconsistencies.
  • We generally don’t have control over vendor-provided widgets. We may be able to make changes via an admin panel, or by writing some CSS, but much of the widget is often only accessible by digging into the JavaScript. Most librarians will balk at this.
  • Widgets bring unnecessary complexity into a site. Complexity is unambiguously the enemy of a well-functioning site.

On the other hand,

  • Widgets provide functionality that you don’t have to build yourself. Maybe you don’t have the time or JavaScript skills to build particular functionality, but a widget helpfully offers a shortcut to get the needed content on the page.

What does this mean for the Kingsborough library? Our page currently has four widgets: a chat widget (built by Springshare), a room reservation widget (also built by Springshare), a search widget (built by our university’s central Office of Library Services), and an hours widget (that I built myself). If you wanted to, you could count a couple of other things, like modals, as widget-like too. While this is probably a common setup, in my opinion it may already be far too much. Short of advocating for greater digital minimalism, I think the best I can do is to attempt to smooth out the CSS to make it as seamless-looking as possible.

Posted in homepage, javascript, widgets | Comments closed

In praise of the Springshare Lounge

At some point not too long ago, CUNY’s Office of Library Services signed a deal with Springshare for a wide range of Springshare products. Springshare makes various tools to help run libraries, of which the most well-known is LibGuides, their CMS. Since CUNY signed this university-wide deal, our library has actively started using many of these products, and they’ve very quickly become an integral part of our work.

One of the nicer features of working with these tools is using Springshare’s community platform, the Springshare Lounge. The Lounge is a technical community, but unlike some other widely known notorious ones, it is very supportive. What I like about the Springshare Lounge is that people are very willing to ask and answer questions at whatever level they are at, and the community will help them. This is very heartening. The spirit of helpfulness is refreshing, and is lacking in many other places on the web.

Posted in libguides | Comments closed

Maintenance

Once a project is built, one important thing that doesn’t get discussed enough is maintenance. Maintaining web projects is essential but mostly underappreciated. It usually doesn’t get you much reward. But web applications are living things that need tending to. This means updating dependencies, but also thoughtfully revisiting the project on a regular basis to make sure that it is still meeting its goals in the best, most appropriate, most up-to-date way.

The most important take away from this post is that there is a real risk in running out-of-date code on the web. Parts of your project will very quickly become vulnerable and need replacing. Under-maintained projects pose a real security risk to both their users and the project maintainers. Basically, you shouldn’t do that. Maintain your projects. It takes time but it’s necessary.

Posted in maintenance | Comments closed

Data

With some time off over the holidays, I took the opportunity to do a deep dive into Google Analytics. This was prompted by an article by Erin Crane which I found quite interesting. Erin shows how putting some time into your GA setup can provide interesting insights about how your library website is used. It’s an example of the kind of quantitative analysis that is highly valued by many campus administrators.

Is that a good reason to do this type of GA work? I’m not so sure. I think there are problems with “data-driven” campus assessment initiatives, like website analytics. Data gathered will in all likelihood be used to serve the agendas of interested stakeholders. Is it even possible to listen to what the “data says”, or is it inevitably a tool to advance someone’s preferred outcomes? I think our data is very, very rhetorical.

There are a lot of other issues with Google Analytics (privacy, surveillance) but I’m going to leave it here for now. In our enthusiasm for assessment, it’s worth remembering that the data itself is not neutral.

Posted in assessment, data, google | Comments closed

In praise of Zotero

It’s hard to believe this blog has been running for almost 7 years and I have yet to write a post about Zotero. Time to remedy that.

Many of you are probably already familiar with Zotero. It’s citation management software. But if you having a passing familiarity, I’d suggest that it’s worth a closer look. You can use it as an all-purpose research management tool. Upload your sources, organize them, take notes on them, and of course, cite them.

There are a lot of things to recommend it: it’s open source; it syncs across devices; it has both web and desktop clients; and it has a generous cap on storage, which you can expand if you are willing to pay a bit. I continue to find new and delightful things that it does. Zotero is stable software that works largely without any headaches. Highly recommend!

Posted in zotero | Comments closed

Git

Git is useful, but troublesome at times. You can pull to the wrong branch and all of a sudden your nicely organized project is a mess. Of course the prickliness of git is not new news. But people don’t use it for the friendly UI; they use it because most of the time – when it’s not causing you headaches – it’s very helpful.

The main takeaway I have gleaned from the past eight years of using git is not to rush. Rushing through git commands will almost invariably lead to disaster. Better to take your time and work through it deliberately and carefully. If you get into an unintended state, it will help that you are clear on how you got there. That in turn will help you get back to a happier place. Git, when it’s humming along nicely, is a marvelous thing. Best to be careful to keep it on track.

Now please excuse me as I have a very messed up git repository to attend to…

Posted in git | Comments closed

Idée fixe

There are some well-travelled paths in library research. I came across one of them this week when I was looking for articles on LibGuides. There are a lot of articles by librarians about LibGuides. On the one hand this is great (we have a comprehensive literature!), on the other hand, do I really have to read all of these?

Anyhow, my reason for looking through these articles is that I’m considering a paper. The worry, of course, is that I don’t have anything new to add. But in past papers I have tried — and always failed — to express something that I can’t quite name. Attempting to communicate this as-of-yet unnamed thing is actually what motivates me to do this work. You can call it a “research agenda” I suppose, but I think it’s better described as some sort of fixation. Maybe I can try to express it again in the context of writing about LibGuides. Maybe this is an opportunity to get a bit closer to what I’m trying to say.

Posted in libguides, research | Comments closed

Thanksgiving debrief

So I followed through on my plan to spend the Thanksgiving holiday by myself, working on the Open Journal Matcher. It went fine. I put in four straight days in front of vim, and I’m pretty sure that I more or less cracked the problem that I was trying to solve.

The goal was to reduce the amount of on-demand work the Open Journal Matcher is doing, and instead pre-process most of it. This required creating, storing and handling some ~6000 spaCy binaries, which represent the abstract collections of the various journals that the OJM is drawing upon. This took some wrangling, but I made a lot of progress. At this point, there are really only a few loose ends to tie up.

A good weekend, all things considered.

Posted in holidays, journal recommender | Comments closed
css.php
Need help with the Commons? Visit our
help page
Send us a message
Skip to toolbar