If it is “only a line in a gem file’ then why bother including it since 99%+ of the time it is going to get removed anyway.

Putting it in the gemfile is like putting Prawn, or paperclip in there by default. It is senseless.

I was hoping that when rails and merb merged that the merb teams humbleness and reasonableness would rub off of the rails team, especially DHH.

Instead it seems like DHH’s arrogance and to be blunt, stupidity, is rubbing off on you.

Rails 3.1 was change for the sake of change, no spinning by you will change that.

Moved to rails 3.2.0.rc1 and my javascripts are not working again. The amount of time wasted to fix such teething issues are just not worth it.

My experience is that I regularly run against issues, some of which have been features from Rails 3.1 which weren’t yet covered in the Rails books. In those situations I’ve generally done the obvious:

1. Google – Not that effective as a high percentage of the posts I find are out of date and/or show an approach which you later find causes further issues.
2. Rails Guides – I’ve found these to be pretty mixed, for example the asset pipeline one has failed to answer many of my simple questions.

This has made the learning process far more painful than it should have been.

So from my perspective if there’s one thing that’d be a big improvement it’d be more comprehensive Rails documentation around new features to help people get onto the right path quickly.

You know that I have the deepest respect for your efforts and the totally thankless (well, almost thankless) task of maintaining software – I know all about it!

Please consider the following carefully: at dojo4 (http://dojo4.com) we have a lot of people hanging out and hacking – everyone from hard core ruby devs, designers learning rails, and investors trying to understand the landscape. I’ve been programming ruby web apps since before fastcgi, before rails, before merb… you know I’ve seen alot. I can tell you definitively that the drone of complaints regarding installing, learning, and deploying rails has increased 10x since the big re-factor. I’d love to talk about this in IM if you have a chance but I can tell you that the perception of many regarding the new shiny bits is obscured by some major hurdles. Also, they are all fixable. I’ll look forward to discussing more in person – wanna come stay in boulder for a bit? We’ll put you up! ;-)

What I am still missing though… and… it IS quite difficult to do, is build and integrate with a largely used CMS solution, with an enterprise CMS like Typo3 is.

We often have requirements to integrate an app with a bigger Website.
Relying on the numerous smallish CMS makes it often still a “No-Go”, when we offer it to clients.
That’s why we still have to go with PHP even if some parts would be amazing built on ruby and rails.
The still don’t want to experiment with self factured software (Micro CMS) or baked together, which isn’t that reliable as a CMS like Typo3 or Drupal (PHP) which has a humangous Userbase and 10’000 of plugins.

This is why php had such a success, because of the variety of (not only but mostly) CMS’ out there.
A Software like an enterprise CMS would push Rails to a whole new level, like Rails with Ruby did. (sorry Ruby purists :-) )
I think, to establish a programming language or even a framework, it has to be used a lot not only in custom apps, there has to be not only some frameworks (rails, sinatra etc.) and many many libraries (gems), but a Software, which builds on it and supports a great way to write your own plugins (relying on that CMS Libraries on top)

It’s a shame, Typo3 CMS didn’t switch technology over to RoR, when deciding to refactor the framework and rebuild its entire framework too.
Because, all the former Typo3 Developers have to learn the new Version anyway.
It could have revolutionized a big part of the websector.

And deep in my heart, I still hope for a crazy great CMS like Typo3 CMS is, but for Ruby/Rails.
It may be time to copy some of their really good concepts, like Apple did from Google :)

( lifespan of a poor software programmer )

I disagree with the article/comments that Rails is “disappearing up its own asshole.” Rails seems to me to always be trying things out (with the spirit of making it better for users and developers) and isn’t afraid to just fucking do it sans any bullshit. Seriously, I’ve used other frameworks (not necessarily web frameworks) and they talk and they plan and they debate and they never fucking do anything. At least Rails has the balls to just put coffeescript and sass in and just put it out there (and let’s be honest, the idea to include these things isn’t coming out of left field either: these are things people have been using and finding useful for a while, which make some real-world improvements (albeit not necessarily everybody’s cup of tea)). I have personally been using haml and sass for years, and when coffeescript came out, I jumped on that train too, because it made javascript feel like the other stuff I was doing (which were done in ways I liked aesthetically and practically). I don’t think the decisions the Rails team makes are arbitrary or stupid. I think the framework is moving forward in a positive direction (the key word here being “moving”). And I don’t think it’s hurting anybody that doesn’t want to use the new features that are coming out if they don’t want to.

Barriers to entry are another thing. Personally it did take some effort to wrap my head around the whole thing when I started out (but it was totally worth the effort in the end! I’m so much happier using Rails). But yeah, it’s not easy. Does it need to be easy? Is that a requirement? I guess more people would use it if it was easier and that would bolster the community and blah blah blah. But I think it’s more important that it’s *good*. Make it *good* first, then make it as easy as you can (part of making it good might mean making it easy, but my point is that the emphasis should be made on sanity over dumbing it down). Rails can be hard, but using it comes with a lot of benefits that make a lot of other things easier (I’ve gone through the effort of understanding Activerecord (and now Arel) because, man, that’s so much better than writing straight up sequel (especially complex join statements) for regular everyday stuff; it allows me to focus on my app (the thing I actually give a shit about) and not worry about the boring stuff).

Writing documentation (and books) are hard for anything in technology, and I don’t feel it’s a fault of the framework that it’s moving faster than books can be published about it. Maybe that’s just a good indication that the print medium itself is becoming more and more obsolete. We need *live* text documentation that is constantly updating and adapting to its changing target. Books will never be able to keep up (I have a shelf of books that are all completely obsolete now. I don’t buy books anymore because the stuff I want to know is online and the newest book at the bookstore is already a year out of touch with what’s actually going on). I feel the Rails community at large is really great at talking about how to use the framework and is generally really nice and helpful when someone has questions.

All in all, Rails is forward thinking and moving and adapting itself to how people are actually doing things. It’s moving. Deal with it. If you don’t want to move, just stay where you are with an older version of it. It can be hard for new users to get into, but I don’t think that alone should dictate how things get changed. Documentation will always be hard to keep up-to-date, but printed documentation (especially about technology) might just be the wrong medium these days. Now, we’re *able* to change faster, and I think that’s a good thing. I think Rails is *not* “disappearing up its own asshole” but is manfully displaying its protruding balls.