Favs

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 ı

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ćulos, ı 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ćulos 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ćulos m´ s interesantes. a o ı a

´ 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

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. Modiﬁcaci´ 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

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ćulos 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 ´ ´ 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á 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á mantener su propio blog en el que podá escribir sobre cualquier ı ı tem´ tica. Surgi´ una relaci´ n entre iguales en la que todos los usuarios podán 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ćulos 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ás 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 asignaturas 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

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án 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ćulos ı 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á proporcionar su nombre, su direcci´ n de correo el´ ctronico ı o e (que debá 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á 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 votar. Los datos de los votos se almacenaban en un fichero de texto que ı 1 http://www.planetplanet.org/

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ás. 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ńeas 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án 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á 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 ı

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 desarrolladores. 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á sido terminado sin esta posibilidad; los recursos (tanto econ´ micos ı o como humanos) necesarios para su desarrollo habrán 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 ´ ´ 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ćulos, 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á 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/

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á 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á 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án 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 ´ ´ 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 ńdice 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á 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/

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á 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á 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 ´ ´ CAPITULO 1. INTRODUCCION

Cap´tulo 2 ı Objetivos Una vez presentado el marco general de desarollo de este proyecto y las tecnologás 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á 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ćulos 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 ´ 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ćulos 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

2.2. ESTUDIO DE ALTERNATIVAS 19 2.2. Estudio de alternativas Desde el comienzo del proyecto desechamos la idea de comenzar un desarrollo desde cero. 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ámos 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 utilizando 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á 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á instalar nuestro software. Esto ocu- o ı rre, por ejemplo, en los centros educativos p´ blicos no universitarios de Andalucá, donde los u ı ordenadores son administrados de forma centralizada por el Centro de Gesti´ n Avanzado. o

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ćulos, 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án 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ćulos por los usuarios. o o ı Comunidad de usuarios y desarrolladores activa. Figura 2.1: Planeta de blogs con Drupal 1 http://drupal.org/

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 ´ CAPITULO 2. OBJETIVOS Adem´ s, el proyecto presentaba una serie de caracter´sticas que hacán 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án 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án muchos docentes o ı que habán comenzado a utilizarlo para crear un planeta con los blogs de sus alumnos, y que ı podán encontrarse en Internet turoriales que explicaban c´ mo ponerlo en marcha. ı o Por estas razones se decidi´ que Feevy será el punto de partida para nuestra aplicaci´ n. o ı o Descargarámos su c´ digo fuente y lo estudiarámos para ver qu´ cosas podámos hacer como ı o ı e ı ellos y qu´ cosas debámos modificar para a˜ adir las funcionalidades deseadas. e ı n La decisi´ n estaba tomada, ofrecerámos 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á empleada ı El objetivo de aplicar una metodologá 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án o ı

´ 2.3. METODOLOGIA EMPLEADA 23 descubiertos y, por otra parte, los usuarios irán 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á, de forma parcial, o ı ı ´ la metodologá agil conocida como Programaci´ n Extrema (XP, Xtreme Programming)[8]. Esta o metodologá 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á 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ás 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˜ ás 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á 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á 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 introduce 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á 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 ´ 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én (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 comunicaci´ 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 retroalimentaci´ n, informando de la correcci´ n del proyecto descubriendo posibles fallos. o o Valentá: ı La valentá 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:

´ 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ńimo 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 ´ 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á 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án encontrando con a ı peque˜ os errores, dificultades o nuevas nececesidades de las que informarán a trav´ s de las n ı e herramientas preparadas para tal efecto, y el equipo de desarrollo se pondrá 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

´ 2.3. METODOLOGIA EMPLEADA 27 De igual forma, el concepto de equipo total defendido por XP puede aplicarse a la comunidad 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 ´ CAPITULO 2. OBJETIVOS

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, ﬁnalmente, 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 ´ ´ ´ CAPITULO 3. DESCRIPCION INFORMATICA En el Anexo A puede encontrarse un manual de usuario en el que se detalla el funcionamiento 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.

´ 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 ´ ´ ´ 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ćulos 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

´ 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ńeas 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á 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 ´ ´ ´ 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á 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án a que el c´ digo disponible contená errores que ı o ı habán sido modificados posteriormente pero no se habán 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ámos comenzar su modificaci´ n de o ı o manera que cumpliera con los requisitos de nuestra aplicaci´ n. o

´ ´ ´ 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á usado, tenámos 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á 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ćulo, 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ćulo 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ćulo, 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á al crear un voto para que se enviara ı un correo electr´ nico al usuario que estaba votando, fue dise˜ ada. o n

36 ´ ´ ´ CAPITULO 3. DESCRIPCION INFORMATICA Posteriormente, se cre´ el controlador votescontroller.rb que se encargará 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ćulos 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

´ ´ ´ 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á cosechado tan buenos resultados en las ı asignaturas donde se habá probado, era que los estudiantes podán consultar las estad´sticas de ı ı ı votos recibidos, de manera que se podá comprobar qu´ entradas del blog resultaban m´ s atrac- ı e a tivas para el resto de compa˜ eros. Del mismo modo, no habá 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ćulos aparecá 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á 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 ´ ´ ´ 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á la p´ gina en tres columnas que o ı a mostrarán los votos que habá recibido cada blog, los votos recibidos por cada artćulo ı ı ı y los votos emitidos por cada alumno, respectivamente, y que se ordenará 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á la creaci´ n de un planeta en una o o ı o

´ ´ ´ 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á 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á 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á 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ćulo publicado en cada bit´ cora agregada y, por ı a

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á o ı la posibilidad de elegir al docente el n´ mero de artćulos mostrados por blog. u ı Figura 3.8: Eligiendo el n´ mero de artćulos 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á 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á 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án en los aspectos que habán 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

´ ´ ´ 3.2. FASE 1: IMPLEMENTACION DE UNA VERSION FUNCIONAL DE LA APLICACION41 Figura 3.9: P´ gina principal del sitio web de FAVS a Uno de los objetivos principales de la aplicaci´ n ha sido desde el principio el de la usabilidad[11]; o querámos que cualquier docente pudiera usar nuestro servicio aunque no tuviera muchos co- ı nocimientos de inform´ tica. Por ello, adem´ s de explicar con un texto el funcionamiento de a a la aplicaci´ n, se dise˜ aron otras p´ ginas, como la p´ gina faq o la p´ gina scheme, que intentan o n a a a describir de una forma sencilla y gr´ fica los pasos necesarios para disfrutar del servicio ofrecido. a ´ El primer objetivo del sitio web estaba cubierto: resultaba muy util para un usuario que quisiera comenzar a utilizar la aplicaci´ n, ya que contaba con documentaci´ n y p´ ginas gr´ ficas o o a a que explicaban su uso y funcionamiento. Sin embargo, no era suficiente para aquellos usuarios que quisieran informar de incidencias o solicitar nuevas caracter´sticas, ni ofrecá soporte para ı ı los posibles colaboradores. Con el objetivo de dotar al proyecto de las herramientas necesarias para crear y potenciar una comunidad a su alrededor se decidi´ registrar el proyecto en Sourceforge. Sourceforge.net es o el sitio web de desarrollo de software libre m´ s grande del mundo, albergando en la actualidad a

42 ´ ´ ´ CAPITULO 3. DESCRIPCION INFORMATICA m´ s de 230.000 proyectos y m´ s de 2.000.000 de usuarios. a a Este sitio permite que el proyecto cuente con todas las herramientas necesarias: foros, listas de correo, sistema de seguimiento de errores, sistemas de control de versiones, descarga de ´ software, utimas noticias y solicitud de nuevas funcionalidades. Figura 3.10: El sitio de FAVS en SourceForge 3.2.3. Elecci´ n de la licencia o La licencia de una aplicaci´ n establece las normas con las que se regir´ su distribuci´ n, uso, o a o modificaciones e incluso las redistribuciones del software. Feevy fue liberado bajo la licencia GPL2 (GNU General Public License). Esto implica que podámos estudiar el c´ digo, hacer modificaciones y redistribuirlas, pero obliga a que estas ı o modificaciones se distribuyan tambi´ n bajo los mismos t´ rminos. e e ´ Es esta la principal caracter´stica de la GPL, y del resto de licencias conocidas como robustas ı o copyleft, ya que aseguran que la naturaleza del software creado siempre ser´ libre, evitando a que el autor de un programa libre pueda tener que competir con versiones modificadas privativas su propio trabajo. 3.2.4. Puesta en marcha de la aplicaci´ n o La Universidad Rey Juan Carlos puso a nuestra disposici´ n una m´ quina con conexi´ n a o a o Internet mediante una direcci´ n IP est´ tica. o a 2 http://www.gnu.org/copyleft/gpl.html

´ 3.3. FASE 2: PROMOCION DEL PROYECTO 43 Se realizaron las instalaciones y configuraciones oportunas para conseguir la infraestructura presentada en la secci´ n 3.1.1 y se registr´ el dominio favs.homelinux.org, redirigiendo el tr´ fico o o a a la direcci´ n IP del ordenador de la Universidad. o Se instal´ el servidor de correo electr´ nico sendmail necesario para el correcto funciona- o o miento de la aplicaci´ n, realizando las configuraciones oportunas. o La versi´ n beta estaba lista para comenzar a ser utilizada. o 3.3. Fase 2: Promoci´ n del proyecto o Tras haber implementado la versi´ n beta de la aplicaci´ n y haber preparado una m´ quina o o a para ofrecer el servicio, comenzaba una nueva etapa en el ciclo de vida del proyecto: habá ı que promocionar la aplicaci´ n para conseguir una comunidad de usuarios que nos informase o de las dificultades, problemas o mejoras que detectaran o, incluso, nuevos desarrolladores que quisieran colaborar con el proyecto. El objetivo de esta nueva etapa era conseguir el fen´ meno o conocido como efecto en red[10]: conseguir usuarios y desarrolladores suele ser el primer paso para conseguir m´ s usuarios y m´ s desarrolladores. a a Esta fase puede resumirse como una campa˜ a publicitaria para dar a conocer nuestro pro- n yecto. Las tareas realizadas se detallan a continuaci´ n: o Comunicamos a David de Ugarte, uno de los l´deres del proyecto Feevy, que ya tenámos ı ı lista una primera versi´ n. La reacci´ n de David fue m´ s que satisfactoria para nosotros. o o a ´ El habá publicado en su blog3 un artćulo titulado Por qu´ liberar Feevy no aporta gran ı ı e cosa, en el que afirmaba que estaba convencido de que liberar el c´ digo de Feevy no iba a o suponer algo positivo para la comunidad. Tras recibir la noticia del nacimiento de FAVS, David nos pidi´ permiso para publicar el correo electr´ nico que le enviamos y public´ un o o o nuevo artćulo en su blog titulado Liberar software siempre paga, que comienza as´: ı ı Feevy ha tenido un cachorrito orientado al trabajo escolar. Se llama FAVS -como nuestra gran amiga curitibense- y est´ a escrito por Jes´s Moreno. Feevy comienza a dar frutos. u Frutos para el dominio p´blico. Para todos. u Jes´s Moreno, nos escribá esta maãna: u ı n 3 www.deugarte.com

44 ´ ´ ´ CAPITULO 3. DESCRIPCION INFORMATICA Como os coment´ este verano, para mi proyecto fin de m´ster e a he comenzado a desarrollar una aplicaciń web basada en o feevy. Se llama FAVS, y es una aplicaciń que est´ pensada o a para profesores. La idea es que el profe pueda tener en su blog o en su sitio web las entradas que publican sus alumnos en sus bitćoras. a Dimos de alta el proyecto en Freshmeat4 , un portal dedicado a informar de las ultimas ´ noticias, actualizaciones y versiones de programas libres. Nos pusimos en contacto con los responsables de la secci´ n de software libre de Educa- o red5 , una fundaci´ n que impulsa el uso de Internet en la educaci´ n, quienes publicaron o o un reportaje sobre la aplicaci´ n. o Figura 3.11: Reportaje sobre FAVS en Educared Enviamos una petici´ n de participaci´ n a la Conferencia sobre Software de Libre en Edu- o o caci´ n Superior de Valencia y fuimos seleccionados para impartir una de las conferencias. o Nuestra participaci´ n consigui´ los objetivos propuestos, ya que, gracias a la ponencia6 o o impartida, el Departamento de Filologá Inglesa de la Universidad de Valencia se in- ı teres´ por nuestra aplicaci´ n y nos solicit´ informaci´ n y ayuda para poner en marcha la o o o o actividad descrita en el siguiente curso acad´ mico. e 4 http://freshmeat.net/ 5 www.educared.net/ 6 http://aulavirtual.uv.es/ficheros/view/slides/presentacion.pdf

´ 3.3. FASE 2: PROMOCION DEL PROYECTO 45 Se envi´ un artćulo sobre la aplicaci´ n al espacio Innovando con las TIC7 de la Junta de o ı o Andalucá. ı Nos registramos en el sitio Aulablog, una comunidad de profesores que usan las TIC en su pr´ ctica diaria, y envámos un artćulo8 que ha tenido m´ s de 750 lecturas. a ı ı a Figura 3.12: Artćulo sobre FAVS en AulaBlog ı Se cre´ la p´ gina FAVS en la Wikipedia, y se incluyeron enlaces a nuestro sitio web en o a p´ ginas relacionadas (como la p´ gina que habla de los planetas de blogs). a a Se escribieron rese˜ as y se enviaron artćulos a otras webs como Men´ ame, Internet en n ı e el Aula o Profeblog, y se enviaron correos electr´ nicos a profesores que imparten cursos o sobre las nuevas tecnologás aplicadas a la educaci´ n en facultades o centros de formaci´ n ı o o del profesorado. Como consecuencia de esta campa˜ a de promoci´ n del proyecto los primeros usuarios se n o registraron en nuestro sitio. ¡El efecto en red habá comenzado! ı Una muestra es el artćulo Participa en los planetas de blogs de aula9 , escrito por Alejandro ı a ´ Valero, en su bit´ cora Apuntes sobre blogs. En el, el autor explica qu´ son los planetas de blogs e y presenta distintas herramientas para su creaci´ n, entre las que destaca a nuestro proyecto. o Alejandro Valero es autor del taller Creaci´ n y uso educativo de blogs que se llev´ a cabo o o ´ en el marco del ultimo Congreso Nacional Internet en el Aula. 7 http://www.juntadeandalucia.es/averroes/espaciotic/spip.php?article46 8 http://www.aulablog.com/favs-planetas-de-blogs-docentes 9 http://avalerofer.blogspot.com/2009/04/participa-en-los-planetas-de-blogs-de.html

46 ´ ´ ´ CAPITULO 3. DESCRIPCION INFORMATICA Figura 3.13: Artćulo de Alejandro Valero sobre Planetas de blogs ı Otro ejemplo es el artćulo Planeta FAVS - vota el mejor post10 escrito por la profesora ı Amelia Tierno tras haber comenzado a utilizar FAVS para sus clases en el IES Ignacio Ellacurá: ı Figura 3.14: Artćulo de Amelia Tierno sobre FAVS ı 3.4. Fase 3: Gesti´ n y evoluci´ n del proyecto o o Tras la campa˜ a publicitaria realizada, los usuarios comenzaron a registrase en el sitio web n y a utilizar la aplicaci´ n para sus clases. En el cap´tulo 4 se hace un estudio m´ s detallado de o ı a esta comunidad de usuarios, pero podemos adelantar que est´ compuesta por docentes de varias a universidades espa˜ olas e institutos de diferentes paises. n En su labor diaria, estos profesores se iban encontrando con problemas, errores o carencias de la aplicaci´ n, y nos las fueron haciendo llegar, fundamentalmente, a trav´ s de correos o e 10 http://auladetecnologias.blogspot.com/2009/05/planeta-favs-vota-el-mejor-post.html

´ ´ 3.4. FASE 3: GESTION Y EVOLUCION DEL PROYECTO 47 o ´ electr´ nicos. Esta ultima secci´ n recoge las tareas realizadas para corregir los errores (o bugs) o que presentaba nuestro servicio y las nuevas funcionalidades y caracter´sticas que se a˜ adieron ı n tras ser demandadas por la comunidad. 3.4.1. Bugs Enlaces err´ neos o Aunque se habán realizado bastantes pruebas con muchos tipos de blogs, cuando comenz´ a ı o utilizarse en producci´ n, los usuarios nos hicieron saber que los enlaces a los artćulos publica- o ı dos en ciertos blogs no eran correctos. Tras estudiar el caso descubrimos que todos los blogs implicados se habán creado en Blog- ı ger11 , una herramienta de publicaci´ n de blogs gratuita de Google. Sin embargo, no todos los o blogs de Blogger presentaban este problema. Tras mucho investigar descubrimos que el problema estaba con el formato de redifusi´ n o Atom utilizado por Blogger. Hasta el final del verano habá funcionado correctamente, por eso ı las pruebas realizadas habán sido satisfactorias. Tras el verano se habán producido algunos ı ı cambios y hubo que modificar la url del feed que ofrecá la gema rfeedfinder (que se encarga de ı buscar los feeds): En lugar de usar la url http://sw-libre.blogspot.com/atom.xml habá que utilizar la direcci´ n ı o http://sw-libre.blogspot.com/feeds/posts/default?alt=rss Programamos un script (del que mostramos el c´ digo a continuaci´ n) que se encarg´ de o o o modificar los datos de los blogs ya almacenados en la Base de Datos y modificamos el c´ digo o del m´ todo create-feed del modelo feed.rb para que guardara la url correcta. e #!/usr/bin/env ruby RAILS_ENV = ’production’ require File.dirname(__FILE__) + ’/../config/boot’ require "#{RAILS_ROOT}/config/environment" feeds = [] feeds = Feed.find(:all) blogger = "blogspot" feeds.each do |feed| 11 http://www.blogger.com

48 ´ ´ ´ CAPITULO 3. DESCRIPCION INFORMATICA if feed.link.include? blogger feed.link = feed.href + "feeds/posts/default?alt=rss" feed.save end end Artćulos repetidos en el planeta ı El error m´ s molesto para los usuarios y que m´ s dificultades ha presentado para su soluci´ n a a o ha sido que, en ciertas ocasiones, en algunos planetas comenzaban a repetirse dos artćulos de ı un blog, y se almacenaban una y otra vez en la base de datos, llenando el planeta de posts repetidos. La primera vez que ocurri´ , cuando el usuario nos avis´ del problema, se detuvo la actua- o o lizaci´ n del planeta para que no siguiera almacenando los artćulos y se borraron de la base de o ı datos todos los posts repetidos. Para actualizar los artćulos publicados en los blogs hay un script que se ejecuta constan- ı temente, el script update-feeds, que realiza una llamada al m´ todo refresh del modelo feed.rb. e ı ´ Este m´ todo obtená los datos del ultimo post publicado (a trav´ s del m´ todo read-first del mo- e e e ´ delo Rfeedreader) y comparaba su t´tulo con el del ultimo post de ese blog almacenado en la ı base de datos. Si eran distintos, creaba un nuevo post con los datos del Rfeedreader. Se modific´ este m´ todo para que no s´ lo comprobara el t´tulo, sino que tambi´ n comparara o e o ı e la url de los posts en cuesti´ n. o Se lanz´ de nuevo el script update-feeds y todo comenz´ a funcionar correctamente. o o Pens´ bamos que habámos solucionado el problema, pero alg´ n tiempo despu´ s otro usuario a ı u e nos avis´ de que se le habá surgido la misma incidencia o ı Comparamos los blogs que habán presentado esta incidencia pero habán sido creados con ı ı diferentes herramientas por lo que sospechamos que el problema estaba en nuestro programa. Finalmente, el m´ todo refresh fue modificado para que comprobara los datos obtenidos del e Rfeedreader con los de todos los posts de ese blog almacenados en la base de datos, y el c´ digo o queda como se presenta a continuaci´ n: o def refresh(forced=false) historias = [] encontrado = 0

´ ´ 3.4. FASE 3: GESTION Y EVOLUCION DEL PROYECTO 49 begin Timeout::timeout(30) do entry = Rfeedreader.read_first(link).entries[0] if !entry.nil? and !entry.link.nil? if (forced or latest_post.nil?) Post.create(:url => entry.link, :title => entry.title, :description => entry.description, :feed_id => id) else historias = posts historias.each do |post| if entry.title == post.title or entry.link == post.url encontrado = 1 break end end if encontrado == 0 Post.create(:url => entry.link, :title => entry.title, :description => entry.description, :feed_id => id) end end end rescue Timeout::Error rescue => err end end 3.4.2. Petici´ n de nuevas caracter´sticas o ı Al utilizar la aplicaci´ n los usuarios se han ido encontrado con ciertas carencias o con al- o gunas funcionalidades no implementadas que les ayudar´an en su labor diaria. La ﬁgura 3.15 es ı una captura de la secci´ n de petici´ n de nuevas caracter´sticas (Feature Requests) del proyecto o o ı en SourceForge:

50 ´ ´ ´ CAPITULO 3. DESCRIPCION INFORMATICA Figura 3.15: Feature Requests Los docentes necesitan editar los datos de sus alumnos La primera caracter´stica que fue solicitada era que los docentes pudieran editar los datos de ı los alumnos que se han inscrito en el planeta. Si un alumno introducá su correo electr´ nico con ı o alg´ n error (o con un espacio al final, por ejemplo), cuando intentaba votar y se le solicitaba su u e-mail, la aplicaci´ n no le permitá emitir el voto. o ı Se modific´ el controlador manage-controller a˜ adiendo el m´ todo edit-student que se en- o n e carga de actualizar los cambios realizados en los datos de los alumnos (la url del blog, su correo y su nombre) llamando al m´ todo update-attributes del modelo feed.rb. e n´ Se dise˜ o la vista edit-student.rhtml que muestra los datos del estudiante seleccionado para su posible modificaci´ n, de la que se muestra una captura en la figura 3.16. o Figura 3.16: Editando los datos de un estudiante Los profes quieren votar En un principio s´ lo los estudiantes que habán agregado su blog al planeta podán votar las o ı ı

´ ´ 3.4. FASE 3: GESTION Y EVOLUCION DEL PROYECTO 51 entradas del resto de compa˜ eros. Sin embargo, algunos profesores nos hicieron saber que les n gustará poder emitir votos para premiar los posts que les resultaban interesantes. ı Se modific´ el m´ todo check-vote del controlador votes-controller para permitir esta situa- o e ci´ n a˜ adiendo una nueva comprobaci´ n: o n o subscription = Subscription.find(:first, :conditions => ["feed_id = ?", feed_id]) user_id = subscription.user_id if User.find_by_id(user_id).email == params[:mail] return 5 end Descargar las estad´sticas de votos ı a n ı ´ Las p´ ginas dise˜ adas para mostrar las estad´sticas resultan muy utiles para consultar las historias m´ s votadas o los estudiantes m´ s activos, pero cuando los docentes querán descargarlas a a ı para utilizarlas en la evaluaci´ n de la actividad se encontraban con ciertos impedimentos. o Se decidi´ a˜ adir la posibilidad de que las estad´sticas fueran descargadas en un fichero o n ı CSV, del ingl´ s comma-separated values, un tipo de documento muy sencillo para representar e datos en forma de tabla y que puede ser editado con las hojas de c´ lculo m´ s populares. a a Se modificaron las vistas de las p´ ginas de estad´sticas de los distintos idiomas para incluir a ı este enlace y se implement´ el controlador report-controller.rb que incluye el m´ todo users que o e se encarga de gestionar estas peticiones: def users @user = User.find(params[:id]) @blogs = @user.generate_stats_blogs(params[:tags]) stream_csv do |csv| csv << ["student","mail","votes_received", "votes_cast" ] @blogs.each do |u| csv << [u [:pupil],u [:mail],u [:votes], u[:votes_cast]] end end end

52 ´ ´ ´ CAPITULO 3. DESCRIPCION INFORMATICA 3.4.3. Un nuevo desarrollador Desde el mes de abril, Jes´ s S´ nchez, un estudiante del Ciclo Formativo de Grado Superior u a de Administraci´ n de Sistemas Inform´ ticos del IES Gonzalo Nazareno de Dos Hermanas (Se- o a villa), comenz´ a colaborar con FAVS en el marco del desarrollo de su Proyecto Integrado (el o proyecto final del ciclo). Comenzaba una nueva etapa para FAVS; el equipo de desarrollo contaba con un nuevo developer por lo que habá que dotar al proyecto de nuevas herramientas: ı Hasta la fecha, aunque el c´ digo fuente de la aplicaci´ n estaba disponible para su des- o o carga, no se habá configurado un CVS p´ blico donde escribir los cambios. En la nueva ı u situaci´ n esta herramienta resultaba imprescindible para que el equipo de desarrollo pu- o diera trabajar de forma conjunta. Se cre´ una lista de correo, favs-developers, en la que se llevarán a cabo los intercambios o ı de ideas entre los desarrolladores de manera que toda la informaci´ n contenida en los o debates no se perdiera y quedara disponible para la comunidad. Tras instalarse en una m´ quina propia un entorno como el que se describe en la secci´ n 3.1.1, a o la primera tarea que llev´ a cabo fue la de poner a disposici´ n de los usuarios m´ s idiomas en o o a los que mostrar los planetas. En un principio, tan s´ lo podá trabajarse con castellano e ingl´ s, o ı e y Jes´ s prepar´ las vistas necesarias para ofrecer soporte, tambi´ n, en franc´ s e italiano. u o e e En la actualidad Jes´ s se encuentra trabajando en la implementaci´ n de una nueva funciona- u o lidad que ha sido solicitada por un profesor de un instituto de Sevilla. Este profesor nos contaba o ´ en un correo electr´ nico que el ha montado un planeta en el que incluye todos los artćulos de ı sus estudiantes, pero que le gustará que en una columna de la p´ gina principal de la asignatura ı a o ı ´ aparecieran tan s´ lo el nombre de cada blog y el t´tulo del ultimo post publicado. Puede seguirse la evoluci´ n de la implementaci´ n de esta nueva caracter´stica en la lista de o o ı correo de desarrolladores del proyecto.

Cap´tulo 4 ı Conclusiones Una vez descritos los objetivos del proyecto y analizada la soluci´ n desarrollada, esta me- o moria termina resumiendo los principales logros alcanzados y proponiendo posibles trabajos futuros. 4.1. Logros alcanzados A partir del desarrollo de este proyecto se ha puesto a disposici´ n de los docentes de todo o el mundo una herramienta libre que permite, sin exigir apenas conocimientos inform´ ticos, que a cualquier profesor pueda crear, mantener y gestionar un planeta que enlace las historias publicadas por sus alumnos en sus blogs. Los estudiantes podr´ n valorar las historias m´ s interesantes a a y las estad´sticas de votos emitidos y recibidos estar´ n disponibles. ı a Consideramos que esta aplicaci´ n puede ser utilizada por docentes de todos los niveles o educativos, ya que introduce en el aula aspectos relacionados con la propiedad intelectual y el conocimiento libre, propicia la creaci´ n y el intercambio de conocimiento y potencia las o habilidades de redacci´ n de los estudiantes motivando una sana competici´ n por escribir los o o art´culos m´ s interesantes. ı a Se ha conseguido crear una comunidad de usuarios del proyecto que informa de los problemas y carencias que detectan en la aplicaci´ n y ha comenzado el proceso de adhesi´ n de nuevos o o desarrolladores, por lo que todos los objetivos descritos en el cap´tulo 2 han sido alcanzados con ı ´ exito. La lista que se muestra a continuaci´ n incluye las universidades, institutos, escuelas o enti- o 53

54 ´ CAPITULO 4. CONCLUSIONES dades que, por haber establecido contacto con nosotros, o por el correo electr´ nico registrado o en la base de datos, tenemos constancia de que est´ n usando nuestro servicio: a Universitat Oberta de Catalunya. Universidad Rey Juan Carlos. Universidad de Valencia. IES Mará Moliner, Sevilla. ı IES Gonzalo Nazareno, Dos Hermanas, Sevilla. IES Las Galletas, Arona, Tenerife. IES Ignacio Ellacurá, Madrid ı IES Eduard Fontser` , L’hospitalet de Llobregat, Barcelona. e Colegio Nacional Mariano Melgar, Per´ . u Escuela Especial no 1383, Rosario, Argentina. Planeta Educativo Profeblog 4.2. Posibles trabajos futuros Aunque los objetivos descritos en el cap´tulo segundo han sido alcanzados y, por tanto, ı el desarrollo de este trabajo final de m´ ster se da por finalizado, estamos seguros de que el a proyecto va a seguir creciendo y evolucionando. La comunidad de usuarios que se ha formado a su alrededor seguir´ detectando nuevas necesidades que, esperamos, ser´ n implementadas por a a el equipo de desarrolladores, a˜ adiendo funcionalidad y nuevas caracter´sticas. n ı Planteamos algunas posibles lńeas de desarrollo futuro: ı 1. Dotar a la aplicaci´ n de la capacidad de detectar votaciones enga˜ osas. Un ejemplo de o n votaci´ n enga˜ osa se da si un estudiante vota 10 artćulos en 1 minuto, ya que parece o n ı

4.2. POSIBLES TRABAJOS FUTUROS 55 dif´cil que los haya le´do. O, por ejemplo, cuando 2 estudiantes se votan constantemente ı ı el uno al otro. 2. Detectar plagios de forma autom´ tica antes de a˜ adir un nuevo art´culo en la Base de a n ı datos. 3. Facilitar la gesti´ n de los distintos planetas de un docente. Aunque esta posibilidad existe o en la actualidad, como se explica en el Anexo A, resulta un tanto inc´ moda si el n´ mero o u de estudiantes es elevado. 4. Permitir la posibilidad de que los docentes que no tengan blog o sitio web puedan elegir alg´ n tipo de plantilla y que nuestro sitio albergue sus planetas. u

56 ´ CAPITULO 4. CONCLUSIONES

Anexo A Breve manual de usuario de FAVS Para crear un planeta con FAVS, el profesor tan s´ lo debe registrarse en la web o http://favs.homelinux.org, eligiendo un nombre de usuario y una contrase˜ a y proporcionando n su direcci´ n de correo electr´ nico. o o Figura A.1: El docente se registra En ese momento FAVS genera una etiqueta HTML que el profesor colocar´ en su blog o en a su p´ gina web. A continuaci´ n, el planeta puede personalizarse, eligiendo el idioma (ingl´ s o a o e espa˜ ol), los art´culos mostrados (decidiendo si se mostrar´ n todos los post de cada alumno o n ı a ´ s´ lo el ultimo) y el estilo y los colores. o 57

58 ANEXO A. BREVE MANUAL DE USUARIO DE FAVS Figura A.2: FAVS genera la etiqueta HTML Una vez que el docente ha pegado la etiqueta HTML en su sitio web, los estudiantes de la asignatura podr´ n darse de alta en el planeta pinchando en el enlace que aparecer´ en el planeta. a a Figura A.3: El blog del docente al pegar la etiqueta HTML Los datos que se solicitan al estudiante son la URL de su blog, su nombre y su correo electr´ nico. o

59 Figura A.4: Agregando un blog al planeta Al registrar su blog, FAVS pregunta al alumno si ha elegido una licencia para los contenidos de su bit´ cora, y lo anima a utilizar una licencia Creative Commons. A partir de ese momento, a en la web del profesor aparecer´ un resumen de los artćulos que escriba cada estudiante en su a ı bit´ cora, junto con su fecha de publicaci´ n, un enlace para leer el post completo y un enlace a o para votar esa historia. Figura A.5: Los posts publicados en los blogs de los estudiantes se enlazan en el planeta Cuando un estudiante decide votar una historia, FAVS solicita su correo electr´ nico y com- o prueba que el alumno pertenece a esa asignatura, que no ha votado ya por ese artćulo y que no ı se est´ votando a s´ mismo. Con el objetivo de detectar posibles votos falsos, la aplicaci´ n envá a ı o ı

60 ANEXO A. BREVE MANUAL DE USUARIO DE FAVS un comprobante por correo electr´ nico en el que se indica que se acaba de votar una noticia y o se insta a contactar con los profesores en el caso de que no sea as´. ı Figura A.6: Votando un artćulo ı Tanto los estudiantes como el docente pueden consultar en cualquier momento las estad´sti- ı cas de votos acumuladas. Estas estad´sticas muestran los votos recibidos por cada blog, los votos ı recibidos por cada artćulo y los votos emitidos por cada alumno. ı Figura A.7: Estad´sticas de votos recibidos y emitidos ı Aunque los estudiantes pueden agregar sus bit´ coras al planeta, el docente tambi´ n tiene la a e posibilidad de a˜ adir los blogs que desee. Para ello tan s´ lo debe seguir el enlace add another n o blog del panel de gesti´ n de FAVS tras identificarse en la aplicaci´ n. o o

61 Figura A.8: Los docentes pueden a˜ adir blogs al planeta n En el panel de gesti´ n de FAVS los docentes pueden ver los blogs que han sido agregados o a su planeta y tienen la posibiidad de editar los datos de cada bit´ cora o, incluso, de eliminar a alg´ n blog que no forme parte de la asignatura. Para ello deben usar los enlaces edit student’s u data o delete del blog correspondiente. Figura A.9: Borrar o editar los datos de un blog Si un profesor quiere tener varios planetas distintos puede hacerlo sin tener que crearse diferentes usuarios haciendo uso de las etiquetas o tags. Para ello, desde el panel de gesti´ n o FAVS, debe pinchar sobre el enlace edit tags y escribir la etiqueta deseada. En el sitio web

62 ANEXO A. BREVE MANUAL DE USUARIO DE FAVS donde el profesor tiene el c´ digo de FAVS, debe reemplazar el atributo src siguendo el siguiente o formato para ﬁltrar los blogs mostrados: src=”http://www.FAVS.com/code/your-id/tag/subject-name” De esta forma tan s´ lo se mostrar´an los blogs etiquetados con el tag subject-name. o ı Figura A.10: Utilizando las etiquetas

Anexo B Instalando Feevy. Ayuda recibida. Se recogen en este anexo los correos electr´ nicos intercambiados con los desarrolladores o del proyecto Feevy en los que nos ayudaron a instalar en un servidor propio su aplicaci´ n: o Hola [l´der del proyecto Feevy], ı Antes de nada me gustará felicitaros por vuestro trabajo, ı y por la idea de liberar Feevy. Para mi Proyecto Fin de Carrera estoy desarrollando una aplicaciń que va a utilizar Feevy, as´ que estoy intentando o ı instalar Feevy en mi servidor, para jugar un poquillo y realizar algunos cambios, pero estoy teniendo problemas. Siguiendo las instrucciones que public´steis en la bitacora, a hay algunas gemas que no puedo instalar: open-uri y timeout no se encuentran. Adem´s al intentar realizar rake db:schema:dump para a construir la BBDD siempre obtengo un error con el fichero Rakefile. ¿A qu´ pueden deberse estas situaciones? Estoy empezando a e trabajar con rails y ań soy novatillo, pero sospecho que u puede deberse a las versiones que uso. He instalado las ´ltimas versiones de rails, ruby y gems. ¿Puede ser ´se u e el problema? ¿Qu´ versiones serán necesarias para poder e ı instalarlo? Muchas gracias. Un saludo, 63

64 ANEXO B. INSTALANDO FEEVY. AYUDA RECIBIDA. Jes´s Moreno. u -------------- Hola Jes´s! u Que bueno lo de tu proyecto! Gracias por usar feevy! Sobre tu problema, me da que est´s utilizando la segunda a versiń con las instrucciones de instalaciń de la primera... o o Te respondo CC a [desarrollador de Feevy] y a [desarrolladora de Feevy]. Seguro que [desarrollador de Feevy] te puede ayudar, porque yo hice una instalaciń de la primera o pero no de la segunda y creo que hay mejoras sustanciales :-) Un abrazo grande [l´der del proyecto Feevy] ı ---------------- Hola Jesus, Graias para tu mensage :) Tienes el codigo de github? Si no, puedes cogerlo all´: ı http://github.com/alx/feevy/tree/master Hace un monton que no he instalado Feevy del principio, problamente es una cosa de Rake que ha desaparecido en una nueva version. Puedes enviarme el mensage que tienes, con el mas informaciones posible? tiendras mas informaciones con: rake --trace Muchas gracias, [desarrollador de Feevy] -------------- Hola [desarrollador de Feevy], e ´ Gracias por tu inter´s. Me he descargado la ultima versiń o del repositorio, pero al instalar las gemas necesarias

65 obtengo esto: Successfully installed rails-2.1.0 Building native extensions. This could take a while... Successfully installed hpricot-0.6.161 Successfully installed simple-rss-1.1 ERROR: could not find gem open-uri locally or in a repository ERROR: could not find gem timeout locally or in a repository Successfully installed cached_model-1.3.1 Building native extensions. This could take a while... Successfully installed mongrel-1.1.5 Successfully installed htmlentities-4.0.0 Successfully installed rfeedfinder-0.9.12 Successfully installed rfeedreader-1.0.13 Successfully installed rfeedfinder-0.9.12 9 gems installed Como ves, no puedo instalar dos de las gemas. He configurado el fichero database.yml con las credenciales necesarias y al ejecutar rake db:schema:dump --trace: (in /var/rails/feevy2) rake aborted! undefined method ‘require_gem’ for main:Object /var/rails/feevy2/config/boot.rb:28 .... /usr/local/bin/rake:19:in ‘load’ /usr/local/bin/rake:19 Quiz´s es por la versi´n de rails que uso? es la 2.1.0. a o Muchas gracias! ---------------- Hola Jesus,

66 ANEXO B. INSTALANDO FEEVY. AYUDA RECIBIDA. Probando ayer con Feevy, tenia el mismo problemo con Rake. Necesitas cambiar "require-gem" con solo "gem" en config/boot.rb No s´ para las gemas, ceo que timeout y open-uri son e dentro la libreria estandar de ruby, entonces no debres tener m´s problemas con eso. a En config/environment.rb, la versi´n de rails est´ o a bloqueada a la 1.2.3. Creo que la ultim´ vez que he mirado a un poco Feevy, fue experimantando haciendo upgrade hasta rails2, y no tenia muchas problemas. El mejor sere que haces un fork de Feevy en Github, donde podrias poner todos tus cambios, eso foncionaba bien con rFeedReader y rFeedFinder para tener ayuda de otros desalloradores :) Suerte, estoy esperando para tus avancadas, y te ayudar´ e si tienes algun pregunta :) [desarrollador de Feevy] --------------- Hola [desarrollador de Feevy], perdona por molestarte de nuevo :-( Ahora obtengo otro error, parece que no encuentra libgd.so.2, que est´ instalado y se encuentra a en /usr/local/. Te dejo la salida: rake aborted! libgd.so.2: cannot open shared object file: No such file or directory ... /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.1/bin/rake:31 /usr/local/bin/rake:19:in ‘load’ /usr/local/bin/rake:19 Alguna idea? Muchas gracias de nuevo por tu ayuda! ---------------

67 Hola Jes´s, u Ah, la famosa libgd :) Me ha dado tanto susto el a˜o pasado que tengo ese codigo n en mi buzon: Patch gd2.rb with following line to link to correct libgd.so: def self.gd_library_name case Config::CONFIG[’arch’] when /darwin/ ’libgd.2.dylib’ when /mswin32/, /cygwin/ ’bgd.dll’ else ’/usr/local/lib/libgd.so.2’ end Tienes que hacer ese patch sobre la gema de gd, dentro gd2.rb, y digame si fonciona ˜ejor :) n Hasta ahora, -------------- Hola [desarrollador de Feevy]! Ya he solucionado el problema con gd2, eres un artista! :-D Ahora obtengo un error al migrar la BBDD, DefaultSubAvatar: migrating ================= -- change_column(:subscriptions, :avatar_id, :integer, {:default=>1}) rake aborted! Mysql::Error: Unknown column ’avatar_id’ in ’subscriptions’: ALTER TABLE subscriptions CHANGE avatar_id avatar_id int(11) DEFAULT 1 Saludos! ------------- Hola [desarrollador de Feevy],

68 ANEXO B. INSTALANDO FEEVY. AYUDA RECIBIDA. mirando la BBDD he visto que la tabla subcriptions no tiene un campo avatar-id, (de hecho en el migrate 017-migrate-avatar.rb aparece comentada la lńea ı que crea ese campo) ¿No deberá aparecer? ı ------------ Hola Jesus, he subido una correcion para la migraciń 017 en un o nuevo commit en github, podrá ayudarte la pr´xima vez :) ı o http://github.com/alx/feevy/commit/f558...1ff7f6cfc9c1e0ae Un saludo, [desarrollador de Feevy] ----------- Hola [desarrollador de Feevy], Muchas gracias por toda la ayuda!! Por fin tengo una versiń de Feevy corriendo en mi servidor. o Ya puedo comenzar a estudiarla y modificarla, os ir´ contando e mis avances. Un saludo y muchas gracias de nuevo! Jes´s. u

Bibliografá ı [1] Orihuela, Jos´ Luis. La revoluci´ n de los blogs. La Esfera de los Libros, 2006. e o [2] Ganley,Barabara. Blogging as a dynamic, transformative medium in an American liberal arts classroom. BlogTalks 2.0: The European Conference on Weblogs, Vienna, Austria, 2004. [3] Robles, Gregorio, Gonz´ lez Barahona, Jes´ s Mará y de las Heras Quir´ s, Pedro. a u ı o Experiencia de uso de blogs en e-learning. Tercera Jornada de Innovaci´ n Pedag´ gica del o o Proyecto ADA Madrid, Fuenlabrada, Espa˜ a, 2008. n http://moodle.upm.es/adamadrid/file.php/1/web_III_jornadas_ADA/ Comunicaciones/Robles&20Martinez.pdf [4] Downes,Stephen Educational Blogging. EDUCAUSE Review, vol. 39, no. 5 (Septem- ber/October 2004): pp 14–26. http://www.educause.edu/ir/library/pdf/ERM0450.pdf [5] Gonz´ lez Barahona, Jes´ s, Senoane Pascual, Joaquń y Robles Martńez, Gregorio Intro- a u ı ı ducci´ n al Software Libre. UOC, 2007. o [6] Lenz, Patrick. Simply Rails 2 (2nd Edition). SitePoint, 2008. [7] Ruby, Sam, Thomas, Dave y Hansson, David. Agile Web Development with Rails (3rd Edition). Pragmatic Programmers, 2008. [8] Kent, Beck y Andres, Cynthia. Extreme Programming Explained: Embrace Change (2nd Edition). Addison-Wesley Professional, 2004. [9] Amor, Juan Jos´ , Herraiz, Israel y Robles, Gregorio. Desarrollo de proyectos de software e libre (segunda edici´ n). UOC, 2007. o 69

70 ´ BIBLIOGRAFIA [10] DiBona, Chris, Ockman, Sam y Stone, Mark. Open Sources: Voices from the Open Source Revolution. O’Reilly Open Source, 1999. [11] Nielsen, Jakob y Loranger, Hoa. Prioritizing Web Usability. Pearson, 2006.

Favs

by Jesus Moreno Leon on Apr 18, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 10

Statistics

Favs — Document Transcript