Live data from Hacker News

Ask HN: Best practices for OS X dev environments

news.ycombinator.com

11–20 of 57 posts

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

#11

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.

It is a good dev environment, but you shouldn't just install server stuff on your mac, that's what the VMs are for (so that all developers would have identical server setup).

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

#12

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…

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 contention. It requires a number of workarounds (like installing open-ssh) on the windows VM that in no way would be viable on a production windows server. And that divergence allows for the "It works on my machine" bugs which is really the whole point of using Vagrant. I use chef for provisioning, and Vagrant also downloads the chef provisioner every single provision, I suspect it does this with puppet as well, so if you're developing on the go and need to re-provision, you're either out of luck or require an unlimited data plan.

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

#13

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

Even if you're deploying to mac, you should use a mac vm. If you manage to get a buggy or corrupt package, it's much easier to revert to a snapshot or reprovision a vm than to reprovision your machine.

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

#14

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.

I think OSX is a great development environment, it supports a great many toolsets and frameworks, and so on .. you don't have to go exclusively the Apple way, though that is changing more and more .. it is still a user-controlled Platform.

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

#15
post #12

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…

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…

I haven't experienced any of that, but then I wouldn't use it for Windows in the first place and it doesn't sound like the kind of thing the OP is doing either.

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

#16

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.

No, it doesn't matter what platform you are developing on or deploying to, if you are working on server-side stuff, use a VM.

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

#17
post #12

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…

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.

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

#19
I've been using Ansible + Homebrew + Vagrant/VirtualBox for the past couple years, and am now able to provision a new Mac for myself in about an hour (with all my apps and settings in place for development) with a good internet connection.

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

#20
post #12

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…

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…

> I use chef for provisioning, and Vagrant also downloads the chef provisioner every single provision, I suspect it does this with puppet as well, so if you're developing on the go and need to re-provision, you're either out of luck or require an unlimited data plan.

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.

Post reply on HN