Want to get more articles like this one? Join my newsletter

How I setup my 2016 MacBook Pro

So this is another article that I’m doing for myself and also to be transparent. I don’t change my computer often (My old computer was a mid-2011 MacBook Air!) and I usually use the opportunity to review my workflow. This time around I wanted to document the process in some way.

The initial plan was to do something like this. That said, a few people told me that it would be something useful to write down. So this is what this article is going to be about.

Since everything is still quite fresh, I can walk through my thought process. I think it’s useful when you’re trying to make decisions whether this tool is useful for you or not. We don’t all work the same way so my workflow might not fit yours.

It’s also worth pointing out that this is going to be macOS centric. I haven’t developed on another operating system in a long time. So you might not get as much out of this if you’re using Windows or Linux.

Alright, so you have your new MacBook Pro box in front of you! You’re ready to get going. You unbox it, boot it up, set up your account for the first time and get to the desktop screen. What’s next!?

Run software updates

You heard that right. Running system updates is the first thing that I do. (How boring!) I click that Apple icon in the upper left and go to Software Update. This takes a little while, but it’ll be out of the way.

System preferences

After I’m done with software updates (or while they’re running), I tend to take care of the other boring stuff as well. This means opening System Preferences and going through all the options. I change them to match my personal preferences.

Keyboard layout

My most important preference change is the keyboard layout. I use the Canadian French one. I know that I’m more of an anglophone now, but I’ve been typing on that layout since I’m a kid. Apple doesn’t support that layout by default so I install a custom made one from GitHub. (I’m not interested in learning a new layout.)

Distraction-free workspace

The rest of my preferences focus on configuring my workspace. What defines my workspace is that almost every application that I use is full screen. I do this to reduce distractions as much as possible. (If you haven’t met me, I’m pretty hyperactive. This helps me a lot.)

Mission control

I also don’t use external monitors. Instead, I rely on mission control to give each application a dedicated space. I’ve been using six spaces for the last few years. In order, they contain:

  1. Communication applications
  2. Specialized applications (e.g. Sequel Pro)
  3. Text editor
  4. Browser
  5. IDE
  6. Terminal

I navigate between each space using trackpad gestures. For this to work well, I need to disable auto rearranging of spaces so that everything stays in order. I find this quicker than turning my head to look at an external monitor. Another bonus is that I can use this when I’m not working from home. (This happens a lot.)


I also configure my dock so it distracts me as little as possible. I do the obvious stuff like shrink it and hide it. I also disable badges on most applications.

A more interesting decision is moving the dock to the right. I can’t remember what prompted me to do it. But I like it a lot now.

That’s because it removes a subtle source of distraction. If you didn’t know, macOS doesn’t do a perfect application window fullscreen. There’s always a small gap to show where the dock is. Noticing the gap often made me look at the dock.

If I put my dock to the left, I’m more likely to notice it since a lot of applications are left heavy. (Navigation and such are always on the left.) We’re also used to looking from left to right since we read from left to right. So, by moving it to the right, I reduce the chance that I’ll notice the gap and open my dock.

Installing homebrew

Homebrew is a (if not the) package manager for macOS. I use it to install most of the tools and applications that I use every day. Without it, it would be a lot more complicated and time-consuming to set all this up.

Installing homebrew is pretty easy. You only need to run the command below. This will run you through the installation process.

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

That said, we’re not done after doing this. Homebrew also needs Xcode (Apple’s official IDE) to work. You can install it by running this command:

$ xcode-select --install

Xcode takes quite a bit of time to download and install. Once installed, I do a final check to see that everything is ok. Homebrew has a handy diagnostic command that you can use to do this.

$ brew doctor

If there are any issues, I fix them right away. But, before we proceed, I want to go over these two homebrew commands:

$ brew install 
$ brew cask install 

I’ll be using these commands a lot to install packages and applications. brew install is the main command for installing anything with homebrew. brew cask install is a special command that lets us install macOS applications like Chrome.


Now that we’ve taken care of all the housekeeping stuff, we can move on to more interesting stuff! I spend a lot of time in terminal because I do a lot of sysadmin work. So that’s the next thing that I setup and configure.

