FiveRuns Blog

Welcome to the Rails TakeFive interview series, where we have a virtual sit down with leading developers from the community and bring you their insights into all things Ruby and Rails.

This week, we're bringing back a popular theme and hosting a Campfire chat between FiveRuns developer, Rubyist and Raconteur Adam Keys and Glenn Vanderburg, noted Rubyist, speaker, author, and the Chief Scientist at Relevance.

In this chat, Glenn and Adam talk about testing, the Ruby Community, framework philosophies, VM implementations, and more. Let's get started!

def index
  @posts = Post.find(:all)

  respond_to do |format|
    format.html
    format.xml  { render :xml => @posts }
  end
end

  @posts = begin
    args = [:all]
    options = args.last.is_a?(::Hash) ? pop : {}
    Post.validate_find_options(options)
    Post.set_readonly_option!(options)

    case args.first
      when :first then Post.find_initial(options)
      when :last  then Post.find_last(options)
      when :all   then Post.find_every(options)
      else             Post.find_from_ids(args, options)
    end
  end

  @posts = begin
    args = [:all]
    options = args.last.is_a?(::Hash) ? pop : {}
    Post.validate_find_options(options)
    Post.set_readonly_option!(options)

    Post.find_every(options)
  end

Glenn Vanderburg has more than 20 years of experience developing software across a wide range of domains, and using a variety of tools and technologies. Glenn is always searching for ways to improve the state of software development, and was an early adopter and proponent of Ruby, Rails, and agile practices. He is also Chief Scientist at Relevance.

Welcome to Rails TakeFive, FiveRuns’ periodic discussion about Ruby on Rails with noted developers from throughout our community. This week, we’re honored to be joined by Jay Fields, noted software developer, author, and speaker.

FiveRuns: Welcome Jay! And, thanks for taking the time. Let’s kick it off by getting your thoughts on the community. Can you name a few relatively unknown or unheralded developers who you think deserve to be recognized and tell us why they rock?

Jay Fields: George Malamidis, Philippe Hanrigou, Pat Farley & John Hume are all not as well known, but superstar developers. I’ve worked with all 4 of them on projects and I would go out of my way to work with all of them in the future. They all possess the fantastic combination of being both innovative and pragmatic. They all have blogs, speak at conferences and contribute to open source. You might not have heard of them yet, but you definitely will in the future.

FiveRuns: Okay, we’ve all made mistakes. Name one of your most embarrassing moments of FAIL, or one of your biggest rookie gaffes.

Jay Fields: Several years ago I was working for ThoughtWorks and I became the Tech Lead for a team building a Ruby application that used a DSL for the business rules. It was the most interesting work I had ever done, but I made a huge mistake. It was a very short project, 3 months in all. In general I believe that premature optimization is a mistake, but on a timeline that small we really needed to start looking at speed early in development. Unfortunately, I didn’t make it a priority. In the end we spent the last 2 weeks of the project working on the performance, and barely got the project out the door.

FiveRuns: Do you agree that Rails presents a big opportunity in the current financial environment, because of the 5-8x productivity boost, the fact that Rails is open source, and the limited accompanying infrastructure costs? How is the economy affecting your work and/or your livelihood?

Jay Fields: I think Rails presents a big opportunity regardless of the financial environment. In fact, I think history shows that to be true. Companies didn’t start adopting Rails because of the financial environment. The adoption of Ruby/Rails has been on the rise since it’s introduction. I do think adoption will slow eventually, but not until all of the talented Ruby/Rails developers are out of the job market. Ruby absolutely makes better programmers more productive, companies would be foolish to ignore that whether they are up or down. Ruby isn’t the answer to all problems, but if it is an answer to your problem and you choose a more ceremonious language, you’re probably making a mistake.

The economy hasn’t had any impact on my livelihood. Computers have become so integral to everyone’s life, I don’t expect any good programmers are out of work. In fact, regardless of the financial environment, I think good programmers will continue to enjoy larger than average raises. If you aren’t getting better than average raises, you either aren’t as good as you think you are, you are trading money for some other form of happiness, or you’re missing opportunities.

FiveRuns: Mike Gunderloy recently did a post outlining the process for contributing code to Rails. What was your very first contribution? What motivated you to get started? Nowadays, how much time do you spend battle-testing your code with friends and fellow developers? How often do you make use of the rubyonrails-core mailing list or the #rails-contrib channel on IRC?

Jay Fields: I’ve never actually had a patch committed to Rails, but I’ve had a few ideas that ended up making it into Rails in slightly varied ways. The most popular is probably the test class method that can be used when writing tests in place of defining test names that start with test. I was motivated to contribute to Rails because I felt that the current options were inferior to what was available, and I was tired of customizing Rails with each new project. There’s also a nice feeling (for me anyway) when you have an idea that can help the community as a whole. I’ve never used the IRC channel, but I’ve found the mailing list to be a great testing ground for patches.

FiveRuns: Have you ever taken a Ruby-related course or seminar, either in-person or virtually? Who are some of the best teachers and courses out there? For nubies? For pros looking to break through to a new level?

Jay Fields: I spend a fair amount of my time learning. I’ve always been in the work-smarter-not-harder camp. In the past few years I’ve attended as many as 6 conferences a year, and there’s almost always a few great presentations. I’m a big fan of conferences usually, but I’ve also been happy with the Pragmatic Studios and The Rails Edge mini-conference. There’s so many great guys in that group: Chad Fowler, Dave Thomas, Mike Clark, Stu Halloway, Justin Gehtland, Marcel Molina Jr, Ezra…. there’s really too many great guys doing Ruby and presenting to name them all. I’m also a huge fan of Geoffrey Grosenbach and PeepCode screencasts. Between those guys there’s information for everyone from a Ruby hobbyist to a professional Ruby developer.

Jay Fields is a software developer and consultant at DRW Trading and www.jayfields.com.

Jay is also the author of Refactoring: Ruby Edition and a contributor to Advanced Rails Recipes.

Welcome to this week’s Rails TakeFive, our weekly discussion about Ruby on Rails with noted developers from throughout our community. This week, we thought we’d take a little different tack and bring you words of wisdom from one of our customers on how they use Rails and FiveRuns Manage to help keep their site humming.

James Elwood is Network Ninja Master for Geezeo.com, a free web-based personal finance application that makes it easy to track all your finances, see where all your money is going, set financial goals and learn from others. Built in Rails, it’s an awesome application and community, and has received a ton of great buzz from the financial community.

FiveRuns: Welcome James, and thanks for taking the time to share your thoughts! Let’s start by talking about how you got started with Rails at Geezeo. When and why did you decide to build Geezeo on Rails? What are some of the biggest benefits you’ve seen?

James Elwood: I came on board a little after Geezeo made the decision to build on Rails. One of first early iterations of our product was built in PHP by an outsourced team. This first iteration provided an initial idea for the site but did not allow a process where the team could rapidly take an idea and make it functional in a short period of time. Coming out of the outsourcing experience the team had been reading Agile Web Development with Rails. Because of this experience and all the buzz in the industry about Rails, we decided to go with Rails full steam ahead.

Sitting back mainly on the sysadmin end I am impressed with how rapidly the team can take something sketched on paper and push it out the door. In prior jobs, often the littlest changes would involve stepping back through legacy code trying to shoehorn in new features with no guarantee that a deliverable would happen in the current quarter or even year. The challenge for me in supporting them is just trying to keep pace with them as the requirements shift and they find new and inventive ways to boost performance and streamline operating costs. My experience is that Rails and the development methodologies surrounding it play a huge part in our ability to dream, design, build, and deliver.

FiveRuns: How has FiveRuns helped streamline and enhance your systems management processes?

James Elwood: By nature I am lazy and have an extreme dislike for perpetual repetition. I also hate re-inventing the wheel when I could be innovating the next big thing. But let me clarify, lest my bosses think that 70% of my time on the job is spent asleep. My feeling is that if you can automate a task then do it because that will free you up to tackle more pressing tasks or ones that add increased value.

At my last job we had the horrendous daily task of writing out the back up logs. (Literally writing them out. By hand, With pencil and paper). It was one of those jobs that you grit your teeth and wish that you could convince the powers that be to look at how you could manage that process by exception. FiveRuns lets me do that for Geezeo.

I rest easy knowing that FiveRuns will wake me up in the middle of the night to tell me that something is wrong with the server. Glancing over graphs on the dashboard gives me a quick and concise view of how my entire stack is performing and if something looks amiss I can drill in for more detail. That beats gnawing on the end of a pencil logging into every server, every morning of every workday. If anything FiveRuns has lowered my pencil budget substantially.

FiveRuns: Can you name a time when FiveRuns was vital to Geezeo’s upkeep?

James Elwood: FiveRuns helped point out an oversight on my part that killed our MySQL backups for a better part of the day (not one of my prouder moments!). We use replication so that we can have an online spare as well as for backups. Since we have been on EC2 since the early days we got into the habit of using mysqldump to get a snapshot of the database off the slave and tossing it up on to S3 for the inevitable “what if?” scenario.

The problem started when I forgot to uncomment one little line in the backup script, the one about stopping the slave. The slave was dutifully replicating while earnestly trying to dump the database to file and in the process just getting plain ugly with itself. So one morning, on a chart scanning expedition, I noticed that the CPU on the slave was tweaked which led me to check into what the instance was or was not doing.

By pointing out my shell scripting oversights, FiveRuns also made it obvious that I really ought to write a report that tells me if I missed any backups in a given period (no way am I picking up that pencil again). Being reminded of my shortcomings and mistakes is critical for me to not drop the ball. I guess in that regard, FiveRuns is like my mom on the job, “Don’t forget to look over your homework and when you get a chance would you please clean out that temp directory sometime this century?”

FiveRuns: How has using FiveRuns improved the user experience at Geezeo?

James Elwood: Soft spots and weaknesses, that it what I am looking for when I use the service. Is there anything on the server side that I can tighten or add capacity to? Are there any controllers that are sucking the life out of the Internet that the team should be made aware of? FiveRuns is part of the process aimed at refining and improving our stack. I’m never really satisfied with anything I work on because when I get the chance to step back I can see where I could have done things differently so I use the service to continually solicit feedback with the hope that I can make the things I do feel a little less unfinished.

FiveRuns: What types of product features or integrations would you like to see in the future from FiveRuns?

James Elwood: Some of the things I love to see is more push reporting, there are times when the work load gets too much and the only applications you might have open are mail and a terminal. Getting the charts pushed out in an email even on a weekly basis would be nice, especially the application metrics. If that could be configured to report on the pieces that a developer is working on and just push those metrics out on how it is performing in the various the environments we are monitoring it could be a big win. Everyone is often heads down during a sprint and can loose sight that the sun still comes up and goes down everyday. Combined with TuneUp I think it would give developers insight into how the code is performing.

