Practicing Ruby

BTW, that online copy is the 1st edition of the book, for ruby 1.8.6 (or maybe even earlier). The language is now at 1.9.3, and while things are fundamentally the same there are assorted little differences. Still, as a free intro to the language it's not bad. If you want to buy a book I'd suggest The Ruby Programming Language, as well as anything by Gregory Brown or David A. Black. Greg also produces the Practicing Ruby newsletter which I cannot recommend highly enough. http://practicingruby.com/ Greg does amazing stuff. See also http://university.rubymendicant.com and http://blog.rubybestpractices.com

One of the best articlets I've read about the ruby dsl's was on practicingruby. You guys can check it out here https://practicingruby.com/articles/domain-specific-apis is free now.

I am the author of "Practicing Ruby" ( http://practicingruby.com ). It's a paid newsletter but I offer it for free for anyone who can't pay for it, and try to release back issues relatively frequently.

He said "[...] it is encouraged to think of it that way rather than calling functions." This is what Sandi Metz talks about when she speaks about message/responsibility centric design vs data-centric design in OOP. The conceptual difference is said to lead to different designs. You don't start out your design by thinking about what data you hold but you think about which responsibilities/roles you have and create objects around those by thinking how they might talk to each other to reach their goals. (I'm currently reading POODR by Sandi Metz, so this is still new to me, if I got anything wrong there then please feel free to correct me) https://www.practicingruby.com/articles/responsibility-centric-vs-data…

Not to pick on Rails, sorting files into "models / views / controllers" seems to be our first instinct. My pantry is organized that way: baking stuff goes here, oils go there, etc. A directory hierarchy feels more pleasant when it maps to features, instead. Less clutter. Most programmers do not care about OO design, but "connascence" has some persuasive arguments. https://randycoulman.com/blog/2013/08/27/connascence/ https://practicingruby.com/articles/connascence https://connascence.io/ > Knowing the various kinds of connascence gives us a metric for determining the characteristics and severity of the coupling in our systems. The idea is simple: The more remote the connection between two clusters of code, the weaker the connascence between them should be. > Good design principles encourages us to move from tight coupling to looser coupling where possible. But connascence allows us to be much more specific about what kinds of problems we’re dealing with, which makes it easier to reason about the types of refactorings that can be used to weaken the connascence between components.