I was astonished when websites started asking for your login credentials for *other* websites in order to scrape your contact info.

The continued erosion of privacy is starting to look like the proverbial frog being boiled alive.

Google would love to have the Facebook and Linkedin social graphs. It seems credible that they would use your credentials to scrape your portion of the graph.

Of course they would put this in their next privacy policy, in suitably nice language, which would cause minor discomfort going down.

So I'm curious why you find the idea ridiculous. Do you not agree that Google desperately wants this data? Or do you think they have some ethical barrier to acquiring it?

But, alas, the second part of that equation â" Google Apps continuing to get better â" just isn't happening as fast as we'd like.
Seems to be a common syndrome. I think the root cause is that Google Apps is a weapon pointed at Microsoft's heart. Google and Microsoft probably have a lot of private conversations. Keeping this weapon pointed gives Google one more bargaining chip when dealing with MS.
Same syndrome when a big company talks about "switching to linux", if I remember correctly from years ago. They don't really switch to Linux, but Microsoft probably becomes more accomodating in their negotiations.
I imagine that inside Google, people developing Apps may be frustrated and wonder why management seems to be sabotaging them. This is often the case when management does the seemingly irrational for strategic reasons.

Actually, an Excel workbook can contain multiple sheets (or tables, as we say in database-land).

And Excel can connect to a database such as MySQL and become just a GUI front end. But when I saw this done around 1999, Excel crushed the DB with horrible queries.

> I take that to mean it is a public domain performance, too.

It means the vendor lets you have unlimited use of the music in exchange for a one-time fee. It's common in film production.

A lot of those puzzles fall into a small number of categories:

• Fermi estimation - how many piano tuners in L.A?
• Church problem - gardeners who may have dirt on their forehead, pirates dividing coins - generally, recursive reasoning about other rational actors
• Discrete Measuring - dividing water or gold or whatever given inconveniently sized measuring devices.

Once you master the solution to one category, all the variations in that category are trivial.

"Freezing up" is precisely the problem; you can solve a lot of these puzzles by following your chain of logic to its end instead of abandoning it when it looks difficult or sketchy.

Whether these puzzles are good for hiring is another matter.

I asked to him to write a certain program on the laptop, using the language of his choice. He chose C++.

He looked up APIs on google and an in man pages.

I'm pretty happy with the program. It's correct, no slower than necessary, reasonably readable. A few minor improvements can be made, and he started to find these before we ran out of time.

Unfortunately he did badly with other interviewers in classic whiteboard situations, so I don't think he'll be hired.

This is the second time I've interviewed this way. I learned that a small task takes much longer to code than I think. Also, that this measures something quite different from whiteboard questions.

Preferred knives? Probably. But I've seen comments from chefs that they wouldn't take their good knives to work, where kitchen help would borrow or ruin them.

"He can do more with a candlestick than most men with a pistol. But he is pretty sure to have the pistol, too."

I run Ubuntu. With every upgrade, they break something and I have to spend time researching it.

Mostly this breakage is someone trying to "improve" things.
For example, pulse-audio. I suffered with it for a long while, then finally found how to rip it out by the roots.

I do not want unix to be like Windows.
I do not want my expectations broken on every release. Let it be. Make it stable.

This is compatible with progress. I want great new applications like Chrome. New apps and libraries don't disrupt the platform. I wish these guys would understand how much of other people's time they are wasting.

I realize that what I'm about to say might not appeal to you. Please try to keep an open mind.

I've been reading Slashdot since about 1999. I've seen a lot of "outrage stories". Stories intended to get your blood pressure shooting through the roof. And they used to work on me.

Remember when Iraq invaded Kuwait? The story was circulated that Iraqi soldiers were taking premature babies out of incubators and throwing them on the ground. Turned out to be a total fabrication, created by Kuwait to get the US into the war. It worked.

Every controversy has two sides. No sane court will convict without hearing both sides. "There are two sides to every beef."

The "outrage story" is always based on giving you only one side. And it works - until you're old enough to recognize it.

Realize that every person who had an unpleasant contact with these border guards could tell a similar story. Only one in a 100 will recognize his own mistake. The majority will claim that he was nice, and the other guy created the problem.

The power to tax is the power to destroy

...and almost any serious MySQL shop uses InnoDB exclusively...

I work at a pretty serious MySQL user, and we use both MyIsam and InnoDB. Properly tuned and used, Isam is faster. Innodb allegedly has the edge in PK-lookups, but my measurements disagree.

Innodb is good if you want Oracle-ish features. Mostly we don't. In fact, the current is flowing the other way; towards things even leaner than MySQL.

We mysqldump the slave, which eliminates that issue. (You can also stop the slave and cp the db files; I think this does not work with Inno). Table locks remain a serious performance issue in Isam; it does take extra effort to prevent lock contention.

Thank you. It still seems to me that the more beneficial part of attr_accessor (automating accessor boilerplate) can be done at compile time.

The term "Monkey Patching" is new to me. If you wanted to (and I shudder at the thought) you could probably apply it to virtual methods in C++ since their addresses are stored in a class vtable.

Within each of the two blocks, the two lines are equivalent; one Perl and one Python. There is no relationship between the two blocks.

Eg attr_accessor. It is a method which, when evaluated by the interpreter generates accessor methods for the names passed in.

I know nothing about Ruby and attr_accessor, but from a quick search this seems to be a compile-time feature. Couldn't you add attr_accessor to a C++ compiler? The compiler would generate the accessor methods.

Perl can be written to be prettier than Python or uglier than anything else imaginable.

Even well-written Perl is noisier than Python.

my $txn = $store->getTxnGroup()->getTxn($txn_id);
txn = store.getTxnGroup().getTxn(txn_id)

Or:

my $ids = [ map { $_->{ id } } @$txns ];
ids = [i['id'] for i in txns]

I still love Perl, but can only think of one place where it's prettier than Python - that's quoting.