jackowayed

Node.js isn't really a usecase that dictates what datastore you should use, it's just a certain way of writing a totally different piece of your app.

In most node.js apps, the best answer is probably a SQL database. Sorry.

If you're working with timelines or other cases where Redis's data models can help you, consider it, though beware that if your data is large, things will get more expensive fast since you're keeping everything in RAM.

HBase, Cassandra, and Riak are all reasonable in similar cases and have their own tradeoffs.

And yes, Couch fits a similar niche as Mongo. You might even be able to use something simpler like BerkeleyDB (quite mature) if you think you want a document store.

RethinkDB may be a nice choice too. It's fairly young but looks like it's going good places.

But your choice should be mostly dependent on what kind of data you're storing and what kind of guarantees and access models you need.

It should not be based on someone on HN telling you "Riak is the best NoSQL database for Node.js" because their idea of what most Node apps need may not be what yours needs.

Ugh. I read Aljazeera English fairly regularly a year ago, before Aljazeera America existed. I appreciated the solid-yet-concise reporting, the fact that there was little enough news that I could kind of read it all, and the fact that it wasn't as America-centric as I'm used to (nice change of perspective).

And now that they're trying to break into the US market, I see a page filled with tweets? I really hope that they don't think adopting CNN's "we'll just read a ton of tweets on air" strategy (which is what finally lead me to swear off CNN entirely) is how to win the US market. I was looking forward to them providing something a little more serious, kind of like NPR.

Yes. I believe you have to stay a year to keep the bonus, but everyone I know who graduated from Stanford last year was offered >100k salary, 100k signing bonus, and some stock (I think per year the stock was about 25k at current market value).

Even non-CS majors. If they studied a quantitative field, can code, and cleared the dev interview, they got that offer.

Well, the front brake has ~70% of the stopping power (both on bikes and cars), so while that will work (assuming you don't skid in the back), it won't be the fastest. You can get quite a bit of stopping out of your front brake without going over, you just have to be precise.

That said, it's a curve with a 40mph speed limit and a 35mph recommendation. If it's not safe to do 35mph around that curve, the road authorities should mark it accordingly.

Wow. Ok, here's some details on the accident based on news stories linked there.

First, background for people who don't know the area:

So this is in Woodside, the hills just west of Palo Alto. It's a nice area where you get more space and nature than living in Menlo Park/PA/MV, at the cost of having a fairly slow drive to get anywhere.

Skyline, the road she was on, is the main north-south way through that area. It's a one-lane-each-way, narrow-shoulder, trees-on-all-sides (leading to weird lighting at most hours) road that is fairly straight for that area, but still has some curves. I think the speed limit is 40mph.

The stretch of Skyline she was on is a very popular bike route. Some people will bike a lot of Skyline, but that ~one mile stretch is especially popular. Old La Honda Rd is a narrow, windy road that is one of the most famous cycling climbs in the area; it's got good shade and is a very steady 7% grade for the whole 3.5 miles. It's intense. Go out on a weekend and you will run into other cyclists, usually many others.

When you get to the top and want to loop back towards Palo Alto/etc, you basically have two options. One is to just go back down, but descending a road that steep and windy, especially given that there's basically always a cliff on one side, is pretty frightening. So I always take the other option, which is to take Skyline down to highway 84, the same direction and stretch of road she was doing.

That always feels like the safe part of the descent to me--it's mostly straight, people drive slightly slower than on 84, and it's not as steep of a descent as 84. 84 is frightening because there still isn't a shoulder, there's some really steep sections, there's some tight switchbacks, and people drive 50 mph.

But, sure enough, where her accident was on Skyline, there's a big blind curve, and not very far after it there's a tiny road (basically a driveway) off to the right. It sounds like as she came around that curve, a van that was headed the opposite direction on Skyline turned left in front of her into that small road, and she ended up hitting the van.

Scary.

I think it would still work. I think you'll end up both getting all of the network packets, in which case the higher-level protocols will ignore the ones meant for the other device. TCP and UDP both have source ports as well as destination ports, but the source ports are usually picked arbitrarily, so the different devices will have connections on different ports and will discard any packets bound for ports they don't have open. And TCP also has sequence numbers (which should be chosen randomly), so even if you ended up on the same port for a TCP connection, your packets are very likely to have different enough seqnos that you ignore each other's packets.

The Architecture of Open Source Applications books[1], while eclectic, seem pretty good from the chapters I've read. They have a few chapters about distributed systems--HDFS, Riak, and a chapter about "Scalable Web Architecture and Distributed Systems" (haven't read it).

1: http://aosabook.org/en/index.html

Faster the more help we get!

