Primero documentar, luego programar

Desde que pasas por las clases de ingeniería del software no hacen más que repetirte que primero hay que definir requisitos, realizar una cantidad ingente de diagramas UML, seguir una metodología, plantearte el ciclo de vida que vas a seguir,etc. Se supone que cuando realizas el proyecto de fin de carrera tienes que aplicar todo eso, primero dedicas tiempo a lo que se denomina planificar y documentar y luego pasas al desarrollo en estado puro, siempre dependiendo del tipo de metodología utilizada.

Dejando un poco de lado la teoría, y llevándolo a la práctica, opino que realizar una correcta planificación de tareas así como definir los requisitos es fundamental en cualquier desarrollo. Es cierto que resulta una tarea pesada, que estas deseando ponerte a cacharrear, ver los frutos de tu trabajo, pero después de dos PFC puedo decir que es lo mejor que he podido hacer. Es tan simple como plantearte qué quieres hacer y en qué orden lo vas a hacer, y si realizas algún diagrama en UML ya tienes claro cómo lo vas a hacer. Luego, cuando toca programar, a  muchos de los problemas ya les tienes una solución. También se evita que tu programa empiece a crecer con mejoras y más mejoras, es decir, como previamente te has planteado lo que quieres hacer, ya tienes unos límites de hasta donde debes llegar para adaptarte a los tiempos de desarrollo establecidos.

En definitiva, aunque me quejara de estar documentando cuando empecé el proyecto, me alegro de haberlo hecho así. Y no quiero ni imaginar como hubiera sido tener que terminar de programar y ponerme a realizar toda la documentación, ingeniería inversa se llama. Ahora en vez de dedicarme a poner todo bonito en un documento de Word, hubiera tenido que hacer toda esa pesada tarea para que no me sirviera de nada, trabajo y tiempo perdido.

Conectar Drupal con Moodle y WordPress

La parte central de Grial 2.0 gira en torno a la conexión entre estos tres gestores de contenidos, Drupal, Moodle y WordPress. Desde un principio, y por diversos motivos que ahora no vienen al caso, se decidió que la conexión fuera unidireccional, manteniendo Drupal como centro de mando y conectándolo con Moodle y WordPress para realizar las tareas pertinentes.

Para lograr este objetivo se han desarrollado dos módulos de Drupal, Drupal to WordPress y Drupal to Moodle, que realizan llamadas a WordPress y Moodle a través de XML-RPC. Ha sido necesario extender las funciones que estos dos CMS proporcionaban a través de su interfaz XML-RPC. Mediante un plugin de WordPress, Drupal to WordPress XML-RPC, se han añadido algunas funciones que permiten utilizar las características Multisite que hasta el momento no eran accesibles a través de este protocolo. En Moodle, en vez de extender la interfaz XML-RPC que viene por defecto, se ha optado por implementar una interfaz nueva, sencilla y potente, que permite realizar operaciones básicas de gestión de cursos.

Se ha intentado minimizar, en la medida de lo posible, las dependiencias entre estos pequeños desarrollos, de tal forma que Drupal to WordPress necesita del plugin correspondiente de WordPress, y Drupal to Moodle necesita la extensión de Moodle, pero tanto el plugin como la extensión pueden ser utilizados de forma independiente.

Todos los módulos y plugins estarán disponibles para su descarga en el repositorio oficial correspondiente a lo largo de este mes.

Cómo instalar Community-ID en Linux 2.0.0 RC3

En el sitio oficial de Community-ID existen una serie de sencillos tutoriales para realizar la instalación de la herramienta pero a partir de la versión 2.0.0 el proceso de instalación ha cambiado un poco. Este pequeño howto está construido a partir del tutorial original realizando algunas modificaciones y traduciéndolo al español.

Requerimientos

  • Web Server Se recomienda la versión 1.3 o superior de Apache Server. Pueden usarse alternativas de servidores HTTP como lighttpd, Cherokee HTTP server, nginx o cualquier otro servidor con el que estés familiarizado.
  • PHP Se require la versión 5.2.4 o superior de PHP, con la extensión MySQLi instalada.
  • MySQL Se requiere la versión 4.1 o superior de MySQL.

Base de datos

Community-ID necesita la creación de una base de datos en MySQL. Para ello se puede utilizar cualquiera de las herramientas de administración que existen para manejar MySQL

create database communityid;

Instalar los fuentes de Community-ID

Descargar en el siguiente enlace la versión 2.0.0 RC3 y descomprimirla en el directorio del servidor web.

cd /var/www
tar xvfz cid-2.0.0-RC3.tar.gz
mv communityid openid

o

cd /var/www
unzip cid-2.0.0-RC3.zip
mv communityid openid

Instalamos la aplicación a través de un navegador web indicando la siguiente URL:

http://mydomain.com/openid

