The Urban Dictionary definition of "wat" is "the only proper response to something that makes absolutely no sense". The concept of wat is covered a little more completely on its page in Know Your Meme.

"Wat" is also the title of a funny demo of Ruby and JavaScript oddities presented by Gary Bernhardt at CodeMash 2012, a rather unlikely tech conference — it takes place in Sandusky, Ohio, in Ohio’s largest indoor waterpark. (If you just said "wat" right now, you’ve used the word correctly.)

In the video, you see this classic wat bit about undefined variables and assignment in Ruby:

You’ll also marvel at the way JavaScript treats (array + array) vs. (array + object) vs. (object + array) vs. (object + object):

Watch the video, and wait for that final slide, which is pure, hilarious wat!

This article also appears in the Shopify Technology Blog.

My friend Robert Nishimura’s looking for a Rails developer for his company, ClearFit, which is based in uptown Toronto. He sent me some details about the position he’s trying to fill; I’ve posted them below.

If you’ve got the skills and if the position sounds interesting to you, you should drop him a line at robert@clearfit.com!

Company Information

ClearFit is changing the way small businesses hire. Most people know that ‘fit’ is the most desirable attribute for employees and employers — that intangible sense that can’t be found in a resume and is difficult to glean from a job interview. It’s a huge problem — employers spend billions every year on staffing in Canada alone.

Most small business owners don’t know where to even start when hiring a new employee. Ask around for referrals, “pay and pray” with a job board or deal with an avalanche of resumes from Craigslist? 

We have built the system that some describe as “an eHarmony for jobs”. We have over 2500 registered employers and tens of thousands of registered career seekers which barely scratches the surface of a multi-billion dollar market. All this and we just completed our first round of investment so we are poised for stellar growth.

We are located in the Yonge/Eglinton neighbourhood, strategically situated between 3 Starbucks and 3 minutes from Bulldog Coffee. We’re also upstairs from Copacabana Brazilian BBQ.

Skills & Requirements

Skills:

• Minimum 2 years experience coding in Ruby on Rails
• Minimum 2 years experience with HTML/CSS
• Experience with Javascript (Prototype, JQuery)
• Experience with Postgres SQL
• Experience with Ubuntu/Nginx
• Experience with GitHub

Bonus points:

• Experience with Amazon EC2
• Experience integrating with other web apps
• Photoshop and front-end web development skillz
• iOS development experience

What ClearFit Offers

• Salary between $80K and $100K based on experience
• Snacks and drinks in our kitchen
• Wicked awesome coffee from our new Nespresso machine
• 15 days paid vacation per year
• Full group benefit plan which includes vision, dental

If this sounds like something you’re interested in, contact Robert Nishimura directly at robert@clearfit.com

Welcome to another Salmagundi — a selection of some interesting techie stuff on the web!

In his article Your Code is My Hell, all-round Ruby/Rails guru Avdi Grimm warns Ruby and Rails developers about a creeping exceptionalism that has been rearing its ugly head as of late. Many Ruby/Rails developers seem to be under the impression that simply because Ruby and Rails do a lot to make programming easier, they can simply ignore things like good coding, good object design, design patterns and the SOLID principles and all those other practices and disciplines that good coders follow and exercise. Ruby’s a great programming language and Rails is a great web development framework (and I’m quite glad to return to them), but they’re not a free pass to code carelessly!

Nick Quaranto from Thoughtbot explains why he loves CoffeeScript, by way of the movie 300, in CoffeeScript: Spartan JavaScript. “Writing JavaScript properly, and in an OO manner, requires you to be verbose,” writes Quaranto. “What I like best is that CoffeeScript is simply…spartan.” He covers the good as well as the bad (but it’s mostly good). If you’d like to try it out, visit the CoffeeScript site to get started.

