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.