I'll be Presenting at Windy City Rails

If you're going to be in the Chicago area on or about Saturday, September 20th, you can see me give my "Using Metrics to take a Hard Look at Your Code" talk at the Windy City Rails Conference. David Heinemeier Hansson, David Chelimsky, and Noel Rappin have been announced as speakers and I'll be joining them for a interesting day of Rails related goodness.

Here's the abstract:

It's an interesting fact of human nature that you can't do something every day and not secretly suspect that you're good at it. Which goes a long way toward explaining why everyone thinks they write fine code. To combat this self-delusion you can use metrics to take a hard look at your application. This talk will discuss the ways in which you can measure how good your Rails project really is. And how to fix the bad parts.

Using a daily metrics build (run every day by CruiseControl.rb) you can compile a 'hit-list' of the worst methods in your application. Then your team can spend some time every iteration trying to refactor these methods.
In my talk I will discuss 4 tools to identify problems:

* Code coverage with Rcov
* Cyclomatic complexity with Saikuro
* Flogging with Flog
* Using source control to figure which files change the most

All of which are pretty easy to use, especially if you use metric_fu -- a Rails plugin (blatant plug). Once you've figure out where the badness is, you must fight it. While showing examples, I'll be discussing:

* Why 90% (or even 100%) test coverage isn't a silver bullet against bugs.
* How Saikuro and Flog measure complexity and the advantages of each.
* When complexity is OK
* Why 'inject' sucks, except when it's pretty cool (see above point).
* Strategies for figuring out if your fancy metaprogramming is worth the extra complexity and what to do if it isn't.
* What is good enough coverage.
* Failing your build on poor metrics numbers.
* Why you should always remember Carlin's law:
"Have you ever noticed that anybody driving slower than you is an idiot,
and anyone going faster than you is a maniac?"

Comments

Post a Comment

Popular posts from this blog

What's a Good Flog Score?

I've been using Flog to measure the complexity of my Ruby code and I was wondering how others interpret Flog numbers. I'll go first with my opinions: Score of Means 0-10 Awesome 11-20 Good enough 21-40 Might need refactoring 41-60 Possible to justify 61-100 Danger 100-200 Whoop, whoop, whoop 200 + Someone please think of the children (note: these are scores for an individual method) The 20 - 60 range is interesting to me. Sometimes the complexity of what you're doing will justify the score and other times the method is in desperate need of refactoring. The highest Flog score I've seen in the wild was in the 300's. What's you're personal high and what do you think of my rankings? In other news, I've redesigned the look of my blog so if you only see my post through a reader you might want to stop on by, take a look, and tell me what you think.
Read more

SICP Wasn’t Written for You

The number of software luminaries who sing the praises of “ Structure and Interpretation of Computer Programs ” (referred to as SICP) is such a long list that you might think only a crazy person would take issue with it. However, to ignore SICP’s problems and continue to blindly recommend it seems just as crazy. SICP was the textbook for MIT’s introductory programming class and was a bit of a departure from other into to computer science textbooks at the time.  Wikipedia sums it up nicely:  “Before SICP, the introductory courses were almost always filled with learning the details of some programming language, while SICP focuses on finding general patterns from specific problems and building software tools that embody each pattern.”  Which sounds awesome, but does essentially say that abstract principles will be introduced before the nuts and bolts of a language.  If you think about that for a minute, you may see where the problems will be. When I was training to be a...
Read more

Point Inside a Polygon in Ruby

Recently my team needed to find out if a point was inside a given polygon and, as usual, we found some code on the internet that did what we wanted. And, as usual, there wasn't much explanation as to what it was doing. Here's the code (after we converted it to Ruby): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 def contains_point? (point) c = false i = -1 j = self .size - 1 while (i += 1 ) < self .size if (( self [i].y <= point.y && point.y < self [j].y) || ( self [j].y <= point.y && point.y < self [i].y)) if (point.x < ( self [j].x - self [i].x) * (point.y - self [i].y) / ( self [j].y - self [i].y) + self [i].x) c = !c end end j = i end return c end end So, you know, it works and I'm grateful to somebody for posting it but we had no idea how it works. So we wrapped 2 tests around it (one where the point is not in the polygon and another where it is...
Read more