duckfruit

Only one reason: Greed

Homeowners want to see their investment appreciate, plain and simple, and will do anything and make up any justification to impede development so as to reduce supply and increase home values. Pretty much any argument, any rule, that restricts housing ("ruining neighborhood character", "affecting the historic value of the neighborhood", and in almost all cases, "environmental impact") can be understood if seen through the prism of selfishness. Never mind that people's lives are more important than obtuse feelings of 'neighborhood character', and never mind that the reason the shitty silicon valley house you bought in the 70s is worth millions only because of the blood, sweat and tears of all the people who came here and started companies and built things.

As you can probably guess, I'm pretty disillusioned at probably not ever being able to ever afford a place to live in the place I call home. (And I'm a relatively well paid engineer, others have it much worse).

Speaking for myself, the key selling point for Typescript (and Flow) is its pragmatism. While it might not have the soundness of a Bucklescript or Purescript, it does what its alternatives have chiefly failed to do for me: Allow me to see immediate incremental benefits without having to refactor an entire codebase.

While the alternatives might be in some ways a better start a greenfield project in, the ability to gradually add types to an existing codebase with developers who are just learning the language with the ability make the system sounder over time is a killer feature for me. Also, the big-company backing helps corporate slaves like me trying to sell a new technology to management.

I for one like the fact that different national space agencies are going with completely different approaches. I doubt that the skycrane used for the NASA's Martian Science Lab mission could be accomplished on a shoestring JAXA budget. On the other hand, an asteroid sample return mission would've cost billions and taken decades if NASA had done it.

At the end of the day, we all take different paths but ultimately get to the same place. Humanity wins.

As much as I hate to admit it as a dedicated AV fanatic: this is very much true.

The simple fact is that most people don't really care about sound quality and the 'good enough' sound they get out of TV speakers or a soundbar is plenty.

'Proper' Surround speakers - as in ceiling mounted speakers in a dedicated home theater room with acoustic treatment, as opposed to a soundbar with an atmos badge attached - have always been expensive and cumbersome and have only grown even more so with the proliferation of fancy new formats like ATMOS and DTS:X. Of course, part of the reason they are so expensive is because of price fixing by AVR companies like Denon, making an already niche market even smaller by erecting a taller barrier of entry. When companies have to resort to underhanded tactics to prop up their margins rather than creating compelling products that people want to buy it is a pretty good sign that the industry is in dire straights.

You are right, sorry. When I first read it I internalized it as meaning to say that Performance is not an extra feature that you tack on to an existing web app (like you would implement say an offline mode as part of an update) but rather something that needs to be considered from the ground up right in the design stage. But I can see how putting it this way could be confusing.

Great read. This could have just as well been titled "Guidelines for Web Design That Respects The User" or "Web Design that Doesn't Suck"

Summarizing:

1. Don't break accessibility

2. Clearly label hyperlinks

3. Make sure your buttons look like buttons

4. Dont paginate for the sole purpose of padding engagement numbers

5. No to decorations that distract from the content

6. Dont break the back button

7. 'Performance is not a feature'

That would be amazing! But you're right in that we'd need vastly improved technology before we can get there.

I tried oculus desktop with the rift, and all I ended up with was a blurry, unreadable display and a headache. We have a long way to go.

"To remedy the situation, the coalition urges Congress to invest in housing assistance."

Of course their answer is federal subsidies. Never mind that regulations can be passed at the local level to ameliorate the situation -- without costing the government a cent -- by allowing for more housing construction. With interest groups like these we'll never get anywhere.

The most salient point that the article breaches is this: When people unfamiliar with the DOM, javascript, or indeed in some cases programming itself try to 'pick up' a complex low level data visualization library like D3, it is natural for them to blame the library. But the problem obviously runs much deeper than that.

Running with the analogy in the article -- it is fruitless for someone who's never done any woodworking or furniture design ever to hope to become the next Charles Eames within the span of a few months.

Idris has a really neat feature called 'Holes' that does exactly this. I wish it could be implemented in every language on earth.

Me too! I was so hyped up about it that I got myself a ThinkPad X1 Yoga with an OLED display. But wish I'd realized sooner that putting an amazing display in a shit laptop still leaves you with .... a shit laptop.

If you have a newer webOS tv, clicking on the 'apps' button should take you to an overlay that displays ads along with the installed apps in a row at the bottom.

I've only used GraphQL (with Relay) on fairly large apps but in my experience the number of apps that don't benefit from some sort of client side state management tends to fall into a very small window.

Introducing state management doesn't come for free, of course. That is an extra layer of complexity that you have to reason and maintain. And if your app doesn't need any client side caching or you don't envision a need to have shared state between your components maybe you don't need to have something like Redux. But I feel like the use cases for those sort of apps tend to be pretty narrow.

edit: Another commenter mentioned a good point that gets to the heart of your question better than my rambling -- You are still managing state in your app - just with Apollo instead of Redux.

They mention it in the article but forgot the caveat in the title:

  How GraphQL[1] Replaces[2] Redux

