Dónde estamos

Se acercan las evaluaciones para el CUSL7 (Concurso Universitario de Software Libre en su séptima edición), por lo que este post servirá para resumir lo que llevamos avanzado del proyecto y lo que queda por hacer.

El bloque de EDUtwitter ya es una realidad. Es un bloque para Moodle que cuenta con las siguientes funciones:

· Visualización personalizable en el bloque de los tweets con el hashtag propio del curso.
· Generador automático aleatorio del hashtag del curso.
· Formulario para que únicamente los profesores puedan enviar tweets desde la cuenta propia del curso sin necesidad de iniciar sesión en Twitter.
· Formulario para que los alumnos registren su nombre de usuario en Twitter.

Con todo esto ya en funcionamiento, quedaría por realizar las siguientes funciones para completar la primera versión del bloque:

· Generación de estadísticas de los tweets de los alumnos haciendo uso de la Stream API de Twitter (ya que la REST API usada en el resto de funciones sólo busca tweets con una semana de antigüedad como máximo).
· Envío de tweets desde la cuenta propia del curso reflejando la actividad reciente del curso, envío controlado por el cron.php de Moodle.

Seguimos investigando y trabajando...

Accediendo a la base de datos de Moodle

La documentación oficial de las funciones para acceder a las tablas de la base de datos de Moodle la podéis encontrar aquí: http://docs.moodle.org/dev/Data_manipulation_API.

En este post sólo voy a resumir algunas de las más comunes que son las que he tenido que usar para almacenar en una tabla los nombres de usuario en Twitter de los alumnos.

Si en un archivo vamos a acceder a alguna tabla de la base de datos, lo primero que tenemos que hacer es declarar la variable global:

global $DB;

· Insertar un registro en una tabla

$DB->insert_record($table, $dataobject, $returnid=true, $bulk=false) 

Donde $table es el nombre de la tabla donde se quiere insertar y $dataobject el objeto que contiene los datos a insertar.


· Actualizar un registro en una tabla

$DB->update_record($table, $dataobject, $bulk=false)

Donde $table es el nombre de la tabla donde se quiere insertar y $dataobject el objeto que contiene los datos a insertar con uno de los campos "id" que especifica el registro a actualizar.


· Eliminar un registro en una tabla

$DB->delete_records($table, array $conditions=null) 

Donde $table es el nombre de la tabla donde se quiere eliminar uno o más registros y $conditiones son las condiciones que cumplirán los elementos que se eliminarán.
Si quieres actualizar un registro, usa update_record, porque eliminarlo y volver a insertarlo provoca que se quede una línea en blanco en la tabla y es menos eficiente.


· Obtener registros de una tabla

$DB->get_records($table, array $conditions=null, $sort='', $fields='*', $limitfrom=0, $limitnum=0) 

Donde $table es el nombre de la tabla donde se encuentran los registros y $conditiones son las condiciones que cumplirán los elementos que se obtendrán.

Por último, decir que si es una tabla con un alto número de resgistros, es mejor usar recordsets:

