Integrando Android y Drupal

18/06/2011

Desde los inicios de S·dos los mercados de movilidad y gestión de contenidos ha sido dos de los tres grandes ejes del desarrollo del negocio de S·dos, prueba de esta apuesta tecnológica y económica son el desarrollo tanto de numerosas apliacaciones web, como portales de gestión de contenidos, basados principalmente en Drupal, que se han desarrollado en estos tres años de vida de S·dos.

En esta continua experiencia de mejora, trabajo e innovación que nos caracteriza, hemos llevado a cabo un amplio trabajo de integración entre aplicaciones web y aplicaciones móviles bajo los paradigmas de desarrollo actuales principalmente basados en la integración de aplicaciones móviles con sistemas externos ad-hoc con el que se comunican para diversas tareas.

Cuando nos encontramos ante la situación de llevar a cabo la implementación de esta integración contra un sistema basado en un CMS la forma de llevar a cabo la integración cambia, ya que se ha de ser capaz de ofrecer a la aplicación móvil las funcionalidades que nos demande, pero bajo el contexto y las reglas que nos marca el CMS.

Cuando hablamos de Drupal, la integración es sencilla (por supuesto si conocemos y comprendemos su arquitectura funcional) gracias a la arquitectura lógica del sistema que basa su escalabilidad funcional en la implementación de métodos gancho y su utilización en módulos de terceras partes.

Para llevar a cabo este tipo de integraciones en S·dos hemos apostado por utilizar una arquitectura basada en REST a través de peticiones HTTP/GET desde la aplicación Android al portal web Drupal, respondiendo éste en formato JSON.

Un posible ejemplo de esta arquitectura podrían ser los siguientes fragmentos de código:

Ejemplo de petición Android:

public JSONArray getResultados() {
    JSONArray jsonArray = new JSONArray();
    // Se configura la petición
    HttpClient httpClient = new DefaultHttpClient();
    HttpConnectionParams.setConnectionTimeout(httpClient.getParams(), 10000);
    // Se realiza la petición a la url necesaria
    HttpPost r = new HttpPost(Config.getUrlBase()+url_menu+idMenu);
    HttpParams params = new BasicHttpParams();
    List nameValuePairs = new ArrayList(2);
    try {
        r.setEntity(new UrlEncodedFormEntity(nameValuePairs));
    } catch (UnsupportedEncodingException e1) {
        // TODO: Tratamiento de la excepción
    }
    // Se configura la cabecera de la petición
    r.setHeader("Content-Type", "application/x-www-form-urlencoded");
    try {
        // Se realiza la petición
        HttpResponse response;
        response = httpClient.execute(r);
        HttpEntity resEntityGet = response.getEntity();
        String json = new String();
        if (resEntityGet != null) {
            // Se obtiene el JSON de respuesta
            json = EntityUtils.toString(resEntityGet);
        }
        try {
            JSONObject jsonResult = new JSONObject(json);
            jsonArray = jsonResult.getJSONArray(jsonCampo);
        } catch (JSONException e) {
            // TODO: Tratamiento de la excepción
        }
    } catch (ClientProtocolException e2) {
        // TODO: Tratamiento de la excepción
    } catch (IOException e) {
        // TODO: Tratamiento de la excepción
    }
    return jsonArray;
}

Para dar respuesta a esta petición simplemente tendremos que crear una entrada de menú en un módulo Drupal a través del hook_menu:

$items['mobile/ejemplo/%'] = array(
'title' => 'Ejemplo',
'page callback' => 'ver_ejemplo',
'page arguments' => array(2),
'access arguments' => array('access content'),
'type' => MENU_NORMAL_ITEM,
);

y la correspondiente función de que atiende la entrada de menú:

function ver_ejemplo($nid){
return drupal_json(array('ejemplo' => node_load($nid)));
exit();
}

Como podemos imaginar una vez sentados estos conceptos la arquitectura se puede extender de la forma que deseemos para dar respuesta a las necesidades de nuestros clientes, permitiendo autenticación, integración con vistas, etc.

“Dime y lo olvido, enséñame y lo recuerdo, involúcrame y lo aprendo”
— Benjamín Franklin


Rendimiento en aplicaciones PHP

22/10/2009

En esta última semana he comenzado a participar en un nuevo proyecto. Consiste en hacer una auditoría del rendimiento y la calidad del software de una aplicación implementada con tecnología PHP. El problema está en que la aplicación va degradando el servidor de aplicaciones web Apache hasta que este provoca una denegación de servicio y es preciso reiniciarlo.

Para esta auditoría se van a utilizar diversas herramientas:

1. Análisis del rendimiento de la aplicación web. En esta parte se localizarán los cuellos de botella en tiempo de ejecución y en definitiva los motivos por los cuales la aplicación consigue degradar el servidor hasta el punto de hacer que provoque la denegación de servicio antes comentada. Para ello se van a utilizar dos herramientas, The Grinder y XCacheGrind.

  • The Grinder. Me la recomendó mi compañero Antonio, y es simplemente espectacular. Es una herramienta basada software libre y su funcionamiento e instalación es muy simple, está basado en una consola central y en uno o varios agentes, cada uno de estos agentes (que son distribuidos entre distintas máquinas físicas) despliega una serie de workers y cada uno de estos workers despliega los hilos que los agentes tengan configurados. Además proporciona un proxy que nos permite realizar las pruebas UI fácilmente con cualquier navegador.
Esquema de funcionamiento de The Grinder

Esquema de funcionamiento de The Grinder

  • XCacheGrind. Esta herramienta tiene dos variantes WinCacheGrind y KCacheGrind y permiten visualizar gráficamente el consumo de tiempo que cada una de las funciones o scripts PHP ha tardado en ejecutarse y otra información que puede ser de interés para realizar las tareas de profile. Para ello hace uso de los logs que proporciona XDebug, que se tendrán que configurar con los siguientes parámetros:

xdebug.remote_autostart = On
xdebug.remote_enable=On
xdebug.profiler_output_dir = “/home/aclr/kcachegrind/”
xdebug.trace_output_dir = “/home/aclr/kcachegrind/”
xdebug.profiler_append = On
xdebug.profiler_enable = On
xdebug.auto_trace = On

Veamos un ejemplo de la información que obtenemos haciendo uso de estas herramientas:

<?php
function escribe($cad){
echo $cad.'<br/>’;
}

for($i = 0 ; $i < 100 ; $i++){
for($j = 0; $j < 100 ; $j++){
escribe(“hola”);
}
}
?>

Distribución de la ejecución

Como se puede apreciar en esta imagen solo el 9.6% del tiempo consumido en la ejecución es utilizado por la función escribe, el resto, el 99.4% del tiempo de ejecución se ejecuta en el main, es decir, en el bucle, en un caso real una situación análoga a esta nos diría que tenemos que tratar de centrar nuestros esfuerzos de optimización en el main, no en la función escribe.

En próximas entradas intentaré hablar un poco más en profundidad de The Grinder y sobre las herramientas que se utilizarán para el análisis de la calidad del código.

Aunque me gusta terminar mis posts con la cita de alguna frase célebre que trate o evoque sobre el tema del que versa el post, esta vez voy no podrá ser, son las 2:04 y me voy a la cama 😉


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


Gestión de contenidos. OpenCms 7 y Drupal 6.

13/11/2008

Después de todo este tiempo sin escribir me gustaría hablar de dos gestores de contenidos con los que he estado trabajando durante este tiempo, OpenCms 7 y Drupal 6.

Alguien me enseñó que en los proyectos de gestión de contenidos a la hora de seleccionar el CMS con el que vamos a trabajar nos interesa tener en cuenta, entre otros, tres factores: comunidad que existe tras el producto, facilidad para modificar la funcionalidad que el CMS nos proporciona y facilidad para modificar su aspecto visual para adaptarlo a la entidad corporativa del cliente, analicemos estos factores para los dos gestores de contenido que nos ocupan.

OpenCms 7 es un gestor de contenidos open source desarrollado por la empresa Alkacon Software haciendo uso de Java y XML. Para su instalación necesita un contenedor de aplicaciones como Tomcat y un SGBD como MySQL. El proceso de instalación es fácil, ya que tras su despliegue en el contendor de aplicaciones tan solo es necesario seguir un gestor de instalación que nos irá solicitando los datos necesarios para llevar a cabo la instalación del CMS. La idea de OpenCms va un poco más allá, además de proporcionar el propio gestor de contenidos, este CMS intenta proporcionar un IDE a través del cual poder realizar nuestros desarrollos.

Drupal 6 es un gestor de contenidos open source que fue originalmente desarrollado por Dries Buytaert y es usado para impulsar los sitios web Debian Planet, Spread Firefox, Kernel Trap y más. Para su instalación necesita un servidor web como Apache y un SGBD como MySQL, al igual que ocurre con OpenCms, Drupal proporciona un gestor de instalación paso a paso.

Estos dos CMS tienen en común que proporcionan un marco de trabajo con una serie de funcionalidades básicas y la capacidad de extender dichas funcionalidades básicas a través del desarrollo de nuevos módulos, funcionales, de contenido y de visualización (skins), a partir de aquí todo es distinto, veámoslo:

Comunidad

Cuando empezamos a utilizar estos dos gestores de contenidos vemos, a la luz de las búsquedas, que existe una gran diferencia entre las comunidades de OpenCms y de Drupal, podríamos fijarnos en el número de módulos que la comunidad de Drupal a aportado y el número de módulos de la comunidad de OpenCms.

