As my Ruby experiences are measured in months rather than years at this point in time, more information is always better than less. And I have always been a sucker for a nice heavy book to keep beside the keyboard. 

The Ruby Way.

Basically this book is a list of common and not so common tasks and code snippets to show you how to handle them in Ruby. Another way to look at it is this book is basically the logical reverse of the language API. Rather than look up a method and find out what it does, you look up a task and it tells you the method. This can be very, very handy.

Ruby is a concise language with many excellent one liners. In the core classes, however, there are often a large number of methods. String is one good example, there is something like 100 methods in the class and I have, more than once, accidentally re-implemented one of them while trying to solve a problem. This is mainly due to simple lack of experience with the language. Now that I have a copy of this book, if I get the feeling that maybe Ruby has something built in to solve problem A, I can look up problem A and find out if there is a one liner rather than writing some custom method.

Even in my relatively small projects, this book has already saved me a handful of hours. Currently I am reading through the book, random chapters at a time. The main goal I have now is to build an internal catalogue of problems that this book solves so I can remember to reference it if those problems crop up. Shortly after I use a method a couple of times, then it is part of the repotoire and I won’t need to look it up again.

So, in a nutshell, if you need a good book to learn to make your Ruby more concise and make better use of the language, go with this one.

The difficulty is that there are only so many programming books that are truly classics. While I appreciate and enjoy learning from well written Hibernate or book on the Google Web Toolkit, ultimately, any software book that starts to discuss a specific framework will quickly become obsolete. As one of my personal definitions of classic is a book that does not grow old with time, this means that a huge percentage of mass market “Learn how to gidazzle with widget fooxily” types of books will never reach the classic status.

Unfortunately, it seems that the dominant type of programming book that is on the shelf in your local bookstore are exactly the ones that will be out of date in a couple of years. This makes me somewhat sad as if the market is for books that quickly go obsolete, the number of people that will write books that go on to be classics will be smaller simply on a basis of supply and demand. I’m not sure where this leaves us. I like buying technology of the month books as well, so I help this. All in all, it’s likely not a problem I suppose. I guess I just wish I could actually find Peopleware or the Mythical Man Month in print on a shelf somewhere.

So now I reach the real crux of the matter. If you are reading this, then you probably read other blogs by various guys in the software industry and they already have pretty much written about the books that you absolutely should read. More, most of you have probably read some of the books that Joel or Jeff have suggested in the past. So I’d simply be duplicating content listing the exact same classic books and suggesting that a serious programmer should read them.

So this has all been a debate as to whether or not to do that. You see, I actually enjoy reading reading lists, especially if there is a little blurb about why the book is good. Every once in a while a wholly new book turns up and I will add it to my ‘to read’ list and I am the wiser for it. Still, I think I can stand up to it and avoid actually creating a reading list of some form.

That about wraps it up for today, this was more of a random ramble than anything else. Back to actual geek topics soon enough.