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.

https://www.youtube.com/watch?v=GLQyj-kBRdo

If you like that kind of control flow, check out the library we wrote to do it: https://github.com/storehouse/engen

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,

http://en.wikipedia.org/wiki/Kerrison_Predictor

http://en.wikipedia.org/wiki/Tachymetric_anti-aircraft_fire_...

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.

[0] https://github.com/artnez/urltree

ipython is a pretty sweet interactive interpreter. Also try ipdb[0]. I can't live without the interactive debugging it offers.

[0] https://pypi.python.org/pypi/ipdb

I've been using the extension for several months until I noticed the transparent redirection. In fact, the only reason I noticed the redirect is when it failed. I clicked on a Google search result and got stuck on a blank page like this:

    http://ecolink3.ecosia.org/?key=3cdcd4dc082e3c7b860abe4608b6925d&out=http%3A%2F%2Fwww.usatoday.com%2Fstory%2Fpopcandy%2F2013%2F01%2F15%2Ffred-armisen-ira-glass-this-american-life%2F1836079%2F&cuid=2

He went completely mental after putting it on.

A few interesting things he noted:

1. Many commercial helicopter pilots today use iPads with a software called Foreflight (http://foreflight.com/). They mount the iPad in the cabin and prefer it to the older analog stuff.

2. The form factor alone is a huge improvement over anything else available on the market, he told me. He also said that many pilots would pay top dollar for a device like Glass. "All" it would need to do is: a) display a hud w/ waypoints, b) show current conditions, c) know which direction he's looking at.

4. Pilots see the world differently. We look at Google Maps, they look at SkyVector[2]. Flying commercially is mostly an automated affair with everything planned out ahead of time. Computers do all the work. The location/size/properties of every airport is stored in a consistent format. Pretty much everything is standardized and easily accessible, no matter how remote the location! [3]

5. He told me that the day-to-day processes are ancient. Logbooks are kept by hand, for example. This is interesting considering aviation is a highly regulated industry. All process are laid out in great detail and slow to change. This could make building software in this space easier once you get past the initial hump.

6. Military pilots have had things like this for years, but way more advanced. He told me about helmet-mounted displays (woah) [1].

We went on to discuss the myriad of practical applications for a device like Glass, even if the cost stays high past the prototyping phase. Unfortunately none of them included every-day usage by his wife and kids.

[1]: http://en.wikipedia.org/wiki/Helmet-mounted_display

[2]: http://skyvector.com/

[3]: http://skyvector.com/airport/ZMCD/Dornod-Choibalsan-Internat...

http://www.vim.org/scripts/script.php?script_id=1928

1) The libraries are guaranteed to be decoupled.

2) The libraries are better maintained individually.

3) It's much easier (sometimes painless) to replace them if they don't suit your needs.

4) ... probably many more.

The hardest part of bootstrapping a new application is the boilerplate. Let someone else take care of managing session state, generating SQL queries, URL routing, DI containers, buffered logging, templating, etc. If you haven't found something that suits your needs, sure, write it yourself.

I wouldn't say what you're doing is stupid. Do what makes you successful and happy. Just don't be stubborn ;)