Little Known Ways to Ruby Mastery by Yehuda Katz

²³/Dec 2008 By Satish Talim

Ruby

A weekly series from the Ruby Masters

Welcome to the next installment of the weekly interview series on the RL blog – “Path to Ruby Mastery” – by top trainers and developers in the Ruby community, from across the globe. The interview series will provide insight and commentary from these notable Ruby trainers and developers, with the goal of facilitating and providing answers to the questions Ruby beginners face. We welcome your suggestions for interviewees and questions. Look for a new post every Tuesday!

Yehuda Katz, USA

This week, we’re happy to have Yehuda Katz from USA.

Satish Talim>> Welcome, Yehuda and thanks for taking out time to share your thoughts. For the benefit of the readers, could you tell us something about your self?

Yehuda>> I’m the current maintainer of the Merb project, and also work on the jQuery and DataMapper projects. Together, Merb, DataMapper, and jQuery are a killer stack that really ramps up productivity. I was an Accounting major in college, and got involved with Ruby in 2005, in the pre-1.0 days of Ruby on Rails. I love Ruby and the community around it, and believe that the future is bright for the language. I currently work for Engine Yard on the Merb project.

Keith Brady, Australia>> What are the pros and cons of Ruby that are being discussed in the development community and what is your opinion on that?

Yehuda>> A lot of people have talked about Ruby as too slow to really be viable. I debunked that in my keynote at MerbCamp. Because Rubyists are so industrious, most of the critical path of Ruby applications have been optimized in C (with servers like Thin and Ebb and bindings to XML libraries like LibXML). People are also concerned about the development process of the Standard Ruby. On the bright side, the RubySpec project has created a runnable test suite for what Ruby is, and the alternative implementations (Rubinius and JRuby) are pushing the language forward.

What’s great about Ruby is how quickly it exposes new developers to advanced programming techniques, like lambdas. You can’t get past simple iterations in Ruby before being exposed to lambdas, and many methods in common frameworks accept blocks (one of Ruby’s lambdas). Additionally, Ruby’s mutability makes it very easy to implement ceremony-less extensions to the language that make building frameworks like Rails or Merb simple and easy to use. Compare Rails or Merb with CakePHP or Struts if you want to see what I mean.

Finally, something that isn’t really related to the language itself is Rails’ strong emphasis on the 80/20 rule and convention over configuration. While Merb tries to go even further by making it possible to opt out of the conventions more granularly, the basic idea is fairly permeated in the Ruby community. It’s very difficult to make a Ruby library popular if it requires out-of-the-box configuration and does not attempt to provide a certain amount of common defaults.

Willian Molinari, Brazil>> What has been your biggest challenge while working with Ruby?

Yehuda>> I’d say the biggest challenge of working with Ruby is how dynamic the language is. While it makes it possible to create really powerful, simple language extensions (and thus makes Rails or Merb possible), those same features allow Ruby libraries to hide complexity and changes that aren’t easy to track down. The popular alias_method_chain feature, for instance, combined with metaprogramming creates methods that run in your application but that you can’t easily look at in source. In fact, it can sometimes be nearly impossible to figure out where all the pieces even come from.

That’s the reason for the Merb rule against alias_method_chain, but you can’t really solve this problem without making Ruby significantly less powerful. It’s important for Ruby programmers to define clear APIs for libraries that they release, and try to avoid opaque magic where possible. Where not possible, library developers should clearly document exactly what they’re doing, so people trying to debug those libraries can understand the underlying codebase.

Satish Talim>> Most beginners in Ruby, would like to contribute their time, skills and expertise to a project but invariably are unaware of where and how to do so. Could you suggest some?

