FROM THE ARCHIVES OF PRAGPUB MAGAZINE DECEMBER 2010
Chad Fowler on Ruby: An Interview with a Ruby Pioneer
By Michael Swaine
A legend in the Ruby community shares his recollections and insights and hopes, from the early days of Ruby enthusiasts to the future of Ruby on silicon and Ruby for phones.
Chad Fowler cut his programming teeth on a Commodore 64 as a kid making blobs of color fly around the screen with ridiculous text and awful “music.” Years later, he has come to realize that this describes his ideal project.
Well, that’s his story. Those whose lives have been enriched by encountering Chad are more likely to emphasize his talents as a teacher (in courses from Pragmatic Studio with Dave Thomas, as author of several excellent books, or for his many lectures and conference keynotes), as a much sought-after consultant (whose consulting work takes him to many countries every year), as a skilled software developer (he’s presently CTO of InfoEther and formerly software developer or manager for some of the world’s largest corporations), or as a generous contributor to the Ruby community (who organizes RubyConf and co-created RubyGems). Or possibly for his earlier career playing saxophone in Memphis bars.
Chad’s generosity was obvious to us when a few simple questions from us led him to share his rich memories and deep insights about Ruby, the most exciting programming language to come on the scene in a generation. Here’s Chad.
Discovering Ruby
🎤 ms: When and how did you first encounter Ruby?
🎷cf: Around the turn of the century (I love that I can say that now) I had a habit of spending my Saturday mornings learning a new programming language. It was my rapid, shallow version of Dave and Andy’s suggestion in The Pragmatic Programmer to learn a new language every year. I would typically download the runtime or compiler of a new language, read some documents, and try to write a useful program in the new language on the same day. Sometimes the languages were mainstream ones I’d just never played with. Sometimes they were completely esoteric obfuscated languages such as Befunge, Ook or Malbolge. Every once in a while I’d spend time looking at a spoken language like Lojban or other so called “conlangs.” Whatever the case, I was always looking for something that would make me think differently or able to express myself in a way I hadn’t considered.
At the same time, I was going through the decision-making process of what programming language to more fully dedicate myself to. I had been using Java for several years by then and had gone pretty deep with it including a fair amount of mucking about with the JVM itself, compiling my own little non-Java-language programs into JVM byte code. I had finally reached the stage where I felt I had learned about as much as I could from Java, and though I mostly loved it, it was time to broaden my horizons.
As an aside, when I got started in the IT industry as a young musician looking for side work, I was lucky enough to find a mentor to guide me through the process. I was focused on system administration at the time, and he gave me some magic advice which I’m convinced is the seed that made my career what it is today. He told me to learn three technologies, all very different from each other which would make me think differently from each other and also open up a new set of marketable skills that would look good as a set on my resume. This worked so well for me early on it was as if I had literally been given the recipe for successful career starts. So I naturally decided to construct my own list as a programmer.
So I decided to jump full-bore into Smalltalk. It was dynamic, had this weird concept of a persistent image that was foreign to me at the time, and had a remarkably minimal syntax, which I’m sure we’ll all agree is on the far end of the spectrum from Java’s. Not only that, it was used by some of the programmers I respected much from the budding agile development community (nobody called it “agile” then). I made this decision on a Friday afternoon as the work week wound down in my corporate job.
On Saturday morning, with full knowledge that I was about to embark on a journey into the center of Smalltalk, I did what I always did: loaded up my Web browser and searched for the Language of the Week. I’m not sure where I first heard about Ruby. It had been a few years earlier. But this Saturday morning, a post from (Pragmatic) Dave Thomas on the Extreme Programming mailing list is what made me decide on Ruby as my weekend project.
I quickly learned the syntax, discovered ERb (“Embedded Ruby”), and rewrote and deployed my weblog software in Ruby as a CGI framework with a MySQL backend. I did all this by around lunch on Saturday. I’d been in this new language routine for quite a while and I’d never made this much progress so quickly. It was bizarre. On Sunday, I came back to Ruby. And on Monday evening after work. And so on.
On the down side, I never really got that good at Smalltalk.
The Early Days
🎤 ms: You got involved with Ruby at a time when it was known only to a small number of people outside of Japan. Could you talk about what the Ruby universe was like then?
🎷cf: Being in the innovation wasteland that Louisville, Kentucky was in 2000, I frequently turned to the internet to find an inspiring professional community of creative software developers. This was no different with Ruby. I’m pretty sure I was the only person using Ruby in Louisville then. I started to introduce Ruby to my co-workers, who would frequently snicker when I mentioned it. I think they were playing a minimalist form of buzzword bingo in the office where the only word on the sheet was “Ruby.” They thought of it as just another crazy thing Chad was goofing around with again. I don’t blame them. But that gives you a sense for how well accepted Ruby was in those early days of Western adoption. My team then remains one of the smartest I’ve had the privilege of being a part of, and they all thought I was crazy.
So I spent a lot of time on irc and on mailing lists arguing minutiae and dreaming of a day when Ruby was in wide enough use that I could use it as my primary work language. There were usually 10–15 people on the freenode #ruby-lang irc channel. The main English Ruby mailing list was of high quality and low traffic. It was my first time stepping far outside of the mainstream IT programmer world and into the realm of software pioneers. I don’t mean that everyone involved with Ruby then was a genius or thought leader or necessarily shaping history. But it was a small community of people who were using a tool nobody around them wanted them to be using, because they felt better and more productive using it. It was a small, global phenomenon. A sign of resistance against mediocrity. I wasn’t even sure Ruby was better than the alternatives. I just knew I felt smarter when using it and when rubbing virtual elbows with the rest of our small community of users.
Back then, by the way, “community” was an apt description of the collection of world-wide Ruby users outside of Japan. I’m quite sure Japan also had a thriving group that would be appropriately dubbed a community as well, but I (still!) don’t speak Japanese and had no way of being sure of it. But in our community, almost everyone at least knew of each other. Many had connected on mailing lists or irc to work on software or documentation together. It reminded me of my local community BBS when I was younger. If we had all been in the same place, we probably would have had a meetup at a bowling alley once a year.
And even early on, there was a strong influx of people from the extreme programming community (which was also a community back then). So at a time when few programmers were talking about things like test driven development, I’d say most Rubyists were versed in TDD if not actively doing it.
I know I’m getting old now, because I find myself thinking things like “those were the good old days.” I think it’s actually more a sign that those days were good than a sign of my age, though. It’s exciting to be part of something new and subversive that you feel is better than what most everyone else is doing. It’s also scary to be putting as much effort into something so shaky as most of us were putting in. For all we knew the project might die, or it could just never catch on. Most of us were working on Ruby based on a combination of love, naivety, and faith.
As for the kind of work people were doing with Ruby at the time, the main thing I can say is that almost nobody was doing their job with Ruby. Most of what was being developed in the Ruby community was stuff around the language itself, such as documentation tools and code browsers. I was using Ruby at work for backend processing tasks and scripting. I also used it to generate Java code to save me time. I think a lot of us were using it behind the scenes in that way.
Ruby on Rails
🎤 ms: What was the impact of Rails?
🎷cf: In mid-2004,we heard the sound of our little community’s death knell. Its origin was Denmark. Its name was Ruby on Rails. When I say “death,” I refer specifically to the little community that I was talking about earlier. Rails changed things for us and for a lot of people who had never (and might still never have) used Ruby.
I knew about Rails and was running an application for a small non-profit that my wife and I were involved with. I knew David Heinemeir Hansson from The Internet and had helped him with issues with the RubyGems packaging system. But even so — I remember the night before RubyConf 2004 in Chantilly, Virginia. I showed up early, as I always do to help set up, and the usual suspects were all arriving from the airport. What was different this time was that almost every one of them was asking, “Has that David Flanemeyer Landon guy gotten here yet?” or some such mispronunciation. Everyone wanted to meet him and to talk to him about Rails.
I was surprised. To me, Rails was just another Web framework in Ruby like Iowa and Arrow and a few others you probably haven’t heard of. People had been using Ruby to do Web development since before I started programming in Ruby, and to me Rails was just a Model/View/Controller framework written in a niche language that almost nobody was using. Though I liked it, I didn’t expect much from it.
But RubyConf 2004 convinced me otherwise. Rails and its creator were the force of the conference. And I remember that DHH did something unusual with his presentation. Rather than spend the entire time discussing technical details of Rails, he gave what seemed more like a How To speech about launching a successful marketing campaign and building a remarkable, successful product. This was definitely not the kind of subject material RubyConf was accustomed to, but what was really interesting about this is that he was effectively laying out the future of Rails' success before it happened, and speaking as if it already had. It seems like this strategy was successful, and I’ve seen him do it repeatedly since then.
That was late September of 2004. By July of 2005, David was keynoting at O’Reilly’s huge Open Source Convention, at which we had previously been struggling to keep our little Ruby track alive. OSCON 2005 was, as much as any other date, location, and time, the arrival of Ruby (via Rails) into the mainstream software developer’s consciousness. After that, the flood gates opened into the Ruby community, with developers leaping in from all corners. We had PHP programmers and even HTML people on one end of the spectrum and hardcore Java and .NET developers and architects on the other end. Well-known developers from other language communities were dipping their toes in or even jumping in head first and re-identifying as Rubyists.
Ruby and Rails books started to flood the shelves. Normal companies started to consider and then adopt Ruby for their main lines of business. People were getting jobs working in Ruby!
And, much to the chagrin of some of us who had been working with Ruby as a labor of love for years prior, Ruby became a “Web language.” Rails was so influential that, for a time, it was common to have conversations with other developers who didn’t know that there was a difference between Ruby and Rails. “Ruby on Rails” was just one thing, not a language and a framework.
That all being said, the overwhelming sentiment was that of thankful disbelief. We all got what we’d been hoping for and more with the arrival of Rails. Not only did it allow us to use our beloved Ruby all day at work, but it gave us both a wonderful Web framework and a shining example of how when bad ideas that become so ingrained that most people don’t even notice them anymore, the ground is fertile for innovation.
Rails on Ruby
🎤 ms: Has Rails influenced the development of Ruby itself? What outside
forces have influenced the evolution of Ruby, if any?
🎷cf: Rails has definitely had an influence on the development of Ruby. Rails definitely doesn’t drive what Matz does with Ruby, but consider that adopted languages (even spoken languages) change largely due to societal pressures. And for most Ruby developers at this point, Rails was the gateway in. That means the initial examples of the language that people see are within the context of the Rails framework. The APIs people first learn are the Rails APIs. The conventions, terminology, expectations of succinctness vs. verbosity all come initially through Rails.
Before Rails, I don’t recall feeling that Rubyists had really settled on accepted style. There weren’t really even pockets of styles that I remember. Some people were still doing camelCaseMethodDefinitions. Some people were putting all of their library code in a single file. Some people set up their packaging with install.rb, some with setup.rb, some with RubyGems.
Rails ingrained a style of Ruby code by example. It became common to define methods that accept a Hash of additional options where the keys in the Hash are Symbols like this:
Botanist.find(:all, :conditions => {:first_name => “Bobby”})
We take that sort of thing for granted now, but back then it was jarring and ugly to my eye. It’s used so pervasively in Rails, though, that it’s commonplace. In fact, Ruby 1.9 takes the Symbols-as-keys convention to a new level of brevity:
Botanist.find(:all, conditions: {first_name: “Bobby”})
It may have been inevitable but I’d say Rails had at least a major indirect effect on that happening.
In Ruby 2.0, Shugo Maeda is working on a new feature called “Refinements.” Refinements allow us to re-open and change Ruby classes only within a specific scope. This makes Ruby’s open classes, modules, and Objects safer to go crazy with. While we’ve been waiting for such a feature since years before Rails was created, Rails’s penchant for souping up existing Ruby classes with convenience methods has certainly fanned the flames of the need. Rails lets you do things such as:
ruby-1.9.2-p0 > 1.day.ago
=> Sat, 27 Nov 2010 00:01:36 UTC +00:00
ruby-1.9.2-p0 > "Botanist".pluralize
=> "Botanists"
ruby-1.9.2-p0 > Object.ancestors.map(&:name).to_sentence
=> "Object, Kernel, and BasicObject"Shugo’s Refinements implementation would allow us to create these handy convenience mechanisms, but localize the effects of their changes, making it safer to do it even more than we do now.
There are many small examples of Rails influencing either the language or the standard library, but the short answer is: it has made an impact.
Another major impact Rails had was that it helped to popularize the RubyGems packaging system (of which I was a co-creator). RubyGems was the way to install Rails, which meant that as Rails grew in popularity, so did RubyGems. Even if people weren’t sold on RubyGems, having it available everywhere Rails was available meant it was the easiest way to get a library or Ruby application out into the hands of developers.
This led to a bazaar-style Open Source ecosystem (as defined by Eric S. Raymond’s The Cathedral and the Bazaar) as opposed to the slower, more conservative Cathedralesque model a monolithic Open Source project might adopt. What we’ve found is that if RubyGems are simple to create and distribute, there’s almost no barrier to creating one for the simplest of needs.
This has evolved in our community to include the new RubyGems.org, which Nick Quaranto developed and led into production last year. Now gem publishing is automated and command-line driven, which means you can go from idea to published, announced gem in minutes if you’re solving a simple problem.
So while this isn’t really an impact on the language directly, it majorly effects the ecosystem of software. Ruby programmers are rarely stuck when their language or standard library doesn't support what they want it to. They can often trivial “fix” those holes and distribute the solutions to everyone else. Rails had a major role to play in making this true.
RubyConf
🎤 ms: Could you talk about RubyConf — the first one and how it has
evolved — and the phenomenon of regional conferences and code fests?
🎷cf: The reason I’m still as involved with Ruby as I am is probably RubyConf. We held the first RubyConf in 2001 in Tampa, Florida. It was originally planned by a developer named Guy Hurst. He came up with the idea, registered a Web domain, set up a Web site, organized a venue, and then got busy with the rest of his life and had to give it up. Dave Thomas didn’t want to see the first conference die on the vine, so he invited David Alan Black and me to a private channel on IRC and asked if we would help see it through.
And we did. The first conference was co-organized by the three of us. We had 34 attendees. Many of us were authors. Four of us were signatories of the Manifesto for Agile Software Development. One of us was the creator of Ruby!
The first RubyConf was more like a meeting than a conference. We had presentations, but most of them became discussions. We had a planning session for what was to become the successor to the Ruby Application Archive (RAA.succ, we called it).
We’ve taken it to a different city each year since and have rotated among the continental US time zones to try to make it easier for people to attend. We’ve gone from 34 attendees in 2001 to around 800 this year in New Orleans. In 2005, just after Rails was released, we had our first rapid sellout. We’ve since sold out events every year, and in 2006 split off another conference called RailsConf to help accommodate the load and stratification in focus and interest that was apparent in 2005.
As an organizer, I can get away with saying that RubyConf has always been informal, sloppy, and somewhat haphazard. But it’s also been magical. People leave the conference with new aspirations, new collaborators, and sometimes with new careers.
Because RubyConf has so far always taken place in the US, a couple of years in, some programmers in Europe took it upon themselves to organize a European conference. They called it Euruko. They also started out very small. They also took to moving the conference around Europe. They now apparently not only move it around but elect new organizers in new host cities every year.
After Euruko started, the organizers of RubyConf (who had incorporated a non-profit called Ruby Central) thought it would be cool to help others get together locally and more frequently than RubyConf would allow. So we put together a grant program, giving out money to people who wanted to organize codefests, where they would get together locally and work on a project. We had a little money left over from the 2003 conference, and being a nonprofit, decided to put it back into the community in this way. We awarded several codefest grants before changing the grants to be in support of regional conferences instead.
I may be wrong, but I think the first major regional conference to spring up in the US was the Mountainwest Ruby Conference in Utah in early 2007. I remember being astonished at the crowd there. It was their first conference and they had something around 200 people. For a local, regional conference.
Since then the regional Ruby conference phenomenon has exploded. Each one has its own local feel and flavor. They’re happening all over the world. I’ve been to many of them and have enjoyed each one differently. And we’ve borrowed ideas for RubyConf.
I’ve been hoping the next step would be to start seeing topic-specific conferences. And this year, once again in Utah….hmmm, we saw Ruby|Web Conference 2010, a Ruby conference specific to Ruby Web technologies. Maybe next year we’ll see Ruby|MusicConf or Ruby|HardwareConf. I hope so.
Ruby Adopters
🎤 ms: You meet a lot of Ruby developers in your travels and talks. Do you have a sense from those encounters just what people are using Ruby for today? And has that changed over the years?
🎷cf: People are using Ruby for all sorts of things these days. Web apps, backend code, GUI apps, simple Web services. It’s all over the board. And telecom apps. And even televisions. More than that, the domains Ruby is finding its way into are getting more and more diverse. In the 2005 timeframe, we always heard about a lot of startups using Ruby. I remember hearing second-hand from the Web 2.0 conference in early 2006 that if startups weren’t using Ruby, people asked them why they weren’t. It was kind of assumed.
But these days it’s not just startups. It’s big corporations and governments. And people trying to open their governments. Some of the biggest companies on the planet are making strategic investments in Ruby code. Many government agencies are doing the same. I’ve personally interacted with five or six US government agencies in the past couple of years.
Ruby in the World
🎤 ms: Can you comment on adoption of Ruby throughout the world?
🎷cf: Ruby is being adopted world-wide, though I see it moving more quickly in the US and Canada than anywhere else. I guess the same would be true of agile development methodologies, NoSQL, git, and other leading-edge ideas. We tend to pick things up quickly in North America.
I don’t mean we’re smarter than people in other places. We’re just more likely to play with new things. I learned this lesson while living and working in India. In the US, we have things like food and shelter so figured out (for the most part) that we don’t think about it anymore. Of course we have a computer or two at home. Of course we have free time. If we don’t, we whine about it. We’re really spoiled.
In other places, technologies are adopted more slowly. In India, a large part of that I think is that the Indian economy is still stabilizing and India’s most successful programmers are typically only a couple of generations past having to worry about the basic needs in life. So the average Indian programmer isn’t yet to the point where they’re goofing around with programming for fun. They’ll get there eventually, but they aren’t there yet.
I’ve seen the same things in other places as well. I’m not sure it’s all economically driven, but I have yet to find a technology culture more thirsty for constant change than the US. When I travel to places like Brazil and India, I see frustrated thought leaders pushing hard to drive change, but basically situated culturally where we were five or six years ago.
Part of me feels bad for them. Another part of me envies them. It’s rewarding to be a revolutionary. :)
JRuby and Other Rubies
🎤 ms: Could you say something about what seems to be the large number of distinct Ruby implementations?
🎷cf: Ruby has several viable implementations. That is to say, “Ruby” with a capital “R” (the language) can be executed by any of a handful of high quality, mostly-code-independent implementations of it. There’s Matz’s Ruby (1.8), YARV (1.8 + a new VM and syntax for 1.9), JRuby, Rubinius, Maglev, IronRuby, MacRuby, Rite, and others in development. All of them can run real Ruby code. All of them provide advantages over the others. Each implementation is faster for some things than the current state-of-the-art canonical Ruby implementation.
Outside of the Lisp/Scheme world, I don’t think I’ve ever seen this happen before. There are tons of options. And Matz embraces them all. In his RubyConf keynote this year, diversity of implementations was a major theme. The many Ruby implementers communicate with each other frequently, share ideas, complain about hard features to implement (heh), and generally make each other better. Even the canonical Ruby implementation has a lot to gain from this thriving community of Ruby implementers.
If you’ve ever worried about the long-term viability of your language, whether it be a niche language or VM, or a commercial situation like the current JVM situation, knowing there are so many Open Source alternatives is refreshing. If something really really bad happened and all of Matz’s interpreter work was somehow lost or compromised, most of us could happily switch to JRuby with minor modifications at most. That’s amazing.
Ruby Culture
🎤 ms: Is there a distinct Ruby culture?
🎷cf: I think there is a cultural aspect to the Ruby ecosystem. We have a bazaar model for implementations. And libraries and library distribution. And conferences. And documentation. And Open Source contributions. And so on.
I think this has happened, because Ruby fosters a culture that has always taken a hard, critical look at our assumptions as software developers and turned them upside down.
Here’s a simple example: why don’t we have to use parentheses and semicolons all over our code? We’ve programmed with needless semicolons and parentheses littering our code for years without questioning it. But with Ruby we don’t have to do that.
The question this raises in my mind is “Why did we ever have to use so many damned parentheses or end every line with a semicolon to begin with?” Could the Java parser not have figured out when a line was ending without a semicolon? Of course it could!
But then again, why did we ever have to do a lot of the things Rails automates for us? Or why hasn’t PBX development always been as easy as it is with the Ruby Adhearsion framework? Or why haven’t we always had Capistrano?
We’ve seen Ruby software break so many habits and assumptions that it has become rightly known as a language for which assumption- and habit-breaking is the norm. One such assumption it broke was that “weird” languages shouldn’t be welcome in Real Enterprises.
Java was weird once too, I guess. But it was also a technology backed by major industry players and a lot of money. When Ruby took the Web development industry by storm in 2004 and 2005, it was a niche Open Source language created by a Japanese man whom nobody in the West had ever heard of. And as I said before, it was the subject of laughter in the traditional IT setting.
But then suddenly many people saw what it made possible. And maybe I’m fooling myself, but I feel as though that opened up the flood gates to the acceptance of things like erlang, python, ocaml, haskell, scala, mongodb, cassandra, and so on. All of these weird unconventional technologies sprang up and were semi-accepted at the same time. I think Ruby (through the success of Rails) at least temporarily made it OK for people to experiment, even in traditionally conservative environments. It became more palatable to attempt to choose the right tool for the job at hand even if that tool didn’t fit into a homogenous corporate toolbox.
As I’ve traveled around the world, I always encounter that one person in every company who’s trying to push everyone else to think more effectively, try harder, strive for beauty, focus on the craft, free themselves from heavy useless process, and so on. That same person espouses “agile” processes and dynamic languages. He or she advocates test-driven development and customer involvement. Domain driven design. Lean startup ideas. All the Good Stuff. Since I’ve been involved with Ruby, Ruby’s been a honey pot for that one person. That’s the magic of Ruby. I can’t explain it, but all of those people…they’ve shown up year after year. It’s a lucky place to be.
The Future
🎤 ms: Where is Ruby headed? What are your hopes for the language or the
community?
🎷cf: I have no idea where Ruby is headed. Part of me says “Screw it. It’s good enough. Let’s just fix bugs and make it faster.” But that’s because I’m not as smart as people like Matz, Shugo Maeda, Nick Quaranto, anyone on the Ruby Core team, anyone on the Rails Core team, etc., etc., who have proven that things can continue to get a lot better consistently even when they seem to be pretty damn good.
I do know that Ruby 2.0 is finally on the horizon. I first heard about Ruby 2.0 at RubyConf 2001. Matz gave a keynote about it. In the keynote he said, “I hope this takes longer to create than Perl 6.” He didn’t really say that. But in 2006 in his RubyConf keynote he did say “Ruby 2.0 is worse vaporware than Perl 6.” He showed dates and proved it.
When your 1.x language isn’t dying, maybe a forever-elusive 2.0 keeps people excited. Think about something you’ve committed to long term. If you always thought you were just in the nascent, undeveloped stage of whatever it was, you’d probably be more motivated to stick with it to see where it goes. If 1.x is awesome, imagine what 2.0 is going to be like! Why ruin it for everyone, right?
Well anyway it looks like Matz is going to ruin it for us all soon. And by “ruin it,” I hope I mean he’s going to rock our worlds. That’s what I hope for. 1.9.2 is the best Ruby ever. In any other language it probably would have been called 2.0.
So what I hope for Ruby is that 2.0 introduces incompatible changes. I hope 2.0 removes all of the little ugly things we’ve all gotten used to. I hope it fixes problems I didn’t realize I had. I hope 2.0 is remarkably different from 2.1, because 2.0 contained crazy ridiculous ideas that didn’t work and had to be pulled out for 2.1.
And I hope Ruby 2.1 can run everywhere. I want to use it to do hardcore math I’m not qualified to do. And I hope to run it on my phone and my microwave. I met Gilad Bracha in Poland a couple of years ago and before he knew I was a devoted Rubyist he criticized the Ruby apologists for justifying the poor performance of the Ruby interpreter by saying that all we do is IO-bound application (Web apps). Gilad said what we all know: there’s no reason Ruby has to be relegated to applications where computation can be slow. Even if that’s a whole lot of apps.
At RubyConf this year, Matz spoke about a new project called “Rite.” Rite is a subset of Ruby with a new implementation made specifically for low-footprint applications such as cell phones and appliances. There’s apparently even a Ruby chip being developed to help speed up method lookups and other slow operations. Maybe that will succeed and become Ruby 3? Or Rubyists might start switching to Rite. It’ll be fascinating to watch.
About Chad Fowler
Chad Fowler is a software developer, author, speaker, conference organizer and musician. By day he is CTO of InfoEther, Inc. where he solves hard problems for companies of all shapes and sizes. By night he writes books such as The Passionate Programmer and the upcoming Rails 3 Recipes.
The photo of Chad is by James Duncan Davidson and is used with his permission.
