51 ms·

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 i

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.

invisiblefunnel 15y ago
It seems to me that Homebrew is much more popular than Macports among rubyists. I would like to see actual data though.
angelbob 15y ago
Capistrano is lacking, but has fewer good alternatives. What would you recommend over it?
- Vitaly 15y ago
  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 https://github.com/astrails/vladify
- sunkencity 15y ago
  I prefer running stuff on heroku, but that's hardly a solution to the problem.
- nfm 15y ago
  Have you had a look at whiskey_disk: https://github.com/flogic/whiskey_disk https://github.com/flogic/whiskey_disk ? It assumes you're using git, supports multiple stages out of the box, uses a reset strategy by default instead of having to hack it in etc. I'm planning on playing with it today.
- technomancy 15y ago
  Back when I was doing Ruby I was always fond of Vlad the Deployer: http://rubyhitsquad.com/Vlad_the_Deployer.html http://rubyhitsquad.com/Vlad_the_Deployer.html No idea if it's aged well.
  - angelbob 15y ago
    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.
- tptacek 15y ago
  I really couldn't get over how many moving parts Capistrano seemed to have and have switched to Fabric, which I love.
- jashkenas 15y ago
  Vanilla Ruby to script SSH.
- bphogan 15y ago
  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.
rhizome 15y ago
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.
- damncabbage 15y ago
  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 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.)
  - benatkin 15y ago
    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: https://github.com/pengwynn/faraday_middleware https://github.com/pengwynn/faraday_middleware The vast majority of commits are by https://github.com/sferik https://github.com/sferik though. I don't think pengwynn is gaming the system, but if someone wanted to, this is how they could do it.
- bphogan 15y ago
  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. :)
hello_moto 15y ago
Maybe maintaining someone else code is not something that this particular crowd prefer? As today generation programmers, we often prefer to work on new features, new things as opposed to keeping things stable and fixing all the kinks. Back in the old days, people were so happy if they could submit a patch.

invisiblefunnel 15y ago

It seems to me that Homebrew is much more popular than Macports among rubyists. I would like to see actual data though.

angelbob 15y ago

Capistrano is lacking, but has fewer good alternatives. What would you recommend over it?

Vitaly 15y ago
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 https://github.com/astrails/vladify
sunkencity 15y ago
I prefer running stuff on heroku, but that's hardly a solution to the problem.
nfm 15y ago
Have you had a look at whiskey_disk: https://github.com/flogic/whiskey_disk https://github.com/flogic/whiskey_disk ? It assumes you're using git, supports multiple stages out of the box, uses a reset strategy by default instead of having to hack it in etc. I'm planning on playing with it today.
technomancy 15y ago
Back when I was doing Ruby I was always fond of Vlad the Deployer: http://rubyhitsquad.com/Vlad_the_Deployer.html http://rubyhitsquad.com/Vlad_the_Deployer.html No idea if it's aged well.
- angelbob 15y ago
  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.
tptacek 15y ago
I really couldn't get over how many moving parts Capistrano seemed to have and have switched to Fabric, which I love.
jashkenas 15y ago
Vanilla Ruby to script SSH.
bphogan 15y ago
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.

rhizome 15y ago

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.

damncabbage 15y ago
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 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.)
- benatkin 15y ago
  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: https://github.com/pengwynn/faraday_middleware https://github.com/pengwynn/faraday_middleware The vast majority of commits are by https://github.com/sferik https://github.com/sferik though. I don't think pengwynn is gaming the system, but if someone wanted to, this is how they could do it.
bphogan 15y ago
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. :)

hello_moto 15y ago

Maybe maintaining someone else code is not something that this particular crowd prefer? As today generation programmers, we often prefer to work on new features, new things as opposed to keeping things stable and fixing all the kinks. Back in the old days, people were so happy if they could submit a patch.