Jake Scruggs

I released metric_fu 0.9.0 last night and just look at all the super cool changes since 0.8.0: Flay task finds duplication and structural similarities in your project Reek identifies common code smells Roodi finds mistakes and troublesome code A configuration class so you can configure like the big boys Standardization of the reports look and feel Increased RSpec coverage Source control type is auto-detected for Churn task Under the hood refactoring to make adding new metrics reports easy Of course it still does all the old stuff like 2 different types of complexity reports, code churn analysis, code coverage, and good old Rails stats. Set up a Cruise Control task to generate metrics reports every day and then you pinpoint the exact moment your project went to hell (or possibly avoid that fate -- your call). Check out the project home page at: http://metric-fu.rubyforge.org/ The best part about this whole thing is that almost everything added since release 0.8 has been added by the...

I just released version 0.8.0 of MetricFu. New in this release: Source Control Churn now supports Git (thanks to Erik St Martin) Flog Results are sorted by highest Flog Score Fix for a bunch of 'already initialized constant' warnings that metric_fu caused The flog reporter can now handle methods with digits in their name (thanks to Andy Gregorowicz) Internal Rake task now allows metric_fu to flog/churn itself To use the Churn task to find files that change a lot with Git, put this in your Rakefile: MetricFu::CHURN_OPTIONS = {:scm => :git} MetricFu is a Ruby Gem that gives you a fist full of code metrics. Find out more at the home page .

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 ...

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...