Oh shit, git (2016) - <AUTHOR> https://ohshitgit.com/ <comment><USER2> Reading this article, I realize that I'm old now. I still remember wrestling with cvs, svn. Merge, branch were slow and even more challenging. It was much easier to mess up and so difficult to rewind.

When I first learned git, I thought it's pretty neat. It solves merge, branch, rewind problems. Git is one of the things in life that doesn't work like the way we think. But it turns out to be a better way.

<comment><USER3> I'm torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable.

That's not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit tracks its own history through rewrites. You get cool commands like absorb and evolve. It's easier to extend than Git.

The only downside to modern Mercurial I can think of is it's still slower than Git, by at least a bit. But it can scale incredibly far with its extensibility. For example, what Facebook did:

[https://code.fb.com/core-data/scaling-mercurial-at- facebook/](https://code.fb.com/core-data/scaling-mercurial-at-facebook/)

So why does it never seem to get consideration? I guess it's because of the insane proliferation of Github and Linux, which is definitely more a blessing than a curse. But it's weird. Back in the CVS and SVN days, it didn't seem like there was ever going to be a 'network effect' for source control like there is today.

I kind of wish Gitlab would implement Mercurial support. I bet it would help Mercurial gain more adoption within teams working on closed source projects. I know Bitbucket does, but to be honest that doesn't really appeal to me much.

<comment><USER4> > I'm torn. Practically Mercurial feels like it should be the winner. The > commands are more uniform and predictable.

I think that's true if you're coming from something like Perforce or Subversion and have some notion of what the expectations are around those environments. It's much easier to translate that model into Mercurial commands.

But in the end it's deceptive; git, ugly as it is, reflects the underlying data model. Once you understand that data model, and how the basic commands manipulate that model, then it becomes a very natural language for manipulating the commit chain.

If there's a downside, it's that git doesn't let you get away for too long without learning the data model, while Mercurial lets you live in blessed ignorance until the first time it doesn't work like svn does, and then you're stuck because its data model is not as cleanly exposed, so you need to gently massage it into a good state rather than just surgically moving it to where you want it to be.

<comment><USER5> I don't get that argument at all. I came from svn, used cvs and ss and I think I even tried to use Perforce at some point.

I don't see how people consider mercurial "easier", "the winner" or whatever.

I think it's like languages: if you're a french speaker and you translate everything into your native tongue while learning, then of course you won't ever get past roman languages. It's just different.

`git add -p` is my absolute favorite command ever. `tig` is just awesome. The gui clients are so beautiful and take away all the so called uglyness nowadays, though I just can't find myself using anything over git add -p. Nothing in mercurials commandline ever came close to these two. But yeah tig isn't really part of git but at the same time it's been around for so long it might as well be.

<comment><USER6> The man page for git reset states in its first paragraph:

> In the first and second form, copy entries from <tree-ish> to the index. In > the third form, set the current branch head (HEAD) to <commit>, optionally > modifying index and working tree to match.

When your documentation starts by saying (in effect) "this command does several different things", that should be a very strong sign that your command UX has some issues.

</comment></comment></comment></comment></comment><comment><USER7> Git is pretty nice, but I'm sure there is something much better waiting to he invented. The CLI in particular could use a ton of improvements.

And I feel it in my bones that there is a revolutionary GUI waiting to be invented. Why can't I drag a commit or set of commits from one branch to another? With safe, easy undo (reflog doesn't count) and super smooth conflict resolution? Etc etc.

And of course there is the interesting rabbit hole of semanitc / language aware diff. Line diffs suck in many ways.

It's one of the hundreds of of problems that I'd love to work on one day, but probably won't get a chance to. Sigh... :)

<comment><USER8> > Git is pretty nice, but I'm sure there is something much better waiting to > he invented.

It is indeed being invented. It's called Pijul: [http://pijul.org/](http://pijul.org/)

This tool is based on strong mathematical theory of patches, instead of snapshot/commit-based. It seems simpler to reason with, but we'd have to unlearn a lot from Git.

It's not suitable for big projects yet, but it's already used by Pijul itself and other Rust components. And it already have its own "Github" called the Nest (because pijul is a bird). Pretty promising imho.

<comment><USER9> > This tool is based on strong mathematical theory of patches

Is this a good thing? What practical problems does a strong mathematical theory of patches solve that git doesn't? And what's the difference between a commit and a patch? Aren't git commits stored as patches?

I'm a math lover, but my gut reaction to that idea is that it sounds off- putting. I don't mean that as a judgement or insult; I'm admitting my own assumption and bias here, jumping to unwarranted conclusion, not saying anything is wrong with pijul. But when the elevator sales pitch is "strong math", it immediately makes me assume it's too technical for a normal programmer and focused on academic ideals rather than getting practical work done as easily as possible.

The FAQ even says, "Pijul is trivial for whoever knows category theory." Is that question really asked frequently? Words like that might convince me to never try it. ;)

<comment><USER10> > Aren't git commits stored as patches?

No, they aren't, git commits are stored as snapshots. Each git commit has one tree, which is a snapshot of the state after the commit; zero or more parent commits; a pair of authors with corresponding timestamps; a commit message; and nothing more. Any patch you see in git is an illusion, made by comparing the commit's tree with the parent commit's tree.

<comment><USER9> Thank you. Sheesh I feel like I should have known this about git. That would make diffing very far apart changes super fast.

So what's the advantage to explicit storage in patches over snapshots? Are diffs between snapshots not able to capture the same information that explicit patches have?

<comment><USER11> The trouble with patches is that you can't get engineers to reliably declare whenever they copy or move code and where it came from. This is part of why svn merging was such a trainwreck, undeclared copies and moves (which look like delete+insert) almost always conflicted.

</comment></comment></comment></comment></comment></comment><comment><USER12> Am I the only one who reads "reflog" as "re-flog", that is, to be painfully whipped again?

