Jake Scruggs

Sometimes a class does too much. It's used everywhere, does everything, knows all about the nasty internals of all the other classes, and every time you change anything in the application it has to change. Or maybe you have a class that everyone loves to refactor because it's so bad. One developer changes it to be better, then another changes it to be a different kind of better, and this keeps happening without it ever getting any easier to use. There's a lot of bad reasons why a class might change all the time so I added a churn report capability to metric_fu version 0.6.0. Now you can use metric_fu to create a report like this: By issuing this command: rake metrics:churn And use the results to find classes that might have problems. It uses 'svn log' to create this report so currently you need to be using subversion. (If anyone out there want to contribute some code to get it working with git, lemme know.) The default is to start counting changes fro...

Every time I create a new rails project I usually put off writing tasks to analyze the code's quality 'cause it takes time and time is, you know, finite. So I've decided to extract some code into a rails plugin which I call metric_fu. It's a bunch of rake tasks that produce reports on code coverage (using Rcov ), cyclomatic complexity (using Saikuro ), flog scores (using Flog ), and rails stats (using 'rake stats'). It knows if it's being run inside a CruiseControl.rb build and puts the output in the Custom Build Artifacts folder so when you view a build you see this: The coverage report is your standard rcov report: Flog output is thrown into an html file: At the end metric_fu calculates the average flog score per method: You might want to check out my previous posts on what to do with a Flog report: The Method Hit List and When You Should Ignore Metrics Saikuro's output is the same as always: (I changed the warning and error levels for this pic -...

There's a bunch of places in our build where we need to execute a system command (such as running sqlplus) but often times we've found that the command fails and our build happily churns away. It's pretty easy to check the result of system command with $?.success? but we have to remember to do that everywhere... So that means it's time to extract a method. Here's what Kurtis and I came up with: module DatabaseHelper def self.command_runner(command) output = `#{command}` puts output fail unless $?.success? fail if output.include? "ERROR" output end end So you pass in a command as a string and the command runner: runs the command prints out the output fails if the return code is bad fails if the output includes "ERROR" (useful when running database imports with sqlplus) and returns the output just to be a good citizen So that's cool but when I started to write the module I thought "Hey, I can test this." Which is...