FAVS, una herramienta para la creación y gestión de planetas de blogs docentes. FAVS es una aplicación web diseñada de forma que cualquier docente, sin apenas conocimientos informáticos, pueda crear, mantener y gestionar un sitio web, el planeta, donde aparezcan los artículos escritos por sus estudiantes en sus blogs. Los alumnos podrán inscribirse en el planeta de la asignatura, leer los escritos de sus compañeros, votar las historias más interesantes y consultar las estadísticas de votos emitidos y recibidos. FAVS es una aplicación gratuita y libre que está siendo utilizada por varias universidades y multitud de institutos y escuelas. favs.es

1. UNIVERSIDAD
REY JUAN CARLOS
´
MASTER OFICIAL
´ ´
EN SISTEMAS TELEMATICOS E INFORMATICOS
Curso Acad´ mico 2008/2009
e
Trabajo de Fin de M´ ster
a
FAVS, UNA HERRAMIENTA PARA LA
´ ´
CREACION Y GESTION DE PLANETAS DE
BLOGS DOCENTES
Autor : Jes´ s Moreno Le´ n
u o
Tutor : Gregorio Robles Mart´nez
ı

3. Resumen
Las bit´ coras (o blogs) han supuesto una revoluci´ n en Internet, y tambi´ n en las aulas de to-
a o e
do el mundo. Blogs institucionales, profesionales, de estudiantes o de aula son una herramienta
utilizada en todos los niveles educativos.
´
En los ultimos tiempos han surgido sitios web que enlazan historias de varios blogs, po-
pularmente denominados planetas, y otras herramientas que permiten que aparezcan art´culos,
ı
a ´
noticias e historias publicadas en diferentes bit´ coras en una unica p´ gina web. De esta manera,
a
se pueden encontrar planetas de las m´ s diversas tem´ ticas (p.ej., sobre la crisis financiera) o de
a a
colectivos (p.ej., personas que trabajan en la misma empresa).
Profesores de todo el mundo han comenzado a utilizar estas aplicaciones para sus clases,
intentando aprovechar las posibilidades que ofrecen como herramientas did´ cticas. Sin embar-
a
go, todas estas aplicaciones presentan ciertas limitaciones para ser usadas en un aula docente,
ya que no se crearon pensando en esta labor. Algunas requieren conocimientos s´ lidos de in-
o
form´ tica, otras exigen mucho tiempo para su puesta en marcha y mantenimiento, e incluso,
a
algunas de ellas, requieren contar con un servidor web.
En este proyecto se presenta FAVS, una aplicaci´ n libre, pensada y dise˜ ada para que cual-
o n
quier docente, sin apenas conocimientos inform´ ticos, pueda crear, mantener y gestionar un
a
sitio web donde aparezcan los art´culos escritos por sus estudiantes en sus bit´ coras. Los alum-
ı a
nos podr´ n inscribirse en el planeta de la asignatura, leer los escritos de sus compa˜ eros, votar
a n
las historias m´ s interesantes -de manera que, si as´ lo deseara el docente, pudiera utilizar esta
a ı
informaci´ n para evaluar esta actividad (heteroevaluaci´ n)- y consultar las estad´sticas de votos
o o ı
emitidos y recibidos.
Esta aplicaci´ n puede ser usada en cualquier asignatura de cualquier disciplina, ya que pro-
o
piciar´ la creaci´ n y el intercambio de conocimiento, potenciar´ las habilidades escritoras de
a o a
los estudiantes y motivar´ una sana competici´ n por escribir los art´culos m´ s interesantes.
a o ı a

5. ´
Indice general
1. Introducci´ n
o 7
1.1. Los blogs en la educaci´ n . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 7
1.2. Experiencias educativas con blogs . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1. Infraestructura inform´ tica necesaria . . . . . . . . . . . . . . . . . . .
a 9
1.2.2. Conclusiones y problemas detectados . . . . . . . . . . . . . . . . . . 10
1.3. Software libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.1. Gesti´ n de proyectos de software libre . . . . . . . . . . . . . . . . . .
o 11
1.4. Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.1. Principios fundamentales . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.2. Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.3. El patr´ n de dise˜ o MVC . . . . . . . . . . . . . . . . . . . . . . . .
o n 14
2. Objetivos 17
2.1. Descripci´ n del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 17
2.2. Estudio de alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1. Planet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2. Drupal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.3. Feevy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3. Metodolog´a empleada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ı 22
2.3.1. Programaci´ n Extrema . . . . . . . . . . . . . . . . . . . . . . . . . .
o 23
2.3.2. Aplicaci´ n de la Programaci´ n Extrema al proyecto . . . . . . . . . .
o o 26
3. Descripci´ n Inform´ tica
o a 29
3.1. Estructura general de la aplicaci´ n . . . . . . . . . . . . . . . . . . . . . . . .
o 29
5

6. 3.1.1. Arquitectura del entorno en producci´ n . . . . . . . . . . . . . . . . .
o 30
3.1.2. Patr´ n Modelo Vista Controlador . . . . . . . . . . . . . . . . . . . .
o 31
3.1.3. Modelo E/R de la Base de Datos . . . . . . . . . . . . . . . . . . . . . 32
3.1.4. Otros datos de inter´ s . . . . . . . . . . . . . . . . . . . . . . . . . . .
e 33
3.2. Fase 1: Implementaci´ n de una versi´ n funcional de la aplicaci´ n . . . . . . .
o o o 34
3.2.1. Modificaci´ n de la aplicaci´ n para el cumplimiento de los requisitos . .
o o 35
3.2.2. Desarrollo del sitio web del proyecto . . . . . . . . . . . . . . . . . . 40
3.2.3. Elecci´ n de la licencia . . . . . . . . . . . . . . . . . . . . . . . . . .
o 42
3.2.4. Puesta en marcha de la aplicaci´ n . . . . . . . . . . . . . . . . . . . .
o 42
3.3. Fase 2: Promoci´ n del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . .
o 43
3.4. Fase 3: Gesti´ n y evoluci´ n del proyecto . . . . . . . . . . . . . . . . . . . . .
o o 46
3.4.1. Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.2. Petici´ n de nuevas caracter´sticas . . . . . . . . . . . . . . . . . . . .
o ı 49
3.4.3. Un nuevo desarrollador . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4. Conclusiones 53
4.1. Logros alcanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2. Posibles trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A. Breve manual de usuario de FAVS 57
B. Instalando Feevy. Ayuda recibida. 63
Bibliograf´a
ı 69

7. Cap´tulo 1
ı
Introducci´ n
o
En este primer cap´tulo se introducir´ n los conceptos de blog y planeta de blogs, y se ana-
ı a
a ´
lizar´ su potencial en el ambito educativo. A continuaci´ n se expondr´ n experiencias docentes
o a
desarrolladas con estas aplicaciones, las dificultades experimentadas durante su realizaci´ n y
o
los conocimientos y medios t´ cnicos necesarios para su puesta en marcha.
e
Posteriormente, dado que el proyecto se distribuye con una licencia libre, se realizar´ una
a
breve introducci´ n al software libre, explicando sus caracter´sticas fundamentales. Se incluye,
o ı
aunque de forma escueta, una descripci´ n del concepto de comunidad virtual y se resume la
o
forma en que los proyectos de software libre son gestionados habitualmente.
Se explicar´ n, finalmente, las caracter´sticas m´ s importantes de Ruby on Rails, la platafor-
a ı a
ma de desarrollo en la que se ha realizado el proyecto.
1.1. Los blogs en la educaci´ n
o
Las bit´ coras o blogs (que proviene de web log) son sitios web donde un autor, o varios
a
autores, publican distintos textos (an´ cdotas, opiniones, art´culos o comentarios). Los textos
e ı
publicados aparecen ordenados en el blog de forma cronol´ gica, siendo el primer texto el pu-
o
blicado m´ s recientemente.
a
Los primeros blogs nacieron a mediados de los a˜ os 90, pero no se popularizaron hasta
n
el a˜ o 1999, cuando se lanzaron herramientas gratuitas para su creaci´ n y mantenimiento. A
n o
partir de ese momento, los blogs han ido ganando protagonismo hasta convertirse en uno de
los servicios m´ s populares de Internet. Cantantes, periodistas, pol´ticos, profesores, empresas
a ı
7

