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.

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.

Platform wars are like monkey knife fights: amusing at first, but regrettable and messy in the end.

You don’t see this very often, and it’s a shame: Jacob Kaplan-Moss, co-creator of Django, the Python-based MVC web application framework, wrote a great article titled Thank You, Rails. From the article’s opening paragraph:

It’s fashionable, or perhaps inevitable, for tech communities to trash their competition…We geeks make arguing over minor technical points into a kind of art.

The most important point in his essay is a few paragraphs down. He points out that while having a competitor often lends focus to a developer community and that a rivalry can often bring about excellence among all parties concerned, it can also bring bitterness and nastiness. He wants to counter those latter things, and so he writes:

I think it’s important to recognize that we in the web development community do in fact owe Rails and the Rails community a debt of gratitude. Rails helped reframe the way we think about web development, and even those who’ve never touched Rails nevertheless are probably reaping indirect benefits right now.

So I think we should all step back from our personal preferences and plainly say thank you, Rails, for all that you’ve done to move the state of web development forward.

Rails was a wake-up call to the web development world in so many ways. In the short time – a mere five years — that it’s been around, it’s been responsible for many changes in the world of web applications:

• Popularizing MVC amongst web developers. Yes, it had been done before, but never quite as elegantly or explained so clearly.
• Bringing concepts like DRY and Convention Over Configuration into the developer vernacular.
• Proving that simplicity is a feature, whether it’s from the developer’s or end user’s point of view.
• Pointing the spotlight at the Ruby programming language.
• Driving a movement towards web applications with both beautiful and usable interfaces.
• Reminding us that programming should be fun.
• Reinforcing an important idea that we often forget: community matters. (If you’ve been to a RailsConf or better still, RubyFringe and FutureRuby, which takes the Ruby/Rails community camaraderie and turns the dials up to 11, you know what I mean.)

Speaking as a Microsoft guy, I too would like to say “Thank you, Rails”. While I can’t honestly classify myself as ever having been a serious Rails developer – it’s mostly noodling on personal projects and one major cancelled project at Toronto’s worst-run startup – I come from the periphery of the Rails community, having been an unofficial evangelist and occasional court jester, as evidenced in this performance from the evening keynotes at RailsConf 2007:

I take a lot of what I’ve learned from the community-building effort that made Rails what it is today and have applied it to my work at Microsoft. From what I’ve been hearing, it seems to be helping.

It’s not just the community aspects of Rails for which both Microsoft and I owe Rails a debt of gratitude — there are the technical aspects as well. I’m sure the event-driven desktop-style development metaphor behind ASP.NET makes a lot of developers happy, but it drove me bonkers – and also to PHP (and eventually, Rails) — back in 2002. The drive to create an MVC web application framework that treated the web like a first-class citizen instead of “like the desktop, but lamer” led to the creation of my preferred Microsoft web framework, ASP.NET MVC, and I cannot begin to convey how grateful I am for that. I love ASP.NET MVC, and a good chunk of the reasons why stem from the Rails-isms that found their way into it. I think ASP.NET MVC developers would benefit from getting to know Rails and taking it out for a spin – and I think the Rails developers would also gain something from giving ASP.NET MVC a try.

I once read a saying that has stuck with me all these years: “When you slice a blade of grass, you shake the universe.” Yeah, it’s a pretty drama-queeny way of saying that everything is interconnected, but it’s true in many respects, including human endeavour, which in turn includes software development. It’s an ecosystem, and different parts of it influence each other all the time. I think that the best participants in that ecosystem learn from other parts, and acknowledge those efforts that make the ecosystem a better place in which to live.

So to echo a Django guy’s sentiment, here’s a Microsoft guy saying it: Thank you, Rails.

This article also appears in Canadian Developer Connection.

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.

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

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.

Here’s a still from what I assume is a propaganda film from World War II titled Rails to Victory. If any of you are planning to do presentations covering the topic of Rails and are looking for some graphics for your slides, you might want to consider this one:

Click the photo to see a larger version.
Photo courtesy of Miss Fipi Lele.