James Elwood is the Network Ninja Master for Geezeo.com, the go-to guy for all networking and web development projects. With 10 years experience in network administration and information technology, James has been a integral part of Geezeo’s success. Before coming to Geezeo, James served as Network administrator for BKM total office, one of the worlds largest distributors of Steelcase office furniture. James holds a Bachelors degree from Connecticut State University and an MBA in Technology management from the University of Phoenix.

Welcome to this week’s edition of Rails TakeFive, our weekly conversation with Ruby and Rails developers from around the world. This week, we spread our wings to the Czech Republic and welcome Karel Minařík, an independent web designer, developer, instructor, and organizer of the Czechoslovakian Ruby Users Group.

FiveRuns: Welcome Karel, and thanks for taking the time to share your thoughts with our readers. Let’s get started by talking a bit about GitHub. The community has really taken off, especially now that the Rails repository has been moved over. Can you talk a little bit about the benefits of Github and how SCM and agile development go hand-in-hand?

Karel Minařík: I think Github is the true Facebook for Ruby and Rails developers now. Starting to use Git alone was a small revolution in how I see version control. Previously, having been using Subversion, it was more like necessary evil — a good practice, precaution and a way how to collaborate on codebase. Git changed everything about that, in the way it blends into my workflow with its easy branching and merging, remote repos, transparent ignore rules, …

“Automagic” branching and merging really is a killer feature for me — when I start working on a new feature now, I regularly create a new branch, write the code and tests and then merge back into master. I keep a “deploy” branch for every project, so it’s easy to provide hotfixes, etc etc. Very hardly would I undertake such adventures in branching and merging with Subversion. Also, the distributed nature, being able to work with the repo on limited connectivity, and knowing that every repo copy is self-sufficient, is very, very nice.

But Github is just another story. Github and the community around it pushed Git usage on a completely different level — in the way it blends “Sourceforge like” code repositories with the “social” features pioneered by Flickr and others: commenting on commits, subscribing to notifications about projects, exchanging messages, …

It’s lot more fun to publish some code when you know there are thousands of other people possibly interested, eager to learn something new and even to help you out. It happened to me with my demo app for the new Rails localization API — instantly Sven Fuchs of i18n core picked it up and was helping me to keep up-to-date with the fast pace of changes to the API, tried a couple of tricks with the complex pluralization rules, etc. I also got people writing me about some “gists” I posted, using the snippets in their code… It is very, very inspiring experience.

Important is, that it puts emphasis on the source code itself, as in Linus Torvalds’ dicto: “Talk is cheap. Show me the code.” The focus shifts from the plain “what does the code do? is it useful to me?” point of view to the code itself: how well architected is it?, how well documented?, has it got a README?, are there any neat Ruby tricks I could learn?

I even find myself more compelled to publish code instead of articles, thanks to Github. You can find great amounts of code on Github, people publishing their own blog engines, packaged solutions, and more. I envision even, there will be a time, when whole contracted (i.e., “commercial”) applications will be open-sourced. Because contrary to what the developer may be thinking, the code “doesn’t matter” in a sense. (As well as stating “but it works” doesn’t matter. When the code doesn’t “work”, it is not even code, it is some sequence of characters: that the code “works” is a pre-requisite for everything else.) The ideas expressed in code matter. There will be no need to guard code in some vault: the ideas embedded in it are very, very hard to “steal”.

FiveRuns: Bruce likes to talk about “backpacking” through other languages. What others have you dabbled in and/or are you learning right now? How have these travels impacted your work in Ruby? Your overall approach?

Karel Minařík: Well, I think the idea of getting “fresh perspective” just by using another programming language for a while is quite exaggerated to some extent :). It’s a pretty low-level point-of-view, that just by coding something in Erlang you’ll pick up some magic powers elevating your skill. What’s quite more important in my opinion and what this topic leads to, is the stress on practicing.

The web programming we do daily is much more craft than science, math and best fine-tuned performance-optimized database query. When you play guitar for example, you’ll know, that your skill deteriorates pretty fast when you’re not practicing, experimenting, learning new licks, fooling around with gear. Jimi Hendrix used to practice almost all the time. It’s the same with programming. It’s essential to practice, experiment and explore your skill aside from the “regular” work.

Here I found much reluctance from my peers to do so: “there’s no time” is the usual statement. Regularly I find the “I am not proud of this piece of code” attitude as well, which is related. Imagine if you would be a guitarist and played only gigs, or worse, played only as an anonymous studio musician. Your skillset would quickly become very limited and your happiness from playing guitar would quickly drop near zero. I attribute this “unwillingness to play” to much failures and dead-ends we encounter daily in software development.

FiveRuns: Beyond Rails, beyond Merb, there are a great number of alternative frameworks for Ruby, including Nitro, Waves, Sinatra, Ramaze, and even the microframework Camping. Do you have any experience working with these frameworks? What have you seen so far that you really like? Dislike?

Karel Minařík: Sinatra, definitely. Sinatra is such an awesome concept: let’s just drop everything and focus on the very basics of a web application. Let’s drop routing, helpers, database abstraction, everything and focus just on getting some URL, run some code, and return back some response. It is related to the practicing topic above: Sinatra makes it unbelievably easy to do some exploratory programming, try out a concept, while still following the best practices like MVC separation of concerns and RESTful orientation. Sinatra is the true “all you need, none you don’t” to me. Of course, Camping was probably the initial kick, “hey! let’s just make something different and have some fun, should we?” — which is the regular pattern with almost everything Why The Lucky Stiff does.

Merb itself doesn’t bring much conceptually new to the table. The idea of “agnostic to everything” is quite refreshing nevertheless, because it’s in direct contradiction to Rails. But Rails to me was and still is about the best practices in web development. Implementing MVC properly and painlessly (the famous “no XML sit-ups” quote), baking in testing from the beginning, embracing RESTful point of view, abstracting common things like dates calculations to transparent domain specific language, things like that. That was the punch delivered by Rails to everyone in the “web applications” field. That is the true sense of “opinionated” to me and I think the web-application space needs such opinions. But Merb to me is above everything a much needed competitor to Rails. Because without competition you risk inertia — the only motivation factors remaining are pride of your work, commitment to users, such things. You obviously still can deliver amazing “product”, but it’s more and more fragile as time goes. So “Go, Merb!” (particularly the slices and parts ideas), as far as I am concerned :).

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

Karel Minařík: Hmm, “ultra-productive”. Sounds dangerous to my ears, all this emphasis on productivity, getting things done (“in no time”), and such. You’ll find lots of people picking up Rails recently only as a tool to deliver some functionality very quickly, with very low cost, with little deliberation. Just a “bigger chainsaw”, hacking down more trees in less time. But what is productivity? Number of features implemented versus time? Does it really lead to durable code? And more importantly: does productivity in this sense really matter so much? Isn’t it important to leave an application some room to grow instead of focusing on “building” it quickly?

The idea of Hashrocket, on the other hand, is plainly awesome. That’s just what the clients would love most: having an idea implemented quickly into some “deployable prototype” to try out how it works. Because you hardly know how something interactive works until it is implemented. It’s an awesome marketing incentive and I have great respect for Obie for coming up with that. This “ultra-agile” approach, when done in small steps and lots of iterations, is the way to make the kind of web applications Rails is destined for. I would just not put it in the same bag with “productivity”.

As for my own tips, I have one: I have found that to be able to come-up with something quickly and not be scared of it, is to do it the “right way”. It means no hacking around, no “I have no time to research this”, things like that. When I had to design a solution for a localization-heavy website recently, I had studied all the tutorials on the new Rails i18n stuff, and came up with a public demo application for it, played around with model translations then, and generally researched the “right way” to do it. To my own astonishment, it didn’t eat as much time as I anticipated, and I had incomparably bigger confidence in the code and my knowledge afterwards. Which in turn “boosts your productivity”, because you’re not constantly mentally tracking everything and you are feeling plainly “much better” about everything. This “feeling” may be hard to pin down and probably is not “measurable”, but essential nevertheless. It’s the “happiness as productivity factor” David Heinemeier Hansson stressed from the beginning.

And writing tests, of course, writing tests :). I don’t see tests as some magical weapon against bugs (there always will be bugs). I don’t see much point in elaborate Selenium-based setups for common apps, but I do see tests as a wonderful protection against myself: “oh, I have changed the attribute name or method return value here, where are the places I should have changed the implementation?”, “I should refactor this code but I am scared that I’d knock something out”, “the code in this app I made half a year ago is kinda embarrassing but let’s rather leave it as it is”. Moreover, in Ruby’s dynamic environment, tests are just a part of your code like everything else. (And here lies the spot where I see the “refactoring features” of IDEs miss the point almost completely.)

FiveRuns: What do you think about Ruby’s role in education? Do you think Ruby is suitable as an introductory language or even as a general instruction language?

Karel Minařík: Well, this is an important topic that deserves much more light that it currently has. I do think Ruby would be very much suitable as an introductory language to programming. I have spent one semester teaching “Programming 101” to non-programmers (New Media students) last year, and I have used Ruby to great result. The students didn’t have nearly any previous experience with programming — the only “programming” some of them did was making HTML pages.

We have covered topics like what is an algorithm, basic “vocabulary” like variables, functions, conditionals, loops, why object-oriented programming matters and is the sane way to go now. In the end they were able to perform some trivial text-analysis and write an Hpricot-based web parser. Some of them picked up interest in Ruby and started writing some console-based programs just for fun. Almost everyone walked away with fundamental understanding of “what those programmers do all the time anyway?”

I attribute much of that to Ruby principles: expressiveness and succinctness. I suspect a course drop-out rate of 80% if we would constantly bang our fingers and heads against public static void main. Ruby just makes you focus on the important things: what is it you’re trying to express and how transparently the code expresses it. It’s much more easier to just “show the code” to illustrate something than to write pseudocode or draw diagrams. In Ruby you can see the essence of writing code very clearly, “without all the curly braces” so to speak.

There should be some activity to get “more Ruby in schools”, I guess :). There was the great attempt with HacketyHack by _why, but that never really got “out of beta”. Moreover, I think the browser is the ideal platform for beginners, not desktop applications: you get instant gratification, you can easily show it, it is properly sandboxed, … So if services like Heroku or “never outta beta” IsOnRails would mature more, that would enable us to teach programming much more effectively.

Ruby’s strong “philosophical background” makes it ideal in my eyes for advanced education as well, because a) of the aforementioned lack of overhead and because b) its focus on domain-specific languages (and language in general), which I suspect will become a much more common approach –– you can see it in the popularity of JavaScript frameworks like Prototype or jQuery. Current academical computer science is very much pre-occupied with the low-level, technical aspects of programming, and too little with its essence: grasping reality and converting it to a set of rules, descriptions and procedures. As Wittgenstein would say: “The world is the totality of facts, not things.”

Karel Minařík is an independent web designer and developer with focus on clean architecture and user interface with rich interactivity. When Ruby On Rails re-ignited his passion for programming, he left Information Architect position at an agency to get back to development. He abandoned his Czech blog about Rails recently, and has some better ideas on his mind now. He lives in Prague, Czech Republic with his wife and two daughters, who are making it all possible. Find his website at www.karmi.cz.

Welcome to this week’s edition of Rails TakeFive, our weekly chat with prominent players around Ruby on Rails. This week, we’re happy to welcome Karmen Blake, noted Ruby on Rails developer, teacher, presenter, and software engineer for Salt Lake City-based GeneTree.

FiveRuns: Welcome Karmen, and thanks for taking the time to share your thoughts. Let’s get started by talking a little about test-driven development. Our own Adam Keys recently gave a talk at RailsConf titled Oh, the Fail I’ve Known. In the talk, Adam outlined a few different kinds of fail: learning failure (the knowledge was available but you didn’t have it), technological failure (you did have the right tool), problem failure (barking up the wrong tree), and so on. If you don’t mind, give us an example of the fail you’ve known?

Karmen Blake: I remember having my eyes opened to test-driven development. I started working with a guy who was big into TDD. I had not been exposed to it before. He showed me he was writing tests, and I thought that was cool for him but not for me (“I just want to crank code!”). Then I started breaking his tests without knowing it and he would come talk to me about why his tests are there and feel free to fix them or add my own. I would think “Why? Just whip out the code!”. His visits to my desk, with patient frustration, increased as the code base grew and his tests were breaking when I checked in code. I had a nickname for him, “test nazi”. I eventually “saw the light” and let him explain to me why his tests were there and the process he went through when writing the tests. At the end of my time on the project, even though I was not fully doing TDD, I learned a lot about it. It was that experience that caused me to research extensively on TDD/BDD and immerse myself into it fully. Now it is a part of my day-to-day coding. Thanks to the “test nazi”.

Over the last couple of projects I’ve worked on I have come to realize how much pair programming has prevented major “fails”. Having a continual code review will do wonders to your code. No cheating or shortcutting your code, no IM or blog-reading distractions, getting immediate help and receiving an alternative view on writing a piece of code are some great benefits of pair programming.

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 – time zones? Gem dependencies? UTC migrations? Better caching? And as a follow-up, what are the most important things in your mind to get done for the next major release?

Karmen Blake: Named scopes are awesome and see a lot of potential coolness with them. Rails 2.2 will be coming with localization and thread safety. Beyond that, I am excited about things I’m seeing with database connection pooling.

FiveRuns: Spurred on by the recently announced Ruby Hero Awards, who is your own personal Ruby hero, and why?

Karmen Blake: Obie Fernandez would have to be my Ruby hero. The things he has been doing in recent years have been very exciting: Rails evangelist, wrote a great Rails book and started a killer software company. I’ve seen Obie speak at OSCON about DSLs in the enterprise. I enjoy his blog and watching videos from conferences. To me Obie is characterized as an initiator, innovator, opinionated, and on the cutting edge of Rails work. His accomplishments motivate me to be better at what I do.

FiveRuns: Bruce likes to talk about “backpacking” through other languages. What others have you dabbled in and/or are you learning right now? How have these travels impacted your work in Ruby? Your overall approach?

Karmen Blake: Other than my computer science schooling which gave me a rigorous foundation, I cut my web-development teeth on PHP, Java Enterprise Edition and Javascript. Developing in these technologies taught me a lot of how the web works and its quirks, too. Developing in Java solidified my understanding of OOP and common code patterns. Developing in JEE and PHP gave me exposure to programming for the web and interfacing with MySQL. I was able to apply those to Ruby right away. I also had to unlearn some Java idioms and patterns because in Ruby many of them are trivial. I am an avid reader of blogs and books. Currently I am reading Smalltalk: Best Practice Patterns by Kent Beck. I spent a small amount of time getting acquainted with Erlang. It looks appealing on many levels. My job has not had a need for it… yet. :)

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

Karmen Blake: Be passionate. Be a continual learner. Work on communication skills as much as technical skills. Be a team player. Encouragement goes farther than negativity. Actions speak louder than words. Be up for a challenge. When I was younger my dad and uncles would remind me that someone out there is always better than you (for me it was in sports). Not to be negative but to push me to be better. They would tell me that if I wanted to improve I would have to compete against better athletes. I apply that to my career as well. If I get an opportunity to rub elbows with smarter people I take advantage of it and soak up what I can like a sponge.

Karmen Blake is a Ruby on Rails developer and software engineer for GeneTree out of Salt Lake City, Utah, but working from Coeur d’Alene, Idaho. Blake previously taught Ruby and Rails at Spokane Community College in Washington State. Blake presented at the 2006 Course Technology annual conference on Rails back when many in academia had not even heard of Ruby or Rails before.

Welcome to this week’s Rails TakeFive interview, our weekly discussion about Ruby on Rails with noted developers from throughout our community. This week, Mike Subelsky, co-founder of OtherInbox, hacker, Ruby on Rails developer, SproutCore neophyte, and improv theater director based in Baltimore, Maryland joins us to share his thoughts on Ruby + Rails.

FiveRuns: Welcome, Mike! And thanks for taking the time! Let’s start by talking about GitHub. Now that the Rails repository has been moved over, can you talk a little bit about the benefits of Github and how SCM and agile development go hand-in-hand?

Mike Subelsky: Agile development is greatly enhanced by elegant tools that enhance collaboration and reduce mental friction, and that’s how we view SCM. Knowing you have every past revision of your code available, and being able to create experimental branches means it’s very easy to try new techniques and throw away what doesn’t work. We keep our code trunk pristine, with all tests always passing, and we deploy that code daily to an alpha server meant to host the bleeding edge version of our app. Our users can even login to that server if they want to try out the latest code. We also always have a tagged branch of our code representing the stable release currently in production. If we need to make a bug fix in between releases, we always have that tagged branch ready for commits, while the rest of the team can continue contributing to trunk. If a major piece of work is in progress, it goes into its own separate branch until its ready to be merged into the trunk.

We use Subversion and Git simultaneously, so we’re in a good position to compare the two approaches. We started OtherInbox before GitHub came to the fore, and are still using Subversion for our server code. We decided to experiment with Git and GitHub while rewriting the browser client as a SproutCore application. The learning curve has been a bit steeper than expected, but I am definitely a Git believer. We have people working on this in three different time zones, all able to share code branches and patches very easily, pushing and pulling code all along.

FiveRuns: Bruce likes to talk about “backpacking” through other languages. What others have you dabbled in and/or are you learning right now? How have these travels impacted your work in Ruby? Your overall approach?

Mike Subelsky: Most web development requires you to dabble in Javascript, but this summer marked my conversion from Javascript dilettante to Javascript veteran. It turns out there is a beautiful, functional, prototypal language wrapped inside Javascript. I discovered this for myself while building a full-blown desktop app for OtherInbox that runs inside the browser. In order to make it perform quickly and reliably, I had to learn to think in Javascript, using functional programming techniques, and not think like a Ruby guy writing Javascript.

This has impacted my Ruby work by teaching me how to better use closures and functional programming techniques to full advantage. As one example, in several places in our app, we pass around Javascript functions intended for lazy execution, whenever an AJAX call succeeds. That’s a pretty common technique these days, but in order to take full advantage of it, I had to make subtle but powerful change in my thinking that will reverberate across all the languages I use.

FiveRuns: Let’s switch gears a little and talk about Merb – they are all about being agnostic—ORM-agnostic, JavaScript library agnostic, and template language agnostic – what does this mean? And what does it mean to be “thread-safe”? Is there promise in implementing Merb alongside of Rails, say, for processing?

Mike Subelsky: I love Merb and think there are many applications where people are using Rails but should be using Merb, because they don’t need the entire Rails stack, or because they are doing something too custom and unconventional and end up having to fight with Rails. The agnosticism simply means that Merb leaves more decisions up to you, though there are still plenty of conventions available if you want them in Merb—more and other gems.

Thread-safety means one process can perform multiple tasks concurrently, via threads, without one thread disrupting another. This can yield much more efficiency in many applications. We are considering rewriting a key part of our application as a separate Merb app to run alongside the main Rails app. Right now, we have a lightweight read-only API that the SproutCore client uses to get updates from the server. The code for this uses almost no Rails conventions (we make raw SQL calls and marshal the results into JSON ourselves) so there’s no reason we have to use Rails. If we serve it up via Merb, we’ll get a performance boost and more efficient use of memory, at the cost of extra complexity.

FiveRuns: Switching to the deployment side of things, Amazon + Rails seems to be a prevalent choice right now for developers looking to quickly deploy their apps in the cloud. Can you talk a little bit about the benefits and challenges here?

Mike Subelsky: We are 100% hosted on Amazon Web Services (AWS), except for our outbound SMTP service, and we’ll probably move that onto AWS soon. There’s an immediate business benefit from the greatly reduced costs compared to conventional providers, and how easy it is to launch new instances when scaling horizontally, but to me the biggest benefits accrue to our productivity and imagination. We can fire up servers for experimental reasons, setup copies of our production environment to try out new features, and so on, which make our development processes extremely agile, because servers are a commodity for us, not some precious, limiting resource.

It can be difficult to manage a cloud of servers, though. If you are planning on launching an app of any moderate scale you will end up having to write a lot of tools to launch and provision servers, monitor their health, and consolidate their logs. As our development team grows, we’re outgrowing the home-brew approach I outlined at the Lone Star Ruby Conference. We’re switching our server management over to RightScale, though there are many other services I would recommend. I think they have the best Ruby gem out there for talking to SQS, S3, and EC2, called Right-AWS.

We use S3 for message storage and it has been very reliable.

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

Mike Subelsky: This may be very trendy to say, but as a developer, I’ve really learned to appreciate the value of having great test coverage. Our app has a lot of moving parts and a very high availability and integrity requirement. We simply cannot and will not ever lose anyone’s email, and we know our customers won’t tolerate even a moment of time without being able to access their email, so the tests help prevent us from ever putting unreliable code into production. It takes extra time to write them, but having a well-tested app means we spend an order of magnitude less time on debugging and troubleshooting, and more time building new features. It also helps us sleep better at night. This summer I made some major schema changes to our app, and I was able to implement them with a minimum of pain because the tests were there to back me up.

As a manager, I always try to keep in mind that our people and what they know are the real platform for our company, not Ruby, Rails, SproutCore, AWS, or any other particular technology choice you could name. I try hard not to dictate the answers to things, or mandate the use of any tool or practice, because often what the team comes up with organically is much better than what I would think of. Except the testing thing, that’s an organizational standard we have that I’m a pretty strong proponent of.

I don’t hear enough about code review. I’d like to figure out a way to inject more code review into our processes in a way that would be agile and not onerous. I think a lot of common bugs could be killed by requiring multiple programmer eyes on production code, and I think it would help developers on a complex project get familiar with more of the codebase.

Mike Subelsky built a variety of Ruby-on-Rails applications as a freelance developer for two years before co-founding OtherInbox with Austin entrepreneur Josh Baer. He is the author of random-data, an open-source Ruby gem used for prototyping new Ruby applications, and wrote two recipes in the recently-released book Advanced Rails Recipes. Prior to becoming a full-time Rails hacker, he served as a U.S. Navy information warfare officer with overseas assignments around the world, including counterterrorism operations during Operation ENDURING FREEDOM. He has also worked as a civilian cybersecurity analyst for the Department of Defense and private industry. He holds Bachelor and Master of Information Systems Management degrees from Carnegie Mellon University, and is a Certified Information Systems Security Professional. He blogs about open-source technologies such as Ruby on Rails and SproutCore at subelsky.com.

Welcome to this week’s Rails TakeFive interview, our weekly discussion about Ruby on Rails with noted developers from throughout our community. This week, Jamie van Dyke is in the house. Jamie recently left Engine Yard and is now CTO at Parfait—“The Ruby Agency”. He’s been a Rails developer since 2005, he’s a Rails Core Contributor, and has developed multiple open source projects.

FiveRuns: Welcome, Jamie! Thanks for taking the time to share your thoughts. Let’s start by talking a bit about Rails 2.1. What about the new release excites you the most – time zones? Gem dependencies? UTC migrations? Better caching? And as a follow-up, what are the most important things in your mind to get done for the next major release?

Jamie van Dyke: Coming from Engine Yard, I’ve seen some tragedies when it comes to application optimisation, I would have to say that the caching improvements are a welcome addition. The ability to seamlessly cache into a memory store and at any point flip it over to memcached with a simple configuration change, removes any excuse for not using it in your application. Although this answers the question, I’d also like to point out that the threading support and internationalisation is a big bonus too. The spaghetti i18n applications I’ve had to deal with in the past will benefit greatly from the built-in support.

However, it’s hard to pick a clear winner that I’m looking forward to, thread safety is a good step in the right direction, as well the changes to ActiveRecord that ease our every day lives. For example, bundle up named_scope with nesting mass model assignment, and a chunk of my code is cleaner immediately.

What I’m trying to say is, I guess, there’s no clear winner in my eyes. It’s the collected improvements that impress me.

FiveRuns: Spurred on by the recently announced Ruby Hero Awards, who is your own personal Ruby hero, and why?

Jamie van Dyke: Personally my Ruby Hero would be Rick Olson. Although he’s directly involved in Ruby on Rails, I think through the myriad of plugins that he contributed and the style in which he wrote them, he’s given a huge amount of time to the Ruby community through plugins and multiple open source projects, he’s shown how good code should be written. He’s also got a humble personality and plays a mean drum set on Rock Band! It has to be said that Jamis Buck could also be my choice though, as his work has been stellar in easing my day to day work in deploying and server scripting. Nice job, Jamis.

FiveRuns: We’ve blogged a little bit about this recently, but do you have any experience that you can share from playing around with Phusion Passenger?

Jamie van Dyke: I’ve personally been an Nginx and Mongrel deployer since the early days, and being an App Support Manager at Engine Yard for over a year I used the same there. However, since starting Parfait I’ve decided to try out Apache again with Phusion Passenger and I have to say my experience has been a positive one. Deploying with Capistrano was a simple Capistrano change, as you don’t ask Passenger to restart directly you merely place a file on the server in a specific location and Apache knows to give it a kick. It’s quick and simple, no need to worry about the mongrel cluster proxy that I’m used to, so monitoring is easier than the Monit battle that you can get into with mongrel.

As for best practise deployments, it’s got to be Capistrano all the way. Versioning of releases with git scm support for the application, is quick, safe and painless. Migrations are a non-issue if you’re using Capistrano, the long deploy task handles bringing the site down during the migration and bringing it back up afterwards. So altogether it’s been a smooth transition, I’m impressed so far, only time will tell whether I change my mind.

FiveRuns: Beyond Merb, there are a great number of alternative frameworks for Ruby, including Nitro, Waves, Sinatra, Ramaze, and even the microframework Camping. Do you have any experience working with these frameworks? What have you seen so far that you really like? Dislike?

Jamie van Dyke: Well, Merb is the real one I’m watching. I haven’t had any experience with any of the alternative frameworks on a work basis, only playing around to see what they’re capable of and the ease of use. They each have a definite place in the marketplace, each focus on different aspects of the web and what is needed.

I particularly like some of the concepts of the Mack Framework, specifically the distributed application idea. Allowing applications to share more than just RESTful resources opens up new possibilities in areas like intranet development, where different departments are responsible for their own functionality but with a shared base layer. I’ll be keeping my eye on that one, for sure. As well as Merb, of course.

FiveRuns: Along those lines, tell us a little more about what you think of Merb – they are all about being agnostic – ORM-agnostic, JavaScript library agnostic, and template language agnostic – what does this mean to you? And what does it mean to be “thread-safe”? Is there promise in implementing Merb alongside of Rails?

Jamie van Dyke: Rails is a very opinionated framework. Opinionated in the sense that it chooses tools for you and expects you to use them. That’s all well and good if you like them, but if you prefer a different method of doing something then it’s a matter of overriding the internals of Rails and creating a fragile work environment. Nobody likes to update Rails and find the plugin they’ve been using and rely on, doesn’t work. Personally I prefer testing using Behavioural Driven Development, specifically with RSpec. For this I have to use plugins in Rails to override the default Test Unit that it assumes I should use. This is exactly what Merb solves. Merb doesn’t assume you want any particular testing framework, it allows me to choose. The same goes for the templating language and javascript etc. It’s nice to have the flexibility to choose what suits me best, rather than the framework developer.

Merb is thread-safe, you say? Indeed it is, and is there promise of it working alongside Rails? Indeed there is. In fact, at Engine Yard we had many customers who used it alongside their Rails application. Most of the time it was to solve the problem of file uploads, which in Rails lock the entire thread. This means that when you have 3 mongrels running Rails and 3 users decide to upload large files at the same time, everyone else visiting the site is put in a queue waiting for the file upload to complete. Merb solves this by doing file uploads in a separate thread, allowing other requests to continue. There are many other uses for thread safety, like long running processes that need to be spawned off by the web interface on demand.

I think there will always be room for Merb alongside Rails, not just for the reasons I’ve mentioned but because of the smaller memory footprint, speed at which it handles requests and more.

Jamie van Dyke is the CTO at Parfait, “The Ruby Agency”. He’s been developing in Ruby on Rails since the beginning of 2005 and web development in general since 1996. He is a Rails Core Contributor and developer of multiple open source projects. After being an Application Support Manager at Engine Yard for over a year, he is now taking that experience into the Ruby training, head hunting and consultancy market.

Welcome to this week’s Rails TakeFive interview, our ongoing interview series featuring insight and commentary from notable members of the Ruby and Rails community. This week, we’re happy to be joined by Reuven Lerner, noted developer, Web/database consultant, author, and writer at GigaOm’s Ostatic open source blog.

FiveRuns: Welcome Reuven! Let’s get started by talking a bit about Rails 2.1. What about the new release excites you the most? Gem dependencies? UTC migrations? Better caching? And as a follow-up, what are the most important things in your mind to get done for the next major release?

Reuven Lerner: I must say, I’ve been very impressed with the Rails 2.1 release. I had read through a number of blog posts describing new features before the release itself, so I wasn’t that surprised to see what was in there.

But there’s a difference between reading about the new features and using them, and I’ve generally been quite impressed with the additions. Some of the features that you mentioned are quite useful. For example, I really like the gem dependencies, and have used them to help me when installing an application on a new server. UTC migrations seem like such an obvious feature in retrospect, but I guess it took a while for the community to realize what might happen when you have more than one developer hacking on the database.

Hands down, though, my favorite new feature in 2.1 is the improved caching support, and particularly the integrated support for memcached. I had been using memcached with Rails 2.0, and it worked well — but only after I spent many hours reading through the documentation for various versions of cache_fu, acts_as_cached, and memcached-client. My favorite part of the caching support is the “cache” method, which looks in the cache for a particular piece of data. If the data isn’t already in the cache, you can provide a block that tells Rails what database query to use to get the data; that value is then stored in the cache for the next time around. This feature should make it a no-brainer for everyone to use memcached in their applications.

What would I like to see in the next version?

First of all, I’d like to see even better integration of memcached. The “cache” function is, as I wrote above, useful and powerful. But while I find the syntax to be logical, it’s also a bit ugly. I’ve been thinking that it might be easier to integrate the memcached support into ActiveRecord, such that I can do a Foo.find(:cache…), with the :cache symbol indicating that I want to retrieve the value from the cache if possible. Most of my uses of memcached are with the database, and I’m going to assume that this is true for others, as well. The one fly in the ointment with memcached support is the weird restriction that memcached imposes on keys: They may not contain spaces. One of my main uses for memcached is to cache parameter values that have been set by a site administrator. Because the parameter name is simply a text field in the database, it can include spaces. (I find that this greatly improves usability for my non-technical clients.) I managed to get around this problem by monkeypatching the String class, adding a String#to_mkey method that replaces space characters with underscores. I would think that memcached could perform this search-and-replace operation on its own — but if it can’t or won’t, then I would like to see Rails take care of it. Another weird problem with memcached is that you sometimes need to invoke “require_dependency” if you’re unmarshalling cached objects. This seems to be a well-known problem in the Rails community, and so I was able to find and solve the problem in relatively short time. But I shouldn’t encounter such weird problems at all, and I’d like to think that Rails is smart enough to deal with this automatically.

I would also like to see better support in migrations for foreign keys and other constraints that PostgreSQL groupies like myself take for granted. It’s nice to say that you can execute raw SQL commands from within migrations, but it always seems like cheating when I have to go outside of a DSL.

Finally — and I know that I’m beating a dead horse here — I would really like to see some built-in support for users, roles, and permissions in future versions of Rails. I realize that there are many in the Rails community, including the core team, who argue that by leaving out such functionality, it lets everyone implement users and groups in a way that’s effective for their needs. But I find this to be a fairly unconvincing argument: Nearly every application needs to deal with users and groups in some way, and it would be a tremendous relief to have it built in. Even if Rails doesn’t include actual functionality for users, groups, and roles, perhaps it could include a standard API for working with plugins that handle this functionality.

That is, Rails itself wouldn’t come with a user-role-group system. But it would have a standard plugin interface that would allow a variety of different authentication schemes to connect to it. And this standard interface would also allow developers to write to a common API. Rails loves to describe itself as “convention over configuration,” but for anyone who has to deal with user registration and authentication, there’s a heckuva lot more configuration than convention.

FiveRuns: Bruce likes to talk about “backpacking” through other languages. What others have you dabbled in and/or are you learning right now? How have these travels impacted your work in Ruby? Your overall approach?

Reuven Lerner: I’ve worked with many different languages over the years, and my feet are firmly in the high-level language (known to some as “scripting languages”) camp. I could work in C or C++, but I’ll do almost anything I can to avoid such work — and I’ve successfully done it for more than 10 years, so I’m pretty happy.

For a long time, Perl was my default language. I wrote lots of code in Perl, wrote columns about Perl, spoke at Perl conferences, and even wrote a book about Perl called Core Perl, which was published by Prentice Hall back in 2000. I disliked the Perl inclination for clever, terse code, particularly when it came at the expense of readability. My Perl code was pretty readable, and CPAN meant that you could jump in and start to write an application immediately.

As time went on, though, I began to sour a bit on Perl. First of all, I really wanted “real” objects. And while the Perl object model is good enough for many things, it’s not nearly as completely integrated as Ruby’s objects. Secondly, I feel like Perl 6 is going in a direction that I don’t really like — not that it matters, given that Perl 6 is taking a heckuva long time to develop. It’s always possible that I’ll work in Perl 6 at some point, but I am really wondering who is going to use Perl 6 outside of the small community of Perl 6 developers. Then again, I was skeptical that Perl 5 would catch on, so perhaps I’m wrong on this front, too. I also became increasingly frustrated with Perl’s hazy typing system, in which numbers become strings and vice-versa. For many years, I thought that this was a feature. But I’ve come around on this, increasingly liking the strict typing that Ruby and Python demand. Indeed, I think that Ruby and Python do the right thing: Variables don’t have to be declared, and can contain any value you want. The value has as type, though, and that type won’t change. I don’t think that Perl is going to change anytime soon on this front, a we can see from the recent “smart match” operator, which really gives men pause.

I actually spent a year or two doing a lot of work in Python, convinced that I would switch much of my work to that language. I did a big project in Python, and I decided that while I like Python quite a bit, it’s a bit too formal and stilted for my taste. If I hadn’t discovered Rails, I’m guessing that I would be a Django developer.

But as it happens, I discovered the one-two punch of Ruby and Rails, and immediately felt like I had come home. I think that the Ruby community has swung the object-oriented pendulum a bit too far, with too much emphasis on metaprogramming. But the language, attitude, and community are more in tune with my development interests and style than Perl. Indeed, the syntax of Ruby is enough like Perl for me to be able to write many things automatically, something that I can’t say for Python.

This might come as a surprise, but I have also been doing a growing amount of PHP work in the last few months. (Yes, I would love to work exclusively in Rails. But being an independent consultant doesn’t always guarantee you the freedom that you might imagine!) I have always pooh-poohed PHP, and I still think that there are a number of serious problems with the language. PHP is growing up, and has learned from at least some of its mistakes. I wouldn’t say that its object model is as powerful as Ruby’s, and there is still a long way to go. But it is now possible to write PHP code that can be taken seriously. Moreover, the PHP community has managed to make the language execute quickly in a minimum of RAM, something that I know the Ruby community is working hard to attain. Working with PHP has given me a greater appreciation for Ruby — but it’s not nearly as bad as what you might think, and it’s even possible to create useful and interesting applications with PHP.

Like all Web developers, I’ve been reading and working a great deal with JavaScript in the last year or two, more than I ever imagined would be possible. I was never a big fan of JavaScript, and I still think that functions within functions within functions can get a bit hard to read, as well as tiring to write. But libraries like Prototype have made JavaScript not only palatable, but fun to work with, allowing me to ignore most browser dependencies. The browsers have also improved their support for JavaScript — increasing execution speed, improving standards compliance, and just making the language more stable.

Even if I could ignore JavaScript nowadays, I’m increasingly inclined to say that I wouldn’t want to. I never really imagined myself as a client-side or GUI programmer, but JavaScript is making all of us do client-side work in some way or another, and I don’t think that this a bad thing.

Finally, I’ll mention a language that most readers have probably never heard of: NetLogo. I’m biased, since NetLogo is developed by the research group at Northwestern University where I’m working on a PhD in learning sciences. And it’s not meant to be a general-purpose programming language, although it is Turing-complete, and you can do all sorts of neat things with it. No, NetLogo is a modeling language, meaning that you are expected to use it to create computerized simulations — typically of scientific, mathematical, or social phenomena. NetLogo’s programming model has a distributed feel, even though it’s not distributed; you create various types of “turtles” on the screen that represent different types of agents, and then tell the turtles how they should move and otherwise interact with one another. It’s a very different type of programming than anything else I’ve ever done, and the models library that comes with NetLogo is itself highly instructive and interesting, offering hours (or even years!) of discoveries.

FiveRuns: We’ve blogged a little bit about this recently, but do you have any experience that you can share playing around with Phusion Passenger?

Reuven Lerner: I downloaded and began to use Phusion Passenger several weeks ago, and I’m extremely impressed and pleased. I’m using it on an application that’s about to go live, and while I can’t tell you whether it’s really faster than lighttpd or Mongrel, it just feels comfortable and nice to be back in the Apache world. I’ve been using Apache since before it was released, and the last few years of working outside of Apache have been interesting, but also frustrating. The fact that I can now use Apache on my server, and configure it in the “usual” way is not only comforting, but also helps me to organize my server under a single configuration directory (for Apache), rather than multiple directories and software configuration files, each of which is responsible for a set of ports on my server. I don’t know if I’m the best person to speak about “best practices” for deployments. I feel like I’ve come full circle in the last few years; I spent several years working with Time Warner’s Web sites, where we had very established development, staging, and production servers. That disappeared from my life for a few years, as I either worked on internal projects that didn’t have different servers, or with small organizations that couldn’t or didn’t set them up.

The fact that Rails has built-in support for development and production servers, and even lets me configure the environment differently for each environment, has been a dream come true. And Capistrano has certainly been a huge help on this front, allowing me to deploy to multiple servers with little or no effort. But as for a true best practice? Well, aside from develop-test-deploy, I’m not really sure if there’s a better way to go about things. The tools could be a bit smoother, and perhaps Capistrano could warn me if I’m trying to deploy something that doesn’t pass all of my tests. But I think that for most of my needs, the tools do the right thing at the right time, allowing me to focus my attention on application development, rather than the ugly and annoying aspects of deployment.

FiveRuns: On that note, let’s talk about Merb. They are all about being agnostic – ORM agnostic, JavaScript library agnostic, and template language agnostic – what does this mean to you?

Reuven Lerner: I’m not really that familiar with Merb, other than downloading it, playing with it a tiny bit, and reading about it. The premise is an interesting one, offering developers a toolkit with which they can create their own Web framework, rather than a complete and ready-to-go framework. In some ways, it seems to me that just XML is a language that can be used to create markup languages, Merb is a framework that can be used to create frameworks.

In some ways, this is a highly attractive option: While I like Prototype and script.aculo.us quite a bit, I have sometimes wanted to work with YUI or Dojo, either because they had some useful widgets or just on a lark. Using a non-Prototype JavaScript framework with Rails is theoretically possible, but I don’t think that it’s really practical. Merb, by contrast, seems to really encourage such experimentation.

I’m also a bit fascinated by the idea of using a different relational-object mappers. I happen to like ActiveRecord, but I recognize very well that it’s slow, and that another mapper might work better for my purposes. I’ve been using SQL for a long time, and it’s still sometimes easier for me to express my ideas in raw SQL. And yes, ActiveRecord lets me do that with find_by_sql, but it’s just not the same. I thus see Merb as a “what if?” sort of framework—a kind of edge-edge Rails, allowing us to explore alternatives without being constrained by the decisions that were already made by the Rails core team.

Merb might grow to be popular for actual application development, but I have to wonder if its impact will really be felt by developers, who will be able to compare different pieces of functionality in ways that would be unthinkable with Rails.

Finally: One of the reasons why I so enjoy working with Rails is the fact that it comes with almost everything I need to start working, right out of the box. If I need something, then it’s often (usually) available as a gem or a plugin. I have so much to do that I’m willing to give up a bit of speed if it means greater convenience and time hacking. So I don’t see myself as the ideal audience for Merb.

However, I do think that the people who are developing Rails, and thinking about what should be included in version 2.5, and even version 3.0, should be playing with Merb a great deal, using it to find the best ideas and practices so that the mainstream Rails community can take advantage of what they find.

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

Reuven Lerner: Oh, how I wish that I could really give advice on how to be hugely productive! People seem to think that I accomplish a lot, and I guess that this is sort of true. (For those who don’t know, I’m the father of three young children, a full-time Web/database consultant and trainer, and a PhD student at Northwestern University. As if that weren’t enough, I’ve been working on an e-learning startup over the last year or so.)

So if I have any “secret” to share about my productivity, it’s a combination of doing things that I do quickly and well (i.e., programming and writing), and sleeping very little at night. I started to sleep very little back when I was in college, editing the student newspaper at MIT. Except for a few years of 9-to-5 work, I’ve been pushing my limits ever since.

But enough about me. What can I suggest that people do to become more productive, or even “ultra-productive”?

I think that the key is to be good at learning new things, and at synthesizing those ideas into an established practice. A lot of classic learning studies have shown that experts — that is, people who have done a task, or seen a problem, hundreds of times — can understand, describe, and solve the problem more quickly and accurately than novices. So in many ways, you can become ultra-productive by seeing the same sorts of problems, again and again. When I first speak with a consulting client, it’s not unusual for me to say, “Ah, I’ve done this many times before.”

The thing is that Web development means learning new skills all of the time. If you’re just going to try to become really good at one set of skills, or at solving one set of problems, then you’ll soon find that the world passes you by. The key to being a good developer is to constantly be improving your skills, learning new languages, frameworks, and techniques and then fitting those into your established work habits.

A key element of being ultra-productive is thus getting really good (and really fast) at learning new technologies, and assimilating them into what you already do. It’s not at all unusual for me to learn about a new technique on a Monday, try it on a Wednesday, and find myself mentioning it to a client on a Friday.

Being able to turn on a dime like that has been extremely helpful in my work, and makes me (I think) a better consultant, as well as a better programmer. How do you become good at learning new technologies? Like any other skill, it’s something that you need to practice a lot. The Pragmatic Programmers say that you should learn a new programming language every year, to keep yourself thinking in new ways. I don’t know if I’d go quite as far as that, but I do agree that you should constantly be challenging yourself to learn new programming techniques, libraries (gems), and other ideas. After a while, you’ll get to the stage in which you can read about a new technique and know how to integrate it not just into a generic program, but into your actual work. But in order to get to that point, you need to read and learn a lot. I read a lot of books and blogs; my kids know that I’m never without a book in my hand, or 2-3 in my backpack (in case I get stuck somewhere).

If you work hard at learning new things, then each new nugget that you learn becomes that much easier for you to integrate, which makes you a more productive person, as well as a more interesting and well-rounded one.

Reuven M. Lerner has been an independent Web/database consultant for 13 years, offering development and training services to companies in North America, Europe, and Israel. For more than three years, his platform of choice has been Ruby on Rails with PostgreSQL, although he uses other languages and technologies as necessary.

When not hacking, writing, teaching, or playing with his children, Reuven enjoys making ice cream, walking, and reading.

Welcome to this week’s Rails TakeFive interview, our weekly discussion about Ruby on Rails with noted developers from throughout our community. This week, we’re happy to be joined by Mike Gunderloy, noted developer and creator of the popular blog A Fresh Cup.

FiveRuns: Welcome Mike! Let’s get started. Our own Adam Keys recently gave a talk at RailsConf titled Oh, the Fail I’ve Known. In the talk, Adam outlined a few different kinds of fail: learning failure (the knowledge was available but you didn’t have it), technological failure (you did have the right tool), problem failure (barking up the wrong tree), and so on. If you don’t mind, give us an example of the fail you’ve known?

Mike Gunderloy: After fifteen years in this industry what fail have I not known? But there are a few that stand out.

Too many times I’ve had a little knowledge (which we all know is a dangerous thing) and mistaken that for knowing everything. It’s very easy to have this overflow into a sort of technological hubris, where you assume that your chosen language and platform are good for solving every possible business problem. If you still think this, either you haven’t had a really wide exposure to the varieties of business problems out there in the world, or you’ve not yet faced your first serious threat of lawsuit. With most of the technologies I’ve worked with in the past, I’ve had the misplaced confidence that I could walk into any customer’s office and use my Awesome Code to solve their problem. In one case I especially remember, my partner and I spent a couple of months on analysis and spikes before we realized that we were in way over our heads, that our current platform was never going to do what the customer wanted, and that we should flee with all possible haste. Fortunately our lawyer was better than the client’s.

Another key failure that I see over and over again in the development community is the cavalier dismissal of business – as if we software people should not sully our hands with the details of doing business. I’m not talking about the details of analyzing your customer’s needs; I’m talking about running your own business. At this point, I’m convinced that you have only three choice. First, you can learn enough about running your own business and take it seriously enough to have an actual corporate structure, an attorney, an accountant, a banker, and an insurance agent. Second, you can pay someone else to handle all this non-coding stuff for you (by taking a salary and letting your boss make a profit from you in return for handling the business side of things). Third, you can code along in blissful ignorance until you get sued into oblivion or hounded by the IRS. Personally, I recommend alternative number one, but then, I’ve been freelancing for decades.

FiveRuns: Now that the Rails repository has been moved over to git, can you talk a little bit about the benefits of Github and how SCM and agile development go hand-in-hand?

Mike Gunderloy: The obvious connection has been remarked on before: your SCM system can be a source of friction when you’re trying to do agile development. This is no different from any other “high-ceremony” system: if there are n steps that you have to take to branch your code, you won’t branch your code as much, you’ll be inhibited from trying quick code spikes, hair will grow on your palms, and so on.

But there are a few other things to say about the Rails community’s current infatuation with git and the wider topic of SCM.

As more and more Rails projects move to git, the barrier to contributing to the Rails ecosystem gets lower and lower. Even if you don’t have an idea for building your own plugin from scratch, you can find one where you’ve hit a pain point, fork the code, and then send your changes back upstream as a pull request. After a few successes with this pattern, any developer will feel more like a part of the wider community. This is a good thing that hasn’t been emphasized enough – and, in fact, it’s one of the areas where Github could use improvement. The overall process of getting a fork of some repo on to your local hard drive, synching it properly, branching, sending pull requests and (on the receiving end) dealing with the pull requests needs to be better documented, and it would be nice to see it streamlined as well. (I know, I know – if I feel pain here, I should take care of it myself. Perhaps I will.)

We also ought to recognize that git isn’t perfect for everyone. It has an excellent feature set, and it excels at what it does. But the collection-of-twenty-command-line utilities approach to building a SCM won’t click with everyone, no matter what homage we pay to the ideals of “small pieces loosely joined.” For wider scale acceptance and easier usage, we could use some better GUI front ends to git. Gitnub is a start for OS X users, and the git bundle for TextMate helps, but the state of the GUI art for git is far behind that for subversion. Some of this, I suspect, is because many Rails coders (and core Linux coders, which after all is where git originated) still have the attitude of “we don’t need no steenkin’ GUIs” and enjoy the feeling of masculine triumph over the world that they get from figuring out how to use a complex tool based on confusing documentation. I’d prefer that properly using SCM not be regarded as a rite of passage.

Finally, beware of Not Invented Here attitudes when it comes to SCM. Yes, git is great, and in many ways it’s an advance over subversion or CVS. But what do you know about other SCM and ALM systems? Have you worked with Team Foundation Server? Perforce? How about some of the big commercial ones like AccuRev or Razor? As we debate the minutiae of git vs. subversion vs. mercurial, we miss the chance to bring in innovations from outside the open source universe that could be exceedingly helpful.

FiveRuns: Bruce likes to talk about “backpacking” through other languages. What others have you dabbled in and/or are you learning right now? How have these travels impacted your work in Ruby? Your overall approach?

Mike Gunderloy: Well, more than dabbled in – before I resolved to switch to Rails in late 2006, I had spent years working in .NET, running a successful .NET web site, writing books and articles about it, and generally making noise in that community. And I’ve lost track of the number of languages I’ve worked with over the past quarter-century, though some stand out – the careful design of VAX/VMS assembler, the elegance of Lisp, the utter pain of RPG II, and so on.

Right now I’m in an odd place as far as languages go: I’m spending much of my learning time immersed in Ruby and Rails. Now that I’ve made a reasonable contracting success with the platform, it’s time to bring my knowledge up to the next level (which is not to know everything, but to know where to find everything). So my “backpacking” is very close to home; more like a visit to the park down the street.

But I have learned a few things about this process over the years. I do think that any good developer should constantly be dabbling in new things; even if you’re not planning a career or language switch any time soon, you need to stay aware of what’s happening in the competitive landscape, lest you end up in a dead end (I knew some exceedingly successful xBase developers back in the day).

It’s tough, though, to get a really good idea of how a new language works on any but the most superficial level without a lot of experience. When I started working with Rails, I wrote a good deal of C# code in Ruby – and before that, I wrote a good deal of VB code in C#. Don’t mistake a superficial acquaintance with a language for a deep appreciation of its idioms and best practices. It’s useful to play with Haskell enough to get an idea of what functioning programming is all about, and to see if there are any patterns you can steal for your Rails work – but that’s not the same as really learning Haskell.

My own personal approach is to cast a fairly wide net of technologies that I’m interested in enough to keep an eye on, and to track a lot of things for later use; that’s part of what drives my blogging at A Fresh Cup. But I tend to not actually buckle down and learn things in depth until I have clients who are ready to pay me to do so. Consultants abhor a billable vacuum.

FiveRuns: We’ve blogged a little bit about this in the past, but do you have any experience that you can share from playing around with Phusion Passenger? What about best practices generally for deployments? What about migrations?

Mike Gunderloy: I recently switched a bunch of Rails servers (internal and client) from nginx + mongrel to Apache + Passenger. It’s been a very positive experience for me: the hit on server resources is, if anything, less than it was. But even better: the hit on my mental ability to keep track of everything is a whole lot less than it was. With nginx and mongrel I had reached the point of being able to deploy a server with reference to notes, judicious use of Google, and copying from what I’d done before. With Passenger, on the other hand, I can get a new server up and running easily by running one executable and editing a couple of files. In fact, if the resource usage were 10 or 20% higher I’d still go with Passenger, just to get away from the endless fiddly bits and mystery breakages of the previous solution.

I’m no Apache expert by any means, but there is a whole lot more Apache expertise out there than there is nginx expertise. That means that if you need to do something outside of the mainline of nginx deployment – say, adding a subdomain served by a PHP application to your Rails application – you’ll spend more time looking for answers with nginx than you will with Passenger. As someone who prefers his time as a developer to his time as a sysadmin, this strikes me as a good thing.

One of these days I’d like to figure out why it’s so hard to find freelance sysadmin contractors to complement freelance developer contractors. If I could contract this stuff out, I would. Meanwhile, I learn just enough to get by, and the benefit of Passenger is that it’s made that “just enough” smaller for me.

FiveRuns: Obie Fernandez’s company, Hashrocket, which has been blogged about extensively, is all about being ultra-productive in 3 days. What are your own tips around, to paraphrase Obie and 37Signals, getting real—on steroids?

Mike Gunderloy: I’m in the second or third wave of Rails developers; I haven’t 100% drunk the 37Signals Kool-Aid, I don’t necessarily think the 37Signals applications are all best-of-breed, and I think the success of Rails and “getting real” has to do with marketing as well as with superior code. I strongly suspect that folks like David Heinemeier Hansson, Obie Fernandez, and other Rails luminaries could be successful using any of a wide variety of languages, frameworks, and workflows.

Having said that (and probably completely blown any credibility I might have in the Rails community), I’ll add that the problems that interest me are not so much those of making the developers at the top of their game even more productive, as those of making sure that things work as well as they possibly can for the average developer. To some extent, Rails is a victim of its own success: the high-profile nature of the framework has caused a lot of business folk to say “I’ve got to get me some of that Rails stuff,” which in turn draws in more developers. Rails makes it easy for these developers to get started, but does it make it easy enough for them to learn how to do things well? Or are we going to see an increasing wave of C# and Java applications written in Ruby and Rails?

The blogging and mentoring that seems to be a core part of the Rails community helps a good deal in this regard. So too do some of the excellent books coming out (though we’re also starting to see some “me too” second string books, another inevitable consequence of popularity). But I’m not convinced that Rails has made the transition from being a close-knit band of top coders to being a good framework in widespread use. Yes, there is widespread use, but the Rails used by Joe Coder who is doing his first web application for the plumbing supply shop down the street is not the same Rails as used by those we all know and love from RailsConf and other high-profile venues.

What can we offer those starting (with Rails) developers in terms of getting ultra-productive? I think it’s not so much the model of 37Signals or HashRocket as it is a continued string of guidance. The fact that Rails is opinionated software is good in this regard; it makes it harder to write Rails applications that don’t work the Rails way. But it’s not enough; there is plenty of room for better documentation, better videos, more user groups, and so on. Writing the next complicated plugin as a tour de force of metaprogramming may be more fun, but if we’d like to see the community (as opposed to a relatively few developers) become supremely productive with Rails we could use a bit more concentration on the knowledge transfer side of things.

Mike Gunderloy, a former .NET developer, has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.

Welcome to this week's Rails TakeFive interview. This week, Part 2 of Adam Key's interview with David Flanagan, noted programmer and author of, among other books, The Ruby Programming Language.

Part 2, wherein Adam and David discuss the craft of programming:

For Part 1 of the interview, please click here.

David Flanagan is a computer programmer who spends most of his time writing about Ruby, JavaScript, and Java. His books with O'Reilly include The Ruby Programming Language, Java in a Nutshell, Java Examples in a Nutshell, JavaScript: The Definitive Guide, and JavaScript Pocket Reference. David has a degree in computer science and engineering from the Massachusetts Institute of Technology. He lives with his wife and children in the U.S. Pacific Northwest between the cities of Seattle, Washington and Vancouver, British Columbia. David has a blog at www.davidflanagan.com

Welcome to the Rails TakeFive interview series, where we "sit down" with leading developers from the community and bring you their insights into all things Ruby + Rails. This week, we'd thought we'd mix it up a little with Campfire, and invite FiveRuns developer, Rubyist and Raconteur Adam Keys to join David Flanagan, noted programmer and author who recently teamed up with Matz to write The Ruby Programming Language.

David and Adam had so much to talk about, we'll break the interview into two parts. This week - Part one, on the book.

David Flanagan is a computer programmer who spends most of his time writing about Ruby, JavaScript, and Java. His books with O'Reilly include The Ruby Programming Language, Java in a Nutshell, Java Examples in a Nutshell, JavaScript: The Definitive Guide, and JavaScript Pocket Reference. David has a degree in computer science and engineering from the Massachusetts Institute of Technology. He lives with his wife and children in the U.S. Pacific Northwest between the cities of Seattle, Washington and Vancouver, British Columbia. David has a blog at www.davidflanagan.com

Welcome to the Rails TakeFive interview series, FiveRuns’ ongoing effort to gather and share points of view from the Ruby on Rails community. This week, we’re happy to welcome three developers from TechCrunch, more specifically CrunchBase, a structured wiki project featuring technology companies, people, and investors that anyone can edit.

TechCrunch developer and recovering robot soccer addict, Henry Work pulled together fellow developers Mark McGranaghan, who recently left TechCrunch to head back to school to “graduate”, and their fearless intern Rob Olson to talk about Ruby on Rails and their use of the framework on CrunchBase.

And, just to let you know, CrunchBase is looking for Ruby developers. Just ping Henry if you’re interested!

FiveRuns: Thanks for taking the time to join us, guys! Let’s start off by talking about Rails 2.1, which was recently released with the help of over 1400 contributors. What about the new release excites you the most – time zones? Gem dependencies? UTC migrations? Better caching? And as a follow-up, what are the most important things in your mind to get done for the next major release?

CrunchBase: Time zones? Gem dependencies? Nay, we’re excited about the small things. Steadfast intern Rob thinks that Comment.last makes using Rails a little bit sweeter, especially from the console. Coming up, Henry’s excited about naming local variables inside collection partials, as well as setting conditions on join tables.

UTC migrations are great but they only resolve migration number conflicts. The following scenario has bitten us a few times:

• Henry creates a migration and runs it
• Gallant intern Rob creates a migration and runs it
• Both Henry and Rob push their new migrations to GitHub
• Henry easily runs Rob’s migration
• Rob curses and has to roll back his migration before running Henry’s

The other downside of UTC migrations is it’s less easy to find them in TextMate! Cmd-T then typing the migration number is basically muscle memory at this point.

FiveRuns: We’ve heard over and over that the GitHub community is what SourceForge should have been ;-). Now that the Rails repository has been moved over, can you talk a little bit about the benefits of GitHub and how SCM and agile development go hand-in-hand?

CrunchBase: Thanks to intrepid intern Rob, we’re now fully on Git, GitHub, and Lighthouse. Though it feels like we’ve been branching and merging with Subversion since grade school, Git’s been working out well. Mark makes a good point here about how lightweight both Git and GitHub are: you can quickly — or dare we say ‘agily’ — checkout projects and see what they’re about. And that’s probably the most important thing to us; a sleek, lightweight SCM and a power repo like GitHub allows us clone, branch, merge, and deploy faster. That time adds up.

FiveRuns: Spurred on by the recently announced Ruby Hero Awards, who is your own personal Ruby hero, and why?

CrunchBase: Ezra Zygmuntowicz – great hacker with great taste, entrepreneurial, supportive of the community that grows around his projects, fearless—like intern Rob.

FiveRuns: Bruce likes to talk about “backpacking” through other languages. What others have you dabbled in and/or are you learning right now? How have these travels impacted your work in Ruby? Your overall approach?

CrunchBase: Mark, who owns the most programming books by far, will take this one:

• Simplicity
• Elegance
• Taste
• SICP
• Functional style

• Brevity
• Discarding onions
• Challenging Assumptions

Mark also notes: “less code, in a functional style, building on and creating the right abstractions.”

FiveRuns: Beyond Merb, there are a great number of alternative frameworks for Ruby, including Nitro, Waves, Sinatra, Ramaze, and even the microframework Camping. Do you have any experience working with these frameworks? What have you seen so far that you really like? Dislike?

CrunchBase: Beyond Merb? We love Merb! McGranaghan closely follows the mailing list and is apt to say things like “that would be a perfect project for Merb.” As for the others, we are obviously excited to see/hear/read about the various web frameworks being created with Ruby. Sadly, we’ve only perused the occasional article. We’re still focused on learning as much as we can about Rails. We’re all about a year into Rails in terms of experience.

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

CrunchBase: Unflinching Intern Rob has this to say about Obie and HashRocket: “HashRocket, ultra-productive in 3 days, is a definitely intriguing. I think every company wishes they could push out that kind of productivity in three days. At TechCrunch we would like to see if their three day game plan can work for bigger projects as well. We would still be going from concept to completion in three days but completion would mark completion of one or more features, not the entire product. Basically every three days set up a game plan for three days from now. Anything that can’t be completed within three days either needs to be pushed back or broken into more manageable pieces. It would take multiple sets of 3 day pushes but it would help by keeping us focused and on a regular release cycle.”

CrunchBase is the free directory of technology companies, people, and investors that anyone can edit. It is developed and maintained by TechCrunch with the support of the tech community. Helping us out on this interview from the CrunchBase team are developers Henry Work, who joined CrunchBase to rewrite the site to its current version. Henry is a former team captain for the Northern Bites, Bowdoin College’s 4-Legged League RoboCup team and winner of the 2007 RoboCup World Championships. Also, Mark McGranaghan a student, developer, and entrepreneur who recently left TechCrunch to “graduate”. And, Rob Olson, Intern for TechCrunch and student at UCI studying Computer Science.

Welcome to this week’s Rails TakeFive interview, our weekly discussion about Ruby on Rails with noted developers from throughout our community. This week, Ari Lerner of CitrusByte and among other things, creator of PoolParty, a framework for maintaining and running auto-scalable applications on Amazon’s EC2 cloud.

FiveRuns: Hi Ari – thanks for joining us! Our own Adam Keys recently gave a talk at RailsConf titled Oh, the Fail I’ve Known. In the talk, Adam outlined a few different kinds of fail: learning failure (the knowledge was available but you didn’t have it), technological failure (you did have the right tool), problem failure (barking up the wrong tree), and so on. If you don’t mind, give us an example of the fail you’ve known?

Ari Lerner: The crumbling foundation fail:

We’ve all been there, the last remaining hours before a deadline and you just can’t get this one feature to work quite right, your specs are falling behind and you haven’t slept in 2 days. You figure you can hack up the remaining features before the meeting even though you know it is just a hack.

What is wrong with this approach is that those features that you implement and hack together end up as artifacts, end up staying in your code. Without a solid foundation for the feature you are constantly hacking against a poorly written weak base. Before you know it, the next crunch time is just around the corner and you are building hacks on top of your original hacks… and so it goes.

I’ve befallen this issue more times than I would like to recount. It can be a struggle, but don’t give up on best practices and the process. The application is really, in the end only as strong as your weakest line of code.

FiveRuns: Now that the Rails repository has been moved over to Github, can you talk a little bit about the benefits of Github and how SCM and agile development go hand-in-hand?

Ari Lerner: Git’s introduction into my workflow has not only revolutionized how I operate as a developer, but how my entire team works together. It is not the only distributed version control system in the world, but the power and flexibility it provides certainly makes the SCM process enjoyable.

I’ve also never felt as connected to other developers on my team as I have when working with Git. The SCM encourages discussion in a way that non-distributed VCSs cannot.

As a development shop, Github allows us to watch our commit frequencies, easily find our points of weakness, open new projects, and then share those with the world. In fact, it’s so incredibly useful that it’s replaced Google as my homepage – that’s how much I appreciate it.

FiveRuns: Bruce likes to talk about “backpacking” through other languages. What others have you dabbled in and/or are you learning right now? How have these travels impacted your work in Ruby? Your overall approach?

Ari Lerner: Knowledge is never a bad thing. Derek Silvers’ public departure from Rails last year summed up my feelings about other languages simply: It’s the most beautiful PHP I’ve ever written, all wonderfully MVC and DRY, and I owe it all to (Ruby on) Rails. With that in mind, I’m constantly learning new languages and techniques, reading through others’ code, and paging through science journals for this knowledge. Amongst several other worthy contenders, the language that has impacted me the most is Prolog. Conceptually foreign, it’s a language that engages both sides of the brain. I’ve recently been writing more C/Objective-C and sifting through yacc/lex.

Ruby – possibly my favorite development language – is incredibly powerful, but it’s ultimately a programming language. I don’t think that Ruby has made me a better programmer, but it has given me the tools to make that process easier. Just as Wesley outsmarts Vizzini in the classic poison scene of “The Princess Bride” with knowledge outside of the scope of the issue at hand, using knowledge outside of my comfort zone only makes me stronger.

FiveRuns: Beyond Merb, there are a great number of alternative frameworks for Ruby, including Nitro, Waves, Sinatra, Ramaze, and even the microframework Camping. Do you have any experience working with these frameworks? What have you seen so far that you really like? Dislike?

Ari Lerner: Rails, Django, Drupal, and others are all great tools – when wielded properly. I think that developers often get mired down when trying to use their one-size-fits-all-tool-of-choice when approaching a problem, and need to think critically about these tools and how to use them. You wouldn’t bring a butter knife to fight a dragon, nor should you… so why use beefy Rails to build a video transcoder when you can use Sinatra?

I have had quite a bit of experience working and contributing to Sinatra and have had the opportunity to push several applications into production. Not only are they maintainable and self-contained, but they are fun to write! I mean, how can you hate the

get '/' do
 "This is the return response from the root body"
end

You can’t.

The trend is growing in the alternative-framework community to slim the framework down and include only what is necessary. This is a great asset for these little frameworks. I hope the trend continues and I look forward to seeing what comes out next.

FiveRuns: Amazon + Rails seems to be a prevalent choice right now,looking way back to the first instances as early as 2006, and seeing how far we have come. Can you talk a little bit about the benefits and challenges here?

Ari Lerner: Amazon’s Web Services is probably the technology that excites me the most at the moment. The unprecedented flexibility enables developers to play, explore and harness the growing landscape of cloud computing. The last time I felt the joy of working with a new technology, I was writing “Drug Warz” on my Ti-83. If you have not yet looked into it, I highly suggest you take a peek.

Now to answer your question!

