How This Book Works
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.)
|
