[Proyecto] #331

Activity

1. gbrielass

   added

   Proyecto I - 2024

   on Jun 27, 2026
2. github-actions commented on Jun 27, 2026

   

   github-actionsbot

   on Jun 27, 2026 – with GitHub Actions

   More actions

   Verificación Automática — Proyecto I 🤖

   Repositorio analizado: https://github.com/gbrielass/proyecto-de-programacion-2026.git

   1. Repositorio

   ✅ El repositorio es accesible y fue clonado correctamente.

   2. Informe (report.md)

   ❌ No se encontró report.md en el repositorio.

   3. Proyecto Python

   ⚠️ Sin pyproject.toml.
   ⚠️ Sin requirements.txt.

   Archivos Python (5, 366 líneas en total):

   • function_empresa.py
   • funciones_restricciones.py
   • funcion_delete.py
   • funcion_client.py
   • main.py

   4. Punto de Entrada

   ✅ Punto de entrada detectado: main.py

   5. Ejecución

   ✅ El proyecto se ejecuta.

   Traceback (most recent call last):
     File "/tmp/tmp2uop83qm/repo/main.py", line 1, in <module>
       import streamlit as st
   ModuleNotFoundError: No module named 'streamlit'
   

   Resumen

   • ✅ Repositorio accesible
   • ❌ report.md con ≥2000 palabras
   • ✅ Archivos Python
   • ❌ Configuración de dependencias
   • ✅ Punto de entrada
   • ✅ Ejecución

   4/6 verificaciones pasadas.

   ---

   Verificación automática — los resultados son orientativos. El profesor revisará en detalle.
3. apiad commented on Jul 16, 2026

   

   apiad

   on Jul 16, 2026

   Member

   More actions

   🔍 Revisión de Código — Claude Code

   Repositorio: https://github.com/gbrielass/proyecto-de-programacion-2026.git

   Qué hace tu proyecto

   Construiste un organizador de eventos en Streamlit (una app web, no de consola) que hace algo bastante ambicioso: cuando un cliente pide un evento con ciertos recursos y personal en una fecha y horario, tu programa busca una empresa que tenga todo lo que se pide y que además esté libre en ese horario sin chocar con recursos ya comprometidos. Ese emparejamiento con detección de solapamiento de horarios es el corazón del proyecto y está muy bien pensado para primer año.

   Ejecución

   La corrí de verdad. Como es Streamlit, la levanté en modo headless (streamlit run main.py) y respondió HTTP 200 sin errores: la app arranca bien. El ModuleNotFoundError: streamlit de la verificación automática es solo que faltaba instalar la dependencia, no un fallo tuyo. Después ejecuté la lógica de negocio directamente con tus datos reales de data/, recorriendo flujos válidos e inválidos. Lo mejor: tu algoritmo de emparejamiento funciona correctamente — encuentra la empresa adecuada, bloquea un horario que solapa con un evento existente que comparte el "Escenario", y deja pasar una fecha libre. Nada reventó con Traceback.

   Lo que está bien

   • El algoritmo de matching cliente↔empresa funciona (funcion_client.py:39-97): verifiqué que encuentra empresas válidas, detecta choques de horario con intersección de intervalos y respeta los recursos ya ocupados. Es lo más difícil del proyecto y lo resolviste bien.
   • Buena modularización: separaste en cinco archivos por responsabilidad (clientes, empresas, restricciones, borrado, UI). Buen instinto.
   • Modelo de datos limpio: tus clases con convertir() y str(fecha) para serializar a JSON manejan bien los tipos que no son serializables por defecto (funcion_client.py:19).
   • Las validaciones de evento (ID de 8 dígitos, duración ≤12h, campos vacíos) sí funcionan y las probé una a una.

   Qué mejorar

   • Falta un return en guardar_empresa (function_empresa.py:22-30). Tus errores de validación están en un if/elif aparte del bloque que guarda, así que cuando hay un error el flujo sigue de largo y guarda la empresa igual. Lo comprobé: guardar_empresa("", "x", [], []) mostró el error de nombre y el de "guardado correctamente", y el registro basura quedó en el archivo. Solución: añade un return después del bloque de errores (o mételo todo en el mismo if/elif como sí hiciste en crear_eventos).
   • Dos restricciones no hacen lo que crees por cómo Python evalúa and/or:
     • "Alfombra" and "Carpas" in recursos (funciones_restricciones.py:20,52) Python lo lee como "Alfombra" and ("Carpas" in recursos), y como "Alfombra" siempre es verdadero, la regla se dispara con solo poner Carpas (sin alfombra). Lo verifiqué. Escribe: "Alfombra" in recursos and "Carpas" in recursos.
     • ("cantante" or "Banda") in personal (funciones_restricciones.py:28,60) se reduce a "cantante" in personal, así que ignora a "Banda" por completo. Escribe: ("cantante" in personal or "Banda" in personal).
     • La idea general: in solo se aplica a lo que tiene inmediatamente al lado; cada nombre que quieras buscar necesita su propio ... in ....
   • Mayúsculas que no coinciden con el menú: varias reglas comparan contra "Proyector", "Tecnico de proyeccion", "Encargado del stand", "Iluminacion ambiental", pero tu menú los ofrece en minúscula ("proyector", "tecnico de proyeccion", etc., main.py:31). Como el texto no calza exacto, esas restricciones nunca se activan. Alinea los literales con las opciones del multiselect.
   • "Eventos del dia" no hace nada: está en el menú pero no tiene su rama elif en main.py. O impleméntala o quítala.
   • Las lecturas de archivo dentro del cuerpo de la clase (funcion_client.py:32-36) se ejecutan al importar el módulo y hacen frágil el programa (falla si el directorio de trabajo no es la raíz), y encima esas variables ceo/client no se usan (vuelves a abrir los archivos dentro de crear_eventos). Puedes borrarlas.

   Sobre el informe

   No encontré report.md en el repo, y es un requisito del proyecto. Te recomiendo escribirlo: explica qué hace la app, cómo la organizaste en archivos, y —esto suma mucho— cuenta cómo pensaste el algoritmo de emparejamiento y detección de conflictos de horario, que es tu mejor pieza.

   ---

   Tienes una muy buena idea central y la parte difícil ya la resolviste bien. Cerrando esos tres detalles de validación (el return y las dos condiciones con and/or) y añadiendo el informe, este proyecto queda redondo. ¡Buen trabajo!