GemStats.org - Help the Ruby community collect stats on library usage(gemstats.org)
gemstats.org
GemStats.org - Help the Ruby community collect stats on library usage
http://gemstats.org
4 comments
I just posted the latest State of the Stack for Ruby.
http://blog.newrelic.com/2011/09/28/state-of-the-stack-a-rub...
It has: - A breakdown of ruby versions - A chart showing the changes to ruby versions deployed since Rails 3 came out - A breakdown of rails versions - A breakdown of ruby dispatchers - The top 50 gems and top 50 plugins
http://blog.newrelic.com/2011/09/28/state-of-the-stack-a-rub...
It has: - A breakdown of ruby versions - A chart showing the changes to ruby versions deployed since Rails 3 came out - A breakdown of rails versions - A breakdown of ruby dispatchers - The top 50 gems and top 50 plugins
Looking forwards to the 1.8 vs 1.9 usage on production sites.
Very cool, looking forward to it :)
They're asking the questions:
I don't see how this will indicate the quality or popularity of a Gem.
A more sound approach may be to spider RubyGems.org, look at the "source code" link, check out the repo, and start doing stuff like look at test coverage, amount of documentation, etc. If the gem source code is on github, you could probably get some idea of the quality based on some metric around the number of followers they have, etc.
--
Edit: I didn't realize they wanted just the Gemfile.
As for the down votes: I'm not sure how this is "FUD". I question the methodology, to which the author responds below. We're all smarter for seeing that.
* Company type
* Team size
* Hosting environment
* Other languages your company has been using ruby
* Years your team has been using ruby
I don't see how this will indicate the quality or popularity of a Gem.
A more sound approach may be to spider RubyGems.org, look at the "source code" link, check out the repo, and start doing stuff like look at test coverage, amount of documentation, etc. If the gem source code is on github, you could probably get some idea of the quality based on some metric around the number of followers they have, etc.
--
Edit: I didn't realize they wanted just the Gemfile.
As for the down votes: I'm not sure how this is "FUD". I question the methodology, to which the author responds below. We're all smarter for seeing that.
First off, they are asking for your Gemfile, not your .gem. There is a big difference here. There is no source code in a Gemfile. Secondly, they clearly state why this is an indication of popularity-- they are getting real world usage statistics, not download counts. They ask for company info because if a company the size of 80 people uses a gem, it's going to effectively be more popular than a company of size 1. 79 more people are using it.
Please stop spreading the FUD.
Please stop spreading the FUD.
Parent comment is FUDish, definitely, but he has a few points.
If the stated aim is popularity measurement, asking for those other things is disingenuous. Want to identify trends? That's ok, but say that's what you're doing.
Secondly, it really is a lot of effort for probably not a lot of great results. Mostly it will suffer from extreme self-selection bias. Further, the site says that "the stats on RubyGems.org...are a weak indicator of gem popularity amongst Rails apps"—that might be true, or it might not be. Regardless, it's some sort of indicator. But beyond that, most of the gems people use are open source: demonstrably good popularity indicators already exist in the form of Github watchers, forks, commits, commit activity, issue reporting, mailing list throughput, etc.
If the stated aim is popularity measurement, asking for those other things is disingenuous. Want to identify trends? That's ok, but say that's what you're doing.
Secondly, it really is a lot of effort for probably not a lot of great results. Mostly it will suffer from extreme self-selection bias. Further, the site says that "the stats on RubyGems.org...are a weak indicator of gem popularity amongst Rails apps"—that might be true, or it might not be. Regardless, it's some sort of indicator. But beyond that, most of the gems people use are open source: demonstrably good popularity indicators already exist in the form of Github watchers, forks, commits, commit activity, issue reporting, mailing list throughput, etc.
There are multiple reasons why we chose the approach we did:
1.) It was easy to implement, we're just parsing using Ripper
2.) It gets us 90% of the way there. There are some last-mile stats that would be interesting. But implementing those take a lot of effort. This is something we threw together over the weekend.
3.) We're interested to see if there are trends in gem usage amongst company types/sizes/years of experience.
4.) Asking people to give access to their git repos is asking quite a bit. We try to maintain anonymity (although we are geocoding IPs on the backend). TBH, if someone asked me for access to my company's private repo I would say 'no'
Thanks for the feedback. :)
1.) It was easy to implement, we're just parsing using Ripper
2.) It gets us 90% of the way there. There are some last-mile stats that would be interesting. But implementing those take a lot of effort. This is something we threw together over the weekend.
3.) We're interested to see if there are trends in gem usage amongst company types/sizes/years of experience.
4.) Asking people to give access to their git repos is asking quite a bit. We try to maintain anonymity (although we are geocoding IPs on the backend). TBH, if someone asked me for access to my company's private repo I would say 'no'
Thanks for the feedback. :)
It would be nice if you published the results of your data, too? Unless that is forthcoming.
I'm not into giving away my data if I don't get some feedback.
I'm not into giving away my data if I don't get some feedback.
Yes, as mentioned on the site, the whole idea behind this is to publish the results. Otherwise there's no value! Can't blame you one bit :).
Would it be possible to create a gem so one could just include stats gathering in their gemfile?
eg.
eg.
gem "gemstats"This is only our first pass. We have discussed the next version which should be passive. Either plug in some analytics directly to Gemfiles or have a post-commit hook to submit the Gemfile when it changes.
It would be great if we could look at Gemstats.org and instantly see stats without having to go through the upload process.
It would be great if we could look at Gemstats.org and instantly see stats without having to go through the upload process.
We included information on Ruby version, Rails version as well as popular gems and plugins.
You can see previous stats here: http://railslab.newrelic.com/
I'm working on publishing the next report, which should be out this week.