Has recorrido las siete primeras lecciones aprendiendo herramientas: montaste el entorno, escribiste tu primer programa, conociste la sintaxis, los tipos, los operadores y las conversiones. En cada ejemplo aparecían Marta, Iván y Lucía, y unas tareas con título, prioridad y horas estimadas. Ha llegado el momento de presentar formalmente el proyecto que atraviesa todo el curso: qué es Taller Nómada, qué problema tiene, qué aplicación vas a construir para resolverlo, cuál es el modelo de datos canónico que usarás durante los once módulos y qué parte construirás en cada uno. Esta lección es el mapa del viaje completo.

1. Taller Nómada: el contexto
2. El problema que hay que resolver
3. El equipo: Marta, Iván y Lucía
4. Qué hará Nómada Tareas
5. El modelo de datos canónico de una tarea
6. El objeto de ejemplo de referencia
7. Reglas de negocio del proyecto
8. Mapa del curso: qué construye cada módulo
9. La estructura de ficheros que irá creciendo
10. Errores Comunes y Consejos
11. Ejercicios
12. Conclusión

Taller Nómada es un pequeño espacio de coworking y taller creativo situado en una nave rehabilitada. Es una empresa completamente ficticia, creada para este curso, con datos igualmente ficticios.

Su actividad tiene dos patas:

• Coworking: doce puestos de trabajo fijos y una sala polivalente que se alquila por horas para reuniones y presentaciones.
• Taller creativo: un espacio con equipamiento de serigrafía, encuadernación y pequeña carpintería, donde se imparten cursos y se acogen proyectos de residentes.

El negocio funciona, pero la gestión interna no. Y ese es el punto de partida.

Hoy, el trabajo de Taller Nómada se organiza así:

• Una pared de notas adhesivas con las tareas en curso.
• Un grupo de mensajería donde se acuerdan cosas que nadie apunta.
• Una hoja de cálculo compartida que nadie actualiza desde marzo.

Las consecuencias son las esperables:

Lo que necesitan no es una herramienta corporativa con mil opciones. Necesitan algo pequeño, rápido y suyo: una lista de tareas compartida donde se vea quién hace qué, con qué prioridad y para cuándo.

Eso es Nómada Tareas, y lo vas a construir tú.

Tres personas que serán las protagonistas de todos los ejemplos y ejercicios del curso.

Sus necesidades no son iguales, y eso es deliberado: te obligará a pensar en filtros, ordenaciones y vistas distintas sobre los mismos datos.

El alcance completo de la aplicación, en orden aproximado de construcción:

1. Crear tareas con todos sus campos, validando los datos de entrada.
2. Asignarlas a una persona del equipo (o dejarlas sin asignar).
3. Cambiar su estado entre pendiente, en-curso y hecha.
4. Editar y eliminar tareas existentes.
5. Filtrar por responsable, estado, prioridad o etiqueta.
6. Ordenar por fecha límite, prioridad u horas estimadas.
7. Calcular métricas: carga por persona, porcentaje de avance, tareas vencidas.
8. Mostrar todo en una interfaz web usable.
9. Persistir los datos en el navegador para que no se pierdan al recargar.
10. Sincronizar con una API remota.
11. Probar la aplicación con pruebas automáticas.
12. Optimizar y desplegar la versión final.

Nada de esto se hace de golpe. Cada módulo del curso añade una capa.

Aquí está el corazón del proyecto. Esta tabla es la referencia oficial de todo el curso: cada vez que aparezca una tarea en cualquier lección, tendrá exactamente estos campos con estos tipos.

id es un número, no un texto. Es un identificador correlativo que asigna la aplicación. Al ser numérico, generar el siguiente es trivial.

responsable puede ser null. Aquí aplicamos lo aprendido en Variables y Tipos de Datos: null significa "deliberadamente sin asignar". No usamos '' ni undefined. Una tarea sin responsable es un estado legítimo del negocio: Marta crea la tarea primero y decide quién la hace después.

prioridad y estado son textos de un conjunto cerrado. Podríamos usar números (1, 2, 3), pero 'alta' se lee y se depura infinitamente mejor que 1. El precio es tener que validar que el valor esté entre los permitidos, algo que ya sabes hacer con ===.

