Seven years

As of today, this blog has been running for seven years. While there have been some hard times, there have also been some optimistic moments where I’ve been really glad to do this kind of work.

And while I’ve posted some charts over the years, I’m proud to say that I have yet to post a picture. This just isn’t that kind of blog. You’ll find plenty of pictures elsewhere on the internet. Not here.

My biggest regret with this blog is that it hasn’t turned into the collaborative space I had hoped it would be. Julia Furay co-wrote a post, which was awesome. But for the most part, it’s just been me, plugging away at the WordPress Classic Editor. If you want to write a post and you’re a CUNY librarian, let me know! I would be happy to have your contributions.

Anyhow, thanks for seven great years! I hope to keep going for a while yet. Happy reading!

Posted in meta | Leave a comment

Why we need version control in LibGuides

LibGuides doesn’t have version control. In my opinion, it really should. I’m not the first to suggest this. I am told that others have also requested this feature.

Hopefully Springshare is working on this. One of the hurdles in implementing version control is that it can sometimes be confusing. Git is certainly daunting to newcomers. But Google Docs has version control of a much simpler sort. Maybe there is a librarian-friendly flavor of version control that could be integrated with LibGuides. I think that this would be a big win.

Personally, I manage version control by keeping a copy of our LibGuides HTML, CSS and JavaScript in a GitHub repository. On occasion, this has been very useful, as there have been times when I’ve had to roll things back. As our LibGuides setup becomes more complex, the importance of this backup has only increased. An external GitHub repository is a passable solution given the options. But it would be much better if version control was built into LibGuides. I hope that this feature can be added soon.

Posted in git, libguides, version control | Leave a comment

Creating a desktop application using Python (part 2)

Usually code works for a while, until it doesn’t. That happened to me this week with new-books-desktop, my desktop application for producing our monthly new books list. I had recently lost the virtualenv that was being used to build the executable to a replaced hard drive, and was hoping that it would be easy enough to rebuild, say with:

pip install -r requirements.txt

But no such luck. Six hours of work later and I am no closer to having a working virtualenv. Over the course of the afternoon, I attempted a lot of fixes, and generated a lot of varied error messages, but I still did not manage to get all of the libraries installed, let alone run the build process. This isn’t the end of the world; I’m sure I’ll get it figured out eventually; but it speaks to how capricious software can seem sometimes. We are often at the whims of different versions of libraries, of different bugs (both patched and unpatched), and of our own shortcomings as problem solvers. It requires patience and humility, as well as a stubborn determinedness to ultimately figure out what is wrong. And then at best our code will work for a little while. Programming is for a person who can accept being a very specific kind of Sisyphus.

Posted in desktop application, maintenance, python | Leave a comment

LibGuides for non-librarians

Next month, I’m planning to teach a workshop for non-librarian faculty on how to use LibGuides. This will be a first for me. LibGuides is a very library-focused tool, and I am curious to see how it goes over with non-librarians.

On the one hand, LibGuides is a very accessible, general-purpose CMS that would seem to have many use cases, much like WordPress. On the other hand, it also has a lot of library-specific tooling built in, which may (perhaps?) alienate non-librarian users. Non-librarians are probably not usually going to want to “add a book from the catalog” or “add a database”. The question is whether they will be willing to look past these features to see it as a general-purpose CMS. I suppose librarian-specific features can be easily ignored, but people also usually expect their software to be aimed specifically at their use case. So the question is: if there are some irrelevant (from their perspective) features, will non-librarians engage with the platform?

We’ll see what happens in the workshop! I will try to report back soon.

Posted in libguides | Leave a comment

StackOverflow

I really dislike StackOverflow. While I acknowledge that it is sometimes useful, I really don’t like the negativity, the showboating, and the pile-on mentality toward people who deviate at all from a perfectly asked question.

So when I recently realized that a giant archive of StackOverflow comments is available to download (https://archive.org/details/stackexchange), I saw an opportunity to dig deeper into questions of sentiment in SO comments.

This is not a small dataset. There are 84,369,024 comments in the archive. Unzipped, it took up 24 GB of disk space. This was too much for my little laptop, so I used an external hard drive to store the unzipped file. The file size also makes processing this data a challenge: the XML file is much too big to store in memory, so I had to do some contortions to process the file in much smaller bits.

Ultimately, I was able to use Python’s TextBlob library to trace sentiment in StackOverflow comments over time:

A chart showing sentiment in StackOverflow comments from 2008 to 2022

First of all, I was surprised that StackOverflow comments scored positively in sentiment at all. I was expecting them to be deeply negative.

Second, there are two interesting trends here. From 2008 to 2017, sentiment on StackOverflow was getting increasingly negative. Then in 2018, things turned around and started improving mildly. I don’t think that this is accidental. In this 2018 blog post, StackOverflow acknowledged that they had a negativity problem. They also made it clear that they were going to take action to address the issue. From the data, the steps they have taken seem to have had an effect: sentiment has improved since 2017.

This implies that StackOverflow was successful at improving the tone in their community somewhat, which is interesting.

Posted in sentiment analysis, stackoverflow | Leave a comment

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 | Leave a comment

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 | Leave a comment

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 | Leave a comment

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
css.php
Need help with the Commons? Visit our
help page
Send us a message
Skip to toolbar