Photo courtesy of "ejc".

A Little Bit About _why

If you were to walk up to someone and utter the seemingly meaningless phrase “Chunky bacon!” and get a smile rather than a look a bewilderment, you could probably mark that person down as a Ruby programmer. That strange two-word combination is seared in the minds of those who have read what is probably the most whimsical programming language book in existence, Why’s (Poignant) Guide to Ruby. The book is one of the strange and beautiful Ruby-related works created by the enigmatic programmer, musician, artist, comic illustrator and wag known only as why the lucky stiff, or _why for short.

_why’s contributions to the world of Ruby programming are many. In addition to the (Poignant) Guide, some of his goodies that I’ve made use of are:

• Camping, an incredibly tiny Ruby web application framework
• Hackety Hack, a “coder’s starter kit” for Ruby, meant to bring back the spirit of experimentation of those days when the BASIC programming language was built into every home computer
• Hpricot, a parser that’s great at scraping HTML and even parsing XML
• Redcloth, a library that implements the Textile markup language
• Shoes, a desktop UI toolkit
• Syck, a YAML library

_why made it a point to reveal as little about himself as possible, and most of us were happy to indulge him. Most people were happy to simply know and address him as “why”, and in the community, it was a point of etiquette to not try and dig too deeply.

_why Vanishes from the Net

Yesterday, _why’s presence vanished from the web. The places online where you could find him have been taken down. These included:

• His Twitter account
• His Github account
• His old blog at whytheluckystiff.net
• Hackety.org, his last active blog
• The (Poignant) Guide site
• The Shoes site
• The Try Ruby site

John Resig has written a lovely “eulogy” for _why, and while I think it’s premature to say that he’s gone forever, it’s still nice to see a nice tribute to him. My favourite part of the eulogy is where John likens _why’s works to a sand mandala:

Sand mandalas are incredibly intricate works of art that take many people many days to construct. They’re very expressive, but fragile, works of art.

After a mandala has been constructed – and displayed – it is ceremoniously deconstructed – which is meant "to symbolize the Buddhist doctrinal belief in the transitory nature of material life."

_why’s entire online presence and code was presented in the sand mandala that was ‘_why’. The person behind ‘_why’ simply decided to move on and close that portion of his life.

I hope that _why’s disappearance is a brief hiatus. The Ruby world – hey, the programming world, the art world, the music world too – just isn’t the same without him.

Finding _why’s Stuff

There’s only one problem with _why’s deletion of his online presence: a number of people have come to depend on his works, particularly his code. The (Poignant) Guide is downloadable from Scribd, and I figure that if it hasn’t happened already, someone will start a Github repository of his code. There’s also Facebook group called Missing why the lucky stiff — let’s hope it doesn’t get all maudlin and support-group-y.

Last but not least, there’s programmer Leah Culver, who commissioned a tattoo from _why:

In Closing

I’ll finish with my favourite tweet from _why, which I blogged about a year ago:

when you don’t create things, you become defined by your tastes rather than ability. your tastes only narrow & exclude people. so create.

This article also appears in Canadian Developer Connection.

The trouble with a lot of example code covering exceptions is that the examples are often cases in which you shouldn’t be using an exception in the first place. Consider the classic known as “Someone’s trying to divide by zero” – here’s the C# version:

// C#

try
{
    result = dividend / divisor;
}
catch (DivideByZeroException ex)
{
    Console.WriteLine("Idiot.");
}

and here’s the Ruby version:

// Ruby (works in IronRuby too!)

begin
    result = dividend / divisor
rescue ZeroDivisionError
    puts "Idiot."
end

// You have to hand it to Ruby for picking great keywords for
// exception handling. While C# borrowed Java's "try / catch / finally",
// Ruby went with the more macho "begin / rescue / ensure".
// As Yoda himself would say: "Do or do not. There is no try."

The better approach would be to do a little defensive programming and make sure that divisor is non-zero before performing the division operation. So why do tutorials on exception handling almost always bring out the “Someone’s trying to divide by zero” example?

There are two reasons:

• It’s simple. It’s only a handful of lines of code.
• It’s predictable. Set the value of divisor to zero and the exception gets thrown. Always.

The truly exceptional exceptions — I/O errors, timeouts and other things that cause exceptions are a little harder to set up and take more code to handle. Hence the divide-by-zero example; it illustrates try and catch (or rescue in a Ruby block) in a way even the newest newbie can understand.

The problem is that many tutorial authors don’t get any deeper than simply explaining the keywords with simple examples, leading people to misuse exceptions, either as a substitute for checking for preconditions or as an unstructured form of flow control in the style of the much-maligned goto (which in many cases is considered harmful).

Like goto, exceptions are unstructured jumps, which make your program’s flow more complex. Unlike goto, exceptions are computationally “expensive” because of all the extra work involved in setting up and backtracking program flow that comes with a thrown exception.

A good guideline to follow is that exceptions are for exceptional cases. Stuff that you can’t easily predict. You can tell if a division operation is going to result in an undefined result – just look at the divisor! Harder to predict are things like whether a server access will time out or if the hard drive will decide that the moment you’re reading a file is the best possible time to corrupt it. Those hard-to-foresee, believed-to-be-rare, exceptional cases are really what exceptions are meant to handle.

Think of exceptions is as being like the airbags in your car. The idea is that they’re a last resort; they’re no substitute for defensive driving. (Like airbags, they’re also expensive to reset.)

Lee Dumond goes into further detail on the topic of defensive programming as being like defensive driving in an article titled Defensive Programming, or Why Exception Handling Is Like Car Insurance. He cites the “Someone’s trying to divide by zero” example, provides a list of defensive programming strategies that you should consider before coding up that exception handler and talks about those exceptional cases when you will have to use an exception. Check it out!

O’Reilly’s conference on Open Source, OSCON, takes place this week in San Jose, California. One of the events taking place at OSCON is the Open Source Language Roundtable, the abstract for which appears below:

We all have our favorite languages in our tool-belt, but is there a ‘best’ overall language? If anyone can hash that out, it will be the members of this roundtable discussion, some of the stars of the open source language space. This wide-ranging session, hosted and moderated by the O’Reilly Media editorial staff, and broadcast live on the web, will try to identify the best and worst features of each language, and which are best for various types of application development.

The roundtable will me moderated by O’Reilly Media’s James Turner and will cover the following languages, listed below with the corresponding panelist:

• Java: Rod Johnson (SpringSource)
• Perl: Jim Brandt (Perl Foundation)
• PHP: Laura Thomason (Mozilla)
• Python: Alex Martelli (Google)
• Ruby: Brian Ford (Engine Yard)

You can catch this roundtable even if you’re not going to be at OSCON because O’Reilly is webcasting the event. It takes place this Wednesday, July 22nd at 10pm EDT (7 pm Pacific) and is expected to run 90 minutes. It costs nothing to catch the webcast and you’ll even be able to ask the panelists questions via chat, but you’ll need to register.

This article also appears in Canadian Developer Connection.

Introducing LearnHub

LearnHub’s home page.

If you’re a student applying to colleges and universities and are looking for help with the process, you should try LearnHub. Based in Toronto, LearnHub is a social learning network that helps students to prepare for standardized tests, assists with finding places to study abroad and provides career counseling. LearnHub’s site has hundreds of thousands of pages of free content, including the world’s largest bank of questions that appear in the GMAT and SAT standardized tests. The site has a large following among students worldwide, particularly in India, and has partnerships with 25 universities to recruit domestic and international students.

With those hundreds of thousands of pages, LearnHub needed to provide a way for students to find what they’re looking for. They provide a search function, and it’s powered by Bing.

The people at LearnHub are part of that sector of Toronto tech that’s into Ruby on Rails, open source and founding startups. Founders John Philip Green and Malgosia Green are a husband-and-wife team who are known for building web applications for education and have been active members of Toronto’s tightly-knit open source tech community since the earliest DemoCamps. John caught Rails fever after trying it out and decided to rewrite a major application using it. The core development team of Wesley Moxam, Carsten Nielsen and Libin Pan are fixtures of the local Toronto’s on Rails scene; a gathering of local Rubyists doesn’t feel complete without them.

So what are they doing, using Bing?

Site-Wide Search

The main room at LearnHub’s offices. Management are to the left, developers to the right.

In the beginning, they went with their first instinct, which was to use Google. “We launched in March 2008,” said co-founder John Philip Green, “and we needed to provide site-wide search, so we went with Google. We signed up, and for a few hundred bucks a year, we got a search function that covered about 5,000 pages. It seemed like a pretty big number, and we thought that would be more than enough to cover our site.”

They soon found that the results weren’t what they expected. “We weren’t getting good results. We’d use our site-wide search to search for something that we knew was in our site, and it wouldn’t show up in the results.” The same search would work just fine if you did it from Google.com, but not from their Google-powered search function. “The results just weren’t relevant, and we also had a limited number of queries,” John said.

The main room at LearnHub’s offices. That’s management in the foreground, developers in the back.

LearnHub’s page count grew quickly and beyond the 5,000 pages covered by their arrangement with Google. “Going up to a bigger package was expensive;” John said, “it would have cost a couple thousand for 50,000 pages, and we were already at hundreds of thousands.”

“We could’ve gotten the functionality for free, but that’s only an option when you show ads in the search results, and the ads that showed up were for our competitors.”

LearnHub’s sales team.