This is what my terminal looks like after I’m done setting it up. This guide helped me set it up the first time. I’m still going to go through it and explain some of the things that I like about the setup.


The first thing worth noting is that I don’t use the default macOS terminal application. Instead, I use iTerm2. I install it using homebrew:

$ brew cask install iterm2

For most developers, there isn’t much of a reason to switch. The main feature that I need from iTerm2 is split panes. I find it more useful than using screen for sysadmin work.

I also change the default terminal colours. I’m a big fan of the solarized colour palette. iTerm2 doesn’t come with a solarized colour palette so I install one. (This is going to be a recurring configuration change with a lot of my applications.)


I also don’t use bash as my command line shell. I replaced it with zsh. I install it (via homebrew) with some extra autocompletion definitions:

$ brew install zsh zsh-completions

Oh My Zsh

Oh My Zsh is a bundle of functions, plugins and themes for zsh. It’s the reason why I use zsh instead of bash. It turns your shell into a tool that feels like it’s working with you instead of against you.

In fact, it’s pretty hard to go back after you’ve used it for a while. That’s why it’s one of the first things that I install. I do it by running this command:

$ sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

Powerline theme

Once installed, I install the powerline9k theme. I like the theme a lot because it gives me a lot of useful information at a glance. It’s not available by default so you have to clone it from the GitHub repository:

$ git clone https://github.com/bhilburn/powerlevel9k.git ~/.oh-my-zsh/custom/themes/powerlevel9k

The theme uses powerline which is status line plugin for vim. It also works with zsh which is why the theme uses it. (I don’t use vim. gasp) It’s what allows it to show us git repository details next to the directory indicator.

You also have to download a powerline font for the theme to work. I’m using one called Meslo. You can download it here.

Configuring zsh

At this point, I’ve installed everything that I need to use zsh. The only thing left to do is to configure it. To do that, I edit the ~/.zshrc configuration file.


The ZSH_THEME variable controls the theme that zsh will use. I change it to powerlevel9k/powerlevel9k. This enables the powerline theme that I just installed.


Next, I uncomment the DEFAULT_USER variable. I change it to my username. This removes user@hostname in the terminal prompt. (It takes a lot of space!)

The last step of the configuration process is choosing which Oh My Zsh plugins you want zsh to load. By default, Oh My Zsh only enables the git plugin. Here are the ones that I use right now:

plugins=(git brew colored-man-pages composer npm pip symfony2 wp-cli)

There isn’t anything too special in that list. Most of those plugins offer autocompletion and aliases for CLI tools that I use on a regular basis. I haven’t found other plugins that I needed besides those.


Once I’m done configuring my terminal, I move on to security. This is often a neglected thing by developers. (That includes yours truly.) I’m trying to be better about it and privacy, but it’s an uphill battle. (This page gives you a sense of the magnitude of the endeavour.)

Password Manager

These days, it’s hard to go a week without hearing about a password leak. I think that it’s just flat out irresponsible to not use a password manager at this point. So I have to install mine before I start needing passwords. (Which is pretty much right away.)

$ brew cask install 1password

I use 1password, but you can also use LastPass or KeePassX. (This last one is free and open sourced.) You can install all three of those with homebrew.

Two-factor authentication

You should also have two-factor authentication enabled if a service supports it. I use Authy to handle the two-factor verification whenever I can. You can’t install using command line (boo!) so I do it by hand.


I also install an anti-virus even on my mac. It’s a myth that Macs don’t get any viruses. It’s just not as common of an occurrence.

$ brew cask install avast

I started by installing Avast because I saw it recommended the most. But Avast wasn’t a good option for me. It slowed my internet connection to a crawl after I installed it.

I tried to fix it using their FAQ. I never got it to work without disabling web shield. After a while, I just got tired of the whole thing and uninstalled Avast.

$ brew cask uninstall avast
$ brew cask install avira-antivirus

I gave Avira a try next. That’s the one recommended in the Mac setup guide that I based this article on. It doesn’t slow my internet to a crawl so I’ve been using it instead of Avast.


My computer is also connected to a VPN at all times. It’s worth noting that a VPN doesn’t make you anonymous on the internet. That said, it’s still a good privacy practice to use one. (More privacy never hurt anymore!)

