¿Cómo disponer de un Servidor Multimedia privado?

En un artículo anterior comentábamos alguna de las circunstancias que nos pueden empujar a analizar la posibilidad de crear nuestro propio servidor de vídeos al estilo de los habituales YouTube o Vimeo como apoyo a nuestra plataforma e-learning.

El motivo que argumentábamos era la dificultad que tenemos para garantizar que nuestros vídeos colgados en esta plataforma no sean descargados y distribuidos fuera de nuestro control y la posibilidad de que disponiendo de una plataforma propia que podemos administrar a nuestro gusto podamos minimizar, si no eliminar totalmente, este riesgo.

Otra circunstancia en la que se justifica la disponibilidad de un servidor privado de estas características es cuando la plataforma e-learning pertenece a un centro de enseñanza primaria o secundaria donde, por razones obvias, el acceso a servidores de streaming a través de internet puede estar limitado en muchas ocasiones, dificultando a los profesores la utilización de vídeos colgados en la red como material de apoyo a su labor docente.

En este último caso, la disponibilidad de un servidor de streaming de vídeo de titularidad propia, situado bien en un hosting privado de internet, bien en un servidor interno de la LAN académica, puede resultar de gran utilidad

Este tipo de servidores pertenecen a una categoría denominan genéricamente MMS (Multimedia Management System), ya que no solo permiten subir y descargar vídeos sino también otros archivos de medios como imágenes o archivos de audio.

Existen diferentes softwares que permiten crear un servidor de estas características y poder disponer de un clon de YouTube para nuestro uso privado. Mencionaremos tres de estos paquetes, de distribución libre y gratuita, basados en la conocida tecnología XAMP, basada en servidor web Apache, base de datos MySQL y lenguaje de scripts PHP y que se apoyan, con ligeras diferencias entre ellos, en una serie de paquetes de gestión de archivos multimedia muy habituales en los entornos de software libre, como FFMpeg, la librería GD y otros que ya comentaremos en su momento.

Estos tres paquetes son

PHPmotion                      http://phpmotion.com

ClipBucket                        http://clip-bucket.com

JUST                                  http://justanothervideoscript.com
 

Si algo tienen en común, además de permitirnos construir nuestro servidor MMS, es la inexistente documentación es español sobe estos productos y la suposición de que quien se enfrenta a la instalación de cualquiera de ellos sabe ya instalar tanto un servidor XAMP como los diferentes paquetes sobre los que se apoyan los productos, ya que se sus páginas web se limitan a dar la lista de requerimientos previos y a explicar sucintamente el proceso de instalación y configuración inicial de producto.

Esto se justifica en parte por el modelo de negocio que sustenta algunos de estos paquetes, que pasa por la comercialización de servicios de instalación del servidor o la comercialización de servicios de hosting especializado, además de la venta de elementos complementarios como temas gráficos o extensiones de software.

De todas maneras, gracias a que muchos usuarios ponen en común sus experiencias en la red, es posible obtener información suficiente como para, con un poco de trabajo y dedicación, poder construir nuestro propio servidor de streaming. Y en este proceso estamos ahora, analizando la información disponible e instalando paso a paso nuestro piloto.

Como no podía ser de otra manera, dado el carácter divulgativo de este blog, vamos a contribuir al conocimiento general con una serie de artículos que iremos publicando en las próximas semanas en los que relataremos de la forma más didáctica posible cómo instalar nuestro propio servidor MMS de pruebas donde analizar cómodamente cualquiera de estos productos.

En el próximo artículo, veremos como instalar el software base necesario, no se aún si en Linux o en Windows, o si toda va bien, por qué no en ambos.

¿Es posible proteger contra descarga nuestros vídeos didácticos?.

Me he encontrado en no pocas ocasiones con docentes que generan vídeos didácticos para incorporar a sus cursos Moodle (u otras plataformas) y que posteriormente se encuentran en la duda de dónde alojar estos vídeos y que preguntan si es posible proteger los vídeos contra descarga.

La respuesta es "No", no hay un método 100% eficaz. Hagamos un repaso a la situación general.

Es bien sabido que Moodle permite subir los vídeos al propio servidor Moodle y servirlos desde allí, pero también es sabido que esto requiere un servidor más potente y con más espacio en disco, por no hablar del consumo de ancho de banda que en muchos hostings excesivamente económicos debe pagarse aparte si superamos el tráfico mensual establecido.

Ante esta situación, la alternativa es colgar los vídeos en servidores de "streaming" externos e "incrustarlos"  en las páginas de los diferentes módulos de los que Moodle dispone; el editor de Moodle, el TinyMCE, dispone de una opción para incrustar elementos multimedia, por no hablar del sistema de filtros de Moodle, que permite insertar un vídeo de Youtube simplemente escribiendo la URL del vídeo en cualquier página.

Pero aquí aparece un problema nuevo: los vídeos colgados en un servicio de las características de Youtube o de Vimeo no tienen ninguna protección contra descarga y por lo tanto, quien quiera mantener a salvo su creación considera un riesgo colgar los vídeos de producción propia en este tipo de servicios.

El problema es de difícil resolución, ya que los vídeos visionados mediante la tecnología de “streaming” se descargan como archivos temporales en el ordenador desde el que se visionan, de manera que existen multitud de aplicaciones que se limitan a capturar este archivo temporal y generar una copia perfectamente útil para su visionado y, por qué no, para su distribución.

Existen mecanismos para minimizar este riesgo, que no para eliminarlo totalmente; por ejemplo, en Youtube es posible subir un vídeo y ponerlo en estatus “Sin clasificar”, de manera que solo podrá acceder a él quien conozca la URL del mismo y no aparecerá en las búsquedas habituales de internet. Está claro que esta protección es bastante débil, ya que cualquier alumno puede difundir la la URL del vídeo, pero mejor esto que nada. En servicios como Vímeo es posible poner una clave al vídeo, de manera que solo lo podrán visionar (y descargar, no lo olvidemos) quien conozca la clave.

Así que deberemos ser más imaginativos y utilizar otros mecanismos, como, por ejemplo, poner una “marca de agua” al vídeo, algo que será técnicamente más fácil o complejo según el software de edición de vídeo que utilicemos, pero a muchos autores no les gusta porque rompe la estética del vídeo.

Personalmente, además de publicar mis vídeos didácticos “sin clasificar” en Youtube, he optado por insertar en los mismo publicidad de mis servicios en los vídeos de producción propia, al final del mismo o incluso al inicio. Indicar el autor y el copyright con el que queremos que esté protegido nuestro vídeo, el curso al que pertenece u otra información sobre nuestros servicios profesionales, permite, ante la posibilidad de que nuestro vídeo se difunda sin nuestro consentimiento, que paralelamente también se difunda nuestro trabajo; es posible que hasta encontremos nuevos clientes para nuestros cursos y que lo que en principio es un problema se convierta en una ventaja. Claro está que siempre hay quien puede editar el vídeo y eliminar esta parte, pero se trata de al menos no ponerlo fácil.

Además, ya puestos a perder la batalla, por qué no publicarlos con un copyright Creative Commons y que quien quiera distribuirlos que lo haga libremente,  respetando las condiciones de esta licencia.

De todas maneras, hay quien es muy celoso de su producción, por lo que es necesario buscar alguna solución mejor para proteger nuestros vídeos de descargas indeseadas, que no pase por ir cada dos por tres a los tribunales.

Personalmente me gustaría disponer de un servidor de streaming privado para hacer pruebas y ver hasta donde se puede llegar. He oído hablar de PHPmotion, por lo que no descarto que en un próximo artículo hable de cómo me ha ido la experiencia con este producto.....

Características de la nueva versión Moodle 2.4

A punto de terminar el proceso de test de Moodle 2.4dev y de que los programadores terminen de corregir los problemas encontrados, esperamos que la versión 2.4 estable sea liberada a más tardar la primera semana de diciembre.

Es momento por lo tanto de analizar los cambios y mejoras que aporta esta versión y de que cada uno de nosotros decida la conveniencia o no de migrar a esta nueva versión de forma inmediata, sabiendo que tarde o temprano tendremos que hacerlo si queremos seguir con la política recomendada siempre en este blog de mantener nuestro Moodle lo más actualizado posible.

Respecto a los requerimientos de la infraestructura, no hay variaciones respecto a la versión 2.3, lo que supone un aliciente para realizar la migración desde esta versión ya que nos evitamos tener que realizar cambios en el software base de nuestra instalación, a veces problemáticos.

Sobre las mejoras “internas”, no visibles directamente al ojo del usuario, se han realizado una serie de optimizaciones para mejorar el rendimiento. A destacar la implementación de un sistema de caché denominado Moodle Universal Cache (MUC) que permite al administrador del sito Moodle implementar diferentes configuraciones que pueden permitir reducir valores tan importantes como el número de peticiones a la base de datos, el número de archivos que se necesitan leer del disco para crear una página o los requerimientos de memoria RAM.

Para gestionar MUC el admin dispone ahora de una nueva opción en el menú de extensiones denominada “Caching” donde configurar diversos aspectos de este nuevo sistema. De todas maneras observo que estas estas opciones son “muy especializadas” y no están al alcance de todos los administradores, sobre todo de aquellos con un perfil más funcional que técnico, y a falta de una documentación que oriente sobre su utilización serán pocos los que se atrevan (o nos atrevamos) a modificar estas configuraciones, al menos en una primera fase.

De todas maneras, a falta de estadísticas sobre la versión definitiva, ya podemos ver algunas provisionales sobre la versión 2.4dev como las que se pueden consultar en este enlace, que dan como resultado mejoras en el rendimiento bastante relevantes.

También a nivel interno y orientado a los programadores de temas gráficos (los Themes) se han implementado cambios internos para permitir más opciones de configuración de estos, lo mismo que con los formatos de curso, lo que permitirá desarrollar nuevos formatos en el futuro.

Una mejora más visibles se centra en el editor TinyMCE al que se le han añadido algunas opciones de configuración para que el admin pueda añadir o quitar botones y configurar las extensiones propias del editor, permitiendo un cierto grado de personalización de las barras de herramientas en cada instalación.

Otra mejora que facilita la vida del admin es la gestión de las extensiones. Si en la versión 2.3 ya se notificaba de la existencia de una nueva versión de las extensiones instaladas, en la versión 2.4 se mejora esta opción permitiendo la instalación vía web de la nueva versión. Una gran mejora, desde luego.

Una de las peticiones de mejora más votadas por los usuarios en el sistema de gestión de cambios de Moodle (el famoso tracker) se ha implementado finalmente: la opción de integrar calendarios externos en el calendario de Moodle. Se ha establecido un sistema de suscripciones a calendarios externos compatibles con el sistema de intercambio iCal, como los calendarios de otros sitios Moodle o los de Google Calendar, entre otros.

También se ha implementado una mejora relevante en la Tareas. Ahora es posible realizar tareas en grupo de trabajo, de manera que, entre otras posibles configuraciones, se puede definir que basta con que un alumno entregue la tarea para que todo el grupo haya cumplido con esta, y la calificación dado por el profesor a esta entrega se aplicará a todos los alumnos del grupo. Para establecer los grupos de trabajo se utiliza la estructura de Grupos (no de Agrupaciones) ya habitual en Moodle.

Otro aspecto relacionado con las Tareas es la posibilidad de cargar ahora las calificaciones a partir de un archivo CSV que podemos generar con una hoja de cálculo.

Para terminar con este repaso a los cambios más importante en Moodle 2.4, hablaremos de algo casi anecdótico, pero relevante por la novedad; se han cambiado por primera vez los iconos, que desde la versión 1.0 permanecían invariables. En esta página pueden ver las equivalencias entre los iconos de las versiones anteriores y la 2.4.

Personalmente no me gusta que los iconos de las actividades y de las opciones de menú sean ahora monocromos, mientras que veo que los correspondientes a los módulos (recursos y actividades), más grandes y coloridos son realmente atractivos.

Como conclusión, esta versión sigue en la línea de las anteriores, la de aportar mejoras relevantes pero entregadas de forma dosificada, sin grandes cambios globales que puedan asustar a los administradores y sin que la experiencia de usuario sufra cambios difíciles de digerir.

Ajustes de PHP en Moodle 2.x

Uno de los problemas más habituales con los que se enfrenta quien aborda la instalación de Moodle es la correcta configuración o parametrización de PHP, lenguaje de script con el que está construido. Muchos problemas de ejecución de Moodle tienen que ver con una incorrecta configuración de este elemento. En este artículo intentaremos dar un repaso a los parámetros que habitualmente debe ser tenidos en cuenta a la hora de abordar la solución de algunos problemas muy habituales.

