I''ve been reading lots of articles criticizing Rails in the last days.
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.
--
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
ditto!! Good job guys! -- Joel Moss Develop with Style at http://DevelopWithStyle.com ==================================Call me +44 7791 503309 http://twitter.com/joelmoss AIM: joelkmoss Skype: joelmoss.info 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. > > 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. > > -- > 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@googlegroups.com). > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > >-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 <joel@developwithstyle.com> escreveu:> ditto!! Good job guys! > > -- > Joel Moss > > Develop with Style at http://DevelopWithStyle.com > ==================================> Call me +44 7791 503309 > http://twitter.com/joelmoss > AIM: joelkmoss > Skype: joelmoss.info > > 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. > > 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. > > -- > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > > -- > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- Atenciosamente, Guilherme Pereira Dutra, Fone: (34) 8407-0109 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Hehe, it should be the same with regards to its philosophy of keep changing for better instead of avoid changes due to backward compatibilities concerns. 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 <joel@developwithstyle.com > <mailto:joel@developwithstyle.com>> escreveu: > > ditto!! Good job guys! > > -- > Joel Moss > > 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. >> >> 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. >>-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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:ByrneJB@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 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Em 01-03-2012 16:59, James B. Byrne escreveu:> 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?The most recent and famous ones are: 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. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Just to say that we shouldn''t care when people try to offend, BUT even 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 On Thu, Mar 1, 2012 at 6:03 PM, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:> Em 01-03-2012 16:59, James B. Byrne escreveu: > > 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? > > > The most recent and famous ones are: > > 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. > > -- > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en.-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
From both articles, I''ve understood that they would prefer Rails to be 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. Em 01-03-2012 17:32, Santiago Pastorino escreveu:> Just to say that we shouldn''t care when people try to offend, BUT even > 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 > > On Thu, Mar 1, 2012 at 6:03 PM, Rodrigo Rosenfeld Rosas > <rr.rosas@gmail.com> wrote: >> Em 01-03-2012 16:59, James B. Byrne escreveu: >> >> 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? >> >> >> The most recent and famous ones are: >> >> 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. >>-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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?> > 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? 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 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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. Thanks, Xavier PS: And of course sincere negative but constructive feedback is also great. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Thu, March 1, 2012 15:03, Rodrigo Rosenfeld Rosas wrote:> > 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. On Thu, March 1, 2012 16:44, Consu wrote:> > 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? > > >> >> 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? > > 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.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. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@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 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> > I didn''t find any of the posts as personal attacks or bad > suited but perhaps is just me.Even though I''m not as involved in contributing to Rails as 1.5 years back but I found them very offensive. A lot of people, including you, put a lot of hard work into Rails. And I thought they were inconsiderate and demanding in their ways. But I''m glad to know that it didn''t bother you Santiago! Keep up the awesome work with Rails. :) Cheers, Rohit Arondekar http://rohitarondekar.com On Friday, March 2, 2012 2:02:33 AM UTC+5:30, Santiago Pastorino wrote:> > Just to say that we shouldn''t care when people try to offend, BUT even > 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 > > On Thu, Mar 1, 2012 at 6:03 PM, Rodrigo Rosenfeld Rosas > <rr.rosas@gmail.com> wrote: > > Em 01-03-2012 16:59, James B. Byrne escreveu: > > > > 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? > > > > > > The most recent and famous ones are: > > > > > 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. > > > > -- > > 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 rubyonrails-core@googlegroups.com. > > To unsubscribe from this group, send email to > > rubyonrails-core+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/RUdb6QBW4aEJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I''m with Rodrigo. I really appreciate all the quality work that the Rails core and each & every contributor puts into this awesome framework. It made me very sad to see that Jose Valim, one of my programming idols, was hurt by all the FUD going around. I hope he is doing well. I just wish this didn''t happen because it''s almost as if all the haters won. :( I expect a rant/spiteful post about Rails will come by every 3-6 months. Let the haters hate. Let us continue to help keep improving this awesome framework. :) Cheers, Rohit Arondekar http://rohitarondekar.com On Thursday, March 1, 2012 9:22:51 PM UTC+5:30, Rodrigo Rosenfeld Rosas wrote:> > I''ve been reading lots of articles criticizing Rails in the last days. > > 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. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/eydmNCgUV_kJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Hi Consul, I didn''t answer this message before because I decided to write an article first sharing my experiences with programming tasks this week: 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.Everyone agrees on this and that is exactly why Rails 3 was targeted at plugin authors. Rails had to attack several other needs before and couldn''t take care about its API for gem developers before. So, in Rails 3, a special attention was given to plugin authors and it should be easier for future upgrades to be done with regards to gem compatibility issues.> 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?I think it is always important to have a glance at plugin sources before you decide to use them. You''ll be able to understand if monkey-patches were required and how this plugin will impact on future upgrades and this will save you lots of work. You''ll also be able to see how good its test coverage is in case you''ll have to take over its maintenance.> What will it cost to redesign?What is the cost of keeping a bad API the next time you''ll have to use it? 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?All applications I''ve worked on in the past decade had a life-time of "forever".> Who should use Rails?Please, read the article above.> What will it cost in real money, to upgrade a bigger Rails App?How much does it cost in real money for writing software using bad APIs?> How long will there be security-fixes for older Rails Versions?It is not feasible to keep investing effort on supporting old Rails versions and that is the reason I think we should be always trying to be up-to-date with our frameworks as a top-priority. 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?It will depend on how important you consider taking a look at its source code and community before deciding for it.> 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,That is not true. Minor versions don''t make incompatible changes to API.> or more because of API changes and we need to fix some > incompatibilities. Such minor releases have to be drop-in > replacements.They are. But managers must understand that you have two options when deciding for some framework. You can get a stable framework that won''t change its API but they must know that features will take longer to get done too with such frameworks. If they decide to adopt one that can respond faster to requirement changes or new feature requests, they must accept that some time will have to be dedicated for doing major upgrades to their application to a newer version from time to time and that this upgrade will require some time and effort too. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Em 01-03-2012 19:07, Xavier Noria escreveu:> 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. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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. 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:michael@schuerig.de http://www.schuerig.de/michael/ -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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, 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 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Em 08-03-2012 05:31, Antonio Tapiador del Dujo escreveu:> 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, > 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 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. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.