Concepts

docker run --rm -it python:3.12-slim bash
# inside the container: python --version; exit

--rm deletes the container the moment it exits. -it gives you an interactive terminal attached to it.

Mini project: build, run, verify, inspect, clean up

mkdir docker-hello && cd docker-hello

cat > requirements.txt <<'EOF'
fastapi
uvicorn[standard]
EOF

cat > main.py <<'EOF'
from fastapi import FastAPI
app = FastAPI()

@app.get("/health")
def health():
    return {"ok": True}
EOF

cat > Dockerfile <<'EOF'
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]
EOF

cat > .dockerignore <<'EOF'
.venv
__pycache__
*.pyc
.git
EOF

Dependencies are installed before COPY . . on purpose: editing main.py later won’t bust the pip-install cache layer, so rebuilds stay fast.

docker build -t hello-api .
docker run -d --name hello --rm -p 8000:8000 hello-api

curl -s http://127.0.0.1:8000/health          # {"ok":true}
docker logs hello                              # confirms uvicorn actually started
docker exec -it hello bash -c "python --version"   # peek inside the running container

docker stop hello                              # --rm means this also deletes the container
docker ps -a                                   # confirm it's gone, not just stopped

Cleanup — useful once containers and images pile up:

docker images                 # see what's on disk
docker system prune -f        # removes stopped containers, dangling images, unused networks

docker system prune is destructive for anything not currently running or tagged as in-use — read what it says it will remove before you run it on a machine with work you care about.

Habits that save pain

• Pin base images (python:3.12.8-slim) when reproducibility matters; latest silently changes under you.
• Put dependency installs before COPY . . (done above) so code edits don’t bust the pip cache every time.
• Don’t bake secrets into images — pass environment variables or mount secrets at runtime, since anything in a layer is recoverable from the image history.
• Prefer one process per container; if you need two processes, you probably need two containers plus docker compose, not a supervisor script.
• Always ship a .dockerignore — without one, COPY . . pulls in .git, .venv, and node_modules, bloating the build context and sometimes leaking history into the image.

Common footguns

• “permission denied” on /var/run/docker.sock — on Linux, add your user to the docker group (sudo usermod -aG docker $USER, then log out/in) instead of prefixing every command with sudo.
• “port is already allocated” — something else is bound to 8000; either stop it (docker ps to find the culprit) or map a different host port (-p 8001:8000).
• Forgetting --rm — stopped containers accumulate silently and eat disk; docker ps -a reveals them, docker container prune clears them.
• Root by default — containers run as root unless you add a USER instruction; fine for local learning, a real problem for anything internet-facing.
• Rebuilding without noticing cache reuse — if you change requirements.txt, Docker reruns pip install; if you only change main.py, it reuses the cached install layer. Confusing these two is a common “why is this taking so long” moment.

You know you’re done when…

• docker build finishes with no errors and docker images lists hello-api
• curl http://127.0.0.1:8000/health returns {"ok":true} while the container runs detached (-d)
• docker logs hello shows the uvicorn startup line, proving the process actually started (not just that the container exists)
• After docker stop hello, docker ps -a shows it gone (because of --rm), not lingering as “Exited”
• You have a .dockerignore so .git and .venv never enter the build context

Next

Getting Started with FastAPI — the API you just containerized, explained properly · wrap models behind HTTP after LLM Mastery.

Install

pip install fastapi uvicorn

Mini project: a notes API with real validation and error handling

# main.py
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field

app = FastAPI(title="Notes API")


class Note(BaseModel):
    id: int
    text: str


class NoteIn(BaseModel):
    text: str = Field(min_length=1, max_length=500)


notes: dict[int, Note] = {}
next_id = 1


@app.get("/health")
def health():
    return {"ok": True}


@app.get("/notes")
def list_notes():
    return list(notes.values())


@app.post("/notes", status_code=201)
def create_note(body: NoteIn):
    global next_id
    note = Note(id=next_id, text=body.text)
    notes[next_id] = note
    next_id += 1
    return note


@app.get("/notes/{note_id}")
def get_note(note_id: int):
    if note_id not in notes:
        raise HTTPException(status_code=404, detail="note not found")
    return notes[note_id]


@app.delete("/notes/{note_id}", status_code=204)
def delete_note(note_id: int):
    if note_id not in notes:
        raise HTTPException(status_code=404, detail="note not found")
    del notes[note_id]

Run it and open the auto-generated docs:

uvicorn main:app --reload --port 8000
# open http://127.0.0.1:8000/docs

Now exercise every path with curl, including the two that should fail on purpose:

curl -s http://127.0.0.1:8000/health
# {"ok":true}

curl -s -X POST http://127.0.0.1:8000/notes \
  -H 'content-type: application/json' -d '{"text":"buy milk"}'
# {"id":1,"text":"buy milk"}  — check the HTTP status too:

curl -s -o /dev/null -w "%{http_code}\n" -X POST http://127.0.0.1:8000/notes \
  -H 'content-type: application/json' -d '{"text":"buy eggs"}'
# 201, not the default 200 — because of status_code=201 on the route

curl -s http://127.0.0.1:8000/notes
# [{"id":1,...},{"id":2,...}]

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8000/notes/999
# 404 — an id that was never created

curl -s -X POST http://127.0.0.1:8000/notes \
  -H 'content-type: application/json' -d '{"text":""}' \
  -o /dev/null -w "%{http_code}\n"
# 422 — Pydantic's min_length=1 rejected it before your code ever ran

curl -s -X DELETE http://127.0.0.1:8000/notes/1 -o /dev/null -w "%{http_code}\n"
# 204

If any of those status codes don’t match, that’s the bug to chase — the point of writing them down is having something concrete to check against, not “it looked like it worked in the docs UI.”

Why it fits AI work

Keep inference or business logic in a plain Python module; the route itself should stay thin: validate → call → return.

Common footguns

• In-memory state isn’t persistence — the notes dict resets to empty every time uvicorn --reload restarts (which it does automatically on file changes). This is fine for learning; for anything real, back it with the SQLite schema from Getting Started with SQL.
• Blocking code inside async def — a synchronous call like time.sleep() or heavy file I/O inside an async def route blocks the entire event loop, stalling every other request. Use a plain def route for sync work (FastAPI runs it in a thread pool automatically) or await a genuinely async call.
• Forgetting the default status code — routes return 200 unless you set status_code= explicitly; a POST that creates a resource should return 201, a DELETE typically 204.
• Trusting raw dict/request.json() instead of Pydantic — skips validation entirely, so malformed input reaches your business logic instead of failing fast with a clear 422.
• CORS errors when calling from a browser on a different origin — add CORSMiddleware explicitly; FastAPI doesn’t allow cross-origin requests by default, on purpose.
• Leaving --reload on outside development — it watches the filesystem and restarts the process, which is convenient locally and inappropriate (and slower) in production.

You know you’re done when…

• GET /health returns {"ok": true} with status 200
• POST /notes with a valid body returns status 201 and an incrementing id
• GET /notes/999 (an id that doesn’t exist) returns 404, not a 500 or an empty 200
• POST /notes with {"text": ""} returns 422 because of Pydantic’s min_length
• You can explain why restarting uvicorn --reload wipes your notes, and what you’d change to make them survive a restart

Next

Serve a tiny model after LLM Mastery (quantization & serving in article 44). For product UIs, pair with Getting Started with JavaScript.

Install and one-time setup

git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

Skip the global config and your commits show up anonymously as whatever your OS username happens to be — annoying to fix retroactively across dozens of commits.

Daily driver

git status                 # where am I?
git add -p                 # stage hunks intentionally, not blindly
git commit -m "message"    # snapshot with a why
git log --oneline -10      # recent history
git diff                   # unstaged changes
git diff --staged          # what will actually be committed

Commit messages: say why, not “update files.” Future-you (and reviewers) need the reason, not a restatement of the diff.

Mental model

working tree  →  staging area  →  commit (immutable snapshot)
     edit            git add           git commit

• A branch is a movable label pointing at a commit — nothing more exotic than that.
• main is a convention, not a special object; Git doesn’t know it’s “the important one.”
• Remotes (origin) are other copies of the same commit graph, not a separate system.

Mini project: create a merge conflict, then resolve it

Tutorials that avoid conflicts teach you to fear them. Do this instead — it’s the single most useful 5 minutes you can spend learning Git.

mkdir git-practice && cd git-practice
git init -b main
echo "Headline: draft" > readme.txt
git add readme.txt
git commit -m "add readme with draft headline"

git switch -c feature-headline
echo "Headline: Hello World" > readme.txt
git commit -am "feature: rewrite headline for launch"

git switch main
echo "Headline: Welcome Friends" > readme.txt
git commit -am "main: rewrite headline for homepage"

git merge feature-headline

Git stops and reports CONFLICT (content): Merge conflict in readme.txt. Open the file — it now looks like this:

<<<<<<< HEAD
Headline: Welcome Friends
=======
Headline: Hello World
>>>>>>> feature-headline

Everything between <<<<<<< and ======= is your current branch (HEAD); everything between ======= and >>>>>>> is the branch you’re merging in. Resolve it by editing the file down to what you actually want — say, Headline: Welcome Friends (Hello World!) — deleting the marker lines, then:

git add readme.txt
git commit --no-edit          # finishes the merge commit
git log --oneline --graph --all

The graph should show two branches converging into one merge commit. You created the exact situation every team hits weekly, and fixed it without panic.

Undo without panic

git reflog is your safety net: Git keeps a log of where HEAD has pointed, even across resets and rebases, for about 90 days by default. Almost nothing is truly lost immediately.

Common footguns

