Railsday 2006 Draws to a Close

This event is the perfect way to highlight the power of Rails. There just aren't many toolsets out there that let you put together this much in this little time.

This event is the perfect way to highlight the power of Rails. There
just aren't many toolsets out there that let you put together this much
in this little time.

I don't mean to start a flame war but this contest proves nothing except that RoR is indeed a great and complete RAD framework. Developping an application in 24 hours is not a small accomplishment and I applaud the results. But where I work applications usually last more than 10 years and go throught many law reforms. Anyway, my point is not to flame Rails but more against those type of contests. They really shows only side of the coin : how great Rails is as a RAD framework. If RAD for any reason doesn't fit in your corporation, than it means nothing.

This event is the perfect way to highlight the power of Rails. There
just aren't many toolsets out there that let you put together this much
in this little time.

I
don't mean to start a flame war but this contest proves nothing except
that RoR is indeed a great and complete RAD framework. [...snipped, read original above] If RAD for
any reason doesn't fit in your corporation, than it means nothing.

So
you work in an organization that prefers large, highly-coupled,

No

bureaucratic-driven,

Yes since I work in the laws sector.

all-in-on applications

Not really.

Look I like parts of RoR but after evaluating it I have 2 main concerns

1) i18n support isn't there. I need to produce bilingual web application.

2) Active Record can't deal really well with legacy DB schemas. It doesn't have the power of a complete ORM tool.

Anyway, I won't go on because I don't want this to degenerate in a flame war RoR versus .net/java/whatever. My point is just that those contests show the main strength or RoR : being a RAD tool. Producing the application is one thing, evolving it is another and is very important in many corporations.

So you work in an organization that prefers large, highly-coupled, deliberate, bureaucratic-driven, all-in-on applications? Just curious, as that seems to be the antithesis of Rails.

I agree with what you're saying in principle -- if you're saying Rails loses a lot of its productivity when you have to retro-fit it into a legacy schema/bureaucratic environment. ;)

So you work in an organization that prefers large, highly-coupled, deliberate, bureaucratic-driven, all-in-on applications? Just curious, as that seems to be the antithesis of Rails.

Trying to keep myself and the topic out of the flame, I think this a too strong affirmation: not all applications built in the IT shops can be built with RoR, and this doesn't mean by any means that those organizations prefere "large, highly-coupled, [...]".

This one is IMO once again too strong:

I agree with what you're saying in principle -- if you're saying Rails loses a lot of its productivity when you have to retro-fit it into a legacy schema/bureaucratic environment. ;)

Afaik the limitations of each and every framework are discussed extensively all over the net. Another important point is that for companies/teams it is possible to be a lot more productive with the frameworks they know and the tools they have, than to even consider switching to another toolkit. Some other times, the client has the final word on which technologies should be used. When deciding how an application is gonna be built there are a lot of factors and facts that count. And the decission is almost always difficult, and the worst decission is to say: "hey I can build all my apps with framework X" (moreover when the decission is taken based on the coolness factor).