Waxing Ballroom Floors on the Titanic (and Other Less Seaworthy Vessels)

Location: Portland Ballroom 253 Level: Expert
Average rating: *....
(1.90, 10 ratings)

(Note: this is more of a structured discussion than a standard moderator-required audience participation “panel”)

“…And of course, there’ll be plenty for That Guy in the 2nd row.”

This talk, like the careers of the panelists, will be a celebration, as they say, of unworkable contradictions. Metaphorically, a seasick hobo bringing the wine course. Or perhaps simply the pockets-full-of-after-dinner-mints robe-wearing NASCAR of “Best Practices” panels.

We’ve spoken at this event before, on the challenges of Rails development in the “enterprise” setting. We highlighted the systematic approach to bringing the sprawling and archaic organization gently but firmly into the hyper-present modernism of super-duper fast-paced standards-based acronym-laced two-faced myspaced(?!) Ruby on Rails web development. Our dank downstairs basement officemates are responsible for that photo of the stack of Java books we sold on eBay once we bought our two Ruby on Rails books.

We’re back with new insights, fresh scars, a healthy dose of road rash. The organization fights back. It’ll reject you like a tumor if you don’t find a way to integrate fully and surveil the organism in new and pervasive ways.

The first part of the panel, “Waxing the ballroom floors on the Titanic — Rails in the Enterprise” talks about the trials and tribulations, as the cliché goes, of bringing Rails to the enterprise, keeping it there, and fighting against overwhelming forces to make sure things are Done Right.

You’ll learn when you shouldn’t even be there, and when you should leave. You’ll learn about the place of lightweight processes. You’ll learn to fight application complexity with relentless domain-driven design and behavior-driven development. And you’ll learn to fight the GANTT chart with the CANT chart — our contribution to project management “tools”, which will tell you “who is the reason you CAN’T do what you should be doing?”. Quite possibly the single most significant development in business process engineering since Parkinson painted the bike shed.

For the practitioner who is hacking while others are playing Werewolf, we have the portion of the panel Yossef likes to call “self improvement through blaming others”, but we’ll formally entitle, “What Rails gets wrong, and when you should care”. We’re the first to admit (and one of the first to plaster non-fictional and tangible 20:1 code reduction numbers all over the Internet) that Rails is damned near a 1-click-installable chipper-shredder for the undead. But every silver bullet has a crappy cardboard carrying case, and Rails is no exception. We’ve hit the (not-so-)edge cases and found where Rails, even with the best intentions and the best plugins, falls short. There are ways forward, but the first step is admitting you have a problem. We’re not Dr. Nic’s A-Team, but we’re here to help.

Finally, the cutting edge portion of the program, “Why everyone keeps getting an STD”, delves into the seamy underworld of code that rarely sees (and probably shouldn’t ever see) the light of day. From no-test code, to assert true, to crappy we’re-testing-that-ActiveRecord-can-do-a-find-evidently “unit” tests, to test_something_that_isn’t_what_the_test_really_does, to 50+ line test methods, to 45-minute test suite runs, to converting from test/unit to test/spec or shoulda or rspec, to TDD’d code, to BDD’d code… we’re seeing it all out there. It’s uglier than Wolfman Jack’s posterior, and we’re bringing it to Portland just for you.

We’ll talk about how to fight the rats’ nest of poorly tested code. How to deal with code that’s “legacy” the instant it is written. How to work in and alongside large systems that can’t be refactored quickly. We call the process “spec-tested development” (STD) and though it looks ugly it’s often a pathway to The Cure™. We’ll introduce you to the Object Daddy, and talk about recursive mocks to help get a handle on those.egregious.principle.of.demeter.violations.that.guy.put.in.your.models.

And, for those easily bored (2nd row or otherwise), we’ve got Gary Coleman pictures.

Photo of Rick Bradley

Rick Bradley

OG Consulting

Rick Bradley was conceived a hillbilly but programmed his way out of the womb and into a lucrative position as punch-card eater at the local Burroughs plant by age 3. These days he is recently released from a multi-year sentence to work in the “enterprise” on one of the largest Ruby on Rails applications on the planet (you may remember him talking about it at the 1st Railsconf). These days he has his hitch on, his house on (which seems to involve a lot of getting his hammer on and his duct tape on), and his Ruby consulting on, as part of Flawed Logic (a wholly-pwned subsidiary of OG Consulting) for clients too distracted to know any better.

Photo of Yossef Mendelssohn

Yossef Mendelssohn

OG Consulting

(please see speaker’s bio information on other proposal)

Photo of kevin barnes

kevin barnes

OG Consulting

Bio pending

News and Coverage
co-presented by Ruby Central, Inc. O'Reilly
  • Engine Yard
  • Sun Microsystems
  • FiveRuns
  • GotThingsDone
  • Heroku
  • ThoughtWorks
  • Atlantic Dominion Solutions
  • Blue Box Group
  • CodeGear
  • E-xact
  • ELC Technologies
  • EnterpriseDB
  • GemStone Systems
  • Intridea
  • Morph Labs
  • RightScale
  • TechRepublic

Sponsorship Opportunities

For information on exhibition and sponsorship opportunities at RailsConf, contact Yvonne Romaine.

Download the RailsConf Sponsor/Exhibitor Prospectus

Media and Promotional Opportunities

Download the Media & Promotional Partner Brochure (PDF) for more information on trade opportunities with O'Reilly conferences, or contact mediapartners@ oreilly.com.

Program Ideas

Post your suggestions for speakers, topics, and activities on the RailsConf wiki or send an email to rails-idea@oreilly.com.

Press and Media

For media-related inquiries, contact confpr@oreilly.com.

Contact Us

View a complete list of RailsConf 2008 contacts.