You have worked through the first seven lessons learning tools: you set up the environment, wrote your first program, and got to know the syntax, the types, the operators and the conversions. Marta, Iván and Lucía turned up in every example, along with a few tasks with a title, a priority and estimated hours. It is time to formally introduce the project that runs through the entire course: what Taller Nómada is, what problem it has, what application you are going to build to solve it, what the canonical data model is that you will use across the eleven modules, and which part you will build in each one. This lesson is the map of the whole journey.

1. Taller Nómada: the context
2. The problem to be solved
3. The team: Marta, Iván and Lucía
4. What Nómada Tasks will do
5. The canonical data model of a task
6. The reference example object
7. The project's business rules
8. Course map: what each module builds
9. The file structure that will keep growing
10. Common Mistakes and Tips
11. Exercises
12. Conclusion

Taller Nómada is a small coworking space and creative workshop housed in a refurbished warehouse. It is a completely fictional company, created for this course, with equally fictional data.

Its business has two legs:

• Coworking: twelve permanent desks and a multipurpose room rented out by the hour for meetings and presentations.
• Creative workshop: a space equipped for screen printing, bookbinding and light carpentry, where courses are taught and residents' projects are hosted.

The business works, but internal management does not. And that is our starting point.

Today, work at Taller Nómada is organized like this:

• A wall of sticky notes with the tasks in progress.
• A messaging group where things get agreed and nobody writes them down.
• A shared spreadsheet that nobody has updated since March.

The consequences are exactly what you would expect:

What they need is not a corporate tool with a thousand options. They need something small, fast and theirs: a shared task list that shows who is doing what, with what priority and by when.

That is Nómada Tasks, and you are the one who is going to build it.

Three people who will be the cast of every example and exercise in the course.

Their needs are not the same, and that is deliberate: it will force you to think about filters, sorting and different views over the same data.

The full scope of the application, in roughly the order it will be built:

1. Creating tasks with all their fields, validating the input data.
2. Assigning them to someone on the team (or leaving them unassigned).
3. Changing their status between pending, in-progress and done.
4. Editing and deleting existing tasks.
5. Filtering by assignee, status, priority or tag.
6. Sorting by due date, priority or estimated hours.
7. Calculating metrics: workload per person, progress percentage, overdue tasks.
8. Displaying everything in a usable web interface.
9. Persisting the data in the browser so it is not lost on reload.
10. Synchronizing with a remote API.
11. Testing the application with automated tests.
12. Optimizing and deploying the final version.

None of this happens in one go. Each module of the course adds a layer.

Here is the heart of the project. This table is the official reference for the whole course: every time a task appears in any lesson, it will have exactly these fields with these types.

id is a number, not text. It is a sequential identifier assigned by the application. Being numeric, generating the next one is trivial.

assignee can be null. Here we apply what we learned in Variables and Data Types: null means "deliberately unassigned". We do not use '' or undefined. A task with no assignee is a legitimate business state: Marta creates the task first and decides who does it afterwards.

priority and status are strings from a closed set. We could use numbers (1, 2, 3), but 'high' reads and debugs infinitely better than 1. The price is having to validate that the value is one of the allowed ones, something you already know how to do with ===.

tags is always an array, never null. If a task has no tags, the value is []. This is an important design decision: it guarantees that all the code downstream can do task.tags.length without checking anything first. And remember from Type Conversion and Comparisons: an empty array is truthy, so you have to check its length, not its existence.

estimatedHours allows decimals. Half an hour is a reasonable unit (7.5). The maximum of 40 corresponds to a full working week.

dueDate is an ISO string, not a Date object. This is probably the most debatable decision in the project, and it is deliberate for three reasons:

1. It sorts itself. '2026-09-30' < '2026-11-05' is true, because the alphabetical order of the ISO format matches the chronological order.
2. It is stored and transmitted without conversions. Neither browser storage nor a JSON API handles Date objects: they turn them into text anyway.
3. It avoids time-zone traps, which are numerous and unpleasant for someone starting out.

We will work with dates as text throughout the course, and we will only use Date objects when we need to calculate differences between dates.

A task always follows this path:

