La idea es sencilla, poder desplegar un proyecto que tienes en un repositorio de Gitlab, en este caso un proyecto de Drupal, en un servidor gestionado mediante Cpanels y que no tenemos acceso vía SSH, lo que sería un servidor compartido de toda la vida.

Paso 1

Lo primero que tenemos que hacer es crear en el servidor con Cpanels el proyecto, la cuenta FTP para acceder al proyecto.

Paso 2

Lo segundo es dar de alta un proyecto en Gitlab, no me voy a parar a explicar esto, aquí os dejo un vídeo donde se explica como hacerlo, únicamente que para este ejemplo he creado una rama devel que es con la que hago todo, obviamente se puede cambiar por cualquier otra rama.

Paso 3

Aquí os dejo también como montar un Pipleline en Gitlab, luego entraré yo al detalle, pero como "entrante" viene bien si no conoces como funciona.

Lo importante en este caso es la configuración de las variables que vamos a usar en el pipeline, que son los valores para conectarnos vía FTP (obviamente tenemos que haber creado un proyecto en el servidor de CPanels, y tener una cuenta de FTP para acceder a los directorios de ese proyecto).

En el menú lateral izquierdo del proyecto en Gitlab accedemos a Settings > CD/CI

Image

En la página que se carga expandimos las opciones de variables:

Image

Creamos las variables en el botón Add variable:

El otro día Iban Nieto publicaba un alegato ( https://lnkd.in/gUXRy_tk ) sobre el valor de las certificaciones, sus palabras me recordaron la frase "la potencia sin control no sirve de nada" convertidas en "el conocimiento sin experiencia no tiene valor".

Yo pienso parecido, es decir, el papel lo soporta todo, y se puede pintar todo, pero cuando un proyecto se sale del papel la cosa se complica y mucho, pero eso no quiere decir que una persona certificada no sepa, quiere decir que necesita aprender, coger experiencia trabajando, soy de la opinión de que antes de certificarte tendrías que trabajar durante un tiempo para que cuando te saques la certificación por un lado puedas apoyarte en el conocimiento que tienes y por otro lado depurar tu experiencia (no nos pensemos que por tener 10 años de experiencia lo hacemos todo bien)

Por otro lado, otra de las cosas que no entiendo es que en este mundo en el que esta toda la información en la red muchas certificaciones son meros ejercicios de memoria en los que lo realmente importante es tu capacidad de memorización por encima de otras cosas.

Una de las cosas buenas que tienen las comunidades de FLOSS es que una persona que participa en un proyecto seguramente o tendrá commits, o módulos/plugins compartidos, habrá respondido en Stack Overflow, o habrá dado charlas/cursos en la comunidad.

Así que a la hora de valorar a una persona habría que mirar:

• Experiencia.
• Certificaciones/cursos.
• Si ha dado charlas/cursos (y se pueden ver por Internet).
• Si ha compartido código (commits, Stack Overflow, módulos/plugins de proyectos de FLOSS, repositorios de proyectos personales).

Y si alguien viene con aires por tener una certificación pero nada de experiencia lo mejor que se puede hacer es darle una oportunidad para que demuestre su capacidad de trabajo y a la vez ayudarle a quitarse esos aires.

pd: Esto lo escribe alguien que se esta preparando una certificación 😅 .

El otro día vi en un vídeo de programación el símbolo ≠ y me dije "a cómo lo puedo poner en VSCode", en realidad el símbolo ≠ se corresponde o con != o con !==, así que me puse a buscar como tenerlo en VSCode, se ve mejor con el símbolo aunque hayas escrito realmente !=.

Se tiene que instalar la fuente Fire Code.

sudo apt update && \
sudo apt install fonts-firacode

Una vez instalada en el archivo settings.json tenemos que añadir las siguientes líneas de código:

"editor.fontFamily": "Fira Code",
"editor.fontLigatures": true,
"editor.fontWeight": "500" // Regular,

Y el código se visualizará en VSCode de la siguiente manera. 

Image

Por todos es sabido que Js y yo somos vecinos pero ni hablamos del tiempo en el ascensor, algún día de estos tendremos que romper el hielo, y parece que esto es lo que en cierta forma ha ocurrido estos días.

Por otro lado, buscando sobre como realizar una llamada asíncrona no he encontrado nada, esto no quiere decir que no exista, puede ser que no haya realizado las preguntas correctas.

Y ahora, vamos con el agradecimiento, primero a Macarena Jiménez por sus recomendaciones de lecturas sobre async await, y javascript asíncrono, a Carlos Azaustre porque gracias a un vídeo suyo de youtube (Este) conseguí dar un pasito más en lo que estaba buscando, y a Tania Rascia porque esta entrada de su blog me termino de abrir el cielo.

Vamos a la chicha, imaginemos que tenemos un botón y cuando le pinchamos recuperamos información vía API ya sea de nuestro Drupal o de otra fuente, la cuestión (para los nóveles como yo en js) es que js es asíncrono y en vez de esperar a que se realice la llamada y se reciba la información, el código se sigue ejecutando, esto supone que puedes haber ejecutado todo tu código pero que no hayas terminado de recibir y procesar la llamada, por eso en js existen las promesas.

Vamos al código para entenderlo mejor.

// Nuestra petición ajax.

      function ajaxCall() {
        return new Promise((resolve, reject)=>{
          $.ajax({
            url: apiPath,
            type: 'GET',
            success: function(data) {
              resolve(data);
            },
            error: function (error) {
              reject(error);
            }
          })
        });
      }

Como explica Carlos en su vídeo y Tania en su post lo importante es que tenemos que devolver una promesa que es un tipo de objeto de js.

En mi caso a diferencia de la propuesta de Carlos o de Tania yo he usado $.when de jQuery para asegurarme de tener los datos de la llamada de Ajax antes de continuar.

function ejecutar(){
        $.when(ajaxCall()).done(function(data){
        // our code
       }
}

Por último llamamos a la función ejecutar en un evento on.

$(".audiofield-player audio").on("play", function () {
    let audioData = $(this).parents('.audiofield-player').attr('data-file');
    ejecutar();
});

Vamos por partes, cuando trabajamos con un editor de código en PHP deberíamos usar XDebug para depurar código, pero no siempre es así y a veces usamos funciones de depuración, en Drupal tenemos funciones propias `ddl()` del módulo devel debug log, `dpm`, o las funciones nativas de php `var_dump` o `print_r`, etc...

Si se nos cuela alguna de estas funciones se puede liar, desde errores al invocar una función que no existe en producción* hasta que salga todo el output de depuración a un cliente.

Para evitar este tipo de errores podemos usar PHPStan, en este caso y para ello necesitamos este complemento de PHPStan: https://github.com/spaze/phpstan-disallowed-calls 

Añadimos esta configuración en archivo php.neon

parameters:
    disallowedMethodCalls:
        -
            method: 'PotentiallyDangerous\Logger::log()'
            message: 'use our own logger instead'
        -
            method: 'Redis::connect()'
            message: 'use our own Redis instead'

    disallowedStaticCalls:
        -
            method: 'PotentiallyDangerous\Debugger::log()'
            message: 'use our own logger instead'

    disallowedFunctionCalls:
        -
            function: 'var_dump()'
            message: 'use logger instead'
        -
            function: 'print_r()'
            message: 'use logger instead'

    disallowedConstants:
        -
            constant: 'DATE_ISO8601'
            message: 'use DATE_ATOM instead'
        -
            class: 'DateTimeInterface'
            constant: 'ISO8601'
            message: 'use DateTimeInterface::ATOM instead'

    disallowedNamespaces:
        -
            namespace: 'Symfony\Component\HttpFoundation\RequestStack'
            message: 'pass Request via controller instead'
            allowIn:
                - tests/*
        -
            namespace: 'Assert\*'
            message: 'use Webmozart\Assert instead'

Disfrutadlo.

* Composer permite instalar dependencias en los entornos de desarrollo y que no se instalen en los entornos de producción `composer install XXX/XXXX --dev`

Con las últimas versiones de PHP 7.4 se ha cambiado de versión también en Xdebug, ahora las últimas versiones de php 7.4 y 8.x tiene Xdebug 3.x, y trae varios cambios respecto a la versión 2.x, vamos a ver como configurar el contenedor de Wodby 4 Drupal y el editor VSCode para poder depurar nuestro código.

Lo primero, en el archivo docker-compose.override.yml vamos a descomentar las siguientes opciones:

  php:
    environment:
#      SSH_AUTH_SOCK: /ssh-agent
#      # Read instructions at https://wodby.com/docs/stacks/php/local/#xdebug
      PHP_XDEBUG: 1
      PHP_XDEBUG_MODE: debug
#      PHP_IDE_CONFIG: serverName=my-ide
#      PHP_XDEBUG_IDEKEY: "my-ide"
#      PHP_XDEBUG_CLIENT_HOST: host.docker.internal # Docker 18.03+ Mac/Win
      PHP_XDEBUG_CLIENT_HOST: 172.17.0.1 # Linux
#      PHP_XDEBUG_CLIENT_HOST: 10.254.254.254 # macOS, Docker < 18.03
#      PHP_XDEBUG_CLIENT_HOST: 10.0.75.1 # Windows, Docker < 18.03
#      PHP_XDEBUG_LOG: /tmp/php-xdebug.log
      PHP_XDEBUG_REMOTE_AUTOSTART: 1
      PHP_XDEBUG_DEFAULT_ENABLE: 1
      PHP_XDEBUG_REMOTE_CONNECT_BACK: 0

Tenemos que regenerar el contenidor ejecutando: 

docker-compose up --build

Una vez configurado el contenedor tenemos que instalar el plugin de Xdebug para VScode, existen varios plugins de Xdebug para VSCode, yo he instado el creado por Felix Becker, tiene más de 4 millones de descargas, al instalarlo aparece en la barra de iconos de VSCode de la izquierda el icono de play/triangulo y un escarabajo..

Image

Al pinchar en el icono de Xdebug muestra el siguiente texto:

Image

Pincha en el enlace create a launch.json file, del listado de opciones del desplegable que se muestra seleccionamos PHP, y nos creará un archivo con el siguiente texto:

CodeSniffer es un script de PHP5 que analiza código PHP para detectar violaciones de un conjunto definido de normas de codificación. Analiza el código fuente para ver si cumple o no con un estándar, ya sea Zend, Pear o uno personalizado.

Junta de Andalucía

CodeSniffer es una herramienta muy sencilla de usar y con uan instalación muy simple que permitirá mantener los estándares de codificación de nuestros proyectos.
La inslatación es muy sencillo, lo primero comprobamos que tengamos instalado CodeSniffer 

phpcs -i

Tiene que devolver algo parecido a esta salidad, no exactamente la misma ya que yo ya tengo instalada los estándares de Drupal:

The installed coding standards are Zend, PSR1, PSR12, Squiz, PEAR, MySource, PSR2, Drupal, DrupalPractice and VariableAnalysis

Si no tenemos instalado CodeSniffer lo instalamos:

composer require --dev drupal/core-dev

Y comprobamos que ahora si tengamos instalado el CodeSniffer.

Una vez instalado tenemos que instalar los estándares de código de Drupal:

composer require --dev dealerdirect/phpcodesniffer-composer-installer

Y ya tendríamos instalado lo básico que usar esta herramienta.

Para usar el analizador de CodeSniffer lo ejecutamos de la siguiente manera:

phpcs --standard=Drupal --extensions=php,module web/modules/contrib/

Con esta orden o nos indica que esta todo bien o nos devolverá un informe como el siguiente:

Vamos a ver esta magnífica unión para tener una web estática (html, css, y js) de forma rápida y sencilla.

Gitlab es una saas que tiene varios servicios, entre ellos ofrece la posibilidad de alojar páginas estáticas de forma sencilla, para hacerlo nos tenemos que fijar en esta sección de la documentación de Gitlab: User and Group website examples, y también en esta otra sección de la documentación de Gitlab: Specific configuration options for Pages.

Por otro lado vamos a usar Tome, que es un módulo de Drupal 8||9 que permite exportar el contenido de nuestra página web a contenido estático, la documentación de Tome esta aquí.

Ahora vamos a la miga de todo esto (en realidad es muy sencillo), para casar Tome con Gitlab Pages, tenemos que entender una cosa, tenemos que definir en Drupal una carpeta donde Tome se encargará de guardar todo el contenido estático, por seguridad y organización en la carpeta donde tenemos los archivos devueltos por Tome no tenemos ni el directorio .git, ni los archivos .gitignore, ni .gitlab-ci.yml. Yo lo que he hecho es crear un directorio llamado public_tome, y dentro de él otro llamado html, es este segundo directorio el que guarda todos los archivos generados por Tome, mientras que dentro de public_tome guardamos todo,  el directorio html sería como el docment_root y el resto de elementos son los que queda fuera del document_root.

Image

Con esta estructura ya construida editamos el archivo de configuración (settings.php o settings.local.php) y añadimos lo siguiente:

$settings['tome_static_directory'] = '../public_tome/html';

Con esta configuración Tome despliega los archivos en la ruta que queremos.

El siguiente paso es configurar el archivo gitlab-ci.yml, este archivo es un archivo de configuración de pipeline que nos permite indicar (de forma sencilla) que queremos hacer durante el pipeline, lo importante para nosotros es la parte de script que es donde indicaremos que parte queremos copiar al servidor de estáticos de Gitlab.

Vamos a ser sinceros, nadie se esperaba que un datacenter OVH ardiese quemando todo, ni ellos ni nosotros, tampoco quiero cortar cabezas, prefiero que OVH haya aprendido de sus errores y haga todo lo posible para que estos errores no vuelvan a ocurrir.

Por otro lado, no tenemos que llevarnos las manos a la cabeza diciendo que OVH no son profesionales, son unos inútiles, etc, o no al menos hasta que sepamos (si algún dia sabemos) que ha pasado, porque otra catástrofe parecida ocurría en 2011 cuando el datacenter de Amazon en Irlanda dejaba de funcionar al caer un rayo.

Image

Y si preguntamos a la gente de sistemas descubrimos que desastres como estos han ido ocurriendo a lo largo de la historia, recuerdo uno que ocurrió hace muchos años en un datacenter en EEUU, no recuerdo cual fue el problema, si la solución y fue volcar a cintas de backup de HP y traslada dichas cintas en furgoneta a otro datacenter, como esta existen más historias, y como parece que estamos condenados a que ocurran vamos a ver varios "trucos" para evitar que esto pase.