-
Notifications
You must be signed in to change notification settings - Fork 0
Home
MQL busca integrarse a la Plataforma Mumuki como un proyecto destinado a la enseñanza online de Bases de Datos relacionales.
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. MQL busca mejorar estos dos últimos puntos de una forma no invasiva.
El proyecto busca generar una plataforma online de enseñanza de conceptos de Bases de Datos, primariamente enfocado a SQL. No es la idea desarrollar una plataforma nueva sino integrarse a Mumuki mediante un Runner que procese y ejecute sentencias SQLite.
Mumuki es una plataforma de enseñanza de programación desarrollada y mantenida por programadores y docentes argentinos mediante un enfoque que prioriza los conceptos por sobre las tecnologías. Se define a si misma como un proyecto que apunta a universalizar el acceso a la educación libre, gratuita y de calidad, enfocándose principal pero no excluyentemente en la enseñanza de la programación.
Una de las ventajas técnicas con las que cuenta Mumuki es que su construcción fue pensada y diseñada de manera de facilitar la incporporación de Runners que trabajen en diferentes tecnologías. Un Runner es un proyecto independiente que -luego de integrado a Mumuki- recibe el ejercicio que plantea el docente junto a la solución brindada por el alumno. El ejercicio es procesado, ejecutado y testeado, retornando el feedback correspondiente al alumno.
Existen Runners que son capaces de correr tecnologías tradicionales como Ruby, Python, Javascript, C++, etc. Y también ejecutar proyectos educativos como Gobstones y Wollok. En este punto es donde se pretende acoplar este trabajo, permitiendo la incorporación de la enseñanza de SQL.
Otra de las ventajas que tiene Mumuki es la posibilidad de generar seguimientos no solo sobre el temario propuesto sino también sobre el avance de cada ejercicio gracias a un sistema de versionado de soluciones. Esto posibilita no solo que el docente visualice las resoluciones de los ejercicios sino también que tanto docente como el propio alumna sea capaz de revisar y evaluar el avance en la construcción de la solución de cada ejercicio.
Este enfoque de versionado de la construcción de las soluciones es una herramienta fundamental para lograr un feedback temprano y asincrónico con respecto a los días de cursada presencial. Esto permite no sólo evaluar una solución sino también la manera en la que se llegó a una solución (correcta o incorrecta).
Se propone entonces un Runner SQLite para la enseñanza de SQL. Si bien existen muchos motores de SQL y cada uno varía en cierto grado la sintaxis permitida, en conjunto con el equipo de Mumuki se decidió utilizar el motor de SQLite por ser muy liviano y veloz.
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 analizar el tiempo consumido por el runner se midió el tiempo promedio de 10 corridas para ejercicios en donde se crea una tabla con 10, 100 y 1000 rows.
Los resultados obtenidos fueron:
- 10 rows: 0.57 segundos
- 100 rows: 0.96 segundos
- 1000 rows: 4.69 segundos
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_code
planteado 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