<comment><USER13> I knew about it for at least a year thinking it _was_ "re-flog", and just considering it mysterious why they would have called it that. (You do often use it for "re"-doing things, maybe it's got something to do with that?) Hey, it was (and is) hardly the only mystery to me in git UI.

Then like a year on I suddenly realized Ohhhhh it's ref-log, that makes a _lot_ more sense!

<comment><USER14> .oO( the beatings continue until morale improves! )

</comment></comment></comment><comment><USER15> One thing that I had been looking for for a long time, but never could find, was a description of the several syntaxes you can use to refer to specific commits. Lots of git tutorials use these magic incantations, but none point you to this crucial bit of explanation.

Recently I discovered that it is found under "git help revisions".

<comment><USER16> Or just gitrevisions(7). The manpage for git(1) mentions this under the section SYMBOLIC IDENTIFIERS. Not that that's the most obvious place to look, but if you rtfm the obvious stuff, you should stumble upon these gems naturally.

It's worth scrounging through git(1) anyway; it mentions several other manpages for things like recommended workflows, the basic structure of the .git/ directory, not to mention gittutorial(7).

<comment><USER15> In git(1) it's below LOW-LEVEL COMMANDS (PLUMBING). You cannot expect a novice to read thoroughly past something like that.

And it's remarkably hard to find using web searches, since most git documentation uses the term "commit" for these things, not "revision".[0] I found it after I discovered "git help -g", which lists "some concept guides" according to "git help".

Of course, n=1 and stuff, but there's a lot about git that is not obviously documented. Something like this should be linked to in multiple places, so even if you skim over one you'll catch it relatively early.

[0] The name of the man page was chosen to avoid conflict with the "git commit" command, I guess?

</comment></comment></comment><comment><USER17> > I committed and immediately realized I need to make one small change!

I think it might be nice to add a disclaimer saying that this is not advisable if you've already pushed the code. Suck it up and make a new commit–don't rewrite public Git history.

<comment><USER18> I think changing history is fine on feature branches that only you are working on, though. IMO the benefits of keeping commit history clean outweigh the cost of having to push with "\--force".

<comment><USER19> This then discourages ad hoc teamwork because you can't touch feature branches other than the ones you own. And because the results of getting it wrong are hairy, people will tend to stay away just in case. It's a chilling effect.

Or, someone might have created another branch off your feature branch, because they depend on your work. Now you've creaed a time bomb for them when they try to merge their work after you've merged your alternative-history version of it. (and the failure mode is just weird, it takes experience to identify that all those seemingly nonsensical merge conflicts are result of this situation)

Etc. It just breaks a lot of things. The Git model and bad UI are already taxing enough to work with in your head, concurrently with your actual programming and domain cognitive load, that adding the uncertainty and multiplied complexity from having history rewritten around you is just a bad tradeoff.

(This may be different if the scenario is not a team, of course...)

<comment><USER20> you just rebase on top of their changes. No biggie here. It does not matter one bit if their branch rewrites itself underneath.

<comment><USER19> But you can't safely rebase that branch! Having rebased it, you would have now broken it for others working on it. So this is a great example how the damage spreads and taints other branches around the history rewrite.

(And even arriving at the "ok i could fix this with rebase" diagnosis will have been painful and frustrating and eaten time & energy, and you can't be sure you got away with it before actually doing it and waiting if your teammates will come kick you in the nuts. or worse, silently spend a day untangling their work.).

It's just fundamentally unsound.

<comment><USER21> > But you can't safely rebase that branch!

Huh? You _don 't_ rebase their branch. You rebase your _own_ changes on top of their branch, which they happened to recently rewrite. Just like you might rebase your changes on top of master after master has undergone changes. I think the parent's point was that it doesn't matter if the branch was rewritten or just extended; either way you rebase the same commits on it the same way. (If you're one of those people who's against the notion of rebasing _entirely_ then that's a separate debate we can have another time, but you need to separate that from the force-push issue.)

<comment><USER19> The "own" branch is also public here and maybe collaboratively worked on

<comment><USER21> So then anyone building on it would rebase the same way you just did? Which was the same way they would have done so if you had just pushed a new commit?

<comment><USER22> yeah exactly, all the FUD about rebase and shared branches is baffling to me. are people regularly getting stuck on 'git pull --rebase' and slamming into merge conflicts?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> Same idea, but much more comprehensive: [https://github.com/k88hudson/git- flight-rules](https://github.com/k88hudson/git-flight-rules)

</comment><comment><USER24> I prefer this, because it has a flow-chart [http://sethrobertson.github.io/GitFixUm/fixup.html](http://sethrobertson.github.io/GitFixUm/fixup.html)

</comment><comment><USER25> 2017: [https://news.ycombinator.com/item?id=15951825](https://news.ycombinator.com/item?id=15951825)

2016: [https://news.ycombinator.com/item?id=12459755](https://news.ycombinator.com/item?id=12459755)

</comment><comment><USER26> Git is nice tool, very versatile in able hands. Thanks to its promotion (plugins and github included), the pragmatic practice of source versioning gained wider adoption and lost that beg-your-IT-dept-to-set-it-up flair.

In the mean time, 'thanks' to Git, the source change history became a maintenance line-item. The expectations of a clean history were raised almost to the level of expectations for bug-free code.

I can see a utility of clean feature history, but asking developers to craft the history is shifting their focus away from the actual code. As long as the source state has been saved, the source control has done its main job.

So for the most of the listed 'shits', the developer should just be able to revert, cherry-pick, and re-commit, and keep going. Nothing esoteric and hard to remember, also fairly common commands across different VCS tools. Shit happens and will happen again, no biggie, no need to blame and shame, source annotation will show the right change/comment anyway.

</comment><comment><USER27> Git performs like what it is : a piece of code created by debugging a blank sheet of paper. I can detect almost no philosophy and no simplifying assumptions. The thought that you need 60+ commands (the current size of my git cheat sheet, including all the bizarre argument incantations which seem customized for all 100+ possible mistakes in git) to get through the day is an abomination. I prefer perforce which requires less than 20 commands. The only reason people use git is because, Linus.

Like no good program, ever, to use git you have to understand all the compromises and all the internals of its data structures. What a joke.

</comment><comment><USER28> > I use reflog A LOT

If you need to reset with reflog a lot you're probably using git wrong.

Sure it can be useful but I don't see why it should be in a workflow.

</comment><comment><USER29> > git diff --staged

The way it worked well was that the "\--staged" flag would be implied if you had already staged some files to be committed.

But on this day I noticed that nothing bad happened from that behavior. So I time traveled back and whispered to the git devs that the interface should be made more pedantic to keep users from relying too much on git to do the right thing for them.

Now it's great because users suffer and I have plausible deniability from this now being on par with the rest of git's interface.

</comment><comment><USER30> This has been immensely useful every now and then

</comment><comment><USER31> > git reset HEAD~ --hard

Seems fairly magical compared to other stuff here. To me at least. Can anyone briefly explain what it does?

<comment><USER32> HEAD~ means 'the second to last commit in the current branch' (ie. the second to last when you `git log`).

git reset means 'point the current branch to this commit instead of wherver it's pointing now' (branches in git are just pointers to commits)

git reset --hard means 'also reset the state of the checkout and staging area to be in sync with the commit'

Thus, the entire spell means 'reset the current branch to make it point the the seecond-to-last-commit, also ensure my current checkout and staging area are in sync to that', or, in other words, fully forget and drop the latest commit.

<comment><USER33> [Edit: It seems that I was mistaken but I'm leaving this up to illustrate the confusion. In my experience "second to last" isn't common and "next to last" is much more common, which I think is why I was confused because I thought they were different, but apparently they are the same. I wonder if there is a regional usage pattern to these phrases. ]

This seems like mistake or a non-standard usage of the english phrase "second to last". Given a git log of:

        $ git log --oneline
        15e0437 - (HEAD -> master) this is the third commit
        f82d1fd - this is the second commit
        9180c17 - initial commit

I would call "f82d1fd" the "next to last commit" and it can be referred to as HEAD~ I would call "9180c17" the "second to last commit" and it can be referred to as HEAD~2

<comment><USER32> I don't know (definitely not a native English speaker), but Wikitionary seems to agree with me: [https://en.wiktionary.org/wiki/second_to_last#English](https://en.wiktionary.org/wiki/second_to_last#English) .

<comment><USER33> Well, I think you may be right. See my edit above. I suspect this is a regional usage pattern and I've just always been in places where "next to last" would be used and not "second to last" so I was thinking they were different, but they apparently are the same!

Learn something new every day.

<comment><USER33> Here is an ngram analysis with a British corpus

[https://books.google.com/ngrams/graph?content=second+last%2C...](https://books.google.com/ngrams/graph?content=second+last%2Csecond+to+last%2Cnext+to+last&year_start=1800&year_end=2000&corpus=18&smoothing=3&share=&direct_url=t1%3B%2Csecond%20last%3B%2Cc0%3B.t1%3B%2Csecond%20to%20last%3B%2Cc0%3B.t1%3B%2Cnext%20to%20last%3B%2Cc0#t1%3B%2Csecond%20last%3B%2Cc0%3B.t1%3B%2Csecond%20to%20last%3B%2Cc0%3B.t1%3B%2Cnext%20to%20last%3B%2Cc0)

And here is one with an American corpus:

[https://books.google.com/ngrams/graph?content=second+last%2C...](https://books.google.com/ngrams/graph?content=second+last%2Csecond+to+last%2Cnext+to+last&year_start=1800&year_end=2000&corpus=17&smoothing=3&share=&direct_url=t1%3B%2Csecond%20last%3B%2Cc0%3B.t1%3B%2Csecond%20to%20last%3B%2Cc0%3B.t1%3B%2Cnext%20to%20last%3B%2Cc0)

<comment><USER32> Nice tool. You should expand the search range to include 2018/2019\. Quite a significant change happened since then.

</comment></comment></comment></comment></comment></comment></comment><comment><USER34> Many of these problems can be avoided by using a pull-request style workflow.

<comment><USER35> I don't see how prs would help solving any of those. It's common for me to use a few of these commands before I open the PR.

<comment><USER36> They stop you from pushing anything broken to master. So you only have to worry about being in a broken state locally on your machine, not about accidentally breaking master for everybody.

Ideally your code review system should be the only one to have merge rights to master. Then nobody can singularly break master at least.

</comment></comment></comment><comment><USER37> Oh shit, this commit message buried by new commits must be fixed before it is propagated to other repositories.

Oh shit someone has fixed an old commit message that was already pushed to other repositories.

Oh shit, this commit ough to be a merge commit. The tree is good, but not the parents.

</comment><comment><USER38> Thanks for this excellent cheat shit

</comment><comment><USER39> The last example [0] really should reference the obligatory XKCD [1]

[0] [https://ohshitgit.com/#fuck-this-noise](https://ohshitgit.com/#fuck-this- noise)

[1] [https://xkcd.com/1597/](https://xkcd.com/1597/)

</comment><comment> rich-tea Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn.

This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day going through something like this: [https://wyag.thb.lt/](https://wyag.thb.lt/)

It will make you better at git and better at programming. Git is a powerful tool and you need to _learn_ how to use it. Imagine if people read articles like this one instead of learning how to drive.

<comment><USER40> What's a DAG?

<comment><USER41> [https://medium.com/girl-writes-code/git-is-a-directed- acycli...](https://medium.com/girl-writes-code/git-is-a-directed-acyclic- graph-and-what-the-heck-does-that-mean-b6c8dec65059)

<comment> rich-tea Unfortunately this article, like almost all others, is still wrong because it looks like commits get mutated when you rebase and the old commits disappear.

It is very important to understand that commits (in fact, all blobs) are immutable in git. You can only make new things. You can't modify old things. Git doesn't delete anything for a while either.

</comment></comment></comment></comment><comment><USER42> I don't get this "afraid of losing something" mindset at all. In fifteen years, I've "lost" some minor changes maybe 3 or 4 times, and this was mostly with SVN, which does not have the safeguards that Git has. The only thing that I am moderately afraid of is pushing to the wrong remote branch.

<comment><USER21> > I don't get this "afraid of losing something" mindset at all. In fifteen > years, I've "lost" some minor changes maybe 3 or 4 times, and this was > mostly with SVN, which does not have the safeguards that Git has. The only > thing that I am moderately afraid of is pushing to the wrong remote branch.

I can lose something for you in 2 seconds in git. Have fun e.g. recovering from this:

      $ git init
      $ mkdir -p widget && echo Introduction > widget/readme.txt
      $ git add widget
      $ git commit -m "Initial commit"
      $ echo Conclusion > widget/readme.txt
      $ git checkout widget
      $ cat widget/readme.txt  # No "Conclusion"??

<comment><USER43> Wow just tried this.. is this considered a bug or a feature and where can you read about this if it is intended behavior?

<comment><USER44> `git checkout --help` gives

           git checkout [<tree-ish>] [--] <pathspec>...
               Overwrite paths in the working tree by replacing with the contents
               in the index or in the <tree-ish> (most often a commit). When a
               <tree-ish> is given, the paths that match the <pathspec> are
               updated both in the index and in the working tree.

As 'widget' is a _path_ (and not a branchname as most often), local changes will be overwritten. Together with `git reset --hard` this is a bit a dangerous operation. I must say, that I don't fully understand the help text and just remember that `git checkout <path>` throws away my local uncommitted changes.

<comment><USER21> Also note that 'widget' could've also easily been a typo for a branch (maybe they meant 'widgets' or something). Meaning that even if you only stick to uses of git checkout for branches, you're not safe (unless you're infallible).

</comment></comment></comment></comment></comment><comment><USER45> Honest to god, I don't know how people who find `git` hard to use manage to write code. Everyone on the Internet acts like the concepts are impossible to grasp and it's like really easy to grok.

Honestly, it faded into the background of code from the beginning. I mean, I know "Forward-port local commits to the updated upstream head" means nothing to anyone not already familiar with `git rebase` but a practical mastery of the tool is very easy to achieve.

I honestly think this is a pedagogical lack. We tell everyone it's this complex thing and that they should be scared of rebase and the reflog and they believe it. Maybe if we didn't, it'd be easier.

<comment><USER46> I was thinking if I would post what you did it would get downvoted but yeah, if you find git hard how or why are you writing code? That is surely a lot harder. Not sure why it is downvoted as sure it might not be a popular opinion but it seems to hold...

<comment><USER47> I want to focus on code and not be wrestling with a version control system.</comment></comment></comment>


Ask HN: What do you use as a web based BOM management tool? - <AUTHOR> I'm on the hunt for a web based app to manage hardware Bill of Materials (BOM).  I found https://ciiva.com/ and http://kimonex.com/
Have you had luck with either tool or do you have a better recommendation? <comment><USER2> Hi there, We are developing new kind of BoM management tool - openBoM. Please check our website openbom.com and feel free to reach me out directly at firstname.lastname@example.com</comment>


Java developers are what's wrong with java? no. - <AUTHOR> http://www.theserverside.com/news/thread.tss?thread_id=61882

<comment><USER2> Blah, blah, blah, Java, blah, XML, blah, EJB, over-engineering, blah, blah, blah, web services, blah, blah, java, culture, blah, ejb, blah, transactions, blah, blah, blah, yada, yada, yada.

I call bullshit on this entire discussion. There are good and bad programmers using all languages and platforms, a bad programmer can write FORTRAN in any language; complex solutions are sometimes called for, and sometimes not; sometimes the "pragmatic" thing to do _is_ to build in flexibility for unanticipated scenarios, sometimes doing so is just over-engineering.

None of this has a damn thing to do with Java (or any other language, library or platform) per-se... it's just hip to bash Java and Java programmers these days. It's what the cool kids are doing, so it must be right, no?

Let's just quit wasting our time on these pointless discussions and worry about building cool shit; whether we're building it in Java, C#, Python, C++, Ruby, Haskell, Erlang, Scala, Clojure, Groovy, Tcl, Perl, Ada, APL, FORTRAN, COBOL, RPG/400, PL/I, Intercal, Brainfuck, Befunge, Whitespace or whatever.</comment>


Bob Lutz Thinks the Tesla Model S Is a Future Classic - <AUTHOR> http://www.thedrive.com/sheetmetal/17833/bob-lutz-thinks-the-tesla-model-s-is-a-future-classic <comment><USER2> "He thinks that, in the future, the Model S "will be remembered as the first really good-looking, fast electric car. People will say 'Too bad they went broke.'""

Indeed. The Model S is a lovely looking car. Better looking than practically every other EV, which is usually an exercise in plastic decor in the wrong places, and cringe.

</comment><comment><USER3> We need the "Android" of iTesla edition that the rest of us can afford...

<comment><USER4> Till Toyota goes all in on electric I don't see it in the near future. Toyota so far has been promoting and trying hydrogen based cars rather than electric.

<comment><USER5> Toyota is playing it safe like they always did. Part of the reason why they build reliable vehicles, albeit rather utilitarian and some times even boring or ugly.

</comment></comment></comment><comment><USER6> I read Lutz's column in Road & Track. It's good.</comment>


Palm Pre's New Strategy: Forget iTunes, Hello Wireless Amazon Downloads - <AUTHOR> http://www.readwriteweb.com/archives/palm_pres_new_strategy_forget_itunes_hello_wireless_amazon_downloads.php

<comment><USER3> Makes sense -- why fight a fight with Apple that they can't win?

There are already plenty of third party sync solutions that will move your music to your Pre. From PreCentral.net: "In other words, we're still leaning towards suggesting people at least dip their toes into the non-iTunes-direct- sync waters. DoubleTwist, Salling Sync, Drag 'n Drop, The Missing Sync: learn them, love them, switch to them."

</comment><comment><USER4> Not sure I agree with this comment 'While Palm hasn't officially responded to the USB-IF's letter - despite being told they had to do so within a week - <USER2> seems that they have, without actually saying so, made their decision. '.

It is likely the Amazon connection was likely in the works long before Palm recieved the ruling by USB-IF, which I believe was only about two weeks ago.

</comment><comment><USER5> Unless you're going to build a music store yourself from scratch, Amazon is the obvious choice.

</comment><comment><USER5> Android phones shipped with an Amazon MP3 store app. Not sure how this is any different.</comment>


You Won't Regret Positive Feedback - <AUTHOR> http://zachholman.com/posts/positive-feedback <comment><USER2> This is an interesting problem. I was a dual English/CompSci major in undergrad, and while CompSci didn't have the notion of critiques, my creative writing classes were almost entirely critique-based. Back then, critiques were almost entirely pleasant and useful. When critiquing product — or even doing code reviews — now, though, it often feels more confrontational.

I wonder how my English professors did it: they fostered an environment where even though you may have slaved away for nights on your short story, _it was alright_ when someone pointed out the flaws. Because critique is really important for creating good products, whether those products are apps or websites or code or short fiction. I don't regret ever giving positive feedback, but I still do sometimes regret flaws in launched products. Could an early critique have made things go another way?

I think at least part of why critiques worked so well in my creative writing classes was the strong notion of authorship, and ownership — that you could give your critique, but if the author disagreed, they were the author and in control of the voice. In professional writing it can be different — your editor can certainly force changes, with more or less control depending on the industry — but even there, a lot of control is left to the writer: the editor might say a section needs work, but even if they suggest changes they'll generally allow writers control over phrasing.

Part of the problem might also be power dynamics: critiques in a professional environment can come across as self-serving, or gunning for a promotion, or as being enforced from the top. Is there a way to separate the critique from the critic?

I don't know how to recreate my old English classrooms yet but I want to. Positive feedback is important to create a healthy work environment, but if you can't highlight problems then how will anyone consider fixing them?

<comment><USER3> That's very interesting. The difference I see between writing/writers and programming/programmers is that, and please correct me if I'm wrong, writers tend to work alone whereas programmers build code as a team.

So if I'm reviewing a pull request, it's code that's going to enter the shared codebase, and touching code of others on the team. It's not the same as reviewing someone's independent work, completely separate from my own.

I do wonder however about creative writing environments, where more than one person is involved. One example I can think of (but have very limited knowledge about) is comedy scriptwriting. I've heard it's usually a team of writers that works on a sitcom. I wonder how they work together constructively, and if there are lessons to be learned from those kinds of environments. Or perhaps the same problems exist there as there are in technology, where egos and timelines are involved...

<comment><USER2> That's a good point — it's a lot easier to give dispassionate negative feedback if the person's work isn't directly tied to your own. And it's a lot easier to view negative feedback as helpful rather than confrontational when it's dispassionate.

</comment></comment></comment><comment><USER4> > It seemed to work for Apple.

One of the greatest features of our universe is that the rules break down as you reach the extreme ends of any standard distribution.

The most survivable weeds in my backyard are clovers and dandelions. However, there is a huge vine growing in the corner of my fence, the thing is like an oak tree. No other vines have grown up anywhere else, and even my attempts to _encourage_ vines to grow along the side of my porch has failed.

If I were to focus on the impressive vine and ignore the clovers and dandelions I'd jump to the conclusion that vines are the most successful weeds in my backyard. While in reality I have no idea why the vine grew, but if I take it out of the equation I can better focus on what is making the clovers and dandelions grow.

Steve Jobs, Apple, Bill Gates, Microsoft, The Beetles, Rolling Stones and countless other extremes do not make good case studies for how to do things simply because their extreme success cannot be compared to anything else. They are all like the vine in my backyard; a special case with an unknown history.

The best thing to do isn't to look at the most successful companies or people, in fact, you would be better served taking the top 10% _out_ of the equation and instead focus on what made the top 75-90% successful.

</comment><comment><USER5> It's true that SJ built a high pressure work environment, but I bet if you asked any Apple engineer, they would all admit they produced some of their life's best work under that culture.

It may seem draining and offensive after the fact, but in the moment being pushed to your max, you really can change the world.

No one is against more positive work places, but not everyone can handle hostile ones, so there is an allure to that in itself.

<comment><USER6> The belief that someone will produce their "best work" in a stress-filled deadline of _one project_ is shortsighted.

If by "best work" you mean "maximum extraction in a short time frame," you're probably correct. But the belief that someone can truly produce a magnum opus in the truest since within one project, especially a project that driven by a negative taskmaster, is completely ludicrous. Its a myth perpetrated by the taskmasters of this industry. These projects may culminate to their magnum opus, but it's not yours.

<comment><USER7> > the belief that someone can truly produce a magnum opus [...] within [...] a > project that driven by a negative taskmaster, is completely ludicrous

There's a difference between a _stressful_ and an _honest_ environment. If you read some of the classics of engineering literature ("Skunk Works", "Dealers of Lightning" etc.), some of the greatest engineering projects ever created were built with managers who were not afraid to tell people they sucked and could do better. I think, in general, to produce a magnum opus most of us do need an external, unbiased mirror of our performance. It's easy to err on the negative side and discourage people; but erring on the positive side (which is far more common these days) is also a betrayal of that person's true potential.

</comment></comment></comment><comment><USER8> I'm a big believer in the advice featured in the blog post. I think criticism is the single most important thing that needs to be addressed in order to solve dysfunctions in a team, and i recognise that addressing this can really change the management fortunes of a business. But what really puzzles me is how Steve Jobs get away with it. He built one of the best management teams in the world, had great employee retention and yet clearly used short-sight tactics for motivation. I just don't get how he pulled it off in spite of his bad behaviour.

<comment><USER9> For what its worth my previous boss seemed to share the same characteristics as Steve Jobs. At times I didn't like him much but he had two redeeming qualities. He was hard on everyone including the server guys who were giving me the run around. Secondly he worked bloody hard! If I asked him to review something, he really would review it. He replied all my emails in detail. When I told him what I needed he would apply his energies to getting what I needed, then it would be my turn to deliver.

Now that I don't work for my former boss I do miss his ability to get things done. I guess the moral of the story is people can get away with Jobs' like attitudes as long as they deliver themselves. Being shitty without the hard work will lead to failure and very unhappy environments. Is it worth it I don't know.

<comment><USER8> Very interesting. I hadn't considered that possibility before. Most of the managers i come across excel in their ability to direct blame to others and criticise yet can never deliver on their own promises or lead by example in getting things done. I can see how, being a real doer would redeem them greatly. It's starting to make sense now. This was a complete eye opener. Thanks!

</comment></comment></comment><comment><USER10> On the one-hand, yeah, positive feedback feels good and all. On the other hand, as Gordon Ramsay says, "My team doesn't care about the positives. They listen for the negatives." Maybe the difference is in the sense of ownership the team feels over the final result. If the look, feel, and strategy has come down from on high, listening for the negatives is of limited utility, since you can't change anything anyway. But if everything is going forward on your say-so, the negatives are a powerful tool that you should seek out at any opportunity.

</comment><comment><USER11> The Steve Jobs effect is often taken to justify being an asshole. No. It's the other way around, in fact.

Yes, Jobs was an asshole in many ways. By being such, he kept bikeshedding executives and bullshitters in line. That is the Steve Jobs Effect, right there. If you have a sniper on the bridge to shoot young wolves before they become a problem, you'll have a much more effective company than if you let the young wolf conflicts happen. It's not that executive assholes are good per se; it's that they're better than young wolves.

Most large companies hire a pretty-faced do-nothing to be the CEO and leave the nastiness to the lieutenants at lower levels. The CEO gets to be everyone's friend. It's the VPs who play nasty games and carve out political fiefs (because, if they don't, they won't get groomed to be future CEOs, there or elsewhere). That makes the organization a lot more ineffective because they all fight each other as they assert their own career agendas.

One of the Tories during the American Revolution wrote that he'd rather have 1 tyrant 3,000 miles away than 3,000 tyrants one mile away. I think there's something there. Apple was an effective company because it had one asshole far away from the people getting the work done, and he routinely made it so unpleasant to be higher-up that only genuine people would even vie for it. This kept the engineers and designers safe from the middle management and junior executives who'd otherwise make their lives a living hell.

Look at Google. I know I pick on them a lot, but with a Steve Jobs that company would _never_ have ended up with calibration scores. To lead any large group of people you have to be enough of an asshole to understand how assholes think. Google's founders are not assholes, and that's why they weren't able, when calibration scores were first proposed, to shoot that idea from a bridge.

Ok, so am I pro-asshole? No, I'm not. Here's one thing to keep in mind. Steve Jobs's are very rare. Assholes are not. For every person with that kind of talent, there are 999 who think they do. Also, I don't think Steve Jobs was that much of an asshole. He had his demons, sure. On the other hand, he seemed to have a genuine interest in protecting engineers and designers from executives and managers. If you were an engineer, he was kind to you. It was only the VPs and above to whom he was known for being a jerk.

I think something more like Valve (open allocation, constitutional anti- asshole employee autonomy provisions) is generally better than Apple (dictatorial control) for most people (but not all). If you want world domination like Apple, then maybe you need an asshole or two. If you just want to build a good company, I think that assholes almost always take away more than they bring. Steve Jobs really is a 4-sigma outlier. That's something that the "tech" industry is getting quite wrong right now. Most of these startups think there's something positive about hiring a few assholes while failing to realize that _one_ can break a whole company.

Also, Fake Steve Jobs's tend to be freakishly common in VC-funded startups where there isn't enough hierarchy for the Steve Jobs Effect to even make sense. In a 10,000 person company, it's better for the 1 person at the top to scare the next 99 enough that the leave the 9900 at the bottom alone so they can make the company great. In a 75-person company, assholes are just outright corrosive.

</comment><comment><USER12> Don't be a shithead. Good advice to remember at any time. Smart people often mistake showing their smarts with being a shithead. The very smartest ones grow out of it.</comment>


Show HN: An Open-Source Intro to WebApps Curriculum - <AUTHOR> http://adicu.com/intro-webdev/

<comment><AUTHOR> Some background: this is a curriculum for a week-long, student-run workshop series and hackathon called DevFest hosted at Columbia University ([http://devfe.st](http://devfe.st)).</comment>


Britain nearly went bust in March, says Bank of England - <AUTHOR> https://www.theguardian.com/world/2020/jun/22/britain-nearly-went-bust-in-march-says-bank-of-england <comment><USER2> Given Britain can't go bust as a matter of accounting given it has its own currency I expected to find an article explaining why the characters suggesting this are lying.

No such luck.

The Bank of England will alway fund the UK government because the UK government owns the Bank of England. If Bailey had refused he would have been sacked.

HM Treasury has those powers under section 19(1) of the Bank of England Act 1998.

<comment><USER3> Interesting how Italy almost went bust for the reason you mention, if the ECB wouldn't have stepped in (potentially illegally, which we might find out in the future), we would have had a eurozone crises.

But of course the guardian never misses a chance to make a conservative government look bad, despite any other government having done the same.

<comment><USER4> Is it because ECU is not Italian money but pound is. UK can go bust on, say, foreign debt. Or UK government can go bust. But UK in pounds?</comment></comment></comment>


REPL: To JSON what Excel is to CSV - <AUTHOR> http://repl.cc

<comment><USER3> That's a stupid name... REPL has had a precise meaning (Read-Eval-Print-Loop) for the last 50 years, and I don't know how one can choose to give that name to a project.

<comment><USER4> Its a template for building a pipeline. Naming it after this metaphor ("jspipe"?) might work better. It's more like a OpenRefine[0] than Excel; that analogy doesn't work at all for me.

It's a REPL in the sense that when you click Run, the value of the current evaluation is used (Looped) as the input for the next expression, but this stretches the common understanding, and naming it this way fails to communicate.

The full page transition when you click Run loses the implicit history from a teletype or terminal scrollback. A shell works because you can see two or more values were visible at the same time. The second pane could then show the code of the currently selected value. You could even show the diff/patch between the values as well.

The 'Run' text should look like a button rather than a label, and be moved to the right. It might work even better to just evaluate the code on a timeout without an explicit gesture.

0\. [http://openrefine.org/](http://openrefine.org/)

Edited: for more positive feedback.

<comment><USER5> Yes, it's _a_ repl, sort of, but calling it "repl" is like calling a new text editor "editor" or a new programming language "language", seriously confusing and impossible to search for.

<comment><USER6> they should have called it "rep" and put up a rant proclaiming "REP IS THE ONE TRUE REPL"

</comment></comment></comment></comment><comment><USER7> Pretty clever, but pretty obscure compared to Excel.

The power of Excel is that you can manipulate the data within the view itself, so for that comparison to make sense, I would expect to be able to add a node to the data, for example, and define its contents using a formula (function).

<comment><USER8> Yeah, I don't understand the comparison to Excel either.

What I really want is SQL for JSON. Regular SQL is a declarative language for transforming flat lists of records into other flat lists of records, and the challenge is extending it to allow nested records. Has that been done?

<comment><USER9> It doesn't have very SQLish syntax, but there are various JSON ports of XPath and XQuery from the XML world.

<comment><USER8> Ooh, that's exactly what I was looking for. Thanks!

</comment></comment></comment></comment><comment><USER10> Maybe explain on the main page a bit better? I didn't understand what this was at first and the screenshots for the example didn't really help. I had to play with it for a minute before I got it.

<comment><USER11> I played with it too, and I still don't get it. I completely missed the Excel comparison.

</comment></comment><comment><USER12> [http://stedolan.github.io/jq/](http://stedolan.github.io/jq/)

<comment><USER13> jq is cool, but can it also be used to construct JSON? It's great for parsing, but OP's tool covers all the different aspects.

<comment><USER14> Yes, It can.

</comment></comment></comment><comment><USER15> Do you mean Excel the expensive PC program found on legacy corporate Windows intranets, or Excel the hard to decipher proprietary file format?

<comment><USER16> He probably means Excel the industry standard program for data collection, management and analysis for everyone not working in IT.

<comment><USER17> And therefore doing it in a way that is NOT reproducible, easy to audit nor reliable.

How many times have we seen papers and science blown because someone made a mistake in the 50 steps they did to get their results?

CSV > Excel

<comment><USER18> Not understanding how you can rank CSV vs Excel. Excel is a platform that let's you easily build up complex calculations with different statistics, graphs, formatting, and a lot more. CSV is an interop file format for plain text tabular data.

Yes, I'd rather a raw dump of data in CSV than XLS, but it seems like you're making a more general statement than that.

</comment></comment></comment></comment><comment><USER19> Please, please don't try the example on the front page. Putting your stripe api key in a script on an insecure host is totally crazy.

<comment><AUTHOR> No key on the front page visible

<comment><USER20> No, of course not, but the example suggests you could put your key in and pull down your invoices from stripe to do data mining on them.

</comment></comment></comment><comment><USER21> I don't get why should I need an app like this.. Isn't it enough to use something like the Chrome console with jQuery.map?

</comment><comment><USER22> If you're a coder that had to generate CSV files to be opened in Excel, you don't necessarily associate those two things as a good match :)

</comment><comment> 97-109-107 Seems like exactly the tool we needed just two days ago for pruning down a 49mb json file. We ended up parsing it in nodejs as it could simply spit out the output to a file. I didn't want to risk crashing my browser again - <USER2> there any chance that a client-side web-app parser (like yours) would be able to handle files that big?

<comment><AUTHOR> Yep. We are trying to push our bizdev to use it as well. It's still slightly complicated... but they're starting to get it! :)

<comment> 97-109-107 Am I missing something, but wouldn't that require pasting the 49mb file into your app through my clipboard? Just getting a file like that into the clipboard, let alone pasting into the browser, seems like a task in itself.

<comment><AUTHOR> Yes you're right. 49mb is slightly large for REPL. but I've been working successfully with 200k lines CSV of over 15mb without issue

<comment><USER23> Your bandwidth has nothing to do with it, it runs in the browser.

All it does is JSON.parse, execute your series of functions then JSON.stringify.

Unless I'm missing something there is no advantage over ad-hoc javascript. If you want to load a file from disk, deserialize and do some processing in javascript then node is absolutely the right tool (and this isn't).

</comment></comment></comment></comment></comment><comment><USER23> I don't get this at all.

I can build a pipeline of functions and view the output just as conveniently in a plain node or browser environment and I would have much more flexibility.

Has anyone got a use case?

Anyone?

</comment><comment><USER24> ...undocumented and bloated?

</comment><comment><USER25> I just don't get this.

<comment><USER26> thank god i'm not the only one.

I don't know what it is, some of the products/projects being shown on HN lately have the problem of coherently explaining and demoing what the they do.

</comment></comment><comment><USER27> My favorite feature is the ability to expand and collapse at the object level. Anybody have a favorite tool for this?

</comment><comment><USER28> The last thing I want to use Excel for is CSV. It seems to me what JSON needs is an equivalent to XSLT

</comment><comment><USER29> Could probably do with turning those screenshots into an animated GIF as it took me a while to work out the flow, and that presumably each stage is persistent (I'm guessing, from the Run 0>1>2 chevrons).

</comment><comment><USER30> I think this is exactly what I needed yesterday when someone asked me is it possible to get a report from Asana into excel (Asana doesn't have this ability, just the json API).

<comment><USER31> Take a look at this: [https://voyager.datanitro.com/](https://voyager.datanitro.com/)

</comment></comment><comment><USER32> Wow, I was expecting this to get some criticism as I clicked the comments, but this is a bit more negativity than I would have expected from HN.

<comment><USER33> More meta-negativity than anyone was expecting.

</comment></comment><comment><USER34> [http://kmkeen.com/jshon/](http://kmkeen.com/jshon/)

</comment><comment><USER35> "Excel is to CSV" You mean a huge bloated mess that takes forever to load and encourages people to turn my beautiful data into some proprietary bollocks because they're to lazy to learn awk? Sorry, that was quite a long sentence, let me see if I can turn it into a useless but pretty chart...

<comment><USER36> Pretty wrong. It's a huge bloated mess that takes forever to lead and can be used to store data and code seamlessly in cells to make a single document holding both presentation and logic. Excel suffers from being a microsoft product, not from a being a bad idea. Spreadsheets are a fucking great idea. Visual programming, code as data, etc etc.

<comment><USER17> I disagree. It isn't reproducible AND people make mistakes and then present papers and other outcomes that later is shown to be false.

Spreadsheets are treated as Swiss Army Knifes. People believe all they need to do anything is Word and Excel.

<comment><USER18> What could the same people who are using excel have used instead that would have prevented them from making an error in their steps of calculation?

</comment></comment></comment></comment><comment><USER37> It would be cool if you could use coffeescript instead of js.</comment>


Digging into Browser-Based Crypto Mining - <AUTHOR> https://arxiv.org/abs/1808.00811 <comment><USER2> If I did the math right, then if the notebook I typing this comment on mined at 100% CPU load for 1 hour, the payout to the script owner would be equivalent to US$0.00085. For nearly 200 Wh consumed, or 70g CO2 equivalent, or $0.004/kWh. That's two orders of magnitude less than the cost of the energy consumed, supposedly somewhere around 3% efficiency.

I suppose asking for donations/selling subscriptions/products/whatever is more sustainable. Even if 3 users out of 100 agreed to donate/pay the monetary equivalent of 1 kWh (~ $0.140), the site owner would receive more than forcing 100 users to heat the air for one hour and putting 7kg CO2 in the atmosphere.

The web doesn't need browser-based mining. The web needs affordable and convenient microtransactions. With something better than a 0.05 + 5% fee.

<comment><USER3> It seems to me the problem its solving isn't efficiently 'mining' the currency, its efficiently _transferring_ small amounts of money. If there was a way a website could present a button I could use to flip them a penny (without a complicated setup or previous relationship with them) on my way thru if I like the content, I'd smash that thing all day long.

The telling thing is that people are seriously considering a system that wastes 97% of the money in the tiny transaction to easily transfer the 3%.

<comment><USER4> Essentially the problem with micropayments is microscams: [https://news.ycombinator.com/item?id=15592192](https://news.ycombinator.com/item?id=15592192)

Stealth browser-mining lets everyone skip all the genuine attempts at transferring value and go straight to microscams.

Edit: hoisted body of comment: "Unsolved, difficult problems of micropayments"

\- pay before viewing: how do you know that the thing you're paying for is the thing that you're expecting? What if it's a rickroll or goatse?

\- so do you give refunds a la steam?

\- pay and adverts: double-dipping is very annoying

\- pay and adverts: how do you know who you're paying? A page appears with a micropayment request, but how do you know you've not just paid the advertiser to view their ad?

\- pay and frame: can you have multiple payees per displayed page? (this has good and bad ideas)

\- pay and popups: it's going to be like those notification or app install modals, yet another annoyance for people to bounce off

\- pay limits: contactless has a £30 limit here. Would you have the same payment system suitable for $.01 payments and $1000 payments? How easy is it to trick people into paying over the odds (see refunds)?

\- pay and censors: who's excluded from the payment system? Why?

Essentially the problem with micropayments is microscams.

Part 2: business model problems!

\- getting money into the system is plagued by usual fraud problems of card TX for pure digital goods

\- nobody wants to build a federated system; everyone wants to build a Play/Apple/Steam store where they take 30%

\- winner-take-all effects are strong

\- Play store et al already exist, why not use that?

\- Free substitute goods are just a click away

\- Consumers will pirate anything no matter how cheap the original is

\- No real consumer demand for micropayments

=> lemma from previous 3 items: market for online goods is efficient enough to drive all marginal prices to zero

\- existing problem of the play store letting your kid spend all the money

\- friction: it would be great if you didn't have to repeatedly approve things, such as a micropayment for every page of a webcomic archive. But blanket approval lets bad actors drain the jar or inattentive users waste it and then feel conned

\- first most obvious model for making this work is porn, which is inevitably blacklisted by the payment processors, has a worse environment for fraud/chargebacks, and is toxic to VCs (see Patreon and even Craigslist)

\- Internet has actually killed previously working micropayment systems such as Minitel, paid ringtones (anyone remember the dark era of Crazy Frog?); surviving ones like premium SMS and phone have a scammy, seedy feel.

\- accounting requirements: do you have to pay VAT on that micropayment? do you have to declare it? Is it a federal offence to sell something to an Iranian or North Korean for one cent?

</comment></comment></comment><comment><USER5> There are a number of other crypto coins that can be mined via the browser, most notably Nimiq which uses an algorithm (Argon2d) that is ASIC resistant meaning in theory it should be even more profitable for normal day users without high end GPU systems to mine.

Nimiq itself is making some pretty interesting tech implementations such as being written ground up in Javascript and rewriting core parts in Rust so it will run in the browser via web assembly. Their code base is worth checking out: [https://github.com/nimiq-network/core](https://github.com/nimiq- network/core)

<comment><USER6> While the paper prominently mentions Monero as an example of browser-based mining, the first part of the analysis is independent of specific cryptocurrencies because it looks for heavy wasm usages. (The second part of the analysis is specifically targeted to Coinhive as it had the largest share, however.)

</comment></comment><comment><USER7> Here's an HTML version if you're on a phone: [https://www.arxiv- vanity.com/papers/1808.00811/](https://www.arxiv- vanity.com/papers/1808.00811/)

<comment><USER8> Bless

</comment></comment><comment><USER9> I've been looking to experiment with browser mining solutions recently but the offerings are really lacking imo. It seems to be a simple problem (let users mine in exchange for virtual goods ~proportional to the solved hashes) but bar CoinHive I ended up with nothing promising and I can't really justify their 30% cut.

</comment><comment><USER10> I feel like one of the big issues here is that we're seeing more users visiting websites on their mobile and that means website owners want to monetize from mobile users. Browser-based mining takes a significant toll on mobile battery and excessively increases the temperature of your mobile device, which can lead to other concerns. Mining is also much slower on most mobile devices.

Coinhive themselves suggest against implementing mining for mobile users, but it appears that some people are not so concerned for their users' mobile devices.

</comment><comment><USER11> Is gpu powered keccak mining possible in a browser? Could anyone point me in the right direction or interesting in collaborating?

<comment><USER12> GPUs are just as power hungry as CPUs (keccak/sha3/sha2/cryptonight; it's going to draw more power). Monetizing your user base via any type of proof-of- work at this point is just plain stealing electricity IMHO, unless your user base is an ASIC farm or working some unheard-of cryptocoin with a low mining difficulty.

I ran 16 GPUs on Bitcoin for 18-24 months when it made sense to do so. I pool hopped to game rewards and had failover bitcoind solo nodes for when pools got DDoS'd. There was a time when it made sense, but ultimately GPUs got priced out.

The people who are chasing this dream are quite literally 6 or 7 years late to the profit margin vs. electrical efficiency equation in terms of Bitcoin and maybe 18 months too late for Monero. That's the evolution of all POW mining, electrical efficiency.

</comment></comment><comment><USER13> These guys also do other "internet measurement". You can find more here [https://netray.io/](https://netray.io/)

</comment><comment><USER14> Could someone with an arXiv account let the authors know that they currently have their emails listed as "{firstname.lastname@example.com"?

<comment><USER15> That's on purpose, to avoid repeating the domain of the email for each author at the same institution.

<comment><USER14> Oh, I should have realized that.

</comment></comment></comment><comment><USER16> im shopping around for ideas to implement with browsercoin.com and reading this gives me some interesting perspectives.

first im not interested in Proof-of-Work or usage of blockchain at all...sort of like with what CoinHive and other browser based JS miners do...once you realize these mining activity really is just to add a level of authenticity and verification to a transaction with the ultimate goal of having a completely auditable trail going back to the genesis block. This exact property can be built using Datomic where I can achieve more or less an unalterable auditable logo of all transaction made to the database even deletes without worrying about any of the mining rewards centralized by pools that essentially dwarf and skew the wealth. The only difference being that Datomic runs on some seriously secure corporate infrastructure, the miners being Google, Amazon, Microsoft, Oracle, Fujitsu, Samsung all regulated and still answering to the civic organs of democratic economies instead of unknown nodes with opaque interests without regulation which makes it ripe for disinformation.

what if instead of running some number crunching, you were incentivized to consume a content, use an app? What if then you could use some of those credits earned to distribute to content creators that you really like (sorta like patreon but you "mine/get rewarded" when you complete a task). I see that BAT of Brave Browser tries to do this but is anybody really using Brave instead of their go-to browser....I doubt it....

I had this idea for the longest time of implementing something like this but with instantly verifiable and creditable tasks. _Proof-of-Achievement_ I coined it. But once I realize I'm not building an ICO or cryptofoolery but a grassroots marketplace for task you can do in your browser.

Some scenarios:

Say you want users for your SaaS web app --> boom you got an audience.

Sa you want to get paid for your SaaS/Content/Video/Music --> boom the audience that has "BrowserCoins" can pitch in to support your cause.

The main selling point being that for the miners the reward is immediate, there will be some clever verification methods, but essentially when you complete a task you "mine/rewarded" 10ßC....there came up with a currency symbol on the spot.

Miner (running a browser extension):

        1. "hmm...create a profile on somebody's Tinder clone app"

        2. *several minutes later*

        3. "okay verified email, browser extension says successful"

        4. *you receive* 10ßC for a job well done from hnaddict393

hnaddict393 (created the job originally):

        1. miner#001 has complete your job titled "awesome dating app needs some love"

        2. verifier#091 is checking the quality of your job.

        3. verifier#092 is checking the quality of your job.

        5. verifier#091 has finished and has approved result.

        6. your job has been completed and 10ßC was removed from your account.

verifier#091 (you mine ßCs by verifying the output of a job):

        1. verifier#091 has started a verification task.

        2. verifier#092 has started a verification task.

        3. verifier#093 has started a verification task.

        4. verifier#093 has rejected output-reason: "profile looks fake"

        5. verifier#092 has accepted output. awaiting your verification.

        6. verifier#091 has accepted output. thank you, your verification pool has been credited 2ßC for reaching a consensus within the acceptable time outlined in EULA.

        7. verification task has reached a consensus: SUCCESS (2/3)

anyways kinda rambled on there but was just thinking of a proof of concept of some sort based on replacing a PoW with a more meaningful work output.

<comment><USER17> To coin the classic HN approach, isn't this just Mechanical Turk + a bank account?

Being less reductionist, you could possibly bootstrap the chicken/egg issue of getting task executors / task creators by proxying tasks off Mechanical Turk.

<comment><USER16> > mechanical turk + a bank account?

yup. basically _near_ insta-verified rewards and verification. The issue mentioned below of someone botting can be solved by having "oracles" or trusted advisors with a score to maintain.

> Being less reductionist, you could possibly bootstrap the chicken/egg issue > of getting task executors / task creators by proxying tasks off Mechanical > Turk.

not sure what you mean by proxy</comment></comment></comment>


This is the way the World may look like 50 million years from now - <AUTHOR> http://www.scotese.com/future.htm <comment><USER2> Looks wrong--last I heard, there's an ocean opening through Ethiopia and the Red Sea.</comment>


The Janitor Programmer - <AUTHOR> http://www.janitorprogrammer.com/

<comment><USER2> Here's a trick I discovered for working with bad code that used to help me a lot: treat it as an archaeological dig. Complicated bad programs usually evolve out of simpler bad programs, often in a semi-consistent way - inconsistent enough to be a maintenance nightmare, but consistent enough for a human reader to grok the patterns. If you can read the code backwards in this way and find the remains of the original simpler system, you then have a model for understanding the whole system: it's the crappy simple original one plus the crappy ways it was extended.

For example, complex bad systems are often extended by means of duplication (C-c-C-v-driven development). It's often possible, when you have a number of duplicated sections, to figure out which was the master and which the copies - e.g. if there were any comments in the original code, people will just leave them in the duplicated code. (The sort of programmer who reads and updates comments probably doesn't program by C-c-C-v in the first place.)

This brings up another point about bad code. Naive bad code is a lot easier to understand than sophisticated bad code. It's bloated and buggy, but there's always a sort of internal order to it. Bad programmers are able to maintain it by remembering the 10 places that X is done and the 19 places that Y is done. Sophisticated bad code, on the other hand - the kind full of impenetrable pseudo-abstraction - is a different can of worms. I don't think the above techniques apply to it. However, naive bad code is more common.

<comment><USER3> _(C-c-C-v-driven development)_

I like to refer to this kind of programming as the successor to spaghetti code: _copypasta_.

</comment></comment><comment><USER4> I want to cry. I found his example of code he needs to janitor to be positively blissful compared to what I often wade through. "When will the hurting stop?"

</comment><comment><USER5> What problems do people see in this code? The hard-coding of the sql statements that differ by only by table name? The code repetition of the while loops? Something else? Just interested in seeing if my understanding and analysis of it agrees with what others think.

Edit: One more - the "select *" when only the "name" is used?

<comment><USER6> I see...

no variables defined before use (optional). Pet hate: VB fakehungarian names where objects are called oSomething.

In the oRS.open line, the "2, 2" are magic numbers - I have no idea what they do without looking them up. (Turns out they are CursorType adOpenDynamic and LockType adLockPessimistic). Since they aren't the defaults, presumably they are necessary, but from the snippet given the defaults might be OK.

The presence of database tables Members and Members2 with (in this snippet) no difference between them. If you don't need two, merge them. If you need two, name them more helpfully. If the data will only be in one or the other, could you use a union query? Why might the data be in one or the other and why not use that information directly to decide which to query instead of querying both? What if there are no names in either table?

As you say, selecting * but only using one field, and the repetition within the if branches.

Unhelpfully named array "myarr"

Redimensioning of the array every time through the loop.

But most importantly, all the body of the code does is take the names from the recordset and put them in an array. I expect (hope) there is a shorter, more efficient, more idiomatic way to copy a recordset into an array.

See other HN topic about the fun, easy and addictive nature of criticism. I shouldn't really - at least they have a product with members and money to employ people to code for them and enough success that their code stayed around long enough to become old and maintainable... and there's plenty of people who'll argue that make it work, ship it, then if necessary rewrite it is much prefereable to make it beautiful, perfect it, tweak it, file for bankruptcy.

</comment></comment><comment><USER7> Sorry the example isn't ugly enough for you guys, but I had to pick something reasonably generic. Sounds like we've all seen a lot worse, but most of the really bad stuff I've seen could be easily identified as proprietary. That particular type of snippet was taken from a system that had a sick amount of duplication and some really "creative" use of arrays for sorting that took forever, when the sort could have simply been done with SQL in a fraction of the time.

</comment><comment><USER8> [http://www.amazon.com/Working-Effectively-Legacy-Robert- Mart...](http://www.amazon.com/Working-Effectively-Legacy-Robert- Martin/dp/0131177052/)

</comment><comment><USER9> Bookmarked.

When you're not flying high on a startup, this kind of stuff pays the bills.</comment>


Show HN: vue-speedometer – Vue component for showing speedometer like gauge - <AUTHOR> https://github.com/palerdot/vue-speedometer <comment><AUTHOR> Hi All,

`vue-speedometer` is a Vue component library for showing speedometer like gauge using d3.

You can see it in action here - [https://palerdot.in/vue- speedometer](https://palerdot.in/vue-speedometer). source code - [https://github.com/palerdot/vue-speedometer](https://github.com/palerdot/vue- speedometer)

As an aside, it shares its core with `react-d3-speedometer`([https://github.com/palerdot/react-d3-speedometer](https://github.com/palerdot/react-d3-speedometer)) which was recently rewritten by modularizing its core.

If you have a need for a similar component in your Vue apps please let me know on what you think. Feedbacks appreciated.</comment>


The 'Future Book' Is Here, but It's Not What We Expected (2018) - <AUTHOR> https://www.wired.com/story/future-book-is-here-but-not-what-we-expected/ <comment><USER2> That was a good read.

I wrote 10 books for conventional publishers (Springer-Verlag, McGraw Hill, Morgan Kaufman, J Riley) but burned out on writing. What made writing new and fresh for me was a few years later starting to self publish. I sell far fewer books but I find it much more satisfying writing exactly what I want, not what publishers' market research dictates.

I stopped publishing physical books, via the excellent Lulu service, because a physical book freezes what I can do with the content. I use leanpub now to publish eBooks and I can effortlessly fix small errors, add examples, and sometimes declare a new edition by adding material and removing out of date material. The platform lets readers get the updates for free. I also started releasing my eBooks with a Creative Commons share with no modifications or commercial reuse license - I encourage readers to share my books with their friends.

The author of this article makes a good case for using an email newsletter. I generally only spend about two hours a day writing and I am not sure if I want to spend some of that time on a newsletter.

<comment><USER3> Ha! Your story fits neatly within the self-determination theory of motivation [1]. You clearly tweaked your autonomy to be higher.

I'm a big fan of the theory, but I almost never see clear cut examples like this in the wild.

[1] [https://en.wikipedia.org/wiki/Self- determination_theory](https://en.wikipedia.org/wiki/Self-determination_theory)

<comment><USER4> Huh, nice observation! I usually shrug at that sort of theory because the terms are too fuzzy to put to a test, but this is a very nice example of the idea.

</comment></comment></comment><comment><USER5> Yeah, we have those "future books". They're called webpages.

As for actual books (ebooks or physical), they have their own unique advantages and use cases compared to something with animations, superfluous effects, link jumping, and so on which sounds like a children's pop-up book and less something for focused study.

<comment><USER6> Reminds me of Matthew Butterick's article on why he didn't make an ebook version of Practical Typography. [https://practicaltypography.com/why-theres- no-e-book-or-pdf....](https://practicaltypography.com/why-theres-no-e-book-or- pdf.html)

<comment><USER7> I appreciate someone taking a principled stand with regard to closed ecosystems / file formats. It's weird that the future turned out this way...

</comment></comment></comment><comment><USER8> I find myself frustrated by a different way in which the "Future Book" is slow to arrive - specifically, the glacial pace that e-Ink displays are improving. I bought each generation and found them better and better, and yet... every generation seems further apart and slower and slower to finally close in on the ideal: black ink on a white, non-glowing background.

The. Background. Is. Still. Gray. Dammit!

So frustrating - I'm an enthusiast for these (for travel). I love owning physical books, but would happily cull all but my top books (you know, 60-80 linear meters of shelf space) and keep a lot of things on e-books. But only if e-Ink displays can finally get to a white background!

<comment><USER9> I'm still waiting for decent note-taking. I like marginalia in physical books. I own the latest paperwhite, which is supposed to have the best note-taking capabilities, and typing is excruciatingly slow.

<comment><USER8> There were a couple things on the market that were claiming this (the ReMarkable and one other new one) as a feature. To me the note-taking would be pretty good also, but the fact that it's black-on-gray is the full-on deal- breaker (or at least, I already have a latest-gen display in the current shade of gray and until it improves, I'm not getting another one, even if it's bigger or good for note taking).

</comment></comment></comment><comment><USER10> I'm reaching the conclusion that thinking the future of the book would be a different _product_ is hugely flawed. Books, or reasonably static electronic equivalents -- PDFs and ePubs -- suit the process of immersive long-form content assimilation. Spastic UI/UX does not.

But as with quipu, cuneiform, papyrus, the codex, moveable type, and its manifold enhancements over the past two centuries (the preceding 350 years saw virtually none to the press itself, though book-form itself advanced markedly), the biggest differences have come in the process of creating, publishing, duplicating, archiving, and propagating texts. Not, for the most part, accessing them.

Starting about 1880, a number of changes to text development and distribution began, with typewritten "manuscripts", loose-leaf bindings (enabling updating of already-published texts), databases, digital text storage, digital typesetting (roff and kin, early 1970s), version control systems, online and hypertext systems, wikis, and distributed version control.

(We might push that back slightly further as well to Carl Linnaeus and index cards.)

The ability of many people to collaborate, _or compete_ , in developing a collective narrative, with instantaneous typeset updates is truly novel. It's also to a large degree independent of and agnostic to end-point consumption -- desktop, laptop, mobile, TTS, and hardcopy are all reasonably equivalent from the perspective of the txt.

(Text discovery, recommendation, and popularity are another matter, McLuhan's observations re: medium are relevant.)

We should pay far more attention to _process_ rather than _product_.

</comment><comment> 52-6F-62 I really like the article, but I have a different point of view when it comes to the ideal "future book".

They seem to carry on the assumption that a book didn't already exist in an ideal format. I'd posit that what we've learned is too many features is actually a bug.

Reading can be a silent, remote activity that coerces you into reflection without the distraction of immediately commenting and joining a community to battle out barely-set thoughts.

A younger me might have said "well a future book according to this person is a web page—capable of almost anything". Now, however, I think a plain transmission in static form (whether read or dictated) is an ideal form unto itself.

Such a static transmission must be worked on, edited, scrutinized. If it isn't, it won't be well-regarded and it can't just go away.

I really like having my collection of paper books. I also really like my Kindle (and I'm so glad there's no community or comment option).

Just to stamp some book-nerd credentials on the end of this—I'm currently working on software in publishing, took a "Book History" course at U of T (Why?), and I'm rarely gifted things, but my sister bought me a first edition of 1984 for a birthday and for some reason my girlfriend decided to buy me an old box set of Azimov's Foundation series (well, the first three) just last week. So there!

<comment><USER11> >They seem to carry on the assumption that a book didn't already exist in an ideal format.

I think you are in very good company with that opinion.

>"Books are sharks... because sharks have been around for a very long time. There were sharks before there were dinosaurs, and the reason sharks are still in the ocean is that nothing is better at being a shark than a shark."

\- Douglas Adams.

<comment> 52-6F-62 Brilliant! Thank you. I knew I loved Douglas Adams.

</comment></comment></comment><comment><USER12> A book is (generally) an idea expressed in long written form. It doesn't matter if it's goat skin or e-ink. The medium is pretty much irrelevant. This is why the form hasn't changed in thousands of years and why we don't need interactive features in books.

There are exceptions to this such as recipes books, but these are collections of somewhat unrelated smaller pieces of content which actually work better in other forms such a blog, wiki, etc.

<comment><USER13> One way in which the medium matters is the duration of an average reading session. After installing kindle on my phone, I found myself enjoying reading in very short sessions, e.g. while queueing for coffee. This different interaction with a book makes me choose books with shorter sections on my phone, than I would on the Kindle device I use before bed. In particular, I found some textbooks with short sections to be excellent for this kind of short reading.

<comment><USER12> Not sure if it's really the medium instead of the situation. You could also use your kindle, tablet, or paper book while queueing for coffee.

</comment></comment></comment><comment><USER14> As Summer is arriving, if you haven't chosen a fun science fiction book yet and are interested in the subject of this article, you may enjoy Neal Stephenson's book, "The Diamond Age". A tablet-like "book" plays a central role in the story.

<comment><USER15> Not to mention printing on paper is a terrible idea in 2019.

<comment><USER16> Why? trees are renewable and our eyes need a break from screens

<comment><USER17> Trees may be renewable but the arable land belongs to the forest.

<comment><USER18> In the US, there are more trees now than 100 years ago. I believe the law is for companies that cut trees for products, to plant two for every one they cut down.

Now there are problems in the rest of the world with deforestation, and hopefully we can fix that.

<comment><USER17> The negative impact of pulping isn't limited to just deforestation and loss of uncommercialized land. I think wikipedia does a fine job to explain the impact:

[https://en.wikipedia.org/wiki/Environmental_impact_of_paper](https://en.wikipedia.org/wiki/Environmental_impact_of_paper)

</comment></comment></comment></comment></comment></comment><comment><USER19> That was refreshingly good.

I'm in the testing phase of an interactive kids' "future book" series. If you're into this kind of thing / have kids, would love to hear thoughts.

Pilot episode is live at [https://www.featherbubble.com](https://www.featherbubble.com).

<comment><USER20> That's really cool. Nicely done. I couldn't find anything in the bear's fur though.

<comment><USER19> Thanks... what device? (the thing should be in the upper right quadrant of screen...)

<comment><USER20> On a macbook. Ah, I found it

</comment></comment></comment></comment><comment><USER21> IMO we will see the biggest change in how books are written after copyright abolition. We sort of kind of do already, with the big titles like Harry Potter, Star Wars (I know, it started out as a movie) etc. We have the canonical, original books, but we also have a lot of fan-made titles. Some of them create a specific narrative based on the original work, i.e. Harry Potter and the Medhods of Rationality[1], and then people create other fanfiction based on that. 99% of it is fourteen-year-old girls with no writing skills, but there are nuggets that could make great money if not for copyright. I think living, breathing universes made by fans, possibly coupled with chapters released as they're being written, fan voting etc. is the future. Even post copyright, it could make authors money, think crowdfunding or "Character x will either murder y or have sex with y, depending on what option gets more money".

[1] hpmor.com [2] se [1] or [https://www.fanfiction.net/s/12461030/1/The- Tinkerer](https://www.fanfiction.net/s/12461030/1/The-Tinkerer)

</comment><comment><USER22> "email has yet to be usurped by algorithms"

Unfortunately, that isn't true. Many people use apps like GMail for Email, which does filter with algorithms. And many people complain about their emails not getting through.

I find that worrying especially with sight on the social media bans of unwanted people. You'd think they could at least resort to email newsletters, but email is controlled by the same corporations that just banned them.

</comment><comment><USER23> Everything this article pines for is in modern video games. Story, interaction, jumps out at you (just add VR).

<comment><USER16> For Fiction I totally agree. Although I am a bit Luddite about paper, I like the break from screen time

<comment><USER24> I'm sure there are some non-fiction mods for various games out there...

Though interactivity is more straight forward in fiction because if you can freely modify the virtual world around you it rapidly becomes fiction.</comment></comment></comment>


Get inc., legal, accounting, taxes easily done for your startup in one place - <AUTHOR> https://launch.gust.com/start/ <comment><USER2> This looks pretty interesting, especially for the first year or two of a startup's life.

<comment><USER3> Thanks! We specifically designed it to remove the barriers and costs that come with starting up, especially for first-time founders who may not be aware of all the bases they have to cover.

</comment></comment><comment><USER4> How's this any different than Stripe's Atlas?

<comment><AUTHOR> Cap table management

<comment><AUTHOR> And more inclusive... anyone can sign up now

</comment></comment></comment><comment><USER5> Why a subscription model?

<comment><USER3> Good question! Most of the tools and services included are ongoing, rather than one-time. We designed Gust Launch to support your startup through its entire lifetime, and many of the things you need (like legal advice, bookkeeping, tax prep, and cap table management) are ongoing for that reason. Aside from the incorporation, basically everything else included in the product is subscription-modeled by other businesses that solely offer that one piece of the product.</comment></comment>


"I don't want to give out my phone number" – A gendered security issue - <AUTHOR> https://jilliancyork.com/2017/08/03/i-dont-want-to-give-out-my-phone-number-a-gendered-security-issue/ <comment><USER2> A bit sexist and paranoid. Tl;dr: Men will harass and call women who give them their phone number, so women shouldn't do it.</comment>


Introducing Knockout, a UI library for JavaScript - <AUTHOR> http://blog.stevensanderson.com/2010/07/05/introducing-knockout-a-ui-library-for-javascript/ <comment><USER2> home page: <http://knockoutjs.com/>

would be interesting to compare with backbone, which has facilities for automatically updating views: <http://documentcloud.github.com/backbone/>

flapjax was one of the originals- porting functional reactive programming to javascript, but has never caught on in a strong way. <http://www.flapjax- lang.org/>

<comment><AUTHOR> Backbone looks amazing - plan to deploy with it soon. The idea of creating a model with properties and bind events to that means that if a variable changes, all elements referring to the model are updated automatically. And if that isn't good enough, it supports persistence back to the server, making for interesting possibilities both with having data on the client side, but also supporting exact state reproduction when someone logs back in from an earlier session. Intriguing.

<comment><AUTHOR> This is great, Backbone supports undo! You can simply use the .previous(attributes) function :)

</comment></comment></comment><comment><USER3> Looks pretty good. In short, (if I understand this well) it solves the problem of updating a value in an ajax app and then having to update lots of separate different parts on the screen in js, which can get messy. They seem to be inspired by Silverlight's approach.

<comment><USER4> The Silverlight perspective is probably right since Steve is a long-time .NET developer who recently took a job at Microsoft.

<comment><USER5> They all just copied from the Flex framework anyway. (Seriously that's been so far ahead of the JS libraries for a long time. I'm happy Knockout exists so I can use it!)

<comment><USER6> Do you mean mx:Binding? I dislike mx:Binding as it has been buggy for us (property value updated but UI does not update). I've resorted to avoiding it and using EventDispatcher to notify views to update themselves.

In general, I think it is way too difficult to fetch data async from a server and update the Flex UI. LiveCycle Data Services is more about push than real- life async use cases.

<comment><USER5> Yeah, there's a few gotchas to watch for with binding that depend on the datatype. Flex 4 has only improved things, though it did take a bit to adjust. I really like the {syntax} though, and apart from the binding issues with XML I really like working with it in Flex but hate it in JS. Flex makes the XML vs. JSON distinctions almost go away for me.

(tldr: yeah, async stuff in Flex can sometimes be really verbose.) I don't find the async stuff too bad, though it all can horribly be abused. The project I inherited used Cairngorm with SOAP services and had a separate Event, Command, and Delegate class for every web service! Some generalizations have made that into only one Command class per web service that's just responsible for handling the specifics, though I also have a general Command class that will offload the response to a callback function the requester can provide. I always liked Ext's (er, Sencha's...) Ext.Ajax.request() and jQuery's offering.

<comment><USER6> Yes, our project was bootstrapped initially by a bunch of Cairngorm loving consultants. I doubt we will move to Flex 4 as we have common company library SWCs that would have to move to Flex 4.

</comment></comment></comment></comment></comment></comment><comment><USER7> Dojo Toolkit offers similar declarative data binding functionality, FWIW. You can use most of Dojo (particularly the Dijit UI library) declaratively if you want to.

</comment><comment><USER8> Steve spoke with Scott Hanselman recently on his podcast show about Knockout: <http://www.hanselminutes.com/default.aspx?showID=262>

</comment><comment><USER9> OFF: Is there any language or framework that uses heavily this "observable variables" paradigm, for example for data processing? (except s4.io)

</comment><comment><USER10> I had to Google "Knockout JS" to find a link, then I found out the OP was referencing the same thing. Seems cheap to call it just a UI library.</comment>


What Is the PCI of Bank Payments? - <AUTHOR> https://www.moderntreasury.com/journal/what-is-the-pci-of-bank-payments <comment><USER2> This article recommends using SOC2 compliant vendors. I wouldn't put faith an a SOC2 certificate. A vendor who's infrastructure consists of almost entirely of hardware and software that's been EoL for years (and wasn't up-to-date before support expired) can pass SOC2, so long as they show that their firewall does NAT for security.

Okay, I'm being somewhat hyperbolic, NAT for security is not the only box a company has to tick to get a SOC2 cert. But I'm being less hyperbolic about long-EoL kit passing SOC2 audits. IMO, a vendor running unsupport(-ed|-able) kit should be an immediate disqualifier.

<comment><USER3> As someone who has performed SOC2 compliance reviews, these are not small tasks. I've performed them on companies that manage core banking systems for other banks and credit unions.

Currently, across quite a lot of critical infrastructure there are legacy systems which are EoL. However, there are aspects or layers to the software which are not, or are protected by higher layers of security.

If your vendors ENTIRE environment is almost EoL software and hardware then yes that is highly concerning and would make it very difficult for them to demonstrate appropriate security controls. However, the reality is that most of the environments I have assessed have only a small portion of their software/hardware environment that is EoL. That is often protected by significant layers of security above that.

<comment><USER4> Out of curiosity, when you're doing a SOC2 compliance review, are your relying on their documentation of security measures, or would you check to see that the documentation matches the security measures that are in place?

<comment><USER3> Documentation of security controls means very little, yes having a framework with a suite of policies and procedures is important. But a proper SOC 2 review is all about actually seeing it in place.

We do a deep dive, where we understand all of the security controls, we then test the design of these security controls through reviewing security configurations within the systems themselves. Then testing the effectiveness of these controls.

So yes, we review documentation and then perform an independent review of the security measures/controls in place. For instance, understanding how batch processes are configured, then testing that the appropriate security controls in relation to batch processes operated effectively.

</comment></comment></comment></comment><comment><USER5> _> The security risk to bank account details is regionally specific. In Europe, IBAN and BIC numbers are readily given out. One reason why is that they are only used in the credit direction._

That's not true, IBANs can be used for direct debit between supporting banks. That's most commonly used for repeat invoices but some shops also support it as payment option for one-time purchases, although instant payments are taking over the latter use-case.

<comment><USER6> Do IBANs allow debit without reliable authorization? In the US having a bank account number (and I suppose maybe a name/street address for more plausibility) is enough to print a check and then withdraw money from it. Do IBANs let a random person do that, or do they need verification from the account?

<comment><USER7> They do, but direct debit is only allowed to "large" companies that move a lot of money in my experience. Usually you have to consent to allow direct debit, sometimes in the paper form, sometimes just by entering your account number. My startup tried to add direct debit via Stripe but our bank didn't allows us to do because we don't move a lot of money through our banks accounts also we're not known. I think a lot of financial things in Europe are based on trust.

<comment><USER8> Are you sure you aren't confusing a bank transfer with direct debit? DD in the US requires PAD/PAP between the debtor and the collector and is cleared through ACH regardless of the size of the account or the sum.

<comment><USER9> No, what GP is saying absolutely is a thing, but not terribly common. Bosch PT Service is one of not that many companies that use it. You only give them your IBAN and check a box basically saying you authorize them to debit the money from your account.

<comment><USER8> That's how Direct Debit works all over the world, that tick is the PAD/PAP contract being signed you basically pre-approve debit requests with it.

</comment></comment></comment></comment></comment></comment><comment><USER10> Quarterly vuln scans don't really make the cut in the modern world. Take CVE-2020-1350 (MS DNS vuln) as an example - it took about 48 hrs from publicizing the vuln to a working exploit to appear on Github.

If you scan per quarter, and it takes you n days or weeks (or months) to fix the critical stuff, it's quite a window of exposure - per each vuln. Any midsize org will carry hundreds or thousands. Enterprises much more.

<comment><USER11> Obligatory:

[https://www.rsync.net/resources/regulatory/pci.html](https://www.rsync.net/resources/regulatory/pci.html)

<comment><USER12> PCI compliance helps a little.

When I was doing IOT power/temperature monitoring sometimes companies wanted us to show PCI compliance before attaching our hardware to their networks. (we weren't) which meant we had to explain to them to put us on a separate network, without credit card processing devices.

<comment><USER13> PCI compliance is extremely easy if you don't handle PANs. Provide a SAQ that says "we don't handle PANs" and you're compliant.

<comment><USER14> Caveat if you are small business. Otherwise, with lots of charges it costs about $100k+ annually in validation, not including labor effort. A startup can hit this quickly, but only under certain circumstances.

<comment><USER15> If you're a startup and you need PCI DSS compliance, please contact me - mahmoud [@] verygoodsecurity.com and I'd love to help!

</comment></comment></comment></comment></comment></comment><comment><USER16> The point about subjecting your external vendor to the technical audit of their security services as well is a good one.

</comment><comment><USER17> Audits and compliance only take you so far. If your actual motivations are to truly improve security, perhaps offering code samples, libraries and reference architectures would be more helpful. Throwing compliance requirements at a technical team is an excellent way to distract them away from a truly secure architecture.

That said, there are a lot of actors out there who need babysitting and absolutely should not be allowed to participate in payment networks without some sort of initial & ongoing due diligence.

This whole thing is a delicate balancing act, but in my experience dealing with PCI-DSS, its currently an extremely heavy-handed approach. I cannot help but wonder if the primary intent of this sort of standard isn't to just keep competitors out.

</comment><comment><USER18> Ad for Modern Treasury.

</comment><comment><USER19> The NACHA response is missing the forest for the trees. Securing the account data is great, but it's only a small piece of the puzzle.

It doesn't: a) penalize ACH Originators responsible for submitting the fraudulent entry (beyond the recently implemented $4.50 charge) b) do anything to promote alternative account numbers for EFTs, which in theory could be better protected as they won't be on paper checks c) promote better validation tools to prevent the likes of Plaid and entities using their APIs from harvesting broad amounts of private consumer financial data

</comment><comment><USER20> How about two-factor authentication as a baseline recommendation for online ACH? Even the infamously recently discussed SMS authentication.

<comment><USER21> ACH is a ca 24 hour duration batch process that does not include authentication. 2fa isn't even really a possibility with the ACH system.</comment></comment>


Show HN: Ultra-low overhead logging for Java - <AUTHOR> https://github.com/obsidiandynamics/zerolog <comment><USER2> Not benchmarking against log4j 2 is odd as it implements low latency asynchronous logging.

<comment><USER3> It explains where the speed gains were achieved and I don't think log4j2 really solves that.</comment></comment>