Llevo un buen rato para encontrar la solución este dichoso fallo: imposible controlar con JavaScript el reproductor JW FLV Media Player. Al obtener el objeto el método getConfig() no existe y la función playerReady() no se llama. Se debe a que en Linux el reproductor necesita que se indique el parámetro id en la variable flasvars con el ID del objeto en cuestión. De otro modo no se cargará correctamente y no será posible hacer nada con JavaScript para controlarlo. Encontrado en este hilo del foro oficial.

En el anterior post explicaba cómo programar clientes para LCDproc usando únicamente Perl. Pues bien, como de serie no trae ninguna pantalla que muestre información de los sensores de temperatura de la placa base y el procesador, he programado un script que lo hace: sensors.pl. Basta ejecutarlo para que muestre una pantalla con las temperaturas de la placa base, north bridge, procesador, tarjeta gráfica, discos duros y las revoluciones del ventilador principal:

Requiere tener instalados lm-sensors para la temperatura de la placa base y procesador, hddtemp para los discos duros y nvclock para la tarjeta gráfica NVIDIA. Está preparado para una pantalla de 20×5, pero es fácilmente adaptable, añadiendo o quitando líneas. El código es muy claro y es sencillo modificar los sensores que se deben mostrar o añadir nuevos…

Ya he hablado de LCDproc en este blog, pero aunque está muy bien las pantallas disponibles son limitadas y al estar programado en C, si no dominas el lenguaje es complicado programar tu propio cliente para mostrar lo que necesites. Para los aficionados al scripting en vez de a la compilación existe perl-LCDd, un pequeño módulo Perl que proporciona una clase para interactuar con la pantalla y así mostrar los datos que se desee. Viene con un ejemplo muy sencillo que ayuda a crear el primer cliente, así como con documentación de los métodos de la clase.

Actualización: para los mas frikis, ésta es la documentación oficial que permite crear un cliente. Es la especificación para comunicarse con el servicio, que puede hacerse incluso por telnet.

Hoy he tenido que mibrar un repositorio Subversion que lleva meses con la versión 1.5 a otra máquina con la versión 1.6. La configuración y demás ha ido bien, pero al intentar acceder al repositorio, me he encontrado con el siguiente mensaje:

bdb: Program version 4.4 doesn't match environment version 4.6

Evidentemente se debe a las diferentes versiones de Berkeley DB que usan las dos máquinas, por lo que es necesario realizar la conversión de las bases de datos. Una opción es utilizar db4.X-utils, pero no siempre está disponible en los repositorios de las distribuciones (por no hablar de Windows), por lo que es mucho más fácil volcar el repositorio con los comandos de Subversion, e importarlo en la nueva máquina. El volcado se realiza con el siguiente comando:

svnadmin dump repositorio > backup.dump

Y en la nueva máquina, en vez de copiar el repositorio tal cual, se crea uno de cero y se realiza la importación:

svnadmin create --fs-type fsfs repositorio
svnadmin load repositorio < backup.dump

Con esto nos ahorramos pelearnos con conversión de versiones

Localizar y optimizar consultas SQL problemáticas es muy laborioso y complejo a veces. Uno de los mayores problemas con los que me he encontrado, es localizar exactamente desde dónde se ha ejecutado esa consulta para así reproducir el problema lo más fielmente posible en un entorno de desarrollo.

Un SHOW PROCESSLIST permite visualizar la lista de consultas que se están ejecutando, con su tiempo y el host desde donde se ha realizado la conexión pero sin más información, cuando lo realmente interesante es ¿desde dónde se ha ejecutado esta consulta?. La solución es muy sencilla: utilizar comentarios SQL dentro de las consultas.

Hoy en día, cualquier aplicación mínimamente grande utiliza una capa de abstracción (bien integrada en un framework, bien propia) por lo que no suele resultar difícil interceptar las consultas para añadir los comentarios. Si combinamos esto con funciones como debug_backtrace() de PHP (o su equivalente en Ruby o Python), tendremos una valiosísima información, ya que es posible determinar desde qué función, clase+metodo e incluso la línea concreta:

SELECT /* controlador test, metodo database, linea 17 */ field1, field2 FROM table

Este pequeño truco faciltará mucho el trabajo de detectar consultas conflictivas especialmente en casos en los que se ejecutan desde muchos lugares en diferentes archivos, y a efectos prácticos el rendimiento no se ve mermado.

