Modelos experimentales de persistencia para aplicaciones web (II): Object Freezer-Relational

En el anterior post vimos un invento de Sebastian Bergmann llamado Object Freezer, que consiste en almacenar objetos PHP en CouchDB de forma automática. Es un buen método para no tener que definir esquemas de bases de datos, escribir sentencias SQL, hacer mapeo objeto-relacional… en definitiva, es una solución que nos puede ahorrar un montón de trabajo.

Pero, una vez aceptadas las ventajas de la congelación, quizá sea necesario guardar esos objetos en una base de datos diferente a CouchDB. Por ejemplo, en MySQL. Y de esto trata el presente artículo: de congelar objetos y guardarlos en MySQL.

Un brevísimo repaso a la congelación

Congelar un objeto (“freeze”) es convertirlo en un array manteniendo los objetos hijos y evitando duplicidad de los mismos. La operación inversa, la descongelación (“thaw”), sería recoger ese array y convertirlo de nuevo en el objeto original.

¿Por qué MySQL, si con NoSQL nos ahorramos todo el trabajo?

  1. A veces no es viable o rentable cambiar de servidor de bases de datos, por la inversión económica y de formación que requieren los sistemas tradicionales.
  2. Interoperabilidad: si en el futuro queremos migrar la aplicación, quizá poder manipular la información con SQL facilite la tarea.
  3. Rendimiento: las bases de datos relacionales se basan en algoritmos muy evolucionados y rápidos, y sistemas como MySQL-MyISAM han demostrado un rendimiento muy alto.

Entonces… ¿Se trata de guardar arrays en MySQL?

Exacto. Eso es lo que hace Object Freezer-Relational, una extensión de Object Freezer escrita por un servidor :-)

Lo primero que debemos pensar a la hora de guardar objetos en MySQL es: ¿cuál es el esquema de tablas? Porque si con CouchDB éramos NoSQL y guardábamos la información en arrays JSON, ahora tenemos que ceñirnos al álgebra relacional, las tablas, los índices y las claves primarias.

Así que este es el esquema que podemos usar:

  • Tabla objects
    • id: el ID único del objeto.
    • className: indica la clase de la cual es instancia el objeto almacenado.
    • isDirty y isRoot: dos atributos que utiliza Object Freezer internamente.
  • Tabla properties
    • name: nombre del atributo.
    • value: contiene el valor del atributo o bien un ID si el atributo hace referencia a otro objeto.
    • type: tipo de dato (int, float, string, boolean, array, objeto…).
    • object_id: ID del objeto al que pertenece el atributo. Hace referencia a objects.id.

Llegados a este punto uno podría pensar: “hey, te estás cargando el modelo relacional”. Efectivamente. Si queremos guardar objetos sin definir su esquema de BD, no nos queda más remedio que soluciones experimentales como la que te presento hoy. Sí, es una “des-normalización”, pero gracias a ella te ahorras escribir SQL.

Object Freezer-Relational se encarga de gestionar este esquema. De hecho, no es siquiera necesario crearlo, ya que lo hace automáticamente.

Vale, ya veo que mola. ¿cómo se usa?

Usar Object Freezer-Relational es tan sencillo como usar Object Freezer indicando los datos de acceso a MySQL:

$storage = new Object_Freezer_RelationalStorage(
    new Object_Freezer,
    NULL,
    FALSE,
    new MysqlStorage(
        "localhost",                    //Servidor MySQL
        "freezer",                      //Usuario
        "passw0rd",                     //Contraseña
        "freezer",                      //Base de datos
        3306,                           //Puerto
        MysqlStorage::ENGINE_INNODB));  //Motor MySQL

A partir de ahí, podemos usar el objeto $storage de la misma forma que el Object Freezer original, con CouchDB, ya que es la misma API.

Object Freezer-Relational está disponible en SourceForge. Puedes descargarlo y probarlo, echar un vistazo al código o leer la documentación si te interesa. Y por supuesto, comentar qué te parece la idea de guardar objetos en una base de datos MySQL :-)

Mejor rendimiento de Drupal con GraphicsMagick

