Pewpewarrows
https://www.reddit.com/r/AskHistorians/comments/hd78tv/does_...
https://acoup.blog/2020/02/28/collections-the-fremen-mirage-...
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.
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?
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.
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.
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.
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.
(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.)
$ 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.004sThe non-existant proxy trick seems useful, I'll have to try that out.
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.
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.
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.
> 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.
* 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.
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.
"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.
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.
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.