DEV Community: Javi Palacios

Dockerfile Best Practices: Security

Javi Palacios — Tue, 25 Aug 2026 10:35:55 +0000

Run this against your current containers:

docker inspect $(docker ps -q) --format '{{ .Name }}: {{ .Config.User }}'

Most of them will return a blank after the colon. Blank means root. You're running production workloads as the most privileged user on the system, and nobody sent you a warning email about it.

Security in Dockerfiles isn't glamorous. It doesn't make it into conference talks the way Kubernetes migrations do. But these four practices are the difference between an image you can deploy to production with confidence and one that's a liability waiting to be discovered. The last lesson covered efficiency — fast builds, lean images. This one covers what keeps you employed.

Don't run as root

Every Docker container runs as root by default. Not a sandboxed root, not an elevated user — actual UID 0, the same root that owns your filesystem. The container is isolated, yes, but isolation has failure modes.

If your application has a vulnerability (and every application does), an attacker who compromises the process gets root-level access to everything in the container. If there's a container escape bug — rare, but they exist and get discovered — that root inside becomes root outside. The principle of least privilege isn't a DevSecOps buzzword; it's the reason you create separate database users instead of using postgres for everything.

# ❌ Default — process runs as root
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

# ✅ Non-root user
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

# Create non-root user and group
RUN groupadd --system appgroup && \
    useradd --system --no-create-home --gid appgroup appuser

# Transfer ownership, then switch
RUN chown -R appuser:appgroup /app
USER appuser

CMD ["python", "app.py"]

The order matters. WORKDIR creates the directory as root before your user exists. Create the user, transfer ownership, then switch — everything after USER appuser runs as that user, including the final CMD.

You can compress the setup into one layer:

RUN groupadd --system appgroup && \
    useradd --system --no-create-home --gid appgroup appuser && \
    chown -R appuser:appgroup /app
USER appuser

Official Node.js images include a node user out of the box, which saves a step:

FROM node:20-slim
WORKDIR /app
COPY package*.json .
RUN npm ci --only=production
COPY . .

# node user is already there in official Node.js images
RUN chown -R node:node /app
USER node

CMD ["node", "server.js"]

Scan for vulnerabilities

Your image inherits every vulnerability in its base image and installed packages. A fresh python:3.12-slim can carry dozens of CVEs that have nothing to do with your code. Most developers have no idea what's in their images because they've never looked.

Trivy is the de facto standard for image scanning — open source, fast, zero configuration to get started:

# macOS and Linux (Homebrew)
brew install trivy

# Ubuntu / Debian
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | \
  gpg --dearmor | sudo tee /usr/share/keyrings/trivy.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] \
  https://aquasecurity.github.io/trivy-repo/deb generic main" | \
  sudo tee /etc/apt/sources.list.d/trivy.list
sudo apt-get update && sudo apt-get install -y trivy

# Arch Linux (AUR)
paru -S trivy

Scan any image with one command:

trivy image python:3.12-slim

python:3.12-slim (debian 12.10)
===============================
Total: 47 (UNKNOWN: 0, LOW: 28, MEDIUM: 14, HIGH: 4, CRITICAL: 1)

That's not a contrived example — base images carry OS-level CVEs from Debian, OpenSSL, and system libraries. Most are LOW or MEDIUM: background noise you live with. HIGH and CRITICAL are what you act on. Filter to see only those:

trivy image --severity HIGH,CRITICAL my-app:latest

You can scan your own built images too, not just bases:

trivy image my-app:latest

If you're on Docker Desktop or Docker >= 24, Docker Scout is already installed and covers similar ground:

docker scout cves my-app:latest

Trivy tends to be more thorough and is what you'll see in most CI/CD pipelines. Scout is convenient if you prefer the Docker Desktop dashboard and don't want another CLI tool — for those who like their metrics with a GUI and don't mind clicking around (no judgment, it works).

Fixing vulnerabilities by rebuilding

Scanning tells you what's there. The fix is often simpler than expected: rebuild against an updated base image.

docker pull python:3.12-slim      # Pull the latest base
docker build --no-cache .         # Rebuild without cache to pick up updates
trivy image --severity HIGH,CRITICAL my-app:latest   # Check again

A surprising number of CVEs in "old" images disappear just from rebuilding. The maintainers of official images patch continuously. If you never rebuild, you never get those patches.

Pin versions correctly

The last lesson covered pinning your base image tag — python:3.12.10-slim instead of python:3.12-slim — for reproducibility. But tags have a security problem: tags are mutable.

Anyone with push access to a registry can overwrite a tag with different content. For official Docker Hub images this essentially never happens, but in CI/CD pipelines pulling from private registries or third-party sources, it's a real supply chain attack vector.

The immutable alternative is the SHA256 digest:

# Get the digest of an image
docker inspect python:3.12-slim --format='{{index .RepoDigests 0}}'

python@sha256:f4f0ef4e6a9a7bbd4954d6e5f4cd89b21f483d39beee63c3a17c840c10f5dd96

# ❌ Floating tag — can change without warning
FROM python:3.12-slim

# ✅ Pinned tag — better, but still mutable
FROM python:3.12.10-slim-bookworm

# ✅✅ SHA256 digest — immutable by definition
FROM python:3.12-slim@sha256:f4f0ef4e6a9a7bbd4954d6e5f4cd89b21f483d39beee63c3a17c840c10f5dd96

A digest is the hash of the image content. That image is exactly that image, forever, on any machine. If someone replaces the tag, the digest still points to the original content.

The same logic applies to system packages. Unpinned installs grab whatever's available today:

# ❌ Unpinned — installs whatever version is current
RUN apt-get update && apt-get install -y curl

# ✅ Pinned version — reproducible
RUN apt-get update && apt-get install -y curl=8.5.0-2ubuntu1

To see what versions are available:

apt-cache madison curl

Do you need digest pinning for every project? Probably not for a personal side project. Yes for production images handling sensitive data or sitting in regulated environments.

Secrets: what must never be in your image

This is where most people trip up. And it makes sense: you need credentials during development. The obvious solution is ENV or ARG in the Dockerfile. It's convenient, it works, and it's a ticking clock.

The obvious problem is "it ends up in git." The less obvious problem is worse: even if it never touches git, every Docker layer is permanently recorded in the image. Delete an ENV in a later layer and the value is still there, visible in the build history:

# ❌ The "cleanup" layer changes nothing
FROM python:3.12-slim
ENV API_KEY=super-secret-key-12345
RUN make some-api-call-using-the-key
RUN unset API_KEY   # Completely useless — still in the previous layer

docker history my-image --no-trunc
# IMAGE          CREATED BY
# ...            ENV API_KEY=super-secret-key-12345  ← visible forever

ARG has the same problem, despite what the docs imply. It doesn't persist as an environment variable in the final image — but it does persist in the layer of the RUN that used it:

ARG API_KEY
# ❌ The value is baked into this layer's metadata
RUN curl -H "Authorization: Bearer ${API_KEY}" https://api.example.com/setup

The right solution for build-time secrets is BuildKit's --mount=type=secret:

# syntax=docker/dockerfile:1
FROM python:3.12-slim
WORKDIR /app
COPY . .

# The secret is available only during this RUN — never stored in any layer
RUN --mount=type=secret,id=api_key \
    API_KEY=$(cat /run/secrets/api_key) && \
    curl -H "Authorization: Bearer ${API_KEY}" https://api.example.com/setup

Pass the secret at build time:

docker build --secret id=api_key,src=./secrets/api_key.txt .

The secret is mounted in a tmpfs during that specific RUN and never written to any layer. The # syntax=docker/dockerfile:1 line at the top enables BuildKit's extended syntax — without it, Docker won't recognize the --mount option.

For runtime secrets — database passwords, API tokens your application needs while running — the answer is straightforward: don't put them in the image. Runtime secrets are injected from outside, at deploy time:

# ✅ The image contains no credentials
FROM python:3.12-slim
WORKDIR /app
COPY . .
RUN groupadd --system appgroup && \
    useradd --system --no-create-home --gid appgroup appuser && \
    chown -R appuser:appgroup /app
USER appuser
CMD ["python", "app.py"]
# The app reads DATABASE_URL from the environment at runtime — never from the image

# In development
docker run -e DATABASE_URL=postgres://... my-app

# In production with Docker Compose
services:
  app:
    image: my-app:latest
    environment:
      DATABASE_URL: ${DATABASE_URL}  # From the host environment, never in the Dockerfile

For more rigorous setups: Docker Secrets in Swarm, Kubernetes Secrets with proper RBAC, or a dedicated secrets manager like HashiCorp Vault. But even the basic pattern of injecting at runtime is infinitely better than credentials baked into a layer that follows the image everywhere it goes.

Non-root user, vulnerability scanning with Trivy, immutable digests instead of mutable tags, secrets out of the image. Four practices that aren't complicated — they just require actually doing them.

Next up is one of the most powerful Docker features for production images: multi-stage builds. You'll learn how to separate the build environment from the runtime environment, with real examples in Go and Node.js that shrink final image sizes from hundreds of megabytes down to a fraction.

Never stop coding!

💡 Challenge: Take your image from the previous lesson's challenge. Add a non-root user and scan it with trivy image --severity HIGH,CRITICAL. Then compare against python:3.12-alpine — there's a surprise waiting for you there.

Git Flow: a workflow for managing releases

Javi Palacios — Mon, 24 Aug 2026 09:17:31 +0000

It's 4 PM and the PM just posted in the team chat: "can we ship version 2.1 today?" You open the repository to check. Feature A is half-done on its branch. Feature B hasn't been touched in three days and isn't merged. Someone is fixing a production bug locally and hasn't pushed. And main has three commits from this week that nobody remembers — are they release candidates or experiments?

Can you ship? What goes in and what doesn't? How do you separate what's ready from what isn't?

Git Flow is the answer to exactly that question. It's not a Git feature — it's a convention about how to organize branches so the team always knows what's in production, what's in development, and how to move between them in a controlled way.

The core idea: two types of branches

Before the details, the concept that holds everything together: Git Flow draws a hard line between code that is production and code that is headed toward production.

Two permanent branches handle this:

main — always production-ready. Every commit on main represents a deployable version. It never has half-finished work. Every time something lands on main, it gets a version tag.

develop — where work in progress gets integrated. It's the team's staging branch: finished features flow into it, releases are prepared from it, and it always reflects where the next version is headed.

The separation between main and develop is the core of Git Flow. main is sacred — it only receives merges from release branches or hotfixes, never direct work.

The temporary branches

On top of those two permanent branches, Git Flow defines three types of temporary branches. Each has a specific origin and a specific destination — and that's what gives the workflow its structure.

feature/

Your day-to-day working branches. Following the branch naming conventions from the last tutorial, each feature branch corresponds to a specific functionality or ticket.

Origin: develop
Destination: develop

# Start a feature from develop
git switch develop
git switch -c feature/123-user-auth

# ... work, commit, work, commit ...

# Merge back into develop
git switch develop
git merge --no-ff feature/123-user-auth
git branch -d feature/123-user-auth

The --no-ff (no fast-forward) flag matters: it always creates an explicit merge commit even when a fast-forward is possible. That preserves in the history the fact that those commits belonged to a feature branch — useful context months later when someone's trying to understand why that code exists.