8. 8 ´ ´
CAPITULO 1. INTRODUCCION
internacionales... los blogs se han extendido por toda la sociedad y han supuesto una revoluci´ n
o
creativa en Internet[1].
Hasta el lanzamiento de este servicio, el mantenimiento y la actualizaci´ n de una p´ gina
o a
web era una tarea ardua que requer´a ciertos conocimientos t´ cnicos, lo que propiciaba que,
ı e
pr´ cticamente, s´ lamente profesionales de la inform´ tica se encargaran de aportar contenido a
a o a
la web. Con esta nueva herramienta el panorama cambi´ por completo, ya que cualquier perso-
o
na con acceso a Internet pod´a mantener su propio blog en el que pod´a escribir sobre cualquier
ı ı
tem´ tica. Surgi´ una relaci´ n entre iguales en la que todos los usuarios pod´an participar cons-
a o o ı
truyendo y compartiendo conocimiento.
Los planetas de blogs son sitios web que enlazan las historias publicadas en un conjunto
de bit´ coras que suelen compartir una tem´ tica com´ n. Los art´culos publicados en los dis-
a a u ı
a ´
tintos blogs enlazados en el planeta aparecer´ n en una unica p´ gina web siguiendo un orden
a
o ´
cronol´ gico, de manera que la ultima historia publicada ser´ la que aparezca en primer lugar.
a
Los blogs y los planetas presentan varias caracter´sticas que hacen de ellos una herramienta
ı
con un gran potencial educativo, por lo que profesores de todo el mundo han comenzado a
utilizarlos en su labor diaria[2, 4]:
Permiten que los estudiantes puedan construir su propio conocimiento de forma colabo-
rativa, lo que se adapta a la perfecci´ n a las metodolog´as comunicativa y constructivista.
o ı
Generan conocimiento libre, posibilitando el intercambio de ideas y los debates.
Potencian las habilidades de escritura de los estudiantes.
Permiten un aprendizaje continuado durante toda la vida, ya que es posible seguir apren-
diendo fuera del aula, buscando y creando conocimiento en cualquier momento, lo que
los convierte en una gran herramienta para la ense˜ anza a distancia.
n
1.2. Experiencias educativas con blogs
Los blogs permiten llevar a cabo actividades de e-learning que pueden desarrollarse en asig-
naturas de titulaciones t´ cnicas y no t´ cnicas en cursos universitarios de grado y post-grado, en
e e
las que los propios estudiantes participan en la evaluaci´ n de los contenidos aportados por los
o
compa˜ eros.
n

9. 1.2. EXPERIENCIAS EDUCATIVAS CON BLOGS 9
En la Tercera Jornada de Innovaci´ n Pedag´ gica del Proyecto ADA Madrid, profesores de la
o o
Universidad Rey Juan Carlos presentaron la siguiente experiencia docente de e-learning basada
en el uso de blogs que hab´an llevado a cabo en varias asignaturas [3]:
ı
Cada estudiante se crear´ un blog donde escribir´ entradas relacionadas con la tem´ tica
a a a
de la asignatura (aclaraciones, comentarios de noticias, an´ cdotas...). Todos los blogs ser´ n
e a
enlazados desde el planeta de la asignatura. Los estudiantes podr´ n puntuar positivamente las
a
entradas de los compa˜ eros que consideren m´ s interesantes.
n a
El alumnado deber´ escribir peri´ dicamente en el blog (semanal o bisemanalmente), de
a o
forma que al final del cuatrimestre se tenga al menos una docena (o media docena) de art´culos
ı
por alumno. Los blogs han de tener contenidos propios, y no se permitir´ n las entradas sin
a
valor a˜ adido que simplemente copien noticias de Internet.
n
Para la evaluaci´ n de la actividad se tendr´ en cuenta los votos recibidos por los com-
o a
pa˜ eros en el blog (por escribir) y los votos emitidos (por leer); por tanto, los estudiantes
n
estar´ n motivados para escribir buenas entradas y para leer y votar las historias publicadas
a
por el resto de alumnos. Los profesores de la asignatura podr´ n valorar positivamente otros
a
elementos adicionales.
1.2.1. Infraestructura inform´ tica necesaria
a
Para que los alumnos pudieran darse de alta en la actividad, se dise˜ aron unos formularios
n
en los que cada estudiante deb´a proporcionar su nombre, su direcci´ n de correo el´ ctronico
ı o e
(que deb´a coincidir con la direcci´ n usada en la plataforma Moodle de la asignatura) y el feed
ı o
de su blog. Un feed es un medio de redifusi´ n de contenido web que se utiliza para suministrar
o
informaci´ n actualizada del contenido de un sitio web.
o
Era necesario contar con un servidor web donde instalar el programa Planet1 que se encar-
gaba de enlazar las historias de los distintos blogs. El profesor deb´a construir un fichero de
ı
texto con las direcciones de los feed de los alumnos dados de alta y lo pasaba al formato del
fichero de configuraci´ n de Planet.
o
Se modific´ ligeramente la plantilla original que mostraba el planeta de manera que se mos-
o
trara un enlace para poder votar las historias. Este link enlazaba a una p´ gina de la Universidad
a
donde se proced´a a votar. Los datos de los votos se almacenaban en un fichero de texto que
ı
1
http://www.planetplanet.org/

10. 10 ´ ´
CAPITULO 1. INTRODUCCION
eran le´dos por una p´ gina en HTML que mostraba las estad´sticas de votos emitidos y recibi-
ı a ı
dos, como se muestra en la figura 1.1.
Figura 1.1: P´ gina original con las estad´sticas de votos emitidos y recibidos
a ı
1.2.2. Conclusiones y problemas detectados
Esta actividad se llev´ a cabo en el transcurso de seis asignaturas de grado y post-grado de
o
titulaciones no t´ cnicas. De estas seis asignaturas, una era presencial y cinco a distancia -una
e
de ellas dentro del programa ADA Madrid-, y todas ellas relacionadas directa o indirectamente
con la inform´ tica y las nuevas tecnolog´as. El n´ mero de estudiantes total que particip´ en las
a ı u o
mismas se encuentra en torno a los 250.
El resultado de la actividad fue bastante satisfactorio, ya que el alumnado particip´ , en l´neas
o ı
generales, de forma activa y los objetivos de creaci´ n de contenido e intercambio de ideas fueron
o
alcanzados.
Respecto a los problemas detectados, por un lado, es evidente que los requisitos t´ cnicos
e
para preparar la actividad son bastante altos (conocimientos de administraci´ n de sistemas
o
GNU/Linux, programaci´ n HTML, necesidad de contar con un servidor web), por lo que s´ lo
o o
profesores de carreras t´ cnicas, con los conocimientos y el tiempo necesarios, podr´an llevarla
e ı
a cabo.
Por otra parte, el hecho de que los estudiantes tuvieran que identificar y proporcionar el URL
(Uniform Resource Locator, es decir, localizador uniforme de recurso, o simplemente direcci´ n
o
web) del feed de su blog resultaba bastante problem´ tico, ya que la mayor´a no cursaban carreras
a ı
t´ cnicas y no se encontraban familiarizados con estos conceptos.
e
Con el objetivo de que cualquier profesor pudiera realizar esta actividad, y que la aplicaci´ n
o
resultara los m´ s amigable posible para estudiantes y profesores, naci´ el proyecto que aqu´ se
a o ı

11. 1.3. SOFTWARE LIBRE 11
presenta.
1.3. Software libre
Todo programa que sea considerado software libre debe ofrecer una serie de libertades que
se resumen en [5]:
Libertad de usar el programa con cualquier fin, sin necesidad de comunicarlo a los desa-
rrolladores.
Libertad de estudiar el c´ digo fuente del programa y modificarlo adapt´ ndolo a nuestras
o a
necesidades, sin necesidad de hacer p´ blicas las modificaciones.
u
Libertad de distribuir copias, tanto binarios como c´ digo fuente, modificadas o no, gratis
o
o cobrando por su distribuci´ n.
o
Libertad de modificar el programa y publicar las mejoras para beneficio de la comunidad.
Estas libertades conllevan una serie de factores que est´ n cambiando el desarrollo de soft-
a
ware tradicional. Por ejemplo, permiten que se pueda reutilizar gran cantidad de software que se
encuentra disponible en repositorios p´ blicos de Internet. Y no s´ lo eso, ya que tambi´ n pueden
u o e
consultarse las listas de correo y los foros utilizados por los desarrolladores del proyecto, donde
puede encontrarse gran cantidad de informaci´ n muy valiosa. De esta forma, el desarrollo de
o
software se acerca a los procesos que se siguen en la investigaci´ n cient´fica en general.
o ı
As´, el proyecto que aqu´ se presenta no comenz´ su desarrollo desde cero sino que se
ı ı o
apoy´ en otros proyectos libres existentes, reutilizando partes de su c´ digo y a˜ adiendo las fun-
o o n
cionalidades necesarias para conseguir los objetivos propuestos. Como veremos en el cap´tulo
ı
3, el proyecto no habr´a sido terminado sin esta posibilidad; los recursos (tanto econ´ micos
ı o
como humanos) necesarios para su desarrollo habr´an impedido su finalizaci´ n en los plazos
ı o
previstos si se hubiera comenzado desde cero.
1.3.1. Gesti´ n de proyectos de software libre
o
Las libertades que ofrecen los programas libres hacen que a su alrededor se creen comu-
nidades de usuarios y desarrolladores que colaboran en la detecci´ n y correcci´ n de errores,
o o

