A Final Farewell - <AUTHOR> https://getfinal.com/company-news/2017/12/06/a-final-farewell/ <comment><USER2> That's too bad. I loved using Final.

I know Privacy [0] is one possible alternative, but it's debit based rather than credit based like Final is, and they require linking a bank account by username and password, which AFAIK makes you entirely liable for any fraudulent activity for the account, so that's a non-starter for me. Anyone aware of any other services that provide virtual cards like these?

[0] [https://privacy.com/](https://privacy.com/)

EDIT: just found out about Token [1], which seems similar. But the fact that it makes you enter your phone number to get a link to the app seems rather shady... I can't seem to find their app on the Play Store so I'm going to assume they're iOS only and skip it. Can anyone comment on their experience with the service?

[1] [https://jointoken.com/#slide1](https://jointoken.com/#slide1)

<comment><USER3> Early Final adopter here. I liked the product but wasn't able to differentiate between Final and other VCCs.

Bank of America and Citibank offer virtual credit card creation which is very close to what Final does. Their UI is very clunky but does the trick without worrying about the liability part.

<comment><USER4> I was using Bank of America's ShopSafe system a decade ago. Remember all those "Get a free Xbox for completing these 12 free trial offers" scams?

Well, it turned out that some of them weren't necessarily scams, and there were whole forums dedicated to actually completing the offers, keeping proper documentation and claiming the prizes.

Most of the free trial offers validated your credit card for the initial free month, and then made it incredibly difficult to cancel the service. So I'd just sign up with a ShopSafe number that was valid for 1 month with a $1 limit.

Typically, instead of actually shipping you the Xbox or whatever the prize was, if you completed the offer they'd just send you a check. The year after I got out of college when I had plenty of free time, I managed to get about $1,200 thanks to those offers and ShopSafe.

It's not a feature I'd use enough to have it dictate my overall credit card choice, but I'd love it if more issuers added to their products.

<comment><USER5> Ahhh the good old days. I'd have spreadsheets of when to cancel trial offers. Probably earned about $20-30k in electronics and cash overall during Freshman year in college.

<comment><USER6> Me and my roommates did this as well. We did it so much that one of my roommates actually got a legally threatening letter from on of the companies behind most of them (Trilegent I think it was) telling him to stop because he was abusing the system. Which was funny because they were so scammy to begin with.

<comment><USER5> Yikes. The worst I got was being sent to collections for a teeth whitening product that was designed to bill regardless of trial cancellation. I learned a ton about negotiating with customer service departments during this time too.

</comment></comment></comment></comment></comment></comment><comment><USER7> We're going to get to a point where no one is willing to invest any time or money (as a consumer) into products sold by a startup, because they all vanish quickly and with short or no notice. I'm already at that point.

It'd suck to be a stable startup with plenty of funds/cashflow in a similar niche to a company closing like this, and have people not willing to try your product because they're now too timid.

<comment><USER8> Only if those products are chained to a proprietary cloud offering, or otherwise dependent on the entity staying in business.

Something like a credit card is, of course, vulnerable to what you say. But the benefit to this sort of timidity is that companies making IoT things ought to lean more heavily into ensuring that their products will work even if they go under.

</comment></comment><comment><USER9> Thoughts on why this happened? I wish they were more forthcoming about the causes. This is the corporate equivalent of ghosting on your tinder date.

<comment><USER10> > ghosting on your tinder date

What does this mean? Apologies if it's something obvious I should know; I'm not cool anymore so this terminology escapes me. :)

<comment><USER11> "ghosting" just means ending all interaction without warning. not necessarily in the context of a relationship. one can ghost a job, a friend, or even someone selling things on craigslist.

 _" He ghosted me after finding out I have kids."_

<comment><USER12> Ghosting can also be situational.

For instance, you can ghost from a bar or party, which is essentially just disappearing without saying goodbye and trying to avoid anyone noticing you leaving. Also called an Irish Goodbye.

<comment><USER13> FWIW in Spain is a French goodbye

<comment><USER14> I've heard it as the Irish Goodbye as recently as the monologue of last week's Saturday Night Live with Saorise Ronan!

</comment></comment></comment></comment></comment></comment><comment><USER15> I emailed their support and they said they've been acquired by another company but can't disclose the details.

<comment><USER16> my theory is that their main asset wasn't their consumers, or even that data, but their ability to be a card processor and issuer (like the big banks). I don't think there's very many of them, and the effort required to build that is very time consuming and expensive.

<comment><USER17> The footer of their pages says their cards are issued by First Bank & Trust, Brookings SD.

<comment><USER16> They have the ability to issue tokenized numbers, that's something that not everyone can do.

TBH, I'm not deeply involved in payments, but what they're doing is extremely unique and I could totally appreciate a larger company (such as a paypal competitor like stripe) wanting a piece of what they're doing.

<comment><USER18> Marqeta does this: [https://www.marqeta.com/](https://www.marqeta.com/)

</comment></comment></comment></comment></comment><comment><USER19> Had to look up their page (getfinal.com). Had I known about this product, I probably would have embraced it. Wish the team the best of luck, and hope it gets revived!

</comment><comment><USER20> I feel kind of guilty since I rarely used my card.

The points I would usually get from my other cards were better.

Also for online transactions, which was supposed to be the strong point of Final, I never use my card on unreputable sites. But even if I did, disputing transactions is so easy these days.

Sorry that you didn't make it folks. Good luck in your future adventures.

<comment><USER21> Yup.

Came here to say this.

Amex has a more compelling offering (and a better website), Discover offers better rewards, same with pretty much every card I have.

</comment></comment><comment><USER22> This is such a shock to me! I've been a Final customer for a year or so now, and I have absolutely loved their product. I told all of my friends about it. I'm so sad to hear they're shutting down, and very curious as to why.

</comment><comment><AUTHOR> For a credit card company their support was amazing. I had a few issues with the 2fa SMS being delayed and they answered within a couple minutes.

</comment><comment><USER23> That was fast (or slow, I guess)... I knew this was gonna happen with Final.

Now let's hope Privacy doesn't also decide to close one day. (It does just virtual cards with your bank ACH backing it)

<comment><USER24> Privacy closed my account abruptly after refusing to process some disputes. From my limited experience they don't appear to comply with the requirements to run a payment network

</comment></comment><comment><USER25> This really, really sucks. I have a business credit card that I have to update 20+ sites for every time there's a compromised card issue, and I'd really love to be able to use one card # for each business I work with. They were going to launch a business card in the future but apparently that is now scrapped.

Are there any alternatives out there for doing this?

<comment><USER26> I've had a good experience with privacy.com, although I'm not super excited that you have to give them your bank logins.

<comment><USER27> Really? You do? Rather weird for a company by that name.

</comment></comment></comment><comment><USER15> I received the same message. I'm a little disappointed that such a notification would be sent via email without any verification on their website, blog, or social media accounts.

If it's legit, I'm saddened. Final had a great idea in virtual cards. I hope someone can explain why they are closing down.

</comment><comment><USER28> I think this was a great idea, so I'm sad to see it go. I have prepaid credit cards for potentially sketchy sites and one "main" credit card that I use for most of my payments online. This could probably have reduced the "administration" overhead involved.

Is anyone aware of a similar offering that is available in Germany? I wouldn't think so, after all most people here don't even have a credit card. We do have debit/ATM cards, but they use a separate payment network developed in German and are not interoperable with Visa/MasterCard.

On that note, I wouldn't mind not getting any benefits since most cards here don't offer any notable ones either. This is probably a direct consequence of there being a pretty strict cap on transaction fees (iirc 0.3% on credit cards).

</comment><comment><USER29> I interviewed with them very very recently. I guess not getting the job was a good thing!

<comment><USER30> Yeah I also met with them but they were waiting to hear back about headcount. It's too bad, there product was useful.

</comment></comment><comment><USER31> Anyone know how this closing could affect your credit if you were a Final customer?

<comment><USER32> Probably not much as long as you were in good standing. It'll reduce your average length of credit by a bit, but afaik having one account with a short age probably won't hit you more than a few points for a little while.

</comment></comment><comment><USER33> I would have used Final if it were a debit card. Didn't want another credit card and was bummed to see that's what it was.

</comment><comment><USER34> I never used Final but from a quick skim it seems like Revolut cover a lot of what they did (and more).

</comment><comment><USER22> Blog post: [https://getfinal.com/company-news/2017/12/06/a-final- farewel...](https://getfinal.com/company-news/2017/12/06/a-final-farewell/)

<comment><AUTHOR> Wow it must have just went up. I looked and saw nothing.

<comment><USER35> Thanks! We've updated the link from [http://mailchi.mp/27332f46a92e/final- will-be-closing-all-acc...](http://mailchi.mp/27332f46a92e/final-will-be- closing-all-accounts).

</comment></comment></comment><comment><USER36> A contender for [https://ourincrediblejourney.tumblr.com/](https://ourincrediblejourney.tumblr.com/) ?

<comment><USER37> That's more for acquihires.

<comment><USER36> discreditable's comment says that they were in fact acquired, although with a username like that who knows ;)

<comment><USER38> Plus they mentioned their "journey" twice. That's got to count for something :)</comment></comment></comment></comment>


Graduates of elite colleges don't make more money - <AUTHOR> http://www.irs.princeton.edu/pubs/pdfs/563.pdf

<comment><USER2> This title is a little bit misleading...

A more relevant question is not whether graduates of certain school do or do not make more, but rather, what causes them to do so. And analysis of students who were admitted to such elite schools, but chose to matriculate elsewhere, shows that on the basis of income alone they had very similar success outcomes. Only for very-lower-income students was there a noticeable advantage to attending the elite school, where this metric is concerned.

Thus, the important factor is the "type of student," not the "type of school." This is borne out in their conclusions as well:

"Consistent with the past literature, we find a positive and significant effect of the return to college selectivity during a student's prime working years in regression models that do not adjust for unobserved student quality for cohorts that entered college in 1976 and 1989 using administrative earnings data from the SSA's Detailed Earnings Records. Based on these same regression specifications, we also find that the return to selectivity increases over the course of a student's career. However, after we adjust for unobserved student characteristics, the return to college selectivity falls dramatically. For the 1976 cohort, the return to school-SAT score for the full sample is always indistinguishable from zero when we control for the average SAT score of the colleges that students applied to in order to control for omitted student variables."

Furthermore, I would importantly mention that while these studies are valuable, they do ignore significant changes in the nature of student bodies, labor markets, and educational institutions since the original cohorts are first observed; their findings can't fairly be 100% extrapolated onto current populations.

I could go more into the weeds here, but I think it is not ultimately necessary. Interesting paper, I think less exciting than the works it cites in its introduction, but still quite neat.

TL;DR = Schools don't matter; students do.

</comment><comment><USER3> "First, the analysis does not pertain to a nationally representative sample of schools, as the sample is derived from the 27 colleges and universities in the C&B dataset, the majority of which are very selective."

The schools are listed in footnotes on pages 8 and 9, and the ones that don't qualify as "elite" aren't exactly shabby either.

</comment><comment><USER4> Maybe it's just me, but that font is really bad. And the huge line spacing isn't helping either.

</comment><comment><USER5> but they do have more satisfying sex lives.

</comment><comment><USER6> Did anyone else find it ironic that it was published by someone at Princeton?

<comment><USER7> How is it ironic?</comment></comment>


Doctors Inject HIV Into Dying Girl [video] - <AUTHOR> http://www.youtube.com/watch?v=h6SzI2ZfPd4

<comment><USER2> The idea is not new:

"""Julius Wagner von Jauregg (1857-1940), Austrian psychiatrist and Nobel Prize winner who discovered that advanced cases of syphilis, a sexually transmitted disease (STD), can be cured by deliberately infecting the patient with malaria. Until the development of the antibiotic penicillin in the 1940s made Wagner von Jauregg`s malaria cure obsolete, he achieved remarkable success in curing patients of a dreaded disease that had been thought to be incurable. For his development of the malaria cure for syphilis, Wagner von Jauregg received the 1927 Nobel Prize in physiology or medicine."""

[http://www.mediahex.com/Wagner_von_Jauregg_Julius](http://www.mediahex.com/Wagner_von_Jauregg_Julius)

</comment><comment><USER3> Amazing. I wonder though, what happens to the HIV?

What I got from the video is that they modify the virus so it won't cause disease and rather just modifies the host t-cells to recognize cancer. Does the virus remain in the host system? Can it still spread? If it spreads what happens to the newly infected person: cancer proof, nothing or HIV?

<comment><USER4> Presumably the way they stop it from being a disease is that they disable the virus's ability to reproduce, somehow. Or otherwise impair its function so that it doesn't behave in the way traditional HIV does.

Hypothetically speaking here, if they put enough of the virus in her system it'd be able to act upon enough of her immune system to get those cancer- killing T cells spread around her entire body and kill enough of the cancer to stop it from coming back. At that point, maybe it's okay if all those T cells die off and her body doesn't know how to kill the leukemia anymore, because it's gone?

Cancer and remission are pretty complex, so I don't know. But that seems plausible to me.

I expect that leaving the virus able to actually spread would be harmful, even if it's been altered to target cancer cells. It would probably alter the immune system in other ways and potentially compromise it?

EDIT: According to another source I just looked at, the cancer-fighting T cells actually do replicate. So I'm not at all sure how they mitigate the downsides to that. Maybe this is a case of it being worth the downsides.

<comment><USER5> Yes -- people these days can live more or less indefinitely with HIV, given a good antiretroviral regiment. Not so with leukaemia. As horrible as it is to say, that's a trade I'd make in a second, if it were me.

(Days ago, my friends lost their six-year-old daughter -- who looked very much like Emma in the video -- to leukaemia. So I'm very much in one of those "fuck cancer" rages right now...)

</comment></comment></comment><comment><USER6> XKCD mentioned this a while ago.

[1] [http://xkcd.com/938/](http://xkcd.com/938/)

</comment><comment><USER7> Wow</comment>


Ask HN: How would you make Twitter irrelevant? - <AUTHOR>

If there were a way for Twitter to become irrelevant, what would that be? <comment><USER2> A project that delivers decentralised twitter-like applications as well as interfaces that aggregates it. There's several projects I believe. Essentially make it akin to an email service.

I suppose if you're aiming for the next best thing after Twitter, it might be brief videos with voice recognition. eg "Joakal: Met HN's founder!" "(PG talking) I like blackberries. Blackberry companies are best" (10, 20 or 30 secs?). That would make spam control and aggregation pretty challenging but lots of potential for advertisements and interviews.

Here's a brief advertisement (edited), "The Last Exorcism - BEST OF Chatroulette reactions": <http://www.youtube.com/watch?v=CNSaurw6E_Q> And brief comedy (edited), "Top 20 5 Second Films Presented By UPROXX": <http://www.youtube.com/watch?v=saqO_ZqX6uY>

</comment><comment><USER3> Well, to answer the question: What are you doing now or what's happening? you could have users wearing glasses that collects video and sound from the environment and sends it into the network for recording and broadcast. The glasses may also have an inbuilt screen and headphones that can receive from the network. Getting lifestreaming right.

The glasses could also detect a user's emotions by their eye state and voice (or pulse.) It may autodetect location and detect sounds to attach environmental metadata -- so great metadata. Think The Terminator combined with Brainstorm.

</comment><comment><USER4> In theory there are only two options for this.

A. Something that is better than Twitter comes along and people like it more.

B. People no longer find Twitter useful/interesting/whatever makes them use it in the first place.

So basically, irrelevancy by competition or by societal shift.

<comment><USER5> Lots of things are "better" than Twitter, for almost any way you could measure "better". The only thing Twitter has going for it is size - everyone is on Twitter. Also they are now really fast and pretty reliable, but even back when that wasn't true, they were still growing like crazy.

<comment><USER6> Well, you can also look it in opposite way. Why is everyone on twitter? There must be something that twitter is doing better than others? Ease of use? simplicity? better marketing? hype? Why are you on twitter?

Make something that makes each one of those "everyone" to leave twitter and join your site and you'll make it irrelevant.

</comment></comment></comment><comment><USER7> If someone here had a way to make Twitter irrelevant, they would be working on it, very quietly.

</comment><comment><USER8> Twitter is an easier-to-use, web-enabled IRC. I suppose if you were to add a slick Twitter-like interface on top of an IRC with permanent handles/profiles then you'd end up with a real-time Twitter.</comment>


Do-nothing scripting: the key to gradual automation - <AUTHOR> https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation/ <comment><USER3> 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 also have a .txt filename to ensure that people understand, that first of all, this is a set of instructions for how to do something, which just so happens to be a valid bash script.

<comment><USER4> You could prefix the script with `#!/bin/bash -vn` and make it executable. It will just print itself.

<comment><USER5> Thanks. Didn't know about this.

</comment></comment></comment><comment><USER6> This idea is great. You could even argue that these scripts actually do something: they allow storing and updating the _state_ of a process. By having these scripts run in a shell rather than in your head, the current state is stored in a machine, not in an unreliable human brain.

<comment><USER7> also they allow you to gradually script stuff as you figure it out.

<comment><USER8> This should be read in conjunction with this other great article about how to gradually automate your process: [https://queue.acm.org/detail.cfm?id=3197520](https://queue.acm.org/detail.cfm?id=3197520)

<comment><USER9> This is a great article, providing even more context for why this stepwise automation is smart.

</comment></comment></comment></comment><comment><USER10> Very nice idea, Dan! This reminds me of the power of checklists that has been discussed here a few times: Simple but highly effective.

It allows for a pretty natural transition:

\- (Markdown) Manual

\- Do-nothing-script (printing out the manual in steps)

\- Partial automation

\- Full automation

<comment><USER11> The reference article for the power of checklists: [https://www.newyorker.com/magazine/2007/12/10/the- checklist](https://www.newyorker.com/magazine/2007/12/10/the-checklist)

Another article, with HN discussion: [https://news.ycombinator.com/item?id=20293246](https://news.ycombinator.com/item?id=20293246)

</comment></comment><comment><USER12> I have a script in our automation setup called "be-the-change" which takes either markdown or a wiki url as a parameter. It will output the markdown or wiki content, wait for the user to confirm they've completed the steps and then print:

Doing manual steps sucks, wouldn't it be great if this was automated for the next person? Be the change you want to see in the world.

</comment><comment><USER13> I love things like this. Mindbendingly simple ideas that rely purely on overturning preconceived notions about what things are "worth" a certain amount of effort. There's a tautological, cart-before-horse paradox in many cases.

</comment><comment><USER14> 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, and the more refined version I say now. I used to say "Have humans do what humans do well; have computers do what computers do well". The key part of that was the idea that computers can't do what humans do. Now, I say "Anything a computer can do well, a human cannot do well". Which includes those pesky twenty step manual processes.

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

<comment><USER14> 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.

<comment><USER16> Printing means you can run the script as-is, and any bits which aren't done automatically are prompted for. Just putting comments describing the steps would be like writing a README except in a more esoteric format and would defeat the primary benefit of the approach outlined in TFA.

<comment><USER14> It kind of boggles me that a real analysis of the problems with naming conventions in manual process got massively downvoted. But no one ever got rich counting on the analytical sophistication of HN.

I'm not saying the original approach is bad. I'm saying it's not the simplest thing that can possibly work. I'm talking about how to move to automation, not how to reduce errors on the manual process. Both are needed.

</comment></comment></comment></comment></comment><comment><USER17> I get it, but this script looks a lot like a checklist to me. Seems like a checklist is a good place to start, no?

If you want more "interest" during the process, make it a point to refine the documentation for your process (clarify a step here, split one command into two steps). Then you have a very clear spec by the time the process needs to be automated.

<comment><USER18> I think the value of using a script as your checklist is that the script can handle some of the book-keeping for you, including making it harder to lose track of where you are.

<comment><USER19> It also documents the process, which is often lacking for these one-offs tasks.

</comment></comment></comment><comment><USER20> This seems like a surprisingly powerful and should-be-obvious kind of idea... I think I'll start making use of it!

</comment><comment><USER21> We do a similar thing for tests that are hard to automate. Instead of having the test protocol in a document it's in a script that prompts the user to do things. The observations are then recorded and stored.

</comment><comment> phoe-krk They are _do-nothing scripts_ but it isn't equivalent to say that _the scripts do nothing_. That is a very important distinction to me.

These scripts organize tasks into flows in a way that makes it possible to split work by logical checkpoints. The tasks between these checkpoints are dependent on one another in the overall flow, but have independent implementations that can be delegated to software or done by humans.

</comment><comment><USER22> It seems to me that all you want is to document a manual process. Having them documented in dump scripts is no different than having them documented as a guide in your knowledge base .e.g in Confluence or as product requirements.

I can see the usage in an isolated team of a few people that will write these scripts for their own benefit.

I am opposed in general with having scarce information around. Better have everything a single place, whether that's a guide on how to provision a user or is how to add a new endpoint to your API or write a new end to end test.

<comment><USER23> There is one advantage of this script over an equivalent document: it provides the instructions in the same context that it's being used (the command shell).

Unless we have script shells that can universally launch a web document side- by-side from the shell prompt where it needs to be used, having it being displayed from the shell itself step by step will reduce the mental load required to follow the instructions. Also, the benefit of having an already semi-automated process in order to build a script in the future is not negligible.

<comment><USER24> I think dual screen solution provides exactly that. Working only on a corporate laptop is very inefficient in this regard.

</comment></comment></comment><comment><USER25> 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.

</comment><comment><USER26> This is a really great idea, and appealing in its simplicity -- I think we might try to implement this in my company for some of our tasks which are really very manual, but for which automation is a daunting task.

</comment><comment><USER27> 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.

</comment><comment><USER28> I like the checklist nature of this. I approached this problem from another side, which involved a very powerful REPL, but lacked the structure this shows: [https://orestis.gr/clojure-unlocking-incremental- automation/](https://orestis.gr/clojure-unlocking-incremental-automation/)

</comment><comment><USER29> That's actually a runbook. But it's a pretty good idea to make your runbook into code! This is a nice, gradual way to begin automating. You automate one step at a time, easiest tasks first, until eventually all of it is automated. The more your steps are reusable, the easier it is to automate other tasks.

An example is approving new users to access a service. Say your list of users is a YAML file. Someone edits the file, fires off a PR, waits for someone to approve it, merges it, and applies the config. You might think it's so easy to do by hand, automating it would be a waste. But if you actually add up the time it takes for humans to do those steps, plus the lead-time from creation to completion, plus the occasional typo, wrong username, or Norway bug, it can take from hours to days to actually complete the task. By automating steps one at a time, you gradually move toward the entire process being a single script that takes a username, and completes the task in about 30 seconds. This is a small win, but added up over all your operations, reduces hundreds of hours of toil _and_ reduces human error. If every engineer automates one step of one runbook per week, over a year you'll have hundreds of reusable automation steps.

To the OP, I'd add the following: 1) use the least-complex way to accomplish the task. If you don't _need_ to write Python, don't. Bourne shell is your friend. Re-use existing tools and automated features. 2) Add documentation to the code that can be auto-generated, so you can use the script as long-lived static documentation. Documenting somewhere else will lead to stale docs. 3) Run all your runbooks from a Docker container. 4) Plan to run these runbooks- in-containers from a CI/CD system using paramaterized builds. 5) Organize your reusable automation steps by technology, but have product-specific runbooks that call the automated features. 6) In a big org, a monorepo of automation features is an efficient way to expose automated features to other teams and ramp up on shared automation quicker.

</comment><comment><USER30> I do the same sorts of things for my scripts.

I start with my "template" script and fill it out.

totally over-engineered for most tasks, but then as the tasks mature they have a firm foundation.

very simplified example:

        #!/usr/bin/python
        import sys,os,argparse

        parser = argparse.ArgumentParser(argument_default=None)
        parser.add_argument('-d', '--debug',     action='store_true',  help='debug flag')
        parser.add_argument('files', nargs='*',  default=[],           help='files to process')
        arg = parser.parse_args()

        def die(errmsg,rc=1):
            print(errmsg, file=sys.stderr)
            sys.exit(rc)

        if not arg.files:
            die('filename required')

</comment><comment><USER31> 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...

<comment><USER32> 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 ...

<comment><USER33> Came to say this. [https://www.youtube.com/watch?v=tweyWNr6X18](https://www.youtube.com/watch?v=tweyWNr6X18)

</comment></comment></comment><comment><USER34> This is a checklist. Checklists are incredible, and I quite like this version.

</comment><comment><USER35> I did something very similar just recently. I have a calendar event to backup all personal data every 3 months, based on a checklist. I'd always wanted to automate it but every time I tried, it just seemed such a daunting task that I never ended up doing it.

Last time, I figured I'd start going at it gradually. So what I did was I turned the checklist into a bash script, telling me what to do at each step. I also implemented the ones that are easy to automate. The plan is to knock out two or three items each time I do the backup, until it's fully automated.

</comment><comment><USER36> That's not "do-nothing" scripting, it's orchestration scripting for a process where the steps are executed by a human.

It's basically the minimal version of a standalone workflow automation; it's got crappy state storage and is really only good for a single human execution unit per script (or perhaps multiple swapped sequentially rather than in parallel), but it's an instance of a fairly well-known class of do-something software.

</comment><comment><USER37> Interesting idea! I'll wrote some boilerplate that I think is a bit nicer:

[https://gist.github.com/mbarkhau/60fc4bbe505914369ebd2fec1ab...](https://gist.github.com/mbarkhau/60fc4bbe505914369ebd2fec1ab6d21b)

</comment><comment><USER38> Nice idea! I'm actually in the process of automating a task bit by bit. Unfortunately it's with the intention of moving it into a CI pipeline, so the "success" there is rather binary, but I will most definitely adopt this process in future.

</comment><comment><USER39> In situations where using full-blown configuration management has too much overhead I often do something like this by just copying the commands I run into a script to begin with. It allows me to easily generalize a sequence of actions into a do-nothing template and doubles as documentation.

I'm very much against documenting concrete steps in a wiki if it is something that can be scripted. Such documentation becomes something that you must maintain, and faulty documentation is worse than no documentation.

I think that wiki documentation should be used to summarize workflows and provide context, but if you're writing step-by-step instructions, often you can just write a script with exactly the same amount of effort.

</comment><comment><USER40> Why do I think that writing a script in Expect ([https://en.wikipedia.org/wiki/Expect](https://en.wikipedia.org/wiki/Expect)) would take as long as doing this and then you would be done?

<comment><USER41> ..because you've never tried using expect in anger?

<comment><USER40> Nope, I like Expect, it's my friend and I'm able to make scripts with it. So, no anger.

</comment></comment></comment><comment><USER42> Anyone interested in this idea should check out [https://github.com/braintree/runbook](https://github.com/braintree/runbook)

</comment><comment><USER43> This is a good idea. I recently wrote down some ideas about "How to Grow a Program," in a symbolic programming environment: [https://github.com/theronic/hoist/](https://github.com/theronic/hoist/)

I call it Hoist - from "hoisting up" concrete, hard-coded values into abstract symbols for reuse. It's complete vaporware at this point, just a place to collect my thoughts for a future essay.

<comment><USER44> See also: In TDD, there are defined steps you go through as you gradually refine your code to actually do more and more things; from returning nothing, to returning one value, to returning a list, etc.

</comment></comment><comment><USER45> Great idea! From personal experience I can say that there are some things ops teams never get around to automate, either because there is always something more important to do, or because it would be too expensive to have a developer spend time automating them. This is a simple, quick solution that solves the problem of accidentally skipping a subtask, thus screwing something up and feeling stupid for doing so.

</comment><comment><USER46> This feels like a useful concept.

I stumbled into doing roughly the same in my macOS system bootstrap script. I found it from the other side, though--usually only after failing to find a good way to automate a step, or realizing automation would be vastly more complex/fragile than just prompting myself to do something manually at the right time.

Probably a more useful concept when it's conscious from the getgo. :)

</comment><comment><USER47> 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 - <USER2> ServiceNow, which allows building process flows like directed acyclical graphs and automation of necessary steps

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

</comment></comment><comment><USER49> What is the value of this over a checklist?

<comment><USER50> 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.

</comment></comment><comment><USER51> raw_input is python 2.x. Dont use it.

</comment><comment><USER52> Seems basically to be a checklist.

However, I don't think it's a good idea. Checklists are not bad, but they are to be executed by humans.

I think trying to automate an existing human process directly is a mistake. Human processes often have features that only humans can do, such as pattern recognition or adapting to small difference. It's often easier to create a computerized (automated) process from scratch than to try to account for all the edge cases that humans might have to deal with (and do without problems).

(The opposite is also true, processes that computers have no issues with can make trouble for humans. For example, humans have imperfect memory. So if the process asks humans to keep track something for extended periods, it can be difficult.)

<comment><USER53> >Checklists are not bad, but they are to be executed by humans.

I disagree. People employ checklists precisely in the situations where it is most critical that every step be executed, in order, as written. The airline industry flies on checklists.

>I think trying to automate an existing human process directly is a mistake. Human processes often have features that only humans can do, such as pattern recognition or adapting to small difference. It's often easier to create a computerized (automated) process from scratch than to try to account for all the edge cases that humans might have to deal with (and do without problems).

Now, you're letting perfect prevent you from ever attempting the good. TFA is explicitly about building a checklist that can morph the automatable steps into automated ones.

<comment><USER52> > People employ checklists precisely in the situations where it is most > critical that every step be executed

I am not arguing against checklists per se. At work, I work on (a rather old) software product which also largely runs on checklists. (Various installation and maintenance procedures are described by a checklist.)

> Now, you're letting perfect prevent you from ever attempting the good.

No. I just, based on my experience with checklists, argue that they are often poor starting point. Often they rely on abilities of humans to execute them properly.

For example, the checklist might read "edit this text file and add this and this line after line that is like this". This is difficult to automate correctly - the proper way might be perhaps to generate or keep a correct copy of the text file so automation can pick it up.

Humans are good at adapting checklists for the purpose at hand, computers aren't. That makes (human-oriented) checklists somewhat difficult to automate.

</comment></comment></comment><comment><USER54> When I can (often):

1\. Write SQL to automate

2\. Put SQL with output in Metabase

3\. Have it manually checked alongside day-to-day operation

4\. Iterate 1-3 (you often will get a lot of feedback)

5\. Replace the manual work, now that the SQL it checked on a lot of cases in production

</comment><comment><USER55> Implementation question:

Whats a good way to generalize such a python script so that windows and nix users can run it?

<comment><USER56> The best way is probably a bootstrap script ie. ps1 or sh which supplies the platform-specific parameters, and can pip install any script dependencies. So, 3-file solution. Additonally, this can be generalised to a CI platform as python can subprocess-run anything there's not a native lib for. Lastly, you could do autodoc via the script for a complete solution.

</comment></comment><comment><USER57> Are there any good slack plugins out there that can do this kind of workflow/ state management?

<comment><USER58> I don't understand why you would want to introduce Slack to this.

What benefits would that give?

<comment><USER57> Slack is like the shared OS we never had

<comment><USER58> I'm sorry, I still don't understand.

The only interpretation of that I'm coming up with is that each step of the process would be kicked off in Slack.

Wouldn't that mean people could easily stomp on each other's toes? Wouldn't there also be tons of needless noise as each of us does our workflows?

I use Slack daily, but we don't have any automation hooked up in it. I realize some teams drive deploys, alerts, and other stuff through it. That makes sense to me - this does not.

Am I missing something?

</comment></comment></comment></comment><comment><USER59> Combined with the concept of literate programming this would also help capture the "why"s of the slog, resulting in inline documentation. Jupyter and org- mode for the win!

<comment><USER60> Running such a checklist in Jupyter seems like a very good approach.

The big advantage is someone else can pick up from where you started.

And reporting is built in as you can save the notebook and review it later.

The only thing it lacks is control flow. A good operations script has exit points: if an operation fails, you often want to rollback and abort. Though even there, you can save state in a variable and have a check.

</comment></comment><comment><USER61> Checklists as Code

</comment><comment><USER62> It's a checklist

</comment><comment><USER63> This just seems like checklists with extra steps.

<comment><USER64> but this can be gradually automated with less effort than a checklist.

</comment></comment><comment><USER65> I do this!

</comment><comment><USER66> 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](https://news.ycombinator.com/item?id=3717715)

<comment><USER67> 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?

<comment><USER68> "maybe"..."in the future" is the root of much object oriented evil

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

<comment><USER70> 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.

</comment></comment></comment></comment></comment><comment><USER71> 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.

<comment><USER72> Yes, very much so. In addition stop using RSA[0] and use ed25519 with `ssh- keygen -t ed25519`

[0]: [https://blog.trailofbits.com/2019/07/08/fuck- rsa/](https://blog.trailofbits.com/2019/07/08/fuck-rsa/)

<comment><USER73> Unless you're using a hardware token via gpg-agent. In that case RSA is the only way most of the time.

<comment><USER74> Yeah hopefully when FIPS 140-3 finishes we'll start seeing hardware tokens that can do elliptic curves.</comment></comment></comment></comment>


Bill gates resigns from Microsoft Board - <AUTHOR> https://www.cnbc.com/2020/03/13/bill-gates-leaves-microsoft-board.html <comment><USER2> discussion thread when it was first announced [https://news.ycombinator.com/item?id=22570909](https://news.ycombinator.com/item?id=22570909)</comment>


The week I tried to unplug from Slack - <AUTHOR> http://www.theverge.com/2015/8/27/9213653/the-week-i-tried-to-unplug-from-slack

<comment><USER2> I don't understand the big deal with Slack. It's a glorified web-based IRC- like thing? And __yet another __centralized, privately owned, third-party service. This is always the big turn-off here. Are there good self-hosted or federated slack alternatives?

<comment><USER3> We had a perfectly working internal IRC system at work. For some managerial reasons, the decision was made to 'keep up with the trend and adapt to new softwares, firstly by moving on to Slack'.

I am young, in my mid-twenties. I like new. I like Slack too. But I honestly couldn't see any reason why we moved to it. We pay slack probably more than what we needed to maintain our own old tiny IRC box. But money aside, there are real issues with Slack that are just not there with hosting your own IRC.

The major one being privacy. For a field that is almost religiously against abuse of privacy, we sure as heck don't seem to have an issue with all of our work conversations being stored on another company's server.

Another quip I noticed was archiving. While my IRC allowed archiving without any limits, there are limits imposed on how much archives you can have access to on Slack. Of course, its customizable, but for that first time you're looking for something said 6 months ago by an ex-employee, you realize that there is no way to go back. You set your preference and learn to move on, cause well, its a different company after all. And you're paying for it.

</comment></comment><comment><USER4> I just turned off all notifications on desktop and phone except direct messages, and instances of (my n6me/my name) anywhere else. So I only get notified if somebody wants something from me personally.

<comment><USER5> That was my approach as well. It helped my productivity immensely, but I do notice that I'm slightly less aware of current events.

<comment><USER4> Agreed about the reduced awareness

</comment></comment></comment><comment><AUTHOR> I try to focus on DM's only. Written about my addiction to Slack bots here: [https://medium.com/@RecurVoice/rise-of-the-slack- bots-5a7928...](https://medium.com/@RecurVoice/rise-of-the-slack- bots-5a7928d404e7)</comment>


Musk spent $50k digging into critic's personal life - <AUTHOR> https://arstechnica.com/tech-policy/2019/09/musk-paid-investigator-50000-to-substantiate-pedo-guy-claim/ <comment><USER2> Elon Musk spent more than $50,000 digging into the personal life of British expat and Thai caver Vern Unsworth in summer 2018 in an effort to substantiate the claim that he was a "pedo guy." Musk revealed the spending in his latest response to a defamation lawsuit Unsworth filed against him last year.

</comment><comment><USER3> Can we all agree that Musk is a twat.

He talks shit about someone to a reporter and then simultaneously is cowardly enough to delete the tweets and investigate the guy he insulted.

I really wish he would take a one-way ride to a comet or something. (Seveneves readers know what I'm talking about.)

</comment><comment><USER4> Musk had no proof and admits he was wrong based on private investigators he hired, and had planned on setting up fake interviews to get personal information but believes the case should be dismissed because the people he paid misled him. What a terrible defense. I'm wondering if Musk wasn't projecting all along.

</comment><comment><AUTHOR> > But Musk argues that it doesn't matter, legally speaking, if his claims > about Unsworth were actually true. What matters is that Musk believed the > claims were true at the time he repeated them to BuzzFeed reporter Ryan Mac.

The core of the defense. His contribution to making electric vehicles popular can/should no longer serve as a shield for terrible behavior.

Edit: I take it from the influx of downvotes that any terrible behavior should just be excused...

</comment><comment><USER5> Whether Musk wins the lawsuit or not, he's proving himself to be an aerospace grade douche...

</comment><comment><USER6> So? Journalists do this with whomever they wish, and it's lucrative enough to be their full-time job.</comment>