[pyar] Nueva herramienta libre - Validación con la comunidad

[Daniel Moisset]

2012/10/18 Aníbal Lovaglio <aniballovaglio en yahoo.com.ar>

> Buenas tardes a todos.
>
> Estamos encarando un proyecto como trabajo profesional de nuestras
> carreras y nos sugirieron que sería una buena idea validar nuestro enfoque
> con la comunidad de python. Cabe destacar que ninguno de los dos
> integrantes del equipo tiene mucha experiencia en esta tecnología y
> podríamos valernos de su experiencia para ahorrarnos algunos disgustos.
>
> El objetivo del proyecto es construir una herramienta online para alumnos
> y docentes de materias de programación de las carreras de sistemas, cuyo
> fin es lograr la entrega y corrección sistematizada de trabajos prácticos
> de programación. Se tratará de una herramienta de Software Libre con un
> diseño incremental por módulos y tenemos intención de dejar el camino
> allanado para futuros equipos que quieran continuar con el desarrollo de
> nuevas funcionalidades.
>

Me parece piola, más de una vez como docente me hubiera venido bien (ahora
no tanto, desde que hacemos que los alumnos entreguen en repositorios SVN,
la parte más tediosa que era juntar todo y tener registro del día de
entrega se hace sola). Pero poder correr tests contra la entrega y cosas
así sería muy piola


> La aplicación está planteada como un servicio de acceso web, al cuál los
> usuarios podrán acceder desde cualquier navegador. Los alumnos cargarían
> sus entregas, estas serían desempaquetadas, compiladas en caso de ser
> necesario, y probadas según los criterios establecidos por los docentes.
> Los docentes podrían acceder a revisar los resultados de estas entregas,
> generar reportes o cargar nuevos trabajos prácticos para ser entregados.
>
>
Lo único peligroso acá es el sandboxing. Si estás corriendo código que el
alumno sigue, deberías poner a correr esto de forma que ese código no te
pueda reventar el sistema (por error o por malicia). Es decir, debería
correr bajo otro usuario, con limites de tiempo, uso de memoria, disco, etc.


> Respecto a nuestra implementación. Como se podrán imaginar, python es el
> lenguaje elegido. Para hacernos la vida sencilla, elegimos Django como
> framework principal, para aprovechar lo que ofrece para la separación de
> vista y modelo, y el ORM que permite sin esfuerzo, usar tanto PostgreSQL
> como MySQL, o SQLite para instalaciones livianas o para descargarse la
> aplicación y probarla fácilmente. Además, estamos usando Travis para
> integración continua ya que el proyecto está hosteado en github y Travis
> permite asociarse los repositorios de github sin esfuerzo.
>
> Finalmente, para asegurar la calidad de la aplicación, automatizamos el
> testing. En principio el testing unitario no debiera presentar problemas ya
> que unittest viene incluído dentro de las utilidades de django mismo,
> aunque hasta ahora se nos presentaron algunos problemas para correrlos con
> SCons
>

el unittest que trae django es en realidad el que trae python (con un par
de extendidas cuando uno quiere testear algunas cosas django-específicas).
Que necesidad compleja tenes al correrlo que no te cubra "./manage.py test"
?


> , pero ya consultamos y vamos a investigar como hacerlo con fabric. Además
> estamos usando pruebas funcionales de integración con la herramienta
> Behave, y alguna ayuda de drivers de selenium.
>
> En resumen, las herramientas que estamos utilizando y queremos saber si
> son las más adecuadas, o si se sabe de algún problema puntual en la
> combinación de unas con otras, son las siguientes
>
> Frameword: Django 1.4.1 (http://django.es/)
> Repositorio: Git-Hub (https://github.com)
> Servidor de integración continua: Travis (https://travis-ci.org/)
> Pruebas Funcionales automatizadas: Behave 1.2.2 (
> http://packages.python.org/behave/)
>
>
Así en general suena bien

Saludos,
   D.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20121018/99b4a3a8/attachment.html>