Un pequeño (y espero útil) apunte antes de que penséis que he abandonado completamente el blog :-(

Se trata de un consejo para mejorar el rendimiento de nuestro sitio Drupal. El sistema utiliza por defecto la biblioteca GD para manipular imágenes (por ejemplo, generar miniaturas). El módulo ImageAPI inserta una capa de abstracción en Drupal que permite elegir qué biblioteca gráfica usar, GD o ImageMagick. Es mejor utilizar ImageMagick, ya que es una biblioteca independiente de PHP y, por ello obtendremos mejor rendimiento total en Drupal, y además es más estable (si falla GD puede caer todo el motor de PHP, sin embargo, si falla ImageMagick no caerá, ya que es un binario diferente).

Pero aún mejor: existe un proyecto llamado GraphicsMagick, que es un fork de ImageMagick y que es más estable y, sobre todo, con mejor rendimiento, ya que consume menos memoria y es más rápida. Y lo que es mejor, tiene la misma API que ImageMagick (el comando convert), con lo cual podemos engañar a ImageAPI diciéndole que use ImageMagick cuando en realidad tenemos instalado GraphicsMagick.

Para lograr esto no tienes más que instalar GraphicsMagick y el módulo ImageAPI de Drupal, en dos sencillos pasos. Supongamos que trabajamos con un servidor Debian/Ubuntu (en otros sistemas operativos no debería ser muy diferente):

  1. Instalamos GraphicsMagick:
    apt-get install graphicsmagick-imagemagick-compat

    Podemos probar que GraphicsMagick funciona escribiendo convert en la consola:

    isra@salon:~$ convert
    GraphicsMagick 1.3.5 2009-01-26 Q8 http://www.GraphicsMagick.org/
    Copyright (C) 2002-2009 GraphicsMagick Group.
    Additional copyrights and licenses apply to this software.
    See http://www.GraphicsMagick.org/www/Copyright.html for details.

    Usage: convert [options ...] file [ [options ...] file ...] [options ...] file

    [más opciones]

  2. Instalamos el módulo ImageAPI y lo activamos en /admin/build/modules (módulos ImageAPI e ImageAPI ImageMagick).
  3. Accedemos a la configuración de ImageAPI en Administración > Configuración del sitio > ImageAPI (/admin/settings/imageapi) y veremos el siguiente mensaje: “The ImageAPI ImageMagick module is the only enabled image toolkit. Drupal will use it for resizing, cropping and other image manipulations“.
  4. Si también hemos activado el módulo ImageAPI GD2, nos dará a elegir (seleccionamos ImageAPI ImageMagick como opción por defecto):

    ImageAPI

¡Y listo! Fácil y rápido. Podemos comprobar que funciona accediendo a Administración > Configuración del sitio > ImageAPI > Configurar (/admin/settings/imageapi/config), lo que nos mostrará información sobre GraphicsMagick (versión, tipos soportados, etc):

ImageAPI GraphicsMagick

¿He hecho benchmarks para comprobar la ganancia de rendimiento con respecto a ImageMagick?

Pues no, lo siento. Pero los chicos de GraphicsMagick sí los han hecho, y son bastante jugosos.

Pero… ¿no es necesaria la extension imagick de PHP?

No, no es necesaria, ya que ImageAPI interactúa con ImageMagick/GraphicsMagick a través del binario convert.

Iré escribiendo algunos artículos más sobre técnicas fáciles para optimizar el rendimiento de Drupal.

Primeras experiencias con WordPress… y muchas nueces ;-)

Web de Nueces San Ignacio
Todo desarrollador web debe saber trabajar con uno o varios sistemas de gestión de contenidos (CMS). Estos programas nos ahorran reinventar la rueda cada vez que tenemos que publicar contenidos en la web, gestionar usuarios y la administración del sitio, organizar nuestro código de acuerdo a un estándar, etc, etc, etc.

Personalmente siempre he sido aficionado a los CMS, pero a nivel de usuario. Me encanta conocer y probar los gestores de contenido, aunque hasta hace poco no había desarrollado proyectos —proyectos de verdad— con una de estas herramientas, por vagancia para afrontar la curva de aprendizaje y por afán de reinventar la rueda (puede ser divertido y muy pedagógico, pero no es práctico si queremos buenos resultados).

El caso es que hace un par de meses comencé un proyecto web para un amigo que cultiva nueces y me animé a probar WordPress, animado por la experiencia de los chicos de Atracciona, que utilizan este gestor de blogs para hacer webs corporativas. Mi proyecto era dar presencia web a la Nueces San Ignacio y captar clientes a través de Internet, por lo que a nivel técnico las exigencias eran mínimas (unas cuantas secciones de texto rico, fotos, un formulario de contacto y poco más).

