You start with the cleanest most minimal config you can get away with, but over the years you keep adding small additions and tweaks until it becomes a massive behemoth that only you will ever understand the reasoning behind.
Part of doing it well is adding comments as you add options. When I used vim, every line or block in the config had an accompanying comment explaining what it did, except if the config’s name was so obvious that a comment would just repeat it.
That's a good call. It's a big problem for JSON configs given pure JSON's strict no-comments policy. I like tools that let you use .js or better yet .ts files for config.
I like this idea a lot, and pushed for json5 at a previous job, but I think there are a few snags:
- it's weird and unfamiliar, most people prefer plain JSON
- there are too many competing standards to choose from
- most existing tools just use plain JSON (sometimes with support for non-standard features, like tsconfig allowing trailing commas, but usually poorly documented and unreliable)
Much easier just to make the leap to .ts files, which are ergonomically better in almost every way anyway.
A lot of json parsers will permit comments even though it isn't meant to be valid. Worth trying it, see if a comment breaks the config, and if not then use comments and don't worry about it.
My gut reaction is to rush to the comments to shill my favourite task runner ( mise tasks[1], now with shell aliases[2]!) but pushing past that, the core idea of writing scripts in a file rather than a shell prompt is a great nugget of wisdom. But I disagree with this bit:
"I want to be clear here, I am not advocating writing “proper” scripts, just capturing your interactive, ad-hoc command to a persistent file."
What's the difference? Why not version control it, share it with colleagues. Imagine writing a unit test to test a new feature then deleting it when done, what a waste. Ok it's not exactly the same because you aren't using these scripts to catch regressions, but all of that useful learning and context can be reused.
I don't think the language you use for scripting is too important as long as the runtime is pinned and easily available on all engineers machines, perhaps using a toolchain manager like... mise[3].
Do these scripts need to be productionised? I prefer working in an environment where efficient sharing of knowledge and solutions is encouraged, rather than framed as a burden of responsibility.
Given the choice between starting with an almost-working script or starting from scratch, I’ll take the former, it might save a few hours.
My colleagues and I don’t do this 100% of the time, but I never regret it and always appreciate it when others do.
Yeah, some of it can be solved as a simple naming convention thing. `_scripts/*.ts` for scripts that are "reproduceable" and/or production-ready and `_scripts/scratch/*.ts` or `_scripts/${username}/*.ts` for scripts that are piecemeal or work-in-progress or user-specific or otherwise "throwaway". Or a graduation process such as where things in `_scripts/` are considered "throwaway" until added to and documented in a larger production task runner like adding them to the "tasks" section of a deno.json file. (They graduate from being shebang run to `deno task taskname` run. They get basic documentation in the `deno task` list and various IDE integrations of such.)
The major thing to be concerned about there is leaking things like hard-coded secrets and that's where something like .env files can come in handy and knowing your tools to make use of them. Deno (as the running example) makes using .env files easy enough by adding the `--env` flag to your `deno run` shebang/task-line and then using `Deno.env` like any other environment variable. (Then don't forget to .gitignore your .env files.)
Heh, honestly I'm kind of touched that you went to that effort.
Obviously I was using hyperbole. But I can say for sure that my life as a developer and second-rate sysadmin improved when I adopted as policy that I would never ever write any Bash script. Not even for a supposed one-liner, since I could just write that in ZX and avoid any temptation to write (and badly maintain) a Bash script.
My main problem with matrix is that it feels sluggish. I'm told the experience can be improved by running your own homeserver so I'll be trying that sometime this year.
In my limited experience, running a homeserver sucked. Really hard to do on limited resources. Then again, that was a long time ago so maybe things have improved and perhaps Dendrite has come along. But Synapse sucked to run IME.
Synapse has improved; Dendrite has stagnated due to lack of funding; meanwhile there are also rust-native homeservers like Conduit which are beta but smaller footprint. The plan on the Element side is to keep optimising Synapse - the main win to be had is https://docs.google.com/presentation/d/1pKtLl4vCV3-8xz8crvxW...
Mise started out using the same plugins as asdf, mostly focused on adding performance and usability improvements. Over time it added more features and security.
Most tools are now directly fetched from github releases without the need for random shell scripts (which is what asdf plugins are).
It also grew to be a task runner and environment manager. At first you might think this is scope creep but they're both opt in and very elegant additions. I don't want to ramble but let's just say they've solved real problems I've had.
I'm a fan of it, and I can't think of a reason why I would use asdf over mise. Its real competition is nix (+devbox/devenv/flox), devcontainers, and pixi.
Frontend churn has chilled out so much over the last few years. The default webapp stack today has been the same for 5 years now, next.js (9yo) react (12yo) tailwind (8yo) postgres (36yo). I'm not endorsing this stack, it just seems to be the norm now.
Compare that to what we had in the late 00's and early 10's we went through prototype -> mootools -> jquery -> backbone -> angularjs -> ember -> react, all in about 6 years. Thats a new recommended framework every year. If you want to complain about fads and churn, hop on over to AI development, they have plenty.
jjui is definitely the best contender ive seen for a jujutsu ui. although, with the ergonomics of jj, and a decent merge editor setup like meld, i haven't really needed a ui at all
I've been fighting the git CLI for over a decade and I've recently picked up lazygit so I can relate to this post. A good TUI has made git a joy to use and when I did try to pick up jj last year it seems like too much learning for too little gain.
I think git will be "good enough" version control for many years to come.
HOCON is so overlooked but an almost ideal config language in my eyes. The only element I'm not 100% on is unquoted string values (the norway problem but not quite as bad since there isn't no/yes booleans), but even thats not too bad.
reply