Jake Scruggs

So there have been a bunch of metric_fu releases since I announced 1.0.0 on this here blog. It's now up to version 1.1.4 and we've added: Flog, Flay, Reek, Roodi, and Rcov now have graphs over time (thanks Édouard Brière ). Cool, dare we say 'Awesome,' templates for the metrics (thanks Nick Quaranto and Edouard Brière). Flog report now tracks average Flog score per method and the average of the worst 5% of your methods. MetricFu now works with Ruby 1.9.1 (thanks to Robert E. Rouse for his help). On to the pics: Homepage Google Group Github Repo Enjoy!

I went to the first ever ORD session last night sponsored by Inventables and Google Chicago and worked on some metric_fu stuff. The idea of the ORD sessions is that there's a lot of open source developers in the Chicago (ORD is the O'Hare airport code) area so why not get them together to hack on some stuff. I'd say over 20 people showed up and had a great time. It didn't hurt that every one who came got an unlocked google phone as a free surprise gift. When they announced, earlier in the evening, that there would be a surprise we all thought: "Oh cool, I'll probably get a t-shirt or a squishy ball." So the phone sort of blew us away. As to metric_fu, Jeff from Inventables and I paired on a new meta metric called "Flurn." It's a combination of FLog and chURN and it tells you about files that not only are very complex but also change all the time. This is pretty bad because if the file is in constant flux and it's got a lot of ...

I spent the week doing an iteration zero for new project. The idea behind iteration zero is to get the development environment as automated as possible so developers can spend their time coding when the real development begins. So here's what we did: 1. Set up new git repository We use GitHub so that only took a few minutes. 2. Make new Rails app Again, just a few minutes 3. Set up geminstaller and basic gems (HAML etc.) Geminstaller installs gems needed by the project and makes sure they are there before starting the app. This functionality has been pulled into modern versions of Rails now, but I've found it a little wonky and I'm working with a former Pivotal Labs guy who just loves the Pivotal stuff (don't even get him started on Tracker vs Mingle ). 4. Set up developer tests. We looked into Shoulda , but ultimately went with RSpec (although we may use the Shoulda macros to test ActiveRecord) because most of the criticisms of RSpec are th...

Last night I chose quantity over quality and ate at a Brazilian steak house. Good times. Webrat: Rails Acceptance Testing Evolved Bryan Helmkamp (weplay) Bryan started out his presentation by handing out Tylenol for those who went out last night and Budwiser for those who didn't. The crowd was appreciative. Bryan show some typical Rails integration testing (simulating clicking through the app without opening up the browser) and compared it to the same test in Webrat. The difference between the integration test and the webrat enabled test was pretty dramatic. The Webrat test was much cleaner and easier to read. Webrat parses the returned html with Nokogiri (which he highly recommends) and so can do some pretty interesting stuff. click_link, fill_in, check (and uncheck), choose, select, attach_file, and click_button all have a simple syntax. Webrat automatically is checking for the success of the request so you don't have to assert success everywhere. It also verifies t...

What's new: Merged in Grant McInnes' work on creating yaml output for all metrics to aid harvesting by other tools Supporting Flog 2.1.0 Supporting Reek 1.0.0 Removed dependency on Rails Env for 3.months.ago (for churn report), now using chronic gem ("3 months ago"). Almost all code is out of Rakefiles now and so is more easily testable Metrics inherit from a refactored Generator now. New metrics generators just have to implement "emit", "analyze", "to_h" and inherit from Generator. They also must have a template. See the flay generator and template for a simple implementation. You now define the metrics you wish to run in the configuration and then run "metrics:all". No other metrics task is exposed by default. Full documentation, as always, is at: http://metric-fu.rubyforge.org/ Let the Google group ( http://groups.google.com/group/metric_fu ) know about any bugs you find.

I really should have done this a long time ago, but you know how it goes. Anyway, if you're using metric_fu and have a question or want to discuss it's direction/development you can now here: http://groups.google.com/group/ metric_fu There's some big changes on the horizon for metric_fu -- If you want to get a preview, head over to github and take a look at the to_yaml branch of metric_fu. I've been pulling in Grant McInnes changes to be able to serialize the output of all the metrics. This means that there will be a yaml file created after each run which can be used by other projects. A number of people have asked for this feature so they can do analysis of their metric data. However, this will probably break some uses of MetricFu as it is an almost complete re-write. What's cool about this branch (besides the output) is that almost nothing is in rakefiles anymore and so is more easily testable. If you use metric_fu and have an opinion on this, or anything ...

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 .

Something I didn't mention when I announced the re-launch of metric_fu as a gem is that now, because it's a gem, you have more options when installing it in your project. First option: Vendor Everything . Lots of people are big fans of unpacking gems into the vendor directory of their Rails project (or a similar folder in a non-Rails project) so that everyone who checks out the code gets the right version of the gem. You can then require it in your Rakefile like this: require 'vendor/gems/jscruggs-metric_fu-0.7.6/lib/metric_fu' However... Second option: Conditionally require the gem. When I announced metric_fu back in April, a lot of commentors bemoaned the fact that they would have to install something into their production code that wasn't really necessary for production. I don't really mind doing this as metric_fu does not modify any classes: It's mostly just a bunch of Rake tasks (and some report building code). However, I see their point. So if...

I just released version 0.7.6 of metric_fu and there's all sorts of new stuff: First, MetricFu is now a Ruby gem on GitHub at: http://github.com/jscruggs/metric_fu Also, the Flog task can now flog any set of directories you like. Just put this into your Rakefile: MetricFu::DIRECTORIES_TO_FLOG = ['cms/app', 'cms/lib'] And, the Flog reports are much nicer: The Flog report generator now looks at a MD5 hash of the files its examining to determine if they files need to be re-Flogged -- which saves time. The Saikuro report generator can also look at custom directories like so: MetricFu::SAIKURO_OPTIONS = {"--input_directory" => '"cms/app | cms/lib"'} MetricFu started its life as a Rails Plugin, but I'm trying to turn it into a flexible gem that can be used in any Ruby application (but still have defaults that enable easy use in a Rails project). Eventually I'd like to create something that could tell you about methods that have hig...

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

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