QuarkBlog_2.0

PDO es una de las muchas abstracciones de acceso a datos que existen en PHP que intenta unificar la manera en la que PHP habla con las bases de datos. La característica que diferencia a PDO del resto es que está escrito en C y no en PHP (con lo que utiliza drivers nativos y esta enfocado en ser rápido y eficiente).

Wez Furlong quiere convertir a PDO en la manera estándar de acceso a datos para PHP, para ello ha estado rediseñando la arquitectura y los interfaces de “PDO versión 2″ para producir una especificación abierta en la que los fabricantes de bases de datos puedan construir drivers, ampliar y mejorar la cobertura de tests unitarios y mejorar los metadatos.

Para obtener la atención de los fabricantes, especialmente IBM, ha propuesto un Contributor License Agreement para facilitar la inclusión de código por parte de las empresas privadas (existen problemas legales por la cesión de propiedad intelectual a un proyecto open source). Existe una versión para empresas y otra a título individual, y la licencia de PDO que es diferente a la de PHP. Wez también ha preparado un FAQ sobre todas las cuestiones legales de este asunto.

Este movimiento ha causado sentimientos enfrentados dentro de la comunidad de desarrolladores de PHP: mientras que Jay Pipes (MySQL) opina que no es para tanto, hay otras muchas personas que han puesto el grito en el cielo. Y es que el conflicto está en que todo aquel que quiera aportar código a PDOv2 o simplemente leer la especificación debe firmar el CLA y atenerse a sus condiciones. Lo que lo convierte en esencia en software no-libre.

PHP no es GPL (su licencia es incompatible) pero es considerado software libre. El requisito de firmar una CLA antes de remitir código o mirar la especificación de PDO v2 elimina directamente la libertad 3 (libertad para mejorar el programa y distribuir cambios al público, por los que se beneficia toda la comunidad), haciendo a PDO no-libre.

Dado que la GPL no se aplica a PHP ni a PDO, veamos la definición de software libre que proporciona la OSI que es más o menos lo que viene a decir el contrato social de Debian haciéndolo un poco más universal. Aquí ya me pierdo un poco (no soy abogado y es posible que me equivoque en muchas de estas cosas) pero creo que la obligación de firmar una CLA viola el espíritu de la definición de la OSI así como los puntos 3 y 5 de la carta.

La inclusión de CLAs es algo nuevo en el mundo de PHP pero es habitual e inevitable en otros proyectos de gran calado e importancia empresarial como Apache o Mozilla. El software libre no es sólo código abierto, es participación y las CLAs ponen trabas al libre intercambio de información porque determinadas empresas podrían influir negativamente en el desarrollo de PDO desplegando su cartera de patentes y segmentaría a los desarrolladores en dos grupos irreconciliables: los que la firman y los que no. Si alguien en PHP necesita drivers privativos para acceso a datos es mejor que estén fuera del núcleo de desarrollo.

Son muchos los desarrolladores que se niegan a pasar por el aro (la mayoría), asi que si las cosas no cambian y se llega a un acuerdo, probablemente se produzca un fork en PDO o directamente se quite del core, lo que sería una verdadera putada …

El formato de llavero PKCS#12 (extensiones .p12 y .pfx) es uno de los más populares para almacenar
claves criptográficas. En PHP podemos gestionar este tipo de claves a partir de la versión 5.2.2
gracias al módulo OpenSSL.

Como es muy nuevo y no hay documentación al respecto, dejo aquí un ejemplo de uso:

Un poquito de rant gracioso en formato twittero.

Autoload es uno de los llamados métodos mágicos de PHP que se dispara “mágicamente” cuando, al instanciar una clase, el interprete no es capaz de localizarla porque no se ha hecho el include/require del archivo correspondiente. Con autoload podemos sobrecargar esta funcionalidad y especificarle a PHP donde debe buscar sin tener que indicar explicita mente todos los archivos de clases de nuestro proyecto mediante include/require.

El problema viene cuando nuestro proyecto utiliza su propio autoload y un componente de un tercero utiliza otro autoload completamente diferente: sólo puede haber un punto para interceptar la llamada “autoload” e inevitablemente colisionan.

Afortunadamente la SPL proporciona un mecanismo para apilar métodos autoload, tantos como sean necesarios, y evitar las colisiones. Veamos un ejemplo:

Las clases Component1 y Component2 tienen dos funciones __autoload() diferentes.

