This is their first iteration. For a simple Rails app, setting up Ubuntu an RDBMS and Redis is trivial, thats true.
The point is that managing 5 Rails apps, one on Mysql, two on Postgres, two on CouchDB, one with Redis, one with Memcached... (and so on so forth) gets non-trivial soon if you don't grow beyond managing it all on your development machine.[1] Suddenly, all that trivial development stuff becomes a question of configuration management.
What the Ruby community understands is that trivial things can pile up into something non-trivial. This is why Heroku solves a trivial problem (deploying a process on some defined environment using git) and takes it to a big scale. Github does the same for repositories (arguably one of the "trivial" tasks for sysadmins) and provides it for a good amount of money. All those services started in the Ruby community for a reason. We love the mundane, as everything else is based on that.
[1] Alternatively, if you are not consulting, multiply the trivial problem by 20 developers and a growing code-base.
I just got done proselytizing the benefits of automation.
I'm not arguing against myself. I'm concerned with why everything Rails people promote and celebrate seems to be along the lines of what originally popularized the framework.
"Make a blog in 15 minutes!" --- you remember this one? Were you programming back then? It's exemplary of what I'm talking about.
Why are they accelerating the trivial? How many times do you really need to deploy a vanilla Rails app over and over in 1,000 different ways? There's much more to deployment than that, and if that's all your needs are, then there isn't much to say.
We should be learning new and advanced ways to manage complexity with Capistrano or Vlad the Deployer or some non-Ruby deployment tool like Puppet, CFEngine, or Chef.
Partly because they can help deal with things other than just the Rails app itself, which is the easy part generally speaking.
I am a happy Puppet/Vagrant-user and would give away a substantial amount of money for a build/management/hosting-service for all that. Still, you need a hook, and the (in)famous 15-minute-blog was a tremendous hook, as is a "setup a clean dev env in 2 minutes". Immediate usage is the greatest hook you can get. I remember using frameworks where the setup took hours and was closely bound to the machine you were using unless you built your own tooling on top of the whole thing.
Also: there is a lot of stuff around in the Ruby world that can advances the state of the community as you say, even by salvaging Rails. I have not written a Rails App in around 2 years, yet I constantly use parts of it. Rails became a much better community citizen over the last few years.
If the 15-minute-hookiness is all you complain about: well, let them have it, if its fun :). I don't care about it a lot, but it is fun to get started.
>Rails became a much better community citizen over the last few years.
That much I've noticed. A lot of Sinatra/Generic-rack-blah users have been successfully pirating various chunks of functionality from the Rails community. I'm thankful for that.
Going slightly off point, but I'm not sure what makes Puppet and Chef (two projects written in Ruby - Chef in particular whose configuration language is pure Ruby code) "non-Ruby deployment tools", versus Capistrano and Vlad, which I presume are being referred to as the "Ruby" counterparts to the others' non-Ruby distinction.
If you're talking about what they deploy, rather than what they're written in, neither Capistrano nor Vlad are in any way limited to deploying Ruby. Capistrano has a few minor built-in niceties for deploying Rails (basically a few pre-written tasks so you don't have to write them yourself) but it's no less applicable to deploying other projects.
This is of course offtopic but I meet lot of people who think Chef/Puppet are not written in Ruby. There is something in wanting to talk about a tool without actually using it.
I'd be a lot happier if it was all client-side. I use Vagrant for all my projects. It's still a pain in the ass and I'd pay good money for a simple drop-in replacement for Vagrant that bundles everything up (DBMS, Ruby, Gems, etc.) in a single directory along with my code. Then when I'm done, I just destroy the ... "project"? and it's like it was never on my box.
Vagrant provides that for me today but it's still difficult and annoying to deal with.
Don't get me wrong. I <3 Vagrant. I use it all the time and for every project. My new MacBook Air is as pristine as the day I got it. But, Vagrant is not the ultimate solution for me. I don't think it exists, of course. My wish list is too long but...
I want something that:
1) Runs completely locally. I want to be able to work offline, on a plane, whatever without needing remote resources.
2) Minimizes dependencies. Adding chef cookbook servers, apt-get, etc. into the mix is another point of failure.
3) Is scalable/reusable. Most people/companies have multiple projects they work on and much of the vagrant/(chef|puppet) architecture doesn't easily support diverse workloads (this project needs recipes x,y,z, this one needs a,b,x,y; this server runs ubuntu 10.10, the other 10.04)
4) Is all integrated. Sure, I can use some combination of chef, chef-knife, and chef-librarian but they don't work together in my project. Someone can check in a new project setting and unless I run vagrant up, it'll continue to run happily. I want something like bundler that will fail to run unless I'm all up to date, and is unified into a single package.
Given those restrictions, here's what bothers me about the vagrant ecosystem (they're not really complaints about Vagrant per-se but the state of dev virtualization):
1) Every project I get needs a VM (unless I want to start installing stuff locally). This increases the amount of time it takes to get a project up and running. Yes, in the long run it pays off, but can be a barrier to entry for "I just want to fork a project for a quick bug fix".
2) VirtualBox building is slow, takes forever, and requires gobs of disk space. If I have 4 projects, it seems I need a separate vbox for each one. Now I've got GBs of files littering my filesystem. I'd kill for dedupe.
3) Chef / Puppet recipes are one-size-fits-all, and to change them requires adding a whole lot of infrastructure. Sure, you can embed them in your project (chef-solo), but then that's not very reusable.
So you can set up your own chef cookbook server, but then it's another moving part that can fail and then no one can provision new VMs. Bleh. We've gone with symlinking our own cookbook repo into our projects. That's suboptimal but avoids a whole lot of yak shaving.
What I'd like are more extensible cookbooks that have per-project configuration. Yes, they often have some configurable values, but occasionally I want to use a cookbook but it's got some strange version of a lib in there that is incredibly out of date that I can't change.
The point is that managing 5 Rails apps, one on Mysql, two on Postgres, two on CouchDB, one with Redis, one with Memcached... (and so on so forth) gets non-trivial soon if you don't grow beyond managing it all on your development machine.[1] Suddenly, all that trivial development stuff becomes a question of configuration management.
What the Ruby community understands is that trivial things can pile up into something non-trivial. This is why Heroku solves a trivial problem (deploying a process on some defined environment using git) and takes it to a big scale. Github does the same for repositories (arguably one of the "trivial" tasks for sysadmins) and provides it for a good amount of money. All those services started in the Ruby community for a reason. We love the mundane, as everything else is based on that.
[1] Alternatively, if you are not consulting, multiply the trivial problem by 20 developers and a growing code-base.