My blog has moved around several times since its inception. I first started it in college using Automattic’s hosted wordpress.com services, then I eventually moved it to a $5 VPS where I self-hosted my own copy of WordPress. After some time of that, its final form has taken the shape of a Hugo-generated static site on a $5 Linux VPS.
I’ll concede that it doesn’t take a substantial amount of toil to deploy a server and configure it to run a basic WordPress blog or static HTML pages for that matter.
I recently read through Cloud Native Patterns by Cornelia Davis. I thought it was a great book. This post is not a review of Cloud Native Patterns, but instead it’s a journal of how I’ve applied some of what I’ve learned.
There have been many times that I’ve declared Popple to be a completed project, but it’s continued to prove itself a valuable playground for experimenting and learning new-to-me ideas in both software development and ops.
I decided to implement a health check capability into my Discord bot. Its uptime is totally unimportant, but it was still fun to do.
In terms of monitoring the Discord bot, there were a few options:
Build my own with cron, bash, and sendmail; install it on a separate host Use cron to send pings to healthchecks.io Use either updown.io or uptimerobot.com. I chose the second option. I found it compelling because the model of pushing a ping from my host to the monitoring API didn’t require me to punch a hole in my host’s firewall so that the monitoring API could scrape the health check endpoint.
I’m willing to bet that many Go programmers have seen or used this strategy for enumerating things in code before:
type Profession int const ( Unknown Profession = iota Warrior Cleric Hunter Mage ) In practice, this is probably fine. In fact, I can’t think of a time this has caused a (known) bug in one of my programs (yet.) Famous last words.
However, there are times where I wish the solution was a little more bulletproof at compile-time.
Behold! The specs Processor: Intel Core i5 11400 6C/12T Motherboard: ASUS Prime 560M-A RAM: 32GiB DDR4 @ 3200MHz (Corsair Vengeance) SSD0: Samsung Pro 970 256GB SSD1: Tcsungbow 1TB ¯\_(ツ)_/¯ Case: CoolerMaster N200 MicroATX Hypervisor/host OS: Debian 11 Bullseye Why? I like virtualization and I want an always-on server to continue to learn and experiment with the KVM virtualization ecosystem.
Why not used enterprise gear? Looks big and loud. Most of the used gear at my price point seemed kind of old, too.
Install an HVF-equipped build of QEMU Download the OpenBSD 7 Install Image Create a new virtual disk Set up the launch script Install OpenBSD Set up host to guest SSH access Install an HVF-equipped build of QEMU The QEMU developers recently merged Apple Silicon support for Apple’s Hypervisor.Framework virtualization layer. This means that barring any complications or removals, the next release tag for QEMU should include this support.
For more information, see the 6.
I’ve written previously about Booting Cloud Images with QEMU. However, I’ve since graduated to a more convenient method of spawning virtual machines. This method is also much faster and is more cohesive with the rest of the virtualization stack that you’ll find on your Linux distribution. As someone who creates and tears down tons of virtual machines for testing things, this method appeals to me more than the previous. Let’s get into it.
I’ve been having a lot of fun lately refining a weekend project I started a few months ago. I basically threw this bot over the wall back in early April. About a month ago, I started getting serious about learning the Go programming language, so I thought I’d just revisit my Discord bot with a more “learned” eye and find ways to polish it up a bit.
Popple is a Discord bot that I made for myself and my friends, and it has been my playground for practicing everything I was learning in a project with an extremely small blast radius.
Regardless of how one might feel about patches-over-email software development, the reality is that a lot of exciting open source projects are developed on mailing lists. Configuring a pleasant plaintext-oriented e-mail environment may not be obvious for those of us who come from a primarily git forge style background. At least, it wasn’t for me. In any case, I’ve finally arrived at a productive setup and I’d like to write it down here for posterity.
Check out the changes locally For everything but the most trivial of patches, check change out locally. Not only is this a technical prerequisite for some of the other tips in this article, but I’ve found it is easier to remain focused on the review when it takes place outside of my email inbox/GitHub/Gitlab/etc.
Use more context when viewing changes The default context for a diff is rather narrow. It will show lines added and removed next to only a few other lines of the code.