Library Technology at Kingsborough

AR, part 3

By Mark Eaton | Published: September 20, 2023

Over on the Springshare Lounge, I was asked for some detail about how our new augmented reality game works, so I posted the text below. I thought it might also be useful to share this here…

This [AR game] was built on a new Group Homepage, starting with a completely empty Homepage Template. Starting with an empty group homepage gives you a blank slate for custom HTML and JS/CSS. With this starting point, you have a lot of flexibility to build what you want.

Nonetheless, there are limitations [with LibGuides]: the “Upload Customization Files” section of the Look & Feel section only allows certain file types, and files under a certain size. I bumped up against these limitations more than once, and it did limit what we could do to a certain extent.

The AR functionality comes from a JavaScript library called AR.js. This library is a bit rough around the edges, and not entirely robust, but we never hit any insurmountable roadblocks when trying to deploy it, so we just kept going. AR.js is meant to be used with a framework called AFRAME, which was not my first choice, but which turned out to be pretty usable. The AFRAME code is what handles the game logic.

The virtual shapes in the library space are triggered by markers, which are posters with patterns on them that we put up around the library, rather than geotagging. The good news is that this meant that once the game was loaded, it could be played without a wifi or cell signal. The bad news was that people kept taking down our posters without asking :(

In the end there were two hard parts: First, getting the HTML menu, welcome screen and congratulations screen to align properly in the viewport of the phone was not easy. It was especially problematic since the image produced by the camera was not usually the size of the screen. If I’m diagnosing this correctly, AR.js was manipulating the image behind the scenes, which made it hard to write the correct CSS. In the end it was a classic finicky CSS problem, and it just took a lot of banging my head against the problem to get it to work.

The other big problem is that modern phones have more than one camera. They even usually have more than one outward facing camera. The problem is that the AR.js library does not always pick the correct camera, making it unusable in a small percentage of cases. Reading the relevant GitHub issues on this showed me that this is something the makers of the AR.js library haven’t even solved, so my odds of solving it are extremely low. Despite this flaw, the game works on over 90% of the phones we have tried, so we decided to proceed with using it as a new student orientation activity nonetheless. When a student’s phone didn’t work, we had them partner with another student who had a working phone.

Anyhow, I hope this brief write-up helps. Let me know if you have any more specific questions!

Posted in ar, libguides | Leave a comment

AR, part 2

By Mark Eaton | Published: September 14, 2023

This was the first week of the fall semester, so our augmented reality (AR) game went live to students for the first time. Prof. Carrie Jedlicka did a ton of work to make this happen. The game worked on more phones than I thought it would (>90%?), which was a nice surprise. The students seemed to like it too, calling it “fun” and “cool” and such. They also got rice krispie squares for completing the game, which they liked.

The game is built on LibGuides, so I also posted about it to the Springshare Lounge, and the random librarian denizens there were all pretty positive about it as well. It’s nice that people are so supportive of what could be seen as such a frivolous project. But it’s fun to make shiny, sparkly things sometimes, and I’m glad people are getting behind it. There’s talk in my department about expanding the game into instruction.

The code is on GitHub. Hopefully this project can continue, because the rice krispie squares were a big hit :)

Posted in ar | Leave a comment

Tildegit

By Mark Eaton | Published: September 9, 2023

I’ve set up an account on tildegit to mirror some of our library’s most important GitHub repos. On the one hand, this is simply a backup: another way to get at our code should something go particularly awry.

On the other hand, this may point to a new direction for our library. I have been unimpressed with the direction that Microsoft has taken GitHub since they acquired it in 2018. The tildeverse offers an alternative. Tilde servers are smolweb communities that provide services like git, irc, bookwyrm, mastodon, gemini, and many other such services, to relatively small communities of users.

The downside to tildegit is that there is a higher barrier to entry than with something like GitHub or GitLab. You need to have an email address on a known tilde server, which most people definitely do not have, to create an account on tildegit. This really limits the ability of most people to open a pull request or an issue. But I have decided that this is not really a problem for me, because I very rarely get pull requests or issues anyway.

Right now my tildegit repos are all mirrors of corresponding GitHub repos. But maybe someday I will swap it around, so that tildegit is pushing the changes, and GitHub is mirroring. We will see.

Posted in git, smol, tilde | Leave a comment

Limits

By Mark Eaton | Published: September 8, 2023

One thing I’ve come to recognize over my time as a programmer is where my limits lie. I’m not a super talented programmer: I started too late in life; and I have a job as a librarian, which prevents me from learning about code full time.

So I do what I can. The problem with programming is that when non-programmers see you do one thing with code, they assume you can do all the things. I’m constantly having to temper expectations and walk back my colleagues when they get too far ahead of themselves with a technical project. For example, today I was saying: “no, we can’t scale out this prototype to the entire college.” I said this because I know my skill set well enough to know that I would flounder at building something of that complexity at that scale.

It’s important to be clear about your limits. If you aren’t, it is easy to get yourself into trouble by over-committing.

Posted in learning | Leave a comment

The smol internet

By Mark Eaton | Published: August 12, 2023

I’ve been interested in gemini for quite a while now. It’s a protocol that serves up plain text with hyperlinks, and that’s about it. It’s pretty much the most minimal experience of the internet that you can imagine.

I think people like gemini for (1) its obscurity. From what I can tell, your odds of accidentally saying something that goes viral on gemini are virtually nil. Also for (2) its privacy. There’s no tracking of anything. That’s just not built into the protocol. And (3) for its smolness. Gemini is the web at a much more human scale. The Wikipedia page on the gemini protocol estimates that there are a total of about 2300 capsules (sites). That’s tiny. Sometimes tiny is what you want.

