Forem: Freddie Carthy

Use Git and Bash to Automate Your Developer Tooling

Freddie Carthy — Mon, 28 Dec 2020 21:21:49 +0000

If you followed part one of this series you should now have a simple repo with your dotfiles and an install script you can run from any machine, even if you don't have Git installed locally. However this is fairly limited. When starting from zero on a new machine there's a plethora of tooling you'll typically want to install; things like Git, Yarn, npm, Homebrew, etc. Additionally you'll have to set up your Git authorship. Let's expand our simple install script so that it handles all of our tooling!

I've set up a sample repo here if you just want to get going.

1. Install Your Basic Package Managers

This script assumes you're using a Mac and that you've gone through the first part of the tutorial. Much like in part one of this tutorial where we added a list of files we want to take with us from system to system, we'll add a list of our preferred tooling we carry with us wherever we go. In this section we'll have our install script install Git, Homebrew, and npm.

First, let's write a function that will install Homebrew. We'll subsequently use it to install Git:

# /install
install_homebrew() {
  _process "→ Installing Homebrew"
  /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

  _process "→ Running brew doctor"
  brew doctor
  [[ $? ]] \
  && _success "Installed Homebrew"
}

Here we define a function called install_homebrew which will install Homebrew from their repository in much the same way we're setting up our install script here. It will also run brew doctor to ensure everything is going smoothly (docs).

Alright, now let's write a simple function to install npm using Homebrew:

# /install
install_node() {
  if ! type -P 'npm' &> /dev/null; then
    _process "→ Installing node"

    curl https://www.npmjs.org/install.sh | sh

    [[ $? ]] \
    && _success "Installed npm"
  fi
}

Now we'll run both of these functions in our install function at the bottom of the file. The function should now look like this:

# /install
install() {
  download_dotfiles
  link_dotfiles
  install_homebrew
  install_node
}

2. Install Your Tooling

OK, we've got a great little script here that will link our dotfiles and install our package managers. At this point you've got a pretty great setup ready for you to use and install the tools you use every day. However we can also have this script do a lot of that for us for tools we use regardless of the system we're using. Now that we've got these package managers installed this should be straightforward.

Create another file in your /opt folder called homebrew. In here list out all Homebrew packages you wish to install in any given computer, like so:

# /opt/homebrew
eslint
fzf
ripgrep
git
n
yarn
vim

This is how things should look now:

/dotfiles
  /opt
    files
    homebrew

  /configs
    .gitconfig
    .gitignore
    .bash_profile
    .vimrc

Back in our install script we'll want to write a function that loops through each of these packages and installs them with Homebrew:

# /install
install_formulae() {
  if ! type -P 'brew' &> /dev/null; then
    _error "Homebrew not found"
  else
    _process "→ Installing Homebrew packages"

    # Set variable for list of homebrew formulaes
    brews="${DIR}/opt/homebrew"

    # Update and upgrade all packages
    _process "→ Updating and upgrading Homebrew packages"
    brew update
    brew upgrade

    # Tap some necessary formulae
    brew tap homebrew/cask-versions
    brew tap homebrew/cask-drivers
    brew tap vitorgalvao/tiny-scripts

    # Store IFS within a temp variable
    OIFS=$IFS

    # Set the separator to a carriage return & a new line break
    # read in passed-in file and store as an array
    IFS=$'\r\n' formulae=($(cat "${brews}"))

    # Loop through split list of formulae
    _process "→ Checking status of desired Homebrew formulae"
    for index in ${!formulae[*]}
    do
      # Test whether a Homebrew formula is already installed
      if ! brew list ${formulae[$index]} &> /dev/null; then
        brew install ${formulae[$index]}
      fi
    done

    # Reset IFS back
    IFS=$OIFS

    brew cleanup

    [[ $? ]] && _success "All Homebrew packages installed and updated"
  fi
}

This is pretty well documented, but let's recap. It will first ensure that Homebrew is installed on our system. It sets a variable for our ops/homebrew file with the packages we want. Further down we loop through each line in the file and installs those packages.

And now we'll call this function at the end of our install function:

# /install
install() {
  download_dotfiles
  link_dotfiles
  install_homebrew
  install_node
  install_formulae
}

Since we also have npm installed we could easily set up a file called opt/npm and list any packages available via npm there. We'd then just have to define a function similar to install_formulae, perhaps called install_npm_packages, and have similar logic.

