Good question! I don't know either, haha. I would probably start by poking around Rails Casts, and talks from prior Ruby & Rails conferences. Ironically, I sub

Good question! I don't know either, haha. I would probably start by poking around Rails Casts, and talks from prior Ruby & Rails conferences. Ironically, I submitted a talk for Rails Conf this year that might've done this for you, but I wasn't accepted... although that doesn't mean I can't just make the talk myself anyway...! That said & very IMHO & bias note: I love Ruby - If you're approaching Ruby from a strict OO perspective, you're at best handicapping yourself and at worst tying your shoelaces together - although partly that's because (AFAIK) Ruby works off of Smalltalk's OO model (which is where the OO term originated) which doesn't really map to what's usually taught in schools. (Everything in Ruby is an object, including functions, and messages are passed between them. At the same time, "everything in Ruby is a function", in that the body of a class definition is also a function.) I generally start with either a flat Ruby script or a simple function (depending entirely on the "business" context of the work), rolling it out script kiddie and/or functional-programming style. As things get grow into complexity, that's when I start identifying where I may want classes and/or data objects. (Unless I'm writing an ActiveRecord model definition, then it's classic school OO from the start). One of reasons (IMHO) that this works is some good advice I got a long time ago: "Ruby is easy to write, so it's easy to rewrite." I say: Put your thoughtful effort towards how chunks of code relate to each other, and where they interact (function signatures being the clearest example), and you really can worry about everything else later (where you'll have the benefit of a better understanding of the problem space). Ritch Hickie's "Simple Made Easy" and ye olde SOLID principles will help out a lot here. Ruby is a playful language, it works well to play around :)