Design Needs More Brutalism
I was trying to use the mobile Google Authenticator app today and I couldn’t read the entire name of the last code I have installed because of the stupid floating "+" button.
The reality is, I sort of know which codes I have installed so I knew which one it was but it struck me: someone thought it was a good design system to have something that obscures the data the user is trying to look at. The Gmail app is another offender, here. The button to create a new email is floating over the list of email’s I’m looking at and obscuring the subject line. I have to scroll my email list in order to read it.
Discord
I created a Discord server. To join follow the link below.
In Defense of -target
Warning
|
Martin Atkins wrote a comment on reddit going into detail about how and
when -target can get you into sticky situations. I have added it to the
bottom of this post and linked out.
|
I’ve been, rightly, downvoted in r/terraform for recommending using -target in production. I say "rightly" because I know it’s a controversial suggestion and I’ve just sort of dropped it like a bomb without defending my position. So here is my defense.
As Configuration
Mitchell Hashimoto post As Code this week reflecting on what "as code" means to him. Different from the popular interpretation of being literal code, his view is that the "code" in "as code" is a 'system of principles or rules", like a "code of ethics". The poor guy has probably been the target of angry emails for a decade.
My experience in the Infrastructure-as-Code world has been that a lot of people
do take the "as code" a little too literally. Usually it’s being strict about
workflows, like dogmatically insisting we should do apply-after-merge
because
that’s closer to the workflow for application code. While I don’t 100% buy
Mitchell’s post, Terraform is clearly trying to make infrastructure management
more like a programming experience, I agree with the sentiment.
Is the Unix Philosophy Still Taught in School?
The Unix Philosophy defines a culture of how to write tooling in the Unix world. At its core, the Unix Philosophy is about designing tools that work together. A consequence is that there must be some rules or convention such that programs can communicate. The power of the Unix Philosophy is that it lets us both automate our workflows and also build more sophisticated and powerful solutions by combining tools. The most common conventions in the Unix world are:
retry: My Favorite API
I like an API that captures a problem and expresses it concisely. I imagine this is how mathematicians feel when they create a beautiful proof. I’ve always enjoyed a good API but it wasn’t until I worked with one of my best friends, who has a background in type systems, that I really started to appreciate what it means to create a good API.
I have a bunch of APIs I like but probably my favorite is retry
, which I’ve
implemented in several languages.
Siren Call of SQLite on the Server
At Terrateam, we are big fans of Fly.io. The service is hosted there and it’s served us well. Just deploy your TOML file, get your infrastructure, do something else with the rest of your day.
One of the interesting sides of Fly is that they invest heavily in server-side SQLite. They’ve written a number of blog posts on how they enable server-side SQLite:
-
I’m All-In on Server-Side SQLite - Ben Johnson, the author of BoltDB, joins Fly to work on Litestream, a SQLite replication solution.
-
Introducing LiteFS - The introduction of LiteFS, which is a FUSE file system designed to replicate SQLite transactions over the network.
-
LiteFS Cloud: Distributed SQLite with Managed Backups - Introducing backups and restores for LiteFS.
Terralith: The Terraform and OpenTofu Boogieman
Terrateam has a very expressive configuration file. We need it because, as any Terraform or Tofu user knows, there is no standard on how you should design your repository. The Eternal September question of r/terraform is asking how to structure a repository for multiple environments. It comes up so much that we even wrote a blog post about it.
Terraform and Tofu users, in my experience, are especially concerned with how to structure a repository. I think this is because Tofu is so low-level. It concerns itself with how to manage the specific resources within your infrastructure but not really your infrastructure as a whole. Tofu manages a state file, which is how it connects the code you write to the actual infrastructure in the cloud. Each directory that has a state file associated with it is called a root module. You run the Tofu program in a root module and it evaluates everything.
The Enshittification of the Chromecast
My favorite Google product for a long time has been the Chromecast. It solved a problem, it was easy to use, and it just worked. It also turned watching YouTube into kind of a social experience, where everyone could connect and add videos to the queue.
My favorite thing about it is you just had to be on the network to cast. I didn’t have to make an account and add myself to a friend’s house group or something. You just connect to whatever Chromecast-capable device is on the network and start casting.
Loops In Tofu Are Weird
Note
|
I will refer to OpenTofu in this post, however everything I say applies equally to Terraform. |
Tofu uses HCL to define infrastructure. It’s fairly simple. Closer to a configuration language than a programming language. Choosing a DSL for a product can be hit-or-miss, but in this case I’m fairly pro-DSL. Given the goals of Terraform (the project OpenTofu is a forked from), using something like YAML would quickly become difficult to manage infrastructure at scale, and a full-fledged programming language brings a lot of complexity. While I understand why users of CDKs and Pulumi like it, I think HCL is accessible to more people. I wouldn’t say that HCL is a great language but it gets the job done and is mostly straightforward. Being a simple language meant that we could implement a parser in Ocaml for Terrateam, which let us implement some neat features around code indexing.