Suelo consultar Compostela Cultura para informarme de los eventos de Santiago, pero por desgracia no hay disponible ningún formato (como RSS o ICS) que permita sindicar/sincronizar los eventos. Por eso le he dedicado un momento para crear un parser que interprete el código HTML de las páginas y genere un archivo ICS, que puede utilizarse para añadirlo a cualquier programa que lo soporte, como Mozilla Sunbird o Microsoft Outlook. De este modo tendremos como un evento más del calendario, con su fecha, hora, ubicación, título y descripcion (este último campo sólo para los eventos para hoy).

Está programado como no en PHP, por lo que puede usarse con un servidor web o via comandos. Este es el código fuente y por defecto obtiene los eventos de música, pero indicando el parámetro GET tipo puede cambiarse.

Sugerencias y dudas, en los comentarios

Aún después de años programando en PHP se descubren cosas nuevas. Hoy gracias a mi compañero Luis descubro algo que lleva implementado ¡¡¡desde PHP3!!! pero que nunca se me había ocurrido o no había necesitado: retornar valores con un include o require:

It is possible to execute a return() statement inside an included file in order to terminate processing in that file and return to the script which called it. Also, it’s possible to return values from included files. You can take the value of the include call as you would a normal function. This is not, however, possible when including remote files unless the output of the remote file has valid PHP start and end tags (as with any local file). You can declare the needed variables within those tags and they will be introduced at whichever point the file was included.

Es decir, que si creamos el archivo test.php:

<?php
function test() { }
return 'OK';
?>

Al hacer este include, la variable $res tendría el valor ‘OK’:

$res = include('test.php');

Una vez se conoce esta funcionalidad, puede sacársele partido

A la hora de generar gráficas para utilizar en páginas web, hay muchas alternativas. Todo depende del tipo de la orientación de la aplicación que se desarrolle. Hay muchas aplicaciones comerciales pero para no perder mi fama, hablaré sólo de las alternativas gratuítas (aunque no todas sean OS) y que puedan generarse utilizando PHP.

JavaScript

Las soluciones basadas en JavaScript utilizan el elemento <canvas> de HTML5, que permite la creación de imágenes dinámicas mediante scripts. Eso permite incluso la interactuación con las gráficas en tiempo real. Algunas soluciones implementan también la creación dinámica de imágenes SVG.

• PlotKit: genera 5 tipos de gráficas con canvas o SVG. Requiere el framework MochiKit.
• Plotr: port de PlotKit para el framework Prototype.
• plOOtr: port de PlotKit para el framework MooTools.
• Flot: destaca por la interactividad (cambios en tiempo real, selección o zoom). Visualmente es más avanzado que PlotKit y requiere el framework jQuery.
• Flotr: port de Flot para el framework Prototype, del mismo autor del port de PlotKit a Prototype.
• jQuery Sparklines: genera gráficas tipo Sparkline usando el framework jQuery.

Adobe Flash

Las gráficas basadas en Flash se componen de un archivo SWF que realizan una petición para obtener los datos que generan la gráfica. Tienen la ventaja de ser más vistosas debido al uso animaciones como efectos al crear la gráfica o tooltips para mostrar los valores de los datos en los diferentes puntos, pero el inconveniente de realizar 2 peticiones HTTP para mostrarse.

• Open Flash Chart: los archivos de datos utilizan JSON y tiene API para PHP y Perl.
• PHP/SWF Charts: genera 20 tipos de gráficas con archivos de datos XML. Tiene API para PHP y versión de pago.
• FusionCharts Free: incorpora API para PHP, ASP, JSP, ASP.NET, RoR e incluso Cold Fusion. También permite crear diagramas de Gantt. Los archivos de datos utilizan XML y tiene versión de pago con el doble de gráficas y más funcionalidades.
• Yahoo! UI Charts: usa JavaScript para crear las gráficas pero Flash para mostrarlas. Todavía está en fase experimental.

Imágenes estáticas

Otra opción es generar imágenes estáticas.

• PEAR::Image_Graph: genera 15 tipos de gráfica. Antes conocida como GraPHPite, ahora stá integrada en las librerías PEAR y tiene varias dependencias, pero puede instalarse como una libreria más.
• JpGraph: genera 16 tipos de gráficas incluyendo mapas y diagramas de Gantt. Tiene versión de pago.
• pChart: genera pocos tipos de gráficas pero muy vistosas.

Online

Una nueva modalidad es la creación de gráficas online mediante una API, que permiten descargar la tarea de generarla en un servidor externo. El inconveniente son las limitaciones que establecen los proveedores del servicio.

• Google Chart: soporta los tipos básicos de gráficas (lineas, areas, barras…) pero incluye dos muy interesantes: mapas y QR-Codes. Tiene límite de 50.000 peticiones/dia y 0.3 megapixels por gráfica.