As part of my Matasano internship, I've been working on a patch to NSS (Mozilla's crypto library, used by both Firefox and Chrome for TLS) that will give the necessary hooks needed for browsers that use NSS to implement TACK. I'll hopefully be submitting that for review soon (you can see it on bugzilla[1] and fresher in-progress GitHub[2]).

At this point, it mostly makes sense for me to finish that (though I'll have a lot less time when I go back to school, so there might be some work that needs to get done when the review comments come back that I can't get to for awhile, so someone to power that to the finish might be helpful).

But once that's in, we'll need to work on getting patches into the Firefox and Chrome that actually integrate TACK. There's also some other work to do, especially for some other longterm ideas we have (eg. securing communication between mail servers with TACK).

If you're interested in helping, either email Trevor (email is on his website[3]), or email me (danielj@matasano for the next week, personal email in my profile).

1: https://bugzilla.mozilla.org/show_bug.cgi?id=905848

2: https://github.com/jackowayed/mozilla-nss/pull/1

3: http://trevp.net

He's not trying to convince anyone. It's all posturing. He's trying to look as good as possible (look like a reasonable, restrained, trustable major player in international politics), and put the US in a position where we look as bad as possible if we do intervene.

And he's doing a great job. The offer to get Syria to put their chemical weapons under international control was brilliant. Obama was saying, "They crossed a red line, there's no option but military," and then Putin put forth a peaceful solution.

Why bother paying a ton for ad space on the day when you know that the site will basically be a giant ad for you anyway?

I would call supporting the objectification of women misogyny. Sure, it's not traditional "hatred" (But really, how many people hate all women in the traditional sense? Is that all people think misogyny means?), but it's a failure to value women as people.

Regardless, it's more than just bad taste. At a professional event for a group that has terrible gender balance, glorifying the objectification onstage only further creates a culture where it is hard for women to feel welcome. It's bad taste that is Part of the Problem. And even a sexualized environment (eg. the stupid CircleShake presentation) can make a lot of people feel uncomfortable, especially women since society views male and female sexuality very differently. Plus women are overwhelmingly the ones who have had very bad experiences with sex (sexual assault, etc), or have worried about it even if it hasn't happened.

So both presentations contributed to the status quo that makes tech/startups feel like a boys club, making it harder for women to feel comfortable joining the communities. I think that supporting these unjust, sexist status quos is misogyny, so both presentations were--in effect, if not in intention--misogynistic.

But it also doesn't matter. He's the CTO. If he were a random dev, firing him would probably be extreme. Talk to him, ask him to avoid touching controversial subjects online for awhile and be more careful and considerate. But this is the guy who leads the technical team. He has a lot of impact on the culture. If he thinks the right response to stupid guys who support the objectification of women onstage at a large, publicly-broadcast professional event is to defend them as "not misogynists," then I don't trust him to be very sensitive to how his work environment may need improvement to make women feel more comfortable. And I doubt many prospective female engineers would either.

Oh, I see, generate two different binaries of the same compiler with different compilers, and you know something is up if the same source compiled by those two separate binaries of the same compiler differ. Assuming the compiler is deterministic, that should work pretty well.

I wonder how well that would work in practice. There are actually quite a few bugs in C compilers[1], and compilers are complicated enough that I could see them hitting some of them when they are compiled. Has anyone done this before?

1: http://www.stanford.edu/class/cs343/resources/finding-bugs-c...

No, the same source code will generate different binaries. The spec doesn't say exactly how source code has to map to machine code, just what should happen based on source code. Differences in the optimizers are almost certain to yield differences in the optimized binaries, and even with optimizations off, binaries are likely to be different due to different compilers making decisions that are more-or-less arbitrary differently.

(Plus a backdoor could easily be set to run only when optimizations are on. Almost all production builds that one would want to exploit should be built optimized, and it would make the exploit a bit harder to spot in compiled binaries.)

Ugh!

This comment conveys the all-too-common reality that "cultural fit" is code for "everyone should be like us." To the extent that cultural fit is a defensible hiring criterion, or even a good one, it doesn't mean pure homogeneity.

There are a lot of ways where it's obvious that you don't want homogeneity. Take the question above. It may be good for the company if all of the individual contributors like being taken advantage of, as they'll work long hours for bad pay or whatever. But if your upper management or sales team likes being taken advantage of, they're going to let the company be taken advantage of, and now it's not so good.

In a lot of things, it's way healthier to have a mix. You want people who like and excel at starting projects and laying good groundwork, and you want others who like refining and maintaining systems that are already defined, because any company that's still building new systems will need people to do both. In most development teams, having all of either will be bad news.