$rs = $DB->get_recordset(....) {
foreach ($rs as $record) {
    // Hacer lo que quieras hacer con esos registros
}
$rs->close(); // No te olvides de cerrarlo cuando termines de trabajar con ellos

Creación de Bloques en Moodle (Parte 1)

Antes que nada avisar de que este artículo es una simplificación de la documentación en inglés de la siguiente página: http://docs.moodle.org/dev/Blocks.
Éste consiste en un tutorial paso a paso para crear un primer Bloque que muestre simplemente un texto HTML en Moodle. "edutwitter" será el nombre que daremos al Bloque de prueba.

Archivos

En el caso más básico de creación de Bloque, son necesarios tres archivos:
- /blocks/edutwitter/block_edutwitter.php
Contiene la definición de la clase, también el desarrollo en si, se controla el plugin y lo que muestra en pantalla.
- /blocks/edutwitter/version.php
Contiene la información sobre la versión y otros parámetros avanzados.
- /blocks/edutwitter/lang/en/block_edutwitter.php
Contiene la información sobre el idioma (inglés) del Bloque. Podemos desarrollar varios idiomas en la carpeta lang.

Primeras líneas

En /blocks/edutwitter/block_edutwitter.php:

<?php
class block_simplehtml extends block_base {
    public function init() {
        $this->title = get_string('simplehtml', 'block_simplehtml');
    }

Estas líneas simplemente representan la definición de la clase y la función init() esencial para todos los bloques, cuyo propósito es dar valores a las variables miembro de la clase que necesitan ser inicializadas. Dentro de ésta inicializamos el título del bloque que aparecerá.

En /blocks/edutwitter/version.php:

<?php
    $plugin->version = 2012010900; // YYYYMMDDHH (año, mes, día, hora)
    $plugin->requires = 2012010900; // YYYYMMDDHH

Aquí ponemos tanto la versión de nuestro Bloque, como la versión mínima que requiere de Moodle para funcionar.

En /blocks/edutwitter/lang/en/block_edutwitter.php:

<?php
    $string['pluginname'] = 'EDUtwitter';
    $string['edutwitter'] = 'EDUtwitter';

Este archivo simplemente actúa como diccionario.

Seguiremos en próximas entregas.

Extensión de Moodle: ¿Actividad o Bloque?

Desde que comencé a trabajar en este proyecto, tenía la duda de cómo enfocar, desde el punto de vista de Moodle, el desarrollo del plugin para interactuar con Twitter. Casi toda la documentación que encontré estaba enfocada a la creación de una nueva "Actividad" en Moodle. Un ejemplo de actividad serían todas las funcionalidades que puede tener un curso: Foro, Wiki, Administrador de Tareas...
Aunque claro, pronto me di cuenta que implementarlo de esa forma tenía poco sentido práctico. Ya que no es una Actividad en sí, sino que el plugin a desarrollar lo que hace es tomar datos de las otras actividades. Además, en un curso puedes añadir el número de instancias que quieras de una Actividad, y eso carecía de sentido en este proyecto.
Entonces empecé a ver algo que se llama Bloque. Éste se añadía a los cursos y se quedaba en uno de los márgenes, normalmente cumpliendo alguna utilidad como búsqueda o incluso mostrando un TimeLine de Twitter. En un principio no me pareció lo que buscaba, ya que pensaba que la actividad que tenía un bloque se limitaba a mostrar cosas, y el funcionamiento que pretendo que tenga el plugin es que trabaje de forma interna.
Desde aquí tengo que dar las gracias a Daniel Cabeza y Juan Antonio Caballero del proyecto EVALfor por despejarme muchas de las dudas y orientarme respecto a los bloques en este caso. Resulta que el Bloque es lo que mejor se ajusta a este proyecto, ya que sólo encontramos una instancia de éste en el curso y se puede programar para que internamente trabaje con el cron de Moodle y obtenga información de la base de datos.
Manos a la obra...

Recapitulando

Acabamos de entrar en el mes de marzo, y es el momento de revisar el trabajo realizado y lo que queda por hacer.

La línea de trabajo hasta ahora seguida ha estado marcada por lo siguiente:

· Investigación sobre la plataforma Moodle (instalación, administración, desarrollo de aplicaciones).

· Conocer el funcionamiento y la estructura interna de los plugin de Moodle.

· Revisar los plugin creados de Moodle buscando coincidencias con el proyecto actual.

· Pruebas sobre el API de Twitter, qué ofrece y cómo puede combinarse con las aplicaciones.

· Repaso de la programación en el lenguaje PHP.

· Uso de la librería cURL de PHP para realizar peticiones al API de Twitter.

· Documentación a través de tutoriales en el blog del proyecto.

En las próximas semanas habrá que tratar las siguientes cuestiones:

· Integrar las peticiones al API de Twitter a través de PHP en la estructura base de un plugin de Moodle, y buscar la forma de representar los resultados, de forma que se puedan hacer pruebas directamente desde la plataforma.

· Empezar a definir funcionalidades concretas para desarrollar dentro del plugin.

· Establecer la lógica de cómo van a funcionar las autentificaciones en el plugin, cuándo se van a realizar peticiones públicas, cuándo se va a usar la cuenta del profesor, si es útil que los alumnos asocien su perfil a su cuenta en tuenti y el plugin pueda hacer uso de ella...

Próximamente en el blog nuevos tutoriales que aún faltan por retocar, sobre las peticiones al API de Twitter en PHP.

API de Twitter

Ya va siendo hora de que hablemos un poco del otro pie del proyecto: Twitter y su API.

Es obligatorio ahora hacer referencia a la documentación oficial de Twitter, que podemos encontrar aquí.

Me voy a ahorrar un poco el apartado más técnico del API, ya que es una información que podéis encontrar en la documentación, y os voy a contar cómo empecé a trastear un poco con ésta.

Twitter nos proporciona tanto dos API de tipo REST como un API streaming. Nos vamos a decantar por el REST. A través de una consola podemos realizar peticiones públicas al API. Es decir, peticiones que no necesitan autentificarse como una cuenta, como por ejemplo, obtener el TimeLine público en un momento dado.

Para realizar todos los tipos de peticiones, tendremos que hacerlo a través de una autentificación. Para comenzar, iniciaremos sesión con nuestra cuenta de twitter en https://dev.twitter.com/apps/new. Entonces nos aparecerá un formulario en el que tendremos que registrar nuestra aplicación.

Una vez rellenemos los campos que nos piden, accederemos al perfil de nuestra aplicación. Twitter sigue un sistema de autentificación llamado OAuth. Así que en el apartado OAuth Settings, encontramos los datos necesarios para realizar peticiones que no sean públicas, sino a través de una cuenta, con una consola.

Para no utilizar una aplicación externa, podemos simplemente entrar en la página https://dev.twitter.com/console, donde tenemos una consola que nos proporciona Twitter para hacer pruebas.

Ahora podemos hacer todas las peticiones públicas que queramos. Para hacer peticiones privadas, pulsamos sobre el candado y le damos a "OAuth". Nos dará la opción de iniciar sesión con nuestra cuenta y ya podremos realizar las peticiones privadas.

Vamos a ver dos ejemplos:

· Petición pública.

Podemos pulsar por ejemplo en Trends -> trends/daily. Ahora pulsamos el botón GET. Tenemos dos pestañas, en la pestaña Request podemos ver qué petición se ha realizado y en la pestaña Response podemos ver la respuesta. En este caso, los trending topics de distintas horas en las últimas 24 horas.

· Petición privada.

Por ejemplo, vamos a escribir un tweet desde la consola en nuestra cuenta promocionando el blog del proyecto. Para ello, pulsamos en Tweets -> statuses/update y sustituimos en la petición http "{status" por el texto que queremos publicar en el tweet. En este caso,

http://api.twitter.com/1/statuses/update.json?status=Podeis seguir los avances del blog en http://edu-twitter.blogspot.com/

Esta vez pulsamos sobre POST y no GET, ya que estamos enviando información y no sólo obteniendo. El resultado es el siguiente:

Y con esto ya podemos ir probando diferentes peticiones al API de Twitter.

Antes de finalizar, hay que mencionar que existen un límite de peticiones, 150 es el límite máximo de peticiones por hora en el caso de peticiones no autentificadas y 350 por hora en el caso de que las hagamos a través de una cuenta.

Instalación de un plugin en Moodle

La M de Moodle proviene de la palabra "modular". Moodle está pensado para que se le puedan añadir fácilmente funcionalidades, y éstas se añaden a través de los plugins, que pueden ser de varios tipos.

Como el proyecto consiste en la elaboración de un plugin, voy a explicar aquí cómo podemos instalar un plugin en Moodle, utilizando uno cualquiera como prueba.

El plugin que he escogido es "OU blog", que consiste en una tarea estilo blog. El único criterio de elección que he seguido ha sido la fácil comprobación de funcionamiento del plugin, que consistirá simplemente en crear una actividad en el curso de ese tipo.

Paso 1 - Descarga del plugin

Recientemente, se ha abierto un Directorio de Plugins divididos en categorías por parte de Moodle.org, que podemos encontrar en el siguiente enlace:

http://moodle.org/plugins/index.php

En este caso, el plugin "OU blog" se encuentra en el siguiente enlace:

http://moodle.org/plugins/view.php?plugin=mod_oublog

Ahora sólo queda pinchar en la pestaña "Download versions" y descargar la versión que queramos.

Tendremos entonces un archivo zip con el plugin.

Paso 2 - Copia de la carpeta del plugin en el directorio de Moodle

Descomprimimos el archivo zip y tenemos una carpeta llamada "oublog" con los archivos del plugin.

Aunque en la instalación de plugins sigue un patrón general, leemos el archivo README por si tenemos que realizar alguna modificación especial.

En este caso, lo único que tenemos que hacer es copiar la carpeta "oublog" dentro de la carpeta "mod" de la raíz de instalación de Moodle. En mi caso, "/var/www/moodle/mod".

Si todo ha ido bien, la próxima vez que iniciemos sesión como Admin en Moodle, nos aparecerá una pantalla como esta:

Paso 3 - Comprobaciones

En esta última ventana que nos ha aparecido, pulsamos el botón "Actualizar" y veremos que la versión se ha actualizado correctamente y pulsamos en "Continuar".

Ahora podemos añadir una nueva tarea al curso que deseemos, y podemos comprobar que ha aparecido la opción "ou blog".

Esta es la captura de un post de prueba:

Paso extra - Eliminación del plugin

Si quisiéramos a continuación o en cualquier otro momento eliminar el plugin, tenemos que seguir las siguientes instrucciones:

- Nos vamos a Administración del sitio -> Extensiones -> Módulos de actividad -> Gestionar actividades

- Pulsamos en "Borrar" en la fila de "OU blog" y luego en el botón "Continuar".

- Para completar el proceso, tenemos que borrar la carpeta "oublog" del directorio mod de Moodle, para evitar reinstalación la próxima vez que entremos.