feedjoelpie

Time tracking, virtual desktop/spaces navigation, audio controls... scaling server resources? I don't know, there are a lot of things you can do with rotate + click + a little screen to let you know what you're doing.

Is there at least one button in addition to the knob? How do I get my hands on a dev kit? I have been casually looking for an internet-connected dial + button + display for a long time. I have lots of different productivity uses I want to try out. Badly.

Edit: I see now that it does indeed have "click" listed in the specs.

Would you consider, as I would, the Yes Men's activities as both trolling and more or less good? https://www.youtube.com/watch?v=LiWlvBro9eI

> "OK, he knows how to reverse a Bitcoin address into a public key, and picked a good address for the purpose."

Yeah, but I can do that. Can it be my turn to be Satoshi now? It's specialized knowledge only insofar as you need to have read how to do it and understand enough to write some commensurate code. This is widely-published stuff. It doesn't take a Satoshi or even an expert.

I'm seeing a lot of bad solutions to this problem written in response to you, so let me say "Do not ignore the the console warnings about array item keys" and list out some gotchas:

* Supply the key to the top level list item component. Do NOT have the list item component define its own key in its render method. That is not how it works

* Don't use the array index for the key. Use something that's unique to the VALUE.

* Don't use _.uniqueId() or similar in any render loop. It will trigger a re-render every time, even if your underlying data has not changed.

* If you use _.uniqueId() outside of a render loop, for example to set a temp ID on a brand new data model (what Backbone does by default), and you have an isomorphic setup, make sure that your client and server counters stay in sync. The server version of _.uniqueId() will just keep counting up forever unless you do something about it.

You really need to try to find something unique (or unique enough) about the data itself. In the case of strings, use the string as the key. If the case of objects, if you really HAVE to, if there is nothing else that could possibly work right, you might get desperate and JSON.stringify them to make the key. Hopefully it doesn't come to that but it's still often better than alternatives that force full DOM reconciliation on the whole list.

You are correct. _.uniqueId() will absolutely wreck your list rendering performance if it is called on every render. 99% of the time, you can find a better unique identifier, but if you absolutely need something like _.uniqueId(), it should never be called in the render loop. It should be attached to the data being iterated over, in advance.

But... the other problem with _.uniqueId is that in an isomorphic setup your server will just keep counting up and up while your client will start from 0 on every page load. So the first time you reinflate React on the client side the checksums won't match and will cause a full-page re-render.

Right, so is there a subset of those multiple choice cases where Mongo is best?

> I do the same thing, but I realized a while back there is a flaw in this model. It means the available creative works—which in turn effectively means the engine of culture—is determined almost entirely by people who are well-off enough to have the free time to do that.

I'm not about to claim that it's in any way an ideal or better, but isn't this how 90% of the literature, and maybe more often art, that we know hold as sacred parts of history, were created?

I've heard rumblings that people have been posting their competitors to Product Hunt before they're ready, thereby sabotaging their launch plans. What do you think can be done to avoid similar bad behavior on OpenHunt?

>So when the crappy HTML Firefox shows up, with way less features than the Firefox of today, remember that this (Thunderbird) was one of the things given up to have it.

Please recall that Phoenix/Firebird/Firefox was born as a lightweight, fast alternative to the bloat of Netscape Communicator/Mozilla Suite. Dropping features from an old bloated application is what launched Firefox to fame in the first place.

Does anyone have details on the financial health of The Economist? They don't play this dumbed down new media game, and while I'm sure they're not gangbusters, they do appear quite a bit more stable than the other traditional outlets that _have_ tried to get in on clickbait.

This is only true if your climate makes it more expensive to heat the building than to cool it.

I fully expect someone to ask, "So why Lintron instead of Hound?" The answer for us is a combination of things. First, given the large quantity of private repos we have, hosted Hound is not cheap. Hound also has a lot more moving parts and isn't particularly friendly to self-hosting setup. It was almost easier to write the prototype version of our own lint bot than it was to set up Hound. This also just makes things really easy to hack on and to ship other behaviors, that may not be strictly linting but still make sense as PR comments, that Hound didn't envision. It's really just a matter of preference. It's pretty easy to fork Lintron, throw it on your own hosting, and hack it to your liking. Whereas Hound is obviously designed primarily to be a subscription service based around config files.

Forgive my lack of specificity with this harshness because it's been a long time. Floobits was horribly broken when I tried it in Sublime Text. Why should I give it a chance in Atom when I have Screenhero, which works quite well?

That very likely could be be my point of confusion. Thanks for the response.

Serious question, not rhetorical:

I have noticed there appear to be artificially-bumped posts from time-to-time that relate to YC companies. Is HN providing extra clout to YC companies' PR above and beyond organic community moderation, and if so, will HN's extra autonomy in any way change that?

Stupidity adequately explains the initial reaction. Bringing charges is merely after-the-fact butt-covering. The whole world knows you're stupid, but if you can get the entire legal system to be just as stupid, it's no longer your fault!

Remember the Aqua Teen Hunger Force "bomb" scare in Boston? The city rigorously pursued legal action to spare their police department the embarrassment of having wasted millions of dollars carefully dismantling DIY Lite-Brites.

