
Setting up a new Mac for development - altryne1
http://a-w.me/osx-setup
======
mellamoyo
> curl -s [http://getmacapps.com/raw/6bl](http://getmacapps.com/raw/6bl) | sh

> ruby -e "$(curl -fsSL
> [https://raw.github.com/mxcl/homebrew/go)"](https://raw.github.com/mxcl/homebrew/go\)")

Please stop doing this. I looked at the script and I know it looks fine but
piping a raw curl into a shell interpreter is just a bad practice.
Unfortunately, it seems to be more and more common as time goes on.

~~~
bithive123
How is this any less secure than "here, download and run this executable"?

~~~
soneil
I fear I'll open another can of worms, but here's a rare consideration. If I
download, unzip, and then run, on-access virus scanning will hit both the
archive and the executable. If I pipe from wget straight to sh, it never hits
disk - and I don't know the OS internals well enough to guess whether a virus
scanner can make a file handle to stdin.

And before I come off as a paranoid nut; yes I have a virus-scanner on OSX.
No, I don't usually use it unless something piques my curiosity (or I'm on my
employers network. Their house, their rules). But that said, I've never had my
house broken into, but I still lock my door.

But for the specific examples in the article;

\- Homebrew, I trust. If I'm going to trust them to patch & build every app it
installs, I may as well trust their distribution mechanism.

\- Dropbox, by blindly running a script from some third-party website I've
never heard of? I'd rather go to dropbox.com and hit the download link.

------
jareds
Somewhat related, I’m looking at getting my first MacBook for basic computer
usage and iPhone programming. I’m trying to figure out what model to get but
since I am totally blind the retina display is a non-factor and a larger
screen is a negative due to reduced portability. I was planning on buying an
11.6 inch Air. With the price drop on the pro my choice is no longer so clear
cut. For $1449 I can get an Air with 256 GB of storage, a 1.7 GHZ processor
that boosts up to 3.3 GHZ, and 8 gigs of ram for $1449. I can get a 13 inch
MacBook Pro with 256 GB of storage, a 2.4 GHZ processor that boosts up to 2.9
GHZ and 8 GB of ram for $1499. Both machines claim 9 hours of battery life.
Will the extra speed on the duel core with the reduced turbo boost provide
enough of a noticeable performance boost to make it worth the Extra weight and
size.

~~~
brown9-2
After having to lug my 15" Pro around as a carry-on in the airport when
travelling once every 3 months, personally my next Macbook choice is going to
be an Air.

~~~
hackerboos
If the Air had a retina screen I'd buy one tomorrow.

~~~
kylec
The 13" retina Pro is pretty darn small and light. It's only half a pound
heavier and 0.03" thicker than the Air's thickest point.

~~~
berntb
Any comments on the dual core processors of the 13" rMBP/Air compared to the
15" rMBP four core processor for Obj C etc development?

(I am ambivalent if I want to do that kind of work. I love my iPad and want to
develop for it, but the frameworks are a little _too_ close to Java with the
30++ chars long names everywhere. :-( )

~~~
kylec
I can't really comment on what Objective C development is like on it as I
don't do any, but I think that the limiting factor on the 13" is the screen
size and not the processing power. Xcode has a lot of panels, and the 13" rMBP
is effectively 1280x800 in its "best for Retina" resolution. This can be
increased to a virtual resolution of 1680x1050 that works pretty well, but is
quite small on a 13" screen.

~~~
berntb
Thanks.

I generally use external screens with a laptop anyway, as long as I don't sit
in a coffee shop or something. (I did some work with my late-2008 13" Macbook.
Yeah, 1280 is too little.)

You did answer my specific question: I need a 15" rMBP (and/)or a setup with
external screen(s) (i.e. not mobile). In 4-8 months, when I should have more
time.

(As an Emacs user it took me hours mostly watching lecture videos to learn how
to use that damn IDE with the differing sets of windows and buttons.)

------
liquidise
I am amazed someone has found the _definitive_ mac setup. Here i thought CLI
guys are still debating the merits of vim vs emacs. I guess i'll file this
away under "presumptuous".

~~~
altryne1
Hehe, lighten up. The definitive part is to make the title stand out.

~~~
qwerty_asdf
I would advocate adjusting the title to:

    
    
      The definitive guide to setting up a new mac for [python, ruby, node, mongo] development
    

...or

    
    
      The definitive guide to setting up a new mac for development [with python, ruby, node, mongo]
    

...since I use my mac for "development", but I don't develop with nearly any
of the languages/tools/packages listed, and almost none of the tools that I
_do_ use are listed in this article. In fact, the only tool that I actually do
use, which gets any mention at all is Xcode?

~~~
altryne1
Noted!

------
qingu
I just got my first mac for development and followed this guide:

[https://github.com/nicolashery/mac-dev-
setup](https://github.com/nicolashery/mac-dev-setup)

~~~
altryne1
Hah! didn't see this one yet. Although it's a bit outdated, I will check it
out as well reference it from my blog post

------
bowlofpetunias
However much fun it is to beat an unwilling commercial OS into submission,
this is 2013. No need to mess around with homebrew and MAMP.

Your new Mac is powerful enough to run multiple Vagrant boxes simultaneously,
with all the tools you need and a near perfect simulation of your target
platform.

Use some good provisioning software (Ansible is awesome) to manage them, and
you're set. All you have to do for OSX is pick your favorite IDE.

Or alternatively, don't use OSX (or Windows), and get a machine that runs
Linux so you can have everything just the way you want/need it.

Everything else is just hobbyism, and as fun and educational as it may be, I'm
wary of developers that waste time on their primary development tools. Sooner
or later it becomes a horrible mess.

I've always been in favor of letting devs use any tool they like, but
developers wasting days on getting version X of package Y to run on their
Windows / OSX box when everyone else just does "apt-get upgrade" on their
(virtual) machine doesn't fill me with confidence in their ability to solve
problems effectively.

~~~
altryne1
I have had the same discussion with my team mates who use ubuntu. Me being a
front end dev and needing graphic tools, means i have to use mac. But to get
the ENV up an running it took a while. However, now the environment is exactly
the same. When they do apt-get I do brew install. I really miss your point
regarding "ability to solve problems effectively" . If you are proficient with
a mac, and you can achieve the same tasks more quickly, then setting it up is
the least of your problems. I agree with what you said regarding windows, as
getting the tools up to date there is a nightmare, but OSX is really up there,
and works fine. No real reason to run everything in a VM and waste memory

~~~
falcolas
The problem I have with this is that you're not developing against the target
environment - you're developing against the closest thing you can make to your
target environment, given your utilities.

The problems that I've run into in the past are typically subtle, but they're
almost always show stoppers (either on the development side or the production
side).

That said, my current environment is on a mac while my production is on EL6,
but my next one will not be. The up front cost to get a DB and nginx running
properly is just not worth the effort to do again.

------
batbomb
On topic: Apple's support for command line utilities and the whole GPL v3
thing is becoming a serious issue.

Bash is 6 years old on the Mac. For the most part, bash 3.2 is fine, but it's
at the point where I have to work with other people's bash 4.x scripts locally
that no longer work. If this sorry state of command line utilities support
from apple keeps up, I'm going to have to switch back to Linux soon.

A bit more on this, I actually just asked a question on stackoverflow (
[http://stackoverflow.com/questions/19642059/proper-way-to-
in...](http://stackoverflow.com/questions/19642059/proper-way-to-install-
bash-4-2-on-os-x-10-9-mavericks-from-source-without-getti) ) about installing
bash 4.2 on Mavericks because it hasn't been working so far. If anyone has any
insight on this, I'd greatly appreciate it.

~~~
northernmonkey
Have a look at the patches applied by the homebrew recipe. Might help. brew
edit bash

------
sazpaz
Just got my first Mac and I've been looking for this type of articles and
general articles for people power users switching to OSX from Windows. While
not a definitive guide this one has some good stuff. I was surprised by how
few articles there are on this topic.

One of goodies I found around: [http://carpeaqua.com/2012/10/15/my-ultimate-
developer-and-po...](http://carpeaqua.com/2012/10/15/my-ultimate-developer-
and-power-users-tool-list-for-mac-os-x-2012-edition-/)

------
ChikkaChiChi
I prefer vagrant to MAMP. Brew is not must-have and you can end up chasing a
lot of minor issues it creates. I've also moved to using git for preference
sync because I'm uncomfortable with the chattiness of the Dropbox app
recently.

This is less a definitive guide and more a list of some useful tools you like.
:)

~~~
moepstar
>>> Brew is not must-have and you can end up chasing a lot of minor issues it
creates

I rather chase any minor issues Brew creates than clean up the mess MacPorts
once created..

~~~
manicdee
MacPorts has worked just fine for me. Brew needs me to hold its hand for just
about everything I install, especially when a vendor supplied library is
updated.

I use BBEdit, oh-my-zsh, Vagrant, VMWare, Django, virtualenvwrapper, Selenium
IDE, Python's selenium, lib::local, Puppet, Sequel Pro, OmniGraffle, Jira,
Stash, git, Mercurial, SURFRAW, psman and a few other tools on a daily basis.

The article did point out Dash to me, and for that I am thankful.

------
jpttsn
Great work. That said, the guide mixes personal preferences eg. using Chrome
and Alfred with things that are indubitably essentials like git, making
"definitive" a stretch. Perhaps this could be separated into sections?

~~~
altryne1
Agreed that it's a little mixed with my personal flavor of how I use my mac.
Although I think Alfred with Dash is essential for development, it's a
personal preference of mine. I'll take notice, and next time it will be
clearer

------
udfalkso
Install Parallels, run Ubuntu and then ssh to it from the OSX terminal. No
more headaches. Everything just works. The sooner you make this move, the
better. I wish I had done it years ago.

~~~
swombat
What's the point of switching to Mac if you want to run Ubuntu?

I'm pretty happy developing on the mac itself. I guess it depends what you do.

~~~
udfalkso
Basically just for photoshop. And the (arguably) better hardware.

------
capkutay
I'm surprised there's no mention of macports...by the way, did anyone else
download mavericks to see that macports is broken?

~~~
kickingvegas
macports 2.2.1 with support for Mavericks is now available. I'm reinstalling
my ports as I type.

~~~
capkutay
thanks!

------
etep
why brew in favor of port (macports)? any particular reason -- just curious.

~~~
patrickmay
I avoid brew because it mungs the default permissions of /usr/local. I'm
probably not their target demographic, though, because I'm already using
/usr/local as the installation location when I build from source. I don't like
tools that violate my expectations.

~~~
tzs
Something like this should work to allow access to /usr/local without changing
the traditional Unix permissions:

    
    
       chmod +a 'user:YOUR_NAME_HERE allow add_subdirectory,add_file,delete_child,directory_inherit' /usr/local

------
jnoland
Going to install OSX Mavericks soon and use this guide. Thanks for the tips.

~~~
altryne1
You are welcome! Let me know in comments if any link didn't work

------
dkl
git comes with either Mac OS X 10.9 or Xcode, as it was installed in /usr/bin/
before I went to install it from Macports.