I’d start my own capsule if I had more bandwidth for writing right now. But I have way more writing to do than I can possibly keep up with at the moment, so starting a capsule sounds a bit irresponsible. Nonetheless, I happily run the AV-98 client, and I pretty reliably keep up with a number of capsules. Gemini is something I definitely want to pursue further.

Posted in gemini, smol | 1 Response

On using a fading JavaScript library

By Mark Eaton | Published: August 8, 2023

I’ve been building some web stuff recently with a JavaScript library that seems to be well past its prime. A couple of years is a long time in JS-land. I deliberately won’t name the library, because my intention here isn’t to criticize; rather I want to point out some of the challenges of working with fading JavaScript.

In its heyday, this codebase provided a buzzy bit of functionality, which probably drew in contributors at the time, although it seems like these contributors have now mostly moved on to other things. Because it was trendy stuff, it seems like the focus was on iterating quickly, and not really doing much maintenance on the corner cases. The attitude in the GitHub issues seems to be: “if you get stuck, figure it out: you’re a developer.”

Fine. I’m not complaining. In a JavaScripty way, that kind of makes sense. But not all of us have the same use cases for a library. We’re not all chasing buzzy features (or at least we are chasing them a bit less, or a bit belatedly :) and we value stability more than you might. If you build things that sparkle briefly and then burn down quickly, your audience is mostly limited to people also doing the same thing. In my opinion, being a good open source maintainer means accommodating the many, quite varied use cases your code might have, in your immediate community but also in other adjacent communities. But then again maybe I just don’t understand the JS mindset.

Posted in javascript, libraries, software | Leave a comment

AR

By Mark Eaton | Published: August 4, 2023

I’ve been working on an augmented reality (AR) tour game for our Fall library orientation. Basically, you wander around the library with your phone camera turned on, and you’ll find some shapes floating in the virtual space, by the reference desk, the circulation desk, and so on. When you collect all the shapes you get to claim a prize from the librarians.

Anyhow, I haven’t got it entirely working yet. It works great on my iPhone, but not so much on my co-worker’s Google Pixel. I think the problem has to do with the multiple cameras that modern phones have, and the AR is not always defaulting to the correct camera. This gets a bit into the JavaScripty weeds, but I’m going to work on it this weekend, and I’ll see if I can make any progress.

This project has been a balancing act of managing expectations. I’ve kept my co-workers up to speed on my progress, but I’ve made clear that I can’t promise that it will be working by September. I know better than to make hard promises when building with technologies I’ve never used before. The library I’m using, AR.js, is a bit rough around the edges, and I lean on it with a good dose of caution and trepidation. We’ll see how this goes. September is not that far away.

Posted in ar | Leave a comment

Vim

By Mark Eaton | Published: July 15, 2023

I am a long-time user of vim. Vim is a terminal-based text editor. It can be expanded through all sorts of plug-ins to give you something similar to an IDE.

I have tried other coding environments: fancy IDEs, with lots of features. Even when I apply the vim key-bindings in those environments, I still don’t like them as much as real vim. I don’t know why. I can’t really explain it. Each time I try a new IDE, I’ll use it for a bit, but eventually find myself back in vim.

Vim has the virtue of running basically anywhere you have a terminal. So you can use it on that machine that you’re SSHing into. Vim will be there for you.

I recently switched from vim to neovim on my home machine. This is really not that much of a departure, rather, it’s mostly just updated infrastructure. Neovim is still very much vim. It does seem a bit less archaic in its construction though. I know that I’m probably being a cranky old coder, but I maintain that vim is an excellent development environment.

Posted in old, vim | 1 Response

In praise of buying low quality books

By Mark Eaton | Published: July 8, 2023

I buy a lot of really bad books on Amazon. They’re minor books, on fringe topics, and they’re usually well out of date. They’re also usually incredibly cheap, like two or three dollars, or some such. And while they’re generally pretty uninteresting, they can often offer a citation to support a minor point in a literature review. (Citations don’t always need to be to authoritative sources. Citing an obscure work can also help make an argument, in a different way.)

So while I use these books for my research, I don’t really want to own a copy. But I buy them anyway. This is because Amazon is often the most effective way to get a hold of them. These books are usually such trash that most libraries that might have once held a copy have long since discarded them. Spending $3 on Amazon is less of a headache than trying to coordinate an ILL from a distant library. Leaving aside the obvious privilege of making such frivolous purchases, and the ethics of buying from a company like Amazon, buying trash books is really a pretty good solution.

Posted in books, research | Leave a comment

Copilot

By Mark Eaton | Published: July 2, 2023

So I set up Copilot last night. Copilot is GitHub’s AI that helps with writing code. I don’t think I’d pay the list price of $10/month for this type of service, but it is free to anyone with a GitHub educator account, which was enough to prompt me to try it.

Needless to say I am suspicious. But ~44% of programmers are using AI tools in their work, and I’m curious what (if anything) they find valuable about it. I’m not far enough into it yet to offer an informed opinion, but I do intend to post here again once I’ve thought this through a bit.

Lastly, getting this working was a bit of a journey. Debian Bullseye did not have a new enough version of neovim. To install a newer version of neovim, I had to install cmake. To install cmake, I had to install a library called gettext. All of this took quite a while, but it was worth it because I can try Copilot in vim. Asking me to use a different IDE would have been a non-starter.

Posted in ai, copilot | Comments closed