Los dos callbacks autoload colisionan.

Utizando SPL podemos detectar si ya hay un callback autoload definido para sobreescribirlo, o apilar el nuestro. Además la función autoload puede meterse como metodo de una clase y mejorar un poco el aspecto del codigo:

Cuidado porque la función autoload no es demasiado liviana y un uso abusivo puede provocar una bajada de rendimiento en el programa, pero de momento y hasta la versión 5.3, sin espacios de nombres en PHP no podemos hacer gran cosa

Os dejo un task para Phing que programé para crear automáticamente paquetes Phar en PHP. Como no hay demasiada documentación sobre cómo extender Phing y crear nuevas tareas, os puede servir de guía para implementar las vuestras porque la verdad es que yo programé esta casi a ciegas.

La tarea: PHPArchiveTask

Y aquí el ejemplo de uso del XML del build.xml correspondiente:

<project name=“builder” default=“package”>
	<!– custom tasks –>
	<taskdef name=“phar” classname=“phing.task.PHPArchiveTask” />
	
	<!– custom properties –>
	<property name=“phar.version” value=“1″ />
	<property name=“dist.dir” value=“./dist” />
	<property name=“src.dir” value=“./src” />
	
	
	<target name=“package”>
		<echo msg=“Building package …” />
		<phar
			version=“${phar.version}” 
			bootstrap=“lib/phar-bootstrap.php” 
			gzip=“true” 
			output=“{dist.dir}/packages/myFirstPharPackage${phar.version}.phar” 
			stub=“{src.dir}/phar-stub.php”>
	
			<fileset dir=“{src.dir}”>
				<include name=“classes/**/*.php” />
			</fileset>
		</phar>
	</target>

</project>

Deberéis colocar la tarea en la ruta phing/task/PHPArchiveTask.php a partir del lugar donde esté el build.xml, tal y como indica el espacio de nombres (de esos espacios de nombres de mentira que hay en PHP…). El resto de opciones creo que están bastante claras.