Here’s another one from Avdi Grimm (he’s got lots of good suggestions — you should check his blog regularly if you’re a Ruby/Rails developer): The Procedure/Function Block Convention in Ruby. He’s got a clever idea for when to use “curly bracket” blocks (he suggests to use the for functional blocks) and when to use “do…end” blocks (he says to use them for procedural ones.

And finally, if you use Git, you’ll want to read Benjamin Sandofsky’s article, Understanding the Git Workflow. “If you’re fighting Git’s defaults,” he writes, “ask yourself why.” He suggests that your workflow should be:

1. Create a private branch off a public branch.
2. Regularly commit your work to this private branch.
3. Once your code is perfect, clean up its history.
4. Merge the cleaned-up branch back into the public branch.

This article also appears in the Shopify Technology Blog.

A hand-drawn copy of a comic panel from why’s (poignant) guide to Ruby on a traffic light in Austin, Texas.

It’s August 19th, which in some circles is known as Whyday. If you’re not familiar with what this day’s about or where its name comes from, you might want to read our earlier article, Whyday is Friday. I like to think of this day as a reminder to bring a sense of whimsy, sharing, fun and wonder to your work, whether it’s programming or anything else.

Jessica Allen tweeted the photo above: an expense report in the spirit of Whyday.

Roger von Oech, who wrote one of my favourite books — A Whack on the Side of the Head — mentioned Whyday in a tweet today!

I must tip my hat to the appropriately-surnamed Josep M. Bach, whose Whyday contribution is Niki, “the first stable, documented version of Niki, a ruby DSL to write songs”. Programming and music — what could be more fitting?

_why’s cartoon foxes are everywhere. This stencilled graffito was found by Janet Swisher in Barcelona, which I believe is quite far from where _why lives.

Wyatt Greene, on this blog Techiferous, is celebrating Whyday with an article about programming archetypes featuring _why-esque comic illustrations. Nicely done!

Andrew Lenards, who leads “a team of developers working on a larger scientific application” is encouraging his developers to celebrate Whyday. Well done, sir!

Andrei Volkov tweeted: “I just MUST use #whyday to promote my translation of Why’s Poignant Guide to Ruby into Russian.” Keep at it, Andrei, and…spaceeba!

The RubyLearning blog is celebrating WhyDay by announcing the 8th batch of their “Ruby with Shoes” course. Shoes is a great little Ruby GUI toolkit that _why whipped up, and there’s nothing that makes learning a new programming language fun like the immediate satisfaction and feedback of a desktop app.

Gogol is a game that’s written in Ruby, minimalist and brain-teasing. This is right up _why’s alley.

As for me, I’m doing my bit to spread the word about Whyday, working on a few ideas to help people get better at programming and ecommerce (which includes making more videos like this one), mixing music with coding with the assistance of my trusty travelling accordion as well as relearning all the Ruby I’ve forgotten over the past couple of years working at the Empire and sharing what I learn along the way.

I feel incredibly fortunate to be at Shopify (I’ve been with the company a shade more than three months), away from the Fortune 50 corporate world and back in the land of startups, programming languages like Ruby and CoffeeScript, and where whimsy and the willingness to take chances and try new things is greatly appreciated. It’s been a wild and crazy year for me both personally and professionally, and it’s only increased my appreciation for bringing the spirit and sense of fun to my work in the same way that _why did. I hope Whyday does the same for you.

Happy Whyday, and happy hacking!

(If you’re doing or did something interesting for Whyday, drop me a line and I’ll mention you and your activity in an upcoming blog post!)

This article also appears in the Shopify Technology Blog.

Clever programmer. Multimedia and performance artist. Whimsical writer. Oddball performer. Howard Hughes-style recluse. All of these phrases are apt descriptions of the guy most of us know only as why the lucky stiff, or _why for short.

Bold, Brief and Gone

If _why had a personal motto, it might be “Be bold, be brief, be gone.” The bold part was plain to see. His Ruby tutorial, why’s (poignant) guide to Ruby, broke away from the style of your typical programming books and went for the wild and whimsical. Only _why would take a topic like metaprogramming — something that confounds a number of experienced developers, never mind the newbies he was trying to reach in his book — and turn it into a fantastic adventure game exercise, complete with comics. Few developers have the breadth of skill and interest to make projects like Try Ruby (a browser-based Ruby shell with instructional guides) to Camping (a Rails-like web app microframework smaller than 4K) to Shoes and Hackety Hack (a UI toolkit for “web-like desktop apps” and a development environment to teach children programming) to Park Place (a “nearly complete clone” of Amazon’s S3). There may be people out there who’d be able to pull off a music-and-programming performance like the one he did at the first RailsConf, but they haven’t yet presented themselves to the world.

The “brief” and “gone” bits take a little more explaining. _why’s notoriety rose with Ruby’s popularity, which in turn was connected to Ruby on Rails. I remember reading some posts on one of his blogs, RedHanded, as far back as late 2003, and the (poignant) guide surfaced in 2004 and found its way into print in 2005, when the chapter A Quick (and Hopefully Painless) Ride Through Ruby (with Cartoon Foxes) appeared in the Apress book The Best Software Writing I: Selected and Introduced by Joel Spolsky. His music-and-code extravanganzas at South by Southwest, O’Reilly’s Open Source conference and the first RailsConf cemented his rep as the programmer who was also a performance artist and by 2008, people were seeking him out for all sorts of things, from personal appearances (Pete Forde tried to get him to come to RubyFringe, but convincing him to leave the US proved to be impossible) to commissioning body art (Leah Culver got him to design a tattoo for her).

All in all, _why’s popular presence on the web spans about 5 or 6 years.

For reasons still unknown to the Ruby community at large — perhaps Matz knows and is sworn to secrecy — _why “disappeared” on August 19, 2009. It’s not that he disappeared in the D.B. Cooper sense, but in the J.D. Salinger sense: not as a legal missing person, but as a person determined to remove himself and his activities from the public eye. In the span of a day, he removed as many traces of his online presence as he could: the blogs, the sites, the projects. Luckily, there’s a lot of his work floating around thanks to his open sourcing and Creative Commons-ing of his works and the curation of many techies who appreciated them.

WhyDay Declared

A year after his disappearance from the online world, Glenn Vandenburg declared the first anniversary of his disappearance as “Whyday”. Whyday is a day to celebrate _why’s contributions to the culture and communities that have grown around the Ruby programming language and all the software built upon it. “We in the Ruby community wish him well,” goes the text on the Whyday site, “but we really miss him.”

The Whyday site goes on:

Why gave us a lot of cool software and other things, but what he really gave to the Ruby community was a spirit of freedom, whimsy, and creativity. When Why took the stage at the first RailsConf, in 2006, he strapped on his guitar, walked to the microphone, and yelled “Put your best practices away!”

Discipline, care, and responsibility are important; we owe our customers, employers, team members, and families to take our work seriously. At the same time, though, we need to play. If we don’t occasionally break out of the mold of our “best practices,” we can easily miss many wonderful ideas, some of which can bear rich fruit (just as Camping and Hpricot led to Sinatra and Nokogiri).

This year, on August 19, celebrate Whyday. Set aside that day to remember Why’s contributions to our community and culture by hacking just for the fun and joy of it.

Among the things people were encouraged to do on Whyday were:

• See how far you can push some weird corner of Ruby (or some other language).
• Choose a tight constraint (for example, 4 kilobytes of source code) and see what you can do with it.
• Try that wild idea you’ve been sitting on because it’s too crazy.
• You can work to maintain some of the software Why left us (although Why is more about creating beautiful new things than polishing old things).
• On the other hand, Why is passionate about teaching programming to children. So improvements to Hackety Hack would be welcome.
• Or take direct action along those lines, and teach Ruby to a child.

I made a note of WhyDay on my personal tech blog, Global Nerdy, as well as the blog I got paid to write for (I was a Microsoft employee at the time). I didn’t get the chance to do as much as I’d like in the spirit of Whyday, probably because I was knee deep in getting ready for TechDays, a series of cross-country conferences run by The Empire.

WhyDay 2011

Here we are, a year after the first Whyday. I’ve done some quick searching and haven’t found any mention of celebrating Whyday this year, so I’ve taken it upon myself to spread the word. It probably helps that I’m no longer at Microsoft and now in Shopify, which not only builds stuff on Ruby and Rails; it was also co-founded by an original member of the Rails core team, and people here are writing the next edition of Rails in a Nutshell. This place just oozes Ruby.

_why might not want to be celebrated, but in my mind, _why isn’t the real reason that Whyday should be celebrated anyway. I think it’s more about the spirit of what _why did: really getting to know the tools you’re using, helping people understand those tools using unorthodox means whenever conventional means just don’t get the point across, and building great tools when the tools you want don’t exist.

It’s about finding joy and delight in your craft, and bringing to it a sense of play. It’s about making things better. All that is in the spirit of why I quit a high-paying, cushy job and joined a rag-tag team of techies in a startup, and this year, I’m going to try to celebrate Whyday — this Friday, August 19th, 2011, a little more properly.

How about you?

This article also appears in the Shopify Technology Blog.

After three years away from all but the most trivial of noodling with the Ruby programming language, I have become a Ruby Foo (as in Mr. T’s catchphrase, “I pity the foo’!”). I am severely out of practice with Ruby, and with two versions having appeared since I last made a living with Rails, even the act of creating a new project is completely different. Since Ruby is the preferred back-end programming language at Shopify and I am the Platform Evangelist, it’s time for me to “sharpen the saw”.

Luckily for me, I ran into Obie Fernandez at the South by Southwest Interactive conference back in March. We sat down for a coffee and he told me about what was happening with Hashrocket and I told him that I was a hair’s breadth away from joining Shopify.

“I’ve been away from Ruby long enough that I’m probably back at newbie level again,” I told Obie between sips of latte made with overcooked beans. “I did it for a bit at the beginning using IronRuby, but between doing all the C# and PHP and the open source ‘Iron’ languages dying of neglect at Microsoft, I’m severely out of practice. I thinking of joining Shopify, and let’s face it: I don’t want to look like an ignoramus in the presence of rock stars like Tobi, Cody and Edward.”

“Give me your email,” said Obie, “and I can do something to help.” Of course he could – he’s the series editor of Addison-Wesley’s Professional Ruby series of books.

Shortly after South by Southwest, a couple of links to PDF editions appeared in my inbox. Thanks, Obie!

The first link was to Eloquent Ruby, Russ Olsen’s guide to speaking idiomatic Ruby and getting the most out of the Ruby programming language. It’s a breezy read, written in the same conversational tone that Olsen used in Design Patterns in Ruby, and the book is broken down into 31 bite-size chapters about a dozen pages in length. Each chapter’s title is some principle for programming eloquent Ruby – the first few are “Write Code That Looks Like Ruby”, “Choose the Right Control Structure” and “Take Advantage of Ruby’s Smart Collections” – and each explains that principle, provides code, shows you where you can find the principles used in actual, working projects. The book straddles the line between tutorial and reference; it’s written in tutorial style, but it’s organized so well that it might as well be a reference for those parts of Ruby that you might not use often (but should) as well as for those parts you keep forgetting (in my case, I always end up having to look up metaprogramming). I’ve been going through it at about a chapter an evening, and I’ve been getting smarter each time. Whether you’re coming back to Ruby after a hiatus like I am or if you just simply want to get better at Ruby, you should have this book in your library.

If you’d like to know more about Eloquent Ruby and its author, Russ Olsen, check out this interview with him at InfoQ.

I have yet to properly sink my teeth into Ruby on Rails 3 Tutorial but a quick scan of the book has shown that it’s quite promising, and the Amazon reviews are bolstering my belief.

I’ll be writing from time to time about my return to Ruby and Rails in this “Ruby Foo” series of posts, and I hope that whether you’re new to the language, returning after a break like me or aiming for “guru” status, that you’ll check out this blog regularly for notes on my explorations and what I’ve learned.

This article also appears in the Shopify Technology blog.

Some of the Shopifolks are travelling this weekend to some interesting events.

rspec::table, a.k.a. The Ruby Job Fair (Friday, May 20th)

If you’re in the Toronto area and looking for a job, you might want to drop by rspec::table employment, otherwise known as the Ruby Job Fair. Our friends at Unspace are holding this event, where Rubyists seeking employment can meet with potential employers.

It’s the third such event put together by Unspace, and it’s specifically aimed at those programmers who’ve eschewed more mainstream programming languages and frameworks for the Ruby, Rails and other Ruby-related goodies because, let’s face it, they’re fun. And hey, we believe that if you’re going to spend your working life — half your waking existence — doing something, it had better be fun, don’t you think?

Have you considered developing for Shopify? Think of it: we’re growing start-up that’s actually profitable, and that was before we secured that Series A funding. We’re in the business of helping people sell stuff online, a field whose growth is strong and steady. We’ve got some killer coders in the shop; I feel like the dumbest guy in the room when I’m around them (I’m okay with that — it has its advantages). The perks of working here are great, from the people to the gear and welcome swag to the location — not some soul-draining industrial park, but in Ottawa’s ByWard Market: central, and the liveliest part of town.

If you’d like to get a job with us and in on some of this action, come on down to the Ruby Job Fair this Friday, May 20th at Unspace’s office (342 Queen Street West, Toronto, east of Spadina, above LuluLemon) from 5:30 p.m. to 7:00 p.m. and say hello to the Shopifolk who’ll be there: Brittany, Edward and Julie!

To find out more about the Ruby Job Fair and the after-party, visit the Ruby Job Fair site.

BarCamp Oregon (Friday, May 20th – Saturday, May 21st)

Shopify is one of five startups that makes up the BarCamp Tour, a group helping sponsor BarCamps all over North America. Thus far, we’ve been to BarCamp Boston and MinneBar (a Minneapolis-based BarCamp serving all of the state of Minnesota). This weekend, we’ll be at the third BarCamp on the tour: Portland, Oregon, affectionately known to some as Portlandia:

BarCamp Portland is an unconference: a conference whose topics, sessions and schedules are determined by the attendees. On the start of the unconference day, people will propose session topics and set up a schedule, after which the unconferencing will begin. We’re expecting geeks of every sort to show up: not just the hackers, but artists, engineers, hobbyists, writers and poets, jokers and journalists, entrepreneurs, cooks and bakers, people who till the land or help neighbourhoods take shape, and anyone else who likes create.

Shopify, along with our partners on the BarCamp Tour – BatchBlue, Grasshopper, Mailchimp and Wufoo — isn’t your typical event sponsor. Yes, we’re each throwing in money to help BarCamp organizers hold their events, but we’re also there at the conference, actively participating, joining in the discussions, providing food and drinks, and even helping carry stuff or clean up. We’re also there to promote our companies, but not in a hard-sell way — we’re there to meet people who want to use our software and services, have questions and get to know the creative, inventive, ambitious people who attend BarCamps!

I’ll be there, helping out, facilitating sessions, answering questions about Shopify and playing accordion (of course). If you see me, please say hi!

To find out more about BarCamp Portland, visit the BarCamp Portland site.

If you’re interested in finding out more about BarCamps, watch this video, taken at one of the first BarCamps in San Francisco:

This article also appears in the Shopify Blog. ]]> http://www.globalnerdy.com/2011/05/19/going-to-toronto-for-ruby-job-fair-and-portland-for-barcamp/feed/ 0 http://www.globalnerdy.com/2011/05/16/rspectable-employment-or-ruby-job-fair/ http://www.globalnerdy.com/2011/05/16/rspectable-employment-or-ruby-job-fair/#comments Mon, 16 May 2011 04:33:18 +0000 Joey deVilla http://www.globalnerdy.com/?p=8239

