Hacker News Reader

Comment by bradgessler | Hacker News Reader

They're asking the questions:

  * Company type
  * Team size
  * Hosting environment
  * Other languages your company has been using ruby
  * Years your team has been using ruby

and asking for a manual upload of the gem.

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.

View on HN

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.

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.

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

Reply on news.ycombinator.com