SearchYC.com

A larger number of available testers means more fresh eyeballs, hence a better chance of repeat queries yielding accurate first-impression data.

Because of that, I think Google can encourage the behavior where people are sending links relevant to themselves up to the their front page in an honest way. If they click things up that have no relevance to themselves, they only screw up their own searches.

So if you have millions of people sending things relevant to themselves up the list, Google is basically gathering data about what the human 'gold standard' for a particular search query is (augmented by machine sorting first).

In information retrieval, one of the hard things is to know whether you've done a better job of returning search results or not, since a gold standard dataset is hard to come by and time consuming to produce.

Here, I think Google is simply using a mechanism where they're aligning people's self-interest to create accurate data they can use to compare their search algorithm tweaks.

Without Ruby on Rails there would have been no Groovy on Grails web application framework. But rubyist keep pushing limits, creating new kinds of database orm libraries like sequel and new web frameworks like sinatra.

Sinatra makes me write web applications that looks like haiku:

  require 'rubygems'
  require 'sinatra'

  get '/' do
     "This is a web application!"
  end

  dataset = DB[:managers].where(:salary =>   5000..10000).order(:name, :department)

  %h1 Markup
   %p
     .my_id Look ma, no end tags!

You are right in being suspect of speed issues. However, look at a common use of jQuery and compare it to straight JS.

$('a[href^="https"]').addClass('secureLink');

This one simple line selects all of the anchor tags on a page that are SSL links, then adds a custom css class to just those anchors. To write that in straight JS you would need roughly 7 lines, which includes an element match, looping through those, retrieving the href content of each one, doing a string match against the results, and adding a new attribute for the class.

At the end of it, the classic JS code isn't any more efficient and its a lot harder to write and read.

Additionally, since we've already selected the anchors with secure SSL links, we can do a lot more things with the jquery object without having to take the cost penalty of doing a new DOM lookup with getElementsByTagName and byId for subsequent operations. Lets chain some more operations:

$('a[href^="https"]').addClass('secureLink').appendTo( $('

MapReduce is used to implement massively parallel batch pipelines. RDBMS are used either for interactive OLTP systems or for data warehouses meant to support queries that may not be known upfront.

Google uses MapReduce in a way similar to traditional ETL pipelines, not for query processing. You could fill any relational data warehouse using MapReduce. So why does this debate refer to SQL at all?.

The answer is stream processing, that is querying, filtering, analysing data without ever storing it. It's about making decisions based on data as it flows through the system. It's not stored in any index, it's thrown away as soon as possible. Google doesn't do that as far as I know, at least not in it's search engine. Algorithmic trading applications do that. Processing sensor data could conceivably work that way as well.

You can cache static pages, but the constant activity of a social network makes that impossible if you're logged in.