study.plynte.com
@franguh
Estado de Lectura Marca tu progreso local en tu navegador (iPad / Móvil / Desktop)
⏱️ ~17 min de lectura
📑 Índice de esta página (16 secciones)

00 · Lección cero: cómo funciona todo (sin tecnicismos)#

Esta lección es para ti si nunca has programado, o si lo intentaste hace tiempo y todo te sonó a otro idioma. No necesitas saber programar ni tener conocimientos técnicos previos. Vamos a recorrer doce ideas que aparecen una y otra vez en el curso, cada una con una comparación de la vida diaria y un dibujo.

Calcula unas 2–3 horas de lectura, con pausas. Al terminar cada sección, pregúntate si podrías explicarla con tus propias palabras. Si no, vuelve a leerla antes de seguir.

ℹ️ Nota Informativa

Esta lección no sustituye a las lecciones técnicas: es el mapa que te permite leerlas sin perderte. No hace falta memorizar nada, basta con entender la idea. Los nombres técnicos (Rust, HTTP, PostgreSQL) se explican con calma en cada lección.


1 · Qué es un programa#

Un programa es una lista de instrucciones escrita en un lenguaje que las personas podemos leer, pero que el ordenador no ejecuta tal cual. Cada instrucción dice algo concreto: "pregunta un nombre", "suma estos dos números", "guarda este texto". Antes de poder usarse, ese texto se traduce a una forma que el procesador sí entiende. Piensa en una receta escrita en tu idioma: la lees y sabes qué hacer, pero la cocina necesita pasos ordenados y sin ambigüedad. Un programa es una receta muy precisa, escrita para una máquina que no improvisa ni adivina lo que quisiste decir.

TEXT
 TU TEXTO (instrucciones)
 ┌──────────────────────────────┐
 │ 1. pregunta el nombre        │
 │ 2. saluda con ese nombre     │
 └──────────────┬───────────────┘
                │ traducción
                ▼
 ARCHIVO EJECUTABLE
 ┌──────────────────────────────┐
 │ 010110 101100 ...            │
 └──────────────┬───────────────┘
                │ ejecución
                ▼
 PANTALLA:  ¿Cómo te llamas?

Lo verás en: lección 00 · Guía de sintaxis, funciones y memoria


2 · Compilar frente a ejecutar#

Hay dos momentos distintos. Compilar es revisar tu texto y traducirlo a un archivo ejecutable. Ejecutar es poner ese archivo en marcha para que haga su trabajo. El compilador de Rust es especialmente estricto: si encuentra algo que no cuadra, se niega a crear el ejecutable y te explica dónde está el problema. Al principio puede parecer molesto, pero significa que muchos fallos aparecen antes de que el programa llegue a usarse. Así que escribir una receta y revisarla es una cosa; cocinarla, otra.

ℹ️ Nota Informativa

Piénsalo como un revisor de recetas: el compilador comprueba que la receta esté bien escrita y que sus pasos encajen entre sí. Dónde falla la analogía: el revisor no cocina ni prueba el sabor. Que la receta esté bien escrita no garantiza que el plato sea el que querías.

TEXT
 1) COMPILAR: revisar y preparar
 ┌──────────┐   ┌────────────┐   ┌──────────────┐
 │ tu texto │──▶│ compilador │──▶│ ejecutable   │
 └──────────┘   └─────┬──────┘   └──────────────┘
                      │
          ✘ errores: no crea nada, te avisa
          ✔ sin errores: crea el ejecutable

 2) EJECUTAR: usar el programa
 ┌──────────────┐   ┌──────────────────┐
 │ ejecutable   │──▶│ resultado        │
 └──────────────┘   └──────────────────┘

Lo verás en: laboratorio local · tu primer "hola mundo"


3 · La terminal y los comandos#

La terminal es una ventana de texto donde escribes órdenes en lugar de hacer clic. Parece antigua, pero es la forma más directa de pedirle cosas al ordenador cuando trabajas con programas. En Windows se usa PowerShell; en macOS y Linux, la aplicación llamada Terminal (o una equivalente). Cada orden es una palabra, a veces con un argumento: cd proyectos entra en la carpeta "proyectos", dir (en Windows) o ls (en macOS y Linux) muestra lo que hay dentro, y cd .. sube un nivel. Escribe exactamente lo que se indica, porque la terminal no adivina.

ℹ️ Nota Informativa