There was another problem: Google’s site search returned its results as a web page. In order to make LearnHub’s site-wide search’s results page have the same look and feel as the rest of the site, they had to stick the Google results in an iframe. “And even then, what was inside the iframe didn’t match the rest of the page,” added John.

They started looking at other options for implementing LearnHub’s site-wide search, including running their own spider. “We really didn’t want to do that,” said programmer Wesley Moxam.

Enter Bing

LearnHub developer Wesley Moxam.

While looking around at search options, Wesley found the Live Search API, which is now known as the Bing API. “It was free, well-designed and spits out JSON,” he said. “Google requires a JavaScript interface or SOAP, and SOAP libraries in Ruby are painful.”

“It took a day to implement and get it up and running,” said Wesley, “The entire switch-over project happened over three days, with us working on it on and off, while we were doing other tasks. Best of all, we get consistent results – the results from the API are the same results you’d get if you just used the Bing site.”

“Bing’s API is simple and straightforward. You call it, you get the results, you take those results and use them how you like,” he continued. “It’s good. It’s hard to explain good software; good software is inherently simple.”

Here’s a screenshot of a LearnHub search results page for the search term “accordion” – and yes, the word appears on a handful of Learnhub pages!

LearnHub’s search results page for the term “accordion”.

LearnHub have benefited from using Bing to power their site-wide search, and they’ve decided to share the wealth. Wesley’s working on refactoring the Ruby library he wrote to act as a wrapper for the Bing API and open source it for anyone to use. It should be available later this summer. He’ll announce it when it’s released, and I’ll announce it here.

The Bing API

It’s easy to harness the power of Bing in your applications, whether for desktop, web or mobile.

The first step is to get an AppID, which is a string that uniquely identifies you as a registered Bing application developer. Go to the Bing Developer Center, sign in with your Windows Live ID (which you can get for free) and follow the link to created a new AppID. You’ll be asked to supply some very basic information about your application and to review the Bing API’s Terms of Use. If you provide the information and agree to the Terms of Use (which I summarize in plain English below), you’ll get an AppID.

Once you have an AppID, you can start experimenting right away with the Bing API. All you need to do is start typing URLs with the format below into your browser’s address bar:

http://api.search.live.net/xml.aspx?AppID=<AppID>&query=<SearchTerms>&sources=<SourceTypes>

where:

• <AppID> is the AppID assigned to you
• <SearchTerms> are your urlencoded search terms
• <SourceTypes> specifies the type(s) of search results you want. The different sourcetypes are explained in the table below:

The default format for results is XML, and that’s the format you get when typing in API calls in your browser. You can also have the results returned as JSON or SOAP if you prefer.

You can find out more about the Bing API in the Bing API section of MSDN.

Bing’s Terms of Use, Explained as Simply as Possible

Here’s a quick explanation of Bing’s Terms of Use for those of us without a law degree. It’s adapted from the Bing documentation and provides a quick summary of what application developers using the Bing API must do and cannot do (besides the obvious "I promise not to use the API to plan a terrorist attack, run a drug smuggling ring or help the band Nickelback take forceful despotic rule of planet Earth").

What you must do:

• You must display all the results you request. No filtering!
• You must display your results in the context of a user-facing application or website.
• You must display attribution to Bing in a manner compliant with our branding rules. Currently, you may determine the specific manner in which you display attribution. A link to http://www.live.com with the query echo is a suggested example.
• You must restrict your usage to less than 7 queries per second per IP address. You may be permitted to exceed this limit under some conditions, but this must be approved through discussion with the folks at api_tou@microsoft.com.
• If you interleave data from any source other than the API with data from the API, you must clearly
  
  differentiate the respective sources. (Yes, you can interleave Bing results with other data!)

What you cannot do:

• You cannot use API results for search engine optimization (SEO). In particular, using the API for rank checks is explicitly prohibited.
• You cannot display advertisements in positions other than the mainline and sidebar.
• You cannot change the order of the results the API returns from a SourceType other than Web. (In other words, you can re-order results from standard searches for web pages!)

Bing Your Apps!

From there, the sky’s the limit. The Bing API is very straightforward and easy to use, it costs nothing to use it, and as someone who’s been using Bing as his default search engine since its beta period, the results it provides are great. Go forth and Bing your apps!

One of the pillars of the Toronto developer scene is the Ruby/Rails community. They’re an active, engaged, hard-working bunch who work without the direct benefit of a large organization like The Empire or its resources (they do, through people like Yours Truly and Nik Garkusha, Microsoft Canada’s open source go-to guy, get some indirect support). They – through the efforts of people like Pete Forde and the Ruby local heroes at Unspace – know how to maximize grassroots organization and harness them into industry-leading events like last year’s RubyFringe and the upcoming FutureRuby conference.

It should therefore not be a surprise that when Pete and company got the idea to help out their fellow Ruby developers during the econopocalypse with a job fair – employment.nil? — they’d take the standard techie job fair formula, turn it upside down and make it their very own. They chose the Gladstone Hotel in Toronto’s hip West Queen West neighbourhood, which is better known as a venue for karaoke, rock bands and burlesque (in fact, I’ve performed in all three kinds of shows there) than for computer and IT-related employment fairs.

This was not your typical job fair. It didn’t have any of the fancy display stands that you normally see on the exhibition floor at tech conferences. Instead, both job-seekers and small companies were told to build poster board displays, a la high school science fairs.

Another rule: no computers allowed! Even iPhone apps were considered “cheating”. The closest you were allowed to get was using whiteboards or pen and paper for “live coding”. This wasn’t about staring at computer screens, but people talking to other people – people who were passionate about the Ruby programming language and its associated frameworks, libraries and communities.

An excerpt from the sign-up page for employment.nil?:

Let’s face it: it’s better to be a Ruby developer than a car manufacturer in 2009, but things have definitely slowed down — for everyone. And yet, there are solid reasons why this is an excellent time to start new projects, launch companies, and create new markets. By definition, Ruby has been adopted by creative individuals that grew frustrated with risk averse bureaucracies.

We believe that there are huge number of opportunities to be found during this economic downturn, both for freelance developers and aspiring entrepreneurs alike. As with most tragic historical near-misses, there are just a huge number of connections that aren’t made even in our own collective back yard.

More from the job fair’s site:

That said, we also believe that Ruby people are determined self-starters that aren’t afraid to self-promote. Anything worth doing in life requires hard work and sacrifice. Sadly, while many developers are patient and willing to think orthogonally, we rarely get an opportunity to practice the other more social skills which make us desirable as team members, project managers, and co-founders. Unless we overcome our shyness and learn to speak eloquently about our experience and skill sets, we have nobody to blame for our work prospects but ourselves.

Our solution is to gather students, developers, development companies, and of course project leaders and company founders for a good old-fashioned career fair.

As you can see from the photos, there were different kinds of booths set up. There were those for companies looking to hire some Ruby developers…

and those deidicated to showcasing some interesting application of Ruby, such as lojacking iPhones:

…or HacklabTO’s own Jed Smith showing how we harness Ruby to drive our laser (yes, we’ve got a laser etcher/cutter!):

And some booths were set up by Ruby programmers showcasing their own work and who were looking for a job:

The event wasn’t just noticed by the Ruby community, who filled the room throughout the 11 a.m. to 6 p.m. course of the event. Late in the afternoon, Ontario’s Minister of Small Business and Consumer Services, Harinder S. Takhar, paid a visit to the job fair.

Pete, ever the gracious event curator, took Mr. Takhar to several booths, introducing him to their owners, who were only too happy to show the Minister their Ruby-related work. Here’s Andrew Burke of Shindig, showing him the projects he’s taking on in his independent software consultancy:

Here’s Kieran Huggins showing Mr. Takhar his work in MyTTC.ca:

I’m sure that grassroots high-tech events with a strong “indie” aesthetic are outside the Minister’s everyday experience, but he seemed pretty impressed with the event: a dedicated group of nerds building software and careers using only laptops, stuff you can download for free and their brain cells.

Here’s Pete explaining the local Ruby developer scene and the concept of open source software to Mr. Takhar:

And here’s Mr. Takhar presenting Pete with an award of recognition for Unspace for putting the event together. At that point, I broke out the accordion and played For He’s a Jolly Good Fellow, partly for the Minister for showing up on a Saturday afternoon, but partly for Pete for putting the event together.

Here’s a close-up of the award:

It reads:

Award of Recognition

On behalf of the Government of Ontario,
I am delight to extend my congratulations on the
Employment.nil?
First Toronto Ruby Job Fair

Unspace Interactive Inc.

Our government recognizes the importance of new and creative opportunities for
business. Building a business requires vision and dedication. I applaud your work and
success in web consulting through your team of industry-leading developers and
designers under one roof.

Please accept my best wishes for continued success.

Harinder S. Takhar
Minister of Small Business and Consumer Services
June 06, 2009

Congratulations to Pete, Meghann Millard, all the folks from Unspace and the Toronto Ruby community on a job well done!

The Photo Gallery

I took a lot of photos at employment.nil? and shared them in a Flickr photoset, which you can also view in the slideshow below:

Created with Admarket’s flickrSLiDR.

In case you’re:

• a programmer who works with the Ruby programming language
• looking for work
• available to get down to Toronto’s “West Queen West” neighbourhood soon

you might want to do what I’m doing in a couple of minutes (as of this writing): heading down to the Gladstone Hotel (1214 Queen Street West, at Dufferin) to get a look at employment.nil, which bills itself as “the first Toronto Ruby job fair”.

Organized by the fine folks at Unspace, who are also organizing the upcoming FutureRuby conference and FailCamp (where I’ll be the MC), employment.nil isn’t your typical computer programmer job fair. No computers are allowed! They’re going to be strict about it – even the use of iPhone applications is verboten. Bring printouts of your resume and some scratch paper to do “live coding”. I’m going to bring my mini-whiteboard and dry-erase markers.

See you there!

If programming in Ruby is your thing and you’re looking for work or workers, you should mark Saturday, June 6th on your calendar. That’s when employment.nil, Toronto’s first Ruby job fair, takes place at the Gladstone Hotel.

Organized by Pete Forde and the folks at Unspace – the local Ruby heroes behind things like the FutureRuby conference – employment.nil is an old-school job fair for Ruby programmers. In fact, it’s so old-school that no computers of any kind are allowed. If you’re looking for work, bring printouts of your code and be ready to write out ideas with pen and paper. If you’re looking for people to work for you, you can set up a booth, grade school science fair-style.

Want to find out more? Check out the employment.nil article in Rethink, Unspace’s blog.

In an earlier article, Default and Named Parameters in C# 4.0 / Sith Lord in Training, I wrote about how C# 4.0 – that’s the version coming out with the next release of Visual Studio, known as Visual Studio 2010 – is going to provide support for named parameters.

In that article, I also incorrectly stated that Ruby supported named parameters. Luckily, Jörg W Mittag spotted my mistake an corrected me in a comment. I’ve since corrected the article and thought I’d show you how I got it wrong in the first place.

Ruby and My Named Parameter Goof

I had a vague recollection of Ruby accepting named parameters. I figured I’d be empirical and fired up irb – the Ruby REPL shell – and put together a quick little method to see if the recollection was correct:

# Ruby 1.8.6
def test_named_params(first, second)
    puts "#{first}\n#{second}"
end

Once put together, I made some test calls to the method:

# irb session (Ruby 1.8.6)
irb(main):> test_named_params("alpha", "beta")
alpha
beta

=> nil

irb(main):> test_named_params(first = "alpha", second = "beta")
alpha
beta

=> nil

Seeing that the interpreter didn’t choke on that named parameter call, I thought to myself “Vague recollection confirmed, Ruby supports named parameters!” and wrote the blog article.

Had my brain actually been firing on all cylinders, I would’ve given the method a proper test by providing the named parameters out of the order in which they appear in the method signature. Here’s what I would’ve seen:

# irb session (Ruby 1.8.6)
irb(main):> test_named_params(second = "alpha", first = "beta")
alpha
beta


=> nil

Uh-oh. If named parameters worked, the first output line would be “beta” and the second would be “alpha”. Clearly something’s wrong with my recollection.

Let’s try some non-existent named parameters – say, ones involving current entertainemtn news headlines — just to see what happens:

# irb session (Ruby 1.8.6)
irb(main):> test_named_params(lindsay_lohan_dui = "alpha",
jim_cramer_smackdown = "beta")


alpha

beta

=> nil

Even with nonsensical named parameters, the method is still accepting the values in order. Why is that?

Just about everything in Ruby has a return value (which can be anything, including nil). You can see for yourself in irb – here’s a quick do-nothing method definition:

irb(main)> def doNothing
irb(main)> end
=> nil

As you can see. defining a method returns a value of nil.

As Jorg pointed out, Ruby assignment statements return a value: the value used in the assigment. Once again, for proof, I’ll use an example from an irb session. In the example below, assigning the string "alpha" to the variable first also returns the string "alpha":

# irb session (Ruby 1.8.6)
irb(main):> first = "alpha"=> "alpha"

In the call to test_named_params, the Ruby interpreter was interpreting my “named parameters” as assignment statements. first = "alpha" evaluates to plain old "alpha", but so does second = "alpha" (and for that matter, so does lindsay_lohan_dui = "alpha"). Each assignment statement in my parameter list was evaluated, and then those values were passed to method in positional order.

Python Supports Named Parameters

After getting the comment from Jorg and correcting my article, I wondered why I thought Ruby supported named parameters. Then it hit me – it’s Python.

So I fired up the Python REPL and put together this quick little method:

# Python 3.0
def test_named_params(first, second):
    print("%s\n%s" % (first, second))

And this time, I decided to be a little more thorough in my testing:

# Python 3.0 REPL
>>> test_named_params("alpha", "beta")
alpha
beta

>>> test_named_params(first = "alpha", second = "beta")
alpha
beta

>>> test_named_params(second = "alpha", first = "beta")
beta
alpha

And some additional searching on the web confirmed that yes, Python method calling does in fact support named parameters.

So in conclusion, when it comes to named parameters, it’s Python si, Ruby no…and C# pronto.

Last year, the folks at Unspace held a fantastic Ruby conference called RubyFringe. They took the standard conference format, threw out the stuff they didn’t like, amplified the stuff they loved and kept the attendance down to around Dunbar’s number. The end result: quite possibly the best geek conference I’ve ever attended (a lot of the other attendees would concur). I wrote quite extensively about RubyFringe in this entry, and here are my notes from the conference:

• Day 1 Notes, Part 1
• Day 1 Notes, Part 2
• Day 2 Notes, Part 1
• Day 2 Notes, Part 2
• Day 2 Notes, Part 3

This year, they’re holding a slightly different conference called FutureRuby. They’ve described it as bill it as “an opportunity to prepare for the future by learning from the mistakes of the past”, and promise us that it won’t just be RubyFringe warmed over – we shouldn’t expect to find the same things in the same places! Here’s what the FutureRuby site says:

We are the artists, philosophers, and troublemakers. We realize that the fringe of today is
the mainstream of tomorrow. We grease the engines of progress, even when we’re working outside of the machine.

FutureRuby isn’t a Ruby conference, but a conference for Rubyists. This is a call to order – a congress of the curious characters that drew us to this community in the first place. We have a singular opportunity to express a long-term vision, a future where Ruby drives creativity and prosperity without being dampened by partisan politics.

FutureRuby runs from Friday, July 10th at 5:00 p.m. and officially end on Sunday, July 12th at around 11:55 p.m.. FutureRuby will also be paired with FailCampTO, which will take place on Thursday, July 9th (I’ll be MCing this event, and I’ll talk more about it in another post).

The early bird tickets for FutureRuby, which sell for CAD$700, are already gone. The regular rate tickets, which sell for CAD$800, are still available, but probably not for long. If you want to attend FutureRuby, I strongly recommend that you go to the FutureRuby registration page and sign up right now.

First Came RubyFringe

I can’t talk about FutureRuby without first talking about RubyFringe.

Last July, the fine folks at Toronto’s Little Coding Shop That Could – Unspace – created one of the best and most memorable conferences I’ve ever attended: RubyFringe. RubyFringe made its mark by taking the standard geek conference formula and turning it on its head. Among the things that distinguished it were:

• RubyFringe was intentionally a small conference, with its attendance capped at 150 attendees.
• No sponsors!
• It had a single conference track, and all presentations took place in the same room.
• The presentations were vetted carefully by people who really, really, really loved the Ruby programming language. This meant that we got interesting speakers and no vendor pitches. We felt Damien Katz’ pain when he talked about his situation prior to creating CouchDB, grooved as Nick Sieger talked about the parallels between jazz and programming, and stayed glued to our seats as Giles Bowkett gave us his rousing call to action in his 400-slide extravaganza, even though he’d gone well beyond his allotted time and was cutting into lunch (it was that good).
• They didn’t allow questions at the end of the presentations. In organizer Pete Forde’s words: “Our experience has been that questions are hard to hear, generally of poor quality, often just statements, and almost always an exercise in demonstrating how brilliant the questioner is while dominating the attention of the whole room.”
• There was a “companion track” for attendees’ non-geeky significant others, where they were taken on a tour of the city while their partners were at the conference.
• They served some of the best food I’ve ever had at a developer conference. The lunches were at the Downtown Metropolitan Hotel, and the big dinner at the Drake Hotel was beyond anything I’ve ever had at a developer conference.
• The conference also included parties at some of the best spots in the city, some of which you wouldn’t find on vanilla tourist guides. Better yet, those parties were open bar!
• Not only was there an opening party at a brewery, complete with stand-up comic, rock band and DJ, but there was a great closing party on Unspace’s roof.
• The organizers paid attention to little details that set the conference apart, from giving everyone transit passes to heralding speakers as they walked on stage with the song of the choice to the giant polaroid montage featuring every attendee.

The organizers’ decisions in crafting RubyFringe made it a high-quality, memorable and inspiring experience, and its carefully limited scale gave it a sense of community that I could almost describe as familial.

Many people who went declared it the best conference they’d ever attended, and many who passed up the opportunity kicked themselves for missing it. Those pale next to the highest praise for the conference: the fact that after attending RubyFringe, a half-dozen handful of attendees were so inspired that they quit their day jobs to strike out on their own doing Ruby development.

Now Comes FutureRuby

With RubyFringe’s resounding success, it was only natural that people would ask if Unspace would be doing it again next year. They gave it some serious thought – the last thing that they wanted to create was a weak sequel. They didn’t want to simply rehash RubyFringe, but reinvent it, just as they had reinvented the developer conference with RubyFringe.

So they reinvented RubyFringe as FutureRuby.

