At Fishtown Analytics, we spend a lot of our time working on dbt projects. As such, we’ve settled on our favorite way to set up our computers to make working on dbt projects as easy as possible.
Note that we are all on MacBooks – if you’re on a PC, some parts of this may not apply to you!
This article won’t cover installing dbt – read these instructions if that’s what you’re looking for.
This article was originally written in Feb 2019. At the time, Atom was our code editor of choice, and this article reflects that. These days, I suspect that VSCode is the editor of choice for folks using the dbt CLI and a code editor. We haven’t updated this article to reflect that since most of our team now defaults to using the dbt Cloud IDE.
Terminal
We use iTerm2 instead of the default Mac Terminal – you can definitely use the default Mac Terminal, but using iTerm will get you more cred with your engineering team 
.
We also customize our terminals so that they work best for us, but this is definitely a matter of personal preference. If you’re new to using the terminal, I suggest asking to pair with an engineer at your organization to learn how they set up their terminal.
Here are some things that we find useful in customizing your terminal:
Install the dbt-completion script : See instructions here- Install the git-completion script: See instructions here.
- Use a dark theme: See instructions here, I like Dracula and Adventure Time! (I use these themes wherever I can!)
- Change your terminal prompt: I like to have information about the status of my git repo – relevant script here. Here’s my (quite verbose!) bash prompt:
- Change the default code editor: Since I use Atom, I added this to my
.bashrcfile (which is called by my.bash_profilefile). It stops me from having to remember that:wqis the way to save and close a Vim window.
export EDITOR="atom --wait"
Code editor
We use Atom as our code editor – our specific setup is below.
You should use whichever code editor you like best/are most comfortable in – other popular alternatives include:
There are a few things we like to do with our editors:
- Ensure that Jinja-flavored SQL is highlighted correctly
- Add useful Jinja and dbt-specific snippets
- Show files that are not included in version control (e.g. compiled files in the
target/directory) – some editors hide these by default. - Grey out the text of files that have compiled code in them, to help prevent you from editing compiled SQL (as opposed to your actual model).
Atom setup
- Ensure that compiled files are shown in the tree view (they are hidden by default since they are included in
.gitignore
). Settings>Packages>tree-view> UntickHide VCS Ignored Files - Install the atom-dbt package. This package provides highlighting for jinja-flavored SQL, Markdown and YAML, as well as adds a number of dbt-specific snippets.
- Install the file-types package, and configure it to render compiled SQL as plain text (useful if you ever find yourself editing compiled SQL!). Add this to your
config.csonfile:
"*": # Be sure to put "file-types" under the "*" key
"file-types":
"**/target/**": "text.plain"
- Turn on the indent guide (especially useful for yaml files).
Settings>Editor>Show Indent Guide
- Install the rainbow-csv package (especially useful for highlighting seeds)
VSCode setup
- Install the better-jinja extension
- Add some file association settings to your
settings.jsonfile (thetargetfile association greys out compiled SQL).
{
"some_setting": custom_value,
...
"files.associations":{
"*.sql":"jinja-sql",
"**/target/**":""
}
}
- Install the rainbow-csv extension (especially useful for highlighting seeds)
- Manually install the
vscode-dbtextension (hopefully this gets onto the marketplace soon!)
Vim setup
One of our community members (@jesse) has a repo for how he sets up his Vim.
If you want to grey out your compiled SQL, add this following to your .vimrc file:
au BufNewFile,BufRead */target/*.sql set ft=text
SQL query runner
Having a query runner is useful when you want to see what the results of your SELECT SQL statements are, or when running statements outside of dbt (e.g. creating new users). We use a query runner when building models (often writing queries in pure SQL first, and then moving them over to dbt), inspecting the results of a model, and debugging things that don’t look right!
Again, we’ve gone for the open source option here, of SQL Workbench. Personally, I don’t love this application, and would welcome any feedback in the comments if you have strong opinions on an alternative. Popular alternatives include:
- Open-source:
- Paid:
If you’re using Snowflake or BigQuery, both provide pretty good web UIs for running queries, so you may not need a query runner on your computer!
SQL formatting/linting
A SQL formatter will format your SQL to match a particular coding convention, while a linter will return errors when your SQL doesn’t match those conventions (rather than updating the code).
While there are a few SQL formatters and linters available, so far none of them play nicely with jinja-flavored SQL, so won’t work with your dbt project.
So for now, we just format by hand! Here is our style guide – it’s a good idea to have one for your organization too!
Global .gitignore
This was something I didn’t know for a really long time!
You can set a global .gitignore for your computer, which means you’ll never accidentally commit system files like those pesky .DS_Store files. This tutorial walks through the steps involved.
