Has recorregut les set primeres lliçons aprenent eines: vas muntar l'entorn, vas escriure el teu primer programa, vas conèixer la sintaxi, els tipus, els operadors i les conversions. A cada exemple hi apareixien la Marta, l'Iván i la Lucía, i unes tasques amb títol, prioritat i hores estimades. Ha arribat el moment de presentar formalment el projecte que travessa tot el curs: què és Taller Nómada, quin problema té, quina aplicació construiràs per resoldre'l, quin és el model de dades canònic que faràs servir durant els onze mòduls i quina part construiràs a cadascun. Aquesta lliçó és el mapa del viatge complet.

1. Taller Nómada: el context
2. El problema que cal resoldre
3. L'equip: Marta, Iván i Lucía
4. Què farà Nómada Tasques
5. El model de dades canònic d'una tasca
6. L'objecte d'exemple de referència
7. Regles de negoci del projecte
8. Mapa del curs: què construeix cada mòdul
9. L'estructura de fitxers que anirà creixent
10. Errors Habituals i Consells
11. Exercicis
12. Conclusió

Taller Nómada és un petit espai de coworking i taller creatiu situat en una nau rehabilitada. És una empresa completament fictícia, creada per a aquest curs, amb dades igualment fictícies.

La seva activitat té dues potes:

• Coworking: dotze llocs de treball fixos i una sala polivalent que es lloga per hores per a reunions i presentacions.
• Taller creatiu: un espai amb equipament de serigrafia, enquadernació i petita fusteria, on s'imparteixen cursos i s'acullen projectes de residents.

El negoci funciona, però la gestió interna no. I aquest és el punt de partida.

Avui, la feina de Taller Nómada s'organitza així:

• Una paret de notes adhesives amb les tasques en curs.
• Un grup de missatgeria on s'acorden coses que ningú no apunta.
• Un full de càlcul compartit que ningú no actualitza des del març.

Les conseqüències són les esperables:

El que necessiten no és una eina corporativa amb mil opcions. Necessiten una cosa petita, ràpida i seva: una llista de tasques compartida on es vegi qui fa què, amb quina prioritat i per a quan.

Això és Nómada Tasques, i el construiràs tu.

Tres persones que seran les protagonistes de tots els exemples i exercicis del curs.

Les seves necessitats no són iguals, i això és deliberat: t'obligarà a pensar en filtres, ordenacions i vistes diferents sobre les mateixes dades.

L'abast complet de l'aplicació, en ordre aproximat de construcció:

1. Crear tasques amb tots els seus camps, validant les dades d'entrada.
2. Assignar-les a una persona de l'equip (o deixar-les sense assignar).
3. Canviar-ne l'estat entre pendent, en-curs i feta.
4. Editar i eliminar tasques existents.
5. Filtrar per responsable, estat, prioritat o etiqueta.
6. Ordenar per data límit, prioritat o hores estimades.
7. Calcular mètriques: càrrega per persona, percentatge d'avenç, tasques vençudes.
8. Mostrar tot plegat en una interfície web usable.
9. Persistir les dades al navegador perquè no es perdin en recarregar.
10. Sincronitzar amb una API remota.
11. Provar l'aplicació amb proves automàtiques.
12. Optimitzar i desplegar la versió final.

Res d'això es fa de cop. Cada mòdul del curs hi afegeix una capa.

Aquí hi ha el cor del projecte. Aquesta taula és la referència oficial de tot el curs: cada vegada que aparegui una tasca en qualsevol lliçó, tindrà exactament aquests camps amb aquests tipus.

L'id és un nombre, no un text. És un identificador correlatiu que assigna l'aplicació. Com que és numèric, generar el següent és trivial.

responsable pot ser null. Aquí apliquem el que hem après a Variables i Tipus de Dades: null significa "deliberadament sense assignar". No fem servir '' ni undefined. Una tasca sense responsable és un estat legítim del negoci: la Marta crea la tasca primer i decideix qui la fa després.

prioritat i estat són textos d'un conjunt tancat. Podríem fer servir nombres (1, 2, 3), però 'alta' es llegeix i es depura infinitament millor que 1. El preu és haver de validar que el valor sigui entre els permesos, cosa que ja saps fer amb ===.

