I love the Ruby community. It’s vibrant, witty, and smart. Truly, our community is one of the best aspects of working with Rails and no small part of its success. As I was nearing completion of this book, I felt a strong urge to include the community in whatever way possible, to give readers a taste of what it’s like, and then it hit me. We all know that there is a Rails way, and yet it is an intensely personal experience, subject to interpretation and joyful exposition. What better way to end the book than with a collection of your thoughts!

So I asked and boy, did you all respond. I hope you enjoy reading the following series of quotes, quips, and essays as much as I did.

Obie Fernandez, Jacksonville Beach (September 12, 2007)

My first thought was “The Rails way is happiness,” but then I remembered a poem that I really like by Edgar Allen Poe. The poem Eleonora started off with him talking about madness and intelligence and how it might be that they are one and the same. He goes on to talk about and give a sense of pity for those who can only dream by night. I am glad I am one of the ones who can dream by day as well as by night. I know the secret!

Desi McAdam, my favorite Rails developer

The creators of Rails were so unhappy with every existing tool for developing web applications that they started from scratch. As should by now be clear by the length of this book, that was a serious undertaking. How much better would PHP be if they had contributed patches instead of writing Rails?

Perhaps a little, but probably not enough for outsiders to notice. To paraphrase the shopkeeper in Whisper of the Heart: “You could polish rough ore, but what you’d get would be worthless. The smaller gem inside is purer. It takes time and effort to find it.” Rails teaches us that sometimes you must discard what you are used to seeing before you can find what you are looking for.

The Ruby way is to polish a stone until you find the jewel within it. Ruby and Rails, for all their power and elegance, cannot stop you from writing cluttered, unreadable code. Only you can decide when the code you have written is as polished as you can make it. Ruby asks us to challenge ourselves to create elegant systems that are pleasant to use and to look upon. Rails asks us to constantly test our assumptions, and to not be afraid to discard large sections of code if they displease us.

These two forces, discontent with the current state of affairs and constant self-criticism of your own work, are what have made Ruby and Rails such popular and powerful tools. If you can recognize these forces in yourself, you will write better code. If you can harness them, you will have found the Rails way, even if that leads you to write something better to replace Rails itself.

Wilson Bilkovich, Rails myrmidon and Rubinius core developer

When I’m working in Ruby on Rails, I feel like I’m sketching with well-sharpened pencils on quality paper, with a good eraser by my side. I’m able to rough out my idea very quickly to see if it has merit. If not, the application can be tossed without too much grief, because a minimal amount of effort was expended initially. If things are working out, I’m able to refine what I like and delete what I don’t, building up the same application from prototype to production with the tightest design spirals I’ve ever experienced developing software.

Dan Gebhardt

The wise student hears of the Rails way and embraces it.

The average student hears of the Rails way and forgets it.

The foolish student hears of the Rails way and laughs aloud.

But if there were no laughter, there would be no Rails way.

Jon Larkowski, with apologies to Lao-Tzu

I have been a .NET developer for the past several years. I have spent every day with .NET in one form or the other but when asked why I do it, my usual response is, “it pays the bills.” I don’t say I love the technology but that it is a means to an end. I still do it every day until there is something better I can do every day.

I think I see a light at the end of the long tunnel that has been my career and it’s Ruby and Ruby on Rails. When using them the experience is very satisfying, very Zen-like, almost to the extreme of being philosophical in nature. When I am asked by my peers as to what Rails brings to me I often find it hard to explain in words they may understand. I realize I explain it as finding a religion, where it is not just the text or the way it is delivered but includes those who share the experience, making it very whole.

The Rails way, or the experience, is about finding passion and the feeling you are doing the right thing. The technology makes it good but the community makes it great.

My involvement in Rails has only been the past year or so but having 20-plus years of software development experience, I have the insight to know when I have found something great.

Rob Bazinet, a software developer currently enjoying learning Ruby and Rails

The Rails way is M: Magical V: Velocity Focused C: Community Driven

Matt Margolis

Freeing yourself from decision-making; that is the Rails way. All the important choices have already been made for you, and instead of deciding which technology to adopt or what application structure you should adopt, you sit down and hack. As you experience the development process, you extend Rails, making plugins to fill the need. It is Zen development.

