Comment by Argorak
14 years ago
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.
http://news.ycombinator.com/item?id=4135058
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.
> "Make a blog in 15 minutes!" --- you remember this one? Were you programming back then? It's exemplary of what I'm talking about.
Actually: Yes. I was even programming Ruby before that, after it won in a flip-coin-contest against Python. :)
We might be on the same page here, but with different mindsets: http://news.ycombinator.com/item?id=4138088
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.
1 reply →
The language a tool is written in is immaterial to how it's used.
Capistrano used to be a lot more Rails-centric than it is now.
I was referring to the predominant cultures/environments they handle. Chef/Puppet/CFEngine are more ecumenical even if Chef/Vagrant/rails is popular.
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.
What are your specific pain points with vagrant? Is it just that you have to keep a VM around or do you have problems with vagrant itself?
2 replies →