chavesn

Right, and how would you further verify “the person paying for your subscription”?

Genuine question, what would that flow look like?

> all of those cases very well justify a manual check, or some sort of extended identification before the user is let in.

Just curious, what would that check look like that's not open to the same vuln?

If oauth makes an authenticity claim, it should be true. Saying it's the same user when it's not is bad, clearly.

in other words: Google could make a more accurate authenticity claim than they currently do.

This problem would be worse without oauth, though, right? With plain email login, all they would need to do is "forgot password" and there wouldn't even be a way to tell.

in other words: Email login would never be able to make a more accurate authenticity claim.

> Failed startups don’t always shut down cleanly like that.

Agreed, and with the number of services and the "ease" of oauth it's likely impossible to even track. You could make a list of the major ones, but there could be hundreds per user, ultimately thousands of unique services used depending on the breadth of the startup's activities.

> NPM stood for "not my problem"

wait...

I think it's more like there's more surface area to forget when you have humans handling so many concerns, and it's not likely the part that's changed the most so it's a likely candidate for being "pushed out of the buffer" (of the human).

In a more typical model, backend devs focus more on security, while not needing to know the frontend, and vice versa.

It seems like that's the point of the story -- they were willing to tip well, and received bad service. If it came after, then drivers would have a reason to make sure food was delivered fast and efficiently.

obviously drivers would want to know it, but is that good for everyone involved? It would make more of an auction but should it even be an auction?

The ligatures are really interesting, but at a glance I process them so much slower than the raw characters, especially the ones that change the graphical semantics such as <= vs ≤. Does anyone have experience getting used to these and 1) does it end up faster? 2) once you are used to it is it harder than it was before to process the raw characters when reading code in fonts that don't have the same ligatures?

Those sans-serif spaces tho...

Keep the same amount of garbage, but make it minimalist garbage

Ok but I can't unsee that the first two say plus plus ("plus+") and the 3rd just says "plus"?

(Very cool project though)

"Hey, this looks like darkpatterns.org. ...oh, it is."

Yeah, but what about "zoom and enhance"? :)

Seriously, sure, 4K is enough for output but who says it's enough for input? As long as sensors keep getting better, the industry will keep finding ways to take advantage of it until it's essentially required.

Imagine a future where you can zoom in on any detail as well as you could with a high-res sensor at capture time?

It's not necessary for today's viewing experiences, but we know little enough about what is going to become popular that I wouldn't put ANY bets on "4K" being enough forever.

All of that statistical analysis was actually a bit silly, because I've never heard the "typo" argument as a reason for email grammar validation[1]. Sounds like a straw man. It didn't need to be disproven.

The conclusion is sound (although leaves out a discussion of the whether an email confirmation field is at least better than nothing).

[1]: (As a side note, I think the most common explanations for grammar validation are programmer perfectionism and proactively stopping user garbage, such as copy-paste errors or intentionally fluffed fields that will result in a bounced email anyway.)

It sounds to me like the point is that the market could be much larger if the transaction value were clear to consumers.

In the current app store, with the methods that consumers are used to spending money on their phones, for whatever reasons, it's not.

It's like when you'll easily spend $30 on drinks on a Friday night, but suffer a shitty note-taking system for years when you could have many of your problems fixed for $5 one time just because you don't know the possible transaction exists.

> To do well in an interview, then, you need to be able to solve small problems quickly, under duress, while explaining your thoughts clearly.

I certainly hope they aren't interviewing anybody under duress.

I agree with you that this is what the law seems to think (being overly broad), but not if you are arguing this is sensical.

In other words, yes, the WSJ does intend to only give Google access to their content, and not the general public.

But no, the WSJ has not "authorized" Google by anything more official than a bank telling their security guards to let anyone into the vault who is wearing a blue t-shirt.

So yeah, I agree with you, there is a lot of conflation of technical means and the law, but we also shouldn't be granting to the WSJ that they are doing any real "authorizing" here, beyond wishing it and hoping it stays true.

Where did this title come from? Not only is it not the title of the post in question, but it's quite inaccurate -- the article doesn't even come close to claiming that anything "almost killed" the doodle.

With that said, I clicked the click-bait title, and I enjoyed the article. (shrug.)

> "I wonder if all I’ve done here is to describe why introverts frequently describe being social as tiring. Extroverts have no problem with any of this"