FutureRuby will take place from July 9th through 12th, and will build on what RubyFringe accomplished. The organizers bill it as “an opportunity to prepare for the future by learning from the mistakes of the past”, and promise us that it won’t just be RubyFringe warmed over – we shouldn’t expect to find the same things in the same places!

What else will it have?

• Parties and nightly entertainment, three nights in a row
• FAILCamp (which I co-hosted last year, and which I am invited to host again) is back with a vengeance, and an adorable sailor suit
• “More better than” swag that you’ll be proud to wear in public
• The return of the companion track for partners and secret lovers during the conference
• An amazing two nights of lunches and dinners that you’ll photograph and tweet about
• Loving attention to all of the details, like excellent wifi, transit passes, and no paid presentations

All the details are in this post at Unspace’s blog, Rethink. You can bet that I’ll be at FutureRuby.

The Merb/Rails rivalry could’ve gone as depicted on the cover of the science fiction “classic” shown below…

(I think Merb would be the Human Bat and Rails would be the Robot Gangster.)

…but instead, the two projects have merged! The result will be the upcoming Rails 3.

The merger is commemorated on a “plaque” page on the Rails site titled The Day Merb Joined Rails, which I’ve excerpted below:

Merb was started two years ago by Ezra Zygmuntowicz as a tiny framework to serve ERb templates from Mongrel. This quickly grew into much more and carved out a niche as an alternative Rails stack. Merbists focused on among other things a small speedy core, being ORM/JavaScript agnostic, and having a rigorous API for extensions.

Along with the expansion in ambition came the fact that Merb and Rails started sharing more and more of the same ideas and even implementation. This lead to a fair amount of unnecessary duplication on both sides of the fence and lead to some paradox of choice. When do I choose one over the other and when?

Rails 3

On December 23rd, we decided to end the duplication and the paradox of choice. That was the day we declared our intentions of bringing the best ideas of Merb into Rails 3. That was the day we announced our commitment to work together.

It’s nice to see this sort of thing happening. It’s more common to see projects forking over the tiniest disagreements, a la “The People’s Front of Judea” in Monty Python’s Life of Brian:

It’s a win for both projects, as well as the users. Rails gets some much-needed optimization, the ability to shed excess weight for speed, framework agnosticism and an API that won’t break with upgrades, and Merb gets a much bigger development community and mindshare momentum that Rails enjoys. Better still, the merger now has both teams’ big brains working on the same project, and isn’t that what the spirit of the DRY principle is all about?

Congratulations to both the Merb and Rails teams! And hey, congrats to all you Ruby/Rails/Merb developers out there too! 2009 just got a little more interesting for all of us.

Links

• The Rails/Merb Commemorative Merger Page
• The Rails Blog: Merb Gets Merged into Rails 3!
• Yehuda Katz’ blog, Katz Got Tour Tongue?: Rails and Merb Merge
• The Merbist: Rails and Merb Core Team Working Together on Their Next Release
• Brainspl.at: Merb *is* Rails
• Lori Holden’s blog: Merb is Rails 3.0
• Tom Mornini’s blog: Rails 2.x + Merb 1.x = Rails 3.0!
• Splendificent: The Merb/Rails Merger Announcement, an Inside Opinion

A number of people have asked me how many sessions I attended at last week’s Microsoft Professional Developers Conference; my answer was “I only attended the keynotes”. Since every session was recorded on video (with a split screen showing both presenter and presentation) and made available online, I decided to focus on what you can’t replicate outside the conference: getting to know people in the Windows developer community.

It’s standard procedure at Microsoft to assign “buddies” to new hires to help them get acclimated. I have the very good fortune of having John Bristowe as one of my buddies; not only is he a warm and friendly guy, but I also already know him (his sister Ashley and I went to Crazy Go Nuts University together). John’s big on podcasting and was very generous in sharing the interviewer’s chair; he let me do a lot of interviews as a way to both get podcasting practice and introduce myself to people in the Windows world. Thanks, John!

You’re going to need Silverlight to view these videos. If you’re rolling your eyes at the prospect of having to download yet another plugin, keep in mind that Silverlight is a pretty cool tool for writing rich internet apps, I’ll be covering it rather extensively soon, and it’s catching on. Besides, you can’t see the videos without it!

Don Box on My Joining the Dark Side, Demos, Oslo and M, Zombies and How to Pronounce “Azure”

Click the picture to see the video of the interview.

After introducing myself to Distinguished Engineer (yup, that’s really his title) Don Box as “Microsoft’s Newest Employee”, I told him about my coming to Microsoft from the F/OSS world and asked him to please tell me that I hadn’t made a tragic mistake and ruined my life by coming over to the Dark Side. We also talked about his preparation process for his keynote demo, the Oslo platform and the M programming platform, the proper way to pronounce “Azure” and whether or not Microsoft is ready for the zombie apocalypse.

Useful Don Box/Oslo Links

• Video of my interview with Don Box.
• Video of Don Box’s and David Langworthy’s PDC 2008 presentation, Oslo: The Language, which introduces the M programming language.
• Video of Don Box’s and Florian Voss’ PDC 2008 presentation, “Oslo”: Customizing and Extending the Visual Design Experience.
• The Oslo site.
• If you’d like to read more about Oslo in Don’s own words, a good place to start is this entry in his blog.
• Don’s blog, Don Box’s Spoutlet.

Miguel de Icaza on Mono

Click the picture to see the video of the interview.

I had a great chat with Mono Project lead Miguel de Icaza about Mono, their answer to Silverlight, the number of people in the Mono Project and how you, as a Windows developer, can take Mono out for a spin. We also talked about how to pronounce “Azure”, and Miguel speculated that the name was a clever choice because the disagreement over its pronunciation is a great way to get people talking about it.

Useful Miguel de Icaza/Mono Links

• Video of my interview with Miguel de Icaza.
• Video of Miguel de Icaza’s PDC 2008 presentation, Mono and .NET.
• The Mono Project’s site.
• Miguel de Icaza’s blog.

John Lam on IronRuby

Click the picture to see the video of the interview.

It’s always good to catch up with Toronto-area guy turned Redmond guy and IronRuby creator John Lam. We had a quick chat about IronRuby and the current state of the project. In the interview, he reminds us that IronRuby is an open source project, talks about the Ruby standard implementation tests it’s currently passing and what to expect from IronRuby in the near future.

Useful John Lam/IronRuby Links

• Video of my interview with John Lam.
• Video of John Lam’s PDC 2008 presentation, IronRuby: The Right Language for the Right Job.
• The IronRuby site.
• Why’s (Poignant) Guide to Ruby — the most whimsical introduction to a programming language, ever!
• John Lam’s blog, John Lam on Software.

Phil Haack on ASP.NET MVC

Click the picture to see the video of the interview.

Phil Haack not only has the coolest surname for a techie, he’s also got an MVC framework for ASP.NET, just like the ones the Rails, Django and Cake people get to play with. In this interview, we talk about MVC web frameworks for the uninitiated, as well as get his take on how to pronounce “Azure”.

Useful Phil Haack/ASP.NET MVC Links

• Video of my interview with Phil Haack.
• Video of Phil Haack’s PDC 2008 presentation, ASP.NET MVC: A New Framework for Building Web Applications.
• The official ASP.NET MVC site.
• Phil Haack’s blog, You’ve Been HAACKED.

.NET Micro Framework

Click the picture to see the video of the interview.

Believe it or not, there’s a .NET framework for embedded devices, the .NET Micro Framework. In this interview, I learn about .NET programming for small devices, the “Dare to Dream Different” contest (where you can win great prizes for coming up with new applications for the .NET Micro Framework) and about what donuts have to do with microcontrollers. Mmm…donuts!

Useful .NET Micro Framework Links

• Video of my .NET Micro Framework interview.
• The “Dare to Dream Different” contest site.
• The .NET Micro Framework site.

It’s Back!

Last Friday marked the return of Ruby on Rails Project Night, a Toronto-based event where developers who worked on Ruby and Rails projects could do in-depth presentations on their current projects or ideas. It was on hiatus for the past couple of months (you can see this entry for the definition of “on hiatus”), but thanks to the efforts of Corina Newby, who helped put together the event at its old venue, it’s back, and judging from the attendance, it was missed. Thanks, Corina, for all your work!

James Robertson

The first speaker was also the special guest (and the reason the event was held on a Friday, as opposed to the typical Monday or Tuesday): James Robertson, whom you may know from his blog Smalltalk Tidbits, Industry Rants. He was on a “Canadian tour”, during which he was talking about the Smalltalk-based web app framework Seaside as well as Webvelocity, which puts the Smalltalk development experience within the browser.

Here’s the abstract for his presentation (from this entry from Corina’s blog):

WebVelocity is a new Smalltalk Development Environment that is oriented around Seaside for Web Development and Glorp for Object/Relatonal Mapping. Come and see how WebVelocity re-targets the Smalltalk development experience into the Web Browser and simplifies the challenge of learning a new environment for newcomers. We’ll even build an entire application using Active Record and Scaffolding during the presentation, with minimal programming. If you’re a fan of Ruby on Rails, you need to come out and see this presentation!

Here are my notes from his presentation:

- Seaside is open source, but Smalltalk ain't
- Seaside is maintained in Squeak, which you could call "the open source Smalltalk"

- Ruby on Rails is opinionated
- "Seaside is also opinated; it just has different opinions"
- When building Seaside, Avi Bryant asked "What if I took all the assumptions about web apps...
  and ignored them?"