Seguro que se me escapa alguna. ¿Sugerencias?

Hay proyectos en los que es necesario pensar en la portabilidad de la base de datos, permitiendo que funcione perfectamente en diferentes servidores. Por ejemplo, el famoso phpBB soporta 7 sistemas. Esto no es recomendable en proyectos en los que el rendimiento es algo vital como sitios web y sólo debe aplicarse a proyectos donde prima la portabilidad.

A nivel de aplicación, esto requiere el uso de una capa de abstracción que hoy en día integran la mayoría de frameworks o que puede lograrse con con la extensión PDO de PHP o clases como ADOdb. Y para convertir las bases de datos entre sí, ya he hablado de SQL::Translator, un potente script programado en Perl.

Conoce el estándar SQL-92

En la especificación de SQL-92 se definen los puntos comunes del lenguaje. Tenerlos claros los puntos es primordial como por ejemplo el uso de comillas simples para literales.

Comprueba todos los datos antes de enviarlos a la base de datos

Esto debe ser básico en cualquier desarrollo, pero nunca sobra recordarlo. Todos los datos que se almacenen deben estar comprobados, ya que un sistema puede aceptar un valor no válido para un tipo de dato y convertirlo mientras que otro sistema lo rechazará.

Usa correctamente los valores NULL y asigna valores por defecto

Todos los campos que sean omitibles en un INSERT o un UPDATE deben tener un valor por defecto o bien ser NULL. En bases de datos como SQLite, el no especificar un valor por defecto provoca un error, mientras que en MySQL no.

Usa transacciones cuando se requiera

Cuando se realizan varias consultas seguidas de inserción, actualización o borrado, es recomendable el uso de transacciones. Es mejor no realizar ningún cambio a que se realice a medias, perdiendo datos.

Usa consultas INSERT y UPDATE completas

Nunca deben omitirse partes de las sentencias de inserción y actualización. Por ejemplo: INSERT INTO tabla (campo1, campo2) VALUES (’a', ‘b’).

Usa siempre ORDER BY

MySQL permite establecer el orden por defecto de una tabla y en otros sistemas el orden puede variar por cada consulta realizada, ya que se puede ordenar por fecha de actualización o inserción del registro. Por eso nunca debe omitirse ORDER BY.

Evita el uso de la integridad referencial

La integridad referencial no está soportada en todos los sistemas (MySQL con tablas InnoDB sí la soporta pero no con tablas MyISAM, SQLite permite asignar claves foráneas pero no hace nada con ellas), por lo que la lógica debe trasladarse a la programación, borrando o actualizando los datos relacionados de ser necesario.

Evita el uso de funciones propias

No deben usarse funciones propias de cada sistema, dificultan la portabilidad. Lo que se puede hacer con una función en una consulta puede hacerse con otra función en la programación. Eso sí, ciertas funciones de tratamiento de cadenas y fechas pueden ser comunes o muy similares, por lo que en caso de ser necesario, debe tenerse en cuenta a la hora de programar para usar la adecuada según el sistema. Algunas capas de abastracción como ADOdb integran ayudas para estos casos.

Evita el uso triggers y procedures

Todo lo que puede incluirse en disparadores y procedimientos almacenables puede incluirse en la lógica de la aplicación. Se pierde comodidad pero evitan problemas, ya que la implementación de estas funciones varía y ciertos sistemas no las implementan.

Evita el uso de vistas

Las vistas funcionan de diferente forma entre los diferentes RDBMS existentes, sobre todo en la actualización de los datos que consulta, lo que puede provocar resultados inesperados. Hay que recordar que sólo algunos sistemas permiten la actualización de datos en vistas, por lo que es importante no hacer uso de esa funcionalidad.

Evita el uso de subconsultas

Del mismo modo que las vistas, las subconsultas funcionan de diferente forma entre los diferentes RDBMS existentes y no todos las implementan. Cada sistema tiene sus restricciones, por lo que una subconsulta que funciona perfectamente en

Evita el uso tipos de datos y atributos no estándar

Los tipos de datos específicos de ciertos motores deben evitarse. Por ejemplo, una fecha timestamp puede almacenarse en un campo INT de 32 bits, pero en MySQL puede almacenarse en un campo tipo TIMESTAMP con el atributo ON UPDATE CURRENT_TIMESTAMP que no es extensible a otros sistemas. Otro ejemplo pueden ser los tipos BOOL, que pueden sustituirse por enteros (0 – 1).