skysight-inc/HackerNews huggingface dataset:
I'm a C# dev and I had to lookup this new feature since it didn't ring a bell. I'm curious, why is this is a big improvement of just having "private set;" in the auto-property? I'm not being sarcastic, I genuinely want to know.

(Incidentally, in terms of your filtering, I absolutely categorize myself as a "mediocre" or "medium-level" developer, but that doesn't mean I don't care about things. Just that their value may not be immediately obvious to me.)
Hey guys,

This is a little side project I worked on while in between jobs. It's a barebones music player sitting on top of the Soundcloud api. I wanted to learn some of the neat es6 features and Redux, a flux implementation by Dan Abramov, and thought it would be good to share for anyone trying to learn React / Redux. Any feedback or criticism is welcome and is greatly appreciated. I'm planning on adding a lot more features if I have time.

Source code here: https://github.com/andrewngu/sound-redux

Thanks!
That's wise. There are parts of POSIX that even I (a notorious purist) think are outdated, unclear, or just not worth the trouble. Appending and random writes sure would be nice, but I appreciate the difficulties involved. Maybe if I get a chance to learn more Go I'll be able to contribute in some of those areas.
> Why the new declarative query language for fetching attributes (columns) from objects (tables)?

SQL isn't very composable- It was the right idea, but there's been a lot of progress in the last 50 years on how to traverse a database. It is all string-based, and it lacks a "pull syntax" (i.e. after the query completes, give me this graph-represented chunk of the result)

> Why build yet another transport mechanism on the top of HTTP, when there are so many to choose from already?

Relay is mostly agnostic on what mechanism is used to fetch results.

> Oh, my god, boilerplate everywhere! What is this, Java?! /s

Yeah, it's kind of awkward to do this stuff in Javascript- Look at what people are doing in more flexible languages, like here https://github.com/omcljs/om/wiki/Quick-Start-%28om.next%29
I can't find the link now, but someone (This American Life or somesuch) published a great analysis of how the top people in every sport have inherent (non-controllable) physical characteristics that give them an edge in their sport.