El proceso de instalación solicitará el nombre de la base de datos previamente creada así como los datos de acceso para acceder a la misma. También se debe indicar el nombre de usuario y la contraseña para la cuenta de administrador. Dicha cuenta no dispondrá de un identificador OpenID por lo que sólo puede utilizarse para labores administrativas.

Fichero de configuración

El fichero de configuración, config.php, contiene una serie de variables que permiten configurar el funcionamiento de la aplicación. A continuación se listan algunos de los parámetros más relevantes.

# Activar (true) o desactivar (false) el formulario de registro de usuarios.
$config['environment']['registrations_enabled'] = false;
# Mantener un log del sistema. El fichero indicado debe crearse previamente y ser modificable por el usuarios del servidor web.
$config['logging']['location']              = '/var/log/communityid.log';

La sección de PASSWORDS contiene una serie de variables que permiten definir los requisitos mínimos que deben cumplir las contraseñas de los usuarios.

# Contraseña distinta al nombre de usuario
$config['security']['passwords']['username_different'] = true;
# Longitud mínima de la contraseña
$config['security']['passwords']['minimum_length'] = 6;
# true si la contraseña debe contener algún carácter numérico
$config['security']['passwords']['include_numbers'] = false;
# true si la contraseña debe contener caracteres no alfanuméricos
$config['security']['passwords']['include_symbols'] = false;
# true si la contraseña debe contener caracteres en minúsculas y mayúsculas
$config['security']['passwords']['lowercase_and_uppercase'] = false;

Permisos de acceso

Cambiamos los permisos de acceso a los ficheros de la aplicación.

cd /var/www
chown -R webserveruser:webserveruser  openid
find openid -type d -exec chmod 550 {} \;
find openid -type f -exec chmod 440 {} \;
cd openid
chmod u+w captchas

Configurar correo SMTP con Gmail en Community-ID

Community-ID viene configurado para realizar el envío de correo a través de Sendmail. Si lo que deseamos es que el envío se realice a través del servidor SMTP de Gmail hay que realizar unas pequeñas modificaciones en el fichero de configuración config.php.

Por defecto los campos correspondientes al email son:

$config['email']['transport']               = 'sendmail';
$config['email']['host']                    = '';
$config['email']['auth']                    = '';
$config['email']['username']                = '';
$config['email']['password']                = '';

En primer lugar debemos indicar smtp como tipo de transporte, todo en minúsculas, y en host smtp.gmail.com. El servidor SMTP de Gmail funciona mediante conexión ssl por el puerto 465 por lo que añadiremos a nuestro fichero de configuración dos nuevas opciones, $config[‘email’][‘ssl’] y $config[‘email’][‘port’]. Por último el tipo de autenticación debe ser login, indicando como usuario y contraseña una cuenta válida de Gmail y la contraseña correspondiente a la misma.

Después de estos cambios el fichero de configuración deberá tener una apariencia parecida a la siguiente:

$config['email']['transport']               = 'smtp';
$config['email']['host']                    = 'smtp.gmail.com';
$config['email']['ssl']                     = 'ssl';
$config['email']['port']                    = '465';
$config['email']['auth']                    = 'login';
$config['email']['username']                = 'tu-usuario-de-gmail@gmail.com';
$config['email']['password']                = 'tu-contraseña-de-gmail';

Desesperación

Esa es la palabra que mejor define mis últimos meses realizando el PFC. Tengo la cabeza llena de parches que pretendían solucionar el mundo, títulos de hilos en foros que otras personas desesperadas como yo comenzaron algún día, recetas mágicas para que todo funcione… Estoy segura de que muchas otras personas han tenido mi problema entonces por qué narices no consigo encontrar una solución en toda esa maraña de información que es Internet. Ante este alto nivel de saturación crees que has llegado a tu límite pero no, todavía puedes hundirte un poco más y es en ese momento cuando, si tienes algo de suerte, empiezas a hallar la solución.

Al principio todo parece tan fácil, yo sólo quería hacer que Drupal fuera un servidor de OpenID y que WordPress y Moodle fueran clientes. El core de Drupal proporciona un cliente OpenID y el servidor se instala como un módulo aparte. Ahí comenzó el problema, el dichoso módulo no funciona y lo peor de todo no se queja de ningún tipo de error.

Aquí comienza a entrar en juego la desesperación. Después de horas sin conseguir que funcionara pasamos a un cambio radical de estrategia, que le den por saco a Drupal como OpenID provider, me monto el mío propio y que todos los servicios sean clientes. Vale, pues el cliente OpenID de Drupal tampoco quiere funcionar.

Unas horas después de otros cuantos parches, consejos, recetas, he conseguido que, utilizando Community-ID como OpenID provider, Drupal y WordPress funcionen correctamente como clientes siempre y cuando Drupal se encuentre en un servidor distinto al que esté el servidor de OpenID. Mañana será otro día, a ver si el cliente de Moodle no da problemas…