Forum: Ruby on Rails Getting Involved and Rails 3 Observations

Hello -

I would like to get involved in the Rails Core development. What's the
process for getting involved?

We've been working with Rails since 2006 and really enjoy the framework 
but
have some reservations around Rails 3's REST implementation and exposed
Java Script. The former seems to be an over reach for a framework and is 
an
application specific architectural decision. The latter takes something
that should be handled by the framework (wrapped and tested) and exposes
it. Migrating one project, both have made working with the framework
slower, more cumbersome and overly complex.

These issues block a clean upgrade path. An upgrade path of 're-write'
is not really acceptable for complex applications done for serious 
usages.

We have 10's of thousands of line applications that eventually need to 
be
upgraded. We need to make and bake some core changes to make this 
possible.
This should not effect the current Rails implementation but enable 
simple,
direct migrations and make the framework more flexible for new projects.
I'm fairly certain in our case it's quicker (and safer) to make these
changes to Rails proper than to rewrite our apps.  Since I'm positive 
we're
not alone on this front, we would like to share that work.

It's not clear how to get involved on this level but I'm willing to chip 
in
my 30 years of experience and that fancy degree achieved along the way 
to
the cause. If someone could point me the right direction, it would be
greatly appreciated.

Thanks,

TT

On 15 November 2012 19:00, Tony Thompson <tony@anthonythompson.net> 
wrote:
> Migrating one project, both have made working with the framework slower,
> Rails proper than to rewrite our apps.  Since I'm positive we're not alone
> on this front, we would like to share that work.
>
> It's not clear how to get involved on this level but I'm willing to chip in
> my 30 years of experience and that fancy degree achieved along the way to
> the cause. If someone could point me the right direction, it would be
> greatly appreciated.

You could try the rails core mailing Iist.
http://groups.google.com/group/rubyonrails-core?hl=en.

Colin

On Friday, November 16, 2012 9:36:13 AM UTC, Colin Law wrote:
>
>
> You could try the rails core mailing Iist.
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
Also try the rails-contrib IRC channel & github issues.

Fred

On Thursday, 15 November 2012 14:00:42 UTC-5, Tony Thompson wrote:
> that should be handled by the framework (wrapped and tested) and exposes
> it. Migrating one project, both have made working with the framework
> slower, more cumbersome and overly complex.
>
>
I'm not sure what you mean by "REST implementation". Sure, there's some
syntactic sugar available if you're using the idiomatic approach - but
there's nothing stopping you from ignoring all that and doing things
manually. From what I recall, that sugar isn't even new (dating back to
early Rails 2)...

Even less clear on "exposed Javascript" - is that an issue with the 
asset
pipeline, with the Rails UJS helpers, or something else?


We have 10's of thousands of line applications that eventually need to 
be
> upgraded. We need to make and bake some core changes to make this possible.
> This should not effect the current Rails implementation but enable simple,
> direct migrations and make the framework more flexible for new projects.
> I'm fairly certain in our case it's quicker (and safer) to make these
> changes to Rails proper than to rewrite our apps.  Since I'm positive we're
> not alone on this front, we would like to share that work.
>

rails-core is definitely the place to bring issues like this up, but I
don't think you'll get much traction if you want to introduce any 
changes
that break existing applications. You may be better off starting with a 
gem
that changes the offending behaviors that you can include into your
applications to smooth the migration process.

--Matt Jones