The final lesson of the course. You have the books, the courses and the communities; what remains is the most tangible piece: the working environment. A machine learning practitioner is only as productive as their workshop: where they write code, how they manage environments and experiments, where they get data to practice with, and what they do when their laptop runs out of steam. In this lesson we set up that workshop with real, well-established tools — many of which you have already touched during the course — and, at the end, we do what a final lesson should: look back, walk the full road from the first module to here, and say goodbye.

1. Notebooks: Jupyter, JupyterLab and Google Colab
2. The editor: VS Code with Python and Jupyter
3. Environments and versioning: venv/conda, Git, DVC and MLflow
4. Experimentation: Optuna and Weights & Biases
5. AutoML: what it is and what to expect from it
6. Public datasets for practice
7. Hardware: when you need a GPU, and cloud alternatives
8. Summary table: tool, use and cost
9. The full journey: course recap
10. Conclusion and farewell

The notebook is the lab journal of ML, and you have used it throughout the course:

• Jupyter Notebook / JupyterLab (jupyter.org): the reference local tool. JupyterLab is the evolution of the classic Notebook: the same idea (cells of code, text and plots) with a full-environment interface — tabs, file explorer, terminals. Cost: free and open source.
• Google Colab (colab.research.google.com): Jupyter notebooks in the browser, nothing to install, with the course's libraries preinstalled and — its trump card — a free GPU (with time and availability limits; paid plans expand the resources). Cost: free at its base tier.

When to use which?

The notebook is ideal for exploring, but when the code matures — reusable functions, tests, the FastAPI service from module 8 — you need a real editor:

• Visual Studio Code (code.visualstudio.com): free, cross-platform and the most widely used editor in the Python ecosystem. With two official extensions it becomes a complete data environment: the Python extension (autocompletion, debugger, interpreter/environment selection) and the Jupyter extension, which lets you open and run notebooks inside the editor itself: the best of both worlds.
• The professional flow we sketched in module 8: explore in a notebook, consolidate into .py files, version with Git. VS Code covers all three phases without switching windows.
• An alternative worth mentioning: PyCharm (JetBrains), with a free Community edition, preferred by those who want a heavier, more complete IDE from the start.

A recap and extension of what we set up in module 8:

• Virtual environments (venv / conda): as we saw in 08-01, every project should have its own isolated environment with its exact library versions. venv + pip (the Python standard) covers most cases; conda adds management of non-Python packages and is popular in data science. Pick one and be consistent; the requirements.txt (or environment.yml) always goes into the repository.
• Git and GitHub: version control for code is not optional. Every project of yours — including those from module 9 — should live in a repository with small, descriptive commits. Beyond history, GitHub is your portfolio (previous lesson).
• DVC (dvc.org): Git versions code, but large datasets and models do not fit in Git. DVC (Data Version Control), which we mentioned in 08-03, extends the Git workflow to data and models: it versions which data produced which model. Free and open source. Note it down for the day one of your projects hits the "which version of the CSV did I train this on?" problem.
• MLflow (mlflow.org): a registry for experiments, models and their lifecycle, also mentioned in module 8. Free and open source. Its minimal use case — logging each experiment's parameters and metrics instead of keeping them in a spreadsheet — already justifies learning it.

• Optuna (optuna.org): you used it in 07-05 for hyperparameter search. It deserves a permanent place in your toolbox: its Bayesian search with pruning of bad trials saves hours compared to a blind grid search, and it integrates with scikit-learn, XGBoost, LightGBM and Keras. Free and open source.
• Weights & Biases (wandb.ai): an experiment-tracking platform widely adopted in deep learning: it logs metrics, plots and models for every run and presents them in shareable web dashboards. It has a free plan for personal use. It is the "managed service" alternative to self-hosted MLflow; knowing one of the two is enough at the start.

