| ▲ | arjie 14 hours ago |
| In order to make it work without polluting the code-base I find that I have to move the persistence into injectable strategy, which makes it good anyway. If you keep passing in `if dry_run:` everywhere you're screwed. 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. |
|
| ▲ | wging 12 hours ago | parent | next [-] |
| One nice way to do things, if you can get away with it, is to model the actions your application takes explicitly, and pass them to a central thing that actually handles them. Then there can be one place in your code that actually needs to understand whether it's doing a dry run or not. Ideally this would be just returning them from your core logic, "functional core, imperative shell" style. |
| |
| ▲ | WCSTombs 12 hours ago | parent | next [-] | | I totally agree with both this and the comment you replied to. The common thread is that you can architect the application in such a way that dry vs. wet running can be handled transparently, and in general these are just good designs. | | |
| ▲ | IgorPartola 11 hours ago | parent [-] | | That’s what I prefer as well. A generation step and an execution step where the executor can be just a logger or the real deal. |
| |
| ▲ | clawsyndicate 2 hours ago | parent | prev [-] | | we rely on this separation for our agents. the llm outputs a declarative json plan that gets validated against security policies before the runtime executes any side effects. catching a bad command during validation is way cheaper than rolling back a container. |
|
|
| ▲ | ryandrake 12 hours ago | parent | prev | next [-] |
| I don't want to have to type rm --wet-run tempfile.tmp every time, or mkdir -p --yes-really-do-it /usr/local/bin 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. |
| |
| ▲ | homebrewer 12 hours ago | parent | next [-] | | That undo program is called nilfs2, which unfortunately never became popular. I'll simply quote the kernel docs: > 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 https://wiki.archlinux.org/title/NILFS2 https://en.wikipedia.org/wiki/NILFS | |
| ▲ | arjie 6 hours ago | parent | prev | next [-] | | No rule is ironclad. I think matching risk to functionality is usually a good idea. For example, most modern Linuxen carry `rm` protected against root removal with `--no-preserve-root`. That is indeed `rm --wet-run` by a different name in the dangerous case. | |
| ▲ | aappleby 12 hours ago | parent | prev [-] | | Sure, in those cases - but if a command has a chance of nuking prod, you want some extra step in there. Preferably something that can't be muscle-memoried through. |
|
|
| ▲ | sh-run 12 hours ago | parent | prev | next [-] |
| I don't like the sound of `--wet-run`, but on more than one occasion I've written tools (and less frequently services) that default to `dry-run` and require `--no-dry-run` to actually make changes. 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. |
|
| ▲ | segmondy 14 hours ago | parent | prev [-] |
| this is where design patterns come in handy even tho folks roll their eyes at it. |
| |
| ▲ | nstart 12 hours ago | parent | next [-] | | Design patterns are one of those things where you have to go through the full cycle to really use it effectively. It goes through the stages: 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 :,) . | | |
| ▲ | tbossanova 9 hours ago | parent [-] | | What about the productivity gains from in memory db for tests though? Hard to measure I guess |
| |
| ▲ | cake-rusk 13 hours ago | parent | prev [-] | | Design patterns exist to paper over language deficiencies. Use a language which is not deficient. | | |
| ▲ | WCSTombs 12 hours ago | parent | next [-] | | There's some truth to this, since some design patterns can simply be implemented "for good" in a sufficiently powerful language, but I don't find it's true in general. Unfortunately, it has become something of a thought-terminating cliché. Some common design patterns are so flexible that if you really implemented them in full generality as, say, some library function, its interface would be so complex that it likely wouldn't be a net win. | | |
| ▲ | cake-rusk 5 hours ago | parent [-] | | > Some common design patterns are so flexible that if you really implemented them in full generality as, say, some library function, its interface would be so complex that it likely wouldn't be a net win Then I would say you have not arrived at the optimal solution. Keep looking. |
| |
| ▲ | awesome_dude 11 hours ago | parent | prev | next [-] | | Just my two cents - but a general purpose language is going to need to be coupled with design patterns in order to be useful for different tasks. 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 ) | | | |
| ▲ | antinomicus 13 hours ago | parent | prev [-] | | Like what? | | |
|
|
