Ruby Hoedown!

Posted on August 12, 2008 by Tommy McGuire
Labels: conference, ruby
Friday, 9:00am Ruby: A Year of Innovation by Jason Seifer and Gregg

I got here a little late, and so may have missed part of the
presentation, which seemed mostly to be a long list of interesting

See (and

Friday 10:30 Cloud Computing with Ruby by Robert Dempsey.

Robert brought the message that Rails CAN scale, at both the web
service and database level, if you know how. Scalability, in this
case, means not only that the system can handle large amounts of work
but also that it can be enlarged to grow as demand increases. Cloud
computing provides that ability. Cloud computing, as defined by
Robert, requires:

A standard production deployment, according to Robert, is two load
balancers, two web servers, and two databases; this runs in the
vicinity of $432 per month.

The options Robert discussed include:

For recommendations, Robert first suggested deciding whether you are a
sysadmin or a developer; if the latter, then to go with Morph, Scalr,
or RightScale.

For more information, see Programming Amazon Web Services, REST on
Rails 2 Projects, and an AWS article series, Introduction to AWS for
Ruby Developers.

Friday, 1:00pm Mock Dialogue, Joe O'Brien and Jim Weirich

Joe and Jim gave a cute skit on the topic of mock objects and

Using mock objects (as any testing) requires require the code to be
written specifically to allow the use of the mocks. Using mocks,
however, goes further to allow tests to (in Michael Feather's rules),

Mock objects are an extension of testing fixtures such as
hand-generated stubs. Hand generated fake classes, for example, can
become as complex as the code being tested, and remedying that can
lead to a large number of testing classes. Mock objects

Just be sure not to go so crazy with mocks that you don't actually
test anything.

P.S. Ugly, difficult tests may indicate bad application code.

P.P.S. The presenters like Flexmock.

Friday, 2:15pm Ruby Best Practice Patterns by Rein Henrichs.

Rein gave a somewhat humorous song and dance about how best practices
are bad on job security grounds....

Rein described best practices as the set of techniques that experts
*currently* recognize and use, and patterns as the decisions experts
make over and over. All are learnable and optimized to communicate

The patterns Rein identified in Ruby are:

The best way of discovering patterns is to read expert's code. Also
read Smalltalk Best Practice Patterns by Kent Beck.

Friday 4:00pm Lightening talks

Friday 5:00pm Keynotes by Obie Fernandez and Chris Wanstrath

First, Obie Fernandez:

Then, Chris Wanstrath gave an inspiring keynote essay, which should be online someplace.

Saturday 9:00am Calling Your Code: Gluing Phone Calls to Ruby by Troy


Twittervox is implemented using Cloudvox and a slice from SliceHost.

Tips for building voice apps:

Saturday 10:15am Ruleby: The Rule Engine for Ruby by Joe Kutner.

Joe began with where declarative programming and rule engines fit into
the programming language landscape. He described a rule engine-based
system as made of a set of facts, a set of rules, and the Rete-based
rule engine. The separation of rules and facts centralizes business
logic knowledge.

In Ruleby, facts are Ruby objects; they become facts by being asserted
and can be retracted. The rules engine can fit effectively into Rails
applications between the controller and ActiveRecord.

Saturday 1:15pm flog <<

Working with an existing codebase is significantly different from
writing new code. One piece of advice: build a scaffold of tests
before starting to change the existing code.

  1. Survey the code: Do not get distracted by incomprehensible code.

  2. Put the commandline script under test.

    • Some code is resistant to testing: make the smallest change to
      make it testable.

    • Some code is mysteriously coupled to other code: leave pending
      markers to indicate the mystery.

  3. Put the library entry points under test.
    • "Characterization" tests - "This code does A."

    • Use CURRENTLY to mark things that may be wrong.

  4. Recursive code?

    • If faced with a "Big blob of code": carefully
      pull things apart.

    • Small commits are good, particularly for reverting.

    • At one point, he broke flog, but all of the tests pass, so he
      decided to add integration tests to act as stronger scaffolding.

  5. Pin down behavior with integration tests. (Should have done this
    • One trick: use a YAML dump to record internal behavior of

    • Use code coverage to identify parts which are not tested...and to

    • Depending heavily on attributes makes code hard to test.

I unfortunately missed the second set of lightening talks, as well as Saturday's keynote.

[Edit: Obie Fernandez is actually named "Fernandez". Sorry! Great book, by the way!]


My name is Obie Fernandez (with an 'F')... thanks for the great notes of the conference.

active directory applied formal logic ashurbanipal authentication books c c++ comics conference continuations coq data structure digital humanities Dijkstra eclipse virgo electronics emacs goodreads haskell http java job Knuth ldap link linux lisp math naming nimrod notation OpenAM osgi parsing pony programming language protocols python quote R random REST ruby rust SAML scala scheme shell software development system administration theory tip toy problems unix vmware yeti
Member of The Internet Defense League
Site proudly generated by Hakyll.