Weaving Raku: semiliterate programming in a beautiful language

The other day (er, ok, month) Brian Wisti wrote an excellent blog post about tangling code using Raku.

Inverse inspiration

My first thought when reading that post was that I want exactly what it describes. My second thought, however, is that I don't – I actually want the exact inverse of what the post describes.

Brian wants to start by writing documentation and then to tangle code out of that file and into one or more executable programs. In his example, Brian starts by writing a Markdown file, and then processes it to produce multiple executable files in multiple programming languages.

On the other hand, I want to start by writing some code – specifically, some Raku code – and then to weave documentation out of that file. Like Brian, I want to write one file that both tells a story and produces machine-executable code; unlike Brian, I want to start a bit closer to the code, and generate the documentation.

Wait, isn't that just Pod6?

At first, this could sound like I'm just describing Pod6, Raku's excellent tool for writing and formatting documentation. Using Pod6, it's already easy to write clear, well-formatted documentation directly in-line with your code. And you can then render the documentation as Markdown, HTML, plain text, or any other output format you'd like. Isn't that exactly what I said I wanted?

Well, no, not exactly. A Raku file with Pod blocks is cleanly divided into documentation (everything inside Pod blocks) and code (everything outside Pod blocks). When you render output documentation, the code is ignored; when you run the code, the documentation is ignored.

This works great for many typical Pod use cases, but it doesn't really let us do the sort of thing Brian was talking about: we can't use Pod to write code and to display that code as part of our documentation. That's a little abstract, so maybe an example is in order.

(read more)

Raku testing and conditional compilation

I've been really falling in love with the Raku programming language – it's powerful, expressive, has great support for introspection, strong pattern matching, and extremely good support for metaprogramming. I'm pretty much sold on using it for any project where I don't need raw performance. (When I do need raw performance, I still reach for Rust).

That said, there are a few niceties and patterns I miss from Rust. Fortunately, Raku is powerful enough to make nearly all of them possible, usually with just a few lines of code.

Today, I'd like to talk about one example: Writing unit tests in the same file as the code under test, without any runtime cost thanks to conditional compilation.

(read more)

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.

(read more)

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.


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

My main desktop, when I log in: screenshot of my default desktop

(read more)

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:

Screenshot of time stamps generated in vim

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:

(read more)

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?

(read more)

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).

(read more)

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!

(read more)

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.

(read more)

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 from the comfort of their terminal, and it's 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.

(read more)
← Later posts Earlier posts →