September 5th, UtahValley.rb Hacking Night

In conversations I've had with members of Ruby Brigades around the country, I've noticed that some groups aren't having hacking nights because they don't know what to do, or they aren't sure how to start. Let me tell you a bit about what we're doing at the utahvalley.rb and the BYU-RUG. Maybe it will spawn some ideas for you and your group.

Ruby Hacking Nights really only need three things to succeed:

• A good place to meet
• A regular (advertised) meeting time
• A couple of regulars

We've managed to put these together here in Provo, and are having pretty good success.

Since we've got a University in our midst, we're using meeting space there. For our meetings, it's a classroom complete with an overhead projector and lots of seating. Our hacking nights are held in the Enterprise Computing Lab — we've got a big central table, lots of power, and Ethernet/WiFi hookups. In a pinch we can pull in a projector and screen too.

We keep to a regular schedule. The second Tuesday of every month is the BYU-RUG meeting. The fourth Tuesday is the utahvalley.rb meeting. The first, third, and fifth Tuesdays are all hacking nights. Even though we've got a regular schedule, we try to keep Rubyholic.com updated with our meeting times and places. We also make announcements to our local mailing lists.

There are three of us who will make almost every meeting and hacking night. Kevin Tew, Devlin Daley, and I. We might work on our own projects, on each others, or on planning and logistics for upcoming meetings. When other people show up, we'll often help out with their projects (either pairing with them or answering questions).

Last night (5 Sep 2006), we put all of these together and had a great hacking night with seven people in attendance:

• Kevin and I planned on doing some work on Cardinal — Kevin gave me a quick tour, then we implemented some tests and found and fixed a bug.
• Devlin wanted to touch base about next weeks meeting (the first of the new school term).
• Ammon (another old-timer) showed up to work on a recipe/menu/shopping manager that he's building in Rails.
• My son, Mike, was there working on some basic Ruby stuff (a program to manipulate the text passed in to it)
• We even had two new attendees (Chris and Tom). Tom brought a project he's working on at his day job.

Chris, Kevin, and Devlin all pitched in at various times to help Tom out, it looked like they were making some good progress. We wrapped things up with a quick discussion of next weeks meeting, and how to get the word out to new CS students on campus.

Ruby Hacking Nights are a great way to strengthen your Ruby Brigade, and to help local rubyists get together to improve their Ruby skills. They're easy to run and attend. When's your next Ruby Hacking Night?

Reading a New (to me) Blog, and a Ruby Love Fest

I think I've found a new favorite blog ... But Uncle Bob. I know, I should've been following it more closely all along — but I've just caught the bug recently.

Believe it or not, my interest was piqued by a recent non-Ruby post he made (about profiling before optimizing), not his recent spate of pro-Ruby posts.

In fact, he's quite pro-Ruby recently, check it out:

The energy and creativity in the Ruby space is enormous. It makes the Java/.Net space look stodgy by comparison. This energy and creativity has traditionally been the precursor to the revolutions that have taken place in our industry. — Joel on Ruby

---

95% of all web applications probably could, and should, be done in Ruby now. — Joel on Ruby

---

(In a comment about refactoring in Ruby) I was able to break through the fear and start refactoring. And, so far, it really hasn't been very difficult. I've been able to keep my tests passing without any horrible hicoughs. But, WOW, the backpressure in my own head was astounding. — Refactoring Paralysis

---

I also noticed a couple of Dave Astels quotes in the comments of Refactoring Paralysis that just add to the pro-Ruby current that flows through that page:

Don't get me wrong.. I'm a huge fan of refactoring tools in Java and C#. I'm just not convinced they are needed as much for Ruby. They would be useful ... but it's not as important as some people think. And it wasn't that long ago that I was one of those people.

---

I find myself refactoring in Ruby as fluidly using TextMate as I did with Eclipse or IDEA in Java.. moreso maybe because it's faster...

---

Working in Ruby is fundamentally different at a philosophical level.

Mmmmm, I love the smell of a Ruby love fest.

New Series at O'Reillynet Ruby Blog