And the same goes for personality issues. It may seem great to build a culture around people coming in at the same abnormal time as you and liking the same kind of fun as you. We're all together all day! We can bond through that fun! But there are a lot of problems that crop up as you grow. Once your culture is defined by, say, being a bunch of 23-year-old men who come in at noon and love video games and drinking, people who don't fit some or all of those characteristics might not feel especially welcome. Hiring people for areas other than engineering gets hard. Hiring senior engineers who are more likely to need to be home by 6 gets hard. Hiring women gets hard. You've just boxed yourself into a pretty small corner of your potential talent pool.

I've seen great companies built out of beautiful mixes of people. A married foodie who lives in SF working alongside a through-and-through Southerner who thinks In-N-Out is exotic. Fresh out of college video game players alongside parents with two decades of experience who like hiking. People still got along great and had a lot of fun together. There were certainly some commonalities, but I'm sure people would answer personality questions in drastically different ways. That doesn't mean they don't "fit" together.

There certainly are some cases where rejecting someone on "fit" reasons makes sense. Say you interview someone who is technically great, seems to be able to generally work well with others, but is terrible at pair programming. Will never cede the keyboard or listen much to their partner, and doesn't seem to be trying to fix it. If your company does a lot of pair programming, don't hire them. If you're a company that doesn't really do pairing, this might be a bit of a red flag, but it's not a deal breaker. There might be some analogs in the personality space.

But culture fit definitely should not mean "we have identical personalities."

This stuff matters. I'm the kind of person who would pass a lot of "culture fit" homogeneity tests (young, white, male, pretty nerdy, elite university), but I hate the homogenous cultures that often crop up at Valley companies and actively avoid them. A major factor in choosing to intern at Matasano this summer instead of some companies that are filled with very happy 22-year-old men is the much more reasonable culture, and all 'tptacek has written on HN about how "culture fit" is often BS.

So if you build a culture where "fit" means "be like us," you won't just cut out a lot of people who aren't like you, you'll cut out people who are like you but prefer communities of diverse people.

Read it aloud. You'll catch typos (save homophones), awkward phrasing, sentences that are long and confusing, and more.

I clicked through the purchase flow and noticed the "SSL secured" text.

But the homepage is not served via SSL. I assume the actual purchase form submits through SSL, but an active network attacker could change it to submit anywhere they want, and no one would know.

Everyone makes this mistake, because they think of SSL as being just encryption. It's encryption, but it's also integrity. If a page has security-sensitive functionality at all near it, you want integrity, even if the content is public. (Another example: You have a totally static personal site. Why would that possibly demand SSL? Well, say you want to post your GPG public key so people can send you encrypted email. Someone who can intercept mail bound for you might also be able to MITM your site, so you want SSL to ensure people actually get your real key.)

Just serve everything over SSL always, and you won't have to think about this.

You can easily find a bedroom in Palo Alto for $1500 (maybe not right downtown, maybe as part of a bigger house/apartment, but a bedroom to yourself). It seems like ~1k is still achievable if you're patient and any part of PA will do. And it only gets cheaper if you're willing to go to Mountain View (only a bit cheaper), Redwood City, or really any other part of the peninsula.

Up until December 2009, my main computer was a desktop we'd bought in 2000. At some point, we had upgraded it from 128MB of RAM to 384MB.

That last year or so, things got rough. I was really pushing the limit of what it could run without feeling unreasonably sluggish (with pretty normal workloads of browsing, IM, and either word processing or Ruby coding). First, I switched from Firefox to Opera. Then, I switched from Gnome to Xfce to IceWM. This made a world of difference, and I really didn't miss Gnome. It got me another 6 months+ out of that computer without being terribly frustrated all the time.

In most cases, on a modern computer where you have multiple gigabytes of RAM, I agree with you. But it's still nice to have those tiny window managers around.

I was considering various things, with a strong desire for something simple and likely to stay around for awhile. I thought about emacs gnus, Thunderbird, and some of the new entrants.

I realized that I would be as happy with something that just sent me a filterable email for every entry in all of my fields, since I already have good interfaces for reading and culling mail on all of my platforms.

So I found one. http://blogtrottr.com/ It seemed nice and had an easy import. If something happens to it, I'm sure I can find another.

For now I'm filtering it all into its own folder, though I try to keep my feeds pretty low-volume, so it wouldn't even be a huge deal if they all landed in my already-pretty-noisy inbox.

I just did that this weekend, but so far I'm quite happy

Yep. There's a well-written article about an early DDoS extortion attempt where the victim fought instead of paying, developing some novel protection technology in the proces: http://www.csoonline.com/article/print/220336

Ugh, this keeps coming up. No amount of cooperation from Certificate Authorities will enable passive attacks on SSL.

All the CA does is cryptographically certify "this is the public key that the Company (eg. Google) gave me"; they never see the corresponding private key.

Cooperation from the CA might give the NSA their own certificates for Google, which would allow for an active man-in-the-middle attack. Certificate pinning would defeat that, and doing that on the fly in the Internet at large would be a serious undertaking.