12. 12 ´ ´
CAPITULO 1. INTRODUCCION
en la solicitud y programaci´ n de nuevas funcionalidades y en otros muchos aspectos como la
o
traducci´ n de la interfaz o la documentaci´ n del proyecto a nuevos idiomas [9].
o o
El objetivo de cualquier nuevo proyecto libre es conseguir una comunidad de usuarios y
desarrolladores entorno al mismo que lo ayuden a crecer, a desarrollarse, de manera que el nivel
de actividad llegue a ser tal que el desarrollo del proyecto sea autocatal´tico, es decir, que la
ı
propia comunidad resuelva las necesidades que se plantean por s´ misma.
ı
C´ mo conseguir esta comunidad no es un problema trivial y, aunque actualmente esta labor
o
se lleva a cabo sin usar procesos ingenieriles, existen algunas buenas maneras de proceder para
´
alcanzar este ansiado exito.
En el cap´tulo tercero justificaremos las decisiones tomadas y explicaremos la labor realiza-
ı
da respecto a los siguientes aspectos:
Elecci´ n de la licencia.
o
El sitio web del proyecto. Estructura, idioma y contenido.
Promoci´ n del proyecto. Conferencias, art´culos, blogs.
o ı
1.4. Ruby on Rails
Ruby on Rails2 , tambi´ n conocido como RoR o Rails, es un framework de desarrollo de
e
aplicaciones web de c´ digo abierto, escrito en el lenguaje de programaci´ n Ruby que sigue el
o o
paradigma de la arquitectura Modelo Vista Controlador [6].
Rails ofrece a los desarrolladores clases que implementan fuciones comunes que se usan en
la mayor´a de las aplicaciones web, encarg´ ndose de muchos detalles de bajo nivel que pueden
ı a
resultar repetitivos y aburridos de programar, permitiendo al desarrollador concentrarse en la
funcionalidad de la aplicaci´ n:
o
Abstracci´ n en el acceso a la base de datos, asegurando que las consultas funcionar´ n sin
o a
importar el Sistema Gestor de Base de Datos con el que se est´ trabajando.
e
Plantillas, reutilizando c´ digo de la capa de presentaci´ n por toda la aplicaci´ n
o o o
Gesti´ n de las sesiones de usuarios
o
2
http://rubyonrails.org/

13. 1.4. RUBY ON RAILS 13
Generaci´ n de URLs limpias y amigables para los buscadores
o
1.4.1. Principios fundamentales
Rails se apoya en varios principios que lo hacen distinto a otros frameworks de desarollo y
que consiguen que los desarrolladores ahorren tiempo y esfuerzo:
Convenci´ n sobre configuraci´ n. Este principio se refiere al hecho de que Rails asume
o o
un buen n´ mero de opciones por defecto respecto a la forma en la que deber´a construirse
u ı
una aplicaci´ n web. Cuando la convenci´ n utizada es suficiente para conseguir los objeti-
o o
vos es innecesario realizar aquellas tareas para las que se ha definido un comportamiento.
S´ lo cuando la convenci´ n no se adapta a las necesidades de la aplicaci´ n, el desarrollador
o o o
puede alterar el comportamiento por defecto y adaptarlo para lograr el deseado. Ejemplos
de convenciones usadas en Rails son la nomenclatura de los objetos relacionados con la
Base de Datos y el proceso por el que los controladores encuentran sus correspondientes
modelos y vistas.
No te repitas (Don’t repeat yourself, DRY). Cuando un desarrollador decide cambiar el
comportamiento de una aplicaci´ n que sigue el principio DRY, no deber´a modificar el
o ı
c´ digo en m´ s de un sitio. En lugar de copiar y pegar c´ digo con la misma funcionalidad
o a o
en distintas partes de la aplicaci´ n, con Rails, esta funcionalidad se almacena una vez en
o
un repositorio central y se referencia desde cada parte de la aplicaci´ n que lo necesita. De
o
esta forma, se reduce la dificultad en los cambios y evoluci´ n del proyecto.
o
´
Desarrollo Agil. El desarrollo agil usa un enfoque adaptativo. Peque˜ os grupos de desa-
´ n
rrolladores van completando peque˜ as partes del proyecto. Antes de comenzar cada ite-
n
raci´ n, el equipo reeval´ a las prioridades para la aplicaci´ n que est´ siendo construida;
o u o a
´
estas prioridades pueden haber cambiado durante la ultima iteraci´ n, as´ que podr´an ne-
o ı ı
cesitar alg´ n tipo de ajuste. Este enfoque se adapta a la perfecci´ n al desarrollo de un
u o
proyecto de software libre como el que se presenta en esta memoria: los usuarios de la
aplicaci´ n van informando de fallos o solicitando nuevas funcionalidades que el equipo
o
de desarrollo se encargar´ de atender.
a

14. 14 ´ ´
CAPITULO 1. INTRODUCCION
1.4.2. Ruby
Ruby3 es un lenguaje de programaci´ n libre, interpretado y orientado a objetos, creado por
o
el programador japon´ s Yukihiro Matsumoto en el a˜ o 1995. Sus creadores lo definen como un
e n
lenguaje de programaci´ n din´ mico y de c´ digo abierto enfocado en la simplicidad y produc-
o a o
tividad. Su elegante sintaxis se siente natural al leerla y f´ cil al escribirla.
a
Como lenguaje interpretado, Ruby no requiere de una fase de compilaci´ n, sino que usa
o
un int´ rprete (un programa que se ejecuta en el servidor web) que traduce el c´ digo fuente en
e o
lenguaje m´ quina sobre la marcha. Cada vez que se invoca un c´ digo (es decir, cada vez que se
a o
sirve una p´ gina web) el c´ digo es traducido.
a o
En Ruby todo es un objeto. Todos los tipos de datos son un objeto y todas las funciones son
m´ todos, y se le pueden asignar propiedades y acciones a toda informaci´ n y c´ digo.
e o o
Ruby es considerado un lenguaje flexible, ya que permite a sus usuarios alterarlo libremente.
Sus partes esenciales pueden ser quitadas o redefinidas a placer. Se puede agregar funcionalidad
a partes ya existentes.
Desde su liberaci´ n p´ blica en 1995, este lengaje ha ido atrayendo cada vez m´ s desarro-
o u a
lladores y, actualmente, cuenta con grupos de usuarios activos en las ciudades m´ s importantes
a
del mundo. Ruby-Talk, la lista te correo principal del lenguaje, recibe 200 mensajes diarios. El
´ndice TIOBE, que mide el crecimiento de los lenguajes de programaci´ n, ubica a Ruby en la
ı o
posici´ n n´ mero 13 del ranking mundial.
o u
1.4.3. ˜
El patr´ n de diseno MVC
o
Un patr´ n de dise˜ o en ingenier´a del software es un modelo formal que es aplicable a
o n ı
´
diferentes dominios. Existen problemas que, aunque pertenecen a distintos ambitos, son seme-
jantes desde el punto de vista de la estructura l´ gica de la soluci´ n. El patr´ n de dise˜ o es esta
o o o n
estructura com´ n que tienen diversas aplicaciones.
u
El patr´ n que sigue el framework Ruby on Rails, y que se ha utilizado en la construcci´ n de
o o
este proyecto, es el patr´ n Modelo Vista Controlador, conocido como patr´ n MVC. Este patr´ n
o o o
divide la aplicaci´ n en los siguientes componentes:
o
Modelo. Para manejar los datos y la l´ gica de negocio.
o
3
http://www.ruby-lang.org/es/

15. 1.4. RUBY ON RAILS 15
Controlador. Se encarga de redirigir un procesamiento determinado por cada petici´ n
o
recibida. Gestiona la l´ gica de la aplicaci´ n.
o o
Vista. Maneja los objetos gr´ ficos de la interfaz de usuario y se encarga de la l´ gica de la
a o
presentaci´ n.
o
Esta separaci´ n implica que una petici´ n de un usuario sea procesada como sigue:
o o
1. El navegador, desde el lado del cliente, env´a la petici´ n de una p´ gina al servidor, que
ı o a
ser´ atendida por el controlador apropiado.
a
2. El controlador recupera los datos necesarios del modelo para responder la petici´ n.
o
3. El controlador facilita dichos datos a la vista.
4. Se genera la vista correspondiente y se env´a al cliente para que se muestre en el navega-
ı
dor.
El proceso se ilustra en la siguiente figura:
Figura 1.2: Procesando una petici´ n de una p´ gina en la arquitectura MVC
o a
Dividir una aplicaci´ n software en estos tres componentes implica varias ventajas que pue-
o
den resumirse en los siguientes puntos:
Mejora la escalabilidad.
El mantenimiento es m´ s sencillo
a
Promueve la reutilizaci´ n
o

