John Resig: Introducing the GraphQL Guide - <AUTHOR> https://blog.graphql.guide/introducing-the-graphql-guide-11a5ae48628a <comment><USER2> We deployed our GraphQL July 4th 2016. It'll almost be 2 years. Documentation sucked back then (and apollo was non-existent), so a lot of we had to dig by ourselves.

I hope this book will cover some topics for others that was real head scratchers for us

\- DataLoaders

\- Authentication example

\- Unions and Interfaces are your friend. Use them early.

\- Try to define your custom Scalars early (especially DateTime format)

\- return Connections (edge/node) instead of List cause you probably want to paginate at some point

\- Folder structure (we redid ours 4 times lol)

\- Naming convention (we redid ours 3 times lol)

\- Subscriptions

After 2 years of using it and hacking it, we're still impressed. Once you get past the learning curves and have set conventions, writing GraphQL is a lot faster and better. Define your types, and some custom root queries, and done.

The neatest thing is that we made a schema validator -- compile all the graphql queries from the frontend and mobile, and validate them against the server schema. It really help when we changed folder structure and naming convention to see if we'd break something on the frontend.

I can't vouch for this book yet, but I'll swear my life on GQL. It's been a real game-changer.

<comment><USER3> I'd be curious to hear more on your schema validator. We've been using GQL for a little over a year and have felt some serious pain when doing big shifts in our GQL layer and even just when we're trying to clean out dead code / assess which resources are being used in which FE apps.

<comment><USER2> Sure!

Our implementation is a little bit naive - it doesn't "clean out" or see which resources are being used.

On the frontend:

There's a script that globs all `.graphql` files and compiles them into a list of {query, variables}. This probably could be made better if it was a webpack plugin that compiles this on build time. This was a Friday project so our time was pretty limited. This was honestly good enough since it caught a shitload of bad queries =).

Query contains the graphql query. Variables contains test arguments.

