Repairing a Botched Arch Linux Kernel Upgrade
I made the jump to Arch Linux on my personal and work computers a few years ago. Ubuntu was a dependable experience, but a combination of issues with the Debian way of life (slow progress) and Canonical's stewardship of the project (e.g., Snaps) convinced me it was time to try another distribution.
It's been a great experience. Pacman is a wonderful package manager, and AUR is everything I wanted PPAs to be. I get the latest versions of packages (including the Linux kernel) shortly after they're released. Of course, that isn't always a good thing, but rolling back to an older version is straightforward.
I recently stubbed my toe in a way that's unique to Arch - my computer crashed while I was in the middle of upgrading my kernel. What's great is I was able to recover with only an hour or so of downtime. What happened?
Migrating my Neovim Config to Lua
I've been a happy Neovim user for the past several years. The pace of development, quality of the product, and energy of the community have made it enjoyable to use. Recently, the project has introduced Lua as a first-class citizen in the editor. In places where you may otherwise be forced to wrangle the mess that is VimL (aka Vimscript), you can instead use a saner, faster scripting language.
I initially refrained from making the jump over to Lua as I held the ideal of being able to return to Vim whenever I wanted. With the release of Vim version 8, which doubled down on VimL, I realized my folly. Vim wasn't going to suddenly adopt the good parts of Neovim, nor was that community going to change overnight. With that, I sat down one Saturday to get to porting. After a few weeks of on-and-off experimentation (and exploring both /r/neovim and GitHub to see how other people did things) , I landed on a stable, Lua-first config that's been humming along for several weeks now.
Let's dive in!
How Git Checkout's Previous Branch Shortcut Works Under the Hood
One piece of Git shorthand I use all the time is git checkout -. Much like
cd -, it references the previous item in your history. In the case of cd,
it will change your current directory to the previous one you were in. So,
$ echo $PWD /home/aru $ cd code/git-req $ echo $PWD /home/aru/code/git-req $ cd - ~ $ echo $PWD /home/aru
Git has its own version of this:
$ git branch --show-current master $ git checkout my-new-feature Switched to branch 'my-new-feature' Your branch is up to date with 'origin/my-new-feature'. $ git checkout - Switched to branch 'master' Your branch is up to date with 'origin/master'.
Handy! But how does it work? I poked through the files in .git (and even
watched the filesystem for changes, but nothing jumped out).
Elixir Development with Vim
I love Vim (more specifically, the NeoVim fork). Modal editing as part of my Unix IDE brings an immense amount of productivity and enjoyment to my day-to-day development activities. As such, whenever I take up a new language or framework, I enjoy experimenting with how best to integrate it into my existing workflow.
Having started programming in Elixir, I've started the customization journey for the language. Much as with Maslow's Hierarchy of Needs, there's a hierarchy of editor support required for an fulfilling programming experience. Let's get there with Elixir!
Kicking the Tires with Elixir, Part 1 - Pipes
Lately I've been playing with Elixir, a functional language that sits over Erlang and the OTP framework. It's exciting because it handles embarrassingly scalable problems with aplomb, enabling a high level of parallelism and concurrency with a great developer experience. While I think Rust shines at the system programming level, Elixir seems like a perfect candidate for web services - balancing power with ergonomics.
There are plenty of well-written posts about the language and its associated libraries. I wanted to touch on what stood out to me as a Pythonista, web developer, and nerd. I don't know how many posts will comprise the series, but I have at least a few topics in mind.
First up: pipes.
Migrating from Gmail to Fastmail
In 2004, Google launched Gmail. This service changed everything. You didn't have to worry about running over your few megabytes of quota - your storage space was "unlimited" (with a ticker and everything)! Deletion was a thing of the past, you now archive! Folders were so ninety-ninety-late, there were labels! I got an invite within the first two weeks of it launching, and it was good.
A decade or so later, Google launched Inbox, which brought innovations like bundles, snoozing, highlights, pinning, sweeping, and smart filtering to the deluge of email that flooded your account each day. I switched from Gmail to Inbox, and it was better.
Then, in true Google fashion, it was sacrificed at the altar of project mismanagement (or whatever the lack of product strategy is called). And it was bad.
Since being forced back to Gmail, I've constantly lamented the death of a service that made dealing with email less painful for me. Gmail is not only without new innovation, but it's also slow; It regularly fails to load new messages, or seemingly loses track of what it should be showing, necessitating a hard refresh. Sure, Google has thrown a few bones at it, like smart replies, but I respond to so few emails that spending a few seconds to formulate a response has never been an issue.
Given these concerns, I realized that the "stickiness" of Gmail was gone. I have the means to pay for service, and nothing is keeping me on Gmail (other than the fact that everyone's been using my Gmail address for 16 years). Leaving Gmail sounded doable, and I owned a personal domain on that I'd love to use for email. The only question was: where do I go for hosting?
Optimizing Rust Binary Size
I develop and maintain a git extension called git-req. It enables developers to check out pull requests from GitHub and GitLab by their number instead of branch name. It initially started out as a bash script that invoked Python for harder tasks (e.g., JSON parsing). It worked well enough, but I wanted to add functionality that would have been painful to implement in bash. Additionally, one of my goals was to make it as portable as possible, and requiring a Python distribution be available flew against that. That meant that I needed to distribute this as a binary instead of a script, so I set about finding a programming language to use. After surveying what was available, and determining what would be the best addition to my toolbox, I selected Rust.
The programming language has a steep learning curve, but has been fun to learn and immerse myself within. The community is great, and I'm excited to find more opportunities to use Rust in the future.
The rewrite took a while to accomplish, but when all was said and done, everything worked, and worked well. I was able to implement some snazzy new features as well as polish some rough edges. However, for how "simple" I felt the underlying program to be, it clocked in at 13 megabytes. That felt like a lot. So, I decided to see what could be done.
Elasticsearch Frustration: The Curious Query
Last year I was poking at an Elasticsearch cluster to review the indexed data and verify that things were healthy. It was all good until I stumbled upon this weird document:
{ "_version": 1, "_index": "events", "_type": "event", "_id": "_query", "_score": 1, "_source": { "query": { "bool": { "must": [ { "range": { "date_created": { "gte": "2016-01-01" } } } ] } } } }
It may not be immediately obvious what's going on in the above snippet.
Instead of a valid event document, there's a document with a query as
the contents. Additionally, the document ID appears to be _query
instead of the expected GUID. The combination of these two irregularities makes
it seem as if someone accidentally posted a query to the wrong endpoint. No
problem, just delete the document, right?
DELETE /events/event/_query ActionRequestValidationException[Validation Failed: 1: source is missing;]
Wat.
A DevOps Workflow, Part 3: Deployment
This series is a longform version of an internal talk I gave at a former company. It wasn't recorded. It has been mirrored here for posterity.
Congratulations, your code looks good! Now all you need to do is put your application in front of your users to discover all the creative ways they'll break it. In order to do this, we'll have to create our instances, configure them, and deploy our code.
A DevOps Workflow, Part 2: Continuous Integration
This series is a longform version of an internal talk I gave at a former company. It wasn't recorded. It has been mirrored here for posterity.
Look at you – all fancy with your consistent and easily-managed development environment. However, that's only half of the local development puzzle. Sure, now developers can no longer use "it works on my machine" as an excuse, but all that means is they know that something runs. Without validation, your artisanal ramen may be indistinguishable from burned spaghetti. This is where unit testing and continuous integration really prove their worth.