Do-nothing scripting: the key to gradual automation • Hacker News Board

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

#71

Post by dharmab » Mon, Jul 22, 2019, 2:43 PM UTC

dusted wrote: post #27

We use this at my place, though in bash, and we call it executable documentation. Stuff like: NAME="$1" # Create directory for the code mkdir "$NAME" # Checkout the source cd $NAME && git something # and so on Sometimes with an echo "You need to read and understand this before just using it"; exit 1 thrown in somewhere for good measure. These files will have no logic, and make very little use of variables. They will…

We embed similar explanatory docs in Markdown. A short example for dig from our troubleshooting guide:

  # General form
  dig @ 

  dig @1.1.1.1 www.example.com
  # Omit the resolver to use the system's configured resolvers
  dig www.example.com
  # Don't need the full output?
  dig +short www.example.com

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

#72

Post by minxomat » Mon, Jul 22, 2019, 2:44 PM UTC

wtetzner wrote: post #51

swiley wrote: post #25

Is anyone else bothered by how they were handling ssh keys in the example? The whole point of public keys is that the private key never has to leave the box it’s generated on. Once you go sharing them you might as well just use a random passphrase.

Yeah, at our company things are done in the reverse of that script: the user generates their SSH keys, and there's a process they use to register the public key with the rest of the system.

I sometimes use GitHub for this. A developer's most up to date keychain is probably their GitHub account, so granting them access is as simple as

    curl -Ls github.com/turbo.keys >> ~/.ssh/authorized_keys

Simplified of course. A script is usually used to revoke that access shortly after. Plus 2FA SSH.

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

#73

Post by manas666 » Mon, Jul 22, 2019, 2:45 PM UTC

if you are working at a small shop or startup - then whatever makes you happy, even these classes are OK.

if you are working at enterprise - then these processes gotta be implemented according to ITIL in a specialized IT Service Management system - like ServiceNow, which allows building process flows like directed acyclical graphs and automation of necessary steps

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

#74

Post by oblio » Mon, Jul 22, 2019, 2:47 PM UTC

manas666 wrote: post #73

if you are working at a small shop or startup - then whatever makes you happy, even these classes are OK. if you are working at enterprise - then these processes gotta be implemented according to ITIL in a specialized IT Service Management system - like ServiceNow, which allows building process flows like directed acyclical graphs and automation of necessary steps

I'm not sure if this is ironic. I've been numbed by too many years of internet usage, I guess :-)

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

#75

Post by NikolaeVarius » Mon, Jul 22, 2019, 2:54 PM UTC

minxomat wrote: post #72

wtetzner wrote: post #51

Earlier quoted context omitted.

Yeah, at our company things are done in the reverse of that script: the user generates their SSH keys, and there's a process they use to register the public key with the rest of the system.

I sometimes use GitHub for this. A developer's most up to date keychain is probably their GitHub account, so granting them access is as simple as curl -Ls github.com/turbo.keys >> ~/.ssh/authorized_keys Simplified of course. A script is usually used to revoke that access shortly after. Plus 2FA SSH.

Huh, never occurred to me to do it this way.

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

#76

Post by iainmerrick » Mon, Jul 22, 2019, 3:01 PM UTC

js8 wrote: post #53

iainmerrick wrote: post #18

Earlier quoted context omitted.

Well, the specific problem it addresses is: 1. We have a tedious manual checklist 2. We’d like it to be fully automated 3. How do we get there from here?? You’re correct to say that if the process had been fully automated from the start it may well have been implemented very differently. But those scripts are hard to write, and basically useless until they’re complete. Often the only practical way to do this stuff is…

You can do automation incrementally, but it's quite a different mindset to automate computer than to write a checklist for humans. If you try to emulate a person with a checklist, then you will often find it is actually harder to automate, because the steps often rely on human adaptability and common sense.

What other approach do you suggest, then, in the extremely common scenario where you have an existing, tedious yet reliable multi-step manual process, and you’d like to automate it?

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

#77

Post by rmetzler » Mon, Jul 22, 2019, 3:59 PM UTC

minxomat wrote: post #72

wtetzner wrote: post #51

Earlier quoted context omitted.

Yeah, at our company things are done in the reverse of that script: the user generates their SSH keys, and there's a process they use to register the public key with the rest of the system.

I sometimes use GitHub for this. A developer's most up to date keychain is probably their GitHub account, so granting them access is as simple as curl -Ls github.com/turbo.keys >> ~/.ssh/authorized_keys Simplified of course. A script is usually used to revoke that access shortly after. Plus 2FA SSH.

Gitlab also has a keys URL, but I can’t say if it’s available for unauthorized clients from the top of my head (currently on mobile). For me it’s usually the fastest way to authorize other team members.

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

#78

Post by mattnewton » Mon, Jul 22, 2019, 4:08 PM UTC

shareIdeas wrote: post #52

epr wrote: post #43

Earlier quoted context omitted.

"maybe"..."in the future" is the root of much object oriented evil

I don't think there is a correct answer, but I like that a developer has foresight.

The problem is you get more information in the future, but all this boilerplate is has been written before that information so the first instinct / seemingly least-resistance thing to do is to fit the new information into the old boilerplate / hierarchy.

Lots of people have OO scar tissue from getting weird impedance mismatches on newish OO systems designed this way.

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

#79

Post by beat » Mon, Jul 22, 2019, 4:14 PM UTC

dkarp wrote: post #60

beat wrote: 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?

In a truly minimal system, there isn't even a prompt. A code comment is about as minimal as I know how to get. That's just a placeholder to remember to automate a step.

When automating a complex manual process, the first thing I do is write comments describing the sequence, and any parameters needed. Parameters in particular can be enlightening, because when manual processes grow organically, naming consistency becomes a source of suffering - humans can just sort of figure out the right thing to type, computers can't intuit these things and they must be made explicit. It's worse when it can't be explicit without updating the process or creating some sort of data store for mapping.

This is why naming things is one of the two hard problems in computer science.

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

#80

Post by barbecue_sauce » Mon, Jul 22, 2019, 4:14 PM UTC

dillonmckay wrote: post #44

naringas wrote: post #40

Earlier quoted context omitted.

maybe he was a Java programmer? all joking aside, the reason he's doing classes seems to be an intention towards making a FooStep (and/or a BarStep) which could then maybe handle generic Foo stuff (authentication comes to mind) in the future?

YAGNI

YAGNI for thee, but not for me.