In which, undeterred, I try to figure out what to write next

One never-ending challenge for faculty is finding things to write about. The problem is especially acute for those on the tenure track, but it really applies to almost anyone in a faculty role. Moreover, coming up with the wrong idea can be a real setback. It’s possible to spend months working on a topic before realizing that it’s not viable. I’ve done this; it’s not a good outcome. Sometimes it’s best to cut your losses and move on.

One strategy I’ve tried is to reapply the same methodology in various iterations. It can be reassuring to take an approach you’ve used before and apply it to a new topic. In my experience, the problem with this approach is that it can lead to boredom. Boredom can quite easily doom a paper too.

Specializing in a specific tool is another strategy. For example, working with Python provided me with a bunch of ideas. They didn’t share a methodology, but they were all built with the same infrastructure. Being knowledgeable about infrastructure can be productive. The boredom may seep in eventually, but maybe a bit less quickly.

I honestly don’t know what the answer to this problem is, but I will determinedly try to figure out what to write next.

Posted in research | Leave a comment

From the archive

I recently dug up an old paper about indexing that I never published. It’s pretty brief, but I think the main argument still stands, so I’ve shared it on CUNY Academic Works.

Maybe of interest if you’re interested in indexing, or the politics of software. Here are the details:

Title: Automation, Abstraction and Building It Ourselves
Link: https://academicworks.cuny.edu/kb_pubs/219/
Abstract: This paper argues that indexers should work collaboratively to build software tools that support our profession. As technology automates the procedural aspects of our work, we need to respond by building tools that support the conceptual labor of indexing.

Posted in indexing, software | Leave a comment

Top 10

I just noticed that in the WordPress classic editor, you can list your blog’s top 10 most used tags! If this were 2005, I would make a word cloud! For your amusement or interest, here they are for this blog:

  1. learning
  2. journal recommender
  3. LibGuides
  4. Python
  5. JavaScript
  6. Twitter
  7. Google
  8. Mastodon
  9. API
  10. homepage
Posted in meta | Leave a comment

Fall is here

The fall semester is starting this week, so it’s a natural inflection point in the academic year. Our departmental website committee wrapped up our summer weekly meetings last week, committed all the code we’d written over the past few months, and made it live.

Things are going to shift dramatically in September. I’ll be spending much less time on the library website (the prevailing theory in our department is that it’s best not to change it too much during peak use), and more time on eresources, as our contract renewals ramp up through December, before tapering off in the new year.

Nonetheless, I do want to continue working on the website (in a low key, probably late at night, way) to make the code both more concise and more modern. I’ll talk more about this project on the blog soon, but for now I’ll just say that I think I can reduce the length of the main HTML document by about 50%. (It remains to be seen if I can actually deliver on that :)

Be well, fellow librarians and technologists, and enjoy the fall!

Posted in eresources, homepage | Leave a comment

Time

Programming around dates, times, and timezones is painful. I’ve done this in Python and in JavaScript and it was miserable either way. It’s due to the complexities of time that we mostly ignore in our day to day lives. We are able to do this because we generally are not in multiple timezones at the same time, and we are not trying to work in Standard and Daylight Savings times simultaneously, and we aren’t adding or subtracting arbitrary lengths of time from other times. Yet when you’re programming around time, you pretty much have to do all of these things. The internet is global, your feature needs to work properly in the summer AND in the winter, and calculating differences in time is almost inevitable.

The good news is that puzzling through these problems once makes them less bad the next time around. Not that it’s easier, but at least you know the fight you’re getting into.

Posted in javascript, python, time | Leave a comment

Hours widget

When we built the current library webpage in 2021, I wrote a homemade widget in JavaScript to display the library’s hours. It has worked consistently since then without any problems, perhaps surprisingly, since the code is very ugly. This original version of the widget drew upon a custom JSON file with the hours data, which I would have to laboriously reconstruct by hand every semester.

