Ask HN: Best practices for OS X dev environments
I'm about to get a new Mac and will be starting fresh on a new drive. I would like to know if there are any best practices in regards to creating multiple user accounts, with different permissions for my scattered development work.
I spend time with node, python, and RoR. I like cloning projects from github and taking them for a spin. I test out bitcoin projects, and send GPG emails, and ssh into multiple servers. And I do all of this on my main user account that has sudo.
Is there some best practice that I should be aware of that would have me use multiple unix users on my new Mac?
56 comments
[ 0.27 ms ] story [ 119 ms ] threadUse 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.
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.
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.
Not myself. The VMs are never doing anything so taxing that they incur significant overhead. I can regularly keep 3-4 running concurrently without an issue.
> usefulness of Ansible for server config declines
I don't ever see this being the case. Configuration is becoming more challenging, not easier. Even if you use a tool like Docker perfectly for all of your services (which is ironically very hard without some kind of CM tool beside dockerfiles), you still have to: install packages, change configuration files, run commands, enable services, change permissions, change firewall rules, modify DB users, manage SELinux, setup log file rotation...
Servers are hard to set up and maintain in a coordinated fashion without some kind of CM tool. And while PAAS providers can handle quite a few lightweight services without requiring you to use any CM tools, there comes a point where they no longer scale the way you need them to, and you're back to provisioning VMs or even bare metal.
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 into version control – check out popular dotfiles repositories. On OS X, this also includes scripts that call `defaults write` for integration with OS X preferences.
As far as multiple unix users are concerned, just create them and use them. There's no special trick you need.
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.
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.
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.
It feels almost as a native support, but the hack is betrayed by the networking setup.
I wish it would be possible to just expose ports on the real localhost.
On non Linux systems, it downoads a prebuilt VM, and runs it with Virtualbox.
This is how Docker currently works on other OSes.
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.
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.
It's generally better to have a shell script install your provisioning tool, or use a box that already has it installed, than depending on Vagrant to do anything for you.
Here's a simple example: https://github.com/puphpet/puphpet/blob/master/archive/puphp...
Otherwise, another option is to either use prebuilt Vagrant boxes with your CM tool already installed, or build your own using Packer.
A quick google search for 'vagrant windows' will lead you to one of many blog posts like this one [1], which point out that your Vagrant experience on Windows will be better if you install Git. This places 'ssh' and 'scp' on your path, and then everything about Vagrant just works, including vagrant ssh. I still prefer to use PuTTY to connect when on Windows, but that's my personal preference.
As for the chef re-provisioning, it is more likely an issue with the environment, not Chef of Vagrant. When Vagrant sees that the Chef binaries are already in place, it will note that and continue with the provisioning. Try it again when you have the git command line tools in your path and see if its still an issue.
However, these problems are with your Windows setup of Vagrant, not Vagrant itself. Vagrant on a Mac requires no such workaround to get the unix tools in place, and casting your aspersions against Vagrant from your experience on Windows when it works out of the box on a Mac is unfair to the tool.
[1] https://eamann.com/tech/vagrant-windows/
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).
For server stuff I would use docker. For docker it's the same story, linux native is better than OS-X with boot2docker.
If you need a lot IDE's then OS-X might be the better choice since retina support is not yet as good on Ubuntu. On the other hand Sublimetext is perfect on linux with retina.
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 ..
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.
Plus, many of the available database installs are much more fragile (and use older versions) on my Mac than they are on a VM.
The only time I see local development working particularly well is for front end development, where the part that matters is in the browser, not the server.
That would seriously restrict my ability to develop on the move or away from my desk.
Second, do you develop on the move unplugged for large stretches of time? Where is that place that doesn't have a plug?
I'm talking about 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?
Anywhere with sunshine and fresh air. We don't get many sunny days in the UK and I'm damned if I'm spending them indoors.
Which is a big chunk of time.
Here's an example: http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-i...
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.
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 :)
I lean more towards local installation for software that can handle multiple applications/connections from one install (e.g. Postgres) unless I'm preparing my staging environment. Sometimes I use Docker containers for local services (e.g. ZeroMQ) while developing so I don't incur a large overhead for every service my application requires. VMs are used for staging.
I follow this pattern on Linux and OSX.
Definitely don't use your Mac in single-user mode though. Not that complicated to set up.
One thing that I've thought about trying though, is Boxen. Github supports hundreds of developer macs and they built this framework to do so. It looks pretty incredible. https://github.com/blog/1345-introducing-boxen
Here are some of my tools and tips.
- homebrew is great - homebrew cask is helpful, too - 1password or similar - virtualbox can give you clean playgrounds and test environments that match your servers - boot2docker is handy for quickly starting and running services like databases without polluting your mac directly too much - I also get a lot of use out of vagrant but YMMV - 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 - The chrome Tabs Outliner plugin is also really key
Here's my recent blog post with more details: http://peterlyons.com/problog/2015/02/osx-development-setup
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.
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!