Configure your development environment at the speed of light!
As Software Developers, we like to have the tools we use configured just the right way. This creates an issue, however, when you have to configure your development environment again in the future for any reason.
“Uurgh, what was that git alias for nice logs again?” and “why don’t I have docker installed on my machine?! I swear I had it installed” become your source of annoyance for the next week.
In an ideal world, it would be amazing to go from a blank brand-new computer to one with all the dependencies needed with one script.
Of course, like with most things, the open–source community comes to the rescue with thoughtbot/laptop. This script will get your brand–new, or sysadmin russian-rouletted, computer to developer ready in less than an hour (I usually average about 15 minutes with a good internet connection).
Be warned: this script is primarily aimed at getting your machine set up for Ruby on Rails development on macOS. Unfortunately, this script will be useless for you if you’re not on macOS since it relies heavily on Homebrew — the package manager for macOS.
If you are on Linux, I’ve found a fork of the repository that claims to work with Linux. I’ve never tried it personally, but it seems to work well. If anyone has used it before, leave a comment below with your experience.
Ruby on Rails developer or not, I recommend you fork either repository and make changes to the script as you see fit. There are a few useful functions, such as
gem_install_or_update that allow you to abstract common use cases.
If you’re a PHP developer, who never plans on writing
ruby code, you’ll probably remove the
gem related code and install
composer instead. If you don’t use
vim then, you may want to remove this line, and so on.
The consequence of this is that no matter what happens to your computer, you can always get going with development within the hour on another machine (provided, in this context, it runs macOS).
Once you have your tools setup, the next step is to re-customise your settings for those tools. If you use a lot of tools, this can become a very cumbersome step very quickly.
One very useful way to combat this is to store your settings files — known as
dotfiles (because they’re usually preceeded with a dot, and therefore hidden by default in a POSIX filesystem) in your favourite source control software and keep it synchronised with a remote server.
This means that if you lose your dotfiles for any reason, then you always have a safe backup.
A lot of tools such as
zsh, etc. all use dotfiles for configuration, so it’s a good idea to keep your dotfiles under source control.
Note that if you use IDEs or tools with proprietrary methods of configuration, then you will have to find an alternate way to keep settings synchronised. Some do it automatically over the cloud, but others have specific files with specific formats that you will have to figure out how to keep synchronised yourself. This is primarily the reason that I strive to use tools that are configured with dotfiles, as they are easier to manage, install and are generally more portable.
There is one issue with just keeping your dotfiles under source control however, and that is the fact that the dotfiles have to be symlinked or copied over to the user’s home directory manually. This can be a bit repetitive, especially if you have a lot of dotfiles, therefore because we’re programmers and strive to reduce repetition, what we really need is a method of managing our dotfiles.
If you’ve read up until this point and started thinking about writing a custom script to do the management of your dotfiles for you, I urge you to consider other options unless you have a very good reason.
There are great dotfile management tools out there that do symbolic linking, copying, and so much more that are battle-tested by the open-source community and most likely more flexible than a custom script.
Here are a few; give them a gander, and see which one works best with your workflow.
I recommend reading up on these tools, and looking at the source code to see how they work. It gives you a better understanding of the tools you are using, allowing you to make the most out of it.
rcup is the tool that links (or copies, if you give it the
-C flag) dotfiles to their appropriate location.
The algorithm it uses is very straightforward:
Any non-dot non-meta file or directory under your dotfiles directory will be installed as a dotfile. For example, .dotfiles/zshrc will be installed into ~/.zshrc .
This means that if, for example, you keep your dotfiles repository in a
~/.dotfiles directory, and you have a
~/.dotfiles/vimrc file — running
~/.dotfiles will symlink (or copy, depending on the parameters given)
Assuming you use the default parameters of rcup and the files were symlinked, it means any changes made to
~/.vimrc will reflect in
~/.dotfiles/vimrc allowing changes to be consolidated in source control and kept constantly backed up (as long as you remember to
git push often).
rcup is a very useful tool, and it can be configured to suit your needs.
man rcup gives more information on which parameters the tool accepts.
Combine into one step
This means that executing my forked
mac script preps my computer ready for development, all while I grab a ☕️.