etiquetas es siempre un array, nunca null. Si una tarea no tiene etiquetas, el valor es []. Esto es una decisión de diseño importante: garantiza que todo el código posterior pueda hacer tarea.etiquetas.length sin comprobar nada antes. Y recuerda de Conversión de Tipos y Comparaciones: un array vacío es truthy, así que hay que comprobar su longitud, no su existencia.

horasEstimadas admite decimales. Media hora es una unidad razonable (7.5). El máximo de 40 corresponde a una semana laboral completa.

fechaLimite es un string ISO, no un objeto Date. Esta es probablemente la decisión más discutible del proyecto, y está tomada a propósito por tres motivos:

1. Se ordena solo. '2026-09-30' < '2026-11-05' es true, porque el orden alfabético del formato ISO coincide con el cronológico.
2. Se guarda y se transmite sin conversiones. Ni el almacenamiento del navegador ni una API JSON manejan objetos Date: los convierten a texto de todos modos.
3. Evita las trampas de zona horaria, que son numerosas y desagradables para alguien que empieza.

Trabajaremos con fechas como texto durante todo el curso, y solo usaremos objetos Date cuando haya que calcular diferencias entre fechas.

Una tarea recorre siempre este camino:

Solo esas transiciones son válidas. Una tarea no puede pasar directamente de pendiente a hecha: alguien tiene que haberla empezado. Esta regla la implementarás en el Módulo 2, cuando aprendas condicionales.

Este es el objeto que reaparecerá una y otra vez a lo largo del curso. Todavía no has estudiado la sintaxis de objetos —eso es Introducción a los Objetos—, pero puedes leerlo perfectamente: es la agrupación de las mismas ocho variables que ya sabes declarar.

Y este es el mismo conjunto de datos expresado con lo que sí sabes hacer hoy: variables sueltas.

Compara las dos versiones. Con una tarea, las variables sueltas son manejables. Con tres, ya empiezas a numerar variables (titulo1, titulo2, titulo3), lo cual es una señal inequívoca de que falta una estructura. Con cuarenta tareas, sería inviable.

Esa incomodidad es intencionada: la sentirás en el ejercicio final de esta lección, y es exactamente la motivación para los objetos y arrays del Módulo 4.

Además del modelo de datos, el proyecto tiene un conjunto de reglas fijas que se aplicarán durante todo el curso:

Estas reglas aparecerán progresivamente. En este módulo ya has aplicado sin saberlo la R2, la R3 y la R8 al validar el formulario de la lección anterior.

Este diagrama muestra qué parte de Nómada Tareas construye cada módulo y cómo se apoyan unos en otros.

Con más detalle, módulo a módulo:

Un detalle importante sobre cómo leer este mapa: cada módulo reescribe parte de lo anterior con mejores herramientas. Las ocho variables sueltas de hoy se convertirán en un objeto en el Módulo 4 y en una instancia de clase en el Módulo 5. No es que lo de hoy esté mal: es que aprendes el andamiaje antes que el edificio.

En la lección Configuración de tu Entorno de Desarrollo creaste esto:

Así quedará al final del curso:

No hace falta crear nada de esto ahora. Se muestra para que veas hacia dónde vas y entiendas la lógica de la organización: el modelo (qué es una tarea y qué reglas cumple), los datos (de dónde vienen y dónde se guardan), la vista (cómo se muestran) y las utilidades. Esa separación en capas es un principio de diseño que se aplica en proyectos de cualquier tamaño.

Errores comunes al abordar un proyecto largo

• Querer construirlo todo de golpe. El impulso natural es abrir el editor y empezar por la interfaz. No funciona: sin lógica validada detrás, la interfaz solo esconde los problemas.
• Cambiar el modelo de datos sobre la marcha. Si en el Módulo 4 decides llamar owner al responsable, todos los ejemplos posteriores dejarán de encajar. Respeta la tabla del apartado 5 durante todo el curso.
• Saltarse el proyecto y hacer solo los ejercicios sueltos. Lo que consolida el aprendizaje es el hilo: ver cómo el mismo problema se resuelve mejor cada vez que aprendes algo nuevo.
• Usar '' en lugar de null para un responsable sin asignar. Rompe la R8 y provoca comprobaciones inconsistentes por todo el código.
• Guardar las fechas en formato dd/mm/yyyy. Deja de poder ordenarse como texto y complica todo lo demás.
• Frustrarse porque el código de hoy es "primitivo". Ocho variables sueltas para una tarea son incómodas, y deben serlo: esa incomodidad es lo que da sentido a lo que aprenderás después.

