Better late than never, here are some thoughts from the erubycon conference in Columbus Ohio.
First of all, what a great conference. The talks were great and the
hallway interactions were excellent. Glenn Vanderburg’s talk on
“Enterprise, Schmenterprise” hit the nail on the head. (paraphrased
soundbite: “The Enterprise it not ready for Ruby, it is desperate
Testing, Testing, Testing
But the theme that kept coming back to me over and over again from the
conference was testing: unit testing, integration testing, UI testing,
all of them. Stu Halloway’s talk on the “Refactoring of the Week”
emphasized the importance of tests to enable refactoring. In
addition, Stu made a strong pitch for getting 100% code coverage in
the projects you are working on. In selecting code to be refactored
for his talks, he would just zero in on any code reported not covered
by RCov and start looking there for fruitful refactoring possibilities.
So, the moral of the story is that if you have 100% code coverage,
then Stu has to work a bit harder to find examples for his refacting
I was inspired by Stu’s talk so I went back and checked all my open
source projects to see how well they were covered by tests. I’m happy
to say that both flexmock and builder are now at 100% and only needed
a little tweeking to get that last percent or two. (Except for the
CSS builder … we really need to finish that class or dump it).
The main library file of Rake is now at 100%. It was in the mid 90s
when I check and needed some attention to get it the rest of the way.
So that is good.
The unfortunate part is that there are some pieces of Rake that are
not well covered. First there are a number of deprecated libraries
that aren’t at 100%, and since people shouldn’t be using them, I’m
more likely to remove them entirely than to write tests for them.
Second, the are some Rakefile tasks that are not adequately covered.
I’m not sure how to address this for Rake tasks tend to be very
involved in the environment you are working in, making it tedious to
mock. I’d love to make the testing of Rake tasks easier, so fee free
to make suggestions.
As for RubyGems … I’d rather not talk about the code coverage stats
on that one.
So, I’m making RCov a part of my standard Rakefile setup and will
start running it more religiously to keep those code coverage numbers
Emacs … We’re not dead yet!
I can’t really call it a “theme” of the conference, more like a strong
undercurrent. There was certainly a number of programmers attending
who use Emacs for their day to day editting, even when programs like
TextMate are available. While emacs is a strong editor for a wide
number of programming languages, its support for Ruby and Rails is
lagging behind some of the more recent editors that are targetting
Ruby specifically (e.g. the aforementioned TextMate). A group of us
holdouts got together and shared some tips and tricks on bringing
Emacs closer to the state of the art in Ruby support. I’ll share some
of those tips here in the near future.
Going into this conference, I heard the organizers swear they were
never doing this again, but the the end everyone was enthusiastic
about next year. So, who knows, if you’ve missed this year’s
erubycon, you might get a chance to join us next year.