16. 16 ´ ´
CAPITULO 1. INTRODUCCION

17. Cap´tulo 2
ı
Objetivos
Una vez presentado el marco general de desarollo de este proyecto y las tecnolog´as utili-
ı
zadas, en este cap´tulo abordaremos los objetivos que se han perseguido durante la elaboraci´ n
ı o
del mismo. Se realizar´ una descripci´ n detallada del problema, se resumir´ , posteriormente, el
a o a
estudio de las distintas alternativas planteadas para su resoluci´ n y se mostrar´ , finalmente, la
o a
metodolog´a seguida en su desarrollo.
ı
Los objetivos principales del proyecto son:
El desarrollo de una aplicaci´ n libre que permita a cualquier docente, sin apenas cono-
o
cimientos inform´ ticos, crear, mantener y gestionar un sitio web donde aparezcan los
a
art´culos escritos por sus estudiantes en sus bit´ coras.
ı a
Formar una comunidad virtual alrededor del proyecto para conseguir que su desarrollo
sea autocatal´tico.
ı
2.1. Descripci´ n del problema
o
Como se ha visto en el cap´tulo de introducci´ n, los blogs y los planetas de blogs presentan
ı o
una serie de caracter´sticas que hacen de ellos aplicaciones con un gran potencial educativo.
ı
Es por ello que multitud de profesores est´ n intentando utilizarlos como herramienta did´ ctica
a a
para sus clases, aprovechando al m´ ximo estas caracter´sticas, pero sufriendo, por otra parte, el
a ı
hecho de que estas aplicaciones no fueron dise˜ adas pensando en la labor de los docentes.
n
Se ha presentado una experiencia docente de uso de blogs, llevada a cabo en diferentes
17

18. 18 ´
CAPITULO 2. OBJETIVOS
asignaturas de la Universidad Rey Juan Carlos, en la que los propios estudiantes participan en la
evaluaci´ n de los contenidos aportados por sus compa˜ eros, y se han explicado los problemas
o n
detectados que impiden que esta actividad pueda ser realizada por profesores de carreras no
relacionadas con la inform´ tica:
a
Es necesario contar con un servidor web donde instalar el paquete Planet.
Son imprescindibles conocimientos de administraci´ n de sistemas GNU/Linux, y cono-
o
cimientos de programaci´ n en HTML.
o
El alumnado debe enfrentarse al concepto de feed y ser capaz de identificar su URL.
Estas son las razones principales por las que se decide comenzar este proyecto, que nace con
el objetivo fundamental de desarrollar una aplicaci´ n que permita que cualquier docente pueda
o
realizar la actividad presentada. Los requisitos que se identificaron inicialmente para la primera
versi´ n de la aplicaci´ n fueron los siguientes:
o o
La aplicaci´ n debe permitir la creaci´ n y gesti´ n de un planeta que recoja los art´culos
o o o ı
publicados en los blogs de los estudiantes de una asignatura.
Los alumnos podr´ n darse de alta ellos mismos en el planeta.
a
Los estudiantes podr´ n valorar positivamente las historias m´ s interesantes.
a a
Debe implantarse alg´ n mecanismo que evite la suplantaci´ n de votos.
u o
Las estad´sticas de votos emitidos y recibidos deben estar disponibles.
ı
La instalaci´ n debe ser sencilla y la interfaz ser´ lo m´ s simple y amigable posible. La
o a a
aplicaci´ n no debe requerir apenas conocimientos inform´ ticos para su puesta en marcha.
o a
Se limitar´ n al m´ ximo los medios t´ cnicos necesarios para su desarrollo.
a a e
Se distribuir´ con una licencia libre.
a

19. 2.2. ESTUDIO DE ALTERNATIVAS 19
2.2. Estudio de alternativas
Desde el comienzo del proyecto desechamos la idea de comenzar un desarrollo desde ce-
ro. Dado que se deseaba implementar una aplicaci´ n libre, se decidi´ aprovechar el trabajo
o o
realizado por otros programas libres que incluyeran funcionalidades similares a las de nuestro
´
proyecto. Esta es una de las ventajas del software libre; pod´amos estudiar el c´ digo de otras
ı o
aplicaciones similares, coger ideas de c´ mo implementar ciertas partes de nuestro proyecto o,
o
incluso, reutilizar partes enteras del c´ digo de otros proyectos.
o
Veamos, por tanto, los diferentes proyectos que fueron estudiados, con sus ventajas e incon-
venientes.
2.2.1. Planet
´
Este programa muestra en una unica p´ gina web (el planeta) una referencia a las noticias
a
publicadas en los sitios web que se agreguen. Utiliza el Universal Feed Parser de Mark Pilgrim
para descargar contenido desde fuentes RDF, RSS o feeds de Atom y proporciona gran cantidad
de plantillas que permiten que se personalice el planeta con diferentes fuentes y colores.
Como se ha comentado, este programa, ligeramente modificado, era el que se estaba utili-
zando para realizar la actividad. La primera idea fue modificar de alguna forma este software
para que permitiera el registro del alumnado en el planeta y que incluyera la posibilidad de las
votaciones, y distribuir el nuevo programa como un paquete Debian para facilitar su instalaci´ n.
o
El problema fundamental de esta soluci´ n es que el docente que quisiera utilizarlo deber´a
o ı
contar con una m´ quina conectada a Internet donde pueda instalar nuestro programa. Esto cho-
a
ca, por una parte, con el requisito de no exigir conocimientos inform´ ticos y, por otra parte, con
a
la intenci´ n de no requerir hardware para su puesta en marcha. De hecho, aunque el docente
o
pudiera contar con una m´ quina conectada a Internet, es probable que no cuente con derechos
a
de administraci´ n sobre la misma, por lo que no podr´a instalar nuestro software. Esto ocu-
o ı
rre, por ejemplo, en los centros educativos p´ blicos no universitarios de Andaluc´a, donde los
u ı
ordenadores son administrados de forma centralizada por el Centro de Gesti´ n Avanzado.
o

20. 20 ´
CAPITULO 2. OBJETIVOS
2.2.2. Drupal
Drupal1 es un Sistema Gestor de Contenido libre, que permite publicar, gestionar y organizar
todo tipo de contenido (art´culos, im´ genes, u otros archivos) en un sitio web y ofrece servicios
ı a
a˜ adidos como foros, encuestas, votaciones, blogs y administraci´ n de usuarios y permisos.
n o
Drupal cuenta con una amplia comunidad de usuarios y desarrolladores, entre los que se ha
formado un grupo de profesores que han puesto a disposici´ n de la comunidad una distribuci´ n
o o
de Drupal lista para instalarla en un servidor, con todos los m´ dulos y extensiones necesarios
o
para que sea personalizada y se pueda crear un Planeta de Blogs. Algunas de las caracter´sticas
ı
de esta distribuci´ n que lo convert´an en un gran candidato son:
o ı
Instalaci´ n sencilla.
o
Plantilla o tema visual f´ cilmente personalizable gracias a su selector de color y al sistema
a
de bloques y men´ s de Drupal.
u
Documentaci´ n de ayuda incorporada y un foro para soporte.
o
Sistema anti-spam en formularios, comentarios, etc.
M´ dulo para la votaci´ n de los art´culos por los usuarios.
o o ı
Comunidad de usuarios y desarrolladores activa.
Figura 2.1: Planeta de blogs con Drupal
1
http://drupal.org/

21. 2.2. ESTUDIO DE ALTERNATIVAS 21
A pesar de sus ventajas, presentaba un inconveniente que chocaba con los requisitos de
no requerir conocimientos t´ cnicos ni hardware para la puesta en marcha de la actividad: es
e
necesario contar con un servidor web donde instalar la distribuci´ n de Drupal.
o
2.2.3. Feevy
Feevy2 es una aplicaci´ n web libre que permite a sus usuarios crear su propio blogroll
o
(colecci´ n de enlaces de blogs) de forma din´ mica, mostrando el contenido de los blogs que se
o a
agreguen a trav´ s de sus correspondientes feeds.
e
Su funcionamiento es muy sencillo:
1. El usuario se registra en el sitio web de Feevy.
2. A˜ ade la URL de los blogs que desea agregar.
n
3. Feevy genera una etiqueta HTML que el usuario debe pegar en su blog o en su sitio web.
a ı ´
4. A partir de ese momento se mostrar´ el t´tulo y un fragmento de los ultimos art´culos de
ı
los blogs agregados en una columna, que se actualizar´ din´ micamente colocando arriba
a a
el m´ s reciente.
a
Figura 2.2: Sitio web de Feevy
La idea de Feevy nos cautiv´ desde un principio: el usuario no necesita contar con ninguna
o
m´ quina para la actividad; tan s´ lo debe registrarse en un sitio web y contar con un blog donde
a o
pegar la etiqueta HTML generada.
2
http://feevy.com

