WingNews logo WingNews GitHub [2]

iamartnez's comments

iamartnez | 11 years ago | on: EA Shuts Down ‘SimCity’ and ‘The Sims’ Developer Maxis

This is where my curiosity lies. I wonder if the DICE founders were very sharp, knew what they were getting into, and had the leverage to set the kind of terms that would maximize their chances of success.

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.

iamartnez | 11 years ago | on: Relay FAQ: Facebook's Data-fetching Framework for React

A common problem in a service oriented architecture is needed to minimize the amount of round trips to a particular service.

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};
You can see where this gets cumbersome. I have to compose one of these for every kind UI view at the root level. On the one hand it's very explicit and the flow of data is very clear, but it also means relationships between data are dupicated in more than one place (often many places).

Could GraphQL help with that scenario?

iamartnez | 11 years ago | on: Reasons to not use Ember.js

What a terrible post.

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.

iamartnez | 11 years ago | on: Neovim: input encoding and you

My understanding is that Neovim will make it much easier for plugins to execute tasks in parallel and in the background.

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

iamartnez | 11 years ago | on: Microsoft Band

I picked one up today. Impressions so far:

- 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.

iamartnez | 12 years ago | on: Erlang and code style

Or is this just the place where I do need to catch errors and process them? And if that is so, isn't it at odds with the whole concept of writing intentional code?

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,

iamartnez | 12 years ago | on: Go: Best Practices for Production Enviroments

Nothing wrong with two services using the same data source. If data locality is a concern, deploy both services alongside one another.

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.

iamartnez | 12 years ago | on: The "Window Resizer" extension for Chrome now contains malware (2013)

Since Chrome auto-updates extensions, users are likely not aware of this change.

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

iamartnez | 12 years ago | on: I, Glasshole: My Year With Google Glass

I was showing my Glass to a family member who visited from out of state. He's a commercial helicopter pilot, isn't wired in to the tech space, and didn't know much of anything about it.

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...

page 1
more