check out his concept here...
http://nrutledge.blogspot.com/p/ubuntu-laptop-concept.html
Interesting read, from both positive and negative viewpoints -
1. Use brainstorming to combine and extend ideas, not just to harvest ideas.
2. Don't bother if people live in fear.
3. Do individual brainstorming before and after group sessions.
4. Brainstorming sessions are worthless unless they are woven with other work practices.
5. Brainstorming requires skill and experience both to do and, especially, to facilitate.
6. A good brainstorming session is competitive—in the right way.
7. Use brainstorming sessions for more than just generating good ideas.
8. Follow the rules, or don't call it a brainstorm.
Read more here - http://www.businessweek.com/
"8. Follow the rules, or don't call it a brainstorm."
- Eight Tips for Better Brainstorming (view on Google Sidewiki)
A group of researchers from Northeastern and Harvard universities have gathered enough data from Twitter to give us all a snapshot of how U.S. residents feel throughout a typical day or week.
Not only did they analyze the sentiments we collectively expressed in 300 million tweets over three years against a scholarly word list, these researchers also mashed up that data with information from the U.S. Census Bureau, the Google Maps API and more. What they ended up with was a fascinating visualization showing the pulse of our nation, our very moods as they fluctuate over time.
The researchers have put this information into density-preserving cartograms, maps that take the volume of tweets into account when representing land area. In other words, in areas where there are more tweets, those spots on the map will appear larger than they do in real life.
Well, it might have been an everlasting discussion about which one of these to use, count(1) or count(*).
I guess, this article of Thomas Kyte already clarified the situation long long ago (well, for IT industry 2005 is long ago anyway, especially given the speed at which we are moving.)
Essentially, what askTom says that, count(*) is better than count(1) since count(1) translates to count(*) internally anyway. I wonder then, why would someone want to use count(1) anyway.
There is at least one more step involved in getting to the actual result. And there is another possible tweak, count(1) has to evaluate an expression as well, "count(1) where 1 is not null". Though its a tautology equivalent, it has to be evaluated nonetheless.
Further, there was some misconception about how the result is returned, whether its read from the data dictionary, this view or table or something like that. I dont think so. The result is calculated at the exact run time,when the query is run, and it actually goes ahead and counts the records in the table.
Should set the record straight...