En primer lugar hemos de recordar que desde la versión Moodle 2.1 se requiere utilizar obligatoriamente PHP 5.3.2 o superior; utilizar cualquier versión anterior de PHP garantiza los problemas.

En segundo lugar hemos de recordar que la configuración de PHP se realiza en el archivo php.ini, si bien en instalaciones realizadas sobre hostings compartidos o sobre VPS construidos a partir de consolas como Parallels o Cpanel, el panel dispone de una utilidad gráfica donde modificar los parámetros de PHP sin necesidad de buscar y editar manualmente el archivo php.ini. Si tiene dudas al respecto, consulte con su proveedor de hosting que le deberá asesorar a respecto.

En tercer lugar, recordaremos que para consultar la configuración actual de PHP desde Moodle con el usuario admin puede hacerlo desde

Administración del sitio – Servidor – Información PHP

Veamos ahora los parámetros que debemos tener en cuenta partiendo de tres de los problemas más habituales que aparecen en los foros de Moodle:

El primer problema que comentaremos es aquel que se produce cuando eterminadas operaciones dan un error del tipo

Fatal error: Allowed memory size of xxxxxxxxxx exhausted (tried to allocate yyyyyyyyyy) in abcd.php on line n

Este error nos informa que la memoria asignada para la ejecución del script php se ha agotado y que precisa de una ampliación.

El valor por omisión en PHP 5.3.2 es de 128M que deberemos ampliar modificando el valor de la directiva

memory_limit =

Este parámetro establece el máximo de memoria que un script puede consumir. Poner este límite evita que scripts mal programados consuman toda la memoria disponible en el servidor. Cojamos el valor recomendado por el error (¡ojo, está en bytes) y ajustémoslo ligeramente al alza.

Un segundo problema habitual es “la pantalla blanca” que aparece en determinadas operaciones como búsquedas, elaboración de informes, ejecución de copias de seguridad u otras operaciones que llevan un cierto tiempo de proceso. Esta “pantalla blanca” se produce cuando la ejecución de un script lleva más tiempo que el definido en la directiva de PHP 

 max_execution_time =

Este valor establece el tiempo máximo en segundos que se permite ejecutar el script (30 por omisión), de manera que si este tiempo se excede, el script se detiene (de ahí que la salida sea una página en blanco). Es otra medida de seguridad para prevenir que un script mal diseñado bloquee el servidor.

Relacionado con este problema está también la directiva

max_input_time =

que determina el tiempo (también 30 por omisión) que un script puede estar cargando datos (por ejemplo, de la lectura de una base de datos). Si el tiempo se excede, el script se detiene.

Si tiene problemas de “pantalla blanca”, vaya subiendo estos valores hasta que se solucionen; para instalaciones grandes, no es extraño encontrarse con valores de 150 o de incluso 300 segundos, valor máximo permitido por la directiva Timeout de Apache. No hace falta decir que valores más altos no sirven de nada ya que será el servidor Apache el que finalice el proceso, salvo que queramos cambiar la configuración de Apache, asunto que queda fuera del objetivo de este artículo.

El tercer y último problema que veremos se refiere al tamaño de los archivos que se pueden subir al servidor. Independiente de cómo Moodle configura este aspecto y los posibles límites que se pongan a nivel de actividad y a nivel de curso, estos nunca podrán superar los valores establecidos a nivel de sitio, que a su vez no puede superar la directiva PHP

upload_max_filesize =

que por omisión esta establecida en valores muy bajos (2M).

Para operar correctamente en Moodle conviene establecer la directiva de PHP y el valor máximo del tamaño de archivos en valores relativamente altos (128M, 256M,...) dependiendo del tamaño de nuestros archivos de copia de seguridad, que suelen ser los archivos de mayor tamaño que habitualmente manejamos. Para limitar a los usuarios deberemos utilizar los valores internos de Moodle a nivel de curso y a nivel de actividad.

Hay una última directiva a tener en cuenta

post_max_size =

Esta directiva el tamaño máximo de “datos post” permitidos (8M, por omisión); los “datos post” tienen que ver con los tipos de tratamiento interno que hace php de la información y, la verdad, los que no somos programadores no necesitamos saber más al respecto. Nos basta con saber que esta directiva también afecta a la subida de archivos y que para poder subir ficheros grandes, este valor de ser mayor o igual que upload_max_filesize.

Del resto de las directivas de PHP, mi recomendación, para quien utilice Moodle, es no tocarlas, si no sabemos muy bien qué hacemos y porqué lo hacemos.

Conector Skype para Moodle 2.x

Bien es sabido por todos los que utilizamos Moodle que unos de sus puntos más débiles es la comunicación síncrona, que se limita a un módulo de chat, obsoleto y poco operativo, del que me atrevería a decir que prácticamente nadie utiliza y que, por lo tanto, nadie lo echaría a faltar si desapareciera de la distribución estándar de Moodle.

Para solventar esta necesidad, la de comunicación personal entre los usuarios de Moodle podemos utilizar los módulos externos que nos permiten conectar con servidores de videoconferencia como BigBlueButtom u OpenMeetings; de este último ya hemos hablado mucho en este blog.

Pero la verdad es que no siempre los administradores de un sitio Moodle disponen de este tipo de servidores que poner a disposición de sus usuarios y aunque dispusieran de los mismos, su utilización para una simple conversación bis a bis entre alumno y profesor o entre dos alumnos es, como se suele decir, “matar moscas a cañonazos”.

Muchos formadores on line han optado desde hace tiempo por utilizar, para este tipo de comunicación, herramientas propias de las redes sociales y por lo tanto, externas a Moodle, como pueden ser Microsoft NetMeeting o la opción de videollamadas que recientemente ha incorporado Google+ a su paquete de aplicaciones.

Otra solución para muchos ha sido utilizar Skype (desde 2011 propiedad de Microsoft), normalmente en su versión gratuita, que permite transmisión de audio y/o imagen, chat e intercambio de archivos, funcionalidades más que suficiente en la mayoría de reuniones de tutoría de un curso e-learning.

