davewasmer

I find this kind of stuff fascinating, but lack the CS and/or mathematics background to understand the discussion beyond the basics. I think I grasp the concepts outlined in the graphic novel linked elsewhere in these comments, but the whitepaper is too deep for me.

Any pointers for someone looking to gain an amateur understanding of this, or is this a topic of sufficient complexity that it precludes an amateur understanding?

The colors used for the map on the homepage are basically indistinguishable to colorblind folks like myself (the trusted vs. untrusted colors, specifically), just FYI.

Why does the app need permission to post tweets for me? Not a chance, sorry.

Just an FYI, but your choice of series colors for your graph are very difficult to differentiate as a colorblind person. Might consider changing one of the colors.

Isn't that a cost/value calculation? :)

You value some things because you enjoy them, more than you value other possible uses of that time.

It's a combination of a proxy, a DNS server, a ipfw rule, and a resolver file. All that is needed to allow you to capture port 80 traffic without running your application server with sudo every time.

A fantastic example of horrible information visualization. Those bar charts are almost useless. The colors don't seem to correspond to anything, the ranking is apparently random, and the x-axis scale varies wildly, making cross-country comparisons an exercise in mental arithmetic.

I'm confused. The author seems to advocate for civil, rational, open-minded discussion, and follows it by advocating that the industry effectively exile someone whose views he disagrees with.

The included quote is not a personal attack on any individual. Yes, its strongly worded - more than I would personally like. But its not a wild rant saying women are an inferior race. The quote doesn't even suggest women shouldn't be in tech - it simply suggests an explanation for the gender imbalance (however accurate that explanation may be).

Why not attack that explanation instead? Leave no doubt in anyone's mind that he is painfully wrong - not by public shaming and ostracizing, but through the rational argument the author seems to so eagerly want.

Yep, basically. Wherever the conversation leads. I haven't been disappointed yet!

Haha - I actually ended up visiting Future Advisor ... across the hall from Engine Yard. The door to the office was shut, so I didn't get a chance to say hi :/

Near Union Square - let me know if you'd like to chat at some point over the weekend!

Thanks for the tip about meetups - any in particular that you would recommend?

Not sure what you meant by running a tight ship. If you mean allowing strangers into the office, I understand - I mentioned the office only because it can be a good icebreaker meeting new people. If coffee shops would be a more comfortable meeting spot, I'm happy to buy.

If you meant something else, I'd be interested in learning what. I didn't think asking to meet new people would be off-putting.

I'll see if I can swing by - 48 hours is a tight schedule, but looks pretty interesting. Thanks for the tip.

Honestly, I'm more interested in meeting the people. If they are up for showing off the office, that's fine, and a good way to break the ice. But I'm not an interior office designer - my interests are more with the people that occupy them :)

Sounds like you had a fun time! Any tips on discovering those random trivia parties (or YC parties to crash ...)?

Unfortunately, I fly out Sunday night (if Boston Logan is cleared out by then!). Thanks for the tip though, wish I could make it.

So, as far as I can tell, there are two benefits this article outlines: avoiding highly nested code, and handling certain types of errors better. Are there other benefits?

In my experience, promises can be more difficult to debug (once the promise library takes my callback, I can't follow the flow of execution until it is called, unless I crack open the library itself), and are less intuitive. While those shouldn't disqualify the idea immediately, it does make me hesitate.

And I'm not sold on the benefits to error handling either. In the author's example, yes, all those error handlers could be grouped together - but how often do you have that many async function calls with identical error handlers? In most situations, that is a warning sign that you aren't handling errors properly and with enough "resolution".

All that said, I don't think promises are useless. There may be times when it makes sense to use them. But calling them the "next great paradigm in JavaScript programming" seems like a bit of a stretch to me.

What about if it isn't OSS? Do you like more reference style docs (i.e. this method takes arguments x, y, z, returns a string) or narrative (i.e. to accomplish goal x, you'll need to do y and z like this ...)?

Personally, I find Stripe's documentation to be excellent. It's clear, concise, and a good balance between narrative guides and comprehensive reference material:

https://stripe.com/docs

This is a good point - for web based companies, your domain registrar will always be your single point of failure. So it makes sense to keep it separate, with the most trustworthy company you can find.

Even in nasty scenario (like GoDaddy's DNS service going down), you can still point your domain somewhere else, even temporarily. But the worst case, your domain registrar going down, leaves you with no alternatives.

The real moral of the story: prices are the only effective mechanism for the efficient allocation of higher order goods.

I agree that survivorship bias is something to watch out for. Stories that tend to do well on HN are the ones that end well.

However, I don't think that should hold back someone who is in the same position I was (a longtime lurker trying to break out). For me, a primary takeaway from this experience was the small downside compared to the large upside of each of my decisions.

Worst case: your post goes nowhere on HN, the person you reach out to ignores you, or your conversation turns up nothing fruitful.

Best Case: your post pins it on HN, the CEO agrees to meet, and it turns into a job offer.

For 30 minutes of effort - that calculation is a no brainer to me. It just takes getting over that lurker inertia, and a lot of patience for failure!

A far better quote than the one I used in the article - thanks for this one, I'll be hanging on it!

I don't think I was clear enough on that point - I didn't mean that the session state itself would be accessed as a REST resource.

I imagine the session state would consist of client side Javascript (since this service would be ideal for the type of single page apps served well by Backbone.js and the like). The javascript would probably submit time-expiring authentication tokens with each request. That way, session could be persisted client side, while maintaining permissioned access to the CRUD actions on the service side.

EDIT (to respond to 6ren's edit):

I agree that, in a production environment, the flexibility of the rapid prototyping could, in many cases, turn into rigidity when faced with just a RESTful API.

But not necessarily in all cases, especially when implementing a single page app style site, where you are more likely to persist data client side in the background for when you need it.

Ultimately, I think the tradeoff might be worth in some circumstances. And given the apparent success of the many mobile BaaS solutions, it seems to be often enough to capitalize on.

I'm not sure. It certainly couldn't handle every use case, but maybe with some convention-style configurations (e.g. a record created via a POST to /users would hash any "password" field) you could handle a bunch of typical web app scenarios.

And if that doesn't work, perhaps the schema-less prototyping is a free tier with a more robust backend service offering for the paid tier?

If it were to operate as simply a REST API, then the service could simply return everything via JSONP to avoid the CORS trap.

True, but don't those services require schema definitions and similar setup? It seems like a lot of prototyping could be sped up by simply inferring relationships based on RESTful URLs and relying on schema-less storage.