What articles are those?
untitled-[2].html (3.67 KB)
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.
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.
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.
hi,
until now, I was only a reader, but this thread bother's me.
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
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.
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.
hi,
until now, I was only a reader, but this thread bother's me.
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.
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.
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
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:
So, now I'm able to answer you. Please, see comments inline below.
hi, until now, I was only a reader, but this thread bother's me.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.
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.
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
On Domingo 04 Marzo 2012 20:36:12 Michael Schuerig escribió:
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.