El problema de utilizar estas herramientas está en que los usuarios salen del entorno Moodle cada vez que quieren comunicarse personalmente y sobre todo, en que deben mantener la lista de contactos fuera del propio Moodle, en la agenda interna de la aplicación utilizada.

Lo ideal sería que en el curso Moodle hubiera un módulo, similar al chat, donde el usuario que deseara establecer contacto con otro usuario del curso pudiera seleccionarlo del directorio del mismo y simplemente pulsando sobre el mismo, se lanzara la solicitud de comunicación.

Así que investigando un poco en la página web de Moodle, concretamente en las sección de extensiones o plugins, he encontrado el conector de Moodle con Skype, que se puede descargar desde la siguiente dirección

http://moodle.org/plugins

Se trata de una extensión disponible oficialmente para las versiones de Moodle 1.9.x, 2.1.x y 2.2.x y que probado personalmente para la versión 2.3.2, para la que también funciona perfectamente.

Su instalación es similar a la de otras extensiones, es decir, basta con descomprimir el archivo descargado en la carpeta

…./moodle/mod

y, entrando como admin en el sitio Moodle, actualizar la base de datos, según el proceso estándar de actualizaciones de Moode.

A partir de aquí, quien diseña un curso dispone de una actividad más, skype, que permite que los usuarios del curso accedan al directorio de usuarios matriculados en el curso y puedan solicitarles una conexión Skype.

A nivel de Moodle es necesario que los usuarios completen en su perfil personal, en el campo correspondiente, el ID de su Skype.

A nivel de PC, como podemos suponer, el usuario debe tener instalado Skpe y la conexión debe estar en estado “Conectado” para poder hacer o recibir llamadas.

Y las prestaciones, las que tenga su Skype, que como todos sabemos, cuenta con una suscripción gratuita, pero con limitaciones, y otra de pago, con más funcionalidades.

Pruébelo, seguro que le gustará.

¡Moodle_años feliz, te deseamos todos.....!

El 20 de Agosto pasado Moodle cumplió 10 años, acontecimiento que ha pasado desapercibido para muchos, pero que tiene una gran relevancia, no solo en el mundo del e-learning sino en el mundo del software libre, por cuanto implica la madurez de un proyecto basado en software opensource que ha conseguido hacerse con una cuota de mercado importante.

Para hacernos una idea, he aquí algunos datos relevantes:

• A día de hoy Moodle cuenta con 27 personas en staff y 54 partners distribuidos en 33 países.
• La comunidad de desarrolladores del núcleo de Moodle está formada por 105 personas y desde su creación han participado en la construcción de las diferentes versiones alrededor de 250.
• Moodle ha superado ya el millón de línea de código
• Además se han desarrollado por parte de otros colaboradores 95 extensiones disponibles en la base de datos de plugins que pueden ser descargadas e instaladas.
• También hemos de mencionar a un número desconocido de traductores alrededor del mundo que mantienen en este momento 110 paquetes de idioma, 24 de los cuales, entre ellos el español, disponen de más del 80% de cadenas de texto traducidas de las casi 18.000 con las que cuenta Moodle.

 

Podríamos hablar de otros datos, pero no se trata solo de números, sino del empuje de un proyecto y de un modelo de negocio basado en software libre que ha calado en estos diez años y  que esperamos que cumpla muchos más.

Para celebrar este acontecimiento el moodler  Piotr Peszko ha creado esta infografía que puede descargar de la url

http://blog.2edu.pl/2012/08/moodle-is-10-years-old-infographic.html

.....y que cumplas muchos más.......

Barreras de competencia tecnológica para un alumno de un curso basado en MUVE.

A la hora de plantear la creación de un curso en un entorno MUVE (Mundos Virtuales), entre otras muchas cosas que es necesario planificar, nos encontramos con un elemento fundamental, muchas veces no tenido en consideración por lo promotores del evento formativo y que puede convertir la iniciativa en un estrepitoso fracaso. Me refiere al análisis previo de las competencias técnicas que necesariamente deben poseer los alumnos para poder abordar el curso y el proceso de capacitación en las mismas que deberá seguir todo alumno que no las posea, salvo que por diferentes motivos, decidamos que quien no alcance un nivel mínimo demostrable, no pueda matricularse en el curso.

Por poner un ejemplo que todo el mundo pueda entender: si organizo una ruta turística en segway por la ciudad, me tendré que asegurar de que quien quiera realizarla sabe manejar el vehículo, o en su defecto, tendré que darle una formación específica previa.

Esta problemática es común a cualquier tipo de curso donde exista una gran componente tecnológica. Lo que ocurre es que hay tecnologías y habilidades asociadas a estas que se van incorporando a la sociedad y con el tiempo acaban por integrarse en la misma. Hace 35 años era muy normal encontrar universitarios que tenían dificultades a la hora de utilizar una calculadora científica, mientras que hoy en día, cualquier estudiante de ESO cuenta con una en su mochila.

En mi experiencia como consultor e-learning sobre plataformas Moodle me he encontrado en numerosas ocasiones con docentes que elaboraban sus cursos sin tener en cuenta que la mayoría de sus potenciales alumnos no han realizado nunca un curso e-learning y que si lo han hecho, no siempre ha sido en una plataforma Moodle, o incluso, si lo han realizado sobre una plataforma de este tipo, la operativa del curso no tiene por qué ser similar a la utilizada por ellos. El resultado, un elevado índice de abandono en las primeras sesiones, fruto de la desorientación de los alumnos y del elevado consumo de tiempo, muy superior al esperado según las especificaciones del curso.

Mi consejo ha sido siempre el mismo y se basa en cuatro premisas

• Defina previamente las competencias digitales mínimas necesarias para abordar el curso y publíquelas junto al resto de la información del mismo
• Haga un test previo a sus alumnos para garantizar que disponen de estas competencias digitales y aconséjeles como actuar en caso de no alcanzar el nivel mínimo requerido
• Establezca un plan de capacitación previa en estas competencias mínima, como puede ser un manual de usuario de la plataforma y un espacio libre de experimentación.Establezca un servicio de soporte técnico durante el desarrollo del curso, diferenciado del soporte conceptual objeto del curso.

La aplicación de estos consejos es totalmente válido en el mundo de los MUVEs aplicados a la docencia. Además de los problemas habituales con los que se puede encontrar cualquier estudiante on line (acceso a la red, desconocimiento del campus virtual, falta de metodología, etc...) se suman los relacionados con el acceso y la acción dentro del mundo virtual.

