Blog de Israel Viana

Artículos sobre software libre

Mejor rendimiento de Drupal con GraphicsMagick

14 de mayo de 2010 | 0 comentarios

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):

¡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):

¿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 ;-)

26 de diciembre de 2009 | 2 comentarios

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)

21 de noviembre de 2009 | 9 comentarios

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

18 de noviembre de 2009 | 0 comentarios

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 Framework 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.


Aún más rendimiento con CssDispatcher

25 de octubre de 2009 | 0 comentarios
CssDispatcher

En el artículo "Maneja las CSS como un profesional" veíamos algunas técnicas para insertar variables y funciones en las hojas de estilo, así como posibles mejoras del rendimiento en el cliente a la hora de servir las CSS, y para ello utilizábamos la biblioteca CssDispatcher.

Pues bien, en este post vamos a ver varias soluciones para aumentar el rendimiento en el servidor cuando servimos hojas de estilos, especialmente si son hojas de estilos tratadas con CssDispatcher.

Es importante diferenciar las mejoras de rendimiento en el cliente y el servidor. Mientras los benchmarks nos dicen que el 80% del tiempo de carga de una página lo causa el cliente (transferencias, renderizado, etc), para nosotros también es importante ese otro 20%, porque genera una carga en el servidor (acceso a disco duro, procesador, memoria...) que puede ponernos en aprietos si las visitas aumentan.

Accesos al disco duro

De por sí, servir una hoja de estilos simple no suele ser muy costoso para un servidor web. Si un cliente solicita /main.css, el servidor abre el archivo, lo lee y lo devuelve. Además, si el sistema operativo implementa caché de ficheros, 1000 visitas no generarán 1000 accesos al disco duro, lo cual aumentará la velocidad y reducirá la carga del servidor.

Si queremos ir más allá y acelerar aún más los accesos a disco duro podemos poner los archivos del servidor un sistema de archivos montado sobre la memoria RAM. Es decir, una porción del sistema de archivos que, en lugar de guardarse en el disco duro, lo hace sobre una porción de la memoria RAM. No es una técnica muy recomendable, porque aunque no es difícil montarlo, los datos desaparecen al apagar o reiniciar la máquina, por lo que habría que tener sincronizados los directorios en memoria con otros en el disco duro para que no se perdiesen.

Procesamiento de la petición

Como ya he dicho antes y todo el mundo sabe, para el servidor web devolver un archivo estático no le cuesta más que abrirlo e irlo enviando por el socket. Pero si la hoja de estilos pasa por el compilador de PHP (por introducir códigos PHP en la hoja de estilos) entonces la cosa se complica un poco. Para acelerar el procesado de scripts es recomendable usar:

  • Una caché de salida, que evita tener que ejecutar repetitivamente el mismo código para cada petición.
  • Un opcode cache, que evita tener que compilar el código para cada petición (si hemos implementado caché de salida, para la mayoría de las peticiones no será necesario ni compilar ni ejecutar el código).
Diagramas de flujo para el despacho de peticiones con caché

Para la opcode cache existen herramientas como APC, XCache o eAccelerator, que una vez instaladas y configuradas debidamente funcionan sin que tengamos que modificar el código de nuestra aplicación web. Puedes leer más sobre opcode cache en PHP Accelerators.

En cuanto a la caché de salida, hay principalmente dos caminos a seguir: gestionar la caché desde el servidor web o desde PHP. La ventaja del primero es que, al no ejecutar código PHP es un poco más rápido. Esto se puede lograr con el módulo Apache mod_cache. La otra posibilidad, gestionarlo con PHP, nos da más flexibilidad y control sobre la solución. En concreto, podremos guardar la caché en el disco duro o en memoria, con gestores de caché como Memcached (mi preferido).

Caché con URL propia

Existe una tercera solución, y es utilizar una caché en disco duro sin procesar las peticiones por PHP. El funcionamiento es el siguiente: si tenemos una hoja de estilos generada con CssDispatcher en /estilos.css.php, podemos guardar la salida en un archivo y ponerlo accesible en /estilos.css. Al ser un archivo estático, se servirá tan rápido como una hoja de estilos normal. Este sistema tiene un problema, y es que si tenemos hojas de estilos específicas para navegadores, no resultará fácil servir una u otra de forma estática. La única solución aparente es utilizar redirecciones y estructuras condicionales en los ficheros de configuración de Apache.