AutoML automates parts of the workflow you have learned: trying algorithms, preprocessing steps and hyperparameters and keeping the best combination. auto-sklearn is the academic reference example on our stack: you hand it the data and a time budget and it explores scikit-learn configurations for you.

An honest perspective:

• What it does well: quickly establishing a strong baseline ("what performance is achievable here?") and saving mechanical search.
• What it does not do: understand the business problem, detect data leakage (module 6), design features with domain knowledge (the MercaFresh RFM features from module 3) or answer for the ethical implications (08-04). Precisely the parts where you add value.
• Bottom line: AutoML does not replace you; it automates what this course taught you to do by hand — and precisely because you have done it by hand, you can use it with judgment and know when to be suspicious.

Everything above needs raw material. Well-established sources of data for your projects:

• Kaggle Datasets (kaggle.com/datasets): thousands of datasets across every domain, with other users' notebooks as starting points.
• UCI Machine Learning Repository (archive.ics.uci.edu): the classic academic repository — many of ML's historic datasets (Iris, Wine, Adult...) live here.
• Open data from Spanish public administrations: the national portal datos.gob.es aggregates public-sector data (transport, census, budgets...), and city councils such as Madrid and Barcelona run their own open data portals. In Spanish — an option if you also read Spanish or work in that context. The advantage is double: you practice with data from a real-world setting, and the resulting projects are more original in your portfolio than yet another Titanic.
• The generators in sklearn.datasets (which we used in several lessons) also remain useful for controlled experiments.

A frequent question at the end of a course like this: "should I buy a GPU?". Short answer: probably not yet.

• You do not need a GPU for: all the classical ML in this course (scikit-learn does not use the GPU), XGBoost/LightGBM on medium-sized tabular datasets, and in general modules 1 through 8. A modern laptop with 16 GB of RAM is more than enough.
• A GPU helps (or is required) for: serious deep learning — training CNNs on many images (09-02), large NLP models, fine-tuning pretrained models.
• Alternatives before buying: Google Colab (free GPU with limits; paid for more), Kaggle Notebooks (also offers a free GPU with a weekly quota) and, for bigger needs, GPU instances from the cloud providers (AWS, Google Cloud, Azure) paid by the hour. The economic rule: rent until the recurring spend justifies buying.

Before saying goodbye, it is worth looking back at the road travelled, with MercaFresh, our online supermarket, as travel companion:

• Module 1: we started from zero: what machine learning is, its types (supervised, unsupervised, reinforcement) and the workflow we would then repeat again and again.
• Module 2: we built the statistical foundation — distributions, correlation, probability — to be able to reason about data, not just run code.
• Module 3: we learned that real data arrives dirty: cleaning, encoding, scaling, the RFM features for MercaFresh's customers and the pipelines that make it all reproducible.
• Module 4: supervised learning: from linear regression to neural networks, by way of logistic regression, trees, SVM, K-NN and Naive Bayes, predicting everything from sales to customer churn.
• Module 5: unsupervised learning: K-means and hierarchical clustering to segment customers, PCA to reduce dimensions, DBSCAN and t-SNE/UMAP to see what cannot otherwise be seen.
• Module 6: the module that separates the amateur from the professional: evaluating honestly — data splitting, metrics, cross-validation, ROC/AUC and the fight against overfitting.
• Module 7: we raised the bar: regularization, ensembles, gradient boosting with XGBoost and LightGBM, deep learning with Keras and systematic hyperparameter tuning with Optuna.
• Module 8: we took the models out of the notebook: serialization with joblib, APIs with FastAPI, Docker containers, drift monitoring and the ethical and legal obligations (GDPR) of putting a model in front of real people.
• Module 9: five complete projects from start to finish — housing prices, images with CNNs, sentiment with NLP, fraud with imbalanced classes and customer segmentation — where everything above met reality.
• Module 10: and this final map: books, courses, communities and tools so that the learning does not stop here.

If on day one someone had shown you the last code cell of the fraud project, it would have looked like a foreign language. Today you read it naturally. That is the journey.

• Mistake: chasing tools instead of projects. Installing MLflow, DVC, W&B and three editors in the same week is procrastination dressed up as productivity. Adopt each tool when a real project hurts without it: DVC when you lose track of a dataset, MLflow when your experiments no longer fit in your head.
• Mistake: buying hardware before you need it. Months of free Colab and Kaggle stand between your current situation and the first justified GPU.
• Mistake: staying in the notebook forever. If a piece of code is going to be reused or deployed, migrate it to .py with Git, as you practiced in module 8. The eternal 200-cell notebook is technical debt.
• Tip: automate your project setup. Keep a project template (folder structure, base requirements.txt, a .gitignore for data) and clone it for every new project: you will be up and running in minutes, with good practices built in.
• Tip: overhaul your workshop once a year, not every week. The tools in this lesson are stable; the weekly fashions in new tooling rarely survive. Your judgment, not novelty, decides what enters your workflow.

Configure a professional environment for a new project from scratch: create a folder with a virtual environment (venv or conda), install scikit-learn, pandas and jupyterlab, generate the requirements.txt, initialize a Git repository with a .gitignore that excludes data and the environment, and verify that you can open both JupyterLab and VS Code on that same environment.

Open Google Colab, create a notebook, switch the runtime to GPU and check from code that it is available (for example, with TensorFlow's tf.config.list_physical_devices('GPU')). Then upload or load a small dataset and train any scikit-learn model to verify the full workflow in the cloud.

Browse datos.gob.es (or your own city's or country's open data portal) and pick a dataset that interests you. Define, in one paragraph, a complete ML project around it: the business question, the type of problem (supervised? clustering?), an appropriate evaluation metric, and which tools from this lesson you would use at each stage. This is your plan for the first week after this course.

Exercise 1 (guideline): the minimal sequence on Linux/macOS: python -m venv .venv, source .venv/bin/activate, pip install scikit-learn pandas jupyterlab, pip freeze > requirements.txt, git init and a .gitignore with at least .venv/, data/ and .ipynb_checkpoints/. In VS Code, select the .venv interpreter (command palette, "Python: Select Interpreter"). If JupyterLab starts and VS Code runs a notebook against the same environment, the workshop is operational: save this recipe as your template.

Exercise 2 (guideline): in Colab: menu Runtime → Change runtime type → GPU. The check should list at least one GPU device. The scikit-learn model will not use the GPU (and that is fine: it is the practical demonstration of the hardware section — classical ML does not need one); the GPU will earn its keep when you rerun the CNN from project 09-02 there and compare training times against your CPU.

Exercise 3 (guideline): one well-posed example: with a city council's traffic accident data, "predict the severity of an accident from time of day, weather and road type" — supervised classification, probably with imbalanced classes (remember 09-04: F1 or AUC-PR beats accuracy here), explored in JupyterLab, versioned in Git, hyperparameters via Optuna and, if the result is worth it, published on GitHub as a portfolio piece. Any dataset works if the question is concrete and the metric is justified.

And with this, the course ends. You started out not knowing what separates supervised from unsupervised learning, and you arrive here having cleaned real data, trained and evaluated dozens of models, deployed one behind an API inside a container, and completed five projects from start to finish. MercaFresh stays behind, but the workflow you practiced with its customers, its fruit and its fraud cases is exactly the one you will apply to any real problem that awaits you.

This final module leaves you the map: books to go deeper, courses to go wider, communities so you never walk alone, and a workshop of tools to work like a professional. Machine learning is a fast-moving field, and far from being a threat, that is the guarantee that you will never be bored: there will always be a better model to train, a new dataset to understand, one more technique to learn.

Only the most important thing remains: practice. Pick a dataset this week — not next month — and walk the full workflow one more time, now with no one guiding you. That is the exact moment you stop being a machine learning student and become a practitioner. It has been a pleasure to accompany you this far. The rest of the road is yours: enjoy it.