So it was not ideal. None of the other librarians knew the workflow to update the JSON file, because it required steps to validate and format (such as with babeljs.io) before uploading, all of which were a bit arcane. So this summer, I built new version of the widget where mercifully the hours data can be easily updated using the LibCal admin interface. This is an obvious improvement.

I’m still working on the details of the new widget now – especially the CSS – but in some ways the new widget is very similar to the old widget. The most obvious difference is the source of the JSON, which is now accessed with ajax, following the example in this repository. I’ve also taken the opportunity to make the JavaScript a lot nicer, which was of course much easier the second time around.

Anyhow, we hope to have a new hours widget to share with you soon!

Posted in javascript, libguides, widgets | Leave a comment

Languages and idiom

This summer, I’ve been going to a French speaking meetup in Crown Heights on Friday evenings. It’s a nice to end the week by simply sitting outside and chatting in French.

It’s got me thinking about natural and programming languages. My ideas on this are probably very naive, so please forgive me, and feel free to improve on them in the comments below.

To me, it seems like fumbling for a word in a natural language is similar in some ways to fumbling with the idiom of a programming language. Not that I think that natural and programming languages are even remotely the same thing. Maybe it’s just that the struggle of searching for idiom is somehow analogous. Maybe it’s not even about language at all, but just about how we handle incomplete knowledge. Maybe it’s about how expressing yourself as you intend to is hard under almost any circumstance, and using a non-native language makes that even more obvious.

In any case, I find that there is something very appealing about trying to express yourself with incomplete idiom. You try your best to communicate with the parts of the language that you have. It’s good to make the attempt.

Posted in language, meetup | Leave a comment

The last days of the Open Journal Matcher

Yesterday I took the Open Journal Matcher offline. It had a good run of just over two years. I was reaching the limits of my comfort level maintaining this kind of production system. Technical debt had built up, and my enthusiasm for maintaining the project had ebbed.

My hope is that someone will pick up where I left off, and build something similar, or perhaps adapt the code for the OJM. There’s a place for a tool like the OJM; and we shouldn’t leave this space entirely to the big journal publishing companies. Thank you to everyone who used the OJM. It has been a pleasure to help you find open access journals!

Posted in journal recommender | Leave a comment

FontAwesome

Probably unsurprisingly, at one point on our website journey our Website Committee wanted icons. Icons are useful, right? They provide a somewhat standardized way of communicating the complex metaphors that are the currency of web design.

But icons are not surprisingly not an easy problem to solve. Sure, you can find any number of icons with a Google images search, but besides varying licenses, these will come in many different sizes and file formats. Which is fine, I suppose, until you want them to all behave the same way on your website.

Enter FontAwesome. I was initially very suspicious of FontAwesome. They want to make money off of icons!? What hubris. But it turns out that using standardized icons makes a big difference in reducing the amount of (CSS) labor that goes into putting icons on a page. For example, you might want all of your icons to be a fixed width; FontAwesome has a CSS class that does exactly that. And other such niceties.

So we pay for FontAwesome. It is possible that we might have squeaked by on FontAwesome’s free tier, but we would have been uncomfortably close to the cap. I am aware of alternatives like ForkAwesome, but since FontAwesome is doing what we want, we don’t have much incentive to switch.

Posted in fontawesome, icons | Leave a comment

What’s next with learning JavaScript

I confess that I mostly use JavaScript as if it were an extension of CSS. What I mean is that I am mostly using it to manipulate elements in the DOM, usually for appearance’s sake. I’m not building applications, or even using JS in a systematic way to solve problems that require some kind of organization.

That said, I’ve worked with JavaScript enough to see its utility. I’d like to be able to tackle bigger problems with it. But I’m intimidated, and even dubious, at the prospect of learning a framework. Is there another way forward? Or should I just aim at getting better at using JavaScript as a supplement to my CSS knowledge?

Posted in javascript, learning | Leave a comment
css.php
Need help with the Commons? Visit our
help page
Send us a message
Skip to toolbar