russelldavis

Stripe returns HTTP 402 ("Payment Required") when a card is declined.

The same logic can apply to flop donk bets. Some flops favor the donking player's range more than their opponent.

This idea is baked into the core of Deno. See, for example, https://deno.land/manual.html#permissionswhitelist.

This approach comes pretty close to solving the problem, but a couple issues are dealbreakers for me:

1) It mutes all notifications, not just non-whitelisted calls. As much as I hate notification overload, I do want a select few to come through.

2) I want a discoverable way for non-whitelisted callers to be able to break through (not everyone will know to call multiple times to break through).

I'm working on an app that addresses those -- email me if you're interested (see my profile).

Amen. The existing spam call blockers are all based on blacklists, and it's a losing battle against spammers who can simply keep spoofing new numbers.

I'm working on an app (iphone & android) that solves this the way you suggest, via a whitelist of contacts, with an optional way for non-whitelisted, non-robocallers to still get through.

If you're interested in early access, email me at russell.davis [at] gmail [dot] [com].

Has anyone used both Ktor and Javalin and have any advice for choosing between the two?

Scrolling on chrome (via the keyboard) has become incredibly slow and janky. One example: log in to twitter, click any tweet, then click outside the lightbox to return to the main page. Then hold the down arrow key. It's unusably slow (and choppy). This also happens on amazon and a bunch of other sites.

Firefox, on the other hand, has consistently fast & buttery smooth scrolling.

I'm surprised this doesn't get called out more.

Another thorough review of water filters: http://thesweethome.com/reviews/best-water-filter-pitcher/

The branch equivalent is `git checkout foo --`. I wrote a simple shell script[1] that makes that the default, requiring you to do `-- <file>` for files, so there's never a possibility of ambiguity.

[1] https://gist.github.com/russelldavis/e5173ce1269fae67baaf

won't give you cancer.

Untrue. "Smokeless tobacco is a major cause of oral cancer, pancreatic cancer, and esophageal cancer."

http://www.webmd.com/smoking-cessation/features/snus-tobacco...

No need to clutter your code with a bunch of try wrappers like this suggests. There's a much better way. It turns out that in a typical web app, a handful of operations account for the vast majority of new execution contexts:

  - setTimeout/setInterval
  - event handlers
  - ajax response handlers

Personally, I'd prefer a world with suppressed donations over one with suppressed accurate objections. Or, you know, we could work towards a world where we have neither.

X-chromosome inactivation is actually consistent with X-linked "recessive" conditions, but it's a little tricky, and the wikipedia page doesn't really explain it. Basically, X-linked phenotypes aren't dominant/recessive in the same way as the others. Usually, dominance takes place between chromosome pairs within each cell. However, with X-chromosome inactivation, dominance takes place between cells. For example, women who are labeled "carriers" for colorblindness actually are colorblind in half of the cells in their eyes, but the other half are sufficient to perceive color almost as well as non-carriers.

For a similar library with a slightly different take, check out plumbum:

http://plumbum.readthedocs.org/en/latest/index.html

Here's the explanation on the differences:

"The project has been inspired by PBS of Andrew Moffat, and has borrowed some of his ideas (namely treating programs like functions and the nice trick for importing commands). However, I felt there was too much magic going on in PBS, and that the syntax wasn’t what I had in mind when I came to write shell-like programs. I contacted Andrew about these issues, but he wanted to keep PBS this way. Other than that, the two libraries go in different directions, where Plumbum attempts to provide a more wholesome approach."

There's no consensus that "reducing the damage done by some security holes" is a good thing? Bernstein mentions it as a distraction (which may be true), but it's better than doing nothing.