The Gemcutter's Workshop
It has been another big bi-week, and the pace of the Ruby community is accelerating. The ruby-talk and rails mailing lists are full to overflowing, the ruby-core mailing list is quite active, project announcements seem to pop up on a daily basis, and new resources seem to appear overnight. It's an exciting time to be involved with the language.
Perhaps the biggest news of this bi-week is that Ruby will be represented in this year's Google Summer of Code. RubyCentral has stepped forward to act as an umbrella organization for Ruby mentors and students. A number of interesting-looking proposals already have been put forward. If you're interested in being a mentor or working on a project, you should head over to their Summer of Code page (www.rubycentral.org/soc2006) and see what's involved.
Eli Bendersky published a nice overview of blocks, procs and methods on his blog (eli.thegreenplace.net/2006/04/18/understanding-ruby-blocks-procs-and-methods). He said he felt like he didn't really understand them, so he set off on a voyage of discovery. Fortunately, he took good notes so the rest of us can follow along. Kevin Tew also went on his own trip through blocks and closures, and left notes for us on his blog (blog.tewk.com/?p=62). Between Eli and Kevin, we've got a pair of nice resources to help figure out closures, blocks, procs and methods, oh my!
James Gray put together a great post about Unit Testing in Ruby. It ended up being too long for his blog, so he posted it here: grayproductions.net/ruby/first_steps.html. James not only covers the basics of testing (and makes a strong case for doing it), but he describes the use of Mock objects quite well. If you're not a Unit Tester already, or if you're just a beginner, go read his article right away. If you've been testing for a while, it's still worth a read.
After two months of hard work, the LibXML team has cut a new release of the libXML bindings for Ruby. This library provides super fast, very functional tools for working with XML and XSLT. Although the library had stagnated for a while, the project seems to have been rejuvenated after a call for developers went out several months ago. The future looks promising for this project.
Hot of the heels of Canada on Rails, the Ruby and Rails communities gathered for the Silicon Valley Ruby Conference. This was more of a grass-roots activity, but it still pulled in some great speakers. A number of attendees provided coverage, among them were:
Ryan Davis (who also spoke): blog.zenspider.com/archives/2006/04/sdforum_group_n.html.
ones, zeros, majors and minors: ozmm.org/svrc.
In general, it sounds like this was a great conference. It's something more Ruby Brigades (or Groups, or Meetups or whatever you want to call yourselves--I prefer Brigades, so I'll stick to that) should look into. Whether you've got a strong group (like the Seattle.rb or NYC.rb), several groups in proximity (like the groups in Michigan or New England) or have a conference organizer nearby (as happened with the Vancouver Ruby Users Group and Canada on Rails), getting a regional conference together can be a great way to build Ruby awareness in your area.
One tantalizing rumor to emerge from the conference is that there's a book in the works on building Domain Specific Languages in Ruby from the Pragmatic Programmers (www.pragmaticprogrammers.com). If true, this should be a great book to add to your Ruby collection.
Speaking of building Ruby awareness, the NYC.rb is doing something a bit off the beaten track; they're hosting a Ruby job fair at one of their upcoming meetings. They've sent out invitations to businesses to come and make a short presentation about their needs and then occupy a table where they can meet with hopeful Ruby hackers. This sounds like another idea that could be copied to good effect in your Ruby Brigade.
Whether you run a Ruby Brigade, or are looking for one near you, you should check out www.rubyholic.com. This site provides a free tool for organizing and scheduling for Ruby Brigades everywhere. (It's also a nice example of Test Driven Development--Ryan Davis and Eric Hodel didn't look at it in a browser until they released their beta, they relied completely on their tests to make it work right.)
This time around, I thought I'd spend a bit of time talking about RubyGems--what they are and how they're used (both from a user's and developer's perspective). Although not everyone agrees with their implementation, RubyGems (or just Gems) have changed the way Ruby is used. And, because Rails has adopted Gems for its primary distribution system, Gems are pushing their way further into Ruby.
For the user, Gems are a great way to install and manage Ruby tools and libraries. gem is the command-line interface for working with Gems and allows you to perform a variety of tasks. Each Gem is a tarball containing two files: data.tar.gz and metadata.gz. data.tar.gz is a tarball of the library or tool. metadata.gz is a YAML file describing the library or tool and explaining how to install it.
For developers, Gems are a convenient way to package and distribute their Ruby projects. They ensure a common install, can set dependencies and provide a cross-platform package for users.
Everything you do with RubyGems (except using them) is done with the gem command. The general form of the command is:
gem <COMMAND> <options>
The help command is very useful and can be used three ways:
gem help commands: this version lists all the commands available.
gem help <COMMAND>: shows specific help for COMMAND.
gem help examples: gives several examples of Gem use.
There are also three general options that will be useful to you:
-p, --[no-]http-proxy PROXY: enables (or disables) an HTTP proxy for all remote operations.
--source URL: sets an alternative source for remote commands (allowing you to use a local archive).
--config-file FILE : sets an alternative config file.
To install a gem that you've already downloaded, you can do:
gem install checkr-0.1.0.gem
If you don't already have the gem downloaded (and normally, you won't), you can install the gem from the repository like this:
gem install zentest
Installing a package may entail installing dependencies as well. For example, the webgen package requires the cmdparse package. Installing it looks like this:
gem install --remote webgen Attempting remote installation of 'webgen' Updating Gem source index for: http://gems.rubyforge.org Install required dependency cmdparse? [Yn] Successfully installed webgen-0.3.8 Successfully installed cmdparse-2.0.1 Installing RDoc documentation for webgen-0.3.8... Installing RDoc documentation for cmdparse-2.0.1...
A number of options can be passed into the gem command. The most useful are:
-v, --version: lets you specify a specific version of gem to install.
-l, --local: restricts the operation to local gems only.
-r, --remote: restricts the operation to remote gems only.
-b, --both: allows you to operate on both local and remote gems.
-i, --install-dir DIR: forces the gem to be installed in a nonstandard directory.
-d, --[no-]rdoc: enables (or disables) the installation of documentation for the gem.
-t, --[no-]test: This enables or disables the running of unit tests on the gem you're operating on prior to installation.
Although there are some packages that people already know they want to install (Rails, ZenTest, Rake and so on), a lot of hidden gems exist too. You can get a listing of all the gems with the list command. At its simplest, it looks like this:
This displays only the local gems though; the -l, -r and -b options shown for the install command work with the list command too, so a more useful form might be:
gem list -r
You can narrow your search results further by specifying a string that appears at the beginning of the gems' names (this string is case-insensitive):
gem list -r Ruby
If you use RubyGems frequently, you may find that you collect a lot of older versions of some gems. The cleanup command can help with some of your housekeeping here. For example, on my system, I have three versions of ZenTest and two each of RubyInline, Rake and ParseTree. Because I need only the latest, I can run:
and get rid of the clutter. As most people are a bit leery of removing a bunch of libraries blindly, gem cleanup takes a -d (or --dryrun) option, which shows you what it would delete instead of actually deleting it. On my system, it looks like this:
gem cleanup -d Cleaning up installed gems... Dry Run Mode: Would uninstall ZenTest-3.0.0 Dry Run Mode: Would uninstall ParseTree-1.3.7 Dry Run Mode: Would uninstall RubyInline-3.4.0 Dry Run Mode: Would uninstall ZenTest-3.1.0 Dry Run Mode: Would uninstall rake-0.7.0 Clean Up Complete
Because this is what I expected, I can go ahead and run the cleanup without any further concerns.
If you want to learn more about RubyGems, you should take a look at the RubyGems Web site (docs.rubygems.org).