I’ve been using cmus to listen to music lately. It is rather glorious software. To see what I mean take a look at this screenshot:
It runs in the terminal and has weird key bindings. To get it running I had to build it from source. It lets me play music off my hard drive, not the network. All of these things speak to my interests, or perhaps more accurately, my aesthetic. Anyhow, the code is on GitHub, if you like.
This week, Carrie Jedlicka and I presented at SpringyCamp, the annual Springshare conference. Our talk was called Creating a Fun Library Tour with Augmented Reality and LibGuides! If you have a Springshare login, you can watch the video here.
It was fun, although I was nervous because there were ~300 people there! Carrie handled it like a pro. We’re glad we had the chance to participate.
Fediverse relays have historically been a bit of a dodgy undertaking. In the past, when I’ve tested a relay, it was a largely unmoderated firehose of random stuff from the network. Unmoderated fedi is often particularly unpleasant; so much so that I could never really stomach it for more than a few days.
But I recently discovered relay.fedi.buzz, which provides relay endpoints for specific hashtags or instances. This is a far different proposition than the usual relay firehose: it’s much more manageable and customizable. From my initial testing, it seems that hashtag-based relay endpoints are useful for specific, niche tags. Popular tags have a predictable amount of spam, so that they’re not particularly interesting to follow. But a relay for an infrequently used hashtag is super useful.
Additionally, relay endpoints for specific instances are a good way to get more content from the parts of the fedi that you actually like.
So overall, relay.fedi.buzz seems useful, and I’m going to work on tweaking the endpoints I follow to see if I can get a reasonably good mix from it. The code for the project is also on GitHub and AGPL licensed, which is nice.
Recently, I posted about my commitment to read one academic article per day. It’s now been just over a month that I’ve been doing this, and I have to say, it has been transformative. I feel a whole new level of engagement with my work and my discipline.
This has also prompted me to read newer articles than I had previously. Having amassed >50 journals’ feeds in my RSS reader has helped. This means that when I open my reader there is always a bunch of new stuff to pick from. This has been important for ideation, recency, and fostering an interesting breadth of topics.
Anyhow, yesterday I wrote some Python scripts to quantify the daily articles I’ve been reading (most common journals, most frequent keywords in titles, for example), and I’ll share some results once I’ve amassed a few more months of data; the limited quantity of data so far means that it is not yet super meaningful.
Nonetheless, my takeaway from this exercise has been unambiguous: reading one academic article per day is an excellent thing to do. Highly recommend.
The last hackathon I attended was quite a while ago. It was at MIT, which was fun, and I think the theme was bookish. I really enjoyed myself. My coding skills at the time were enough to contribute, but not so much that my team was really counting on me. I met some interesting people and we built a thing. I still follow some of my former team members on GitHub.
Next month, a hackathon is coming to us. The NASA International Space Apps Challenge is happening worldwide, with Kingsborough hosting one of the local events. This is a great initiative for our college, and I hope that a lot of Kingsborough students participate and have some fun.
I signed up yesterday, and I’m trying to convince some of the other librarians to join me. Hackathons are great entry points for people who are code-curious, or who may be trying to figure out how to start their code journey. My experience of the MIT event was that is was supportive, inclusive and positive. I hope the Kingsborough event lives up to that. I encourage you to sign up, explore and enjoy! It’s not about creating an incredible, prize-winning app; it’s about learning and having fun.
I recently posted about using Lua to configure my neovim setup. This has been altogether a big improvement. One thing that is easier is having separate .lua configuration files for each file type that I work with in vim.
At first, this seemed useful for minor quality-of-life improvements, like setting differing default tabs for Python and JavaScript files. This would mean cleaner code with less fiddling; so that was a win.
But then it became clearer that there were more powerful possibilities. I found a Reddit post[1] about Lua configuration for markdown files that would let me use neovim more like a word processor when working with .md files. So my markdown.lua file now looks like this:
vim.opt.wrap = true -- Wrap text
vim.opt.breakindent = true -- Match indent on line break
vim.opt.linebreak = true -- Line break on whole words
-- Spell check
vim.opt.spelllang = 'en_us'
vim.opt.spell = true
-- alter up and down arrows for better text navigation
vim.keymap.set("n", "<Down>", "gj")
vim.keymap.set("n", "<Up>", "gk")
-- disable GitHub copilot
vim.cmd(':Copilot disable')
And now I have a minimal word processor where I can use vim commands! I am very happy about this. The last pleasing bit about this is that I can turn off GitHub Copilot. My paranoid side worries that what I write in Microsoft365 of Google Docs will just go to train LLMs, which is not what I want. I am more confident that neovim is not going to do this.
[1] I would link to this here, but I can’t find it again :/
This post is a bit of a departure from the library technology stuff I usually post about, but I feel that it is very much core academic librarianship, so probably relevant to some people here.
I was listening to this interview with Eleanor Colla, where she talks (among many other things) about committing to reading one academic article per day. This struck me as a wonderful idea. Some upsides: it will keep me immersed in my discipline(s); it will keep me up to speed on the latest developments in scholarship; it will get me thinking about what makes for good academic writing; it might make me a marginally more interesting person overall. I was sold.
So last week, I started with my own one-article-per-day regimen. So far, I’ve read some anthropology, some political science, and some library studies. It’s been great! I’ve been solely following my interests, with no mercenary professional development or publication agenda of my own at the moment. I’m hoping that, over the medium term, gently steeping in academic writing like this will start to improve my skills as an academic librarian. Maybe at the end of the year I’ll publish the reading list.
I’ve liked the idea of the Lua programming language since reading about it in Coding Places: Software Practice in a South American City. After reading that book, I put some effort into learning a bit of Lua syntax, but never really followed up beyond that. It seemed potentially useful but I didn’t really have the use case to pursue it much further.
Elsewhere, I’ve also posted about my enthusiasm for vim and neovim. One of the big advantages of switching from vim to neovim is that you can write your configuration files in Lua. Indeed, I’ve noticed an increasing portion the online conversation about neovim configuration has moved to Lua, and away from its predecessor, vimscript.
Anyhow, my old, vimscript-based config was not that complicated, clocking in at 30 lines. I figured that an afternoon comfortably ensconced on a west-facing deck would be enough time to make the migration from vimscript to Lua, so today I tackled the problem. It was a good exercise: the revised Lua version is more concise than its predecessor, at 18 lines. It also resolved a few (admittedly very minor) problems I was having with the vimscript version. But it’s also much more readable than vimscript, and I’m hoping that it will be easier to work with in the future.
In my last post on Quasar, I was just getting started with the framework, basically taking components from the docs and trying them out for myself. Now I’m getting a bit further into it: I’m getting different components wired up to interact with each other. This is, of course, what Vue excels at, so I’m confident that I’m on the right path. I’ll have to do a bit of refreshing of my Vue knowledge, but that is undoubtedly a good thing.
I’m also excited that I have a more expanded data set to use for my current Quasar project, thanks to some nice data scraping work with Selenium by my colleague at BMCC. We have additional scraping to do before the application is fully functional, but if all goes well, it is possible that it could be ready in the next week or two. I hope that a further update will be forthcoming soon!
Google has caused a controversy these past few days by disabling uBlock Origin in the latest version of Chrome. uBlock is the most widely regarded browser-based ad blocker. “Disabling” may be the wrong word, as uBlock seems to still be partially functional. I won’t go into the details, because there’s plenty of more knowledgeable discussion elsewhere on the web.
What’s clear is that the direction of travel is not good. In my opinion, ad blocking is core browser functionality: it makes many websites more usable, but it also makes them safer by not delivering ad-based malware. So when my Chromebook updated to Chrome version 127 this afternoon, I was contemplating that it might become totally useless for me. I was thinking I might have to wipe it and sell it.
Installing Firefox would be a good solution, but seemed unlikely, if only because the word “Chrome” is right there in the name of the computer. Nonetheless it was worth exploring for lack of other good options. A search of the Google Play Store was not encouraging: there is a mobile Firefox app there, but it is not really suitable for my laptop format.
I then turned to the Debian container on my Chromebook. On Mozilla’s recommendation, I tried installing Firefox through Flatpak, which didn’t work, probably because of my lack of understanding of Flatpak. But then I went back to basics and ran:
sudo apt install firefox-esr
and all of a sudden I have working Firefox in both ChromeOS and in the Debian container! Success. I immediately installed uBlock Origin. The Chromebook lives to see another day.
