Live data from Hacker News

Ask HN: Best practices for OS X dev environments

news.ycombinator.com

41–50 of 57 posts

Re: Ask HN: Best practices for OS X dev environments

#41

I don't think you will find multiple OSX user accounts viable/enjoyable. OSX puts a lot of important preferences (keyboard/mouse settings for example) within the user account, so you will end up having a nightmare keeping things in sync and sane. You won't be able to rely on a lot of important tools like dropbox or 1password easily. Just stick with 1 user. Use docker or virtualbox/vagrant for stuff you don't want to…

> I don't think you will find multiple OSX user accounts viable/enjoyable. OSX puts a lot of important preferences (keyboard/mouse settings for example) within the user account, so you will end up having a nightmare keeping things in sync and sane.

I've used multiple user accounts for years and I found multiple user accounts very useful when there are clear separations between projects (e.g. multiple freelance clients).

The settings you refer to are the kinds of things that belong in your dotfile repo. I can set up a new account and import all my settings in a matter of seconds this way – not a nightmare at all.

> I've lately started using project-specific instances of chrome (created with the chrome SSB script). This lets me keep lots of tabs separate and easily pause work and resume later

This is what multiple user accounts are for, except they work with all applications, not just Chrome.

Re: Ask HN: Best practices for OS X dev environments

#42
It is interesting to see everybody using VM's and containers.

Personally I have a web server I do all my work on, so I can get to that from my mac over: http, ftp, ssh, and vnc.

I do all my work online so I can easily point any device (or ask a friend with an exotic device to click a link to test something) and I can also work from any device with an internet connection.

This setup has let me be flexible, travel, work, and get things done for the past two years. I highly recommend a dev environment thats also already online so when your laptop lid is shut, your ability to work isnt!

Re: Ask HN: Best practices for OS X dev environments

#43
post #18

Everyone is suggesting VM's but I found them far too much of a pain. Homebrew has been able to install all databases and other dependencies for me.

I'd say go with VMs.

It's only a pain if you don't invest a week or so to master their use (which a knowledgable unix dev can also do in 1-2 days).

Installing "all databases and dependencies" on the Mac with Homebrew is not scalable, and it's not repeatable, and it's too kludgy. And when multiple versions of libs and such start to be needed, it wont even work.

(For small scale stuff, like some Wordpress development, it might be ok. But it would still be better to use a VM).

You won't deploy on a Mac in the end, but on some Linux box, so develop on a VM offering the same environment.

Note that I would still develop on a VM even if I was using Linux as a desktop -- you should not mix your desktop machine with your development environment.

Re: Ask HN: Best practices for OS X dev environments

#44
post #18

Everyone is suggesting VM's but I found them far too much of a pain. Homebrew has been able to install all databases and other dependencies for me.

I really like the idea of a VM on mac OS too, but recently I've been experiencing nothing but trouble... I use to develop on a Ubuntu machine and having everything running natively, then I started to work from a co-working space, so I setup my Mac with Vagrant, Virtualbox, Ansible (for provision), to run my Django app, and after that I noticed that all my browser calls to the local development server were taking betw…

Search "Mac fix DNS" and you'll find what to do.

Here's an example: http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-i...

Re: Ask HN: Best practices for OS X dev environments

#45
post #25
post #18

Everyone is suggesting VM's but I found them far too much of a pain. Homebrew has been able to install all databases and other dependencies for me.

How do people find the battery life overhead? A quick test showed a Flask dev server tool 25% in a VM compared to less than 2% natively. That would seriously restrict my ability to develop on the move or away from my desk.

First, 25% of the VM's CPU (seen in the VM's "top") is not the same as 25% of the host CPU.

Second, do you develop on the move unplugged for large stretches of time? Where is that place that doesn't have a plug?

Re: Ask HN: Best practices for OS X dev environments

#46
post #17
post #12

Earlier quoted context omitted.

Vagrant has been a much bigger time sink for me than benefit. The ssh-agent never works while provisioning for nix servers, only during ssh (which I can do using the -- -A regardless). It often gets confused and the machines need to be destroyed and re-created after 1-2 provisioning attempts. Packers (The tool used to create vagrant boxes) lack of support for winrm on windows systems has also been a bone of contentio…

