Re: [Rails] Getting Involved and Rails 3 Observations

28 views
Skip to first unread message

Colin Law

unread,
Nov 16, 2012, 4:35:10 AM11/16/12
to rubyonra...@googlegroups.com
On 15 November 2012 19:00, Tony Thompson <to...@anthonythompson.net> wrote:
> 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.

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

Colin

Frederick Cheung

unread,
Nov 16, 2012, 7:01:00 AM11/16/12
to rubyonra...@googlegroups.com, cla...@googlemail.com


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 

Matt Jones

unread,
Nov 16, 2012, 3:46:02 PM11/16/12
to rubyonra...@googlegroups.com


On Thursday, 15 November 2012 14:00:42 UTC-5, Tony Thompson wrote:
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. 


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
Reply all
Reply to author
Forward
0 new messages