Reality is not idealism. It would be ideal if people didn't have to care what they were wearing and I don't think people disagree with "that would be a better world".
The keywords are "that would be a better world" compared to "this is the world we live in".
You don't see people going into a ghetto at night wearing a Rolex watch, a 20kt gold chain, a money clip in their suit pocket, and another wad of cash sticking out of their back pocket.
Those sort of people, the kind ignorant of reality, end up being mugged or robbed. While nobody thinks "they deserve to be robbed" people will say "what the fuck was he doing walking into a ghetto wearing $25,000 in jewelry? Of course he was going to get robbed."
Recognizing reality for what it is instead of what people wish it to be is different than victim blaming. People will try to conflate the former for the latter though.
Yes. My opinion on both issues is similar (one party may be to blame for an act, but the other can still be considered as behaving irresponsibly), and I am surprised that my comment has not yet been downvoted to the lowest circle of hell.
If you have two fields in a query, does that mean two resolve functions? If I using a SQL database and the two fields were stored on two columns on the same table, wouldn't that cause 2 SQL queries to be run?
Sangria in Scala has a mechanism called "Deferred" that lets you specify that it should ask you to resolve objects of a certain type all at once at the end, and you would do a single SQL query per object type there.
If the JavaScript implementation doesn't have something like this, perhaps it can be hacked on top.
I'm a big fan of React but it took me a year after its introduction for me to get it and like it. What particularly did the trick for me was one of Pete Hunt's talks he gave a year after release acknowledging the confusion and explaining the reasoning for React rather than just the technology itself.
I feel like GraphQL can be something great and the pain points they identify with typical APIs are stuff I've felt but GraphQL just feels incomplete to me. I feel they're focusing too much on what GraphQL looks like on the client-side and not enough what it looks like on the server-side. The biggest question I have is what's going to process the GraphQL query on the server to fetch the data from the actual datastore? What does that look like when working with typical datastore such as a SQL-based database? The closest thing I've seen that answered that question was this blog post[0] which doesn't look very appealing if that's what the server-side implementation is going to look like. The blog post's implementation looks like a more complicated version of my own APIs which are usually a series of custom endpoints based on my client's needs. I don't see the big deal right now. Maybe next year...
I found this example in the dataloader README useful, as it deals with loading from a SQL-based database, with relationships, which is similar to the first project I'm planning on trying it with:
Pulling data from a datastore is up to you. You can use whatever library you like to pull data in. All you have to do is make your `resolve` methods just return the data.
The GraphQL schema definition is basically an adapter (as in adapter pattern) on top of your datastore(s).
GraphQL means UI components can stand on their own - they work without custom endpoints. And it's faster. You do need to write an adapter between GraphQL and your datastore, which is probably hard today, and probably easier next year, but you only need to pay that cost once.
> The biggest question I have is what's going to process the GraphQL query on the server
It's really not much different from processing a REST-based API request. In theory, you could parse the request and then just execute the necessary SQL to fill out the result.
However, what Facebook's GraphQL library lets you do is define a schema that specifies how each piece of the result is fetched. It's like a declarative API builder. ("GraphQL" is a huge misnomer; it's neither graph-query-oriented, nor is it a query language — it's a protocol.) GraphQL-the-language doesn't make much sense until you look GraphQL-the-library and understand its design.
For example, let's say the GraphQL query is:
query {
story(id: "1") {
text
}
}
Your schema might be declared like this:
const storyType = new GraphQLObjectType({
name: 'Story',
description: 'A story.',
fields() {
id: {
type: new GraphQLNonNull(GraphQLString),
description: 'The ID.',
},
text: {
type: GraphQLString,
description: 'The text.',
}
}
});
const queryType = new GraphQLObjectType({
name: 'Query',
fields() {
story: {
type: storyType,
args: {
id: {
description: 'ID of the story to fetch',
type: new GraphQLNonNull(GraphQLString)
}
},
resolve(root, {id}) {
return SQLDatabase.findStoryById(id)
}
}
}
});
You declare static fields as well as resolver functions that take arguments and are expected to furnish the query with the actual results. You then "execute" the query, which will cause the resolver's to run as they are triggered by parts of the query. For example, if the storyType contains resolvers, any nested queries will invoke them.
I recommend looking at the tests [2] in the GraphQL JS library, because they show some useful examples. There's already a Ruby [1] library for declaring schemas in the same way.
If you're doing SQL underneath, optimizing a GraphQL query into the fewest possible SQL queries might be tricky. For example, let's say each story has an author; doing an author query per story isn't going to cut it; you're going to want to join the authors table. But the outer queryType doesn't know if the query will be asking for the authors. I don't know if the library provides any way to solve this yet.
The docs page delivered 270kb of compressed and minified JavaScript (1MB uncompressed) but sadly didn't seem to show anything with JavaScript disabled. I thought all the hot new React apps were isomorphic nowadays.
This reminds me of morning routine back in grade school called "Mad Minute" where we would be given a sheet containing 30 or 50 simple equations to solve. You'd have to complete it in a minute and the teacher would stopped grading at the first wrong answer so getting the first one wrong follwed by 49 correct answer would net you a score of zero.
When I first transferred to that school I was terrible at it but I did get pretty good at it later on. I think it did a lot for my arithmetic skills.
What is the real harm of not rescinding this guy's internship? Seems punitive and petty. It's not like anyone actually believes that FB cares about privacy. Whatever reputation or brand damage there was done a long time ago by FB's repeated violations of user privacy, which is just the natural state of things given their advertising-based business model.
FB could have turned this around and scored a marketing coup: "look we're hiring the hacker who exposed a security flaw, he'll be patching up the hole he found this summer - because at FB we're committed to user privacy and saving baby harp seals!"
But then again, is this really a big surprise? Just another data point in the growing contradiction between what SV is and what SV wants to be.
> But most people hope that individual Facebook employees have limited strictly audited access to user data.
Any reason to think this is at all the case?
I recall Google getting into trouble over this in the past [1]. I can definitely see data scientists and other employees at FB taking a peek... if anything just finding out who looked at your profile/photos/etc would be pretty tempting.
At this point, FB is just too valuable as a source of intel. I just assume that the US Govt (and others) has direct and easy access. Use at your own risk.
> Way back in 2005, a kid named Chris Putnam wrote a computer virus that rapidly spread across Facebook. [...] Pretty quickly, Facebook's COO, Dustin Moscovitz, was able to figure out Putnam was behind the attack. But instead of having Putnam arrested, Facebook hired him.
> "I will be forever grateful that the company was so sympathetic toward people like myself. It's one of the things that really sets Facebook apart with its passion for scrappy, hacker-type engineers."
Everybody loves a cool hacker persona. Except when it's directed against you :) And, facebook, imo, is more of "get shit done", rather than "break shit". This was more of the latter.
But really, if you work for a company, even if just as an intern, you really should be looking out for their interests. If you aren't, then why would they keep you?
but then, it really isn't a smart PR move from facebook. Now we know that not only do they mess up with privacy big times, but that they're not hiring anyone that wants to raise public awareness on that subject. As if public awareness was detrimental to facebook.
Which it obviously is, but by hiring that personn anyway, and have him work on privacy and ethic inside fb they could have shown some good will.
