Interesting guide, one thing I find lacking in ruby is longevity in projects. Too much cool new stuff, why not just work out the bugs in the existing projects instead? Of course it's easier to write a new half-assed implementation than getting the hard last percent done.
Interesting that he roots for homebrew over macports and rbenv over rvm while at the same time voting for capistrano. Of those 3 projects I find macports and rvm to do what I need from them perfectly and capistrano to be really lacking in both performance and complexity.
Too much cool new stuff, why not just work out the bugs in the existing projects instead?
This may not be a popular opinion, but I have a suspicion that the high degree of wheel reinvention in the world of Ruby and Rails libraries is due to two things: NIH Syndrome & the professed preference by employers for people with active GitHub projects. This causes all kinds of people to make their own gems and such where existing implementations could be improved without such a division (diffusion?) of labor.
I'm definitely feeling the push to show that I'm doing something on my 'Hub account. I can see why it'd be tempting to go and reinvent a wheel to give that impression.
To make it worse, GitHub only occasionally shows commit activity on repos belonging to other people. I have plenty of side-projects going over on a communal account at http://github.com/smashcon. If I work on some of those repos for a couple of weeks, however, to the casual observer it appears as if I haven't been doing anything at all.
(The canonical answer appears to be "fork and use pull requests", but at this point in the project they're just too clumsy for little benefit, particularly each only has a single committer.)
On the other hand, if you get someone else to commit on a project you start, people will think of you when they think of the project. Case in point: until I looked at the history in-depth I always thought of pengwynn when I looked at this project:
I love that things change, and I love the almost competitive nature between projects, but it's grating if you maintiain existing things.
If you're a consultant hopping from one client gig to the next each few months, it's great. If you maintain your own things, it gets frustrating when things you relied on are no longer maintained because the developer got tired of putting up with putdowns about how his project "sucks" and [x] is the new hot way to log people in. :)
I dunno, I've stuck with Capistrano... I've used Vlad, but Cap just works and it only needs to be as complicated as you make it. My cap files are usually about 40 lines total and that often includes a section where I write the database.yml on the fly to the server. I've used all the other options, and they're nice, but Cap works nicely still.
Vlad's not bad. There's a similar project called Fezzik that I use extensively for non-Rails projects. Neither is as good as Capistrano if you're deploying a Rails project.
we are using vlad instead of capistrano and are very happy with it. it is much simpler conceptually. Also from several projects that I converted from capistrano to vlad it runs much much faster for the standard deployment process. I'm not sure what is the reason as I didn't investigate it much.
we have custom vlad plugins for usual rails related stuff, so our config/deploy.rb scripts are usually about 5-10 lines long. see https://github.com/astrails/vladify
Interesting that he roots for homebrew over macports and rbenv over rvm while at the same time voting for capistrano. Of those 3 projects I find macports and rvm to do what I need from them perfectly and capistrano to be really lacking in both performance and complexity.