Piénsalo como un camarero muy literal: si pides "algo de beber", no sabe qué traerte; si pides "un vaso de agua fría", lo hace. Dónde falla la analogía: un camarero puede corregirte si te equivocas; la terminal, en cambio, ejecuta lo que escribiste, así que conviene leer antes de pulsar Enter.

TEXT
 C:\Usuarios\ana> cd proyectos
 C:\Usuarios\ana\proyectos> dir
     web/        notas.txt
 C:\Usuarios\ana\proyectos> cd ..
 C:\Usuarios\ana>

cd cambia de carpeta, dir lista su contenido y cd .. vuelve a la de arriba.

Lo verás en: laboratorio local · herramientas en Windows


4 · Archivos, carpetas y rutas#

Todo lo que guarda un ordenador vive en archivos (un documento, una foto, un programa), y los archivos se organizan en carpetas, que pueden contener otras carpetas. La ruta es la dirección completa de un archivo: el camino de carpetas desde la raíz del disco hasta él. En Windows las carpetas se separan con barras invertidas (C:\Usuarios\...); en macOS y Linux, con barras normales (/home/ana/...). Una ruta puede ser absoluta, si empieza desde la raíz, o relativa, si empieza desde la carpeta en la que estás ahora. Saber en qué carpeta estás resuelve, más de lo que parece, los casos de "no encuentra el archivo".

ℹ️ Nota Informativa

Piénsalo como una dirección postal: "Calle Mayor 5, 2.º B, Valencia" va de lo general a lo particular, y el cartero necesita el camino completo. Dónde falla la analogía: la dirección postal no cambia según dónde esté el cartero; una ruta relativa sí depende de la carpeta en la que te encuentres.

TEXT
 C:\
 └── Usuarios\
     └── ana\
         └── proyectos\
             ├── notas.txt
             └── web\
                 └── index.html

 Ruta completa (absoluta):
 C:\Usuarios\ana\proyectos\web\index.html

Lo verás en: laboratorio local · carpetas aisladas


5 · Variables y tipos#

Una variable es una caja con nombre donde guardas un valor para usarlo después. Le pones una etiqueta ("edad", "nombre") y dentro guardas algo: un número, un texto o un verdadero/falso. Cada caja tiene además un tipo, que dice qué clase de valor admite: no es lo mismo guardar 27 que guardar "Lucía". En Rust, el tipo queda fijado antes de ejecutar el programa, y el compilador vigila que no los mezcles sin querer. Así se evitan errores tontos, como sumar un nombre a una edad. Por defecto, además, el contenido de una caja no cambia una vez puesto, salvo que lo pidas de forma explícita.

ℹ️ Nota Informativa

Piénsalo como las cajas de una cocina con etiqueta: "azúcar", "sal", "harina". Puedes cambiar lo que hay dentro, pero nadie debería meter sal en la caja del azúcar sin que alguien lo note. Dónde falla la analogía: en una cocina no hay un revisor que lo impida; el compilador de Rust sí lo impide antes de que el programa arranque.

TEXT
 ┌───────────────┐   ┌───────────────┐
 │ edad          │   │ nombre        │   ← etiqueta
 ├───────────────┤   ├───────────────┤
 │ 27            │   │ "Lucía"       │   ← valor
 └───────────────┘   └───────────────┘
  tipo: número        tipo: texto

Lo verás en: lección 01 · Tipos y flujo de control


6 · Funciones: entrada, proceso y salida#

Una función es un paso con nombre que recibe datos, hace algo con ellos y devuelve un resultado. Su forma básica es siempre la misma: entrada, proceso y salida. Por ejemplo, una función "sumar" recibe dos números, los suma y devuelve el total. Así no repites la misma operación en veinte sitios: la escribes una vez y la llamas cuantas veces necesites. Si la función no depende de nada externo (ni de la hora, ni de un archivo, ni de internet), la misma entrada siempre produce la misma salida, y por eso es fácil de entender y de probar.

ℹ️ Nota Informativa

Piénsalo como una máquina de café: metes café molido y agua (entrada), la máquina prepara la bebida (proceso) y sale un café (salida). Dónde falla la analogía: una máquina real puede quedarse sin agua o averiarse, y una función también puede fallar. El programa tiene que prever esos casos.

TEXT
 ENTRADA        PROCESO         SALIDA
 ┌───────┐    ┌───────────┐   ┌───────┐
 │ 3 y 4 │───▶│ sumar     │──▶│   7   │
 └───────┘    └───────────┘   └───────┘

