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.

I took a stab at making a Ruby on Rails application a couple of years ago and when the start-up fell apart, I felt that I should use my now existing free time to give it another shot. The technology seemed fairly interesting and while my first crack ended up being relegated to the dust bin of my back up hard drive, it made me want to learn more about the language and framework. The project I have been working on for the past couple of weeks will likely get launched to family and friends in the next week or so and I’ll likely open it up to the public assuming there aren’t any real problems.

One thing that I discovered with Ruby on Rails the first time around is that the framework seemed almost sinister in it’s ability to detect a Java programmer. You’d go through, doing things, never quite sure what you have to write and what the framework does for you. Eventually, you’d step on metaphorical toes of Rails and things would silently stop working. Even worse, you’d get an exception or error from deep in the framework’s stack. It was as if there was some special code in place to detect common patterns from curious Java developers and would blow up in our faces. Probably not, but that’s what it felt like.

I picked up Rails Recipes a couple of weeks ago now and am very glad I did. The book is laid out in a fairly similar manner to the Gang of Four’s Design Patterns, in that it is really a collection of fairly unrelated strategies to conquer various problems. There are sections on how to improve your Rails testing, how to better use the built in Rails support for the Prototype and script.aculo.us Javascript libraries, common ActiveRecord (Rails data abstraction layer for those who haven’t used rails), etc.

The book is well written and to the point. I read through most of the recipes which were relevant to me in less than a day. What was really nice was that there were several how to guides for things which appear in many real projects, but are a bit more sophisticated than what usually appears in the Rails tutorials found in the wild on the Internet. Things like self referential many to many relationships are common enough that you have to know that there is support for it built into Rails, but exactly which incantations are required to correctly set it up are not exactly clear.

Rails Recipes is excellent for things like this. Tasks that are common and are a part of the framework, but are just complicated enough that the basic tutorials do not cover them. I had found that there was a large gap in documentation online between the Rails newbie guides and Rails expert solutions. This book fills that gap nicely.

Many books specific to languages and frameworks, once you have advanced beyond a certain proficiency level they cease to be useful. Rails Recipes is not immune to this and while I am not there yet, I can see the day when I look at the topics covered and think, “How quaint.” That said, though, I definitely feel that this book will help me get to that point more quickly and efficiently than I would have done alone or with the help of the documentation that is currently published on the Internet.

For me, this was definitely worth the investment. If you are a Rails guru, maybe skim it in a bookstore first before buying, but if you are just getting over the rookie phase and looking for the next logical step to take to improve your abilities, this is a pretty good book to go with.