Algo de código, por favor

Vamos a implementar tres sistemas de caché: uno con Memcached, otro en disco y otro en disco accesible directamente.

Cache en Memcache

<?php

include 'class.Css.php';

//Nombre del elemento en Memcache
$cache_name = 'moduleName_' . Css::getUserAgent();
//Tiempo de vida. Para archivos que no cambien mucho, poner valores altos
$cache_time = 3600*24; 

//Conexión a Memcache
$mc = new Memcache();
$mc->connect('localhost');

//Si la salida no está en caché, se genera y se almacena
if (!$out = $mc->get($cache_name)) {

    //Incluye la biblioteca CssDispatcher.
    //No se incluye si no es necesaria
    include 'class.CssDispatcher.php';

    $estilos = new CssDispatcher;

    //Crea una nueva hoja de estilos
    $general = new Css('example.css.php');
    //Asigna variables
    $general->background = '#eee';
    $general->border_color = 'red';
    $general->header_size = 2.1;

    //Crea otra hoja de estilos para navegadores WebKit
    $another = new Css('example2.css.php', Css::UA_WEBKIT);
    $another->bold = 'font-weight: bold';

    //Añade las hojas de estilo al dispatcher
    $estilos->add($general);
    $estilos->add($another);

    //Añade un aviso
    $out = '/* Generated by CssDispatcher ' . strftime('%c') . " */\n"
        . $estilos->render(false, true, false, true);

    //Guarda la salida en Memcache
    $mc->set($cache_name, $out, null, $cache_time);
}

header("Content-Type: text/css");
echo $out;
die();

?>

Tiempo de ejecución (renovando la caché): 3.6480ms
Tiempo de ejecución (utilizando la caché): 0.6439ms

Caché en disco duro

Este script tendrá será más lento y pesado para la CPU que el anterior, pero no necesita de servicios adicionales como Memcached, imposibles de instalar en alojamientos compartidos.

<?php

include 'class.Css.php';

//Archivo de caché
$cache_name = 'cssCache/moduleName_' . Css::getUserAgent();
//Tiempo de vida, poner valores altos para archivos que no suelen cambiar
$cache_time = 30; 

if (file_exists($cache_name)) {
    if (date('U') - fileatime($cache_name) > $cache_time) {
        $regenerate = true;
    } else {
        $out = file_get_contents($cache_name);
    }
} else {
    $regenerate = true;
}

//Si la salida no está en caché, se regenera
if ($regenerate) {

    //Carga la biblioteca CssDispatcher
    include 'class.CssDispatcher.php';

    $estilos = new CssDispatcher;

    //Crea una nueva hoja de estilos
    $general = new Css('example.css.php');
    //Asigna variables
    $general->background = '#eee';
    $general->border_color = 'red';
    $general->header_size = 2.1;

    //Añade otra hoja de estilos para navegadores WebKit
    $another = new Css('example2.css.php', Css::UA_WEBKIT);
    $another->bold = 'font-weight: bold';

    //Añade las plantillas al dispatcher
    $estilos->add($general);
    $estilos->add($another);

    $out = '/* Generated by CssDispatcher ' . strftime('%c') . " */\n"
        . $estilos->render(false, true, false, true);

    //Graba la salida en el fichero
    file_put_contents($cache_name, $out);
}

header("Content-Type: text/css");
echo $out;
die();

?>

Tiempo de ejecución (renovando caché): 1.290ms
Tiempo de ejecución (utilizando caché): 0.242ms

El último caso, una caché en ficheros accesibles públicamente, es más rápida y más ligera que la anterior, pero nos añade la tarea de actualizar la caché cuando nos interese, bien con una tarea programada (cron) o mediante algún otro mecanismo.

<?php

include 'class.Css.php';
include 'class.CssDispatcher.php';

