This is a collection of “tips and tricks” I’ve put together over the years for the tools I use to do command-line development, network monitoring, and server maintenance.
I use htop to view the list of running processes on remote machines.
Things I do on remote hosts.
Using one of my tools, Specsheet, to check that my Mac is up-to-spec.
Automating things I do during development.
Some tips and tricks for Wireshark, the packet explorer.
I use the fish command-line shell, because I like its friendly syntax, its auto-complete feature, and its sensible set of defaults.
Wrangling Rust development.
I’ve learnt a lot of useful information by going over people’s dotfiles and configs, or reading interviews to see which tools they use. I’d get ideas for things to automate that I hadn’t considered before, see solutions to problems I’d just accepted, and just find it interesting seeing the way other people work. I then used to copy parts of their working environment to my own.
The thing is, there are many tools out there, and an even larger number of ways to connect them. I’ve grown worried that our development environments are getting too many “rickety bridges”, where even if we’re using rock-solid, proven, stable programs, we’re connecting them together with random scripts found on the Internet and tweaking them with suggestions from forgotten yet authoritative-sounding blog posts from 2011.
I think we can do better. In these notes, I want to describe the workflows, customisations, overridden defaults, and pipelines between programs that have proven themselves to work for me, and I hope you find them useful, too.
The code samples and scripts embedded in these technical notes are licenced CC0, which means you are free to run, copy, adapt, and modify them, even for commercial purposes, with no attribution required.
However, I must state that the commands, code, and scripts are all provided “as-is” without warranty of any kind. You are ultimately the one responsible for doing any research or diligence before following any instructions listed here, meaning you will be liable if something goes wrong. Always read the official documentation before running a command — never blindly copy-and-paste something without learning what it does beforehand.