[1] Or any well designed back end API

[2] For some narrow, often simple applications. And even in those cases it usually doesn't replace redux as much as it augments it.

Very briefly: operations like Transpose, Strided Slice, Padding, and batching are standard operations used to build Convolutional Neural Networks, which is in turn is a standard building block for a vast array of machine learning applications (eg, image recognition)

You wouldn't choose it over haskell every time, but for the limited subset of times where you need to write frontend code ReasonML has distinct advantages.

ReasonML is basically OCaml that compiles to JS, designed to make interoperation with Javasascript easy. There are compile to JS projects for Haskell too, but the ease of interoperability with popular JS libraries like react and support from facebook's open source tooling chain make it a much better choice for most frontend projects IMHO -- unless you're already a haskell expert in which case go with what you already know!

Free content, sure. But also ads for penile enhancements and dialog boxes that go "Congratulations! You've won $100,000 in Amazon gift cards! Click here quick [obvious phishing link] to claim your prize!". Scams, pure and simple. Not claiming that tracking prevention is going to solve these problems, but any move that at least attempts to reign in the worst excesses of a scummy industry is a step in the right direction IMHO.

Anil Dash had a good thread about this recently, and he puts it much better than I:

https://twitter.com/anildash/status/949476770922844161

I'm not so sure that's true. The mitigations they're doing seems to work very well for all sorts of form factors. I've been using a dell UP3017Q OLED monitor as my main display for most of last year and haven't had any issues so far whatsoever. It's simply the best display I've ever used. Even for my LG OLED tv, which I've had for a couple of years hasn't exhibited any image retention issues at all, despite watching a lot of news with scrolling headlines and logos. I wish OLED monitors would become more generally available since they're far, far superior to LCDs but for some reason apart from a limited run of the Dells and some short lived laptop models they're pretty much nonexistent.

Portals are like one of those ideas (like all great ideas) that are incredibly useful but seem obvious in retrospect. Thank you facebook and the react team for all your hard work!

And unlike oil, Lithium can be recycled indefinitely

I have an X1 Carbon from work. Overall an OK windows laptop, but man does the eink(?) touch strip thing suck. While I think that the Macbook version will be far superior, I hope they manage to solve its glaring shortcomings. Some observations:

1. Questionable utility. Sure, there's an icon for 'copy' and 'paste', but I cannot imagine it being easier for anyone to hunt along a non tactile touch surface located in an awkward position to hit that icon rather than just using Ctrl + C (or the mouse, which you've just made your selection with). That's a shortcut almost everyone knows.

2. Poor/Non-existent third party software support. Basically works for IE and Windows Explorer and that's it.

3. Software that drives the screen is poorly made and crashes occasionally.

4. The strip is a 2 bit/pixel B&W screen that is hard to read and is not backlit.

I like that suggestion. Thank you!

I tried mapping jj to esc, but even after a few days I couldn't really get used to it. Always drove me crazy when it would switch modes when I just intended to type 'jj' as a variable name in loops. At least it got me to use more meaningful names!

Your latter suggestions are brilliant, I'm going to steal them right away.

for...of is more flexible. While forEach is a method on Array.prototype, for...of is a consistent syntax that can be used in more places. For instance, iterables:

  function *myIterable (v) {
    while(--v) yield v
  }
  let launchCountdown = myIterable(60)
  for (let i of launchCountdown)
    console.log(`t minus ${i} seconds`)

So in effect arrays can be thought of as iterables in ES6. So IMHO it allows for more consistent behavior with the way iterators in other languages like Java and C++

When it started applying to Chinese companies

You might be thinking about miles per UK (Imperial) Gallon, rather than US Gallon. 1 UK gallon = 1.2 US gallon. Even a new 2015 Civic only gets around 32 Miles per US gallon.

Does anyone know of a way to fix the problem when getting out of a fullscreen page in Chrome for Mac? Normally, when trying to exit fullscreen page when the browser is already maximized, it gets thrown out of its workspace - a minor annoyance, but it's irksome enough that I try to avoid using HTML5 fullscreen in web pages.

I'm not sure how much damage being able to use computers without Microsoft Office by itself has done to people's perception of Microsoft. I'm more convinced that having, for the first time since the days of Amigas and AppleII's, major competing computer platforms has really dislodged the pre-eminence of the company in popular conception.

Financial institutions are using all available data to improve estimations of creditworthiness. The Horror!

I don't support the implicit assumption that it is better to err on the side of leniency when it comes to credit provision. Inadequate information was as responsible as lack of oversight for causing the financial crisis. Racial discrimination is also a flawed analogy -- that was a case of using traits that had no bearing on credit risk to calculate a deliberately false appraisal, whereas using data on online activity is far more akin to the practice of requiring bank statements.

Granted, mistakes could very likely be made, but so far the author presents no evidence that using such information is any worse than other means of estimating credit.

To be fair, the comparison might not be entirely accurate since it is possible to 'plus one' something while just being a gmail/youtube user -- without necessarily being an active google+ user.