It’s Ruby Job Fair time! This Friday, May 20th, from 5:30 p.m. to 7:00 p.m., at the offices of Accordion City-based development shop Unspace (342 Queen Street West, just above the LuluLemon store), rspec::table, a.k.a. The Third Ruby Job Fair will take place. If you’re a Ruby developer looking for work, you also want to be at rspec::table. If you’re curious about developing in Ruby, guess what — you should also drop by rspec::table!

Among the employers who’ll be present at rspec::table will be my employer, Shopify. We’re sending a couple of people, including developer advocate Edward Ocampo-Gooding, down to Toronto to chat with developers and see who’s got the chop and the interest in working for the company who’s making the only ecommerce platform that matters. If you’d like to work for one of Canada’s most promising startups (who also recently landed $7 million in series A funding and hired Canada’s best tech evangelist), you should come to rspec::table and talk to Edward about Shopify!

At 7:00 p.m., the event will shift gears and become a special edition of Rails Pub Nite, the monthly get-together or Rails developers and their friends. This special edition will be an “afterparty” held on Unspace’s rooftop deck, which offers a stunning view of downtown Toronto that gets even more stunning as the sky gets dark. Free food and drink will be provided, and having attended a number of Unspace catered events, I can assure you that they’ll be good. The fun will continue until 11:00 p.m..

