8 ms·

Setting up a new Mac for development

55 points by altryne1 13y ago

mellamoyo 13y ago
> 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.
- altryne1 13y ago
  Totally agree! I'll put a notice on the blogpost with a different way of doing this. Youre right, this can lead to bad stuff :/
- vondur 13y ago
  You see this sort of thing more and more these days. But hey, if you can't trust something linked off of hacker news, who can you trust? ;)
- tuananh 13y ago
  it's bad practice : yes but the source is there on github. you can always take a look. what is there to be afraid of.
  - btgeekboy 13y ago
    On a non-github platform, it would be trivial to serve different content if the user agent was curl or wget.
  - ultimoo 13y ago
    The first URL isn't https. A rogue router anywhere from your building or your ISP to the server's building could potentially tamper with a plain text http response, which would then be evaluated by your shell.
    - tuananh 13y ago
      well i was talking about homebrew. it uses https. ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"
- alex_anglin 13y ago
  Especially when the first script installs Dropbox. I was sure I wasn't the only one who read that and thought "Seriously???"
- fishtoaster 13y ago
  I feel like this discussion comes up every time someone mentions homebrew. The conclusion I've come to is that `curl -s foo.com/bar | sh` is less secure than downloading and running an install script locally iff you intend to review the install script yourself. If you're just downloading homebrew and running an install script by hand without reading it (as, honestly, I usually do), there's no difference.
  - kbutler 13y ago
    It's also at least as safe as downloading and running a binary executable.
    - falcolas 13y ago
      I see this assertion all the time, and I disagree. For one thing, the script is coming over http, so it's trivial to intercept and replace the content, perhaps even silently so you get the original content plus a few extra box owning goodies. Two, as a .sh script, its self-selecting in terms of what system the binary executable has to be written for. Also, it's typically not as easy to escalate privileges in an executable as it is in an arbitrary shells script.
      - kbutler 13y ago
        curl -s foo.com/bar | sh vs curl -o install foo.com/bar && chmod a+x install && ./install The script is an open source installer, the binary is hidden/closed. You and others at least have the option to inspect it. The binary would also be coming over http (https is clearly preferred for binaries or scripts). A binary can always embed a script and do a 'system' call to execute any script-available privilege escalation. I'm not sure what you mean by "as a .sh script, its self-selecting in terms of what system the binary executable has to be written for". I think you mean that a single .sh script can target multiple platforms. That doesn't mean a binary is any safer for you to download and execute on your system.
- bithive123 13y ago
  How is this any less secure than "here, download and run this executable"?
  - logicallee 13y ago
    it takes a ton of work to package and upload a binary, and if you make it malicious it's right there in the dowwnload folder. This is more like executing the current text of a web site (whatever that is) in a totally ephemeral way. That gives total plausible deniability to anyone who would serve you a particular version based on your IP, for example.... (or anything else). You're just not keeping the evidence. I mean, you "could". But doing things this way, you're not...
  - soneil 13y ago
    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.
- rytis 13y ago
  I agree with this 100%. And here's to all replies that say it's as secure as a package: it's only partly about security. The other part is version control. I can install a specific version of an RPM relatively easily, but wget|sh approach makes it much more inconvenient. One day it does one thing, the next day it may do something completely different. Even if I install on 2 machines, there's no guaranty that the repo owner won't push changes in the meantime.
