When I started working at Spotify, I had never used the command line or git before. I won’t lie; I was a little afraid of the command line, with its black background and walls of text. But it quickly became clear that I would have to learn to work with it. Every developer had their own VPS to work on and mounting it over ssh was kinda crappy cause the network was pretty shaky at times.
Everyone (bar a few, perhaps) seemed to be using either vim or emacs for their day-to-day work. Walking around the office, looking at people’s screens, you could see them all being immersed in their work, coding across multiple splits, switching between them with a few keystrokes; it seemed highly efficient, to say the least!
At this point I decided I would have to change my ways; I used to change editors on a pretty regular basis, always pouncing on the new ones as they popped up, mainly cause I had not yet found an editor I was truly comfortable with.
It was time I started using vim.
I figured the best approach would be to just dive in, cold turkey, and use nothing except vim from then on. I approached a colleague and asked if I could copy his vim config – since vim isn’t exactly known for being the most user-friendly editor out of the box – and off I popped!
I’m not gonna lie – it was painful. I barely got any work done that first week; my fingers and mind just couldn’t seem to get used to the different modes and commands.
To illustrate: there’s a variety of ways to enter insert mode; it took a while before I fully realised the subtle differences between them and when each of them is the most efficient choice.
Nowadays, I love the command line. I love git. I love vim. This is all because of the stuff I learnt at Spotify and all the things that I’ve learnt since.
From the moment I copied my colleague’s vim config, I realised the importance of configuring my tools properly. From then on, I strived to get the most out of the tools I used and that it’s never a waste of time to research this kinda stuff.
So, what am I trying to say with this little story?
It’s important to configure your tools, making sure you’re working in an environment where you feel both comfortable and confident. That’s why I am writing this article – to hopefully help others out the same way my ex-colleagues have helped me.
Initially I was planning to just make a single article about all this, but as I was writing it, it became quite long, so I’ve decided to instead split this up into four articles each focussing on its own topic.
This is the first article in the series, where I’ll take you through the basics of creating your dotfiles home and linking it with a repository. The rest of the articles will each cover one of the following topics: bash, git and vim.
By the end of the series, you should have the following:
- A useful bash prompt, including display of git branch
- Some useful aliases for bash and git
- Some basic configuration to make vim less terrible
Make my own dotfiles? Effort…
The “annoying” thing about dotfiles, is that they are personal. No two people are alike and the same can be said for one’s preferences. Because of this, maintaining your own dotfiles makes sure you remain in full control of your setup and keeps it free of cruft you don’t need.
That doesn’t mean it’s a bad thing to look at other people’s configurations and steal the bits that you like, that’s what I do too, but copying them over into your own dotfiles will allow you to modify things easily and exactly to your liking.
There’s quite a large community around dotfiles; a lot of developers on github have their very own dotfiles repo – these are ideal for finding interesting bits of code that will make your life easier. On top of that, there’s dotfiles.github.io which has a list of popular bootstraps and frameworks to help you on your way to greatness!
My dotfiles can be found here.
Let’s dive in
So, now that you know why you should create your own dotfiles, let’s get started. First off you’ll need a central repo to store your config. In this series we’ll be using github since that’s what I’m familiar with, but I’m sure that bitbucket is also well up to the task.
First off, you’ll want to make a new repository on github. I’d suggest just naming it “dotfiles”, without any gitignore or license, but that’s ultimately up to you.
Then, create a
.dotfiles directory in your home directory where you’ll keep
the actual files. Once they’re stored in there, we’ll create symbolic links to
the required files so they are where the operating system expects them. You can
create the directory by typing:
$ mkdir ~/.dotfiles
Then, to finish things off go into the directory, make it into a git repo and set the appropriate remote:
$ cd ~/.dotfiles $ git init $ git remote add origin firstname.lastname@example.org:chielkunkels/dotfiles.git
Of course you’ll want to replace
chielkunkels with your own name.
To finish off today’s article, we’ll create our .bashrc file and link to it from our home directory.
$ touch ~/.dotfiles/.bashrc $ cd $ ln -s .dotfiles/.bashrc
Depending on your operating system you’ll also need to include the bashrc file
Some OS’ come with a
~/.profile in place which looks for the
sources it if found; if that’s not the case, put the following in your
~/.bash_profile (create it, if necessary):
To finish things off, let’s push these changes to our repository:
$ git push -u origin master
Wondering what the
-u stands for? It sets the upstream of your local branch.
In layman’s terms this means telling git which branch on the remote you would
like to synchronise with.
Not doing this would mean that if you want to
git push, you would always have
to specify which remote + branch you would want to push to (the
in the command above). Using the
-u flag on your first push means that you can
git push without any arguments from then on.
Well then - you’ve just taken your first steps in maintaining your very own dotfiles. Feels good, doesn’t it? But it doesn’t stop here! In the next article in the series, we’ll go about the basic configuration of your bash prompt.
Thanks for reading and until next time.
:e: The next article in the series is out, covering more in-depth
configuration. Check it out here.