Comunidad y software libre

12/10/2009

El otro día estaba hablando con una buena amiga de la facultad sobre su proyecto fin de carrera, se trata de un portal web implementado con tecnología Drupal, me preguntaba si conocía algún tipo de software, libre, para hacer pruebas de usabilidad, la verdad que me quedé un poco a cuadros, ya que no tenía idea de qué contestarle.

Cuando llegué a mi casa al curiosidad me pudo y me puse a buscar información acerca de este tema, tras un rato empecé a vislumbrar que para la realización de las pruebas de usabilidad existen dos tipos de herramientas, las herramientas de eyetracking y las herramientas de clicktracking. Mientras que las primeras, las más avanzadas, se basan en recoger dónde mira el ojo cuando está visualizando la información, las segundas recogen dónde ha hecho click el ratón en la página html, ambas, sin embargo, muestran los resultados de una forma muy parecida, utilizando heatmaps.

Ejemplo de heatmap

Ejemplo de heatmap

El siguiente paso fue buscar herramientas que proporcionaran las funcionalidades de las que hablaba antes, cuál fue mi sorpresa cuando de repente veo que existe un módulo de Drupal que permite mostrar heatmaps integrándose con la librería de la herramienta ClickHeat.

Estas son las cosas que a uno le hacen pensar y plantearse cosas. La oferta de gestores de contenidos de software libre es amplísima, Drupal, OpenCms, Joomla, Mambo, Magnolia y un largo etcétera, pero a la hora de elegir uno en ¿qué parámetros debemos basarnos?, pueden ser muchos, rendimiento, escalabilidad, curva de aprendizaje, etc, pero para mí uno indispensable es la comunidad de usuarios que haya alrededor del cms en cuestión, una comunidad activa que ayude a través de foros, faq´s, listas de correos, etc, una comunidad que desarrolle y comparta sus desarrollos.

En mi experiencia con los gestores de contenidos he tenido la oportunidad de trabajar con dos de ellos, OpenCms y Drupal. Independientemente de la tecnología, arquitectura, etc utilizada en cada uno de ellos hay una diferencia entre ellos que veo sumamente clara, y es la comunidad, mientras que en Drupal tenemos una activa comunidad con más de 300 módulos desarrollados, compatibles con la versión 6 del gestor de contenidos, en OpenCms es complicado si quiera encontrar una décima parte de esos módulos.

¿Por qué en una comunidad autónoma, como la nuestra, en la que se ha hecho y se sigue haciendo una apuesta tan fuerte por el software libre son tan pocas las empresas proveedoras que siguen este enfoque y se convierten en meras consumidoras de software libre?

Como he citado en otras ocasiones:

El software es como el sexo, es mejor cuando es libre. Linus Torvalds

Anuncios

Software libre, de verdad

03/08/2009

Hace algún tiempo comenzamos con el desarrollo de un proyecto utilizando tecnología OpenCms, como fruto de este trabajo hemos liberado cinco nuevos módulos que esperamos sea de utilidad para la comunidad (los módulos están modelados con maven y documentados con docbook):

RestrictedVFSWidget

Este módulo es una evolución del wdiget de exploración de OpenCms, con él se modelará el comportamiento de un árbol de exploración del directorio virtual de OpenCms en el que tan sólo se mostrarán los directorios y aquellos tipos de contenidos que se hayan configurado en la declaración del tipo de contenido que lo use.

SurveyModule

Con este módulo se amplía el funcionamiento del módulo Alkacon OAMP Survey Module, de manera que se ofrece la posibilidad de generar las gráficas de los informes en flash mediante Open Flash Chart.

Modulo Alfresco

El objetivo de este módulo es proporcionarle a los usuarios de OpenCms una herramienta con la que asignar recursos de un gestor documental Alfresco para ser utilizados en el portal. De esta forma se consigue separar la capa de gestión de contenidos de la capa de gestión documental, pudiendo aprovechar todas las funcionalidades que un gestor documental como Alfresco proporciona.

Georeference

Este módulo permite llevar a cabo la geolocalización de puntos a través de Google Maps, estableciendo las localizaciones directamente sobre un mapa que se muestra en el formulario de alta/edición de contenidos de OpenCms.

Thesaurus

El objetivo de este módulo es proporcionarle a los usuarios de OpenCms una herramienta con la que etiquetar los contenidos (noticias, eventos, etc) que se utilicen en el portal.

El software es como el sexo, es mejor cuando es libre. Linus Torvalds


Puntos de administración en OpenCms 7.0.5

25/05/2009

