Cleaning your GitHub profile with a simple Bash script

I recently read Andrei Cioara's take on the best way to organize GitHub repos. The short version is that GitHub's flat name-spacing leaves all your repos in a single, jumbled list—which is both annoying for you to deal with and makes it harder for anyone else to find your most useful projects.

In particular, if you're an active participant in the open-source world, you could easily have dozens of forks cluttering up your repo list, not to mention any old, half-finished projects you might have floating around.

Andrei suggests a clever solution: Create single-user organizations and move certain repositories over to those organizations. For example, I've created a codesections-forks organization to hold all the projects I've forked to make pull requests and a codesections-playground repo to hold my one-off experiments. As a result, my main repository page is now much cleaner—down to just 13 public repos, all of which I actively maintain.

But what Andrei doesn't explain is how to move all your repos. If you do it through GitHub's UI, it's pretty painful—you have to click through several different pages and manually type in both the name of the repo you want to move and the target org. And—since the only reason this is worth doing is if you have a bunch of repos you'd like to move—this ends up being a lengthy process.

Fortunately, there is a better way.

Screenshots from arch/stumpwm/tmux/vim/qutebrowser setup

I recently made a number of pretty significant change to the look and feel of my Linux desktop environment, and I'm pretty happy with how my setup looks now. It's not for everyone, but I thought at least some of y'all might be interested in seeing how it looks.

What I changed

I was previously using dwm as my display manager—and, if you haven't tried it, I highly recommend it. But I just switched to stumpwm, which sacrifices a bit in minimalism but makes up for it in configurability. That change deserves—and will get—it's own blog post. But, for now, you'll just get to see the pictures.

At the same time, I've changed from a standard Solarized color scheme for vim to the nofrils color scheme as part of an experiment with removing (almost) all syntax highlight from my code. That also deserves its own post; again, all you get right now is the screenshots.

The result of all of these changes is a highly minimalist, distraction-free, and keyboard-centric window setup—and I'm very happy with it for now.

Screenshots

(In each case, click for a bigger image—and most of these really need it.)

My main desktop, when I log in:

Using Vim to take time-stamped notes

I frequently find myself needing to take time-stamped notes. Specifically, I'll be in a call, meeting, or interview and need to take notes that show how long it's been since the meeting started. Basically, I want something that looks like this:

My first thought was that there's be a plugin to add time stamps, but a quick search didn't turn anything up. However, I little digging did turn up the fact that vim has the built-in ability to tell time.

This means that writing a bit of vimscript to insert a time stamp is pretty easy. After a bit of fiddling, I came up with something that serves my needs, and I decided it might be useful enough to others to be worth sharing. Here's what I came up with:

Thinking about moving the site away from Netlify

I'm very strongly considering moving this site away from Netlify. In fact, I'd go so far as saying that I'm planning to unless writing this post—or hearing from y'all—changes my mind.

Before I launch into why, though, I want to clarify: I've been very happy with Netlify. They've delivered exactly what they promised: fast, free, static hosting backed by a global CDN. Deploying is as easy as running git push in the terminal; if you're thinking about using them, you probably shouldn't let this post dissuade you.

So, given all those positives, why am I still thinking about migrating the site?

Comparing Rust and JavaScript Ergonomics with a Simple Linked List

My day-to-day work involves writing a fair bit of JavaScript but, lately, I've gotten really interested in Rust.

I'm into the idea of building lightweight programs that can run with lower resource consumption than is typically required for a JS runtime, and Rust's speed, memory safety, and status as the most loved programming language was enough to get my attention. Add in Rust's strong type system and support for many functional-programming features—both areas I've long wanted to dig into—and it's fair to say that I'm Rust-curious at the least. Curious enough to work through the Rust book and the first half of Rust By Example (both of which are great, by the way!). I'm certainly enjoying the process so far.

But, the other day, I decided to take a slightly different approach: I decided to take a simple linked list program—the type can and do ask my students to implement in JavaScript in ~20 minutes—and re-implement it in Rust. Specifically, I decided to build a queue implemented with a singly linked list.

Going in, I expected the Rust version to be much more verbose than the JavaScript version, far faster, and moderately difficult to write. As it turns out, though, the Rust version is hardly any more verbose than the JavaScript version, but was virtually impossible to write—at least in safe Rust. (I was right about it being faster, though).

