2022-07-19.01
Discover more from hrbrmstr's Daily Drop
2022-07-19.01
dua; DNS Response Size; Command Line Interface Guidelines
Howdy, Denver! Managed to slipstream an edition in amongst travel (I had forgotten just how much I hate domestic air travel). Still lots of command line goodness, today, with a DNS deep dive tossed in for good measure.
dua
dua [GH] ("Disk Usage Analyzer") is a Rust crate and CLI tool, created by Sebastian Thiel (@theelbasian), to conveniently learn about the usage of disk space of a given directory. It's parallel by default and will max out your SSD, providing relevant information as fast as possible. It can also optionally delete superfluous data, and do so more quickly than rm.
Not only that, but it is fast. Tap the link in the header image caption to get a full demonstration of what you can do with it.
I ran it interactively to poke at my recent Rust projects and realized I need to get way better at cleaning up targets/.
As noted, you can also use it in your own Rust (et al.) apps if you don't want to use it on the command line.
DNS Response Size
Pop quiz: What is the maximum number of A records in a DNS round-robin? Or the largest number of bytes in a TXT record? Maybe it's all the same, and we should ask what is the maximum size of a DNS response?
Is it…
512 bytes
1,232 bytes
65,536 bytes
"It depends."
?
Let's find out!
The above is how Jan Schaumann (@jschauma) started his blog entry on the topic, and I heartily suggest you dig into the wild ride Jan takes us on.
I think I've mentioned how much I 💙 DNS in previous editions, and if you don't 💙 DNS even 1/10th as much as I do after reading it, then I guess you're just gonna have to be perma-REFUSED (RCODE 5) queries for new editions.
Command Line Interface Guidelines
Command line tools are heavy on my mind, having just written yet-another Rust-based CLI tool.
As someone who has been using the command line for ages, seeing the initial differences between legacy tools such as find and grep compared with two modern alternatives — fd and ripgrep, respectively — was a fantastic experience. Intuitive defaults; great help/documentation; and serious speed.
Aanand Prasad, Ben Firshman, Carl Tashian, Eva Parish, and Mark Hurrell also 💙 the command line and wanted to help aspiring CLI developers build modern CLI tools. So, they put together an open-source guide to help folks write better command-line programs, taking traditional UNIX principles and updating them for the modern day.
Here's their pitch:
A lot has changed about how we program computers since those early days. The command line of the past was machine-first: little more than a REPL on top of a scripting platform. But as general-purpose interpreted languages have flourished, the role of the shell script has shrunk. Today’s command line is human-first: a text-based UI that affords access to all kinds of tools, systems and platforms. In the past, the editor was inside the terminal—today, the terminal is just as often a feature of the editor. And there’s been a proliferation of git-like multi-tool commands. Commands within commands, and high-level commands that perform entire workflows rather than atomic functions.
Inspired by traditional UNIX philosophy, driven by an interest in encouraging a more delightful and accessible CLI environment, and guided by our experiences as programmers, we decided it was time to revisit the best practices and design principles for building command-line programs.
The guide is gorgeous, sensible, and informative. Even if you're "just" building internal CLI tools, you'll build better ones after digesting this tome.
FIN
Tis going to be a very, very long day but 🤞🏽 for a Wednesday edition. ☮