As I understand it, immutability makes management of state on complex objects easier to deal with. Whereas ImmutableJS the library makes immutability performant in JS. Someone please correct me if I'm wrong because I cannot seem to locate my source anymore, but I believe what ImmutabilityJS does is not actually deep-copy complex objects, but reuse references to nested objects that have not changed. Such that you get a new object, but not everything in the object is new, which is what keeps things fast.

The big advantage of JSX to my company is that our design team, which does design in the browser, has a much shorter leap to understanding it than plain JavaScript. These suggestions of "JSX sucks, you can express this in plain JS" always leave people with those skill sets behind. Sure it would be really awesome if the designers were also serious JS programmers, but that's not why we hired them, and with JSX they don't need to be.

Whaaaat? Laptops with integrated graphics are the vast, vast majority of personal computer sales. That's its major use case. The one that almost everyone with a laptop has.

Another reason that, even despite sharing a lot of syntax with PHP, Hack is one of my favorite languages:

http://docs.hhvm.com/manual/en/hack.nullable.php

Or is it that the completely-analog piano has become more niche? Digital pianos these days sound and feel fantastic when put up against their analog counterparts in the lower end of the price range (what you'd find in a typical home). And they require zero maintenance and can be moved with ease. There will always be a place for a "real" piano, but you no longer need one if you just want to learn and play. I personally have a digital stage piano. It's 20 lbs. without the stand, and I can sling it over my shoulder with ease. 9 times out of 10, when I try to play a piano in someone's home it's out of tune and has some sticky or unplayable keys. So I'd say that analog pianos aren't dying, but they have become relegated to the niche of people who either want them as furniture or people who are serious enough to maintain and care for them. For the rest of us, digital is the right choice.

Instincts are strange. I have been (happily) surprised by myself on multiple occasions by how I've reacted to near-impact situations. Do I think that means cars can't do it? Absolutely not. I do think that it will take a lot of learning to get the same out of them. On the other hand, do I also think that replacing every car on the road with a self-driving one right now would result in fewer accidents and fatalities? Yes. If it were illegal to drive and all vehicles were required to be autonomous, I 100% believe that would drop the danger of motor vehicles significantly. Where it gets weird is the concept of fault. Right now, because most motor vehicle accidents are driver error, humans screwing up almost serves as an insurance policy for manufacturers. If fewer people die, but more of them die as a result of manufacturers' software... Yeah I don't know. The future is going to be weird.

While I have largely moved away from Backbone, what makes Backbone really great, still, is its adaptability. While I wouldn't endeavor to write a brand new application with it so much anymore, it's extremely hackable and especially great for abstracting away ugly legacy web service APIs. It's definitely saved my sanity on that front on more than one occasion.

It's actually worse than that. Here's an article from 2 years ago describing how the biggest employers of H1Bs use the program to bring low-paid immigrants into the country, train them, and ship them back home to pay them even less while doing the same work: http://www.npr.org/sections/alltechconsidered/2013/04/03/176...

Companies like these use up most of the H1B slots such that truly skilled high tech jobs that pay well, and would accept H1B if they could, are going unfilled. This is why you see so many U.S. companies setting up branches in Europe and Canada.

I'm going to take a not-that-wild guess and suggest that they're completely aware of the inefficiency and moved forward with it because A) it gives the company a fatter profit margin when the customer is paying for less Soylent and more water, and B) this is the best way to move toward getting Soylent into the corner store refrigerator.

Their optional typing for JS is called Flow, and they've open sourced an IDE of sorts (a suite of Atom plugins) called Nuclide (http://nuclide.io/).

Not sure why you're so quick to jump to the conclusion that there's a conspiracy, but comments appear when people write them. And I'm looking at a whopping score of 3 on my end. Such coordination! Many conspiracy!

Mixed feelings. On the one hand, the people who complained most loudly about this article rewrite should probably examine their motivations. Because I doubt there would have been this level of scrutiny if not for an ugly undercurrent of anti-feminism.

On the other hand, the article deviated so far from the original just-the-facts version, and the "analysis" was so one-dimensional, that it felt like it veered into Fox-News-for-liberals territory. Which should not be worthy of a pre-eminent news publication.

Perhaps "analysis" at a serious news publication should simply not be written hastily just for the sake of mass click appeal.

At any rate, it doesn't seem like it would have been that hard to throw some opinion piece links or an analysis piece link in the suggested/related section.

MacBook 13 or 15 retina. A great 13" for software development can be had for ~$1200.

Why Mac:

* It's Unix-like.

* Homebrew is fantastic for OSS package management.

* It's ubiquitous. (Yeah you could use Arch Linux instead of a Mac with Homebrew, but Homebrew will always get updates first.)

* Great battery life. (Linux often sucks at this.)

Why Retina:

* Text is extremely clear. It may seem like nothing before you've used it for a while, but you'll never go back.

* More real estate for side-by-side viewing of whatever you need.

* The Retina MBPs are actually quite light, enough so that I don't have MacBook Air envy ever.