E113 - Demo: De un JN a un proyecto estructurado

Resumen

El episodio 113 de enCoders es una demo en vivo de cómo llevar un proyecto de ciencia de datos desde un Jupyter Notebook monolítico (el entregable de un bootcamp, con rutas absolutas y todo mezclado) a un proyecto estructurado y modular. El presentador convierte el `.ipynb` a `.qmd` con Quarto, crea un repositorio Git con `.gitignore`, adopta una estructura de carpetas propia y crea un ambiente virtual con `requirements.txt`. Después divide el código en scripts numerados (`a01`, `a02`…) y en archivos de modelos separados, de modo que cada script tenga inputs y outputs claros. Se discuten el data leakage, el formato de guardado de datos (mejor Feather o Parquet que CSV) y el uso de rutas relativas a la carpeta del proyecto. En paralelo hay conversaciones sobre memes, el uso de ChatGPT/Claude para programar y las clases frente a scripts simples. La conclusión principal es que modularizar desde el inicio no cuesta velocidad y facilita mucho el mantenimiento, la depuración y el trabajo en equipo.

Capítulos

• 00:00
  IntroSe presenta el episodio 113: pasar un proyecto de Jupyter Notebook exploratorio a uno estructurado, un problema común para quien empieza como data scientist. Se menciona el episodio 96 sobre el manifiesto de programación, donde ya se habló de estructura de proyectos. Se explica que el proyecto de ejemplo es el trabajo final de un bootcamp con datos abiertos de una empresa ficticia de telecomunicaciones, y que usará Visual Studio Code, Positron y RStudio.
• 03:52
  Estado inicialSe describen las carpetas existentes: `.Rproj.user`, `.vscode` con colores de ventana, la carpeta `datasets` con cuatro archivos públicos (clientes, uso de internet, etc.) y el notebook. El problema concreto es irrelevante; lo que importa son las prácticas aplicables a cualquier proyecto.
• 04:37
  Convertir .ipynb a .qmd y desventajas de usar .ipynbCon `quarto convert` se pasa el notebook a texto plano. Un `.ipynb` es un JSON que incrusta tablas e imágenes (png), por lo que puede filtrar datos sensibles, y sus cambios son imposibles de revisar en el control de versiones (unas 100.000 líneas).
• 06:52
  Creación de repo, herramientas que agilizan el uso de Git y gitignoreSe crea el repositorio y un `.gitignore` copiado de otro proyecto que ignora notebooks, datasets, etc. Se comentan interfaces de Git como SourceTree, GitKraken y GitLens, y se recomienda aprender los comandos básicos y luego usar una herramienta; se remite a los videos de Git del canal.
• 11:45
  Commiteo de settingsSe commitean los archivos de settings de RStudio y VS Code para tener consistencia al usar el proyecto en otro computador. El `.qmd` se commitea como "proyecto inicial". También se responde una pregunta del chat sobre cómo empezar en ciencia de datos: partir con un proyecto que resuelva un problema.
• 12:22
  Diferencia entre exploración y ejecuciónCuando un proyecto está listo interesa ejecutarlo para lograr un objetivo (por ejemplo, un modelo de propensión de pago que evalúe un dataset nuevo cada mes), no la exploración. Los comentarios exploratorios e importaciones innecesarias pueden resumirse o eliminarse.
• 14:08
  Por qué modularizar el código?Un monolito es frágil, porque cambiar una parte rompe otra. Separar en "cajitas" permite reemplazar o insertar piezas aisladas y mejora la mantenibilidad a largo plazo.
• 14:50
  Estructura de carpetasSe menciona Cookiecutter como librería de plantillas, aunque el presentador copia la estructura de un repositorio propio. Prefiere que todo el proyecto sea código fuente (sin carpeta `src`) y una carpeta `files` no commiteada con datasets (input, intermedios, output), documentación, figures, logs, reportes y modelos entrenados. Los demás participantes aconsejan que la estructura sea entendible y constante, sobre todo en equipo.
• 21:50
  Ambiente virtual, pip, requirementsSe explica `requirements.txt` como lista de librerías y versiones para reproducir el proyecto, y se mencionan pip, conda, mamba, poetry y renv para R. Los ambientes virtuales aíslan versiones entre proyectos; para sistemas operativos distintos se recurre a Docker (episodio 25). Se crea el venv `.venv` con Python 3.12 desde Positron, y la terminal nueva queda activada automáticamente.
• 33:20
  Test del código de principio a finSe instalan las librerías con `pip install -r requirements.txt` y se actualiza el archivo con las versiones exactas usando `pip freeze >`. Se ajustan las rutas a la carpeta `files`, se prueba la ejecución y se muestra un render ya hecho para confirmar que el ambiente funciona. Hay anécdotas sobre conflictos de versiones (TensorFlow no existía para Python 3.13) y sobre buscar el punto de quiebre con búsqueda binaria.
