BT

Railsday 2006 Draws to a Close

| by Obie Fernandez Follow 0 Followers on Jun 17, 2006. Estimated reading time: less than one minute |
Railsday 2006 seems have lived up to its promise of excitement. Over 180 teams of 1-3 Rails developers registered for the contest, competing for fame and great prizes, including a MacBook Pro. According to the real-time stats available at http://spectate.railsday2006.com/ commits to the official Subversion repository peaked at 640 per hour (over 10 checkins per second!) around 12am EST, the last few minutes of the contest. In all, the contestants made over 5400 commits in 24 hours. Now the only thing that remains is to see what all the teams actually wrote in their day of furious coding.

Some of the URLs have already started to bubble up out of the fray. Rails superstars Technoweenie, Courtenay and  Justin Palmer had the most commits for their Railsday app bloction.com and were kind of enough to post photos of their team in action. Other impressive Railsday 2006 apps already visible online include Advisr, Eventell, and SimpleForms.

With such a large pool of participants, now it will be very interesting to see how long it takes to judge the winners.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

No accident by Michael Furtak

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.

Re: No accident by Alexandre Poitras

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.

Re: No accident by Phil Barnes

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.


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.

Re: No accident by Alexandre Poitras

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.


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.

Re: No accident by Phil Barnes

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.



Wow, this might end up in "blockquote hell", but here goes ;)

I'm not trying to incite an argument -- just that so many times I've heard a 'it doesn't work in my organization' argument without substance. So on that count, I appreciate your addendum. :)



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.


There are a number of options for i18n, just none that are inherent to Rails itself: wiki.rubyonrails.com/rails/pages/Internationali...


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


Is the issue the schema naming or the schema OR mapping? wiki.rubyonrails.com/rails/pages/HowToUseLegacy...


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.


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. ;)

My intention is the same as yours -- to make sure that people are aware of where Rails excels, where it is less than ideal, and to keep the conversation out of "flame territory". :)

Thanks!

more clarifications without flame by Alex Popescu

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).

BR,

./alex
--
.w( the_mindstorm )p.

Re: more clarifications without flame by Phil Barnes

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, [...]".


It was honestly just a question, not an implication that a non-rails app would need to be any (or all) of the (negative?) attributes I put forth. Fortunately, Alexandre responded positively, as I hoped. :)


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).


I'm not quite sure what that has to do with my statement about Rails and legacy/bureaucratic environments, but I think I agree with you. ;)

The original point I was trying to make, was that just because you work within environment XYZ doesn't necessarily preclude you from using Rails, simply because you think it doesn't support this or that. I find it's a useful exercise to challenge why Rails should or should not be overlooked due to technical or even business factors. I know noone, myself included, that claims any piece of technology is the proverbial "hammer to use on all nails".

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT