[Proyecto I] #333

Activity

1. github-actions commented on Jun 30, 2026

   

   github-actionsBot

   on Jun 30, 2026 – with GitHub Actions

   More actions

   Verificación Automática — Proyecto I 🤖

   Repositorio analizado: https://github.com/SamuelAlej18/proyecto-univ-2026-programacion

   1. Repositorio

   ✅ El repositorio es accesible y fue clonado correctamente.

   2. Informe (report.md)

   ⚠️ report.md encontrado pero con solo 1,536 palabras (mínimo: 2,000).

   3. Proyecto Python

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

   Archivos Python (3, 533 líneas en total):

   • servidor/funciones.py
   • servidor/main.py
   • servidor/crearUsuario.py

   4. Punto de Entrada

   ⚠️ No se encontró un punto de entrada claro (main.py, app.py, etc.).

   5. Ejecución

   ⚠️ Sin punto de entrada identificado — no se intentó ejecutar.

   Resumen

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

   2/6 verificaciones pasadas.

   ---

   Verificación automática — los resultados son orientativos. El profesor revisará en detalle.
2. 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/SamuelAlej18/proyecto-univ-2026-programacion

   Qué hace tu proyecto

   Montaste un planificador de conciertos cliente-servidor de verdad: un backend Flask (API REST en servidor/) y un frontend web en HTML/CSS/JS puro (web/) que se comunican por fetch. El sistema hace registro/login con clave secreta de empresa, y gestiona eventos en cuatro locales validando un montón de reglas de negocio (recursos, duración, antelación de 24h, colisiones de lugar, artistas mundiales, etc.). Lo más valioso: resolviste la planificación con algoritmos genuinamente buenos — inserción ordenada por búsqueda binaria y un barrido (sweep-line) para calcular la demanda máxima de recursos teniendo en cuenta los solapamientos. Eso es un nivel notable para primer año.

   Ejecución

   Corrí todo de verdad: creé un entorno con Python 3.12, instalé Flask y flask-cors, arranqué tu servidor y golpeé cada endpoint con datos reales (válidos e inválidos).

   • Registro y login funcionan perfecto. Registré un usuario, se guardó en usuarios.json, y el login aceptó la clave correcta y rechazó la incorrecta.
   • Pero el subsistema de eventos no arranca en el estado que subiste. GET /eventos (y todo lo que crea/lista/elimina eventos) devuelve HTTP 500 con TypeError: object of type 'bool' has no len(). El propio evento de ejemplo de tu informe también revienta.
   • La causa es un solo carácter mal puesto en servidor/main.py:43. Cuando corregí esa línea en mi copia y reejecuté, todo el sistema funcionó end-to-end: crear evento, detectar colisión de lugar, rechazar nombre con tilde, eliminar por índice, rechazar índice fuera de rango. Tu lógica está bien; lo que la tumba es ese typo.

   Lo que está bien

   • Los algoritmos son correctos. Probé tu lógica de negocio de forma aislada con 11 casos (validaciones, inserción binaria, barrido de demanda, filtro de expirados) y todos pasaron. La inserción binaria mantiene la lista ordenada; el barrido detecta bien cuándo faltan recursos.
   • Buena separación de responsabilidades: main.py (HTTP), funciones.py (negocio), crearUsuario.py (auth). Nombres claros y en español consistente.
   • Detalles cuidados: los archivos JSON se crean solos si faltan, manejas fechas inválidas devolviendo None, y usas .get(clave, 0) para recursos ausentes.
   • El informe es honesto y coincide con el código: no infla funcionalidades, describe bien las tres decisiones algorítmicas.

   Qué mejorar

   • El bug crítico (main.py:43): escribiste if len(eventosPosteriores!= len(eventos)):. Python evalúa primero eventosPosteriores != len(eventos) (que da un booleano) y luego intenta len() de un booleano → crash. Debe ser if len(eventosPosteriores) != len(eventos):. Es solo mover un paréntesis.
   • Segundo bug, lógico (funciones.py:99-105): en Sala 23 y Cuarto del Rock usas elif piano != 1, que rechaza también el caso de cero pianos. Probé un evento sin piano en Sala 23 y lo rechazó con "solo se admite un piano". Como querías "como máximo uno", debería ser elif piano > 1: (y lo mismo con la batería). Tal como está, dos de tus cuatro locales quedan casi inutilizables.
   • debug=True en producción (main.py:158): por eso el error se mostró como una página de depurador con PIN. Ponlo en False fuera de desarrollo.
   • requirements.txt está en UTF-16, no en UTF-8 (seguramente por pip freeze desde PowerShell). Por eso el bot no lo detectó y pip install -r requirements.txt puede fallar. Regénéralo en UTF-8.
   • La lección de fondo: los dos bugs los habría cazado en segundos un solo GET /eventos y un solo evento en Sala 23. Antes de entregar, reejecuta el ejemplo de tu propio informe. Tu problema no fue de algoritmos (esos los dominas) sino de verificar el flujo completo después del último cambio.

   Sobre el informe

   Coincide bien con el código y es honesto — no exagera con "demuestra" ni "prueba". El único detalle importante: el evento que pones como ejemplo válido (report.md:111-118) es justamente el que produce el TypeError en el código entregado, señal de que no reejecutaste tras tu último cambio. Además está algo por debajo del mínimo de palabras (1536 de 2000). Nada de esto opaca que el diseño técnico esté bien explicado.

   Buen trabajo de fondo, Samuel — el núcleo algorítmico es de los buenos. Corrige esas dos líneas y tienes un proyecto que funciona completo. 💪