DEV Community: Javi Palacios

What is JavaScript and Why Node.js Exists

Javi Palacios — Fri, 13 Nov 2026 08:28:25 +0000

JavaScript has a reputation problem. It's a toy language. It has no types. Equality is broken. It lives in the browser getting in the way of designers. All of that is partly true, and none of it has anything to do with what you're going to do in this course.

Because the same language people complain about online is behind half the APIs you hit every day. Not by accident, either: it got there through a very specific design decision made a while back.

No JavaScript today. Instead you're going to understand where it came from, why somebody took it out of the browser and put it on a server, and what's actually inside Node when you type node and press Enter. Everything else in this course stands on that, and a crooked foundation just means you memorise the rest.

JavaScript was born in the browser

It's 1995. Netscape owns the web and has a problem: pages are static documents. Any form validation means a round trip to the server and back. Brendan Eich writes a language for the browser in a handful of days, in a hurry, with no time to pick a nice design.

The name was marketing. Java was hot, so the language got called JavaScript despite having nothing to do with Java. It's the part of its history that makes more sense in a sales meeting than in an engineering book.

Then came standardisation: the language is ECMAScript on paper, and JavaScript is the commercial name of the implementation. In practice everyone says JavaScript, in the same way everyone says aspirin instead of acetylsalicylic acid.

The interesting bit isn't the trivia, it's the consequence. JavaScript was designed for one environment — the browser — where the main job is reacting to events: a click, a network response, without freezing the interface. That event model wasn't a detail, it was the whole point of the language. Years later somebody looked at it and thought it could do something bigger than a button.

Why anyone took it out of there

In 2009 Ryan Dahl introduced Node.js. The problem he was chasing wasn't a JavaScript problem, it was a server problem.

The classic way to handle connections is one thread per connection: request arrives, thread reserved, wait for the database, respond, release. It works, but every connection costs memory and every thread switch costs time. With thousands of concurrent connections — most of them waiting on a disk or a network — the server spends its day arranging threads that have nothing to do.

Node proposes the opposite: one thread for your code, and no waiting around. When something needs a file or a socket, Node hands off the wait and moves on. When the answer arrives, it comes back.

JavaScript was a perfect fit precisely because of its origin story: the browser had already taught it to live on events and callbacks. The language that looked bolted to a browser window turned out to be the one that already knew how not to block.

V8 is not Node

Two things get mixed up constantly, and it's worth separating them on day one because half the internet uses them as synonyms.

V8 is the JavaScript engine: the program that reads your code, compiles it, and runs it. Google builds it, Chrome ships it, and it knows nothing about files, networks, or servers. It only knows how to run JavaScript very fast.

Node.js is the whole environment: the engine, plus an I/O library, plus a set of modules for talking to the operating system.

The usual analogy is an engine and a car. V8 is the engine; Node is the car — chassis, gearbox, fuel tank. An engine on a stand makes a very convincing noise and gets you nowhere.

Don't take my word for it. Install Node as shown below and ask it:

node -p "process.versions.v8"
node -p "process.versions.uv"

14.6.202.34-node.40
1.52.1

Two numbers, two different parts. The first is V8, the engine. The second is libuv, which deserves its own section.

libuv: the one that waits for you

libuv is what makes Node's promise possible. Its job is talking to the operating system so your process can keep hundreds of operations in flight without hundreds of threads.

Every OS has its own mechanism: epoll on Linux, kqueue on macOS and the BSDs, completion ports on Windows. libuv puts one interface in front of all of them, and adds a thread pool for the jobs the OS can't background on its own — some disk operations, DNS, cryptography.

That kills a myth worth killing early: Node is not "single-threaded" in the sense that the process has one thread. Your JavaScript runs on one thread, yes, but there is more staff downstairs. What you don't get is one thread per request.

The practical consequence is the one that matters: while libuv waits, your main thread carries on. It doesn't sit around watching the data arrive; it handles the next thing. And when the data lands, it comes back.

What Node wins and what it loses

Node isn't better. It's different, and the difference fits in a table:

Situation	Node	The classic alternative
Many connections waiting on data	Shines: one thread serves them all	Every connection costs a thread
I/O-heavy API	Fits naturally	Works, with more machinery
Real time: chat, notifications	Open connections are cheap	Open connections are expensive
CPU-heavy work	Struggles: it blocks the thread	Spreads the work across threads
Number crunching, heavy processing	Not its turf	Exactly its turf

The row that decides the rest of this course is the fourth. In Node, if your code spends twenty seconds computing, the server stops answering for twenty seconds. There's no spare thread, nobody else at the door. We'll come back to that in detail, and it has a fix — but the fix is never "hope it doesn't happen".

JavaScript versus Python

You come from another language, so this comparison isn't decoration: it's the fastest way to learn. These are the differences that actually change how you write code.

Concept	Python	JavaScript
Typing	Dynamic, with optional type hints	Dynamic, no types in the language
Objects	Classic classes	Prototypes, with `class` as syntactic sugar
Numbers	Separate integers and floats	One type: IEEE 754 double precision
Concurrency	Threads under the GIL, plus `asyncio`	One thread and an event loop
Execution	Interpreted by CPython	Compiled on the fly by V8

Two caveats, because a table lies by omission.

Numbers are what trips up Python developers most. JavaScript has no integers: every number is a double-precision float. 0.1 + 0.2 isn't 0.3, it's 0.30000000000000004, and that's not a bug, that's the type. Big integers lose precision, which is exactly why BigInt exists.

Concurrency isn't about one being worse. The GIL and the event loop are two answers to the same question: how do you stop a program from staring at the ceiling while it waits.

You'll see the object model up close in the next lesson. For now, just know that class in JavaScript is not what it looks like: there are no real classes, there's a prototype chain with pleasant syntax on top.

Installing Node with nvm

You could install Node from the official site and have exactly one version. That works right up until the first project that needs a different one. Then the ritual starts: uninstall, reinstall, break something, roll back.

nvm is a version manager: it installs several at once and lets you switch per project. That switch is declared in a file, .nvmrc, which you commit with the code. From day one, because day one is when it costs nothing.

The official install is a script. If you'd rather use your package manager there are options, though mind the second one:

# macOS and Linux (Homebrew)
brew install nvm

# Ubuntu / Debian
# there is no official nvm package in the repositories:
# the documented route is the install script

# Arch Linux (AUR)
paru -S nvm

The route the project itself recommends:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash

Real output:

=> Downloading nvm from git to '/home/your-user/.nvm'
=> Cloning into '/home/your-user/.nvm'...
=> Compressing and cleaning up git repository
=> Appending nvm source string to /home/your-user/.bashrc
=> Appending bash_completion source string to /home/your-user/.bashrc

Then open a new terminal, or reload your shell file, so the command exists:

nvm --version

0.40.3

Now the useful part. Install the line that gets long-term support today:

nvm install --lts

