iamartnez

For example, I think they decided to keep the studio in Stockholm. That might have went a long way to keep the EA influence down and letting them focus on building blockbuster titles.

Perhaps EA is a sink or swim kind of organization (on that level)? In a harsh kind of way. In reality most franchises do eventually sink.

I wonder if DICE came to the negotiation table more prepared and/or with something up their sleeve. It could be that EA is hands off so long as a studio produces highly profitable titles. As soon as there's a dip, snip snip.

Example: To render a UI view, I need to fetch a list of friends, a list of posts, and a list of notifications. All 3 of these data types (friends, posts, notifications) have users associated with them. Instead of fetching users for the 3 data types 3 separate times, I need to flatten that into a single call. I end up with something like this:

  var [posts, friends, notifs] = yield [
    getPosts(),
    getFriends(),
    getNotifs()
  ]; // executes in parallel

  var userIDs = new Set();
  userIDs.addAll(posts.map(p => p.userID));
  userIDs.addAll(friends.map(f => f.userID));
  userIDs.addAll(notifs.map(n => n.userID));

  var users = yield getUsers(userIDs.toArray());

  return {posts, friends, notifs, users};

Could GraphQL help with that scenario?

For anyone who hasn't explored the Redis source, do it! It's very approachable and strikes and interesting balance between cleverness and maintainability.

Actually, it does have one use. If you're a recent grad or new to the industry, pay close to attention. Don't be like this guy.

Before you envelope yourself in the comfort of frameworks and libraries, learn how to poke around the internals and understand the underlying architecture. Remember that these are tools written by humans just like you. They'll have bugs. Performance problems. Maybe an edge case the creators haven't thought of. And sometimes you'll be making the mistake.

My personal rule (YMMV) is to never adopt a framework or library unless I'm ready to open a pull request. There are obvious exceptions like databases and other huge projects. I'm specifically referring to small libraries and application frameworks for this rule.

Treating frameworks and libraries as a magical-voodoo-black-box is asking for trouble.

Moreover if you decide to write a blog post warning people not to use a framework or library, you better have some deeper technical insight to back it up. This is just rude.

I'd use that for running ctags on save without blocking the editor, for example.

- Comfortable. - Looks nice, I like wearing it. Doesn't feel flashy. - Does what it says it will. No buggy surprises. - Scroll performance isn't very good. - UI feels right otherwise. Nothing annoyed me. - Complementary iPhone app is well done. - Doesn't feel flimsy. Feels sturdy without feeling bulky. - Setup is simple.

No complaints so far. If you desire the features it offers I'd say it's definitely worth buying.

I'm impressed.

No it's not. The author touches on this:

Note the word intentional. In some cases, we do expect calls to fail. So we just handle it like everyone else would, but since we can emulate sum-types in Erlang, we can do better than languages with no concept of a sum-type.

So handle errors you expect explicitly and let the rest crash.

    case user:authenticate(Username, Password) of
        {ok, UserRecord} -> ...;
        {error, notfound} -> ...;
        {error, badpass} -> ...
    end,

Or you could place the data behind an API. It would speak HTTP/Thrift/whatever and would be solely responsible for handling the data. Front the API with a cache if latency becomes an issue.

For your specific example, consider pushing data to autocomplete and search instead of having them pull.