Only those transitions are valid. A task cannot go straight from pending to done: someone has to have started it. You will implement this rule in Module 2, when you learn about conditionals.

This is the object that will come back again and again throughout the course. You have not studied object syntax yet —that is Introduction to Objects— but you can read it perfectly well: it is a grouping of the same eight variables you already know how to declare.

And here is the same set of data expressed with what you can do today: separate variables.

Compare the two versions. With one task, separate variables are manageable. With three, you are already numbering your variables (title1, title2, title3), which is an unmistakable sign that a structure is missing. With forty tasks, it would be unworkable.

That discomfort is intentional: you will feel it in the final exercise of this lesson, and it is exactly the motivation for the objects and arrays of Module 4.

Beyond the data model, the project has a set of fixed rules that will apply throughout the course:

These rules will appear progressively. In this module you have already applied R2, R3 and R8 without knowing it, when you validated the form in the previous lesson.

This diagram shows which part of Nómada Tasks each module builds and how they lean on one another.

In more detail, module by module:

One important note on how to read this map: each module rewrites part of the previous work with better tools. Today's eight separate variables will become an object in Module 4 and a class instance in Module 5. It is not that today's approach is wrong: it is that you learn the scaffolding before the building.

In the lesson Setting Up Your Development Environment you created this:

This is how it will look by the end of the course:

You do not need to create any of this now. It is shown so that you can see where you are heading and understand the logic of the organization: the model (what a task is and what rules it obeys), the data (where it comes from and where it is stored), the view (how it is displayed) and the utilities. That separation into layers is a design principle that applies to projects of any size.

Common mistakes when tackling a long project

• Wanting to build it all at once. The natural impulse is to open the editor and start with the interface. It does not work: without validated logic behind it, the interface only hides the problems.
• Changing the data model as you go. If in Module 4 you decide to call assignee owner, none of the later examples will fit any more. Stick to the table in section 5 throughout the course.
• Skipping the project and doing only the standalone exercises. What consolidates the learning is the thread: seeing the same problem solved better every time you learn something new.
• Using '' instead of null for an unassigned task. It breaks R8 and leads to inconsistent checks all over the code.
• Storing dates in dd/mm/yyyy format. They can no longer be sorted as text and everything else gets harder.
• Getting frustrated because today's code is "primitive". Eight separate variables for one task are awkward, and they are meant to be: that awkwardness is what gives meaning to what you will learn next.

Tips

• Keep this lesson handy. The data model table is the reference you will come back to across all eleven modules.
• Create a folder per module inside the project while you practice (practice/module-01/), and keep js/ for the final code.
• Make a Git commit at the end of each module. You will see your progress and be able to go back.
• Whenever you learn something new, ask yourself: "which part of Nómada Tasks does this improve?" It is the best way to make a concept stick.
• Invent your own tasks for the Taller Nómada team. The more you play with the data, the more natural the domain will feel.
• Do not run ahead. If a later module tempts you, resist: the order is designed so that each piece rests on the previous one.

For each of these three proposed tasks, state which rules of the data model or of section 7 it breaks and how you would fix it:

Task A

Task B

Task C

Write a script that declares three Taller Nómada tasks using only what you have learned in this module (variables, types, operators, conversions, template literals). No objects, no arrays of objects, no functions and no loops.

The three tasks:

The script has to print:

1. A header with the name of the project.
2. One summary line per task in this format: [1] Redesign the multipurpose room · Iván · high · in-progress · 12 h · due 2026-09-30
3. The team's total estimated hours.
4. The average hours per task, rounded to one decimal place.
5. How many tasks are high priority.
6. The task with the nearest due date (comparing the ISO dates as text).
7. A warning with console.warn if the total exceeds 30 hours.

Answer each question with reasoning, in three or four lines:

1. Why is tags always an array ([] when it is empty) instead of null? What problem does that decision avoid, given what you know about truthy values?
2. What concrete advantage does storing dueDate as '2026-09-30' give over '30/09/2026'?
3. While writing exercise 2 you will have felt a certain awkwardness. What exactly is it, and what do you think will solve it?

Exercise 1

Task A — breaks seven rules:

