mercenariophp

Actualmente se considera que mantener los parámetros sensibles de configuración, como los datos de conexión a base de datos, la key de una API, etc.. en un fichero de configuración que va a ser leído por la aplicación, como algo inseguro. El camino más fiable para poder disponer de esta información será través de las variables de entorno. El propio autor menciona la sección relativa a la configuración de The Twelve Factor App, una metodología ampliamente aceptada para el desarrollo de aplicaciones. El fichero finalmente se puede filtrar de alguna manera, mientras que las variables de entorno al estar solo presentes en la sesión de la ejecución, no. El servidor se puede parametrizar para que estas no sean propagadas arbitrariamente entre los subprocesos que se deriven del principal.

Para no tener que preocuparnos de esta configuración en los entornos de desarrollo, la librería PHP dotenv se encargará de leer un fichero donde recogerá los valores de estas variables y las inyectará en los arrays $_ENV y $_SERVER también las hará accesibles a través de la function getenv(). De esa manera podremos acceder a estos valores como en producción.

Marcho de vacaciones, debería haber publicado ya pero no me da el tiempo… cambio de trabajo, vacaciones… Nos vemos en una semana, he creado un repo donde dejaros los ejemplos de como debería quedar el código del tutorial de symfony3 tras cada post… solo hay que encontrar la release con el nombre del tutorial, espero que os sea de ayuda. Pronto tendré todos los posts cubiertos.

Releases Turorial Symfony3

Hasta pronto !!

Cuando en una clase necesitamos pasar múltiples datos, ya sea como entrada (parámetros) o como salida (retorno) se tiende a utilizar arrays. Dada su sencillez de manejo y adaptabilidad se utilizan para contener estos valores que son pasados de método a método, o incluso, de clase a clase. Esto hace que el código sea menos estructurado, más difícil de testear y sus errores menos trazables. Estos meses he podido leer varios argumentos a favor del uso de objetos de datos, que conceptualmente, podemos aproximarlos a la implementación de Value Object. Según la Wikipedia es un pequeño objeto que no es identificado por su clase en si, si no por su equidad, dos value object son iguales cuando contienen los mismos valores (==), no cuando son el mismo objeto (===), su cometido es mantener los datos inmutables para su transporte entre las piezas de la lógica. En realidad es uno de los elementos propios de diseño para Domain Driven Development, creo que podemos abstraer algun concepto de su implementación, como la inmutabilidad, para mejorar un poco lo que hacemos. Quizás el concepto sea muy estricto, solo lo voy a utilizar como referente, pero se acerca mucho al sentido de lo que me gustaría implementar.

Los bundles representan la modularidad de Symfony, en otros sistemas se denominaría plugin, es parecido, incluso mejor. En symfony todo es un bundle, desde las funcionalidades del propio core hasta el código de nuestras aplicaciones. Es fácil implementar nuevas features empaquetadas en bundles third-party o incluso redistribuir nuestro propio código, simplifican enormemente la tarea de escoger y mantener las funcionalidades que queremos implementar en nuestras aplicaciones.

Hoy toca algo más liviano, los tutoriales de Symfony han sido bastante extensos, no penséis que han acabado, pero voy a intentar llenar un poco el hueco entre ellos… Mientras escribía, he leído un post de Ye Tian para weebly en el que hablan de esta librería, maennchen/ZipStream-PHP. Es una librería que nos permite agregar varios archivos a un comprimido Zip/Tar para su descarga de manera muy sencilla. Plantean un caso bastante simple, en el que vuelcan el contenido de ficheros a variables para ser enviados a descarga, esta librería los comprime en zip/tar y transmite al cliente. Viendo el repositorio de origen entiendo que es posible hacerlo sin tener que consumir memoria con un proceso intermedio. Además es posible empaquetar múltiples ficheros a este comprimido y facilitar en una única descarga todos los elementos que deseemos. Tras las primeras pruebas he comprobado que la librería presenta algunas issues, de manera que el soporte para grandes ficheros (para mi lo más interesante) queda inutilizado. Al hacer stat sobre ficheros de más de dos Gigas parece que se calcula mal el tamaño y lo trata como un archivo pequeño, intentando meterlo en memoria. En Github pude comprobar que no solo falla el stat, si no que la propia compresión Zip tampoco soporta volúmenes de más de 2Gb. Siguiendo los comentarios pude llegar a este “fork” de la herramienta, barracudanetworks/ArchiveStream-php, que si es capaz de realizar la tarea para todos los tamaños de fichero necesarios. Eso si, para los archivos muy grandes no realiza compresión, si no que los almacena sin comprimir en el mismo paquete.