//Generamos hojas de estilos para todos los navegadores
$navegadores = array(Css::UA_IE6, Css::UA_IE, Css::UA_GECKO, Css::UA_WEBKIT);

//Para cada navegador generamos la hoja de estilos correspondiente
foreach ($navegadores as $navegador) {
    //Archivo de caché
    $cache_name = 'cssCache/estilos_' . $navegador . '.css';
    //Tiempo de vida. Para archivos que no cambien mucho, poner valores altos
    $cache_time = 30; 

    $estilos = new CssDispatcher;

    //Crea una nueva hoja de estilos
    $general = new Css('example.css.php');
    //Asigna variables
    $general->background = '#eee';
    $general->border_color = 'red';
    $general->header_size = 2.1;

    //Añade las plantilla al dispatcher
    $estilos->add($general);

    //Hoja de estilos para WebKit
    //No vale utilizar la detección de navegador de CssDispatcher
    if ($navegador == Css::UA_WEBKIT) {
        $another = new Css('example2.css.php');
        $another->bold = 'font-weight: bold';
        $estilos->add($another);
    }

    $out = '/* Generated by CssDispatcher ' . strftime('%c') . " */\n"
        . $estilos->render(false, true, false, true);

    //Graba la salida en el fichero
    file_put_contents($cache_name, $out);
}

echo "Caché de CSS actualizada";

?>

Tiempo de ejecución del actualizador de caché: 4.009ms
Tiempo de obtención de la hoja de estilos: 86ms (incluye la transmisión del fichero)

Ya que con este método no tenemos un sólo punto de entrada para las diferentes hojas de estilos, será necesario cargar una u otra CSS en función del navegador, a través de los artificios clásicos: comentarios condicionales o la cabecera User-Agent. Pero tendremos que hacerlo manualmente, ya que al usar ficheros estáticos no se ejecuta CssDispatcher. Por ejemplo, según el ejemplo, si el navegador es Firefox tendremos que invocar cssCache/estilos_20.css.

Por mi parte, es todo por hoy. ¿Conoces alguna otra técnica para aumentar el rendimiento al servir CSS? ¿Has probado a cachear la salida de CssDispatcher?


Linux es un buen entorno de programación en PHP

25 de septiembre de 2009 | 5 comentarios

Siempre he apostado por el software libre, pero hasta hace no mucho usaba Windows, un sistema privativo, para desarrollar. No me convencían las herramientas de programación en PHP para Linux, ya que estaba muy contento con Notepad++ para escribir scripts y TortoiseSVN para trabajar con Subversion. Usaba un servidor WAMP y phpMyAdmin para administrar la base de datos.

Ahora, sobre Debian, trabajo con unas herramientas que no tienen nada que envidiar a las anteriores. Vayamos por partes.

Un editor de PHP para Linux

Si algo me faltaba en Notepad++ era un autocompletado de código potente (el de Notepad++ se basa solamente en las palabras del archivo actual) y la autodocumentación en línea (es decir, soporte de phpDoc). Tras darle una oportunidad a Eclipse/PDT, me he decidido definitivamente por NetBeans. Tiene integración con Subversion, phpDoc, XDebug y Firefox, y me parece más productivo que Eclipse. Una de las características que más me gusta es que tiene en cuenta la cláusula @return de los comentarios phpDoc de una función para entender el tipo de dato que devuelve:

NetBeans, mi IDE favorito para PHP

No obstante, no he dejado de usar Notepad++, gracias a WINE. Lo utilizo para manejar archivos de diferentes codificaciones, procesar textos con expresiones regulares y escribir PHP cuando no me apetece iniciar NetBeans ;-)

Un cliente Subversion para Linux

Como ya he dicho, NetBeans tiene soporte nativo de Subversion. En otros casos, utilizo kdesvn y RapidSVN. Además, he aprendido el valioso placer del cliente svn por línea de comandos ;-) Por cierto, existe un cliente privativo aunque muy potente llamado SyncroSVN, disponible para Windows, Mac y Linux.

Un depurador de PHP para Linux

De nuevo NetBeans me soluciona la papeleta, pero también utilizo KCacheGrind, un excelente visor de volcados XDebug:

KCacheGrind visualiza los informes de XDebug de múltiples formas

Cross-browser en Linux

Si algo abunda en GNU/Linux son los navegadores. Los de siempre, Firefox (con el maravilloso Firebug), Opera, Chrome y lynx (o links o elinks), además de Konqueror (que nadie usa). Para el malvado Internet Explorer utilizo una máquina virtual con Windows XP en la que dispongo de muchas versiones de IE, gracias a Internet Explorer Collection. Además, existen renderizadores de Internet Explorer on-line.

Internet Explorer 1

Instalar extensiones es más fácil en Linux

Los paquetes Apache+PHP para Windows suelen traer algunas extensiones, pero a la hora de instalar otras nuevas (tanto PECL como PEAR) los métodos varían, y las utilidades de línea de comandos no siempre funcionan.

En Linux muchas extensiones PECL y bibliotecas PEAR están disponibles a través de los repositorios.

Extensiones PHP a través del repositorio

Además, el paquete de desarrollo php5-dev permite instalar compilando las extensiones de la forma más sencilla:

# pecl install nombre_de_la_extension

Y lo mismo para librerías PEAR:

# pear install nombre_de_la_biblioteca

Conclusión

Si aún trabajas con Windows, anímate a probar GNU/Linux con Ubuntu o la distribución que más te guste. En una hora habrás podido instalar todas las aplicaciones que necesitas para programar de forma productiva y cómoda con PHP. Si ya lo has hecho, ¿qué experiencia tienes? ¿utilizas alguna de las herramientas que he citado? Comentar es gratis ;-)


Maneja las CSS como un profesional

14 de septiembre de 2009 | 13 comentarios

Una parte importante de cualquier aplicación o sitio web son los estilos CSS. Las hojas de estilos se suelen escribir aisladas de la aplicación, sus tecnologías y metodologías. Además, suelen ser servidos como archivos estáticos, de forma que no pasan por la base de datos ni el resto de la aplicación. Existen buenas prácticas relacionadas con la legibilidad y mantenibilidad de las hojas de estilos, pero pocas veces se opta por mezclar las CSS con las aplicaciones, entre otras cosas porque servirlos como ficheros estáticos es más rápido que procesarlos con PHP, y porque a menudo los diseñadores que escriben los estilos no conocen las tecnologías de programación.

No obstante, como se explica en "Supercharge Your CSS with PHP Under the Hood" y demuestran algunas aplicaciones como Plone o phpMyAdmin, mezclar las tecnologías de programación con el lenguaje de estilos CSS puede aportarnos más potencia y comodidad a la hora de escribir, mantener y aumentar el rendimiento de las stylesheets. Y por el mismo precio también te presentaré CssDispatcher, una biblioteca que te ayudará a hacer todo eso casi sin esfuerzo.

Variables y funciones en CSS

En programación, si vas a utilizar varias veces un dato, lo almacenas en una variable para manejarlo más cómodamente. El mismo principio podemos aplicar, por ejemplo, con los colores en una hoja de estilos. De este modo evitamos repetir (es decir, recordar o copiar-pegar) códigos hexadecimales. Por ejemplo, el siguiente estilo:

.paginacion { border: 1px solid red; }
.paginacion a { color: red; }

...quedaría de este modo:

.paginacion { border: 1px solid <?=$rojo ?>; }
.paginacion a { color: <?=$rojo ?>; }

Como ves, he utilizado las etiquetas cortas y el operador de impresión <?= en lugar de echo para abreviar. Establecer variables para colores facilita la tarea de crear esquemas de colores intercambiables (y más legibles):

body { color: <?=$color_texto ?>; }
a { color: <?=$color_enlace ?>; }
h1 { color: <?=$color_primario ?>; }

#divCentral { border: 1px solid <?=$color_primario ?>; }

Como ya he comentado, phpMyAdmin hace uso de esta técnica. Aquí tenemos un pequeño ejemplo:

th {
    font-weight:        bold;
    color:              <? echo $GLOBALS['cfg']['ThColor']; ?>;
    background:         <? echo $GLOBALS['cfg']['ThBackground']; ?>;
}

