Home
Trabajo de Inserción Profesional
Leandro Di Lorenzo
Universidad Nacional de Quilmes
8 de julio de 2017
Desde hace alguno años a esta parte, y gracias a la fuerte penetración de Internet y la computación en la sociedad, se vienen generando diversos cambios paradigmáticos en cuanto a la manera de transmitir conocimiento. La enseñanza tradicional del docente para con los alumnos hoy se ve complementada (y hasta a veces superada) por la gran cantidad de recursos existentes en Internet y las redes sociales. Pero no por cantidad se gana en calidad. Ni tampoco hay que pensar que Internet puede reemplazar la calidez humana, el compromiso y la claridad del docente. Pero la educación y la formación deberían ser capaces de adaptarse a los tiempos actuales y lograr mejores formas de brindar conocimiento a la sociedad a través del medio que la sociedad moderna utiliza de forma mayoritaria.
Hay nuevas formas de enseñar. Una de esas formas es el Proyecto Mumuki, que busca combinar muchas de esas ellas para lograr aprovechar lo mejor de cada una.
El presente trabajo tiene como objetivo colaborar con el Proyecto Mumuki aportando nuevas herramientas educativas. Se busca incorporar a la Plataforma Mumuki un Runner que permita la generación de guías y ejercicios de SQL, una tecnología que no cuenta con demasiadas soluciones en línea.
Mumuki es un proyecto que tiene como objetivo promover la educación de la programación utilizando software y contenido libre.
A diferencia de otros sitios de educación que brindan cursos y tutoriales de programación, Mumuki se presenta como una plataforma colaborativa en donde existen guías y ejercicios en distintas temáticas, pero con un fuerte eje en el seguimiento de las soluciones y la colaboración entre pares.
La plataforma queda dividida mayormente en cuatro componentes:
- Laboratory: el entorno web en donde los estudiantes resuelven ejercicios y reciben feedback.
- Classroom: herramienta para que el docente puede generar seguimiento de sus alumnos.
- Bibliotheca: repositorio de guías y ejercicios.
- Runners: componentes que se encargan de ejecutar y verificar los programas enviados por los alumnos.
Existen hoy en día muchos Runners en Mumuki. Cada uno se encarga de trabajar sobre una tecnología puntual. Existe un Runner de Javascript, otro de Ruby, de Gobstones, de C++, de Wollok, de QSIM, de Prolog, de Java. Y podríamos seguir.
A cada ejercicio (o guía) se le asocia un Runner, el cual es el encargado de procesar el ejercicio y retornar un buen feedback. Para que todos ellos puedan convivir deben respetar ciertas reglas de comportamiento. Cada Runner debe utilizar el framework Mumukit y establecer los métodos necesarios para que el flujo del proceso de evaluación del ejercicio sea satisfactorio. O sea, cada Runner debe cumplir con la guía del buen ciudadano Mumuki.
En el equipo docente de la materia Bases de Datos en la Universidad Nacional de Quilmes surgió la necesidad de contar con herramientas que permitan mejorar la enseñanza de determinados conceptos, entre ellos SQL.
Entendemos que la mejora en la enseñanza debe surgir desde diferentes aspectos: calidad en la transmisión de conceptos, planteo de problemas inteligentes, voluntad del alumno en ejercitarse y buen feedback con el alumno para comprender los problemas surgidos y los conceptos adquiridos por él.
Nace entonces la idea de MQL (Mumuki Query Learning) cuyo objetivo primario es enseñar SQL. Como ya se comentó, Mumuki es una excelente herramienta de enseñanza online, lo cual cubre varios aspectos en lo que concierne a la materia:
- Evita que los alumnos puedan enfocarse en resolver problemas de forma temprana y sin tener que lidiar con la instalación de un motor de bases de datos.
- Permite al docente conocer de forma instantánea la situación de cada alumno con respecto a la guía planteada.
- Permite tanto al docente como al alumno identificar aquellos problemas que le resultaron más complicados
Otra de las ventajas que tiene Mumuki es la posibilidad de generar seguimientos sobre la guía de ejercicios y sobre cada versión enviada por el alumno en cada ejercicio. Esto posibilita que el docente (y el alumno) visualicen y revisan el avance en la construcción de la solución de cada ejercicio. No solo importa el resultado, sino como se llegó al mismo.
Además, Mumuki se diferencia de otras herramientas en el hecho de que no busca enseñar lenguajes o tecnologías, sino que pretende transmitir conceptos. Bajo este criterio se puede observar que en Mumuki no se enseña Javascript, se utiliza Javascript para enseñar Programación Funcional. Tampoco se enseña Ruby, se lo utiliza para enseñar Metaprogramación.
Lo mismo aplica a Bases de Datos: no se busca enseñar enseñar SQL, se pretende enseñar al alumno a buscar y relacionar información utilizando SQL. Y también dejar la puerta abierta para lograr, por qué no, la enseñanza de Álgebra Relacional, Modelos Relaciones, Bases de Datos No-Relaciones (aquellas orientadas a Documentos, Grafos, Objetos).
No es el alcance de este trabajo cubrir toda esa temática, pero si el deseo de que pueda servir como semilla para un campo mucho más vasto.
El presenta trabajo busca incorporar un Runner SQLite a la plataforma Mumuki para permitir la enseñanza de SQL.
Existen muchos motores de Bases de Datos. Algunos de los más reconocidos y robustos de la industria son: Oracle, PostgreSQL, SQL Server.
Las diferencias entre ellos, en lo que concierne a una primera enseñanza de SQL están dadas por algunas cuestiones de sintaxis. Postgres quizás está más cerca del standard SQL y fue considerado como primera opción de Runner.
Pero por la naturaleza de la herramienta, cada ejercicio de cada alumno necesita ser ejecutado en un ambiente único y limpio. Para ello los Runners de Mumuki deben implementar una virtualización mediante Docker para inicializar una base de datos con las tablas que haya explicitado el docente, correr la solución del alumno y apagarse. Ante ese escenario todos los grandes motores generan un costo demasiado excesivo.
SQLite por el contrario es un motor sencillo, utilizado mayormente en etapas de desarrollo, pero muy, muy liviano. Quizás no implemente de forma demasiado correcta algunas cuestiones, pero la ventaja de performance en una primera etapa de enseñanza de SQL alcanzó para definirmo como el elegido.
Para analizar el tiempo consumido por el runner se midió el tiempo promedio de 10 corridas por ejercicio, donde cada ejercicio creaba una tabla con 10, 100 y 1000 rows insertados respectivamente.
Los resultados obtenidos fueron:
- Ejercicio con 10 rows: 0.57 segundos
- Ejercicio con 100 rows: 0.96 segundos
- Ejercicio con 1000 rows: 4.69 segundos
Cuando un alumno está realizando un ejercicio, eventualmente lo envía para verificar la solución. Ese código es recibido por Mumuki Laboratory mediante un Request HTTP. El Laboratory lo procesa y lo reenvía al Runner correspondiente, agregando código o datos extras según hayan sido configurados para ese ejercicio.
Mumuki cuenta con varios módulos de aprendizaje. Como en cada módulo se enseñan diferentes conceptos, cada concepto está ligado a una o varias tecnologías. De esta forma Mumuki Laboratory sabe a qué Runner enviar la información, según cuál sea el ejercicio que se está intentando resolver.
El Runner recibe los datos y procesa la solución haciendo uso de Docker. Los Runners son implementaciones concretas del componente Mumukit, el cual establece la lógica común sobre cómo los Runners deberían comportarse.
Cada Runner entonces procesa el código recibido y se lo envía a su Docker a la espera de un código de salida o un set de resultados, según el ejercicio. El Runner procesa el resultado recibido de Docker y retorna al Laboratory en el formato correspondiente para que el Laboratory pueda mostrarle al alumno la verificación de su solución en un formato común.
En la imagen se puede visualizar el comportamiento descripto.
Para la presentación del Proyecto MQL se generó cierto trabajo de base que consistió en organizar el trabajo por delante, generando el repositorio, el tablero de Trello con un Backlog y estimaciones iniciales y el desarrollo de las Slides
- Preparación de Docker integrado con un motor SQLite
- Integración con Travis CI
- Integración con CodeClimate
- Primer borrador de este documento
- Codificación y testing de ejercicio base con sintaxis inválida, detectando el fallo y mostrando la respuesta correcta
- Codificación y testing de ejercicio base correcto, verificando que los resultados retornados sean los deseados
- Modificación del Worker (Docker) para que el script ejecute la query solución planteada por el alumno y la provista por el docente
- Estudio y documentación de los Hooks de Mumukit para lograr una mejor comprensión de lo requerido para establecer el código del Runner de SQLite
- Modificación del código y generación de test para correr una prueba en donde la inserción inicial de los datos de la tabla se carguen mediante el
extra_codeplanteado por el docente
- Modificación de código en Worker y Runner para permitir que el retorno de los datos del Worker puedan ser correctamente parseados y lograr comparar y verificar que los resultados del ejercicio.
- Generación de test que verifique los resultados correctos
- Generación de test que verifique el caso de error.
- Adaptación del test de integración que simula el envío HTTP tal como sería recepcionado si viniese de Mumuki
- Instalación de Mumuki en forma local para probar ejercicios de forma visual
- Generación de un Capítulo SQL en Mumuki-dev
- Generación y verificación de funcionamiento de un ejercicio en Mumuki-dev
- Refactorización del script del Worker para permitir mayor y mejor flexibilidad en la ejecución de ejercicio
- Refactorización de la estructuración de la comunicación de datos entre el Runner y el Worker; permitiendo que sea el Runner quien organice la información y que el Worker la reciba en formato json bien estructurada.
- Refactorización del Runner para que el comportamiento haga uso de diversos Hooks de Mumukit y pueda verificar de forma más segura y correcta los datos retornados por el Worker.
- Generación de la clase que permite renderizar los resultados en formato HTML.
- Verificación (y ajustes) del funcionamiento en Mumuki-dev con el Checker y el Render funcionando
- Carga de un ejercicio más complejo en Mumuki-dev en donde se utilice más de un dataset como resultados de las pruebas
- Refactorización de la comparación de datos mediante una clase propia que abstrae el comportamiento.
- Coloreo de sintaxis
- Pull Request y correcta integración con Proyecto Mumuki en producción
- Medición de tiempos del procesamiento del Worker
- Corrección de un error que no permitía el encoding correcto
- Corrección de un error que no permitía que un resultado sea vacío
- Refactorización de la estructura solicitada al docente al cargar un ejercicio, para poder brindarle mayor flexibilidad en la generación del ejercicio
- Refactorización de la estructura solicitada al docente y del código del Worker para permitir que el docente pueda poner como respuesta esperaba la query correcta o bien el set de datos esperado
- Refactorización del Runner para permitir generar un diff entre los resultados
- Mejoramiento visual en el render HTML que permite ver las diferencias al estilo diff de git