Lo verás en: lección 00 · Guía de sintaxis, funciones y memoria


7 · Memoria RAM frente a disco#

Un ordenador tiene dos sitios para guardar cosas. La memoria RAM es como la mesa de trabajo: todo lo que el programa usa en ese momento se pone ahí porque es muy rápida. El disco es como el armario: es más lento, pero guarda las cosas aunque apagues la máquina. Por eso, cuando cierras un programa sin haber guardado, lo que estaba solo sobre la mesa desaparece. Un programa que no guarda sus datos en disco pierde todo al reiniciarse. Esta idea es clave para entender por qué existen las bases de datos.

ℹ️ Nota Informativa

Piénsalo como un cocinero: trabaja sobre la mesa con los ingredientes del plato actual, y el resto está en la despensa del fondo. Dónde falla la analogía: la RAM no se "tira", simplemente se vacía al cortarse la corriente. Y el disco también puede fallar, por eso existen las copias de seguridad.

TEXT
 ┌────────────────────┐   ┌────────────────────┐
 │ MEMORIA RAM        │   │ DISCO              │
 │ (la mesa)          │   │ (el armario)       │
 │ rápida             │   │ más lento          │
 │ se vacía al        │   │ guarda aunque      │
 │ apagar             │   │ apagues            │
 └────────────────────┘   └────────────────────┘

 Mientras el programa corre: trabaja en la mesa.
 Para que sobreviva: se escribe en el armario.

Lo verás en: lección 07 · Invariantes de PostgreSQL


8 · Cliente y servidor#

Muchas aplicaciones están repartidas en dos partes. El cliente es quien pide: normalmente, el navegador con el que lees esta página, o una app del móvil. El servidor es un programa que espera peticiones, las atiende y responde. El cliente muestra lo que ves; el servidor guarda la información, decide qué es correcto y te la entrega. Cuando abres tu red social, tu teléfono pide "dame mis mensajes" y el servidor responde con ellos. En tu ordenador de estudio, cliente y servidor pueden correr a la vez, cada uno en su ventana, y hablarse como si estuvieran lejos.

ℹ️ Nota Informativa

Piénsalo como un restaurante: tú (cliente) pides en la mesa, la cocina (servidor) prepara el plato, y el camarero lo trae. Tú no entras en la cocina. Dónde falla la analogía: en la web, el cliente también hace trabajo propio, como mostrar botones o comprobar que escribiste bien un formulario.

TEXT
 ┌──────────────┐                ┌──────────────┐
 │  NAVEGADOR   │ ────── pide ──▶│   SERVIDOR   │
 │  (cliente)   │                │  (programa   │
 │ muestra lo   │◀── responde ── │  que espera) │
 │ que ves      │                │ guarda y     │
 └──────────────┘                │ decide       │
                                 └──────────────┘

Lo verás en: lección 12 · Integración de extremo a extremo


9 · Petición y respuesta HTTP#

Cuando el cliente pide algo, envía una petición (request). Incluye una acción, como GET ("dame esto") o POST ("toma estos datos y guárdalos"), y una dirección del recurso, como /notas/3. El servidor contesta con una respuesta que incluye un código de estado: un número de tres cifras que resume el resultado. El 200 significa "todo bien, aquí tienes lo que pediste". El 404 significa "no encontrado": la dirección o el elemento no existe. El 500 significa "error interno": el servidor tropezó con un fallo por dentro. Una regla práctica: 2xx es que salió bien, 4xx indica que hay que revisar lo que se pidió, y 5xx indica que el problema está en el servidor.

ℹ️ Nota Informativa

Piénsalo como pedir un libro en una biblioteca: das el título (la dirección). La bibliotecaria puede decir "aquí está" (200), "no lo tenemos en el catálogo" (404) o "se ha caído el sistema del almacén" (500). Dónde falla la analogía: en HTTP hay muchos más códigos que estos tres, y la respuesta lleva datos con formato estructurado, no una conversación.

TEXT
 NAVEGADOR                        SERVIDOR
    │                                │
    │ 1. GET /notas/3                │
    │ ──────────────────────────────▶│
    │ (busca la nota 3)              │
    │ 2. 200 OK: aquí tienes         │
    │ ◀──────────────────────────────│
    │                                │
    │ 3. GET /notas/999              │
    │ ──────────────────────────────▶│
    │ 4. 404 Not Found: no existe    │
    │ ◀──────────────────────────────│