1. Si un método puede ser static, decláralo estático. La velocidad se incrementa en un factor de 4.
2. echo es más rápido que print, aunque la diferencia es despreciable.
3. Inicializa el contador de tus bucles for antes y no en el propio bucle.
4. Si tienes que iterar un objeto o un array, utiliza SPL en lugar de bucles recursivos.
5. Destruye las variables que ya no utilices con unset() para liberar memoria, especialmente si son objetos o arrays pesados. Si utilizas OOP, revisa el destructor __destruct() en este sentido.
6. Si tienes que recorrer un array enorme y no te interesa guardarlo, considera utilizar array_shift() para ir leyendo y borrando a la vez.
7. No abuses de __get(), __set() y __autoload().
8. require_once() es pesado. Muy pesado en PHP < 5.0.
9. Utiliza paths absolutos a los ficheros en los include() y require(), el SO tarda menos en resolver las rutas al fichero.
10. Si necesitas saber el timestamp de acceso a un script, considera utilizar $_SERVER['REQUEST_TIME'] en lugar de time()
11. Comprueba si puedes usar strncasecmp(), strpbrk() y stripos() en lugar de expresiones regulares.
12. str_replace() es más rápido que preg_replace(), pero strtr() es hasta 4 veces más rápido que str_replace().
13. Si la función, como la función de reemplazo de cadenas, acepta dos arrays y un carácter como argumentos, y tu lista de argumentos no es muy larga, considera escribir varias sentencias de reemplazo redundantes, pasando un carácter cada vez, en lugar de una linea de código que acepte arrays como búsqueda y reemplazo.
14. La supresión de errores con @ es bastante ineficiente a la par que desaconsejable.
15. eval() is evil (y además horrorosamente lento).
16. $row['id'] es hasta 7 veces más rápido que $row[id]
17. Si una variable de clase es constante, utiliza const.
18. Los mensajes de error son ineficientes, utilizalos sólo cuando sea necesario.
19. No uses funciones dentro de los bucles, como for ($x=0; $x < count($array); $x++). La función count() se ejecuta cada vez que se repita el bucle.
20. Incrementar una variable local en un método es lo más rápido. Casi lo mismo que llamar a una variable local en una función.
21. Incrementar una variable global es dos veces más lento que hacerlo con una variable local.
22. Incrementar una propiedad de un objeto (por ejemplo $this->prop++) es 3 veces más lento que hacerlo sobre una variable local.
23. Incrementar una variable indefinida es hasta 10 veces más lento que hacerlo en una ya inicializada.
24. Declarar una variable global sin utilizarla también enlentece la ejecución. PHP comprueba si existe.
25. La cantidad de métodos definidos en una clase no afecta al rendimiento.
26. Los métodos de la clase concreta se ejecutan más rápidos que los de la clase base.
27. $localvar++ es hasta 15 veces más rápido que function inc(){ $localvar++; }.
28. Las cadenas encerradas entre comillas simples son más rápidas que las que lo están con comillas dobles porque PHP no expande las variables que puedan contener. Si usas PHP 5+, la diferencia es mínima.
29. Cuando se aplica echo a una lista de cadenas por argumento, es más rápido separarlas con una coma (,) en lugar del operador de concatenación (.). Esto sólo funciona con echo por ser una construcción del lenguaje y no una función.
30. Un script PHP es servido por Apache entre 2 y 10 veces más lento que una página estática. Cachea resultados cuando sea posible.
31. Los scripts PHP se “compilan” cada vez que son ejecutados a menos que se guarde el código objeto en un cache. Las diferentes herramientas de compilación de PHP incrementan el rendimiento hasta un 100%.
32. Puestos a cachear, Memcached es mucho más rápido y versátil que un cache a disco. APC también da buen resultado pero es menos escalable.
33. Usa ip2long() y long2ip() para almacenar direcciones IP como números en lugar de como cadenas. Reduce el espaco en un factor de 4 y los cálculos de rango, máscara y ordenaciones son más sencillos y rápidos.
34. Usa la extensión SOAP nativa en lugar de NuSOAP.
35. Valida las direcciones de correo electrónico con checkdnsrr().
36. php_filter() mejor y más rápido que tu sistema home made de validación.
37. Las funciones mysql_* son más lentas que mysqli_*, pero no tan eficientes como el driver mysqlnd para PDO (disponible en el inminente PHP 5.3)
38. Usa sentencias preparadas, en lugar de concatenar las consultas a mano, para mejorar el rendimiento y frenar significativamente las SQL-Injections. ( y Matt puede decir misa, hacedme caso a mi )
39. No reinventes la rueda, mira a ver si puedes aprovechar algo de PEAR, PECL, SourceForge, CakePHP, CodeIgniter, Zend Framework, …
40. Utiliza highlight_file() para postear código formateado y bonito en los foros (por favor!!).
41. Si guardas un objeto o array serializado en la base de datos, considera usar gzcompress() y gzuncompress() para ahorrar espacio. GZip puede reducir el tamaño de un texto plano hasta en un 90%.
42. El operador ternario no es más rápido que un if-else.
43. empty() es más rápido que $var == '', pero es más rápido el operador identidad $var === ''. En general la identidad es más rápida en cualquier situación.
44. do-while es más rápido que while, pero más lento que for. Lo primero a optimizar de un programa son los bucles ( un viejo truco de Algoritmia y Arquitectura de computadores )
45. Si necesitas determinar si una cadena tiene un cierto tamaño, es más rápido utilizar la construcción del lenguaje !isset($str{5}) que la función strlen($str) < 5
46. el preincremento ++$i es más rápido que el postincremento $i++ debido a interioridades del interprete de Zend, de echo es una de las optimizaciones a nivel de OPCODE más utilizadas por los compiladores de PHP.
47. Usa preg_* en lugar de ereg_*, está a punto de desaparecer y es mucho más lento.
48. Usa direcciones IP en lugar de nombres de dominio.
49. El manejador de flujos ob_start() puede aumentar el rendimiento hasta en un 25%.
50. El paso de argumentos por referencia en PHP no es igual al paso de una referencia en C mediante un puntero. En PHP una referencia sirve para acceder a una variable mediante dos nombres distintos (nombre de variable y valor de la variable son cosas distintas en PHP). Por tanto pasar arrays por referencia como en C, en realidad, es más lento que hacerlo por valor. En PHP 5+ los objetos se pasan explícitamente por referencia.
51. Un uso apropiado de las referencias como alias de nombre de variable:
    1.  
    2. $a[‘b’][‘c’] = array();
    3. // 2 accesos por iteración a la tabla hash
    4. // donde PHP almacena las variables
    5. for($i = 0; $i < 5; $i++)
    6.         $a[‘b’][‘c’][$i] = $i;
    7.  
    8.  
    9. // con un alias por referencia es mas rápido
    10. $ref =& $a[‘b’][‘c’];
    11. for($i = 0; $i < 5; $i++)
    12.         $ref[$i] = $i;
    13.  