• Force-pushing shared branches — git push --force overwrites history your teammates already pulled. Use --force-with-lease if you must, and only on branches you own.
• Detached HEAD confusion — git checkout <sha> (not a branch) puts you in detached HEAD. Commits there are orphaned unless you git switch -c <name> before leaving.
• Committing secrets or large binaries — they live in history forever unless you rewrite it (git filter-repo), which is painful. .gitignore them before the first commit, not after.
• Rebasing after pushing — rewrites commit SHAs your collaborators already have, forcing them into confusing conflicts. Rebase local, unpublished work only.
• .gitignore added too late — adding a pattern doesn’t untrack files already committed; you also need git rm --cached <file>.

You know you’re done when…

• git log --oneline --graph --all shows both branches merging into a single history
• You deliberately created and resolved a real merge conflict, not just avoided one
• git status is clean before you switch branches (no surprise stashing later)
• You can find a “lost” commit with git reflog without googling the command
• user.name / user.email are configured, so your commits aren’t anonymous

Next

Use Git on every course project. Pair with Getting Started with the Linux Shell so git and the terminal feel like one tool.

Essentials

const name = "Sharda";     // prefer const
let count = 0;             // when a value must change

const add = (a, b) => a + b;

const nums = [1, 2, 3, 4];
const evens = nums.filter((n) => n % 2 === 0);
const doubled = nums.map((n) => n * 2);

const { id, role } = { id: 1, role: "student" };   // destructuring
const label = `user #${id} (${role})`;              // template literal

Always use ===/!==, never ==/!=. Loose equality coerces types in ways that surprise you ("0" == false is true).

Async without tears

async function load() {
  const res = await fetch("https://httpbin.org/get");
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return await res.json();
}

load().then(console.log).catch(console.error);

async/await and Promises are the same idea: “do this when the network returns,” written to read top-to-bottom instead of nested in callbacks. The one rule that prevents most bugs: every Promise needs either an await, a .then(), or an explicit .catch() — an unhandled one (“floating promise”) fails silently and you find out in production.

Mini project: a todo app that survives a page reload

DOM manipulation and localStorage together, with zero dependencies and zero build step. Save this as todo.html and open it directly in a browser.

<!DOCTYPE html>
<html>
<head><title>Todos</title></head>
<body>
  <input id="task" placeholder="New task" />
  <button id="add">Add</button>
  <ul id="list"></ul>

  <script>
    const KEY = "todos-v1";
    const load = () => JSON.parse(localStorage.getItem(KEY) || "[]");
    const save = (todos) => localStorage.setItem(KEY, JSON.stringify(todos));

    function render() {
      const list = document.getElementById("list");
      list.innerHTML = "";
      load().forEach((todo, i) => {
        const li = document.createElement("li");
        li.textContent = todo + " ";

        const del = document.createElement("button");
        del.textContent = "x";
        del.onclick = () => {
          const todos = load();
          todos.splice(i, 1);
          save(todos);
          render();
        };

        li.appendChild(del);
        list.appendChild(li);
      });
    }

    document.getElementById("add").onclick = () => {
      const input = document.getElementById("task");
      const value = input.value.trim();
      if (!value) return;
      const todos = load();
      todos.push(value);
      save(todos);
      input.value = "";
      render();
    };

    render();
  </script>
</body>
</html>

Test it end to end, in this order:

1. Open todo.html, add three tasks — they appear immediately.
2. Refresh the page. All three should still be there. This is the real test: it proves data persisted in localStorage, not just in a JavaScript variable that resets on reload.
3. Delete the middle task. Confirm it removed that one, not its neighbor — an easy off-by-one bug in splice(i, 1) if i were computed wrong.
4. Open DevTools → Application → Local Storage and inspect the raw JSON string yourself.

Extend it: add an “edit” button, or a “clear completed” button using .filter() instead of .splice().

Common footguns

• == vs === — covered above, but it’s the single most common source of “why is this true when it shouldn’t be” bugs.
• Losing this in callbacks — a plain function used as an event handler gets its own this; an arrow function captures the surrounding scope’s this. The todo app above uses arrow functions for exactly this reason.
• var vs let/const — var is function-scoped and hoists, causing loop-variable bugs (for (var i ...) inside async callbacks all seeing the final i). Default to const, use let only when reassigning, and avoid var entirely.
• Floating promises — calling an async function without await or .catch() swallows errors silently. Lint rules like no-floating-promises exist specifically for this.
• Mutating arrays you’re about to render from — todos.push(...) then forgetting to save() before render() leaves the UI and storage out of sync; the app above always saves, then renders.
• NaN !== NaN — the one value that isn’t equal to itself; use Number.isNaN(x) to check, never x === NaN.

You know you’re done when…

