MetricFu, The Development Continues
77 views
Skip to first unread message
Benjamin Fleischer
Jan 3, 2013, 5:06:22 PM1/3/13
to metr...@googlegroups.com
Hi all, I'm Benjamin Fleischer, the new 'Lead Developer' for metric_fu's continued development.
I created a new github organization 'metricfu' such that the project is now located at https://github.com/metricfu/metric_fu . It is now the official metric_fu repo.
It contains patches that I've manually applied from the original jscruggs/metric_fu pull requests and issues, as well as subsequent work that I've done trying to improve 1.9 and 1.8 compatibility and well as some structural reorganization in an attempt to isolate dependencies and narrow the interfaces. I've also released an updated version of roodi and make fork and update some other dependencies. I'm also contacting some of the maintainers of the dependencies, e.g. churn, about updating their dependencies. This is just the beginning.
I put 'Lead Developer' in quotes above because it's a volunteer position I have assumed by forking Jake's branch, doing some work, and discussing reviving the project with him. MetricFu, as an open-source project is really owned by the community, so if you would like to get involved in helping to maintain it, there are many ways to help, and I encourage you to help out. I'm just a guy with commit access currently pushing a bunch of code to the project.
How can you help? Submit pull requests to improve external or internal documentation, update the website, report bugs, fix bugs, help keep track of the issues and pull requests queue, submit pull requests for code in your fork that you think could be helpful, or get involved in the discussing the future direction of the project, from short range compatibility to longer-term goals and milestones.
My hazy vision for the future:
Better isolate each metric, and modularize them in a conventional way such that they can easily be turned on and off, even with 3rd party gems or code. But, to stabilize the current feature-set before starting off in a new direction, if possible. My vision could probably use a few more eyes. (and ears, mouths, etc).
About me:
I'm a Ruby (mostly Rails) dev of 3 or so year who loves refactoring code. I work at MrSkin.com (you may know of it from such films as 'Knocked Up'). I can be contacted at bfleische...@gmail.com and g'chatted at bflei...@gmail.com . My github username is 'bf4'. I am now learning a lot about the differences in how a gemspec manages dependencies and bundler, and then how that affects the behavior of a gem executable. (It isn't pretty).
So, take a look at https://github.com/metricfu/metric_fu and thanks for all, and submit an issue and/or pull request
-Benjamin
p.s. I imported the issues from Jake's repo, which resulted in what looks like a lot of recent issues added by me. In actuality, most of them are probably old and invalid. I point it out because it looks confusing.
I created a new github organization 'metricfu' such that the project is now located at https://github.com/metricfu/metric_fu . It is now the official metric_fu repo.
It contains patches that I've manually applied from the original jscruggs/metric_fu pull requests and issues, as well as subsequent work that I've done trying to improve 1.9 and 1.8 compatibility and well as some structural reorganization in an attempt to isolate dependencies and narrow the interfaces. I've also released an updated version of roodi and make fork and update some other dependencies. I'm also contacting some of the maintainers of the dependencies, e.g. churn, about updating their dependencies. This is just the beginning.
I put 'Lead Developer' in quotes above because it's a volunteer position I have assumed by forking Jake's branch, doing some work, and discussing reviving the project with him. MetricFu, as an open-source project is really owned by the community, so if you would like to get involved in helping to maintain it, there are many ways to help, and I encourage you to help out. I'm just a guy with commit access currently pushing a bunch of code to the project.
How can you help? Submit pull requests to improve external or internal documentation, update the website, report bugs, fix bugs, help keep track of the issues and pull requests queue, submit pull requests for code in your fork that you think could be helpful, or get involved in the discussing the future direction of the project, from short range compatibility to longer-term goals and milestones.
My hazy vision for the future:
Better isolate each metric, and modularize them in a conventional way such that they can easily be turned on and off, even with 3rd party gems or code. But, to stabilize the current feature-set before starting off in a new direction, if possible. My vision could probably use a few more eyes. (and ears, mouths, etc).
About me:
I'm a Ruby (mostly Rails) dev of 3 or so year who loves refactoring code. I work at MrSkin.com (you may know of it from such films as 'Knocked Up'). I can be contacted at bfleische...@gmail.com and g'chatted at bflei...@gmail.com . My github username is 'bf4'. I am now learning a lot about the differences in how a gemspec manages dependencies and bundler, and then how that affects the behavior of a gem executable. (It isn't pretty).
So, take a look at https://github.com/metricfu/metric_fu and thanks for all, and submit an issue and/or pull request
-Benjamin
p.s. I imported the issues from Jake's repo, which resulted in what looks like a lot of recent issues added by me. In actuality, most of them are probably old and invalid. I point it out because it looks confusing.
Jake Scruggs
Jan 3, 2013, 5:50:28 PM1/3/13
to metr...@googlegroups.com
Just chiming in to say thanks to Benjamin for taking over the managing of this project from me. I'm still on the mailing list and may help out from time to time but not to the degree I did before.
-Jake
Rich Morin
Jan 3, 2013, 6:11:36 PM1/3/13
to metr...@googlegroups.com
On Jan 3, 2013, at 14:06, Benjamin Fleischer wrote:
> Hi all, I'm Benjamin Fleischer, the new 'Lead Developer' for metric_fu's
> continued development.
Congratulations or commiserations, as appropriate. Regardless, thanks!
> Hi all, I'm Benjamin Fleischer, the new 'Lead Developer' for metric_fu's
> continued development.
For some time, I have been interested in the idea of running metric_fu
in some sort of "continuous harvesting" fashion. That is, download gems
and such, run metric-fu on them, and save the results in a database.
Could you answer a couple of questions about the current state of affairs,
to help me understand the difficulties and risks?
* In general, do the tools provide machine-friendly output formats
(eg, JSON, XML, YAML), in addition to human-readable reports?
* In cases where metric_fu is doing dynamic analysis of running code,
is there any way to protect the harvesting system from broken or
malicious code?
-r
--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume r...@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841
Software system design, development, and documentation
Benjamin Fleischer
Jan 4, 2013, 5:48:00 PM1/4/13
to metr...@googlegroups.com
Replies below
On Thu, Jan 3, 2013 at 5:11 PM, Rich Morin <r...@cfcl.com> wrote:
For some time, I have been interested in the idea of running metric_fu
in some sort of "continuous harvesting" fashion. That is, download gems
and such, run metric-fu on them, and save the results in a database.
This is currently being done by the codeclimate.com project (e.g. see https://codeclimate.com/github/metricfu/metric_fu ) and was done by the now defunkt Caliper project (by devver folks).
You might want to take a look at e.g. https://devver.wordpress.com/2009/10/27/improving-code-using-metric-fu/ and watch a still-relevant talk Jake gave a year or so ago http://vimeo.com/20544748
Could you answer a couple of questions about the current state of affairs,
to help me understand the difficulties and risks?
* In general, do the tools provide machine-friendly output formats
(eg, JSON, XML, YAML), in addition to human-readable reports?
Metric_Fu generates yaml data in the local ./tmp folder unless configured otherwise
* In cases where metric_fu is doing dynamic analysis of running code,
is there any way to protect the harvesting system from broken or
malicious code?
From what I've seen in the codebase, this could only occur while running the tests for rcov etc. There are some ruby sandboxing tools I found when researching your question: https://github.com/tario/shikashi , https://github.com/omghax/jruby-sandbox
Hope that helps
-Benjamin
Dan Mayer
Jan 5, 2013, 6:10:58 PM1/5/13
to metric_fu
I worked on this back in my days with Devver, it can definitely be a bit interesting to have all of that data to crunch over time. Right now codeclimate is definitely the best version of that sort of tracking. Code Climeate doesn't use metric_fu directly but utilizes many of the same underlying tools as metric_fo.
I agree with Benjamin that test coverage is the only part of metric_fu which executes code. Nothing else would need to be sandboxed.
peace,
Dan
--
You received this message because you are subscribed to the Google Groups "metric_fu" group.
To post to this group, send email to metr...@googlegroups.com.
To unsubscribe from this group, send email to metric_fu+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/metric_fu?hl=en.
Reply all
Reply to author
Forward
0 new messages