mercenariophp

La mayoría de los proyectos dependen de un un número amplio de librerías externas en las que apoyan su desarrollo, incluso es posible modular los proyectos en diferentes librerías para que el mantenimiento de las partes sea independiente o utilizable por otros proyectos. Así que en todo momento la información de las actualizaciones o cambios sobre estos fuentes deberá ser lo mas precisa posible. Como primera referencia se suele utilizar el número de versión, prácticamente todo el software tiene su número versión, en la forma v1.0.0, 2.3.1, v0.4.2, etc… este número de versión se suele desgranar en tres partes X.Y.Z . A través de estos índices podemos saber que ha cambiado en el software del que depende nuestro proyecto, y saber si nos va a traer problemas, o no, su actualización. Para ello se propone seguir las reglas especificadas en semver.org

ReactPHP es una librería en estado alpha que nos permite implementar programación asíncrona basada en eventos. La parte más conocida es la que se encarga de levantar un servidor HTTP básico a partir de un script PHP, sin la necesidad de leer, reinstanciar y tratar el código en cada petición. Al estar ya levantado y preparado para atender las peticiones tampoco hay necesidad de hacer el bootstrap de PHP en cada petición. Es una librería añadida a nuestro proyecto, la cual podemos instanciar para generar un bucle infinito y atender todas las Requests que lleguen a un puerto determinado de la máquina. Gracias a ReactPHP podremos dotar a nuestros proyectos con su propio script de servidor y no depender de terceros para gestionar nuestras ejecuciones, ganando así control y una enorme mejora en los tiempos de respuesta. Tal y como muestran muchos benchmarks realizados con ab parece que las peticiones atendidas pueden llegar a multiplicarse varias veces. Para poder hacer alguna prueba vamos a preparar un script para servir Slim Framework, ya tengo algunas pequeñas API’s con este framework y así aprovecho y lo utilizo para mis experimentos.

Composer es un gestor de dependencias, su principal objetivo es mantener las librerías de terceros que utilizamos en un proyecto, estas librerías pueden ser de muchos tipos, desde el core de un framework hasta una paquete que nos permita generar PDF. Con un pequeño archivo en JSON, se definen estas dependencias y las versiones a utilizar. A través de un comando, Composer descarga, actualiza o elimina todo el código fuente de cada una de estas dependencias y también hace la misma comprobación recursivamente para cada uno de los paquetes descargados. Finalmente genera un sistema de autoload que agiliza el uso de las clases externas y nos permite declarar nuestros propios namespaces para así beneficiarnos de la inclusión automática de nuestras clases.

Hace unos días comencé a refactorizar una configuración que tenia hecha para Slim framework (v3), esta permite cargar los controladores dinámicamente en función de la ruta de la petición, sin tener que declararlos previamente en el router. Ahora es un objeto tipo Factory que instancia, configura y retorna una Slim\App lista para usar. Aunque es algo más engorroso, creo que es mejor no referenciar directamente el contenedor DI dentro del controlador, ya que esta dependencia podría ser considerada un anti-pattern (Service Location). Así que añadimos un interface para el controller, que garantice la ejecución del método pasando sus dependencias como parámetros. He cambiado la forma en que implementaba el routing dinámico para hacerlo un poco más accesible, poder reutilizarlo o mejorarlo de una manera más sencilla.

[Github: English readme]

Estoy preparando un pequeña estructura de directorios para poder usar como modelo al iniciar un proyecto, estoy enganchado a Composer y adaptándome a usar Docker, por lo que ya genero todo con esto en mente y dejo los ficheros básicos preconfigurados. Todo debe estar organizado bajo un árbol de directorios claro, que nos permita clasificar y separar los diferentes archivos de configuración, dependencias, herramientas y código fuente. Habitualmente en el directorio raíz dejo los archivos relacionados con la virtualización, configuración, temporales, etc… es el nivel “máquina”, después genero una carpeta src donde vuelco todo mi código fuente, tests y carpetas de librerías externas.

Rob Allen describe en su blog la forma en que él genera los controladores en Slim3, este framework asocia las rutas con un método, clase callable, o closure para resolver la llamada. En este ejemplo inyecta una closure al contenedor, esta funciona según el patrón Factory, se encarga de resolver las dependencias y devuelve una nueva clase “Controller” a cada llamada.

Últimamente se está viendo un gran avance en librerías para el soporte del propio desarrollo en PHP, como Jigsaw, Sismo, Deployer, etc… hoy estuve haciendo algunos tests con Jigsaw, un generador de paginas estáticas, orientado a proyectos, blogs…

Para hacer un poco más rápida y fácil la generación de tests unitarios sobre un proyecto que ya tenemos en marcha lo mejor es automatizar la generación de las clases de test que vayamos a usar… En este ejemplo voy a utilizar el repositorio import-export-legacy que aun tiene mucho coverage pendiente. Suponiendo que ya tenemos una instalación válida de PHP el proceso será sencillo, descargamos los paquetes phar de PHPUnit, generamos un archivo bootstrap para inicializar el autoload de composer, generamos una configuración en xml para PHPUnit y tras esto podremos empezar a desarrollar los tests…

En www.sitepoint.com nos recuerdan un poco como funcionan los diferentes JOINS aplicables a una consulta mySQL, la verdad que en pocas ocasiones llego a salir de las INNER o LEFT/RIGHT JOINS pero esta bien tenerlo en mente para no intentar reinventar la rueda ante un caso mySQL mas complejo… 3 More Joins You Should Be Familiar With