Pewpewarrows

It's worth noting the quote the title is referencing, when examined with any level of scrutiny, is completely unfounded:

https://www.reddit.com/r/AskHistorians/comments/hd78tv/does_...

https://acoup.blog/2020/02/28/collections-the-fremen-mirage-...

Oh awesome, thanks!

Does a setting like this also work for the iPad app? That's typically what I watch Netflix on while falling asleep.

Forgive me if this is a dumb comment to make, as I'm just barely starting to get into monitoring and the statistics knowledge that goes along with it, but adaptive fault detection does tend to scare me a bit. In the event that a problem isn't a spike, and instead gradually builds up over hours/days/weeks, I wouldn't be confident in something picking a dynamic threshold for me. I'd be afraid of it deeming the ever-rising resource usage as normal behavior, if it happens slow enough, and me not being alerted before it's too late (servers becoming unresponsive).

What's the difference between them offering snap-on Glass over existing prescription glasses, and offering an existing Glass model with snap-in prescription lenses? You need to have one or the other, and in both cases it's an addition to normal glasses, not a replacement. Your requirement can never be satisfied for those with sub-par vision.

As for your main point: for this initial model, the main benefit it offers, that I hear from users time and time again, is the instant photo/video capability. Not having to dig your phone or camera out of your pocket / handbag is a huge win for a lot of people in the initial explorer program.

But that's not why I think the product will succeed. I can see the future potential of an always-on heads-up display, and that's just too useful to pass up. Will it ever get there? Maybe not, but I think it has a greater chance of that than failure.

Problem is…people who wear glasses can’t wear Google Glass.

Uhh, what? I was under the assumption, at least from all their marketing material and everything that I've heard about Glass from other people on the internet, that there are models that fit over your existing prescription glasses. No?

Fabric to bootstrap new Salt minions, and Salt for the actual deployment.

Starting before 21 legally != Starting before 21 illegally

You'd be surprised how much of a difference it makes when you remove the rebelliousness and allure of doing something illegally. You see this time and time again with parents sheltering their children from certain activities or harsh realities.

This is an awfully wrong approach. As with things like Alcohol, if you teach your children how to operate and act responsibly, they get into less trouble with it as an adult.

If you stilt their growth and don't allow them to touch a gun until they're 18, they won't have developed enough to handle it themselves without supervision.

The "killer features" all come from you using other Google products/services while signed-in to the same account that you use with Google Now.

Search for "pizza" or a specific address on your computer while signed-in to Google Maps? The next time you look at your phone it tells you how long it would take to get there, and offers you turn-by-turn directions, automatically.

Have a flight confirmation email sent to your signed-in Gmail account? You'll be notified on your phone if your flight gets delayed, how long the trip will be, and information about your destination. Same goes for package delivery confirmation emails.

And those really only scratch the surface. The more you use it, the more you come to rely on it, which makes you want to use Google-branded services more and more often. It's a brilliant move on their part.

And again, there's the belief that someone should have the legal right to perform an action, regardless of whether or not that action is reprehensible.

Ex: You should have the legal right to believe that all green-skinned humans are inferior to blue-skinned humans. But that belief makes you a jerk and I will judge you for it.

There's a difference between HN believing that businesses should legally be allowed to do all of the above, and HN believing that it's socially / morally wrong to do any of the above.