52. La manera más rápida a este lado de Rio Grande para detectar si el SO es Unix o no es utilizar la constante DIRECTORY_SEPARATOR.
53. La manera más rápida de concatenar muchas cadenas de poco tamaño es abrir un flujo de salida con ob_start() y hacer un echo de todas ellas para despues recoger la cedena final con ob_get_contents(). Esto es así porque en el tratamiento de cadenas el factor limitante es la reserva de memoria y al crear un flujo se reservan de golpe 40K, aumentando en pedazos de 10K cuando hace falta más.
54. En las sentencias switch() ordena los casos empezando por los más frecuentes.
55. Procesar ficheros XML con expresiones regulares es más rápido que hacerlo con SAX o DOM. Atención: el uso de expresiones regulares para procesar XMl puede acortar significativamente su esperanza de vida.
56. Eliminar los comentarios o escribir en una sola linea no hace que se ejecute más rápido, lo único que consigues es que los demás te odien a muerte.
57. Usar objetos no hace que todo sea más rápido, más bien al contrario, pero utilizarlos mejora otras muchas cosas.
58. Cuanto menos (x)HTML en la salida del script, más rápido renderiza la pagina.
59. Utiliza constantes en lugar de funciones: PHP_VERSION vs. php_version(), PHP_OS vs. php_uname(), PHP_SAPI vs. php_sapi_name(), etc.
60. Si todo lo demás falla … escribe una extensión en C.

Conclusión: no prestes mucha atención a todo esto; dependiendo de la carga y la máquina, algunas optimizaciones apenas van a ser apreciables por el usuario final. Sólo con cambiar los while por do-while no va a hacer que tu programa corra como el viento, cuanto mejor conozcas tu stack de software y los entresijos de la aplicación más profundas serán las mejoras que puedas aplicar.

¿Alguien conoce alguna más?

PHP Archive es una extensión que permite desplegar aplicaciones PHP autocontenidas en un único archivo, con extensión .phar obviamente.

Esta extensión todavía no forma parte de la distribución oficial (pero esto cambiará en PHP6, sino antes) así que para instalarla hay que compilarla o utilizar PEAR/PECL, pero he encontrado problemas para hacerlo con los paquetes de Ubuntu/Debian y me consta que en otras distros ocurre lo mismo. ¿Solución? Compilar todo el stack de PHP a mano para después compilar la extensión.

Como esto es un coñazo he decidido publicar la extensión compilada y lista para utilizar (si os fiáis de mí claro):

MD5: f4e82469c7a4d98df5daa30b02b35db4

Mientras el blog ardía …

La semana pasada entró en el repositorio de PHPUnit una nueva métrica de software que sirve para detectar el índice de código duplicado de un proyecto (el típico copy&paste), así que poco a poco PHPUnit deja de ser una herramienta “sólo para tests unitarios”.

Esta nueva métrica se une al extenso abanico de las ya existentes y pueden utilizarse a modo informativo o como restricciones a la hora de programar. Para ello, PHPUnit es capaz de integrarse con otra herramienta bien conocida en el mundo Java , CruiseControl.

Algunos apuntes rápidos sobre tecnologías que hacen que este verano esté trabajando en lugar de estar tumbado bajo una palmera sorbiendo licor de un coco con sombrilla:

Xdebug

