El .gitignore de Spring Initializr cubre .project, .classpath y .settings, pero no bin/, que es donde la extensión de Java de VS Code deja las clases compiladas. Aparecía como carpeta sin rastrear en todas las máquinas.
Desarrollo de Aplicaciones Web con Spring Boot
Taller de 5 días para el área académica de Tecnologías de la Información de la Universidad Tecnológica de Xicotepec de Juárez, impartido por NOCHEBUENA|DEV.
Construimos una API REST con Spring Boot 4 sobre Java 21, desde el contenedor hasta el despliegue. El dominio es el de PEI, la plataforma de evaluación de proyectos integradores: el recurso central es el evento y su ciclo de vida de ocho fases, que es el mismo proceso de las ferias de ciencia y de emprendedores.
Qué necesitan instalado
| Windows | WSL 2 con Ubuntu |
| Docker Desktop | con la integración de WSL activada |
| Visual Studio Code | con la extensión Dev Containers |
No hace falta instalar Java ni Maven: viven dentro del contenedor.
Cómo empezar
git clone https://code.nochebuena.dev/workshops/spring-boot.git
Desde WSL, no desde /mnt/c. Después:
- Abrir en VS Code la carpeta
repositories/pei-api— no la raíz del repo, porque ahí es donde vive el.devcontainer - Aceptar Reopen in Container cuando VS Code lo ofrezca
- La primera vez tarda: descarga las imágenes y las dependencias de Maven
Ya dentro del contenedor:
./mvnw spring-boot:run
| Servicio | Dónde |
|---|---|
| API | http://localhost:8080 |
| pgAdmin | http://localhost:5050 |
| PostgreSQL | sólo dentro de la red del compose, sin puerto publicado |
pgAdmin ya trae el servidor registrado. La contraseña de la base está en el
docker-compose.yaml del .devcontainer.
El material
Las diapositivas están en pdf/ y su fuente en docs/,
escritas en Marp.
| Día | Módulo | |
|---|---|---|
| 1 | 0 — Introducción | |
| 1 | 1 — Contenedores, Compose y devcontainers | |
| 1 | 2 — Fundamentos del ecosistema Spring | |
| 2 | 3 — Web y REST | |
| 3 | 4 — Persistencia | |
| 4 | 5 — Seguridad | |
| 5 | 6 — Imágenes y despliegue | |
| 5 | 7 — Microservicios |
Los símbolos que aparecen en las diapositivas: 💬 idea clave · ⚠️ error común · 🎓 cómo enseñarlo · 🔗 documentación oficial
Las ramas
Cada día tiene checkpoints. Si algo se atora, se cambia de rama y se sigue sin quedarse atrás.
| Rama | Qué contiene |
|---|---|
main |
sólo el material: diapositivas y el proyecto base |
dia_1_final |
el estado con el que cerró el día 1 |
dia_2_inicio |
el andamio del día 2: modelo, DTO y servicio en memoria |
dia_2_final |
el día 2 resuelto: controlador, fases, validación y errores |
dia_3_inicio |
de donde arranca el día 3 |
Las ramas resueltas de cada día se publican al terminar ese día, y las de los días siguientes conforme avanza la semana.
Para trabajar, sáquense su propia rama y no la de ellos. El patrón es el
mismo todos los días — mi_dia_N a partir de dia_N_inicio:
git switch -c mi_dia_3 dia_3_inicio
Así pueden comparar contra la rama resuelta cuando quieran, sin perder lo suyo.