In even more praise of Ctrl+Z. (Don't try it in a terminal window, though)
[deleted]
In praise of –dry-run
151–160 of 175 posts
Re: In praise of –dry-run
#152If you're interacting with stateful systems (which you usually are with this kind of command), --dry-run can still have a race condition. The tool tells you what it would do in the current situation, you take a look and confirm that that's alright. Then you run it again without --dry-run, in a potentially different situation. That's why I prefer Terraform's approach of having a "plan" mode. It doesn't just tell you w…
>That's why I prefer Terraform's approach of having a "plan" mode. It doesn't just tell you what it would do but does so in the form of a plan it can later execute programmatically. Then, if any of the assumptions made during planning have changed, it can abort and roll back. Not to take anything away from your comment but just to add a related story... the previous big AWS outage had an unforeseen race condition bet…
Overkill I’m sure for many things but I’m curious as to whether there’s a TLA kind of solution for this sort of thing. It feels like it could although it depends how well modelled things are (also aware this is a 30s thought and lots of better qualified people work on this full time).
Re: In praise of –dry-run
#153If you're interacting with stateful systems (which you usually are with this kind of command), --dry-run can still have a race condition. The tool tells you what it would do in the current situation, you take a look and confirm that that's alright. Then you run it again without --dry-run, in a potentially different situation. That's why I prefer Terraform's approach of having a "plan" mode. It doesn't just tell you w…
Totally agree, and this is covered in an (identically named?) Google Research blog [1]. Just last week I was writing a demo-focused Python file called `safetykit.py`, which has its first demo as this: def praise_dryrun(dryrun: bool = True) -> None: ... The snippet which demonstrates the plan-then-execute pattern I have is this: def gather(paths): files = [] for pattern in paths: files.extend(glob.glob(pattern)) retur…
G-Research is a trading firm, not Google research
Re: In praise of –dry-run
#154Earlier quoted context omitted.
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 ap…
What about the productivity gains from in memory db for tests though? Hard to measure I guess
In my experience, there is no in-memory database replacement that correctly replicates the behavior of your database. You need to use a real database, or at least an emulator of one.
For example, I have an app that uses Postgres as the database. I have a lot of functions, schemas, triggers, constraints in Postgres for modifying database state, because the database is 100x faster at this than my application will ever be. If I have an in-memory version of Postgres, it would need to replicate those Postgres features, and at that point I really should just be standing up a database and testing against it.
I have worked with people claiming that unit tests need to hermetically run in-memory, because reasons. Ok, I don't disagree, but if my bug or feature requires testing that the database is modified correctly, I need to test against a real database! Your in-memory mock will not replicate the behavior of a database _ask me how I know_ ...
These days, Docker makes this so easy that it's just lazy to not standup a database container and write tests againts it.
Re: In praise of –dry-run
#155Earlier quoted context omitted.
Totally agree, and this is covered in an (identically named?) Google Research blog [1]. Just last week I was writing a demo-focused Python file called `safetykit.py`, which has its first demo as this: def praise_dryrun(dryrun: bool = True) -> None: ... The snippet which demonstrates the plan-then-execute pattern I have is this: def gather(paths): files = [] for pattern in paths: files.extend(glob.glob(pattern)) retur…
G-Research is a trading firm, not Google research
The G stands for "Google", does it not?
Re: In praise of –dry-run
#156Re: In praise of –dry-run
#157I like the opposite too, -commit or -execute as it is assumed running it with defaults is immutable as the dry run, simplifying validation complexity and making the go live explicit.
There was a tool I used some time ago that required typing in a word or phrase to acknowledge that you know it's doing the run for real. Pros and cons to each but I did like that because it was much more difficult to fat finger or absentmindedly use the wrong parameter.
Github will do that when you delete a repo.
Re: In praise of –dry-run
#158Earlier quoted context omitted.
this is where design patterns come in handy even tho folks roll their eyes at it.
Design patterns exist to paper over language deficiencies. Use a language which is not deficient.
Re: In praise of –dry-run
#159Earlier quoted context omitted.
> you can (de)serialize anything to and from JSON, so it's really not that hard First, it is hard, especially in at least somewhat portable manner. Second, serialization only matters if you cannot (storage, IPC) pass data around in-memory anyway. That's not the problem raised, though. Whatever the backing implementation, the plan, ultimately, consists of some instructions (verbs in parent) over objects (arguments in…
> First, it is hard, especially in at least somewhat portable manner. I'm curious what portability concerns you've run into with JSON serialization. Unless you need to deal with binary data for some reason, I don't immediately see an issue. > Such representation, which is by the way specified to be executable bidirectionally (roll back capabilities), is a full blown program Of course this depends on the complexity of…
> I'm curious what portability concerns you've run into with JSON serialization.
The hard part concerns instructions and it is not technical implementation of serializing an in-memory data structures into serialization format (be it JSON or something bespoke) that is the root of complexity.
> You have a function to execute the process that takes the configuration and a function to roll back that takes the same configuration.
Don't forget granularity and state tracking. The opposite of a seemingly simple operation like "set config option foo to bar" is not a straightforward inverse: you need to track the previous value. Does the dry run stop at computing the final value for foo and leaves possible access control issues to surface during real run or does it perform "write nothing" operation to catch those?
> This does tie the representation very closely to the program itself so it doesn't work if you want to be able to change the program and have previously generated "plans" continue to work.
Why serialize then? Dump everything into one process space and call the native functions. Serialization implies either strictly, out of band controlled interfaces, which is a fragile implementation of codegen+interpreter machinery.
Re: In praise of –dry-run
#160Earlier quoted context omitted.
Design patterns exist to paper over language deficiencies. Use a language which is not deficient.
https://www.cognitect.com/blog/2007/5/17/design-patterns-are...
I agree. Doesn't contradict anything I said. So I will assume you posted the link in support of my argument :)