• En primer lugar están los condicionantes de tipo técnico, como son los requisitos específicos de hardware y de software (tarjeta gráfica, visor 3D), el registro como usuario de la plataforma, la creación del avatar, y las técnicas de movimiento y ubicación en el mundo virtual.
• En segundo lugar, nos encontramos con problemas relacionados con la estrategias de socialización del alumno dentro del mundo virtual, desde la configuración del propio avatar hasta los mecanismos para interactuar con otros avatares, generalmente desconocidos para la mayoría de los alumnos.
• En tercer lugar, muchos estudiantes tiene problemas a la hora de identificar los circuitos de comunicación y los repositorios de información del curso, ya que además de los habituales en cualquier campus virtual, se suman los internos propios del MUVE utilizado.

Si quiere conocer una experiencia interesante y ver cómo se abordaron estos problemas en un caso real, le recomendamos que vea este enlace.

En conclusión, si quiere organizar un buen curso utilizando un MUVE, garantice antes que sus alumnos se mueven, como pez en el agua, dentro de ese mundo virtual.

Mi primera participación en un MOOC

Hace unos días que comencé una experiencia de aprendizaje totalmente nueva para mi, la participación en un MOOC, siglas de Massive Open Online Course (Curso en red abierto y masivo).

Como dice su nombre, un MOOC es un curso impartido en red, gratuito para los participantes y de carácter masivo en lo referente al número de estos, que pueden ser desde varias decenas a miles. 

En el caso que nos ocupa, hay unos 200 o 250 participantes teóricos, aunque a la hora de la verdad, somos muchos menos los que participamos activamente y me temo que muy pocos los que finalicemos el proceso.

Este MOOC en concreto es sobre SLOODLE (Simulated Linked Object Oriented Dinamyc Learning Eniroment) y lo patrocina la consultora ELEARNING3D que lidera la consultora y experta en formación y mundos virtuales Ruth Martínez.

El curso se estructura en retos que los participantes deben ir cumpliendo, bien de forma individual, bien de forma colaborativa, estableciendo alianzas con otros participantes.

El primer reto estaba relacionado con la comprensión del propio modelo MOOC y era diferente según el perfil con el que cada participante se identificara, de manera que los resultados del trabajo individual o colectivo eran diversos, desde recopilar información sobre el modelo MOOC hasta diseñar un MOOC, pasando por establecer un DAFO del modelo MOOC..

Existe un curso Moodle donde todos los participantes estamos dados de alta y donde recibimos las instrucciones pertinentes, pero la comunicación se realiza no solo mediante foros Moodle habilitados a tal efecto sino que se potencia la utilización del Twitter y de unos determinados hastags o etiquetas.

Cada alumno puede utilizar los recursos de la web que considere oportuno, sus propios blogs, wikis o repositorios personales, las herramientas que use habitualmente o los recursos que se pacten cuando se establecen alianzas de colaboración entre participantes, debiendo etiquetarlos adecuadamente

De momento este es el elemento más débil que he visto en el modelo MOOC, la falta total de criterios a la hora de utilizar herramientas comunes y sobre todo, la ausencia total de criterios para compartir la información, de tal manera que no existe un repositorio final común donde todos los participantes o grupos de participantes puedan presentar sus resultados finales para uso y disfrute del resto de los compañeros.

No cabe duda que la libertad total en el uso de herramientas facilita la participación activa de los alumnos que no se ven obligados a utilizar determinados recursos técnicos que a priori pueder ser desconocidos representar una barrera, pero tengo que disentir totalmente en el hecho de que no se hayan establecido mecanismos comunes de publicación de los resultados.

Planteado este problema a los tutores del evento, estos consideraban inicialmente que la mera utilización de los hastag o etiquetas en un buscador web era un sistema de publicación más que suficiente, algo con lo que personalmente disentí argumentando que el sistema de etiquetas se ideo para filtrar la información de la red y facilitar la recopilación de fuentes sobre un determinado tema para luego ser tratada de forma personal, pero no como sistema de publicación de resultados finales, por cuanto el mismo hastag identifica fuentes iniciales, trabajos intermedios o parciales y los resultado finales, lo que obliga a cada participante a filtrar y depurar de nuevo todos los elementos de información que han participado en el proceso.

Así, si quiero compartir el resultado final de mi trabajo y beneficiarme de los resultados obtenidos por otros compañeros, este sistema basado en búsqueda de etiquetas se demuestra totalmente ineficaz, y de forma contradictoria, más ineficaz cuanto más éxito de participación tenga el evento, al crecer el número de mensajes en Twitter que deben ser filtrados.

Desde mi punto de vista, habilitar una simple página de texto compartida donde cada persona o grupo pueda añadir un enlace a su trabajo final es más que suficiente, si bien, la creación de un foro específico, una wiki, una base de datos o incluso un glosario, todos ellos elementos de los que dispone el propio Moodle sobre el que se está realizando el curso, pueden ser una solución sencilla a este problema.

En este momento los promotores del evento se están planteando esta opción y buscan la solución más adecuada para establecer este repositorio, y como no podía ser de otra manera, me he puesto a su disposición para colaborar en lo que pueda.

Veamos a partir de ahora como continua el MOOC; el segundo reto tiene que ver con los MUVEs, los Mundos Virtuales.

Nueva versión de OpenMeetings 2.0

En diciembre de 2011 el proyecto OpenMeetings fue aceptado por Apache software Foundation, creada en 1999 por los desarrolladores del servidor HTTP Apache y cuyo objetivo es dar cobertura legal a los programadores voluntarios que desarrollan sus proyectos bajo esta fundación.

El primer efecto de este cambio ha sido la discontinuación de la web histórica de Openmeetings http://code.google.com/p/openmeetings/ que ha dejado de mantenerse. Ahora la página web oficial del proyecto es

http://incubator.apache.org/openmeetings

En esta nueva página podemos encontrar desde mediados de julio una nueva versión del servidor OpenMeetings, cuyo nombre oficial es

apache-openmeetings-incubating-2.0.0.r1361497-14-07-2012

y que podemos descargar del apartado downloads.

El objetivo de este artículo es dar un repaso a las novedades de esta nueva versión, para lo que tras leer detalladamente la información que acompaña al producto y realizar una nueva instalación desde el inicio con esta nueva versión, los resultados del análisis son los siguientes:

Respecto a los requerimientos previos, debemos comentar lo siguiente:

• Se mantiene la necesidad de que la versión de Java disponible sea la de Oracle JRE 6 y no la openJDK, lo que sigue obligando a desinstalar la segunda e instalar la primera en determinadas distribuciones de linux que incorporan de serie openJDK.
• Además de OpenOffice, se hace una mención expresa a que se puede utilizar Libreoffice, algo que personalmente ya comprobé en su día.
• A los productos que deben estar preintalados (Java y OpenOffice ya mencionados, ImageMagick, GhostScript, SWFTools, FFMpeg, SoX ) se añade ahora JODConverter, una librería Java que se apoya en OpenOffiice/LibreOffice y que se utiliza para automatizar la conversión de documentos entre diferentes formatos. La descarga de la última versión se puede realizar desde

http://jodconverter.googlecode.com/files/jodconverter-core-3.0-beta-4-dist.zip

y para instalarlo basta con descomprimir el zip en una carpeta de programas, por ejemplo en /opt en linux o en Archivos de programas, en Windows. En la configuración de OpenMeetings debernos indicar el path a este producto.

• Si se desea utilizar otra base de datos a la proporcionada de por omisión (Apache Derby), es necesario en algunos casos instalar el driver de conexión entre Java y la BD en cuestión. En el caso de MySQL, el driver JConnector de MySql , que se puede descargar de

www.mysql.de/downloads/connector/j/

y se debe colocar en la carpeta

.../red5/webapps/openmeetings/WEB-INF/lib

Respecto al arranque del servidor, en esta versión ya no es necesario arrancar OpenOffice como servicio y mantenerlo activo, ya que el propio OpenMeetings, a través de JODConverter lo abrirá y cerrará cuando sea necesario.

El proceso de instalación básicamente es el mismo que el de las versiones anteriores, si bien ahora es posible realizar la instalación de red5+openmeetings desde la consola de comandos, opción que aún no he probado personalmente y que posiblemente no aporte grandes ventajas respecto a la instalación desde el navegador web.

Para aquellos que quieren migrar de una versión anterior, sigue sirviendo el sistema consistente en hacer copia de seguridad desde la versión previa y, tras instalar la nueva versión, importar la copia de seguridad. Estas operaciones, a partir de ahora, también podrán realizarse desde la consola de comandos.

Respecto a las mejoras que nos encontramos en el producto, la primera que llama la atención es que la interface de usuario se ha reconstruido totalmente, mejorando la apariencia.

También podemos ahora trabajar con temas XML. El tema por omisión se guarda en

.../red5/webapps/openmeetings/default-theme.xml

y en el archivo se guardan los colores del del borde, fondo y fuente y el path a los iconos. Si hacemos algún cambio, este se produce inmediatamente, basta con recargar el navegador.

El calendario también se ha rehecho desde cero. Esta nueva versión incorpora algunas funciones nuevas que habrá que analizar. Una de las más interesantes consiste en la posibilidad de proteger con contraseña las invitaciones enviadas desde el propio calendario.

También se anuncian mejoras en los componentes de audio y vídeo que ahora usan las especificaciones de Adobe SWF10, que mejoran las capacidades de los archivos Flash., y que se incorporan en las versiones de Adobe Flash 10 y posteriores

Respecto a las integraciones con otros productos, la aplicación contiene nuevos módulos que permiten la integración directa con Asterix, el software para gestión de centralitas VoIP. Habrá que probar, cuando sea posible. esta integración.

También dentro del capítulo de integraciones, he de mencionar que aunque no se ha actualizado el conector con Moodle desde octubre de 2011 y que este solo está soportado oficialmente para las versiones de Moodle 2.0 y 2.1, podemos decir que las pruebas realizadas apuntan a que igual que funcionaba con Moodle 2.2.x, también funciona correctamente con la versión actual 2.3.1+ .

Espero que este primer análisis sea útil para todos aquellos que usan OpenMeetings como herramienta de comunicación en sus cursos e-learning.

Proceso de actualización a Moodle 2.3

He estado trabajando en establecer un procedimiento de actualización a Moodle 2.3 que sea fácil y que no cause problemas, al menos, no más que los habituales en cualquier migración de Moodle. La verdad es que esta actualización no difiere mucho de otras actualizaciones con las que nos hemos encontrado anteriormente, por lo que he querido aprovechar la ocasión para recordar algunos aspectos a tener en cuenta a la hora de abordar una actualización de versión.

Para que este procedimiento sea efectivo se deben cumplir una serie de requisitos comunes a cualquier otra actualización de versiones anteriores, a saber.

• La instalación no debe incorporar desarrollos complementarios ni modificaciones de los scripts de serie. Si estos existieran deberán revisarse y rehacerse según las características de la nueva versión.
• La instalación no debe incorporar extensiones de terceros que no hayan sido validadas por sus autores (o por usted mismo si ha decido hacer las pruebas pertinentes con sus propios recursos). En esta afirmación incluimos los temas no estándar.
• La actualización debe hacerse desde la versión inmediatamente anterior, por lo que deberá actualizar su sitio Moodle, versión a versión, hasta llegar en nuestro caso a la 2.2.3.

Sobre este último aspecto hemos de comentar que el esquema de la base de datos de Moodle va cambiando de versión a versión y que si nuestro sitio es antiguo y ha sufrido ya varias actualizaciones, es posible que se haya ido degradando paulatinamente. No vamos a explicar ahora cómo solucionar este problema y solo recordaremos dónde está la información de cómo hacerlo después de la actualización http://docs.moodle.org/23/en/Verify_Database_Schema

En segundo lugar, es necesario recordar qué elementos debemos guardar para, en caso de problemas, poder echar marcha atrás y retornar a la situación de origen.

• Carpeta moodle, que contiene los scripts de la versión de moodle instalada así como las extensiones de terceros instaladas.
• Archivo config.php, ya copiado en la carpeta anterior, que contiene la configuración de acceso al sitio moodle.
• Carpeta moodledata, que contiene los archivos subidos al servidor.
• Base de datos moodle, que contiene la información de nuestro sitio. Para copiar la base de datos debemos recurrir a las utilidades de gestión de nuestra base de datos; si se trata de MySQl, la copia la podemos hacer con herramientas como phpMyAdmin.