Ben Stiglitz

I’m fairly new to web development. I wasn’t doing web dev with Perl CGI scripts, or PHP, or even much with J2EE. Rails was my introduction to serious web development. For me, Rails made web development something that I didn’t have to try and avoid.

I can’t help but compare Rails to C. I learned C fairly early in my lifelong love affair with programming. Raw power, expressiveness (I was previously using mainly assembly language), being able to do some cool stuff very quickly. Smalltalk gave me the same feeling all over again. Rails gives me that feeling again... Ruby, of course is a big part of that... the ability to accomplish much in very little time, with very little code.

To me the Rails way is about how it feels. Rampant productivity, flow, expressiveness, malleability, few hurdles or roadblocks...

The Rails way is like blasting down the coastal California highway on a sunny day in a Corvette convertible with the top down.

Dave Astels, author of TDD: A Practical Guide and Test Mercenary at Google, Inc.

The Rails way is ...

Jim Remsik, a.Net Developer with a job change in the near future

OK, so what is this “Rails way” that people speak of? Is there, in fact, such a thing, and if so, is it actually definable? I believe that the “Rails way” is a subjective concept, and as such I’d like to explain what it means to me. If we ever meet, I’d love to know what it means to you.

Let’s start with a simple, almost embarrassing analogy. Let’s talk locomotives, carriages, trains, and railways. No, I’m not talking about the small models that your dad painstakingly paints and crafts in the garage. I’m talking about the real deal. Big huge powerful engines. Tracks laid for miles. Cargo. Passengers. The heavy, sooty smell of smoke, steam, and coal. Technology that powered the industrial revolution. Technology that people constantly challenged, improved, and reinvented. It’s still happening today. For example, in terms of technology, the Transrapid Shanghai Maglev Train is a far cry from the steam locomotives that operated along the English railways during the early nineteenth century. Books similar to this one were written about the technology behind railways, for the people interested in or building with the technology. However, for the majority of people, the technology behind railways isn’t their focus. It’s what railways enable that is interesting: holidays to the seaside, visiting Gran, shipping goods to new markets, being able to live farther from work. Now, what I personally think is interesting about railways is the inherent limitations; the fact that they limit where you can travel. Your choice of destinations is essentially decided for you. The decisions were made when the tracks were laid and the stations were built. People decided that you’d want to travel from London to Newcastle.

“Gah, the gall!” you might cry. “I want complete control of where I can go,” you might suggest. After all, choice is freedom, right?

Ruby on Rails is similarly limiting. It lays the tracks down for you. It tells you where to go. Of course, you’re not strictly limited to following its direction—you can go where you want. However, I’m sure that riding a train over rough undulating terrain won’t be the most comfortable journey you’ve ever had. This leads to an important question: “How do I know that Rails is taking me in the right direction?” Clearly this is a subjective question. The answer really depends on your own definition of “right.” However, for me it was most certainly the right direction. Let me give you a little bit of context:

So, I was well into my Ph.D. studies. I had implemented a prototype in Java to evaluate my ideas. The only problem was that the Java system was a house of cards constantly falling over. Looking back in retrospect, I think that it was mostly to do with the fact that my ideas were in a state of flux: They were constantly changing. After all, I was researching. Unfortunately, the Java code base I had written became complicated and convoluted with all the changes. In an ideal imaginary world I would have just conjured up new ideas which, in order to be evaluated, would be magically implemented by some AI research bot. Clearly this wasn’t the case, and I had to write my own code. However, with the Java implementation, the code started to control my ideas rather than the ideas controlling the code. For example, I’d find myself saying things like “It would be great to be able to do this, but that would be too hard, or take too long to implement.” It caused me a great amount of frustration, followed by a fair amount of depression.

Now, I’m not trying to get all emo on you. Go and find someone who’s done a Ph.D. and you’ll see that each and every one of them had some kind of depression during the course of their research. I hope you’ll excuse the mild tautology, but it’s just a depressing reality of the nature of Ph.D.’s. In my case, my depression grew from being frustrated with my tools, and not knowing where to turn next to fix the big mess I was in. I was lost, and without direction.