22. 22 ´
CAPITULO 2. OBJETIVOS
Adem´ s, el proyecto presentaba una serie de caracter´sticas que hac´an que pudi´ ramos
a ı ı e
reutilizar gran parte de su c´ digo:
o
Se distribuye con la licencia libre GPL (GNU General Public License).
Se trata de una aplicaci´ n web que se encuentra en producci´ n. Muchas funcionalidades
o o
pod´an ser reutilizadas, como, por ejemplo, el registro de usuarios o la agregaci´ n de un
ı o
blog.
Es capaz de leer los feed de los blogs gratuitos m´ s populares.
a
Ha sido programada utilizando el framework Ruby on Rails siguiendo el patr´ n MVC.
o
Para a˜ adir un blog el usuario no necesita conocer la URL del feed.
n
Por otra parte, estudiando los usuarios de Feevy, se observ´ que exist´an muchos docentes
o ı
que hab´an comenzado a utilizarlo para crear un planeta con los blogs de sus alumnos, y que
ı
pod´an encontrarse en Internet turoriales que explicaban c´ mo ponerlo en marcha.
ı o
Por estas razones se decidi´ que Feevy ser´a el punto de partida para nuestra aplicaci´ n.
o ı o
Descargar´amos su c´ digo fuente y lo estudiar´amos para ver qu´ cosas pod´amos hacer como
ı o ı e ı
ellos y qu´ cosas deb´amos modificar para a˜ adir las funcionalidades deseadas.
e ı n
La decisi´ n estaba tomada, ofrecer´amos un servicio web, gratuito y libre, que permitiera
o ı
que cualquier docente pudiera crear y mantener un planeta de blogs (con soporte para votaciones
y estad´sticas) que le permitiera desarrollar la actividad presentada en el primer cap´tulo.
ı ı
2.3. Metodolog´a empleada
ı
El objetivo de aplicar una metodolog´a o modelo de desarrollo a la construcci´ n de una
ı o
aplicaci´ n software es convertir el desarrollo en un proceso formal, con resultados predecibles,
o
que permitan obtener un producto final de alta calidad, que satisfaga las necesidades y los
requisitos identificados.
El objetivo de este proyecto era lanzar una primera versi´ n de la aplicaci´ n que cumpliera
o o
con todos los requisitos planteados y conseguir una comunidad de usuarios que fuera aportando
informaci´ n al proyecto. Por un lado, los posibles fallos o vulnerabilidades del programa ser´an
o ı

23. ´
2.3. METODOLOGIA EMPLEADA 23
descubiertos y, por otra parte, los usuarios ir´an demandando nuevas funcionalidades para hacer
ı
de la aplicaci´ n un programa m´ s completo.
o a
Tras estudiar distintos modelos de desarrollo se decidi´ que se seguir´a, de forma parcial,
o ı
ı ´
la metodolog´a agil conocida como Programaci´ n Extrema (XP, Xtreme Programming)[8]. Esta
o
metodolog´a se adapta considerablemente al desarrollo de un proyecto como el que se pretende
ı
´
implementar, ya que hace enfasis en la adaptabilidad y la comunicaci´ n, y promueve el desa-
o
rrollo de peque˜ as iteraciones con nuevos requisitos.
n
En este cap´tulo se pretende exponer, por tanto, las bases de esta metodolog´a y c´ mo se ha
ı ı o
adaptado la misma para el desarrollo de este proyecto.
2.3.1. Programaci´ n Extrema
o
ı ´ ´
La Programaci´ n Extrema es una de las metodolog´as agiles m´ s existosas de los ultimos
o a
tiempos. Naci´ hace unos 8 a˜ os, y ha sido probada con exito en multitud de compa˜ ´as de
o n ´ nı
todos los sectores y tama˜ os por todo el mundo.
n
´
El exito de XP radica en que se centra en la satisfacci´ n del cliente. Esta metodolog´a est´ di-
o ı a
se˜ ada de manera que el cliente recibe el software que necesita en el momento que lo necesita.
n
XP anima a los desarrolladores a cambiar los requisitos sin importar el momento del ciclo de
vida del producto.
Esta metodolog´a tambi´ n se basa en el trabajo en equipo. Los gestores, los clientes y los
ı e
desarrolladores forman parte de un equipo dedicado a crear un software de calidad. XP intro-
duce una forma sencilla, pero efectiva, de lograr un estilo de desarrollo que implique a todo el
equipo.
XP se apoya en cinco principios fundamentales: simplicidad, comunicaci´ n, retroalimenta-
o
ci´ n (feedback), valent´a y respeto.
o ı
Simplicidad:
La simplicidad es la base de la programaci´ n extrema, y propone dos m´ ximas que reco-
o a
gen este principio: Haz la cosa m´ s simple que pueda funcionar y No lo vas a necesitar.
a
Al realizar modificaciones en el c´ digo por parte de diferentes desarrolladores la comple-
o
jidad aumenta severamente. Para mantener la simplicidad es necesaria la refactorizaci´ n
o
del c´ digo, es decir, modificar el c´ digo sin alterar el comportamiento. Tambi´ n se aplica
o o e

24. 24 ´
CAPITULO 2. OBJETIVOS
la simplicidad en la documentaci´ n; en el c´ digo s´ lo se comentar´ n las partes que no
o o o a
var´en (como el objetivo de un m´ todo), y se apostar´ por la autodocumentaci´ n, eligien-
ı e a o
do adecuadamente los nombres de las variables, m´ todos y clases.
e
Comunicaci´ n:
o
Muchos de los problemas que aparecen en los proyectos se deben a una mala comunica-
ci´ n. La programaci´ n extrema busca conseguir una comunicaci´ n constante.
o o o
Por una parte, la comunicaci´ n con el cliente es fluida ya que pertenece al equipo de
o
desarrollo. El cliente debe decidir las caracter´sticas y funcionalidades que tienen prio-
ı
ridad y siempre debe estar disponible para solucionar dudas. Por otro lado, el c´ digo es
o
otro instrumento de comunicaci´ n entre los programadores. Cu´ nto m´ s simple sea el
o a a
o a o ´
c´ digo mejor ser´ la comunicaci´ n. Por ultimo, las pruebas unitarias son otra forma de
comunicaci´ n ya que describen el dise˜ o de las clases y los m´ todos al mostrar ejemplos
o n e
concretos de c´ mo usar su funcionalidad.
o
Retroalimentaci´ n (feedback):
o
La retroalimentaci´ n ayuda a mantener el proyecto en el rumbo adecuado, por ello XP
o
propone t´ cnicas para conseguir feedback r´ pido y frecuente.
e a
La opini´ n del cliente respecto al estado del proyecto se conoce en tiempo real, ya que
o
forma forma parte del equipo de desarrollo. La generaci´ n constante de nuevas versiones,
o
con ciclos muy cortos, que muestran resultados de las nuevas caracter´sticas ayuda a no
ı
tener que deshacer parte del trabajo y volver a comenzar por cambios en los requisitos o
malentendidos con el cliente. Las pruebas unitarias proporcionan una gran retroalimenta-
ci´ n, informando de la correcci´ n del proyecto descubriendo posibles fallos.
o o
Valent´a:
ı
La valent´a es imprescindible para mostrar el sistema al cliente, con todos sus errores,
ı
para que pueda orientarnos y modificarlo a su gusto. Tambi´ n lo es para modificar el
e
c´ digo que funciona con el objetivo de hacerlo m´ s simple.
o a
Respeto:

25. ´
2.3. METODOLOGIA EMPLEADA 25
Todos los miembros del equipo de desarrollo deben respetarse y colaborar comport´ ndose
a
como uno s´ lo. Los programadores deben respetar el trabajo de otros programadores, y
o
deben respetar la opini´ n del cliente y de los usuarios.
o
Para concretar estos proncipios generales, XP propone una serie de pr´ cticas de las que
a
mostramos, a continuaci´ n, las m´ s importantes:
o a
Trabajar con el cliente: el cliente debe formar parte del equipo de desarrollo.
Planificaci´ n: la planificaci´ n se realiza en base a ciclos de desarrollo cortos (2 o 3 se-
o o
manas). Al comienzo de cada ciclo el cliente puede cambiar los requisitos, por lo que la
planificaci´ n se revisa continuamente.
o
Versiones peque˜ as: al final de cada ciclo hay que ofrecer al cliente una nueva mini-
n
o ´
versi´ n que muestre algo util al usuario final y no trozos de c´ digo que no pueda ver
o
funcionando.
Dise˜ o simple: hacer siempre lo m´nimo imprescindible de la forma m´ s sencilla posible,
n ı a
sin incluir partes que podamos necesitar en el futuro, se programa para hoy.
Met´ foras: los nombres de las clases, los m´ todos y las variables deben elegirse de manera
a e
que s´ lo con los nombres se pueda uno hacer una idea de qu´ es lo que hace cada parte
o e
del programa.
Pruebas autom´ ticas: las pruebas autom´ ticas son una excelente herramienta de comuni-
a a
caci´ n y feedback por lo que deben convertirse en una actividad b´ sica.
o a
Integraci´ n continua: cada modificaci´ n debe incluirse en el sistema final y probarse de
o o
forma conjunta.
Propiedad del c´ digo colectiva: todos los miembros del equipo pueden y deben modificar
o
y conocer cualquier parte del c´ digo.
o
Normas de codificaci´ n: debe haber un estilo com´ n de codificaci´ n de forma que parezca
o u o
´
que ha sido realizado por una unica persona.

26. 26 ´
CAPITULO 2. OBJETIVOS
La siguiente figura recoge todas las caracter´sticas mencionadas y resume c´ mo se integran los
ı o
aspectos fundamentales de la programaci´ n extrema:
o
Figura 2.3: eXtreme Programming
2.3.2. Aplicaci´ n de la Programaci´ n Extrema al proyecto
o o
Esta metolog´a se adapta considerablemente al proyecto que se presenta en esta memoria.
ı
Como ya se ha comentado, tras conseguir una primera versi´ n funcional de la aplicaci´ n, el
o o
objetivo era publicarla y promocionarla para conseguir una comunidad virtual a su alrededor
que ayudara al proyecto a crecer. La comunidad de usuarios de la aplicaci´ n (que, como vere-
o
mos, est´ formada por docentes de varias universidades e institutos) se ir´an encontrando con
a ı
peque˜ os errores, dificultades o nuevas nececesidades de las que informar´an a trav´ s de las
n ı e
herramientas preparadas para tal efecto, y el equipo de desarrollo se pondr´a a trabajar para
ı
solucionarlo.
De esta forma, la comunicaci´ n entre el cliente (los usuarios) y el equipo de desarrollo
o
tomar´ un papel fundamental que ir´ marcando la evoluci´ n de la aplicaci´ n. No existe un plan
a a o o
a priori de las nuevas funcionalidades a desarrollar o de los errores que corregir, estos van siendo
informados sin previo aviso, por lo que la adaptabilidad que propugna XP se convierte en un
factor imprescindible para nuestro proyecto.
As´, la idea de publicar cada pocas semanas nuevas mini-versiones (una versi´ n de la apli-
ı o
o n ´
caci´ n con peque˜ os cambios que ofrecen algo util al usuario) se adapta a la perfecci´ n a nuestra
o
situaci´ n.
o

27. ´
2.3. METODOLOGIA EMPLEADA 27
De igual forma, el concepto de equipo total defendido por XP puede aplicarse a la comu-
nidad del proyecto.
´
Por ultimo, cuando el objetivo de crear una comunidad que incluya varios desarrolladores
sea alcanzado, el trabajo en equipo y el respeto entre los miembros del equipo de desarrollo
que propone XP ser´ fundamental para que el proyecto pueda seguir creciendo. Cualquier desa-
a
rrollador podr´ modificar cualquier parte del c´ digo, aunque, como tambi´ n se defiende en XP,
a o e
habr´ que seguir unas normas de codificaci´ n de manera que se mantenga un estilo com´ n en
a o u
todo el c´ digo.
o

28. 28 ´
CAPITULO 2. OBJETIVOS

29. Cap´tulo 3
ı
Descripci´ n Inform´ tica
o a
En este cap´tulo se pretende mostrar, desde un punto de vista m´ s t´ cnico que el seguido
ı a e
hasta el momento, la estructura y el funcionamiento de la aplicaci´ n desarrollada.
o
Comenzaremos el cap´tulo con una secci´ n que describe la arquitectura utilizada para la
ı o
puesta en producci´ n de la aplicaci´ n, la organizaci´ n del c´ digo siguiendo el patr´ n MVC, el
o o o o o
modelo de la Base de Datos y, finalmente, algunos datos de inter´ s sobre la aplicaci´ n.
e o
Posteriormente, con el objetivo de acercar al lector al proceso de desarrollo seguido en su
implementaci´ n, se incluyen 3 secciones que representan las diferentes etapas del ciclo de vida
o
del proyecto:
Fase 1: Implementaci´ n de una versi´ n funcional de la aplicaci´ n.
o o o
Fase 2: Publicaci´ n de la aplicaci´ n y promoci´ n del proyecto.
o o o
Fase 3: Gesti´ n y evoluci´ n del proyecto.
o o
3.1. Estructura general de la aplicaci´ n
o
Como ya se ha explicado en los cap´tulos anteriores, tras estudiar varios proyectos libres se
ı
decidi´ seguir la l´nea del proyecto Feevy, adaptando su aplicaci´ n para que cumpliese nuestros
o ı o
requisitos.
De esta manera, se comenz´ a desarrollar una aplicaci´ n web que permitiera que cualquier
o o
docente, sin apenas conocimientos inform´ ticos, puediera llevar a cabo la actividad descrita en
a
el primer cap´tulo.
ı
29

30. 30 ´ ´ ´
CAPITULO 3. DESCRIPCION INFORMATICA
En el Anexo A puede encontrarse un manual de usuario en el que se detalla el funciona-
miento de la aplicaci´ n, que se resume en los siguientes pasos:
o
1. El docente se registra en nuestro sitio web.
2. Selecciona el idioma y personaliza la apariencia.
3. La aplicaci´ n genera una etiqueta HTML.
o
4. El docente pega la etiqueta en su blog o en su p´ gina web.
a
5. A partir de ese momento, los estudiantes pueden agregar su blog al planeta.
6. Los art´culos escritos en los blogs agregados ser´ n mostrados en el planeta.
ı a
7. Los estudiantes podr´ n votar los posts m´ s interesantes.
a a
8. Las estad´sticas de votos emitidos y recibidos podr´ n ser consultadas.
ı a
3.1.1. Arquitectura del entorno en producci´ n
o
La infraestructura necesaria para poder ofrecer el servicio descrito requiere contar con un
equipo conectado a Internet en el que se instale un servidor web, un servidor de aplicaciones
Rails y una Base de Datos.
Las posibilidades de elecci´ n son numerosas y, tras estudiar diferentes opciones, nos deci-
o
dimos por la siguiente arquitectura:
Como sistema operativo, se utilizar´a Debian GNU/Linux.
ı
Como servidor web, Apache.
Como servidor de aplicaciones Rails, mongrel.
Como SGBD, MySQL.
Como sistema de memoria cache, para reducir los accesos a la Base de Datos, nos deci-
dimos por memcached.

