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.
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.
On Thursday, 15 November 2012 14:00:42 UTC-5, Tony T. 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 J.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.