Global Nerdy

Click the comic to see it on its Flickr page.

[Found via Laughing Squid.]

The Return of Enumerating Enumerable

Back in January, I wrote that although the Ruby documentation site RubyDoc.org was useful, I found its writing unclear or confusing and some of its entries lacking in important information. In the “do it yourself and share it afterwards” spirit of open source, I started cataloguing the methods in Ruby’s workhorse module, Enumerable in a series of articles called Enumerating Enumerable. Enumerable is a pretty good place to start: its methods are often used and RubyDoc.org’s writeups of its methods are sparse (and in some cases, barely intelligible), especially when it comes to applying them to hashes.

In observance of another spirit of open source — that part that makes me sometimes yell “Free as in crap!” — I dropped the ball. There’s nothing like a little company turbulence and a sudden and very complete change in jobs to completely throw a wrench in a not-for-profit, self-driven, spare-time scratch-an-itch project like Enumerating Enumerable. Each time I started to write a new installment of Enumerating Enumerable, something would come up and I’d say “I’ll write it later.” As you know, later often turns into never.

I’ve been meaning to bring programming articles back to Global Nerdy for some time. In spite of the fact that my career track has been taking me away from day-to-day programming, I still plan to keep my skills sharp with writing development articles and working on hobby coding projects. With the RubyFringe conference coming up (I’m MCing the first evening’s commencement event) and my feeling a bit Ruby-rusty, I thought “What better time than now to reboot the Enumerating Enumerable series?”

So here begins version 2.0 of Enumerating Enumerable. I’ll be working my way through Enumerable‘s methods in alphabetical order, from Enumerable#all? to Enumerable#zip, each method covered for both arrays and hashes as well as special cases, supplemented with easy-to-grasp tables and graphics. I hope you find it useful!

Enumerable#all? Quick Summary

Enumerable#all? and Arrays

When used on an array and a block is provided, all? passes each item to the block. If the block never returns false or nil during this process, all? returns true; otherwise, it returns false.

# "feta" is the shortest-named cheese in this list
cheeses = ["feta", "cheddar", "stilton", "camembert", "mozzarella", "Fromage de Montagne de Savoie"]

cheeses.all? {|cheese| cheese.length >= 4}
=> true

cheeses.all? {|cheese| cheese.length >= 5}
=> false

When the block is omitted, all? uses this implied block: {|item| item}. Since everything in Ruby evaluates to true except for false and nil, using all? without a block is effectively a test to see if all the items in the collection evaluate to true (or conversely, if there are any false or nil values in the array).

cheeses.all?
=> true

cheeses << false
=> ["feta", "cheddar", "stilton", "camembert", "mozzarella", "Fromage de Montagne de Savoie", false]

cheeses.all?
=> false

Enumerable#all? and Hashes

When used on a hash and a block is provided, all? passes each key/value pair as a two-element array to the block, which you can “catch” as either:

1. A two-element array, with the key in element 0 and its corresponding value in element 1, or
2. Two separate items, the first being the key, the second being the corresponding value.

If the block never returns false or nil during this process, all? returns true; otherwise, it returns false.

# Here's a hash where for each key/value pair, the key is a programming language and
# the corresponding value is the year when that language was first released
# The keys range in value from "Javascript" to "Ruby", and the values range from
# 1987 to 1996
languages = {"Javascript" => 1996, "PHP" => 1994, "Perl" => 1987, "Python" => 1991, "Ruby" => 1993}

languages.all? {|language| language[0] >= "Delphi"}
=> true

languages.all? {|language, year_created| language >= "Delphi"}
=> true

languages.all? {|language| language[0] >= "Visual Basic"}
=> false

languages.all? {|language, year_created| language >= "Visual Basic"}
=> false

languages.all? {|language| language[0] >= "Delphi" and language[1] <= 2000}
=> true

languages.all? {|language, year_created| language >= "Delphi" and year_created <= 2000}
=> true

languages.all? {|language| language[0] >= "Delphi" and language[1] > 2000}
=> false

languages.all? {|language, year_created| language >= "Delphi" and year_created > 2000}
=> false

Using all? without a block on a hash is meaningless, as it will always return true. When the block is omitted, all? uses this implied block: {|item| item}. In the case of a hash, item will always be a two-element array, which means that it will never evaluate as false nor nil.

And yes, even this hash, when run through all?, will still return true:

{false => false, nil => nil}.all?
=> true

Special Case: Using Enumerable#all? on Empty Arrays and Hashes

When applied to an empty array or hash, with or without a block, all? always returns true. That’s because with an empty collection, there are no values to process and return a false value.

Let’s look at the case of empty arrays:

cheeses = []
=> []

cheeses.all? {|cheese| cheese.length >= 4}
=> true

cheeses.all?
=> true

# Let's try applying "all?" to a non-empty array
# using a block that ALWAYS returns false:
["Gruyere"].all? {|cheese| false}
=> false

# ...but watch what happens when we try the same thing
# with an EMPTY array!
[].all? {|cheese| false}
=> true

…now let’s look at the case of empty hashes:

languages = {}
=> {}

languages.all? {|language| language[0] >= "Delphi"}
=> true

languages.all? {|language, year_created| language >= "Delphi"}
=> true

languages.all?
=> true

# Let's try applying "all?" to a non-empty hash
# using a block that ALWAYS returns false:
{"Lisp" => 1959}.all? {|language| false}
=> false

# ...but watch what happens when we try the same thing
# with an EMPTY hash!
{}.all? {|language| false}
=> true

Here are my notes on the presentation Search Behaviour: A Tour of the Golden Triangle presented by Enquiro Research’s Gord Hotchkiss as part of the Search User Behaviour panel at Search Engine Strategies 2008 Toronto.

The Golden Triangle refers to that upper left-hand corner of a search engine results page where the reader’s eye spends most of its time. The phrase was coined by the search engine marketing firm Enquiro Research based on the results of their 2005 eye-tracking study, in which they tracked the eye movements of readers of Google results pages.

The Area of Greatest Promise

Why is the first listing seen so important? Because it’s in the Area of Greatest Promise. That’s the upper left-hand corner of the page. We found that the average time that users spend on a search results page is about 10 to 12 seconds. During the first 2 seconds of that time — or basically 20% of the time people spend on a search page — users’ eyes are mostly focused on the Area of Greatest Promise.

We ran a test: we took a Microsoft search results page and changed one thing: the sponsored link at the top of the page — in other words, an advertisement in the Area of Greatest Promise. In some cases we showed an ad that was highly relevant to the search, in others, we showed a non-relevant ad. We then asked our test subjects:

• if they would use the search engine for a similar query
• if they would use the search engine for other queries
• if they would recommend the search engine to a friend
• if they would make the search engine their preferred one

Here’s a photograph of a chart showing the results that shows test subjects who were shown relevant and non-relevant ads in the Area of Greatest Promise:

For every question, the test subjects who were shown relevant ads in the Area of Greatest Promise answered “yes”. The lesson is that the quality and relevance of that top ad in a search engine results page is critical.

Why do We Scan Search Results in Groups of 3 or 4?

When you look at the hot spots in our eye tracking “heat maps”, you’ll see that the first 3 or 4 items are scanned, and subsequent results are also scanned in groups of three or four. That’s because of the way our brains our wired. Human memory isn’t stored in a convenient clumps, but instead each memory is broken into fragments and stored in different parts of the brain, depending on the context. When we retrieve a memory, these fragments are reassembled on a “bench” which we call working memory or executive function. Channel capacity — that is, capacity of working memory — is limited to “seven, plus or minus two” items.

We see this all the time in purchasing behaviour. When you think of laptop for purchase, you typically consider 3 or 4 brands. We take shortcuts when thinking of something, cutting things down into graspable chunks. This approach is sometimes called satisficing. Search engines give us a playground to satisfice, and it all happens in the Golden Triangle.

Why is branding so important?

Although we want to narrow things down to as few selections as possible when making a purchase, we feel that a result set is more useful when there are alternatives presented. In an experiment where we presented test subjects looking for Brand A in search results pages with:

1. Brand A as both the top organic and sponsored result
2. Brand A as the top organic result, Brand B as the top sponsored result
3. Brand A as the top organic result, Brands A and B as the top sponsored results

…the test subjects recalled, purchased and clicked more when presented with more brands in the PPC area of the page.

Another strange thing we noticed while doing eye tracking on searches for laptops. We kept seeing “bounces”, where our test subjects’ eyes kept moving away from the Golden Triangle and over to the right sidebar of the search results page where the advertising was. This would happen about 2 or 3 seconds into their scanning the page. We found out that it was because Dell wasn’t a brand returned in the top set of our tests — they were looking for Dell in the sidebar.

This led us to do more research and we ended up finding that there is a 16% “lift” in brand association when your brand is in both the top organic and sponsored results.

How Rogers Missed the Boat on the iPhone Announcement

Rogers recently announced that they were going to the be exclusive iPhone carrier in Canada. We know there was a lot of interest in this development because Google queries in Canada for the search term “iPhone” tripled. If you looked at the Google search results page for “iPhone” on the day Rogers made the announcement, you’d have seen this:

Rogers is nowhere to be seen on the Google results page — not in the organic results, and not in the PPC results. But you know who bought an ad? BlackBerry. Rogers’ heads are up their asses.

“Canada is so far behind in search, it’s embarrassing.”