Roadmap

Los hitos no fijan versiones de productos. Cada incorporación verifica soporte y documentación oficial en la fecha de implementación, y añade sus fuentes al registro antes de escribir una sola línea de clase.

3.0 — El mismo problema en cada motor (actual)

• 15 partes, 74 clases, 230 horas, con la parte 00 como rampa de entrada.
• 408 implementaciones repartidas en las 74 clases: cada una declara un caso con su salida esperada y lo resuelve —o explica por qué no— en varios motores.
• 267 de ellas se ejecutan contra el motor real en integración continua: SQLite y DuckDB sin servicios, y PostgreSQL, MySQL, MongoDB, Redis y Neo4j contra el contenedor, con el cliente oficial de cada uno.
• Todo motor declara su por qué no y su página de documentación oficial, y el validador comprueba que ese enlace cuelga del dominio que registra el catálogo.
• Registro de 120 fuentes con ISBN, DOI o URL oficial, y verificador que comprueba también los 347 enlaces de documentación de motores.

2.0 — Programa con fuentes verificables

• 14 partes, 64 clases, 210 horas.
• Registro de 109 fuentes con ISBN, DOI o URL oficial.
• Validación que bloquea cualquier clase sin respaldo bibliográfico.
• Sitio de GitHub Pages generado, con búsqueda y filtros.
• Integración continua sobre Python 3.11, 3.12 y 3.13.

2.1 — Laboratorios ejecutables por parte

El núcleo ejecutable pasó de dos laboratorios a cinco: todos sin dependencias externas y comprobados en integración continua sobre Python 3.11, 3.12 y 3.13.

Hecho:

• actualización perdida reproducida con hilos reales y corregida con actualización atómica, control optimista y bloqueo pesimista;
• laboratorio de planes de ejecución con aserciones sobre el plan y sobre el trabajo —instrucciones de la máquina virtual—, no sobre el tiempo, para que sea reproducible en cualquier máquina;
• laboratorio de cargas NoSQL que mide TTL frente a coherencia, incrustar frente a referenciar y el efecto de una clave de partición caliente;

• pruebas que someten al validador a un repositorio roto a propósito, para que la regla de las fuentes esté demostrada y no solo declarada.

• laboratorio de réplica que cuenta lecturas obsoletas, garantías de sesión rotas y el costo de cada corrección;

• laboratorio de respaldo y restauración a un punto en el tiempo, con RPO y trabajo de recuperación medidos;
• mapeo de certificaciones con la cobertura calculada desde los pesos oficiales del examen.

Pendiente:

• reproducción automatizada de las anomalías de aislamiento (método de Hermitage) contra PostgreSQL y MySQL en contenedor;
• medición del retraso de réplica contra un motor real, no solo sobre el modelo;
• cronometrar la restauración sobre PostgreSQL con archivado de WAL;
• cobertura del resto de las partes: quedan siete sin laboratorio propio.

2.2 — Autoevaluación y trazabilidad del aprendizaje

Hecho:

• banco de preguntas publicado en el sitio con las 256 preguntas de evaluación, cada una enlazada a su clase y a la rúbrica que la corrige;
• registro de avance por clase, guardado localmente en el navegador, con contador en la portada y filtro de clases pendientes.

Pendiente:

• rúbrica del proyecto final aplicable por una tercera persona: diez dimensiones con sus cuatro niveles descritos, mínimos por dimensión y faltas críticas, generada desde el currículo;
• examen final por rol y criterio de evidencia de laboratorio, también generados.

Pendiente:

• cuestionario interactivo con corrección orientativa en el cliente, sin servidor y sin convertir preguntas de explicación en preguntas de opción múltiple, que sería empobrecerlas;
• ejemplos de entrega corregidos —un trabajo de nivel 2 y otro de nivel 4 sobre el mismo dominio— para calibrar a quien corrige.

2.3 — Material descargable

• PDF por parte y PDF del programa completo, generados desde las mismas lecciones;
• versión en blanco y negro apta para impresión, sin cortar bloques de código;
• cuadernos ejecutables por laboratorio.

2.4 — Ampliación de la cobertura

Cada motor nuevo entra con ficha, documentación oficial en el registro y una clase que lo trate; nunca solo con una línea en el catálogo:

• motores distribuidos SQL (CockroachDB, TiDB, YugabyteDB);
• formatos de tabla abiertos (Iceberg, Delta, Hudi) sobre almacenamiento de objetos;
• motores vectoriales adicionales y comparación medida de recall entre ellos.

3.0 — Programa evaluable de extremo a extremo

• proyecto final con conjunto de datos de mayor escala y mediciones esperadas;
• guion de defensa técnica con criterios públicos;
• portafolio verificable a partir de las evidencias generadas;
• traducción al inglés, conservando el mismo registro de fuentes;
• ampliar el mapeo de certificaciones a los exámenes cuyo temario hoy no es verificable —Google Professional Data Engineer, CDMP— si sus proveedores publican pesos citables.

Criterios para cerrar un hito

Un hito se da por cerrado cuando: la validación pasa, los artefactos están regenerados, las fuentes nuevas están en el registro y citadas, y existe una evidencia reproducible de lo que el hito afirma haber conseguido.

Fuente de esta página: ROADMAP.md