Hoy les traigo otro tutorial sobre Symfony 4 y Symfony Flex. Siguiendo con la puesta al día que llevo con Symfony 4, hoy llego a cómo navegar por las páginas web. Es decir, los fundamentos de cómo utilizar el DomCrawler, el BrowserKit y el CssSelector de Symfony. Esto puede servir para dos cosas. La primera utilidad es para comprobar que el proyecto en el que estamos trabajando funciona como debe hacer. Podemos automatizar pruebas funcionales navegando por el proyecto, comprobando que los resultados son los esperados, mientras que desarrollamos y antes de que llegue a producción ningún fallo. La segunda utilidad es para navegar por páginas web remotas que estén en servidores remotos, no en local. Quizá necesitamos hacer comprobaciones en producción, o puede que necesitemos obtener contenidos, información relevante, o ficheros remotos alojados en páginas web mediante el protocolo HTTP que necesitemos recoger por alguna razón. És decir, la segunda utilidad es para conectar tu proyecto con sistemas informaticos remotos mediante el protocolo HTTP.
programación
Siguiendo con la puesta al día que llevo con Symfony 4 y Flex, he llegado a los eventos. En el proceso de una petición HTTP al servidor, en Symfony ocurren muchas cosas. Durante ese proceso, se van ejecutando una serie de tareas en orden. A la vez que se procesan esas tareas, se van disparando una serie de señales. Estan señales definen los eventos. Y a su vez podemos engancharnos a estas señales para personalizar el funcionamiento de la aplicación web. Es decir, cuando un navegador hace una petición a un proyecto web Symfony, éste la recibe con el fichero public/index.php y comienza la ejecución de todo el framework junto con todo lo que hayamos construido, además de todos los componentes extra que le hayamos instalado. Ésta ejecución se hace en perfecta armonía, es una buena forma de comunicar componentes de Symfony entre sí, con los nuevos componentes que hayamos instalado, o para personalizar el comportamiento de nuestra aplicación.
Hoy traigo un pequeño CODEKATA sobre una consulta que me ha hecho un lector. Se trata de unos códigos fuentes en Symfony 4 para subir ficheros al servidor, pero sin usar ningún componente extra en el proyecto. Se trata de unas pocas modificaciones que le he hecho al código fuente de ejemplo de la documentación oficial. Así el código dejará de chequear la extensión, el mime type del fichero, y además de que no renombra los ficheros con un identificador único. Esto puede tener doble filo porque puedes acabar machacando los ficheros en nuevas subidas, pero siempre se le puede añadir después la lógica necesaria para comprobar si el fichero ya existía.. 😉
Continuando con un post anterior sobre mostrar tablas de datos interactivas, traigo hoy otro CODE-KATA, hecho en Symfony 4 para probar el Datatables más a fondo. En aquel post empecé a testear el Datatables con pocos datos. Datatables es un plugin de jQuery con el que en poco tiempo, listas, ordenas y filtras tablas de datos de forma muy profesional. Ahora estoy probando cómo funciona sobre un proyecto con ingentes cantidades de datos, en concreto con una tabla con 622,001 registros. Llegado a éste extremo, no puedes cargar el 100% de los datos en el servidor, enviarlos al navegador, y pintarlos. Si lo haces, el navegador se sobrecargará, no podrá pintar la tabla, o irá muy muy lento.
Ya estoy de nuevo por aquí compartiendo una verdadera joya del software, el Datatables. Esta es una herramienta para desarrollo frontend, que mediante Javascript, crea unas tablas de datos muy profesionales para tus proyectos en muy poco tiempo. Se trata de un plugin de jQuery, que le da vitaminas a la presentación de datos en el navegador del cliente. Javascript actúa en la parte de frontend, es decir, tenemos que enviarle al navegador el HTML, CSS y Javascript con el Datatable configurado. Entonces, en el navegador del cliente, mediante Javascript, se regenerará el contenido web de la tabla para hacer los listados, ordenados y filtrados de la tabla de datos.
Con este post vengo a hacer una crítica sobre los estereotipos, en cómo se nos clasifica a los programadores: programador frontend vs backend. Es una especie de alarma, un grito al cielo como programador, una explicación de porqué subestimar el área de programación nos puede traer una cantidad ingente de problemas. Quizá este post levanta ampollas entre algunos gestores de proyectos web, pero creo que compartir experiencias a todos nos enriquece. ¡Ojo! que no hablo de gestores de proyectos, sino de gestores de proyectos web.
Hoy traigo un pequeño CODE-KATA en PHP para iniciar el crawleo de una página web. Se trata de un pequeño script en PHP con el que listar lo que llamamos assets de una página.
Otra de las mejores cosas que tiene Symfony es el manejo y creación de los formularios. Podríamos seguir creando formularios a la antigua, mediante HTML, construyendo poco a poco dichos formularios. Pero si quieres ser realmente productivo construyendo aplicaciones que gestionan mucha información, interactuando con los usuarios, deberías de usar ésta herramienta y aprovechar lo que Symfony nos ofrece.
Continuando con la actualización a Symfony 4, repasando de parte a parte todas las mejoras que nos trae ésta nueva versión, llegamos al contenedor de servicios. Ésto es la madre del cordero de Symfony, tenemos un contenedor de servicios, muy rápido, en donde vamos a organizar nuestra aplicación web lo mejor posible.
Un lector me ha escrito consultando sobre un post algo antiguo, sobre cómo poner un sencillo mensaje de cookies en una web. La verdad es que no me he explicado muy bien en aquel post, los navegadores han cambiado durante estos últimos años, Javascript también.. así que aquí estoy compartiendo otro mensaje de aceptar cookies más actual. Este mensaje de aceptar cookies es una actualización de aquel antiguo que vengo usando en nuevos proyectos. Es un mensaje hecho artesanalmente que puedes copiar y pegar para tu web. El único requisito que tiene es que necesitas usar la librería de jQuery para que funcione. jQuery hoy día es como un estándar, hace tan bien su trabajo de acceder al DOM de las páginas web, que cómo no usarlo en todos los proyectos.
¡Hola de nuevo! Llevo unos días muy ajetreado y no he tenido tiempo de escribir nada en el blog, así que aquí estoy compartiendo de nuevo un pequeño HOWTO que me está ayudando mucho en el día a día. Se trata de un pequeño script en Shell Script que automatiza el despliegue en servidor de una aplicación web hecha con Symfony 4. En Symfony 4 ha cambiado toda la estructura de directorios, así que para tenerlo todo bien controlado y evitar fallos intermitentes, esta es una de la cosas a automatizar. No es plan que cada vez que queramos hacer un despliegue en producción o en el área de pruebas tengamos que entrar al servidor, descargar la última versión, refrescar archivos temporales, etc..
Continuando con el repaso de Symfony 4, Symfony Flex, sigo con las configuraciones y entornos de ejecución. Como buena estrategia de desarrollo, tenemos que tener presente el establecer varios entornos en los que vamos a trabajar en los proyectos sobre Symony. Es decir, por defecto, Symfony te invita a usar 3 entornos: Desarrollo, cuyo nombre en clave es dev, del inglés develop. Pruebas, cuyo nombre es test, que podemos correr en local o en un entorno con CI y CD. Producción, con nombre en clave prod, que será en el servidor en Internet, aunque podemos simularlo en local también.