Somehow, I stumbled across Rails. I’m not sure what attracted me to it. Perhaps it was because I had already been using and enjoying the simple wiki Instiki for a while (one of the first-ever Rails applications). Perhaps it was the strong sense of community. Perhaps it was the smart, interesting, and often funny blog posts. Perhaps it was the sheer excitement and thrill displayed by people using Rails. “Whoops,” I forgot the fact that it could have also been the eye-opening screencasts. In fairness, it was probably a healthy dose of each of these things. Rails offered me a lot of what I was wanting: an intelligent, excited community of interesting people focusing on a framework that allowed useful things to be built remarkably quickly and effortlessly. I needed some of that!

The next year or so were lost years in terms of research; I hardly progressed. However, I learned a lot more about programming than I had done in any other similar period of time. I devoured blog posts and books like I had been starved of information. Learning Ruby really opened my mind to the interesting facets of programming languages. Suddenly I could see that programming didn’t just have to be an engineering task; there were many other aspects. It was also an art, a craft, even a study of language itself. The philosophies behind Rails such as “Convention over Configuration” and “Don’t Repeat Yourself” didn’t just make sense; they were obviously sensible. My eyes were starting to open. Everything that the Rails community did and talked about seemed interesting. It’s almost as if they acted as a wonderful filter of what to read and learn, and most importantly it was a filter I grew to trust.

Let’s return to the discussion about trains and freedom: “Railways limit where you can travel,” and “your choice of destinations is essentially decided for you.” We discussed that possible retorts to these statements would be phrases like “I want complete control of where I can go,” and “choice is freedom.” Well, look at it from my context. I had complete choice and freedom of where I could go with my research. That wasn’t my problem. My problem was that I didn’t know which way to go, and so I was going nowhere. Having too many unclear and unknown options was essentially blinding my way.

After my Rails hiatus, I returned back to my research with renewed vigor and strength. I decided to scrap my implementation, and completely rebuild it using Ruby and Rails. I rebuilt it in a fraction of the time it took to implement the original, with a fraction of the original code-base. What’s more, the new implementation was completely tested, so the house-of-cards scenario was no more, and get this, I actually enjoyed building it. I enjoyed working on something that had once been such a frustration and cause of depression. It turned out that using Rails as a filter on the set of possible implementation options didn’t feel at all restrictive or imprisoning; it actually gave me clarity and direction. I believe that this is part of what people refer to as the Rails way, which for me is only the start of an exciting and promising journey.

Sam Aaron, who doesn’t do short answers

Ruby on Rails demonstrates that quick need not be dirty, and best practices need not be complex. It is the perfect example of the 80/20 principle in the modern world of web applications—Rails doesn’t meet everyone’s needs, but when it does it is a sweet solution indeed.

Gabe da Silveira, available at websaviour.com

Rails and Ruby, Ruby and Rails, what can I say?

I’ve been an object-oriented programmer for 30-odd years. I was one of the lucky guys who was part of the Smalltalk community in its heyday. I grudgingly took up Java work when “write once run anywhere” took over the world.

Then I retired and went back to playing with technology according to my own whims, and picked up the odd job every now and then to pick up a stray buck.

I played with various open source web apps, some good, others not so much. I run a wiki based in mediawiki, and was actively playing with that code for a while. It shows that well-written code can even be obtained in PHP. On the other hand a few consulting experiences reacquainted me with the horrors of what hacked-together code could produce.

Along the way, one of my buddies asked me if I’d played with Ruby, so I took a look. Somehow I felt strangely at home. Ruby took enough OO ideas from Smalltalk, sprinkled in some advanced ideas like modules and singleton methods, and added some, mostly good, stuff from Perl. I’d looked at python too, but Ruby just felt more complete and comfortable.

Then I got a Rails gig, adding some new features to an existing app. In comparison to an earlier similar job to try to extend a PHP mission-critical app, this was heaven. Instead of spending all my time just trying to figure out what the code was supposed to be doing, the Rails code was obvious both in the code and its structure. Best of all there were TEST CASES. A great boon to the new kid on a project.

