Is the prevailing opinion then that OS X really just isn't a good development environment? Seems like most of the suggestions so far are "install one or more Linux VMs". As someone who develops on a MacBook Pro everyday, I know I definitely fall in the Linux VM camp.
Ask HN: Best practices for OS X dev environments
11–20 of 57 posts
Re: Ask HN: Best practices for OS X dev environments
#12Don'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…
Homebrew Cask also has no oversight for breaking changes, so use this only as a convenience, not a tool to be relied upon. It frequently looses track of applications, and I can't even find where it decides to put some error logs if they're created at all.
Some of these problems could be my lack of experience in operations, but the documentation for these is far from complete. A VM with snapshots and a good backup strategy will serve you better in the short term. This changes if you're attempting to support multiple dev, but if you're a lone guy, then snapshots are far far less buggy.
Re: Ask HN: Best practices for OS X dev environments
#13Use one VM per project, not Mac OS X. Unless of course you're deploying on Mac OS X. Use snapshots and switch between them when disk space becomes an issue. The big advantage is that, either through careful notes or configuration management, you'll actually be able to recreate your development environment in the future.
Re: Ask HN: Best practices for OS X dev environments
#14Is the prevailing opinion then that OS X really just isn't a good development environment? Seems like most of the suggestions so far are "install one or more Linux VMs". As someone who develops on a MacBook Pro everyday, I know I definitely fall in the Linux VM camp.
But the overlooked thing in this discussion is that its mostly about hardware. If someone made a hardware, physical device, that was as comfortable and life-friendly as a Macbook Pro, I'd switch to it in an instance. The Google pixel laptop looked promising, but was hobbled by sub-standard specs and a 'meh' attitude, it seems, but the point is whats overlooked is the physical experience that comes with using OSX.
So I'm with you, there's nothing quite like having the slab ramped up with some fat VM's. Linux works great in that environment, too ..
Re: Ask HN: Best practices for OS X dev environments
#15Don'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…
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…
The Salt provisioner doesn't bootstrap Salt every time, so it may be a bug with the Chef provisioner rather than something that's true of all provisioning. Isn't Chef installed by default on most base boxes anyway though? It sounds like you've hit an edge case that you can work around by installing Chef in your base box.
Snapshots and backing up VMs sounds a lot more hassle than Vagrant.
Same goes with Cask – I've never had it lose track of applications. It's hard to see how this could happen, as this mechanic is pretty simple – if it's in the directory, it's present, otherwise it's absent.
Re: Ask HN: Best practices for OS X dev environments
#16Is the prevailing opinion then that OS X really just isn't a good development environment? Seems like most of the suggestions so far are "install one or more Linux VMs". As someone who develops on a MacBook Pro everyday, I know I definitely fall in the Linux VM camp.
It's not about needing tools from Linux, it's about keeping your development environment and your deployment environment separate. Otherwise all sorts of unwanted dependencies can creep in and it's difficult to reproduce the correct deployment environment outside of your development environment. If you manage your deployment correctly from the start, it's a hell of a lot easier.
For instance, if you install a web server in your case-insensitive development environment, write a load of code, then deploy to a case-sensitive deployment environment, then you may inadvertently introduce errors because you got the case wrong somewhere in your code. You introduced a dependency upon a development environment property that wasn't present in your deployment environment and things broke.
The environment you write code in and the environment you have to execute that code in are often very different things. Mixing them up is bad news – that's where virtual machines help you out by keeping the two separate.
Re: Ask HN: Best practices for OS X dev environments
#17Don'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…
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…
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.
Re: Ask HN: Best practices for OS X dev environments
#18Re: Ask HN: Best practices for OS X dev environments
#19See: https://github.com/geerlingguy/mac-dev-playbook
Once you start using VMs and/or containers for your development, you'll stop worrying about environments and breaking things :)
Re: Ask HN: Best practices for OS X dev environments
#20Don'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…
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 won't install Chef or Puppet for you - your provisioning scripts need to do this.
If you're seeing Chef being downloaded every single time you provision, then your scripts are broken and you should fix them, or your 3rd party scripts are broken and you should report a bug.