> If you’re learning a new language, a strong community consensus about a right and a wrong way to tackle problems aids learning
Right, but the problem is that there doesn't seem to be a 'right' way, That's the problem.
We were all prototype a few years ago, now it jquery ... we (well I) hadn't heard of coffeescript till a few months ago and now its a default option in rails, The way we were constructing ActiveRecord finders had been set all through Rails 2, now we've changed it, the way we dealt with gems was set all through rails 2 now its changed completely in Rails 3.
I like change, I like staying on the cutting edge of web technologies, but I don't want to learn something, only to discard it and re-do it completely to bring it up to date with a new way of doing things all the time.
> If, as coders, we aren’t constantly striving to improve the status quo, what’s the point?
The point is that you have to realize that Rails isn't just your personal plaything any more, people are invested in it just as much any one person or group of people.
I have 5 Rails 2 apps that I support at work and a couple more outside of that, they're all on rails 2 ... bringing them up to Rails 3 without disruption, isn't going to be trivial and I'd be nice if folks acted like they understood that and didn't dismiss similar concerns, or berate folks for having concerns.
To that end, my personal preference would be to see fewer but more substantial releases and a little bit more engagement with the community before making major decisions about the framework instead of the steady drumbeat of updates and (seemingly) unilateral decisions (that coffee script decision really irked me, can you tell?)
I think rails developers blindly upgrade their apps, just because they want to be on the hottest new technology. I know I am drawn by the glitter of rails 3.1 beta. But everyone should really weigh the business decision of upgrading; what do you really truly gain by being on the latest rails for all your apps? Sometimes the technical debt you take on by maintaining an old framework is less than the effort you have to spend to upgrade, especially for sunsetting apps.
1. jQuery quickly replaced prototype for most projects via the jrails gem. This just reflects the underlying reality.
2. Coffeescript as the default was a bad idea. This would make more sense in say a year from now.
3. Rails 3 active record w/ ARel is HUGELY better. I used to have to pull out find_by_sql every so often, haven't needed it yet in rails 3.
4. Bundler solves a whole raft of annoying dependency issues in rails 2. I can't tell you how many hours I lost to dealing with weird issues with vendored gems.
Bringing rails2 apps to rails 3 is going to suck for you. I'd argue that one of the prices for the elegance of rails is that you need to spend more time constantly upgrading it.
However, the advantage of this price is that you have a framework that has been consistently lead of the pack in terms of productivity and simplicity.
How can you know this?
I'm not going to say that Ruby on Rails is the most productive, as python's Django (my bread and butter) is not too shabby either, and most popular platforms have some web framework that gets close or that are better at various tasks (e.g. I chose PlayFramework for some project I had because of its async support and couldn't be happier about it).
But IMHO, Rails 3 has the best design of the bunch - ActiveModel, ARel, Bundler, Passenger, database migrations that don't suck, less boilerplate than anything else of the same size/scope, the best plugins system I've seen (yes, I think it is better than Django's, no matter what Zed Shaw has to say about it) and also has the advantage of popularity.
This doesn't come without sacrifice. I hate that they've forcefully added SCSS/CoffeeScript as a default. But the great refactoring of Rails 3 had to be done, as frankly, the Rails 2 codebase was an incomprehensible mess. And you can't be on the leading edge of web frameworks without breaking stuff.
That said, Coffeescript as a default? Geez, I'd really like to know what they are smoking.
"the framework which I have found to consistently lead the pack in terms of productivity and simplicity"
(this is a true statement for me, personally, though I haven't done much on the Python front)
Furthermore, any likenesses to people real, living, or yet-born are purely coincidental, or have been properly sublicensed through those who own their copyright.
You may not make copies of my post without the express, written consent, of the National Football, Baseball and Basketball leagues.
The problem is that the state of the art changes. The reason Rails is still relevant is because the core team is committed to improvement, even at the expense of API stability and legacy support. That's definitely a valid concern for someone supporting apps on a shoestring, but on the other hand it makes Rails more suitable for someone who wants to stay on the cutting edge. You simply can't have it both ways...
> We were all prototype a few years ago, now it jquery ...
You mean __7__ years ago when they chose it as the default? Rails was the first framework with Ajax support built-in, and it was done poorly because nobody understood how it should really work at the time.
> we (well I) hadn't heard of coffeescript till a few months ago and now its a default option in rails
It's easy to argue that CoffeeScript shouldn't be a default, but then it's even easier to just turn it off. Shouldn't be a point of major contention, but I can see how people don't like it.
> The way we were constructing ActiveRecord finders had been set all through Rails 2, now we've changed it
Yes, they replaced a hodge-podge of ad-hoc query construction with a relational algebra library that enables dramatically more flexible query construction and lazy loading. Who knows how many broken edge cases were fixed merely by the switch to a proper mathematical basis.
> the way we dealt with gems was set all through rails 2 now its changed completely in Rails 3.
Bundler solves dozens of thorny issues that were intractable in the Rails system. Now Rails is simpler because it doesn't have to have any gem activation code, it's handled by a separate library that can solve your gem management problems for your non-Rails projects as well. You may not have run into any of these issues, but I assure you there were real and Bundler is a big step in the right direction.
Yeah but what are the implications of that? You want Microsoft-style legacy support from Apple? They ain't gonna give it to you, because that lack of legacy support is what enables them to move forward at the pace they do. This has definitely impacted the type of projects I feel comfortable delivering in Rails (ie. no low-budget small client sites), but for an actively developed app it makes Rails a more attractive place to be.
But that's not the question here -- the question is whether Rails is getting progressively easier or harder for a newbie to pick up and whether those changes are going to result in better or worse applications.
If you read the article he makes other points as well, the author of this article just seized on this because it was probably easiest to shoot down.
In the original article the author says ...
"The speed of change in using and learning rails however is a real worry for anyone who wants to use it. It might completely change by the end of next month"
That's what I'm interested in discussing, and I suspect where the real problem lies.
Then you have to make the decision for each app - "Do I upgrade or stay on the latest version"? I personally prefer that tradeoff - Rails can cleanly add new features even it breaks the past. Then I decide if I need those features more than I need the pain of upgrading.
You're thinking "Why can't they just opt out of this and let us have our fun" and we're thinking "why are they forcing this on everybody".
Its kind of how you get a windows box and it has all this crap on it by default ... you can go uninstall or turn stuff off, but its fricking annoying as heck.
Some things should be the way things are done in rails, bundler, the new ActiveRecord queries. yes
Some of this other stuff, not so much ... you should have to explicitly turn it on not turn it off, and then if we're seeing wide adoption then we can make it part of the core.
What is wrong with that approach?
one that can be opted out of if desired. This is not new for Rails, but it seems like every time we turn around, people are acting surprised.
Don't make people opt out of stuff especially on things that might not be so core to rails ... Opting out is annoying ... its much better to go "Wow, I didn't know that was there" than "crap ... I have to turn this stuff off now". It gets on people's nerves, the fact that you're not seeing that despite confessing that people complain each time it happens suggests a certain amount of tone deafness.
I could be wrong, but I think its worth re-evaluating.
As long as something is backwards compatible, I don't see the problem. That is the natural progression of a rapidly evolving industry like tech, there is always something new. I don't see how introducing coffeescript as an option makes a problem for anyone. I agree there shouldnt be change for changes sake, but often through trial and error we discover a more efficient way of doing things. If rails doesn't evolve, it will be replaced by frameworks like Django, CakePHP that do.
That said, I love the changes in Rails 3. Considering strings unsafe and escaping them by default is great, bundler rocks, arel is very nice, and the mailer api is nice.
The rapid change and code purity ideals in the Rails world leads to benefits, so I tolerate it in Rails in spite of its costs.
This idealism has unfortunately infected projects in the Rails ecosystem that are really just infrastructure (where change should occur slowly). As examples, both Rspec and RubyGems are willing to break compatibility and code that I rely on for benefits that are neglible, aesthetic, or invisible to me. The difference is, when Rails breaks something, 90% of the time it buys me something.
And thats a dangerous attitude to have, because as smart as they are (and they are very smart guys, make no mistake), they can also make bad decisions, just like the rest of us ... the difference being that the impact on all of us could be huge.
The author says Rails is growing up, part of growing up is learning to be responsible too.
I find this all a bit odd, since as a Rails newbie, I found Rails 3.0.x very easy to learn with a little help from Michael Hartl's tutorial and the Rails Guides. Perhaps this is an example of the "curse of knowledge?" In other words, that since Coast found Rails 2 easier, he assumed that newbies would as well?
 Front-end developer with little back-end experience.
Like what happened to Rails 3.0.7 and Rake 2 weeks ago.
I wish the Rubygems guys would put down the crack pipe though. They're the one problem in this setup and, admittedly, they're a massive problem :(
Another thing to learn.
If you've a Rails 2.x app with plugin ActsLikeWhatever, and you run into some problem with that plugin, chances are the fix will only be in the newest, non-Rails2, release.
Part of the problem is the leadership. They take the stance, "you bastards are doing it wrong" if you want to do things a little different.
The community almost split when they managed to swallow Merb and keep Rails. It's toned down quite a bit but that negativity definitely carried over from the early days and infects the community (swearing in presentations and porn references, etc.).
But these thinking aids aren't exactly radical paradigm shifts that will expand your mind and make you a significantly better programmer for the rest of your days. Rails is one of the most influential frameworks and did a lot to advance the field but now there are other frameworks that are much easier to learn and get a functional web service started.
So saying dissenters are slow to learn, stubborn or haven't been writing tests really doesn't do anyone a service and doesn't make anything clearer, sorry.
Yikes, unfortunately this knocks rails off of my to-try list. I've got a non-web application with an unusual, but by no means bad, schema. I've found it makes a good measuring stick for frameworks/tools. I have nothing against doing things in the way of a particular framework, but I have existing code to bring to the party too, if something isn't going to play nice I ignore it. I can't live with building something that exists in isolation. Its either not going to work with what I have, or hold me back when I want to build on top of it with something else.
class Account < ActiveRecord::Base
has_many :posts, :class_name => "Post", :foreign_key => "postid"
class Post < ActiveRecord::Base
belongs_to :account, :class_name => "Account", :foreign_key => "postid"
#Account.first.posts.create(:title => "test", :body => "test")
> Conventions over configuration is nice but it requires some stability.
if you were to compare this with an agnostic framework with drop-in, you have to set everything. with rails, you just gonna say "oh, this isn't default so i have to explicitly set this".. or "oh, this is no longer default so i have to set this".. it's just a convention.. if you want to use rails in an unconventional way, by all means do it, you just have to know more about its internals if you intend to do this -- this makes sense when you think about it(you don't want to be hacking hard on a piece of software you don't really understand, you're going to want to know what you're doing so that you have a good idea when some unexpected problem arises).
>Part of the problem is the leadership. They take the stance, "you bastards are doing it wrong" if you want to do things a little different.
if you did that and decided there's really nothing out there that can solve your problem, they you can just implement it however you want, rails is very configurable, but really, you're just limited to what ruby can do..
>So saying dissenters are slow to learn, stubborn or haven't been writing tests really doesn't do anyone a service and doesn't make anything clearer, sorry.
i'm sorry, did the article speak to you this way? are you a girl where you might be giving meaning to what's actually being said?
"I have a moderately complex Rails app that I want to upgrade, but I don't have much confidence in my tests, I maybe don't have proper separation of concerns, and I just know that one hacky thing I did a while back is going to bite me in the ass."
It's just something that happens over time in any moderately complex app. I see Rails point release candidates as a good reminder to bust out rcov and spend a few days plugging up the gaps in test coverage before the stable release comes out.
If you've been procrastinating upgrading your Rails 2.3.x app to 3.0.x, you're really gonna have fun going straight from 2.3.x to 3.1. Sometimes you just gotta rip off the band-aid.
This says it all for me. Upgrading an app or parts of an app that have great test coverage is really pretty straightforward. It's only more difficult if you weren't following best practices all along.
Like people working with Rails in the the real world with real, less-than-perfect programmers.
Yes, if I'm an ideologically pure, saint-like programmer with 100% test coverage and purely idiomatic ruby, then upgrades should be a breeze.
Except the plugin ecosystem problems still arise-- even the 'perfect' programmer has to be perpetually upgrading to the latest-and-greatest plugins since the last authentication/taggable/whatever plugin has been abandoned in favor of the flavor-of-the-week.
Its the nature of the software beast that upgrading a large and complex application to a new version of the language or framework is difficult and maybe prohibitively difficult. Once something is written and it works it often times stays as is... sometimes for decades.
This comment has been a service provided by the small bot running in my brain programmed to respond to mentions of the GoF book with a link to Norvig's presentation on them:
I am extremely thankful to the people in the community who are putting their time and effort to build such great software and essentially giving it away for free. I am personally both awed and humbled by the excellent work put in by all the individuals who directly or indirectly contributed to Ruby and Rails across all the versions. If not for them I would not have quit my day job. If not for Rails, I am pretty sure that I would not be enjoying my life, as much as I am enjoying it today.
The point is that Rails has grown up to the point where makes it simple to write complex applications. For small projects, these choices may seem to be an overkill. But trust me, when you put it into production and start getting traction you will thank Rails. I have built applications with Sinatra and Rack and assembled my own Rails environment using tons of middleware and a lot of glue. I know how hard it is to do it the right way and appreciate the fact that Rails makes it a cakewalk for us. I sure learnt a lot of Ruby but I would choose Rails any day as I know that there has been a lot of thought put in by the community to make it awesome.
To phrase it differently: I feel comfortable with a framework or community forcing me to change how I achieve some higher-level goal. But when that convention prevents me from doing something, period, I start to worry.
Rails is very opinionated about the things it handles and how it does them, but I've never had a problem rolling my own solutions and integrating them in. Not every model has to inherit from ActiveRecord, arbitrary code runs just fine in lib/ What's the problem?
... coming from the people who are known for relying heavily on monkey patching existing classes.
Or did that change recently?
But I think that's more a reflection of myself (being an "old" guy who's "been there, done that" several times over and resistant to change and trends) and not the fault of Rails. So I try to keep up.
But Rails is good for the web. The web was pretty stagnant at one time, and it sucked, and didn't keep up with the needs of users and businesses.
And that's why I don't have a real problem with Rails' rapid pace. It keeps everyone on their toes, including their competitors.
Even when you get your app up and running the load times in 1.9.x at the minute mean you'll be hanging around waiting for rails to generate files and your going to have to get Spork running to make any kind of rapid TDD/BDD.
Rails used to be the easy way into all this modern development goodness, now that "blog in 20 minutes" simplicity has gone along with the famous screencast.
With less opinionated software, changes actually rarely break you since it typically requires opt-in/code change to pick up the new capabilities.
Because RoR has this tendency to reinvent itself every 18 months or so, the answer to the question is a resounding no. It's being used mostly to explore new ways to create web sites, but RoR is more and more becoming a framework you really want to avoid if you need to create a production site that you are planning to work on for years to come.
I don't think it is a statement on the platform at all - just a repercussion of one of its tenets.
Rails will be retrofitted to make it easy to start with a “core” version of Rails (like Merb’s current core generator), that starts with all modules out, and makes it easy to select just the parts that are important for your app. Of course, Rails will still ship with the “stack” version as the default (just as Merb does since 1.0), but the goal is to make it easy to do with Rails what people do with Merb today.
Here's configuring the middleware: http://guides.rubyonrails.org/rails_on_rack.html
Here's a stackoverflow question on how to disable ActiveRecord: http://stackoverflow.com/questions/2212709/remove-activereco...
Have you seen ActiveModel? It gives a common interface for orms to interface with so swapping out ActiveRecord doesn't break half of the view helpers.
Rails 3 is far, far easier to extend and modify than 2.3 was.
Now I know it's not that bad but I can see a future where instead of just having the rails book, you have books for every new thing and option possible and the section looks like the Java section where Struts, Spring, and even Scala/Clojure all make the idea of switching to to rails seem far more daunting than it needs to be.
If you've seen something that fits the bill, please pass it on.
Still working in Sinatra does give you that fun feeling of old Rails.
The fact that you could then evolve this into something production-ready (arguably), well that was just icing on the cake!
this is what i was referring too much of these are in ruby on rails from the beging ...