Closed tansaku closed 8 years ago
@armandofox @mtc2013 I got something basic working using the following syntax:
ProjectMetric.configure do |config|
config.add_metric :code_climate_project_metrics
config.add_metric :github_project_metrics
end
This was after looking at how OmniAuth and RSpec handle their config. I'm not sure if this is ideal, but it appears to work ... have test driven this.
Have also spiked two gems to test it with:
managed to get this done on the plane - will continue knocking about next week when I get a chance - your thoughts and input most welcome ...
next step might be to get CI and integration with slack set up ...
Could also spike a Rails 5 app to use this gem ...
I'm also tempted to build out the individual gems in order to check that this gem will support the range of config that the individual metrics need - see my notes in README ...
Seems like we could use 'instance_eval' to change block scope and avoid need for config variable ...
But my current approach doesn't have advantage over pure class methods I think...
Blog articles have some interesting options ... Making a configuration class allows us to isolate configuration components, and can also pass new configuration class to yield temporary config
http://brandonhilkert.com/blog/ruby-gem-configuration-patterns/
http://www.justinweiss.com/articles/3-ways-to-configure-your-ruby-api-wrappers
http://kirillplatonov.com/2014/11/08/configure_ruby_module/
Makes me think there are several sad paths to test ...
I've updated to use the instance_eval
approach and we now have a nice clean config
I guess we would need some way to configure the gem externally to indicate which other project metric gems to pull in ... I guess passing a block to a config method or something like: