djacobs

Totally agreed. Wikiwand has made me excited every time I see a Wikipedia link because the reading experience is so well thought out.

This is the way we should be talking about privacy. Using vivid examples that are relevant to everyday people’s lives on both sides of the political divide. Avoiding broad, philosophical-sounding proclamations.

I hope people on HN are taking note.

Interesting to see that this headline typo (copied from the Gizmodo article) has lasted on the front page of HN for 9+ hours!

Chalk it up to only reading the beginnings and endings of words?

I agree, the substance was there, but the story could use some editing and organization. If it were me, it'd look something like:

  1) How people think URLs work, the good parts that people see every day
  2) Abstract problems with URLs, followed by concrete examples, maybe links to prominent related bugs
  3) Suggested fixes for the problems, including what browers are doing at a UX level
  4) Honest look at tradeoffs involved for end users
  5) Remaining complications and unanswered questions

This looks excellent. I've wanted to build something like this for a while, and I'm excited to play around with it.

Nice work!

I had the same reaction: https://www.youtube.com/watch?v=puK5CwThaq4

I looked through the patterns and I wonder what makes them 'idiomatic'?

I've found it useful to use wrapper libraries like Enzyme [0] and Teaspoon [1] when testing React components and interactions.

[0] https://github.com/airbnb/enzyme

[1] https://github.com/jquense/teaspoon

Thanks for the response. If the choice is between manually specifying that (type of) code for every kind of object (and likely moving to a #create factory method) or using a native syntax for class declaration, I can see why people would choose the latter.

I'm not yet convinced that it's just syntactic sugar. For example, what (generic) code is `super` syntactic sugar for?

Even if it is just syntactic sugar, that syntactic sugar makes it much more approachable for devs who want to use classical inheritance (not that I'd encourage that).

IMO for web apps that you have open all the time (maybe Asana, Google Docs), native OS navigation and window management is significantly better than tab navigation. Of course it doesn't have as much of a benefit if you do it for every tab you have open.

True, a paid service is probably more likely to be around in a few years (in general), but does that matter for distributed source control?

I guess if you depend on non-git features, like issues, there's a chance that there's some lock-in. However, most of the ones I use have a migration strategy [0].

[0] http://webapps.stackexchange.com/questions/49729/how-can-i-i...

I think my experience is different from yours (I don't let spikes make it past my own branch), but as far as production goes, we're on the same page!

I'm all for using tools that don't make bad things easy, but I think threeseed is saying that for hacks and spikes, the "later point" you're referring to might not matter. (I agree that those are the only jobs I'd use Mongo for, too.)

Of course, if you're at a company where those spikes find a way of turning into production code, then it's a different story.

I restarted my modem and router two times before I realized that the network was fine and that it was just Facebook that was down. Props to their ops team for uptime that is so reliable.

Backbone Marionette would make the LOC comparison a fair one and is worth looking into if you haven't already. Marionette is an especially good answer for people who like the Backbone way of organizing apps but hate boilerplate/non-declarative view bindings.

My favorite part of Marionette is that it has opinions about things like model/view management -- so it avoids a lot of boilerplate -- but it can almost always be molded/tweaked to fit your specific needs (animations, lazy loading, views partially rendered on the server). It lets you 1) mix and match pieces build to work with Backbone (ModelBinder for declarative model-view bindings, Relational for client-side relations, etc.), 2) scale state change management up and down as appropriate for your app (via model changes, controller interactions, route events), and does not force you into a fully single-page architecture if you don't want it.

Anyway, I think Marionette is a pretty great way to write small, modular, readable code without sacrificing high-level abstractions.

Thanks for that insight, I was missing the entropy lens.

From what I understand, it's hard to known when brute-forced decryption is "done" (i.e., the decryption yielded plain text data that is the original data). As far as I know, machines look for patterns in the potentially decrypted data that look like common formats (or for data that correspond to real letters/words in a certain language). Does visual cryptography make decryption "done-ness" harder to detect?

I'm happy to contribute, too -- let me know if you're interested in any help with editing or creating/maintaining a PDF.

It would be great to host an up-to-date PDF with this, too. (Any interest in publishing this when it's at 1.0?)

I think it's important to remember that Backbone is not one library but a modular ecosystem. I am a huge fan of Backbone Marionette + Relational + ModelBinder as a very valid alternative to Ember and Angular.

I think this is less "Lyft is awkward", more "I am not Lyft's target market and am (inexplicably) upset about it".