Also, if I'm being honest, it's much better to use `--wet-run` for the production run than to ask people to run `--dry-run` for the test run. Less likely to accidentally fire off the real stuff.
I'm using MVC design patterns for some codebases, I'm using DDD plus Event sourcing and Event Driven for others.
I suspect that you are thinking of a small subset of design patterns (eg. Gang of Four derived patterns like Visitor, Strategy, or Iterator )
no patterns. -> Everything must follow the gang of four's patterns!!!! -> omg I can't read code anymore I'm just looking at factories. No more patterns!!! -> Patterns are useful as a response to very specific contexts.
I remember being religious about strategy patterns on an app I developed once where I kept the db layer separated from the code so that I could do data management as a strategy. Theoretically this would mean that if I ever switched DBs it would be effortless to create a new strategy and swap it out using a config. I could even do tests using in memory structures instead of DBs which made TDD ultra fast.
DB switchover never happened and the effort I put into maintaining the pattern was more than the effort it would have taken me to swap a db out later :,) .
For services, I prefer having them detect where they are running. Ie if it's running in a dev environment, it's going to use a dev db by default.
The program should default to actually doing whatever thing you're asking it to do.
On the other hand it would be great if every tool had an --undo argument that would undo the last thing that program did.
> NILFS2 is a log-structured file system (LFS) supporting continuous snapshotting. In addition to versioning capability of the entire file system, users can even restore files mistakenly overwritten or destroyed just a few seconds ago.
https://docs.kernel.org/filesystems/nilfs2.html
And this works well if your CLI command is simply performing a single operation, e.g. call this REST API
But the moment it starts to do anything more complex: e.g. call API1, and then send the results of API1 to API2 – it becomes a lot more difficult
Of course, you can simulate what API1 is likely to have returned; but suddenly you have something a lot more complex and error-prone than just `if not dry_run:`
I've yet to have anyone mistakenly modify anything when they need to pass --commit, when I've repeatedly had people repeatedly accidentally modify stuff because they forgot --dry-run.
$ rm file.bin
$ rm —-commit file.bin
$ cat foo.txt > bar.txt
$ cat foo.txt | tee —-write-for-real bar.txt
$ cp balm.mp3 pow.mp3
$ cp —-i-mean-it balm.mp3 pow.mp3
if [ -n "$DRY_RUN" ] ; then
alias rm='echo rm'
alias cp='echo cp'
fi
`rm` a single file? Fine. `rm /`? Maybe block that one.
I use "live run" now, which I think gets the point across without being sort of uncomfortable.
--make-it-so
--do-the-thing
--go-nuts
--safety-off
So many fun options.
I prefer the inverse, better, though. Default off, and then add `--commit` or `--just-do-it` to make it actually run.
This should always be included in any application that has a clear plan-then-execute flow, and it's definitely nice to have in other cases as well.
--really
--really-really
--yolo
"Do you really want to 'rm -rf /'? Type 'fiberglass' to proceed."
--nuke Delete all of the archives stored. To protect against accidental
data loss, tarsnap will ask you to type the text "No Tomorrow"
when using the --nuke command.Otherwise it's not very wise to trust the application on what should be a deputy responsibility.
Nowadays I'd probably use OverlayFS (or just Docker) to see what the changes would be, without ever risking the original FS.
ElevenLathe•3h ago
weikju•3h ago
eichin•2h ago