Live data from Hacker News

Do-nothing scripting: the key to gradual automation

blog.danslimmon.com

61–70 of 126 posts

Re: Do-nothing scripting: the key to gradual automation

#61
post #5

I can't help looking at this and working out how to build a tool that can generate a Do Nothing script straight from your histfile, making the business of archiving the commands you just executed as easy as possible too...

If you're about to do a sequence of commands into a terminal, you can create a transcript with the 'script $filename' command ('script' command is in the util-linux package', according to the man page), and it will capture input/output into the transcript. This would probably make this task easier, since you could see the output data, and how the output data is transformed into arguments into the next command ...

Came to say this. https://www.youtube.com/watch?v=tweyWNr6X18

Re: Do-nothing scripting: the key to gradual automation

#62
post #60
post #45

I'd go farther... you can have steps that literally "do nothing". They can be comments, or simple echo statements. They're placeholders to remember to write the code for that step later. This is particularly important when you need to deal with integration that isn't necessarily easy - handling auth credential safely, making sure it works in your pipeline, etc. But all this gets back to something I used to say a lot,…

But these steps already do nothing except say echo what should be done. How does that differ from your "literally do nothing" steps?

my hot take is that it differs is that you plan to never automate some of the steps, if they're steps for a human to do. As part of onboarding, you might send out an email introducing this new human. The "description" field of this new human should be written by a person, not scraped from their linkedin or google, and summarized to less than 100 words by a computer.

Re: Do-nothing scripting: the key to gradual automation

#63
post #23

What is the value of this over a checklist?

I would argue that it _is_ a checklist.

The difference is that it's a more gradual entry to automate the task.

One could, for example, replace any item with a script/program invocation, while leaving the others untouched. It's an intelligent, piecemeal step towards automation.

I would also add that in really critical tasks, one could automate _either_ the item, or it's verification. Sometimes it's easier to check that something is correct than to do it-- or vice-versa.

Re: Do-nothing scripting: the key to gradual automation

#67
Suggested upgrade: Have such scripts ask for a unique name/"instance identifier" when run so they can log to simple text files in a well-known directory and potentially pick up where they left off. For when you invariably use these for long-running tasks and have 7 of them in-flight, and your power goes out or Windows forces a reboot.

Re: Do-nothing scripting: the key to gradual automation

#68
post #39

I know this isn’t the point of the article but the code shown there is the archetypal case where writing classes is an anti-pattern, as argued in “Stop Writing Classes” [1]. All the classes in that code can — should! — be functions. There’s no downside, and it’s less code (and otherwise identical). [1] https://news.ycombinator.com/item?id=3717715

Moreover, the steps should be in a table, with just one function to process the contents of the table.

Re: Do-nothing scripting: the key to gradual automation

#69
An additional benefit of this approach is that your checklists now get code reviews, git hooks, history, etc. for free.

I mention this because I worked at a company where checklists were typically simply added to a wiki and required separate processes for things like peer review.

Re: Do-nothing scripting: the key to gradual automation

#70
post #68
post #39

I know this isn’t the point of the article but the code shown there is the archetypal case where writing classes is an anti-pattern, as argued in “Stop Writing Classes” [1]. All the classes in that code can — should! — be functions. There’s no downside, and it’s less code (and otherwise identical). [1] https://news.ycombinator.com/item?id=3717715

Moreover, the steps should be in a table, with just one function to process the contents of the table.

The point of writing this script is to follow up by replacing each function's implementation with code that automates the step. Using a data-driven design here ossifies the code and makes it harder to migrate the automated version.
Post reply on HN