iamjackg

Good thing it's not a cloud service then!

It is indeed. It's an interesting open source project too, because its usefulness is very much inversely proportional to the time you spend using it! Contributors often start submitting changes, then their children grow up and they lose interest in the project. Sort of a built-in attention span limit.

For me, a lot of that came down to making sure every automation I add is usable with the least amount of mental effort. For the longest time I didn't automate much at all and often questioned whether I needed all this or not, then we had a baby.

Now we have a button in his nursery that will dim the lights, start playing white noise on a Google Home speaker, mark the start of a new nap on our Babybuddy instance, then turn off the lights after 30 seconds. When I press it again, it turns off the noise and stops the sleep tracking. If we didn't have Home Assistant we'd have to do all these things manually multiple times a day. Instead it just takes a single button press.

It's a small example, but things like this will keep popping up, and I'm looking forward to making them easier.

From the way you worded this, I was expecting them to use the chair and sleigh as propellers. What's special about OP is that the propeller design is unusual, proving that Leonardo wasn't that far off when he came up with the idea.

Sorry, it was not my intention to construct a strawman: maybe I misunderstood what you were saying.

> a way for the EU to control US companies, extending their power beyond their jurisdiction

How are they extending their power beyond their jurisdiction, considering that this is something done in the EU to EU citizens?

If those companies extend their business beyond the US' jurisdiction, why do you feel they shouldn't be subject to some form of control where they operate? I'm legitimately asking. This is about something that was done within the EU to EU citizens. Why shouldn't the EU have a say?

Ansible is awesome, but would largely be overkill for something like this. I'm not doing much more than ensuring a few things are in place, merging a couple files, and then running docker-compose up/down, or exec-ing into running containers to run commands. I certainly wouldn't want people to have to run an entire playbook just to do all this: it's slow, requires even more setup, and is not really well suited for quick CLI-like use.

For 1, I do agree that the term is overused, but in this case it's not really about the beauty of the code itself: it's about the fact that the final generated script acts in a predictable way and prints information and help messages in a format that people are already familiar with. You don't have to write your own usage message: it does it for you, and it looks the way I would expect a usage message to look.

I also see argument 2 a lot, and I've already addressed this in other comments, but sometimes you really just need to call a couple of commands while prepping some env vars or config files for convenience.

In those cases, reaching for Python or Go ends up being a lot of boilerplate for very little advantage, especially when you want to pass control over to other applications once you're done setting things up.

Since the landing page is not the clearest, you can think of this as an argparse equivalent for Bash.

You provide a YAML file listing commands, subcommands, arguments, and flags, and it automatically generates a Bash script that can parse and validate them, provide help messages, and run your code for each command.

It also lets you keep the actual code for each command and subcommand in separate files, which are merged together into one distributable Bash script at generation time.

It's basically a templating system to auto-generate argument parsing so you don't have to solve that again or deal with things like optparse.

I have, and I quite like it! That doesn't seem to be the way most people feel about it though.

I need to build things that pass the bus audit: other people also have to understand them and work on them and, for better or for worse, Bash is a very popular lowest common denominator for many devs.

In my case, I used it to build an all-in-one tool for a local dev environment. It wraps all kinds of operations for starting/stopping things, extracting and modifying data, etc. while providing some useful tips when things go wrong.

At its core it's just interacting with existing software like docker-compose, git, and some internal tools, which I find is still much, much easier to do with shell scripting than "proper" languages.

Hah! I have to admit that I spent quite some time thinking about whether I wanted to use this or switch to a "real" language.

For all its shortcomings, I find that shell scripting is still the easiest way to put together a tool that needs to interact with a lot of other commands, no matter how large it ends up being. I love Python to death, but using `subprocess` for everything is the opposite of my idea of a good time.

I think you might have misunderstood the comment you're replying to: they're saying that economies (and related policies) are often built through some form of design process, not that factory jobs are design jobs.