En este caso no se usa el operador = para imprimir, y sí echo. Es recomendable hacer lo mismo ya que en muchos servidores (sobre todo con las versiones más recientes de PHP) las etiquetas cortas están desactivadas.

Además de colores, puedes utilizar las variables para calcular medidas relativas. Por ejemplo, si tenemos un layout de 800px de ancho con dos columnas, una de 600px y otra de 200, podemos expresarlo con medidas relativas (%) para hacer más accesible nuestras hojas de estilo:

#columna1 { width: <?php echo ($ancho_columna1/800)*100 ?>%; }
#columna2 { width: <?php echo ($ancho_columna2/800)*100 ?>%; }

También podemos utilizar propiedades completas como variables:

h1 { <?php echo $negrita ?>; }

Donde $negrita valdría font-weight: bold.

Llegados a este punto, seguramente estés pensando "muy bonito, pero ¿dónde defino las variables?". En el tutorial de NetTuts los ejemplos muestran las declaraciones de variables en el mismo fichero que las CSS, pero no creo que sea una buena práctica. phpMyAdmin tiene ficheros separados donde se definen los valores, aunque utilizar el array $_GLOBALS no es muy elegante, sobre todo si tu aplicación es orientada a objetos.

Como ya adelanté al comienzo, vamos a ver una biblioteca llamada CssDispatcher que facilita la gestión de CSS con PHP. Esta librería propone un método concreto de definir las variables de los estilos, de forma que se identifiquen fácilmente y además los nombres no causen conflictos con el resto de variables de la aplicación. Este método es sencillamente añadir las variables a una instancia de la clase Css a través del tipado dinámico:

$general = new Css('general.css.php');
$general->fondo = '#eee';
$general->color_borde = 'red';
$general->cabecera = 2.1;

Aunque las variables son introducidas en el objeto, al usarlas en la plantilla CSS sólamente tenemos que especificar su nombre, como variables "tradicionales":

body { background: <?php echo $fondo ?>; }

De este modo podemos asignar variables a cuantas hojas de estilos queramos, sin que interfieran los nombres:

$general = new Css('general.css.php');
$general->altura_cabecera = '5em';

$ie_hacks = new Css('ie_hacks.css.php');
$ie_hacks->altura_cabecera = '5.1em';

Ah, por cierto, las variables también pueden ser de tipo función anónima. Por ejemplo...

$general->layout = function($proporcion) {
	return $proporcion / 800;
}

...que se podría aplicar de este modo:

.columna1 { width: <?=$layout(100) ?>em; }

Un último apunte sobre CSS "plantilladas": te recomiendo que las nombres con extensión .css.php, como se ve en los ejemplos, o bien .css.tpl. Utilizar la extensión simple .css puede llevar a confusiones... pero es sólo un consejo.

Aumentando el rendimiento

Tanto si usamos variables en las CSS como si no, podemos mejorar el rendimiento si las procesamos con PHP, tanto en el servidor (tardamos menos en procesarlas) como en el cliente (le llegan antes).

Un ejemplo es el envío de varias hojas de estilo como un solo fichero. Mientras las buenas prácticas de CSS recomiendan separar las hojas de estilo por secciones o por navegadores (por ejemplo, ie-hacks.css, webkit.css, etc), las buenas prácticas de rendimiento nos aconsejan minimizar el número de peticiones HTTP. Así pues, ¿qué escogemos: mantenibilidad o rendimiento? Pues yo me quedo con las dos: escribamos las CSS en ficheros separados y juntémoslas a la hora de servirlas.

CssDispatcher nos permite hacerlo de una forma muy sencilla. Una vez que hemos creado instancias de la clase Css para cada hoja de estilo, las añadimos a un objeto CssDispatcher:

$general = new Css('ejemplo.css.php');
$general->fondo = '#eee';

$otra = new Css('example2.css.php');
$otra->negrita = 'font-weight: bold';

//Creamos un dispatcher
$estilos = new CssDispatcher;

//Añadimos las CSS al dispatcher
$estilos->add($general);
$estilos->add($otra);