Task B — breaks two rules:

• estimatedHours: 55 exceeds the maximum of 40 (R3). If the work really is 55 hours, it has to be split into several tasks: that is exactly what the rule is designed to force.
• tags: ['Workshop', 'workshop', 'INVENTORY'] breaks R9 twice over: there is uppercase and there is a duplicate ('Workshop' and 'workshop' are the same tag once normalized). The correct value would be ['workshop', 'inventory'].

Task C — it is valid. It is worth going over why each questionable field is fine:

• assignee: null is correct: the task exists but has not been assigned yet (R8).
• tags: [] is correct: an empty list, not null.
• estimatedHours: 9.5 is correct: the field allows decimals and this is within range.
• status: 'in-progress' with assignee: null is odd from a business point of view (someone has started it but there is no record of who), yet it breaks no written rule. It is exactly the kind of detail you discover while building, and that in a real project would lead to adding a new rule.

Exercise 2

Output:

Techniques from this module that show up here:

• Number(priority === 'high') converts a boolean into 1 or 0 so the results can be added up. It is a direct application of the explicit conversion from Type Conversion and Comparisons.
• Math.round(x * 10) / 10 rounds to one decimal without using toFixed, which would return a string.
• Comparing ISO dates as text works because alphabetical order matches chronological order.
• The chained ternaries pick the earliest date and its associated title.
• The && short-circuit fires the warning only when the threshold is exceeded.

Exercise 3

1. Why is tags always an array?

Because it lets all the downstream code treat the field the same way, with no preliminary checks: tags.length always works, whether there are three tags or none at all. If the value were null when empty, every place that read the field would first have to ask whether it exists, and forgetting to do so would cause a TypeError. On top of that, as you learned in the previous lesson, an empty array is truthy, so if (tags) does not tell a full list apart from an empty one: the correct check is always tags.length === 0, and that check is only possible if the field is always an array.

2. What advantage does the ISO format give?

That its alphabetical order matches its chronological order, because the components go from largest to smallest magnitude (year, month, day) and are zero-padded. That lets you sort and compare dates with the < and > operators without any conversion or library, exactly as done in exercise 2. With '30/09/2026' the text comparison would be nonsense: '30/09/2026' < '15/10/2026' would be false, because it would be comparing '3' with '1'. The ISO format is also the international standard, the one JSON APIs use and the one the browser's <input type="date"> field expects.

3. What awkwardness did you feel?

That each task needs eight numbered variables (title1, title2, title3...), and that any calculation over the whole set —adding up hours, counting priorities, finding the most urgent— has to be written by manually repeating all three cases. With three tasks it is tedious; with forty it would be impossible. Two things are missing: a way to group a task's eight fields into a single unit (objects, Module 4), a way to group all the tasks into a single collection (arrays, Module 4), and a way to repeat an operation over all of them without copy-pasting (loops, Module 2). That need, felt first-hand, is exactly why those tools exist.

You now know the whole project. You know what Taller Nómada is, what its real problem is and what Marta, Iván and Lucía need from the application. You have the canonical data model of a task, with its eight fields, its types and its allowed values, and you understand the design decisions behind it: why assignee can be null, why tags is always an array and why dueDate is text in ISO format. You know the ten business rules you will implement along the way, the life cycle of a task, the map of what each module builds and the file structure you are working toward.

With that, you close Module 1. You started without having written a single line of JavaScript and you finish with a development environment set up, a project underway and the ability to declare, calculate, convert and compare the data of a real task. That is no small thing.

But you have finished the module with a very specific and very productive frustration: you can describe three tasks, but you cannot decide or repeat. You do not know how to make the program check for itself whether a status transition is valid, nor how to go through a list of forty tasks without writing the same thing forty times. All your code runs top to bottom, in a straight line, without making a single decision.

That changes in Module 2: Control Structures. You will start with Conditional Statements, where you will learn to make the program pick one path or another —classifying a task's priority, detecting whether it is overdue, allowing or rejecting a status change—, and you will move on to loops, which will let you apply that logic to all of Taller Nómada's tasks at once. It is the moment when your code stops being a list of instructions and starts behaving like a program.