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.
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.
...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.
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.
I work at BIGCO. Everything you say is partly true, but:
I've developed apps on Oracle and MySQL. Cost is not a factor; we get Oracle for free here. And yet I always choose MySQL for new projects. And that is the overwhelming majority preference, among experienced engineers who disagree on lots of other things. Why?
Performance. Even with good DBAs investing a lot of time, Oracle cannot deliver. Remember, we tune our schema and MySQL instance until it's faster than many custom-written datastores. (Obviously, I'm talking about MyISAM). MySQL is so fat-free that it's hard to beat in custom C. And yes, MySQL's performance falls off rapidly with complex queries. Query optimization does consume significant engineering time.
Hassle factor. Just as you feel MySQL has imposed too much weirdness on you, I feel that Oracle has wasted too many of my hours. Everything about this db is clumsy, old-fashioned and obscure.
Transaction-phobia. We're not doing banking apps here. I remember Oracle instances getting slow because open sessions are piling up, either from humans, broken pooling, or scripts. One more headache I'm thankfully free from.
There's no free lunch here. Oracle provides a more seamless abstraction, including ACID, at the price of performance. That is an appropriate tradeoff for some apps.
It is complex. Part of engineering is constantly evaluating what-if scenarios. In my group, the Indian engineers are so much faster at mental arithmetic that they can evaluate a possibility without "breaking stride". In practice, it means more ideas are considered.
It's tempting to dismiss arithmetic as useless because we have electronic support, but having it on tap does change the dynamic of design meetings.
Of course I know that power came at a price; many extra hours spent drilling arithmetic instead of learning an instrument, or hacking, or whatever.
Beating "us" at what?? Cheap labor? Human rights violations? Mass poverty?
Beating us at being a world power. Yes, we are still ahead. But the first derivative favors China.
I just read a great article on Gao Xiqing, a Chinese official who oversees $200 billion of China's US investment. Studied and worked in the US. He probably has a better sense of where the US is heading than most of us.
He criticized the tendency for the brightest Americans to pursue Law, MBA, and finance rather than engineering/science. (Caused by salary imbalance).
In the long term, if a country full of lawyers, MBAs and financial wizards, with no industrial base, gets in a war with a country of engineers and scientists with a huge industrial base, what do you think will happen?
Your experience is limited to dealing and interacting with Chinese/Indian/etc software engineers who are most likely members of the upper echelon of their country's respective caste systems. The ones with the opportunities to study abroad, attend universities, build careers, etc. Of course it will seem like the entire population values education as highly as you make it seem if that is all you deal with.
That's a good point in general. But my co-worker's children are in school in China, because American school doesn't challenge them. I forget the exact delta in math education, but it's big.
I work with lots of good Chinese and Indian software engineers. Most never saw a computer before University. They did have a rigorous and old-fashioned education, with lots of math and logic.
I also know talented hackers who got into programming as kids/teenagers, and benefited from the fast dev cycle of Apples, TRS-80s, etc.
But giving kids the latest and greatest computers is not going to help anything. The important stuff can be learned on a 486.
Chinese and Indian schools value the academic achievers, while American schools value the funny, the athletic and the socially gifted. That is why those countries are beating us.
I've worked on both good and bad Perl. Perl's sigils are not an issue; neither are Lisp's parentheses or Python's whitespace. These things cease to annoy once you spend some time with the language.
The reason there's a lot of bad Perl is the reason there's a lot of bad PHP: both languages enable beginning programmers to get things done.
I have great respect for Schneier as a computer security expert. Applied Cryptography was wonderful. But Schneier errs in thinking that physical security is the same thing as cyber security, and that his computer/crypto expertise somehow extends to the physical world.
A lot of geeks share Schneier's fallacy. And since geeks tend to be a lot smarter than the folks in charge of real-world security, the tendency to false superiority is magnified. But intelligence is not the whole story. There is also experience and instinct.
Some of the key differences:
In the real world, security through obscurity often works. And is often the only way to achieve a goal.
In the real world, any security measure which causes an attacker to make an extra move, or expend extra resources, is useful.
In the real world, there are no perfect barriers; there aren't even any strong barriers. All barriers are just speed bumps.
If Schneier (or any computer geek) were in charge of airport security, I'm pretty sure we would have had another terrorist incident since 9/11.
If all you care about is speed, then you can get even more if you go with an embedded database like Firebird or SQLite. Or try a flat file. Those are terrifically fast if you do them right.
In my experience, SQLite is slower than MySQL, despite being in-process. SQLite is transactional, remember? And flat files will only support linear scan lookups, unless you implement your own indexing scheme. Which would make them "non-flat". Unless the table is very small, MySQL will be faster on SELECTs (by PK) than the flat file.
Slashdot Mirror
On an Atmel AVR with 2K of RAM, I found C++ works well. Of course you have to be conservative about using language features.
I can see how with multiple programmers at different skill levels its dangerous.
In principle with C++ you don't pay for what you don't use.
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:
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
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.
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.
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.
I work at BIGCO. Everything you say is partly true, but:
I've developed apps on Oracle and MySQL. Cost is not a factor; we get Oracle for free here. And yet I always choose MySQL for new projects. And that is the overwhelming majority preference, among experienced engineers who disagree on lots of other things. Why?
There's no free lunch here. Oracle provides a more seamless abstraction, including ACID, at the price of performance. That is an appropriate tradeoff for some apps.
It is complex. Part of engineering is constantly evaluating what-if scenarios. In my group, the Indian engineers are so much faster at mental arithmetic that they can evaluate a possibility without "breaking stride". In practice, it means more ideas are considered.
It's tempting to dismiss arithmetic as useless because we have electronic support, but having it on tap does change the dynamic of design meetings.
Of course I know that power came at a price; many extra hours spent drilling arithmetic instead of learning an instrument, or hacking, or whatever.
Beating us at being a world power. Yes, we are still ahead. But the first derivative favors China.
I just read a great article on Gao Xiqing, a Chinese official who oversees $200 billion of China's US investment. Studied and worked in the US. He probably has a better sense of where the US is heading than most of us.
He criticized the tendency for the brightest Americans to pursue Law, MBA, and finance rather than engineering/science. (Caused by salary imbalance).
In the long term, if a country full of lawyers, MBAs and financial wizards, with no industrial base, gets in a war with a country of engineers and scientists with a huge industrial base, what do you think will happen?
That's a good point in general. But my co-worker's children are in school in China, because American school doesn't challenge them. I forget the exact delta in math education, but it's big.
I work with lots of good Chinese and Indian software engineers. Most never saw a computer before University. They did have a rigorous and old-fashioned education, with lots of math and logic.
I also know talented hackers who got into programming as kids/teenagers, and benefited from the fast dev cycle of Apples, TRS-80s, etc.
But giving kids the latest and greatest computers is not going to help anything. The important stuff can be learned on a 486.
Chinese and Indian schools value the academic achievers, while American schools value the funny, the athletic and the socially gifted. That is why those countries are beating us.
I've worked on both good and bad Perl. Perl's sigils are not an issue; neither are Lisp's parentheses or Python's whitespace. These things cease to annoy once you spend some time with the language.
The reason there's a lot of bad Perl is the reason there's a lot of bad PHP: both languages enable beginning programmers to get things done.
I have great respect for Schneier as a computer security expert. Applied Cryptography was wonderful. But Schneier errs in thinking that physical security is the same thing as cyber security, and that his computer/crypto expertise somehow extends to the physical world.
A lot of geeks share Schneier's fallacy. And since geeks tend to be a lot smarter than the folks in charge of real-world security, the tendency to false superiority is magnified. But intelligence is not the whole story. There is also experience and instinct.
Some of the key differences:
If Schneier (or any computer geek) were in charge of airport security, I'm pretty sure we would have had another terrorist incident since 9/11.
In vi, the % key will bounce between braces. Emacs undoubtedly has an equivalent. What editor are you using?
I tried to set up an app on Google's AppEngine, and got an error saying that they're out of space. They'll email me when space is available.
That somewhat deflates the promise of great scalability, etc.
In my experience, SQLite is slower than MySQL, despite being in-process. SQLite is transactional, remember? And flat files will only support linear scan lookups, unless you implement your own indexing scheme. Which would make them "non-flat". Unless the table is very small, MySQL will be faster on SELECTs (by PK) than the flat file.