Of course that code didn’t get the way it was just because it was written using Rails, but it sure helped. Another thing which Ruby, and Rails in particular, shares with Smalltalk is that there is quite a lot of good code in the literature to read, understand, and use as a source of exemplars.

It’s not that you can’t write awful Rails code, but you have to work at it a little harder! If you trust your sense of smell when you find yourself working in Rails, you know that you are probably doing something wrong, and should look for examples of how others solved similar problems; and you’re very likely to find those examples without much looking.

Rick DeNatale, retired IBM Smalltalk Guru, principal of DenHaven Consulting and Terralien crew member

At numerous sweet at the mid-night

I say I love Rails

The night also becomes thus beautiful

The stars cannot help but blinking eye

The beautiful Rails world

I love you

I asked myself over and over again

I don’t love you to love who

I love you, Rails

Hackem, university student in China

In my experience, first as an employee, and now as a company owner, the Rails way can be summed up with Three Cs—collaboration, consistency, and contribution.

Collaboration: Doing things “the Rails way” means not only tighter collaboration between team members, but also tighter collaboration with our clients. Between team members, there’s a tangible feeling of excitement in using Rails to its fullest potential, resulting in code reviews that are dynamic and educational, instead of mind-numbing or incomprehensible. In client interactions, it means more frequent release cycles, and feedback at earlier stages. We hit a lot closer to the moving target with Rails than we did with PHP.

Consistency: Coming from a background in a variety of languages and frameworks which did not take an opinionated stance, I’m all too familiar with how hard it can be to decipher another programmer’s coding style. Embracing the Rails way has reduced the time we spend explaining ourselves to each other, and simply puts us all on the same page. This has been invaluable to us.

Contribution: By doing things the Rails way we’re in a much better position to give back to the community. While I’ve been a consumer of open source software for at least the past dozen years, Ruby on Rails is the first open source project to which I’ve contributed patches (and felt the joy of seeing those patches merged into the Rails core). Contribution is possible at any level, too. Plugins, gems, documentation, blog entries about new discoveries, or even just volunteering to speak at local Rails events. The cooperative spirit that seems to emerge from the Rails way is one I’ve not seen paralleled in any other software project, and I’m excited to be a part of it.

Jared Haworth, founder of Alloy Code, a web development company based in Raleigh, NC

For me, the Rails way represents freedom. The freedom to concentrate on writing solutions and not compiler fodder. The freedom to learn one underlying language and not esoteric configuration file formats. The freedom to mold said language and solution like a lump of clay into an elegant piece of software and not be thwarted by language or API designers who feel they know best. The freedom to have fun, again, to not mind the long, hard hours put into crafting a beautiful piece of software. The freedom to return to the familiar land of dynamic languages.

Mel Riffe, former Smalltalk programmer

The Rails way is about finding the most beautiful answer to any problem. These solutions are not found by one-off hackery, but by building upon smart conventions and principles with other developers. It’s about keeping the obscurists out and bringing the artists in. Viva la Rails way!

Hampton Catlin, self-proclaimed Ruby Prophet

Rails has taken me places that I had forgotten existed. I recall a time not so long ago when I sat up late at night slowly grasping the joy of software creation. College was a time for exploration, for pushing the limits of my mind and my capabilities.

Then Corporation and Comfort snatched me from Excitement and Growth. Education was pushed back in my mind as I was molded into a standards-based automaton. Work just enough to impress, but don’t even attempt to wow. Good enough was great and great was a pipe dream.

The epiphany that I was whiling away my passion for a consistent paycheck arrived suspiciously close to the moment I discovered Rails. Rails led me away from Corporation and back toward Fulfillment. Ruby slapped me in the face and left me smiling at the sting.

Barry Hess, who can be found speaking in tongues at bjhess.com

Rails has strong opinions about a particular way of rapidly building end-to-end applications from the simple to the complex with minimal effort and tight integration. Each developer should experience the Rails way of building web applications so they can decide if that way can be their way, and to learn what they can from that approach to take forward into their own work.

Geoffrey Wiseman, software development generalist and writer/editor at large

The Rails way is being part of a community dedicated to helping each other work smarter, build better products, and have more fun doing it. It’s about the freedom of not being beholden to any single company. The Rails way is a path beaten out by people who care about beauty and craftsmanship in software development, and when you walk it, you do your part to mark it for those who will follow.

Luke Melia, railing away in NYC

Rails—beauty in code

Creative, fun, and perfect

Future that is pure

David Parker, all you need to know at davidwparker.com

I started programming when I was 13—I remember that summer well; it was the end of playing outside and skinned knees for me. I found the BASIC Programming book for our TRS-80. My monitor was a TV, my files were saved on a cassette tape, and my printer contained 5-inch wide thermal paper. I was hooked on programming. Over time, I upgraded my computers as well as my programming skills, learning more versions of Basic and C/C++. After four years of Pascal and one semester of Java in college, I picked up a PHP book and learned PHP and landed my first job. As I grew as a developer and became more familiar with web development, I struggled with good design such as MVC, database rows to objects and templates. I tried to come up with a web framework and experimented with a few. None of them made it simple enough or even logical enough. The typical CRUD part of development wore on me because it was so tedious and repetitive. Web development for me became boring and such a drag! I entered into about two years of what I call “programmer depression” where I was not excited about anything code-related and I would come home from work and not even turn my computer on.

Programming communities are inspiring. In 2006, I reconnected with developer and friend Keith Casey after a few years where we had no contact. He was involved in some open source projects, including DotProject, a LAMP-based project management application. I did some contract work with him and got involved in the open source community and participating in the forums for projects by helping answer questions and discuss design. He encouraged me to attend local user group meetings in Chicago. I found the Chicago PHP group and met some Perl programmers (shh, don’t tell anyone there were Perl people at a PHP meeting!) and started learning Perl, then later found the Ruby group. I was soon attending three user group meetings a month—Ruby, Perl, and PHP. Occasionally, I visited the Python group. I was learning new things and being around other programmers both in person and through open source projects. At that time, I was the only programmer in the company and I was starved for some geek conversation. PHP is nice for some applications because it’s so easily supported on most web servers. Perl I loved because of its testing libraries and its flexibility and I learned a lot about design. Rails I loved because it made MVC make sense to me; ActiveRecord lets me map database rows to objects with ease. Scaffolding made getting basic CRUD done quickly, leaving me the time and freedom to work on the business logic of the application. Programming was fun again!

Rails is agile. As my growth as a developer continued, I learned the agile/scrum process and Rails was a natural fit. Scaffolding helps me to prototype quickly and get feedback from the customer early in the process. One day, a business analyst came to the developers needing an application and was trying to explain what he needed. We had a similar application already, but he just needed a few things changed, which would unfortunately require significant redesign. After hearing him talk for 15 minutes, I walked to my desk and with the help of Streamlined created a basic Rails application with a few controllers and models. I had created a nearly complete site within the hour. I showed it to him and after I customized the forms the way he wanted and added a few more features, I had a production-level application deployed in about 18 hours.

Rails allows rapid development. Another thing I’ve learned is that managers who are used to languages other than Ruby may have a hard time with the rapid development of Rails. In one case, I had some tasks for a project and was given a lecture about how it’s too much work for the hours estimated. Further, I could not possibly be creating quality code if I did manage to get it done within that time frame. I knew I could do it and with quality code! I left that meeting with determination and even took the time to explain the process to a person new to Rails as I created my RESTful Rails site, used scaffolding, then customized the parts that were particular to my needs. I ran the tests (46 of ’em!) and it was done. Just in case there was criticism about my code being high quality I ran rcov (a test coverage tool) on my tests and had 100% test coverage. How ya like them apples?

Rails has given me confidence and boldness. Normally I am a very timid person and don’t often initiate conversations with strangers. One day, I’m on my daily commute via train to Chicago when someone sat next to me with a Play Station Portable (PSP) in a unique case. I asked him about his case and talked about how I am going to steal my husband’s PSP one of these days and put linux on it. He said he was a mainframe programmer and didn’t like it at all. He wanted to get into web development. So I immediately start in about Rails, sharing the highlights of the framework and how much I like it. He started writing down notes. I told him what sites to go to for more info, what books to read, and I even let him watch the classic “Rails Blog in 15 Minutes” video on my laptop. I keep watching for him on the train to ask if he’s tried it yet!

