what Ruby knowledge should I have? [closed]

Question

I just discovered the what c# knowledge should I have? question and wondered about the same, but for Ruby. I consider Ruby to be my favorite programming language, and beyond learning the basics, at least what I've picked up from numerous Ruby on Rails projects and a few Ruby scripts, I've tried to learn from reading blogs like Gluttonous, O'Reilly Ruby, Ola Bini, and Polishing Ruby. I've also read in books like The Ruby Way.

However, I haven't felt fully prepared when being interviewed about my Ruby skills. I was asked once if I knew about closures and at first I responded that I didn't, but then I asked if the interviewer meant code blocks, like lambda and do...end, and he did. How did I go about 3 years of programming Ruby and trying to learn the language without learning that closures = code blocks?

So, my question to you is what knowledge should a Ruby programmer have of the Ruby language? What would you expect, as an interviewer for a Ruby position, me to know? Just list some topics, and I'll do the reading about them. Listing Ruby-specific tools like Ruby on Rails, Rake, Rack, etc. is good too, if you think that's necessary.

Answer 1

This is sort of from the top of my head; I'm sure I am missing a lot. Besides the things mentioned here, understanding programming and object-oriented programming in particular is a must, of course.

A few important language features:

• Realise that in Ruby, everything is an expression, and be able to apply that principle, even if you think it makes your code unreadable.
• Closures are mentioned; I would also expect Rubyists to know the differences between blocks and procs (and lambdas) and know how to convert between them. Closure mastery is important to being able to write beautiful Ruby, in my opinion.
• Operator overloading: know what happens when you define methods named [], []=, ==, +, <<, etc. on an object.
• Be proficient with most instance methods of Array, Enumerable and Hash (even if you don't know the exact definition by heart). Your Ruby code will be so much more verbose if you don't use methods like collect, inject, join, zip, etc. where appropriate.
• Thoroughly understand what Symbols are, and when you should use / avoid them.
• Understand what metaclasses are, know the difference between class variables and class instance variables.
• Know how object attributes work in Ruby, how you can define them with attr_accessor and friends, and how you can define them yourself.
• Be able to use modules, both as mix-ins and as namespacing tool. You should also understand how to mix-in instance methods and class methods (or be able to figure out how you could do it).
• Know the difference between raise/rescue and throw/catch, and be able to use both correctly.
• Understand how metaprogramming works, and at least have a basic idea of all the methods that allow you to do metaprogramming (mostly hidden in the classes Module and Object).
• Be able to use a Hash method argument as a substitute for named arguments (even if it's just because it's a common pattern).
• Know how concurrency does and doesn't work in Ruby.
• Continuations, even if they're rarely used.

Some vital tools:

• Know and understand Ruby gems
• and rake
• and RDoc.
• and YAML.

Some framework knowledge:

• Basic knowledge of Rails would be useful. Even if it's only because the outside world sometimes doesn't seem to know the difference between Rails and Ruby.
• Know there are other web frameworks than Rails: Merb, Sinatra, Camping, ...

Ultimately, keep in mind that the above is "just knowledge", and not skills. It's probably easy to pick up most of this if you're not familiar with it.

Answer 2

You could probably fill in any gaps in knowledge you have due to being a real programmer and not an academic by reading The Ruby Programming Language by the creator of Ruby, Yukihiro Matsumoto. It covers a lot of obscure details, such as the vagaries of multiple assignment in different kinds of lambdas, and is relatively new, covering new semantics in Ruby 1.9.

A boss of mine once told me that a long-term programmer that he knew and trusted once turned to him and asked, "I forget... how many bits are in a byte?" The moral of the story wasn't that this guy was an idiot--it was that it's sometimes possible to write a fair bit of competent code over a long term and miss out on things that seem to others as though they should be elementary.