Feature branches never touch main. Not ever. If a feature isn't ready for the release, it simply doesn't get included.

release/

When develop has enough finished work to justify a new version, you create a release branch. Only bug fixes go in here — no new features. The goal is stabilization, not expansion.

Origin: develop
Destination: main and develop

# Create release branch from develop
git switch develop
git switch -c release/2.1.0

# ... fix bugs, update version numbers ...

# Merge into main (with version tag)
git switch main
git merge --no-ff release/2.1.0
git tag -a v2.1.0 -m "Release version 2.1.0"

# Also merge back into develop (to keep the bugfixes)
git switch develop
git merge --no-ff release/2.1.0

git branch -d release/2.1.0

The double merge can look surprising at first. Why also merge back into develop? Because the bug fixes that went into the release branch need to live in future code too. If you only merged into main, those fixes would disappear in the next version — and you'd spend a baffling amount of time re-fixing bugs that were "already fixed." This is the step teams most often forget, and the one that causes the most head-scratching six months later.

hotfix/

For when something breaks in production and can't wait for the next release. It's the only branch type that starts directly from main.

Origin: main
Destination: main and develop

# Create hotfix from main
git switch main
git switch -c hotfix/561-payment-gateway-timeout

# ... fix the bug ...

# Merge into main
git switch main
git merge --no-ff hotfix/561-payment-gateway-timeout
git tag -a v2.0.1 -m "Hotfix: payment gateway timeout"

# Also merge into develop
git switch develop
git merge --no-ff hotfix/561-payment-gateway-timeout

git branch -d hotfix/561-payment-gateway-timeout

Same double merge, same reason: the fix needs to be in the next release too, not just in the version that's currently deployed.

The full picture

Put together, the branch diagram of a project using Git Flow looks like this:

         v1.0          v2.0    v2.0.1
main  ────●─────────────●────────●────────────▶
           \           ↑ \      ↑ \
develop  ───●──●──●──●──/──●────/──●──●──▶
                 \  /       \  /
feature          ●─●         ●─●
                        ↑
                   release/2.0

develop advances continuously. Features branch off and merge back into it. When there's enough for a release, the release branch goes out, gets stabilized, and lands on main with its version tag. Hotfixes go directly from main and propagate to both branches.

Does this feel like a lot of moving parts? It is. Git Flow doesn't aim to be simple — it aims to be predictable. On a team of four people, predictable is worth a lot more than simple.

The git-flow extension

All of this can be done with plain Git commands (as in the examples above), but there's an extension that automates the repetitive steps: git-flow, created by the same Vincent Driessen who designed the workflow in 2010 (in a blog post that has since accumulated roughly 18 million views — turns out a lot of teams had this problem).

# macOS and Linux (Homebrew)
brew install git-flow-avh

# Ubuntu / Debian
apt install git-flow

# Arch Linux (AUR)
paru -S gitflow-avh

Initialize it in your repository:

git flow init

The command asks a few questions about branch naming (defaults are main, develop, feature/, etc.). Once configured:

# Start a feature
git flow feature start 123-user-auth
# Equivalent to: git switch -c feature/123-user-auth develop

# Finish a feature
git flow feature finish 123-user-auth
# Equivalent to: merge into develop, delete branch

# Start a release
git flow release start 2.1.0

# Finish a release
git flow release finish 2.1.0
# Equivalent to: merge into main + tag + merge into develop + delete branch

# Start a hotfix
git flow hotfix start 561-payment-timeout

# Finish a hotfix
git flow hotfix finish 561-payment-timeout

The extension doesn't do anything you can't do by hand, but it eliminates the cognitive load of remembering all the steps — especially the double merge, which is easy to skip when you're in a hurry. For those who prefer a visual interface, GitKraken and SourceTree both have native Git Flow support, if you don't mind waiting for an Electron app to load.

When to use Git Flow (and when not to)

Git Flow has a reputation that isn't entirely unfair: it's a complex workflow. Many steps, many branches, merging things in two places. Apply it to a project that doesn't justify it and you add ceremony without benefit.

It makes sense when:

The project has versioned releases: libraries, SDKs, mobile apps, packaged software
Multiple developers are working on parallel features that need to stay isolated from each other
You need to maintain multiple production versions simultaneously (hotfixes on v2.0 while v2.1 is in development)
The team has a clear, scheduled release cycle — not continuous deployment

It doesn't make sense when:

Your team does continuous deployment — every merge to main goes to production in minutes. In that context, develop adds nothing, because "production" and "in development" are practically the same thing
The project is small or you're working alone
Your release cadence is very short (multiple times per day)

For those cases, the next tutorial covers GitHub Flow: a deliberately simpler workflow built for continuous deployment. One stable branch, short-lived feature branches, and deploy directly after merge. Fewer moving parts, less friction, enough structure for most modern web projects.

Git Flow isn't the most popular workflow nowadays — that's probably trunk-based development. But it remains the reference for understanding how to separate work in progress from production code, and plenty of projects with versioned releases still use it for exactly that reason. Understanding it gives you the vocabulary to reason about any branching workflow, however simplified.

💡 Challenge: Think about a project you've worked on (or know well). Which scenario fits it better: versioned releases with parallel work, or continuous deployment? Would Git Flow add value or just overhead? Reason through the answer using the criteria from this lesson.

Never stop coding!

Branch naming conventions in Git

Javi Palacios — Sat, 22 Aug 2026 12:31:44 +0000

You join a new project. Clone the repo. Run git branch -a to get a feel for the landscape. This is what you find:

  remotes/origin/test
  remotes/origin/test2
  remotes/origin/test-final
  remotes/origin/johns-branch
  remotes/origin/new-feature
  remotes/origin/new-feature-v2
  remotes/origin/TEMP
  remotes/origin/fix
  remotes/origin/actual-fix
  remotes/origin/DO-NOT-MERGE
  remotes/origin/main

Eleven branches. Zero information. Which ones are merged? What's in johns-branch — and does John still work here? When was TEMP created, and does anyone know what happens if you delete it? What's the difference between fix and actual-fix, and which one made it to production?

The problem isn't that there are branches. Branches are one of Git's best features. The problem is that without a naming convention, each developer on the team invents their own system — and the remote ends up looking like a graveyard where you know things are buried but have no idea where.

Why branch names matter

It's easy to think of a branch name as a minor detail, a label that only matters while the branch is alive. That framing is wrong.

A branch name is a temporary contract with your team. It communicates what kind of work the branch contains, which ticket or feature it's tied to, and when it's appropriate to delete it. Without that contract, every branch interaction starts with the same question: "wait, what is this?"

Three signs you have a naming problem:

Someone asks "can I delete this branch?" and no one knows the answer
You run git branch -a and spend more time reading names than doing actual work
There are two active branches called feature-new and feature-new-v2 and no one remembers which one is current

A good naming convention makes the branch self-documenting.

The common patterns

Most teams use a prefix that describes the type of work, separated from the rest of the name by a forward slash:

feature/user-authentication
fix/null-check-in-api-endpoint
hotfix/critical-payment-failure
release/2.3.0
chore/update-dependencies
docs/api-reference-v2

The most common prefixes:

Prefix	When to use
`feature/` or `feat/`	New functionality
`fix/` or `bugfix/`	Bug fix during active development
`hotfix/`	Urgent fix going straight to production
`release/`	Release preparation branch
`chore/`	Maintenance: dependencies, config
`docs/`	Documentation-only changes
`refactor/`	Code refactoring without behavior change
`test/`	Adding or fixing tests

If the commit best practices tutorial from last lesson looks familiar, you'll notice the prefixes map directly to Conventional Commits types — that's not a coincidence. When your branches and your commits speak the same language, the project history becomes much easier to read at a glance.

You don't need to use all of them. A small team running feature/, fix/, and hotfix/ has everything it needs. The key isn't exhaustiveness — it's consistency.

Including the issue number

The type prefix is half the information. The other half is knowing which ticket or issue the branch corresponds to. The most widely used convention puts the issue number before the description:

feature/123-user-authentication
fix/482-null-response-user-endpoint
hotfix/561-payment-gateway-timeout

The number comes first for a practical reason: branches sort alphabetically in most tools, and putting the number first automatically groups branches for the same issue together. It also makes searching trivial — if you know the ticket number, you can filter directly.

GitHub and GitLab also recognize issue numbers in branch names and link them automatically in the interface — a small detail that saves a surprising amount of navigation over time.

If your team doesn't use an issue tracker (it happens, no judgment), just use the description alone. But if you do, the number is free and there's no reason not to include it.

Format rules

A branch name is going to appear in git log, in pull requests, in CI/CD output, and possibly in changelogs. Worth making it look right in all of those contexts.

Always kebab-case: lowercase, words separated by hyphens. No spaces (Git converts them and the result is a mess), no underscores, no camelCase.

feature/user-auth          # ✅
feature/userAuth           # ❌
feature/user_auth          # ❌
feature/User Auth          # ❌ (and Git will complain)

Descriptive but not a paragraph: the name should be readable in git log --oneline. feature/123-add-email-verification-to-user-registration-flow is technically correct but unnecessarily verbose. feature/123-email-verification says the same thing.

Avoid "new", "final", "v2": these names age badly. feature/new-login becomes meaningless as soon as there's a second login implementation. hotfix/final-fix is a promise no software can keep.

No personal names on shared branches: johns-branch is fine locally while you're exploring something. On the remote, a personal name carries no information relevant to the rest of the team — and once John leaves, the branch sits there forever, a mystery for everyone who comes after.

Team conventions vs personal preferences

If you work alone, you can be as informal as you like with local branch names. No one's going to judge a branch called wip-attempt-3 on your machine.

On the remote, though, names are public. And a name that makes perfect sense to you right now might mean nothing to a teammate next week, or to yourself in three months (which is essentially the same thing).

The most sustainable way to keep a convention alive on a team is to document it somewhere visible before someone creates their first branch — in the README.md, in CONTRIBUTING.md, or better yet, enforce it with a Git hook that validates the format automatically. It doesn't need to be sophisticated — a pre-push script that checks the name starts with a recognized prefix already eliminates 90% of poorly named branches without anyone having to play enforcer.

If you're like me when I started, conventions can feel like unnecessary overhead. The project is moving fast, the branch name is the least of your problems, you'll sort it out later. You won't. And when you have 80 branches on the remote and no one knows what's safe to delete, you'll remember this conversation.

Branch lifecycle

Branches have an expiration date. They're created for a specific purpose, they get merged, and they should die. In practice, they rarely do.

To see which branches are already merged into main:

git branch --merged main

To delete a local branch that's been merged (safe — Git won't delete it if it has unmerged changes):

git branch -d feature/123-user-auth

To delete it even if it hasn't been merged (you're scrapping that work):

git branch -D feature/abandoned-experiment

The capital D is intentional — it's the "do it even though you think it's a bad idea" flag. Use it when you know what you're doing, not as a way to make Git stop complaining.

To delete a branch on the remote:

git push origin --delete feature/123-user-auth

And to clean up local references to remote branches that no longer exist:

git fetch --prune
# or equivalently
git remote prune origin