• 35:06
  Precausiones con data leakage y por qué modularizar sirve para evitarloSe separa un preproceso común de otro ad hoc. Data leakage es filtrar información de test o del futuro al entrenamiento, por ejemplo al imputar nulos o escalar con todo el dataset. Un compañero cuenta un caso real en que una base pisaba datos retroactivamente con nulos y el modelo de fuga de clientes funcionaba demasiado bien. Se aconseja usar XGBoost para mirar la importancia de variables, y definir la lógica solo con entrenamiento y luego aplicarla a test.
• 42:16
  MemesSe comentan memes sobre procesos de selección, un experto en datos usando ChatGPT para SQL, el notebook en producción y el "efecto LinkedIn". Se sugiere crear un archivo de funciones que se importe en el notebook.
• 46:23
  Mati descubriendo ChatGPT en su vida de programadorMati cuenta que usa ChatGPT para programar casi sin pensar, pasándole contexto y código. Se recomienda Claude 3.5 Sonnet, y se debate si la IA "hace más tonto" o si uno evoluciona; se contrastan los puristas de YouTube con el exceso de promesas en LinkedIn. El presentador usa un chat fijo para generar el esqueleto de sus clases en formato Quarto.
• 57:40
  Mati y su trato humano con ChatGPTMati cuenta que agradece y se disculpa con ChatGPT y le parece raro no hacerlo. Se opina que tratar con cortesía a la IA conserva la humanidad, y se mencionan los proyectos de Claude para chatear con transcripciones de cursos. También se explica el objetivo del canal: aprender, enseñar y compartir conocimiento con la comunidad hispanohablante.
• 01:00:55
  División del código monolítico en múltiples archivosSe exporta el notebook a un `.py` y se divide en secciones (librerías, importación, nulos, duplicados), dejando fuera las celdas que solo imprimen. El EDA se mueve a un archivo aparte, porque ejecutar el proyecto no debería repetir gráficos y lecturas innecesarias. Se mencionan los snippets y atajos de la extensión Macros (episodio 80).
• 01:08:58
  Uso de Todos para explicitar tareas futurasSe dejan comentarios `TODO` y se recomienda la extensión Todo Tree para ver las tareas pendientes del proyecto. Se explica que imputar con un valor fijo (cero) no genera leakage porque la lógica no depende de los datos. También se muestra cómo mover paneles laterales en VS Code.
• 01:12:16
  División del preproceso global en varios módulosSe separan en archivos distintos el preproceso general, la ingeniería de características, la división train/test, el pipeline y el bootstrapping, y cada modelo (gradient boosting, MLP) va a su propio archivo en la carpeta de modelos. A la pregunta de si conviene una clase con todos los modelos, la respuesta es que mientras se itera conviene evitar la orientación a objetos y preferir scripts simples.
• 01:19:08
  Uso de la carpeta sandbox y IDs de scriptsTodo se deja primero en `sandbox` mientras no se sabe el orden y luego se renombra con IDs (`a01`…`a06`; `i01` para insights; `m01` para modelos). Los IDs permiten abrir archivos con Ctrl+P y referenciarlos fácilmente ante otra persona.
• 01:21:28
  Inputs y outputs de los scripts. Por qué NO usar csv?Cada script lee un input y guarda un output que sirve de checkpoint y de input del siguiente, así se puede insertar un script nuevo mientras respete el formato. CSV pierde los tipos de datos (por ejemplo las fechas) y obliga a reformatear; se recomienda Feather o Parquet, y se desaconsejan pickle y RDS por ser específicos de cada lenguaje.
• 01:27:24
  NO ocupen rutas absolutas. Siempre rutas relativas (idealmente a la carpeta del proyecto)Las rutas absolutas solo funcionan en el computador de quien las creó. Tampoco conviene usar `..`, porque depende de dónde esté el archivo; es mejor partir siempre desde la carpeta base del proyecto.
• 01:29:48
  Cómo importar archivos del proyecto y otras cosas que se pueden hacer (detalles en un epidosio futuro)Se puede hacer que los lenguajes partan desde la ruta del proyecto con `launch.json`, variables de entorno o agregando la carpeta al `PYTHONPATH`. Se menciona un archivo `params` con variables globales y la posibilidad de usar archivos de configuración (YAML o JSON), temas para otra sesión.
• 01:32:21
  CierreSe adelanta que en una próxima sesión se verán modelos, evaluación y un modo de pruebas ligero para iterar en segundos. Los participantes opinan que partir estructurado desde el inicio no cuesta velocidad, y el presentador publica su plantilla en su perfil de GitHub. La próxima semana el tema será FastAPI; los streams son los martes de 7 a 9 de la tarde, hora chilena.

Palabras clave