etiquetes és sempre un array, mai null. Si una tasca no té etiquetes, el valor és []. Aquesta és una decisió de disseny important: garanteix que tot el codi posterior pugui fer tasca.etiquetes.length sense comprovar res abans. I recorda de Conversió de Tipus i Comparacions: un array buit és truthy, així que cal comprovar-ne la longitud, no l'existència.

horesEstimades admet decimals. Mitja hora és una unitat raonable (7.5). El màxim de 40 correspon a una setmana laboral completa.

dataLimit és un string ISO, no un objecte Date. Aquesta és probablement la decisió més discutible del projecte, i està presa a propòsit per tres motius:

1. S'ordena sola. '2026-09-30' < '2026-11-05' és true, perquè l'ordre alfabètic del format ISO coincideix amb el cronològic.
2. Es desa i es transmet sense conversions. Ni l'emmagatzematge del navegador ni una API JSON manegen objectes Date: els converteixen a text de totes maneres.
3. Evita els paranys de zona horària, que són nombrosos i desagradables per a algú que comença.

Treballarem amb dates com a text durant tot el curs, i només farem servir objectes Date quan calgui calcular diferències entre dates.

Una tasca recorre sempre aquest camí:

Només aquestes transicions són vàlides. Una tasca no pot passar directament de pendent a feta: algú l'ha d'haver començada. Aquesta regla la implementaràs al Mòdul 2, quan aprenguis condicionals.

Aquest és l'objecte que reapareixerà una vegada i una altra al llarg del curs. Encara no has estudiat la sintaxi d'objectes —això és Introducció als Objectes—, però el pots llegir perfectament: és l'agrupació de les mateixes vuit variables que ja saps declarar.

I aquest és el mateix conjunt de dades expressat amb el que sí que saps fer avui: variables soltes.

Compara les dues versions. Amb una tasca, les variables soltes són manejables. Amb tres, ja comences a numerar variables (titol1, titol2, titol3), cosa que és un senyal inequívoc que falta una estructura. Amb quaranta tasques, seria inviable.

Aquesta incomoditat és intencionada: la sentiràs a l'exercici final d'aquesta lliçó, i és exactament la motivació dels objectes i arrays del Mòdul 4.

A més del model de dades, el projecte té un conjunt de regles fixes que s'aplicaran durant tot el curs:

Aquestes regles apareixeran progressivament. En aquest mòdul ja has aplicat sense saber-ho la R2, la R3 i la R8 en validar el formulari de la lliçó anterior.

Aquest diagrama mostra quina part de Nómada Tasques construeix cada mòdul i com es donen suport els uns als altres.

Amb més detall, mòdul a mòdul:

Un detall important sobre com llegir aquest mapa: cada mòdul reescriu part de l'anterior amb millors eines. Les vuit variables soltes d'avui es convertiran en un objecte al Mòdul 4 i en una instància de classe al Mòdul 5. No és que el d'avui estigui malament: és que aprens la bastida abans que l'edifici.

A la lliçó Configuració del teu Entorn de Desenvolupament vas crear això:

Així quedarà al final del curs:

No cal crear res d'això ara. Es mostra perquè vegis cap a on vas i entenguis la lògica de l'organització: el model (què és una tasca i quines regles compleix), les dades (d'on vénen i on es desen), la vista (com es mostren) i les utilitats. Aquesta separació en capes és un principi de disseny que s'aplica en projectes de qualsevol mida.

Errors habituals en abordar un projecte llarg

• Voler construir-ho tot de cop. L'impuls natural és obrir l'editor i començar per la interfície. No funciona: sense lògica validada al darrere, la interfície només amaga els problemes.
• Canviar el model de dades sobre la marxa. Si al Mòdul 4 decideixes anomenar owner el responsable, tots els exemples posteriors deixaran d'encaixar. Respecta la taula de l'apartat 5 durant tot el curs.
• Saltar-se el projecte i fer només els exercicis solts. El que consolida l'aprenentatge és el fil: veure com el mateix problema es resol millor cada vegada que aprens alguna cosa nova.
• Fer servir '' en lloc de null per a un responsable sense assignar. Trenca la R8 i provoca comprovacions incoherents per tot el codi.
• Desar les dates en format dd/mm/yyyy. Deixen de poder ordenar-se com a text i ho compliquen tot.
• Frustrar-se perquè el codi d'avui és "primitiu". Vuit variables soltes per a una tasca són incòmodes, i han de ser-ho: aquesta incomoditat és el que dona sentit al que aprendràs després.

Consells

• Tingues aquesta lliçó a mà. La taula del model de dades és la referència que consultaràs durant els onze mòduls.
• Crea una carpeta per mòdul dins del projecte mentre practiques (practica/modul-01/), i deixa js/ per al codi definitiu.
• Fes un commit de Git en acabar cada mòdul. Veuràs el teu progrés i podràs tornar enrere.
• Quan aprenguis alguna cosa nova, pregunta't: "quina part de Nómada Tasques millora això?" És la millor manera de fixar un concepte.
• Inventa les teves pròpies tasques per a l'equip de Taller Nómada. Com més juguis amb les dades, més natural et resultarà el domini.
• No avancis matèria. Si un mòdul posterior et tempta, resisteix: l'ordre està pensat perquè cada peça es recolzi en l'anterior.

Per a cadascuna d'aquestes tres tasques proposades, indica quines regles del model de dades o de l'apartat 7 incompleix i com la corregiries:

Tasca A

Tasca B

Tasca C

Escriu un script que declari tres tasques de Taller Nómada fent servir només el que has après en aquest mòdul (variables, tipus, operadors, conversions, template literals). Res d'objectes, arrays d'objectes, funcions ni bucles.

Les tres tasques:

L'script ha d'imprimir:

1. Una capçalera amb el nom del projecte.
2. Una línia de resum per tasca amb el format: [1] Redissenyar la sala polivalent · Iván · alta · en-curs · 12 h · venç 2026-09-30
3. El total d'hores estimades de l'equip.
4. La mitjana d'hores per tasca, arrodonida a un decimal.
5. Quantes tasques són de prioritat alta.
6. La tasca amb la data límit més propera (comparant les dates ISO com a text).
7. Un avís amb console.warn si el total supera les 30 hores.

Respon raonadament en tres o quatre línies cada pregunta:

1. Per què etiquetes és sempre un array ([] quan està buit) en lloc de null? Quin problema evita aquesta decisió, tenint en compte el que saps sobre valors truthy?
2. Quin avantatge concret aporta desar dataLimit com a '2026-09-30' en lloc de '30/09/2026'?
3. En escriure l'exercici 2 hauràs notat una incomoditat. Quina és exactament, i què creus que la resoldrà?

Exercici 1

Tasca A — incompleix set regles:

Tasca B — incompleix dues regles:

• horesEstimades: 55 supera el màxim de 40 (R3). Si la feina són realment 55 hores, cal partir-la en diverses tasques: és el que la regla pretén forçar.
• etiquetes: ['Taller', 'taller', 'INVENTARI'] incompleix la R9 per partida doble: hi ha majúscules i hi ha un duplicat ('Taller' i 'taller' són la mateixa etiqueta un cop normalitzades). El correcte seria ['taller', 'inventari'].

Tasca C — és vàlida. Val la pena repassar per què cada camp dubtós està bé:

• responsable: null és correcte: la tasca existeix però encara no s'ha assignat (R8).
• etiquetes: [] és correcte: una llista buida, no null.
• horesEstimades: 9.5 és correcte: el camp admet decimals i és dins del rang.
• estat: 'en-curs' amb responsable: null és estrany des del punt de vista del negoci (algú l'ha començada però no consta qui), però no incompleix cap regla escrita. És just el tipus de detall que es descobreix construint, i que en un projecte real portaria a afegir una regla nova.

Exercici 2

Sortida:

Tècniques del mòdul que apareixen aquí:

• Number(prioritat === 'alta') converteix un booleà a 1 o 0 per poder sumar-los. És una aplicació directa de la conversió explícita de Conversió de Tipus i Comparacions.
• Math.round(x * 10) / 10 arrodoneix a un decimal sense fer servir toFixed, que retornaria un string.
• La comparació de dates ISO com a text funciona perquè l'ordre alfabètic coincideix amb el cronològic.
• Els ternaris encadenats trien la data menor i el títol associat.
• El curtcircuit && dispara l'avís només quan se supera el llindar.

Exercici 3

1. Per què etiquetes és sempre un array?

Perquè permet que tot el codi posterior tracti el camp de la mateixa manera, sense comprovacions prèvies: etiquetes.length funciona sempre, tant si hi ha tres etiquetes com si no n'hi ha cap. Si el valor fos null quan està buit, cada lloc que consultés el camp hauria de preguntar abans si existeix, i oblidar-ho provocaria un TypeError. A més, com vas aprendre a la lliçó anterior, un array buit és truthy, de manera que if (etiquetes) no distingeix una llista plena d'una de buida: la comprovació correcta és sempre etiquetes.length === 0, i aquesta comprovació només és possible si el camp és sempre un array.

2. Quin avantatge aporta el format ISO?

Que el seu ordre alfabètic coincideix amb el seu ordre cronològic, perquè els components van de més a menys magnitud (any, mes, dia) i porten zeros a l'esquerra. Això permet ordenar i comparar dates amb els operadors < i > sense cap conversió ni llibreria, tal com es fa a l'exercici 2. Amb '30/09/2026' la comparació de text seria absurda: '30/09/2026' < '15/10/2026' seria false, perquè compararia '3' amb '1'. El format ISO també és l'estàndard internacional, el que fan servir les APIs JSON i el que espera el camp <input type="date"> del navegador.

3. Quina incomoditat has notat?

Que cada tasca necessita vuit variables numerades (titol1, titol2, titol3...), i que qualsevol càlcul sobre el conjunt —sumar hores, comptar prioritats, buscar la més urgent— cal escriure'l repetint manualment els tres casos. Amb tres tasques és tediós; amb quaranta seria impossible. Falten dues coses: una manera d'agrupar els vuit camps d'una tasca en una sola unitat (els objectes, Mòdul 4), una manera d'agrupar totes les tasques en una sola col·lecció (els arrays, Mòdul 4), i una manera de repetir una operació sobre totes elles sense copiar i enganxar (els bucles, Mòdul 2). Aquesta necessitat, sentida amb les teves pròpies mans, és exactament el motiu pel qual existeixen aquestes eines.

Ja coneixes el projecte complet. Saps què és Taller Nómada, quin és el seu problema real i què necessiten la Marta, l'Iván i la Lucía de l'aplicació. Tens el model de dades canònic d'una tasca, amb els seus vuit camps, els seus tipus i els seus valors permesos, i entens les decisions de disseny que hi ha al darrere: per què responsable pot ser null, per què etiquetes és sempre un array i per què dataLimit és un text en format ISO. Coneixes les deu regles de negoci que aniràs implementant, el cicle de vida d'una tasca, el mapa del que construeix cada mòdul i l'estructura de fitxers cap a la qual avances.

Amb això tanques el Mòdul 1. Vas començar sense haver escrit ni una línia de JavaScript i acabes amb un entorn de desenvolupament muntat, un projecte en marxa i la capacitat de declarar, calcular, convertir i comparar les dades d'una tasca real. No és poc.

Però has acabat el mòdul amb una frustració molt concreta i molt productiva: pots descriure tres tasques, però no pots decidir ni repetir. No saps fer que el programa comprovi per si mateix si una transició d'estat és vàlida, ni recórrer una llista de quaranta tasques sense escriure quaranta vegades el mateix. Tot el teu codi s'executa de dalt a baix, en línia recta, sense prendre ni una sola decisió.

Això canvia al Mòdul 2: Estructures de Control. Començaràs amb Sentències Condicionals, on aprendràs a fer que el programa triï un camí o un altre —classificar la prioritat d'una tasca, detectar si està vençuda, permetre o rebutjar un canvi d'estat—, i continuaràs amb els bucles, que et permetran aplicar aquesta lògica a totes les tasques de Taller Nómada d'una sola vegada. És el moment en què el teu codi deixa de ser una llista d'instruccions i comença a comportar-se com un programa.