Practical Ruby Gems

TimHunter writes "I was skeptical when I first saw the title of David Berube's new book, Practical Ruby Gems, from Apress. Do Ruby programmers really need a book devoted entirely to add-on libraries? Most Ruby programmers already know about the RubyGems package management system, and most already have their set of favorite gems. About a third of the way through the book I grudgingly admitted that Rubyists might be able to use this book. After all, even long-time Ruby programmers are unlikely to know about all the gems covered in this book. So then I had a new question. Would I find something in this book that made me say 'I didn't know you can do that with Ruby!'" Read on for the rest of Tim's review. Practical Ruby Gems author David Berube pages 271 publisher Apress rating 8 reviewer Tim Hunter ISBN 1-59059-811-3 summary A survey of useful and interesting Ruby libraries Ruby is an object-oriented programming language in the same family as Perl and Python. The programming language used by Ruby on Rails, Ruby is very popular for writing web applications but also widely used for general-purpose programming tasks. Ruby is open source with a commercially friendly license, and is available for Linux, Mac OS X, and Microsoft Windows. RubyGems is Ruby's system for managing, delivering, and installing third-party libraries and applications. It is similar to Perl's CPAN or the Python Package Manager.

Libraries distributed by RubyGems are called "gems." RubyForge is the central Ruby software repository and the primary distributor of gems. According to sysadmin Tom Copeland, RubyForge currently hosts about 1400 different gems. Of that number, Berube selected 29 useful and interesting libraries for his survey of "practical" gems. All of the gems described in this book work the same on Linux, OS X, and Windows.