La experiencia con WordPress ha sido impresionante. A pesar de que no me gustan sus tripas (algunos fragmentos de código son verdadero spaghetti code), diseñar un theme con WordPress es increíblemente fácil y rápido. Una vez tuve el diseño en HTML/CSS, pasarlo a WordPress fue cosa de una noche. No toma más esfuerzo que copiar un tema (por ejemplo, Kubrick) e ir modificando las plantillas, adaptando el CSS y cambiando el marcado que sea necesario.

El resultado, una web corporativa con un panel de administración muy potente, la disponibilidad de miles de plug-ins y el respaldo de un software probado en millones de servidores.

Logo de Nueces San IgnacioMás allá de la programación, también diseñé la web, el logotipo —y las tarjetas de visita, y un dossier comercial, todo ello con software libre e imágenes libres— y todo lo relativo a márketing en redes sociales, SEO y SEM. Y aunque el mercado en el que se mueve la empresa no depende en gran medida de Internet (el objetivo es vender toneladas de nueces, y el público objetivo hoy en día son distribuidores y grandes superficies), poco a poco la estrategia web va dando fruto. La experiencia ha sido gratificante, porque no es lo mismo hacer un proyecto para un cliente (con la exigencia de calidad y la concentración de sólo programar) que para un amigo (he tenido total libertad para diseñar, desplegar, redactar, etc). Te lo tomas con más calma, le dedicas las horas que puedas y el resultado acaba siendo muy satisfactorio, porque de un modo u otro me he involucrado en la empresa.

Conclusión, WordPress es un muy buen gestor de blogs que también puede ser usado como gestor de contenidos genérico para sitios web pequeños, con una rapidez en la creación de themes que nunca antes se había visto. No obstante, cuando tenga tiempo he de revisar otros CMS para sitios web corporativos. Hace algún tiempo probé CMS Made Simple, pero no me convenció. Sin embargo, MODx promete bastante.

Cuestiones todas a resolver en 2010. Feliz Navidad y que el año que se avecina sea el mejor de tu vida :-)

5 razones para no usar Smarty (o similares)

En la mayoría de los casos, Smarty no es la solución idónea para separar la lógica de las vistas, aunque hay que admitir que la versión 3 está siendo un salto de calidad impresionante. No obstante, estas son las cinco principales razones que he encontrado para no incluirlo más en mis proyectos:

  1. PHP es un lenguaje con sintaxis embebida, es decir, es de por sí un sistema de plantillas. Para mayor claridad puedes utilizar la tag de apertura corta (<? en lugar de <?php) y el operador de impresión (<?=$nombre ?> en lugar de <?php echo $nombre ?>). Además, Smarty no añade funcionalidad.
  2. Con Smarty debes aprender una nueva sintaxis para imprimir variables, hacer bucles, etc.
  3. En aplicaciones complejas tendrás que crear un montón de plug-ins para cargar widgets u otros fragmentos de código para las vistas que quieras reutilizar. O bien utilizar cada dos por tres la tag {php}.
  4. Smarty es difícil de integrar en gestores de contenido, frameworks y editores de código.
  5. Smarty reduce el rendimiento de tus aplicaciones web ya que debe parsear y convertir a PHP las plantillas. Incluso con caché el rendimiento se ve afectado (más accesos a disco).

Ya habíamos hablado de este tema en Plantillas PHP: cuestión de rendimiento, proponiendo el funcionamiento básico de un motor de plantillas basado en PHP puro.

ACTUALIZACIÓN (23 de noviembre):

Algunos expertos han escrito artículos en profundidad sobre este tema, por ejemplo “Template Engines” de Brian Lozer o la entrada de “PHP and Templates” de phpPatterns.

Con respecto a las alternativas, Savant y PHPTemplate (creado para Drupal) son buenas opciones. Además, los principales frameworks (CakePHP, etc) y gestores de contenido (Joomla!, WordPress) suelen incluir sus propios motores de plantillas en PHP.

“In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code.”

Los CMS más populares

El ritmo de publicación del blog está algo bajo últimamente, y seguirá así en las próximas semanas ya que estoy bastante ocupado con diversos proyectos, alguno de los cuales contaremos en detalle ;-)

Descargas semanales de WordPress, Joomla, Drupal, eZ Publish y Alfresco