$estilos->render();

Cross-browser

Otro de los problemas comunes cuando se escriben estilos es la compatibilidad entre navegadores. No todos renderizan las CSS de igual forma, así que es habitual escribir hojas de estilo con propiedades específicas para Internet Explorer, Safari/Chrome, etc. Dependiendo del que esté utilizando el usuario se envía una u otra.

Se han venido utilizado tres métodos diferentes para cargar hojas de estilos específicas:

  • Comentarios condicionales (sólo funcionan en IE): para añadir CSS específicas de Internet Explorer basta con envolver la línea de llamada (<link rel="stylesheet"...) con las directivas <!--[if IE 6]> y <![endif]-->.
  • JavaScript: una vez cargada la página, se ejecuta un script que comprueba el navegador y carga dinámicamente la hoja de estilos correspondiente. En consecuencia, los usuarios que no ejecuten JavaScript (por seguridad o por usar un navegador viejo/limitado) no podrán cargar hojas de estilo específicas.
  • En el servidor:: antes de enviar la página, el script que la genera comprueba la cabecera HTTP User-Agent y escribe las invocaciones correspondientes al generar HTML.

Elegiremos el último método por ser más seguro y compatible. Con CssDispatcher definir CSS específicas de navegador es tan fácil como añadir un segundo parámetro en el constructor de la clase Css:

//Enviará la hoja de estilos si el navegador del usuario es Internet Explorer 6
$ie_hacks = new Css('ie_hacks.css.php', Css::UA_IE6);

Puedes especificar las siguientes familias de navegadores: Internet Explorer 6 (Css::UA_IE6), Internet Explorer >6 (Css::UA_IE), Gecko (Css::UA_GECKO), WebKit (Css::UA_WEBKIT). También puedes utilizar los sinónimos UA_MOZILLA, UA_FIREFOX, UA_SAFARI y UA_CHROME respectivamente. Para más información puedes ver la referencia de CssDispatcher.

En resumen

Hemos visto varias técnicas que nos ayudan a manejar de forma más eficaz y eficiente las hojas de estilos. Puedes utilizar las que necesites, tanto si quieres hacerlo de forma manual como utilizando CssDispatcher (u otras bibliotecas, si las encuentras dímelo!). A saber:

  • Asignación de variables en espacios de nombres seguros.
  • Hojas de estilos específicas de un navegador.
  • Minimización del código CSS.
  • Unión de hojas de estilos para un envío único.

Rendimiento en el servidor con cache

No hay que olvidar que generar estilos con CssDispatcher provoca una carga en el servidor por los accesos a disco (para obtener las CSS y otro para obtener los scripts) y por el tiempo de compilación y ejecución. Por ello, una buena técnica para aumentar la velocidad y reducir sobremanera el throughput es cachear el resultado final de la ejecución de CssDispatcher. Para cachear la salida de un script existen varias técnicas:

  • Cache en el servidor web: la salida de una petición se almacena en memoria o disco y se sirve sin ejecutar nada de PHP. En Apache esto es posible con el módulo mod_cache y sus motores de almacenamiento, mod_disk_cache y mod_mem_cache.
  • Cache a través de PHP: esta técnica hace básicamente lo mismo que la anterior, pero en vez de estar gestionada por el servidor web se gestiona con scripts PHP. Por ello, aunque no es necesario compilar y ejecutar los scripts de CssDispatcher sí es necesario ejecutar el script de control de cache, por lo que esta solución no es tan buena como mod_cache. No obstante, en servidores compartidos y otros entornos de escaso control es una buena solución. Además, el script de control de cache se puede cachear con los sistemas de cache de bytecodes como APC o eAccelerator, aunque eso ya es un tema aparte.

MagiSQL ha muerto

7 de agosto de 2009 | 4 comentarios

Hace cerca de un año que comencé un proyecto llamado MagiSQL, con el objetivo de crear una herramienta modular de gestión de bases de datos relacionales, compatible con múltiples sistemas de BBDD y con licencia libre, por supuesto.

