Ubuntu on an 2012 macbook pro

By Mark Eaton | Published: October 8, 2023

The cheap Chromebook I bought last year is starting to flake out. The keyboard is becoming less responsive; the left shift key has become particularly troublesome. I’m realizing that you can only expect so much mileage out of a $300 machine. It has been my daily driver for a year, so I think it has held up remarkably, all things considered.

I’m realizing that I need a backup machine though. I’m still not willing to buy a fancy new laptop, so I’m trying to make do with what I have. What I have is a 2012 MacBook Pro that has been sitting in a box under the bed for several years. This may not sound that appealing, and indeed you are right: running MacOS it is entirely unusable. But I put Ubuntu 22.04 on it, in an attempt to salvage some more useful years out of the hardware.

So far so good. The Ubuntu minimal install that I started with was a mistake (too minimal), so I reinstalled with the normal Ubuntu installation. I had to install some drivers to get the wireless working, but now it is a usable machine. I hope to report back once I’ve spent some time with it and can give a better assessment of how useful this setup is.

Posted in chromebook, linux, macbook, ubuntu | Comments closed

Editing

By Mark Eaton | Published: October 7, 2023

Despite doing a lot of writing over the past few years, I’m definitely not a well-seasoned editor. If I’m being honest with myself, I’m not critical enough: I’m too willing to say “yes, this is fine.” But with some texts, strong criticism is definitely needed. I also sometimes feel that my edits are too superficial, and sometimes don’t adequately address the structural problems of a text.

But I do like editing. On the editorial board for Code4Lib Journal, I really appreciate reading the papers and watching them come together through rounds of revisions and input from editors. Editing technical topics poses unique challenges, because we are all sometimes confronted with the limits of our own technical knowledge. But it is valuable work, because we’re helping to produce something that hopefully benefits the Code4Lib community and beyond.

I also feel that editing is very much a learnable skill. Even in the brief time I’ve been on the editorial board, I think my editing abilities have come a long way. Granted I was starting from a low base. Nonetheless, watching the other editors has been very instructive. I hope to stick at this until I get much better at it. It’s probably a good skill to work on.

Posted in code4lib, editing | Comments closed

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 | Comments closed

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 | Comments closed

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 | Comments closed

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 | Comments closed

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 | Comments closed

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 | Comments closed

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 | Comments closed

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 | Comments closed

  • Subscribe to this blog


     

    Rest assured that your email won’t be used for any purpose other than sending you posts from this blog.
Skip to toolbar