But if they want to decrypt traffic passively and they don't know about serious SSL vulnerabilities, they would have to have Google's private key. And with Perfect Forward Secrecy, even that is not sufficient. (PFS requires an active attack because the session key can only be determined if you're actually one of the two doing the handshake, or you know how to factor very large numbers.)

If you read "Consider the Lobster" (which you should), you'll note that the product did change. Lobster used to be cooked dead, then canned in saltwater. Now it's cooked live and served immediately with a hefty side of melted butter.

Sure, maybe the class-based issues made it less likely that people would be willing to try even lobster done right, but I don't think lobster as it was once served would have much more success today.

I think this makes a lot more sense on the choosing a job side than the hiring side.

I've had great luck working for awesome friends of mine and awesome friends/acquaintances/ex-coworkers of their friends. In a large software organization, so much comes down to not just the company and the problems but the exact team you're on that removing a lot of that uncertainty and working on a team with/for people close in your social graph is great.

But strongly biasing your hiring search toward people close in the social graph is a terrible idea. First of all, you're artificially limiting the pool of "ideal candidates" dramatically. Second of all, if most people you hire are friends of friends, you're likely not to build a very diverse company. Your culture will get skewed toward things that you and your friends care about and are interested in, and pretty soon there will be large groups of people who don't feel that they especially fit in at your company because eg. they're not male, they have kids, they don't drink, they don't watch sports, they read philosophy, they don't find working >40 hours/week productive or enjoyable.

This is a problem in many Silicon Valley startups that leads me, despite being demographically indistinguishable from what these companies overindex on (young, male, white, straight, elite education), not to want to work at most Valley startups. I deeply admire that Thomas cares about making a company that avoids these problems, which is a large reason why I'm working for Matasano this summer instead of one of the many Valley companies that would feed me three meals a day and in many cases would have a better-known brand.

But the comment I replied to basically posited "wealth" as the one and only universal good by suggesting that if the government strives for something that doesn't eventually yield wealth, there's no point.

An overused example: Fascism has at times lead to incredible economic growth, creating wealth that did measurable good in most citizen's lives (by ending terrible depressions). But there was more that came along with that, which mostly wasn't cutting into the country's wealth (maybe it squanders some human capital, but so does 30% unemployment, which the Nazis completely reversed in around 5 years). Despite the positive implications of fascism on "wealth", there's a lot that the Nazis did that most would be inclined to call bad.

On the other hand, Scandanavian socialist democracy may not be optimal for wealth creation, but it has a lot of benefits that help people lead enjoyable lives that are free from the risk of various kinds of terrible suffering (eg. homelessness).

There are no universal goods, but when pushed, very few people are actually willing to eschew all goods except wealth. And if you are, what's so special about wealth that makes it a good you're willing to quasi-universalize?

> Long term, if political freedom doesn't bring wealth, then what is the bloody point?

Seriously? You think that everything a government should strive to guarantee is a means where the end is wealth? You don't think that equality, freedom to criticize questionable government practices (even those that improve GDP), or anything else should be a goal in itself?

There are laws and medical licenses for this reason. There are always incentives to cut costs, whether administering medicine for cash from patients or for insurance payments.

At least with this model, the patient is choosing the doctor, paying him, and receiving he care. So if he cuts corners in a way that makes the patient less satisfied (eg. very short appointments, cramped/dilapidated office, bad on-time performance, office in a bad part of town), the patient can choose to go elsewhere. If it's the one place the patient's insurance will cover thanks to the reduced price from cutting those corners, the patient has no real choice.

The cost of food is very predictable and pretty flexible. Anyone who needs to can eat well on <$100/week as long as they have access to a reasonably-priced grocery store and facilities to cook and store food. (Also, note that even our barebones welfare state includes foodstamps.)

On the other hand, medical costs can vary wildly and randomly. A perfectly healthy person who's been following health best practices might suddenly develop a serious condition that is treatable, but only with five to six figures of treatment.

It's the same interface for the developer, but instead of being run directly on the CPU, it's run in a JavaScript virtual machine that interprets it or eventually compiles it to some kind of native code. That's very hard to overcome from a performance standpoint.

HBase isn't built for analysis workloads. It doesn't have a complex query engine, so you end up having to do massive scans (which aren't especially fast), transfer a ton of data to the node where your analytics code is running, and do the computation there. If things are too big to run on one machine, that's your problem, not HBase's.

On the other hand, Impala, RedShift, Oracle Exadata, etc. let you ask the database to do work at a much higher level, which allows for much better performance because the data storage and computation layers can work in tandem (so you can prune down to only the data your query needs at each storage node before hitting the network, for example), and the database does the work of optimizing for multiple cores and nodes, not the writer of the analysis routine.