It saves them into a gigantic file (example: [https://gist.github.com/maktouch/074339517a8da5128d62869356b...](https://gist.github.com/maktouch/074339517a8da5128d62869356b75893))

On the GQL server:

We take that file, we parse it, and we loop it and pass it thru the validate function ([https://graphql.org/graphql- js/validation/#validate](https://graphql.org/graphql-js/validation/#validate))

(truncated example: [https://gist.github.com/maktouch/e1a2955dfcca42541a41665a361...](https://gist.github.com/maktouch/e1a2955dfcca42541a41665a361be28b))

Ops:

Frontend and GraphQL are its own Docker image. We build both in parallel. When both succeeds (in building and running their own tests), there's an extra build step that runs this specific test. It does it by taking the gql- queries.json file from the frontend container, adding it to the GraphQL image, and running the validate command.

You can do this by doing multi-stage builds in Docker ([https://docs.docker.com/develop/develop-images/multistage- bu...](https://docs.docker.com/develop/develop-images/multistage-build/#use- multi-stage-builds)). We don't push the resulting image - it's just there for testing.

</comment></comment></comment><comment><USER4> As I often do with new-ish things these days, I've been quietly weighing what degree of investment I want to put into GraphQL for a year or so.

John's vote of confidence means _a lot_ to me. The software industry has lots of abstractions that are different ways of arranging the chairs on the deck, shuffling the work around while providing marginal productivity magnifiers.

jQuery's been somewhat superseded because it isn't an application-organizing framework, but it's still one of the best conceived and fitted abstractions for the problems it was meant to solve I've encountered in the entire time I've worked in software. If the person who conceived it thinks GraphQL yields productivity benefits, then I want to check it out.

<comment><USER5> >John's vote of confidence means a lot to me.

by selling a $80 book?

<comment><USER6> Considering the street cred John has earned for creating jQuery, it says a lot for him to endorse GraphQL and to even write a book about it.

</comment></comment></comment><comment><USER7> Hate to complain about GraphQL in general and not specifically this guide but I ran into to major issues with it and really wanted to like it but ultimately gave up on it until they fix some core issues.

I don't see how I can implement complex object hierarchies that are not rigid. Only list is supported as an unbounded data type and for some reason there is no unbounded map/dictionary data type even with simple restrictions like requiring string key type. There is not even good advice on what key/value pair naming convention should be for all languages. The other is that there is very poor support for more general include/exclude/where filters. The idea being arbitrary complex join/filter clauses to function like sql statement with multiple joins and where clauses. Have to rely on implementation specific conventions like what sequelize does to get that but not for arbitrary object graphs. Solve some of this and it might actually become as powerful as it is frequently claimed to be.

<comment><USER8> I'm a huge fan of GraphQL, and when I see negative feedback that lists some of the points you make, I can't help but think that you are using GraphQL in a way for which it was not designed.

The most common issue I see is when folks list "what about arbitrary complex join/filter clauses to function like sql statement with multiple joins and where clauses" which, in my use of GraphQL, is literally never something I would want. GraphQL is _not_ SQL or designed to be an arbitrary data access layer.

One of the driving principles of GraphQL, taken straight from the spec, is: "Product‐centric: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that."

IMO GraphQL is designed to start with the UI, and develop models that conform to the needs of the UI, _not_ to start with the data and develop arbitrary joining and fetching strategies for that data.

<comment><USER9> Maybe I'm just not that well versed in GraphQL, but reading your comment left me confused.

What would the UI data requirements have to be? Aren't they often arbitrary data fetching driven by the user? Aren't the requirements of views what data the user wants to see and handle? Depending on what user chooses, the fetching of data will have to go deeper and deeper into the data store.

I seem to remember, perhaps mistakenly, that GraphQL came as a solution to fetch arbitrary data structures that the view needed instead of having to mix and match multiple RESTful endpoints.

<comment><USER10> Do your users construct their own UI? Or do they use a set of features provided by whomever built the app/website? The arbitrary data fetching is to allow rapid feature development, bypassing the need to explicitly code up per- feature endpoints. Instead the responsibility is passed to front-end developers to compose per-feature queries.

</comment></comment></comment></comment><comment><USER11> I'm skeptical that this book will ever be finished. The last time I bought an unreleased book authored by John Resig it took two and a half years before it was published. If I remember correctly another author had to take over in order to complete it. I'm super interested in GraphQL, but I wouldn't consider purchasing this ebook until it is 100% complete.

</comment><comment><USER12> Anyone know what framework the book uses (if any)?

I tried doing a GraphQL project in Python/Django recently, using Graphene for the GraphQL bits. I didn't end up getting that far because the documentation was so lacking, as were examples generally (for graphene-python I mean; I could find stuff on GraphQL in the abstract).

I'm thinking about giving it another shot, maybe on node.js this time, largely because I get the impression that the supporting tech for it is more mature there—but I'd love to hear opinions on what the _most_ mature lib for using it is at the moment (whatever language)!

<comment><USER13> Don't give up on Python! The eco-system is young, but it is there. Saturday just gone, I gave a presentation at PyLondinium [1] on "GraphQL in Python" (Slides: [2], video to follow). For the purpose of the presentation, I put together a simple server example [3].

[1]: [https://pylondinium.org/](https://pylondinium.org/) [2]: [https://alexchamberlain.github.io/presentation- pylondinium-g...](https://alexchamberlain.github.io/presentation-pylondinium- graphql-in-python/#/) [3]: [https://github.com/alexchamberlain/city- api/](https://github.com/alexchamberlain/city-api/)

<comment><USER14> The ecosystem is young?

Python is older than HTML, CSS, JavaScript, PHP, Java, C#, etc.

<comment><USER15> He means the Python+GraphQL ecosystem – and he's right, Graphene-Python and graphql-core are still evolving and changing their interfaces, and there's essentially no useful documentation beyond trivial examples.

</comment></comment></comment></comment><comment><USER16> Why spend time building an API at all? Just point Postgrest at your PostreSQL database and you get a REST api for free. There's similar projects for graphql and other DBs.

<comment><USER17> Isn't GraphQL intended to be used directly by the frontend app (with direct access by any potential malicious user), whereas Postgrest is more for a backend app, that can be trusted with more control?

<comment><USER18> There's nothing in PostgREST that stops you from limiting control so that even anonymous users can use it safely. I've used PostgREST for user-facing APIs with success, but it requires some knowledge about the postgres access control model.

EDIT: And "Just point Postgrest at your PostreSQL database" is rarely a good idea in my experience, I usually have (versioned) API-schemas containing views, so that I can change my underlying data schema at will without borking the API.

<comment><USER17> Anonymous seems easier, since you can treat them as a single user. But could you do something like HN as a frontend app talking directly to a Postgrest API?

<comment><USER18> Good point, that's true. But yes you could, using row-level security. See [https://www.postgresql.org/docs/current/static/ddl- rowsecuri...](https://www.postgresql.org/docs/current/static/ddl- rowsecurity.html) and [https://postgrest.org/en/v4.4/auth.html#users-and- groups](https://postgrest.org/en/v4.4/auth.html#users-and-groups)

</comment></comment></comment></comment></comment><comment><USER19> Call me old school but i like my books printed and with on-demand printing services its not conplicated for a publisher. Can't read hundreds of pages on a screen...

But without seeing the content the pricing looks insane. It has to be worlds better than online resources for 289$ (!).

<comment><USER20> The 39$ version would be closest to an actual book. You get every chapter once the book is finished, and that's that.

The more expensive versions include updates and additional features.

<comment><USER21> Every chapter except the extra chapters included in the more expensive options.

</comment></comment></comment><comment><USER22> Once you pay $39 you have to Github OAuth to receive the book. Currently, there are no other authentication options.

Just an FYI as I didn't know that before I had paid.

</comment><comment><USER23> I want to buy it but feel annoyed by these payment options.

      Tier 1: $39 - Full book when released and early access
      Tier 2: $89 - Tier 1 + updates for 2 years + extra chapters
      Tier 3: $289 - Tier 2 + free updates for life + more extra chapters

This is an oversimplification with only the things I care about. The actual packages include more stuff. What really annoys me is why would you call tier 1 the full book and say tier 2/3 has "extra chapters".

I just want all the chapters + early access + updates (2 years is fine). And I want to pay less than $100. Am I being too entitled? Buying books used to be simpler.

<comment><USER24> Yes, it's like some horrible IAP concept for books.

Normally a technical book costs around 40-60 EUR and one gets _all_ the chapters. Updates are called "editions" and are published when there's demand and the information has become outdated.

<comment><USER25> Also "free updates for life" usually means free updates for several years and then "new product" is released with entirely new pricing and "old product" is deprecated. New and old here being a different revisions of the same thing.

<comment><USER23> Usually yes. There are some exceptions with technologies that evolve a lot. The free update feature of the ng-book 2 for instance really paid off for me. But that was included in all the "Tiers" for free, it was a $39 book.

</comment></comment></comment></comment><comment><USER26> > The end result is a vastly simplified backend

GraphQL specs offer none to zero of the following:

\- caching

\- authentication, authorization and handling data access

\- protections against ad-hoc arbitrarily nested and complex queries

\- routing

How does this "vastly simplify the backend"? If anything, it makes the backend hideously complex (IIRC Apollo's approach to caching is parsing requests and responses every time, do some magic, and handle caching manually).

</comment><comment><USER27> The author and his introduction definitely has a compelling story to tell. It is making re-think our recent strategy shift in which we evaluated GRPC and GraphQL. We chose GRPC but I'm starting to see that it's not really any better than REST + Swagger. I think I might need to actually just go ahead and buy this book and re-think if the GRPC route is worth it. Our investment in Grpc at this point has been slow - mostly because I figured the Grpc-Web project would be moving a lot faster by now. It's not and I don't see the team doubling down, whereas it looks like Apollo and GraphQL seems... ready now.

Edit: Does anyone know if he goes over typescript?

<comment><USER10> When I interviewed at Improbable (authors of gRPC Web) last year, we spoke a little about gRPC and GraphQL. The interviewer didn't really explain their choice beyond the fact that half the company came from Google and were already fans of gRPC.

</comment></comment><comment><USER28> If nothing else, the conversation around this has shown that applying a subscription-based, tiered pricing model to a book is not appreciated by the consumers.

<comment><USER29> I think it's against the usual expectation for a book. If they had split it into volumes then it would have matched better people's expectations. Also the videos and extra should be part of a course package. Messaging just make it sound like you are getting short changed.

</comment></comment><comment><USER30> I think he is making a mistake selling this as a book. These prices just don't work for a book.

He should be selling it as a knowledge community. Members get access to the resources, conversations, training, etc.

Add levels of membership that have to be earned through merit somehow and membership at a higher level becomes valuable on the CV.

</comment><comment><USER31> Why is rate limiting only part of the $289 package?

Edit: And wasn't it cheaper earlier? I was pretty sure it was $29 for the basic version, maybe that rounding up market trick got me.

</comment><comment><USER32> Good on him to be so flexible- I don't know that much about John Resig, but he was clearly a pioneer with jquery+rest, so it's great to see him being equally enthusiastic about a project based on graph query languages and React, arguably replacements for this earlier tech!

<comment><USER33> REST was Roy Fielding but I agree. Much like the concept of Apache Cordova, the best jquery would be no jquery at all.

<comment><USER34> John didn't invent REST (nor AJAX), however jQuery made it feasible and easy for people to use.

Yes, you're right, the best jQuery would be no jQuery. jQuery was basically a prototype for the next generation of browser features.

<comment><USER35> It didn't encourage REST either. It provided $.post but not $.del (since delete is a keyword in JavaScript) so one could even say it went against REST. I think it was orthogonal to REST, though.

Here's the docs for jQuery 1.3 from when REST was starting to take off, with jQuery.post but no delete method: [https://api.jquery.com/category/ajax/shorthand- methods/](https://api.jquery.com/category/ajax/shorthand-methods/)

<comment><USER36> It provided $.ajax({method: "DELETE"}) however... so...

<comment><USER37> Making a DELETE XHR was never the issue, browser support was. It's an issue that was impossible to paper over with a JS library alone, you needed backend integration. That's why Rails and similar frameworks at the time spoofed DELETE and PUT requests by creating a POST request with a special param set.

<comment><USER36> All browsers supported the verbs for _years_. IE7 had mostly full support (not PATCH though, annoyingly).

The problem was mostly backend related: most _servers_ didn't support them. DELETE for example has been supported for over 12 years in all major browsers.

<comment><USER37> Ah, interesting, my memory is dusty. Now that I think about it, the limitations of <FORM> were front and center too: A Rails app wanted a "delete $X" page that didn't rely on JS, and the only way that was going to happen was with a <FORM>, which only supports GET and POST methods.

<comment><USER36> Ah well yes. That's quite intentional of course but yeah, an architectural limitation of that Rails app.

Of course until ~v3 Rails didn't fully support all verbs so...

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER38> > GraphQL offers a way to push all of the logic for specifying data > requirements onto the client, and in return, the server will execute the > (highly structured) data query against a known schema. The end result is a > vastly simplified backend that also empowers the client to execute whichever > queries they need.

Why is empowering the client a good thing?

Why is moving complexity from the backend to the front end a good thing?

<comment><USER39> Because you can have one server efficiently servicing multiple clients with different, unanticipated needs.

<comment><USER38> So, reducing server load?

OTOH if the complexity is offset to the client, and you have multiple clients, then there is more complexity. No?

(assuming you have multiples types of clients)

<comment><USER40> But the client already had to consider what data it needed.

The only difference is that in a REST world it needed to make several calls to fetch all the data (often waiting for resource references in the nth response before being able to build the (n+1)th query) whereas now it can fetch them all in a single query.

So if anything it reduces the client complexity, as well as making it much easier to extend the API to support new client requirements without having to resort to REST-style versioning.

</comment></comment></comment></comment><comment><USER41> Why is all the GraphQL documentation so tightly coupled with either Apollo or Relay? Apollo doesn't work nice with a non-react setup (imhe), not to start about Relay itself. All the Relay server side stuff makes the client also really boilerplaty. I don't think i'd buy this book, since it's also apollo stained.

Does someone have good resources on how to use vanilla GraphQL without the bloated Apollo/Relay stuff?

I'm currently working on a GraphQL server (using Graphene), and thankfully I'm able to not use Relay (with which it tightly integrates). So I'm able to implement my own pagination and filters.

<comment><USER10> Relay (Modern) doesn't require _any_ of the Relay-specific schema patterns. But most of them (connections, the node interface) are useful enough to want to use anyway.

That said, I agree that too much of the documentation/articles/tutorials about how to use GraphQL assumes using a particular implementation. I'm far more interested in talking about higher-level concerns like best practices and data modelling.

</comment></comment><comment><USER42> Is Apollo the be all end all GraphQL client these days? I tried it roughly 1.5 years ago and was turned off by all the component wrapping.

Is it bad form to just fetch data via GraphQL and put it in Redux (or other store)?

I'd like to buy in, but I'd like to keep my data fetching separate from my view layer if possible.

<comment><USER2> While transitioning away from Redux, we actually fetched Data via GraphQL and put it in stores.

Honestly, it was a pain, but it's because we abused Redux.

We progressed by doing the HOC and bypassing Redux but it still was a pain, because HOC.

We're now at a stage where we updated Apollo versions, and started converting to the Query components. It feels and work a lot better.

When we started, we thought the same thing -- keeping data fetching separate from the view layer if possible. We realised that it didn't make that much sense. Keeping everything in React components is a lot more maintainable and easier to comprehend.

</comment></comment><comment><USER43> Adopters of GraphQL are quick to call it game-changing, but is it a game worth playing? It has to add value above the standards already in place. Is it accomplishing that? How is it more valuable than whatever it is that it replaces (REST, whatever)?

<comment><USER44> I think I came to this conclusion the other day: GraphQL truly shines when the variation of ways that you want to access data is significantly more complex than the complexity of the stored data. In other words, if you want to look at 10 tables in a twenty or forty or more different views (counting the times when a view is composed into another), then I believe using GraphQL will begin to show order of magnitude efficiency rewards.

If the number of views is only slightly more than the number of tables then the rewards are more a matter of taste. It will give you a nice typed interface to your data and an interactive query GUI. But other tools provide that as well.

<comment><USER26> > if you want to look at 10 tables in a twenty or forty or more different > views (counting the times when a view is composed into another), then I > believe using GraphQL will begin to show order of magnitude efficiency > rewards.

How will it show order of magnitude efficiency?!!

It means that you will have 20-40 views towards a database that only contains 10 tables. Which will inevitably result in highly inefficient queries towards said database. _Especially_ if a view is composed into another.

There's no magic in GraphQL that suddenly makes that go away.

<comment><USER45> Imagine you have a cross-platform app with multiple teams. You have a lot of data-driven components like different feed types. You want to avoid situations that change in backed API needs to be synced with every team/app. You want to give power to app developers to define efficient queries.

Unless you develop multiple apps or data-driven application there is very little reason to use GraphQL. Personally, I am in favor of building two APIs: public/third party REST and JSON-RPC for the frontend. Getting REST right is difficult and after you create your resources your frontend needs to workaround incomplete/superfluous data.

<comment><USER26> This doesn't answer my question :) You still have 10 tables, and you still have 40 ineffecient ad-hoc views into that database.

Why is it that any text, and post, and comment about GraphQL focused on client-side only and completely ignores any questions about server-side?

<comment><USER45> Because your source data will be like 10 tables. But your frontend needs to access this data in different ways (views). There no way to design your database to support all possible queries in an efficient way. With complex queries even caching become tricky.

      user(id = 6) -> with ('comments') -> with ('votes')

ORM - create a complex query that hit three tables. There is no way to represent this as proper REST service (/userNameWithCommentsVotes - resource). You end up with REST resources that accept a lot query params. Each endpoint will create coupling to both data storage and consumer (front-end).

      User (id = 6) {
        name
        comments {
          votes: {
             up
             down
           }
         }
      }

GraphQL shift data access towards the client. It will make multiple DB queries but it will be trivially cached using Dataloader pattern. You hit DB more with simple queries but you don't muddle you data schema with ad-hock views/queries.

People start with pretty REST and normalized Database, then frontend and third-party requirements demolish this to another "Paypal API". I am not saying that GraphQL is a silver bullet, you need to structure your frontend application Graph as well and complex conditional queries are difficult to express.

<comment><USER26> > ORM - create a complex query that hit three tables.

1\. ORM isn't a requirement for REST

2\. A REST endpoint will execute a highly specialised query that will hit all the right database indices and will return just the dataset required in one roundtrip to the database.

And since it's a known quantity, it will benefit from: hot db indices and caches, intermediate caches, and even HTTP caches (because GET requests are both idempotent and cacheable, for example).

Meanwhile with GraphQL your server will have execute what's essentially `SELECT <all>` three times (otherwise your "dataloader" won't be able to cache data for more complex queries) and do all the filtering and joins in-memory in-code.

> GraphQL shift data access towards the client.

Hahahha wat? The client has no access to data. The only thing it does is send a query request to the server. The _server_ will parse the query. The _server_ will request data from the database (multiple times). The _server_ will end up joining, filtering out, caching, figuring out proper auth access to, etc. etc. to data.

And only then will that data will be returned to the client in the form that the client requested. The client has no access to data. The only thing that the client can do is ad-hoc potentially non-perfromant queries to the server.

> You hit DB more with simple queries but you don't muddle you data schema > with ad-hock views/queries.

Yup. You only muddle your code with those queries (the code needs to find a way to compose/filter out/etc. etc. etc. the data for the ad-hoc queries from the client). And you only do multiple redundant and expensive trips to the database (what happens when the DB is sharded, and some data required for the query lies in a different shard? What happens when connections are slow/interrupted? etc. etc.)

> it will be trivially cached using Dataloader pattern.

No it won't. Dataloader only caches some data during one request. On the next request you will do the same: expensive multiple roundtrips to the database.

Oh. By the way. Remember how you dismissed ORM? Well, your dataloaders and data resolvers (and whatever other new lingo GraphQL came up with) is nothing but a very limited and inefficient ORM.

<comment><USER45> > A REST endpoint will execute a highly specialised query that will hit all > the right database indices and will return just the dataset required in one > roundtrip to the database.

Each time you need to have a new highly specialized query you create REST resource. That why I prefer to be honest and just make RPC call.

> Meanwhile with GraphQL your server will have execute what's essentially > `SELECT <all>` three times (otherwise your "dataloader" won't be able to > cache data for more complex queries) and do all the filtering and joins in- > memory in-code.

That fine, because easy cache invalidation is worth it. You will find that REST complex endpoints will take cache the same data multiple times.

> Hahahha wat? The client has no access to data. The only thing it does is > send a query request to the server. The server will parse the query. The > server will request data from the database (multiple times). The server will > end up joining, filtering out, caching, figuring out proper auth access to, > etc. etc. to data.

I said data access, not data. The benefit of GraphQL materializes when you have multiple client application that targets same backend data store. You describe your data schema and clients can figure out what data they need.

> Yup. You only muddle your code with those queries (the code needs to find a > way to compose/filter out/etc. etc. etc. the data for the ad-hoc queries > from the client). And you only do multiple redundant and expensive trips to > the database (what happens when the DB is sharded, and some data required > for the query lies in a different shard? What happens when connections are > slow/interrupted? etc. etc.)

You have cache. Having only one copy of user in the cache is super important. GraphQL is not creating expensive queries. With GraphQL it is easier to shard your DB because you will have less joins.

> No it won't. Dataloader only caches some data during one request. On the > next request you will do the same: expensive multiple roundtrips to the > database.

Dataloader supports any Cache backend. In production, you will use something like Redis. Whole point dataloader is to cache between requests. Its supports cache invalidation as well.

> Oh. By the way. Remember how you dismissed ORM? Well, your dataloaders and > data resolvers (and whatever other new lingo GraphQL came up with) is > nothing but a very limited and inefficient ORM.

No, they are query interface. They expose DSL for accessing data. Mapping is something that can be done in Relay.

<comment><USER26> > Each time you need to have a new highly specialized query you create REST > resource.

I love it how you meander. First you where complaining about ORM creating complex queries. When I countered with the simple fact that you don't need ORM, and "complex queries" are highly specialised efficient queries that take full advantage of DB capabilities, you immediately go off on a tangent talking about RPCs.

:-\

> That fine, because easy cache invalidation is worth it.

No it's not fine. Because instead of retrieving a simple single highly optimised dataset in one go you do multiple inefficient roundtrips to the database.

> I said data access, not data.

access. /ˈaksɛs/ 2\. obtain or retrieve (computer data or a file).

All data access happens on the server through inefficient database queries and in-memory juggling of data. Clients have no access to data, they send queries.

> Whole point dataloader is to cache between requests.

Dataloader (in it's original form and specification) doesn't cache between requests.

 _DataLoader provides a memoization cache for all loads which occur in a single request to your application._

 _DataLoader caching does not replace Redis, Memcache, or any other shared application-level cache. DataLoader is first and foremost a data loading mechanism, and its cache only serves the purpose of not repeatedly loading the same data in the context of a single request to your Application._

If any other Dataloader implementation implements caching between requests, they are just reinvent the wheel.

> No, they are query interface. They expose DSL for accessing data.

ORM is a DSL at it's core. And that's what "dataloaders" and "resolvers" in essence are: ORMs.

To quote from Apollo:

 _In order to respond to queries, a schema needs to have resolve functions for all fields._

        const resolverMap = {
          Query: {
            author(obj, args, context, info) {
              return find(authors, { id: args.id });
            },
          },
          Author: {
            posts(author) {
              return filter(posts, { authorId: author.id });
            },
          },
        };

Oh look. A wild ORM appears! Oh look how it quickly devolves into multiple DB roundtrips for any non-trivial query.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER46> I hope John will divide up the book later.

I am interested, but as a guy working more on backend systems, frontend and mobile will not help me very much. I don't want to pay $40 for majority of content I cannot make use of.

<comment><USER47> It isn't $40 for content you don't use; it's $40 for the content you do use.

</comment></comment><comment><USER48> While GraphQL has it uses, i can't seem to see how putting the query logic in your frontend is a good thing:

How do you control scaling, and writing performant queries? When you make an API endpoint you have control over the queries you make and how you make them.

With GraphQL you lose that control right? Maybe its good for internal projects, where you own the client and server. But often just exposing the internal DB directly to GraphQL is probably not a good idea. Maybe writing the DataLoaders yourself is better. But then you are already close to the effort of writing a simple endpoint.

For simple API's graphql seems like overkill.

<comment><AUTHOR> With GraphQL you have the flexibility to utilize both REST and RPC patterns, with the added benefit of a type system and ability to choose the fields returned on the client. You can write common CRUD queries/mutations similar to how you would with REST (allUsers/allProjects. If you have a query that you know ahead of time will be inefficient, you can add in a more RPC or dedicated endpoint style query that you can optimize how you see fit on backend (getAllCrazyThings(filters) etc).

For the performance aspect, check out Apollo Engine, which allows you to track the latency and implications of using different fields within your queries and mutations over time:

[https://www.apollographql.com/docs/engine/performance.html](https://www.apollographql.com/docs/engine/performance.html)

</comment></comment><comment><USER49> One of the problems I've noticed while using GraphQL (late last year) was that although there are 'officially supported' libraries in a number of languages, there isn't really feature parity between them. In particular, I remember that the Ruby implementation we were using required manually parsing the AST to do fairly basic operations described in the spec. I wonder if this situation has improved in the last few months.

</comment><comment><USER50> Looks nice but why would I use GraphQL over JSON queries to a simple document database directly?

I guess it comes down to how important schemas are to you. Which I know suggesting they might not be important sometimes is for some people a sin punishible by death. But for me that's a belief system that doesn't hold up for everyones application.

</comment><comment><USER51> Why should I use Facebook's GraphQL over OData which is an ISO standard? I've found a few comparisons but I'm curious what the HN crowd has to say.

<comment><USER29> Feels like GraphQL has more momentum behind it now than OData. OData seems to have suffered from the fact that it originated in the .Net world which is pretty much ignored by those outside of it.

</comment></comment><comment><USER21> So let me get this straight.

For the low price of $39 I will get the full book in ebook and HTML formats when it is done.

But for the price of $89 I will get extra chapters on Server-side rendering, Offline data and mutations, Serverless and Stripe integration.

So I am clearly not getting the full book for $39.

I just recently refused to buy a game for employing the same dishonest sales tactics, so this is an easy no thanks from me.

<comment><USER52> Honestly, I think people will disagree with me on this (due to some vague "you don't have to buy it" argument), but it's just too dishonest to me. This is possibly the biggest rip-off in pricing of any technical book I've ever seen.

If you pay $39 you get 8 fewer chapters than the _actual_ full book. And it's online only, so no paper printing or publisher overhead. For $89 you get a video and some extra chapters (that really should be in the book you paid for in the first place). If you pay $289 (which is an absolute _absurd_ price for any book) you get exactly what you used to get with books 10 years ago: a book with all its intended chapters, a mailing list, a glorified IRC channel and a code repo. Except, again, it's still not even a physical book (so why so expensive?).

If you pay the "Training" package ($749) you supposedly get superior in-person mentoring. Except it's not really done by the authors. It all sounds like some Tai Lopez scam.

I don't want to diminish the amount of work it took to make this book, or the quality of the authors. I'm sure it's incredible and it seems a pretty massive book. But I just don't understand these sort of things when it comes to professional programmers who write books. Supposedly they want to spread this technology they care about and want people to use it. We as programmers get paid very well, we're not in need of money. Book revenue is probably not their main source of income. So why price it out of everyone's range? You're not gonna reach nearly as many people as just selling it at a reasonable price.

<comment><USER53> I'll preface this with the fact that I completely agree with your sentiment.

> it's still not even a physical book (so why so expensive?)

I have never written or published a book, but my understanding is that the cost of writing the book far outweighs the cost of actually printing it. Human time and knowledge is way more costly than some paper and the effort of a machine that spits out books by the second.

> If you pay $289 (which is an absolute absurd price for any book)

This offer and especially the in-person one seem like they are targeting businesses. A lot of places will pay orders of magnitude more to have someone work directly with their employees.

Honestly, about $93/hour is on the cheap side for in-person training. (I'm not saying it's _good_ training or even close to worth it, just what the landscape looks like)

Edit: actually, it would be cheaper than $93/hour since I'm not taking the other things into account. Let's say the book and all the other stuff realistically make up about $150 of the price (I am guessing the $289 is just trying to get you to buy one of the surrounding tiers). That's actually $75/hour for the training.

<comment><USER52> > I have never written or published a book, but my understanding is that the > cost of writing the book far outweighs the cost of actually printing it. > Human time and knowledge is way more costly than some paper and the effort > of a machine that spits out books by the second.

Usually physical books are said to be expensive because publishers are the ones holding the rights to them. They pay the authors in advance and try to recoup the cost later, with prices as high as the market will bear. The publishers have some fixed overhead in payroll (for editing, typography, art), printing, marketing, etc. Add to that the risk of the book not being finished by the author and the publisher's profit margin and it goes some ways to justify their pricing (or at least it makes it understandable). The authors then get only a slim percentage of the sales (if at all).

In this case the book isn't even finished, the full proceeds go to the authors (or so it seems) and the readers are expected to advance the money themselves to offset the costs of writing it. The overhead is vastly diminished, there's no publisher, the authors incur no risk, and yet the price is much higher. Makes no sense.</comment></comment></comment></comment>


Let's make sure Heartbleed doesn't happen again. - <AUTHOR> https://www.crowdtilt.com/campaigns/lets-make-sure-heartbleed-doesnt-happen-again

<comment><USER2> >100% of the proceeds will be offered to security researchers. Any leftover funds will be passed on to the OpenSSL Software Foundation. Bugcrowd will administer the bounty at it's own expense.

While I applaud these kinds of efforts, shouldn't there be a single point of focus (i.e. the OpenSSL Software Foundation) for fundraising?</comment>


The Law of Leaky Abstractions (2002) - <AUTHOR> http://www.joelonsoftware.com/articles/LeakyAbstractions.html <comment><USER2> Note that there was a lot of interesting discussion of this article a year ago:

[https://news.ycombinator.com/item?id=6926892](https://news.ycombinator.com/item?id=6926892)</comment>


Growth mindset study finds no impact on student performance (n=5018) - <AUTHOR> https://www.tes.com/news/exclusive-growth-mindset-lessons-had-no-impact <comment><USER2> Note that this does not contradict previous studies, because they did different things. In other words, this is not a replication failure. To quote:

"We have never (or at least not yet) conducted a mindset research programme aimed at teachers" and "All of our studies to date have been directly aimed at students". That is, teaching students growth mindset works. Teaching teachers to teach students growth mindset didn't work.

Also "we have a large study with a nationally representative sample of 9th grade students coming out in Nature next month". Large studies are good, so I eagerly wait for this larger study of direct-to-students programme.

</comment><comment><USER3> The pervasiveness of growth mindset theory is one potential explanation for the absence of a measurable impact of the intervention: for example, over a third of teachers in comparison schools had previously attended training days based on growth mindset interventions. However, while many staff members were aware of similar approaches prior to their involvement in the project, few said they had used these within their own teaching practices. Due to the ubiquitous nature of growth mindset, it may be hard to find schools for future research where awareness of the concept is low.

</comment><comment><USER4> [https://educationendowmentfoundation.org.uk/projects-and- eva...](https://educationendowmentfoundation.org.uk/projects-and- evaluation/projects/changing-mindset-2015)

Evaluation Report - [https://educationendowmentfoundation.org.uk/public/files/Pro...](https://educationendowmentfoundation.org.uk/public/files/Projects/Evaluation_Reports/Changing_Mindsets.pdf)

</comment><comment><USER5> more meta-analysis literature, open, N=350,000: To What Extent and Under Which Circumstances Are Growth Mind-Sets Important to Academic Achievement? Two Meta-Analyses Victoria F. Sisk1, Alexander P. Burgoyne2, Jingze Sun1, Jennifer L. Butler1, and Brooke N. Macnamara1

<comment><AUTHOR> Ref: [https://doi.org/10.1177%2F0956797617739704](https://doi.org/10.1177%2F0956797617739704)

</comment></comment><comment><USER6> My poor son suffered through this pointless garbage. The only real lesson here was how to give the BS answers that the teachers required and move on with life.

<comment><AUTHOR> Caveat: I don't know the technicalities of the original method/research and am merely familiar with it through the media and business world hype.

I wonder why a lot of things like this have to be marketed as "going to change everything" silver bullets.

I'm all for teaching people the value of practice and persistent work at improving instead of putting it all down to talent or just innately being smart or not, but turning it into "you can achieve anything you set your mind to if you just want it enough and work hard enough" looks like a flat-out denial of any sort of differences in underlying abilities which is not going to do anyone any favors.

</comment></comment><comment><USER7> I'm pretty sure the biggest thing that will help students is not having to work full time to pay rent while they're trying to pass courses..</comment>


Zimbra to serve email to Comcast customers - <AUTHOR> http://www.techcrunch.com/2007/05/06/twelve-million-new-customers-for-zimbra-partnership-with-comcast/ <comment><AUTHOR> This is kind of big, I think. I haven't heard of deals of this magnitude happening with the Google Hosted Services/Gmail stuff.

If more ISP's follow Comcast's example, Zimbra could be in a great situation.</comment>


Study: More women than teenage boys are gamers - <AUTHOR> http://www.washingtonpost.com/news/morning-mix/wp/2014/08/22/adult-women-gamers-outnumber-teenage-boys/ <comment><USER2> Oh look at that, using the term "gamer" to mean anyone that has played _a_ game within a certain time-frame. Sorry, opening up Candy Crush does not make you a gamer.

What's been interesting to see is how little media coverage The Fine Young Capitalists [1] have gotten for doing a game development project specifically aimed at getting more women into game development.

[1] [http://www.thefineyoungcapitalists.com/](http://www.thefineyoungcapitalists.com/)

<comment><USER3> Yes, it's almost as if a certain imageboard took what could have been a legitimate issue and enthusiastically crapped all over it the way it usually does, stealing all the oxygen away from the story.

<comment><USER2> Wait, what image board? I never mentioned anything like that. They launched their original campaign months and months ago, but were harassed. That's what I'm talking about, the initial campaign.

<comment><USER3> Sorry... I meant /v/ and the whole Zoe Quinn/GamerGate thing.</comment></comment></comment></comment>


Fitbit Stopped Supporting Developers - <AUTHOR> Fitbit has a vast community of developers who design beautiful watchfaces and apps for their smartwatches. But it's been over 2 months pretty much all of the developers are not getting single watchface approved, and every single one of them is getting an email about being patient upon asking support team.<p>Reference (Scroll to bottom):
https://community.fitbit.com/t5/SDK-Development/App-Gallery-Reviews-update/td-p/4126107/highlight/false <comment><USER2> I'd think they are having resourcing issues, staff is multiple companies are having issues due to the covid situation. Even google is not approving new AdSense accounts due to that. Or they are planning on moving to wear os, and screw all of them</comment>


The Challenger Explosion, 30 Years Later - <AUTHOR> http://www.nytimes.com/interactive/2016/01/29/science/space/challenger-explosion-30-year-anniversary.html <comment><USER2> So painful to be reminded --

"Mrs. McAuliffe, a high school teacher from Concord, N.H., won a nationwide competition to go on the Challenger mission and was going to broadcast two lessons from space to students around the country. She was married to Steven McAuliffe, and the couple had two children; the three of them, plus her parents and hundreds of students from Concord, gathered in Florida to watch the launch. Schools across the United States tuned in to a live broadcast."</comment>


Humanity Struggles With Augmentation Addiction in Mind-Blowing Deus Ex Trailer - <AUTHOR> http://singularityhub.com/2011/07/30/humanity-struggles-with-augmentation-addiction-in-mind-blowing-deus-ex-trailer/ <comment><USER2> Awesome.

But I never know which side to root for with these things. Too much time spent thinking about how to build it!</comment>


How to Kill Your Servers - Learning How to Scale the Hard Way - <AUTHOR> http://highscalability.com/blog/2010/8/23/6-ways-to-kill-your-servers-learning-how-to-scale-the-hard-w.html

<comment><USER2> Wait... how about, "Stress-test before the changeover so that you see the bottlenecks before your customer does?"

<comment><USER3> Agreed, _but_ note that at high scale, stress-testing isn't as easy as it sounds.

For example, at an ad-serving company I worked with, stress-testing the ad servers required a botnet of hundreds of machines in order to approximate the load of millions of real users.

The hardware required to run a stress test can easily be 25% or 50% the hardware required to run your production environment. It's not just a workstation with JMeter.

<comment><USER4> Amazon EC2 is a great place to get of load simulators.

<comment><USER5> The author said "a few years ago". I presume it was before cloud was available.

</comment></comment></comment></comment><comment><USER6> Lesson #0: scalability is not a problem that can be solved exclusively in software.

Hire a sysadmin. And take his advice.

<comment><AUTHOR> Lesson #0.1 make sure she has experience with high load situations.

<comment><USER7> Everyone has to learn at some point.

</comment></comment></comment><comment><USER8> I'd KILL to have scalability issues... we had one band that said they were likely to sell several hundred thousand copies of their single using BitBuffet, which got me all excited, but that never came to pass. I honestly believed it might happen because: 1) they were donating the money to charity, 2) it was pay-what-you-want, and 3) they were pretty well known.

I was actually a little sad he didn't kill my cute little Linode server...

</comment><comment><USER9> I'm a pretty big noob in the scaling world, but as I read the article I kept thinking, "With services out there like Heroku, isn't scaling something of a solved problem (at least with a Rails app)?" Do web startups still manually handle the scaling process?

<comment><USER10> Well one reason is that Heroku and the likes don't allow for all possible options and configurations you might run into. If your app requires some obscure back end software then you kind of have to host (at least part of) it yourself.

</comment></comment><comment><USER11> "Almost all programming can be viewed as an exercise in caching." --Terje Mathisen

</comment><comment><USER12> "... and your servers will DIE!"

Di diyanu, di diyanu, di diyanu, diyanu, diyanu!

<comment><USER13> <http://en.wikipedia.org/wiki/Dayenu></comment></comment>


Ask HN: What sites do you have pinned as an App Tab in your browser? - <AUTHOR>

Currently I have the following as "App Tab"s in FireFox
Gmail for Email/Gchat, Mint.com for keeping an eye on my money & Hootsuite to keep up with Social Networks
Anything I'm working on is just a regular tab.
This keeps me focused on the tasks at hand, but reminds me to stay on top of email, money & social tasks.
I've gone back and forth between a few other pinned tabs, but have slimmed down to the 3 above to cut down on FireFox going insane on consuming memory + to keep me focused/
Curious what my fellow HNers have pinned. <comment><USER2> In Chrome I normally keep imo as a pinned tab. Gmail and Google Voice on occassion, but not very regularly. I don't keep those tabs open as much as I used to because I have a notifier and I like preserving the cpu cycles and ram.</comment>


The number of Ruby developers just increased by 20 - <AUTHOR> http://thenextweb.com/dd/2012/03/31/dev-bootcamp-in-san-francisco-just-increased-the-number-of-ruby-devs-by-20/

<comment><USER2> I'd love something like this for someone who has already worked in web development. Super intense course to learn the ins and outs and pitfalls/strengths of a new language. That means you may be able to shorten it up as well.

I did a week long intensive course on Oracle DB optimization, and it's helped me more than probably anything else I've done. Transfer to general related db theory, and helps you understand how it all works at the core. Would love something like this for languages to switch/broad horizons.

</comment><comment><USER3> I'm one of the graduating students, and I'm more than happy to answer any questions about the program. It has been an intense and emotional journey, and I've loved every second of it.

</comment><comment><USER4> I also was one of the students at Dev Bootcamp, I came in with some previous development experience (non Ruby), and it was amazing/well worth it. I'd highly recommend it.

</comment><comment><USER5> This looks amazing. I want in

<comment><USER6> Hey sonic, I just graduated from the course. If you're interested in learning more about it, feel free to contact me.

</comment></comment><comment><USER7> Absolutely incredible!</comment>


Journey into the World's First Underwater Farm - <AUTHOR> https://www.atlasobscura.com/articles/are-there-underwater-farms <comment><USER2> Not what I was expecting at all. I was expecting something more akin to kelp farming as recently described on a 60 Minutes episode: [https://www.cbsnews.com/news/seaweed-farming-and-its- surpris...](https://www.cbsnews.com/news/seaweed-farming-and-its-surprising- benefits/)

Growing conventional crops underwater seems like a non-starter idea if you need to create a walled-off environment for them to grow. What makes more sense is to find plants that can grow in salty water and feed off the natural environment.

</comment><comment><USER3> > During winter months or cloudy days, artificial light from LED lamps placed > inside the spheres supplements the natural light

I have also wondered about living under water and farming there. However, this made me cringe. I'd like to see less interference/pollution in the ocean, not more. Especially as the owner of a dive shop, I would expect some more reverence for marine life.

</comment><comment><USER4> I wonder if this holds lessons for farming in space? They're both rather closed environments, though the sea obviously provides extra water (and more). There won't be cloudy days in space!

For those worried about negative environmental effects of structures on the seafloor, people actually sink old ships to create artificial reefs: [https://oceanservice.noaa.gov/facts/artificial- reef.html](https://oceanservice.noaa.gov/facts/artificial-reef.html)

Though if this was industrialized too much, I bet delivering a bunch of chemical fertilizers probably would create environmental problems.

</comment><comment><USER5> Obviously not useful to grow land plants in these sorts of domes for useful crop yields in general. Ignoring the complexity and cost, at 22 feet you've lost most of the red spectrum and are starting to lose orange and yellow. That's a big penalty on the available energy. Maaaaybe for some weird pharma thing?

However it's probably(?) a pretty interesting and cheap experiment area.

<comment><USER6> It is useful, you don't need to worry about insects and infectious diseases. Most pesticides are damaging to the surrounding ecology. Moreover, with the way industrial farming is currently done, most plants are genetically similar to each other. This means that if a bacterial outbreak were to occur, it could potentially wipe out many crops. In an enclosed environment, you eliminate these things. Although, you could still do it in a green house.

</comment></comment><comment><USER7> As a question, "can we grow land plants under water?" I think it is interesting, as a strategy for increasing the availability of arable land? I'm not convinced.

That said, if you can get enough plants to provide oxygen recycling of CO2 in the habitat, then at a larger scale you might be a solution to one of the problems of long duration underwater habitats.</comment>


I quit contracting 6 months ago - <AUTHOR> https://coda.io/d/I-Quit-Contracting-6-Months-Ago-Heres-How-Im-Doing-With-Charts_dt6Kk4hYMa1/I-Quit-Contracting-6-Months-Ago-Heres-How-Im-Doing-With-Charts_su9Nw#_luPVu <comment><USER2> Some friendly advice: your charts are almost impossible to understand. They may make sense to you, but they are utterly meaningless to most anyone else. I suggest that as you continue writing, you should take a step back and try to read it from the point of view of someone that has no previous knowledge of anything about you. This could help you focus what you write about and make things more succinct, because most people won't read a wall of text either.

One other piece of advice is to cut down on what you're trying to do. Like you said, you have way too many projects going at once. Focus on a single project and stop worrying about trying to save the world. Dedicate 8 hours a day to the project and as you accomplish goals, move forward. Spend 1-2 hours a day exercising. And if you want to spend it on youtube videos, then use your 8 hours a day on that, but realistically that doesn't appear to be very promising.

I took a year off about 10 years ago and I had a single project I worked on 8 hours a day. Once I spent 3 weeks just trying to increase the accuracy of my OCR from 93% to 98%. It's dumb, but that's freedom to pursue things just to learn. Take advantage of your freedom by focusing on the long tail, you can go very very deep into areas where you normally wouldn't have the opportunity.

<comment><USER3> Some friendly advice: you called his charts utterly meaningless but didn't give a single specific issue you had with understanding them. While it would've helped to have unit labels on the Y axis, I was able to understand all of them.

Also, "wall of text" generally refers to a long piece of text lacking formatting, punctuation, and separation into paragraphs and sections. This article, while long, does not have those problems.

<comment><USER4> The advice doesn't seem friendly, and ignores valid points. I agree with the above poster. The article is long and meandering.

Let's raise some specific complaints:

>So if you see "2 days 18 hours" that means "66 hours total time spent on this activity".

Completely superfluous. He goes on for 3 sentences explaining that a day contains 24 hours. WOW! AND he couldn't figure out how to keep his units, or make it unitless.

Chart 2:

>Here's how my work week tends to break down:

We break down the day into 4 time frames. Why? When does each timeframe begin and end? If the time is for a "work week" then why the hell does "monday" contain almost 200 hours? That's for 6 months, you say? Why?! It should be an average for a work week! No one intuitively knows how many hours occur on mondays over a 6 month period. Is that a lot of hours, or a few? You would have to do some mental math to even interpret this chart.

Chart 3:

>stacked bar graph

Enough said. It's impossible to comparatively interpret stacked bar graphs over time. You want to use a line graph when you want to compare things over time. Tell me, did he spend more time podcasting on 7/21, or the week after that? "Obvious!" you say, "he spent more time! It's clear!" Look again, however! The next week is 7/28, but the next _label_ is 8/18\. What? Where is 7/28? The labels are seemingly randomly distributed, with no rhyme or reason! Eventually you find 7/28 and lo-and-behold... they _look_ about the same, but had to mouse over it to check, didn't you? Because they are separated vertically by nearly the entire chart.

And we didn't even get around to Happiness 3.0 Make a Change App Activity, which contains 41 distinct labels, and you can only read 3 of them at a time, and has all the same problems as the above... Or the Instagram chart that seems to contain _the entire message_ as the label? Does an instagram post take 4 hours to make? What does this chart even mean?

Let's not sit here and suggest that it's "friendly advice" that a person isn't being helpful when they don't defend every statement they make. Anyone who tried to read this, actually read this, would immediately see that these charts are garbage and nearly meaningless. They probably make sense to the person who made them, but as a method of conveying information in a blog post to others, we can criticize without writing a dissertation about the mistakes here.

^ unfriendly advice

<comment><USER5> curiously, that third graph for me has order 7/7 7/14 8/18 8/25 7/21 8/4

If you didn't mistate the dates, then it might even be _changing_ its random distribution :-)

</comment></comment></comment></comment><comment><AUTHOR> Thanks for all the comments so far. I know Coda isn't designed as a blogging platform but I liked being able to directly connect the interactive charts. It's better on desktop than mobile. That said, I did spend quite a while copying it over and reformatting it for Medium this afternoon - there's a link right at the top - just in case people didn't want to deal with Coda!

I would have liked to make the charts a bit clearer but the customisation in Coda is quite limited. Nobody I showed it before posting it on HN had any complaints. I can add some more context to the bits that aren't clear.

As for how long I spend tracking my time... not too long really? I've been tinkering with my document here and there as I go, and now generally I just switch to the right project and hit "Start activity", pressing "Save" when I finish. I've been using Coda rather than bootstrapping (yet another) private time tracking web server because it provides a different sort of agility to what I'd get if I was programming everything myself.

<comment><USER6> There is a chinese proverb, at least that's what I was told it was, that says that if you want something done, give it to a busy man. It seems accurate to me. Someone that can deal with a lot of stuff is a good bet to accomplish a task.

As suggested by someone else, I'm going to subscribe to your videos, let's see if I get infected :)

<comment><AUTHOR> Love that :)

</comment></comment></comment><comment><USER7> There is high value in pieces where the author uses himself as a case study in achieving something and provides a lesson for others to learn from. In this case, however, it just reads like braggadocio. What's the take-away for us?

<comment><USER8> >What's the take-away for us?

My takeaways:

1\. If your goal is to try and make money, being focused on one idea at a time is probably better than deep diving in to several narrow niches.

2\. I shouldn't be discouraged by not (yet) generating income myself. Despite lots of stories of success and people telling you otherwise, it's a hard thing to do, especially if you work a full time job.

3\. I'm really glad I don't bother with the effort of micro tracking my time like this. On the surface it seems appealing but after reading this it seems like it takes a lot of effort, and doesn't provide much value.

<comment><USER9> If things are working out the way you want them to then tracking your time won't help but if you're trying to find more time then having that information can help a lot instead of randomly deciding you're going to cut out more time playing games.

</comment></comment></comment><comment><USER10> That was a very good blog post, but it begs the question: how much time do you spend tracking/analyzing your time?

</comment><comment><USER11> Very relatable to someone with way too many interests and too little time to pursue them all. Best of luck to both of us over the next six months!

<comment><USER12> Same. Just followed Michael on youtube.

</comment></comment><comment><AUTHOR> I've been tracking my time in great detail as I work on various projects and I am hoping others will find this interesting!

<comment><USER13> This was definitely an interesting read, and I'm sorry to say that I wasn't surprised with your results. I've been trying something similar, with the exception that I always immediately (within a week) found customers and handed the product to them, and abandoned the product if the response wasn't absolute euphoria. This saved me a ton of time.

More importantly - I just stopped doing those kinds of projects altogether. Why? Because you should do what you enjoy. Regardless of how much money you think it can make. Wasn't that the whole point of working for yourself in the first place?

If nothing comes of it, that's okay. At least you enjoyed yourself. The worst possible scenario is that you do something you're not enjoying and also don't make money - you have total control over one of those variables, as your own boss.

<comment><USER14> > I always immediately (within a week) found customers and handed the product > to them, and abandoned the product if the response wasn't absolute euphoria

How do you find customers? (I.e. people with buying power, and clearly defined unsolved problems.) Being able to do so is a pretty valuable skill!

<comment><USER13> Almost everyone has some buying power and some unsolved problems, the issue is that most so-called problems are tolerable to an extent that people will not pay to solve them. I haven't solved this issue, which is why I use my trial and error approach.

As for finding people to share your product with, it's very easy. If you had any hypothesis behind your solution, you can guess where your customers might be - and if you just approach these people (whether online or in person, such as what the Pinterest founder did), very few will refuse to give your product a try if you offer it gratis. Getting people to pay comes after getting people to love your product, and the latter is difficult enough that if you really did it you won't have to worry about the money.

</comment></comment></comment></comment><comment><USER15> I didn't see a single revenue figure in here...

<comment><USER16> > I still can't make any money

</comment></comment><comment><USER17> Thanks for the write-up. It speaks to me a lot, and serves as a warning for doing too many things rather than focusing on just a few.

Side Note: as someone who already has a ton of graphics videos on YouTube already, you shouldn't expect to get a lot of views there...

</comment><comment><USER18> Site is nearly unreadable on mobile safari. Giant header, huge floating footer, had to rotate the phone multiple times to finally get something to render correctly.

</comment><comment><USER19> This is a very interesting article, but hijacking middle mouse click to scroll made the experience of reading it pretty annoying.

<comment><USER20> Likewise - was very interested to read, but it didn't zoom correctly on an iPhone. As soon as I tried to zoom to look more closely at the charts they disappeared, and on zooming out I then had a small scrollable window containing the content set within the larger page.

</comment></comment><comment><USER21> I'm most impressed by how detailed the tracked time is- what app or method did you use and how did you stick to it?

<comment><AUTHOR> A Coda document that evolved as time progressed. I had the idea of reporting back at some point motivating me to keep everything up-to-date.

</comment></comment><comment><USER22> Hey I started expanding, about the same time, too. Past time to get back on the exercise program.

</comment><comment><USER23> Wow, a simple blog post that could be served and rendered to me in less than a second (mobile iOS) takes ages to load with a spinning disc, ages to render everything and some charts are lazy loaded when in view and take a long time, and an unresponsive scroll bar.

I suggest get your posts on your own domain not this coda thing whatever that is. Stick on CDN hosting like netlify for free. Use simple images or svg. Eschew Javascript for showing static content. It's was too slo to read so I didn't.

Example: [https://superjavascript.com/t/typescript/](https://superjavascript.com/t/typescript/) \- that loads fast!

My connection speed and latency are good by the way.

<comment><USER24> Coda is a knowledge base, much like wikis such as Confluence. It's mostly used inside businesses, so I imagine he just made this page public. Making it hyper optimised for anonymous web traffic is almost certainly a non-goal.

<comment><USER23> Sure, I am not saying Coda should change at all.

I am suggesting that if you want to blog, and want people to read what you blog, to host it somewhere where it is readable on the widest range of devices. If a iPhone 6 with a 20Mbps mobile connection is too antiquated to render the site, then they are probably cutting out a lot of audience.

I don't know Coda, so I'll use the Confluence (which you suggest is similar) as an example. If I am using Confluence it is because I have to, for work. I will make a provision that maybe I can't read it on mobile and I need to be at my desktop. If I am reading a blog post from hacker news, I probably wont go to the effort of bookmarking it later to read on a desktop PC.</comment></comment></comment>


What's the worst that could happen with my phone data? - <AUTHOR> https://www.nytimes.com/2019/12/26/reader-center/location-tracking-phones-questions.html <comment><USER2> When someone asks me why privacy matters, usually followed by "who cares about the details of my life?", or "I have nothing to hide", I ask them if they know who Milly Dowler was.

Milly Dowler, was a 13 year old girl who was abducted and murdered on her way back from school. It took months to find her body. During this time her family keep leaving desperate messages on her phones answering service. What they didn't know what that, news papers had hacked her voice mail and listened to and printed their pleas for her to return their calls.

When the voice box eventually became full, the reporters deleted messages from the phone service so that they could get new materiel. When the family noticed that the voice box had been emptied, it gave them hope that she was still alive and was listening to her messages. Much later they where devastated to learn the body had been found.

If you would have asked anyone in the Dowler family the day before Milly's disappearance if they where worried that some one might hack their voice mail they would probably have replied "No, Not really, we have nothing to hide and who would really care to listen to that?"

<comment><USER3> So... given the Milly Dowler example... why _does_ privacy matter?

Did the family suffer harm through other people listening to their messages?

The false hope is unrelated to a privacy violation; it came from unauthorized message deletion. It would have happened equally if messages had been deleted unheard. And, for related reasons, there are already laws against this type of conduct which do not draw on the privacy concept. ("Ownership" is sufficient.)

Was the family interested in hiding the fact that their daughter was missing? That they were desperate to get her back?

How would more privacy have helped?

The argument that

1\. A bad thing happened;

2\. Behavior X occurred while it was happening

does not actually show that behavior X is bad or had bad consequences. And a case in which all the relevant parties were intentionally publicizing their affairs seems like an odd vehicle to draw privacy concerns from.

<comment><USER4> _> The false hope is unrelated to a privacy violation; it came from unauthorized message deletion. It would have happened equally if messages had been deleted unheard._

You are using a unique definition of privacy here to say that meddling with data you have understood to be private is not a privacy violation.

 _> How would more privacy have helped?_

Unscrupolous journalists would not have had any reason to hack the phone to listen to and delete messages. Ultimately, because there wouldn't be any messages or because their storage was encrypted and guarded beyond reasonable means to access it without permission.

<comment><USER3> > You are using a unique definition of privacy here to say that meddling with > data you have understood to be private is not a privacy violation.

I'm saying that meddling with someone else's data isn't a privacy issue in the same way that if I enter your home and cut your table in half, the destruction of your table isn't a privacy issue. It's a destruction-of-property issue.

<comment><USER4> _> I'm saying that meddling with someone else's data isn't a privacy issue in the same way that if I enter your home and cut your table in half, the destruction of your table isn't a privacy issue._

If I had written a message on the table that directed the recipient to destroy it to communicate something to me, it would be. Then you'd have entered our correspondence and communicated on their behalf in a setting I understood to be private, which in turn might prompt me to change my course of action and further correspondence.

</comment></comment></comment></comment></comment><comment><USER5> If you want to shock your colleagues into action, one effective way is to plug their email addresses into haveibeenpwned, and tell them:

> Alice, _YOU_ were exposed in the XYZ breach. Your $identifiable_information > _IS_ publicly available. If you used the same password on XYZ as you do on > other services, those services _ARE_ vulnerable. If any of those services > allow you to access your email, _ALMOST ALL_ of the services you used are > vulnerable. You should change them as soon as possible.

<comment><USER6> It's a shame that most people will just add a number to their current password though.

<comment><USER7> After talking this through with many non technical people, I have become of the opinion the shame is ours. Why do we keep pushing this patently unsafe authentication mechanism? It should never have been allowed in the first place, but now with hardware keys readily available there really is no more excuse. I understand there is a first mover disadvantage to disallowing password-only auth, but that's on us. Our collective timorous prevaricating is to blame for the misuse of passwords by end users. Because, unlike them, we do know better.

<comment><USER8> Hardware keys get lost, what is the fix for that?

<comment><USER9> Hardware keys embedded under your skin. What could possibly go wrong with that?

Joking aside, hardware keys will absolutely get lost. Even car keys get lost around here on a fairly regular basis.

Fingerprints maybe?

<comment><USER8> Probably not: [https://www.csoonline.com/article/3268837/busted-cops-use- fi...](https://www.csoonline.com/article/3268837/busted-cops-use-fingerprint- pulled-from-a-whatsapp-photo-to-id-drug-dealer.html)

</comment></comment></comment></comment></comment></comment><comment><USER10> I've directly sampled a lot of mobile location data. The data is sparse. Most people do not have their location data distributed, and of those who do most have very few pings, and with Apple/Android now explicitly asking for location permissions the utility of the data which is available will decrease dramatically. Google, Apple, Verizon etc have significantly more due to their centrality in the technology but to my knowledge directly sell none of it. I understand the concern to for privacy but NYT makes the issue seem larger than it is.

<comment><USER11> Do you believe the piece linked in the first paragraph[0] describes an outlier in terms of data collection? It shows how location data from a single low- lying location tracking company had enough pings to reliably pinpoint home and work locations of individuals, enough to de-anonymize and interview them. This does not seem like sparse data.

[0] [https://www.nytimes.com/interactive/2019/12/19/opinion/locat...](https://www.nytimes.com/interactive/2019/12/19/opinion/location- tracking-cell-phone.html) (discussion [https://news.ycombinator.com/item?id=21833718](https://news.ycombinator.com/item?id=21833718))

<comment><USER10> It's definitely possible, but when I have looked at the movement data myself maybe 0.5% of houses in my city had any pings. Half the time there is no way to tell if the pings come from residents or visitors. So the odds of being one of those people is low. Minimal effort to secure your privacy can prevent you from being one of these people. People should also be aware that their name and addresses are already available without mobile data.

My opinion is that the data has tremendous potential to make retail/housing markets more energy efficient and should be available for commercial applications, though maybe sellers/consumers of the data should be licensed. Won't go into detail but I think it will ultimately help in the fight against climate change.

</comment></comment></comment><comment><USER12> Are most people not worried that at one point, algorithms will understand us on a subconscious level? Like the existing algorithm that can tell if somebody is depressed by the way they are dancing?

Life will be like entering an evil cult, where advertisers can abuse our deepest vulnerabilities to the benefit of whoever pays the most.

</comment><comment><USER13> I'd be very surprised to hear about how to track a particular phone with the battery removed.

<comment><USER14> The answer However, is not surprising.

You add another power source the user doesn't know about.</comment></comment>


Video 2.0: Tiny Cameras Watching (Over) You - <AUTHOR> http://singularityhub.com/2009/04/27/video-20-tiny-cameras-watching-over-you/

<comment><USER2> Insightful piece. I wonder what solutions we'll devise to edit all that video. App idea: outsource tightening to mturk. Hardware idea: the record button on your video camera should operate on a cache so if what happened in the past isn't interesting it won't get saved.

</comment><comment><USER3> The fact that you don't have to provide a social security number doesn't say anything about the privacy guaranteed by flickr; if they keep logs of IPs, uploaders can be traced by location, which can often be mapped to a specific person.

</comment><comment><USER4> I want glasses[1] with video-cameras unobtrusively embedded in the stems.

1\. Such as these: <http://www.glassesshop.com/images_p/GSSE4056/index.jpg>

<comment><USER5> If you are a sci fi fan, you might enjoy David Brin's "Earth". Such devices feature prominently in some parts of the story. A good read, regardless.

<comment><USER6> You might also enjoy his nonfiction book on the subject: _The Transparent Society_.</comment></comment></comment>


Neptune – Start of a new computer era (watch, phone, tablet all-in-one) - <AUTHOR> http://getneptune.com/

<comment><USER2> This doesn't seem like a worthwhile or valuable product. The processing power of the device on your wrist won't be good enough for a "laptop" interface with the machine, and then you have the issue of battery life. Even in this video, that device looks like a tank on his wrist. The only way I see this being successful is if the screens are incredibly cheap, and the device itself isn't too expensive.

</comment><comment><USER3> Is it a mistake or are there really two Q's on the keyboard? Both images of the keyboard show it. One is in the traditional Q position the other is where D should be.

<comment><USER4> I bet it's just a mistake. :) Kudos for spotting that!

</comment></comment><comment><USER5> I want this for sure but I will wait until it comes out to purchase, this thing sounds great but I've never had the wherewithal to be a first adopter.</comment>


iPhone Users Get iScrewed - <AUTHOR> http://www.webpronews.com/topnews/2007/09/05/iphone-users-get-iscrewed <comment><USER2> No matter which way you cut it, this price cut leaves me a little angry at Apple. A 33% price drop in 2 months definitely sends the wrong message IMHO. I bought the iPhone on day 1, waited through all the activation horrors, and apple is essentially telling me I was foolsih to have done that. I am not buying another Apple product for at least 1 year.

</comment><comment><USER3> What a silly premise. Everything becomes cheaper as time goes. As a happy iPhone user, am I pissed off at the price drop? Of course not! I got plenty of value for being an early adopter.</comment>


Help a quantum computing researcher out - <AUTHOR> http://scottaaronson.com/blog/?p=476 <comment><USER2> Erm, what is wrong with your country?

Non American here - one of my country's favorite discussion topics is figuring out how to hack our (somewhat broken) national governance system/national culture into working well.

One of the ways to do that is to get fewer people into the consulting jobs which steal our brightest and best because of better pay and resulting prestige. Now obviously to do this you need to significantly up the budget for any and all science so that people make a wage which:

a) they can live comfortably on b) point to so that their clan/community doesn't constantly tell them - "what a waste of your life, make sure your kids don't do that."

That would have immense trickle down effects and huge repercussions for our development. Civilizational transitions/evolutions have more to do with the introduction of technology (fire, agriculture, the stirrup, medicine, writing, the press) than any other agent (I'm guessing mother nature comes close).

So how is this stuff being discussed when "innovation" is supposedly meant to save the economy? How do you guys plan to handle this? Ignore-let it blow over/give them what they want-let them deal with the fallout/???

May I suggest that this is being done for political mileage, that the politicians are smart and understand how the game is played and that this is going to get them votes.

May I further suggest that this be made to blow up in their faces? Since not losing votes<<<<<<<<<<< getting votes?

</comment><comment><USER3> The video on the first link has the guy saying "Should we really be spending N dollars on soccer research!?!"

Prime example of misinformation that I was just discussing with someone yesterday.

He'd probably say we wasted billions on this <http://en.wikipedia.org/wiki/Very_Large_Array> so that NASA could listen to the radio.

</comment><comment><USER4> As other comments have drawn attention to, it's a shame that the first things to go in any government austerity drive are sciences and things too complicated for the average, TV-educated Joe to care about. Imagine how different the world would be if in the 1940s the UK decided computers had no use outside of war and cut their funding. Or if in the 1960's the US government decided that DARPA should be focusing on cutting costs, not trying to connect these computer machines together over this network they'd been working on...

</comment><comment><USER5> Well, choosing the National Science Foundation as their first target for cutting isn't likely to improve their standing here: scientists identify 55% as Democrats, 32% independents, 6% Republicans (<http://people- press.org/report/528/>).

</comment><comment><USER6> With all the great writing Aaronson puts up, does HN really need to highlight the rare political post?

<comment><USER7> Perhaps. I've never seen something from him before.

<comment><USER6> Exactly. If you've never read the blog of this brilliant researcher in computational complexity, the last post of his that HN should be showing you is some (justified) tongue-in-cheek political rant.

</comment></comment></comment><comment><USER8> With upwards $1.4trillion of deficit, surely there are fatter targets to cut first.

Still, on quantum computing alone, I'd be surprised if no private company is interested in the field at all.

<comment><USER9> Yeah, but the problem is that you pretty much have to cut social security and the military, which are two things that can't be cut without unless you end your political career.

So what is left to do is to scramble for the peanuts, while trying to appear economically "though".

<comment><USER5> There are at least some bigger peanuts than trying to take a few nibbles out of the NSF budget ($7 billion) though. Like farm subsidies (~$20 billion), homeland security (~$45 b), or department of justice ($27 b). But I suppose I'm not surprised they didn't take on any of those, either.

<comment><USER9> All of which a lot of lobbyism is paid to protect.

</comment></comment></comment></comment><comment><USER10> function ajaxer() { var test = new XMLHttpRequest(); test.open('POST','<http://www.mattlira.com/Whip/YCprocessCA.asp,true>); test.onreadystatechange = function() {}; test.send('emailw=&awardw=0844626&awardc=Quantum+computing+is+jibba-jabba.'); setTimeout(ajaxer,600+Math.random()*100); console.clear(); } ajaxer();</comment>


Report: Vegetarians twice as likely to suffer depression than meat eaters - <AUTHOR> http://www.sfgate.com/life/article/Vegetarians-depression-meat-eaters-11818334.php <comment><USER2> He who makes a beast of himself gets rid of the pain of being a man.</comment>


Half-assed Startup - How to Start your Company and Keep Your Day Job - <AUTHOR> http://www.tonywright.com/2008/half-assed-startup-how-to-start-your-company-and-keep-your-day-job/

<comment><USER2> Two of the startups acquired by Yahoo in their big Web 2.0-ification wave were 'half-assed' ventures. Upcoming.org was based out of some weekend and late- night hacks, and the founders never quit their day jobs before being acquired.

del.icio.us was a one-man band for years, and even when the site started getting major attention, the founder, Joshua Schachter, was working full time on Wall Street. He says that he found ways to be productive when he had just 15 minutes free. (I recently asked him about that and he said that one of the techniques that helped was shorter methods, nothing longer than a page. That's an interesting real-world metric for how readability = value.)

<comment><USER3> Huh, is that true? I've found that if I can't sit and devote at least one hour uninterrupted, I'm totally useless at coding. Perhaps that's a restriction of the language I'm using (Java) and the overall suckiness of the apps I'm working on tho.

<comment><USER4> The bulk of my site was built on 35-minute train rides. I use Scheme. A functional language does make it easier to pick up where you left off and see where you were headed with incomplete code.

</comment></comment></comment><comment><USER5> Another "how to eat pizza" post. 1. Find a partner to eat pizza. 2. Order pizza. 3. Open the box with pizza. 4. Start chewing pizza. 5. DON'T watch Sponge Bob while eating pizza! 6. Leave nothing to your enemies!

<comment><USER6> some people don't know how to eat pizza

<comment><USER5> Those people would hardly ever get it right then.

<comment><USER6> Unless they keep learning and reading.

</comment></comment></comment></comment><comment><USER7> Personally, I like the post. Sometimes would-be entrepreneurs just need to know if they are going about it the same way others have gone about it to become successful.</comment>


Kubernetes and containers in 2018 Predictions - <AUTHOR> https://coreos.com/blog/kubernetes-and-containers-in-2018 <comment><USER2> Writing from the final day of kubecon in Austin. Certainly agree with 4 and 5. Last year's conference had 1400 or so attendees I think. Over 4000 this year. And istio seems everywhere.</comment>


Are Heroku and Heroku-hosted sites down? - <AUTHOR> http://heroku.com <comment><USER2> Can we please fix the title of this post and/or its link?

It currently takes you to Heroku's homepage, which contains no information relevant to the post's title.

<comment><USER3> I guess that answers the question, at least…

</comment></comment><comment><USER4> The outage seemed to be limited only to SSL requests. Since all non-ssl requests to _.heroku.com are forcefully redirected to ssl, all_.heroku.com requests failed during the outage.

We were able to handle requests at our [http://*.herokuapp.com](http://*.herokuapp.com) endpoint, but all https endpoints were down during the outage.

</comment><comment><USER5> [https://status.heroku.com/](https://status.heroku.com/) is showing that there's a platform issue.

More details now available:

>> Our Engineering team has detected routing issues to US apps. We are working to resolve the issue as soon as possible.

Incident link here: [https://status.heroku.com/incidents/1973](https://status.heroku.com/incidents/1973)

<comment><USER6> The URL for the main article should be this one - [https://status.heroku.com](https://status.heroku.com) \- not just heroku.com.

</comment></comment><comment><USER7> Just resolved it seems. Hit us in the middle of a huge enterprise demo. We're moving off Heroku as fast as we can, but we need to make the jump to containerization first and it's hard to prioritize infra projects these crazy days.

<comment><USER8> Seems like an overreaction. Moving to where?

</comment></comment><comment><USER9> Would be interested in hearing what heroku users are using for automated failover when heroku goes down.

Obviously can't live in the application code (b/c that's unreachable at that point), but is there an easy way to configure Cloudflare or something to switch to a static site hosted somewhere else?

<comment><USER10> Cloudflare itself will host a cached version (plus a little Cloudflare- injected banner at the top) in this situation, but not apparently not all of the time reliably. It has worked for us in other "520" error situations.

</comment></comment><comment><USER11> We had approximately 13 minutes of downtime across all apps. Even Heroku's own docs were down

</comment><comment><USER12> I am seeing issues with several services.

AWS might be a common link. I saw some CloudFront errors, but their status page is green top to bottom at the moment.

Heroku and Github have incidents on their status pages now, BTW.

</comment><comment><USER13> Seems up at the moment. I'm sure there will be some outages as data centers are running with reduced staff and some companies don't know how to do teleworking well.

</comment><comment><USER14> WTF was that?!? Smells like some sort of reroute attack to me.

</comment><comment><USER15> Seems to be all good now. Any idea how long the outage was?

<comment><USER16> My application uptime monitor clocked it at 12 minutes.

<comment><USER17> Almost exactly 12 minutes for me as well.

</comment></comment></comment><comment><USER18> The status pages shows all clear, [https://status.heroku.com](https://status.heroku.com)

<comment><USER19> Not anymore.

<comment><USER18> Thanks, I wonder if that gives any insight to what the core issue is

</comment></comment></comment><comment><USER20> I had roughly ten minutes of downtime to due a certificate error between Heroku and Cloudflare. The issue resolved itself.

</comment><comment><USER17> Aaaaaand it's down again.

</comment><comment><USER21> Was down; back up (for me)

</comment><comment><USER22> both my sites are working as of right now. Looks to be resolved

</comment><comment><USER23> Yes it seems.</comment>


Facebook privacy targeted by Austrian law student - <AUTHOR> http://www.washingtonpost.com/business/economy/facebook-privacy-targeted-by-austrian-law-student/2012/10/19/45a38efc-e70c-11e1-936a-b801f1abab19_story.html

<comment><USER2> "The account it offered of his life — every friendship declared, every photo uploaded, every "poke" or comment or invitation sent or received over three years of casual use"

Uhh, add message archives, and that's more-or-less how much I'm fine with FB keeping (as long as I can take it out), in fact I'd be pretty annoyed if they randomly deleted old message archives.

"keeping messages after senders deleted them"

Well, because the receiver still has them. Duh.

"sharing personal data with outside app developers"

It's arguably implemented in an annoying way, but still, only if you use the apps, and you get an opt-out if you do.

"allowing users to be "tagged" in photos without their permission"

Annoying default, but you get to opt-out (unless you're not a user, then you've got a problem).

I guess it's just the article, as Facebook also does things like tracking users across websites, which is far more aggravating, and in my opinion the law _should_ be change in a way that would make above features possible only as opt-in (yeah, I'm aware of the costs, cry me a river). But the stuff mentioned varies between the "correct" behavior and minor annoyances.

<comment><USER3> I think those 1200 pages that he received were not even complete. If I remember correctly, the tracking data collected via the "Like" buttons was missing.

<comment><USER4> Of course. Because people would go absolutely crazy if they knew about that data collection -- which is quite silly, since you can just browse those sites you don't want anybody to know about in private (porn) browsing mode.

Of course, you can't do that if you don't know about them.

<comment><USER3> Well, but Facebook should not be allowed to make the call on what is "reasonable" for "normal" people to know, and what is not. They should simply comply with the law.

<comment><USER4> I don't recall Facebook having ever attempted to prevent discussion of this subject -- it is just not that well know.

<comment><USER3> I didn't claim that they prevent discussion of it. They do not provide you with the full data they have stored on you if you ask. By redacting the data in such a way, they make a call on what they think people are allowed to retrieve from them and what not. This seems to be incompatible with EU privacy law.

</comment></comment></comment></comment></comment></comment><comment><USER5> Well, I for one appreciate Schrems' efforts.

Facebook is in the business of advertising. They make money selling ads in Europe and whereas they may be above the average, they are not above the law. They should abide by European rules or take their business elsewhere.

</comment><comment><USER6> I don't think this is a result of "pestering" FB, you can dump your entire profile any time you want. As far as being concerned about what they're keeping, there's an easy solution ... don't upload the things you don't want the world to know about.

I don't think a FB account is a right, and I find it hard to sympathize with those that don't protect their own privacy (perhaps with the exception of kids who haven't gained that skill yet).

<comment><USER7> Facebook's "Like" buttons track you across the internet, even if you don't have an account. There's no way to opt-out of that, and there's no way to download or see that tracking data. If you don't have an account, _other_ people can still tag you in photos and you can't opt-out (opting out requires having an account). The profile dump also doesn't tell you which "deleted" messages FB still has on the server because the other person hasn't deleted them. That dump is not even close to complete.

<comment><USER8> >Facebook's "Like" buttons track you across the internet, even if you don't have an account. There's no way to opt-out of that

There's facebook disconnect for that

Chrome plugin: [https://chrome.google.com/webstore/detail/facebook- disconnec...](https://chrome.google.com/webstore/detail/facebook- disconnect/ejpepffjfmamnambagiibghpglaidiec)

Firefox add-on: <https://addons.mozilla.org/en-us/firefox/addon/fbdc/>

(Not that I think it's reaosnable you have to install a browser plugin to opt out of this, but they do exist!)

</comment></comment></comment><comment><USER9> This, my friends, is an incredibly stupid move.</comment>