Extensión funcional

La extensión funcional de estos dos CMS´s se realiza a través de la creación de módulos, ya sean funcionales o de contenido. La creación de un tipo de contenido para OpenCms es, a priori, más ventajosa que la de Drupal, pero ahí está el matiz, a priori, si lo que queremos crear es un tipo de contenido nuevo simple, por ejemplo, una noticia, con validaciones simples, comprobar si los campos están rellenos, OpenCms nos lo pone más fácil que Drupal, pero esa facilidad es un arma de doble filo cuando queremos hacer algo más complicado, por ejemplo una validación que no se pueda realizar con expresiones regulares, por ejemplo, que la fecha de alta de la noticia no sea posterior al día actual, ahí es donde Drupal le saca ventaja a OpenCms, mientras que con OpenCms tendríamos que crear una clase que X’ que heredara de la clase X y que implementa la interfaz Y, con Drupal tan solo tendríamos que tomar el valor del campo en el correspondiente hook y realizar la validación mencionada, esto para tipos de contenidos, el caso más fácil, pero si complicamos el caso, por ejemplo con la creación de un módulo funcional de administración, empezaremos a tener problemas, incluso en el propio desarrollo. Me explico, la idea de OpenCms de proporcionar un marco desde el que poder implementar, ahora mismo la considero hilarante, teniendo en cuenta el estado actual del mercado de IDE´s, suponiendo que no vamos a usar OpenCms para desarrollar nos encontramos con el problema del versionado, ¿cómo lo hacemos?. Cuando tenemos un módulo de contenidos versionamos el módulo y listo, pero cuando desarrollamos un módulo funcional, mucho de los ficheros y estructura de directorios han de ubicarse en una carpeta específica del VFS, para solventar este problema, un posible solución pasaría por replicar en el módulo los directorios VFS y mantener el fichero manifest.xml para que al importar el módulo lo mapee correctamente. Con Drupal no nos encontramos con este problema, los módulos, ya sean de contenidos o funcionales tienen una ubicación específica y desde ahí pueden trabajar, no necesitan declarar ninguna propidad y el versionado es trivial.

Apariencia

En este apartado las cosas están más o menos igual. En OpenCms 7 tenemos el Workspace desde donde podremos crear los contenidos y administrarlos con una apariencia similar a la de un sistema operativo. Para generar la interfaz del portal, podemos, de manera opcional, instalar y usar el Template Two, configurando esta plantilla podremos generar, de forma ágil, el skin de nuestro portal. En el otro lado tenemos los themes de Drupal, con ellos podemos modificar, con unos pocos golpes de ratón, completamente la apariencia de nuestro portal, sin existir una ruptura abrupta en la interfaz como ocurre con OpenCms, además estos themes, al igual que el Template Two, son totalmente transparentes con otras características como las URL´s amigables. El problema existiria si decidiéramos hacer uso de nuestras propias templates, en ese caso tendremos que programas nosotros esas características.

Horizontalmente a estos existen otros problemas, como por ejemplo la necesidad de tener un OpenCms para poder generar los instalables de los módulos a partir de los fuentes del repositorio, por suerte, siempre hay quien se preocupa de poner remedio a este tipo de eventualidades.

Nada es verdad ni es mentira; todo es según el color del cristal con que se mira. Ramón de Campoamor.


Integración continua con PHP (I)

27/09/2008

Para una empresa que tiene en el Desarrollo de Software una parte importante del núcleo de su negocio disponer de todas las herramientas necesarias para facilitar el desarrollo (IDE´s, licencias de software, entornos de preproducción, etc) de su actividad supone una ventaja respecto a sus competidores.

Hoy vamos a comenzar con el primero de una serie de posts cuyo objetivo final es conseguir configurar un sistema de integración continua para proyectos ejecutados con tecnología PHP. Un entorno de integración continua es una de esas herramientas que facilitan y mejoran todo el ciclo de vida de un producto software.

Un sistema de integración continua está compuesto por una serie de piezas que dispuestas de una cierta forma permitirán realizar integraciones automáticas frecuentes del proyecto, con todas las ventajas que ello supone. Estas piezas que necesitamos son, como mínimo:

  • Sistema de control de versiones (SVN).
  • Sistema de construcción de proyectos (Phing).
  • Servidor de integración continua (Xinc).

En este primer post solo vamos a cubrir las dos primeras partes del sistema de integración continua: sistema de control de versiones y sistema de construcción de proyectos. Para el sistema de control de versiones vamos a utilizar Subversion y como sistema de construcción de proyectos vamos a usar Phing.

Como supongo que todos conocemos lo que es un sistema de control de versiones como Subversion hablemos de Phing. Phing es un sistema de construcción de proyectos basado en Apache Ant que permite automatizar, a través de la descripción en un fichero XML, tareas como: ejecución de pruebas de unitarias, generación de documentación, comprobación de estándares de codificación, generación de “distribuibles”, etc.

