Plataformas MOOC comparadas (II)

Enunciado de los ejercicios 

Lo primero que podemos decir es que el interfaz gráfico, diseño y presentación de la sección de presentación de los ejercicios es muy mejorable. Me limitaré a mostrar una captura de pantalla:

Captura de pantalla 2016-04-25 a las 22.55.36

Desde luego, es de todo menos atractiva. Enormes cantidades de texto, sin gráficos ni separaciones evidentes. Ojo, no creo que sea un error del creador (creadores) del curso. Creo que es un error de diseño de la plataforma. Definitivamente no está preparada para impartir cursos MOOC. Veamos algo similar para el caso de Coursera:

maxresdefault

En la parte superior hay 3 cajas que dividen claramente las fases de un Ejercicio evaluado entre pares. En la parte central hay espacio para el enunciado del ejercicio y para aceptar el código de conducta. En la parte inferior hay una caja de texto para editar la respuesta o indicar mediante un enlace dónde encontrar la solución detallada. También permite guardar borradores (Save Draft), aspecto éste que brilla por su ausencia en MiriadaX.

En Coursera, también se especifica mediante colores (gris, verde, rojo) en que estado nos encontramos dentro de cada fase:

coursera_p2p_colores

En MiriadaX no existe este tipo de indicadores. Tampoco podemos auto-evaluarnos:

Captura de pantalla 2016-04-25 a las 23.23.16

Rúbricas (o la ausencia de ellas)

En MiriadaX, el interfaz para evaluar el trabajo de un compañero/a no dispone de una rúbrica de ayuda. No hay criterios, se limita a mostrar una caja de texto y una única puntuación, de 0 a 100:

sin_rubrica_miriadax

Esto es tremendamente incómodo. Al final, lo que hacen los alumnos es limitarse a escribir «Muy bien» o «Sigue así». Dos o tres palabras y una nota de 100. Algo rápido y sin críticas constructivas de ningún tipo. En Coursera, sin embargo, el interfaz es más rico, se dispone de rúbricas de evaluación y cada criterio puede ser evaluado de forma independiente. Además, existe también una caja de texto donde, en algún curso, se pide cumplimentar al menos 20 palabras:

rubric_webform

Además, el alumno siempre tiene disponibles los criterios de evaluación de la rúbrica cuando está respondiendo a las preguntas/trabajos, lo que facilita la labor de respuesta:

coursera-fail-2-1

Plataformas MOOC comparadas (I)

Introducción

A lo largo de esta semana iré publicando mis impresiones sobre las plataformas MOOC que he ido probando como alumno. Compararé aspectos relacionados con la docencia: herramientas para la presentación de contenidos, para el seguimiento del alumno, para la evaluación (autoevaluación, co-evaluación, hetero-evaluación), usabilidad, gestión de certificados, interacción entre usuarios (foros, chats) y también aspectos relacionados con el propio software que sustenta las plataformas (cómo están desarrolladas internamente, qué subsistemas usan, política de licencias).

Las plataformas que traeré a colación son edX, Coursera y MiríadaX,  porque son en éstas donde he trabajado como alumno, y edX y Moodle como plataformas en las que puedo decir algo sobre los aspectos de software, gracias a su licencia abierta.

Antes de nada, quería presentarme, haciendo especial hincapié en los aspectos relacionados con la enseñanza online que he trabajado, bien como alumno o bien como profesor.

También quiero dejar claro que todas las plataformas MOOC que tienen como objetivo expandir el conocimiento y lo hacen de forma gratuita y con materiales de calidad me merecen el mayor de los respetos. Me quito el sombrero ante el trabajo que han realizado (y siguen realizando) edX, Coursera, MiríadaX, Udacity, FutureLearn, P2P University y demás entidades. Lo que viene a continuación son una serie de posts sobre mi experiencia como usuario, como alumno o como desarrollador en todas estas plataformas, indicando los puntos buenos y malos y sugiriendo mejoras mediante análisis comparados.

Empezaremos comparando el sistema de MiríadaX con los de edX y Coursera, dado que son las plataformas sobre la que he estado trabajando más recientemente. MiríadaX usa internamente el CMS Liferay. No es una plataforma preparada ad-hoc para impartir MOOCs  (como podría ser Open-edX o la plataforma de Coursera) y eso se nota en multitud de detalles.  Veamos algunos de ellos, aspectos que no se han cuidado lo suficiente, no se han tenido en cuenta o son mejorables.

Variables sin valores asignados

Si nos fijamos en el mensaje de entrega de una tarea, veremos lo siguiente:entrega1

«La asignación de tareas para evaluar se realizará a las {4} del día {5}, fecha de la zona horaria {6}, que es la establecida en tu perfil.» No es algo que ocurra una vez en una pantalla, ni siquiera algo que ocurrió una vez o dos. Ocurre siempre, desde hace meses.

Incoherencia en la forma de dirigirse al alumno

¿Cómo nos dirigimos al alumno? ¿Debemos usar el tratamiento de usted o el de tú? Entiendo el trato de usted y me parece correcto. Pero en mi caso, me resulta muy artificial. Agradecería una opción que permitiera elegir entre una forma u otra de dirigirse al alumno. No obstante, eso no sería un error: basta con elegir el tratamiento. Sin embargo, lo que sí es un error es «bailar» en el uso de usted y tú.  Si nos fijamos en la ventana anterior, veremos un tratamiento de tú: «Próximamente recibirás…», «Recuerda realizar…». Sin embargo, en otras pantallas, vemos el tratamiento de usted, como en la siguiente: «Piensen bien su evaluación…», «El objetivo de este curso es sacar el máximo provecho al trabajo que están realizando…»

tu_usted

Imposibilidad de reintentar la entrega antes de que finalice el plazo

Una de las aportaciones interesantes de un MOOC es que el alumno puede trabajar por su cuenta, a su ritmo, e ir mejorando sus conocimientos mediante iteraciones: construye una solución y la guarda como posible envío. Esta primera solución seguramente no sea óptima. El alumno puede darse cuenta estudiando algo más, o comentando los problemas encontrados con sus compañeros en el foro. Esta retroalimentación le permitirá mejorar su solución y grabarla como una entrega mejorada. En cualquier caso, es muy conveniente que el sistema que da soporte al MOOC permita la grabación de soluciones. No digo que mantenga un histórico, bastaría con que nos deje guardar un único trabajo, pero que éste se pueda subir tantas veces como se quiera, siempre dentro del plazo de entrega. Cada vez que el alumno envíe, la nueva entrega sustituirá a la anterior (lo ideal, como digo, sería un histórico, pero esta solución parcial de «nos quedamos con la última», valdría). Lo que no es de recibo es limitar a un único envío, tal y como hace MiríadaX. Avisan por activa y por pasiva que el envío, único, es final. No importa que aún queden días para el «deadline». No podrás cambiar ni reenviar mejoras a tu trabajo, está prohibido mejorar 🙁 Este es un aspecto que ninguna plataforma MOOC (edX, Coursera, Udacity, FutureLearn, Google CourseBuilder) ha descuidado. Es un error de libro, sin embargo, ahí está.

entrega3

No entiendo esta restricción. Es muy probable que una vez entregada la tarea, y el alumno esté más relajado, se le ocurran mejoras a la entrega realizada. O simplemente, quiere enviar una versión preliminar – digna, pero no excelente – por si acaso no le da tiempo a completar la versión final, de mayor calidad. Tal cuál está planteada la entrega, esto no puede hacerse. Una entrega evaluada entre pares no es razón para este comportamiento. Puede alegarse que se hace para que los alumnos dispongan rápidamente de ejercicios para evaluar, pero no hay razón para hacerlo así. Se puede dejar un período de evaluación de una semana a partir del momento de la entrega. Por ejemplo,en edX y en Coursera, el alumno puede enviar tantas versiones de su tarea mientras no haya terminado el plazo de entrega.

Por otro lado, se recomienda adjuntar una versión del archivo html con la solución, pero si ya está online… no le veo mucho sentido. Entiendo que pueda ser una medida de seguridad (por si la versión online cae), pero implica nuevos problemas: si la versión online y el archivo (versión offline) varían, ¿cuál evaluar? si la versión offline no incluye referencias a gráficos o vídeos porque están enlazados, ¿qué hacer? y si las incluyen (¿un vídeo?), ¿para qué ofrecer dos versiones?.

Mala semana para la seguridad de las extensiones en Firefox y Chrome

Investigadores de seguridad presentaron la semana pasada, en la Black Hat Asia 2016, bajo la ponencia «Automated Detection of Firefox Extension-Reuse Vulnerabilities» una extensión que reutiliza código de otras ya instaladas con fines maliciosos. Es una técnica nueva (extension-reuse) interesante.

En febrero presentaron un artículo sobre la misma vulnerabilidad (CrossFire: An Analysis of Firefox Extension-Reuse Vulnerabilities) en el simposium «The Network and Distributed System Security Symposium 2016» organizado por la Internet Society.

