4,593 karma · joined April 21, 2010
http://mikeknoop.com https://x.com/mikeknoop
Airlines prefer business class customers (routine flights, willing to upgrade to expensive business class tickets) and those customers typically search for small 1-2 day windows.
Or maybe the other way around?
https://github.com/josdejong/jsoneditoronline 200+ stars
https://github.com/tburch/jsonblob 50+ stars
http://www.youtube.com/watch?v=GjozYFToIM4&t=959s
tl;dr early Reddit used a technique mentioned: defaulting to the person with the most expertise.
Lot's of growth avenues, looking forward to seeing this grow.
One implementation detail I ran into is how to detect dupes. When you have Backbone Models, this is easy: every model has an `id`. But say you want to apply this same singleton behavior to a Backbone Collection, which don't have natively have `id`s. I saw two options:
1. Assign an `id` to the collection when instantiated (could just be a string, so that you can force a singleton only when you desire it).
2. De-dupe based on `instanceof` checks. The downside here is you always get a singleton even if you might want a one-off instance of a collection.
Are there any other options? Can your Identiy Map handle collections?
Powergrid: Unique because there are no dice involved; a game of economics
Steam: Unique because there is a bank (partly tied to your score) that you can borrow against to build pieces faster
SSL: It is not the onus of the vendor to ensure people are properly securing requests. I have seen horrendous things done in the name of "security" but it only adds headaches. Fix this at the client level. SSL everywhere is sufficient. By extension, vendors often introduce mechanics because they want to make the world better: http://xkcd.com/927/
Platform Support: I think the counter-argument is community client libraries, which the OP is correct: they are worse. The stability + scaling + support issues mentioned by OP can usually be solved by better API design and better architecture behind the scene.
Backwards Compatibility: OP claims you never have to update your code if you use their client library. This is likely true. Good API design would dictate not breaking exposed endpoints unless there is new functionality to be had. In this case, to take advantage of any new API features, you'd still have to update your code. No cost savings are had either way.
We spent many months ripping every client library out down to the raw requests. We are in a unique position because of how many APIs we have to support, but the overarching advise we give to people designing APIs:
If you are deviating from the norm, you're doing it wrong.
REST APIs are nice because you can infer how to communicate with the API out of the gate. APIs are a pain and you only introduce headaches by not doing things in a sane, conventional fashion.
1. myModel.on('change:title', this.render, this); // inside `myView`
2. myView.dispose(); // when you are done with `myView`
This will automatically remove all the referenced binds onto `myView` and simply removing the root view as OP mentions is sufficient.EDIT: HN link here http://news.ycombinator.com/item?id=4723588