Please, keep changing!
Rodrigo Rosenfeld Rosas
I'd just like you to know there are lots of people that are actually
happy with the way Rails is currently doing.
I'm one of them.
I did find very valuable all the work put in Rails 3 and I find it much
better organized than before versions and I'm expecting Rails 4 to be
even better.
Of course there are lots of things to be improved in Rails, specially in
the documentation (I think Rails 1 documentation model was the best I've
seen for Rails so far), but that doesn't mean Rails is doing it wrong.
It doesn't mean Rails 3 was a mistake. It doesn't mean Rails should be
trying really hard to keep backward compatibility, since I suffer
everyday working with Java APIs that were poorly designed (as the
language itself) just because improving them would break backward
compatibilities.
Or like having to write "$.each(function(index, element){})" in jQuery
because "each" was badly designed when it was born inverting the
parameters most useful order.
Reading all those articles made me think that some of you would consider
those criticisms and re-evaluate the future of Rails.
So, I'm here to say that lots of other developers do support the way
Rails is currently evolving and we want it to keep it in the same "rails".
Thank you very much for all effort put in its code-base.
Cheers,
Rodrigo.
Joel Moss
--You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.To post to this group, send email to rubyonra...@googlegroups.com.To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Guilherme Dutra
Atenciosamente,
Guilherme Pereira Dutra,
Fone: (34) 8407-0109
Rodrigo Rosenfeld Rosas
Em 01-03-2012 16:48, Guilherme Dutra escreveu:
Did you mean that Rails would keep changing or would be the same? You weren't clear about that.
Em 1 de março de 2012 12:56, Joel Moss <jo...@developwithstyle.com> escreveu:
ditto!! Good job guys!
--Joel Moss
James B. Byrne
On Thursday, 1 March 2012 at 15:52, Rodrigo Rosenfeld
Rosas wrote:
> I've been reading lots of articles criticizing Rails
> in the last days.
>
What articles are those?
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:Byr...@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
Rodrigo Rosenfeld Rosas
On Thursday, 1 March 2012 at 15:52, Rodrigo Rosenfeld Rosas wrote:I've been reading lots of articles criticizing Rails in the last days.What articles are those?
http://gilesbowkett.blogspot.com/2012/02/rails-went-off-rails-why-im-rebuilding.html
http://merbist.com/2012/02/29/learning-from-rails-failures/
I do respect their opinion. I just think I should state my opinion too so that their opinion don't become the only one.
Santiago Pastorino
if someone is doing that we should definitely listen to critics, try
to improve what is wrong and not being :emo: about that.
Anyway I didn't find any of the posts as personal attacks or bad
suited but perhaps is just me.
Cheers.
--
Santiago Pastorino
WyeWorks Co-founder
http://www.wyeworks.com
Twitter: http://twitter.com/spastorino
Github: http://github.com/spastorino
Rodrigo Rosenfeld Rosas
more backward compatible in new releases.
I know you want to listen to their critics and that is exactly the
reason that I felt I should state that I prefer the API to be changed to
better in major releases instead of worrying too much about backward
compatibility.
Also I do find valuable a small and readable code-base, so keeping lots
of code just to be backward-compatible doesn't feel right to me.
Perhaps you got a wrong impression from my original message intention.
I'm not criticizing them for expressing their opinions. I was just
wanting to tell you that there are other opinions about this too to take
into consideration and I'd like you to listen to our opinion too.
Cheers,
Rodrigo.
Consu
hi,
until now, I was only a reader,
but this thread bother's me.
On Mar 1, 9:43 pm, Rodrigo Rosenfeld Rosas <rr.ro...@gmail.com> wrote:
> From both articles, I've understood that they would prefer Rails to be
> more backward compatible in new releases.
issue.
Some time's you got a gem and your app depend's on it, but it wan't
work with a new rails version. What should I do, in such cases?
What will it cost to redesign?
>
> I know you want to listen to their critics and that is exactly the
> reason that I felt I should state that I prefer the API to be changed to
> better in major releases instead of worrying too much about backward
> compatibility.
>
> Also I do find valuable a small and readable code-base, so keeping lots
> of code just to be backward-compatible doesn't feel right to me.
What's the life time of a rails app?
Who should use Rails?
What will it cost in real money, to upgrade a bigger Rails App?
How long will there be security-fixes for older Rails Versions?
How long will my used plugins be useable?
In my opinion, it's hard to explain a manager, Yeah, we have to make a
little upgrade from Rails X.Y.Z to X.Y.ZZ, but it will last 2 weeks,
or more because of API changes and we need to fix some
incompatibilities. Such minor releases have to be drop-in
replacements.
regards
dieter
James B. Byrne
>
> I do respect their opinion. I just think I should state
> my opinion too so that their opinion don't become the
> only one.
I doubt that will ever be the case. There seems to be some
number of people that believe that Rails works well enough
for their needs. Beside, here you are only preaching to the
choir. Although, I agree that the core team has certainly
earned our thanks and deserves to hear it.
Personally, I did not find going from 2.3 to 3.0 so hard as
to warrant much comment, having previously switched to
Bundler in RoR-2.3 using Yehuda's preinitializer hack.
And I found the upgrade helper in 3.0 of inestimable
value. But it was time consuming and I must confess to a
little weariness when some of changes required treading
through the source code altering syntax in ways that
appeared to me more form than substance.
Moving us to 3.1 from 3.0 is only hung up at the moment
because of the issue I have encountered with the
sqlite3-ruby gem and AR-3.1. That will eventually be
solved
but it has already taken an inordinate amount of time to
resolve and no doubt a considerable amount more will be
required. The one thing I do glean from this is that I
believe the RoR core team does not consider the desirability
of being able to stay current on long term Linux releases as
seriously as others who spend money happen to.
The "enterprise" is where the money is and "enterprisey"
people tend to value stability over new features. I would
rather write code for Rails-3.1/3.2 and 4.x when the time
comes, but I have to keep existing applications working
first. Every hour worked on an existing application
simply to accommodate an incompatible change introduced by
a point version update to Rails or some other gem it
depends upon is an hour lost from other, more profitable,
activity.
We run systems with OS's CentOS-4, 5 and 6. The 4's are at
their end of life, today in fact, and the services that they
hosted are almost all moved to 6 based vm systems. But the
5's have an eol five years from now and the cost of moving
things off them has to be justified. I can arrange for that
to happen using sleight of hand vis a vis switching to
virtual machines, but that will take time as well.
Deciding to deprecate things provided by mainline core
distributions in favour of replacements that may not be
supported on, or even available for, a current long term
support release I believe is of questionable benefit to
Rails in the long term. In our case I was able to use rvm
to deal with the requirement for ruby-1.8.7 (CentOS-5 ships
only 1.8.6 and we did not run any RoR apps on the 4s) but
sqlite is proving to be somewhat more intractable. And
given its peripheral use in our application, caused by yet
another gem dependency no less, that is almost maddening.
Sexy is over once you are married to an app. If you make
it hard for organizations to keep the application
framework up-to-date without rebuilding their entire
platform then they will eventually move to something that
makes it less hard. Ultimately it becomes simply a
question of where money is spent and who gets to make the
decision.
From my own experience I do not believe that this is what
RoR is doing, but at the same time I believe that it
warrants consideration when making changes. A little PR on
the matter might go a long way in RoRs's favour as well.
Xavier Noria
pulling from each other. Rails tries to keep a balance while leaning
on the side of moving forward.
Some people like that, some people don't. There's no solution to that conflict.
Rodrigo I personally appreciate a lot your email. Sincere positive
feedback is absolutely great, I bill *less* hours everyday to work on
Rails, I pay the docs server from my wallet, I do it because I like
it, nobody owns me anything and it is my pleasure, but it is good to
hear some positive words.
Thanks,
Xavier
PS: And of course sincere negative but constructive feedback is also great.
Rohit
I didn't find any of the posts as personal attacks or bad
suited but perhaps is just me.
Cheers,
Rohit Arondekar
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
Rohit
Rodrigo Rosenfeld Rosas
http://rosenfeld.herokuapp.com/en/articles/ruby-rails/2012-03-04-should-we-move-forward-or-remain-backward-compatible
So, now I'm able to answer you. Please, see comments inline below.
Em 01-03-2012 18:44, Consu escreveu:
hi, until now, I was only a reader, but this thread bother's me. On Mar 1, 9:43 pm, Rodrigo Rosenfeld Rosas <rr.ro...@gmail.com> wrote:From both articles, I've understood that they would prefer Rails to be more backward compatible in new releases.I would prefer it. It's not only a rails issue, also a plugin / gem issue.
Some time's you got a gem and your app depend's on it, but it wan't work with a new rails version. What should I do, in such cases?
What will it cost to redesign?
In the article above, I showed how a good API may allow me to complete my work in a few hours while a bad API will get me done after a full week.
I know you want to listen to their critics and that is exactly the reason that I felt I should state that I prefer the API to be changed to better in major releases instead of worrying too much about backward compatibility. Also I do find valuable a small and readable code-base, so keeping lots of code just to be backward-compatible doesn't feel right to me.When I read this I got following question's: What's the life time of a rails app?
Who should use Rails?
Please, read the article above.
What will it cost in real money, to upgrade a bigger Rails App?
How long will there be security-fixes for older Rails Versions?
When you delay the update it can become really hard to do it and big softwares like Gitorious, Redmine and ChiliProject couldn't upgrade from Rails 2 yet.
How long will my used plugins be useable?
In my opinion, it's hard to explain a manager, Yeah, we have to make a little upgrade from Rails X.Y.Z to X.Y.ZZ, but it will last 2 weeks,
or more because of API changes and we need to fix some incompatibilities. Such minor releases have to be drop-in replacements.
Rodrigo Rosenfeld Rosas
> Keeping backwards compatibility and moving forward are contrary goals
> pulling from each other. Rails tries to keep a balance while leaning
> on the side of moving forward.
>
> Some people like that, some people don't. There's no solution to that conflict.
>
> Rodrigo I personally appreciate a lot your email. Sincere positive
> feedback is absolutely great, I bill *less* hours everyday to work on
> Rails, I pay the docs server from my wallet, I do it because I like
> it, nobody owns me anything and it is my pleasure, but it is good to
> hear some positive words.
Xavier, I'd like to thank you very much for all the work you've been
putting on Rails documentation infra-structure for the last years.
I do appreciate it a lot as I find the documentation to be *the most
important* feature of any framework or library, tied with automated
tests and API design.
When I complained about lack of documentation in Rails 3, I wasn't
blaming you in any way.
I always thought that the main issue is that Rails core developers don't
take documentation as serious as they take automated tests. The culture is:
"We have already opened docrails write access to anyone, so if you find
something missing in the documentation, fix it yourself and let us work
on new features and refactorings."
The problem is that usually the best person to document a new feature is
the one who developed it. But as long as he wrote a test for it, it is
fine. Finished. No need for including the documentation changes in the
same commit.
I'm not saying that this happens with every one, but it happens a lot
and it is the reason we have lots of gaps in the API documentation and
sometimes the guides are not updated to reflect some changes.
In my opinion, developers should worry about documentation as much as
they're worried about their test suite and they shouldn't accept patches
lacking documentation updates.
But I've already expressed those opinions in the past and I don't think
it changed anything, so I guess we'll continue to have some delay in the
documentation update process.
But that is not your fault. Thank you very much for all your effort and
money put on Rails documentation. They're much appreciated.
Cheers,
Rodrigo.
Michael Schuerig
> What will it cost in real money, to upgrade a bigger Rails App?
For the past few weeks I've been working on Rails app that has grown
over about 3 years to around 25kloc. The app was stuck at Rails 2.1.2,
uses quite a few gems/plugins and had a fair number of monkey patches to
Rails itself and the plugins.
It took me 20 to 30 days to convert this app to Rails 3.2.2; the exact
amount of days is hard to pinpoint as I did a lot of other cleanup and
things that weren't strictly necessary, such as rewrite queries in the
new style. Simply put, the effort I spent on this task is utterly
negligible compared to the programming effort in the life of that
application so far. Even more so when the whole project is considered.
What made this update possible at all was the solid test coverage.
Interestingly, changes in Rails itself were the least of my problems.
The code was and still is in bad shape. Apparently that's what you get
when an app grows over several years with changing programmers and no-
one to enforce a deliberate architecture and good style.
Don't allow your code to degenerate into a mess. Know, assess, and apply
the advice in the available books on Ruby and Rails good practices. If
an upgrade to a newer Rails version seems daunting, it may well be
because it exposes problems with your codebase that are quite
independent of Rails itself.
Michael
--
Michael Schuerig
mailto:mic...@schuerig.de
http://www.schuerig.de/michael/
Antonio Tapiador del Dujo
> On Thursday 01 March 2012, Consu wrote:
> > What will it cost in real money, to upgrade a bigger Rails App?
>
> For the past few weeks I've been working on Rails app that has grown
> over about 3 years to around 25kloc. The app was stuck at Rails 2.1.2,
> uses quite a few gems/plugins and had a fair number of monkey patches to
> Rails itself and the plugins.
>
> It took me 20 to 30 days to convert this app to Rails 3.2.2; the exact
> amount of days is hard to pinpoint as I did a lot of other cleanup and
> things that weren't strictly necessary, such as rewrite queries in the
> new style. Simply put, the effort I spent on this task is utterly
> negligible compared to the programming effort in the life of that
> application so far. Even more so when the whole project is considered.
> What made this update possible at all was the solid test coverage.
I agree with you, Michael. When a developer says "you know things will break,
you just don’t know what, when and how.", it seems to me that there is a lack
of solid test coverage that would show up those failures.
I join to thank the core-team members and the community for all the great work
of these years. We love you! <3
Rodrigo Rosenfeld Rosas
> On Domingo 04 Marzo 2012 20:36:12 Michael Schuerig escribi�:
>> On Thursday 01 March 2012, Consu wrote:
>>> What will it cost in real money, to upgrade a bigger Rails App?
>> For the past few weeks I've been working on Rails app that has grown
>> over about 3 years to around 25kloc. The app was stuck at Rails 2.1.2,
>> uses quite a few gems/plugins and had a fair number of monkey patches to
>> Rails itself and the plugins.
>>
>> It took me 20 to 30 days to convert this app to Rails 3.2.2; the exact
>> amount of days is hard to pinpoint as I did a lot of other cleanup and
>> things that weren't strictly necessary, such as rewrite queries in the
>> new style. Simply put, the effort I spent on this task is utterly
>> negligible compared to the programming effort in the life of that
>> application so far. Even more so when the whole project is considered.
>> What made this update possible at all was the solid test coverage.
> I agree with you, Michael. When a developer says "you know things will break,
> of solid test coverage that would show up those failures.
I kind of understand this feeling. I don't write tests for my views, for
example. So, you'd have to manually check all your views to see if some
Rails changes in the view layer broke your application...
I'm curious... How many of you are really testing the output of your
views? I'm not talking about integration tests where you use only a few
parts of the view to test some specific behavior.
Cheers,
Rodrigo.