Y siguiendo con los ataques de seguridad a las extensiones, hoy se publica una noticia sobre una empresa que en febrero compró una extensión bastante popular (Better History) para inyectarle código malicioso que hace que los navegadores de sus usuarios sean redirigidos, a través de un enlace lnkr.us, a páginas con banners -al parecer a la página que más pague a la empresa- cada vez que pinchan en un enlace (realmente el 50% de la veces y no es una redirección simple, sino que la página original a la que el usuario se dirigía también se abre). El comportamiento no es maligno únicamente por esto, sino porque la empresa de esta extensión está recogiendo datos privados sobre las URL que los usuarios visitan. Para más inri, el código fuente de Better History en GitHub no refleja los añadidos maliciosos que la compañía ha introducido.

Google ha eliminado la extensión de la Chrome Store, pero los usuarios han advertido de que este comportamiento se repite en otras extensiones populares como Chrome Currency Converter, Web Timer, User-Agent Switcher, Better History, 4chan Plus, and Hide My Adblocker.

Google ha eliminado también User-Agent Switcher, pero el resto sigue online.

Instalando mod_wsgi en OSX El Capitan

Receta rápida:

$ git clone https://github.com/GrahamDumpleton/mod_wsgi.git
$ cd mod_wsgi
$ ./configure
$ make
$ sudo make install
$ sudo vim /etc/apache2/httpd.conf

Añadir las siguientes dos líneas:

LoadModule wsgi_module libexec/apache2/mod_wsgi.so
WSGIScriptAlias / /Library/WebServer/Documents/

Reiniciar Apache y comprobar:

$ sudo apachectl restart
$ apachectl -M | grep wsgi
 wsgi_module (shared)

Podemos probar con este Hello World (hello.py). Copiarlo en /Library/WebServer/Documents y abrirlo desde el navegador con http://localhost/hello.py :

import os, sys
sys.path.append('.')
def application(environ, start_response):
    status = '200 OK'
    output = 'Hello world!!\n'
    response_headers = [('Content-type', 'text/plain'),
        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)
    return [output]

Done.

Transmission, torrents, OSX y malware KeRanger

Captura de pantalla 2016-03-07 a las 22.49.09 Cuando necesito descargar torrents, uso Transmission en Linux y uTorrent en OSX. No es que uTorrent esté libre de pecado (Spigot -PUP-,  EpicScale -mining de bitcoin no deseado, y demás basura), pero la semana pasada (4 de marzo) Transmission para OSX llevaba de regalo  KeRanger, ransomware. Sí, malware que cifra el contenido de tu disco duro y te pide un rescate – pagado en bitcoin, por supuesto- para obtener la clave que lo descifra. Parece ser el primer caso de ransomware dirigido específicamente a usuarios de OSX. Fue la gente de Palo Alto Networks fueron los primeros en dar el aviso, indicando que la web de Transmission había sido comprometida, dejando un fichero de instalación .dmg(la versión 2.90 de Transmission) infectado con KeRanger. Lo «bonito» del asunto es que esta versión de KeRanger había sido firmada con un certificado válido de desarrollador de aplicaciones para OSX, saltándose el control básico de Apple Gatekeeper que impide a un usuario básico instalar una aplicación que no venga firmada (se salta abriendo el binario con el menú contextual mientras pulsas Control, pero es una primera barrera de seguridad). Si el usuario instaló la versión infectada de Transmission, esta ejecutará una versión incrustada de KeRanger, esperará 3 días (suele ser habitual esperar a ejecutar el castigo, para ocultar al usuario el origen de la infección) y se comunicará con un servidor C&C (Command & Control) sobre la red Tor. A partir de ahí, cifrado del disco y petición de rescate (400 dólares).

Apple ha actuado rápido. Lo primero, invalidar el certificado con el que se firmó la aplicación en cuestión. Lo segundo, añadir una regla a XProtect, el sistema de lista negra que usa OSX por defecto. Puedes consultar los bichos que pululan por Internet en este fichero de tu OSX: /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist. ¿El primero de la lista? Nuestro amigo KeRanger:

Captura de pantalla 2016-03-07 a las 23.21.41

El análisis técnico del bicho en la página de Palo Alto Networks merece mucho la pena. Verás que el desarrollador está preparando funciones específicas para buscar y cifrar backups de Time Machine (qué angelito…). Verás también que usa tanto cifrado asimétrico (RSA) para cifrar un número elegido al azar junto a un IV dependiente del contenido del fichero, con lo que formará la clave que usará para cifrar el contenido del fichero usando cifrado simétrico (AES).

El 5 de marzo la gente de Transmission eliminó el ejecutable infectado de su web. Apple también ha hecho su trabajo. Pero el secuestro de webs para implantar malware parece que está de moda. Hace un par de semanas fue el turno de Linux Mint. Esta semana ha caído Transmission. ¿Quién será el siguiente?