31. ´
3.1. ESTRUCTURA GENERAL DE LA APLICACION 31
Figura 3.1: Arquitectura del entorno de producci´ n
o
3.1.2. Patr´ n Modelo Vista Controlador
o
Como se explica en el cap´tulo de introducci´ n, el modelo de desarrollo seguido responde
ı o
al patr´ n MVC. As´, la estructura de directorios que marca el Framework de desarrollo Ruby
o ı
on Rails separa el c´ digo de cada uno de estos elementos almacen´ ndolos en diferentes ficheros
o a
de directorios separados. Puede observarse esta situaci´ n en la figura 3.2
o
Figura 3.2: Estructura de directorios siguiendo el Patr´ n MVC
o
En el subdirectorio controllers se almacenan los ficheros que se encargan de gestionar las
peticiones recibidas. Si para atender una petici´ n es necesario acceder a la informaci´ n almace-
o o
nada en la Base de Datos, el controlador implicado solicitar´ los datos al modelo apropiado (los
a

32. 32 ´ ´ ´
CAPITULO 3. DESCRIPCION INFORMATICA
modelos est´ n almacenados en el subdirectorio models). En ese momento se generar´ la vista
a a
oportuna (subdirectorio views) que devolver´ la p´ gina correspondiente.
a a
En el subdirectorio helpers se guardan peque˜ os trozos de c´ digo que ser´ n reutilizados
n o a
en diferentes partes de la aplicaci´ n. Un helper suele contener l´ gica de presentaci´ n relativa-
o o o
mente complicada, de manera que este c´ digo se saca de las vistas manteniendo su c´ digo m´ s
o o a
sencillo.
3.1.3. Modelo E/R de la Base de Datos
La figura 3.3 resume el modelo Entidad-Relaci´ n de la Base de Datos y muestra las entida-
o
des y las relaciones fundamentales de la aplicaci´ n:
o
Figura 3.3: Modelo E/R de la Base de Datos
La entidad Feed representa los blogs de los estudiantes y, como veremos en detalle en el
esquema, algunos de sus atributos son el t´tulo, la url o el nombre del estudiante que lo mantiene.
ı
La informaci´ n de los profesores se recoge en la entidad User; y los blogs agregados a un
o
planeta de un profesor se almacenar´ n en la entidad Subscriptions.
a
La informaci´ n relativa a los art´culos publicados en cada blog se recoge en la entidad Post,
o ı
y la entidad Vote representa cada voto emitido por un estudiante a favor de un post.
En la figura 3.4 pueden estudiarse en profundidad los atributos identificados en cada una de
las entidades utilizadas por la aplicaci´ n:
o

33. ´
3.1. ESTRUCTURA GENERAL DE LA APLICACION 33
Figura 3.4: Atributos de cada entidad
3.1.4. Otros datos de inter´ s
e
Los datos que se muestran en la figura 3.5 se han obtenido usando la herramienta SLOC-
Count1 , una aplicaci´ n libre que permite analizar proyectos software. Para ello, el programa
o
cuenta las l´neas f´sicas de c´ digo, separ´ ndolas por lenguajes, y realiza una estimaci´ n del
ı ı o a o
coste y del esfuerzo necesario para su desarrollo bas´ ndose en el modelo COCOMO (Modelo
a
Constructivo de Costes).
Figura 3.5: Datos obtenidos con SLOCCount
Llama la atenci´ n el dato relativo al coste estimado necesario para el desarrollo del proyecto,
o
que supera los 209.000 d´ lares, alrededor de 150.000 euros. La herramienta estima que hubiera
o
sido necesario el trabajo de 2,45 desarrolladores durante m´ s de 7 meses y medio para poder
a
completar el trabajo.
Por esta raz´ n se afirmaba en el cap´tulo de introducci´ n que el proyecto no habr´a podido
o ı o ı
llevarse a cabo en el tiempo previsto si no hubi´ ramos podido reutilizar el c´ digo y el trabajo de
e o
1
http://www.dwheeler.com/sloccount/

34. 34 ´ ´ ´
CAPITULO 3. DESCRIPCION INFORMATICA
´
otras aplicaciones libres. Esta es una de las grandes ventajas del software libre: la innovaci´ n.
o
Gracias a que el proyecto Feevy fue liberado, bas´ ndonos en su aplicaci´ n y realizando algunas
a o
modificaciones, hemos puesto a disposici´ n de docentes de todo el mundo una herramienta que
o
puede ayudarles en su trabajo diario. Adem´ s, nuestro proyecto tambi´ n es libre, por lo que,
a e
quiz´ s, alguien, en cualquier parte del mundo, podr´ reutilizar nuestro trabajo adapt´ ndolo a
a a a
sus necesidades y desarrollar una nueva herramienta que estar´ , de nuevo, a disposici´ n de toda
a o
la comunidad.
3.2. Fase 1: Implementaci´ n de una versi´ n funcional de la
o o
aplicaci´ n
o
En esta secci´ n pretenden mostrarse las tareas realizadas y las decisiones tomadas desde
o
que se comienza con el desarrollo de la aplicaci´ n hasta que se consigue una versi´ n beta que
o o
satisface los requisitos iniciales.
Tras tomar la decisi´ n de aprovechar el trabajo realizado por el equipo de desarrollo de
o
Feevy, la siguiente tarea fue realizar una instalaci´ n de la aplicaci´ n en un servidor propio para
o o
estudiar detenidamente su funcionamiento y su c´ digo.
o
En la web del proyecto aparec´a un enlace al c´ digo fuente y unas instrucciones que, tras
ı o
varios intentos de instalaci´ n frustrados, demostraron su invalidez. Se estableci´ contacto con
o o
David de Ugarte, uno de los l´deres del proyecto, el cual nos remiti´ a Alexandre Girard, el
ı o
desarrollador principal de Feevy. Alexandre, amable y pacientemente, nos ayud´ en el proceso
o
de instalaci´ n, gui´ ndonos en la soluci´ n de los problemas con los que nos encontramos. En
o a o
el Anexo B de esta memoria se han incluido algunos de los correos electr´ nicos enviados que
o
fueron intercambiados durante el proceso de instalaci´ n.
o
Algunos de los errores obtenidos se deb´an a que el c´ digo disponible conten´a errores que
ı o ı
hab´an sido modificados posteriormente pero no se hab´an incluido en el tarball descargable, por
ı ı
lo que, tras ser descubiertos, el equipo de desarrollo de Feevy tom´ nota y actualiz´ el c´ digo.
o o o
Una vez finalizado el proceso de instalaci´ n de Feevy en un servidor propio, y tras estudiar
o
el c´ digo fuente y la estructura de la Base de Datos, pod´amos comenzar su modificaci´ n de
o ı o
manera que cumpliera con los requisitos de nuestra aplicaci´ n.
o

35. ´ ´ ´
3.2. FASE 1: IMPLEMENTACION DE UNA VERSION FUNCIONAL DE LA APLICACION35
3.2.1. Modificaci´ n de la aplicaci´ n para el cumplimiento de los requisitos
o o
El primer paso consisti´ en la eliminaci´ n de las funcionalidades que no iban a ser utilizadas.
o o
Por ejemplo, en Feevy, al tratarse de una aplicaci´ n de ocio utilizada fundamentalmente por
o
adolescentes, cada blog se identifica con un avatar. En nuestra aplicaci´ n no se iban a usar estos
o
elementos, de manera que se procedi´ a su eliminaci´ n en el c´ digo y en la Base de Datos.
o o o
Tras la supresi´ n de todo lo que no ser´a usado, ten´amos una aplicaci´ n sobre la que co-
o ı ı o
menzar a a˜ adir las nuevas funcionalidades. Se resumen a continuaci´ n las tareas realizadas
n o
para implementar las principales caracter´sticas.
ı
Soporte para las votaciones
La aplicaci´ n deb´a ser modificada para que admitiera la posibilidad de que los estudiantes
o ı
valorasen positivamente las entradas de sus compa˜ eros. Se identificaron los siguientes requi-
n
sitos:
1. Cuando un usuario desee votar un art´culo, deber´ pinchar sobre el enlace ’vota este post’
ı a
que aparecer´ junto al mismo.
a
2. El usuario ser´ dirigido a una p´ gina en la que se mostrar´ el t´tulo del art´culo que va a
a a a ı ı
votar y se le solicitar´ que introduzca su correo electr´ nico.
a o
3. La aplicaci´ n enviar´ un correo electr´ nico al usuario inform´ ndole de que se ha recibido
o a o a
un voto en su nombre, de manera que se puedan detectar posibles suplantaciones de votos.
4. Se impedir´ que un usuario se vote a s´ mismo, que vote m´ s de una vez un mismo
a ı a
art´culo, o que un usuario vote por un blog que no pertenece a su asignatura.
ı
Para a˜ adir esta funcionalidad se realizaron las siguientes tareas:
n
Se cre´ la tabla votes en la Base de Datos.
o
n´
Se dise˜ o la vista new.rhtml, que permite a los estudiantes emitir un voto.
La vista notification/newvote.rhtml, que se generar´a al crear un voto para que se enviara
ı
un correo electr´ nico al usuario que estaba votando, fue dise˜ ada.
o n

