gnuu.org

.spaced li { margin-bottom: 15px; }

A couple of days ago I published an analysis on the usage data provided by NewRelic and GemStats.org which showed that real world usage does not seem to correlate with gem download counts provided by RubyGems.org (or watchers/forks on Github). This generated a fair bit of feedback from people who were skeptical of the results. This article briefly attempts to address some of the questions and concerns people are having with the analysis.

Update 10/21/11: See the explanation of why the download count might be such an unreliable indicator of popularity, read Why are the Numbers So Whack? Plausible Explanations for Crazy Gem Download Counts

Update (Jul-25-2011): I fixed the “clear launchpad” command to properly remove any empty folders and reset the page count, since some users reported that it was leaving some folders lying around.

I just installed Lion today, though I had been using the Developer Previews for a while now. I like Lion, but some things irk me. I’ve compiled a list of tips that I use to make my experience more sane, most specifically, clearing the list of apps in Launchpad (which I couldn’t find discussed anywhere else).

Today I released YARD 0.7.0, you can install it with:

$ gem install yard

As always, documentation can be found on the site at http://yardoc.org

YARD 0.7.x has a feature on the table called macros. This allows developers documenting code to very quickly create documentation templates for repetitive DSL methods. The more trivial part of macros is that YARD will now detect any DSL method with a docstring attached to it and automatically turn it into an instance method, using the first parameter as the method name. Obviously this is not always what you want, so macros can be even more powerful and allow for arbitrary expansion of any of the method call parameters.

A few days ago I had a discussion on twitter with @jacobian (Jacob Kaplan-Moss) about the supposed implicit failure of using auto generated documentation tools in Ruby; RDoc, YARD, and the like. The originating quote was from Jacob based on his talk at Github’s recent CodeConf (transcribed by @titanous):

I have just released the "Ripper" library as a gem on Rubygems. It is available here and is meant for Ruby 1.8.x users only. Ruby 1.9 users already have Ripper packaged with their stdlib, so they don’t need to install this. This release is a backport of Ripper to Ruby 1.8.x and enables the library to work in pre-1.9 MRI. Ruby 1.8.x users can install it as:

$ [sudo] gem install ripper

An example usage of ripper is:

Giles just wrote a post regarding the "private" keyword’s "unprofessionalism" (I’m having Christian Bale flashbacks) that included a conversation we had on Twitter. Unfortunately, Twitter isn’t exactly a great medium for expressing complex thought, so I figured I’d elaborate the issue a little bit without phrasing things for a 140-character limit.

Are we really writing "dynamic" programs, or are we just trying to avoid writing down all those type signatures?

I’m currently doing research for a survey on [program] verification and testing in dynamic languages in order to find out what information is out there about verifying program correctness in languages like JavaScript, Python, and Ruby. I’ve made a few discoveries. If you saw me tweeting the following, you saw what I discovered: