FiveRuns Blog

Coming off an awesome RailsConf, we’re picking back up the FiveRuns TakeFive interviews, our ongoing series of insight and commentary from notable members of the Ruby and Rails community. This week, we’re pleased to have Jeff Cohen, co-founder of Softies on Rails share his views on Ruby on Rails with us.

FiveRuns: Welcome Jeff, and thanks for taking the time to join us. Let’s get started with a question spurred from the recent Ruby Hero Awards. Who is your own personal Ruby hero, and why?

Jeff Cohen: Without hesitation my vote goes to Geoffrey Grosenbach. The official Ruby on Rails podcast had a big influence on me when I first started learning Rails. It was one of the few sources of information I had available to me when I was trying to understand what Rails was all about, and the podcasts just hit the spot every time. His innovative approach with PeepCode screencasts has set the standard again. He’s also one of the living examples of the “Matz is nice, so we are nice” standard that the Rails community would do well to emulate more often.

FiveRuns: Obie Fernandez’s startup Hashrocket, which has been blogged about extensively, is all about being ultra-productive in 3 days. Obie has written about ultra-productivity, but we have to ask – what are your own tips around, to paraphrase Obie and 37Signals, getting real—on steroids?

Jeff Cohen: I’ve found two danger areas where my productivity curve begins to like that deep chasm Gandalf fell into. The first is overdesigning. It’s too easy to build more than you really need. I think I’m being smart, but I’m just wasting time. So I recommend: write tests (or specifications, whatever you want to call them) first. You’re less likely to get too clever. However, you should write them at the highest level of abstraction that you can get away with. High-level tests are good. They give you the freedom to innovate. Testing at too low a level tends to lock me into the “usual” way of solving the problem. The more high-level the tests are, the more creative the solution code can become.

The second productivity gravity well is any UI design work that doesn’t involve coding. Draw on a napkin or photoshop something all you want, but it really means nothing until you see it on the screen. So don’t prototype anything paper if you can avoid it. Start with simple, raw HTML. Inline the styles if you have to. The goal is to go from idea to browser as fast as possible. Make it ugly, just make it work. You can refactor it later into real HTML/CSS/ERB templates once you’re happy that you’re on the right track.

FiveRuns: What was your first “ah-ha” moment with Ruby on Rails and when did you know that the framework was a good fit for you?

Jeff Cohen: It was the fall of 2005, and my friend Brian Eng in the next cube over asked me if I had ever heard of this new thing called Rails. Now, this was back before there was even a 1.0 of Rails - I think it was version 0.13. We were both working as .NET developers at the time. I enjoyed .NET development for desktop applications, but didn’t really get the hang of ASP.NET so I always kind of shied away from web development, even though that was what I really wanted to learn how to do. Anyway, we started learning some Ruby on Rails to see what the buzz was all about. We helped each other figure things out, and pretty soon I had a simple one-model web application running in my browser. It was eye-opening. I used the Ruby One-Click Installer for Windows, the Rails gems, and about 10 lines of code in Notepad. The whole convention-over-configuration thing was just awesome. Rails was easier, more logical, and simply more enjoyable for me than ASP.NET. Within a year, I walked away from my 12-year-long Microsoft-based career to accept a full-time job doing Rails development. But the thing was, I was lucky to have someone like Brian introduce Rails to me, and to learn from. I would never have made the switch alone. So nowadays I try to spend time helping others when they decide to switch to Rails, too.

FiveRuns: Along those lines, do you have any specific recommendations for people switching to Rails from another language or framework?

Jeff Cohen: First, they should learn Ruby apart from Rails. When I see ugly Rails code, a shallow understanding of Ruby is often to blame. The better you get at Ruby, the better your Rails code will automatically become. Second, learn how to model your domain properly. I know Ajax is fun to do, and it’s also easy to put all your logic into your controllers. But the best Rails apps also have a rich, cool domain model. Their models are the gears for the application. The controllers decide which gear needs a nudge, and wonderful things seem to happen. Finally, read! Get a couple books, read blogs, and read other people’s code. Don’t just Google for code snippets and then ask for help when you get stuck two minutes later. You really need to learn the basics first. And once you’ve starting to get your feet under you, start helping others who are just starting out. You inevitably learn something yourself, and it’s a way you can immediately begin to give back to the community.

FiveRuns: Let’s talk a bit about Rails 2.1, which was recently released with the help of over 1400 contributors. What about the new release excites you the most—and as a follow-up, what are the most important things in your mind to get done for the next major release?

Jeff Cohen: I was glad to hear from people who went to RailsConf that Jeremy Kemper spoke about how the core team is focusing less on new features these days, and more on security and scalability. I think the overall feature set of Rails is quite strong. If anything, I want less. I cringe a bit when I see pleas for more configurability. I don’t think that’s what we need right now. Rails must remain good at its core purpose: database-backed web applications. I want it be very opinionated. I love conventions that make things really easy for the 80% case. But one thing I do wish for, is an easier way to share code among Rails applications. Plugins work well up to a point. I think most people would like an easier way to share an entire MVC “molecule”: a model-view-controller capsule that can be shared among applications. It’s not an easy problem to solve, and it’s not like I have a solution for it yet, either.

Jeff Cohen has worked with object-oriented programming languages and frameworks for more than 15 years. A former MCSD, he co-founded the SoftiesOnRails blog at www.softiesonrails.com in 2005. He is the founder of Purple Workshops, and is currently writing a book with Brian Eng titled Rails for .NET Developers to be published by Pragmatic Bookshelf this fall.