Me he planteado muchas veces la viabilidad y utilidad del proyecto, ya que la competencia es muy dura (phpMyAdmin, pgAdmin, Oracle Enterprise Manager, etc etc etc) y exige reinventar la rueda en la mayoría de los módulos. Además, para que el proyecto fuese exitoso no sólo era necesario que me dejase los ojos durante muchas horas, sino que más programadores se sumasen al proyecto y desarrollasen módulos compatibles con los sistemas gestores de bases de datos, ya que yo no tengo tiempo ni medios para hacer MagiSQL compatible con Oracle, MS-SQL Server, PostgreSQL, MySQL y DB2, como está planteado en los objetivos del proyecto (de momento sólo funcionaba con MySQL). Además, este verano he reescrito por completo el núcleo, lo que ha retrasado y complicado aún más el desarrollo.

Por estos motivos y muchos otros (baja productividad, falta de tiempo y concentración, cuestiones personales...) he decidido no continuar el proyecto. Nunca ha alcanzado un nivel de madurez mínimo como para ser usable, y la gran parafernalia de módulos, clases y patrones hace bastante inútil el código que hay en mi disco duro y en el SVN de Sourceforge. En resumen, que se irá todo a la basura.

¿Todo? Eso significaría tiempo perdido, derrota, fracaso. Y aunque no deja de serlo, es un fracaso del que estoy orgulloso y del que he aprendido un montón, entre otras cosas:

  • He ideado el patrón de diseño "Application Status", del que tendréis más noticias dentro de algún tiempo... ;-)
  • Me he acostumbrado a escribir documentación en línea (phpDoc) y en inglés.
  • Me he familiarizado con la biblioteca AdoDB.
  • Me he hartado de Smarty. Era el último proyecto en el que lo usaba, y desde ahora sólo utilizaré plantillas PHP.
  • He aprendido más cosas sobre la reescritura de URL y expresiones regulares.
  • He comprendido e implementado multitud de patrones.
  • Me he familiarizado con las excepciones de PHP y los métodos mágicos.
  • He explotado las novedades de PHP 5.3.
  • He encontrado un buen entorno de programación en PHP sobre Linux (Netbeans, KCacheGrind, etc).
  • Me he convencido una vez más de que reinventar la rueda es friki, divertido pero inútil y bastante frustrante.
  • He escuchado cientos de discos mientras hacía todo eso ;-)

Bueno ¿y ahora, qué? Ya que el proyecto era para una asignatura de la carrera (aprovecho para decir que, tras pasar al Grado en Informática en la UCAM, he tenido que volver a matricularme de una asignatura que ya tenía aprobada), será sustituido por un motor de almacenamiento en MySQL para Object Freezer. Object Freezer es una biblioteca escrita por Sebastian Bergmann para almacenar objetos en la base de datos CouchDB sin preocuparse de SQL, DAO y demás inventos del pasado ;-)

PD: perdón por saltarme la canción del lunes, no tengo mucho tiempo últimamente para postear, pero os he dejado un regalito en twitter ;-)


La licencia de PHP prohíbe nombrar a tus proyectos "PHPnosequé"

17 de julio de 2009 | 0 comentarios

Navegando por la documentación de PHP, he ido a parar a la página de licencia. Es esta página, además del texto legal se dan algunas explicaciones e indicaciones, entre las cuales está la instrucción de no usar la denominación "PHP" en nombres de proyectos que utilicen esta tecnología.

De hecho, esta indicación viene apuntada en una de las cláusulas la propia licencia:

4. Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from group@php.net. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo"

Más claro agua. Así que proyectos como phpMyAdmin, CakePHP, PHP-Nuke y un interminable etcétera están inclumpliendo los términos de la licencia, a nos ser que cuenten con un permiso especial del grupo PHP (ignoro si es así).

Por supuesto, esto no significa que Rasmus Lerdorf y compañía tengan "patentada" la denominación PHP, sino que no puedes usarla en proyectos que se basen en su tecnología, ya que se consideran derivados de PHP. Una curiosa cláusula que sorprende que no hayan leído o no hayan atendido los responsables de tantos proyectos exitosos.


Licencias libres: me quedo con la BSD