Based on a discussion over at the Ruby web page redesign mailing list, I've started a new series of articles over at O'Reilly's Ruby blog. I'm posting spotlights on Ruby libraries and applications. The first one is the Spotlight on Glark by Martin DeMello.

If you've got a favorite library or application and you'd like to see it highlighted at O'Reilly's Ruby blog, write up a spotlight and send it to me. I'll work with you to get it into shape to be published, then post it for you. You'll get fame and glory (well, a little bit), the spotlighted project will get some publicity, and the Ruby blog readers will learn about something new and useful to them — everybody wins.

New RubyCorner . . . Oooh, Shiny!

After several weeks of work, the folks over at RubyCorner.com have released their new version. I've been lucky enough to see it while they worked through the final stages of development and designt, and I've got to say — I like it.

The new look is both nicer, and easier to read (at least to my eyes). I also enjoy the new blog language listing and language filtering features. Since I'm working on improving my German and Spanish, it's easy for me to watch just the blogs in those languages and in English. (Nothing against anyone blogging in another language, it's got not very accessible to me.)

If you're a blogger or blog reader, with an interest in the Ruby community you should sign up at RubyCorner. It's a nice little system that's getting better.

Code Coverage is Evil . . . Eh, Not So Much

"[T]he concept of a coverage report is itself fatally flawed" wrote John Casey in his blog post Testing: Coverage Reports Considered Dangerous. Deborah Hartmann was a bit less over the top in her follow up post Code Coverage Stats Misleading. These blog posts decrying code coverage have it wrong, but they do contain a grain of truth. Let me touch on some of the points I think deserve another look.

The Problems

John was working on a large refactoring of Maven, and was relying on code coverage reports to let him know how complete his tests were. He wrote:

I had nearly perfect coverage numbers on the parts I felt were critical - not on constructing exceptions where the constructor consists of super( message, error ), mind you - and felt fairly confident that this plugin would almost drop in as a replacement of the old incarnation. As a first test, I attempted to create the assembly for Maven itself, at which point the whole plugin fell apart. After battling several NullPointerExceptions, I finally managed to build this fairly straightforward assembly, but by this time I was badly shaken. I had the coverage numbers, but I was starting to see that they weren't telling me the whole story.

John's real problem wasn't that the code coverage reports were wrong, just that he was looking at them for the wrong information. Like checking your tachometer to see how fast you're going. Coverage reports can't tell you what is tested, just what's not tested.

Having hit a significant failure with code coverage, John wen on to say:

"Bumping the progress bar of your coverage report up to account for a line of code which has been touched by one test is a fatally flawed concept, and it can lead to misperceptions on the parts of managers and developers alike"
"the worst thing you can do is to look at a test coverage report"

One of Deborah's commenters wrote: "We consider those test results internal to our development team and actually never show them to management or clients.".

Really though, the problem here isn't that the coverage results are wrong or misleading. Just that they're misleading, especially in isolation. (Deborah herself pointed this out. Coverage results are important, but only for telling your part of what you (and your management and clients) need to hear.

"The sky is falling!" Well, okay, no one actually said it. Just for the record, it's not true either.

A proposed solution

There is some hope though. If we think about our tests in terms of expected behavior, as per BDD, we'll be a lot better off. Using this approach, we can write our tests around the specification (so that we know we're covering our desired functionality and the (documented) edge cases. With good reports, used in conjunction with code coverage reports, we can show ourselves (and others) that we're testing the code's expected functionality and ensuring that we're not leaving code paths uncovered. (By the way, code coverage reports can also show us dead code hiding in our projects, see my article at Linux Journal for an example of this).

speaking of nice reports, I showed off the RSpec html test report at RubyConf*MI. It got great reviews. If you're interested in trying out BDD, RSpec has a lot of upside. I'd love to see this kind of report built from test/unit output as well.

On a related note, I don't think any set of unit tests (TDD or BDD) is going to catch all the bugs that lurk in our code. Gregory Brown had some good advice about this that didn't make it into our recent interview: "[W]rite tests to reproduce any bug reports [you] have. This seems to be a solid way to improve test coverage, and avoid the problem of recurrent bugs.".