Comments on: Extracting Rails code http://www.sitepoint.com/blogs/2006/05/24/extracting-rails-code/ Sun, 07 Sep 2008 21:57:54 +0000 http://wordpress.org/?v=2.5 By: Anonymous http://www.sitepoint.com/blogs/2006/05/24/extracting-rails-code/#comment-29921 Anonymous Mon, 12 Jun 2006 09:32:20 +0000 http://www.sitepoint.com/blogs/?p=1550#comment-29921 <strong><em><code><blockquote><a href="http://springframework.org" rel="nofollow"></a></blockquote></code></em></strong>

]]> By: Ryan Bates http://www.sitepoint.com/blogs/2006/05/24/extracting-rails-code/#comment-26543 Ryan Bates Fri, 26 May 2006 17:45:11 +0000 http://www.sitepoint.com/blogs/?p=1550#comment-26543 Well, I think Rails does have a bit of a barrier as well, but in a different sense. You have to learn to do things the "Rails Way" or else you will be fighting it and have a terrible time. When I first started using Rails I wanted to do things my way. I wanted more control over the database schema, the naming of the Controller and Model classes, and even the organization of the files. Once I accepted the Rails way of doing things, I found it was such a better method and makes things so much easier. It is amazing how much functionality you can get with such little effort when following the conventions. Beyond that, there are many other practices that rails encourages, but doesn't require. Test Driven Development for example isn't required, but with Rails it is so easy you might as well try it. Sorry for the off topic tangent. Well, I think Rails does have a bit of a barrier as well, but in a different sense. You have to learn to do things the “Rails Way” or else you will be fighting it and have a terrible time. When I first started using Rails I wanted to do things my way. I wanted more control over the database schema, the naming of the Controller and Model classes, and even the organization of the files. Once I accepted the Rails way of doing things, I found it was such a better method and makes things so much easier. It is amazing how much functionality you can get with such little effort when following the conventions.

Beyond that, there are many other practices that rails encourages, but doesn’t require. Test Driven Development for example isn’t required, but with Rails it is so easy you might as well try it.

Sorry for the off topic tangent.

]]> By: timlucas http://www.sitepoint.com/blogs/2006/05/24/extracting-rails-code/#comment-25863 timlucas Thu, 25 May 2006 00:47:13 +0000 http://www.sitepoint.com/blogs/?p=1550#comment-25863 Thanks Ryan. "Do the the simplest thing that could possibly work" was probably <em>the biggest</em> idea that I liked about Rails, but I love the fact the you don't hear much harping on about the the "rules". At the end of the day we're all trying to solve real problems and spend the least amount of time. Rails doesn't seem too scary to pick up and learn, but XP on the other hand seems to have quite a barrier to entry. "Rails: Web oriented XP for the rest of us" ? Thanks Ryan. “Do the the simplest thing that could possibly work” was probably the biggest idea that I liked about Rails, but I love the fact the you don’t hear much harping on about the the “rules”. At the end of the day we’re all trying to solve real problems and spend the least amount of time. Rails doesn’t seem too scary to pick up and learn, but XP on the other hand seems to have quite a barrier to entry. “Rails: Web oriented XP for the rest of us” ?

]]> By: Ryan Bates http://www.sitepoint.com/blogs/2006/05/24/extracting-rails-code/#comment-25836 Ryan Bates Wed, 24 May 2006 21:00:53 +0000 http://www.sitepoint.com/blogs/?p=1550#comment-25836 One thing I like about rails and its community is it seems to follow a lot of Extreme Programming practices. Avoiding unnecessary abstraction goes right along with the practices You Aren't Gonna Need It and Do the Simplest Thing that could Possibly Work. http://xp.c2.com/YouArentGonnaNeedIt.html http://xp.c2.com/DoTheSimplestThingThatCouldPossiblyWork.html I like to think of it this way: Adding abstraction prematurely is like trying to teach someone how to whistle when you don't even know how to whistle. In other words, don't add abstraction until you understand the domain completely; otherwise you are just guessing - shooting in the dark. Abstraction creates flexibility at the cost of complexitiy, and you want to avoid unnecessary complexity. Once you see the direct need for abstraction in your implementation, that is the time to add it through refactoring. One thing I like about rails and its community is it seems to follow a lot of Extreme Programming practices. Avoiding unnecessary abstraction goes right along with the practices You Aren’t Gonna Need It and Do the Simplest Thing that could Possibly Work.

http://xp.c2.com/YouArentGonnaNeedIt.html
http://xp.c2.com/DoTheSimplestThingThatCouldPossiblyWork.html

I like to think of it this way: Adding abstraction prematurely is like trying to teach someone how to whistle when you don’t even know how to whistle. In other words, don’t add abstraction until you understand the domain completely; otherwise you are just guessing - shooting in the dark. Abstraction creates flexibility at the cost of complexitiy, and you want to avoid unnecessary complexity. Once you see the direct need for abstraction in your implementation, that is the time to add it through refactoring.

]]>