Generating placeholder images with Pixabay, jq, and curl

Just recently, I found myself in need of several hundred pictures. I'm working on a fairly large-scale app, and I want to be able to test its server infrastructure under load. In my case, that means uploading a decent number of images to Amazon's S3 servers and testing how the app's performs holds up.

So, where to get several hundred reasonably decent pictures, preferably with as little work as possible?

Licensing Difficulties

I asked around, and several of my colleagues recommended Unsplash. In a lot of ways, that would be perfect—they have gorgeous photos, and an easy-to-use API. There's just one problem: The Unsplash API expressly requires all images to be hotlinked back to their servers. As they explain:

Downloads and views are one of the main motivations for many Unsplash contributors. By opening up the Unsplash API to 3rd party applications their photography is seen and used by more users which inspires them to contribute more, new contributors to join, and an even better library for you and your community of creatives.

When displaying Unsplash images, you should use the urls property returned by the API on all of the API photo objects.

That makes a certain amount of sense. (I suspect they might also be harvesting the data for advertising purposes too, based on a closer reading of their ToS—but, either way, it's their product and they make the rules.)

So, if Unsplash is out, what does that leave us with?

Other Options

Well, there's always placekitten. But, just for the sake of argument, let's assume that we'd like somewhat realistic data in our app and that we're building an app that isn't kitten-centric (I know, what is the Internet coming to!).

I investigated a few other options, but none of them quite worked. I looked at Wikimedia Commons (limited API, no way to programmatically filter based on license); Pexels (no public access to API—only after requesting access); Flicker CC (API is exclusively non-commercial); PlaceImage and LoremPixel (Good APIs but very limited image selection).

The Best Choice

After sorting through the contenders, I finally found a site that would work perfectly: Pixabay, which has a great (although not 100% user-friendly) API and allows full use of their images on external server. And everything there is perfectly open-source. Thanks to Thomas Pfeiffer for pointing me in the right direction, by the way.

Having settled on the source of our images, how do we actually go about pulling some down? Let's code!

Mastodon Mobs and Mastodon Mods: Dealing with Outside Groups Pressuring Instance Administrators

The fediverse recently had an incident after a minor celebrity created an account. I very much do not want to talk about the details/merits of that incident¸ but I do want to use it as a prompt for thinking about how the fediverse should deal with some related issues.

Gtypist Lesson Focusing on Programming Keys

Just published a gtypist lesson. The README is below.

GNU's gtypist program is a great way for Linux users to improve their typing speed right from the command line, and is widely available for every distribution. I personally used it extensively when I switched from practicing law to programming and discovered that the keyboard was full of keys I'd basically never needed before. (If you need convincing of the importance of typing speed to programming, please see the postProgramming's Dirtiest Little Secret.

However, despite fitting so perfectly into a programming/command-line workflow, gtypist doesn't actually have a lot of content focused on programmer-specific keys. This lesson fills that gap.

Sending Keybase Chats Using Vim

I cannot spell. Like, was-sent-to-special-classes-as-a-child-and-they-gave-up-on-me cannot spell. Luckily, this isn't an issue 99% of the time as an adult, because I'm never asked to operate in an environment without a spellcheck. Except … I just started using keybase.io's chat program, and it doesn't check spelling. Clearly, this needed to be fixed.

I found a way to fix it: I now write my chat messages in Vim and then pipe them to keybase chat. I thought this would be a pretty rare use case (how many other people really care about spelling, or want to edit one-line chat messages in Vim?) But a number of people expressed interest, so I decided to write this post as a how-to.

I'll give you the tl;dr how-to version quickly, and then I'll walk though what we're doing in a little more detail and talk about how you could customize it for your use-case.

Mastodon Is Better than Twitter: Elevator Pitch

Mastodon is a newcomer social media platform that is a lot like Twitter—short messages, followers, hashtags, all that. But Mastodon is much better than Twitter, and not just because being totally ad-free and keeping chronological timelines make it far more enjoyable to use (though that certainly helps!).

All that is nice, but the real advantage Mastodon has over Twitter is that Mastodon is not an outrage machine that's corroding our ability to view our politic opponents as real humans, deserving of sympathy and understanding.

To explain how much better Mastodon is, I'm going to give you three examples of how Mastodon is better, and then I'll step back and talk about why Mastodon is better.