8 de julio de 2009 | 4 comentarios

Me encuentro desarrollando estos días mi programa de dominación mundial Magis (anteriormente llamado MagiSQL). Aunque desde un principio pensé en licenciarlo con GPL, mi creciente antipatía por Richard Stallman y la cláusula que ahora comentaré me han llevado a preferir la licencia BSD.

Las dos licencias de las que hablo son licencias de software libre aprobadas como tales por la OSI (Open Source Inititative). A grandes rasgos, ambas amparan las cuatro libertades del software libre (libre uso, libre estudio, libre modificación y libre redistribución). La principal diferencia radica en la cláusula protectora de la GPL: los programas licenciados bajo sus términos no pueden ser mezclados con software no libre, es decir, las obras derivadas de una GPL deberán ser GPL también. Esta cláusula es muy importante para los defensores de la religión GNU, pero personalmente prefiero que la libertad sea libertad real: mi software es tan libre que puede ser usado para propósitos no libres.

Más allá de cuestiones doctrinales, la cláusula protectora de la GPL intenta promover la creación de más software GPL, en base al ya escrito. En la otra cara, esta libertad (libertinaje para los Stallman-áticos) de las licencias BSD y similares es observada con recelo, ya que permite a terceros (empresas) utilizar software libre ("gratis") y vender estos sistemas modificados, consiguiendo así que el propio software libre esté al servicio del malévolo negocio del privativo.

En mi opinión, esto es cierto, algunas empresas pueden aprovecharse de los que hacemos software libre para redistribuirlo con/como privativo; es un peligro patente. Pero entiendo que la libertad significa más que una barba larga y la cultura hippie que envuelve los sermones de RMS. Quiero hacer programas tan libres que se pueda incluso malutilizar su libertad; porque la libertad no está en el software, sino en las personas que lo usan.


10 consejos para hacer más productiva tu navegación con Firefox

13 de marzo de 2009 | 0 comentarios
  1. No abuses de las extensiones. Elimina todas las que no sean estrictamente necesarias.
  2. Si lees mucho, blogueas o investigas, quizá la extensión Wired Marker te resulte útil.
  3. MeeTimer es una interesante extensión que mide el tiempo que pasas en cada página, clasificándolo en trabajo, ocio, etc.
  4. Un theme chillón o sobrecargado puede desconcentrarte y ralentizar Firefox.
  5. Elimina la barra de Google, la de Yahoo! y cualquier otra que no aporte una funcionalidad que realmente uses. Te quitan espacio en la pantalla para navegar, y no suelen ser muy útiles.
  6. Utiliza los atajos de teclado y ratón: Ctrl+T abre una nueva pestaña, y click central en un enlace lo abre en una pestaña nueva. Los mouse gestures son un gran invento, aunque personalmente no los uso.
  7. Firefox se está volviendo lento y pesado. Quizá puedas prescindir de él. Opera y Chrome son dos excelentes opciones (esta última me gusta por rápida y sencilla), aunque sin la potencia de las extensiones de Firefox.
  8. Hay extensiones y scripts para Greasemonkey que mejoran aplicaciones web como GMail o Netvibes. Por ejemplo: Better GMail o Better Google Reader. Mis aportaciones: un script para maximizar el espacio de Netvibes y otro para hacer más ancho el gestor de tareas Remember The Milk.
  9. Con Menu Editor puedes eliminar todas esas opciones de los menús que no te hacen falta (por ejemplo, en el menú contextual de un enlace no necesitas el menú Abrir en pestaña nueva porque ya sabes cómo hacerlo con un sólo click). Y con CuteMenus puedes ponerle iconos, para facilitar la navegación por los menús.
  10. El plug-in the Foxit Reader para leer PDF es más rápido y ligero que el de Adobe Reader.

¿Algún otro consejo? ¿Te parece Firefox un buen navegador para no perder el tiempo?


israelviana.es es propiedad de Israel Viana, escrito en Murcia (España). Puedes ponerte en contacto conmigo a través de la dirección de e-mail .com.
Información en RDF Metadatos Dublin Core Creative Commons License