jugglinmike

ARIA-AT is a W3C Community Group (of which I'm a member) trying to address this problem: https://aria-at.w3.org/about

It also contradicts the author's earlier argument:

> I need to know there was intention behind it. [...] That someone needed to articulate the chaos in their head, and wrestle it into shape.

If forced to choose, I'd use coherence as evidence of care than use it as a refutation of humanity.

Great catch. I was getting ready to mention the theoretical risk of asking an LLM be your arbiter of truth; it didn't even occur to me to check the chosen example for correctness. In a way, this blog post is a useful illustration not just of the hazards of LLMs, but also of our collective tendency to eschew verity for novelty.

That part was straightforward thanks to the "d3-force" plugin for D3.js:

https://github.com/d3/d3-force

I probably ought to spend a little more time tuning the parameters, though.

> Maybe there is a way to build a new web, a new kind of social media using a > hash graph to implement a decentralized web of trust, something that can > allow content verification without forcing everyone to sacrifice their right > to remain anonymous online.

Comparisons to OpenGPG are likely to make anyone cringe, but if you're willing to suspend disbelief about the usability issues, it seems like such an apt metaphor. Where signing a key is vouching for the owner's humanity, not their identity. I can imagine websites integrating my browser to attach a "humanity key" to the content I post, and my browser maintaining my collection of keys and my preferences for divulging them.

Granted, pseudonymity is not the same as anonymity. Maybe if the meaning (and lifespan?) behind these keys was constrained, then they could be sufficiently disposable to approximate anonymity.

This system is either fundamentally flawed or already implemented, but I don't know how determine which. Can anyone here share writing along these lines?

The real irony comes from the author's claims:

> Unlike reading books and long magazine articles (which > require thinking), we can swallow limitless quantities > of news flashes, which are bright-coloured candies for > the mind.

...and the manner of publication:

> This is an edited extract from an essay first published > at dobelli.com. The Art of Thinking Clearly: Better > Thinking, Better Decisions by Rolf Dobelli is published > by Sceptre, £9.99. Buy it for £7.99 at > guardianbookshop.co.uk

But there's a good case to be made for knowing your audience. In that sense, this version is actually much more likely to reach those who might be influenced by it.

jQuery supports custom builds today:

https://github.com/jquery/jquery/blob/e80117adb49eff8f82140b...

Based on the full quote (below), it seems that he was referring to Valve's offering only:

"Well certainly our hardware will be a very controlled environment," he said. "If you want more flexibility, you can always buy a more general purpose PC. [...]"

Yeah, that's a good point. This introduces a new inventory consideration, namely CPU model demands (they'll have to determine the best distribution of proc models across each product). Probably not too big a deal

Two points that I haven't seen covered yet:

1. Waste. If some component on your motherboard goes, you're on the hook for a new CPU (and vice versa). This seems tremendously wasteful. Maybe bigger repair shops will support mail-in refurbishing? Will people take advantage of that? Or just buy new for convenience?

2. Competition. Smaller motherboard vendors won't be able to sell direct anymore. I'm wondering if anyone can comment on how bad of a thing this is.

The OP doesn't mention expected client count, but the number of concurrent connections is a crucial factor that these tests overlook.

I'm currently doing some Socket.io stress testing, and it's clear that XHR-polling is significantly harder on the CPU for the reasons you've mentioned. This detail is lost in the noise for single-client tests, but it will become increasingly relevant as more clients connect.

"Showing up every day is very interesting because it’s the least visible indicator of success. No successful person tallies how much they show up every day. Well except maybe this guy."

I really expected this link to point to Jerry Seinfeld's productivity secret. The story has made the rounds at this point, but in case anyone missed it:

http://lifehacker.com/281626/jerry-seinfelds-productivity-se...

There was a good discussion on this kind of service a while back--check out "Javascript Cryptography Considered Harmful"

HN: http://news.ycombinator.com/item?id=2935220 Direct link: http://www.matasano.com/articles/javascript-cryptography/

I believe Web Intents (http://webintents.org/) are designed to address this problem. Specifically: http://examples.webintents.org/intents/share/share.html

It's great to see knowledge like this compiled into one place. Unfortunately, it looks like the resource is only superficially open source.

I was about to make a pull request to fix a typo, when I found someone had already done so: https://github.com/rstacruz/backbone-patterns/pull/3

If a objective correction like this takes 6 weeks (and counting!) to be merged, does the open nature of this page really matter?

Not that this detracts from the message, but take the claim "This is a massive work-in-progress." with a grain of salt.

> CoffeeScript was a godsend here, simply as an explicit compile and validation step. > Automatic local scoping (no var necessary) is a sane choice, and safe loop scoping with for x in y do (x) -> erases a whole category of errors. > indentation

Thought it might be useful to others seeking these advantages that passing your JS through JSHint in the build process could provide these benefits. It's not a cure-all, of course--the author cites other benefits that linting can't achieve. But if you're a like-minded developer looking for assurances along these lines in JavaScript, check out http://jshint.com and https://github.com/jshint/jshint/

Lawrence Lessig has much to say on the subject:

http://onpoint.wbur.org/2012/01/02/lawrence-lessig-on-money-...

Basically, publicly-funded elections could remove the corrupting influence of corporate money. Still not clear on how we get there, but I may pick up his latest book to learn more

Throwing mine out there, too--for spoofing your user-agent string:

https://github.com/jugglinmike/chrome-user-agent

I think the author mis-understands memory management. The following line argues that, without a reference to the prototype, the object is smaller:

"The other way it differs from the constructor pattern is that the prototype class is not instantiated. Which reduces the memory consumption of the object (among other things)."

Admittedly, there is some ambiguity because the second statement is a fragment. The way Crockford is quoted seems to support this fallacy, though.

Echoing what jashkenas said: anything you may save on a reference to the function's prototype (minimal), you lose when creating copies of each member function.

What Crockford was speaking about in his post was using "new" directly on a function definition. In that specific case, the reference to the prototype is useless, since it is blank. In the OP's "Mammal" example, the prototype reference provides key functionality that is well worth the cost.

I can't say I completely disagree.

When I was putting this together, I kind of felt like I was writing a general article on one method of exploiting polymorphism--not necessarily the Strategy pattern specifically. Honestly, I'm still not sure.

What I do know is that JavaScript has a number of features that make OOP significantly more informal--namely dynamic typing, object literals, and first-class functions. I'm thinking of implementing more patterns in JS in the future to try and get a better grasp on this...

I think jbwyme is getting at this with his comment http://news.ycombinator.com/item?id=2680408 (specifically "Then, if needed, use a prototype to set defaults"). Using the prototype is not really necessary at all, but it adds some amount of formality to what is otherwise a ragtag collection of objects.

Good point! I don't have much experience with animation libraries, but maybe if I look at some source code I can get a stronger real-world use case for the article...