Hace ya algo menos de un año que comencé a trabajar con el gestor de contenidos OpenCms 7.0.5, durante este tiempo he desarrollado nuevos tipos de contenidos, widgets personalizados y puntos de administración, para el desarrollo de estas tareas me he servido de muchos recursos online pero sobre todo me ha sido de gran utilidad el foro de la comunidad de OpenCmsHispano, es por ello que he decidido realizar este tutorial cuando el otro día me encontré con este mensaje, manos a la obra.

Un punto de administración en OpenCms es una entrada en la vista de administración del gestor de contenidos con la que podremos realizar ciertas operaciones, OpenCms trae en su distribución básica una serie de entradas de administración con la que se podrán llevar a cabo tareas de administracion de usuarios, módulos, caché, etc, así como los mecanismos necesarios para extender con nuevas entradas estas funcionalidades de administración

Vista de administración del workplace

Vista de administración del workplace

Para crear un nuevo punto de administración en OpenCms deberemos crear la correspondiente estructura de directorios en /system/workplace/admin es en este directorio donde se definen los puntos de administración a través de la creación y edición de propiedades de los directorios.

Correspondencia con la zona de administración

Correspondencia con la zona de administración

En este tutorial vamos a crear un nuevo punto de administración en OpenCms denominado “Personas” que nos permitirá hacer CRUD de entidades de tipo persona, para ello he desarrollado un nuevo módulo que he denominado “PersonManagement”. Como veréis cuando instaléis el módulo (y reincieis el servidor de aplicaciones) el módulo genera un nuevo directorio /system/workplace/admin, si accedemos a las propiedades de este directorio veremos que se encuentran editadas las siguientes propiedades:

  • Description: Establece el texto que se mostrará en la caja “Ayuda” de la zona de administración.
  • NavImage: Establece la imagen que se mostrará en la zona de administración.
  • NavInfo: Establece el nombre del grupo al que pertenecerá el nuevo punto de administración.
  • NavPos: Establece con un número real (float) la posición que ocupará el icono del nuevo punto de administración.
  • NavText: Establece el texto que aparecerá bajo el icono del punto de administración.
  • Title: Establece el título del directorio aunque no es de utilidad dentro de la zona de administración.
  • admintoolhandler-class: Establece la clase que se ejecutará para hacer la gestión de los permisos de acceso al punto de administración.
  • default-file: Establece la página jsp que se ejecutará cuando accedamos a ese directorio.
Propiedades del directorio

Propiedades del directorio

Si accedemos a este directorio veremos que podemos encontrar tres páginas jsp person_list.jsp (genera el listado de los elementos), person_edit.jsp (genera el formulario de edición de los elementos de tipo persona) y person_new.jsp (genera el formulario de creación de elementos de tipo persona), si accedemos a cada una de estas páginas veremos cómo podemos encontrar un fragmento de código que sigue el siguiente patrón:

<%@page import=”paquete.de.la.clase.*”%>
<%
NmbreClase admin = new NmbreClase(pageContext, request, response);
admin.displayDialog();
%>

Como podemos observar para generar el formulario solo necesitamos una clase, que extenderá las correspondientes clase de OpenCms, y que se encargará de generar todo el código html necesario para
generar un listado o un formulario de edición o de alta.

En estas páginas jsp también es necesario editar las propiedades para que el contenido de dichas páginas se muetren correctamente.

También me gustaría haceros un par de recomendaciones para el desarrollo de funcionalidades con OpenCms:

Código del módulo

La información compartida progresa y mejora, de manera que su valor sólo puede aumentar. El conocimiento acaparado simplemente se detiene. Paul Jones, director de ibiblio.


Openfire y OpenCms se conocen

28/04/2009

En el proyecto en el que actualmente estoy trabajando tiene la necesidad de incorporar un servicio de mensajería instantánea (IM), como punto de partida mi compañero Manu me recomendó que empezara estudiando la tecnología que había desarrollada alrededor del protocolo Jabber (protocolo libre IM basado en XML).

Alrededor de este protocolo hay toda una comunidad de software libre que se dedica al desarrollo tanto de servidores como de clientes XMPP. Entre todos los servidores que estuve evaluando me decanté por uno que por su extensibilidad, tecnología y comunidad me convenció, Openfire. Se trata de un servidor de código abierto basado en Java, extensible a través de plugins y desarrollado por la comunidad bajo licencia GPL.

Como comentaba antes en el proyecto existía la necesidad de integrar un servidor de mensajería instantánea, la integración de Openfire con Opencms, el CMS que estamos utilizando, consistía en la autenticación de los usuarios. Para conseguirlo hemos tenido que hacer dos cosas, una del lado de OpenCms y otra de Openfire.

OpenCms

Hemos desarrollado un módulo de OpenCms que ofrece un servicio web con dos operaciones para realizar la autenticación de usuario, a este servicio web solo hay que pasarle el usuario y la contraseña encriptada, él se encargará de comprobar que el usuario y la contraseña son correctos así como de chequear toda la lógica de negocio, devolviendo un objeto en el que se indica si el proceso ha sido correcto.

Openfire

En este caso hemos desarrollado un plugin que cuenta con un cliente para el servicio web y que es el encargado de hacer la petición. Para que Openfire realice la autenticación utilizando la clase que hemos desarrollado, y que ha de implementar la interfaz (AuthProvider), en el método de inicialización del plugin hemos de cambiar la propiedad provider.auth.className para indicarle que utilice nuestra clase, es sumamente importante que previo a este paso hayamos registrado en el classpath del plugin dicha clase.

Una vez hecho esto, OpenCms y Openfire ya se conocen ;-p

No hay lugares remotos. En virtud de los medios de comunicación actuales, todo es ahora. Herbert Marshall Mcluhan


Web Services sobre OpenCms

18/01/2009

En este post voy a explicar un tema muy específico: cómo generar un módulo de OpenCms 7.0.5 que despliegue un web service sobre mismo contexto de OpenCms 7.0.5.

Para ello me recomendaron que me basara en la arquitectura Axis2 de Apache.

Antes de comenzar es muy importante que se haya comprendido cómo se ha de trabajar con un módulo de OpenCms 7.0.5 y Maven, para ello me gustaría recomendaros el estupendo post que en su día escribió mi compañero Antonio Manuel Muñiz respecto a este tema.

El primer paso que debemos dar para poder desplegar servicios web sobre el contexto de OpenCms, a través de un módulo, es preparar la instancia de OpenCms para tal propósito, para ello crearemos dentro del directorio “WEB-INF” un nuevo directorio “services” tal y como se muestra en la siguiente ilustración:

Estructura de directorios

Estructura de directorios

A continuación deberemos modificar el fichero web.xml de OpenCms para declarar el servlet de Axis2 que se encargará de atender las peticiones a los servicios web que declaremos.

