

Setting Up A New Machine for Ruby Development - as used at 37signals these days - ChrisArchitect
http://37signals.com/svn/posts/2998-setting-up-a-new-machine-for-ruby-development

======
dotBen
My preference is still a *nix virtual instance running locally (or on a LAN
server/my desktop) so that I can keep even better control over environment,
keep discrete projects separate and clone dev environments quickly to peers.

VMWare Fusion works out great for this, but FOSS VirtualBox works out too if
you want the free route.

The rest of the 37 Signals advice is sound, just do it within the virtual
instance.

~~~
psadauskas
I agree, but I would like to point out that if you use Virtualbox, you can
script the whole setup of the VM with vagrant. The only downside I have with
using VMs is that it's hard to use some of the nice OSX GUI tools ( GitX,
Pixelmator) on the files in the VM.

~~~
veidr
Actually, I find using VMWare Fusion to be a great way to use all the good dev
tools available on the Mac -- SourceTree git client, CSSEdit, BBEdit, etc --
while actually developing on the same Linux environment you'll use in
production.

The key is to build and install the latest version of Netatalk on the Linux
VM, and then mount its filesystem on the Mac via AFP. Netatalk has a config
option (-admingroup) that lets members of an arbitrary group mount a volume
with root privileges, which is very handy for development.

(Netatalk has plenty of bugs[1], but works well enough for development.)

I've tried to get this same setup with CIFS (Samba), as well as sshfs.
However, apps like TextMate or CSSEdit freak out with permission errors (even
if you set up ACLs or something so that you really have write permission, the
Mac apps don't believe you do).

Netatalk is the only magic sauce I have found that lets you mount a Linux
server's disks as volumes that your Mac sees as simple writable volumes, but
where you actually have root privs as far as the Linux box is concerned.

Not something I'd use on a real server, but great for development.

\-- [1]: the most insanely annoying one being that it currently can't serve
the root volume; you have to configure it to make /etc, /var, etc available as
separate shares

~~~
ajtaylor
At my last job, I was successfully using NFS to share a directory from OS X to
a FreeBSD VM running under Parallels. I went that way so that TimeMachine
could backup the shared directory (which contained source code). It seems like
it would still work if you did the reverse procedure and made sure the
directory on OS X was backed up via Time Machine, but I'd love to hear of your
experience.

------
masklinn
> Homebrew: Remember how painful it used to be to get imagemagick installed?

Uh... no?
[https://trac.macports.org/browser/trunk/dports/graphics/Imag...](https://trac.macports.org/browser/trunk/dports/graphics/ImageMagick/Portfile?rev=2591)

edit: ah, so any comment not gushing over how fantawesomastic homebrew is is
now verboten. Noted, I guess.

~~~
joblessjunkie
Don't assume you're getting downvoted through simple fanboyism.

Your comment is thin and unproductive, and flies in the face of the
experiences of many.

We've been using ImageMagick in our product for about 6 years. Across 4 new
Mac laptops and 3 versions of OS X, `sudo port install imagemagick` has
_never_ worked for me.

I've had similar woes on Ubuntu with `apt-get install imagemagick`.

I don't know if the fault lies with ImageMagick itself, the package managers,
or just the simple fact that ImageMagick has an extraordinary number of
library and environmental dependencies which are always moving.

Even today, my local development environment loads and runs ImageMagick with
no errors or warnings, yet emits only black and white graphics -- no color. At
this point, I'm exhausted of trying to fix it, and I've given up.

I've never tried brew, but I'm more than willing to give it a shot.

------
petercooper
I wonder if they'll do one about deployment too (like Capistrano, Passenger,
etc). I _heard_ they used to use Capistrano, REE, and Phusion Passenger but
have been moving to Ruby 1.9.2 and Unicorn but it'd be interesting to hear
more.

In terms of test framework, however, the answer is well known ;-)
[http://www.rubyinside.com/dhh-offended-by-rspec-
debate-4610....](http://www.rubyinside.com/dhh-offended-by-rspec-
debate-4610.html)

~~~
dhh
Our setup for new deployments is rbenv, 1.9.3dev, Unicorn, nginx, Capistrano.

~~~
yatsyk
And what about system configuration? Your chef cookbooks repo is not updated
for a long time. Do you still use chef, switched to puppet or use something
else?

~~~
themcgruff
We are still (happily) using Chef. We'll update the public repo shortly. We
just need to remove from of the more "private" bits before publishing.

~~~
yatsyk
Thank you for clarification!

------
nikcub
Is bundler like pip + virtualenv in python land?

~~~
joelhaasnoot
Think bundler = pip, virtualenv = rbenv

------
idlewords
Further refinements to the self-licking ice cream cone.

------
ChrisArchitect
cue the inevitable 'why not using x' etc - but it's always interesting to hear
what the heads are using day-to-day

~~~
ubercore
I really want to post "why not use Vagrant to automate all of that?" but I
stopped myself.

~~~
joevandyk
vagrant forces you to run in a virtual machine, bit more inconvenient than
running on the local physical host.

~~~
ubercore
I've found it's pretty seamless. You're editing files on your local dev
machine, which vagrant auto-mounts in the guest OS. Ports are automatically
forwarded to your host dev machine, so my workflow is literally exactly the
same as if I developed directly in OS X. The only difference is first having
to run "vagrant ssh" to run commands in the dev environment, but for having a
repeatable, share-able, isolated environment with all dependent libraries
automatically installed, it's well worth typing "vagrant ssh".