This is good, but he loses me with this line at the end.

Extraversion is defined as "being predominantly concerned with obtaining gratification from what is outside the self."[1] Someone can have high social need without high social skill.

[1]: https://en.wikipedia.org/wiki/Extraversion_and_introversion

https://en.wikipedia.org/wiki/Digital_camouflage ?

"Thank you, but please realize that your response is zero percent correct, thanks."

94/100

I used this to check the text messages from Key and Peele's "Text Message Confusion" skit[1]:

Keegan: "I've been trying to reach out to you all day, are we on for tonight?" Polite (71 / 100)

Jordan: "Sorry dude, missed your texts. I assumed we'd meet at the bar. Whatever, I don't care." Polite (71 / 100)

Keegan: "Do you even want to hang out?" Impolite (30 / 100)

Jordan: "Like I said, whatever." Neutral (47 / 100)

Keegan: "Jesus, you are fucking priceless" Impolite (30 / 100)

Jordan: "You're the one who's fucking priceless!" Impolite (6 / 100)

Keegan: "You wanna go right now?" Impolite (31 / 100)

Jordan: "Ok let's go" Polite (76 / 100)[2]

Keegan: "You wanna really do this now?" Impolite (13 / 100)

Jordan: "Fuck yeah, let's do it" Impolite (19 / 100)

Jordan: "First round's mine" Neutral (43 / 100)

[1]: https://www.youtube.com/watch?v=naleynXS7yo

[2]: Adding a "." to the end of the "Ok let's go" drops it by three points to 73 / 100

This is great advice. The thing many businesses probably fail to realize is that, generally speaking, where [A] is the baseline customer base, the audience with Groupon is not "[A] with some subset of [A] paying cheaper prices" but instead, "[A] + [B], where [B] is an audience they never would have found."

To increase your audience, you almost always have to pay.

In contrast to big business, America especially likes to celebrate and idealize the small business owner as the one who truly knows the value of treating the customer right. But if these stories are frequent, it probably just exposes the sad truth that it's not as common, even in small business, as we like to believe or hope.

Indeed, some the most beneficial exchanges to observe are outright arguments.[1] When no one disagrees, no idea is truly tested.

This reminds me of pg's "What you can't say" essay[2]. We may be able to identify areas we are wrong by evaluating the topics on which we are most unlikely to allow dissent.

[1]: http://i.imgur.com/akfcNkJ.gif

[2]: http://www.paulgraham.com/say.html

Yesterday, when The Boring Front-end Developer was posted, the top commentary[1] seemed generally critical of the change-averse attitude. The TL;DR was "this is technology industry, new stuff is good. Get used to it."

Front-end code preprocessors, recent build systems and package managers, new-age frameworks (Angular), "Universal JS", and SPAs would all fit into this category.

Some tend to be skeptical, some are evangelists. There is a line in the sand, and while most developers don't fall clearly on either side, taken in aggregate, the line is visible.

I quite liked the BFED post. However, I submitted this because I think it makes persuasive counter-points.

Given the negative tone yesterday, I thought the crowd here might be more receptive to the more forward-thinking mindset. What's fascinating to me is that, even with nearly directly opposing viewpoints, the commentary on both HN discussion threads is actually quite critical.

[1]: https://news.ycombinator.com/item?id=9879172

I tried this, and the second random string I tried was the image in question:

http://imgur.com/52nu1

It took me a while to realize that they are talking about the number of birthdays listed on the page about March 27[1], not actually combed from all Wikipedia person pages, as I expected from the title.

To anyone who knows even a little about how Wikipedia is edited, this shouldn't be a mystery at all; there are no automatic pages or statistics, even for fixed entities like dates, and there is no automatic cross-referencing.

So as you'd expect, a person entered every birthday on that page, and there is absolutely no reason to assume that comparable detail has been given to all other days of the year.

(I'd hardly call this an easter egg, and I wish more people understood Wikipedia enough to make this entirely uninteresting.)

[1]: https://en.wikipedia.org/wiki/March_27

How common are remote radio controllers in historical or modern systems?

I think the most interesting part of this article is the use of radio for a wide-area network, even if it only got a passing mention in the article.

Some questions I'd love to know: What kind of protocol was used? Are computer uses of walkie-talkie radio bands allowed by the FCC? How do the receivers work? If they don't run on their own microprocessor, how were they designed?