In September 2018 I switched job to work as a remote consultant for a small UK company. Without a work computer, I considered buying a Mac for the following reasons:
Ruby development in Windows is a pain
I like the UNIX environment
The overall user experience, I believed, was top-notch
The other option would have been Linux, but my experiences of macOS had, until that point, been better than my experiences of Linux.
Figuring that I’d want about five years out of the machine, and having worked for too long on too-slow Macs, I dropped € 3,200 (~ $3,719 at the time) on a high-spec 15-inch Macbook Pro1 — the most I’d ever spent on a computer, high-end gaming machines inclusive. It stung, but I wasn’t about to skimp on the most important tool of my trade.
The purchase would go on to be my most regrettable, whose resulting ordeal is still far from over. The toll it has taken on me is evidenced by my writing this at 4:30AM on a work night, awoken and unable to fall back asleep with the whole debacle running through my head.
Over the past few months, I’ve been on a bit of a journey through different OSes1, desktop environments, apps, and even editors. Ultimately I settled on Arch Linux + KDE Plasma + Neovim, but I ended up with some different ideas along the way.
One such idea was to ditch tmux and simply use a modern, more featureful terminal emulator. I primarily used tmux for splitting “windows” and its scrollback buffer, but it contributed another layer of abstraction to debug when things like performance, colour support, or displaying images became a problem. Meanwhile, almost any modern terminal emulator can do splits and scrollback buffers.
So I settled on Konsole, which supports all that I need and some other niceties (like ligatures). I set up my key bindings to create splits similarly to those I used in Tmux, and… immediately missed a feature of my tmux setup. This was the ability to switch between tmux panes and vim splits using the same key combination, as though they were in fact the same thing.
# regular named paramsHASH.map { |a, b| [a, b] }
# new numbered paramsHASH.map { [_1, _2] }
Anyway, I wondered if there was any performance impact in this change so I threw together a quick benchmark. Result: it’s just as fast as named params.
Update: This post originally benchmarked against Xsv v0.3.2, but many performance changes (particularly to memory) were made, so I’ve now benchmarked against v0.3.7 and updated accordingly.
TL;DR: Xsv was ~5 times faster than alternatives at parsing the XLSX file I benchmarked it against, allocating the fewest objects and memory, making it by far the least resource-intensive of all benchmarked gems.
When exporting data for general use, we in the industry are likely to reach for CSV files; they’re basically plain-text, but with a sort-of agreed-upon structure — well, there is RFC 4180 but Wikipedia agrees that implementations are inconsistent at best.
I previously wrote about this topic, but it involved generating a special SSH key and adding that to git config. One day I realised I could just use agent forwarding, so here’s the process.
Assuming Hass.io, install the official SSH Server addon and add your public key the config.
Now let’s init our git repo and reset it to the remote config.
I have a PC hooked up to the TV in our living room, which is used primarily for Kodi and video games. I’m using a Logitech Harmony activity to switch the TV on, power the AV receiver, change to the PC input, etc. The only problem is that there’s no way to turn on or off the PC via Harmony, so I often sit down and forget to turn it on, or go to bed and find that it has been running all night. Inconvenient and a waste of energy!
Thankfully, we can use HomeAssistant to bridge the gap, but there are a few pieces to the puzzle.
One of our servers recently experienced an issue in that its disk usage was consistently growing to illogical, unmanageable proportions. This would trigger an OpsGenie alert and wake me up, so in a groggy state I’d delete some extraneous log files (we log a lot), promise myself to look into it tomorrow, and go back to bed.
I don’t have the best of memories at the best of times. This happened a few times before I looked into the problem.
First I thought we were just logging “too much” — actually we require pretty extensive logging, so my proposed fix was to be increasing the server’s disk space — until I saw a massive difference between the output of sudo du -h --total --max-depth=1 / and df -h --total / — a 14GB difference on a 25GB server.
I use HomeAssistant for my home automation needs. It does a fantastic job, but does require regular editing of config files. Although we can install vim on the server, I’m much more at home editing on my local machine, so I was in search of an easy way to keep config files in sync.
There are a whole host of ways to achieve this, but I settled on what I think is the simplest: a git repository hosted on GitHub. Rather than setting up a git server on the HomeAssistant machine, it’s simpler to manually pull to keep things in sync, but a little less convenient. With a little tweak, though, it works perfectly. Here’s a quick walkthrough.
To those of us who have embraced editing text in vim, working on anything longer than a sentence outside of vim becomes rather frustrating. This means we’ll often open up vim, write our thing in there, and paste it back into the original text control.
But there are better ways. After much trial and error — and with the help of various findings on Google — I’ve created a couple of Automator scripts to make working with vim on MacOS less chafing. The following assumes NeoVim and iTerm2, but porting to regular vim and Terminal.app should be fairly simple.
Having written a number of API clients in Ruby, I’ve often run into the problem of testing them. We can assume that the API will return the results specified in their documentation, but we’d still like to see what our API client returns; this may differ considerably from what the API itself returns.
The last thing we want to do is hit the actual endpoints: this is slow, may incur rate limiting, the server may be down at test time, endpoints may change, and it’s just not cool to hammer an external service.
This is a little round-up of approaches I’ve had success with.
I’ve long been in search of good Ruby auto-completion framework for vim, without luck. As soon as a new option comes about, I’ll jump on it, only to find that it either doesn’t work at all, or sometimes does its job at best.
Fortunately, we now have Solargraph. Solargraph understands Ruby code and does a great job of extracting pertinent information for auto-completion, documentation, and refactoring purposes.