• Adding a task updates the list immediately with no page reload
• Reloading the browser keeps your todos — proof localStorage persisted, not just in-memory state
• Deleting one todo removes exactly that item, not a neighbor
• DevTools → Console shows zero errors during the whole flow
• You can explain why the delete handler uses an arrow function rather than a plain function

Next

Frontends often call Python backends — see Getting Started with FastAPI. For AI product UIs, keep JS thin and put model logic on the server.

Survival kit

pwd                 # where am I?
ls -la               # what is here, including dotfiles?
cd path              # move
mkdir -p a/b         # create nested dirs in one shot
cp src dst && mv old new
rm -i file           # interactive delete (safer while learning)
less file            # paginated view, quit with q
head -n 20 file
tail -f log.txt      # follow a growing log

Find and search:

grep -n "ERROR" app.log
grep -R "TODO" . --include="*.py"
find . -name "*.csv"

Two habits worth building immediately: use Tab for completion (fewer typos, faster) and Ctrl+R to search command history instead of retyping. man <command> or <command> --help beats guessing flags from memory.

Pipes, redirection, and exit codes

Programs read stdin and write stdout; chaining them is the entire philosophy of the shell:

cat access.log | grep " 500 " | awk '{print $1}' | sort | uniq -c | sort -nr | head

Every command leaves an exit code in $? — 0 means success, anything else means failure. Scripts that ignore this silently continue after real errors.

grep "ERROR" app.log
echo $?              # 0 if found, 1 if not found, 2 if app.log doesn't exist

Paths, permissions, and the environment

• . current dir, .. parent, ~ home
• chmod +x script.sh && ./script.sh — the executable bit, not the file extension, controls whether it runs
• chmod 644 file (owner read/write, everyone else read) vs chmod 600 (owner-only) — numeric modes are owner-group-other, each digit a sum of read(4)+write(2)+execute(1)
• echo $PATH — the ordered list of directories the shell searches for commands; which python3 tells you exactly which binary will run, which matters when you have both a system Python and a venv Python

Mini project: build a log analysis pipeline

Generate a synthetic access log with real (pseudo-random) variation, then answer three questions about it with pipelines — no sample output is given here on purpose; you run it and read your own numbers.

for i in $(seq 1 40); do
  ip="10.0.0.$(( RANDOM % 5 + 1 ))"
  if (( RANDOM % 5 == 0 )); then status=500; else status=200; fi
  echo "$ip GET /page$(( RANDOM % 4 )) $status"
done > toy.log

wc -l toy.log                                                   # should print 40

Now answer three questions:

# 1. Which IP hit the server most?
awk '{print $1}' toy.log | sort | uniq -c | sort -nr | head -5

# 2. What's the status code breakdown?
awk '{print $3}' toy.log | sort | uniq -c

# 3. How many 500s happened total?
grep -c " 500$" toy.log

Re-run the generator loop and the pipelines again — because it uses $RANDOM, your numbers will differ each time, which is the point: you’re checking that the pipeline logic is correct, not memorizing one output. Cross-check by hand: add up the counts from question 2 and confirm they sum to 40.

Common footguns