$ brew cask install windscribe

Right now, I’m using Windscribe as my VPN provider. (Someone recommended it to me.) It seems good so far. It doesn’t impact my internet latency in a noticeable way on my MacBook. But I’ve had issues with iOS where some apps don’t work with it on.

I should also point out that Windscribe is a Canadian VPN provider. This means that it’s operating in one of the five eyes countries. If you’re worried about this, you should look into another VPN provider. (You can find some suggestions here.)


If you’re a developer, you should be using SSH for some of the things that you do. For me, none of my servers uses password authentication so I need SSH for that. This means that I need an SSH key on my computer.

I wasn’t happy with how I stored my last SSH key. (I left it on Dropbox unencrypted.) So I decided to generate a new SSH key instead of using my old one. Generating an SSH key is pretty simple. You can just run this command from the GitHub guide:

$ ssh-keygen -t rsa -b 4096 -C "my_email@example.com"

The process will ask you to enter a passphrase for your SSH key. You should add a passphrase to your SSH key. This makes it more secure in case it falls into someone else’s hands.

Now, the default behaviour with SSH is to ask you for this passphrase every time you use your SSH key. That’s not something that I want to do when I’m using a strong password. That’s why I use ssh-agent.

This came installed on macOS Sierra, but you still need to configure SSH to use ssh-agent. This process has changed since macOS 10.2.2. For ssh-agent to take over, you need to edit your ~/.ssh/config file:

Host *
  AddKeysToAgent yes
  UseKeychain yes
  ServerAliveInterval 60

AddKeysToAgent tells SSH to use ssh-agent for all SSH keys. UseKeychain gives permission to macOS to store all passphrases in Keychain. ServerAliveInterval is a setting that I use to help prevent my SSH connections from timing out. This isn’t a problem if you don’t work on servers much.


Once I’m done configuring SSH, I proceed with installing and configuring git. This is the preferred version control system for web developers. By default, it comes already installed on macOS. But I want it managed by homebrew so I install it again:

$ brew install git

Once homebrew finishes installing git, I run the following command:

$ which git

I want to see /usr/local/bin/git as the output for which git. This means that the default git executable is now the one managed by homebrew. If I don’t get this output, it means that /usr/local/bin is missing from my PATH variable. I add it by editing the /etc/paths file and putting /usr/local/bin at the top of it.

Global configuration

Next, I want to tweak my git global configuration. I start with the standard name and email. This is a useful step if you want to use Bitbucket, GitHub or GitLab. (Those are the three primary git repository hosting services.)

$ git config --global user.name "Carl Alexander"
$ git config --global user.email "my_email@example.com"

I also want to create a global ignore file. This lets me define files and directories that I want to ignore for all my projects. To do that, I follow this guide from GitHub.

$ vi ~/.gitignore_global

I start by creating a .gitignore_global file in my home directory. I put the following in it:

# compiled source #

# Packages #
# it's better to unpack these files and commit the raw source
# git has its own built in compression methods

# Logs and databases #

# OS generated files #

# IDE files #

This is a modified version of this gist. I added the IDE section at the end which contains IDE and text editor files and directories. You should never commit those to a project.

Once I saved my .gitignore_global file, I added to the git global exclude files. I do it by running this command:

$ git config --global core.excludesfile ~/.gitignore_global

Desktop client

I tend to use git with a desktop client when I’m working on my computer. (I use the standard git CLI when I’m working on a server.) I was using Tower on my old MacBook Air, but I decided I wanted to try a new desktop client.

$ brew cask install gitkraken

The first one that I tried was GitKraken. I had heard great things about it. That said, it didn’t end up being a good desktop client for me. It focuses too much on git flow which I don’t use much.

$ brew cask uninstall gitkraken
$ brew cask install sourcetree

The next one that I tried was SourceTree. As of right now, I’m still using it. I had tried it a long time ago and hadn’t liked it. But it’s improved a lot since then.

If you’re already using Tower, SourceTree won’t be a big change for you. It’s pretty much like Tower. So why do I keep using it?

