Roadmap; where is metric_fu going?

[Benjamin Fleischer]

I'm thinking of organizing the various TODO items into a roadmap, to help sort out what needs to be done, from what could be done, and what should be done.

e.g. There was recently an issue created to add the turbulence gem.  Right now I'd prefer to continue to focus on cleaning up the metric_fu code, fixing it, and making it 'pluggable'.  

I think that what metrics to include and how is ultimately a bigger and important question than how to clean up the code.   Should we replace churn with turbulence? Should we replace cane with rubocop?  Should we add brakeman? What should be the 'core' metric tools and what should be options?  And how can we improve guidelines of how to understand the metrics we generate?

Thoughts? Interest in getting involved in putting together a roadmap?  

Here's a wiki page https://github.com/metricfu/metric_fu/wiki/Roadmap and here's the list of TODO items https://github.com/metricfu/metric_fu/blob/master/TODO.md

-Benjamin

[Robin Curry]

Agreed. +1 for focus on cleaning up and making it pluggable. I think making it 'pluggable' makes the 'what metrics to include?' question pretty much go away, right? (Or at least changes the nature of that question.)

[Brian Johnson]

Is this question still being actively explored? I was building a metric gem and found metric_fu, but it doesn't include security or style metrics (aside from the extremely basic rules in Cane). So I'm still going to have to wrap metric_fu with Brakeman and Rubocop to get the coverage I want. It would be fantastic to have those integrated with Metric_fu's graphing functionality.

[Benjamin Fleischer]

Yes, we hope to stabilize the metric api soon.  It's theoretically possible to plug a metric in now, but probably not worth the effort.  That's what this WIP PR is about https://github.com/metricfu/metric_fu/pull/139  

--
You received this message because you are subscribed to the Google Groups "metric_fu" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metric_fu+...@googlegroups.com.
To post to this group, send email to metr...@googlegroups.com.
Visit this group at http://groups.google.com/group/metric_fu.
For more options, visit https://groups.google.com/groups/opt_out.

[Benjamin Fleischer]

 I wanted to update y'all on the progress of metric_fu to 5.0 and being pluggable, as well as fish for your thoughts and assistance.

I'm sending this email less complete than I'd ideally like it to be, else I might not send it for even longer :) Please ask questions where unclear. (And I know it is, in parts)

1. Should metric_fu just pass through options to the metric it runs? 

   e.g. https://github.com/metricfu/metric_fu/blob/master/lib/metric_fu/metrics/flog/init.rb#L8
   i.e. align the run_options keys with flog option keys
2. Where should metric config files go?
   e.g. have a per-metric config  such as config/reek.yml in devtools? how should we work with devtools? https://github.com/rom-rb/devtools 3.  Related to #1 and #2, be able to specify
     - external config files via the command-line,
     - the .metrics file location, via the command-line, if necessary (depends on #2)
     - a global .metrics file in the home directory?  (Windows-friendly)
4. re: metric responsibilities, autoloading, and file/folder structure

  -Once PR 139 is complete, the loading responsibilities of metric_fu will be something like this on require 'metric_fu':

  in the loader.setup load

    1. the logger
    2. the MetricFu::Configuration
    3. the MetricFu::Metric
    4. the generator, perhaps renamed to runner
    5. The Reporter which loads the Formatter
    6. The Result aggregation class (do we even need this?)
    7. The metrics included by metric_fu
    8. Metrics included by external options e.g. see this spike https://gist.github.com/bf4/6592ea3da5ea8e00f396#file-loader_setup-rb-L24

    9. The Rake tasks if Rake is required

5. Responsibilities

  - MetricFu::Metric - superclass of all metrics, including hotspots.  It knows how to enable (run?) the metric, activate its depdendent libraries, if is graphed, loads its grapher

  - MetricFu::Grapher - if metric is graphed, how to graph it

  - MetricFu::Hotspot - how to weight metric

  - template for outputting the metric, html, yaml, json, etc

6. Directory structure and base classes

   lib/metric_fu/metric.rb 

   lib/metric_fu/reporter.rb

   lib/metric_fu/formatter.rb 

   lib/metric_fu/metric_grapher.rb - was known as lib/metric_fu/reporting/graphs/grapher.rb

   lib/metric_fu/graph.rb - (graph generator) was known as lib/metric_fu/metrics/graph.rb

   lib/metric_fu/metric_runner.rb  - now known as lib/metric_fu/metrics/generator.rb

   lib/metric_fu/template.rb  - or perhaps templates/template.rb  - now known as lib/metric_fu/metrics/base_template.rb

   lib/metric_fu/hotspot.rb - not the hotspot metric, but the hotspot analyzer (which each metric also subclasses)

   lib/metric_fu/metrics/example_metric/{config.rb,runner.rb,grapher.rb,hotspot.rb,template.rb(not erb!)}

   misc to be considered

   lib/metric_fu/{logger.rb,io.rb,configuration.rb,environment.rb,formatter.rb,loader.rb,result.rb,utility.rb,gem_run.rb,error.rb}

   remove lib/metric_fu_requires.rb or at least use rubygems see https://gist.github.com/bf4/6731278#file-read_deps_from_gemspec-rb-L3

For more code samples and other notes, please see https://gist.github.com/bf4/6592ea3da5ea8e00f396

- Benjamin

[Daria Mehra]

Allow me to chime in on #1 and #2 since they caused me most pain as a new user of metric_fu. 

1. Should metric_fu just pass through options to the metric it runs? 

   e.g. https://github.com/metricfu/metric_fu/blob/master/lib/metric_fu/metrics/flog/init.rb#L8
   i.e. align the run_options keys with flog option keys

My vote is YES! Figuring out the mapping from the metric's settings (eg: Cane) to metric_fu's was non-trivial. If they are aligned, it also eliminates the need to document metric_fu's options - just refer the user to the manuals for metrics it runs. Then metric_fu's own configuration can be limited to --enable|disable <metric_name>.

 

2. Where should metric config files go?
   e.g. have a per-metric config  such as config/reek.yml in devtools? how should we work with devtools? https://github.com/rom-rb/devtools 3.  Related to #1 and #2, be able to specify
     - external config files via the command-line,
     - the .metrics file location, via the command-line, if necessary (depends on #2)
     - a global .metrics file in the home directory?  (Windows-friendly)

I felt the need to have a configurable location for .metrics file (or, if per-metric config files are to be used, then configurable directory where they all live). The reason is that I'm integrated with Jenkins, and currently if I want Jenkins to see my .metrics file, I have to commit it to my project's git repository. I prefer to keep non-production code separate (in this case, I'd put .metrics in a different repo altogether, if I could) but I have to tell Jenkins where to look for the file. Either command-line option, or home directory solution would work for this setup. 

I haven't used devtools so no opinion on that. Could you point me at a doc explaining what devtools are for? The github page told me how to install them but not what they do. Thanks!

-- daria.

[Rich Morin]

Apologies if this is already the case, but I would like all of the MF
plugins to have a mode in which they emit machine-friendly (eg, YAML)
output to a specified file path.

-r

--
http://www.cfcl.com/rdm Rich Morin r...@cfcl.com
http://www.cfcl.com/rdm/resume San Bruno, CA, USA +1 650-873-7841

Software system design, development, and documentation

[Benjamin Fleischer]

On Sun, Dec 22, 2013 at 4:56 PM, Rich Morin <r...@cfcl.com> wrote:

Apologies if this is already the case, but I would like all of the MF
plugins to have a mode in which they emit machine-friendly (eg, YAML)
output to a specified file path.

Robin?