By the way, the regular edition of Rails Pub Nite, which takes place on the third Monday of every month, is still taking place tonight at its usual digs: The Rhino (1249 Queen Street West) from 7:00 p.m. – 11:00 p.m.. If I were in town, I’d be there.

If you’d like to attend rspec::table, you need to register (it’s a mere $5.00 to register)! If you want to attend the Rails Pub Nite afterparty, you also need to register (it’s free)! To register, go to rspec::table’s Guestlist page — and hurry before the tickets run out!

If you’re a developer out in the Maritimes, you might want to check out Derek Hatchard’s Maritime Dev Con, which takes place on June 18th in Moncton. It’s a single-afternoon, two-track conference – which means you should be able to take time out to attend it – covering a number of topics including:

• .NET and ASP.NET
• Java
• iPhone development
• Ruby
• Python
• Groovy
• NoSQL and MongoDB
• “Rockstar Estimating Skills”

Maritime Dev Con has a registration fee that won’t hurt your wallet – it’s a mere CAD$19!

I’m a big fan of small, regional gatherings like Maritime Dev Con and its western counterpart Prairie DevCon. Each region has its own specializations and needs that a by-locals, for-locals conference can do a better job of serving, and the smaller size of these conferences allows for more back-and-forth between audience and presenter, and between attendees. Support your local conference!