- Some of what I show you is what happens when you blow those assumptions

- The canonical Seaside example -- the number increment/decrement button
  (now we know where that disastrous DemoCamp Seaside presentation came from!)
- Seaside uses continuations to remember state
- They enable "proper" support for the backbutton
- Session state info is keyed via a cryptographically secure key in the URL

- With Rails, you're dealing with two different worlds: templates and code
- Seaside is just one world: You don't write any HTML at all, you write all Smalltalk
- It's all in one place
- Support for debugger -- you can debug web apps as if they were desktop apps, with breakpoints and resumes
- In Seaside, the "html" argument is a "brush" that knows how to "paint" HTML
- You can debug in the middle of a page hit

- In beta: Seaside totally within the browser
- Editing code within a webpage, including tooltips and color hinting
- Every time a method is entered and it is syntactically correct, it is auto-saved -- no need to manual save!
- [Shows a Smalltalk debugger with an Ajax front end]
- "In some ways, it's even more productive than the real Smalltalk environment is"
- [Smalltalk console within the browser]
- [Auto-indenting within the browser]
- [Auto-generates a scaffolding-like page]
- The "call" method lets you write web app code very much like writing GUI stuff

Paul Doerwald

The second speaker was Paul Doerwald, who changed his topic from the more Ruby/Rails-specific “insights gained from working with ActiveRecord validation” to a more general (but still interesting) topic: Agile Documentation. He figured that it might be a better fit with James’ presentation, and it was — it was also quite interesting.

Here’s the abstract for his presentation:

“Programmers generally hate writing documentation. That’s because most documentation is kept separate from the code and becomes hard to keep up-to-date. Besides violating the DRY principle… it can lead to misleading documentation, which is generally worse than none at all.” [Subramaniam/Hunt '06]. Why do developers hate writing documentation, and why do stakeholders and managers keep requiring it? Is there agile documentation beyond inline API documentation (JavaDoc, RDoc, etc.) and comments in the code? What parts of a project deserve separate-from-code documentation? How do we identify them, capture them, and keep them relevant?

Tonight’s Toronto Ruby on Rails Project Night presentation discusses the problem of documentation, explores some key aspects to consider when writing effective documentation, and dreams of a future of testable, executable documentation, where non-code knowledge could be integrated into your code.“

And here are my notes from his talk:

- My original presentation was going to be about insights gained from ActiveRecord validation
- But I've decided to change it -- it's now on Agile Documentation
- It's my M.Sc. Thesis!
- "You'll find this talk a bit heavy on problem and not so heavy on solution"
- Think of this as an introduction -- I want to frame things and ask:
  what is Agile Documentation?

- By "documentation", I mean by the kind that's by programmers for programmers

- It's not a particularly sexy area
- Frameworks are sexy:
    - Rails is sexy
    - Django is sexy
    - CakePHP is sexy...(for PHP)
- Languages are sexy
    - Ruby is sexy
    - Objective-C is..."strangely alluring"
- Even databases are sexy! Consider CouchDB and AWS
- What's not sexy?
    - Documentation
    - Backup -- at least not until Apple's Time Machine
    - Both are viewed as a waste of time

- We're developers. We may grudgingly accept the presence of non-developer things,
  but we don't want to do them
- Documentation is hard to write
- It seems so much easier to program rather than write
- Writing -- the non code-type -- is not our core competency
- We say "Our code is the authoritative documentation!"
- Consider what DHH said in a "Signal vs. Noise" blog entry in February 2006
    - When asked "How do you document your projects?", he replied "We don't."
    - He also said:
        - "Never worked consistently or successfully"
        - "Not necessary for our work"
        - "Most Rails developers can walk in and find out"
        - "We use Ruby"
        - "Method docs only for non-obvious behaviour"
        - "Docs mean BDUF"
        - "Appropriate only for onerous enviroments with complex policies"
        - "Focus on code quality instead"

- Like backups, docs are important
- We're not the only people who'll be working on a project, especially if it's a success
- We don't want to feel like we're wasting time when we're working
- Running a documentation tool and taking its output and pasting it into a Word doc is not DRY
- Why are we writing highly-coupled docs?

- Is there such a thing as agile documentation? I'm going to say yes
- Look at the Agile Manifesto
    - "We value working software over comprehensive documentation"
    - But it doesn't say that comprehensive documentation isn't valued!

- What's the state of the Art
    - For API Documentation, it's JavaDoc
    - In Rails, the outer classes are well documented, but not the inner ones
    - The JDK is extremely well-documented
    - You could say that RSpec is a form of agile documentation
    - It's a stretch, but Domain-Specific Languages could also be agile documentation
    - After all these, I can only think of process
    - When do we do docs? At the beginning of the process? At the end?

- What could agile documentation look like? What does it feel like?
- I borrowed principle from Alastair Cockburn's "Agile Software Development:
  The Cooperative Game, 2nd ed."
- The goals set out in the book:
    - Finish the game (i.e. finish development and launch the product)
    - Set up the game for the next team
    - Think of pool: maybe you take the hard shot first to set yourself up later for the easy shot
    - Coburn calls this "residue": the stuff that one team leaves behind for the next team
    - Residue includes:
        - Code
        - Process in place
        - Documentation

- I would argue that DHH/37signals has an oral form of documentation
- It works if the company doesn't grow too quickly
- What are we really asking for when we ask for the documentation: Tacit Knowledge
    - "That which is seen but not noticed"
    - It is information that is understood and implied but not stated
    - If you've ever brought someone else onto a team, you spend a lot of time
      explaining things that are obvious to you
    - You might not explain that stuff if you're doing it on paper
    - You don't want to end up in a situtation where there's too much documentation

- What can we borrow from software engineering principles?
    - Orthogonality
        - A good thing in software development
        - Intersect at a clear and obvious point and do not influence each other at any other point
    - Cohesion
        - All attributes and methods are related to the essence of the class
        - Don't have people look in 5 different places to get the answer to a single question
    - Coupling
        - The extent to which one thing is dependent on each other

- To the future
    - 5 years ago, unit testing was unheard of in the web development world
    - Rails and similar projects have helped popularize unit testing
    - We've moved from the point to where we say "testing is awesome"
    - Testing is now a core value
    - Can we make documentation a core value?

- Agile documentation processes
    - Large companies are good at this; open source people not so good
    - Looking to Rails:
        - Documentaton conventions?
        - What if we had 5 steps for writing documentation that did 70% of the work?
    - Can we integrate documentation with code?
        - In many cases, the docs exist as a Word document
        - A step up is to use a Wiki -- support for multiple authors, versioning, linking
        - Can we put docs right in the codebase?
        - Every Rails app has a doc directory -- can we use that?
        - We test code -- is there a way to make testable documentation?
        - What if we could tag a method and class with a keyword and make that keyword appear in the docs?
          -- We could generate an alert when changes happen

Checking Out the Rich Media Institute

After the presentation, which was held in the Rich Media Institute’s basement-level lecture room, a number of us headed upstairs to check out its main floor. If you’re a techie with a creative bent, this place is like a candy store. The front part is a store full of books, t-shirts, music and other goodies that new media creators and aficionados would love, while the back is a gallery for local interactive artists’ works.

I took some photos of the place and posted them in the gallery below. Click on any of the thumbnails to see a larger version of the picture:

After “a much-needed summer hiatus” (which you can read as “the complete implosion of Toronto’s worst-run software development shop, which used to host the event”) Ruby on Rails Project Night makes its comeback this Friday, September 19th at its new home at the Rich Media Institute in Kensington Market.

Event organizer Corina Newby promises that it won’t normally be on Fridays, which should the minds of your significant others, party-going friends or World of Warcraft clans at ease. The event is being held on a Friday this time to accommodate the schedule of special guest James “Smalltalk Tidbits, Industry Rants” Robertson, who’ll be there to give us a presentation of the Smalltalk-based web application framework Seaside and the Seaside-based Smalltalk development environment WebVelocity.

Also scheduled is local Ruby on Rails developer Paul Doerwald, who’ll be doing a presentation on insights he gained from working with ActiveRecord validation.

As always, one of the greatest benefits of these gatherings is actually meeting local developers who work with or are interested in working with Ruby and Rails. It’s good for you, your software development career and the future of Accordion City as a hub for high-tech when gatherings like this take place, so be a part of it!

By the way, did I mention that the event is FREE?

Once again, the date is this Friday, September 19th at the Rich Media Institute (156 Augusta Avenue). The presentations will start at 6 p.m. and run until about 7:30. If you’re planning to attend, let Corina know at corecorina@hotmail.com.

The next method I’m going to cover in Enumerating Enumerable — the series of articles in which I try to do a better job of documenting Ruby’s Enumerable module than Ruby-Doc.org does — is inject, a.k.a. reduce. Not only is it one of the trickiest methods to explain, it’s also one of the cornerstones of functional programming. I thought that I’d take a little time to explain what the function does.

inject

The term inject comes from Smalltalk and isn’t terribly descriptive. I remember reading the documentation for it and being all confused until I saw some examples. I then realized that I’d seen this function before, but under two different names.

reduce

Burning Man 1999: gratuitous nudity and even more gratuitous accordion!

The second name by which I encountered this function is reduce, and it was at Burning Man 1999. I was to start a new job the week after Burning Man, and I had to learn at least some basic Python by then. So along with my camping gear, accordion and a kilo of candy for barter, I also brought my laptop (a 233Mhz Toshiba Sattelite with a whopping 96MB of RAM) and O’Reilly’s Learning Python and noodled during the downtime (early morning and afternoon) on Python 1.6. When I got to covering the reduce function, I was confused until I saw some examples, after which I realized that I’d seen that function before, but under a different name.

(You may have also heard of reduce through Google’s much-vaunted MapReduce programming model.)

fold

The first name by which I encountered this function is fold, or more specifically, “fold left” or “foldl”, and it was at the “Programming Paradigms” course I took at Crazy Go Nuts University. “Programming Paradigms” was a second-year course and had the reputation of being the most difficult course in the computer science curriculum. The intended purpose of this course was to provide students with an introduction to functional programming (these days, they use Haskell and Prolog, back then, it was Miranda). Its actual effect was to make most of the students swear off functional programming for the rest of their lives.

In spite of the trauma from this course, I ended up remembering a lot from it that I was able to apply, first to Python and now to Ruby. One of these things is a cute little trick for cememnting in your mind what fold does.

What Ruby-doc.org Says

Before I cover that cute little trick, let’s take a look at what Ruby-doc.org’s documentation has to say about Enumerable’s inject method.

One thing you’ll find at Ruby-doc.org is that as of Ruby 1.8.7 and later, inject gained a synonym: the more familiar term reduce.

As for the description of the inject/reduce method, I don’t find it terribly helpful:

Combines all elements of enum by applying a binary operation, specified by a block or a symbol that names a method or operator.

If you specify a block, then for each element in enum<i> the block is passed an accumulator value (<i>memo) and the element. If you specify a symbol instead, then each element in the collection will be passed to the named method of memo. In either case, the result becomes the new value for memo. At the end of the iteration, the final value of memo is the return value fo the method.

If you do not explicitly specify an initial value for memo, then uses the first element of collection is used as the initial value of memo.

(Yes, those stray <i> tags are part of the text of the description for inject. Hopefully they’ll fix that soon.)

This confusing text becomes a little clearer with some examples. The most typical example of inject/reduce/fold in action is the classic “compute the sum of the numbers in this range or array” problem. There are a number of approaches you can take in Ruby, all of which use inject/reduce:

(1..8).reduce(:+)
=> 36

(1..8).reduce {|sum, number| sum += number}
=> 36

(1..8).reduce(0) {|sum, number| sum += number}
=> 36

The reduce method takes some kind of operation and applies it across the enumerable to yield a single result. In this case, the operation is addition.

Explaining how that operation is applied is a little trickier, but I do just that in the next section.

Demonstrating inject / reduce / fold With a Piece of Paper and Literal Folding

To explain what’s happening in the code above, I’m going to do use a piece of paper. I’ve folded it into 8 even sections and then numbered each section, as shown in the photo below:

Think of the paper as the range (1..8). We’re now going to compute the sum of the numbers in this range, step by step, using a literal fold — that is, by folding the paper. I’m going to start folding from the left side of the paper, and when I do, I’m going to add the numbers that I’m folding into each other.

In the first fold, I’m folding the number 1 onto the number 2. Adding these two numbers yields 3, which I write on the back of the fold:

For the second fold, I fold the first number 3 onto the second number 3. The sum of these two numbers is 6, and I write that on the back of the resulting fold:

I fold again: this time, it’s the number 6 onto the number 4, the sum of which is 10. I write that number down on the resulting fold:

Next, I fold 10 onto 5, yielding the number 15:

I then fold 15 onto 6, which gives me 21:

Next comes 21 folded onto 7, which makes for a sum of 28:

And finally, 28 folded onto 8, which gives us a final total of 36.

And there you have it: a paper-based explanation of inject/reduce/fold, as well as why I often refer to the operation as “folding”.

Once again, it’s Enumerating Enumerable time! This is the latest in my series of articles where I set out to make better documentation for Ruby’s Enumerable module than Ruby-Doc.org’s. In this installment — the seventeenth in the series — I cover the group_by method.

In case you missed any of the previous articles, they’re listed and linked below:

1. all?
2. any?
3. collect / map
4. count
5. cycle
6. detect / find
7. drop
8. drop_while
9. each_cons
10. each_slice
11. each_with_index
12. entries / to_a
13. find_all / select
14. find_index
15. first
16. grep

Enumerable#group_by Quick Summary

Enumerable#group_by and Arrays

When used on an array, group_by iterates through the array, passing each element to to the block. The result value of the block is the group into which the element will be placed.

Example 1

For the first example, I’ll use some code similar to the example given in Ruby-doc.org’s writeup of group_by:

(0..15).group_by {|number| number % 3}
=> {0=>[0, 3, 6, 9, 12, 15], 1=>[1, 4, 7, 10, 13], 2=>[2, 5, 8, 11, 14]}

In the code above, the numbers 0 through 15 are passed to the block, which receives each number as the parameter number. The group that each number is placed into is determined by the result value of the block, number % 3, whose result can be one of 0, 1 or 2. This means that:

• The resulting hash will have three groups, represented by the keys 0, 1 and 2
• The key 0’s corresponding value is an array containing the numbers in the range (0..15) that are evenly divisible by 3 (i.e. the numbers for which number % 3 is 0.
• The key 1’s corresponding value is an array containing the numbers in the range (0..15) that when divided by 3 leave a remainder of 1 (i.e. the numbers for which number % 3 is 1.
• The key 2’s corresponding value is an array containing the numbers in the range (0..15) that when divided by 3 leave a remainder of 2 (i.e. the numbers for which number % 3 is 2.

Example 2

In the first example, the keys in the resulting hash are the same type as the values in the array whose contents we’re grouping. In this example, I’ll show that the keys in the resulting hash don’t have to be the same type as the values in the array.

simpsons = %w(Homer Marge Bart Lisa Abraham Herb)
=> ["Homer", "Marge", "Bart", "Lisa", "Abraham", "Herb"]

simpsons.group_by{|simpson| simpson.length}
=> {5=>["Homer", "Marge"], 4=>["Bart", "Lisa", "Herb"], 7=>["Abraham"]}

In the code above, each Simpson name is passed to the block, which receives it as the parameter simpson. The block’s result is the length of simpson, and this result is the group into which the name will go.

In the resulting hash:

• Note that the keys are integers while the names in the groups are strings.
• The key 5’s array contains those names in Simpsons that are 5
  characters in length.
• The key 4’s array contains those names in Simpsons that are 4 characters in length.
• The key 7’s array contains those names in Simpsons that are 7 characters in length.

Example 3

In the previous two examples, the keys for the resulting array were calculated from the values in the initial array. In this example, I’ll demonstrate that the keys for the groupings can be determined in a completely arbitrary fashion that has nothing to do with the values:

# Put the Simpsons into randomly determined groups
simpsons.group_by{rand(3) + 1}
=> {3=>["Homer", "Bart", "Abraham", "Herb"], 1=>["Marge", "Lisa"]}

# Let's try that again. The results are very likely to be different:
simpsons.group_by{rand(3) + 1}
=> {1=>["Homer", "Bart"], 2=>["Marge", "Lisa", "Herb"], 3=>["Abraham"]}

# One more time!
simpsons.group_by{rand(3) + 1}
=> {2=>["Homer", "Bart", "Lisa"], 3=>["Marge", "Herb"], 1=>["Abraham"]}

Enumerable#group_by and Hashes

When used on a hash, group_by passes each key/value pair in the hash to the block, which you can “catch” as either:

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

Example 1

In this example, we’ll group the cast of Family Guy by the item that they’re bringing to a potluck dinner:

potluck = {"Peter" => "lasagna",
           "Lois"  => "potato salad",
           "Chris" => "lasagna",
           "Meg"   => "brownies",
           "Stewie" => "chateaubriand",
           "Brian" => "potato salad",
           "Evil Monkey" => "potato salad"}
=> {"Peter"=>"lasagna", "Lois"=>"potato salad", "Chris"=>"lasagna", "Meg"=>"brownies",
"Stewie"=>"chateaubriand", "Brian"=>"potato salad", "Evil Monkey"=>"potato salad"}

# Here's one way to do it:
potluck.group_by{|person, bringing| bringing}
=> {"lasagna"=>[["Peter", "lasagna"], ["Chris", "lasagna"]], "potato salad"=>[["Lois", "potato salad"],
["Brian", "potato salad"], ["Evil Monkey", "potato salad"]], "brownies"=>[["Meg", "brownies"]],
"chateaubriand"=>[["Stewie", "chateaubriand"]]}

# Here's another way to do it:
potluck.group_by{|person| person[1]}
=> {"lasagna"=>[["Peter", "lasagna"], ["Chris", "lasagna"]], "potato salad"=>[["Lois", "potato salad"],
["Brian", "potato salad"], ["Evil Monkey", "potato salad"]], "brownies"=>[["Meg", "brownies"]],
"chateaubriand"=>[["Stewie", "chateaubriand"]]}

Example 2

In the previous example, the groupings were based on a calculation performed on the objects in the original hash. In this example, the groupings will be random: a random number generator will determine whose car each potluck attendee will ride to the potluck dinner:

potluck.group_by {[:peters_car, :quagmires_car, :clevelands_car][rand(3)]}
=> {:peters_car=>[["Peter", "lasagna"], ["Chris", "lasagna"], ["Evil Monkey", "potato salad"]],
:quagmires_car=>[["Lois", "potato salad"], ["Meg", "brownies"], ["Stewie", "chateaubriand"]],
:clevelands_car=>[["Brian", "potato salad"]]}

# Let's try another random grouping
potluck.group_by {[:peters_car, :quagmires_car, :clevelands_car][rand(3)]}
=> {:peters_car=>[["Peter", "lasagna"], ["Meg", "brownies"]], :quagmires_car=>[["Lois", "potato salad"],
["Stewie", "chateaubriand"], ["Brian", "potato salad"], ["Evil Monkey", "potato salad"]],
:clevelands_car=>[["Chris", "lasagna"]]}

# One more time!
potluck.group_by {[:peters_car, :quagmires_car, :clevelands_car][rand(3)]}
=> {:peters_car=>[["Peter", "lasagna"], ["Chris", "lasagna"], ["Stewie", "chateaubriand"]],
:quagmires_car=>[["Lois", "potato salad"], ["Evil Monkey", "potato salad"]], :clevelands_car=>[["Meg", "brownies"],
["Brian", "potato salad"]]}

Welcome to another installment of Enumerating Enumerable, my series of articles in I attempt to do a better job of documenting Ruby’s Enumerable module than Ruby-Doc.org. In this installment, I cover the first method.

In case you missed any of the previous articles, they’re listed and linked below:

1. all?
2. any?
3. collect / map
4. count
5. cycle
6. detect / find
7. drop
8. drop_while
9. each_cons
10. each_slice
11. each_with_index
12. entries / to_a
13. find_all / select
14. find_index

Enumerable#first Quick Summary

Enumerable#first and Arrays

When used on an array without an argument, first returns the first item in the array:

posts = ["First post!", "Second post!", "Third post!"]
=> ["First post!", "Second post!", "Third post!"]

# What's the first item in posts?
posts.first
=> "First post!"

# Here's the equivalent using array notation:
posts[0]
=> "First post!"

When used on an array with an integer argument n, first returns an array containing the first n items in the original array:

# What are the first 2 items in posts?
posts.first 2
=> ["First post!", "Second post!"]

# Note that when you provide an argument of 1,
# the result is still an array -- with just one element.
# If you want a scalar, don't use an argument.
posts.first 1
=> ["First post!"]

# Here's the equivalent using array slice notation:
posts[0..1]
=> ["First post!", "Second post!"]

posts[0...2]
=> ["First post!", "Second post!"]

When used on an empty array, first returns:

• nil if no argument n is provided
• The empty array, [], if an argument n is provided

[].first
=> nil

[].first 2
=> []

Enumerable#first and Hashes

In Ruby 1.8 and previous versions, hash order is seemingly arbitrary. Starting with Ruby 1.9, hashes retain the order in which they were defined, which makes the first method a little more applicable.

When used on a hash without an argument, first returns the first item in the hash as a two-element array, with the key as the first element and the corresponding value as the second element.

# Let's see what stages of partying our friends are in
party_stages = {"Alice" => :party_mineral,
                "Bob"   => :party_animal,
                "Carol" => :party_reptile,
                "Dave"  => :party_vegetable}
=> {"Alice"=>:party_mineral, "Bob"=>:party_animal, "Carol"=>:party_reptile, "Dave"=>:party_vegetable}

# Who's the first partier and what state is s/he in?
party_stages.first
=> ["Alice", :party_mineral]

When used on a hash with an integer argument n, first returns an array containing the first n items in the hash, with each item represented as a two-element array:

party_stages.first 2
=> [["Alice", :party_mineral], ["Bob", :party_animal]]

# Note that when you provide an argument of 1,
# the result is still an array -- with just one element.
# If you want a scalar, don't use an argument.
party_stages.first 1
=> [["Alice", :party_mineral]]

When used on an empty hash, first returns:

• nil if no argument n is provided
• The empty array, [], if an argument n is provided

{}.first
=> nil

{}.first 2
=> []

Once again, it’s Enumerating Enumerable, my series of articles in which I attempt to outdo Ruby-Doc.org’s documentation of Ruby’s Enumerable module. In this article, I cover the find_index method, which was introduced in Ruby 1.9.

In case you missed any of the previous articles, they’re listed and linked below:

1. all?
2. any?
3. collect / map
4. count
5. cycle
6. detect / find
7. drop
8. drop_while
9. each_cons
10. each_slice
11. each_with_index
12. entries / to_a
13. find_all / select

Enumerable#find_index Quick Summary

Enumerable#find_index and Arrays

When used on an array, find_index passes each item in the array to the given block and either:

• Stops when the current item causes the block to return a value that evaluates to true (that is, anything that isn’t false or nil) and returns the index of that item, or
• Returns nil if there is no item in the array that causes the block to return a value that evaluates to true.

Some examples:

# How about an array of the name of the first cosmonauts and astronauts,
# listed in the chronological order of the missions?
mission_leaders = ["Gagarin", "Shepard", "Grissom", "Titov", "Glenn", "Carpenter",
"Nikolayev", "Popovich"]
=> ["Gagarin", "Shepard", "Grissom", "Titov", "Glenn", "Carpenter", "Nikolayev",
"Popovich"]

# Yuri Gagarin was the first in space
mission_leaders.find_index{|leader| leader == "Gagarin"}
=> 0

# John Glenn was the fifth
mission_leaders.find_index{|leader| leader == "Glenn"}
=> 4

# And James Tiberius Kirk is not listed in the array
kirk_present = mission_leaders.find_index{|leader| leader == "Kirk"}
=> nil

Enumerable#find_index and Hashes

When used on a hash, find_index passes each key/value pair in the hash to the block, which you can “catch” as either:

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

As with arrays, find_index:

• Stops when the current item causes the block to return a value that evaluates to true (that is, anything that isn’t false or nil) and returns the index of that item, or
• Returns nil if there is no item in the array that causes the block to return a value that evaluates to true.

Some examples:

require 'date'
=> true

# These are the names of the first manned spaceships and their launch dates
launch_dates = {"Kedr"              => Date.new(1961, 4, 12),
                "Freedom 7"         => Date.new(1961, 5, 5),
                "Liberty Bell 7"    => Date.new(1961, 7, 21),
                "Orel"              => Date.new(1961, 8, 6),
                "Friendship 7"      => Date.new(1962, 2, 20),
                "Aurora 7"          => Date.new(1962, 5, 24),
                "Sokol"             => Date.new(1962, 8, 11),
                "Berkut"            => Date.new(1962, 8, 12)}
=> {"Kedr"=>#<Date: 4874803/2,0,2299161>, "Freedom 7"=>#<Date: 4874849/2,0,2299161>,
"Liberty Bell 7"=>#<Date: 4875003/2,0,2299161>, "Orel"=>#<Date: 4875035/2,0,2299161>,
"Friendship 7"=>#<Date: 4875431/2,0,2299161>, "Aurora 7"=>#<Date: 4875617/2,0,2299161>,
"Sokol"=>#<Date: 4875775/2,0,2299161>, "Berkut"=>#<Date: 4875777/2,0,2299161>}

# Where in the list is John Glenn's ship, the Friendship 7?
launch_dates.find_index{|ship, date| ship == "Friendship 7"}
=> 4

# Where in the list is the first mission launched in August 1962?
launch_dates.find_index{|ship, date| date.year == 1962 && date.month == 8}
=> 6

# The same thing, expressed a little differently
launch_dates.find_index{|launch| launch[1].year == 1962 && launch[1].month == 8}
=> 6

Using find_index as a Membership Test

Although Enumerable has a method for checking whether an item is a member of a collection (the include? method and its synonym, member?), find_index is a more powerful membership test for two reasons:

1. include?/member? only check membership by using the == operator, while find_index lets you define a block to set up all sorts of tests. include?/member? asks “Is there an object X in the collection equal to my object Y?” while find_index can be used to ask “Is there an object X in the collection that matches these criteria?”
2. include?/member? returns true if there is an object X in the collection that is equal to the given object Y. find_index goes one step further: not only can it be used to report the equivalent of true if there is an object X in the collection that is equal to the given object Y, it also reports its location in the collection.

A quick example of this use in action:

# Once again, the mission leaders
mission_leaders = ["Gagarin", "Shepard", "Grissom", "Titov", "Glenn", "Carpenter",
"Nikolayev", "Popovich"]
=> ["Gagarin", "Shepard", "Grissom", "Titov", "Glenn", "Carpenter", "Nikolayev",
 "Popovich"]

# Yuri Gagarin is in the list
gagarin_in_list = mission_leaders.find_index {|leader| leader == "Gagarin"}
=> 0

# Captain James T. Kirk is not
kirk_in_list = mission_leaders.find_index {|leader| leader == "Kirk"}
=> nil

# gagarin_in_list is 0, which as a non-false and non-nil value evaluates as true.
# We can use it as both a membership test *and* as his location in the list.
p "Gagarin's there. He's number #{gagarin_in_list + 1} in the list." if gagarin_in_list
"Gagarin's there. He's number 1 in the list."
=> "Gagarin's there. He's number 1 in the list."

# kirk_in_list is nil, which is one of Ruby's two "false" values.
# Let's use it with the "something OR something else" idiom that
# many Ruby programmers like.
kirk_in_list || (p "You only *think* he wasn't there.")
"You only *think* he wasn't there."
=> "You only *think* he wasn't there."

Parts that Haven’t Been Implemented Yet

Ruby-Doc.org’s documentation is generated from the comments in the C implementation of Ruby. It mentions a way of calling find_index that is just like calling include?/member?:

# What the docs say (does not work yet!)
["Alice", "Bob", "Carol"].find_index("Bob")
=> 1

# What happens with the current version of Ruby 1.9
["Alice", "Bob", "Carol"].find_index("Bob")
ArgumentError: wrong number of arguments(1 for 0)
...

Ruby 1.9 is considered to be a work in progress, so I suppose it’ll get implemented in a later release.

We’re at lucky number 13 — the thirteenth article in the Enumerating Enumerable series, which covers the methods of Ruby’s Enumerable module. I started this series after being disappointed with the documentation at Ruby-Doc.org.

In this article, I’m covering the find_all — a.k.a. select — method.

In case you missed any of the previous articles, they’re listed and linked below:

1. all?
2. any?
3. collect / map
4. count
5. cycle
6. detect / find
7. drop
8. drop_while
9. each_cons
10. each_slice
11. each_with_index
12. entries / to_a

Enumerable#find_all / Enumerable#select Quick Summary

Enumerable#find_all / Enumerable#select and Arrays

When used on an array, find_all and its synonym select passes each item from the array to the block, returning an array containing only those elements in the original array for which the block returns a value that doesn’t evaluate to false.

If no item in the array causes the block to return a value that doesn’t evaluate to false, find_all/select returns an empty array.

In the examples that follow (which are based on my examples for the detect/find method), I’ll be using the find_all method. select does exactly the same thing; it’s just that I prefer find_all.

# Once again,  I shall establish my "old fart" credentials
classic_rock_bands = ["AC/DC", "Black Sabbath", "Queen", \
"Ted Nugent and the Amboy Dukes", "Scorpions", "Van Halen"]
=> ["AC/DC", "Black Sabbath", "Queen", "Ted Nugent and the Amboy Dukes",
"Scorpions", "Van Halen"]

# Of the bands in the array, which ones have
# a name longer than 8 characters?
classic_rock_bands.find_all {|band| band.length > 8}
=> ["Black Sabbath", "Ted Nugent and the Amboy Dukes", "Scorpions", "Van Halen"]

# Which ones have a name exactly 5 characters long?
classic_rock_bands.find_all {|band| band.length == 5}
=> ["AC/DC", "Queen"]

# If no band in the array meets the criteria,
# find_all returns an empty array.
# Which ones have names shorter than 5 characters?
classic_rock_bands.find_all {|band| band.length < 5}
=> []

Enumerable#find_all / Enumerable#select and Hashes

When used on a hash, find_all/select passes each key/value pair in the hash to the block, which you can “catch” as either:

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

As with arrays, find_all/select passes each item from the hash to the block, returning an array containing only those items in the original array for which the block returns a value that doesn’t evaluate to false.

Note that each item in the result array is a two-element array corresponding to an item from the original hash. In this array, element 0 contains the key and element 1 contains the corresponding value.

If no item in the hash causes the block to return a value that doesn’t evaluate to false, find_all/select returns an empty array.

years_founded = {"AC/DC" => 1973, \
                 "Black Sabbath" => 1968, \
                 "Queen" => 1970, \
                 "Ted Nugent and the Amboy Dukes" => 1967, \
                 "Scorpions" => 1965, \
                 "Van Halen" => 1972}
=> {"AC/DC"=>1973, "Black Sabbath"=>1968, "Queen"=>1970,
"Ted Nugent and the Amboy Dukes"=>1967, "Scorpions"=>1965, "Van Halen"=>1972}

# Ruby 1.9 preserves hash order so that hashes keep the order in which
# you defined them, while Ruby 1.8 puts them in some mysterious order.
# All these examples are in Ruby 1.9

# Which bands were founded in 1970 or later?
years_founded.find_all {|band| band[1] >= 1970}
=> [["AC/DC", 1973], ["Queen", 1970], ["Van Halen", 1972]]

# Here's another way of phrasing it:
years_founded.find_all {|band, year_founded| year_founded >= 1970}
=> [["AC/DC", 1973], ["Queen", 1970], ["Van Halen", 1972]]

# Which bands were founded after 1980?
years_founded.find_all {|band, year_founded| year_founded > 1980}
=> []

Here’s number 11 in the Enumerating Enumerable series, in which I’m trying to outdo RubyDoc.org in their documentation of Ruby’s key Enumerable module. In this article, I cover the each_with_index method.

In case you missed the earlier articles, they’re listed and linked below:

1. all?
2. any?
3. collect / map
4. count
5. cycle
6. detect / find
7. drop
8. drop_while
9. each_cons
10. each_slice

Enumerable#each_with_index Quick Summary

Enumerable#each_with_index and Arrays

When used with on an array and given a block, each_with_index iterates through the array, passing each item in the array and the number representing its order in the array to the block. Once again, I’ll use the “Justice League” example:

justice_league = ["Aquaman", "Batman", "Black Canary", \
                  "Flash", "Green Arrow", "Green Lantern", \
                  "Martian Manhunter", "Superman", \
                  "Vixen", "Wonder Woman"]
justice_league = ["Aquaman", "Batman", "Black Canary", "Flash", "Green Arrow",
"Green Lantern", "Martian Manhunter", "Superman", "Vixen", "Wonder Woman"]

justice_league.each_with_index {|member, index| puts "#{index}: #{member}"}
=> 0: Aquaman
1: Batman
2: Black Canary
3: Flash
4: Green Arrow
5: Green Lantern
6: Martian Manhunter
7: Superman
8: Vixen
9: Wonder Woman
=> ["Aquaman", "Batman", "Black Canary", "Flash", "Green Arrow", "Green Lantern",
"Martian Manhunter", "Superman", "Vixen", "Wonder Woman"]

Note that unlike the each_cons and each_slice, each_with_index doesn’t return nil, but the original array, just like each does. each_cons and each_slice are newer methods that were introduced in Ruby 1.9; perhaps Matz and company decided that it made more sense for “each” methods to return nil from now on. each and each_with_index have return the original array as they always have, since making changes to these methods might break a lot of existing Ruby code. Hooray for those little inconsistencies that creep into every programming language!

Enumerable#each_with_index and Hashes

When used with on a hash and given a block, each_with_index iterates through the hash, converting each item in the hash into a two-element array (where the first element is the key and the second element is the corresponding value), and then passing that array and the number representing its order in the original array to the block. Once again, I’ll use the “Enterprise Crew” example:

enterprise_crew = {:captain => "Picard",
                   :first_officer => "Riker",
                   :science_officer => "Data",
                   :tactical_officer => "Worf",
                   :chief_engineer => "LaForge",
                   :chief_medical_officer => "Crusher",
                   :ships_counselor => "Troi",
                   :annoying_ensign => "Crusher",
                   :attractive_ensign => "Ro",
                   :expendable_crew_member => "Smith"}
=> {:captain=>"Picard", :first_officer=>"Riker", :science_officer=>"Data",
:tactical_officer=>"Worf", :chief_engineer=>"LaForge",
:chief_medical_officer=>"Crusher", :ships_counselor=>"Troi",
:annoying_ensign=>"Crusher", :attractive_ensign=>"Ro",
:expendable_crew_member=>"Smith"}

enterprise_crew.each_with_index {|member, index| puts "#{index}: #{member}"}
=> 0: [:captain, "Picard"]
1: [:first_officer, "Riker"]
2: [:science_officer, "Data"]
3: [:tactical_officer, "Worf"]
4: [:chief_engineer, "LaForge"]
5: [:chief_medical_officer, "Crusher"]
6: [:ships_counselor, "Troi"]
7: [:annoying_ensign, "Crusher"]
8: [:attractive_ensign, "Ro"]
9: [:expendable_crew_member, "Smith"]
=> {:captain=>"Picard", :first_officer=>"Riker", :science_officer=>"Data",
:tactical_officer=>"Worf", :chief_engineer=>"LaForge",
:chief_medical_officer=>"Crusher", :ships_counselor=>"Troi",
:annoying_ensign=>"Crusher", :attractive_ensign=>"Ro",
:expendable_crew_member=>"Smith"}

Enumerable#each_with_index Oddities

Blocks with a Single Parameter

What happens if you use each_with_index with a block that has only one parameter? You’d think that the block would accept the item and index passed to it as a two-element array, with the item as the first element and the corresponding index as the second element, but that’s not the case:

# For each item in justice_league, this line will output the following:
# {second letter of member's name} : {first letter of member's name}
justice_league.each_with_index {|member| puts "#{member[1]}: #{member[0]}"}
=> q: A
a: B
l: B
l: F
r: G
r: G
a: M
u: S
i: V
o: W
=> ["Aquaman", "Batman", "Black Canary", "Flash", "Green Arrow", "Green Lantern"
, "Martian Manhunter", "Superman", "Vixen", "Wonder Woman"]

When each_with_index passes an item and its index to a block that takes only one parameter, the item goes into the paramter, and the index is discarded. Simply put, in this case, each_with_index behaves just like each.

Without a Block

What happens if you use each_with_index without a block to create an Enumerator object that spits out the next item when its next method is called? This:

hero = justice_league.each_with_index
=> #<Enumerable::Enumerator:0x159cb98>

hero.next
=> "Aquaman"

hero.next
=> "Batman"

hero.next
=> "Black Canary"

Note that calling next only yields the next item in the collection; the index information is lost. In this case, each_with_index behaves just like each.