3. Final Touches

We now have all of our tooling installed and ready to use! There's just one more thing we can add to make this truly plug-and-play. We'll want to make sure that Git is ready for use with our email and username. In case you forgot, you have to tell Git who you are in order to start making commits and pushing code! At the top of the install script let's add a couple of additional variables we'll need:

# /install
USER_GIT_AUTHOR_NAME: <your github user name>
USER_GIT_AUTHOR_EMAIL: <your github email>

Let's add another helper function to show us a warning in the event that something goes wrong. Add this near the other helpers we added in part one.

_warning() {
  echo "$(date) WARNING:  $@" >> $LOG
  printf "$(tput setaf 3)⚠ Warning:$(tput sgr0) %s!\n" "$@"
}

Now let's write a function to automatically set your GitHub authorship:

# /install
setup_git_authorship() {
  GIT_AUTHOR_NAME=eval "git config user.name"
  GIT_AUTHOR_EMAIL=eval "git config user.email"

  if [[ ! -z "$GIT_AUTHOR_NAME" ]]; then
    _process "→ Setting up Git author"

    read USER_GIT_AUTHOR_NAME
    if [[ ! -z "$USER_GIT_AUTHOR_NAME" ]]; then
      GIT_AUTHOR_NAME="${USER_GIT_AUTHOR_NAME}"
      $(git config --global user.name "$GIT_AUTHOR_NAME")
    else
      _warning "No Git user name has been set.  Please update manually"
    fi

    read USER_GIT_AUTHOR_EMAIL
    if [[ ! -z "$USER_GIT_AUTHOR_EMAIL" ]]; then
      GIT_AUTHOR_EMAIL="${USER_GIT_AUTHOR_EMAIL}"
      $(git config --global user.email "$GIT_AUTHOR_EMAIL")
    else
      _warning "No Git user email has been set.  Please update manually"
    fi
  else
    _process "→ Git author already set, moving on..."
  fi
}

This is checking for a couple of things. First it checks to see if your global .gitconfig file already has the author name set. If it does there's nothing else to do here. If it isn't set it will use the username and email we defined at the top of the file. If you haven't set those either it gives you a warning that you'll need to add GitHub authorship on your own.

And of course we'll have to call this function after everything else is done:

# /install
install() {
  download_dotfiles
  link_dotfiles
  install_homebrew
  install_node
  install_formulae
  setup_git_authorship
}

That's it! I hope you found this useful. In the next article we'll explore creating an update script that will pull the latest changes to your dotfiles form GitHub, install any new packages, and source your .bash_profile.

If you enjoyed this post, I'd love to hear about it on Twitter!

Getting Actionable Feedback From Your Team

Freddie Carthy — Sun, 27 Dec 2020 21:52:38 +0000

Getting and giving feedback is an incredibly important aspect of being an engineer. More so for an Engineering Manager or any type of lead role where their job is to deliver results and help develop careers.

Most engineers practice some type of feedback loop with their manager. Generally this takes the form of a weekly or bi-weekly check-in. If for some reason you're not already doing this with your team, start doing it now. A regular feedback loop is one of the best ways to keep your engineers happy, on track, level them up, and grow as a manager.

Too often I see check-ins and reviews be wasted away where the meeting ventures toward "so, how you doin'?" territory. This doesn't help anyone. Here I’ll outline a routine I've used to ensure that I get and give feedback on a regular cadence, ensure it is feedback you can both act on, and keep track of the progress over time. OK, let's get to it!

The One-to-One Check-in

So you're a people manager and you've been having regular check-ins with your team. Let me ask you something, what did you discuss with each one of them two months ago? How was their morale? Were they excited about the projects they were working on? Were they making progress toward their career goals? What was their biggest blocker? Were they happy with how you were supporting them? If you can't confidently answer these questions you're doing yourself, your team, and frankly your company, a disservice.

Let's go over a simple routine to solicit actionable feedback, raise red flags to your leadership team as soon as you see them, and ensure that your team feels taken care of.

1. Gathering Feedback

In order for check-ins to be successful both you and the engineer must be prepared. Walking into a meeting with no clue of what you'll talk about is a sure way to waste the meeting time. Create a shared document between you and the engineer where you can both add your thoughts and talking points for the meeting. I've used Google Docs and Confluence for this in the past. Really, anything will work so long as you can make it visible to just the engineer and yourself. List out three to five open-ended questions. Some examples:

What happened over the past 2 weeks that you're happy about?
What happened over the past 2 weeks that you're not so happy about?
How could our team be more effective?
How do you feel about your velocity over the past 2 weeks?
How do you feel about the team's velocity over the past 2 weeks?
How can I better support you?
What questions do you have for me?

Create a bank of 10-20 of these types of questions that fit your needs or specific situation. Every two weeks pick some new ones from the list and put them at the top of the document. Or perhaps pick the same ones to track progress over time on a specific topic.

2. Reinforcement

Set a weekly reminder for each team member to fill out the document. This could be whatever fits your workflow best; multiple calendar alerts on the one-to-one invite, Slack reminders, email, etc.

The goal here is fill out the document with intent and not rush through it. This will ensure the feedback is as complete as possible, and I've found success with reminding the team to fill it out about one week prior to the check-in.

3. The Discussion

When you finally meet with the engineer, guess what? You now have a ton of stuff to discuss. When I first implemented this strategy my check-ins went from 15 minute coffee walks to 45 minute meaningful conversations. Deep dives into how the team could collaborate better, projects the team wanted to experiment with, or resources I never knew they needed. I was amazed at the level of detail in the feedback I was able to get. This document is also now a historical record for both of you and can be used to inform your six month and yearly reviews.

You can also add an "action items" section to the document (in Confluence these could create Jira tickets) where either you or the engineer can add things to tackle over the next two weeks. When you meet again you can review these items.

This is just one way of soliciting meaningful feedback from your team. Have you tried any other routines? What has worked well for you?

If you enjoyed this post, I'd love to hear about it on Twitter!

Make Your dotfiles Portable With Git and a Simple Bash Script

Freddie Carthy — Wed, 23 Dec 2020 04:46:48 +0000

Are you getting the most out of your dotfiles? Time and again I see engineers under-utilizing the power of their dotfiles. They either don't maintain a version-controlled set of dotfiles, or they do but they haven't been touched in years. This can lead to a fragmented developer environment between your personal and work computer. Wouldn't it be cool if you could have a one-line install for your dotfiles and a single command to keep them up-to-date between systems?

My dotfiles are like my digital identity. They serve two primary purposes; they hold all of my settings and I use them to install all of my tooling. This keeps my work and personal computer 100% synced.

At minimum there's a handful of files that I like to share across systems. These include files like .gitignore, .gitconfig, bash aliases, .bash_profile, .vimrc, and a number of others.

There's also several tools that I always use regardless of the system I'm working on; Git, Vim, yarn, npm, and Homebrew to name a few.

In this series I'll show you how to supercharge your dotfiles to keep them synced across your machines effortlessly.

1. Setting things up.

This script assumes you're using a Mac. First things first you'll need to setup a repo on GitHub (or preferred location) for your dotfiles.

I've set up a sample repo here if you just want to get going.

Clone the repo and cd into it. Create a folder called /opt, and in there a file called files (in the future this folder will also hold a list of tools you use). In that file paste the following (add any dotfiles relevant to you):

# /opt/files
configs/.gitconfig    .gitconfig
configs/.gitignore    .gitignore
configs/.bash_profile .bash_profile
configs/.vimrc        .vimrc

This list will tell our future install script to look for the files listed on the left and create symlinks in our home directory with the names on the right. We haven't setup the /configs folder to hold our dotfiles quite yet, so let's do that next!

Create a /configs folder at the root of the project. This folder is what will hold all of our dotfiles (as listed above). Think of these files as the "source of truth" for each of your dotfiles. For each of the files you can paste in the contents of your current dotfiles to get started. Make a commit and push this baby up! This is how things should look like now:

/dotfiles
  /opt
    files
  /configs
    .gitconfig
    .gitignore
    .bash_profile
    .vimrc

OK, moving on...

2. Creating a simple install script

Now we've got our dotfiles in our /configs folder and pushed to GitHub. Pretty great! But what we really want to do is have an easy way to download these dotfiles onto a new system without even having Git installed.

Create a file called install at the root of the project. We'll need this script to do a couple of things for us:

Download the repo and set itself up in the /usr/local/opt directory. This is because we'll keep our local copy of the cloned repo where we make changes separate from the set of files your machine will use as the "source of truth".
Symlink our dotfiles in that directory from our home directory.

At the top of the file let's set up a few variables for easy use in our functions:

# /install
#!/usr/bin/env bash
LOG="${HOME}/Library/Logs/dotfiles.log"
GITHUB_USER=your github user name here
GITHUB_REPO=<your github repo name
DIR="/usr/local/opt/${GITHUB_REPO}"

Setting the LOG location to this will ensure that all logs are visible in the macOS Console app. Handy if something goes wrong and you need to check the logs. Make sure to set GITHUB_USER to your username and GITHUB_REPO to whatever you're calling your dotfiles repo. Let's also set up a couple of helper functions that will print out some fancy output as our script runs.

# /install
_process() {
  echo "$(date) PROCESSING:  $@" >> $LOG
  printf "$(tput setaf 6) %s...$(tput sgr0)\n" "$@"
}

_success() {
  local message=$1
  printf "%s✓ Success:%s\n" "$(tput setaf 2)" "$(tput sgr0) $message"
}

OK, so now we get to the fun part. Let's write a function that downloads our dotfiles repo so we can use it locally.

# /install
download_dotfiles() {
  _process "→ Creating directory at ${DIR} and setting permissions"
  mkdir -p "${DIR}"

  _process "→ Downloading repository to /tmp directory"
  curl -#fLo /tmp/${GITHUB_REPO}.tar.gz "https://github.com/${GITHUB_USER}/${GITHUB_REPO}/tarball/main"

  _process "→ Extracting files to ${DIR}"
  tar -zxf /tmp/${GITHUB_REPO}.tar.gz --strip-components 1 -C "${DIR}"

  _process "→ Removing tarball from /tmp directory"
  rm -rf /tmp/${GITHUB_REPO}.tar.gz

  [[ $? ]] && _success "${DIR} created, repository downloaded and extracted"

  # Change to the dotfiles directory
  cd "${DIR}"
}

What this is doing is creating a /dotfiles directory at DIR, downloading a tarball of your latest main branch, extracting the file, cleaning up, and finally changing your working directory to /usr/local/opt/dotfiles.

Now that we've downloaded your dotfiles we need a basic function to grab your dotfiles from the /configs folder and create symlinks to them in your home directory. Here it is:

# /install
link_dotfiles() {
  # symlink files to the HOME directory.
  if [[ -f "${DIR}/opt/files" ]]; then
    _process "→ Symlinking dotfiles in /configs"

    # Set variable for list of files
    files="${DIR}/opt/files"

    # Store IFS separator within a temp variable
    OIFS=$IFS
    # Set the separator to a carriage return & a new line break
    # read in passed-in file and store as an array
    IFS=$'\r\n'
    links=($(cat "${files}"))

    # Loop through array of files
    for index in ${!links[*]}
    do
      for link in ${links[$index]}
      do
        _process "→ Linking ${links[$index]}"
        # set IFS back to space to split string on
        IFS=$' '
        # create an array of line items
        file=(${links[$index]})
        # Create symbolic link
        ln -fs "${DIR}/${file[0]}" "${HOME}/${file[1]}"
      done
      # set separater back to carriage return & new line break
      IFS=$'\r\n'
    done

    # Reset IFS back
    IFS=$OIFS

    source "${HOME}/.bash_profile"

    [[ $? ]] && _success "All files have been copied"
  fi
}

Looks a bit complex, but what's happening here is actually quite simple. It looks at the /opt/files file we created, which lists each of your dotfiles, and loops through each line. It then creates a symlink in your home directory for each of those pointing to the files in your /usr/local/opt/<repo name>/configs folder.

3. Putting it all together

Finally, we need to actually run these functions for things to actually happen. Here's how I like to do that:

# /install
install() {
  download_dotfiles
  link_dotfiles
}

install

Place that snippet at the bottom of your install file and you're ready to go. Keep in mind that running this script will replace any dotfiles you've listed in your files file!

Now, running the following command in your terminal will execute our script:

$ bash -c "$(curl -#fL raw.githubusercontent.com/<your github username>/<your dotfiles repo name>/main/install)"

In the next installments 😂 we'll expand on this by having it install our tooling as well as setting up an update script.

If you enjoyed this post, I'd love to hear about it on Twitter!