I started GPG signing most of my commits last year. Right now, SourceTree is the only desktop client that supports commit signing. I had to do it by hand with Tower before.

GPG signing

This is as good a time as any to talk about generating a proper GPG key. Have you ever looked into it? No? (I admit this was more of a rhetorical question lol) Well, it’s a special kind of hell.

They recommend that you use an offline machine to generate a master key. You then use that master key to generate subkeys for each of your computers. You also need to create revocation certificates in case your master key gets lost or stolen.

Let’s just say I wasn’t down for that much work to sign my git commits. Lucky for me (and you!), there’s keybase.io. It’s a service that reduces the complexity of generating GPG keys. You can install it with homebrew:

$ brew cask install keybase

If you’re interested in using keybase with GitHub, you can look at this handy little guide. It’ll walk you through the steps of setting everything up. It’s pretty painless overall.

Since I’d already gone through the setup before, the process was a bit different for me. I just needed to log into keybase and add the new MacBook as a device. Once I’d done that, I could import my keys.

$ keybase login
$ keybase device add
$ keybase pgp export | gpg --import
$ keybase pgp export --secret | gpg --allow-secret-key-import --import


Of course, you can’t develop for the web without a browser. My main browser is Chrome. I think it has the best developer tools of the three major browsers.

$ brew cask install chrome
$ brew cask install firefox

This doesn’t prevent me from installing Firefox anyways. I use it and Safari for browser testing. If there’s an issue with Chrome, I’ll also fall back on one of the two. (I don’t have a particular preference between the two.)


Extensions are also another reason why I love Chrome so much. I’m careful to not go overboard with them. (Chrome can take a lot of memory already without extensions taking more.) But I still have to use some. So here they are in alphabetical order:

  • 1password integrates with 1password to fill and record passwords used in Chrome.
  • Accessibility Developer Tools is a must-have tool if you do any work with accessibility.
  • AdBlock shouldn’t need any explanations.
  • Go Fucking Work is what I use to block sites like Reddit or Facebook so that I don’t get distracted.
  • Grammarly is also a must-have extension if you do any writing. (It’s also available for Firefox and Safari if you use those.)
  • HTTPS Everywhere ensures that you’re always using HTTPS whenever possible.
  • Toby is a tab manager with cloud syncing.
  • Xdebug helper lets me use Xdebug from Chrome. (More on Xdebug later!)
  • Windscribe is an extension that leverages Windscribe’s VPN connection to add extra privacy at the browser level.

Developer tools

So at this point, I’m pretty much ready to install all the developer tools that I use. As you’ll see, there’s nothing too surprising in there.

Sublime Text

For some, Sublime Text is all they’ll ever need. It’s a powerful text editor like vim, emacs and atom. There are also plugins for it that let you customize it further.

$ brew cask install sublime-text
$ ln -s /Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl /usr/local/bin/subl

As with most applications, I install Sublime Text using homebrew. I also symlink the Sublime Text binary to /usr/local/bin. This lets me open files in it via command line like this:

$ subl /path/to/file_or_dir

It’s not uncommon for people to use plugins to transform Sublime Text into an IDE. I don’t use it that way. (I find there are still things an IDE is better for.) For me, it’s just a simple text editor.

That said, I still do a few changes to it. Sublime Text also supports themes so I change that. I’ve been using the Material Theme for a while now. I haven’t found one that I like better. (And it’s solarized!)

I also change some of the default preferences. Here’s what they look like:

    "color_scheme": "Packages/Material Theme/schemes/Material-Theme.tmTheme",
    "theme": "Material-Theme.sublime-theme",
    "default_line_ending": "unix",
    "ensure_newline_at_eof_on_save": true,
    "shift_tab_unindent": true,
    "tab_size": 4,
    "translate_tabs_to_spaces": true,
    "trim_trailing_white_space_on_save": true,

Yes, you read that right. I’m dirty spaces guy. (Get the pitchforks!) So I want translate_tabs_to_spaces to be true and I set my tab_size to 4. ensure_newline_at_eof_on_save and trim_trailing_white_space_on_save are both there to enforce the PSR-2 coding standards.

Once everything is good in Sublime Text, I go back to terminal to make some changes to git. I want to configure Sublime Text as a git merge tool. I do it by running these commands:

$ git config --global mergetool.sublime.cmd "subl -w \$MERGED"
$ git config --global mergetool.sublime.trustExitCode false 
$ git config --global merge.tool sublime
$ git mergetool -y


My IDE for the last few years has been PhpStorm. Before that, I was using NetBeans. NetBeans is an open source Java IDE, but they also have a modified version of it for PHP that’s quite good.

I can’t remember what made me switch at the time. That said, I’m still super satisfied with it. (I haven’t looked at other IDEs since I switched.) They have all the features that I want out of an IDE including WordPress integration. It also integrates a lot of the PHP tools that I use on a regular basis. (More on those later when I go over my PHP environment!)

$ brew cask install phpstorm

Even though PhpStorm isn’t free, you can still install it with homebrew. It has a free trial if you want to check it out.

That said, you might not want to pay for an IDE. That’s fine too! If I was looking for a free IDE today, I would look at Visual Studio Code before going back to NetBeans.


The most important change to my IDE is the colour palette. This is another application where I use a solarized theme. (Who would have guessed!?) Mine is a customized version of this intellij solarized colorscheme.

This is what it looks like at the moment. There are too many changes to go over each of them. But, if you’d like to try it out, I’ve uploaded a copy here. (The theme is Solarized Dark (New Carl). Don’t judge my naming!)

PHP Tools

PhpStorm also integrates with a lot of PHP tools. I want to add those in before I move on. This also means that I need to install PHP.

$ brew tap homebrew/php
$ brew install homebrew/php/php70

I was using PHP 5.4 on my old MacBook Air so that I could stay close to the WordPress minimum version. But I decided that, for this computer, I’d start with PHP 7.0 and work my way down if I needed it. That’s why I chose this PHP version.


$ brew install composer

The first tool that I install after installing PHP is composer. If you don’t know what composer is, it’s a dependency manager for PHP. It lets you manage external libraries that your PHP project needs.

It’s pretty much the most important change to the PHP ecosystem in the last decade. You won’t see it used as much in the WordPress world. That said, it’s a mandatory tool if you do any PHP work outside the WordPress world.


$ brew install wp-cli

WP-CLI is the WordPress command line tool. It lets you perform a wide range of operations on your WordPress site without having to use a browser. It’s a bit like the composer of the WordPress ecosystem.

Now, if you weren’t using WP-CLI already, it might not be worth it for you to install. I find that it can be handy in a lot of situations. (It’s indispensable for me when I’m working on a server.) But the reality is that it depends on you using it in your workflow. If you don’t think you’ll use it, you don’t have to install it.


$ brew install phpunit

PHPUnit is another important PHP tool. It’s the preferred PHP unit testing library. WordPress uses it for its own unit tests. I use it for unit testing regular PHP projects as well as WordPress plugins.

Coding standards

$ brew install php-code-sniffer
$ brew install php-cs-fixer

I use these last two tools to detect and fix coding standard issues in my code. PHP code sniffer is a tool that detects coding standard violations. You can customize it for any coding standards that you want including the WordPress ones.

PHP code sniffer can also fix coding standard errors in your code. That said, I tend to use PHP coding standard fixer instead. It’s a pretty handy tool, but it only fixes PSR-1 and PSR-2 issues. It won’t be that useful for you if the majority of your work is with WordPress.

Specialized applications

I also use a few (well, two) specialized applications that are worth mentioning. One is Sequel Pro. The other is Paw.

$ brew cask install sequel-pro

Sequel Pro shouldn’t need an introduction. (It’s pretty much the best thing about working with MySQL.) It’s a free open source MySQL database management application for macOS. If you work with MySQL databases and are on macOS, you should consider trying it out.

As for me, I use Sequel Pro for all my database administration tasks. It doesn’t matter if it’s a local database or a remote one. I don’t ever use phpMyAdmin. (I don’t even think you should install it on a server, but that’s another discussion!)

$ brew cask install paw

Unlike Sequel Pro, it’s possible that you haven’t heard of Paw. Paw is an HTTP client for macOS who’s primary purpose is to help you work with APIs. Now, that the WordPress REST API content endpoints are in core, using a REST API tool is more important than ever.

