Hacker News Reader

Comment by IgorPartola | Hacker News Reader

What I like is a system where you first create a plan for what you will do, then there is an executor that will execute the plan. So --dry-run just doesn't run the executor. Of course, depending on what you are working with that might not be possible, but if you can design it like so, do it. It also makes everything nicely decoupled.

View on HN

Yes, I like this a lot. You often end up with a main code path that looks like this:

    do a bunch of stuff

    make a plan

    if dryRun {
        plan.Print()
        exit()
    }
    plan.Execute()

Lines 1 & 3 had side effects, sad panda

Reading from disk, spending CPU cycles, allocating memory, and making queries on the network are all technically side effects--but they're not really cause for "sad panda".

Everything on a computer has some side effects, and the purpose of --dry-run is to stop execution without certain effects that we care about. It's impossible to eliminate side effects entirely, so this is not a goal.

I had http:// 192.168.100.123 :7654/lights_on.sh that idempotentially turns on lights in my room. Trying to query or even pre-fetching does it. I was aware it’s not wisest, wasn’t as stupid as to expose it, also it broke so it is no more, but there’s always the guy who does that.

The "n" key on your keyboard is connected to some dynamite attached under the desk, if you type "--dry-run" or even just "-n", it plays the song "Those Endearing Young Charms" and then explodes, killing everyone in the room.

https://www.youtube.com/watch?v=ZLNduq2pnN0

At some point it doesn't matter if there's "the guy who does that", because the right choice is to let "the guy who does that" deal with the consequences of their own crazy setup.

HTTP PUT is for idempotent operations, and would be appropriate here.

HTTP GET is also idempotent in REST, and slightly easier than PUT (since you can just append any parameters onto the end of the URL with GET instead of inserting them into the HTTP headers with PUT)

I believe HTTP GET is "nullipotent", meaning that accessing a resource 0 times is supposed to be the same as accessing it once or more. So I don't think it's appropriate for actions like "lights on".

I guess you really do have to preface your jokes with joke disclaimers these days.

It's impossible to tell if someone is being sarcastic on the internet, because no matter how stupid your comment is at face value, there's always a percentage of people on the forum stupid enough to say it in earnest.

https://en.wikipedia.org/wiki/Poe%27s_law

Use a winking smiley face emoticon ;-) or /s

But I was smiling when I wrote my comment, isn't that enough?

With the number of fanatics of Haskell and functional programming on HN, it's completely reasonable to think you were serious with your comment.

Yeah, not sure how this would work with any workflow that caLLs out to another service and uses the result of that to determine the next step, if that intermediate call changes state somewhere.

Then you can only really dry run that first phase anyway.

Indeed, the other service then needs to support dry runs.

I think a large part of the next 10 years is us figuring out that frameworks are an anti-pattern and that everything is going to have to move to libraries that abide by CQRS.

Did not know what CQRS is, did some light googling[1]:

CQRS (Command and Query Responsibility Segregation) is an alternative to a simple CRUD-based database interface. CQRS separates reads and writes into different models, using commands to update data, and queries to read data.

    Commands should be task-based, rather than data centric. ("Book hotel room", not "set ReservationStatus to Reserved").
    Commands may be placed on a queue for asynchronous processing, rather than being processed synchronously.
    Queries never modify the database. A query returns a DTO that does not encapsulate any domain knowledge.

The models can then be isolated, as shown in the following diagram, although that's not an absolute requirement.

[1]

I really like this book on CQRS & ES: https://www.amazon.com/Practical-Microservices-Event-Driven-...

It’s a really practical treatment of CQRS & ES with JS examples. I had heard about CQRS & ES on HN for years but I had never seen any system that actually used it or any practical examples so this book is amazing cause it takes you through how to build a system using them.

Are you worried about that intermediate call changing between the dry run and the actual run? That can be avoided by saving the execution plan and allowing the actual run to load the execution plan from the dry run.

I'm sure there have been older tools with this, but Terraform is the first I encountered with it and I really like this model.

rsync is where I first encountered it. I've made it a habit to always do a dry run first as a sanity check and it has saved me some headaches.

rsync has a plan mode? I had no idea.

-n or --dry-run. Rsync has a TON of features, it is worth the time to thoroughly read the man page at least once

Right, but `--dry-run` is just a dry run mode, right? You have to sort of post-process it to create a plan.

I feel like the context for this comment thread was lost. Just to repeat it to forestall any further discussion in this subthread on non-plan dry-run, this is how I saw it:

* Igor: a good way to do dry run is to make plan

* * Me: first time i have seen 'plan' as explicit step for dry-run is with Terraform

* * * fickle: rsync is where i first encounter it [it here is not plan, it is dry-run]

* * * * me: really? rsync has 'plan'?

* * * * * john: rsync has dry-run. read manpage

i.e. Igor and I are talking about explicit plan (which is interesting model) and you guys are talking about dry-run.

Ah, sorry, I definitely lost that context. Thanks for clarifying

rsync --only-write-batch exactly works as you want. This is another dry-run.

Terraform does frequently suffer from the lack of good separation here though, depending on the provider in question - a plan can often succeed where a subseuqent apply will fail. Too much external state / not enough validation, generally.

Reply on news.ycombinator.com