> Vagrant has been a much bigger time sink for me than benefit. This has been my experience as well... and I would really, really like to have a system in place where I could painlessly spin up VMs to do development in, so that I could leave my Mac as is.

Build a custom box for Vagrant. I did this and now can spin up a CentOS 7 image with Apache, MySQL (Mariadb), RVM (ruby version manager) and a bunch of utilities (wget, curl, git, etc.) in a matter of minutes. I wrote up a how-to on my blog (in profile). I've tried Puppet but it just seemed like more trouble - that would be useful for 10's or 100's of nodes.

As an example, I wanted to try out Ghost to see if I liked that better than Jekyll/Octopress for a blog, so after 'vagrant init centos7' I had a VM running and I could screw up a ton of stuff then and not care.

Re: Ask HN: Best practices for OS X dev environments

#47
post #12

Earlier quoted context omitted.

Vagrant has been a much bigger time sink for me than benefit. The ssh-agent never works while provisioning for nix servers, only during ssh (which I can do using the -- -A regardless). It often gets confused and the machines need to be destroyed and re-created after 1-2 provisioning attempts. Packers (The tool used to create vagrant boxes) lack of support for winrm on windows systems has also been a bone of contentio…

Windows is, admittedly, a second class citizen for Vagrant. That said, with one install and one config file change, vagrant is as usable on Windows as it is on the Mac. I keep a number of exploratory Vagrant instances on a USB key (just the files, the boxes default to your "home" directory on the machine), and work on them regularly on both a Mac and Windows. A quick google search for 'vagrant windows' will lead you…

I'm talking about running windows inside of Vagrant and having these issues on a Mac. The problems I've detailed have long standing issue logs on github, some closed without resolution. I'm not casting aspersions, I'm explaining my use and my experience. This is valid, regardless of whether you have had the same experience. Regardless, the tool sells itself as working on windows, so it is not only fair, but apt. Providing a counter example is a good rebuttal, but saying my experience is invalid reeks of fanboyism.

Re: Ask HN: Best practices for OS X dev environments

#48

In regards to Python and Ruby (on Rails), have you found the tools pyenv and rbenv (or rvm)? Node also has a similar tool, nvm. These all allow you to manage separate version of languages and sets of package dependencies. I have found them invaluable in keeping concerns separated. I lean more towards local installation for software that can handle multiple applications/connections from one install (e.g. Postgres) unl…

I tend to agree. Most of my web development work lately has been with Rails, although a bit has been with Node, and a bunch in Python in the past. Rbenv is wonderful for managing different versions, npm takes care of local dependency installs quite nicely, and virtualenv solves the problem for Python too. I generally just install a local copy of postgresql and redis, and I'm good to go without having to mess with a bunch of different VMs and things like that.

Re: Ask HN: Best practices for OS X dev environments

#49
post #4

I use vagrant + virtualbox (runs ubuntu via vagrant setup) + ansible to bootstrap the VM. I've had this setup for 2 years now. No issues and I get to use sublime to edit files locally while they are shared with the VM.

I do the same, but I've had trouble with the overhead of virtual machines (admittedly on an older laptop). Have you not found this to be a problem at all? As deployments get simpler and the usefulness of Ansible for server config declines, I'm thinking about abandoning the VMs and going back to running things in OS X.

haven't hit this problem much. But I do have a solid iMac that I use for development.

Re: Ask HN: Best practices for OS X dev environments

#50

Don't install server-side stuff directly on your Mac. If you are working on server-side projects, then use virtual machines. Vagrant in combination with a configuration management system (e.g. Puppet) is very helpful here. Use Homebrew to install command-line tools. Use Homebrew Cask to install GUI tools that aren't on the Mac App Store. Lots of people find it useful to check their environment's configuration files i…

As I understand it App Store apps are 'sandboxed' - so is there any way to use this to create light, snapshottable containers isolated from the main filesystem?

I've been using Vagrant and Virtualbox, but the lack of speed is painful. And the overhead with a couple running at once.

It just strikes me as odd that Ruby has rbenv, Python has virtualenv - but there's nothing language agnostic and native to the Operating System, that I can use to try out new languages/tools, and nuke if all goes wrong without messing up my OS X filesystem (or versions of installed programs).

Post reply on HN