36. 36 ´ ´ ´
CAPITULO 3. DESCRIPCION INFORMATICA
Posteriormente, se cre´ el controlador votescontroller.rb que se encargar´a de gestionar
o ı
las peticiones de creaci´ n de un nuevo voto. Se a˜ adi´ el m´ todo p´ blico create y el
o n o e u
m´ todo protegido check-vote, que se encarga de comprobar que se cumplen los requisi-
e
tos establecidos para poder enviar un voto. Se muestra a continuaci´ n el c´ digo de este
o o
m´ todo:
e
def check_vote
## Check that pupil is not voting himself
feed_id = Post.find_by_id(params[:id]).feed_id
if Feed.find_by_id(feed_id).mail == params[:mail]
return 2
end
## Check that pupil is not voting a post again
if Vote.count(:conditions =>
["mail = ? and post_id = ?",
params[:mail],params[:id]]) > 0
return 3
end
## Check that mail belongs to a verified student
subscription = Subscription.find(:first,
:conditions => ["feed_id = ?",
feed_id])
user_id = subscription.user_id
subs = []
subs = Subscription.find(:all,
:conditions => ["user_id = ?",
user_id])
subs.each do |s|
if s!=nil and s.feed !=nil and
s.feed.mail == params[:mail]
return 1
end
end
return 4
end
Para que apareciera el enlace ’vota este post’ junto a los art´culos publicados, hubo que
ı
modificar el modelo user.rb y las diferentes vistas que muestran el contenido de los blogs
agregados en funci´ n de los colores y el idioma elegido.
o

37. ´ ´ ´
3.2. FASE 1: IMPLEMENTACION DE UNA VERSION FUNCIONAL DE LA APLICACION37
Soporte para las estad´sticas
ı
Uno de los motivos por los que la actividad hab´a cosechado tan buenos resultados en las
ı
asignaturas donde se hab´a probado, era que los estudiantes pod´an consultar las estad´sticas de
ı ı ı
votos recibidos, de manera que se pod´a comprobar qu´ entradas del blog resultaban m´ s atrac-
ı e a
tivas para el resto de compa˜ eros. Del mismo modo, no hab´a muchos estudiantes a los que les
n ı
´
resultara atractivo el hecho de aparecer en los ultimos puestos del ranking, por lo que la motiva-
ci´ n para escribir buenos art´culos aparec´a de forma (casi) espont´ nea. Adem´ s, los profesores
o ı ı a a
utilizaban la informaci´ n de votos emitidos y recibidos para evaluar parte de la actividad.
o
Los requisitos identificados respecto a esta funcionalidad fueron los siguientes:
En cada planeta aparecer´ un enlace que llevar´ hasta la p´ gina con las estad´sticas.
a a a ı
Esta p´ gina de estad´sticas mostrar´ los votos recibidos por cada blog, los votos recibidos
a ı a
por cada post y los votos emitidos por cada alumno.
Las tareas llevadas a cabo para lograr este objetivo fueron los siguientes:
Se modific´ el controlador usercontroller.rb y las vistas que muestran los planetas de
o
forma que se mostrara un link que enlazara con la p´ gina de estad´sticas asociada a ese
a ı
planeta.
Se implement´ el m´ todo stats en el controlador usercontroller.rb que se encargar´a de
o e ı
gestionar las peticiones de las p´ ginas de estad´sticas, del que se muestra el c´ digo:
a ı o
def stats
@user = User.find(params[:id])
@pupils = @user.generate_stats_pupils(params[:tags])
@posts = @user.generate_stats_posts(params[:tags])
@blogs = @user.generate_stats_blogs(params[:tags])
partial_badge = "user/badge/content/stats"
partial_style = "user/badge/style/light"
partial_badge += "_" + @user.opt_lang.gsub(’-’,’_’)
logger.debug "partial_style: #{partial_style}"
logger.debug "partial_badge: #{partial_badge}"
@style =
render_to_string(:partial => partial_style,
:locals => { :id => params[:id]})
@style = "" if params[:style] == "open-css"

38. 38 ´ ´ ´
CAPITULO 3. DESCRIPCION INFORMATICA
@content =
render_to_string(:partial => partial_badge,
:locals => { :id => params[:id],
:posts => @posts,
:blogs => @blogs,
:pupils => @pupils} )
@stats = [@content, @style]
if request.env[’HTTP_ACCEPT’] =˜
/(application|text)/(html|xhtml)/
logger.debug @content.to_s
render :layout => true
end
end
En el modelo user.rb se a˜ adieron los m´ todos que realizan las consultas necesarias en la
n e
Base de Datos para obtener la informaci´ n de los votos emitidos y recibidos.
o
Se dise˜ aron las vistas en los distintos idiomas para mostrar estas estad´sticas, como
n ı
puede verse en la figura 3.6. Se decidi´ que se dividir´a la p´ gina en tres columnas que
o ı a
mostrar´an los votos que hab´a recibido cada blog, los votos recibidos por cada art´culo
ı ı ı
y los votos emitidos por cada alumno, respectivamente, y que se ordenar´a cada columna
ı
de mayor a menor n´ mero de votos.
u
Figura 3.6: Nueva p´ gina con las estad´sticas de votos emitidos y recibidos
a ı
Los estudiantes deben poder agregar sus blogs al planeta
En Feevy, cada usuario debe ir a˜ adiendo uno a uno todos los blogs que quiera incluir en
n
su planeta. En nuestra aplicaci´ n esta situaci´ n convertir´a la creaci´ n de un planeta en una
o o ı o

39. ´ ´ ´
3.2. FASE 1: IMPLEMENTACION DE UNA VERSION FUNCIONAL DE LA APLICACION39
tarea un tanto ardua si el n´ mero de alumnos de la asignatura fuera elevado: el profesor deber´a
u ı
que recibir la informaci´ n de las bit´ coras de cada estudiante (la url del blog, su nombre y su
o a
correo electr´ nico) y tendr´a que ir a˜ adi´ ndolos uno a uno, aumentando las posibilidades de
o ı n e
que produjera alg´ n error.
u
Con el objetivo de facilitar la puesta en marcha de la actividad, se decidi´ modificar nuestra
o
aplicaci´ n de forma que permitiera que los estudiantes pudieran agregar su blog sin intervenci´ n
o o
del docente.
Se modificaron las vistas de los distintos idiomas de manera que incluyera el texto Si eres
alumno de esta clase quiz´ s quieras dar de alta tu blog, a˜ adiendo el enlace correspondiente.
a n
Se implement´ el m´ todo new del controlador subscriptions-controller.rb que se encargar´a
o e ı
de gestionar las peticiones de agregaci´ n de un blog.
o
n´
Finalmente, se dise˜ o la vista views/subscriptions/new.rhtml, mostrada en la figura 3.7, que
permite que los alumnos puedan proporcionar los datos de su bit´ cora.
a
Se decidi´ incluir una nota que anima a los estudiantes a utilizar una licencia Creative Com-
o
mons para los contenidos publicados en sus bit´ coras, de forma que los aspectos relacionados
a
con la propiedad intelectual y el conocimiento libre se introducir´ n en el aula de forma natural.
a
Figura 3.7: Agregando un blog al planeta
Configurar FAVS como un planeta tradicional
o ´
En Feevy tan s´ lo se muestra el ultimo art´culo publicado en cada bit´ cora agregada y, por
ı a

40. 40 ´ ´ ´
CAPITULO 3. DESCRIPCION INFORMATICA
tanto, hubo que modificar la aplicaci´ n de manera que se comportara como un planeta tradicio-
o
nal mostrando todos los posts publicados en cada blog.
De hecho, aprovechando la funcionalidad ya implementada en Feevy, se decidi´ que se dar´a
o ı
la posibilidad de elegir al docente el n´ mero de art´culos mostrados por blog.
u ı
Figura 3.8: Eligiendo el n´ mero de art´culos mostrados por blog
u ı
3.2.2. Desarrollo del sitio web del proyecto
El sitio web es el elemento que proporciona la primera impresi´ n sobre el proyecto y de
o
´
su dise˜ o depende gran parte de su exito. Debe proporcionar visibilidad, es decir, debe dar a
n
conocer el proyecto a los usuarios y explicar el funcionamiento del servicio ofrecido[9]. Dado
que ser´ el primer contacto de cualquier persona con el proyecto, debe tener una estructura
a
adecuada y clara[7].
Identificamos varias secciones que la p´ gina principal deb´a contener: descripci´ n del ser-
a ı o
vicio, ejemplos de FAVS en acci´ n y ayuda.
o
En este paso tambi´ n se tuvo que tomar otra decisi´ n importante para el proyecto: ¿qu´ idio-
e o e
ma se usar´ en el sitio web del proyecto? Aunque la primera idea fue realizar una web en caste-
a
llano, finalmente se decidi´ , pensando en las posibilidades potenciales de atracci´ n de usuarios
o o
y desarrolladores, que la web estar´a en ingl´ s.
ı e
Se realizaron pruebas de uso con profesores de distintos niveles educativos y con diferentes
dominios del idioma ingl´ s que fueron muy satisfactorias. Se prepararon manuales de usuario
e
tanto en espa˜ ol como en ingl´ s que incid´an en los aspectos que hab´an resultado m´ s pro-
n e ı ı a
blem´ ticos en las pruebas.
a
La figura 3.9 es una captura de la p´ gina principal del sitio web desarrollado.
a