Setting up a new Mac for development | Hacker News Reader

Setting up a new Mac for development

a-w.me

55 pointsaltryne166 comments

> curl -s http://getmacapps.com/raw/6bl | sh

> ruby -e "$(curl -fsSL 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.

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 :/

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? ;)

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.

On a non-github platform, it would be trivial to serve different content if the user agent was curl or wget.

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.

well i was talking about homebrew. it uses https.

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

Especially when the first script installs Dropbox. I was sure I wasn't the only one who read that and thought "Seriously???"

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.

It's also at least as safe as downloading and running a binary executable.

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.

curl -s foo.com/bar | sh

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.

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

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

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.

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.

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-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//)

" /* 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

So how do you go to the start/end of lines then?

There are 2 options (on applications which havn't overridden default key bindings) -

a) cmd-left arrow for beginning and cmd-right arrow for end of the line.

b)emacs key bindings are available as well control-a and control-e for the beginning and end of a line.

Option a) gets slightly complicated in text entry on edit controls of browsers which have the cmd-left arrow key mapped to previous page (Firefox). In addition, a lot of multiplatform software ends up making things behave like on Windows ( Microsoft Office being one) by overriding defaults for these keys and home and end keys do take you to the beginning and end of the line there.

The point is, as developers, we can master whatever conventions matter to us. Me, personally - I use Home and End in the line context, not the document context.

So I'm quite happy knowing how to bend the computer to my will and not the other way around.

oh totally - I was just objecting to the use of the word "correct" :).

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.

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

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.

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.

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.

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

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.

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

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.

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

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

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

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?

Noted!

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

https://github.com/nicolashery/mac-dev-setup

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

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.

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

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.

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

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

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

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

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

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.

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

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.

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?

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

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.

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.

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

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

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

thanks!

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

And why PasswordBox instead of 1Password?

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%

It's a personal preference but it seems like brew is more supported and the lack of need for 'sudo' wins in my book

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.

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

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

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

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.

Reply on news.ycombinator.com