I got a number of books for free this past week:

• Head First PMP – When my friend Leigh Honeywell heard that I was taking a project management course later this month, she told me that she got this book for free at a conference and had no use for it. So she gave this book to me, and I’ll be reading it so that when the course comes around — it’s May 21st through 23rd — I’ll be at least familiar with the material.

And four books from Apress, courtesy of Julie Miller:

• Pro PHP: Patterns, Frameworks, Testing and More
• PHP Objects, Patterns, and Practice, Second Edition
• Practical Web 2.0 Applications with PHP
• Practical Reporting with Ruby and Rails

I’ll be reading them this month and posting my reviews here in Global Nerdy. Watch this space!

Next Tuesday is the second Tuesday of the month, which means: Ruby/Rails Project Night, hosted by TSOT!

The Quick Version

• When: Tuesday, February 12th, 2008:
  • Doors open around 5:30 p.m.
  • Presentations begin sometime between 6 – 6:30 p.m.
  • Arrive early to get fed!
• Where: TSOT developer office, 151 Bloor Street West (just east of Avenue Road), Suite 1130
• Admission: FREE (but please register!)
• Register with: Corina Newby or Joey deVilla

About Ruby/Rails Project Night

Ruby/Rails Project Night is a Toronto-area gathering held at the TSOT developer office on the second Tuesday of every month. It’s an event that lets people developing projects in either Ruby or Ruby on Rails show them off in front of their peers in 20-30 minute presentations. Presenters are encouraged to go into as much technical detail as they like (even showing the code, if they’re so inclined) and cover all sorts of aspects of their projects, from programming issues to visual design and usability to the business of making a living off their software.

Whether you code in Ruby and Rails for a living like we do, dabble in it in your spare time or are just curious as to what the fuss is all about, we encourage you to come to our office next Tuesday for Ruby/Rails Project Night! It’s a chance for you to see software that’s being developed right here in town and to mingle with other developers interested in Ruby and Rails. We provide food and drink, so you can focus on the presentations and not your grumbling stomach.

Who’s Presenting

Yours Truly will start the night with an opening monologue to get things going, after which I’ll be followed the the evening’s main presentations:

• How to Avoid Hanging Yourself in Rails, by Rowan Hick. This presentation is subtitled “or: Optimizing Your ActiveRecord Associations”.
• EasyBrandingTools.com: Mike Bowler and Steve Vetzal will talk about their project that helps new businesses be memorable.
• CRMS – Clinical Research Management System. Luke Galea will present this project, a Rails and Prolog/XSB application that manages drug and procedure trials at some of the biggest hospitals in the U.S..

What Happened at the Last Ruby/Rails Project Night?

Click the photo to see it on its Flickr page.

Check out this article, which has a quick write-up and photos.

Default Routes Considered Harmful, and Other Rails SEO Tips covers SEO for Rails apps, with both on-page SEO tips (Prettier URLs, Better Title Tags and DRY in Content) and off-page SEO tips (Easy Linking and Bookmarks).

Just got the email: early bird registration for RailsConf 2008 (which is $100 cheaper) is now open. When I was working a nice big company like Tucows, they’d foot the bill, making the decision a no-brainer. Now that I’m at TSOT, which is a start-up, we don’t have those budgets and now I have to think about the bang-per-buck ratio. Are you going, and what factors are you taking into account?

I’ve been quite impressed by the “Addison-Wesley Professional Ruby” series of books (I’ve got The Ruby Way and RailsSpace) as well as the work of series editor Obie Fernandez, whom I had the pleasure of meeting at RailsConf 2006. That — along with glowing reviews for both books plus my serious immersion into Ruby and Rails at TSOT — is why I’ve got Design Patterns in Ruby and The Rails Way on order. I’m looking forward to getting my paws on these books, and I’ll post reviews shortly afterwards.

(I’m normally pretty conservative when it comes to spending on computer programming books for the past little while, but that’s because evangelism rather than programming has paid the rent. That situation has changed somewhat.)

Both Design Patterns in Ruby and The Rails Way are in Antonio Cangiano’s set of recommended Ruby and Rails books. If you’re looking to get into either Ruby or Rails (or if you’re already into either and just looking for related reading material), check out his list.

Tonight is TSOT’s first monthly Ruby/Rails Project Night, where we invite the local developer community into our offices to see presentations on Ruby and Rails development and socialize. We’ve got a great lineup of speakers:

• Yours Truly, on the lessons and challenges of Zed Shaw’s rant
• Andrew Burke on the business and technical aspects of his current Rails project
• Hampton Catlin on Ziplocal.com
• Mike Ferrier on The Score’s iPhone application

The event will take place at TSOT’s office — 151 Bloor Street West (on the south side, just east of Avenue Road), suite 1130. The doors open at 5:30 p.m., during which time we’ll serve food. Presentations start at 6-ish, with breaks in between and some time for socializing afterwards. Admission is free, but space is limited — to register, please email joey.devilla@tsotinc.com.

The blogger at willcode4beer says in 17 Thousand Reasons I’m not a Ruby on Rails Developer that the median salary of Rails developers is on average $17K less than that for J2EE developers. I’m not worried — the pay at TSOT for RoR development is on par with the J2EE rates cited.

The article also suggests that “to bring salaries up, they need to drop the ‘easy’ part. Development is hard, and no language or platform is going to change that. We solve complex problems. Complex problems are hard to solve. period. They should focus on the productivity gains in the areas where Rails shines, and try to avoid the areas where it doesn’t.”

The resemblance is uncanny, isn’t it?
Zed Shaw photo by Adewale Oshineye — click the photo to see it on its Flickr page.

By now, most Rails developers — and even a number of people who couldn’t care less about Rails — have read Zed Shaw’s infamous rant titled Rails is a Ghetto. It’s given me a lot to think about, and as a result, I’m changing my presentation topic at Tuesday’s TSOT Ruby/Rails Project Night to Rant Said Zed: I’m Too Sexy for my Rails (or: Lessons and Challenges from Zed Shaw’s Rant). I promise that it’ll be both informing and entertaining.

• Want to know more about Tuesday’s TSOT Ruby/Rails Project Night, which takes place this Tuesday, January 8th? See this entry.
• Want to sign up? Email me!

Aside: A Quick Trip Down Memory Lane

How can I reference Right Said Fred without showing you the video for their one hit?

If you’ve been following the usual programmer and tech new sites, you’ve probably read (or at least heard of) Zed Shaw’s rant, titled Rails is a Ghetto. If you haven’t read it yet, go there now, give it a quick read and come back. I can wait.

High-spirited stuff, isn’t it? As you might expect, there have been a number of interesting responses to Zed’s polemic, but only one made me laugh out loud — it’s this entry in Jesse Stay’s blog:

Ruby on Rails is weak right now, it’s breaking apart from the inside. Now is the time for the Perl community to show its strength and unite in an effort to make Perl once again the most used platform on the web!

Perhaps it’s time for Larry Wall to update his maxim about the great virtues of a programmer: it should now be laziness, impatience, hubris and revenge fantasies.

Today marks the start of my fourth week at TSOT, a Toronto-based startup that develops custom social networking software in Ruby on Rails. The company’s first two products are FraternityLive and SororityLive, which as you might imagine are targeted at fraternities and sororities, with future plans for creating similar apps for other fields.

I was hired primarily for my tech evangelism cred and broad development experience (Visual Basic, Python, PHP, Director and Java from the rough-and-tumble Java 1.2 days) rather than for experience with Rails, on which I’d done only a little spare-time noodling. This means that a good chunk of my time during this first month on the job has been split between getting familiar with Rails as well as TSOT’s apps.