Installing latest LTS version.
Downloading and installing node v26.13.1...
Computing checksum with sha256sum
Checksums matched!
Now using node v26.13.1 (npm v11.20.0)
Creating default alias: default -> lts/* (-> v26.13.1)

That lts/* is what you want: not a number that expires, but "whatever LTS is current". Check it:

node -v
npm -v

v26.13.1
11.20.0

And pin it as the default, so a fresh terminal doesn't start with the system one:

nvm alias default 'lts/*'

default -> lts/* (-> v26.13.1)

For a specific project, a .nvmrc with one line:

echo 'lts/*' > .nvmrc
nvm use

Found '/home/your-user/project/.nvmrc' with version <lts/*>
Now using node v26.13.1 (npm v11.20.0)

That file gets committed. Anyone who clones the repo runs nvm use and gets the same version you have, without reading a stale README. It's the "works on my machine" that actually works.

First contact with the runtime

Before writing real JavaScript, let's confirm the runtime is where you think it is. Create the course project:

mkdir node-backend && cd node-backend
npm init -y
mkdir -p src/lessons

Open package.json and add the line that turns on modern modules:

{
  "type": "module"
}

That "type": "module" is not decoration: it changes how Node reads import and export, and you'll use it for the whole course. Without it, Node assumes the old system and examples fail in a way that tells you nothing.

Now the first file, src/lessons/01-runtime.mjs:

console.log("Node", process.version);
console.log("Platform", process.platform, process.arch);
console.log("V8", process.versions.v8);
console.log("libuv", process.versions.uv);

Run it:

node src/lessons/01-runtime.mjs

Node v26.13.1
Platform linux x64
V8 14.6.202.34-node.40
libuv 1.52.1

On your machine linux x64 will read darwin arm64 on a recent Mac, win32 x64 on Windows. The V8 and libuv numbers move with patch releases. What doesn't change is what you just saw: Node isn't a language, it's a program made of parts, and those parts have versions.

process is the object representing the running process. It's global, always there, and it's the front door to nearly everything a server does: environment variables, arguments, signals, output. You don't need to memorise it today, just know it exists and that it isn't magic.

Common problems

`nvm: command not found`

The install script appends a few lines to .bashrc or .zshrc, but it doesn't reload the terminal you already had open. Open a new one, or source the file:

source ~/.bashrc

On zsh, source ~/.zshrc. And if you installed nvm through Homebrew, the Homebrew message may tell you to create ~/.nvm first — read it, it says so.

`node -v` shows a different version

Blame PATH. If Node is also installed by the system, by Homebrew, or by a manager like asdf, it can come first. Check:

which node

If the path isn't under ~/.nvm/versions/node/…, that's your problem. Sourcing nvm, opening a new terminal, or running nvm use in the project fixes it.

`.nvmrc` exists but the version doesn't change

.nvmrc is a declaration, not a command. Someone has to read it:

nvm use

Some shell setups load it automatically when you enter the directory, most don't. If it doesn't switch, run nvm use by hand before you start working.

`nvm install --lts` fails with a checksum or network error

Usually a corporate network, a proxy, or an odd mirror. Retry, and if it persists, check whether a proxy is intercepting HTTPS. It's not Node and it's not your code.

What you take from this lesson

You now know the ground you'll be working on:

JavaScript was built for the browser, and its event model turned out to be useful on a server.
V8 runs the language; Node is the environment around it.
libuv does the waiting, which is why Node handles thousands of connections on one JavaScript thread.
Node wins at I/O and loses at CPU work. That limit will show up again and again.
You have Node installed through nvm, with the version pinned in .nvmrc and an LTS default.
You ran code in the runtime and saw its parts report their own versions.

If you come from another language and this feels like translation, that's exactly what it is. Learning Node isn't memorising new syntax: it's translating what you know and finding the three or four places where the translation isn't exact.

If you don't program yet, this isn't your entry point: the Python from scratch course gives you the foundation this course assumes.

Next lesson we start on the language itself: variables, functions, destructuring, spread. No explaining what a variable is, and Python sitting next to it the whole way.

Never stop coding!

Setting Up PostgreSQL with Docker, psql, and pgAdmin

Javi Palacios — Wed, 11 Nov 2026 12:30:36 +0000

Time for the pleasant part: stop talking about databases as an idea and run one for real.

You open the terminal, type docker compose up, logs start flying, one line says database system is ready to accept connections, another looks like it was written by a printer having a difficult morning, and now you're thinking: is that it? Is PostgreSQL running? Where do I connect? Which user? Why does a database need more environment variables than some projects have tests?

Relax. We're not deploying production. We're building a lab. And a good lab needs three things: a database you can break without apologizing, a fast way to talk to it from the terminal, and a visual interface for looking around without feeling like you're defusing a bomb.

Today we'll set up that lab with PostgreSQL 18, Docker Compose, psql, and pgAdmin. CLI first, because psql is where you'll really learn SQL. pgAdmin comes second as a visual helper, for those days when a tree of tables feels calmer than another blinking prompt. We all have those days.

One thing before we go on: this assumes you have Docker installed and know how to bring something up with Compose. If that is not you yet, the Docker Compose lesson is where to start.

What we are actually running

Our environment will have two containers:

Service	Image	Purpose
`postgres`	`postgres:18`	The PostgreSQL server where the data lives
`pgadmin`	`dpage/pgadmin4:9.15`	A web UI for connecting to PostgreSQL

We'll also use a Docker volume to persist PostgreSQL data. That matters: if you remove the container but keep the volume, your data stays. If you remove the volume, it disappears. Docker has no emotional attachment to your tables. Useful to remember before experimenting with commands that start with docker volume rm.

The shape is this:

Your terminal
     │
     ├── docker compose
     │       ├── postgres container → PostgreSQL server
     │       └── pgadmin container  → Web UI
     │
     └── psql → command-line client

In the Docker course, we already work with containers, ports, and volumes. Here we won't become Docker administrators again; we'll use it as a tool to get PostgreSQL clean, reproducible, and easy to restart after we do something educational. “Educational” sometimes means “I broke everything.” That's part of the process.

Let's create the file.

Creating the lab project

Create a folder for the course:

mkdir -p ~/sql-course
cd ~/sql-course

Inside it, create a file named compose.yaml:

touch compose.yaml

Now write this configuration:

services:
  postgres:
    image: postgres:18
    container_name: sql-course-postgres
    environment:
      POSTGRES_USER: course_user
      POSTGRES_PASSWORD: course_password
      POSTGRES_DB: course_db
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U course_user -d course_db"]
      interval: 5s
      timeout: 5s
      retries: 5

  pgadmin:
    image: dpage/pgadmin4:9.15
    container_name: sql-course-pgadmin
    environment:
      PGADMIN_DEFAULT_EMAIL: admin@example.com
      PGADMIN_DEFAULT_PASSWORD: admin_password
    ports:
      - "5050:80"
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - pgadmin_data:/var/lib/pgadmin

volumes:
  postgres_data:
  pgadmin_data:

Before running it, let's understand it. Copying YAML without understanding it is like signing a contract because “the indentation looks clean.” Dangerous, though aesthetically pleasing.

Understanding the `compose.yaml`

The first part defines the postgres service:

postgres:
  image: postgres:18

This tells Docker to use the official PostgreSQL 18 image. We could use latest, but for a course that's a bad idea. latest can mean one thing today and another thing tomorrow. And when you're learning, having the floor move under your feet is not helpful. You already have NULL waiting for its turn.

The container_name line below is optional: it pins the container name so docker ps and docker compose logs postgres stay predictable instead of growing a suffix. Production files usually leave it out, because it stops the service from scaling to several replicas; in a lab, stable names are worth more than that freedom.

Then we have the environment variables:

environment:
  POSTGRES_USER: course_user
  POSTGRES_PASSWORD: course_password
  POSTGRES_DB: course_db

The official PostgreSQL image reads these variables when it initializes an empty database:

POSTGRES_USER: creates the initial user.
POSTGRES_PASSWORD: sets that user's password.
POSTGRES_DB: creates the initial database.

This only applies the first time the volume is initialized. If you change POSTGRES_PASSWORD after the container has already run, PostgreSQL won't magically rewrite the password. The data already exists inside the volume. Docker doesn't read your mind, and honestly that's probably for the best.

Then we expose the port:

ports:
  - "5432:5432"

The first 5432 is the port on your machine. The second 5432 is the port inside the container. PostgreSQL listens on 5432 by default, so we keep the classic mapping.

Next comes a very important line:

volumes:
  - postgres_data:/var/lib/postgresql

For PostgreSQL 18, the official image uses /var/lib/postgresql as the recommended volume location. The actual data directory lives inside that structure. Could you mount a different path? Yes. Do you need to today? No. Simplicity first. There will be time later for backups, upgrades, and decisions that make a DBA stare silently out the window.

The healthcheck asks whether PostgreSQL is ready:

healthcheck:
  test: ["CMD-SHELL", "pg_isready -U course_user -d course_db"]

pg_isready asks the server whether it is accepting connections and returns an exit code based on the answer. -U and -d tell it which user and which database to ask for; without them it would use the container's default user, which is not the one you want.

Careful with the attribution, because it is the most common misreading of a Compose file: the healthcheck does not wait for anything. It only declares the service's state, moving from starting to healthy once the first check passes. What actually waits is the condition on the other service, and that comes a couple of blocks further down.

The second service defines pgAdmin:

pgadmin:
  image: dpage/pgadmin4:9.15

pgAdmin needs an email and password to create its initial administrator user:

environment:
  PGADMIN_DEFAULT_EMAIL: admin@example.com
  PGADMIN_DEFAULT_PASSWORD: admin_password

This is a local lab. Do not use these credentials in production. That sounds obvious, but uploading .env files to GitHub also sounded obvious, and yet the internet is what it is.

Finally, we expose pgAdmin on port 5050:

ports:
  - "5050:80"

That means you'll open pgAdmin at http://localhost:5050.

And finally, the line that ties the two services together:

depends_on:
  postgres:
    condition: service_healthy

This is what actually keeps pgAdmin from starting too early: Docker waits for the postgres healthcheck to report healthy and only then brings pgadmin up. Without the healthcheck that condition would have nothing to check; without the condition, the healthcheck would report and nobody would listen. Both pieces together are what remove the classic “I opened the UI and it says it can't connect”.

We have the blueprint. Now let's power it on.

Starting PostgreSQL and pgAdmin

From the ~/sql-course folder, run:

docker compose up -d

The -d flag starts everything in the background. Without -d, the terminal stays attached to the logs, which is sometimes useful and sometimes like watching a fireplace made of text.

Check that the services are running:

docker compose ps

You should see something like this:

NAME                  IMAGE                 STATUS                    PORTS
sql-course-postgres   postgres:18           Up (healthy)              0.0.0.0:5432->5432/tcp
sql-course-pgadmin    dpage/pgadmin4:9.15   Up                        0.0.0.0:5050->80/tcp

If postgres says starting, wait a few seconds and run the command again. Databases also deserve to start with dignity.

You can inspect the logs with:

docker compose logs postgres

The line you're looking for is:

database system is ready to accept connections

Once you see that, PostgreSQL is ready.

Now let's talk to it from the terminal.

Connecting with `psql`

psql is PostgreSQL's command-line client. It's direct, powerful, and at first a little dry, like many tools you eventually learn to respect.

You can enter psql inside the container:

docker compose exec postgres psql -U course_user -d course_db

If everything works, you'll see something like this:

psql (18.4 (Debian 18.4-1.pgdg13+2))
Type "help" for help.

course_db=#

That course_db=# prompt means you're inside PostgreSQL, connected to the course_db database.

Try your first query:

SELECT version();

You'll see something like this:

                                              version
-----------------------------------------------------------------------------------------------------
 PostgreSQL 18.4 (Debian 18.4-1.pgdg13+2) on x86_64-pc-linux-gnu, compiled by gcc 14.2.0, 64-bit
(1 row)

Then try something smaller:

SELECT 1 + 1 AS result;

 result
--------
      2
(1 row)

Notice AS result. That's an alias: a temporary name for the output column. In this course we'll use aliases in snake_case, descriptive, and without quotes unless there is a strong reason. That means total_spent, not Total Spent, not x, not prettyColumnBecauseReasons. Queries deserve names that don't look like they were invented at 3 AM.

To exit psql, type:

\q

Yes, it starts with a backslash. In psql, client-specific commands use \. SQL queries end with ;. At first this looks like a tiny oddity. Then you discover that psql has a whole universe of internal commands and accept that terminals also have secret rooms.

Let's look at the useful ones.

Basic `psql` commands

Enter again:

docker compose exec postgres psql -U course_user -d course_db

Inside psql, try:

\l

Lists databases. You'll see four: yours, postgres, and the two templates PostgreSQL uses to create new databases.

                                       List of databases
   Name    |   Owner     | Encoding | Locale Provider |  Collate   |   Ctype
-----------+-------------+----------+-----------------+------------+------------
 course_db | course_user | UTF8     | libc            | en_US.utf8 | en_US.utf8
 postgres  | course_user | UTF8     | libc            | en_US.utf8 | en_US.utf8
 template0 | course_user | UTF8     | libc            | en_US.utf8 | en_US.utf8
 template1 | course_user | UTF8     | libc            | en_US.utf8 | en_US.utf8
(4 rows)

The ICU and privilege columns are trimmed here; PostgreSQL 18 prints more of them. What matters is that you recognise the shape.

\conninfo

Shows which database, user, and server you're connected to.

You are connected to database "course_db" as user "course_user" via socket in "/var/run/postgresql" at port "5432".

That /var/run/postgresql is the tell that you are inside the container, talking over the local socket instead of coming in over the network.

\dt

Lists tables in the current schema. Right now you'll probably see none, because we haven't created any tables yet. That's fine. A fresh lab doesn't have samples on the table.

\?

Shows help for psql commands. It's long. Very long. Don't try to memorize it. Nobody becomes a better person by learning every meta-command at once.

For now, these are the ones you need:

Command	What it does
`\q`	Exit `psql`
`\l`	List databases
`\conninfo`	Show current connection
`\dt`	List tables
`\d table_name`	Describe a table
`\?`	Show `psql` help

And here's the key difference:

SELECT 1;

That is SQL.

\dt

That is a psql command.

If you mix them up and something fails, it doesn't mean you're bad at SQL. It means you're learning where the language ends and the tool begins. Small border, large confusion. Classic computing.

Now let's open pgAdmin.

Connecting with pgAdmin

Open your browser at:

http://localhost:5050

Email: admin@example.com
Password: admin_password

You'll see pgAdmin. Breathe. Yes, it has many panels. Yes, it looks like an airplane cockpit designed by someone who deeply loves context menus. You don't need to understand all of it today.

To register the PostgreSQL server:

Right-click Servers.
Choose Register → Server....
In the General tab, use this name:

SQL Course PostgreSQL

In the Connection tab, use these values:

Field	Value
Host name/address	`postgres`
Port	`5432`
Maintenance database	`course_db`
Username	`course_user`
Password	`course_password`

The important detail is the host: inside Docker Compose, the service is named postgres. pgAdmin should not connect to localhost, because from pgAdmin's point of view localhost means “the pgAdmin container itself”, not your machine and not the PostgreSQL container.

This breaks brains. Not because it's advanced, but because the word localhost looks innocent and then turns out to have contextual identity. Like a polite villain.

Save the connection. If everything works, you'll see the server in the left tree. Open Databases and you should see course_db.

pgAdmin will help you inspect structures, explore tables, and run queries visually. But we'll build the muscle in psql. The UI helps; the terminal teaches. Also, no Electron fan heroics, which is always a small act of mercy.

Creating a test table

Back to psql for a real check:

docker compose exec postgres psql -U course_user -d course_db

Create a simple table:

CREATE TABLE books (
  id INTEGER,
  title TEXT,
  author TEXT
);

Now list the tables:

\dt

You should see something like this:

         List of relations
 Schema | Name  | Type  |    Owner
--------+-------+-------+-------------
 public | books | table | course_user
(1 row)

And if you want to see what is inside that table without opening pgAdmin:

\d books

                        Table "public.books"
 Column |  Type   | Collation | Nullable | Default
--------+---------+-----------+----------+---------
 id     | integer |           |          |
 title  | text    |           |          |
 author | text    |           |          |

Columns and types, still without PRIMARY KEY or NOT NULL. That is deliberate: they arrive in their own lesson.

Insert a couple of rows:

INSERT INTO books (id, title, author)
VALUES
  (1, 'The Pragmatic Programmer', 'Andrew Hunt and David Thomas'),
  (2, 'Designing Data-Intensive Applications', 'Martin Kleppmann');

Query the data:

SELECT id, title, author
FROM books;

 id |                title                 |             author
----+--------------------------------------+--------------------------------
  1 | The Pragmatic Programmer             | Andrew Hunt and David Thomas
  2 | Designing Data-Intensive Applications | Martin Kleppmann
(2 rows)

You just created a table, inserted data, and queried it. We haven't discussed primary keys, detailed data types, constraints, or design yet. That's coming soon. Right now the important part is proving that the lab works.

If you open pgAdmin and refresh Schemas → public → Tables, you should see the books table. If it doesn't appear, right-click and choose Refresh. pgAdmin sometimes needs to be reminded that the world has changed. We all know someone like that.

Stopping, starting, and cleaning the environment

To stop the containers without deleting data:

docker compose down

To start them again:

docker compose up -d

Your books table will still be there because it is stored in the postgres_data volume.

Check it:

docker compose exec postgres psql -U course_user -d course_db -c "SELECT id, title FROM books;"

The -c flag runs a query and exits. Very useful for quick checks.

If you want to delete the whole lab, including data:

docker compose down -v

⚠️ That -v removes the volumes defined by the Compose file. Here that means deleting postgres_data and pgadmin_data. In a lab, that's fine. In a real environment, this command can turn a normal morning into a meeting with security, product, and someone asking “do we have a backup?”

Use down -v only when you really want to start from zero.

Common problems

Port `5432` is already in use

If you have PostgreSQL installed locally, port 5432 may already be taken.

Change the external port:

ports:
  - "5433:5432"

Inside Docker it remains 5432; from your machine you connect through 5433.

pgAdmin does not connect with `localhost`

Inside pgAdmin, use postgres as the host, not localhost.

localhost from a container means “myself.” And pgAdmin, despite its enthusiasm, is not PostgreSQL.

I changed the password and it still fails

If the volume already existed, changing POSTGRES_PASSWORD in compose.yaml does not change the password inside PostgreSQL.

To restart from scratch:

docker compose down -v
docker compose up -d

This deletes data. Repeating it because this is where someone scrolls too fast and then looks at the terminal like it betrayed them: this deletes data.

`psql` is waiting because I forgot the semicolon

In SQL, many statements end with ;.

If you write:

SELECT 1

psql will show something like:

course_db-#

It isn't broken. It is waiting for you to finish the statement. Type:

And it will continue. The first time it's scary. The second time it's annoying. The third time it's just who you are.

What you take from this lesson

Today you set up the base environment for the course:

PostgreSQL 18 running in Docker.
A persistent volume so recreating containers doesn't delete your data.
psql as the main tool for running SQL.
pgAdmin as a visual helper.
A first books table to prove everything works.
The difference between SQL commands and psql meta-commands.

This is not “installing a tool.” This is preparing the workbench. From now on, when we talk about tables, columns, rows, constraints, or queries, they won't be drawings in the air: you'll have a real database where you can test things and break them with some elegance.

In the next lesson we'll write our first SELECT queries: choosing columns, using aliases, filtering results, and starting to read data with intention. That's where SQL stops being “that thing under the ORM” and starts looking like a very precise way to ask questions.

Never stop coding!

Linux essentials for DevOps: navigation, files, and permissions

Javi Palacios — Tue, 10 Nov 2026 14:20:31 +0000

You enter a Linux machine for the first time with actual professional intent. Not “I'll paste two commands from Stack Overflow and may the gods of production be kind,” but real professional intent.

You type ls / and get this:

bin  boot  dev  etc  home  lib  opt  proc  root  tmp  usr  var

And of course: what is etc? Why does usr look like someone lost a vowel? Is var short for variable? Is root a folder or a person with too much power? Can you touch anything or will the server start producing administrative smoke?

Don't worry. Linux is not trying to intimidate you. Well, maybe a little. But beneath those short names there is a solid logic. In DevOps, that logic is not optional: servers live on Linux, logs live on Linux, services are configured on Linux, and many incidents start with someone saying “I only moved a file.” Spoiler: it was never just a file.

The Linux filesystem is not one giant folder

In Linux everything hangs from a single root: /.

There is no C:\, D:\, or separate drive tree like on Windows. There is one tree. Everything lives inside that tree: disks, users, configuration, logs, processes, devices, and a few corners that look like they were named to check whether you were paying attention.

A simplified map looks like this:

/
├── bin      → Essential commands like ls, cp, mv
├── etc      → System and service configuration
├── home     → User directories
├── opt      → Optional third-party software
├── tmp      → Temporary files
├── usr      → User-space programs and libraries
└── var      → Variable data: logs, caches, queues

Think of / as a technical building:

/home contains the users' apartments.
/etc is the room with manuals, keys, and configuration.
/var is the storage room where things change constantly: logs, queues, caches.
/tmp is the workbench where temporary stuff is left and later cleaned up.
/bin and /usr/bin are shelves full of tools.

You don't need to memorize every directory today. No serious person learns Linux by reciting /usr/libexec like medieval poetry. What you need is to know where things usually live and, above all, not treat / like a downloads folder you can reorganize “your way.”

Let's move through that tree.

Knowing where you are: `pwd`, `ls`, and `cd`

Before touching anything in a terminal, you need orientation. In a graphical interface you see windows, icons, and folders. In a terminal, your map starts with three commands:

pwd: prints where you are.
ls: lists what is there.
cd: changes directory.

Enter the course VM if you're following the recommended setup:

multipass shell devops-lab

Now ask where you are:

pwd

/home/ubuntu

That means you are in the personal directory of the ubuntu user.

List its content:

ls

You'll probably see little or nothing. Normal. A newly created home doesn't have boxes all over the floor yet. Give it time.

Now use more useful formats:

ls -l
ls -lh
ls -la

The difference matters:

Command	What it shows
`ls`	Basic names
`ls -l`	Long format: permissions, owner, size
`ls -lh`	Human-readable sizes
`ls -la`	Hidden files too, like `.bashrc`
`ls -ltr`	Sorted by date, most recent last

Files starting with . are hidden by convention. They are not magic. They are not ashamed. They are usually configuration files you don't want mixed with everything else.

Move around:

cd /var/log
pwd
ls -lh

Go back home:

cd ~

Go up one level:

cd ..

Return to the previous directory:

cd -

cd - looks like a tiny detail until you're jumping between /etc/nginx/sites-available and /var/log/nginx and start feeling like you could get lost inside your own terminal. Then it stops being a detail and becomes basic survival.

You can now look and move. Time to create your own ground.

Creating directories without starting an archaeological dig

In the previous tutorial we created a workspace called ~/devops-course. Let's use it:

cd ~/devops-course
pwd

If you don't have it, create it now:

mkdir -p ~/devops-course/{scripts,configs,logs,projects,notes}
cd ~/devops-course

The -p flag in mkdir means: “create parent directories if they don't exist and don't complain if they already do.” It is one of those humble flags that prevents unnecessary drama.

Compare:

mkdir projects/app

If projects does not exist, it fails.

mkdir -p projects/app/src

If the whole path is missing, it creates it. No speech. No Jira ticket.

To see the structure more nicely, you can use tree. If you don't have it installed:

# macOS and Linux (Homebrew)
brew install tree

# Ubuntu / Debian
sudo apt install -y tree

# Arch Linux
sudo pacman -S tree

Now:

tree ~/devops-course

/home/ubuntu/devops-course
├── configs
├── logs
├── notes
├── projects
└── scripts

tree is not mandatory, but it helps a lot when a structure grows. And in DevOps, structures grow. Sometimes in healthy ways. Sometimes like a final-FINAL-v2 folder nobody dares to delete.

You have space. Now let's create files.

Creating, copying, moving, and renaming files

Create an empty file:

touch notes/lesson-03.md

Write one line of text:

printf 'Linux navigation practice\n' > notes/lesson-03.md

Notice >: it redirects output and overwrites the file. If there was content before, it replaces it. No questions asked. Linux trusts you a lot, which is beautiful until you remember that sometimes you shouldn't trust yourself that much either.

Append content without deleting what was already there:

printf 'Current directory: %s\n' "$(pwd)" >> notes/lesson-03.md

>> appends to the end.

Now copy the file:

cp notes/lesson-03.md notes/lesson-03-copy.md

Rename it:

mv notes/lesson-03-copy.md notes/linux-filesystem-notes.md

Move it to another directory:

mv notes/linux-filesystem-notes.md configs/

Yes, mv is used both for moving and renaming. It is the same concept: changing a file path. If the name changes inside the same directory, we call it renaming. If the directory changes, we call it moving. The tool does not need two different buttons to feel complete.

To copy directories, you need -r:

cp -r configs configs-backup

-r means recursive: copy the directory and its content. Without -r, cp refuses because a directory is not a simple file. Good for cp. Someone had to set boundaries.

Before deleting anything, let's learn to inspect content.

Reading files without opening an editor

On servers, you often don't want to edit a file. You just want to see it. For that you have several tools:

cat notes/lesson-03.md

cat prints the whole file. Good for small files. For large files, cat is like opening a hose inside your house: everything comes out, technically it works, but maybe that was not the plan.

See the beginning:

head -n 5 /var/log/syslog

See the end:

tail -n 5 /var/log/syslog

Follow a file in real time:

tail -f /var/log/syslog

tail -f is fundamental for logs. It watches the file and prints new lines as they appear. It is the terminal equivalent of standing next to a door waiting for someone to enter, but with more professional value.

Navigate a long file:

less /var/log/syslog

Inside less:

Space: move down one page.
b: move up one page.
/text: search.
n: next match.
q: quit.

Yes, q to quit. If that just reminded you of Vim, fair. And if Vim still stares at you from a corner like a final boss, Mastering Vim from Scratch starts exactly with surviving that first encounter.

You can now create, move, and read. Next comes the part where slowing down is wise.

Deleting files: the chainsaw moment

Delete a file:

rm configs/linux-filesystem-notes.md

Delete an empty directory:

rmdir configs-backup

If the directory has content, rmdir refuses. Good. That refusal is a handrail.

Delete a directory with everything inside:

rm -r configs-backup

And here comes the classic:

rm -rf some-directory

-r deletes recursively. -f forces and reduces questions. Together they are useful. Also dangerous. rm -rf is not evil, but it is a chainsaw: legitimate tool, terrible idea to use while sleepy and without checking where it points.

Simple rule:

pwd
ls -la some-directory
rm -rf some-directory

First confirm where you are. Then confirm what you are deleting. Then delete.

If you're writing scripts, use the defensive version:

rm -rf -- "$target_directory"

That -- marks the end of options and prevents a weird value starting with - from being interpreted as a flag. The quotes are what keep spaces and special characters from turning your script into an episode of a true-crime podcast. Both are the groundwork for everything that follows: in the coming lessons you'll meet them inside real scripts, where one unprotected space stops being a detail and becomes a half-deployed service.

If you want the whole story, the automation part of this course covers it end to end.

Now let's talk permissions, because sooner or later you'll see Permission denied and think Linux has something personal against you.

Understanding permissions: `rwx` without dark magic

Run:

ls -l notes/lesson-03.md

You'll see something like this:

-rw-r--r-- 1 ubuntu ubuntu 62 Aug  3 10:00 notes/lesson-03.md

The important part is this:

-rw-r--r--

Read it like this:

- rw- r-- r--
│ │   │   └── others
│ │   └────── group
│ └────────── owner
└──────────── type

The first character indicates the type:

-: regular file.
d: directory.
l: symbolic link.

Then come three blocks:

owner;
group;
others.

Each block can contain:

r: read;
w: write;
x: execute.

For a file, x means it can be executed as a program or script. For a directory, x means it can be entered or traversed. Yes, the same symbol changes meaning slightly depending on context. Linux does these things. Don't stress: with practice it starts making sense.

Create a small script:

cat > scripts/hello.sh <<'EOF'
#!/usr/bin/env bash
printf 'Hello from Linux\n'
EOF

Try to run it:

./scripts/hello.sh

You'll probably get:

bash: ./scripts/hello.sh: Permission denied

The file exists, but it has no execute permission. Add it:

chmod +x scripts/hello.sh

Now:

./scripts/hello.sh

Hello from Linux

You'll also see permissions in numeric form:

chmod 755 scripts/hello.sh
chmod 644 notes/lesson-03.md

Practical translation:

Mode	Usual meaning
`755`	owner everything, others read and execute
`644`	owner reads/writes, others only read
`600`	only the owner reads/writes
`700`	only the owner has everything

Don't memorize every number like safe combinations. Keep the common ones. In DevOps you'll see 600 for private SSH keys, 700 for .ssh, 755 for executable scripts/directories, and 644 for regular files.

Changing the owner: `chown`

chmod says what can be done with a file. chown says whose it is:

sudo chown ubuntu:ubuntu configs/app.env

That sets ubuntu as owner and ubuntu as group. For a whole tree:

sudo chown -R deploy:deploy /srv/app

-R is recursive, same as in cp and rm, with the same warning attached: pointed at the wrong path it changes the owner of half the machine. Check it first with ls -l, exactly as you did before deleting anything.

In DevOps you'll reach for it mostly when deploying: files arrive owned by one user and the service runs as another, and until the owner matches, the process cannot write its own logs. Which is why Permission denied rarely means “Linux has it in for you”: it means the file belongs to somebody else.

Permissions are clearer now. The last missing piece is finding things, because a real server never leaves important files neatly on the table.

Finding files and searching inside them

Find files by name:

find ~/devops-course -name "*.md"

Find directories:

find ~/devops-course -type d

Find recently modified files:

find ~/devops-course -type f -mtime -7

find looks rough at first. Then you discover it can locate almost anything if you give it clear criteria. It is like a tracking dog, but with syntax from the seventies.

Search text inside files:

grep -r "Linux" ~/devops-course/notes

Useful options:

grep -ri "linux" ~/devops-course/notes
grep -rn "Linux" ~/devops-course

Command	What it does
`-r`	searches recursively
`-i`	ignores case
`-n`	shows line numbers

Later you'll use more modern tools like rg (ripgrep) because they are extremely fast and pleasant. But grep is everywhere. On a minimal machine, in a tiny container, on a server with a 2014 personality: grep is usually there. Learn it first. Add the turbo later.

Guided practice: prepare an operations structure

Let's put everything together in a small practice. Create a structure simulating an operations project:

cd ~/devops-course
mkdir -p projects/webapp/{bin,config,logs,tmp}

Create a configuration file:

cat > projects/webapp/config/app.env <<'EOF'
APP_ENV=development
APP_PORT=8080
LOG_LEVEL=info
EOF

Create a script:

cat > projects/webapp/bin/start.sh <<'EOF'
#!/usr/bin/env bash
printf 'Starting webapp on port 8080\n'
EOF

Make it executable:

chmod +x projects/webapp/bin/start.sh

Generate a fake log:

printf '[INFO] Application started\n' > projects/webapp/logs/app.log
printf '[WARN] Cache is empty\n' >> projects/webapp/logs/app.log

Check the structure:

tree projects/webapp

projects/webapp
├── bin
│   └── start.sh
├── config
│   └── app.env
├── logs
│   └── app.log
└── tmp

Run the script:

./projects/webapp/bin/start.sh

Search configuration:

grep -n "APP_PORT" projects/webapp/config/app.env

Read logs:

tail -n 10 projects/webapp/logs/app.log

Check permissions:

ls -l projects/webapp/bin/start.sh

This practice looks small, but it contains half of operational life: structure, configuration, scripts, logs, permissions, and search. Change the names and you're already close to what you'll do with real services.

What you should take from this lesson

Linux becomes less scary when you stop seeing it as a black box and start seeing it as a system with a map.

Keep this:

/ is the root of the filesystem.
/home, /etc, /var, /tmp, /usr, and /opt have common responsibilities.
pwd, ls, and cd provide basic orientation.
mkdir, touch, cp, mv, and rm manipulate files and directories.
cat, head, tail, and less let you read without editing.
chmod controls permissions; rwx is not decoration.
find and grep help you locate files and content.
rm -rf is used with respect, not faith.

Challenge: Inside ~/devops-course/projects, create an api-service directory with bin, config, and logs subdirectories. Add an executable bin/healthcheck.sh script that prints OK, a config/service.env file with SERVICE_PORT=3000, and a logs/service.log file with two lines. Then use find, grep, ls -l, and tail to prove everything exists and makes sense.

In the next tutorial we'll continue with Linux, but one level higher: processes, services, basic networking, and system logs. In other words, the part where the machine stops being “files in folders” and starts behaving like a living system that sometimes needs care, sometimes needs a restart, and sometimes needs you to read journalctl before blaming Kubernetes.

Never stop coding!

Verifying and understanding AI-generated code

Javi Palacios — Mon, 09 Nov 2026 15:30:37 +0000

AI gives you a beautiful function. Clear names, type hints, decent structure. It even looks like it was written by someone who slept eight hours, which already puts it ahead of a worrying amount of human Tuesday-afternoon code.

You copy it, paste it, run something quick, and it works.

Then the uncomfortable question arrives: can you explain every line? Do you know what happens with weird input? Did you check for an except Exception: pass tucked away like a roach under the fridge? Or are you about to add code to your project because it “looks fine” and has nice hair?

This is one of the most important rules of working with AI: never accept code you don't understand. Not because AI is bad. Not because every line must be handcrafted with artisanal suffering as if programming were stone carving. But because once code enters your repo, it becomes your responsibility. The blame will not say “a very confident model wrote this.” It will say your name. How thoughtful.

In the previous lesson we looked at refining an AI conversation without losing control. Now comes the professional filter: deciding whether generated code deserves to enter your project or needs to go back in the oven.

The “can I explain this?” test

The first filter is not tests. It is more uncomfortable: explaining the code in your own words.

If AI generates this:

from collections import defaultdict


def group_orders_by_user(orders: list[dict]) -> dict[int, list[dict]]:
    grouped_orders: dict[int, list[dict]] = defaultdict(list)

    for order in orders:
        grouped_orders[order["user_id"]].append(order)

    return dict(grouped_orders)

Before using it, you should be able to answer:

What does defaultdict(list) do?
Why is it converted to dict at the end?
What happens if an order does not have user_id?
What happens if user_id is a string?
Does the function modify the original objects or only group them?

If you can't answer, that's fine. Really. The problem is not not knowing; the problem is pretending you do because the code looks nice. That is the path to production with a flashlight and no batteries.

You can use AI itself to explain the code:

Explain this code line by line.

For each line or block:
- What it does
- Why it is necessary
- What it assumes about the input data
- What could fail

Do not suggest improvements yet. Only explain.

That “do not suggest improvements yet” matters. Without it, AI may jump into refactoring before you understand the current version. Then you have two problems: the original code you didn't understand and a new version you also don't understand. The worst kind of two-for-one.

Make AI declare its assumptions

Generated code always contains assumptions. Some are reasonable. Others are the technical equivalent of “surely nobody will pass a string here.” Spoiler: somebody passed a string.

Ask AI to bring those assumptions into the open:

List every assumption this code makes.

Classify them as:
1. Assumptions about input data
2. Assumptions about the environment
3. Assumptions about performance
4. Assumptions about security

For each assumption, explain what would happen if it is false.

For the previous function, a good review should point out things like:

Each order must be a dict
Each order must contain the user_id key
user_id must be an integer if you want the return type to be true
The list must fit in memory
There is no structure validation

Notice what just happened: the function did not change, but your understanding did. Now you know where the corners are. And in programming, corners matter, because that is where the bug sits with a coffee and infinite patience.

Tests are not decoration

The second filter is tests. Not as a religious ceremony, but as a concrete way to say: “this does what I think it does.”

For the function above, you can ask for tests like this:

Write pytest tests for this function.

Cover:
- Empty list
- One order
- Multiple orders for the same user
- Orders for different users
- Order without user_id
- user_id with the wrong type
- Large list (100,000 orders): time should grow linearly, not quadratically

Do not change the implementation yet.

The last line matters again. First you want tests that describe behavior and edge cases. Then you decide whether the implementation needs to change.

An initial set could be:

import pytest

from orders import group_orders_by_user


def test_groups_orders_by_user_id() -> None:
    orders = [
        {"id": 1, "user_id": 10, "total": 25.0},
        {"id": 2, "user_id": 10, "total": 15.0},
        {"id": 3, "user_id": 20, "total": 40.0},
    ]

    result = group_orders_by_user(orders)

    assert result == {
        10: [orders[0], orders[1]],
        20: [orders[2]],
    }


def test_returns_empty_dict_for_empty_list() -> None:
    assert group_orders_by_user([]) == {}


def test_raises_key_error_when_user_id_is_missing() -> None:
    orders = [{"id": 1, "total": 25.0}]

    with pytest.raises(KeyError):
        group_orders_by_user(orders)

Are these tests perfect? No. Are they better than “I tried one example and it seems fine”? Massively. That “seems fine” has funded more overtime than many consulting companies.

If you are also following the Python from scratch course, this connects to something fundamental: a function is not just the code you write, it is the contract it fulfills. Tests make that contract visible.

Red flags that are not negotiable

Some signals should make you stop. Not “I'll check later.” Not “surely it doesn't matter.” Stop.

AI can generate reasonable code and still sneak in dangerous things. Especially if the prompt was broad, the context was incomplete, or you asked for “production-ready” code, that phrase that summons demons with Scrum certification.

Look for this:

TODO inside critical logic.

def charge_customer(customer_id: str, amount: float) -> None:
    # TODO: implement payment retry logic
    payment_provider.charge(customer_id, amount)

A TODO here is not an innocent note. It is debt with interest.

Silently swallowed exceptions.

try:
    send_invoice(invoice)
except Exception:
    pass

This is not error handling. It is putting duct tape over the red warning light in your car. The problem is still there, but now you also can't see it.

Hardcoded secrets.

API_KEY = "sk_live_123456"

No. Just no. Not for testing. Not “I'll change it later.” Git has memory. GitHub too. The internet, unfortunately, has better memory than some product teams.

SQL built by string concatenation.

query = "SELECT * FROM users WHERE email = '" + email + "'"

If this appears, an alarm should go off. Use parameterized queries. SQL injection is not an urban legend seniors tell juniors to scare them; it still works because we still write things like this.

HTML built by gluing user data together.

return f"<p>Order for {email}</p>"

The same mistake in a different suit. If that email comes from a form, someone can drop a <script> in there and wait. Templates that escape by default (Jinja, React) have your back; the moment a |safe, an innerHTML or a dangerouslySetInnerHTML shows up, you need to know exactly why it is there. And “the AI wrote it” is not a reason.

Complex regex without explanation.

pattern = r"^(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*?&])[A-Za-z\d@$!%*?&]{8,}$"

It might be correct. It might also be a trap shaped like a hieroglyph. If AI generates a complex regex, ask it to explain it and add tests. If you cannot understand it, don't place it in critical logic.

The serious review prompt

After understanding the code and getting basic tests, ask for a review with professional suspicion. Not so AI can gently critique itself with corporate softness, but so it searches for concrete problems.

Use something like this:

Review this code as if you were responsible for approving it in a code review.

Look specifically for:
1. Functional bugs
2. Missing edge cases
3. Security risks (SQL injection, XSS, hardcoded secrets)
4. Performance problems
5. Hidden assumptions
6. Unnecessarily complex code
7. Differences between what the code does and what the name promises

For each finding, answer with:
- Severity: high, medium, or low
- Concrete evidence in the code
- Why it matters
- Minimal recommended change

Do not rewrite the whole code unless it is strictly necessary.

This structure avoids two common problems: AI replying “looks good” with a plastic smile, or rewriting everything because it got excited. You want findings, evidence, and minimal changes. Surgery, not a full bathroom renovation.

You can also ask it to compare against the tests:

Compare the implementation with the tests.

Indicate:
- Which behaviors are covered
- Which behaviors are not covered
- Which test you would add before modifying the implementation
- Whether any test asserts questionable behavior

This is especially useful because tests can also be wrong. Unpleasant surprise: AI can generate tests that verify exactly the bug it just invented. Green tests, wrong code. All very elegant.

Understanding does not mean memorizing everything

There is a psychological trap here: thinking that “understanding the code” means being able to rewrite it from memory on a whiteboard while somebody stares at you like you're in the interview.

No.

Understanding means you can explain:

What problem it solves
What inputs it expects
What outputs it promises
What errors it can raise
What important decisions it makes
Which cases are still not covered
Which part still makes you uncertain

That last point is key. A professional developer is not someone who never has doubts; it is someone who can locate them. “I don't understand this part” is not a defeat. It is a sign that you should not merge yet. Much better than the classic “I think it's fine,” a sentence that should come with a fire extinguisher.

A useful practice is asking for a reverse explanation:

Ask me questions to check whether I understand this code.

Start with easy questions and increase the difficulty.
Do not give me the answers until I respond.

This turns AI into an examiner, not a generator. And it is uncomfortable in the right way: it forces you to demonstrate understanding, not just nod while reading.

When to accept, refine, or reject

After reviewing, you have three options.

Accept when:

You understand the code
Tests cover the important behaviors
There are no serious red flags
It fits the project's conventions
The change is simpler than the problem it solves

Refine when:

The idea is correct, but validation is missing
Naming is confusing
Tests are insufficient
There is a clear edge case to add
The implementation works, but is more complex than necessary

Reject and start fresh when:

You cannot explain an important part
The architecture does not fit
There are structural security risks
AI assumed false requirements
Fixing it would cost more than asking for a new version

This decision matters more than the perfect prompt. The perfect prompt does not exist. What exists is judgment. And judgment is trained by reviewing, testing, rejecting, and asking again with better constraints. Yes, it is more work than copy-paste. It also comes with fewer surprises.

Key concepts from this lesson

AI-generated code enters your repo under your responsibility
If you cannot explain an important line, you should not accept it yet
Ask AI to declare assumptions before refactoring
Tests turn “it seems to work” into verifiable behavior
Security red flags, secrets, SQL injection, and swallowed errors are not negotiable
A good review asks for evidence and minimal changes, not theatrical rewrites
Accepting, refining, or rejecting is a technical decision, not an emotional one

AI can write code quickly, but speed without judgment only gets you to the bug faster. Your job is not to compete with AI by writing more lines; it is to direct, understand, and decide what deserves to live in the project.

In the next lesson we'll zoom out and look at the AI tool landscape for developers — chats, IDE integrations, terminal agents, and APIs — and when each one makes sense without turning your workflow into a subscription flea market.

Never stop coding!

Iteration and refinement: the AI dialogue

Javi Palacios — Tue, 27 Oct 2026 11:42:23 +0000

You ask AI for a small function. Nothing dramatic. A quiet little function that fits on screen and minds its own business.

Three messages later, the function has logging, validation, caching, metrics, timezone support, a Manager class, two custom exceptions, and the unmistakable feeling that someone has lost control of the construction site.

When did that happen? Which exact prompt turned a function into a seed-stage startup? Was it you? Was it the AI? Was it enthusiasm? Yes.

Working with AI is not about writing one perfect prompt and waiting for code to fall from the sky smelling faintly of fresh coffee. It's a refinement dialogue. You ask for something, evaluate the answer, correct it, tighten it, cut it down, and ask again. Done well, the result improves step by step. Done badly, you end up with a long, contradictory conversation and code that no longer remembers why it was born.

In the previous lesson we looked at generating code with AI without asking “make me things” and hoping for the best. Now comes the part immediately after that: what to do when the first answer is not enough. Which is most of the time. Mild surprise.

The first answer is rarely the right one

The first AI response is usually a draft. Sometimes a good draft. Sometimes a draft wearing clown shoes. But still a starting point, not a stone tablet carried down from a mountain.

This matters because many people treat the first answer like a pass/fail exam: if it's wrong, “AI is useless”; if it's right, they copy it; if it's half-right, they copy it anyway but with a worried expression. None of those is a professional workflow.

A healthier flow looks like this:

Round 1:
"Create a basic working version. Prioritize clarity over optimization."

Round 2:
"Now handle the edge case where the list is empty."

Round 3:
"This version loops over the list twice. Refactor it to use a single pass."

Round 4:
"The code works, but the names don't explain intent. Improve names without changing behavior."

Round 5:
"Add tests for the normal case, empty list, and duplicate values."

Notice the structure: each round changes one specific thing. You don't say “improve it.” “Improve it” is a black box. It could mean performance, readability, architecture, security, naming, tests, or the AI deciding to introduce a Strategy pattern because apparently today we are doing Enterprise Java.

Good refinement means directing. Not vaguely nudging.

The refinement loop

The basic pattern has four steps:

Ask for a concrete version
Evaluate what works and what doesn't
Correct one specific dimension
Verify that the previous behavior still holds

The part people skip is the third or the fourth. Usually both, because humans are optimistic until production educates them.

Look at this example:

I want a Python function that receives a list of prices and returns the total
including tax. The tax rate should be configurable. Prioritize clarity.

AI might return this:

def calculate_total_with_tax(prices, tax_rate=0.21):
    total = 0
    for price in prices:
        total += price
    return total + (total * tax_rate)

Not bad. But maybe you want type hints and validation:

Keep the same logic, but add type hints.
If any price is negative, raise ValueError.
Do not change the function name.

That Do not change the function name looks silly until you don't include it. Then the AI decides calculate_total_with_tax is now called compute_invoice_amount because it sounds more professional. And yes, it does sound more professional. It also just broke all your tests.

A refined answer might be:

def calculate_total_with_tax(prices: list[float], tax_rate: float = 0.21) -> float:
    for price in prices:
        if price < 0:
            raise ValueError("Prices cannot be negative")

    total = sum(prices)
    return total + (total * tax_rate)

Better. Now verify:

Check whether the change preserves the previous behavior.
Compare the original version and the new one for these cases:
1. [10, 20]
2. []
3. [0]
4. [-5]

Format:
- Case
- Original result
- New result
- Relevant difference

This step is not ceremonial. It's the equivalent of looking both ways before crossing the street. Most days nothing happens. On the day something does, you're glad you weren't crossing while staring at your phone.

Change one thing at a time

The golden rule of refinement is simple: one dimension per round.

Don't do this:

Make it faster, cleaner, add tests, handle errors, use better architecture,
explain the changes, and make it production-ready.

That prompt looks productive. It is actually six conversations stuffed into one and asked politely not to collide. What happens if the result gets worse? Was it the optimization? The architecture? The tests? The moon in Capricorn? Good luck debugging that.

Do this instead:

First, review readability only.
Do not change behavior.
Do not optimize yet.
Return only the refactored version and a list of naming changes.

Then:

Now review performance.
Keep the same behavior and the same public interface.
Point out any trade-off before changing the code.

Then:

Now add tests.
Do not modify the implementation unless you find a real bug.

This is not slower. It's how you avoid rebuilding the whole cabinet because you tightened three screws at once and now the door closes like it has unresolved resentment.

Good refinement leaves a trail. You know what changed, why it changed, and what was not supposed to change.

When to refine and when to start fresh

Here's a decision that separates beginner AI usage from professional AI usage: not every conversation deserves to be rescued.

Refine when the base is good:

The general idea fits
The code works on the happy path
The structure makes sense
The problems are localized
You can clearly describe what you want changed

For example:

The general solution works for me.
Refine only the error handling: right now it silently returns None,
but I want it to raise ValueError with a clear message.
Do not change the function signature.

Start fresh when the foundation is crooked:

The architecture doesn't fit your project
The AI assumed false requirements
The conversation now mixes contradictory decisions
You've corrected the same thing three times and it keeps coming back
The code works, but by accident and with a damp basement smell

That's when you cut:

Let's start over.
Ignore the previous approach.

New goal:
[clear description]

Constraints:
- [constraint 1]
- [constraint 2]
- [constraint 3]

Do not reuse code from the previous response unless I explicitly ask for it.
Before writing code, summarize the proposed design in 5 bullets.

“Ignore the previous approach” is not magic, but it helps. The important part is that you provide a clean new specification. You are not trying to patch a conversation that now looks like a 73-message Slack thread where nobody knows whether we're still discussing the original bug.

If you're unsure, use this rule: if you can explain the change in one sentence, refine. If you need to explain the entire history of how you got there, start fresh.

Managing long conversations

Long AI conversations have a problem: context gets diluted. It doesn't disappear all at once, but it loses weight. Important decisions compete with old details, discarded changes, temporary examples, and that response from twenty minutes ago where you asked for “just a quick test.” Yes, that quick test now lives in the context like inherited furniture.

To stay in control, use checkpoints.

Every few rounds, ask for an operational summary:

Summarize the current state of the solution.

Format:
1. Original goal
2. Decisions made
3. Current requirements
4. Constraints that must NOT change
5. Code or files affected
6. Pending work

Then review the summary. This matters: do not accept the summary without reading it. AI can confidently summarize things you never decided. Very human skill, actually; it also happens in meetings.

If the summary is correct, use it as the new anchor:

Use this summary as the main context for the next responses.
If anything contradicts earlier messages, prioritize this summary.

And if you're opening a new conversation, paste your own summary:

Working context:
- I'm implementing [feature]
- We already decided [decision]
- We don't want [constraint]
- The expected behavior is [behavior]
- The current problem is [problem]

Task:
Help me continue from here.

This reduces noise dramatically. Not because AI has “perfect memory,” but because you're putting the map back in front of it. And trust me: in long conversations, the map is not optional. It's the difference between reaching the destination and optimizing a function nobody uses anymore.

The refinement template

Save this template. It's simple, but it prevents 80% of the chaos:

Original goal:
[what I wanted to achieve]

Current response:
[paste the relevant part, not the whole novel]

What works:
- [point 1]
- [point 2]

What I want changed:
- [specific change]

Constraints:
- Do not change [interface / name / behavior / format]
- Keep [convention / style / dependency]
- Do not add [thing you don't want]

Response format:
1. Briefly explain the change
2. Return the refined version
3. List what stayed the same
4. Mention any trade-off

Example:

Original goal:
Create a function that groups users by country.

Current response:
[paste function]

What works:
- The output shape is correct
- The normal case works

What I want changed:
- Handle users without a country using the key "unknown"

Constraints:
- Do not change the name group_users_by_country
- Do not change the output format
- Do not add dependencies
- Do not turn this into a class

Response format:
1. Briefly explain the change
2. Return the refined function
3. List what stayed the same
4. Mention any trade-off

The sentence “Do not turn this into a class” belongs in a museum. Not because classes are bad, but because AI has a habit of putting formal clothes on problems that were perfectly fine in a t-shirt.

Ask for differences, not just new versions

When refining, we often ask for “the improved version.” That's fine, but one piece is often missing: understanding what changed.

Ask for a conceptual diff:

Before giving me the final code, summarize the changes from the previous version:
- What changed
- What stayed the same
- Why the change improves the solution
- What risk it introduces, if any

This forces you to review with judgment. If the AI says “the signature stayed the same” and you can see the signature changed, you now know not to trust that answer without inspection. Excellent: you found the problem before pasting code.

You can also ask it to show only the relevant changes:

Return only the modified parts.
Do not repeat the whole file unless necessary.

This is especially useful when working with large files. If every response repeats 300 lines, your conversation fills with noise and you end up scrolling like you're searching for a hidden clause in a phone contract.

Less text does not always mean less quality. Sometimes it means less surface area for things to break unnoticed.

Don't let AI move the goalposts

The biggest danger in refinement is not that AI makes a mistake. We already expect that. The real danger is that it slowly changes the goal and you don't notice.

You start with:

I want to validate an email.

Five rounds later you're discussing users, allowed domains, normalization, DNS verification, rate limiting, and a notification service. All of it may be reasonable. It may also be completely unnecessary.

That's why it's useful to repeat the original goal during the conversation:

Remember the goal: validate the format of an email on the frontend.
We are not implementing user registration.
Do not add domain verification.
Do not introduce network calls.

This is not being rude. It's directing. AI does not pay the maintenance cost of keeping a system simple. You do. You will maintain that code when the excitement is gone and only the repository remains.

A good warning sign: if a response introduces an abstraction you didn't ask for, pause. Ask:

Why did you introduce this abstraction?
What concrete problem does it solve in this case?
What would the simplest version look like without it?

Sometimes the abstraction will be justified. Often it won't. That's where you need to act like an architect, not a spectator. AI proposes; you decide. If you reverse that order, your code starts looking like a house designed by someone paid per hallway.

Key concepts from this lesson

The first AI response is usually a draft, not the final result
Good refinement changes one concrete dimension per round
“Improve it” is too vague; ask for specific, verifiable changes
Refine when the base is good; start fresh when the approach is crooked
In long conversations, use checkpoints and summaries you actually review
Ask what changed and what stayed the same, not just for a new version
Repeat the original goal to prevent the conversation from moving the goalposts
AI proposes; you direct and decide

💡 Challenge: Take an AI response you've used recently and run one controlled refinement round. Change only one thing: readability, performance, error handling, or tests. Before accepting the result, ask what changed, what stayed the same, and what risk it introduces.

Refinement is where AI stops being an answer machine and starts becoming a real working tool. But one critical piece is still missing: understanding and verifying the code it generates. In the next lesson we'll review code line by line, spot red flags, and avoid trusting code that works only because God is good.

Never stop coding!

Scope and namespaces in Python: where your variables live

Javi Palacios — Mon, 26 Oct 2026 07:43:49 +0000

You have a variable called counter. You can see it. It's right there. You wrote it yourself, probably after a coffee that stopped being warm twenty minutes ago. You run the program and Python tells you it has no idea what variable you're talking about.

Excuse me? Didn't we just see it? Did it leave the building? Do variables have private lives now?

Welcome to scope: the part of Python that decides where each name can be seen from. It isn't black magic, although at first it has the same energy as looking for a missing sock inside a washing machine that swears it knows nothing.

What scope is

Scope is the area of a program where a name exists and can be used. That name can be a variable, a function, a parameter, or anything Python can reference.

Look at this example:

def greet():
    message = "Hello"
    print(message)

greet()
print(message)

The first part works:

Hello

But the last line fails:

NameError: name 'message' is not defined

message exists inside greet(), but not outside it. It is a local variable of that function. From the outside, Python can't see it.

Think of a room with a whiteboard inside. People in the room can read what's on the whiteboard. People outside can't. Shouting louder does not change the building architecture.

Local variables

A variable created inside a function lives in that function's local scope:

def calculate_total(price):
    tax = price * 0.21
    total = price + tax
    return total

result = calculate_total(100)
print(result)

121.0

price, tax, and total are local to calculate_total(). They exist while the function runs. When the function finishes, its scope disappears.

That does not mean the returned value disappears. return total gives the value back to the outside code, and that value is stored in result. But the name total itself belonged to the function.

This matters: returning a value does not export the variable. It exports the value. The local variable stays home, like that friend who says "I'll join later" and absolutely does not join later.

Global variables

A variable defined outside any function lives in the module's global scope:

tax_rate = 0.21

def calculate_total(price):
    return price + (price * tax_rate)

print(calculate_total(100))

121.0

The function can read tax_rate because it does not find that name in its local scope, so it looks outside.

So far, everything is calm. The shelf is standing. We haven't found the extra screw yet.

The problem appears when you try to modify a global variable from inside a function:

counter = 0

def increment():
    counter = counter + 1
    return counter

print(increment())

This fails:

UnboundLocalError: cannot access local variable 'counter' where it is not associated with a value

And here Python looks dramatic, but it has a reason. Because there is an assignment to counter inside the function, Python decides that counter is local to that function. Then, when it evaluates counter + 1, it tries to read the local variable before it has a value.

Yes: the global variable exists. Yes: the name is the same. No: Python does not use it in that case. This is where things get interesting, which in programming usually means "you will stare at the screen in silence for thirty seconds."

The mental rule: Python searches from the inside out

When Python sees a name, it looks for it through a chain of scopes. At this level, keep this idea:

First it checks the local scope of the current function
Then enclosing scopes if there are nested functions
Then the module's global scope
Finally built-in names like print, len, or range

This is usually summarized as LEGB:

Letter	Scope	Meaning
L	Local	Inside the current function
E	Enclosing	Outer functions when functions are nested
G	Global	The current module
B	Built-in	Names Python provides by default

Don't stress about memorizing the acronym like it's a production password. The important part is the direction: Python starts nearby and moves outward.

name = "global"

def show():
    name = "local"
    print(name)

show()
print(name)

local
global

Inside show(), the local name wins. Outside, the global one is used. Each scope has its own whiteboard.

What a namespace is

A namespace is the map that connects names to objects.

More simply: it's like an internal dictionary where Python stores things like this:

{
    "name": "Ada",
    "age": 36,
    "greet": <function greet>
}

You usually don't manipulate that dictionary directly when you're starting out, but it exists. And it helps explain why two scopes can have variables with the same name without overwriting each other.

message = "outside"

def example():
    message = "inside"
    print(message)

example()
print(message)

inside
outside

There isn't one single message variable fighting for its identity. There are two message names in two different namespaces. Same text, different whiteboard.

It's like having two folders called final-project in two different directories. Not elegant, but the system understands it. Your brain may not, but the system does.

The global keyword

If you really want to modify a global variable from inside a function, you can use global:

counter = 0

def increment():
    global counter
    counter = counter + 1
    return counter

print(increment())
print(increment())

1
2

global counter tells Python: "when I say counter inside this function, I mean the global counter."

It works. Using a chair as a ladder also works. The question is whether you should.

global is not evil because it exists, but it is often a sign that your function depends too much on external state. That makes code harder to test, harder to reuse, and easier to break from somewhere else.

Compare this:

counter = 0

def increment():
    global counter
    counter = counter + 1
    return counter

With this:

def increment(counter):
    return counter + 1

counter = 0
counter = increment(counter)
counter = increment(counter)
print(counter)

The second version is more explicit: the function receives a value and returns another one. It does not touch hidden things in another room. If something breaks tomorrow, you have fewer dark hallways to inspect.

Nested functions

Python lets you define functions inside other functions:

def create_greeting(name):
    prefix = "Hello"

    def build_message():
        return f"{prefix}, {name}"

    return build_message()

print(create_greeting("Ada"))

Hello, Ada

build_message() can read prefix and name, even though they are not defined inside it. They are in the scope of create_greeting(), which is its outer scope.

That is the enclosing scope in LEGB: an inner function can see names from the function that contains it.

This appears in closures, decorators, and more advanced code. For now, keep the idea: a nested function can look outward, but not randomly. Python follows a specific route; it does not open drawers at random like you do when you're looking for your keys five minutes before leaving.

The nonlocal keyword

Now for the delicate part. An inner function can read variables from the outer function, but if it wants to modify them it needs nonlocal:

def create_counter():
    counter = 0

    def increment():
        nonlocal counter
        counter = counter + 1
        return counter

    return increment

counter = create_counter()

print(counter())
print(counter())
print(counter())

1
2
3

nonlocal counter tells Python: "this counter is not local to increment(), but it is not global either; it lives in an outer function."

Without nonlocal, you would get the same UnboundLocalError problem as before: Python would see an assignment to counter inside increment() and assume it is a local variable.

nonlocal is used less often than normal variables, and that's fine. You don't need to put nested functions everywhere to feel professional. Sometimes clear code is just a normal function with clear parameters. Revolutionary, I know.

When to avoid global and nonlocal

The practical rule:

Use local variables whenever you can.
Pass data as parameters.
Return results with return.
Use global rarely and with a clear reason.
Use nonlocal when you are creating an inner function that needs to remember state.

This pattern is usually better:

def apply_discount(price, discount):
    return price - (price * discount)

final_price = apply_discount(100, 0.15)
print(final_price)

Than this:

discount = 0.15
final_price = 0

def apply_discount(price):
    global final_price
    final_price = price - (price * discount)

apply_discount(100)
print(final_price)

The second version works, but it leaves side effects behind. The function doesn't just calculate: it also modifies a global variable. It's the kind of code that looks innocent until it grows, multiplies, and one day someone asks why final_price is changing without being invited to the party.

Common scope mistakes

Thinking a local variable exists outside

def create_user():
    name = "Ada"

create_user()
print(name)

NameError: name 'name' is not defined

Fix: return the value.

def create_user():
    name = "Ada"
    return name

name = create_user()
print(name)

Modifying a global without global

total = 0

def add(price):
    total = total + price
    return total

This fails because Python treats total as local inside add().

Better solution at this level: avoid global state.

def add(total, price):
    return total + price

total = 0
total = add(total, 10)
total = add(total, 20)
print(total)

Shadowing a built-in by accident

You can create a variable called list, sum, or str. Python lets you. Python also lets you make your life harder with a smile.

list = [1, 2, 3]

numbers = list("123")

That fails because list no longer points to the built-in list; it points to your variable.

Avoid it. Use names like numbers, items, or users. Your future self does not need more mystery in the workday.

Key concepts from this lesson

Scope defines where a name can be seen from.
Variables created inside a function are local to that function.
Variables defined outside functions live in the module's global scope.
Python searches names from the inside out: local, enclosing, global, and built-in.
A namespace is the map that connects names to objects.
global lets you modify global variables from a function, but it should be rare.
nonlocal lets you modify variables from an outer function when working with nested functions.
Passing data through parameters and returning results usually creates clearer code than modifying external state.

💡 Challenge: Fix this code without using global. The function should receive the current value of total, add price, and return the new total.

total = 0

def add_product(price):
    total = total + price
    return total

total = add_product(15)
total = add_product(30)
print(total)

Next up: lambda functions and higher-order functions — how to pass functions around as values, when a lambda helps, and when it just turns your code into a ransom note written with symbols.

Never stop coding!

Why We Need Databases

Javi Palacios — Sat, 24 Oct 2026 22:41:39 +0000

You start a small project. Very small. So small that saving the data in a file feels perfectly reasonable.

A users.json here. An orders.csv there. Maybe a shared spreadsheet because “business can see it too.” Everything is calm. Everything is under control. Until someone asks: “can we see last month's orders grouped by customer, excluding cancelled ones, sorted by revenue?”

And suddenly your humble file becomes a crime scene investigation: manual filters, copies named final_v2_good_really_this_time.xlsx, formulas nobody wants to touch, and the very specific feeling a former coworker once summarized perfectly: “it works because God is good.”

That's where databases begin.

Not because they're more elegant. Not because they sound more professional. Because at some point, storing data is not enough. You need to query it, relate it, protect it, modify it safely, and let multiple people or processes work with it at the same time without turning your application into a social experiment.

The problem: storing data is not managing data

Storing data is easy.

[
  {
    "id": 1,
    "name": "Ada",
    "email": "ada@example.com"
  }
]

This works. For learning, for a small script, for a demo, for that personal project that starts on a Sunday afternoon and ends up living in production for three years because “we'll clean it up later.” Spoiler: they did not clean it up.

The problem doesn't show up when you have three users. It shows up when you have thousands. Or when two processes write at the same time. Or when you need to know which orders belong to which user. Or when someone deletes a line by mistake. Or when a query that used to be instant now takes long enough for you to reconsider your career choices.

A flat file is not designed to answer complex questions. It's designed to store bytes. That's important, but it's only the first step.

The difference between “I have data” and “I have a database” is the difference between having all the screws for a shelf in a plastic bag and having the shelf assembled, stable, and without that one leftover metal piece staring at you from the table like it knows something you don't.

What breaks when we use files for everything

Files are not bad. In fact, many databases store information in files internally. The difference is that a database adds a layer of organization, rules, queries, and guarantees on top.

When you use files directly, sooner or later these problems appear:

1. Querying data becomes painful

With a small file, finding something is trivial. Open the file, read line by line, find what you need.

Now imagine a CSV with one million orders:

order_id,user_id,total,status,created_at
1,42,99.90,paid,2026-07-01
2,57,19.50,cancelled,2026-07-02
3,42,149.00,paid,2026-07-03

Now you want to answer:

How much has each user spent?
What are the top 10 best-selling products?
Which orders are paid but not shipped?
How much did revenue grow compared to last month?

You can do it with scripts, yes. You can also assemble a shelf with a spoon if you have enough patience. Possible is not the same as reasonable.

SQL exists to ask questions of your data declaratively:

SELECT user_id, SUM(total) AS total_spent
FROM orders
WHERE status = 'paid'
GROUP BY user_id
ORDER BY total_spent DESC;

Don't worry about understanding every word yet. The important idea is this: instead of writing a program that walks through the file step by step, you tell the database what result you want. The engine decides how to get it.

That difference changes everything.

2. Relationships become manual

Real data almost never lives alone.

A user has orders. An order has line items. A line item points to a product. A product belongs to categories. A review belongs to a user and a book. Everything starts connecting to everything else, because the real world has the rude habit of not organizing itself into one pretty list.

With files, you manage those relationships yourself:

{
  "order_id": 1,
  "user_id": 42,
  "product_ids": [7, 12, 19]
}

Does user 42 exist? Do products 7, 12, and 19 exist? What happens if product 12 is deleted? Who prevents user_id from pointing to someone who no longer exists?

Exactly: you. Your code. Your discipline. Your teammate on Friday at 6:03 PM. Good luck.

A relational database lets you express those rules as part of the model itself:

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  user_id INTEGER REFERENCES users(id)
);

Again, you don't need to master the syntax now. Keep the concept: the database can know that orders.user_id must point to a real user. That's not just storage. That's integrity.

And when data matters, integrity is not a fancy extra. It's the seatbelt.

3. Multiple writers at once is a dangerous party

Imagine two processes updating the same file at the same time.

One reads the file. The other reads it too. One writes changes. The other writes later with an older version. Result: lost data. The kind of bug that doesn't scream, doesn't explode, and doesn't leave a stack trace. It just eats information and walks away like nothing happened.

That's the worst kind of bug: the one that doesn't look like a bug until you do the math.

Databases are designed to handle concurrency: multiple clients reading and writing at the same time under clear rules. That's why concepts like transactions, locks, isolation levels, and ACID exist. Today we'll only name them; later we'll open them carefully, because there is enough material there to make a spreadsheet cry.

The basic idea is simple: a database doesn't just store data. It coordinates changes.

4. Security and guarantees disappear quickly

With files, you usually have operating system permissions: who can read or write the file. That's useful, but it doesn't go far enough.

In a real application, you might want rules like:

The backend can insert orders, but not delete users.
An analyst can read sales, but not emails.
A user can only modify their own reviews.
Nobody should be able to create an order with a negative total.

A database lets you model permissions, constraints, roles, validations, and access rules in a much finer-grained way. It doesn't replace application security, but it acts as your last line of defense.

And yes: you want that last line. Because trusting all application code to be perfect forever is a beautiful strategy, just like trusting that “this time I will definitely remember to make a backup before touching production.”

So what is a database?

A database is an organized system for storing, querying, modifying, and protecting persistent data.

The key word is not “storing.” A file already does that. The key is the full set:

Persistence: data survives when the application shuts down.
Structure: data follows an understandable model.
Querying: you can ask complex questions without writing the whole algorithm by hand.
Relationships: you can connect entities without relying on human memory and optimistic comments.
Integrity: you can define rules to avoid invalid states.
Concurrency: multiple processes can work at the same time without stepping on each other like they're editing the same Word document in 2007.
Security: you can control who accesses what.
Performance: you can search through millions of rows without reading everything every time.

Put all of that together and you no longer have “a place to put things.” You have a central piece of your system.

And here's an important point: a database does not magically fix bad design. If you model your data badly, the database will obey. With admirable professionalism and terrible consequences.

Types of databases from a distance

This course focuses on SQL and PostgreSQL, but it's worth knowing that not all databases use the same model.

Type	How it thinks about data	Examples	Where it appears
Relational	Tables, rows, columns, and relationships	PostgreSQL, MySQL, SQL Server	Business applications, structured data, strong integrity
Document	JSON/BSON documents	MongoDB, CouchDB	Flexible data, catalogs, semi-structured content
Key-value	Key → value	Redis, Valkey	Cache, sessions, counters, simple queues
Graph	Nodes and relationships	Neo4j	Complex relationships: social networks, recommendations, fraud
Time-series	Data indexed by time	TimescaleDB, InfluxDB	Metrics, sensors, events, observability

Don't stress about memorizing this now. The goal is to give you a map, not send you out explaining distributed databases on a napkin like you're in a backend interview at 9 AM.

The important idea: each type of database exists to solve different problems. But if you're learning from zero, starting with the relational model is the best investment. Many ideas about data, performance, querying, and integrity are easier to understand from there.

Why PostgreSQL

We'll use PostgreSQL 18 throughout the course.

Not because it's the only option. MySQL, MariaDB, SQL Server, Oracle, and SQLite exist and have real use cases. But PostgreSQL is an excellent database to learn with and to work with seriously because it combines several things that are hard to find together:

It's open source and widely used in the industry.
It implements SQL in a powerful and mostly standard way.
It has advanced types: JSONB, arrays, ranges, UUIDs, full-text search.
It supports constraints, transactions, views, materialized views, roles, extensions, and serious tooling.
It scales from small projects to large systems.
It lets you learn general SQL while also using modern features that appear in production.

PostgreSQL is a good school because it doesn't treat you like you only want to store four rows. It gives you grown-up database tools from the beginning. Some of them won't show up until much later, but it's good to know they're there, patiently waiting for you to stop writing SELECT * out of habit.

What learning SQL really means

Learning SQL is not memorizing commands.

Memorizing commands creates that dangerous feeling of “I know SQL” until a query appears with LEFT JOIN, GROUP BY, HAVING, a subquery, and a NULL staring from the corner. Then the castle starts wobbling.

Really learning SQL means understanding questions like these:

What shape does my data have?
What relationship exists between these tables?
Which rows am I filtering before grouping?
Why is this query reading ten million rows?
What index does this access pattern need?
What happens if two users modify the same thing at the same time?
What is my ORM actually generating?

That's why this course starts here, before installing anything. Because if you understand the problem, the tool stops feeling like magic. And when the tool stops feeling like magic, you start using it with judgment.

What you take from this lesson

If you understood this, you now have the mental foundation for the course:

A file can store data, but it doesn't manage querying, relationships, concurrency, and integrity well.
A database adds structure, rules, guarantees, and query capabilities.
SQL lets you ask for the result you want, not manually describe how to walk through the data step by step.
Relational databases remain fundamental because they model structured data and relationships very well.
PostgreSQL will be our main tool because it's modern, open, powerful, and widely used in production.

In the next lesson we'll set up the environment: we'll run PostgreSQL 18 with Docker, connect with psql and pgAdmin, and leave a database ready for real data. If Docker still looks at you funny, Mastering Docker from Scratch is the perfect warm-up; we'll use it here without turning this lesson into another container-moving day.

Never stop coding!

Docker Compose networking: networks, services, and isolation

Javi Palacios — Sat, 24 Oct 2026 07:46:27 +0000

There is a very Docker Compose moment: Postgres is running, the API is running, the logs look reasonable, and the API still says it can't connect to localhost:5432.

You check docker compose ps. Postgres is Up. You check the docker-compose.yml. The port is there. You stare at the screen with that specific mix of suspicion and tiredness that only appears when a tool is technically telling the truth in the least helpful way possible.

Is Postgres down? No. Is the port wrong? Maybe, but probably not. Is localhost a trap with good branding? Exactly.

In Docker Compose, each container lives in its own little network world. Once you understand that, the rest stops feeling like dark magic with YAML.

Compose's default network

When you run docker compose up, Compose automatically creates a network for the project. If your directory is called myapp, that network is usually named something like myapp_default.

All services in the docker-compose.yml join that network by default.

services:
  api:
    image: myapp/api

  db:
    image: postgres:16-alpine

Even though you didn't write networks: anywhere, Compose did some work for you:

docker compose up -d
docker network ls

You'll see a network like this:

NETWORK ID     NAME            DRIVER    SCOPE
abc123def456   myapp_default   bridge    local

Inside that network, services can find each other by service name. The API can connect to Postgres using db as the hostname.

postgresql://myapp:secret@db:5432/myapp

Don't use the container IP. Container IPs can change when services are recreated. Using container IPs in Compose is like writing down where you parked three weeks ago on a napkin: technically useful for a few minutes.

Use service names.

`localhost` inside a container is not your machine

This is the main trap.

From your machine, localhost means your machine.

From inside a container, localhost means that container.

services:
  api:
    image: myapp/api
    environment:
      DATABASE_URL: postgresql://myapp:secret@localhost:5432/myapp

  db:
    image: postgres:16-alpine

That is wrong for container-to-container communication. The API will look for Postgres inside the API container itself. Spoiler: it is not there. If it were, you'd have another problem, probably with a suspicious architecture smell.

The correct version uses the service name:

services:
  api:
    image: myapp/api
    environment:
      DATABASE_URL: postgresql://myapp:secret@db:5432/myapp

  db:
    image: postgres:16-alpine

Mental model:

Connecting from	Correct host
Your browser to the API	`localhost` if the port is published
API to Postgres	`db`
API to Redis	`redis`
One container to another	The service name

Don't stress if this feels counterintuitive at first. localhost has spent years looking innocent while ruining entire afternoons with a smile.

`ports` is not how containers talk to each other

Another classic confusion: thinking you need to publish a port so another container can connect to it.

You don't.

services:
  api:
    build: ./api
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgresql://myapp:secret@db:5432/myapp

  db:
    image: postgres:16-alpine

The ports: "3000:3000" line publishes the API port to your machine. It lets you open http://localhost:3000 from your browser.

But the API does not need Postgres to have ports: "5432:5432" to connect to db:5432. Both services are already on the internal Compose network.

This matters for security. If you publish Postgres like this:

services:
  db:
    image: postgres:16-alpine
    ports:
      - "5432:5432"

You're exposing the database to the host. In development that can be useful if you want to connect with TablePlus, DBeaver, local psql, or another external tool. But don't do it “just in case”. “Just in case” in infrastructure is a polite way of saying “I'll leave this door open and see what happens”.

If only the API needs to talk to the database, don't publish the port.

Custom networks: separate rooms

The default network is fine for small projects. All services can see each other and life goes on.

But in a more realistic application, you might have:

web: frontend or reverse proxy.
api: backend.
db: database.
redis: cache.

There is no reason for web to connect directly to db. The frontend talks to the API. The API talks to the database. The database should not be standing in the lobby waving at the entire building.

You can model that with custom networks:

services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"
    networks:
      - frontend

  api:
    image: myapp/api
    networks:
      - frontend
      - backend

  db:
    image: postgres:16-alpine
    networks:
      - backend

networks:
  frontend:
  backend:

Now the rules are clear:

Service	Networks	Can talk to
`web`	`frontend`	`api`
`api`	`frontend`, `backend`	`web`, `db`
`db`	`backend`	`api`

web and db do not share a network, so they cannot resolve each other by name or connect directly. This does not replace authentication, firewalls, permissions, or common sense, but it reduces surface area. And reducing surface area is one of those boring things that prevents interesting incidents. Interesting incidents are overrated.

`expose` vs `ports`

Compose also has expose:

services:
  api:
    image: myapp/api
    expose:
      - "3000"

expose documents that a service listens on a port for other services on the network, but it does not publish that port to your machine.

In practice, services on the same network can connect to a container port even if you don't write expose. That's why many teams don't use it. It can be useful as documentation inside the docker-compose.yml, but don't confuse it with security.

The important difference:

Field	Publishes to host	Main use
`ports`	Yes	Access from your machine or outside
`expose`	No	Document internal ports

If you want to open something from the browser, use ports. If only containers talk to each other, you usually don't need anything.

External networks

Sometimes you want several Compose projects to share a network. For example, a common reverse proxy (traefik, nginx, caddy) routing multiple local apps or services on the same server.

First create the network manually:

docker network create shared-proxy

Then declare it as external:

services:
  app:
    image: myapp/api
    networks:
      - shared-proxy

networks:
  shared-proxy:
    external: true

external: true means: “Compose, don't create this network; it already exists, use it.”

If the network doesn't exist, Compose fails. And that's good. Better to fail than silently create a new network and leave you wondering for half an hour why the proxy can't see your app. Docker already has enough material to confuse you without extra help.

Network aliases

By default, each service resolves by its name: api, db, redis.

Sometimes you want additional names. That's what aliases are for.

services:
  api:
    image: myapp/api
    networks:
      backend:
        aliases:
          - api-service
          - internal-api

  worker:
    image: myapp/worker
    networks:
      - backend

networks:
  backend:

From worker, these hostnames point to the api service:

api
api-service
internal-api

Use this carefully. An alias can help when a legacy application expects a specific hostname. But if you start adding three names per service “for convenience”, you'll end up with a tiny home-made DNS system inside YAML. Like having five nicknames for the same person in a group chat: funny until someone new tries to understand the conversation.

Complete example

A reasonable stack with reverse proxy, API, database, and cache:

services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"
    networks:
      - frontend

  api:
    build: ./api
    environment:
      DATABASE_URL: postgresql://myapp:secret@db:5432/myapp
      REDIS_URL: redis://redis:6379
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    networks:
      - frontend
      - backend

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: myapp
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: myapp
    volumes:
      - db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U myapp -d myapp"]
      interval: 5s
      timeout: 3s
      retries: 5
    networks:
      - backend

  redis:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 3
    networks:
      - backend

volumes:
  db-data:

networks:
  frontend:
  backend:

Notice three details:

Only web publishes a port to the host.
api talks to db and redis using service names.
db and redis are not on frontend, so web cannot talk to them directly.

This does not turn your app into Fort Knox. But you're no longer putting every service in the same room with a sticky note that says “be nice”.

Practical challenge

Take the docker-compose.yml from the previous tutorial and split it into two networks: frontend and backend. The API should be on both. Postgres and Redis should only be on backend. If you have a web or proxy service, put it only on frontend and publish only its port.

Then verify that your internal URLs use service names (db, redis, api) and not localhost. If you find a localhost inside an environment variable used between containers, don't look at it fondly: change it.

You now have the right mental map: Compose creates a default network, services discover each other by name, ports is for reaching your machine, and custom networks let you isolate what should not talk directly. In the next tutorial we'll close the Compose module with best practices: environment-specific files, secrets, resource limits, logging, and the small details that separate a useful docker-compose.yml from one that looks written during a power outage.

Never stop coding!

Docker Compose volumes and data persistence

Javi Palacios — Fri, 23 Oct 2026 05:38:35 +0000

Docker has a very effective teaching method: you start Postgres, insert data, stop the container, start it again, and everything is still there. Nice. You gain confidence. You clean things up. You run the wrong command. You open the app again and the database is emptier than a sprint retrospective where everyone says “all good”.

Where did the data live? Inside the container? Somewhere in Docker? In a secret folder guarded by a small daemon with trust issues?

Take a breath. Docker doesn't hate your data. Containers are disposable by design. If you want persistence, you need to declare it explicitly. That's what volumes are for.

The problem: containers are not hard drives

A container has its own filesystem. You can write files, modify data, create directories, and feel like everything is under control. The catch is that this writable layer belongs to the container.

Remove the container, and those changes go with it.

docker run --name temp-postgres -e POSTGRES_PASSWORD=secret -d postgres:16-alpine
docker rm -f temp-postgres

The container is gone. Its writable changes are gone too.

That's not a bug. That's the model. Containers should be safe to destroy and recreate. The image contains the application; the data lives outside.

Think of a container as a moving van. Useful, necessary, maybe smelling vaguely of cheap air freshener. But you don't store your lease, family photos, and the only copy of your production database inside the van. Those go in labeled boxes.

In Docker, those boxes are volumes.

The three volume types you'll actually use

In Compose, a service can mount several kinds of storage:

services:
  app:
    image: myapp
    volumes:
      - app-data:/app/data
      - ./src:/app/src
      - /app/temp
      - ./config:/app/config:ro

volumes:
  app-data:

Those four lines are not the same thing. Treating them as interchangeable is how you end up staring at docker volume ls like you're reading ancient ruins.

Named volumes

services:
  app:
    image: myapp
    volumes:
      - app-data:/app/data

volumes:
  app-data:

A named volume is storage managed by Docker. You give it a name (app-data), and Docker decides where it physically lives on the host.

This is the default choice for data you want to keep: databases, uploaded files, persistent caches, internal application state.

The upside: it works consistently across Linux, macOS, and Windows. You don't depend on a specific host path.

The downside: the files are not sitting neatly inside your project directory. Docker stores them internally. If you're like me when I started, that creates a very specific anxiety: “I know my data exists, but I don't know where it lives.” Correct. Welcome to the club.

You can inspect volumes with:

docker volume ls
docker volume inspect myproject_app-data

Compose usually prefixes volume names with the project name. If your directory is called myproject and your volume is app-data, the real volume might be myproject_app-data. Docker isn't trying to be mysterious. It just has a gift for making simple things look slightly like infrastructure archaeology.

Bind mounts

services:
  app:
    image: myapp
    volumes:
      - ./src:/app/src

A bind mount mounts a host directory into the container. Here, ./src on your machine appears as /app/src inside the container.

This is excellent for development: edit code in your editor, the container sees the change immediately, the dev server reloads, and for one beautiful second software feels like it was designed by someone on your side.

services:
  api:
    build: ./api
    volumes:
      - ./api/src:/app/src
    command: npm run dev

But bind mounts depend on the host filesystem. If ./api/src exists on your laptop but not on the server, deployment fails. If file synchronization is slow on macOS, you'll feel it. If someone changes the path, the container does not develop intuition.

The practical rule:

Development: bind mounts for source code and local configuration.
Persistent data: named volumes.
Production: avoid mounting source code from the host unless you have a VERY clear reason.

Not “interesting”. Clear.

Anonymous volumes

services:
  app:
    image: myapp
    volumes:
      - /app/temp

An anonymous volume has no explicit name. Docker creates one automatically for /app/temp.

This can be useful for internal container paths, but for important data it's a trap with good lighting. The volume exists, yes, but you didn't choose a stable name for it. Weeks later, you'll see a list of long IDs and have to guess which one contains what.

It's like having a drawer full of unlabelled cables. One of them is definitely important. Good luck finding the right charger before USB invents another connector.

For data you want to keep and understand, use named volumes.

Read-only volumes

services:
  app:
    image: myapp
    volumes:
      - ./config:/app/config:ro

The :ro suffix mounts the volume as read-only. The container can read /app/config, but it can't write there.

Use this for configuration, certificates, static files, or anything the container should not modify. If an application only needs to read a file, don't give it write access. Least privilege applies locally too. Your laptop is not a moral exception.

Database persistence

The most common Compose case is a database.

services:
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: myapp
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: myapp
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

Postgres stores its data in /var/lib/postgresql/data. By mounting db-data there, the data lives in the volume, not in the container's writable layer.

Now you can remove and recreate the container without losing the database:

docker compose down
docker compose up -d

The container changes. The volume remains.

But pay attention: down and down -v are not polite cousins. docker compose down removes containers and networks, but keeps named volumes. docker compose down -v also removes the volumes declared by Compose.

docker compose down     # Keeps named volumes
docker compose down -v  # Removes named volumes too

That -v is tiny, quiet, and destructive. Like a red button without a safety cover. Use it when you deliberately want to delete data: resetting a local database, cleaning a test environment, starting from scratch.

Don't use it as “general cleanup” if the data matters.

For other databases, the idea is the same: mount the volume where the image stores its data.

services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - postgres-data:/var/lib/postgresql/data

  mongo:
    image: mongo:7
    volumes:
      - mongo-data:/data/db

  mysql:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: secret
    volumes:
      - mysql-data:/var/lib/mysql

volumes:
  postgres-data:
  mongo-data:
  mysql-data:

The path changes depending on the image. The pattern doesn't.

Initialization scripts

Many official database images can run initialization scripts the first time the database is created.

With Postgres, anything mounted into /docker-entrypoint-initdb.d runs when the data directory is initialized:

services:
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: myapp
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: myapp
    volumes:
      - db-data:/var/lib/postgresql/data
      - ./init-scripts:/docker-entrypoint-initdb.d:ro

volumes:
  db-data:

For example:

-- init-scripts/01-create-tables.sql
CREATE TABLE IF NOT EXISTS notes (
  id SERIAL PRIMARY KEY,
  title TEXT NOT NULL,
  created_at TIMESTAMP NOT NULL DEFAULT NOW()
);

Important detail: these scripts run when the data directory is empty. If the volume already exists and Postgres has already initialized, they do not run again.

Feeling the “but I changed the SQL and nothing happened” moment? Good. The volume already had data. Docker is not going to wipe your database because you edited a file. That would be helpful in a deeply criminal way.

To test initialization changes locally:

docker compose down -v
docker compose up -d

That deletes the volume and forces a fresh initialization. Deliberate, visible, consequences included.

Development vs production

Volumes also separate two very different needs: fast development and stable runtime behavior.

In development, you want hot reload:

# docker-compose.dev.yml
services:
  api:
    build:
      context: ./api
      target: development
    volumes:
      - ./api/src:/app/src
      - ./api/package.json:/app/package.json:ro
      - /app/node_modules
    command: npm run dev

The - /app/node_modules line creates an anonymous volume so the container's node_modules directory doesn't get overwritten by the host. This trick exists because JavaScript decided dependencies should have more emotional mass than the actual project. We're not fixing that today.

In production, you don't mount source code from your machine. You build an image and only mount the data that must persist:

# docker-compose.prod.yml
services:
  api:
    build:
      context: ./api
      target: production
    volumes:
      - api-data:/app/data
    command: npm start

volumes:
  api-data:

Then combine files depending on the environment:

# Development
docker compose -f docker-compose.yml -f docker-compose.dev.yml up

# Production
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

The base docker-compose.yml describes the shared stack, and the environment-specific files override what changes. Just like with Git, you commit what describes the project and keep machine-specific details out.

Backups: persistence is not a backup

A persistent volume is not a backup. Say it with me: persistence is not backup.

A named volume survives container recreation. It does not protect you from docker compose down -v, manual deletion, data corruption, an overconfident script, or you on a Friday afternoon thinking “this definitely won't break anything”.

For databases, the best backup is usually the database's own tool. For Postgres:

docker compose exec db pg_dump -U myapp myapp > backup.sql

That runs pg_dump inside the db container and writes the output to your machine. Clear, portable, and database-aware.

You can also make a low-level copy of a volume using a temporary container:

docker run --rm \
  -v myproject_db-data:/data:ro \
  -v "$(pwd)":/backup \
  alpine \
  tar czf /backup/db-data-backup.tar.gz -C /data .

What's happening here:

myproject_db-data:/data:ro mounts the volume read-only.
"$(pwd)":/backup mounts your current directory as the backup destination.
tar czf archives the volume contents.
--rm removes the temporary container when it exits.

If you've spent years fighting shell quotes, you noticed "$(pwd)". If not, don't worry: Bash will get its own course later, because this topic deserves more than “copy this and trust me”. That's not decoration. It keeps the command from breaking when the path contains spaces. The shell is always waiting for a chance to remind you that quotes are not optional.

To restore into an empty volume:

docker volume create myproject_db-data

docker run --rm \
  -v myproject_db-data:/data \
  -v "$(pwd)":/backup:ro \
  alpine \
  tar xzf /backup/db-data-backup.tar.gz -C /data

For databases that are actively running, don't blindly copy files while the engine is writing. It might help in development. In production, use pg_dump, consistent snapshots, or the official tooling for your database. Faith can move mountains, but it does not guarantee transactional integrity.

Cleanup without destroying what matters

These Compose and Docker commands have very different effects:

docker compose stop
docker compose down
docker compose down -v
docker volume ls
docker volume rm myproject_db-data
docker volume prune

Human translation:

Command	What it does
`docker compose stop`	Stops containers, removes nothing
`docker compose down`	Removes containers and networks, keeps named volumes
`docker compose down -v`	Removes containers, networks, and project volumes
`docker volume rm <name>`	Removes one specific volume
`docker volume prune`	Removes volumes not used by any container

docker volume prune asks for confirmation, but it does not know which volume was “emotionally important”. It only knows whether a container is currently using it. If you have an old volume with data you care about and no container is attached to it right now, it can be removed.

Before deleting, inspect:

docker volume inspect myproject_db-data

And if you're unsure, back it up first. Boring advice. So is wearing a seatbelt, until the day it stops being boring.

Practical challenge

Create a docker-compose.yml with Postgres and a fake API or any lightweight image you know. Add a named volume for Postgres, start the stack, create some data, run docker compose down, then start it again and confirm the data is still there.

After that, back up the volume using the temporary alpine container. You don't need an enterprise backup system yet; just understand the flow: volume → .tar.gz archive → restore into an empty volume.

You can now treat Docker Compose data with the respect it deserves: outside the container, with clear names, with clean separation between development and production, and with backups that don't depend on crossed fingers. In the next tutorial we'll go into Docker Compose networking: default networks, custom networks, service isolation, and why your database should not be cheerfully waving at the entire stack.

Never stop coding!

Setting up your DevOps work environment: Linux, terminal, and essential tools

Javi Palacios — Thu, 22 Oct 2026 06:29:04 +0000

The first real collision with DevOps usually isn't Kubernetes. Or Terraform. Or that YAML file that looks like it was written by someone with strong feelings against indentation.

The first collision is usually less heroic: you try to prepare your environment, open a terminal, see three different ways to “use Linux,” someone mentions SSH keys, someone else says “just use WSL,” another person says “spin up a cloud instance,” and suddenly installing a few tools feels like choosing a mortgage.

Should you use local Linux? A VM? WSL? AWS? GCP? Will your laptop explode? No. Unless you run too many browser tabs while VirtualBox is trying to breathe. But conceptually, no.

This lesson sets up a serious working environment for the course: real enough to learn DevOps properly, simple enough that you don't spend three days configuring the workshop before touching a single tool.

What a DevOps learning environment actually needs

A DevOps environment does not need to look like production from minute one. That would be like learning to drive by entering a six-lane roundabout with a truck behind you. Educational, sure. Also unnecessarily traumatic.

What it does need is a place where you can practice four things:

using a Linux terminal comfortably;
installing command-line tools;
running services, scripts, and processes;
connecting to remote machines through SSH.

That last point matters. DevOps lives a lot on servers. Even when we later work with containers, Kubernetes, or cloud providers, the base is still the same: a shell, permissions, processes, logs, networking, and files.

If you don't have a strong terminal foundation yet, that's fine. This course starts exactly there. And if Git still feels like a black box full of branches, Mastering Git from Scratch will save you several uncomfortable conversations with yourself.

First the judgment; then the options.

The recommended option: a local Ubuntu VM

To follow this course consistently, the recommended option is a local VM running Ubuntu 24.04 LTS.

Not because Ubuntu is magically better, but because it gives us a shared baseline: real Linux, systemd, systemctl, journalctl, networking, permissions, packages, and a machine you can break without touching your main system. Think of it as a small practice server at home. If you destroy it, delete it and create another one. Much better than learning electricity by sticking a screwdriver into the main panel.

We'll use Multipass, a Canonical tool for creating Ubuntu VMs from the CLI. The picture looks like this:

your machine ── multipass ──> Ubuntu VM devops-lab

Before continuing: Multipass is recommended because it lets us create an Ubuntu VM in a simple and reproducible way. But it is not a religious requirement.

If you work on a corporate machine, have security restrictions, already use a virtualization tool approved by your company, or your computer needs a special setup, use whatever method fits your environment: VirtualBox, VMware, UTM, Hyper-V, Parallels, libvirt, or anything else you are allowed to use.

The tool is not the goal. The goal is to end up with an Ubuntu 24.04 LTS VM —or an equivalent Linux distribution— that you can access, where you can install packages, run commands, manage services, and practice without touching your main system.

DevOps is about understanding systems, not marrying the first installer mentioned in a tutorial.

Installing Multipass

Install Multipass according to your system:

# macOS and Linux (Homebrew)
brew install --cask multipass

# Ubuntu / Debian
sudo snap install multipass

# Arch Linux (AUR)
paru -S canonical-multipass

Arch users already know the drill: if multipassd won't start, install dnsmasq and add ReadWritePaths=/usr/local/etc/multipassd to the service. If QEMU can't find OVMF.fd, symlink it from edk2-ovmf to /usr/share/qemu/.

On Windows, install it from PowerShell:

winget install -e --id Canonical.Multipass

If virtualization is disabled in your BIOS/UEFI, your company policies are strict, or Hyper-V is doing Hyper-V things, Multipass may complain. Don't stress: DevOps does not hate you personally. It's virtualization. Sometimes it feels like opening a door; sometimes it feels like getting approval from five departments to move a chair.

Once installed, check that it responds:

multipass version

Now we can create the VM.

Creating the course VM

The course VM will be called devops-lab:

multipass launch 24.04 --name devops-lab --cpus 2 --memory 4G --disk 30G

That command creates an Ubuntu 24.04 machine with:

2 CPUs;
4 GB of RAM;
30 GB of disk;
the name devops-lab.

If your computer is low on resources, you can reduce it to --memory 2G, but 4 GB will be more comfortable for what we'll do later. A tiny VM works, sure, like a chair with one loose leg works. The question is how much trust you want to place in it.

To list your VMs:

multipass list

To enter the VM:

multipass shell devops-lab

Multipass already knows how to enter the machine. You don't need to configure SSH manually for everyday course work. It's a convenient door managed by the tool.

To exit:

exit

To stop the VM:

multipass stop devops-lab

To start it again:

multipass start devops-lab

And if you break everything with educational enthusiasm:

multipass delete devops-lab
multipass purge

Breaking a lab VM is not a tragedy. It's almost part of the process. Like burning the first pancake: you don't serve it, but it teaches you how hot the pan is.

Accepted alternatives

Multipass will be the baseline for examples, but it is not the only valid way to follow the course.

Option	When to use it	Main trade-off
Multipass	Recommended course baseline	Depends on local virtualization
WSL2	You use Windows and Multipass does not fit your setup	Very practical, with a few Windows moments
Local Linux	You already use Linux and know what you're touching	You can break your real system
Cloud	You want real public infrastructure	More realistic, but billing enters chat

WSL2 on Windows

If you work on Windows and Multipass gives you trouble, WSL2 is a reasonable alternative. Microsoft documents the basic installation as a single command: wsl --install, which installs WSL and, by default, Ubuntu.

From PowerShell as administrator:

wsl --install

Restart if Windows asks for it. Windows asking for a restart: the ritual that keeps the ecosystem humble.

WSL2 works for many parts of the course, but it is not exactly a traditional VM. Filesystem, networking, and services can behave differently. Great to start; not always identical to a server.

Local Linux

If you already use Linux, perfect. You're home. You probably also have an opinion about your distro, terminal, and package manager. Arch users already know the drill.

You can follow the course on your real system, but at the beginning it helps to separate learning from your daily machine. You don't learn carpentry by removing your front door first.

Cloud later

Cloud will show up later when we actually need it: IAM, security groups, cloud networking, Terraform against real infrastructure, managed services, and other pieces with consequences.

Can free tier work? Yes, if you respect limits and conditions. Am I going to promise that the whole course will be free on cloud? No. That would be like saying “don't worry, this YAML will definitely work the first time.” Technically possible; emotionally irresponsible.

Entering with Multipass and practicing SSH

For course work, you'll usually enter like this:

multipass shell devops-lab

You can also run commands without opening a full shell:

multipass exec devops-lab -- lsb_release -a

But SSH is still fundamental in DevOps. On real servers, cloud instances, and many lab environments, SSH will be your front door.

So let's practice it against our local VM. First generate a key if you don't already have one:

ssh-keygen -t ed25519 -C "devops-course"

Accept the default path (~/.ssh/id_ed25519) unless you have a reason to change it. The public part (id_ed25519.pub) goes to the remote machine. The private part (id_ed25519) is not shared. Ever. Think house keys: you can give the lock a copy of your public identity, but you don't post your private key in a team chat. Obvious, until it happens. And it happens.

Copy the public key into the VM:

multipass transfer ~/.ssh/id_ed25519.pub devops-lab:/home/ubuntu/id_ed25519.pub

Enter the VM with Multipass:

multipass shell devops-lab

Inside the VM, add the key to authorized_keys:

mkdir -p ~/.ssh
cat ~/id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
rm ~/id_ed25519.pub
exit

Now check the VM IP:

multipass info devops-lab

Look for the IPv4 line and connect through SSH:

ssh ubuntu@<vm-ip>

If you need a specific key:

ssh -i ~/.ssh/id_ed25519 ubuntu@<vm-ip>

If this does not work on your system, that's fine: some drivers, firewalls, or networking setups may block direct access by IP. We'll use multipass shell to follow the course; SSH is extra practice here, and we'll revisit it with cloud later.

The important idea is this: Multipass gives you the convenient door; SSH is the door you'll use on real servers. You should know both.

Now that you have a stable way into a Linux machine, you need the base tools.

Essential tools

We'll install the minimum reasonable toolkit for the first lessons:

git, for versioning files and scripts;
curl and wget, for making requests and downloading resources;
vim, because sooner or later you'll edit something in a terminal;
htop, for reading processes without suffering through top;
jq, for working with JSON;
net-tools or modern equivalents, for basic networking commands.

If Vim traps you and you can't exit, it's not a bug, it's an initiation ceremony. Mastering Vim from Scratch starts exactly from that kind of existential moment.

If you're following the recommended path, enter the VM first with multipass shell devops-lab and use the Ubuntu/Debian commands. If you're using another alternative, adapt the installation to your system:

# macOS and Linux (Homebrew)
brew install git curl wget vim htop jq

# Ubuntu / Debian
sudo apt update
sudo apt install -y git curl wget vim htop jq net-tools

# Arch Linux
sudo pacman -S git curl wget vim htop jq net-tools

Then verify everything responds:

git --version
curl --version
vim --version
jq --version

You don't need to memorize every tool now. git gives us traceability; curl lets us talk to services; jq lets us read JSON without crying; htop shows processes with less of a 1998 accounting spreadsheet vibe.

With tools ready, let's make the terminal more comfortable.

Configuring a comfortable terminal

You could do the entire course with the default shell, no plugins, and no colors. You could also write all your code in a tiny-font plain text editor. Possible is not the same as wise.

For now, bash is fine. In fact, it's what you'll find on most servers you connect to. But this is your work terminal, your personal environment — you can afford some luxuries here. If you want a nicer experience, install zsh and, optionally, Oh My Zsh. If you want the slower walkthrough, there is already a dedicated tutorial on how to install ZSH and Oh My ZSH! in GNU/Linux, which fits this Ubuntu VM especially well.

# macOS and Linux (Homebrew)
brew install zsh

# Ubuntu / Debian
sudo apt install -y zsh

# Arch Linux
sudo pacman -S zsh

Oh My Zsh is installed through a remote script. That's common, but it is still a remote script. The responsible version: read it before running it. The realistic version: at least run it from the official source and not from random-devops-blog-2020.example, please.

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

After installing, change your default shell to zsh. If you are using the recommended Multipass VM, the ubuntu user has no password, so use sudo:

sudo chsh -s $(which zsh) ubuntu

On other systems, chsh may ask for your password without sudo. Both achieve the same result.

Now add a few useful aliases to the end of ~/.zshrc or ~/.bashrc, depending on your shell:

# DevOps aliases
alias ll='ls -lah'
alias ports='sudo ss -tulpn'
alias logs='sudo journalctl -f'
alias c='clear'

Reload the configuration:

source ~/.zshrc

Or if you use Bash:

source ~/.bashrc

Don't fill your shell with 200 aliases on day one. That looks like productivity, but it's often decoration with side effects. Start with four or five you actually use. Your terminal should help you, not become an airplane cockpit where you don't know which button turns off the engine.

Creating the course workspace

Let's leave a clean structure for the next exercises:

mkdir -p ~/devops-course/{scripts,configs,logs,projects,notes}
cd ~/devops-course

touch notes/lesson-02.md
printf 'DevOps course workspace ready\n' > notes/lesson-02.md

Check the result (using the ll alias you just created):

ll

You should see something like this:

drwxr-xr-x  7 user user 4.0K Jul  6 10:00 .
drwxr-x--- 20 user user 4.0K Jul  6 10:00 ..
drwxr-xr-x  2 user user 4.0K Jul  6 10:00 configs
drwxr-xr-x  2 user user 4.0K Jul  6 10:00 logs
drwxr-xr-x  2 user user 4.0K Jul  6 10:00 notes
drwxr-xr-x  2 user user 4.0K Jul  6 10:00 projects
drwxr-xr-x  2 user user 4.0K Jul  6 10:00 scripts

Now initialize a Git repository to version your notes and scripts:

git init
git status

On branch main

No commits yet

Untracked files:
  notes/

Make the first commit. First, tell Git who you are (if this is your first time using Git on this machine):

git config user.email "you@email.com"
git config user.name "Your Name"

Add --global if you want this configuration applied to all your repositories.

Now for the actual commit:

git add notes/lesson-02.md
git commit -m "chore: initialize devops course workspace"

Yes, even for a learning workspace. Especially for a learning workspace. If you break something, Git gives you a way back without doing archaeology in your own directory.

Final check

Before closing, run this small checklist:

pwd
git --version
ssh -V
curl --version
jq --version

And confirm mentally:

I have a usable Linux terminal;
I have a course directory;
I can install tools;
Git works;
I know how to connect through SSH, or at least I understand what I need to do it.

If any of this fails, don't continue as if nothing happened. That's one of the big DevOps lessons: a half-broken environment today becomes a lost afternoon tomorrow. Like a chair with one loose leg: you can sit on it, yes, but part of your brain is already drafting the incident report.

Your environment is no longer “an open terminal where things happen.” You now have a minimal workshop: a shell, base tools, a working structure, Git, and a clear idea of how to enter a remote machine.

In the next lesson we'll go down into the Linux filesystem: directories, files, permissions, and basic commands. That's where /etc, /var, /home, and friends stop looking like names chosen by someone in a hurry.

Never stop coding!

Introduction to the DevOps world: culture, automation, and feedback

Javi Palacios — Wed, 21 Oct 2026 06:50:40 +0000

It's 5:43 PM on a Thursday. Development has just finished a feature. Operations needs to deploy it. The feature works locally, tests are green, the ticket is Done, and someone is already thinking about closing the laptop with dignity.

Then production shows up and says: “adorable, but no.”

The server has a different Node version. The environment variable is missing. The deploy script depends on a manual step known by exactly one person. Logs live on one machine, configuration on another, and the document explaining the process is called deploy-final-v2-good-now-for-real.md.

Whose fault is it? Dev? Ops? The VPN? That README nobody has updated since 2021? If you're just starting out, this may sound exaggerated. If you've worked in software before, you probably just remembered a specific face. Sorry about that.

Welcome to the DevOps world.

The problem before DevOps

For a long time, software delivery was organized around a very clear separation:

Development wrote the code.
Operations managed servers, networks, deployments, and production.

On paper, that sounds reasonable. Like separating kitchen and service in a restaurant: one team prepares the food, another serves it. The problem starts when the kitchen doesn't know how the dish is served, service doesn't know what's in the dish, and the customer is staring at lasagna that's still frozen in the middle.

In software, that separation produced familiar symptoms:

“It works on my machine.”
“Ops handles deployments, ask them.”
“We can't deploy until Friday because there's a change window.”
“Where are the logs?”
“Who touched production?”

“It works on my machine” is practically cultural heritage in this industry. It solves nothing technically, but it does buy three seconds of awkward silence. Like assembling IKEA furniture, finding one spare metal part, and deciding it was probably decorative. The shelf is standing. For now.

The real problem wasn't that Dev was irresponsible or Ops was slow. That caricature is convenient, but wrong. The problem was the system of work: separated teams, different goals, little automation, late feedback, and deployments treated as special events instead of a normal part of development.

That's where DevOps comes in.

What is DevOps?

DevOps is a culture and a set of practices for delivering software faster, more safely, and more reliably through collaboration, automation, and continuous feedback.

The important sentence is this: DevOps is not a tool.

It is not Jenkins. It is not Docker. It is not Kubernetes. It is not Terraform. It is not having a 400-line YAML file and hoping that if you look at it respectfully enough, it won't fail.

Tools help, of course. But DevOps starts earlier: it starts when development and operations stop working like two departments throwing packages over a fence and start sharing responsibility for the whole software lifecycle.

That full lifecycle looks roughly like this:

Plan → Code → Build → Test → Release → Deploy → Operate → Monitor

DevOps tries to make that cycle:

faster, because repetitive steps are automated;
safer, because manual changes and surprises are reduced;
more observable, because you know what is happening when something breaks;
more collaborative, because the team shares context and responsibility.

The uncomfortable bit: DevOps cannot be “installed.” It has to be practiced. If a company says “we bought DevOps,” what it probably bought is a tool, consulting, or a laptop sticker. Real DevOps changes how work happens.

And to change how work happens, you need three core ideas.

The three core ideas: collaboration, automation, and feedback

We could build a giant list of principles, but for now keep three. They are the tripod. If one leg fails, the camera falls and the picture comes out blurry. Humble metaphor, accurate result.

Collaboration

Dev and Ops should not meet for the first time on deployment day.

Collaboration means that people writing the code understand how it runs in production, and people operating the system understand what is changing in the product. Not so everyone does everything all the time — that ends in calendar-shaped chaos — but so there are no absurd walls.

A developer doesn't need to become a BGP networking expert to deploy an API. But they should understand what variables it needs, what ports it exposes, what logs it emits, and how to tell if it is healthy.

An operations person doesn't need to know every detail of the business domain. But they should be involved in decisions that affect deployment, capacity, observability, and recovery.

DevOps removes the “I already did my part” escape hatch. In real systems, that sentence is a trap. Your part does not end when you run git push; it ends when the software delivers value in a real environment.

Automation

Every repeated manual step is a future incident updating its résumé.

Building by hand, copying files over SSH, restarting services “in the correct order,” editing configuration directly in production... all of that can work once. You can also cross a road with your eyes closed once. That doesn't make it a methodology.

Automation turns fragile rituals into repeatable steps:

Code → pipeline → tests → build → deploy → monitoring

Instead of depending on someone remembering the exact ceremony, the process lives in scripts, pipelines, repositories, and infrastructure as code.

This is where tools we'll cover later enter the picture: Git, Jenkins, Docker, Kubernetes, Terraform, Prometheus, Grafana. But notice the mental order: problem first, tool second. Buying Kubernetes before understanding deployment is like buying an excavator because you want to hang a picture frame.

Feedback

Fast feedback prevents errors from arriving late, expensive, and dressed as production.

Automated tests, pipelines, alerts, logs, metrics, dashboards, postmortems: all of this exists to answer questions as early as possible:

Does the change work?
Is the system still healthy?
Did the deploy break something?
Are users suffering?
Can we recover quickly?

Without feedback, you work blind. And working blind in infrastructure has a technical name: Friday afternoon.

With collaboration, automation, and feedback, you can already see why DevOps is not “put someone in charge of Jenkins.” It is a way to reduce distance between writing software and operating it.

So, is DevOps a role?

Here is where the confusion gets fun. Fun in the sense of “some org charts look generated by a sleep-deprived AI.”

DevOps started as culture and practices, not a job title. Then the industry did what the industry does: it turned the idea into job postings.

Today you'll see titles like:

DevOps Engineer
Site Reliability Engineer
Platform Engineer
Cloud Engineer
Infrastructure Engineer
Build and Release Engineer

Are they the same? No. Do they overlap? A lot. Does it depend on the company? Absolutely. Does that help beginners? Not even slightly.

A practical way to frame it:

Focus	Main question
DevOps	How do we deliver software better and with less friction?
SRE	How do we make the system reliable in a measurable way?
Platform Engineering	How do we build a platform so other teams deliver software better?

DevOps usually focuses on collaboration, automation, CI/CD, and infrastructure. SRE takes many of those ideas into operational reliability: SLOs, error budgets, incident response, toil, postmortems. Platform Engineering climbs another level: internal tools, Golden Paths, and self-service so teams don't reinvent deployment in every repository.

If DevOps reduces the wall between Dev and Ops, SRE puts numbers on reliability, and Platform Engineering builds the road teams drive on. If the road is well built, nobody thinks about it. If it isn't, everyone ends up in an infinite roundabout holding a Jira ticket.

What a traditional DevOps Engineer does

In many companies, the DevOps Engineer role combines several responsibilities:

Designing and maintaining CI/CD pipelines.
Automating deployments.
Managing infrastructure as code.
Maintaining servers, environments, and configuration.
Setting up basic monitoring.
Helping teams deploy more safely.

That means touching many moving parts. Some pleasant. Some YAML-shaped.

The usual skills include:

Linux/Unix, because most servers live there.
Terminal and scripting, especially Bash and sometimes Python.
Git, because without version control there is no traceability. If Git still feels like a black box with branches, Mastering Git from Scratch will save you real pain.
Containers, usually Docker. If you want to enter there before Kubernetes, Mastering Docker from Scratch is the natural path.
Cloud providers, like AWS or GCP.
Observability, so you can see what is happening when the system stops smiling.

The key is not knowing all of this on day one. No serious person expects that. The key is understanding the map: which piece solves which problem and how the pieces talk to each other.

Because if you don't have a map, every tool looks like a universal solution. That's how you end up trying to fix a DNS problem with Terraform. Don't ask how I know.

The DevOps ecosystem

A simple way to understand the ecosystem is to follow a change from the moment it is written to the moment it is observed in production:

Development → Build → Test → Deploy → Monitor

Git → Jenkins → Docker → Kubernetes → Prometheus
      GitHub    Registry   Helm         Grafana
      GitLab    Artifacts  ArgoCD       Alerts

Don't memorize all the names yet. Seriously, don't stress. The list looks like a hardware store where someone mixed screwdrivers, saws, cables, and a welding machine in the same aisle.

What matters is understanding the categories:

Version control: where code and change history live.
CI/CD: how build, tests, and deploy are automated.
Packaging: how the application is packaged to run consistently across environments.
Orchestration: how multiple services and their lifecycle are managed.
Infrastructure as Code: how infrastructure is described in a versioned way.
Observability: how you see what is happening inside the system.

Each category answers a different question. That distinction saves you from a classic trap: learning tools without understanding the problem. That produces long résumés and fragile systems. Lots of technology, little judgment. Like buying a professional toolbox to tighten one screw and ending up disassembling the washing machine.

The course roadmap

This course is designed so the map appears gradually, not as a wall of acronyms on day one.

We'll move through three large phases.

Phase 1: Traditional DevOps

First we'll build fundamentals:

Linux and terminal.
Processes, services, logs, and basic networking.
Bash scripting.
Git applied to infrastructure.
CI/CD with Jenkins.
Docker and containers.
Kubernetes.
Terraform.

This phase answers the question: how do I automate and operate the software delivery lifecycle?

Here you'll get your hands dirty. Good. DevOps without touching a terminal is like learning to swim from a PowerPoint deck.

Phase 2: SRE

Then we'll move into Site Reliability Engineering:

Advanced observability.
SLOs and error budgets.
Incident management.
Blameless postmortems.
Chaos engineering.
Capacity planning.
Sustainable on-call.

This phase asks a different question: how do I make the system reliable without turning the team into a permanent fire brigade?

SRE introduces a fundamental idea: reliability with numbers. Not “we want it to work well,” but “this service must meet this SLO, and this is the acceptable error margin.” Less heroic intuition, more engineering.

Phase 3: Platform Engineering

Finally we reach Platform Engineering:

Golden Paths.
Developer Experience.
Self-service.
Backstage.
Service catalog.
Internal Developer Platforms.
Internal tooling.

This phase answers the mature question: how do I build a platform so other teams deliver software better without depending on me for every step?

That shift is huge. You move from putting out fires to designing systems that prevent fires from starting. Or, more realistically, systems that at least keep the fire in a controlled area, with alerts, a runbook, and an extinguisher that didn't expire in 2019.

What you should take from this first lesson

DevOps is not about tools. It is about reducing friction between building software and operating it in a real environment.

Tools matter, but they are the consequence. Git, Jenkins, Docker, Kubernetes, Terraform, Prometheus, or Backstage make sense when you understand what problem they solve. Without that context, they are just expensive names in an architecture nobody wants to touch.

Keep these ideas:

DevOps emerged to break silos between Development and Operations.
The foundation is collaboration, automation, and fast feedback.
DevOps is not a pure role, even though roles called DevOps Engineer exist.
SRE and Platform Engineering are related evolutions, not magic words.
The course will move from real fundamentals to modern internal platforms, without jumping straight into deep YAML.

💡 Challenge: Think of a real or imaginary project you know. Write a short note describing how a change is delivered today: who writes the code, how it is tested, how it is deployed, where logs are checked, and how the team knows it works. If at any point your answer is “I don't know” or “someone does it manually,” perfect: you just found a future lesson in this course.

In the next tutorial we'll prepare the working environment. We'll compare local virtual machines, cloud environments, and WSL2, then set up a Linux base so you can start using the terminal without relying on dark magic or “it was already configured on my laptop.”

Never stop coding!

Marks and jumps in Vim: navigate without losing the thread

Javi Palacios — Tue, 20 Oct 2026 12:31:21 +0000

You're editing a function at line 347. Before finishing, you need to check how another function works. You jump with /, get there, read it, realize you also need to see a constant you defined near the top. You head up there. When you try to get back to line 347 — you can't find it. You search for the function name, land close, move around a bit. You pick up the thread again. Now you need to check one more thing in another file.

This isn't editing anymore. This is sightseeing.

Vim has a full system for remembering where you've been: marks for manually saving positions, a jump list for the automatic history of your movements, and a changelist for the spots where you made edits. Once you work these into your flow, "where was I?" stops being a question.

Marks: leaving a signal before you go

A mark is a saved position. To create one, use m followed by a letter:

ma

That saves your current position under the key a. You can use any lowercase letter (a-z). Now move wherever you need to — another function, another section, another file. To return exactly where you were, use backtick followed by the letter:

`a

Cursor back to that exact line and column.

There's also the apostrophe version:

'a

The difference: `a (backtick) jumps to the exact position — line and column. 'a (apostrophe) jumps to the line, but to the first non-blank character. It's the difference between remembering "it was in the third drawer, under the old batteries, in the right corner" versus just "the third drawer." Both work. One is more precise.

Which one to use? Backtick. Almost always. Unless you specifically need the first character of the line, backtick puts you back exactly where you left the cursor.

Marks are movements too, which means they compose with Normal mode grammar:

d`a    " delete from cursor to mark a
y'b    " yank from cursor to the line of mark b

Vim gives you 26 local marks (a-z) and 26 global ones (A-Z) — fifty-two total. Exactly the number that makes you think you need a naming convention and maybe a spreadsheet to track them all. What you'll actually use is two or three: ma to mark where you jumped from, mb for something you need to check later, and ms for that other thing you've been putting off. Always the same two or three.

Global marks: across files

Uppercase letters (A-Z) are global marks: they work across files and persist between Vim sessions.

mA

That saves the current position under A. Tomorrow, after closing and reopening Vim, `A takes you right back there — opening the file if needed.

Useful when you're constantly jumping between two or three files: mA in the config file, mB in the routes file, mC in the main entry point. You jump between them without searching for anything.

Honest limitation: only one slot per letter. If you use mA in a different file, the previous A is gone. Fine with three files; not the right tool if you're trying to build a full project index with 26 active entries. For navigating many files, Vim has better tools you'll see later in the course.

Automatic marks: the ones Vim sets for you

Vim also saves certain positions automatically. You don't have to do anything — they're already there when you need them.

Mark	What it stores
`.	Position of the last change in the file
`^	Position where you left Insert mode last time
`[	Start of the last yanked or changed text
`]	End of the last yanked or changed text
`<	Start of the last visual selection
`>	End of the last visual selection

The most useful one day-to-day: `. jumps to the last place you made a change. No setup, no thinking. `. and you're there.

Then there's '' (two apostrophes), or (two backticks) for the exact-position version. Both store where you were before your last big jump — a search, gg, G, jumping to a mark. It's the retroactive "take me back to the start" command. You don't activate it in advance; Vim records it automatically on every large jump.

To see all active marks at any point:

:marks

It shows a table with name, line, column, and the text at that line. Useful when you've been working for a while and can't remember which mark points where — which is exactly when you need it.

The jump list: the editor's history

Beyond manual marks, Vim keeps an automatic position history called the jump list. Every large jump — searching with /, going to a mark, gg, G, jumping to a definition — gets recorded.

To navigate that history:

Ctrl+o    " go back (older jump)
Ctrl+i    " go forward (newer jump)

Ctrl+o is your browser's back button, but for positions inside the editor. If you've made four jumps from where you started, four Ctrl+o presses bring you back one step at a time. Ctrl+i goes the other way.

To see the full list:

:jumps

The jump list holds 100 positions. A hundred. Just enough to make it look like something you need to actively manage — you don't. When it fills up, the oldest entry quietly disappears. Vim doesn't send a notification. You keep editing.

A note about searches with / and ?: every jump to a result registers in the jump list. If you move through six matches with n, you have six entries. Ctrl+o undoes the trail.

The changelist: where you edited

The jump list tracks positions. The changelist tracks specifically the spots where you made a change in the file.

g;    " go to older change
g,    " go to newer change

To see the full list:

:changes

The common case: you edited something, jumped to another spot to check a variable, and now you want to get back exactly to where you were typing. g; and you're there.

The changelist stores the last 100 changes with exact positions — a detailed audit trail of everything you've touched in the file since you opened it. In practice, you'll use g; once, to get back to the last place you typed something. That's what it's there for.

Special jumps

`%`: the matching pair

Place the cursor on a parenthesis, brace, or bracket, and press %:

It jumps to the matching character. On ( → jumps to ). On } → jumps to the { that opens it. You can bounce back and forth with repeated %.

Useful in heavily nested code: instead of visually counting where a block ends, % takes you there directly.

`gd` and `gD`: go to definition

gd    " go to local definition (within the current scope)
gD    " go to global definition (from the top of the file)

gd finds the first occurrence of the word under the cursor within the local scope — useful for jumping to where a variable is declared. gD does the same but searches from the beginning of the file.

Not the same as LSP, which you'll see later in the course and which jumps with actual semantic context. gd and gD are text searches. In files without LSP, or for local variables with clear names, they work without any configuration.

`gf`: open the file under the cursor

The most underrated command in this lesson.

Place your cursor over a file path in the text:

import { config } from '../config/app'
require('./utils/format')

And press:

gf

Vim opens the file. No extra commands, no file explorer, no copying the path and pasting it into :e. If it exists, gf goes there. To come back, use Ctrl+o — the jump was already recorded in the jump list.

One caveat: gf works with the literal text under the cursor. Paths using bundler aliases (@/components) or implicit extensions might need extra configuration to resolve. On explicit paths, it works out of the box.

Key concepts from this lesson

m{a-z} creates a local mark; `{letter} jumps to the exact line and column; '{letter} jumps to the line
m{A-Z} creates a global mark that persists across sessions and works across files
`. jumps to the last change; '' jumps to the position before the last big jump
:marks lists all active marks
Ctrl+o / Ctrl+i move backward and forward through the jump list
g; / g, move through the changelist (edit history)
% jumps between matching open and close characters
gd / gD jump to the local or global first occurrence of the word under the cursor
gf opens the file whose path is under the cursor

💡 Challenge: Open a large file from a real project. Set ma where you are, jump to another section with /, come back with `a. Make a small edit, jump with gg, come back with g;. If there's any file path referenced in the code, place your cursor on it and try gf. Then run :marks and :jumps to see both lists — everything you just did is recorded there.

Marks and jumps close out Vim's core navigation system. You now have the tools to move through any codebase without losing the thread. In the next tutorial, we'll cover text objects — what many consider Vim's actual superpower: the ability to operate on "the content inside these quotes," "the block within these braces," or "this whole word" with a single two-key command.

Never stop coding!

DEV Community: Javi Palacios

What is JavaScript and Why Node.js Exists

JavaScript was born in the browser

Why anyone took it out of there

V8 is not Node

libuv: the one that waits for you

What Node wins and what it loses

JavaScript versus Python

Installing Node with nvm

First contact with the runtime

Common problems

nvm: command not found

node -v shows a different version

.nvmrc exists but the version doesn't change

nvm install --lts fails with a checksum or network error

What you take from this lesson

Setting Up PostgreSQL with Docker, psql, and pgAdmin

What we are actually running

Creating the lab project

Understanding the compose.yaml

Starting PostgreSQL and pgAdmin

Connecting with psql

Basic psql commands

Connecting with pgAdmin

Creating a test table

Stopping, starting, and cleaning the environment

Common problems

Port 5432 is already in use

pgAdmin does not connect with localhost

I changed the password and it still fails

psql is waiting because I forgot the semicolon

What you take from this lesson

Linux essentials for DevOps: navigation, files, and permissions

The Linux filesystem is not one giant folder

Knowing where you are: pwd, ls, and cd

Creating directories without starting an archaeological dig

Creating, copying, moving, and renaming files

Reading files without opening an editor

Deleting files: the chainsaw moment

Understanding permissions: rwx without dark magic

Changing the owner: chown

Finding files and searching inside them

Guided practice: prepare an operations structure

What you should take from this lesson

Verifying and understanding AI-generated code

The “can I explain this?” test

Make AI declare its assumptions

Tests are not decoration

Red flags that are not negotiable

The serious review prompt

Understanding does not mean memorizing everything

When to accept, refine, or reject

Key concepts from this lesson

Iteration and refinement: the AI dialogue

The first answer is rarely the right one

The refinement loop

Change one thing at a time

When to refine and when to start fresh

Managing long conversations

The refinement template

Ask for differences, not just new versions

Don't let AI move the goalposts

Key concepts from this lesson

Scope and namespaces in Python: where your variables live

What scope is

Local variables

Global variables

The mental rule: Python searches from the inside out

What a namespace is

The global keyword

Nested functions

The nonlocal keyword

When to avoid global and nonlocal

Common scope mistakes

Thinking a local variable exists outside

Modifying a global without global

Shadowing a built-in by accident

Key concepts from this lesson

Why We Need Databases

The problem: storing data is not managing data

`nvm: command not found`

`node -v` shows a different version

`.nvmrc` exists but the version doesn't change

`nvm install --lts` fails with a checksum or network error

Understanding the `compose.yaml`

Connecting with `psql`

Basic `psql` commands

Port `5432` is already in use

pgAdmin does not connect with `localhost`

`psql` is waiting because I forgot the semicolon

Knowing where you are: `pwd`, `ls`, and `cd`

Understanding permissions: `rwx` without dark magic

Changing the owner: `chown`

`localhost` inside a container is not your machine

`ports` is not how containers talk to each other

`expose` vs `ports`

`%`: the matching pair