Comments on: On The Desired Complexity of Rails http://www.napcsweb.com/blog/2011/08/21/on-the-desired-complexity-of-rails/ professional web development and consulting Mon, 22 Aug 2011 18:56:36 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Joe Fiorini http://www.napcsweb.com/blog/2011/08/21/on-the-desired-complexity-of-rails/comment-page-1/#comment-28547 Joe Fiorini Mon, 22 Aug 2011 18:56:36 +0000 http://www.napcsweb.com/blog/?p=294#comment-28547 Well said Brian. I too have seen a use for some of these more complex patterns in my projects. Let's always remember that we're using Ruby. For example, dependency injection is useful in some cases in Ruby, but any Ruby developer worth his salt should be able to think of a better way to configure an IoC container than a complex XML schema. As a more concrete example, when I've written presenters (similar to the decorators you mentioned) I make heavy use of Ruby's Delegator class so I can completely wrap the model. IMO far more elegant than what I could do in a less dynamic language. Rails was built to make developers more productive. As we apply these patterns we should use that as our constraint to build better solutions than what we've had in the past. Well said Brian. I too have seen a use for some of these more complex patterns in my projects. Let’s always remember that we’re using Ruby. For example, dependency injection is useful in some cases in Ruby, but any Ruby developer worth his salt should be able to think of a better way to configure an IoC container than a complex XML schema. As a more concrete example, when I’ve written presenters (similar to the decorators you mentioned) I make heavy use of Ruby’s Delegator class so I can completely wrap the model. IMO far more elegant than what I could do in a less dynamic language. Rails was built to make developers more productive. As we apply these patterns we should use that as our constraint to build better solutions than what we’ve had in the past.

]]> By: bryanl http://www.napcsweb.com/blog/2011/08/21/on-the-desired-complexity-of-rails/comment-page-1/#comment-28546 bryanl Mon, 22 Aug 2011 18:53:38 +0000 http://www.napcsweb.com/blog/?p=294#comment-28546 You've stumbled on the fine line of "should we make this easy to code, or should we be nice to future developers?" I could type paragraphs and paragraphs of reasons to keep things simple, but I'd just be wasting my time. Projects grow up. Projects get transferred to other developers. The time tested patterns that may bring with them a bit of complexity always seem to be the better solutions. The trick is to turn the complex pattern into a simple abstraction. You’ve stumbled on the fine line of “should we make this easy to code, or should we be nice to future developers?” I could type paragraphs and paragraphs of reasons to keep things simple, but I’d just be wasting my time.

Projects grow up. Projects get transferred to other developers. The time tested patterns that may bring with them a bit of complexity always seem to be the better solutions. The trick is to turn the complex pattern into a simple abstraction.

]]>