menu
Entrades a "Tutoriales"
Programar sin debugar debería estar prohibido para cualquier desarrollador que se precie. El problema es que a veces no nos lo ponen fàcil, y ese es el caso de docker en MacOS. Después de una dura batalla, hemos conseguido hacer funcionar xdebug en docker y poder debugar con PhpStorm. En este artículo os detallamos toda la configuración necesaria para poner dicho entorno en funcionamiento.
Fichero docker-compose.yml
En el lado de Docker, el contenido del fichero docker-compose.yml deberá contener lo siguiente, por debajo del bloque php – environment:
PHP_XDEBUG: 1
PHP_XDEBUG_MODE: debug,develop
PHP_IDE_CONFIG: serverName=my-ide
PHP_XDEBUG_IDEKEY: "PHPSTORM"
PHP_XDEBUG_CLIENT_HOST: host.docker.internal
PHP_XDEBUG_CLIENT_PORT: 9003
PHP_XDEBUG_REMOTE_AUTOSTART: 1
PHP_XDEBUG_REMOTE_CONNECT_BACK: 0
PHP_XDEBUG_START_WITH_REQUEST: 1
PHP_XDEBUG_IDEKEY variará en función de nuestro IDE favorito para desarrollar. En este ejemplo hemos usado PhpStorm, de ahí ese valor. Por ejemplo, para Visual Studio Code seria “VSCODE”.
En al versión 3 de xdebug se usa el puerto 9003 por defecto, mientras que en la versión 2 era el 9000. Este setting, PHP_XDEBUG_CLIENT_PORT, sería redundante, pero por la paranoia prefiero que esté presente y descartar errores por esta causa.
El próximo tres de junio se publicará la novena versión mayor de Drupal.
Históricamente, una nueva versión de este tipo no solo suponía la incorporación de una colección, a veces abrumadora, de nuevas características; si no que rompía lo que en informática denominamos la compatibilidad hacia atrás, obligado a los programadores a adaptar sus módulos y temas contribuidos y a los dueños de sitios, en la mayoría de los casos, a reconstruirlos usando la nueva versión.
Por suerte, la novena versión que se publicará en unos escasos quince días, supone un cambio en este paradigma. Actualizar el sitio de Drupal 8.9 a 9.0 será tan sencillo como actualizar de Drupal 8.8 a 8.9.
Veamos cómo se ha conseguido esto.
El problema: nuevas características vs. compatibilidad hacia atrás
Todo sistema informático, con el paso del tiempo, incorpora nuevas características e intenta mantener la compatibilidad hacia atrás. Desgraciadamente, ambos conceptos actúan como fuerzas opuestas: sistemas que se preocupen de mantener la compatibilidad hacia atrás harán casi imposible la incorporación de nuevas características y, en el caso contrario, incorporar muchas novedades hará imposible mantener la compatibilidad con paquetes antiguos.
Al trabajar en proyectos de desarrollo lo normal es contar con varios entornos en que el código se está ejecutando.
Por ejemplo, en nuestros proyectos es normal que:
- cada uno de los miembros del equipo tenga un entorno local donde escribe y prueba código,
- tengamos un entorno de integración donde las aportaciones de cada programador se unen y se prueba su correcto funcionamiento conjunto,
- exista un entorno de staging (o puesta en escena) donde los editores del sitio puedan probar las nuevas características y subir contenido de prueba, y
- haya uno o más de un entorno de producción donde está el contenido real accesible por los usuarios finales.
Estos entornos tienen un orden: local, integración, staging y producción. Solemos decir que algo está más abajo cuando está más cercano a los entornos locales y más arriba cuando está más cercano de producción.
React es un framework Javascript muy popular creado por Facebook. Permite la construcción de interfaces rápidas, bellas e interactivas, de las que enamoran a los usuarios. Drupal, por otro lado, es un CMS fantástico que permite crear sitios Web pequeños, medianos y grandes.
A veces se quiere utilizar ambos a la vez: ofrecer el sofisticado backend de Drupal y un rápido frontend basado en React.
En este artículo, repasamos varios métodos para combinar ambas tecnologías.
Headless Drupal o embedded React
La principal decisión que se debe tomar cuando se utiliza React con Drupal es si se quiere utilizar "headless Drupal" donde Drupal es solo el backend y React es la única interfaz que el usuario ve o si queremos solamente añadir React a un sitio web Drupal utilizando el sistema de plantillas de Drupal. Profundicemos:
Headless Drupal con un frontend en React
En un escenario como este, Drupal se utiliza como backend de una aplicación construida con React. Ambos sistemas están completamente separados y se comunican utilizando HTTP, con REST y GraphQL, por ejemplo.
Esta opción es la mejor si se quiere:
¿Qué es Behat?
Behat es una herramienta de BDD (Behaviour Driven Development) que se utiliza para comprobar el comportamiento de una aplicación desde el punto de vista de un final. Es muy popular el uso de esta herramienta para pruebas de automatización de casos, utilizando escenarios legibles para los humanos.
Para escribir los test se usa el lenguaje Gherkin, muy similar al Inglés, de forma que se puedan escribir los test de la forma "Teniendo en cuenta que... Entonces debería...". Se puede además extender escribiendo funciones PHP personalizadas en el archivo FeatureContest.php que se crea dentro de la carpeta bootstrap.
¿Cuando usar Behat?
Behat ayuda a cumplir con las especificaciones y requisitos del cliente porque funciona con test que describen escenarios de posibles comportamientos del usuario en la web. Estos test pueden ser creados y mantenidos por cualquier persona, ya sea un gerente de proyecto, un desarrollador o cualquier otra parte interesada en el proyecto.
Los test automatizados de Behat pueden ayudar a:
En muchas ocasiones nos encontramos peculiaridades de cada entorno que pueden causar incidencias cuando el entorno cambia, por ejemplo cuando ponemos una web en producción o cuando implementamos ciertos cambios en una web que ya está en producción, las diferencias entre el entorno que se uso para desarrollar y el entorno de producción son causa de incertidumbre, y en ocasiones pueden ser también causa de dolores de cabeza y de tiempo invertido innecesariamente. Versiones de php, motores de base de datos, apache, nginx, varnish, etc. pueden convertirse en una gran molestia si no lo tenemos en cuenta desde el principio y si no disponemos de un entorno adaptado a las peculiaridades de cada proyecto.
Recientemente hemos estado trabajando en un proyecto Drupal 8 desarrollando una funcionalidad basada en la API de Views, donde la parte central de la misma gira en torno a un gran buscador con decenas de filtros expuestos donde no todos corresponden a campos de Drupal.
Unos de los muchos requisitos de esta funcionalidad era tener la posibilidad de seleccionar de forma dinámica los campos de la entidad a mostrar en la consulta, pudiendo además indicar cuáles por defecto dentro de la propia View. Para hacer esto posible, tuvimos que desarrollar un Plugin custom de Exposed Form, del que trataremos hoy de forma básica y amena en el siguiente tutorial.
PASO 1
Creamos como siempre un módulo custom con los ficheros necesarios para dar de alta a nuestro plugin, al que llamaremos por ejemplo, my_custom_exposed_form.
Ayer tuve el placer de realizar una presentación en el Drupal&Beers, una quedada mensual organizada por Drupal.cat, comunidad catalana de Drupal.
A continuación os comparto la charla, sobre composición de páginas complejas con Paragraphs.
Paragraphs es un módulo de Drupal que utilizamos en muchos proyectos de Atenea tech (tanto en Drupal 7 como -sobretodo- en Drupal 8). Es un módulo muy recomendable para la edición de contenido complejo. Espero que esta pequeña inrtoducción os sea de utilidad y empecéis a usar Paragraphs en vuestros proyectos (¡más que recomendable!):
Cuando Tim Berners-Lee creó el World Wide Web en 1990 lo hizo pensando en una enorme biblioteca de documentos entrelazados. Por eso cuando diseñó su protocolo de comunicación (HyperText Transfer Protocol o HTTP) no se preocupó por la seguridad. Toda la información que HTTP envía es visible para cualquiera con mínimos conocimientos sobre redes.
No fue hasta unos años después cuando Netscape desarrollo HTTPS, que añadía una capa de seguridad a HTTP. Toda la información se envía encriptada. Ya es posible hacer la compra semanal, gestionar las cuentas del banco o compartir las fotos de nuestras vacaciones con los amigos del instituto.
Pero para que HTTPS funcione, debemos tener un certificado que garantice quien somos, solo así se puede crear una conexión segura. Y para garantizar que el certificado es cierto, los navegadores solo confían en los certificados creados por un número limitado de entidades.
Estas entidades certificadoras siguen un costoso proceso para garantizar que somos quien decimos ser y cobran sus honorarios proporcionalmente. Así, para tener una conexión segura, lo que tenemos que hacer es gastar nuestro dinero en un certificado. Hasta que llegó Let’s encrypt.
En la primavera de 2016 nació esta entidad certificadora avalada por una colección casi infinita de partners de casi todos los sectores de la industria. Rompe con la tradición en dos puntos: los certificados son gratuitos y el proceso para su creación automático.
El pasado 24 de noviembre realizé una charla en el Drupal & Beers sobre gestión de configuración con Drupal. En esta ocasión, comparto en el blog las diapositivas de dicha charla que espero que os sean de utilidad:
Pàgines
Categorías
- Empresa 126
- Eventos 103
- Proyectos 117
- Tutoriales 63