Un depurador, perfilador y analizador de trazas para PHP con posibilidad de realizar code coverage (no me atrevo a traducirlo

Lo mejor de esta herramienta son los volcados de pila y variables en memoria, una auténtica gozada después de sufrir durante años los echo, los var_dump y los printr.

El tema del perfilado de código también es bastante interesante de cara a ver dónde se pierden ciclos en los scripts. En Linux se puede ver el árbol de llamadas del código con el KCacheGrind de toda la vida (viene con KDE-devel en todas las distros); para los que sufren Windows está el port WinCacheGrind, pero ya aviso que es lento y pesado a más no poder. Para OSX ni idea, imagino que habrá un port de KCacheGrind o como mínimo se podrá utilizar la instrumentación de valgrind/callgrind a pelo, no se.

También se puede integrar con Eclipse + PDT para depurar sin salir del IDE, aunque es un poco patatero todavía.

Para instalar Xdebug lo mejor es tirar de los repositorios PEAR/PECL y compilarlo. No hay paquetes para Ubuntu ni para Debian de momento.

PHPUnit

Un framework para realizar tests unitarios de manera tan sencilla que da reparo no hacerlos

Antes utilizaba SimpleTest pero este me gusta mucho más por la versatilidad que ofrece y el rápido desarrollo. Está completamente orientado a objetos y puede funcionar conjuntamente con Xdebug para realizar unos bonitos informes de cobertura.

PHPUnit es una herramienta sobre la que se está trabajando muy activamente. Entre las cosas interesantes que se pueden hacer (a parte de lo que he dicho) quizá destacaría el mutation testing y el test para bases de datos PHPDBUnit que es un port directo del DBUnit de Java.

Estas funcionalidades no están publicadas actualmente pero los ansiosos pueden hacer un checkout del svn de PHPUnit para empezar a hackear, están en /phpunit/branches/mutation_testing y /phpunit/branches/dbunit respectivamente.

Otra herramienta increíble que puede interactuar con PHPUnit es Selenium del que ya hablé por aquí hace un tiempo. Con estas dos joyitas se puede construir un sistema de tests de aceptación completo para aplicaciones web.

Para instalar PHPUnit, lo mejor de nuevo, es tirar de Pear porque la versión que viene empaquetada en Debian/Ubuntu es bastante antigua.

Phing

¿Habeis utilizado alguna vez Apache Ant en Java? pues Phing es lo mismito pero para PHP; guarda una cierta compatibilidad con la sintáxis de Ant pero incorporando algunos targets útiles para PHP,como por ejemplo la integración con PHPUnit o el acceso a Subversion.

Tampoco es que me guste mucho utilizar XML para hacer los scripts de los despliegues … porque el XML tiende a hacer las cosas complicadas imposibles, pero para las tareas habituales no se requieren más de una docena de lineas.

Para instalarlo, más Pear.

En Trac, a la hora de introducir un nuevo ticket, le podemos asignar keywords:

Este es un campo sin valor aparente mas que para taggear tickets hasta que el otro día se me ocurrió un hack curioso: utilizar los keywords asociados a un ticket para disparar acciones como por ejemplo notificaciones por email, reconstruir la documentación, etc.

Cómo funciona

Funciona de forma similar al anterior hook que comenté, el auto cierre de tickets: responde a mensajes del estilo “changed blah blah to do this or that, fixes #34″.

Si el mensaje contiene alguna orden de cierre sobre un ticket (las ordenes son personalizables a través del array $msgClose), se pasa a ver si el ticket tiene keywords (puede tener varias separadas por comas).

En este caso se ejecutan las acciones pertinentes.

Para añadir nuevas acciones hay que mapearlas en el array $keyword2action.

En el ejemplo vemos que la keyword publish ejecuta la acción emailThis.

Por último los callbacks de las acciones tienen esta pinta:

Donde $commit es el mensaje de cierre del ticket, $description es la descripción del ticket en Trac, $url es la URL al ticket completo y su historial en Trac y por último $ticket es el número de identificación del ticket.

Qué necesito

1. Una máquina con Trac, Subversion y un servidor de correo correctamente configurados.
2. ¡El script!

En el gancho post-commit de Subversion hay que colocar las siguientes variables (si no están ya):

Problemas

• Trac debe utilizar SQLite como backend, aunque es posible utilizar MySQL modificando un par de lineas del código.
• PHP5 + PDO + SQLite, no suele estar instalado en servidores baratos.
• Si se cierra un ticket sin pasar por Subversion no funciona.

Usos

Hay algunos cambios mayores en un proyecto que por alguna razón nos interesa comunicar a los cuatro vientos cuando finalmente son implementados, bien a una lista de correo, un canal RSS, un informe para el jefe, etc. Estos tickets especiales pueden marcarse para desencadenar la acción elegida.

También es útil cuando se reporta un typo en la documentación o en los archivos de cadenas para localizar/internacionalizar. Marcando estos tickets se puede regenerar de nuevo los archivos de documentación o compilar las traducciones tan pronto como el fallo este resuelto.

¿Alguna sugerencia más? ¿Para qué lo emplearíais?