This article also appears in Canadian Developer Connection.

Hello, IronRuby 1.0!

Although it’s been out for the past couple of weeks and might be considered old news, I couldn’t let it pass unmentioned, especially given my history with the Ruby programming language: IronRuby 1.0 has been released!

IronRuby is an implementation of Ruby targeting the .NET Framework and built on Microsoft’s Dynamic Language Runtime, which in turn runs on top of the Common Language Runtime. Version 1.0 is compatible with Ruby 1.8.6; future releases will aim for compatibility with Ruby 1.9.

You can use IronRuby 1.0 to build these sorts of applications:

• Desktop applications using WPF
• Desktop, in-browser rich internet applications and Windows Phone applications using Silverlight
• Ruby on Rails applications (up to Rails version 2.3.5)
• Good ol’ command-line applications
• and of course, the REPL (Read-Evaluate-Print Loop) goodness of irb

As of version 1.0, IronRuby comes in two flavors:

• The one that runs on top of .NET 4.0. The .NET 4.0 framework is the latest version and was released with Visual Studio a couple of weeks ago (you can download it for free here). This is the preferred version, and features goodies such as:
  • Faster startup
  • Compatibility with C#’s dynamic keyword
  • Access to all the new features in the .NET 4.0 framework
• The one that runs on any earlier .NET, starting with 2.0 SP1. For compatibility with earlier versions of .NET as well as with Mono, you’ll want to use this version.

