Rails, Grails, and convention over configuration
Back in 2003 I wrote a quick application generator using turbine, java, and xml and published to sourceforge called thrust. It is extremely primitive by today's standards, but the important point is that is embraced the "convention over configuration" concept.
I now see a lot of folks jumping into rails/grails without really thinking about what it really means and what the proper application of these tools might be. For example, I see folks deciding that rails/grails is the best development environment for them to build an application, then subsequently decide to write custom code for every thing. While rails/grails are still really good development frameworks no matter what, in many regards deciding to override their default behavior instead of understanding the patterns and embracing them is selling the idea short.
In my experience, I see many software applications as a similar pattern applied to itself. Rails/Grails (and thrust) are designed to exploit this and enable an exponential speedup in development time as well as a reduction in apparent complexity. I say apparent complexity because it still exists, but the framework should absorb the essential complexity (the part you cannot get rid of) and hide it from the developer in most circumstances.
Lets use an example: Suppose you are writing an application with a collection of screens that allow you to edit some information in tables in a relation database. Using any of these three frameworks, you can define a template that all these screens should use and automagically generate a good starting point for most of your screens (CRUD) + directory listing per entity.
If for some reason, you have no need for CRUD or a listing, or if you aren't using a database... you might be using the wrong tool for the job. That's not to say that these frameworks are not useful in this context, but you might not be getting the value that you COULD have from it.
I now see a lot of folks jumping into rails/grails without really thinking about what it really means and what the proper application of these tools might be. For example, I see folks deciding that rails/grails is the best development environment for them to build an application, then subsequently decide to write custom code for every thing. While rails/grails are still really good development frameworks no matter what, in many regards deciding to override their default behavior instead of understanding the patterns and embracing them is selling the idea short.
In my experience, I see many software applications as a similar pattern applied to itself. Rails/Grails (and thrust) are designed to exploit this and enable an exponential speedup in development time as well as a reduction in apparent complexity. I say apparent complexity because it still exists, but the framework should absorb the essential complexity (the part you cannot get rid of) and hide it from the developer in most circumstances.
Lets use an example: Suppose you are writing an application with a collection of screens that allow you to edit some information in tables in a relation database. Using any of these three frameworks, you can define a template that all these screens should use and automagically generate a good starting point for most of your screens (CRUD) + directory listing per entity.
If for some reason, you have no need for CRUD or a listing, or if you aren't using a database... you might be using the wrong tool for the job. That's not to say that these frameworks are not useful in this context, but you might not be getting the value that you COULD have from it.
Comments