ora600

According to the article, Yelp had 7 different data sources and similar number of targets.

If they wrote a loader for each combination, they'd end up with 49 combinations. Not to mention 7 loaders to write every time they add an app.

With Kafka - they just need to connect each thing to Kafka - 14 connectors instead of 49.

This is pretty much the scenario Kafka was invented for, and you get stream processing for free: https://engineering.linkedin.com/distributed-systems/log-wha...

required.acks works together with min.insync.replicas.

Basically "required.acks" lets you choose between "no acks", "leader only" and "all in sync replicas", while min.insync.replicas lets you control what "all in sync replicas" actually mean.

In this case, you will enjoy the new consumer in 0.9 a lot!

I already use Houzz for something similar. Houzz lets me browse products by similar categories, but also lets me see how the product looks in actual rooms and has lots of social features.

Scala: Java has tons of boiler-plate code and is not "functional" enough.

Obviously the author doesn't have kids. I don't think anything can prevent them from breaking and changing things. Maybe they won't do it with iPad (although I doubt it), but they'll still do it. Part of being a human child and all.

If you are currently living and creating wealth in Somalia, then I agree - society doesn't help you much and if you pay any taxes, you can stop.

If you live in a first world country, you should realize that the difference between your country and Somalia is a result of government work and is funded by taxes.

Secure borders, police guaranteeing your property rights, courts, lack of bribes and corruption (relatively!), good roads, good lines of communications, educated people to hire. They don't just show up randomly in places.

Years ago I've read an article that recommended doing this manually as a way to assist the flow of traffic.

I thought its a nice idea and tried it. Unfortunately, I tried this in Tel-Aviv, where drivers from other lanes immediately moved their cars into the space that opened between my car and the one ahead of me. It didn't take me long to figure out that I'm getting nowhere.

Two years later, when I moved to the bay area, I tried it on the 101 during rush hour traffic. To my shock, it worked. It was exceedingly rare to have any car move into that space. Or move lanes in general. For some reason (laziness? safety?), California drivers don't switch lanes as much as Israeli drivers do.

Moral: There's time and place for every algorithm.

I love the explanation of terms. Highly useful.

It also highlights the near complete lack of correlation between how much a plan costs and how much benefits you get.

... and ZFS copy-on-write has been known to cause severe performance degradation for databases. Not to mention that too many SAs keep the default ZFS block size, which is far too large for OLTP databases.

That's an awesome idea and I hope it works out well. I'd love to be able to follow my favorite hair stylist and beautician around. I also hope my customers will want to follow their favorite database consultant :)

You see, passwords suck. Big time. They are extremely vulnerable to brute-force attacks, people forget them, people write them down on post-it notes, and people use the same password on every single site. Not to mention that the website has to store your password securely, and not every website has amazing track record doing that.

Passwords make the world less secure.

So we need to replace them with something. And that "something" has to be secure and easy to use.

Turns out that this is a difficult problem to solve, so we keep trying. I agree that OpenID is not exactly the perfect solution, but it doesn't mean that there is no problem to solve.

What I'd really want to see is public-key authentication for website.

Let me upload my public key when I create an account on a website, and let the browser interact with my ssh-agent to authenticate.

(2) It is very easy to be super busy and bored. Having lots of boring work does not magically add up to become interesting all of the sudden.

This is almost like Oracle support telling me "There is no problem" after I call them about my database corruption.

The author, who obviously loves your software, couldn't find you enough times that he wrote a blog post about it. There are several reddit thread about this issue. Several replies to this thread express the same frustration - they can't find your software when they know it exists and want to use it. You hear it a lot yourself too.

But still you don't think its a big deal. I'm wondering what kind of evidence will convince you its a big deal.

It sounds like awesome software. I'm glad I've heard of it. I just hope I'll remember the name when I'll need it.

I did both, and in my situation it seems that travel is a bigger issue.

Even with crazy startup hours, we could usually get at least one shared meal a day and you know... see each other. We could also workout together. Maybe get a hug while I'm talking to a customer on one hand and coding in the other. It adds up.

When you are in another state - its really away.

Consulting often means lots of travel time. Even remote customers will usually want to meet face-to-face at some point, and requirement gathering is often best done on-site.

This becomes an issue when you want to settle down and grow your family.

Follow up research I'd like to see:

Some research has been done on effective group problem solving. There are several possible methods - pick a leader and let him decide, reach consensus, majority decision, etc. Some have been shown to be more effective than the rest.

Teach an effective method to all groups, and see if there is still any difference.

Actually the article says "the more women the better". I don't think an all-women group could count as diverse. The researchers explained the findings in terms of "social sensitivity" and communication style, not diversity.

The gap between exceptional developers and average developers was proven in some planned experiments, as described in Peopleware.

This article, on the other hand, contains lots of philosophy, imagining and wishful thinkings - but not an ounce of proof.

The only fact is about analysts - not developers. The financial field does not make a good comparison - random chance plays a much bigger role in wall-street than in software development.

I recall reading in "Random Walk Down Wall-Street" that it has been shown that even the best managed funds don't do better than well-diversified random stock selection. Taking the high impact of chance in the investment sector into account, if someone was a star analyst at one place, it is likely that he'll perform worse at his next assignment due to regression to mean.

Heh, its nice to see a version of "don't wear a short skirt when you go out, and don't drink" aimed at the 50% of the population that normally don't get blamed when they are victims of crime.

They don't seem to like it either.

Also, the lack of any scalability charts or diagrams of architecture is suspicious.

If you can't make it opensource, at least write a serious paper to support the claims. Like Google did for Big-Table.

A lot of people think their systems are scalable and fault-tolerant. Most are not. And from the information provided, we can't tell.

If I was evil and suicidal I could wipe up many companies by "drop database including backup".

When you have DBA access to production databases, lack of root does not stand in the way of doing evil.

It does stand in the way of using message logs to troubleshoot, checking contents of /proc to determine which directory a process is running from, tuning TCP parameters to maximize data transfer rates without nagging the sysadmins, etc.

It is my understanding that airlines going bankrupt again and again is a direct result of their relationship with their pilot unions:

http://philip.greenspun.com/flying/unions-and-airlines

As a database consultant I can assure you there are great many servers on which I have a user, but no ability to "su root".

Oh, that was my favorite thing about working at HP. The conversations!

"Where do you work?"

"HP"

"Oh, I have a problem with my printer/laptop"

"Actually, I work on superdome specific optimizations for the HPUX compiler."

"So why does printer ink cost so much?"

....

My guess is that you didn't seriously learn functional programming in any language.

It is not just about memory management and data structures. It is about functions as first class objects, no side effects, lazy evaluation, closure, monads. The fact that you can basically write a compiler in an hour as a first year student (that was exercise 3 in my course).

I'm not a programmer, I'm a DBA. The code I write is mostly short and ugly scripts in Perl and Bash. I can do very little Java and almost no other language. The one and only time I used Lisp was in my first programming course in the university. Incidentally, it was also the one and only time I enjoyed programming.

Also, I bet that Cloudera already hired many of the best Hadoop engineers in Yahoo. Because the founders knew who they are and could put serious resources into recruiting them.

Cloudera is pretty much dominating the commercial Hadoop market now. It has a huge marketing head-start and arguably better engineers, since it was founded by Yahoo's employees who thought they can do better by leaving. They also have more experienced support and training organizations, pretty much by definition (Yahoo's Hadoop group didn't do that).

I'm wondering how Yahoo spinoff is planning to compete.

Cubist.