| You won't learn Ruby from this book. There is relatively little in the way of introductory or tutorial information. If you are totally new to Ruby, I suggest you start with another book. Having said that, programmers are a tenacious bunch, and I grant that it might be possible to learn Ruby from this book. Chapter 1, "Ruby in Review," does contain a brief introduction and some tutorial information. Chapter 1 also contains a fairly comprehensive "gotcha" list (which has been hard to keep up-to-date). The usefulness of this list will vary widely from one reader to another because we cannot all agree on what is intuitive. This book is largely intended to answer questions of the form of "How do I…?" As such, you can expect to do a lot of skipping around. I'd be honored if everyone read every page from front to back, but I don't expect that. It's more my expectation that you will browse the table of contents in search of techniques you need or topics you find interesting. Some areas this book covers are very elementary. That's because people vary in background and experience; what is obvious to one person may not be to another. I have tried to err on the side of completeness. On the other hand, I have tried to keep the book at a reasonable size (obviously a competing goal). This book can be viewed as a sort of "inverted reference." Rather than looking up the name of a method or a class, you will look things up by function or purpose. For example, the String class has four methods for manipulating case: capitalize, upcase, downcase, and swapcase. In a reference work, these would quite properly be listed alphabetically, but in this book they are all listed together. Of course, in striving for completeness, I have sometimes wandered onto the turf of the reference books. In many cases, I have tried to compensate for this by offering more unusual or diverse examples than you might find in a reference. I have tried for a very high code-to-commentary ratio. Overlooking the initial chapter, I think I've achieved this. Writers may grow chatty, but programmers always want to see the code. (If not, they should want to.) The examples here are sometimes very contrived, for which I must apologize. To illustrate a technique or principle in isolation from a real-world problem can be very difficult. However, the more complex or "high level" the task was, the more I attempted a real-world solution. Therefore, if the topic is concatenating strings, you may find an unimaginative code fragment involving "foo" and "bar", but when the topic is parsing XML, for example, you will usually find a much more meaningful and realistic piece of code. This book has two or three small quirks to which I'll confess up front. One is the avoidance of the "ugly" Perl-like global variables such as $_ and others. These are present in Ruby, and they work fine; they are used daily by most or all Ruby programmers. However, in nearly all cases, their use can be avoided, and I have taken the liberty of omitting them in most of the examples. Another quirk is that I avoid using standalone expressions when they don't have side effects. Ruby is expression oriented, and that is a good thing. I have tried to take advantage of that feature. However, in a code fragment, I prefer not to write expressions that merely return a value that is not usable. For example, the expression "abc" + "def" can illustrate string concatenation, but I would write something like str = "abc" + "def" instead. This may seem wordy to some, but it may seem more natural to you if you are a C programmer who really notices when functions are void or non-void (or an old-time Pascal programmer who thinks in procedures and functions). My third quirk is that I don't like the "pound" notation to denote instance methods. Many Rubyists will think I am being verbose in saying "instance method crypt of class String" rather than saying "String#crypt," but I think no one will be confused. I have tried to include "pointers" to outside resources whenever appropriate. Time and space did not allow putting everything into this book that I wanted, but I hope I have partially made up for that by telling you where to find related materials. The Ruby Application Archive on the Web is probably the foremost of these sources; you will see it referenced many times in this book. Here, at the front of the book, is usually where you'll find a gratuitous reference to the typefaces used for code and how to tell code fragments from ordinary text. However, I won't insult your intelligence; you've read computer books before. And now a word about personal pronouns. Here in the introduction, I've used the singular first person consistently, but throughout most of the book, I've used we, in the manner of kings and editors. This is not (just) my pompous nature revealing itself; it's a very real concession to the fact that a little over 10 percent of this book was written by other people. (Most readers skip the acknowledgements in a book. Go read them now. They're good for you, like vegetables.) | 