More than anything, I try to use the right tool for the job. I like multiple languages and Ruby with Rails is the one I choose for web development in most cases. I may choose PHP for a site if it has only one dynamic page or a site that just needs an email form. Perl is great for system tasks or data processing. Each of these languages has their strengths and I will not put anyone down who thinks otherwise. I think the biggest problem is the lack of community among developers across languages. It’s usually someone trying to point out why X language is no good. Come on guys... that doesn’t help anyone. You can learn from other languages even if it’s not your primary language. Sometimes when I am programming in one language I think of how I would do it in another. Often, thinking “outside the box” like this will guide me to the right solution.

Rails has definitely inspired me and changed the way I think about web development. The community surrounding Ruby/Rails is outstanding and that makes me a better programmer.

Nola Stowe, Language Geek

The Rails way is pragmatic to its core, born from the twin forces of deep experience and the need to solve the real-world programming problems at hand. It dumps conventional wisdom on how things ought to be done and, instead, takes a fresh look at the mitigating the real impediments to developer productivity.

Curt Hibbs, author of the most successful online tutorials for Rails

Some days, I think it means expressive, iterative, simple, elegant web development.

Some days, I think it means ignoring decades of collective wisdom and inventing a wheel made of cornstarch—it’s more lightweight, and we’re probably not going too far, so why overengineer?

Some days, I think it means “F*** you.”

It’s one of those days.

Jay Levitt, former chief mail systems architect at America Online, lives in Boston, MA

The Rails way is all about making programmers happy. It’s about automating, abstracting, and refactoring until a web application can be written in the fewest number of lines needed to get the job done. It’s about making it easier to write the right kind of code than the wrong kind.

And when programmers are happy, they can focus on writing great applications that make the user happy, too!

Geoffrey Grosenbach, PeepCode Publishing and voice of the Ruby on Rails podcast

“c7Fd9uk3nu4ck0td8iv9oz1nv0ak5ljjSw2iv6mu9pz1ly3im0cq7il4ta2y”.gsub(/wd/,”).gsub(‘jj’,’ ‘)

Jeremy Hubert, being his silly self

Working with Rails feels like pair programming with a talented, experienced, and opinionated web developer. If you can swallow your pride and follow Rails’ lead, great productivity gains await you. If you have strong opinions about web development and database design, there are going to be arguments, and your productivity will languish. Initially, developing the Rails way means humbling yourself, surrendering to the opinions of Rails, and seeing web development through Rails’ eyes. But take heart! As you learn Ruby, your arguments with Rails will begin turning in your favor. Eventually, developing the Rails way means listening to Rails’ opinions, picking your battles, and through the power of Ruby, bending Rails to your will.

Dave Hoover, software craftsman

There’s a line at the beginning of the SICP lectures—a famous course on functional programming—where Harold Abelson is defining “computer science” for his class:

In the same way, my sense of “the Rails way” is not really about Rails, Ruby, or any of these new tools we’re using. Its “essence” is an uncompromising drive to optimize for productivity and happiness. It’s a hard-learned pragmatism: Processes for people who refuse to solve the same problem twice, who are annoyed enough by the speed bumps their tools sometimes introduce that they happily gas up the steamroller.

A necessary corollary to the idea that Rails’ secret sauce is distinct from the code frozen to our vendor directories is that one day, a better instantiation of these practices will come along. I love Ruby, Rails, and their communities, but I know that we’ll all move on at some point. When that day comes, and some new 10-minute screencast makes us squeal like kids, we should have the sense to jump into it head-first, with the same abandon with which we dropped all that stuff we used to do for a living.

Chris Kampmeier blogs at http://www.shiftcommathree.com

If DHH ain’t doing it, you don’t do it. (Seems every time some clever fellow gets into trouble it’s because of that.)

Zed Shaw, author of Mongrel web server