You can use Paw to test API calls to the custom WordPress REST API endpoint that you’re building. Or you can use it to check what’s returned by an existing WordPress REST API endpoint. It’s also useful if you’re developing code that makes use of another API.

The only thing about Paw is that it’s not free. (It also has a 30 day trial like PhpStorm.) It’s worth the investment if you work with APIs a lot. That said, if you don’t work with them a lot or you’re looking for something free, you should check out Postman. It’s a great alternative.

Development environment

At this point, I have everything I need to write code or work with a MySQL database. That said, I still have no development environment that I can test my code against. Keeping this for last was an intentional decision on my part.

Why? Well, my old development environment was a simple LEMP stack (Linux, Nginx, MySQL and PHP) that I managed by hand. It wasn’t bad, but it felt a bit dated compared to newer setups like VVV.

Temporary solution needed

My initial plan was to develop a virtualized development environment using Docker. I was (and maybe still am) determined to build one even if containers aren’t virtual machines. That said, it wasn’t ready for use and I needed a development environment to work.

So I had to pick something temporary to use until then. The options that I kept hearing were local (a Docker-based solution), MAMP, VVV, Valet or the built-in PHP web server. I could also go back to my old manual setup until I got my Docker virtual machine working.


$ composer global require laravel/valet
$ valet install

I decided to give Valet a try first. It felt like the one with the least overhead. It’s pretty much a small PHP app on top of nginx.

Falling for Valet

So how did it do? Well… it was love at first sight! Working with Valet has been so smooth and painless that I’m thinking I won’t bother with a virtual machine at all. That’s how much I’m loving it.

But what’s so great about it? It’s been a common question since I’ve proclaimed my love for valet. I think it’s because it has just the right blend of minimalism for me.

Virtualized development environments like VVV are heavy and resource intensive. Virtual box is a resource hog unless you spend time tuning it. It’s the main reason why I resisted using a virtual machine for so long.

That said, virtualized development environments also have their benefits. They offer a consistent development environment that hundreds of developers use. You don’t have to worry about installing and configuring anything. It’s all done for you.

My old way of managing my development environment was a lot simpler and less resource heavy. But I had to do everything by hand. It also didn’t have some of the nifty tools that came with a virtualized development environment.

Best of both worlds

For me, valet combines what I liked the most about both types of setup. It’s a bunch of services installed via homebrew like I was doing before. I can still tweak and add things to fit my needs too. (I’ll talk about that next.)

But, at the same time, it also does most of the site configuration for me so I don’t have to worry about that anymore. You can add a new site or directory of sites with a single command line. Valet will then auto-detect what type of project (Laravel, Symfony, WordPress, etc.) each site is. Using that knowledge, it’ll adapt each site’s configuration as needed. (It’s pretty magical.)

It also has most of the features I wanted from a virtualized development environment. It uses Dnsmasq to do a similar job as vagrant-hostupdater. It also supports SSL, but in a more straightforward way than Vagrant. (You only have to run the valet secure command.)

Filling the gaps

Like I mentioned earlier, Valet doesn’t install everything for you. It does the bare minimum to support most PHP project types. It then assumes that you’ll install everything else that you need yourself.

This means that I still have a few things to install to complete my setup. I’m not looking to mirror everything that I have on my production environment. But there’s some stuff that I consider mandatory for both.


Valet doesn’t install a database for you. It’s pretty hard to work without one. For WordPress, you need either MySQL or MariaDB which is a drop-in replacement for MySQL.

$ brew install mariadb
$ brew services start mariadb

I use the latter which is now the version supported by the original MySQL team. brew services start mariadb ensures that MariaDB always starts when you reboot your computer. You can skip it if you don’t want that.

$ brew install postgresql
$ brew install homebrew/php/php70-pdo-pgsql
$ brew services start postgresql

I also install PostgreSQL. This is my preferred database when I’m not using WordPress. PHP doesn’t come with PostgreSQL-related functions by default so I install those as well.

Caching system

Caching is hard problem to work on. For that reason, I want my development environment to include a caching system. That way I can work on it without relying on my production environment.

