Como convertir en app un problema de tu día a día
Este proyecto empezó por una necesidad sencilla:
quería una herramienta ética de autoevaluación y coevaluación que funcionase de verdad en el aula.
Y, sin saber programar, decidí intentar construirla.
Lo que cuento aquí no es una guía profesional.
Es el proceso real de cómo me fui equivocando, aprendiendo y uniendo piezas hasta crear algo que funciona.
🔧 1. El objetivo inicial: evaluar sin poner nombres, simplificando triangulaciones de datos (uno de los pilares de la evaluación en el aula)
Quería tres cosas:
Autoevaluación honesta → reflexión personal del alumnado.
Co-evaluación anónima → cada alumno valora a dos compañeros sin saber quiénes son.
Triangulación → combinar auto/co/docente para ver discrepancias.
Esto marcó toda la arquitectura.
🧩 2. Dos servicios que no sabía que necesitaba
Sin planearlo, terminé creando una arquitectura con dos microservicios:
1) core-app
La app principal.
Aquí vive la lógica educativa: formularios, pantallas, base de datos, rutas, etc.
Sirve para:
gestionar actividades,
guardar respuestas,
mostrar la interfaz del alumnado,
controlar que todo fluya bien.
2) code-broker
Un servicio pequeño que solo hace una cosa: crear códigos efímeros para mantener el anonimato.
Sirve para:
que cada alumno tenga un alias temporal,
evitar que alguien pueda saber quién es quién,
separar identidad y evaluación.
No tenía previsto crearlo, pero la necesidad me llevó ahí.
🧠 3. Los modelos: la estructura de la app
Antes no sabía ni qué era un “modelo”.
Ahora tengo cinco:
Activity → representa cada actividad creada por el docente.
SessionData → gestiona las sesiones anónimas del alumnado.
SelfAssessment → almacena la autoevaluación.
CoTargetAssignment → decide a quién debe evaluar cada alias.
CoAssessment → guarda cada coevaluación enviada.
Cada uno existe porque el aula lo pedía: si faltaba uno, algo no funcionaba.
🔄 4. La magia: asignar coevaluaciones de forma ética
Crear un servicio que:
recoge todas las autoevaluaciones,
mezcla alias anónimos,
genera un “ciclo circular”,
asigna a cada alumno dos compañeros,
y evita que haya repeticiones o fugas de información.
Sirve para que la coevaluación sea justa y totalmente anónima.
🌱 5. La interfaz: simple, rápida y sin distracciones
Usé HTMX y plantillas Jinja2 porque necesitaba algo sencillo.
Pantallas creadas:
self_assessment.html → Likert + reflexión personal.
co_assessment.html → evalúa a los compañeros asignados.
Sin efectos, sin ruido.
Solo lo necesario para aprender.
🏗️ 6. Las rutas: donde todo empieza a funcionar
Las rutas son los “caminos” que usa la app:
GET /ui/activities/{id} → entrar a la actividad.
POST /ui/self → enviar autoevaluación.
GET /ui/activities/{id}/co → empezar coevaluación.
POST /ui/co → enviar coevaluaciones.
Sirven para conectar la UI con la lógica interna.
⚙️ 7. Migraciones, entorno y requirements
Sin esperarlo, tuve que aprender:
Alembic (migraciones de base de datos),
requirements por servicio,
entornos virtuales,
configuración .env,
cómo ejecutar dos servicios a la vez.
No era el plan… pero fue necesario. Y para ello consultaba en dos vías: chat con IA LLMs y sus respuestas adaptadas a codex en visual code studio, con full access.
🎯 8. ¿Y por qué cuento todo esto?
Porque este proceso demuestra algo importante:
un docente puede crear tecnología real si tiene necesidad, curiosidad y tiempo para equivocarse.
No estoy construyendo para ser programador.
Estoy construyendo porque mi aula lo pide.
Y todo lo que escribo aquí es simplemente un diario honesto de aprendizaje técnico, paso a paso.
Gracias por seguir este camino conmigo.