Readit NewsFor little scripts, I'm not writing unit tests- running it is the test. But I want to be able to iterate without side effects, so it's important that the dry mode be as representative as possible for what'll happen when something is run for real.
Put another way: your dry code should do everything up until the point that database writes / API calls / etc actually happen. Don't bail too early
It's short, fun, and totally informal. Thanks for looking!
There's a little more context about the project on my blog: https://xavd.id/blog/post/predicting-the-future/
*4KB webpage files*
So a website where each page does not exceed 4KB. This includes whatever styling and navigation needed. Surprisingly you can share a lot of information even with such constraints. Bare bone html is surprisingly compact and the browser already does a whole lot of the heavy lifting.
Why 4KB? Because that used to be the default page size in x86 hardware. So you can grab the whole thing in one chunk.
This whole comment is not 1KB.
Perhaps I have now infected one of you. I am sorry.
For me personally, I tend to draw the line at write operations. So in your example, I'd want a dry run to verify the permissions that it can (if I expect those to be a problem). But if that can't easily be done without a write, then maybe it's not worth it. There are also situations where you want a dry run to be really fast, so you forego some checks (allowing for more surprises later). Really just depends.