(Note that this is merely a reply to your comment in a vacuum, and shouldn't be construed as me supporting either "side" in this thread.)

It's impossible and immoral to have two projects with the same name. How dare they.

Completely unscientific, but if these outputs are any indication, this is going to be great news for Rubby users in the future...

  $ time ruby -e "puts 'hello world'"                                                                                                                           
  hello world

  real    0m0.184s
  user    0m0.079s
  sys     0m0.092s

  $ time ~/Downloads/topaz/bin/topaz -e "puts 'hello world'"                                                                                                    
  hello world

  real    0m0.007s
  user    0m0.002s
  sys     0m0.004s

Comparing conversion rates of a complete before and after revamp won't tell you anything about the effectiveness of individual components of the revamp. You'd need several A/B tests or a gradual series of changes to tell you whether labels inside or out actually made a difference overall.

That's only half of the argument. The other half being that, after having text in there (say, in the edit form of a CRUD app), your user no longer remembers what that field was supposed to represent to begin with.

We do something very similar, but like you said there are the occasional sneaky devils trying to download their own dependencies. Nine times out of ten it seems like it's some version of distribute that they insist on fetching.

The non-existant proxy trick seems useful, I'll have to try that out.

True, "learned" does sort of imply that it's a best practice now used by nearly everyone in the community. I know that's far from the truth. "Encountered" is more appropriate, so I'll edit my OP.

This should also be a reminder to everyone that you shouldn't be reliant on a single point of failure for your deploys. It's something that we in the Python community have already encountered (and hopefully learned from) due to the historical unreliability of our equivalent package repo, PyPI.

Have an internal repo that's accessible by your deploy servers, which in turn locally caches anything that you might have previously needed to externally fetch.

Obligatory link to the Sequelitis Mega Man UX video:

http://www.youtube.com/watch?v=8FpigqfcvlM&feature=playe...

The article hit the nail on the head: the best walkthrough is the one that it nearly invisible to the end-user, yet still accomplishes its goal of progressively introducing a UI to them in a long-lasting way.

As any gamer in the last 15 years will tell you: the Windows key is the bane of our existence. It's a classic case of know your audience and customer, because if you've ever played a video game on Windows and are now developing one, you know that you should be disabling that key.

You mentioned expected behavior, which is good to abide by. But there's also preventing accidents. Your users are imperfect. It's the reason big red buttons also get a follow-up confirmation dialog.

Now, I'd definitely like to have a conversation about whether there should be a setting for disabling that override. But as for the default: it's pretty straightforward. When playing a fullscreen video game, the number of accidental occurrences of that button press far outweigh the number of intended uses. Pick your battles.

Not looking to get into a whole thing here, but...

> he wouldn't have been able to if he didn't have easy access to firearms and a large cache of ammunition.

There's no possible way you can know that. Guns are certainly more accessible than, say, making a pipe bomb, but definitely less accessible than knives. Reference that story floating around the internet the past few days of some guy stabbing 22 kids in China. Not to mention the fact that you also have no knowledge of how capable he was of illegally obtaining the firearms and ammunition from other sources.

Hand-wavy terms are preferred if the text is end-user facing (and when end-users tend to not be too technical). Of course, a tooltip or "more details" link explaining the real technologies should then be used.

You can understand what sexism is while also acknowledging that there are extremists in every group. I can already picture a few such extremists calling this title sexist.

Sounds like the developers who wrote that code didn't know how to write comments. Here's some guidelines:

* Anything that duplicates the line they describe in prose should absolutely be removed. They're worthless and become out of date immediately.

* If you have logical "paragraphs" of code separated by newlines and comments summarizing the paragraph, that's a great indication that your parent method/function/whatever is in charge of doing too much. Turn the comments into names of new methods/functions and refactor accordingly.

* If the algorithm is sufficiently complicated, it definitely deserves a documentation block describing the "how"s and "what"s. But more often than not those comments are just a duplication, as specified in the first bullet point above. If you don't think any code ever deserves these sorts of comments: congratulations, you've never worked on anything non-trivial in your career. I suggest that you find more of a challenging project.

* Definitely leave a comment behind explaining the "why"s behind a particular block of code if its intentions are not immediately obvious.

* Definitely have headers of documenting comments for functions/classes/methods/parameters/etc. Is your first reply when someone asks "How do I learn to use Rails?" to say "Read the entire source code to Rails"? No, of course not. For the same reason, your reaction to "How do I use this block of code" should not be "Read the block of code." Abstractions and proper APIs people, come on. I should be able to glance at the docs above it along with the definition and know how to use it, what to pass to it, and what I might expect in terms of returns / side effects. Bonus points if you have a tool to auto-extract these into a static site that you host for your team.

There are plenty of things that you can leave out when writing parseable source code, but don't because it would make the code horribly un-readable.

That is, there's a reason for whitespace around operators, after commas, extraneous newlines, etc. It makes the code easier to read and maintain. Now while I'm willing to admit that this whole area is largely aesthetic and personal, if you submitted a line of code to me that was just this without the parentheses:

> 2 * 3 + 1

I would reject the code review in a heartbeat. Part of making your code readable to others and less error-prone during maintenance is adding extraneous stuff to it that isn't necessary for the code to parse/compile/interpret.

I agree. But in all code that I write, regardless of pretty much whatever language it's written in, I always explicitly add parentheses around what I want the order of operations to be.

"1 * 3 + 4 / 20 && foo" is unreadable. No one wants to memorize the order of operations for every language they use and have to figure it out in their head. Make life easier for the people who have to maintain that line of code you just wrote.

So let me get this straight. You didn't like Django because after not taking the time to learn it, you couldn't get it to do what you wanted. So you switched to a very lightweight model (webapp2), and loved the learning curve and flexibility. And then you tried out Rails (about as Django as you can get in terms of steep learning curve and having to contort to do non-traditional things) and loved it.

Nothing in that logic adds up. And for the record, I've yet to do a "traditional" web app in Django. Having taken the time to learn it inside and out I get all the benefits of flexibility that I would with something like Flask/webapp2, but retain the convention and mindshare for the rest of the project that does fit into common usecases.

Afaik, Disqus uses websockets with Nginx fine. I believe they recently mentioned writing and using this module: https://github.com/wandenberg/nginx-push-stream-module

At the core developer Q&A during DjangoCon US this year, it was pretty much universally agreed upon that non-relational database support for the core of your app was too much of an edge-case to bother finishing work on.

I used MongoDB for a year and a half. For 99% of projects that I see on HN and hear about IRL, I'm comfortable saying that you don't need that as your core database. Consider it for the portion of your domain that actually needs nonrel benefits (such as analytics), along with others like Couch, Redis, or Riak.

Your thinly-veiled CRUD app with a social layer doesn't need MongoDB. Here's a nickel, go use a real relational system like Postgres that makes sense for the meat of your data.