Lo verás en: lección 05 · Contratos HTTP


10 · API: un menú entre programas#

Una API (Application Programming Interface, o interfaz de programación de aplicaciones) es el conjunto de peticiones que un programa acepta y el formato de las respuestas que devuelve. Funciona como un contrato: quien pide sabe qué puede pedir y qué recibirá, sin necesidad de conocer cómo funciona por dentro el otro programa. Por ejemplo, una API de notas podría aceptar "dame la lista", "crea una nota" o "borra la nota 3", y responder siempre con un formato conocido. Así, la web y la app del móvil pueden usar los mismos datos sin copiar la lógica. Si el servidor cambia por dentro pero el contrato se mantiene, los clientes siguen funcionando.

ℹ️ Nota Informativa

Piénsalo como la carta de un restaurante: indica qué puedes pedir y cómo llegará el plato, pero no la receta ni dónde está la despensa. Dónde falla la analogía: una carta rara vez cambia sin avisar, mientras que en software cambiar el formato de una API sin avisar puede romper a quienes la usan.

TEXT
 Cliente: "quiero la lista de notas"
                  │
                  ▼
 ┌──────────────────────────────────────┐
 │ MENÚ DE LA API                       │
 │ GET   /notas       devuelve la lista │
 │ POST  /notas       crea una nota     │
 │ GET   /notas/3     devuelve una nota │
 └──────────────────────────────────────┘
                  │
                  ▼
 El servidor prepara lo que pediste

Lo verás en: lección 06 · Límites con Actix


11 · Base de datos: tablas, filas y disco#

Una base de datos es un sistema especializado en guardar información de forma ordenada, en disco, y en recuperarla cuando se le pide. Los datos se organizan en tablas. Cada tabla tiene columnas (qué datos guardas, como el título o si la nota está hecha) y filas (cada fila es un elemento completo, como una nota). Lo importante es que la base de datos escribe en disco, no solo en la memoria del programa. Por eso, aunque reinicies el servidor o apagues el ordenador, las filas siguen allí. Además, una base de datos bien diseñada puede impedir datos incoherentes, por ejemplo una nota sin título.

ℹ️ Nota Informativa

Piénsalo como un archivador de oficina con fichas: todas las fichas tienen los mismos campos, y el archivo se guarda en una sala que no se vacía al cerrar la oficina. Dónde falla la analogía: en un archivador dos personas podrían coger la misma ficha a la vez; las bases de datos reales tienen mecanismos para evitar eso, y muchas más funciones (copias, consultas, control de accesos).

TEXT
 Tabla "notas"
 ┌────┬──────────────┬────────────────┐
 │ id │ título       │ hecha          │
 ├────┼──────────────┼────────────────┤
 │ 1  │ Comprar pan  │ sí             │
 │ 2  │ Llamar a Ana │ no             │
 └────┴──────────────┴────────────────┘
   columnas: qué guardo
   fila: una nota completa

Lo verás en: lección 07 · Invariantes de PostgreSQL


12 · Tipos de error: sintaxis, compilación, ejecución y lógica#

Programar implica equivocarse, y eso es normal. Hay cuatro tipos básicos de error, según cuándo aparecen. Los de sintaxis son errores de gramática, como olvidar un paréntesis. Los de compilación aparecen cuando la gramática es válida pero algo no encaja, por ejemplo mezclar un número con un texto. Los de ejecución surgen mientras el programa corre, por ejemplo al intentar abrir un archivo que no existe. Los de lógica son los más traicioneros: el programa funciona sin avisar, pero hace algo distinto de lo que querías. Como nadie los señala, existen las pruebas para detectarlos. Un error es información: te dice dónde mirar. No es un fracaso personal.

ℹ️ Nota Informativa

Piénsalo como un GPS: cuando dice "recalculando", te avisa de que el camino previsto no sirve y te da una pista. Dónde falla la analogía: un error de lógica es como un GPS que te lleva con total seguridad a un lugar equivocado, sin decir nada.

TEXT
 Momento en que aparece      Tipo de error
 ──────────────────────────────────────────
 Escribes el texto        ▶ SINTAXIS
                             falta un paréntesis
 Compilas                 ▶ COMPILACIÓN
                             los tipos no encajan
 Ejecutas                 ▶ EJECUCIÓN
                             un archivo no existe
 Lo usas y responde mal   ▶ LÓGICA
                             hace algo distinto a lo pedido