Consejos

• Ten esta lección a mano. La tabla del modelo de datos es la referencia que consultarás durante los once módulos.
• Crea una carpeta por módulo dentro del proyecto mientras practicas (practica/modulo-01/), y deja js/ para el código definitivo.
• Haz un commit de Git al terminar cada módulo. Verás tu progreso y podrás volver atrás.
• Cuando aprendas algo nuevo, pregúntate: "¿qué parte de Nómada Tareas mejora esto?" Es la mejor forma de fijar un concepto.
• Inventa tus propias tareas para el equipo de Taller Nómada. Cuanto más juegues con los datos, más natural te resultará el dominio.
• No adelantes materia. Si un módulo posterior te tienta, resiste: el orden está pensado para que cada pieza se apoye en la anterior.

Para cada una de estas tres tareas propuestas, indica qué reglas del modelo de datos o del apartado 7 incumple y cómo la corregirías:

Tarea A

Tarea B

Tarea C

Escribe un script que declare tres tareas de Taller Nómada usando solo lo aprendido en este módulo (variables, tipos, operadores, conversiones, template literals). Nada de objetos, arrays de objetos, funciones ni bucles.

Las tres tareas:

El script debe imprimir:

1. Una cabecera con el nombre del proyecto.
2. Una línea de resumen por tarea con el formato: [1] Rediseñar la sala polivalente · Iván · alta · en-curso · 12 h · vence 2026-09-30
3. El total de horas estimadas del equipo.
4. La media de horas por tarea, redondeada a un decimal.
5. Cuántas tareas son de prioridad alta.
6. La tarea con la fecha límite más próxima (comparando las fechas ISO como texto).
7. Un aviso con console.warn si el total supera las 30 horas.

Responde razonadamente en tres o cuatro líneas cada pregunta:

1. ¿Por qué etiquetas es siempre un array ([] cuando está vacío) en lugar de null? ¿Qué problema evita esa decisión, teniendo en cuenta lo que sabes sobre valores truthy?
2. ¿Qué ventaja concreta aporta guardar fechaLimite como '2026-09-30' en lugar de '30/09/2026'?
3. Al escribir el ejercicio 2 habrás notado una incomodidad. ¿Cuál es exactamente, y qué crees que la resolverá?

Ejercicio 1

Tarea A — incumple siete reglas:

Tarea B — incumple dos reglas:

• horasEstimadas: 55 supera el máximo de 40 (R3). Si el trabajo realmente son 55 horas, hay que partirlo en varias tareas: es lo que la regla pretende forzar.
• etiquetas: ['Taller', 'taller', 'INVENTARIO'] incumple la R9 por partida doble: hay mayúsculas y hay un duplicado ('Taller' y 'taller' son la misma etiqueta una vez normalizadas). Lo correcto sería ['taller', 'inventario'].

Tarea C — es válida. Merece la pena repasar por qué cada campo dudoso está bien:

• responsable: null es correcto: la tarea existe pero aún no se ha asignado (R8).
• etiquetas: [] es correcto: una lista vacía, no null.
• horasEstimadas: 9.5 es correcto: el campo admite decimales y está dentro del rango.
• estado: 'en-curso' con responsable: null es raro desde el punto de vista del negocio (alguien la ha empezado pero no consta quién), pero no incumple ninguna regla escrita. Es justo el tipo de detalle que se descubre construyendo, y que en un proyecto real llevaría a añadir una regla nueva.

Ejercicio 2

Salida:

Técnicas del módulo que aparecen aquí:

• Number(prioridad === 'alta') convierte un booleano a 1 o 0 para poder sumarlos. Es una aplicación directa de la conversión explícita de Conversión de Tipos y Comparaciones.
• Math.round(x * 10) / 10 redondea a un decimal sin usar toFixed, que devolvería un string.
• La comparación de fechas ISO como texto funciona porque el orden alfabético coincide con el cronológico.
• Los ternarios encadenados eligen la fecha menor y su título asociado.
• El cortocircuito && dispara el aviso solo cuando se supera el umbral.

Ejercicio 3

1. ¿Por qué etiquetas es siempre un array?

Porque permite que todo el código posterior trate el campo de la misma forma, sin comprobaciones previas: etiquetas.length funciona siempre, tanto si hay tres etiquetas como si no hay ninguna. Si el valor fuese null cuando está vacío, cada lugar que consultase el campo tendría que preguntar antes si existe, y olvidarlo provocaría un TypeError. Además, como aprendiste en la lección anterior, un array vacío es truthy, de modo que if (etiquetas) no distingue una lista llena de una vacía: la comprobación correcta es siempre etiquetas.length === 0, y esa comprobación solo es posible si el campo es siempre un array.

2. ¿Qué ventaja aporta el formato ISO?

Que su orden alfabético coincide con su orden cronológico, porque los componentes van de mayor a menor magnitud (año, mes, día) y llevan ceros a la izquierda. Eso permite ordenar y comparar fechas con los operadores < y > sin ninguna conversión ni librería, tal y como se hace en el ejercicio 2. Con '30/09/2026' la comparación de texto sería absurda: '30/09/2026' < '15/10/2026' sería false, porque compararía '3' con '1'. El formato ISO también es el estándar internacional, el que usan las APIs JSON y el que espera el campo <input type="date"> del navegador.

3. ¿Qué incomodidad has notado?

Que cada tarea necesita ocho variables numeradas (titulo1, titulo2, titulo3...), y que cualquier cálculo sobre el conjunto —sumar horas, contar prioridades, buscar la más urgente— hay que escribirlo repitiendo manualmente los tres casos. Con tres tareas es tedioso; con cuarenta sería imposible. Faltan dos cosas: una manera de agrupar los ocho campos de una tarea en una sola unidad (los objetos, Módulo 4), una manera de agrupar todas las tareas en una sola colección (los arrays, Módulo 4), y una manera de repetir una operación sobre todas ellas sin copiar y pegar (los bucles, Módulo 2). Esa necesidad, sentida en tus propias manos, es exactamente el motivo por el que existen esas herramientas.

Ya conoces el proyecto completo. Sabes qué es Taller Nómada, cuál es su problema real y qué necesitan Marta, Iván y Lucía de la aplicación. Tienes el modelo de datos canónico de una tarea, con sus ocho campos, sus tipos y sus valores permitidos, y entiendes las decisiones de diseño que hay detrás: por qué responsable puede ser null, por qué etiquetas es siempre un array y por qué fechaLimite es un texto en formato ISO. Conoces las diez reglas de negocio que irás implementando, el ciclo de vida de una tarea, el mapa de qué construye cada módulo y la estructura de ficheros hacia la que avanzas.

Con esto cierras el Módulo 1. Empezaste sin haber escrito una línea de JavaScript y terminas con un entorno de desarrollo montado, un proyecto en marcha y la capacidad de declarar, calcular, convertir y comparar los datos de una tarea real. No es poco.

Pero has terminado el módulo con una frustración muy concreta y muy productiva: puedes describir tres tareas, pero no puedes decidir ni repetir. No sabes hacer que el programa compruebe por sí mismo si una transición de estado es válida, ni recorrer una lista de cuarenta tareas sin escribir cuarenta veces lo mismo. Todo tu código se ejecuta de arriba abajo, en línea recta, sin tomar ni una sola decisión.

Eso cambia en el Módulo 2: Estructuras de Control. Empezarás con Sentencias Condicionales, donde aprenderás a que el programa elija un camino u otro —clasificar la prioridad de una tarea, detectar si está vencida, permitir o rechazar un cambio de estado—, y seguirás con los bucles, que te permitirán aplicar esa lógica a todas las tareas de Taller Nómada de una sola vez. Es el momento en el que tu código deja de ser una lista de instrucciones y empieza a comportarse como un programa.