IronRuby is free in both senses of the word:

• Free as in beer. It costs nothing – just download it and use it!
• Free as in speech. It’s open source software, released under the Microsoft Permissive Licence, which is recognized by the Open Source Initiative.

You can download IronRuby 1.0 from the IronRuby site on Microsoft’s CodePlex site.

Ruby and IronRuby Reading

Programming Ruby, a.k.a. “The Pickaxe Book”, is on every serious Rubyist’s shelf. It’s both a good introduction to the language and a pretty decent reference.

why’s (poignant) guide to ruby isn’t a complete guide to Ruby, nor is it your typical programming book. It’s free, online, the most whimsical programming book you’ll ever read, and it’s been the driving force behind a lot of dynamism and creativity of the Ruby community.

The newly-released IronRuby Unleashed covers both the Ruby programming language, the IronRuby implementation and using IronRuby to mix Ruby and .NET into a Reese peanut butter cup of developer goodness.

Ruby Job Fair 2010

Last year, I attended and wrote about employment.nil?, the Ruby job fair held by Toronto software development shop Unspace. They’re doing it again this year with a different format. Where last year’s was modelled after a science fair (the kind you remember from high school), this year’s is going to be modelled after “speed dating” and will feature 5-minute chats between people looking for work and people looking to hire.

To reflect the new format and pay homage to the Ruby-style naming of the first event, they’re calling it require ‘date’. The job fair will take place in Toronto on Sunday, May 30th in the back room of the Rivoli (334 Queen Street West, just east of Spadina) from 2:00 p.m. to 4:00 p.m.. It will be followed from 4:00 p.m. to 9:00 p.m. with OMGRPNBBQ, a special barbecue party edition of Ruby Pub Nite held at Unspace’s office and rooftop deck (342 Queen Street West, a few doors over from the Rivoli).

• If you’re looking to hire people or looking for a job and want to attend, sign up here. There’s a small registration fee of $6.66.
• If you want to attend OMGRPNBBQ, sign up here.

This article also appears in Canadian Developer Connection.

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.