Una vez hechas las copias de seguridad de estos elementos el siguiente paso es actualizar la carpeta moodle con la nueva versión. En muchas actualizaciones anteriores bastaba con sobrescribir los archivos de la carpeta moodle con los de la nueva versión, pero en el caso de Moodle 2.3 esto no está permitido. Si lo hacemos nos saldrá el siguiente mensaje de error

“ Some old PHP scripts have been detected which may indicate that you installed this version over an older one. Please fix the installation directory by removing all old scripts (except config.php) before installing the new version and then try the upgrade again. You can find more information in upgrade documentation at http://docs.moodle.org/23/es/Upgrading “

Cuya traducción, que ya he enviado para su incorporación al pack del idioma español, es

“ Se han encontrado algunos scripts antiguos de PHP, lo que podría indicar que ha instalado esta versión sobre otra versión más antigua. Por favor, solucione esto eliminando todos los scripts anteriores (excepto config.php) antes de instalar la nueva versión y vuelva a intentarlo de nuevo. Puede encontrar más información en la documentación sobre la actualización en http://docs.moodle.org/23/es/Upgrading “

En consecuencia, para actualizar nuestra instalación a Moodle 2.3 es necesario:

• Descargar el paquete moodle-2.3.zip de la web moodle.org
• Hacer una copia del archivo config.php
• Vaciar la carpeta moodle
• Descomprimir el contenido de moodle-2.3.zip en la carpeta moodle
• Volver a instalar las extensiones que teníamos anteriormente instaladas.
• Copiar de nuevo el archivo config.php guardado a la carpeta moodle

Hecho esto, basta con arrancar Moodle desde la URL habitual; se inicia el proceso de actualización que nos muestra la pantalla de extensiones con las operaciones a realizar sobre las mismas y posteriormente se realizan los cambios sobre la base de datos. Finalmente se nos presenta una página de configuración de algunos nuevos elementos que incorpora esta versión, como por ejemplo, activar la nueva opción “Arrastrar y soltar” para texto y enlaces, ya que por omisión solo viene activada para archivos.

Ya tenemos nuestro sitio Moodle actualizado a la nueva versión, pero aquí no hemos acabado, ya que queda pendiente la actualización de las actividades del tipo Tarea; recordemos que hasta ahora había 4 tareas diferentes, mientras que la nueva versión ha incorporado una nueva y única Tarea. La actualización se hace para todo el sitio mediante un motor de ayuda, que se deberá ejecutar como usuario admin, similar al que se incorporó en las versiones anteriores 2.x para la conversión de las preguntas de cuestionario y que podemos encontrar en

Ajustes – Administración del sitio- Motor de ayuda para actualizar tareas.

Una vez pasado este proceso ya podemos continuar trabajando con nuestro sitio Moodle actualizado ahora a la nueva versión 2.3 .

Espero que este artículo les sea útil.

Cuándo actualizar a Moodle 2.3.

Con la reciente liberación de la nueva versión 2.3 de Moodle vuelve a surgir el problema ya recurrente en los administradores de Moodle de si conviene actualizar inmediatamente a la nueva versión o si por el contrario, merece la pena esperar unas semanas o incluso unos meses hasta que se estabilice la nueva versión y los usuarios más valientes nos cuenten cómo les ha ido el proceso y qué problemas han encontrado

Cada instalación es un mundo diferente y no existe la respuesta universal a la pregunta anterior, pero lo que si es verdad es que a la hora de tomar nuestra decisión debemos tener en cuenta algunos aspectos que para los administradores experimentados son obvios, pero quizás resulten útiles a los administradores más noveles.

El primer aspecto a considerar es la cadencia temporal con la que Moodle está liberando las nuevas versiones, cada 6 meses. Este aspecto, muy valorado por unos y criticado por otros, genera, según como enfoquemos nuestra política de actualizaciones, una problemática diferente.

• Si nuestra política es estar siempre en la última versión, nos encontramos en una situación de actualizaciones constantes que puede generar un cierto estrés en la organización, ya que dos actualizaciones importantes al año, en según que instalaciones con centenares de cursos y miles de usuario, no son tarea fácil, por no hablar de determinados impedimentos metodológicos en la gestión de cambios propios de cualquier organización.
  
• Si nuestra política es conservadora y solo actualizamos las versiones cuando los requerimientos de nuestros usuarios no quedan satisfechos con la versión instalada, podemos encontrarnos con un salto de tres o cuatro versiones y con un proceso mucho más complejo desde el punto de vista técnico del que podíamos esperar inicialmente, y con unas necesidades de formación a nuestros usuarios muy superiores a las que corresponderían a un proceso de actualización continua.
  

La duda a resolver, por lo tanto, no es “actualizar o no actualizar” sino “cuándo actualizar”. Tarde o temprano deberemos dar el paso si no queremos tener un versión discontinuada y sin soporte, por lo tanto, hemos de elegir el momento óptimo en el que dar el salto de versión.

Pero antes vamos a hacer una observación importante: “No todas las actualizaciones suponen un salto equivalente”, es decir, no todas las actualizaciones de versión nos reportan el mismo nivel de beneficio ni todas las actualizaciones nos enfrentan a un mismo nivel de dificultad técnica.

Especial atención a aquellas actualizaciones cuyos requerimientos técnicos cambian respecto a la infraestructura (Base de Datos, Servidor Http, PHP.....). Afortunadamente no son habituales, pero generan toda una problemática añadida a tener muy en cuenta, como en el caso del cambio de versión de PHP que se produjo entre las versiones 1.9.x y las 2.x)

Una manera rápida de saber si una versión contiene cambios más profundos que otra es fijarnos en la numeración que la identifica, formada por 2 ó 3 números separados por puntos. Así,

• Los cambios más importantes, que implican un cambio profundo en la estructura interna del producto e incluso un cambio tecnológico de gran calado, corresponden al primer número. Así, en Moodle solo existen 2 grandes versiones, la 1.x y la 2.x. Cuando sale la versión 2.0 sabemos que Moodle, como producto, ha entrado en una nueva fase conceptual que aporta una nueva visión del producto y en paralelo requerirá un esfuerzo superior de actualización.
  