• Unquoted variables — rm -rf $DIR/* silently becomes rm -rf /* if $DIR is empty or unset. Always quote: rm -rf "$DIR"/*, and set set -u in scripts to error on unset variables.
• Parsing ls output — filenames with spaces or newlines break naive for f in $(ls) loops. Use find . -print0 | xargs -0 or a glob (for f in *.csv) instead.
• Forgetting set -e — without it, a failing command in a script doesn’t stop the script; later commands run against a broken state.
• source script.sh vs ./script.sh — sourcing runs in your current shell (env var changes persist); executing runs in a subshell (they don’t). Mixing these up is why “but I exported it!” doesn’t always work.
• Trusting PATH order blindly — which python3 before debugging “wrong version” complaints; a stale /usr/local/bin entry ahead of your venv is a classic trap.

You know you’re done when…

• toy.log contains exactly 40 lines after the generator loop
• All three analysis pipelines run with no errors and the status-code counts sum to 40
• You can explain why rm -rf "$DIR"/* (quoted) is safer than the unquoted version
• echo $? immediately after a command tells you pass/fail without re-running anything
• which <command> points to the binary you actually expect

Next

Getting Started with Docker packages the environment you just learned to navigate. Getting Started with Git version-controls the scripts you write in the shell.

Install and isolate

python3 --version          # aim for 3.10+
python3 -m venv .venv
source .venv/bin/activate  # Windows (PowerShell): .venv\Scripts\Activate.ps1
python -c "import sys; print(sys.executable)"   # confirm it points inside .venv
pip install --upgrade pip

Two things trip up almost everyone new to Python:

• On Ubuntu/Debian the command is python3, not python, until you activate a venv (which usually symlinks python for you). If python is “not found,” check that first.
• python -c "import sys; print(sys.executable)" is your sanity check. If it prints a system path instead of something ending in .venv/bin/python, your venv isn’t active — and any pip install you run next pollutes the wrong environment.

One project → one virtualenv. Never pip install into the system Python for learning work; it turns into unremovable clutter within a month.

Core ideas in one screen

from pathlib import Path

# list comprehension: transform + filter in one line
lengths = [len(w) for w in "a longer sentence here".split() if len(w) > 3]

# dict comprehension: build lookups fast
by_len = {w: len(w) for w in ["cat", "elephant", "ox"]}

# `with` guarantees the file handle closes even if read() raises
text = Path("notes.txt").read_text(encoding="utf-8") if Path("notes.txt").exists() else ""

Mini project: a real CLI tool, not a toy snippet

Most “getting started” posts show you a script you run once. Build a small command-line tool instead — it forces you to touch arguments, files, and error paths, which is where Python actually gets used.

#!/usr/bin/env python3
"""wordcount.py - rank word frequency across one or more text files."""
import argparse
import re
from collections import Counter
from pathlib import Path

STOPWORDS = {
    "the", "a", "an", "and", "or", "but", "is", "are", "was", "were",
    "to", "of", "in", "on", "for", "it", "this", "that",
}


def read_words(path: Path) -> list[str]:
    text = path.read_text(encoding="utf-8").lower()
    return re.findall(r"[a-z']+", text)


def main() -> None:
    parser = argparse.ArgumentParser(description="Count word frequency in text files.")
    parser.add_argument("files", nargs="+", type=Path, help="one or more text files")
    parser.add_argument("-n", "--top", type=int, default=10, help="how many words to show")
    parser.add_argument("--no-stopwords", action="store_true", help="drop common stopwords")
    args = parser.parse_args()

    counts: Counter[str] = Counter()
    for path in args.files:
        if not path.exists():
            raise SystemExit(f"error: {path} does not exist")
        counts.update(read_words(path))

    if args.no_stopwords:
        for word in STOPWORDS:
            counts.pop(word, None)

    for word, n in counts.most_common(args.top):
        print(f"{n:5d}  {word}")


if __name__ == "__main__":
    main()

Run it end to end:

printf "the quick brown fox jumps over the lazy dog. the dog barks at the fox.\n" > notes.txt
python wordcount.py notes.txt
python wordcount.py notes.txt --no-stopwords -n 5
python wordcount.py missing.txt      # exercises the error path — should exit cleanly, not traceback

The first run shows the at the top with count 4. The second, with stopwords stripped, promotes dog and fox (count 2 each) to the top. The third should print your SystemExit message and exit with a non-zero code — try echo $? right after to confirm.

Extend it yourself: add a --min-length flag, or read from stdin when no files are given (if not sys.stdin.isatty(): ...).

Common footguns

• Mutable default arguments — def f(x=[]) reuses the same list across every call. Use def f(x=None): x = x or [].
• Bare except: — swallows KeyboardInterrupt and typos alike. Catch the specific exception you can actually handle.
• range(len(x)) instead of enumerate(x) — works, but hides intent and invites off-by-one bugs.
• Comparing floats with == — 0.1 + 0.2 == 0.3 is False. Use math.isclose().
• Forgetting .lower() before comparing strings — silent case-mismatch bugs that “work on my test data.”
• Mixing tabs and spaces — Python 3 raises TabError; configure your editor to show whitespace and insert spaces only.

You know you’re done when…

• python -c "import sys; print(sys.executable)" prints a path inside .venv, not your system Python
• python wordcount.py notes.txt runs with no traceback and prints ranked counts
• --no-stopwords visibly changes which words rank highest
• python wordcount.py missing.txt fails with your error message, not a raw FileNotFoundError traceback
• You can explain, without looking it up, why def f(x=[]) is a bug

Next

• Python in 10 Days — structured sprint
• Getting Started with PyTorch — tensors next
• Getting Started with FastAPI — wrap scripts like this one behind HTTP
• LLM Mastery — when you want language models from first principles

Install

python3 -m venv .venv && source .venv/bin/activate
pip install torch    # see pytorch.org for a CUDA-specific build if you have an NVIDIA GPU
python -c "import torch; print(torch.__version__, torch.cuda.is_available())"

torch.cuda.is_available() prints False on most laptops — that’s expected, not broken. Everything below runs fine on CPU; it’s small on purpose.

Tensors

import torch

x = torch.randn(2, 3)       # shape (2, 3)
y = x @ x.T                 # (2, 2)
print(y.shape, y.dtype)

a = torch.tensor([1.0, 2.0, 3.0], requires_grad=True)
loss = (a ** 2).sum()
loss.backward()
print(a.grad)                # d(loss)/da == 2*a == [2., 4., 6.]

Shapes are a language. Write them in comments until they’re muscle memory: (B, T, C) for batch, time, channels. A RuntimeError: shapes cannot be multiplied is PyTorch telling you exactly where your mental model diverged from reality — read it, don’t guess.

nn.Module in one page

import torch.nn as nn

class TinyMLP(nn.Module):
    def __init__(self, d_in: int, d_hid: int, d_out: int):
        super().__init__()
        self.net = nn.Sequential(
            nn.Linear(d_in, d_hid),
            nn.ReLU(),
            nn.Linear(d_hid, d_out),
        )

    def forward(self, x):
        return self.net(x)

Mini project: train it to convergence and check the numbers

Two Gaussian blobs, one small network, fifty epochs. This is small enough to run in seconds on a CPU and large enough to show a real loss curve.

import torch
import torch.nn as nn
import torch.optim as optim

torch.manual_seed(0)

n = 200
x0 = torch.randn(n // 2, 2) + torch.tensor([-2.0, -2.0])   # class 0, centered at (-2,-2)
x1 = torch.randn(n // 2, 2) + torch.tensor([2.0, 2.0])      # class 1, centered at (2,2)
X = torch.cat([x0, x1])
y = torch.cat([torch.zeros(n // 2), torch.ones(n // 2)]).long()   # CrossEntropyLoss needs Long targets

model = nn.Sequential(nn.Linear(2, 8), nn.ReLU(), nn.Linear(8, 2))
opt = optim.AdamW(model.parameters(), lr=0.05)

for epoch in range(50):
    logits = model(X)
    loss = nn.functional.cross_entropy(logits, y)
    opt.zero_grad(set_to_none=True)
    loss.backward()
    opt.step()
    if epoch % 10 == 0:
        acc = (logits.argmax(dim=1) == y).float().mean()
        print(f"epoch {epoch:3d}  loss {loss.item():.4f}  acc {acc.item():.2f}")

with torch.no_grad():
    final_acc = (model(X).argmax(dim=1) == y).float().mean()
print(f"final accuracy: {final_acc.item():.2f}")

Run it and check two things concretely: the printed loss should trend down across epochs (not flat, not nan), and final accuracy should land at or near 1.00 — the two blobs are far enough apart (centers 4 units apart, unit-variance noise) that a tiny two-layer network separates them almost perfectly. If accuracy stays near 0.50, something upstream is broken — gradients not flowing, wrong loss, or a shape mismatch silently broadcasting incorrectly — not “the model needs more epochs.”

That loop — forward, loss, zero_grad, backward, step — is the heartbeat of every LLM training run, from this ten-line example to a multi-billion parameter model.

Habits for LLM work

• Use torch.no_grad() or torch.inference_mode() when evaluating — it skips building the autograd graph, saving memory and time for computations you won’t backpropagate through (used above in the final accuracy check).
• Move tensors with .to(device) once, near the top; keep the model and every batch on the same device — mismatches raise RuntimeError: Expected all tensors to be on the same device.
• Log shapes when debugging, not just values — print(x.shape) finds broadcasting bugs faster than staring at numbers.
• Start CPU-small, like this example; add GPU only once the toy version is verified correct. Debugging correctness and debugging performance are different problems — don’t mix them.

Common footguns

• Forgetting zero_grad() — gradients accumulate by default across .backward() calls; skip clearing them and your updates silently compound garbage from previous steps.
• Wrong target dtype — nn.functional.cross_entropy requires Long (integer class index) targets, not Float. Passing floats raises a cryptic error or silently misbehaves depending on the PyTorch version.
• Missing model.eval() / torch.no_grad() during evaluation — irrelevant for this tiny model (no dropout or batchnorm), but essential once you add either; forgetting eval() leaves dropout active during “evaluation,” giving noisy, non-reproducible metrics.
• Device mismatches — moving the model to GPU but leaving a batch on CPU (or vice versa) is one of the most common real-world PyTorch errors.
• Reusing a model/optimizer across notebook cells without resetting — re-running a training cell without re-initializing model/opt continues training from wherever it left off, which is easy to mistake for “starting fresh.”

You know you’re done when…

• The printed loss trends downward across the 50 epochs, never flat or nan
• Final accuracy prints at or near 1.00
• torch.cuda.is_available() correctly reflects your actual hardware, so you’re not debugging “slow training” on a CPU-only box expecting GPU speed
• You can point to the exact three lines where gradients are cleared, computed, and applied
• You can explain why y is .long(), not .float(), for cross_entropy

Next

LLM Mastery — especially articles 11–27 (autograd through GPT internals). Pair with Getting Started with Python if the syntax still feels new.

Core verbs

SELECT id, title
FROM posts
WHERE published = TRUE
ORDER BY created_at DESC
LIMIT 10;

Aggregations:

SELECT author_id, COUNT(*) AS n_posts
FROM posts
GROUP BY author_id
HAVING COUNT(*) >= 3
ORDER BY n_posts DESC;

Joins — always explicit, never a bare comma:

SELECT u.name, p.title
FROM users u
JOIN posts p ON p.author_id = u.id
WHERE u.active = TRUE;

Mutations (use carefully in production):

INSERT INTO posts (author_id, title) VALUES (1, 'Hello');
UPDATE posts SET published = TRUE WHERE id = 42;
DELETE FROM comments WHERE id = 7;

Mental model

• Tables ≈ spreadsheets with types and constraints.
• Rows ≈ records; columns ≈ fields.
• JOIN stitches tables together on matching keys.
• GROUP BY collapses rows into buckets; HAVING filters buckets, WHERE filters rows before grouping.

Mini project: a blog schema with data you can verify

Use SQLite for zero setup — one binary, one file, no server.

sqlite3 blog.db

CREATE TABLE users (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  email TEXT NOT NULL UNIQUE
);

CREATE TABLE posts (
  id INTEGER PRIMARY KEY,
  author_id INTEGER NOT NULL REFERENCES users(id),
  title TEXT NOT NULL
);

CREATE TABLE comments (
  id INTEGER PRIMARY KEY,
  post_id INTEGER NOT NULL REFERENCES posts(id),
  user_id INTEGER NOT NULL REFERENCES users(id),
  body TEXT NOT NULL
);

INSERT INTO users (name, email) VALUES
  ('Asha', 'asha@example.com'),
  ('Ravi', 'ravi@example.com'),
  ('Meera', 'meera@example.com');

INSERT INTO posts (author_id, title) VALUES
  (1, 'Hello SQL'),
  (1, 'Joins Explained'),
  (2, 'Why Indexes Matter');

INSERT INTO comments (post_id, user_id, body) VALUES
  (1, 2, 'Great intro!'),
  (1, 3, 'Finally makes sense'),
  (2, 3, 'More examples please');

Now run three queries and verify each against the INSERTs above before trusting the output:

-- 1. All comments on post 1, with commenter names
SELECT c.body, u.name AS commenter
FROM comments c
JOIN users u ON u.id = c.user_id
WHERE c.post_id = 1;
-- expect exactly 2 rows: Ravi's and Meera's comments on 'Hello SQL'

-- 2. Top commenters by comment count
SELECT u.name, COUNT(*) AS n_comments
FROM comments c
JOIN users u ON u.id = c.user_id
GROUP BY u.name
ORDER BY n_comments DESC;
-- expect Meera first with 2 (she commented on posts 1 and 2), Ravi with 1

-- 3. Posts with zero comments
SELECT p.title
FROM posts p
LEFT JOIN comments c ON c.post_id = p.id
WHERE c.id IS NULL;
-- expect exactly 'Why Indexes Matter' (post 3 has no comments above)

If your output doesn’t match the comments in each query, re-count the INSERT statements — that mismatch is the whole point of the exercise: SQL results are always derivable by hand from small data, so “it looks right” is never good enough.

Common footguns

• WHERE x = NULL never matches anything — NULL isn’t equal to anything, including itself. Use WHERE x IS NULL / IS NOT NULL.
• SQLite is lenient about GROUP BY — it lets you SELECT a non-aggregated, non-grouped column without erroring (many other databases reject this outright). The value you get back is essentially arbitrary; only select columns that are either grouped or aggregated.
• Missing ON clause → cartesian join — FROM a, b without a join condition returns every combination of rows from both tables, which silently explodes result size on real data.
• LEFT JOIN + WHERE on the right table’s column (not IS NULL) — turns your outer join back into an inner join by accident, because WHERE comments.body = 'x' filters out the NULL rows the LEFT JOIN produced.
• SELECT * in application code — breaks silently when someone adds or reorders a column; name the columns you actually use.
• No index on a foreign key — joins on author_id or post_id do a full table scan once your tables grow past a few thousand rows; CREATE INDEX idx_posts_author ON posts(author_id); fixes it.

You know you’re done when…

• sqlite3 blog.db ".tables" lists users, posts, and comments
• All three exercise queries return exactly the row counts predicted in the comments above
• You can explain why WHERE comments.id IS NULL after a LEFT JOIN finds posts with no comments — and why WHERE comments.id = NULL would return nothing at all
• Every join in your queries uses explicit JOIN ... ON, never a bare comma
• You can name one column in this schema that would benefit from an index, and why

Next

APIs often wrap SQL — see Getting Started with FastAPI. RAG systems sometimes store metadata in SQL and vectors elsewhere — see LLM Mastery art. 40.

What “hands-on” actually means

Every course in the hub follows the same structure: a short code-along that introduces the day’s concept, a concrete task you complete yourself using that concept, and a capstone project at the end that forces you to combine everything from the earlier days. There’s no day that’s just “read about generics” with nothing to run afterward — if a day doesn’t produce code you executed and checked, it’s not in the course.

As an example, Go in 10 Days spends day one on goroutines and channels conceptually, then has you build a small concurrent worker pool that fetches a list of URLs in parallel and reports which ones failed — a task that only “works” if you actually understood the concurrency primitives, not just read about them.

The full list

• TypeScript — 10 days
• JavaScript — 10 days
• Rust — 10 days
• Go — 10 days
• Java — 10 days
• Kotlin — 10 days
• Swift — 10 days
• C++ — 10 days
• C# — 10 days
• Ruby — 10 days
• PHP — 10 days
• SQL — 10 days
• Zig — 7 days
• Bash — 7 days
• Python in 10 Days — already on the site

How to actually pick one

Don’t pick based on hype alone — match the language to what you’re trying to build next:

If you genuinely don’t know, Go or TypeScript are the safest defaults — both have large hiring markets, both are approachable in under two weeks, and both show up constantly in the backend/frontend split that most teams use.

Common footguns when learning a new language this way

• Course-hopping instead of finishing — starting three 10-day courses in the same week means finishing none of them; the daily tasks build on each other, and losing the thread halfway through is worse than not starting.
• Copy-pasting the code-along instead of typing it — you’ll pass the day’s task without understanding it, then stall on the capstone, which deliberately doesn’t hand you the pattern.
• Skipping the capstone — it’s the only part of each course that tests whether you can combine ideas from multiple days, which is the actual skill you’re building, not any single day’s syntax.
• Treating 10 days as “fluent” — these courses get you to “can read the language, can build something small and working, knows where to look next.” That’s the honest bar; real fluency takes shipping real code over months, not a sprint.
• Ignoring the language’s own tooling — every course leans on the language’s standard formatter/linter/test runner (gofmt, cargo test, rustfmt, etc.) rather than fighting it; skipping that step means fighting style debates with yourself for months afterward.

You know a course is actually done when…

• You completed the capstone without re-reading the day-by-day code-alongs from scratch
• You can write the “hello world” equivalent from memory, with correct syntax, no lookup
• You know the language’s standard way to run tests and format code, and have actually run both at least once
• You can explain the one or two concepts that felt hardest on day one, in your own words, without the course’s explanation in front of you
• You’ve pushed the capstone to a Git repo — see Getting Started with Git if that step itself is the unfamiliar part

Each course has daily code-alongs, a concrete task, and a capstone. Start at the hub and pick one language this week.

What “mastery” actually means here

Every article follows the same shape: one core idea, one piece of runnable code that demonstrates it, and one exercise that breaks if you don’t actually understand the idea. There are no slide-deck articles that just describe a concept in prose — if you can’t paste in code and watch a number change (a loss, an accuracy, a generated string), the article isn’t done. That’s a deliberate constraint on us, not just advice to you.

Who it’s for

• Beginners who want first principles, not marketing decks about “AI”
• Engineers who’ve called ChatGPT-style APIs and want to know what’s actually happening underneath
• Anyone willing to type code, watch loss curves, and debug shape mismatches at 11pm

You’ll get the most out of it if you’re comfortable with the material in our Getting Started with Python and Getting Started with PyTorch posts — you don’t need to be an expert in either, but you should be able to run a script from the terminal and read a RuntimeError without panicking.

Shape of the path

Start here: 01. What is a Language Model, Really?

A concrete sample, so this isn’t just a list of links

Article 4, Bigram Language Model, has you build the simplest possible language model — a table of “given this character, what’s the next one” counts — and generate text from it. It’s a handful of lines, it runs in under a second, and the output is obviously bad (mostly gibberish with occasional real words), which is the point: it gives you a concrete, terrible baseline to improve on for the next 46 articles. By article 27, Implement Tiny GPT, you’re writing the actual self-attention and feed-forward blocks yourself, not importing them from a library.

How much time it takes

Plan for 30–90 minutes per article if you type the code yourself rather than copy-pasting — and you should type it yourself, since transcription is where you notice what you don’t actually understand. Foundations and neural-guts articles (01–20) run comfortably on a CPU. Transformer-scale training (21–35 onward) benefits from a GPU, but every article’s code is written to run on a small config first so you can verify correctness before scaling up.

FAQ

Do I need a GPU? Not to follow along and understand the code. You’ll want one (even a modest one, or a free-tier cloud GPU) once you start training the larger configs in the transformers and post-training phases.

Do I need to finish all 50 in order? Foundations (01–10) and Neural guts (11–20) build directly on each other — don’t skip those. Once you’re through Transformers (21–35), the post-training articles are more modular; RAG (art. 40) and agents (art. 41) don’t require you to have done fine-tuning (art. 36) first.

What’s the capstone? Article 50, Capstone: Train Your Own, has you train a small GPT on a dataset of your choosing, end to end, using everything from articles 01–49 — your own tokenizer decisions, your own architecture choices, your own eval.

Warm-up posts, if you need tooling first

These getting-started posts are short, practical, and each ends with something you build and verify yourself:

• Python
• Git
• Linux shell
• Docker
• JavaScript
• SQL
• PyTorch
• FastAPI