This guide explains how I install a clean version of Perl from source on macOS, along with the modules that I use every day.
My philosophy for programming tools is to try to keep things as simple and transparent as possible. I often find that modern package and version managers, while powerful, add layers of complexity I don’t need. I rarely require multiple versions of a programming language on the same machine, and I don’t want to hunt for where my binaries and libraries are located. Instead, I prefer a stable, predictable architecture where I know exactly where to find everything.
There are many ways to install Node.js on MacOS, such as nvm or homebrew, but I’ve always preferred a direct, manual approach. For me, this method gives you complete control, involves no extra package managers, and makes upgrades transparent and simple.
This guide will walk you through manually installing Node.js on macOS (and the same principles apply to Linux).
A while back, I decided it was time to finally learn how to touch-type. I was never a slow typer, but my hands constantly roamed the keyboard instead of staying in the home position. Inspired by Steve Yegge to do better, I settled on using GNU Typist (the command is gtypist) as my practice partner.
GNU Typist is run from a terminal window, and is fast enough to run under an ssh session. I’ve run it remotely on RHEL and locally on Linux Mint and WSL. I did have some issues when I tried to build it from my Macbook. I forked the project and made some minor changes to the build process. Here is how I got it to build on MacOS:
Every time I set up a new Mac, I follow a specific process to install my command-line programming tools. My goal is simple: create a development environment that closely mirrors the RHEL web servers I work with daily. This guide outlines that process.
This guide outlines how to install three prerequisites to working from the command line on MacOS: Xcode command line tools, Homebrew, and bash.
It’s been on my list for some time to finally start using Neovim and all that it has to offer as an IDE. As an experienced Vim user, it was hard deciding on what path I should take to convert over. Almost by definition, Vi users are all distinct snowflakes and have their preferred tools and methodologies. That makes it hard to choose who’s advice to follow.
Takeaway
After trying (and failing) to bolt on the IDE components to my current Vim configuration, I came away with the feeling that I can still use Vim as a text editor, but to use Neovim as an IDE I should start from scratch with one of the pre-configured flavors.
Note that I was successful in porting my current Vim configuration, so it would be possible to use Neovim as my ‘Vim’. But for now I think it is safest (and sanest) to maybe use both in tandem for different types of editing.
The GitHub CI Actions for my favorite open-source project, the bookmarking service Shaarli, started failing recently. No one was quite sure why, especially because there hadn’t been any significant updates to the tests, and they passed locally for all the developers who ran them. I had a small pull request that was failing as well, so I thought I would give fixing the actions a shot.