No obstante, me gustaría comentar el informe de CMS Wire sobre los gestores de contenido más en boga en este año 2009, que el creador de Drupal ha comentado con gran acierto. Las encuestas arrojan unos resultados esperables pero muy interesantes.

En primer lugar, la ya tradicional hegemonía de PHP como tecnología más popular para gestión de contenidos. Me sorprende que, en la era de los frameworks no tengan tanta fuerza otras tecnologías como Python con Zope o Django (a excepción de Plone), aunque quitarle el puesto al “trío de ases” es tarea difícil, por el recorrido y la comunidad que tienen.

En segundo lugar, es muy importante notar que el estudio no es un ránking de los mejores CMS, sino de aquellos más populares, con los que más familiarizados están los encuestados. Que WordPress y Joomla sean los más populares no significa que sean los mejores. Tienen grandes bazas como el apoyo de la comunidad, mucha documentación, gran cantidad de plug-in y muy buena aceptación en entornos empresariales.

Pero no nos equivoquemos. WordPress juega en una liga distinta a Plone y Drupal. WordPress es un gestor de blogs, fácilmente personalizable y puede ser utilizado y administrado por gente con muy pocos conocimientos. Sin embargo, no debe ser empleado como gestor de portales o grandes sitios. Tampoco como sistema ECM ni Intranet. Además, las “tripas” de WordPress tienen mucho código spaghetti. No obstante, mi experiencia personal (lo estoy utilizando para dos proyectos, una revista on-line y una web corporativa) es muy positiva, ya que en muy poco tiempo pude montar un pequeño sitio web y estoy bastante satisfecho, especialmente con la API para crear themes.

Un último apunte sobre WordPress: la métrica de popularidad de WordPress está ligeramente inflada ya que muchos de los encuestados confundieron el gestor de contenidos WordPress con el servicio de alojamiento gratuito WordPress.com.

Por su parte, Joomla es un portal bastante ampliable (hay plug-ins para hacer CRM y cosas así), además es fácil de usar para editores y administradores. Pero en mi opinión, no puede crecer a sitios realmente grandes.

Valoración general de los CMS

En otro nivel están Drupal y Plone. Ambos presentan no sólo una solución de gestión de contenidos, sino un framework para desarrollar sistemas de este tipo (Drupal en sí mismo y CMF, que originalmente no forma parte del proyecto Plone), con lo cual la capacidad para ampliar estos CMS es mucho más grande, sobre todo en Plone por estar construido sobre Zope.

En tercer lugar, la gente está entendiendo que el concepto de CMS es demasiado genérico. No se puede comparar Alfresco, que es un ECM, con un gestor de tareas colaborativo o una red social. Todos ellos son gestores de contenido pero es necesario no confundir peras con manzanas. A las PYMES les suelen interesar los gestores de publicación de contenidos, tales como portales, prensa, blogs… soluciones sencillas que permitan crear rápidamente sitios con un diseño propio y contenidos adecuados. Y a organizaciones más grandes, sistemas que puedan crecer hacia la gestión documental (ECM), intranets/portales del empleado o aplicaciones empresariales más grandes.

Otras conclusiones interesantes:

  • En la valoración general, Joomla! desciende por debajo Alfresco y Silverstripe. También sale mal parado Plone, en noveno puesto con sólo un 30% de votos positivos. El otro 70% son los que no fueron suficientemente hombres para plantarle cara a Zope ;-)
  • Drupal es el que más ha crecido en cuanto a profesionales del desarrollo, y WordPress en cuanto a márketing/redaccción. Además, hay casi el triple de libros sobre Drupal (25) que sobre WordPress (9). Sobre Plone, hay 7 libros publicados.
  • En general, en Internet se habla mucho más de Joomla que de Drupal. Este dato se invierte en los medios sociales, sobre todo en Twitter.
  • Este año, en los blogs (Technorati) se habló de Plone un 55% menos que el año pasado. No obstante, Plone es el cuarto CMS en cuanto a repercusión en la web social.
  • Drupal tiene tantos premios como WordPress y Joomla juntos.

Una última cosa… me alegro de que hayan eliminado del top 20 a PHP-Nuke, que lleva bastante tiempo sin publicar una nueva versión. Antaño fue un sistema omnipresente —diría incluso que marcó una generación— pero malísimo en cuanto a seguridad, diseño, calidad del código, etc. Hoy en día la gestión de contenidos es diferente… gracias a Dios.