Course Practicalities

Tools and Environments


Main Tools

The course project has a small stack that helps keep the focus on databases rather than on framework complexity.

To work comfortably on the course, you will need:

  • Docker and Docker Compose, used to start PostgreSQL and the web application together,
  • a code editor such as Visual Studio Code or another editor intended for writing code,
  • a browser for opening the project pages,
  • and a terminal where you can run commands such as docker compose up --build.

The project itself uses FastAPI, Jinja, PostgreSQL, and raw SQL. You do not need to memorize all of those tools immediately, but you should become comfortable recognizing where each one appears in the project.

If you want a part-by-part overview of how the same project grows through the course, or a reminder of the usual local workflow, keep the Project Roadmap nearby while studying.

Windows users

If working with terminals, containers, and local development tools feels awkward on Windows, using Windows Subsystem for Linux (WSL) may make the workflow smoother. The exact setup is up to you, but the main goal is to have a predictable environment where Docker, the terminal, and the editor work well together.

The examples in these materials have been written and tested in a Linux environment, but they should work in WSL as well. If you run into issues, check the documentation of your tools and consider asking for help in the course forums or support channels.

Optional Tools for Database Inspection

You can complete the course without becoming an expert in database tooling, but it is often helpful to have some way to inspect PostgreSQL directly.

Useful optional tools include:

  • psql
    • with docker, run docker compose exec db psql -U studytracker to get a terminal connected to the database called studytracker running in the container named db,
  • a PostgreSQL extension for your editor,
  • or a database browser or administration tool that lets you inspect tables and run queries.

Direct inspection becomes especially useful when debugging, verifying seed data, or checking whether a write query really changed the intended rows.