- fit2rule 13y ago
  Yeah, like .. and also, be careful with the 'plugins' of a 'keyboard' manager, kiddiez .. these are helaciously un-inspected playgrounds for harvesting. It may "improve" your developer chops, but then .. "it may not". There are ways to change the keyboard home/end key without needing an app to download. For example, a bit of Google instead yields: $ cd ~/Library $ mkdir KeyBindings $ cd KeyBindings $ nano DefaultKeyBinding.dict Put these lines in that file, including the curly braces: { /* Remap Home / End keys to be correct */ "\UF729" = "moveToBeginningOfLine:"; /* Home */ "\UF72B" = "moveToEndOfLine:"; /* End */ "$\UF729" = "moveToBeginningOfLineAndModifySelection:"; /* Shift + Home */ "$\UF72B" = "moveToEndOfLineAndModifySelection:"; /* Shift + End */ "^\UF729" = "moveToBeginningOfDocument:"; /* Ctrl + Home */ "^\UF72B" = "moveToEndOfDocument:"; /* Ctrl + End */ "$^\UF729" = "moveToBeginningOfDocumentAndModifySelection:"; /* Shift + Ctrl + Home */ "$^\UF72B" = "moveToEndOfDocumentAndModifySelection:"; /* Shift + Ctrl + End */ } (from Matt: http://mwholt.blogspot.co.at/2012/09/fix-home-and-end-keys-on-mac-os-x.html http://mwholt.blogspot.co.at/2012/09/fix-home-and-end-keys-o...) Why require a third-party to do such things, developers? And also, umm .. dotfiles, kidz? Really, just like that? wtf. Please do not encourage such glib attitudes in an article intended for 'quick action', but rather .. dissect the thing. A collection of links with explanatory text is one thing.. Take some time, this isn't homework. Dig deeper. (+todo: grep -ir ".dict" this_article_suites_.x//)
  - vvhn 13y ago
    " /* Remap Home / End keys to be correct */" only when correct == "Windows Convention" Home and End keys on the Mac (on applications which don't override default behaviour for these keys) are conventionally the same as old UNIX - they take you to the beginning and end of the document and not the beginning and end of the line (as on Windows). http://en.wikipedia.org/wiki/Home_key http://en.wikipedia.org/wiki/Home_key
    - waylonrobert 13y ago
      So how do you go to the start/end of lines then?
qingu 13y ago
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 13y ago
  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
jareds 13y ago
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.
- altryne1 13y ago
  I'd say that if retina display isn't your thing, go for the best macbook air available. It's a killer machine with a staggering 12 hours of battery life and it weighs so little your back with thank you. In terms of performance, with the new mavericks optimizations and haswell proccessor you will barely make this machines fans work unless you compile xcode or encode video
- sn0v 13y ago
  How often are you going to be carrying this around? If the answer is "not that much" then I'd say throw in the extra 50 for an rMBP.
- vondur 13y ago
  That's a tough call. If this was going to be my only and everyday machine, I'd go for the 13" Pro with the Retina display. The processor is faster and I could live with the extra weight. If it's a secondary machine, I'd go for the Air for the portability and battery life.
- brown9-2 13y ago
  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.
jnoland 13y ago
Going to install OSX Mavericks soon and use this guide. Thanks for the tips.
- altryne1 13y ago
  You are welcome! Let me know in comments if any link didn't work
etep 13y ago
why brew in favor of port (macports)? any particular reason -- just curious.
- Apocryphon 13y ago
  And why PasswordBox instead of 1Password?
  - altryne1 13y ago
    Oh, well, 1password seems very greedy. Although I don't mind paying for software, 1password ends up being extra costy when you want the app and the mobile apps. Especially now that a new one released and it's not an update but a new app you need to buy. Where as password box is free. 100%
- altryne1 13y ago
  It's a personal preference but it seems like brew is more supported and the lack of need for 'sudo' wins in my book
- patrickmay 13y ago
  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 13y ago
    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
dkl 13y ago
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.
liquidise 13y ago
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 13y ago
  Hehe, lighten up. The definitive part is to make the title stand out.
  - qwerty_asdf 13y ago
    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 13y ago
      Noted!
jpttsn 13y ago
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 13y ago
  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
capkutay 13y ago
I'm surprised there's no mention of macports...by the way, did anyone else download mavericks to see that macports is broken?
- kickingvegas 13y ago
  macports 2.2.1 with support for Mavericks is now available. I'm reinstalling my ports as I type.
  - capkutay 13y ago
    thanks!
deleted 13y ago
[deleted]
sazpaz 13y ago
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-power-users-tool-list-for-mac-os-x-2012-edition-/ http://carpeaqua.com/2012/10/15/my-ultimate-developer-and-po...
udfalkso 13y ago
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 13y ago
  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 13y ago
    Basically just for photoshop. And the (arguably) better hardware.
batbomb 13y ago
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-install-bash-4-2-on-os-x-10-9-mavericks-from-source-without-getti http://stackoverflow.com/questions/19642059/proper-way-to-in... ) 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 13y ago
  Have a look at the patches applied by the homebrew recipe. Might help. brew edit bash
ChikkaChiChi 13y ago
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. :)
- altryne1 13y ago
  As it states in the title, it's very opinionated. Vagrant is nice, but it doesn't replace MAMP for the functionality that I use it for, which is mainly virtual hosts.
- moepstar 13y ago
  >>> 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 13y ago
    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.
bowlofpetunias 13y ago
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.
- swah 13y ago
  In my experience, Linux graphics aren't smooth like OSX. I have the same problems you describe here: http://news.ycombinator.com/item?id=6545726 http://news.ycombinator.com/item?id=6545726
- altryne1 13y ago
  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 13y ago
    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.

55 points by altryne1 13y ago

> 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.

altryne1 13y ago
Totally agree! I'll put a notice on the blogpost with a different way of doing this. Youre right, this can lead to bad stuff :/
vondur 13y ago
You see this sort of thing more and more these days. But hey, if you can't trust something linked off of hacker news, who can you trust? ;)
tuananh 13y ago
it's bad practice : yes but the source is there on github. you can always take a look. what is there to be afraid of.
- btgeekboy 13y ago
  On a non-github platform, it would be trivial to serve different content if the user agent was curl or wget.
- ultimoo 13y ago
  The first URL isn't https. A rogue router anywhere from your building or your ISP to the server's building could potentially tamper with a plain text http response, which would then be evaluated by your shell.
  - tuananh 13y ago
    well i was talking about homebrew. it uses https. ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"
alex_anglin 13y ago
Especially when the first script installs Dropbox. I was sure I wasn't the only one who read that and thought "Seriously???"
fishtoaster 13y ago
I feel like this discussion comes up every time someone mentions homebrew. The conclusion I've come to is that `curl -s foo.com/bar | sh` is less secure than downloading and running an install script locally iff you intend to review the install script yourself. If you're just downloading homebrew and running an install script by hand without reading it (as, honestly, I usually do), there's no difference.
- kbutler 13y ago
  It's also at least as safe as downloading and running a binary executable.
  - falcolas 13y ago
    I see this assertion all the time, and I disagree. For one thing, the script is coming over http, so it's trivial to intercept and replace the content, perhaps even silently so you get the original content plus a few extra box owning goodies. Two, as a .sh script, its self-selecting in terms of what system the binary executable has to be written for. Also, it's typically not as easy to escalate privileges in an executable as it is in an arbitrary shells script.
    - kbutler 13y ago
      curl -s foo.com/bar | sh vs curl -o install foo.com/bar && chmod a+x install && ./install The script is an open source installer, the binary is hidden/closed. You and others at least have the option to inspect it. The binary would also be coming over http (https is clearly preferred for binaries or scripts). A binary can always embed a script and do a 'system' call to execute any script-available privilege escalation. I'm not sure what you mean by "as a .sh script, its self-selecting in terms of what system the binary executable has to be written for". I think you mean that a single .sh script can target multiple platforms. That doesn't mean a binary is any safer for you to download and execute on your system.
bithive123 13y ago
How is this any less secure than "here, download and run this executable"?
- logicallee 13y ago
  it takes a ton of work to package and upload a binary, and if you make it malicious it's right there in the dowwnload folder. This is more like executing the current text of a web site (whatever that is) in a totally ephemeral way. That gives total plausible deniability to anyone who would serve you a particular version based on your IP, for example.... (or anything else). You're just not keeping the evidence. I mean, you "could". But doing things this way, you're not...
- soneil 13y ago
  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.
rytis 13y ago
I agree with this 100%. And here's to all replies that say it's as secure as a package: it's only partly about security. The other part is version control. I can install a specific version of an RPM relatively easily, but wget|sh approach makes it much more inconvenient. One day it does one thing, the next day it may do something completely different. Even if I install on 2 machines, there's no guaranty that the repo owner won't push changes in the meantime.
fit2rule 13y ago
Yeah, like .. and also, be careful with the 'plugins' of a 'keyboard' manager, kiddiez .. these are helaciously un-inspected playgrounds for harvesting. It may "improve" your developer chops, but then .. "it may not". There are ways to change the keyboard home/end key without needing an app to download. For example, a bit of Google instead yields: $ cd ~/Library $ mkdir KeyBindings $ cd KeyBindings $ nano DefaultKeyBinding.dict Put these lines in that file, including the curly braces: { /* Remap Home / End keys to be correct */ "\UF729" = "moveToBeginningOfLine:"; /* Home */ "\UF72B" = "moveToEndOfLine:"; /* End */ "$\UF729" = "moveToBeginningOfLineAndModifySelection:"; /* Shift + Home */ "$\UF72B" = "moveToEndOfLineAndModifySelection:"; /* Shift + End */ "^\UF729" = "moveToBeginningOfDocument:"; /* Ctrl + Home */ "^\UF72B" = "moveToEndOfDocument:"; /* Ctrl + End */ "$^\UF729" = "moveToBeginningOfDocumentAndModifySelection:"; /* Shift + Ctrl + Home */ "$^\UF72B" = "moveToEndOfDocumentAndModifySelection:"; /* Shift + Ctrl + End */ } (from Matt: http://mwholt.blogspot.co.at/2012/09/fix-home-and-end-keys-on-mac-os-x.html http://mwholt.blogspot.co.at/2012/09/fix-home-and-end-keys-o...) Why require a third-party to do such things, developers? And also, umm .. dotfiles, kidz? Really, just like that? wtf. Please do not encourage such glib attitudes in an article intended for 'quick action', but rather .. dissect the thing. A collection of links with explanatory text is one thing.. Take some time, this isn't homework. Dig deeper. (+todo: grep -ir ".dict" this_article_suites_.x//)
- vvhn 13y ago
  " /* Remap Home / End keys to be correct */" only when correct == "Windows Convention" Home and End keys on the Mac (on applications which don't override default behaviour for these keys) are conventionally the same as old UNIX - they take you to the beginning and end of the document and not the beginning and end of the line (as on Windows). http://en.wikipedia.org/wiki/Home_key http://en.wikipedia.org/wiki/Home_key
  - waylonrobert 13y ago
    So how do you go to the start/end of lines then?

qingu 13y ago

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 13y ago
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

jareds 13y ago

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.

altryne1 13y ago
I'd say that if retina display isn't your thing, go for the best macbook air available. It's a killer machine with a staggering 12 hours of battery life and it weighs so little your back with thank you. In terms of performance, with the new mavericks optimizations and haswell proccessor you will barely make this machines fans work unless you compile xcode or encode video
sn0v 13y ago
How often are you going to be carrying this around? If the answer is "not that much" then I'd say throw in the extra 50 for an rMBP.
vondur 13y ago
That's a tough call. If this was going to be my only and everyday machine, I'd go for the 13" Pro with the Retina display. The processor is faster and I could live with the extra weight. If it's a secondary machine, I'd go for the Air for the portability and battery life.
brown9-2 13y ago
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.

jnoland 13y ago

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

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

etep 13y ago

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

Apocryphon 13y ago
And why PasswordBox instead of 1Password?
- altryne1 13y ago
  Oh, well, 1password seems very greedy. Although I don't mind paying for software, 1password ends up being extra costy when you want the app and the mobile apps. Especially now that a new one released and it's not an update but a new app you need to buy. Where as password box is free. 100%
altryne1 13y ago
It's a personal preference but it seems like brew is more supported and the lack of need for 'sudo' wins in my book
patrickmay 13y ago
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 13y ago
  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

dkl 13y ago

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.

liquidise 13y ago

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 13y ago
Hehe, lighten up. The definitive part is to make the title stand out.
- qwerty_asdf 13y ago
  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 13y ago
    Noted!

jpttsn 13y ago

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 13y ago
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

capkutay 13y ago

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

kickingvegas 13y ago
macports 2.2.1 with support for Mavericks is now available. I'm reinstalling my ports as I type.
- capkutay 13y ago
  thanks!

deleted 13y ago

[deleted]

sazpaz 13y ago

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-power-users-tool-list-for-mac-os-x-2012-edition-/ http://carpeaqua.com/2012/10/15/my-ultimate-developer-and-po...

udfalkso 13y ago

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 13y ago
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 13y ago
  Basically just for photoshop. And the (arguably) better hardware.

batbomb 13y ago

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-install-bash-4-2-on-os-x-10-9-mavericks-from-source-without-getti http://stackoverflow.com/questions/19642059/proper-way-to-in... ) 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 13y ago
Have a look at the patches applied by the homebrew recipe. Might help. brew edit bash

ChikkaChiChi 13y ago

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. :)

altryne1 13y ago
As it states in the title, it's very opinionated. Vagrant is nice, but it doesn't replace MAMP for the functionality that I use it for, which is mainly virtual hosts.
moepstar 13y ago
>>> 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 13y ago
  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.

bowlofpetunias 13y ago

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.

swah 13y ago
In my experience, Linux graphics aren't smooth like OSX. I have the same problems you describe here: http://news.ycombinator.com/item?id=6545726 http://news.ycombinator.com/item?id=6545726
altryne1 13y ago
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 13y ago
  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.