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
Personally, I don't understand the hype of rubyenv. I really love rvm. I'm not sure why the author called rvm a "mess of bash scripts". I guess because rvm has a lot of features? If I did not care for gemsets and all of the other niceties that rvm has, I guess I would be on the market for another ruby manager. The fact that the author of this article was rubbed the wrong way by Wayne and rvm, rubbed me the wrong way.
He probably called it a "mess of bash scripts" because, uh, it is a mess of bash scripts. Have you looked at the implementation? RVM is amazing in the functionality it has, don't get me wrong, but it hacks into your shell in some nasty ways and when things go wrong good luck figuring out why without diving deep into the underlying bash.
When you have a new box, or when things go wrong, is probably the time to try out "rvm implode" and try rbenv. Reinstalling rubies takes some time and it looks like there might be some time required to configure/fix existing apps to use rbenv?
Part of the problem is that it overrides extremely low-level things like cd. That can get in your way pretty badly if there's a bug, or just a feature you don't understand.
this is not quite correct. it has a configuration option for this and you can set it to false. it was actually set to false as default for a while after rubyenv was released but then it reverted to true by default as I suppose it a better option for most users.
but again, if you don't like this part of rvm, just switch it off
Sorry guys, but this post is silly.
What is modern on "ruby development" on mac?
Why use zsh, xcode?
"ruby development" doesn't mean you are doing rails.
There's nothing silly about a developer sharing his preferred development configuration.
Also, you glossed over the fact that he's not installing Xcode so that he can use its IDE; rather, he's installing to get LLVM/GCC easily. He makes it clear that ZSH is his preference and that he recommends it.
The vast majority of developers looking for a guide to set up their machine for Ruby development will be Rails developers. Denying that is silly.
Sometime I don't understand people that use Vim for everything.
I used Vim casually so I'm not an expert. I understand that it'll take a while to master it. But compare to netbeans where you can navigate Ruby code quite fast (shortcut to method implementation, class implementation, project browse, auto-suggest, etc), why would I want to use Vim when I have to find the proper plugins (not just one, but a few) before I can be productive (assuming they can do what I mentioned above).
I understand people who use VIm for everything. I've recently come ack to it after a few years away.
It's nice to have an editor you know how to be productive in when you start using a new tech.
In an average workday I'll touch ASP, JavaScript, Sass, CoffeeScript, PHP, and Ruby code. When I use VIm, I can use all of the shortcuts and things I've learned over the years to manipulate text. I know how to manage projects, find files, etc.
That's a huge advantage. Having to learn Eclipse to do Java or Visual Studio to do C# adds complexity cos you have to learn the tool and the language.
So yea, I totally get it. This goes for TextMate or Emacs too.
I don't use it for everything, hence my JetBrains recommendation. I use PyCharm a lot, too, for example, and Android dev is a hassle without Eclipse.
The portability of Vim-the-application and thus the portability of the skills to use it are a big reason why I put in the time to learn it (same applies for Emacs). I can just as comfortably program locally, on a remote server or on a friend's machine.
As a netbeans user but vim fanatic. I really like netbeans for project management, but vim is awesome for just manipulating text tons faster than you can with netbeans. Try the jVi plugin for netbeans to get that text editing power of vim with the project management features of netbeans.
If you want to set your login shell to zsh, go to System
Preferences -> Users and Groups. Right-click on your user
account and select Advanced Options. Change the login shell
dropdown to /bin/zsh.
You're better off using `chsh -s /bin/zsh` (or, better yet, `brew install zsh`, append `/usr/local/bin/zsh` to `/etc/shells`, and use that, instead).
Software that lacks a good uninstaller is always suspect, to me. It makes me smile to know that this is all that's necessary to remove RVM:
> rvm implode
How's rbenv for uninstallation? I'm familiar-enough with rvm that I know I can restore absolutely everything from scratch with a couple config options and a while for compilation - I'm more than happy to spend that to experiment as long as rbenv has a similar panic-button.
How are you getting this completion from ri ? I use zsh, and the rvm's ri (.rvm/rubies/ruby-1.9.2-head/bin/ri) gives no completion at all (ri 2.5.8).
However, /usr/bin/ri (ri v1.0.1 - 20041108) does give completion but different from your list.
ri K<tab> gives Classes and methods (e.g. Kconv\#guess) and not just classes. So it's a huge list. Thx.
It's always interesting to see differences in people's 'base' stacks. Where feasible I like to have the environment on my dev machine reflect production as closely as possible so I would go with Passenger over Pow, but this is a great little guide.
That's what I use Vagrant for: attempting to mimic production machines as close as possible. But that only happens as I'm testing before a release. Otherwise I use the easiest / best tool for the OS and machine that I'm developing on.
I actually miss vagrant/virtualbox in the stack. Why not use a virtual dev environment for every project you're working on. It seems silly to me to install all required components for each and every project on my dev machine, possibly with different/conflicting versions (think: multiple pg server versions etc.) instead of having a self contained environment for every project.
I thought the ad-hominem-ish bit about rvm was disappointing. The Ruby landscape is a weird place where each project belongs to one and only one name. Instead of improving on projects, people prefer to invent their own, and then the drama race begins. Open your Gemfile and try to find a gem with a truck factor != 1.
I think it is natural and understandable because there are many Ruby freelancers around who desire to build a brand around their name. But the "competition" between rbenv and rvm was not constructive at all so far. It would be much more helpful if there was one .rubyversion file that both would respect, for starters.
Interesting...still weighing whether I want to familiarise myself with Ruby/RoR or if I should continue to enhance my python skills and learn Django...I think the fact that more people are talking about Ruby development may sway me towards RoR
Depends, if I look at my local job listings where there's one ruby listing for every 10 python ones I'd say different but I'll admit that that ratio is abnormally high but indicates that the same trend governs most places bar Chicago. However, if I look at HN submissions, it's almost the other way around. Given that I've worked in three countries in the last 5 years and noticed the same trend in all of them, I am starting to think that Ruby developers are simply more evangelist.
For tutorial/walkthrough with lots of example small scripts Beginning Ruby, 2nd ed by Peter Cooper. For a straight reference The Ruby Programming Language by David Flanagan and Yukihiro Matsumoto. A middle-ground (tutorial first half; reference second half): Programming Ruby 1.9 (aka, the Pickaxe Book) by Dave Thomas.
A great second book (maybe even first if you're comfortable enough learning basic syntax on your own) is Eloquent Ruby by Russ Olsen.
I've been using macports for ages, nothing wrong with it. Okay, it does not check to see the stock installs of OSX, and installs its own ruby, perl, python etc. Apart from that it's been very reliable.
My main problem with macports has been that it occasionally does not play nicely with manual source-installs, or any other package manager. And damn near everything needs sudo.
Everything I've needed has been available in homebrew, and more up-to-date and better isolated and hasn't collided with anything yet. I haven't used it as long as I've used macports, but so far it has been a far more pleasant experience. And incomparably faster - I swear, macports has a sleep() call in every operation. Very much recommended if you haven't tried it, and it cleans up nicely too - you just delete its single folder.
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.