Ruby's a pretty populate language that we've worked a lot with over the past years.

Debugging Tips

Ruby-Debug is your friend

Debugger.post_mortem do  
  block
end

Will do a post mortem if the block throws an exception. (Debugger.post_mortem by itself does this, but if say this is part of a Rake task you are better off using the block version of this -- rake has a lot of internal catches to prevent exceptions going out, and is hard to retrofit so the global variant of this function works).

Getting Variables and values in the scope where an exception was raised

See this answer on StackOverflow.com for a ton of code to answer this question

Open Classes are your enemy

* How To Find Where A Method Is Defined

Multiple Version Of Ruby

Multiple Versions of Ruby (with version chooser menu shell script)

OR, a real tool to do it...

The Dr Nic approved way...

AND THEN READ how to get Rubygems up with this new Ruby...

Documenting Ruby

Comments are a code smell

• Neal: Ruby's an expressive language, it should be obvious from the code what it does!
• Ryan: Comments should be salt, not the "eat your vegetables" task your CS professor told you to do.

Places where you should use comments

• Anything important / test breaking I should know about before I refactor this? (Example: alias_method_chain methods - you need to call the original method)

Comments Should

• Describe BECAUSE or SHOULD conditions (blah blah blah BECAUSE blah blah)
• Explain why you implemented it your way, so it can be compared to the alternative method, instead of being thrown out because "we can't figure it out so it sucks"
• Help refactorers avoid mistakes that you ran up against. (Principal of: make it easy for someone else to help you make your code better)

Summary

• When righting comments, use "SHOULD" or "BECAUSE" statements
• Should be the salt, to flavor the dish, but not a course of a meal.

Comments:

Add comments by visiting: Ruby/Comments