Lo primero que haremos será llevar a cabo la instalación del sistema de control de versiones para ello podemos seguir los pasos de pasos de la siguiente guía.

Una vez instalado el sistema de control de versiones pasaremos a instalar Phing, (suponiendo que tenemos ya tenemos instalado PHP) para ello seguiremos los siguientes pasos:

  • apt-get install php5-dev, con este paquete podremos instalar phpize que nos facilitará la instalación de Xdebug.
  • apt-get install pear, PEAR es un sistema de distribución de componentes PHP.
  • pear channel-discover pear.phing.info
  • pear install -a phing/phing, con la opción -a haremos que se descarguen todas las dependencias de Phing.
  • pear install VersionControl_SVN-0.3.1, debemos instalar este paquete porque la configuración por defecto de Pear siempre instala la versión “estable” y para trabajar con phing necesitamos esta versión alpha.

Bien, ya tenemos instalado nuestro sistema de construcción de proyectos, ahora veamos cómo funciona. Para comenzar, una prueba simple (más adelante lo complicaremos más). Supongamos, para no ser demasiado simplista, que estamos desarrollando un proyecto con Drupal y lo tenemos versionado, un nuevo recurso se incorpora al proyecto para poder comenzar a desarrollar lo único que tendrá que hacer es instalar Phing y tras descargar el fichero build.xml

<?xml version="1.0"?>
<project name="drupal" default="dev" basedir=".">
    <target name="dev" depends="checkout"/>
    <svncheckout
       svnpath="/usr/bin/svn"
       username="usuario"
       password="contraseña"
       repositoryurl="http://localhost/svn/portal-drupal/trunk/"
       todir="/home/user/workspace/Test"/>
</project>

Tras hacer esto ya tendrá disponible el entorno de desarrollo listo para comenzar con actividad.

Aunque se presentado un ejemplo muy simple las posibilidades de Phing son, como hemos comentado antes, muy ampllias y las iremos descubriendo en sucesivos posts.

La función de un buen software es hacer que lo complejo aparente ser simple. Grady Booch


Sobre los prejuicios y PHP

04/09/2008

Con la llegada de PHP5 y su orientación a objetos (la orientación a objetos que PHP4 proporcionaba no lo convertía en una opción competitiva aún) con sus modificadores de visibilidad, manejo de excepciones orientada a objetos y demás características ha vuelto a cobrar fuerza una opción que revoloteaba en la cabeza de muchos ingenieros software a la hora de seleccionar un marco tecnológico con el que modelar la solución software que le proporcionarán a sus clientes, está claro, a la luz de los hechos, que dicha opción no existe o no tiene el mismo peso en todas cabezas.

En el día a día , tanto profesional como personal, se toman muchas decisiones, de mayor o menor envergadura, en base a una serie de criterios y motivos. Muchos de estos criterios y motivos son estudiados minuciosamente para conseguir maximizar los beneficios obtenidos de tales decisiones, pero por desgracia hay otras decisiones, fundamentales para una empresa que tiene en la Ingeniería del Software una de sus áreas de negocio, como son los marcos tecnológicos con los que trabajar, que se toman en base a prejuicios e ideas infundadas. PHP es uno de esos marcos tecnológicos que cuenta con un número mayor de ellas:

  • PHP no es seguro.
  • No es escalable.
  • Java tiene frameworks que facilitan el desarrollo de aplicaciones.
  • Java es más fácil.
  • Java lo usan más empresas.

Como vemos existen muchos prejuicios (recalcando la palabra prejuicio) alrededor de los marcos tecnológicos basados en PHP, muchos de ellos totalmente falsos y otros muchos demasiado poco matizados como para poder tomarlos en consideración. Porque las facilidades que PHP o cualquiera de sus frameworks (Symfony, Cake, etc) o productos (Magento, OSCommerce, Drupal, Phing, Xinc, etc) proporcionen para gestionar la seguridad y la escalabilidad, la capacidad de un técnico para asimilar nuevos conceptos, etc no quedan exclusivamente determinados por el marco tecnológico, al igual que las herramientas utilizadas para desarrollar un producto no determinan totalmente la calidad de éste, sino que nos proporcionan esa serie de criterios, comentados al principio, que debemos evaluar para conseguir seleccionar el marco tecnológico que mejor se ajuste a nuestras necesidades y las de nuestros clientes.

No se trata de hacer una defensa desaforada de los marcos tecnológicos basados en PHP o cualquier otra tecnología, sino de hacer una defensa de la toma de decisiones razonada y basada en criterios y motivos sólidos y fundamentados.

No existen soluciones, solo caminos que merece la pena tomar. Proverbio chino.