Michael Phelps has a bizarre chest-to-leg ratio, which is excellent for swimming. He could never be a top tennis player even if he dedicated his life to it. Serena Williams would never be a top swimmer.
I found "Go Blueprints" a good introduction for someone who wants to get into practical projects quickly, and doesn't need an introduction to programming. If I were to write a book about Go it would be exactly that, demonstrating how useful Go can be for day to day tasks, and for cli tools and servers.
Religion: Ruining Everything Since 4004 BC by Zachary Weiner – Kickstarter
NCAA would never admit that their "scholar athletes" are a minor league!
Investment in Spanish startups to surpass $500M in 2015 for the first time
I've used Go for neural networks and machine learning with great success. Fast, safe, fairly straightforward. Much easier to parallelize than with Python.
> I deal with REST zealots like this everyday :( just the fact that people spend so much time debating what is and what isn't REST should be a red flag that maybe it isn't the answer to everything.

REST isn't the answer to everything, to be sure -- but its actually not the REST zealots who pretend it is. Rather, its the opposite: the people who pretend that REST is the answer to everything are the people who just throw around the label "REST" willy-nilly on whatever solution they've come up with to whatever problem they are dealing with.

REST zealots are generally fine with people offering solutions that aren't REST, especially for problems for which REST isn't a particularly ideal solution; what they object to is people claiming something is REST that isn't, which interferes with the ability of people to understand what REST is and what its good for, or to even understand what is being proposed.

> Overloading HTTP error codes is another interesting problem. If the server returns 404 for a resource, what actually happened?

A consumer really shouldn't, in the normal case, care what generated the error code, they should care what the error code means. 404 means the requested resource didn't exist. What component of the system processing the request made that decision shouldn't matter to the consumer (and may indeed change without any change to the meaning because of implementation changes.)

The people responsible for the implementation of the system returning the status code certainly care, and should have sufficient logging detail to support that.

In any case, HTTP/1.1 specifies [0] for 4xx series errors that "Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition." So, any implementation following the standard will, unless there is a good reason not to, provide an explanation of the error with the 404 response, so to the extent that there is further information that a consumer needs to understand, it should be provided.

> HATEOAS is just superfluous. I've met zealots who will defend it to the death. I just haven't found a practical use for it.

Have you used a web browser? If you have, and you understand how they work, you should be able to think of a practical use for HATEOAS. If its not applicable to your problem, that's fine to, just don't call whatever solution you cook up REST, because it isn't.

> REST encourages creating a CRUD interface for every single resource.

No, it doesn't.

> I've met people who have created literally 100 endpoints upfront for a small application - how is that maintainable?

Probably moreso than an application that puts 100 unrelated pieces of functionality into the same endpoint. Now, if there was too much functionality implemented for the problem, that's not REST's fault, which really addresses how you organize functionality, not what functionality you provide.

[0] http://tools.ietf.org/html/rfc7231#section-6.5
Bah, you're right. :-)
Apple Removes Over 250 iOS Apps with Ad SDK That Collects Personal User Data
I am not familiar with Stross's book. If I remember correctly this subject is not part of the YC application (marital status, family...). I have applied three times including the latest for w2016. I have not been invited for an interview yet, so maybe it comes up in that context. For the record, I am single, no family, former aerospace engineer, laid off in my early to mid-fifties, several years ago. The topic of age diversity is of great interest to me. I believe there is a lot of engineering talent and experience laying dormant, waiting to be tapped - people laid off right before retirement. Adding to my defense systems engineering skills I've become a full stack developer for the project I am applying with, and I am ready to go!

(edited for typo)
This article is implying that a group of the best engineers of the world (Facebook and Netflix engineers came up with similar solutions with Relay and Falcor), are just dumb and don't know how the web works.

There are motivations behind those solutions, and are documented across videos, papers and documentation. It seems to me, that the author is ignoring the previous experience of such teams.
er, they left a couple things out of the family tree (page xii). Like C++, Java, C#, ...
For what it's worth, the institution [1] behind this study is one of the most prestigious scientific institutions here in Spain.

[1] http://www.cbm.uam.es/
Right, but if your argument is that they just didn't understand REST, and yet they employ some of the smartest people around, so if they can't understand REST, what chance do the rest of us have?
Scaling Google with Eric Schmidt – Class 8 Notes CS183C
That's true they connect usually to large nerve clusters, the common one is the one in the armpit (circumflex nerve).

They can also fool the brain into thinking that the sensation comes from say your fingers because the brain co-locates the actual nerves that would've sent the signal by basically the transmission delay.
Hundreds of Apps Banned from App Store for Accessing Users’ Personal Information
> Go has an object model.

I'm no sure go creators would agree with this. The go object model is different enough from other object models that it would not qualify as one for a lot of people.
Many companies--especially tech companies--deliberately blur the line between those two things.
REST is one of the worst tech religions ever created yielding the most blinkered zealots. It's treated like a Bible where every word is taken as the Gospel truth that can't be tested, validated, compared or improved upon. Any alternative technology that reduces latency, improves performance and end user experience is considered an evil intrusion invalidating the purity of REST and must be vanquished.

In the name of REST, practitioners give themselves a free-ticket to develop large, over-architected, dumb chatty high-latency solutions at the expense of the end user as long as tech choices are made within their interpretation of REST. Normally technology serves the client, unless you're a REST zealot in which case what the needs of the client is secondary, its more important to obtain Internet kudos points by forcing your way up the maturity ladder.

No we must develop and shoe-horn all App and User experiences within the constraints of an ambiguous thesis that was built to link and update documents and create server-driven turn-by-turn apps. The fact they can't correctly interpret what different parts of REST means amongst themselves have generated programmer-decades worth of wasted discussions in the most useless bikeshed ever.
That is truly amazing! Deren Brown would approve!
"REST" as we've come to know it is just a useful design pattern for APIs. That's it. It's not a law. You probably don't lack understanding of REST, every developer just has their own interpretation of edge cases (multi-resource responses, etc.) and different experience with what's worked and what hasn't.

I wouldn't get caught up in the details. Use whatever tool is appropriate to solve your problem(s). I think it's likely we'll find certain design patterns (GraphQL vs. REST) are best suited to projects with specific problem spaces or scope. Maybe it's always best to start out "RESTful" and begin migrating to a different interface as your app scales in complexity. Maybe the latter problem is only an issue with medium or larger projects. Perhaps it's best to teach developers to be strict with REST to develop good habits and start migrating away once they're confident and comfortable with their ability to make architectural decisions.

Either way --- don't sweat it. Experiment with what you like because you're the creator. Figure out what works best for you, and you'll be able to identify wins and challenges and decide for yourself how to use the technologies around you and what they bring to the table.
> Is everyone being super-stoked about Star Wars and Breaking Bad really a vital aspect of a company's identity? Is a shared passion for ping-pong over lunchtime really an important part of a company's continued success?

This is a different argument than one about age discrimination. Whatever the culture a company and its employees adopt, my point is that it isn't necessarily age discrimination if you are getting the "not a good culture fit" feedback. It's not the number of years you've been alive so much as an attitude, which is something you can change. If you're unwilling to, fine. If this makes you mad, I'm sorry. However your emotions sway you, it is still not age discrimination.
"you can be sure that this is, for better or worse, the official company response"

Quite the opposite: there's absolutely nothing official about it. It isn't published on an amazon domain, doesn't carry any signature as amazon, and the only evidence that this is in any way related to amazon is that the guy works at amazon.
That's a strength. I didn't know about the Plasma argument and it looks like a good one.

Someone is yet to post a good refutation to it there.

The weakness is in allowing those who disagree to throw a tantrum, be impolite, use curse words, and attack other participants, such as this post:

"What the fuck has this to do with global warming?? electric currents and your shitty plasma have nothing to do with this, literally 99% of your spam quotes are irrelevant quotes"

When it's obvious from the "spam" arguments posted that the Earth sits within a system that is 99% plasma.

The problem with this system is that you will get many participants Skissor (author of the above-quoted pearl) asking for arguments to be censored or removed. This is the major problem that forums everywhere have yet to solve - when enough of the majority deem the minority's point of view as "trolling" as asks that it be censored, there is no real debate.
In certain situations, like some generics declarations, and in the lambda syntax. Overall, no.

Even still, it's only a bit of typing, which has never really bothered me. Once typed, the available refactoring tools make it super simple to edit, and I find that I spend way more time editing code than creating it from whole cloth.
Oh man! I was thinking about the whole legal language should be something of a formal language a little less than a year ago. I'm glad someone is doing something along those lines.
It does encourage more endpoints because I can't include data from two different objects in a response. They should be GET separately. With highly relational data where I need to create an endpoint that returns information regarding 50 different object types, how should I do that? My rolled up response is no longer REST.

When I need to act on that data and call an API that can do a variety of CRUD operations to 50 different objects types, how should I do that in a REST way?

It leads to developers creating a multitude of APIs to interact with those 50 different object types. Just so they can say their API is REST. For someone trying to use the API it's a nightmare.
Creepy steganographic puzzle arrives in tech blog mail
Robotics ideas to benefit humanity sought in $1m UAE competition
There is no such a thing as ideal translation of the bible, simply because there is no single bible. Each tradition has a different set of sources for the biblical text. Just for the old testament you can choose between Septuagint and Massoretic texts, and we know these two traditions existed for centuries already at the time of Jesus. For the new testament, you will learn that all existing copies differ from each other, sometimes with entire chapters or even books being added or removed. Modern translations use the so-called Text Receptus, which is an invention of Erasmus. So, a translation of the bible is just like the picture of a unicorn. Most people will agree on the general shapes, but when it comes to the details there is no way to determine if it is true or not, because there is no original to compare.
If you concede that Go didn't do anything new other than getting popular, then I can't find anything to disagree with.

> What feature does Rust have that wasn't invented in some academic paper by the 1990s if not sooner?

Actually, the borrow check is novel (though you can find precursors in Cyclone and fractional permissions work), and I think that is responsible for a lot of Rust's popularity (as it enables memory safety with dynamic allocation and no garbage collection, something that is actually new). But the answer you were looking for is "nothing", and that's precisely my point in regards to Golang. This stuff isn't new. Specific repackagings of it are getting popular, but I think that factors unrelated to the technical details of the type system have been largely responsible for that.

(I also continue to disagree that structural typing as implemented in Go is a useful feature—I think it's a net negative for usability because it saves a few keystrokes at the cost of precluding implementing interfaces for types outside of the package they were defined in without writing annoying wrapper structs—but that's neither here nor there.)
That's what I do. If the candidate is in the room I hand them my keyboard. If they are on a google hangout I send them a link to collabedit.com. People seem to do a lot better with a keyboard and syntax highlighting.
Check out DynaTrace. They are probably the best tool I know of but expensive.
* Expiration date d+1day (security impact: NIL) > not much impact unless the certificate age is tied to the time it might take some one to refactor a key
* Name doesn't match the cert > Can't trust that you communicating with the correct party, worth as much as plain text to me
* CA not trusted > Unless you can explicitly verity the end certificate and the chain = plain text to me
* Certificate is self-signed > same as the above
* Certificate was generated using old/broken crypto > depending on the exact issue government agencies will most likely be able to break the encryption, if it's more easy attacks like BEAST or CRIME so can resourceful non-governmental organizations and individuals.

This isn't just crying wolf we need a new and better system, one that ensures that the key exchange is secure, and one that ensures that who ever you speaking too is the actual intended precipitant and not a system which currently if one of those fails both fail, and more often than not can easily fail on both on it's own out of the gate.
I once had an interviewer intentional preface with "I always come off a bit hostile" and I was tempted to just stop right there. If you appear hostile in interviews and you know you appear hostile in interviews because people keep telling you that, why are you even still in the interview loop? Technical interviews are already stressful enough without the added stress of a hostile inverviewer.
They're not going to retrofit an SCR system on to cars proven to meet emissions standards when the software is running in compliance mode. They're going to reflash the ECU with software that doesn't cheat. The result for the consumer: a minor drop in fuel economy and more frequent cycling of the Diesel Particulate Filter (DPF) will have a little more noticeable impact on performance than when in cheat mode.

The DPF is like a muffler with a trap to catch the soot and ash from the exhaust. That black stuff you see coming out of a truck but never from a TDI even when in cheat mode. When the DPF is cycling, the engine passes unburned fuel from intake to exhaust on every fourth stroke. The unspent fuel lands on the trap, and when the hot exhaust from the next stroke ignites that fuel, the soot and ash are reduced, which in turn reduces NOx emissions. If they are smart with the software, they'll try to run the DPF when the car is cruising not accelerating, and the impact on performance will be hardly noticeable at all.

Cycling the DPF more often will likely result in a longer lifespan for that unit. Currently they need to be cleaned when they become fouled. Cycling the DPF more frequently, thus burning the soot out of the trap more regularly will likely reduce fouling.
Building a Realtime Quiz App with Ruby on Rails and React.js
Will you do any less when it's your demographic's turn to be deprived?
Exactly. Programming is not a zero-sum game. There are a zillion times more people making their living at it now than 40 years ago, but exactly the same number of champion sportsball teams in whatever contest per year: 1. You can make an awesome living or have a great company without being the #1 company.
I thought we were adult enough to not throw out and entire detailed and interesting article because of one sentence we didn't like.
If you're just sending HTTP requests, regular threading in Python works fine - waiting for a socket response doesn't block the execution of other threads.

Python threads are real threads, and things like blocking socket IO does not block Python execution in other threads.
first off apologies for the criticism about flush(), I only skimmed the code and flush() is usually where I look for first.

Anyways goofys at this point is just a toy project. There are more optimizations that I can potentially do (proper read prefetching) it's mostly good enough.
How did this article get flag killed?

I wanted to say something constructive about the topic: Any time you layer an arbitrary UX over a given data model, expressiveness is absolutely necessary in the protocol in order to minimize round trips. This is why SQL has been so successful on the server side.

An alternative to the "moving the whole graph to the client side" approach is the intercooler.js way [http://intercoolerjs.org/]: HTTP requests express UI/UX needs, rather than generalized data queries to support a client-side object graph and model.

This eliminates a whole swath of complex issues that come up with managing multiple instances of data in a distributed object graph environment, knocking system complexity down an order of magnitude.
> I can't see how people think returning 404 for a "this product doesn't exist" is defensible.

Because that fits perfectly the definition of a 404.

> You now have two different things intertwined: this product doesn't exist (generally not a huge deal - what if an end user manually edits the url on your storefront?), and this url makes no sense (a huge deal - something is broken).

Arguably, the "this URL makes no sense" case is a better fit for a 400 [0] rather than a 404 [1], so those two cases need not be conflated even when using a 404 for the "this product doesn't exist" case.

[0]: "The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)."

[1] "The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists."
Social Skills Are Last Line of Defense for Humans Seeking Work
An electric motorcycle company says it was killed off by Apple's poaching
Wyoming has about 580 thousand total population, and no prep schools comparable to the East Coast ones. Its not simply raw intellectual ability. The most qulualified student in each year from that state will most likely find an Ivy League overwhelming. If each such school wants at least one man, one woman from there, it's not going to work.
I've seen SQL code written in this style too.

http://stackoverflow.com/questions/519876/sql-formatting-sta... -- having the comma at the start of the line makes it easier to comment out the line
Comparing Hosted Database Performance
A Statistical Argument for Not Being Nervous on First Dates
> The HN crowd, or any expert community, don’t have any greater a chance of predicting the success of a startup than a more general crowd.

And what 'more general crowd' are you so confidently comparing to, exactly?
Interesting how this article was #1 on HN a few hours ago and mysteriously disappeared.

Conspiracy?
You might not sense anything at forty especially if you're one of these youthful "40 going on 27" types, and the mid 20's people pretty much accept you as one of them. People's stereotypical ideas of what forty looks like doesn't match all the examples of what forty actually looks like.