Lo verás en: lección 03 · Modelar errores y pruebas


🗺️ El gran dibujo: cómo encaja todo#

Juntemos las piezas. Cuando escribes una dirección en el navegador y pulsas Enter, ocurre algo parecido a esto:

TEXT
 ┌─────────────┐  (1) petición  ┌─────────────┐
 │ NAVEGADOR   │ ─────────────▶ │ SERVIDOR    │
 │ módulos     │                │ Rust        │
 │ 09 a 12     │ ◀───────────── │ módulos     │
 │ (pantalla)  │  (4) respuesta │ 01 a 06     │
 └─────────────┘                └──────┬──────┘
                                       │ (2) pide datos
                                       │ (3) recibe datos
                                       ▼
                                ┌─────────────┐
                                │ BASE DATOS  │
                                │ PostgreSQL  │
                                │ módulo 07   │
                                └─────────────┘

Lee el dibujo en este orden: primero sale la petición desde el navegador, luego el servidor consulta la base de datos, y al final la respuesta regresa hasta tu pantalla. Cada pieza corresponde a una parte del curso: el navegador se estudia en los módulos 09 a 12, el servidor en los módulos 01 a 06 (Rust, y después Actix para las peticiones HTTP), y la base de datos en el 07. Los módulos 13 a 18 aplican todo esto al diseño, las pruebas y la operación.


🧭 Ruta recomendada para principiantes#

Estas cifras son estimaciones orientativas, no plazos. El ritmo real depende de tu experiencia previa y de cuánto practiques. En conjunto, el camino completo ronda las 120–160 horas, lo que supone unos 4 a 6 meses a un ritmo de 6–8 horas por semana. En cada lección puedes empezar por la sección 🧭 Explicado para principiantes, que resume la idea antes del detalle.

PasoQué leerTiempo aprox.
1Esta lección: cómo funciona todo2–3 h
2Laboratorio local: instalar herramientas y hacer tu primer "hola mundo"2 h
3Guía de sintaxis, funciones y memoria3 h
401 Tipos y flujo y 02 Ownership y préstamos8–10 h cada una; la 02 en dos sesiones
503 Errores y pruebas y 04 Colecciones6–8 h cada una
605 Contratos HTTP, 06 Actix y 07 PostgreSQL; 08 Async como segunda pasada6–10 h cada una
709 HTML y CSS a 12 Integración6–8 h cada una
813 a 18, primero en modo lectura4–6 h cada una
9Algoritmos2–3 sesiones por semana de 90–120 min, con repaso semanal

No hace falta completar los 70 días de algoritmos de forma seguida. Dos o tres sesiones por semana con un repaso semanal suelen funcionar mejor que una maratón.


✅ Autoevaluación amable#

Intenta responder cada pregunta antes de abrir la respuesta. Si fallas alguna, no pasa nada: vuelve a la sección correspondiente. No es un examen.

1. ¿Qué es un programa?

Un texto con instrucciones precisas que se traduce a un archivo ejecutable.

2. ¿Qué hace el compilador de Rust si encuentra un error?

No crea el ejecutable y te explica dónde está el problema.

3. Apagas el ordenador. ¿Qué pasa con los datos que solo estaban en la RAM?

Se pierden, porque la RAM se vacía al apagarse. Lo que estaba guardado en disco sigue ahí.

4. Un servidor responde 404. ¿Qué significa?

No encontrado: la dirección o el elemento pedido no existe. Un 500 indicaría un fallo interno del servidor.

5. ¿Qué es una API?

Un contrato entre programas: indica qué peticiones acepta y en qué formato responde.

6. ¿Por qué los datos de una base de datos sobreviven a un reinicio?

Porque se guardan en disco, no solo en la memoria del programa.

7. Tu programa compila y se ejecuta, pero el total de la factura sale mal. ¿Qué tipo de error es?

Un error de lógica: el programa no avisa, pero hace algo distinto de lo que querías.

8. En Windows, ¿dónde escribes los comandos de este curso?

En PowerShell.


Siguiente paso#

Cuando te sientas cómodo con las doce ideas, sigue con el laboratorio local para hacer tu primer programa. Después, vuelve al índice de este módulo y consulta el mapa general del curso.

Estado de Lectura Marca tu progreso local en tu navegador (iPad / Móvil / Desktop)