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

[Aníbal Lovaglio]

De: Daniel Moisset <dmoisset en machinalis.com>
Para: Python Argentina <pyar en python.org.ar> 
CC: "sercom2012 en googlegroups.com" <sercom2012 en googlegroups.com> 
Enviado: jueves, 18 de octubre de 2012 17:10
Asunto: Re: [pyar] Nueva herramienta libre - Validación con la comunidad
 

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" ?

--> Lo que no me cubre "./manage.py test" es lo de tests funcionales con Behave. Queremos que se corran todos los tests que tengamos cuando hagamos push al repo. Esto incluye los tests de features que hayamos incluido. Además, de alguna manera, correr tareas "por consola", nos hace depender un poco de Travis, y mudarnos de server de CI, o que alguien quiera forkearse nuestro proyecto y desarrollar cosas nuevas, sería más laborioso. En cambio, tenerlo  todo armado para que un "make", "mvn" o "scons" haga que se despliegue todo serí mucho más conveniente.
 
, 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.

_______________________________________________
pyar mailing list pyar en python.org.ar
http://listas.python.org.ar/listinfo/pyar

Saludos!
Aníbal
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20121018/b7c3116b/attachment.html>