If you'd rather manage all of this visually, lazygit has a dedicated branch view where you can browse, delete, and navigate entirely by keyboard — no syntax to remember, no Electron, no fan heroics. For those who prefer a mouse, GitLens in VS Code covers this reasonably well too.

A naming convention doesn't fix architectural problems or make the code better. But it eliminates an entire class of questions that shouldn't be questions: what's in here? Is this merged? Can I delete it? With consistent names, those answers live in the name itself.

In the next tutorial, we'll look at Git Flow: the workflow that takes these branch prefixes and formalizes them into a structured process with clear roles for main, develop, feature/, release/, and hotfix/ — a way to coordinate work across a team where multiple people are pushing to the same repository at the same time.

💡 Challenge: Open a repository you've worked on (or any popular open source project on GitHub) and run git branch -a. Evaluate the names against the conventions in this lesson — which ones are self-documenting? Which ones require additional context to understand? If you were naming those branches today, what would you call them?

Never stop coding!

Visual mode in Vim: select, operate, own it

Javi Palacios — Fri, 21 Aug 2026 11:35:18 +0000

Most people discover Visual mode and feel a small wave of relief: finally, something familiar. Select text, then do something with it. That's how every other editor works. That's how your hands already think.

That's a perfectly fine starting point. The problem is if you stop there — using Visual mode as "keyboard-driven mouse selection" and nothing else. Because there are two things here that go well beyond that: operators that behave differently in this context, and a block mode that does things VS Code needs a plugin to simulate.

The three Visual modes

Visual mode isn't one thing — it's three, each with distinct behavior:

Command	Mode	What it selects
`v`	Characterwise	Character by character
`V`	Linewise	Full lines, regardless of cursor position
`Ctrl+v`	Blockwise	A rectangular region (columns across multiple lines)

v is the intuitive one. Press v, move the cursor, the selection grows. Every Normal mode motion works: w, e, $, gg, G, even search patterns. If you can navigate in Normal mode, you already know how to select in characterwise Visual.

V always grabs full lines. It doesn't matter where the cursor is when you enter — you get the entire current line, and each movement extends by whole lines. Useful when you're working with code blocks where character-level precision doesn't add anything.

Ctrl+v is the interesting one. Its own section.

`gv`: bring back the last selection

A small command worth knowing early: after operating on a selection and returning to Normal mode, gv restores exactly your last visual selection. Useful when you indented with > but not enough, or when you want a second operation on the same range without reselecting from scratch.

Operating on a selection

With text selected, the most useful commands are:

Command	What it does to the selection
`d`	Delete the selection
`c`	Delete the selection and enter Insert
`y`	Yank (copy) the selection
`>`	Indent the selection
`<`	Dedent the selection
`=`	Auto-format the selection
`~`	Toggle case
`u`	Lowercase
`U`	Uppercase

Don't try to memorize all of this now. d, y, and > cover 90% of real-world usage. The rest will show up naturally when you need them.

One combination worth learning early: vap — enters Visual mode and selects the entire paragraph (the text object ap = "a paragraph"). In code, a paragraph is a contiguous block with no blank lines separating it: a Python function, an HTML element, a JSON object. vap + > indents it, vap + d deletes it, vap + y copies it.

Block Visual mode

Here's where things get genuinely interesting.

Ctrl+v activates blockwise Visual mode. Instead of selecting characters or full lines, you select a rectangle: a column range across multiple lines simultaneously. Move three lines down and five columns right — you've selected exactly that rectangular area.

The most common use case: inserting the same text at the start of multiple lines at once.

" You have this code:
const name = 'Alice'
const age  = 30
const role = 'admin'

" You want to comment out all three lines with //
" 1. Place the cursor on the 'c' of the first line
" 2. Ctrl+v → activate blockwise Visual
" 3. 2j → extend the selection two lines down
" 4. I → enter Insert at the start of the selection
" 5. //  → type the comment (you only see it on the first line)
" 6. Esc → Vim replays the Insert across every line in the block

That Esc at the end is the magic moment: what you typed appears on all the lines at once. This is Vim's multiple cursors — no plugins, no Ctrl+D from VS Code, no Alt+click. Just Ctrl+v, I, text, Esc.

The same mechanic works with A instead of I to append at the end of each line — even if the lines have different lengths, Vim extends the selection to match the longest one.

If this feels like a magic trick, that's because it kind of is. Block Visual mode is one of those features that turns someone who uses Vim because they have to into someone who starts to get why people are so loud about it.

Visual vs Vim's grammar: when to use each

After learning Visual mode, someone always asks: "why bother selecting with Visual when I can just do d3w or ci" straight from Normal mode?"

Fair question. Honest answer: each one wins in different situations.

Use Visual when:

You don't know exactly where the range ends and need to see it before committing
The selection has an irregular shape that no single motion describes cleanly
You want to apply multiple operations to the same range (gv + operation)

Use operator-motion when:

You know exactly what you want and the motion describes it precisely
You're going to repeat the operation with . — because Visual mode breaks that repeatability

That last point is what most people miss early on. When you do d3w in Normal mode, . can replay it exactly — three words deleted, wherever the cursor ends up next. When you select with v and then delete, . only repeats the deletion but not the selection. It loses the "shape" of the change.

If you're making the same edit in multiple places, Normal mode's grammar with operators and motions is faster and repeatable. If you're doing it once and need to see the range before confirming, Visual is the right call.

Key concepts from this lesson

Three variants: v (characterwise), V (linewise), Ctrl+v (blockwise)
gv restores the last visual selection — operate on the same range without reselecting
vap selects the entire paragraph — works well with code blocks
Block Visual + I / A + text + Esc = multiple cursors with no plugins
When to use Visual: uncertain range, irregular shape, no need to repeat with .
When to use operator-motion: known range, repeatable change, serial edits

Visual mode completes the trio of core Vim modes. From here the learning curve shifts: what comes next isn't more modes — it's ways to move faster. The next tutorial covers searching with /, ?, and * — how to jump anywhere in a file in a handful of keystrokes.

Never stop coding!

Lists in Python: your first data structure

Javi Palacios — Thu, 20 Aug 2026 10:49:47 +0000

At some point, one variable isn't enough. You're writing a program to track a shopping cart, a list of players in a game, or the results of a search — and you need to store multiple values that belong together. You could create product_1, product_2, product_3... but we both know where that ends up.

That's what lists are for.

What is a list?

A list is an ordered collection of elements. Ordered doesn't mean alphabetically sorted — it means every element has a fixed position, and that position is how you reach it. Think of it as a numbered row of slots: you know exactly where everything is.

products = ["shirt", "pants", "sneakers"]
numbers = [1, 2, 3, 4, 5]
mixed = [42, "hello", True, 3.14]   # Python allows mixed types

Square brackets, elements separated by commas. If you're coming from Java or C, you're waiting for the type declaration and the size. Python doesn't ask. A list is created with whatever you give it, grows when you need it to grow, and shrinks when you remove things.

An empty list is perfectly fine — you'll create it first and fill it as you go:

cart = []   # Empty list, will be filled as the user shops

Accessing elements: the index

Every position in a list has a number called an index. Indices start at 0, not 1:

fruits = ["apple", "pear", "grape", "kiwi"]
#           0         1       2        3

print(fruits[0])   # "apple"
print(fruits[2])   # "grape"

The first element is always 0. It seems arbitrary until you start doing position arithmetic and it makes complete sense — but that's a conversation for another day.

Try to access an index that doesn't exist, and Python won't guess or make something up:

print(fruits[10])   # IndexError: list index out of range

The IndexError is the most common error when working with lists. You'll see it. You'll be annoyed by it exactly once. After that, you'll know where the problem is before you even finish reading the traceback.

Negative indices

What if you need the last element of a list but you don't know how many elements it has? Calculate the length and subtract one? Python has something better: negative indices.

[-1] is always the last element. [-2] is second to last. And so on:

fruits = ["apple", "pear", "grape", "kiwi"]

print(fruits[-1])   # "kiwi"  — last
print(fruits[-2])   # "grape" — second to last
print(fruits[-4])   # "apple" — same as [0]

Without negative indices, "give me the last element" would be fruits[len(fruits) - 1]. With them, it's fruits[-1]. The difference isn't just shorter — it's that when you read this code three weeks from now, fruits[-1] says exactly what it does with no mental overhead.

Slicing: extracting a range of elements

You've been accessing one element at a time with [index]. Slicing lets you grab a range of elements with [start:end]:

fruits = ["apple", "pear", "grape", "kiwi", "orange"]

print(fruits[1:3])   # ["pear", "grape"] — indices 1 and 2, not 3
print(fruits[:2])    # ["apple", "pear"] — from start to index 1
print(fruits[2:])    # ["grape", "kiwi", "orange"] — from index 2 to end
print(fruits[:])     # All elements — a full copy

The pattern is the same as range(): start is included, end is not. If you remember that from the previous lesson on for loops, you already know how this works — Python uses this convention consistently.

You can also add a step, just like range(start, stop, step):

numbers = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

print(numbers[::2])    # [0, 2, 4, 6, 8] — every other element
print(numbers[::-1])   # [9, 8, 7, 6, 5, 4, 3, 2, 1, 0] — reversed

That [::-1] to reverse a list is one of those Stack Overflow answers that gets forty upvotes and zero comments explaining what's happening. It's not magic — it's a negative step that walks the list from the end to the beginning. Now you know what you're looking at when you see it.

Iterating with for

You already did this in the previous lesson. for loops and lists are a natural fit — lists are exactly the kind of sequence the Python for was built for:

fruits = ["apple", "pear", "grape", "kiwi"]

for fruit in fruits:
    print(fruit)

apple
pear
grape
kiwi

If you need the index alongside the value, use enumerate():

for index, fruit in enumerate(fruits):
    print(f"{index}: {fruit}")

0: apple
1: pear
2: grape
3: kiwi

enumerate() gives you pairs of (index, element). It's the right way to iterate over a list when you need the position. The alternative — looping with range(len(fruits)) and accessing with fruits[i] — works, but it's a tell that you learned another language before Python.

len() and the in operator

Two tools you'll use constantly with lists:

len() returns the number of elements:

fruits = ["apple", "pear", "grape", "kiwi"]
print(len(fruits))   # 4

in checks if an element is in the list:

print("pear" in fruits)     # True
print("banana" in fruits)   # False

And not in for the opposite:

if "banana" not in fruits:
    print("No bananas here")

Together, these answer the two most common questions you'll have about a collection: how many things are in here, and is this specific thing in here? With len() and in, 80% of those checks are a single line.

You can now create lists, access elements by position (positive and negative), extract ranges with slicing, iterate with for and enumerate(), and check membership with in. That covers the reading side. The next tutorial covers writing: adding elements with append(), removing them with remove(), and a first look at list comprehensions — one of those Python features that feels like it shouldn't work until you run it and it just does.

Never stop coding!

💡 Challenge: Create a list with the names of five movies you like. Then: (1) print the first and last using positive and negative indices respectively; (2) display the three in the middle using slicing; (3) ask the user for a movie title and tell them whether it's in your list; (4) print all movies numbered from 1 onward using enumerate(). Bonus: add a sixth movie before printing the full list (you'll need append() — covered in the next tutorial, but feel free to look it up).

