Introduction

FXRuby is a library for developing powerful and sophisticated crossplatform graphical user interfaces (GUIs) for your Ruby applications. It’s based on the FOX Toolkit, a popular open source C++ library developed by Jeroen van der Zijp. What that means for you as an application developer is that you’re able to write code in the Ruby programming language that you already know and love, while at the same time taking advantage of the performance and functionality of a fully featured, highly optimized C++ toolkit.

Although FOX doesn’t have the same level of name recognition as some other GUI toolkits, it has been available since 1997 and is still under continuous development. FXRuby has been under development since late 2000, and the first public release was in January 2001. I’ve been the lead developer during that entire time, with a number of community volunteers contributing patches along the way. It’s a tricky proposition to guess the size of the user community for an open source project, but according to the RubyForge statistics there have been close to 45,000 downloads of FXRuby since the project was moved there (and almost 18,000 before that, when it was hosted at SourceForge). Questions posted to the FXRuby users mailing list are often answered by myself, Jeroen van der Zijp (the developer of FOX), or one of the other longtime members of the FXRuby community.

Introduction

If I were to buy a real recipe book—you know: a book about cooking food—I wouldn’t be looking for a book that tells me how to dice vegetables or how to use a skillet. I can find that kind of information in an overview about cooking.

A recipe book is about how to make things you might not be able to easily figure out how to make on your own. It’s about skipping the trial and error and jumping straight to a solution that works. Sometimes it’s even about making things you never imagined you could make.

If you want to learn how to make great Indian food, you buy a recipe book by a great Indian chef and follow his or her directions. You’re not just buying any old solution. You’re buying a solution you can trust to be good. That’s why famous chefs sell lots and lots of books. People want to make food that tastes good, and these chefs know how to make (and teach you how to make) food that tastes good.

Good recipe books do teach you techniques. Sometimes they even teach you about new tools. But they teach these things within the context and the end goal of making something—not just to teach them.

My goal for Rails Recipes is to teach you how to make great stuff with Rails and to do it right on your first try. These recipes and the techniques therein are extractions from my own work and from the “great chefs” of Rails: the core Rails developer team, the leading trainers and authors, and the earliest of early adopters.

Preface

This book is the second edition of the PickAxe, as Programming Ruby is known to Rubyists. It is a tutorial and reference for the Ruby programming language. If you have the first edition, you’ll find that this version is a significant rewrite.

When Andy and I wrote the first edition, we had to explain the background and appeal of Ruby. Among other things, we wrote “When we discovered Ruby, we realized that we’d found what we’d been looking for. More than any other language with which we have worked, Ruby stays out of your way. You can concentrate on solving the problem at hand, instead of struggling with compiler and language issues. That’s how it can help you become a better programmer: by giving you the chance to spend your time creating solutions for your users, not for the compiler.”

That belief is even stronger today. Four years later. Ruby is still our language of choice: I use it for client applications, I use it to run our publishing business, and I use it for all those little programming jobs I do just to get things running smoothly.

In those four years, Ruby has progressed nicely. A large number of methods have been added to the built-in classes and modules, and the size of the standard library (those libraries included in the Ruby distribution) has grown tremendously. The community now has a standard documentation system (RDoc), and RubyGems may well become the system of choice for packaging Ruby code for distribution.

This change has been wonderful, but it left the original PickAxe looking a tad dated. This book remedies that: like its predecessor, it is written for the very latest version of Ruby.

Introduction

As I drove across the central Texas landscape, my excitement and anxiety were both building. I was driving to a new client that would change everything for me. This short trip would take me an hour south to a small college town, but symbolically I was beginning a much longer journey. I was going from Java to Ruby.

The past year, I had been involved in my first non-Java project in more than a decade, and based on that success, I had recently written a book called Beyond Java. I called into question my investments in not only the Java platform but also ten years of skills, hundreds of customers, scores of enterprise applications, four Java books (including three Java One best-sellers and a Jolt award), and a reputation as a pragmatic Java developer. As often happens, researching Beyond Java changed the way I think about software development today. Modern programming should be about leverage, with much more emphasis on total cost and productivity. The more I learned, the more I believed that this industry was heading for a revolution that would change the way we write most database-backed Internet applications first and a much broader suite of applications later. I put together a plan to ready my company for the pending revolution, but planning and executing show much different levels of commitment. This client would be my first full- Ruby client.

Introduction

The shoemaker’s children are running around barefoot. People on the outside of software development projects see them spew out a multitude of tools that shift work from people to computers. But the view inside a project is—all too often—different. There, we see days filled with repetitive manual chores. At one desk, a tester is entering test data into a database by hand. At another, a programmer is sifting through the output from a version control system, trying to find the file she wants. At a third, a business analyst is copying data from a report into a spreadsheet.

Why are these people doing work that computers could do perfectly well? It’s a matter of knowledge and skill. The tester thinks programming is too hard, so he never learned. The programmer knows programming, but none of her languages makes automating this kind of job easy, and she doesn’t have time to do it the hard way. The analyst once wrote a script to do a similar chore, but it broke when she tried to adapt it to this report. Getting it working would take more time than copying the data by hand, even if she has to copy it six times over the next month.