Yehuda>> Merb of course! While I may be biased, the Merb project has a simple enough codebase (at around 6,000 lines for the core framework) to take a look at some outstanding tickets and dive in quickly. It’s also a relatively popular framework, so contributions you make could start helping developers very quickly. You can get information on how to get started contributing to Merb. You might also dive into other edgy projects like DataMapper or YARD. Both could use some love, but have the potential to really be game-changers to the Ruby ecosystem, so getting involved now could be a great way to get in on the ground floor. The only thing I’d add is that when getting involved in a project, make sure to understand the culture and goals of the project. Be humble while learning the rules and idiosyncrasies of the project and its team.

Keith Brady, Australia>> What types of applications are currently being developed in Ruby and what changes do you foresee over the next year or two?

Yehuda>> The biggest changes have to do with old Ruby infrastructure that’s being pushed to the breaking point. Rubygems, rake, and rdoc were all fantastic pieces of software during the earliest days of Ruby in the US, but the community is putting so much pressure on the projects that significant changes are afoot. Rubygems, for instance, really needs support for “packages”, a simple change that could dramatically improve the way large Ruby projects package their applications. I’d look for modifications or wholesale replacement of core pieces of Ruby infrastructure over the next year.

Michael Uplawski, Germany>> According to you, what is a comfortable size of a Ruby/Rails-project? Why?

Yehuda>> Once a Ruby projects gets larger than about 5-10,000 lines of code, I like to start breaking it up into modules. When I say modules, I mean defined sub-projects with their own external APIs that other modules connect to. This prevents the sort of intertwined Ruby projects that are extremely difficult to refactor because of how connected everything is to everything else. In a Merb project, I’d strongly recommend using slices for this purpose. Merb itself uses rubygems to separate out the core framework (around 6,000 LOC) and additional modules, which all use the same plugin API that we expect users to use in general.

Dennis Theisen, Germany>> Do you think Ruby is ready to be used in “Enterprise applications”? Kindly justify your answer.

Yehuda>> Absolutely. The productivity benefits alone justify using Ruby in the Enterprise. While certain parts of Ruby might still be rough (SOAP support is a good example), the language itself, and the frameworks surrounding it are so productive that it’s worth having to deal with the oddities of SOAP4R, for instance. Ruby is also fundamentally changing the way Enterprises should think about software. While it’s simple to think that you’re building a piece of software from the ground up with very little common infrastructure, the fact is that proprietary applications built inside enterprises are constantly reinventing the same wheels over and over and over. Since Ruby and its supporting infrastructure is open source, large companies can leverage the power of the work others are doing to avoid having to reinvent the wheel.

Additionally, as more and more large companies, like Yellow Pages, begin to use Ruby, the feedback loop becomes more powerful as more and more large companies feed back into the community. Engine Yard, the company I work for, has been on the forefront of encouraging contributions, and the ecosystem around Rails and Merb is growing every day (Gartner found that 1,000,000 developers are already using Ruby, and that number is expected to grow to 4,000,000 in just a few years).

Satish Talim>> Do you have any other suggestions for these participants (would-be Ruby developers)?

Yehuda>> Don’t be seduced by the power of the dark side. But seriously, Ruby is an extremely powerful language, but you should still define clear, consistent APIs to use both internally and in libraries. When testing, test those interfaces. Avoid mocking out large pieces of the interfaces that prevent you from determining whether the full application or library works. A clear API, with only a few public parts exposed, is worth its weight in pixie dust.

Satish Talim>> Thanks Yehuda for sharing your views with the RubyLearning participants.

On 30th Dec. we talk to Ilya Grigorik from Canada.

Disclaimer:
The opinions expressed are those of Yehuda Katz and do not necessarily reflect those of www.RubyLearning.com.

The Path to Ruby Mastery Series (So Far):

Tags// interviews, Little Known Ways to Ruby Mastery, Merb, Ruby, Ruby Beginners' Questions, The Ruby Programming Language, Yehuda Katz,

Ruby Learning

Not Just Ruby Any More!

Little Known Ways to Ruby Mastery by Yehuda Katz

A weekly series from the Ruby Masters