Just before my first day at TSOT, I went down to Boston to join my in-laws for American Thanksgiving. While there, I decided to take advantage of the strong Canadian dollar and Thanksgiving weekend sales to do a little job-related book shopping. Although I had the PDF edition of Apress’ Practical Rails Social Networking Sites, I was pleased to stumble across another book on building social networking apps in Rails: Addison Wesley’s RailsSpace: Building a Social Networking Site with Ruby on Rails. I figured that if I find a book that covers the sort of development work that I’m about to start, I should buy it on the spot (after a quick skim of the book while in the store, of course).

Of all the books I’ve read on Rails development, this one’s my current favourite. Yes, there’ll always be a special place for Agile Web Development with Rails, but I have to say that I like the pacing, ordering of topics and the presentation of material in RailsSpace a little bit better. I like the way that authors Michael Hartl and Aurelius Prochazka take a slightly different approach to teaching Rails, from going with a social networking app rather than a “store” app to their clever visualization of Rails’ directories as a pie chart, shown below:

Graph adapted from RailsSpace
and borrowed from Weblog of Fernando Reig Matthies.

So take it from a guy who’s paying his rent by working on Rails social networking apps: if you have some development experience under your belt and are looking to pick up Rails in a hurry (or if you’re looking for a gift for someone who needs to learn Rails in a hurry) I recommend:

• Picking up a book on Ruby (because you need solid Ruby fundamentals to really write good Rails code — I’ll talk about my favourite Ruby books later)
• Picking up RailsSpace: Building a Social Networking Site with Ruby on Rails

Here’s what other folks have to say about the book:

• Review at Amazon.com by Charles Harvey: My favorite of the Ten Ruby and Rails Books on my desk — “The authors’ programming style(s) are easy to read while following and teaching the Ruby/Rails community practices. The book uses output examples after each snippet of code so you can follow along not wondering if what you just did worked.

  The example app you produce while working through RailsSpace is not YASNS (Yet Another Social Networking Site) rather a (LBERBPS) Learn by Example Rails Best Practices Site. It was fun for me as I was tired of shopping cart, and book/music store examples.

  I don’t know how to put it into to the right words, but this books code flows.

  I always enjoy the rare book that sets a standard of excellence, and that is what puts this book at the top of my Ruby on Rails Library.”

• myCATs: An excellent Rails tutorial for the intermediate Rails Programmer — “This book is just plain fun. As the title implies, the focus is on building a social networking site using Ruby on Rails. The depth of knowledge of the authors, Michael Hartl and Aure Prochazka, is evident right from the first chapter. The examples are relevant and well explained, with clean, consice, well-tested and correct code.”
• Nate Klaiber: RailsSpace review — “I may seem cynical about social networks, but this truly book pays attention to the small details. Building a social network is a great tutorial that covers many aspects of Rails and building your own application – no matter what it is. It has several callout boxes that give more explanation where it is needed. It discusses the importance of testing. It shows the importance of refactoring. All of this comes together to make a great reading experience and knowledge gained. If you are a Rails professional, there might not be a whole lot new for you, but if you are just beginning Rails this is an excellent full-blown tutorial. Even if you don’t want to create a social networking site, the foundation and principles set in this book will give you the knowledge needed to start building your own application.”
• ComputerWorld: RailsSpace hits the Ruby on Rails learning sweet spot — “…if you’re already a proficient OOP developer — or a beginner who prefers learning by example — RailsSpace offers useful insight into what the Ruby on Rails hoopla is all about.”
• A.P. Lawrence: RailsSpace — “I liked also that the project paid attention to both looks and ease of use without clouding up with too much detail. The design is simple, but with enough attention paid to presentation to understand how to accomplish that in ROR, and the same is true for niceties like data validation: they do enough to show the concepts without burying us in it.

  The authors also included deliberate mistakes – that is, design deficiencies which you might notice before they get around to pointing out the problem. That’s good too, because often the best way to understand why you need to do something this way is to see what happens when you don’t.”

• WebChicanery: RailsSpace – The Book — I’m somewhat skeptical of these “build a project and learn” type of book, but this book may be one the the handiest book on Ruby that I’d had a chance to read. The authors approach it was a very pragmatic and structured standpoint, all while explaining some neat steps and additions they’ve thrown in along the way.”