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".

It's always good to share Vim tips, so thanks for that.

Question, though -- why not use the native <C-i> and <C-o> to navigate between jump points? It will get you to the previous and next buffers but has just enough granularity to be useful for other things, too. (<C-6> is native buffer toggling and ignores jump points, but it's not easy to type.)

It's true that in general, people need to understand what is dangerous in each language they use.

However, as far as I can tell, the problem here has nothing to do with homoiconicity. The "get string" vulnerability, as you call it, comes out of Clojure's (excellent) JVM support, and not from the Lisp side of its family tree. A "read" is not just a read only because reading Java means creating and compiling arbitrary classes and objects. That, in turn, is largely because Java is not homoiconic.

I'm not an expert on this, but I have a different take. I think that "is" happens when there is an implicit gerund before the plural noun.

- [Working] five days in the office is too much (I do think that the title should be "too much", not "too many")

- [Having] two hundred students is better than [having] none.

That is, there is an implicit subject, and it is not the plural noun, which is actually a direct object.

Nanoparticles would be the solute in this case. (If a foreign substance, and not water, were the solvent, you'd have problems regardless of how tiny the solent's particles were.)

I disagree -- frameworks enforce structure (especially of callbacks), not code style.

Unity of code style is something you can solve with standards, style guides, pairing with new developers, and following conventions from surrounding code.

Clojure is nice because the community, while having different opinions about how often you should use X technique vs Y, generally has core sensibilities about what makes for good, simple code that composes well and doesn't tangle concerns. (This is largely due to the influence of Rich Hickey.) This (and not "perfectly uniform code style") makes for an effective large team.

I don't agree that in pair programming you should succumb to your pair or take a least-common denominator philosophy. When I pair, I always use a (customized) Vi, swapping between two editors if my pair's is different. I'm intimately familiar with mine (and he with his), so we're much faster this way (and happier, to boot).

Hinton was one of the people who invented backpropagation, which has let neural nets be as powerful as they are today. Somehow, despite his brilliance and intimate familiarity with backpropagation, his explanation of it is stunningly clear and simple. I'm thoroughly enjoying this course and recommend it to anyone who wants to build their own neural networks.

While I enjoyed most of Brian's talk, I wasn't particularly convinced by his dislike of refinements. Essentially, it boiled down to "this feature is hard to implement, it hides complexity, and it isn't well specified". The first and third arguments shouldn't matter to us nearly as much as the middle one. And I fail to see how namespacing monkey patches can do anything but decrease and contain accidental complexity (in the same way that method dispatch and polymorphism are better at limiting complexity than explicit conditionals).

I've tried using Sublime with Vintage mode, and about 30% of the time I'm editing, I try a Vim combo and nothing happens. This isn't just for advanced Vim features -- it's for basic things like g_.