Dockerfile Best Practices: Layer Caching and Efficiency

Javi Palacios — Wed, 19 Aug 2026 14:04:17 +0000

You change one line in your app. Save. Run docker build. And wait. And wait.

Two and a half minutes for a one-line change. Exactly as long as it takes when it installs all your dependencies from scratch. Because it does — every single time.

Here's where it gets interesting.

Docker has a layer caching system that, when used correctly, makes 90% of your builds nearly instant. The catch is that it doesn't behave in an obvious way until someone explains it. Every Dockerfile instruction creates a layer, and Docker only rebuilds starting from the first layer that changed. Everything before it? Straight from cache.

The order of your instructions isn't decorative. It's performance.

How Docker's layer cache works

When you run docker build, Docker processes each instruction in order and checks: did I already build this layer? If the instruction and its inputs are identical to last time, it uses the cache. If anything changed, it rebuilds that layer from scratch — and every layer after it too.

That "every layer after it" is what bites you. The cache invalidates in a cascade. Once one layer changes, all subsequent layers get rebuilt even if nothing about them changed.

Look at this classic Dockerfile from someone who just learned the basics:

# ❌ Layer order that destroys the cache
FROM python:3.12-slim
WORKDIR /app
COPY . .                                    # Copy everything first
RUN pip install -r requirements.txt         # Then install dependencies
CMD ["python", "app.py"]

The problem? COPY . . copies your entire project — app code, config files, assets, everything. Every time you change a single line of code, that layer gets invalidated. And everything after it — including dependency installation — rebuilds from scratch.

# ✅ Layer order that uses the cache
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .                     # Only the dependency manifest
RUN pip install -r requirements.txt         # Cached unless requirements.txt changed
COPY . .                                    # Code goes last
CMD ["python", "app.py"]

With this order, Docker only reinstalls dependencies when requirements.txt actually changes. Modify your app code? The first three layers hit cache and the build takes seconds.

The golden rule: what changes rarely goes near the top; what changes often goes near the bottom.

What this looks like in practice

This isn't premature optimization. On a medium-sized Python project:

# Badly ordered Dockerfile — you change app.py:
[+] Building 47.3s (8/8) FINISHED
 => [1/4] FROM python:3.12-slim                0.1s  (cached)
 => [2/4] WORKDIR /app                         0.0s  (cached)
 => [3/4] COPY . .                             0.4s  ← full project copy
 => [4/4] RUN pip install -r requirements.txt 46.1s  ← reinstalls everything

# Well-ordered Dockerfile — you change app.py:
[+] Building 0.8s (8/8) FINISHED
 => [1/4] FROM python:3.12-slim                0.0s  (cached)
 => [2/4] WORKDIR /app                         0.0s  (cached)
 => [3/4] COPY requirements.txt .              0.0s  (cached)
 => [4/4] RUN pip install -r requirements.txt  0.0s  (cached) ← already done
 => [5/5] COPY . .                             0.2s

47 seconds versus under one. Same Dockerfile, different order.

If you're like me when I started, you've been through that loop: make a tiny change, kick off the build, go refill your water, come back just in time to see it finish. The right layer order eliminates that loop entirely.

Combining `RUN` commands

Every RUN instruction in your Dockerfile creates a new layer. Each layer adds overhead to image size and pull times. The trick is combining related RUN instructions into one, especially when installing system packages:

# ❌ Three unnecessary layers
RUN apt-get update
RUN apt-get install -y curl wget
RUN rm -rf /var/lib/apt/lists/*

# ✅ One single layer
RUN apt-get update && apt-get install -y \
    curl \
    wget \
    && rm -rf /var/lib/apt/lists/*

The rm -rf /var/lib/apt/lists/* cleanup at the end is critical — and it must be in the same RUN. Put it in a separate RUN and Docker creates a layer that "deletes" those files, but they still exist in the previous layer. Your image ends up the same size with an extra layer that pretends to clean up without actually doing it.

For Node.js, the equivalent:

# ✅ Install and clean in a single step
RUN npm ci --only=production \
    && npm cache clean --force

Don't stress about cramming everything into one giant monolithic RUN. Combine instructions that are logically related — install plus clean, configure plus compile. Instructions that don't share state can stay separate.

If you want to see exactly what's in each layer — and why your image weighs what it weighs — dive is the CLI for that: interactive layer inspection, size per layer, and which files each instruction touched. No Electron, no waiting for an app to load.

`.dockerignore`: the build context matters

You saw .dockerignore in the last lesson as a way to keep secrets out of your image. There's an equally important reason almost nobody mentions: build speed.

Think about it. You have a Node.js project. How big is node_modules? 200 MB? 500 MB? That directory everyone has on their machine and pretends not to look at? The build context is everything Docker packages and sends to the daemon before executing the first instruction — not just what you COPY into the image, but everything in the directory. Without .dockerignore, Docker packages and ships all those hundreds of MB on every build, even if they never make it into the image.

If you've used Git, .dockerignore works exactly like .gitignore: same glob syntax, same idea, different destination. Your existing .gitignore already excludes most of what you don't want in the build context — use it as a starting point and add Docker-specific entries on top.

A complete .dockerignore for a Node.js project:

# Dependencies
node_modules
npm-debug.log
yarn-error.log

# Test coverage
coverage
.nyc_output

# Build output
dist
build
.next
out

# Environment and secrets
.env
.env.local
.env.*.local

# Git history
.git
.gitignore

# OS files
.DS_Store
Thumbs.db

# IDE config
.vscode
.idea

And for Python:

# Virtual environments
venv
.venv
env

# Python bytecode
__pycache__
*.pyc
*.pyo
*.pyd

# Test coverage
.pytest_cache
htmlcov
.coverage

# Build artifacts
dist
build
*.egg-info

# Git
.git

# Environment
.env

The rule: if Docker doesn't need that file to build the image, don't send it.

Choosing the right base image

Your FROM choice determines your image's starting size, the vulnerabilities it inherits, and how long it takes to pull. A decision that looks trivial with consequences that aren't.

The most common Python variants — and the logic applies to any runtime:

python:3.12         → ~1.02 GB   (full Debian, everything included)
python:3.12-slim    →  ~148 MB   (Debian without extras)
python:3.12-alpine  →   ~57 MB   (Alpine Linux, minimum possible)

The temptation is to go straight for Alpine because it's the smallest. This is where things get genuinely weird.

Alpine uses musl libc instead of glibc. Most of the time that's invisible. But Python libraries with C extensions — numpy, pandas, Pillow, basically everything that does anything useful — don't have precompiled wheels for Alpine. So what does pip do? Compiles them from source. During the build. Along with all the headers and tooling that requires installing first.

The result: you picked the smallest base image to be efficient, and your build now takes 10 minutes instead of 30 seconds. You optimized for size and got the opposite. That's the Alpine tax that every "reduce your Docker image size" tutorial conveniently leaves out.

The practical recommendation:

-slim: the sensible starting point for most projects. Significantly smaller than full, without Alpine's compatibility headaches.
-alpine: for simple tool images, Go binaries, or when you've verified there are no incompatible dependencies.
Full (no suffix): only when you need specific Debian build tools you can't install yourself.

One more thing: pin your version. Don't use python:3.12-slim; use python:3.12.10-slim. Floating tags can silently change with a docker pull. In production, that kind of surprise tends to happen at the worst possible moment.

# ❌ Floating tag — can change without warning
FROM python:3.12-slim

# ✅ Pinned version — reproducible everywhere
FROM python:3.12.10-slim-bookworm

There's more to explore — distroless images from Google, Chainguard images, BuildKit's parallel execution. But what's in this lesson already gets you fast builds and lean images for real-world projects.

Layer cache with the right ordering, combined RUN instructions, a solid .dockerignore, and a sensible base image choice. Four practices that directly affect the time you spend staring at a terminal.

In the next lesson, we get to the part everyone tends to ignore until it's too late: Dockerfile security best practices. We'll cover why running as root inside a container is a terrible idea, how to scan for vulnerabilities, and how to handle secrets without baking them into your image for eternity.

Never stop coding!

💡 Challenge: Take the Dockerfile from the previous lesson's challenge (the Flask app). Change one line of app code and rebuild with docker build. Watch which layers rebuild. Then reorder the Dockerfile so dependency installation gets cached correctly, rebuild again with a code change, and compare the times. The docker build output will tell you exactly what hit cache and what didn't.

Git commit best practices

Javi Palacios — Fri, 14 Aug 2026 09:43:32 +0000

There's a particular kind of dread that only developers know: running git log --oneline on a project you wrote two years ago and finding this:

a1b2c3d fix
e4f5g6h wip
i7j8k9l more stuff
m0n1o2p trying something
q3r4s5t FINAL
u6v7w8x FINAL_REAL_THIS_TIME

The bad part isn't seeing it. The bad part is recognizing the handwriting. You wrote those commits. In a period of your life when you apparently had better things to think about.

The problem isn't aesthetic — it's functional. When you run git bisect three months from now to track down a regression and Git points at q3r4s5t FINAL_REAL_THIS_TIME as the culprit, the history will tell you nothing. You'll have to read the full diff line by line to figure out what changed, why, and whether it was intentional. Repeated for every commit in the range. At 2 AM.

A well-written commit history is living documentation. This lesson is about how to write one.

The atomic commit principle

Before talking about format, the most important idea: each commit should contain exactly one logical change.

Not "Tuesday's work." Not "everything from the sprint." One change, well-scoped, with its context.

Why does this matter so much?

git bisect works: each commit is independently verifiable. A commit that mixes five changes tells you nothing when bisect points at it.
git revert is painless: undoing an atomic commit is clean. Undoing one that mixes a refactor, a migration, and a CSS fix is not.
git cherry-pick becomes possible: you can move a specific change to another branch without dragging unrelated things along.
Code review is faster: the reviewer sees a single, clear unit. They don't have to guess which lines belong together.

The temptation is to group things because they're "related." But "related" is too broad. A function refactor and the tests that cover it — fine, those can go together. A refactor, a database migration, and a CSS fix — those are three separate commits.

Conventional Commits

Once you're clear on what goes in each commit, you need to decide how to describe it. Conventional Commits is a lightweight specification for commit message format. Projects like Angular, Vue, Vite, and thousands of open source libraries use it — not for aesthetics, but because the format is machine-readable. Tools like semantic-release can generate changelogs and compute the next version automatically based on your commit types.

The format:

type(scope): subject

body

footer

A real example:

feat(auth): Add Bearer token validation

The authorization header now requires the Bearer prefix.
Bare tokens sent without it will receive a 401 response.

BREAKING CHANGE: Authorization header format changed

That looks like a lot of structure for a text message. Bear with me — each part has a concrete reason.

Types

The type describes what kind of change the commit contains. The most common ones:

Type	When to use
`feat`	New functionality
`fix`	Bug fix
`docs`	Documentation changes
`refactor`	Refactoring without observable behavior change
`test`	Adding or fixing tests
`chore`	Maintenance: dependencies, configs, scripts
`perf`	Performance improvement
`style`	Formatting, whitespace, semicolons — no logic change
`ci`	CI/CD configuration
`build`	Build system changes
`revert`	Reverting a previous commit

Don't stress about memorizing the full list from day one. feat, fix, refactor, and chore cover more than 80% of day-to-day commits. The others you pick up when you need them.

Scope (optional)

The scope goes in parentheses after the type and indicates the area of code affected:

feat(auth): Add token refresh endpoint
fix(api): Return 404 for deleted users
refactor(database): Extract query builder to its own module

There's no canonical list of correct scopes — each project defines its own. What matters is consistency: if the auth layer is called auth, always call it auth, not authentication one day and auth the next. Scopes are useful for filtering history; they lose that value if they're not stable.

If the change is cross-cutting or doesn't fit neatly into any area, just leave it out.

The subject line

The subject is the first line — what you see in git log --oneline. It's the most important part of the message:

feat(auth): Add Bearer token validation
             ↑
             imperative mood — "Add", not "Added" or "Adding"

Imperative mood: "Add feature", "Fix null check", "Refactor validation". Not "Added", not "Adding", not "Fixes". Git itself uses this style in its own messages (Merge branch, Revert "feat: ..."). Matching it is consistency, not arbitrary convention.

70 characters max: GitHub and GitLab truncate the subject line in their interfaces beyond that. Anything longer belongs in the body.

No trailing period. Capitalize the first letter.

And most importantly: describe the change, not the activity. feat(auth): Add null check before token verification is useful. fix: Fix bug is useful to no one.

The body

The body is optional, but it's where the most durable value lives: the why.

It's separated from the subject by a blank line (required — Git treats them as distinct sections without it):

fix(api): Handle null response in user endpoint

Accounts deleted via the legacy migration tool can leave ghost sessions
in the database. The endpoint was crashing on these instead of
returning a clean 404.

The migration tool will be deprecated in Q3, but until then this
null check is necessary.

The diff already shows what changed. The body explains the context the diff can never show: why the bug existed, what scenario triggered it, what alternatives were ruled out, what's expected to change later. That information disappears forever if you don't write it down now — you're the only one with the full context, and you have it right now, while making the commit.

Not every commit needs a body. chore: Update dependencies doesn't need elaboration. But for a non-obvious fix, a design decision, or a change that might surprise someone six months from now, the body is invaluable. Future you will thank present you. Or at least stop blaming present you.

The footer and breaking changes

The footer is for structured metadata: issue references and, most importantly, breaking changes.

A breaking change is a change that breaks backward compatibility with a previous API or public behavior. It's declared in two complementary ways:

feat(api)!: Remove deprecated v1 endpoints

All v1 endpoints removed. Clients must migrate to the v2 API.

BREAKING CHANGE: v1 endpoints no longer available
Closes #341

The ! after the type is the fast signal — visible at a glance in the log. The BREAKING CHANGE: in the footer is the formal declaration that release tools use to know a major version bump is needed in semver. Both together ensure both humans and tooling understand the magnitude of the change.

Issue references also go in the footer:

fix(auth): Reject expired tokens on silent refresh

Closes #482
Refs #391

The practical workflow: --fixup and --autosquash

The atomic commit principle collides with reality in a predictable way: you make a commit, keep working, and realize there's an error in that previous commit. The instinctive solution is a new commit that says "fix typo" or "oops." The correct solution is --fixup:

# You realize commit abc123 needs a correction
git add -p                    # stage only the fix
git commit --fixup abc123     # creates: "fixup! feat(auth): Add Bearer..."

This creates a commit automatically marked as a fixup for the original. When you clean up history before merging:

git rebase -i --autosquash main

Git reorganizes the commits on its own and squashes the fixups into their target commits. What lands in main is clean: no "fix typo", no "oops", no "more stuff." The project history, told in order.

A well-written commit history isn't extra documentation someone decided to maintain — it's the documentation Git gives you for free if you feed it properly. A year from now, when someone runs git log -S "mysterious_function" to understand why that function exists, your commits are the only thing they'll find. Make them worth finding.

In the next tutorial we cover branch naming conventions: how to name branches so your team understands at a glance what they contain, which ticket they're tied to, and when it's safe to delete them.

💡 Challenge: Find the most cryptic commit in one of your projects. Rewrite it in Conventional Commits format with a proper subject, body, and footer if applicable. The exercise trains the muscle for writing the message in the moment, not reconstructing it after the fact.

Never stop coding!

How to resolve merge conflicts in Git

Javi Palacios — Thu, 13 Aug 2026 11:07:50 +0000

You run git merge feature/auth-improvements and instead of the clean one-liner you were hoping for, your terminal dumps this:

Auto-merging src/auth/middleware.ts
CONFLICT (content): Merge conflict in src/auth/middleware.ts
Automatic merge failed; fix conflicts and then commit the result.

You open the file and find:

<<<<<<< HEAD
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ error: 'Unauthorized' });
=======
  const authHeader = req.headers.authorization;
  const token = authHeader && authHeader.startsWith('Bearer ')
    ? authHeader.split(' ')[1]
    : null;
  if (!token) return res.status(401).json({ error: 'No token provided' });
>>>>>>> feature/auth-improvements

What is HEAD here? Which version is "correct"? Do you pick one and delete the other, or can you combine them? What happens if you accidentally leave a <<<<<<< in the file?

Conflict markers have a logic to them. Once you understand it, resolving conflicts stops being stressful and becomes something you can do methodically — still a bit tedious, but never mysterious.

Conflict markers

When Git can't automatically resolve a merge, it marks the conflicting sections with a syntax that's been unchanged for decades (yes, those three angle brackets — it's genuinely one of the least intuitive choices in software tooling, and yet here we are). The structure is always the same:

<<<<<<< HEAD                          ← start of your version (current branch)
your version of the code
=======                               ← separator
their version of the code
>>>>>>> feature/auth-improvements     ← end of their version (branch being merged)

HEAD is your current branch — what you have right now. The label after >>>>>>> is the name of the branch you're merging in. The ======= is the divider between the two versions.

To resolve the conflict you have three choices: keep your version (top), keep theirs (bottom), or write a new version that integrates both. What you cannot do is leave the markers in the file — that's not valid code, and it will cause problems the moment someone runs it.

The diff3 variant

There's a setting that gives you significantly more context, and you should enable it now:

git config --global merge.conflictstyle diff3

With diff3, the markers include an extra section: the common ancestor — what the file looked like before either of you touched it:

<<<<<<< HEAD
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ error: 'Unauthorized' });
||||||| merged common ancestors
  const token = req.headers['x-auth-token'];
  if (!token) return res.status(403).json({ error: 'Forbidden' });
=======
  const authHeader = req.headers.authorization;
  const token = authHeader && authHeader.startsWith('Bearer ')
    ? authHeader.split(' ')[1]
    : null;
  if (!token) return res.status(401).json({ error: 'No token provided' });
>>>>>>> feature/auth-improvements

Now you can see what each person actually changed. The ||||||| section is the original. From that, it's clear: you switched from x-auth-token to authorization, and they also switched the header but added Bearer format validation on top. The right resolution isn't picking a winner — it's combining both changes. That's obvious once you see the base. Without it, you're guessing.

The three-way merge

The reason diff3 makes sense becomes clear when you understand how a merge actually works.

When you merge two branches, Git doesn't just compare your version against theirs. It compares both versions against the common ancestor — the last commit both branches share. That's why it's called a three-way merge: three versions, three ways.

The logic is clean: if only one side changed a line, Git resolves it automatically — it takes the changed version, because the other side didn't do anything different. A conflict only appears when both sides changed the same area of code in different ways. Git doesn't know which change was intentional, so it stops and asks you.

Without the common ancestor, you can't tell whether your version should "win" or whether you need to integrate both changes. With it, you have all the information needed to make the right call.

Resolving conflicts by hand

git status tells you exactly which files have conflicts:

git status

On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   src/auth/middleware.ts
        both modified:   src/config/database.ts

The process for each conflicted file:

Open it and find the <<<<<<< markers
Decide what the code should look like (yours, theirs, or a blend)
Delete all the markers (<<<<<<<, |||||||, =======, >>>>>>>)
Save the file
git add src/auth/middleware.ts

Once every conflicted file is resolved and staged:

git commit

Git has a merge commit message already prepared. Edit it or leave it as-is.

For entire files: --ours and --theirs

If there's a file where you know one version wins completely — no blending needed — you don't have to edit markers manually:

git checkout --ours src/package-lock.json    # take our version entirely
git checkout --theirs src/yarn.lock          # take their version entirely
git add src/package-lock.json src/yarn.lock

This is especially useful for auto-generated files like lockfiles. Merging two lockfiles line by line is a losing battle — the correct lockfile is the one that results from running your package manager in your environment, not some hybrid of two different install states.

Merge tools

Resolving conflicts manually in large files is doable but slow. Merge tools give you a visual layout of the conflicting versions — no more scrolling through markers trying to keep track of which block belongs to whom.

lazygit

If you live in the terminal — or if the idea of opening VS Code to resolve four conflict hunks feels like calling the fire department because your toast burned —, lazygit is the tool. A full TUI (terminal UI) for Git: no Electron, no three-second startup, no fan suddenly deciding this is its moment to shine.

# Install lazygit
brew install lazygit          # macOS / Linux via Homebrew
pacman -S lazygit             # Arch (nobody's surprised)
apt install lazygit           # Debian/Ubuntu

Open lazygit in the repository and conflicted files appear clearly marked in the Files panel. Select one and the right panel shows the conflict hunks: you can navigate between them, pick your version or theirs with a single keypress, or drop into your $EDITOR for anything that needs a more surgical approach. When you're done, the file is ready to stage — without opening a new window or switching context.

For anyone who resolves conflicts regularly, the speed difference is real. Not because lazygit is magic, but because there's nothing to wait for.

VS Code and IntelliJ

For those who prefer a full GUI with a three-panel view (your version, the ancestor, theirs), VS Code and IntelliJ IDEA have built-in merge support. To configure them for use with git mergetool:

git config --global merge.tool vscode
git config --global mergetool.vscode.cmd 'code --wait $MERGED'

git mergetool

Git opens each conflicted file in your configured tool, one at a time. Works well for complex conflicts where you want to see a full file's worth of context on a wide screen.

vimdiff

vimdiff is available without any extra configuration. Arch users already know what comes next; everyone else discovers it by accident on a day when nothing else is installed, learns more Vim shortcuts than they planned, and walks away with an ambiguous relationship with the tool. It works. It's not exactly friendly. But it's been working for decades, which counts for something.

And if the accidental session leaves you with more questions than answers — or just stuck in a buffer with no idea how to exit — there's a Vim course from scratch that starts exactly from there.

git merge --abort

Sometimes the right move is to back out entirely.

git merge --abort

This undoes the merge completely and puts you back exactly where you were before running git merge. No trace, no half-committed state, no stray markers in the code. As if it never happened.

When to use it:

The conflicts are too extensive and you need to rethink your approach before continuing
You merged the wrong branch
You need to sync with your team before making decisions about conflicting code
Your merge tool crashed halfway through (it happens more than it should)

It's not giving up. It's knowing when to stop so you can do it right, rather than forcing a resolution you're not sure about.

Strategies for complex conflicts

Let one side always win

If you know that in case of a conflict your version should always take precedence (or always theirs), you can tell Git upfront:

git merge -X ours feature/branch    # on conflict: take our version
git merge -X theirs feature/branch  # on conflict: take their version

This only kicks in when there's a real conflict — it doesn't touch changes Git can resolve automatically. Useful for maintenance branch merges where the precedence rule is clear before you start.

Rebase first, then merge

Conflicts are less frequent — and when they do appear, smaller and with clearer context — when your branch is up to date with main. Instead of merging directly after weeks of divergence, sync first:

git fetch origin
git rebase origin/main
# resolve conflicts one commit at a time if they appear
git push --force-with-lease origin feature/your-branch

Rebase replays your commits on top of the updated main. If conflicts appear, you deal with them one commit at a time — small doses, each with clear context about what changed in that specific step. Far more manageable than a single merge with weeks of accumulated divergence.

Preventing conflicts

The best resolution is the one you don't have to do.

Sync frequently. A branch that hasn't touched main in three weeks will have conflicts. A daily git rebase origin/main keeps the gap small and the conflicts manageable.

Small, short-lived branches. The longer a branch lives, the more it diverges. Long features get broken into smaller pieces that merge early, before the differences have time to accumulate.

Talk to your team before touching critical files. Database migrations, package.json, shared configuration files — these are conflict hotspots. It's not a technical problem; it's a communication problem. "I'm going to change the user schema this afternoon — does that affect anyone?" in the team channel prevents half an hour of conflict resolution.

Feature flags instead of long-lived branches. If the code is deployed but turned off by a flag, you can merge without waiting for the feature to be finished. The branch lives days instead of weeks, and conflicts don't have time to build up.

Conflicts are the part of collaborative work that Git delegates to humans — and rightly so, because the machine doesn't know which change was intentional. Understanding the three-way merge, enabling diff3, and knowing when to reach for --abort instead of forcing through a resolution you don't fully understand: those three things turn something intimidating into something completely manageable.

In the next tutorial we start the workflows module: how professional teams organize their day-to-day Git usage, from the classic Gitflow model to trunk-based development, and when each one makes sense.

💡 Challenge: Create two branches from the same commit, modify the same lines of a file in each branch in different ways, then merge one into the other. Enable diff3 first if you haven't already, and pay attention to how the common ancestor helps you understand exactly what each side changed.

Never stop coding!

Investigating Code Changes Line by Line with git blame

Javi Palacios — Wed, 12 Aug 2026 07:53:15 +0000

You've been there. You're staring at a file with a 50-line function that makes zero sense. Nobody on the team knows what it does. The person who wrote it left the company. And the commit says "WIP". Or "fix". Or — my personal favorite — "asdfgh".

Who wrote this? When? Was anyone even reviewing code at this point?

This is where git blame goes from a useful tool to your best ally for code archaeology (and possibly the most hated person in your team's history).

git blame line by line

The name is dramatic on purpose. It tells you exactly who added each line, in which commit, and when. There's no hiding from it.

git blame file.py

The output gives you everything you need:

abcdef1 (Maria Gomez 2026-03-15 10:23 +0200  1) def calculate_total(items):
bcdef12 (Maria Gomez 2026-03-15 10:23 +0200  2)     total = 0
1234567 (John Perez  2026-04-02 14:05 +0200  3)     for item in items:
abcdef1 (Maria Gomez 2026-03-15 10:23 +0200  4)         total += item.price
defa456 (Maria Gomez 2026-04-05 16:41 +0200  5)     return total * 1.21  # TODO: hardcoded tax

Each line shows: commit hash, author, date and time, line number, and content.

You spot the # TODO: hardcoded tax on line 5, grab the hash defa456, and run:

git show defa456

Full commit right there: what changed, why, and in what context. Next time someone says "that code was always there", you've got the exact timestamp.

Blame on a line range

If the file has 800 lines, you don't need blame for all of them. Limit it:

git blame -L 45,90 file.py     # lines 45 to 90
git blame -L 45,+20 file.py    # 20 lines starting from line 45

Much more manageable when you already know where the problem is.

Filtering the noise: -w and -M

By default, git blame shows the author of the last person who touched that line. But if someone reformatted the file — indentation, whitespace — it blames the wrong person. That leads to unnecessary awkward conversations.

git blame -w file.py       # ignore whitespace changes
git blame -M file.py       # detect lines moved within the file

The -M flag is especially useful after big refactors where someone shuffled functions around the file. It shows the original author, not the one who did the internal copy-paste.

git log -p: history with full diffs

Sometimes you don't care who touched what. You want to see ALL the changes in a file over time, with the complete diff in every commit — without running git show for each one manually:

git log -p file.py

Navigate with the arrow keys, exit with :q.

Don't stress if the output is massive — git log has filtering options for exactly this, and we'll cover them next.

git log --follow: when the file was renamed

A file can be renamed several times over its life. git log file.py shows its history, but if it used to be called old_file.py, it won't see that.

git log --follow file.py

Git follows the file even after name changes. You get the complete history — what the file was called at every point in its life.

(On Windows, filesystems are case-insensitive by default — you know how this goes — so if someone renamed Auth.py to auth.py, Git loses the trail without this flag.)

git log -S: find when a piece of code appeared

This is the most powerful option when you know what you're looking for but not when it appeared.

git log -S "calculate_total" --oneline

Shows all commits that added or removed that string from the code. It doesn't search commit messages — it searches the actual diff. If you're like me when I started, this feels like dark magic. It isn't, but it's close.

Perfect for:

"When was this bug introduced?"
"This variable isn't used anymore — when did it stop being used?"
"Who added this dependency without telling anyone?"

Combine with -p to see the full context in each commit:

git log -S "calculate_total" -p

Note: -S searches for an exact string and detects when the occurrence count changes. If you need regex, use -G instead.

git show: see a file at any point in time

Once you've got a hash — from blame, log, or anywhere — looking at the full commit is trivial:

git show abc1234
git show abc1234:src/app.py        # the file as it was at that commit
git show abc1234 --stat           # changes summary, no full diff

The git show hash:path/to/file is especially useful when you need to see what a file looked like at a specific point without having to checkout. See it, copy what you need, move on.

Practical workflow

You're new to a codebase. You find a weird function. You want to know its story. Here's the process:

Who added it? git blame file.py → grab the hash from the suspicious lines
What changed in that commit? git show hash → full context
When did it appear? git log -S "function_name" → complete timeline
Was the file renamed? git log --follow file.py → full history including renames

Four commands for a complete code forensics investigation. After this, "I don't know who wrote that" stops being a valid answer on your team.

For the next tutorial

Next up is what you need when things get serious: merges. Merge conflicts, strategies to resolve them, and how to avoid them by just talking to your team before they happen. That last one sounds obvious. It isn't.

💡 Challenge: Pick a file in your current project you don't know well and use the four commands in this tutorial to reconstruct its history. You'll find things you didn't expect. Probably things you didn't want to find.

Never stop coding!

Your First Code Conversation with AI

Javi Palacios — Tue, 11 Aug 2026 06:42:13 +0000

The first real coding message you send to an AI is usually the wrong one. Too vague, missing half the context, not entirely sure what you're even asking for. You type something, look at it, delete it, rephrase, look at it again — and somehow the blank cursor feels more intimidating than any compiler error you've ever seen.

Here's the thing: send it anyway. The first message doesn't need to be good. Getting the dialogue started is the work.

Dialogue, not search

Using AI for code is not like searching Stack Overflow or querying a documentation site. With search, you get one shot — a vague query returns vague results and you start over. There's no back-and-forth, no way to clarify, no memory of what you tried before.

With AI it works differently: it's a conversation. You can start imprecise and sharpen as you go. You can ask why it chose a particular approach. You can say "this doesn't work" and continue from there without repeating all the context. The model carries everything said in the current session — you're always building on what came before.

That's the mental shift. Not "I need to formulate the perfect question." It's "I'll build toward the right answer together with it."

Setting up your first session

If you're using Claude, open claude.ai. The free tier covers everything in these first modules — no API key, no terminal, no configuration required. A text field and a send button.

Do you need a well-crafted prompt before starting? No — Module 2 is entirely about that. For now, the only requirement is an open chat window and a real problem.

One thing to understand from the start: each conversation is independent. The model has no memory of previous sessions. Everything we covered in earlier tutorials about hallucinations and context blindness applies here: it only knows what's in this conversation.

Experiment 1: ask it to explain something

For your very first session, work in familiar territory. Don't start by asking it to build something from scratch — start by asking it to explain code that already exists.

Take this Python snippet:

numbers = [3, 1, 4, 1, 5, 9, 2, 6]
result = sorted(numbers, key=lambda x: -x)[:3]

And write something like:

Explain what this Python code does, line by line:

numbers = [3, 1, 4, 1, 5, 9, 2, 6]
result = sorted(numbers, key=lambda x: -x)[:3]

The response comes back in a few seconds — formatted, technically precise, with clear explanations. Your first reaction might be: "that's it?" Yes. Now the important part starts.

Does the explanation make sense? Does it describe the behavior you'd actually see if you ran the code? Run it:

numbers = [3, 1, 4, 1, 5, 9, 2, 6]
result = sorted(numbers, key=lambda x: -x)[:3]
print(result)  # [9, 6, 5]

Did the explanation predict that output? If yes — good. If not — that's useful information about the limits of that particular response. Not a failure, just data.

This isn't a test you're running on the AI. It's the process: receive, understand, verify. Always in that order.

Experiment 2: ask it to fix something

The second experiment is closer to everyday use. You have broken code. You hand it to the AI.

def calculate_average(numbers):
    total = 0
    for num in numbers:
        total += num
    return total / len(numbers)

print(calculate_average([]))  # ZeroDivisionError

The bug is obvious if you have experience. But if you're new to Python, or you're in the middle of something larger and don't have the bandwidth for this right now, the AI can solve it in seconds:

This code throws ZeroDivisionError when the list is empty. How do I fix it?

def calculate_average(numbers):
    total = 0
    for num in numbers:
        total += num
    return total / len(numbers)

The response will likely propose something like:

def calculate_average(numbers):
    if not numbers:  # Handle empty list
        return 0  # or None, or raise ValueError — depends on your use case
    total = 0
    for num in numbers:
        total += num
    return total / len(numbers)

Notice: the AI will probably give you options — return 0, return None, raise ValueError. That's not hedging, it's accurate. It doesn't know which behavior fits your project. That decision belongs to you.

There's a specific feeling that comes with pasting AI-generated code into your editor — not quite confidence, not quite skepticism. Somewhere in between. That feeling is correct. It means you're thinking, not just copying. Don't override it. Read the fix, understand why it works, pick the option that matches your actual requirements.

Experiment 3: ask it to generate something

The third experiment is the one that impresses you first — and the one that requires the most care. Give the AI a specification and watch it write code from scratch.

Start with something small and verifiable:

Write a Python function that takes a list of strings and returns only those
longer than 5 characters, sorted alphabetically. Include a usage example.

The response will be something like:

def filter_and_sort_strings(strings):
    # Filter strings longer than 5 characters, then sort alphabetically
    return sorted([s for s in strings if len(s) > 5])

# Example usage
words = ["cat", "banana", "apple", "elephant", "fig", "mango"]
result = filter_and_sort_strings(words)
print(result)  # ['banana', 'elephant', 'mango']

Run the example. Verify the output matches what you expected. Then test with your own cases:

# What about empty strings?
print(filter_and_sort_strings(["", "a", "hello world"]))  # ['hello world']

# What about exactly 5 characters?
print(filter_and_sort_strings(["exact", "longer"]))  # ['longer'] — "exact" is 5 chars, not > 5

Does the behavior on edge cases match your use case? The code is correct in the abstract. If you wanted "5 or more characters" instead of "more than 5", that difference is yours to catch — the AI implemented exactly what you asked for, not necessarily what you meant.

That gap — between correct generation and appropriate generation — is the one that bites you in production. The first is the AI's job. The second is yours.

The evaluation loop

After every response — explanation, fix, or generated code — three questions before you use it:

Does it run? Execute it. An immediate AttributeError or SyntaxError is data: something in the response isn't right. Unexpected output is also data.

Do I understand it? If you can't explain what each line does, don't merge it. Not because the AI is unreliable — because code you don't understand is code you can't debug when things go wrong. And things always go wrong eventually.

Does it fit my context? AI-generated code works in the abstract. Your project has conventions, dependencies, constraints. Does the solution respect them? Or does it assume something that isn't true in your system?

These questions are fast for simple cases. For a sorted() with a custom key, a glance is enough. For authentication code, data validation, or business logic — these become a real review, not a quick skim.

The challenge: build a calculator

You've seen the three dynamics — explain, fix, generate. Now combine them.

💡 Challenge: Use AI to build a simple Python calculator. Requirements:

Accept two numbers and an operation (+, -, *, /)
Return the result
Handle division by zero gracefully
Include at least one usage example per operation

One rule: verify each piece of code you receive before asking for the next one. Don't paste the entire solution in a single shot.

When you're done, you'll have completed your first end-to-end AI-assisted coding session.

You've used the AI to explain, fix, and generate code. The cycle is three steps: receive, understand, verify. And you've seen directly that the AI doesn't make context decisions for you — those belong to you.

In the next tutorial, we start Module 2: Effective Prompting for Developers. First topic: the RCTF framework — Role, Context, Task, Format — the concrete difference between a prompt that gets what you need and one that returns something plausible but not useful.

Never stop coding!

The AI Model Landscape in 2026: who's who and where to start

Javi Palacios — Fri, 07 Aug 2026 12:41:02 +0000

Let me be upfront about something: this tutorial will age badly. Not the concepts — those hold. But the specific names, the price points, the rankings — the AI model landscape moves fast enough that any comparison table has an expiration date. What's the best model for code today might be second place next quarter. The one that seems expensive now might be the obvious choice by the time you're reading this.

That said: the mental model for navigating this landscape doesn't expire. What questions to ask when choosing a model, how API access differs from a subscription, what "context window" actually means on a regular Tuesday — that's stable. With the right map, you can update yourself when things change. And they will.

The frontier models: the big three

Frontier models are the most capable models at any given moment. In 2026, the competition comes down to three:

Claude Sonnet 4.6 (Anthropic) is the model you'll be using throughout this course, and the current benchmark for coding tasks. Together with Opus 4.7, it ships with a 1M token context window at standard pricing — no special headers, no premium plan required. It stands out for sustained reasoning, precise technical writing, and following complex multi-step instructions. Sonnet 4.6 is the speed-quality balance; Opus 4.7 is more powerful but slower and more expensive.

GPT-5.4 (OpenAI) — released March 2026 — is the first general-purpose model with native computer use: it can operate desktop interfaces and execute complex workflows across applications. It reaches 1M tokens of context, incorporates the coding capabilities of GPT-5.3-Codex, and comes in multiple variants — Thinking, Pro, mini (free tier), and nano (API-only) — making it the most accessible of the three. Recently, GPT-5.5 has been released, with improvements in speed and reasoning.

OpenAI also maintains the Codex family as a separate line: GPT-5.3-Codex is optimized for complex agentic software engineering and leads benchmarks like SWE-Bench Pro; GPT-5.3-Codex-Spark is its ultra-fast variant, designed for real-time response. They're not always the best choice — for general reasoning or mixed tasks, GPT-5.4 covers more ground — but if your use case is intensive agentic engineering, they're worth knowing about.

Gemini 3.1 Pro (Google) — released February 2026 — has a 1M token context window and strong performance on complex reasoning benchmarks: 77.1% on ARC-AGI-2, which measures the ability to solve entirely new logical patterns. Its natural advantage remains Google ecosystem integration — Workspace, Cloud, Android, NotebookLM. For projects already living in Google Cloud, it's hard to ignore.

The "which is best?" question has an easy answer and an honest one. Easy: Claude. Honest: it depends on the task, changes every few months, and benchmarks published with great fanfare on a Friday tend to be outdated before anyone seriously cites them the following Monday. The real practical difference between all three in day-to-day use is smaller than those leaderboards suggest.

There's also something counterintuitive worth naming: for everyday work, the tool wrapping the model matters more than the model itself. Copilot with GPT-4o integrated directly into your editor can be more productive than Claude with no integration, even if Claude outperforms it on whatever benchmark you prefer. More on that in the next section.

Specialized coding tools

Beyond the frontier models, there are tools built specifically for development workflows. The key distinction: these aren't models — they're interfaces and assistants that use frontier models under the hood.

GitHub Copilot — specifically its Pro+ plan — is the option with the widest model roster inside a single environment. You can switch between Claude Sonnet 4.6, GPT-5.3-Codex, Gemini 3 Pro, and others directly from the chat interface, without changing tools. The VS Code and JetBrains integration is the most mature on the market, with an autonomous agent that can edit files, run terminal commands, and iterate on errors without manual intervention.

Its weak point is context: the native limit is 128K tokens, well below the 1M of the frontier models. Workspace mode partially compensates with RAG indexing of your codebase, but that's not the same as real coherence across a long context window. If you need long sessions with a lot of code in flight, Cursor or OpenCode have the edge. If you value model variety and deep editor integration, Copilot Pro+ is hard to beat.

Cursor is a full editor (a VS Code fork) with AI woven into the editing flow. You talk to it about your code, make changes across multiple files from a single instruction, and review diffs before applying. It's more assertive than Copilot — it doesn't just complete, it collaborates. If the workflow clicks for you, going back feels like a downgrade.

OpenCode is the terminal agent you'll use from Module 3 onward in this course. Unlike Copilot or Cursor, it has no monthly subscription of its own — it connects to whichever providers you choose, either by logging into your existing account or by supplying an API key. OpenCode orchestrates; the model comes from whoever you already have a contract with.

To get started without spending anything, OpenCode includes 8 free models through its Zen service (CLI-only): mainly Chinese models — MiniMax, GLM, Kimi — that let you explore the tool without a credit card. They have real limitations in speed, reasoning, and context; they're a starting point, not a substitute for frontier models.

On the other hand, there’s OpenCode Go, which, for $5 in the first month and $10 a month thereafter, gives you access to a curated selection of high-quality Chinese models — the latest versions of those mentioned above and others — with fairly generous usage-based limits. It’s a middle-of-the-road option for those who want more power and longer usage time than the free OpenCode Zen models offer, but don’t want to commit to the more expensive plans for the Frontier models.

When you want more power, you have several paths:

Log in with your provider account: if you already have a subscription with OpenAI, Google, or others, you can use it directly from OpenCode — the same way you would from their web interface or official app.
OpenCode Zen (pay-as-you-go): token access with no markup — you pay only the card transaction cost on top of the provider's price.
Your own API key: connect directly to whichever provider you prefer.

One important exception: Anthropic. It has explicitly banned the use of its monthly subscription plans (Claude Pro) with third-party tools like OpenCode — API access only. This isn't an OpenCode limitation — it's a unilateral Anthropic policy decision that could be repeated by other providers; worth keeping in mind from the start.

Everything I’ve told you in these last two sections — the best models, prices, etc. — will generally still hold true, but the specific model names and their prices may change. The important thing is to understand the big picture: what each type of model does, the difference between API and subscription, and how to choose the tool that best suits your workflow.

The CLI ecosystem and editor plugins

OpenCode isn't the only terminal agent. The major AI companies have their own CLI tools that work very similarly — same philosophy, same command-line access:

Claude Code (Anthropic): Anthropic's official CLI, with a VS Code plugin already available and especially well integrated.
Codex CLI (OpenAI): OpenAI's terminal agent, focused on intensive software engineering tasks.
Copilot CLI (GitHub): GitHub Copilot's terminal extension.

This course uses OpenCode as the reference to avoid multiplying examples across every tool, but the mental model you'll build applies equally to all of them.

For those who'd rather not open a separate terminal window: every code editor has an embedded terminal. If a specific plugin doesn't exist yet for your preferred tool — or isn't as well-integrated as Claude Code's VS Code plugin — running the agent from that embedded terminal works without issues.

Try answering "which AI tool do you use for coding?" without a thirty-second preamble. It's harder than it sounds — not because you don't know, but because the boundary between these tools shifts faster than anyone can track, and the underlying model a given tool uses quietly changes every few months anyway. The real question isn't "which is better" but "at which point in your workflow do you want AI to show up."

API or subscription: the difference that matters

There are two ways to access these models, and the confusion between them is more common than you'd expect — partly because providers use the same product names to mean different things depending on context. If this has never been fully clear to you, that's not a gap in your knowledge; it's a gap in how the industry communicates.

A subscription (Claude Pro, ChatGPT Plus, Gemini Advanced) is flat-rate access: fixed monthly fee, and you can use the model from the provider's web interface or app, from their own tools (CLI, desktop, editor plugins), and in most cases from third-party tools like OpenCode by logging into your account. It has usage limits — tokens per day, requests per week, depending on the provider — and when you hit them, access is cut off until the counter resets. The upside is predictability: you know exactly what you'll pay this month.

The API is programmatic, pay-per-use access: you get a key and call the model from your code or from whatever integration you need to build. You pay for the tokens you send and the tokens you receive, not for time. Rate limits still exist — per minute or per hour, depending on provider and tier — but there's no fixed monthly ceiling: consume more, pay more. The cost is variable, and depending on usage, it can easily exceed what a subscription would have cost.

The real distinction, then, isn't "basic vs. advanced" or "for the web vs. for tools" — it's predictable fixed cost versus variable, uncapped cost. The API is necessary when you want to build your own application with AI capabilities, or when a provider doesn't allow using your subscription with third-party tools (Anthropic's case, as we saw). For everything else, a subscription gets you far.

Do you need the paid API to follow this course? Spoiler: you don't. The early modules use the web interface, covered by the free or basic subscription tier. The API comes in when we reach OpenCode — and at that point, typical learning usage costs less than you'd expect.

The context window: beyond the number

Every model advertises its context window in tokens. All three frontier models — Claude 4.6, GPT-5.4, and Gemini 3.1 Pro — now reach one million. The number sounds impressive.

Reality check: the context window is how much information the model can "see" in a single conversation — your message, the conversation history, and any files or code you've attached. Everything together.

200k tokens sounds like a lot. In practice, that's roughly 150,000 words or about 600KB of code. Enough to paste an entire medium-sized codebase. For answering a quick question about one function, 2,000 tokens is plenty.

What actually matters isn't the maximum number — it's two things. First, whether the model maintains coherence across a long context (not all models do this equally well). Second, how cost scales as the context grows, because in the API you pay for input tokens too. A long conversation with a large codebase attached can burn through budget faster than expected.

Rate limits and how they affect real work

Rate limits are the caps providers put on how many requests or tokens you can send per minute, hour, or day. They vary by plan and provider.

For learning purposes, you won't notice them. Rate limits become a real problem when:

You're running the API in production with multiple simultaneous users
You have an automated process making many calls in sequence
You're on the free tier during a heavy working session

The signal that you've hit a rate limit is usually a 429 Too Many Requests error. The fix: wait a few minutes or upgrade your plan. It's not a code error — it's a usage cap.

What this actually costs

I'll save you the deliberation: for learning, cost is essentially a non-issue. Most models have free tiers that comfortably cover the first few weeks of use. Claude.ai has a free tier. ChatGPT has a free tier. Basic subscriptions are around $20/month.

The API is where cost becomes variable — and that variability can surprise you the first time you see the bill after an afternoon debugging session that went longer than planned. Pricing is measured in dollars per million tokens. In 2026, Claude Sonnet is around $3 per million input tokens and $15 per million output tokens. GPT-5.4 is in a similar range.

What does that mean practically? A typical working session with OpenCode — a few hours of back-and-forth with code attached and project context — runs between $0.50 and $3. An intensive session with a large codebase and many iterations might reach $10. For daily learning use, the monthly total usually lands between $5 and $20.

Practical advice: set a spending limit on your API account from day one. Every provider lets you configure this. Not because you'll accidentally spend a fortune, but because knowing there's a ceiling is worth the 30 seconds it takes to set it.

Where to actually start

With all of this on the table, the real question is: what do I do right now?

Situation	Recommendation
Just discovered this	Claude.ai free — no setup, no cost, straight to the point
Want to try multiple models without leaving the editor	GitHub Copilot Pro+ (widest model roster)
Want the most integrated editor experience	Cursor (free trial available)
Need long sessions with genuinely large context	OpenCode or Cursor (real 1M tokens, not RAG)
Following this course through Module 3	Claude.ai until then, then OpenCode
Ready to start with the API	Claude API with a spending limit configured

You don't have to pick one forever. Most developers who've been working with these tools for a while use two or three depending on context — the web interface for quick exploration, an editor tool for autocomplete, and a terminal agent for tasks that need file access and command execution.

You now have the map. You know who the players are, how models differ from tools built on top of them, when the API makes sense, and how to think about cost without letting it become a blocker. In the next tutorial we get into real conversations with AI: how to structure a code prompt, what context to include, and how to evaluate the response before you commit it to your project.

Never stop coding!

for loops and range() in Python: iterate without the busywork

Javi Palacios — Thu, 06 Aug 2026 13:34:23 +0000

You already know how to count from 1 to 10 with while. A counter, a condition, an increment — four lines of code where three of them exist only to serve the fourth. That works. But Python has a better tool for situations like this:

# while: you manage the counter yourself
counter = 1
while counter <= 10:
    print(counter)
    counter += 1

# for: Python manages it for you
for i in range(1, 11):
    print(i)

Same result. Half the ceremony. The difference isn't just aesthetic — it's about intent. The for loop says "I know exactly what I want to iterate over." The while says "keep going until this condition is false." When you know the sequence upfront, for is the right tool.

What is a for loop?

A for loop iterates over a sequence of elements — one at a time, in order — and runs a block of code for each one. When it runs out of elements, it stops on its own.

fruits = ["apple", "pear", "grape"]

for fruit in fruits:
    print(fruit)  # Print each fruit

apple
pear
grape

The structure is for <variable> in <sequence>:. On each iteration, the variable (fruit) takes the value of the next element. No indexing, no incrementing — the loop handles it.

One thing that catches beginners off guard: the loop variable doesn't disappear when the loop ends. After the for finishes, it's still in scope, holding the value from the last iteration.

for fruit in fruits:
    print(fruit)

print(fruit)  # "grape" — still accessible after the loop

It's not a bug — it's just how Python scoping works for loop variables. File this away; you'll appreciate knowing it the first time you need to debug something after a loop.

range(): generating number sequences

Iterating over an existing list is useful, but often you just want to repeat something a set number of times. That's what range() is for — it generates a sequence of integers on demand.

It comes in three forms:

range(stop)

The simplest: generates numbers from 0 up to (but not including) stop.

for i in range(5):
    print(i)

Notice: range(5) gives you five numbers starting at 0. The stop value is not included — this is the same "half-open interval" convention you'll see everywhere in Python, from slicing to indexing.

range(start, stop)

When you want to start somewhere other than zero:

for i in range(1, 6):
    print(i)  # 1, 2, 3, 4, 5

Clean and readable — no + 1 hacks.

range(start, stop, step)

The third argument controls the step — how much the sequence advances on each iteration.

for i in range(0, 11, 2):
    print(i)  # Even numbers from 0 to 10

A negative step lets you count backwards:

for i in range(10, 0, -1):
    print(i)  # Countdown from 10 to 1

Don't stress about memorizing all three forms right now. You'll use range(n) the vast majority of the time — "repeat this n times" covers most everyday cases. The rest you'll pick up as you go.

Iterating over other sequences

for loops aren't limited to lists and ranges. They work with anything iterable — which, for now, you can read as "anything that has elements to loop through."

Strings are iterable — each character is its own element:

for char in "Python":
    print(char)

P
y
t
h
o
n

You'll get a full introduction to lists in the next tutorial, but the pattern is exactly the same as you saw with the fruits example. The for loop is generic — it doesn't care whether you're going through characters, numbers, or anything else. The mechanism is always the same.

break: stop early

Just like with while, you can cut a for loop short with break. The moment Python hits a break, it exits the loop immediately — no remaining elements are processed.

numbers = [3, 7, 2, 9, 4, 6, 1]

for number in numbers:
    if number == 9:
        print("Found 9, stopping.")
        break   # No need to keep looking
    print(number)

3
7
2
Found 9, stopping.

Once break fires, 4, 6, and 1 never get touched. If what you're looking for appears early in a long list, break saves you from processing the entire thing.

Here's where it gets interesting: Python has an else clause for for loops. The else block runs only if the loop completed without hitting a break. If break fires, the else is skipped entirely:

emails = ["user@example.com", "admin@site.com", "support@company.com"]
target = "another@email.com"

for email in emails:
    if email == target:
        print("Email found.")
        break
else:
    print("Email not found in the list.")  # Only runs if no break occurred

Email not found in the list.

If you've used other languages and this for-else pattern feels strange — you're not alone. It surprises most people the first time. But once it clicks, it's genuinely useful for "search and report" scenarios where you want different behavior depending on whether the search succeeded.

Nested loops: a for inside a for

You can put a for inside another for. For every iteration of the outer loop, the inner loop runs completely through all of its iterations before the outer loop moves on.

for row in range(1, 4):
    for col in range(1, 4):
        print(f"({row},{col})", end=" ")  # Print on same line
    print()  # New line after each row

(1,1) (1,2) (1,3)
(2,1) (2,2) (2,3)
(3,1) (3,2) (3,3)

The outer loop handles rows; the inner loop handles columns. A multiplication table is the classic example:

for i in range(1, 6):
    for j in range(1, 6):
        result = i * j
        print(f"{result:3}", end="")  # Right-align in 3 chars
    print()

  1  2  3  4  5
  2  4  6  8 10
  3  6  9 12 15
  4  8 12 16 20
  5 10 15 20 25

Nested loops work well for two-dimensional structures: tables, grids, coordinate pairs. One thing to keep in mind: the operations multiply. A loop of 100 inside a loop of 100 is 10,000 total operations. Add a third loop of 100 and you're at 1,000,000. Two levels of nesting is fine; three levels is usually a sign to rethink the approach.

for vs while: the definitive breakdown

Situation	Use
You know how many times to repeat	`for`
You have a sequence to iterate over	`for`
Reading a file from start to finish	`for`
Iterating over a list, string, or range	`for`
The stopping condition depends on external input	`while`
Waiting for valid user input	`while`
A game that runs until the player loses	`while`
Retry loops with unpredictable timing	`while`

In practice, you'll reach for for far more often than while. Most iteration in Python has a concrete sequence to go through, and for handles it more clearly and directly than managing the loop yourself.

With for and range() in your toolkit, you can iterate over any sequence without tracking a counter. The natural next step is having something interesting to iterate over: in the next tutorial you'll learn about lists — Python's most versatile data structure — including how to create them, access elements by index, and combine them with everything you've learned so far.

Never stop coding!

💡 Challenge: Write a program that generates and prints the multiplication tables from 1 to 10, formatted so each result takes the same amount of space (try f"{result:4}" for alignment). Bonus: ask the user to enter a number between 1 and 10 and show only that table — with the option to request another one until they decide to quit.

DEV Community: Javi Palacios

Dockerfile Best Practices: Security

Don't run as root

Scan for vulnerabilities

Fixing vulnerabilities by rebuilding

Pin versions correctly

Secrets: what must never be in your image

Git Flow: a workflow for managing releases

The core idea: two types of branches

The temporary branches

feature/

release/

hotfix/

The full picture

The git-flow extension

When to use Git Flow (and when not to)

Branch naming conventions in Git

Why branch names matter

The common patterns

Including the issue number

Format rules

Team conventions vs personal preferences

Branch lifecycle

Visual mode in Vim: select, operate, own it

The three Visual modes

gv: bring back the last selection

Operating on a selection

Block Visual mode

Visual vs Vim's grammar: when to use each

Key concepts from this lesson

Lists in Python: your first data structure

What is a list?

Accessing elements: the index

Negative indices

Slicing: extracting a range of elements

Iterating with for

len() and the in operator

Dockerfile Best Practices: Layer Caching and Efficiency

How Docker's layer cache works

What this looks like in practice

Combining RUN commands

.dockerignore: the build context matters

Choosing the right base image

Git commit best practices

The atomic commit principle

Conventional Commits

Types

Scope (optional)

The subject line

The body

The footer and breaking changes

The practical workflow: --fixup and --autosquash

How to resolve merge conflicts in Git

Conflict markers

The diff3 variant

The three-way merge

Resolving conflicts by hand

For entire files: --ours and --theirs

Merge tools

lazygit

VS Code and IntelliJ

vimdiff

git merge --abort

Strategies for complex conflicts

Let one side always win

Rebase first, then merge

Preventing conflicts

Investigating Code Changes Line by Line with git blame

git blame line by line

Blame on a line range

Filtering the noise: -w and -M

git log -p: history with full diffs

git log --follow: when the file was renamed

git log -S: find when a piece of code appeared

git show: see a file at any point in time

Practical workflow

For the next tutorial

Your First Code Conversation with AI

Dialogue, not search

Setting up your first session

`gv`: bring back the last selection

Combining `RUN` commands

`.dockerignore`: the build context matters