🧰 Essential Development Tools Installation
A full stack developer is only as fast as their workshop. In this lesson you'll install and configure the small, sharp set of tools that every stack shares — version control, an editor, three language runtimes, containers, databases, and an API client — so the rest of the course has a solid foundation to build on.
🎯 Learning Objectives
By the end of this lesson, you will be able to:
- Install and verify Git, VS Code, Node.js, Python, and PHP on your operating system
- Configure Git with your identity and sensible defaults for a new machine
- Use a package manager (winget/Chocolatey, Homebrew, or apt) instead of hunting for installers
- Run databases in Docker so your host machine stays clean and reproducible
- Prove your environment works end to end with a small multi-language smoke test
Estimated Time: 45–60 minutes • Difficulty: Beginner
Hands-on: Build a "smoke-test" project that exercises Git, Node, Python, PHP, and a Dockerized database in one go.
In This Lesson
The Developer's Toolkit
Every craft has a core set of tools you reach for daily. For a full stack developer, that set is remarkably consistent no matter which language you specialize in. Master this handful once and you can sit down at almost any project and be productive.
💡 Analogy: Think of these tools as a chef's mise en place — knives, cutting board, pans, and a clean station. You set them up once, keep them sharp, and then the actual cooking (writing code) flows without interruption.
We'll install these in a deliberate order: a package manager first (so everything else becomes a one-line install), then Git, then the editor and runtimes, and finally Docker for databases. Along the way you'll verify each tool — installing without checking is how "it works on my machine" bugs are born.
Start With a Package Manager
Before installing anything else, install a package manager for your OS. A package manager downloads, installs, and updates software from the command line — no browser downloads, no "next, next, finish" wizards, and trivially easy upgrades later.
📖 What is a package manager?
A tool that installs software from a curated catalog with a single command, tracks what you've installed, and updates everything at once. It's the App Store of the command line — and the standard way professionals set up machines.
Windows — winget (built in) or Chocolatey
winget ships with modern Windows 10/11, so you usually already have it. Chocolatey is a popular alternative with a larger catalog.
# winget is already installed on current Windows — verify it:
winget --version
# (Optional) Install Chocolatey from an *elevated* PowerShell:
Set-ExecutionPolicy Bypass -Scope Process -Force
iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
macOS — Homebrew
# Install Homebrew (the de-facto macOS package manager)
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# Verify
brew --version
Linux — your distro already has one
# Debian / Ubuntu use apt — refresh the catalog first
sudo apt update
# Fedora uses dnf; Arch uses pacman
# sudo dnf check-update
# sudo pacman -Syu
✅ Why this matters
With a package manager in place, installing Git becomes brew install git or winget install Git.Git — and six months from now, one brew upgrade updates everything at once. That single habit saves hours over a career.
Version Control with Git
Git is the industry-standard version control system. It's a time machine for your code: it records every change, lets you branch off to try ideas safely, and makes collaborating with other people possible without emailing zip files around.
Install Git
# Windows (choose one)
winget install --id Git.Git -e
choco install git -y
# macOS
brew install git
# Ubuntu / Debian
sudo apt install git -y
# Fedora
sudo dnf install git -y
# Arch
sudo pacman -S git
Configure your identity (do this once per machine)
Git stamps every commit with a name and email. Set them globally so every project inherits them:
# Who you are — appears on every commit
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
# Modern default branch name
git config --global init.defaultBranch main
# Sensible line-ending handling
git config --global core.autocrlf true # Windows
git config --global core.autocrlf input # macOS / Linux
# Use VS Code as your commit editor (optional but nice)
git config --global core.editor "code --wait"
# Verify everything took
git config --global --list
⚠️ Line endings will bite you
Windows ends lines with CRLF; macOS and Linux use LF. Getting core.autocrlf right on day one prevents the maddening "the whole file changed but I only edited one line" diffs when collaborating across operating systems.
Editor & Language Runtimes
Next come the editor you'll live in and the three language runtimes this course uses. (VS Code gets a full lesson of its own next — here we just get it installed.)
VS Code
# Windows
winget install Microsoft.VisualStudioCode
# macOS
brew install --cask visual-studio-code
# Ubuntu / Debian (via Snap — simplest)
sudo snap install --classic code
Node.js & npm — install via a version manager
Node.js runs JavaScript outside the browser; npm is its package manager. Rather than installing a single fixed version, use a version manager so you can switch Node versions per project — real jobs often pin specific versions.
# macOS / Linux — install nvm, then the latest LTS
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
source ~/.bashrc # or ~/.zshrc
nvm install --lts # install newest Long-Term-Support release
nvm alias default 'lts/*' # make it the default
# Windows — use nvm-windows (installs via winget)
# winget install CoreyButler.NVMforWindows
# nvm install lts
# nvm use lts
# Verify
node -v
npm -v
📖 LTS vs Current
LTS ("Long-Term Support") releases are stable and supported for years — the right default for learning and production. "Current" releases carry the newest features but change faster. When in doubt, choose LTS.
Python
Python powers the Django/Flask stack later in the course. Install it, then always work inside a virtual environment so each project keeps its own isolated dependencies.
# Windows
winget install Python.Python.3.12
# macOS
brew install python
# Ubuntu / Debian
sudo apt install python3 python3-pip python3-venv -y
# Verify
python3 --version # 'python --version' on Windows
pip3 --version
# Create and use a per-project virtual environment
python3 -m venv .venv
# Activate it
source .venv/bin/activate # macOS / Linux
# .venv\Scripts\activate # Windows PowerShell
# Install packages *inside* the environment
pip install flask requests
# Freeze exact versions for teammates / deployment
pip freeze > requirements.txt
# Leave the environment when done
deactivate
PHP & Composer
PHP still powers a large share of the web (WordPress, Laravel). Composer is its dependency manager — the npm/pip equivalent.
# Windows
winget install PHP.PHP.8.3
choco install composer -y
# macOS
brew install php composer
# Ubuntu / Debian
sudo apt install php php-cli php-mbstring php-xml php-curl unzip -y
# Verify
php --version
composer --version
Docker & Databases
Docker packages software into containers — isolated, pre-configured mini-environments that run identically on any machine. For local development it shines at one job in particular: running databases without installing them onto your host system.
Install Docker Desktop
# Windows (requires WSL 2 — see note below)
winget install Docker.DockerDesktop
# macOS
brew install --cask docker
# Ubuntu — Docker Engine via the official convenience script
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER # run docker without sudo (log out/in after)
# Verify (Docker Compose ships inside modern Docker as 'docker compose')
docker --version
docker compose version
docker run hello-world
⚠️ Windows needs WSL 2
Docker Desktop on Windows runs on top of the Windows Subsystem for Linux. If Docker refuses to start, run wsl --install in an elevated PowerShell, reboot, then launch Docker Desktop again.
Run databases as containers
Instead of installing PostgreSQL, MongoDB, and MySQL natively, pull and run them on demand. Delete the container when you're done and your machine is spotless.
# PostgreSQL
docker run --name dev-postgres -e POSTGRES_PASSWORD=devpass -p 5432:5432 -d postgres:16
# MongoDB
docker run --name dev-mongo -p 27017:27017 -d mongo:7
# MySQL
docker run --name dev-mysql -e MYSQL_ROOT_PASSWORD=devpass -p 3306:3306 -d mysql:8
# See what's running / stop / remove
docker ps
docker stop dev-postgres
docker rm dev-postgres
✅ Why Dockerized databases?
- No pollution: nothing permanent gets installed on your OS.
- Reproducible: everyone on the team runs the exact same
postgres:16. - Disposable: corrupt your data while experimenting? Delete and recreate in seconds.
API Testing Tools
Once you build backends, you'll need a way to send requests to them and inspect the responses. A GUI API client makes this pleasant; the humble curl command handles it from the terminal.
Install a GUI client
# Postman
winget install Postman.Postman # Windows
brew install --cask postman # macOS
sudo snap install postman # Linux
# Insomnia (lighter-weight alternative)
brew install --cask insomnia # macOS
sudo snap install insomnia # Linux
...or just use curl
curl is pre-installed nearly everywhere and is perfect for quick checks:
# GET a JSON endpoint
curl https://api.github.com/zen
# POST JSON to your local server
curl -X POST http://localhost:3000/hello \
-H "Content-Type: application/json" \
-d '{"name":"Ada"}'
Hands-on: Smoke-Test Project
🏋️ Prove the whole toolkit works
Objective: Create one small project that touches Git, Node, Python, PHP, and a Dockerized database — so you know your environment is genuinely ready before the real work begins.
Instructions:
- Create and enter a project folder, then initialize Git and a
.gitignore. - Add a tiny Node/Express server, a Python script, and a PHP script.
- Start a PostgreSQL container and confirm you can reach it.
- Run each piece and confirm no errors.
# 1. Scaffold + version control
mkdir dev-env-test && cd dev-env-test
git init
printf "node_modules/\n.venv/\n__pycache__/\n" > .gitignore
# 2. Node/Express
npm init -y
npm install express
// server.js — a one-route Express server
const express = require('express');
const app = express();
app.get('/', (req, res) => {
res.send('Node environment is working!');
});
app.listen(3000, () => console.log('http://localhost:3000'));
# app.py — confirm Python runs
from datetime import datetime
print("Python environment is working!")
print(f"Current time: {datetime.now():%Y-%m-%d %H:%M:%S}")
<?php
// index.php — confirm PHP runs
echo "PHP environment is working!\n";
echo "PHP version: " . phpversion() . "\n";
# 3. Start a database container
docker run --name test-pg -e POSTGRES_PASSWORD=devpass -p 5432:5432 -d postgres:16
# 4. Run each component
node server.js # then visit http://localhost:3000
python3 app.py
php index.php
docker ps # confirm test-pg is 'Up'
💡 Hint — "command not found"?
A freshly installed tool often isn't on your PATH until you open a new terminal window. Close and reopen your terminal, then re-run the verify command (node -v, python3 --version, php --version). On Windows, restart VS Code entirely so it inherits the updated PATH.
✅ What success looks like
Each command prints its "…is working!" line with no errors, the browser shows the Express message, and docker ps lists test-pg as Up. Clean up afterward with docker stop test-pg && docker rm test-pg.
Best Practices & Troubleshooting
✅ Do
- Install through a package manager so upgrades are one command.
- Use version managers (nvm) and virtual environments (venv) to isolate per-project versions.
- Verify every tool immediately after installing it.
- Run databases in Docker during development.
⚠️ Don't
- Don't install packages globally with sudo to dodge permission errors — fix the root cause (use nvm/venv) instead.
- Don't commit
node_modules/,.venv/, or secrets — that's what.gitignoreis for. - Don't skip verification and assume it worked.
Common issues
| Symptom | Likely cause | Fix |
|---|---|---|
command not found | Tool not on PATH yet | Open a new terminal / restart VS Code |
EACCES on npm install | Global install without a version manager | Use nvm; never sudo npm |
| Cannot connect to Docker daemon | Docker Desktop not running (or no WSL 2) | Start Docker Desktop; wsl --install on Windows |
| Port already in use | Another service on 5432/3000 | Map a different host port, e.g. -p 5433:5432 |
Summary & Quiz
🎉 Key Takeaways
- Install a package manager first; everything else becomes a one-line install and upgrade.
- Git needs a one-time identity and line-ending config on each machine.
- Use nvm for Node and venv for Python to isolate versions per project.
- Run databases in Docker to keep your host clean and reproducible.
- Always verify — a smoke-test project proves the whole toolkit works together.
🎯 Quick Quiz
Question 1: Why is installing a package manager the recommended first step?
Question 2: What's the main reason to run PostgreSQL in a Docker container during development?
Question 3: You just installed Node but node -v says "command not found." What's the most likely fix?
📚 Further Reading
🚀 What's Next?
Your tools are installed — but many of them (Git, npm, Docker, package managers) are driven from the command line. Next we'll build real fluency in the terminal so you can wield this whole toolkit quickly and confidently.
🎉 Workshop set up!
Your mise en place is ready. Let's learn to move fast inside it.