Desde el punto en que acabamos el último día vamos a implementar la base de datos que vamos a necesitar para gestionar nuestras entidades. Como primer desarrollo podemos destacar la necesidad de tener un pequeño blog, que, al acceder a la aplicación informe a nuestros usuarios de los últimos cambios o de las noticias relevantes. De paso aprovecharé para ver la implementación de los usos más cotidianos de acceso a la BD. No esperaba hacer entradas tan largas pero la verdad que a poco que te metes Symfony y Doctrine se llevan tu tiempo, tienen una curva de aprendizaje pronunciada aunque bastante fácil de seguir, espero que no se os haga muy denso…

Continuamos con la serie sobre Symfony, esta vez vamos a tocar el tema de los templates. Con el metalenguaje Twig y atendiendo al estándar de tres niveles propuesto por Symfony, vamos a implementar un sistema de plantillas que nos permita utilizar un framework cliente HTML (responsive), Bootstrap, como salida de nuestras aplicaciones. Quizás sería más sencillo si el HTML fuese maquetado con funciones PHP nativas, pero sea como sea, es cierto que este concepto aleja la representación de la información de la lógica de negocio, poniéndolos en dos capas totalmente separadas. Además a día de hoy los sistemas de plantillas como smarty o twig hacen uso de estrategias que minimizan el impacto de esta capa sobre los proyectos, como compilar las plantillas a PHP nativo de manera transparente cada vez que se encuentra un cambio en una de ellas. La idea es crear un Layout, una plantilla global con la estructura básica de la página y con la inicialización del framework cliente, en ella inyectaremos los diferentes apartados que iremos creando para nuestra web.

Symfony es uno de los frameworks más utilizados, versátiles y potentes del mercado. Sus componentes como el gestor de plantillas Twig, su ORM/DBAL Doctrine o su firme acogida a los estandares le han hecho merecedor de una posición privilegiada entre las opciones de las grandes empresas. Está tras plataformas tan potentes como phpBB, drupal o blackfire. Tiempo atrás había hecho algún experimento para ver como funcionaba, pero a día de hoy estoy desactualizado. Voy a desarrollar una pequeña aplicación para tener una base desde la que iniciar un proyecto orientado a continuous-delivery, y así familiarizarme con su estructura y forma de trabajo. He hecho bases parecidas en CakePHP y trabajado con Zend, aunque en este último no llegué nunca a ver el CRUD generator. Los resultados son muy buenos, estaba especialmente contento con CakePHP, a ver que puedo sacar de Symfony.

A lo largo de varios posts generaré una aplicación esqueleto que implementará un control de usuarios (ACL), un sistema de menú, traducciones, los interfaces de estos sistemas y las plantillas necesarias para conformar un layout. Al comenzar un nuevo desarrollo nos quitaremos de encima la primera carga de trabajo que es montar la base. Con muy poco esfuerzo conseguiremos levantar una nueva instancia de aplicación para mostrar, y ganaremos tiempo para desarrollar las primeras pantallas de gestión de básicos. Hay que recordar que lo que no esta en producción no tiene valor, de manera que cuanto antes tengamos partes funcionales en producción antes empezaremos a generar.

No estaba muy contento con el código de la librería reactphp-slim, parecía poco elegante. Así que me he puesto manos a la obra y he decidido cambiar un poco la forma en que trabaja, de paso terminar de añadir cosas que faltaban. He generado un objeto Server encargado de setear los callbacks a ReactPHP para que haga la llamada al método process de la aplicación basada en Slim Framework. He generado dos clases estáticas encargadas del paso de datos entre los objetos request/response de ambos frameworks, siendo el objeto Server el pegamento de todo el paquete. Él se encarga de recoger la request, del arranque de la aplicación y de poblar la response, ocultando las llamadas que nosotros antes implementábamos a mano.

Atom es un proyecto propio de los creadores de Github para desarrollar un editor de código abierto y hackeable hasta el núcleo. Es una variante del navegador Chromiun especializada en la escritura de código. Muchos desarrolladores han ido generando packages para el desarrollo, convirtiendo este versátil editor en un IDE completo. He estado desarrollando con él dos meses este verano, la verdad que la impresión es muy buena. Aunque no sé si el rendimiento de mi vieja máquina esta llegando a su límite o si realmente este editor, con todos los packages necesarios, precisa una maquina muy, muy potente.