Cloud computing is all the rage today. Just as Rails revolutionized the web development framework, cloud computing is the next logical step in hosting, but it’s not going to solve all hosting issues. The non-technical challenge is to recognize it is just another weapon in your development tool-belt. The developer is the real secret sauce.

The largest technological challenges are configuration and maintenance of the EC2 instances. there is software on all sides of the spectrum that can aid in automating this process that can aid in automating this process, from my own open-source PoolParty to commercial RightScale that aids in support.

Amazon’s EC2 makes it tempting to throw away proven techniques of deployment and management, but breaking the encapsulation of the methodologies just spells disaster. I am always in favor of using all the right tools available, but in their proper place.

I think it would be a mistake to have your application aware of its own hosting environment. You don’t want your software knowing it is running on a cloud, it should do what it does best… be the application.

Ari Lerner is a solutions architect at CitrusByte in Los Angeles, Ca. He is a core contributor and has been working with Rails since version 0.6. He has recently released PoolParty, an open-source approach for managing and scaling cloud-computing instances. He graduated from the University of Arizona with a degree in Computer Science and in Theatre Arts.

Welcome to this week’s Rails TakeFive interview, our weekly discussion about Ruby on Rails with noted developers from throughout our community. This week, we’re honored to be joined by Ryan Bates, the producer of Railscasts, the free Ruby on Rails screencast series.

FiveRuns: Welcome Ryan, and thanks for taking the time to join us! We’ve asked several folks recently about Rails 2.1. With over 1,400 contributors, clearly a community effort. What about the new release excites you the most? And, what are the most important things in your mind to get done for the next major release?

Ryan Bates: By far my favorite feature in Rails 2.1 is named_scope. Rails has long had the power of scoping finds, but I don’t think it reached its full potential until now. named_scope cleans up my code considerably in every application I’ve worked on.

Second, I would have to say gem dependencies. In the past it’s always been a struggle juggling gems and plugins around for apps. Now specifying which gems an app requires (and in which environments) is so easy. I can see plugins going away in favor of gems.

For the next major Rails release, I’m excited about Active Model. That’s the abstraction of various Active Record and Active Resource functionality. This would, for example, make it easy to add validations to custom models which don’t have a database back-end.

FiveRuns: Some have said that the GitHub community is what SourceForge should have been! Now that the Rails repository has been moved over, can you talk a little bit about the benefits of Github?

Ryan Bates: Wow, I’m glad you asked this. GitHub has improved my coding more than any other tool recently. Not only because it introduced me to Git, but because it brings the social aspect into coding like never before.

There’s a saying that goes something like this. You should program for people first, computers second. It’s easier to go the extra mile for readability when you know others may be watching.

Also, one of the best ways to improve your own code is to read other code. GitHub makes it easy to follow master programmers and learn from their code.

On top of all this, it makes coding more enjoyable. Now I look for excuses to code because it’s so much fun to put my project on GitHub and share it with the world.

FiveRuns: Bruce likes to talk about “backpacking” through other languages. What others have you dabbled in and/or are you learning right now? How have these travels impacted your work in Ruby? Your overall approach?

Ryan Bates: While not necessarily a language, I have been learning a lot more about the command line and specifically Z Shell (zsh) lately. Here is a tool I use every day, but never made the most of until recently. Once you know what commands you have available, it’s amazing how much can be done by just piping a few of them together in the shell instead of writing a 20 line Ruby script.

I find Ruby and the command line work well together too. Working with files can get a little clumsy in Ruby. Now I sometimes call out to the shell in the middle of Ruby to do the job.

FiveRuns: Spurred on by the recently announced Ruby Hero Awards, who is your own personal Ruby hero, and why?

Ryan Bates: Chris Wanstrath. I have long been a fan of errtheblog.com. Oh, and GitHub. Need I say more?

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

Ryan Bates: Hashrocket’s 3 day launch is inspirational. As a programmer, it’s very easy for me to get caught up in how best to code something without actually coding it. I forget this important agile principle: Do the simplest thing that could possibly work.

Time constraints are a great way to enforce this. Next time when you need to add a feature, set the timer for an hour (give or take) and get started. If you haven’t made some good progress when the buzzer goes off, then perhaps you need to take another look at your problem and approach it from another direction or break it up. It’s too easy to waste hours or more in the “planning” stages to determine how best to code something.

I like to parallel programming to drawing. When starting a drawing you first sketch out the scene with a light pencil. It’s not perfect, but the lines are easy to erase and change if necessary. The sketch is also very fast which makes it cost little. This is important in case you start drawing from the wrong perspective, you can catch this early and start over without much loss.

Ryan Bates has been involved in web development since 1998. In 2005 he started working professionally with Ruby on Rails and is now best known for his work on Railscasts, the free Ruby on Rails screencast series.

Welcome to this week’s edition of Rails TakeFive, our ongoing interview series of insight and commentary from notable members of the Ruby and Rails community. This week, we’re happy to welcome Jacques Crocker, a Rails developer from Palo Alto and the man behind RailsJedi.com.

FiveRuns: Welcome Jacques, and thanks for joining us! Let’s kick it off by talking 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?

Jacques Crocker: Rails 2.1 was an amazing point release. One of my biggest pain points for a long time has been gem dependencies. 99% of all my Capistrano deployment failures up until recently were because one gem or another was installed on my local machine but not on the server. In fact, I was halfway done writing my own little gem dependency management plugin that was in use on several of my sites before I saw the edge Rails announcement and subsequently ripped out all traces of my version of the code.

Also, named_scope was a very nice addition to the core. I was already using the excellent scope_out plugin on all my projects, however it had some quirks that have all been smoothed out after switching over to named_scope.

The most immediate need I see for the next release of Rails is to be able to split up large rails projects into separate projects that can easily share code. As soon as any Rails project gets up to 25-30 controllers, it starts to lose a lot of the fun it had when it was 5-6 controllers. But if your Rails project was instead maybe 4 independent but related applications, each with 5-6 controllers then I think development would be a lot more enjoyable for large projects. The trick is allowing these projects to reuse common functionality without becoming too interconnected so they can be swapped out and shared easily. Rails Core needs to address this if they want to take on the real scalability problem, that is scaling a large code-base.

I’d also love for them to ditch migrations altogether and integrate PJ’s auto_migrations plugin.

FiveRuns: You’ve recently written about Phusion Passenger. Tell us a little about your experiences with it so far.

Jacques Crocker: Yep, I’ve been using mod_rails extensively since RailsConf. Given the meager amounts of memory most virtual servers provide, I see Phusion Passenger as a massive benefit since you no longer have to worry about running X numbers of mongrels, and can rely on Passenger to scale up and down as needed. In addition, the use of Enterprise Ruby has decreased memory usage on my servers fairly dramatically (20-30%).

Deployments with Passenger have been a big improvement over the old mongrel/nginx process. It cut my Capistrano config in half, as I used to have all the nginx load balancing config, and mongrel setup as part of my deploy.rb. Now it’s just a simple git update, gem install, migration, and server restart. I’m even exploring the possibility of running any pending migrations automatically as part of the application initializer.

I’m also really excited about the Rack support, giving us an easy way to deploy other Ruby frameworks (like Merb). Rails 2.2 should bring Rack compatibility as well. That should enable a consistent deployment platform for all Ruby web frameworks.

FiveRuns: On that note, let’s talk about Merb – they are all about being agnostic—ORM-agnostic, JavaScript library agnostic, and template language agnostic – what does this mean? And what does it mean to be “thread-safe”? Is there promise in implementing Merb alongside of Rails, say, for processing?

Jacques Crocker: I think Merb is a natural response to some of the wrong choices the Ruby on Rails team made in picking libraries to promote. While Rails initially got me into Prototype and Scriptaculous, I quickly grew frustrated with the framework and made the switch to JQuery. In fact, every time I fork my base Rails project, by default it has JQuery for Javascript, HAML for views, and Sass for stylesheets. I have a suspicion that within a year, it might also include DataMapper as a replacement for ActiveRecord.

I was extremely happy to see that Merb decided to implement “slices”, which is similar to Rails Engines, a hugely mistreated Rails plugin. Engines could have been revolutionary had it been encouraged and integrated by the Rails Core. I’m hoping that merb-slices will demonstrate to the Rails Core team that pluggable, self-contained apps are really the only way we’ll be able to manage our applications’ rapidly growing complexity.

The whole “thread-safe” concern, for me, has been rendered mostly irrelevent. With Mongrel clusters (and now Passenger), the core threading issues have been fairly easy to work around. As for mixing Merb and Rails on the same application, it’s probably a bad idea. If you need an alternative for some fast processing alongside Rails, Sinatra would be an even lighter, faster alternative.

FiveRuns: Beyond Merb, you mentioned Sinatra, but there are a great number of alternative frameworks for Ruby, including Nitro, Waves, Ramaze, Camping, ... What have you seen so far that you really like? Dislike?

Jacques Crocker: After Erik Kastner’s excellent session at RailsConf this year, I starting using Sinatra on some toy projects and have been impressed with it.

Just being able to create all your controller actions in one file is great for small projects, as you don’t have to explore your project directories whenever you need to find something. Plus I love the fact that I can still use HAML and Sass, which drastically reduces the size of the HTML and CSS needed in the view.

The major downside of course is the lack of Rails plugins, which can save a lot of time implementing complex features like tagging and S3 file uploads and can be extremely time saving for even really small projects. However I think the Sinatra community is growing fast and will eventually have stable ports of all the most popular Rails plugins.

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?

Jacques Crocker: Obie has been a huge inspiration for me. I’ve been involved in rapid startup bootstrapping for a few years now, and it was great to see Hashrocket succeed in delivering rapid development projects as a packaged service.

I took part in last year’s Rails Rumble (building PubBud) and I think the capability is there for anyone to be able to build a significant web application in a few days time, given the right vision and tools. This year there are going to be way more teams, and a lot of excitement as people have been getting much better at building Rails apps fast. I’m looking forward to competing again.

The single best tip I can offer for “ultra-productivity” is to create and continuously improve upon your own Rails new project skeleton. In that skeleton app, collect all the most useful rails plugins, stabilize them, and make them your own. Add in base stylesheets and ui components (I use blueprint) so the views don’t slow you down. Also add in common helper methods that you frequently use.

They key is to use this skeleton often, that is use it to create a new web app. I try to start a new Rails project from my base project at least once a week. Most of the time I leave it after hacking for 3-4 hours, but each time I end up improving on the base project and extracting pieces of functionality into my asset library.

This was one of the ways I was able to implement OpenSourceRails in a single weekend. All the major features – file uploads, tagging, bookmarking, ratings – were stuff I’ve implemented before and were part of my library. Having a collection of tried and true pieces of functionality along with a well structured and familiar base project will be a big time saver on any new project.

Jacques Crocker is a Rails developer from Palo Alto and blogs at RailsJedi.com. He also runs OpenSourceRails.com, a gallery for open source ruby on rails web apps.