Practical Ruby Gems is divided into three parts. Part 1 describes the RubyGems system itself. This part explains how to install the RubyGems software and then use RubyGems to install and manage individual gems. (RubyGems is not part of Ruby's standard distribution, except in the "one-click installer" for Microsoft Windows.) The section entitled "What is require_gem?" in Chapter 3 demonstrates one of the problems with writing technical documentation for a moving target like RubyGems. Practical Ruby Gems describes RubyGems 0.9.0. After the book went to press the RubyGems team released a new version that replaced the 'require_gem' method with a method called simply 'gem'. Currently all uses of 'require_gem' generate a warning message. (The remedy for this mistake is simple: attach a yellow sticky with the words "s/require_gem/gem/g" to page 20.) This is really a nitpick, though. Generally the text and examples in the book work as well for the new release as they did for 0.9.0.

Part 2 is by far the largest and has a chapter devoted to each of the 29 gems. The chapters in this part share a common structure. After a short introduction to the gem, there is a section entitled "How Does It Work?" which explains the purpose of the gem and how it's used. Frequently this section includes a small example. "How Does It Work?" is followed by a complete example script. Then, "Dissecting the Example" steps through each part of the example, explaining how it works and pointing out important classes and methods. The examples frequently combine two or more gems, such as the example for pdf-writer, which also uses the net-sftp gem, and the example for the mongrel web server gem, which also uses the Camping web micro-framework gem.

The examples — always practical, frequently interesting, at least to a geek like me — are the heart of the book. Berube said that "no one wants to pay to read a chapter that regurgitates [the gem's built-in documentation]....I wanted to write a book that you could take the examples and actually be interested in what they accomplished." For instance, Chapter 6 describes the BlueCloth text-to-HTML conversion gem. The example in this chapter is a script that converts lightly marked-up text to PDF by combining BlueCloth with html2ps and ghostscript. Chapter 12 describes the yahoofinance gem, a library for retrieving stock quotes using the Yahoo! Finance API. The example for this library combines yahoofinance with the fxruby GUI library to produce a rudimentary stock ticker in less than 100 lines of code. (The source code for all of the examples in the book can be downloaded from the Apress web site.)

But not every example is perfect. Several of the examples rely on MySQL, which I found a chore to install. I wish Berube had chosen a simpler data base for these examples. I never did get the Camping example to run successfully. I suspect the problem was caused by some change to a gem introduced after the book went to press.

In Chapter 22 I got my "you can do that with Ruby?" moment. This chapter explains runt, a Ruby library for creating "temporal expressions," objects that describe dates that reoccur, such as "every Thursday" or "the last Thursday of every month." The example combines runt with linguistics, a small gem that extends some of the Ruby core classes with methods that support such things as pluralization and conversion from numbers to words. The result is a program that lists a set of dates expressed as "the 3rd Mondays of 2026." I was impressed by both gems, not only for the functionality they provide but by their natural and elegant interfaces as expressed in the example script. I not only learned about two very practical Ruby gems, but something about Ruby programming itself. This particular example may not strike everybody the way it did me, but I believe that most readers will find an equally pleasant surprise.

Part 3 is a tiny, advanced topics section which describes how to create and distribute your own Ruby gems and how to run a private gem server on a local network.

Practical Ruby Gems is not for the novice. Berube assumes that his reader is familiar with programming in general and Ruby specifically, and is also familiar with the operating system in which Ruby is running. This is an appropriate assumption because Practical Ruby Gems will be most useful to readers who are serious about programming Ruby, such as professionals or serious amateurs, or those would like to become professionals or serious amateurs.

Practical Ruby Gems is available in PDF format from the Apress web site at about half the price of the paper book.

I have been programming Ruby as a hobby for over 5 years. I am the maintainer of RMagick, one of the gems reviewed in this book. Apress gave me a review copy of Practical Ruby Gems, but otherwise I have no connection to the author or publisher.

You can purchase Practical Ruby Gems from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Are books like this relevant any more?

[numbsafari]

Does anyone here remember books like O'Reilly's "The Whole Internet" (http://www.oreilly.com/catalog/twi2/index.html)?

With things like blogs and wikis are dead tree versions of these sorts of catalogs really useful or relevant any more?

The debates here on slashdot rage on about global warming and being "environmentally friendly"... yet how can anyone support a book like this when it could just as easily have been published as a web page?

I stopped wasting time and money on books like this ages ago. I cannot for the life of me understand why people still bother.

Re:Are books like this relevant any more?

[numbsafari]

But this book isn't about learning the language. It's a catalog of third-party packages you can use with Ruby.

A book that documents something that isn't going to change, or develops a concept that requires more than 20 pages of text certainly deserves to be a book.

But a shopping list belongs in a PDA.

One topic I'd like to see covered.

[AltGrendel]

Installing Ruby on an Apache web server and getting it to work properly. I've seen bits and pieces all over the Ruby Forge wiki and in a ton of Google searches, but nothing that worked.

Re:One topic I'd like to see covered.

[CastrTroy]

Sign up for a hosting service that supports Ruby. While I realize the significance of doing stuff like this yourself, if you really want to just try out a language nothing will stop you quicker than not even being able to get it running. That's why when I look for a web host, I pick one that supports a lot of different technologies, even If I never plan on using them.

Re:One topic I'd like to see covered.

[AaronBrethorst]

Have you considered using Mongrel instead? It seems to signficantly less wonky than Apache when it comes to running RoR sites.

Re:One topic I'd like to see covered.

[tcopeland]

> Installing Ruby on an Apache web server and getting it to work properly.

The trick here is using Apache 2.2 + mod_proxy + Mongrel. The Mongrel book is well worth the $15, too.

Big Fat Books

[kahei]

As someone who just bought a paper copy of the Unicode 5 standard, with annexes and code charts and all, weight 10lb or so, even though it's all downloadable for free, I am really getting a kick out of these replies.

So why did I buy it? Why not read the PDFs that are thoughtfully provided free by the Unicode Consortium?

1 -- I can flip through a book in front of the TV. Not so a PDF. Yes, I have a tablet PC.
2 -- As a book, the size of the different sections is much more real to me. I know this sounds wierd but with the book I can have insights like 'boy, the addition of Cuneiform bulked out Plane 0 by *this much* that I wouldn't have with PDFs. It helps with situational awareness, I guess.
3 -- When I want to show it to someone, I go "Hey, look at this bit here in annex 15!" And they look. If I go "Hey, when we get near some wireless access, go to this site and click 'annexes' and then number 15 and it's section 13.7 near the bottom!" they ain't gonna look.
4 -- Same applies when the 'someone' is me.
5 -- I see the book, with its myriad post-it notes and bookmarks and marginalia and apprehend it as a whole. This does not happen with a website. With a website I don't even know if I've read it all.
6 -- etc etc etc ad nauseam.

Now I don't even like Ruby -- I was a big Ruby fan back in about 1998 and like many other first-generation Ruby fans I learned a harsh lesson about what happens when the whole project is dictated by one xenophobic Japanese guy. Plus as you can deduce from the above I kind of need multilingualization! But if I were still into Ruby this is just what I'd want -- a book I can just pick up off the table in front of the TV, and get an idea, and show the page to someone else, maybe even cite it later. Not a website that changes and that I have to have a computer to read and that requires instructions like 'go to this URL, click on this'. A book! That's why we have them!

It's what's for breakfast!

Re:Big Fat Books

[kahei]

Well, I didn't really mean 'xenophobic' in the KKK sense so much as in the 'Not Invented Here' sense. I really don't think /. is the place to go into agonizing detail, especially as I am kind of about to eat now. However generally at the time I was thinking of (late 90s) I found there were some disheartening things about Ruby as a project (rather than as a language):

-- Only a very small core of Japanese people who knew Matz really got to commit anything. Not in that core? No matter how great the value of what you try to commit, you might as well gived up.

-- Unicode? That's an evil anti-Japanese conspiracy. We must wait until suitable Japanese standards like konjaku mojikyo are mature enough to support. Until then Ruby has built-in support for specific Japanese encodings and the rest of the world doesn't matter. This endlessly-repeated debate partly inspired my page about Japanese attitudes to Unicode.

-- Matz used (and still uses AFAIK) Unix only. If it's part of unix (eg fork()) it's in Ruby. If it's not (eg proper threading) it's not in Ruby. Similarly, Matz is used to old-style C with global static vars all over the place, and therefore that's how Ruby is always gonna be. Having been an IT manager in Japan on occasion, I'd say it's a cultural thing that there's no point fighting. Sure, Ruby 2 is right around the corner. Sure.

-- Documentation is hobbyist-grade. I admit that while writing this post I googled a bit to check if my memories were still valid. I found that there is a project devoted to deducing the Ruby standard by experimenting with the Ruby implementation. If you can't see the problem with that... :)

Of course back in the late 90s, Ruby 2 was just around the corner and it took a long time for it to become clear that these were systemic, rather than temporary, failings. The current wikipedia page basically sums up everything I just said under 'criticism'. What it fails to mention is that these failings were a conscious decision.

Disclaimer: I was 100% observer in this process so I'm not a bitter rejected contributor. However, at that time I had high hopes that Ruby might become an industrial-strength language with threading and i18n and a proper spec and so on, and if very slowly and painfully became clear that that would never happen, which was kind of depressing.

I don't want to bash Ruby. I like ruby. I still write ruby programs. The fact is, though, ruby contains what Matz like to live with, and Matz lives in a relatively old-school world of fork()-ing single-threaded ASCII-piping unix processes with ad-hoc documentation. And any attempt (I didn't make any but I saw plenty made) to change that will be politely and apologetically totally ignored.

Now I feel a bit dirty for having made my first ever Internet post that is critical of a software project. I would like to say again that I like Ruby and it has it's place and if I were able to use ruby 'industrially' I would want a book such as the one reviewed.

Re:Big Fat Books

[Kristoph]

I can only add that given all these issues Ruby has, nevertheless, become hugely popular so I guess someone must be doing something right?

In the fullness of time, however, if Matz and Co do not meet the needs of the community someone will go off and fork Ruby, or maybe just repackage, document it etc ...

Is that not the point of open source ... ?

]{

MySQL Install made easy

[LinkFree]

"Several of the examples rely on MySQL, which I found a chore to install." For anyone out there who'd like to have MySQL, PHP, and javascript support in Apache should check out Apache Friends (http://www.apachefriends.org/en/index.html) Their xampp project, available for Windows, Linux, sparc, etc. Is easy to install, and once you've done it, it's all ready to use. Full MySQL and PHP support. I also installed their Perl addon, and so far it's all worked flawlessly.

Re:Practical RubyGems

[numbsafari]

Consider all the effort that an author puts into compiling such a book as this? Then consider the editor, the typesetter and graphic designer, the pre-press preparation, the printing, marketing and ultimate delivery of a book that is out of date as soon as the contract to even publish it has been signed.

What if the author simply kept an up-to-date web site with rankings and reviews, removing projects that have gone dead and indicating which projects simply reinvent and which projects actually move the ball forward? What if the author charged a fee for accessing the site and getting updates? Even for a measly $5 per subscriber they would make money.

Re:I like the trend of selling cheaper PDFs

[Hatta]

If I'm paying for electronic reading material, PDF is the last thing I want. PDF is for printing; if you need a hard copy just buy the book. What I want from an electronic text is device independence. PDFs are optimized for paper, it's a real bitch to page through them on a screen. I have to keep scrolling, then paging, and scrolling again, and god help me if there are multiple columns per page. HTML on the other hand works great at reflowing the text for whatever device I might be using.

Re:Perl Python?

[Fweeky]

"Ruby has one web framework"

Wha? There's Rails, Nitro, Iowa, and a bunch of smaller ones like Merb and.. meh, I forget the names. Just because we've been taken over by <troll>kiddies who love one in particular and barely even notice the rest of the community</troll> doesn't mean that's all there is.

Perl has quite a few frameworks too, I'm sure. PHP clearly isn't one, since it's nothing to do with Perl, aside from some ancient history when it wasn't even called PHP. PHP's a language, not a framework, not even to itself. If you do count PHP as a framework, the list of ones Ruby and Perl have just went up by an order of magnitude.

Re:Practical RubyGems

[tcopeland]

> the Ruby web sites are so completely littered with dead
> projects, projects that have never released code, and
> so on, not to mention rampant wheel-reinvention.

That's just the nature of open source. It takes a minute to start an open source project in Ruby or any other language - and neglecting that project take even less time. :-)

That said, if anyone has a dead project on RubyForge, put in a support request to have it deleted; keep things tidy! And I posted some notes on cleaning up live projects too. Good times.

Runt on Ruby on Rails

[duncangough]

Runt is a great library, I'm surprised it doesn't get more support. I wrote a short how-to for getting Runt up and running with Ruby on Rails: http://suttree.com/2006/08/14/runt-on-ruby-on-rail s/