$ brew install redis
$ brew install homebrew/php/php70-redis
$ brew services start redis

My preferred caching system is Redis. It’s an in-memory data structure store like memcached. I prefer Redis because it can do everything Memcached can do and more. I also find it easier to use than Memcached.


Xdebug is another important PHP extension. If you’re not familiar with it, it adds debugging capabilities to PHP. This is very useful in a development environment.

$ brew install homebrew/php/php70-xdebug

Xdebug has quite a few useful features, but I’ve always used it for the stack trace. That said, it’s also well-known for its ability to connect with debuggers. This lets you set breakpoints in your code so that you can inspect it as it’s running.

By default, Valet doesn’t configure Xdebug to let you connect to a debugger. If you want to be able to use a debugger with Valet, you need to edit the ext-xdebug.ini file and add:


With homebrew and PHP 7.0, you can find the ext-xdebug.ini file in the /usr/local/etc/php/7.0/conf.d/ folder. If you’re not using PhpStorm, you’ll need to use the appropriate idekey for your debugger.

Additional PHP extensions

There are two other PHP extensions that I need to install as well. They don’t quite need as much of an explanation as the rest. So I lumped them all together here.

$ brew install homebrew/php/php70-intl
$ brew install homebrew/php/php70-opcache

The intl extension adds extra internationalization functions to PHP. The opcache extension improves the already stellar performance of PHP 7. And more performance never hurts!


I also work with Ansible a lot. It’s a configuration management tool that I use to configure WordPress servers. I install it using the installation instructions from my project wiki.

$ brew install python
$ pip install ansible debops passlib pycrypto
$ debops-update

What about JavaScript?

I haven’t talked a lot about JavaScript. That’s because JavaScript isn’t a huge part of my workflow. I still install node.js for npm.

$ brew install node

But, besides that, I don’t install anything else. I don’t work with task runners like grunt or gulp. I’m also not sold on frontend javascript still except for specific use cases. (Most of which aren’t WordPress related.)

Remaining applications

We’re almost done now! The only thing left to is to install the remaining applications that I haven’t installed yet.

Installed with Homebrew

Here are the ones (in alphabetical order) that I install using homebrew:

$ brew cask install dropbox
$ brew cask install filezilla
$ brew cask install flux
$ brew cask install owncloud
$ brew cask install skype
$ brew cask install spectacle
$ brew cask install vlc
$ brew cask install zoomus

Dropbox and ownCloud are two cloud file storage solutions. Everyone knows Dropbox, but you might not have heard of ownCloud. It’s an open source version of Dropbox that you can host yourself.

FileZilla is a free open source FTP client. Flux is something I tried out a few years ago and ended liking a lot. It adjusts the colours of your screen depending on the time of day.

I still use Skype to do some conference calls. That said, I’m liking Zoom a lot and use it with The WP Crowd to record our podcast. I plan on using it more in the future.

The last two applications are Spectacle and VLC. Spectacle is a great little application. It lets you manage your application windows with keyboard shortcuts. Meanwhile, VLC has been my go-to video player for almost a decade.

Installed from the App Store

There are two applications that I need to install from the App Store. But I’m stubborn and want to keep installing everything from my terminal. So I install mas to let me do that.

$ brew install mas

Unlike with Homebrew, mas needs you to give it the ID of the application that you want to install. You can search for the IDs using mas search. You then install the application using mas install.

$ mas search spark
$ mas install 1176895641
$ mas search tweetbot
$ mas install 557168941

Spark is an email client that I use instead of using Chrome. I was shying away from email clients ever since Sparrow shut down. Everyone that I’d tried had been pretty average. That said, I like Spark a lot so far so take it as you will!

Tweetbot has been my Twitter client for almost as long as I’ve been using Twitter. I use it both on macOS and iOS as well. It’s worth every penny.

And that’s it!

I’ve now installed and configured everything that I use on my new MacBook Pro. There are a few gems in there worth copying in there. They took some time to investigate and figure out.

But, otherwise, this isn’t a blueprint that you should copy as is. As I said in the introduction, it’s more of a window into what went into my decision process. This means that I expect you to use your judgement to decide what to take away from this article.

Creative Commons License