• Los cambios que afectan parcialmente al producto, a determinados módulos que son añadidos, sustituidos o eliminados, pero que no afectan al núcleo principal ni a la filosofía de trabajo, se identifican con el segundo número. Así, cuando sale la versión 2.3 sabemos que esta incorpora capacidades nuevas no incluidas en la versión anterior 2.2. Como regla general, estos cambios de versión generan cambios en la estructura de la base de datos de Moodle.
  
• El tercer número hace referencia a pequeños cambios dentro de la versión, en muchos casos correcciones de errores detectados, parches de seguridad o cambios pendientes que no entraron a tiempo en la versión anterior, En estos casos puede haber también cambios en la estructura de la base de datos, aunque no siempre es así. En breve veremos una versión 2.3.1 qué corregirá aquellos pequeños problemas que se puedan encontrar en la versión inicial.
  
• Finalmente, existen versiones cuya numeración finaliza con el signo más (+). Son actualizaciones semanales recomendadas, que incorporan pequeñas correcciones y parches que se considera importante ponerlas a disposición del usuario sin esperar a la siguiente subversión. Así, tras la salida de la versión 2.2.3, existe un paquete 2.2.3+ que se actualiza semanalmente y que conviene instalar regularmente.
  

Para conocer con detalle las mejoras que ofrece, cada nueva versión viene acompañada de documentación que se puede consultar en el área de descarga de Moodle (Release notes y Fixed issues) donde se informa de las nuevas funcionalidades que incorpora la versión y de los errores reportados que han sido corregidos. Es fundamental consultar esta documentación para tomar la decisión adecuada a nuestra situación.

De momento vamos a dejar al margen la actualización entre versiones principales, es decir, la migración de 1.9.x a 2.x, que requiere de una cierta planificación y vamos a suponer que nuestra instalación ya está en la línea 2.x. ¿Cómo debemos comportarnos a partir de ahora cuando se liberen nuevas actualizaciones?

Como con Moodle no todo son grandes instalaciones y existen multitud de sitios con un número reducido de cursos (pongamos menos de 20, de 50, o de 100, como prefiera el lector) y es en este segmento de instalaciones medianas o pequeñas donde vamos a analizar qué política puede ser más conveniente.

Como regla general podemos decir que es conveniente mantener nuestra instalación actualizada en el tercer número de la misma, proceso que normalmente no supone mayores riesgos si seguimos las instrucciones del documento Upgrading notes que acompaña a cada nueva versión en la página de descargas de Moodle. Estas actualizaciones suelen ser rápidas y no suelen presentar problemas.

Respecto al segundo número, (por ejemplo, de la 2.2.x a la 2.3), en mi opinión personal la actualización inmediata puede aplicarse en aquellas instalaciones en las que se cumplen las siguientes criterios, por otro muy comunes en los sitios de tamaño reducido;

• La instalación no debe tener desarrollos complementarios hechos a medida, ya que estos habrá que reprogramarlos de nuevo para adaptarlos a las características de la nueva versión.
  
• La instalación no debe tener instaladas extensiones de terceros, incluídos los “Themes” que sean compatibles con la nueva versión. Deberá esperar unas semanas a que las extensiones se validen por sus creadores, o si no, deberá hacer usted mismo las pruebas necesarias.
  

Dicho de otra manera, cuanto más estándar sea su instalación, más fácilmente podrá mantenerla actualizada

Finalmente, una recomendación, por muy pequeño que sea su sitio Moodle, “Tenga siempre un plan de marcha atrás, por si algo no sale bien”.

Calificación avanzada en Moodle 2.3. La calificación mediante Guías de Evaluación.

La nueva versión de Moodle 2.3, a punto de ver la luz, incorpora una serie de mejoras que ya hemos comentado anteriormente en el artículo Moodle 2.3. Llega la nueva versión. 

 

Como ya mencionamos entonces, Moodle 2.3 incorpora una nueva extensión para la Calificación avanzada de tareas, que se une a la Calificación por rúbricas que se incorporó en la versión 2.2 y de la que también hablamos en su momento en el artículo El sistema avanzado de calificaciones de Moodle 2.2. Evaluación por Rúbricas.

Este nuevo sistema de calificación avanzada “Marking guide” lo hemos traducido por “Guía de evaluación”, ya que básicamente consiste en definir una lista de elementos que configuran la tarea y que serán evaluados de forma independiente por quien tenga la responsabilidad de calificar la tarea, normalmente el profesor.

El proceso para calificar una tarea por este sistema es muy sencillo: cuando creamos la tarea, en el formulario de configuración de la misma debemos definir en el campo “Método de calificación” que queremos calificar mediante “Guía de calificación”.

Una vez guardada la tarea, en el menú de Ajustes de la tarea seleccionamos, en la opción “Calificación avanzada”, la opción, “Definir guía de evaluación”. Un nuevo formulario nos permitirá definir la lista de criterios por los que deseamos evaluar la tarea. Así, en cada criterio además de definir su nombre y la descripción del mismo, diferente para el alumno que para el profesor, deberemos definir la puntuación máxima permitida

La suma de calificaciones de los criterios deberá coincidir con la calificación máxima dada a la tarea, si bien, si no es así, el propio sistema realizará un escalado proporcional de forma automática.

Cuando el profesor vaya a evaluar la tarea vera cada uno de los criterios que conforman la Guía de evaluación y deberá calificar cada uno de ellos, de manera que a calificación total corresponderá a la suma de estas calificaciones parciales. El alumno, cuando consulte la calificación también verá el desglose de la misma según los criterios establecidos, aunque esto último se puede configurar para que no sea así.

Un aspecto interesante, es que las Guías de calificación ya realizadas pueden ser reutilizadas en otras tareas a modo de plantillas, de manera que podemos ahorrarnos mucho trabajo si construimos un sistema de Guías de evaluación estándar que utilizaremos habitualmente.

Desde luego se trata de un sistema muy útil para aquellos profesores que deban evaluar a sus alumnos según diferentes competencias y que no necesiten un sistema tan elaborado, matemáticamente hablando, como el que nos proporciona la evaluación por rúbricas, pero que sea un poco más detallado que la calificación estándar.

Si desea probar por usted mismo cómo es estes nuevo sistema de calificaciones, puede hacerlo libremente, en un Moodle 2.3 de pruebas que he habilitado para quien desee ver esta nueva versión y que permanecerá abierto hasta que se libere la versión definitiva.

http://tyfconsulting.com/moodle23