<servlet>
—-<servlet-name>AxisServlet</servlet-name>
—-<display-name>Apache-Axis Servlet</display-name>
—- <servlet-class>org.apache.axis2.transport.http.AxisServlet</servlet-class>
—-<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
—-<servlet-name>AxisServlet</servlet-name>
—-<url-pattern>/services/*</url-pattern>
</servlet-mapping>

Una vez hecho esto, crearemos un módulo de OpenCms y modificaremos las directivas “<exportpoint />” del fichero “manifest.xml” para que OpenCms copie en el directorio “/WEB-INF/services” los servicios web desplegados como ficheros .aar

<exportpoint uri=”/system/modules/com.test.webservice.regard/services/” destination=”WEB-INF/services/”/>

Lo que tenemos que hacer a continuación es generar el fichero pom.xml necesario para que realice dos tareas fundamentales: obtener las librerías necesarias para que los servicios web puedan funcionar sobre la instancia de OpenCms y para que genere el fichero .aar a partir de los fuentes que le indiquemos.

Una vez hecho todo lo anterior tendremos listo el módulo para poder generar servicios web que corran dentro del mismo contexto que el OpenCms sobre el que se despliegan y, por tanto, puedan acceder a su información, para ello lo último que tendremos que hacer será generar un Singleton o un método dentro de la propia clase que se encargue de iniciar un objeto de la clase CmsObject que será el objeto a partir del cual podremos realizar todas las operaciones necesarias. Para llevar a cabo el desarrollo del servicio web para Axis2 os recomiendo el siguiente post.

Una vez hecho todo lo anterior ya solo nos quedará desplegar el módulo OpenCms y probar el nuevo servicio web a través de algún programa de generación de clientes.

0021

Respuesta positiva

Respuesta negativa

Respuesta negativa

Aquí dejo el módulo por si os es de utilidad.


Integración continua con PHP (II). Pruebas unitarias.

27/12/2008

En el proceso de construcción del software la implementación y ejecución de pruebas unitarias es, entre otros, uno de los pilares fundamentales. La creación de tests unitarios y su ejecución automatizada permiten dotar a dicho proceso de construcción del software de confianza y calidad, permitiendo éstos parámetros, a su vez, la puesta en marcha de metodologías de trabajo ágiles.

En la actualidad existen en el mercado del software libre multitud de frameworks que facilitan la tarea de implementación y ejecución de pruebas  unitarias, concretamente, para entornos de desarrollo basados en tecnología PHP nos encontramos con frameworks como PHPUnit o SimpleTest, aunque también existen frameworks de desarrollo, como Symfony, que proporcionan su propia suite de testing.

En el presente post nos centraremos en PHPUnit y su integración con Phing para un proyecto basado en Symfony 1.0 (instrucciones de instalacion).

Para instalar PHPUnit ejecutaremos las siguientes instrucciones (se supone que tenemos instalado pear):

  • pear channel-discover pear.phpunit.de
  • pear install -a phpunit/PHPUnit

Una vez instalado PHPUnit, crearemos un proyecto symfony (con la correspondiente aplicación y módulo), para este post vamos a crear una clase Contact con su correspondiente test ContactTest. Para ejecutar los tests nos situaremos en la carpeta “/lib/classes/” del proyecto y ejecutaremos la siguiente instrucción:

  • phpunit *Test.class.php

Pero, cómo podemos automatizar la ejecución de las pruebas, es en este punto donde entra en juego la herramienta de la que hablamos en el anterior post, phing, con ella podemos declarar una nueva tarea que ejecutará todas las pruebas unitarias que hayamos implementado para la aplicación que estamos desarrollando. veámoslo.

En primer lugar tendremos que crear un nuevo fichero build.xml con el que construiremos nuestra aplicación, este fichero contará, entre otras, una tarea de ejecución de pruebas que será algo como lo siguiente:

<target name=”test”>
<phpunit2 haltonfailure=”false” printsummary=”true”>
<batchtest>
<fileset dir=”./lib/classes/”>
<include name=”*Test.class.php”/>
</fileset>
</batchtest>
</phpunit2>
</target>

Con esta tarea le estamos indicando a phing que queremos ejecutar todas las pruebas que se encuentran en el directorio “lib/classes/”, que no queremos que se pare si encuentra alguna prueba no satisfactoria y que queremos que se muestre por pantalla el resumen, a su vez existen otras tareas ligadas a phpunit que permiten obtener reportes más completos como gráficas estadísticas, niveles de covertura, etc.

Como podemos ver la integración de phpunit en phing nos proporciona una forma ágil de ejecutar tests unitarios obteniendo los reportes oportunos.

Aquí dejo el proyecto symfony con el fichero build.xml

En esta ocasión voy a optar por no escribir una frase célebre que más o menos resuma la idea que se escondía detrás de este post, como es mi costumbre, sino que voy a aprovechar para felicitaros a todos estas fiestas y desearos un feliz comienzo de año 2009.


NetBeans PHP IDE vs EclipsePDT

22/11/2008

Hace ya algún tiempo leí un post en el que Justin Carmony hacía una comparación de dos IDE´s para trabajar con tecnología PHP, Zend Studio  y Eclipse PDT. Me gustaría seguir la tarea que comenzara Justin (como se puede observar por el título del post) haciendo una comparación entre dos IDE´s de desarrollo de software libre, Eclipse PDT y la que podría ser la estrella revelación de la temporada NetBeans IDE 6.5.

Ahora bien, qué factores podríamos evaluar sobre estos dos IDE´s, Justin nos propone 6, veáse: facilidad de instalación, refactoring, PHP Unit testing, debugging, editor y Zend Platform & Zend Framework. A mí me gustaría plantear los siguientes factores: code completion, code errors y project plan, aunque también comentaré algo sobre los primeros.

Debbuging.

Esta primera característica es una de las que Justin evalua en su post. Tras haber trabajado un tiempo con PHP PDT me he podido percatar que durante la depuración la profundidad de exploración no pasaba de 3, este problema no lo tenemos en NetBeans, como podemos ver en las imágenes.

Code completion.

Con este factor se evaluará la capacidad del IDE para completar el código, facilitando de esta manera la programación. Aunque tanto PDT como Netbeans poseen esta característica, la ejecutan de forma distinta, mientras que Netbeans completa el código tanto de las funciones y métodos que hemos definido, como de las funciones existentes en el core y extensiones de PHP, PDT lo hace tan solo de los métodos y funciones que están definidos en el proyecto actual.

Code errors.

Con este factor se evaluará la capacidad del IDE no sólo para mostrar los errores que se pueden producir durante la programación, sino también la claridad y completitud de los mismos. En este factor la diferencia es más clara, como podemos observar en las siguientes imágenes.

Project plan.

Con este factor se pretende evaluar el roadmap de ambos proyectos, ya que éste nos indica las líneas de trabajo que se están siguiendo e incluso podremos solicitar qué líneas de trabajo nos gustaría que se siguieran. En la wiki del proyecto Netbeans podemos ver cuáles son las características que se van a implementar en futuras releases del IDE e incluso ¡¡¡votar por las que más nos interesen!!!, entre ellas podemos encontrar algunas muy interesantes como PHP Unit Support, Support for Symfony, PHPDocumentor integration y otras muchas. En el roadmap de PDT IDE podemos encontrar cuál será el mantenimiento evolutivo del proyecto, de las características que están planeadas implementar llama la atención, personalmente: Code Template y Code Assit for Dynamic Variables.

La construcción exitosa de toda máquina depende de la perfección de las herramientas empleadas. Charles Babbage