Usar un paquete de Composer de forma local

Para probar con código PHP que irá en el futuro en un paquete de Composer podemos incluirlo en nuestra aplicación de esta forma:

  • Creamos un repositorio de Github para el paquete (esto es obligatorio para poderlo subir a Packagist).
  • Supongamos que nuestro paquete se llama karontek/bcons y que el repositorio está en /home/koas/bcons. En el fichero composer.json de la aplicación donde queramos usar ese paquete añadiremos:
"repositories": [
  {
    "type": "path",
    "url": "/home/koas/bcons"
  }
]

"require": {
  "karontek/bcons": "dev-main"
}

Virtualhost de Apache para SPA de Vue y API con PHP

<VirtualHost *:9080>
    # Vue.js Single Page Application
    DocumentRoot /var/www/app/dist
    <Directory "/var/www/app/dist">
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted

        RewriteEngine On
        RewriteBase /
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule . /index.html [L]
    </Directory>

    # PHP API
    Alias "/api" "/var/www/app/api"
    <Directory "/var/www/app/api">
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted

        RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule ^ index.php [L]
    </Directory>
</VirtualHost>

En un caso como este todas las peticiones a la API van a dominio.com/api/XXXXX

Usar nginx como proxy durante el desarrollo de aplicaciones con Vue

Estoy desarrollando bcons y el entorno de desarrollo de la aplicación web es el típico de Vue3 con Vite que abre un puerto para poderse conectar y que haga el refresco automático etc. En mi caso accedía con esta URL: http://bcons.local:4321

Pues bien, la API se ejecuta desde http://bcons.local/api y me estaba volviendo loco porque no había forma de crear las cookies desde el PHP de la API. Aunque en teoría el puerto no afecta a las cookies no conseguía que el navegador creara la cookie.

La solución es configurar nginx para que las peticiones al puerto 80 se redirijan al puerto 4321 que es donde Vite está sirviendo la app. Así quedaría el bloque de configuración (incluyendo la regla para que las peticiones a las API se ejecuten correctamente):

upstream devapp {
    server bcons.local:4321;
}

server {
  listen 80;
  listen [::]:80;
  proxy_hide_header X-Frame-Options;

  server_name bcons.local www.bcons.local;
  root /home/koas/Server/htdocs/bcons;
  index index.php index.html;

  location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.1-fpm.sock;
  }

  location /api/ {
     try_files $uri $uri/ /api/index.php?$query_string;
  }

  location / {
    proxy_pass http://devapp;
  }
}

Ahora accedo a la app de desarrollo a través de http://bcons.local (sin necesidad de especificar el puerto) y la cookie se crea sin problema.

Añadir una resolución de pantalla a un adaptador “headless”

Una forma estupenda de aprovechar una tableta antigua es utilizarla como monitor adicional, y hay un programa llamado Deskreen que nos permite hacerlo de forma sencilla.

En Linux la forma más sencilla de usarlo es comprando un adaptador HDMI o DisplayPort headless, que no es más que un pequeño dispositivo que se enchufa a una salida HDMI o DP de tu ordenador y le hace creer que tiene un monitor conectado.

En mi caso, el adaptador traía un montón de posibles resoluciones de pantalla, pero ninguna coincidía con la resoución de mi iPad (2048 x 1536), así que tuve que investigar cómo añadirla.

Primero ejecutamos xrandr para listar nuestras pantallas, en mi caso el adaptador headless aparece con el nombre HDMI-A-0.

A continuación ejecutamos este comando para obtener el modo de pantalla (puede que tengas que instalar el paquete xcvt):

cvt 2048 1536 59.97

El primer parámetro es el ancho en píxeles, el segundo el alto y el tercero la frecuencia de refresco, ese valor lo tomé de la salida de xrandr buscando la resolución más parecida a la que quería crear.

Este comando nos devuelve esto:

Modeline "2048x1536_59.97" 265.50 2048 2200 2416 2784 1536 1539 1543 1592 -hsync +vsync

Creamos el nuevo modo:

xrandr --newmode "2048x1536_59.97" 265.50 2048 2200 2416 2784 1536 1539 1543 1592 -hsync +vsync

Y se lo añadimos a nuestro adaptador:

xrandr --addmode HDMI-A-0 2048x1536_59.97

Y ahora en la aplicación de gestión de pantallas nos aparecerá para nuestra “pantalla” la nueva resolución y podremos seleccionarla. También podemos seleccionarla desde la línea de comandos:

xrandr --output HDMI-A-0 --mode 2048x1536_59.97

Si queremos hacer estos cambios permanentes crearemos un fichero .xprofile en nuestra carpeta de usuario y lo haremos ejecutable:

touch $HOME/.xprofile
chmod +x $HOME/.xprofile

Y escribiremos en él los comandos de xrandr:

xrandr --newmode "2048x1536_59.97" 265.50 2048 2200 2416 2784 1536 1539 1543 1592 -hsync +vsync

xrandr --addmode HDMI-A-0 2048x1536_59.97

xrandr --output HDMI-A-0 --mode 2048x1536_59.97

Nota: la resolución nativa de mi iPad (2048 x 1536) hacía que el texto de las ventanas que movía a ese monitor se viera muy pequeño, así que reduje la resolución a la mitad, de 2048 x 1536 a 1024 x 768. Simplemente volví a hacer todos los pasos indicados con la nueva resolución.

Por cierto, Deskreen se puede usar sin necesidad de ese adaptador headless para enviar la pantalla de una aplicación a cualquier dispositivo que tenga un navegador. Así que si no tienes el adaptador o no tienes una salida HDMI / DP disponible también puedes usarlo para mostrar en una tableta cualquier aplicación que estés ejecutando (aunque claro, no podrás controlarla con el teclado / ratón).

Montar carpetas de S3 en nuestro sistema de ficheros

Instalamos s3fs:

sudo apt install s3fs

Creamos un usuario IAM y obtenemos su Key y Secret. Con estos datos creamos un fichero de contraseñas, por ejemplo en ~/.s3Secret:

ACCESS_KEY_ID:SECRET_ACCESS_KEY
chmod 600 ~/.s3Secret

Finalmente montamos la carpeta:

s3fs nombreDelBucket /ruta/donde/queremos/montar -o passwd_file=~/.s3Secret

Depurar Android Chrome mediante wifi

A partir de creo que es la versión 11 de Android podemos enlazar un móvil con nuestro ordenador y usar las herramientas de desarrolladores para depurar páginas web usando wifi. El ordenador y el móvil deben estar conectados a la misma wifi.

Lo primero que debemos hacer es instalar la versión más reciente de adb en nuestro ordenador. A continuación activamos la depuración por wifi en las opciones de desarrollador.

Hecho esto pulsamos en la opción de enlazar mediante código PIN, que nos mostrará una dirección IP, un puerto y un código pin. Con estos datos ejecutamos el comando:

adb pair IP:PUERTO

Introducimos el código pin y nos indicará que el enlace se ha realizado correctamente. Pero aún hay que hacer un paso más:

adb connect IP:PUERTO

y en este caso el puerto es el que nos aparece en la sección principal de “Depuración por wifi” del teléfono.

Después de hacer esto nos aparecerá el teléfono al listar los dispositivos:

adb devices

Nos vamos al navegador y abrimos una pestaña con esta URL:

chrome://inspect/#devices

Y nos aparecerán las pestañas abiertas en el Chrome de nuestro móvil; desde allí podemos lanzar el inspector web.

Migrar a Vue3

Voy a ir dejando por aquí cómo migrar ciertos elementos de Vue2 a Vue3 para tenerlo todo junto en un mismo sitio hasta que me lo aprenda.

Scoped slots

Dentro del componente:

slot(name="icons" :row="scope.row")

Para acceder al slot dentro del código del componente:

import { useSlots } from "vue";
const slots = useSlots();
console.log(slots.icons);

En el padre:

template(#icons="{ row }")
  div {{ row }}

nextTick

nextTick(() => {});

Acceder a los datos de una fila de el-table

template(#default="scope")
  pre {{ scope.row }}

Emitir eventos

const emit = defineEmits(["myEvent"]);

emit("myEvent", { foo: bar });

Llamar a un método de un componente desde una referencia

Por defecto todos los métodos del componente son privados, así que hay que indicar que queremos que se pueda acceder desde fuera:

defineExpose({ nombreDelMetodo1, nombreDelMetodo2 });

SQLite y el error “attempt to write a readonly database”

Este error es la seguna vez que viene a morderme el culo, hace poco fue con nginx, que se emperraba en decir que no podía leer el fichero index.html de un bloque.

La solución en ambos casos es la misma, así que a ver si escribiéndola me la consigo aprender: no basta con tener permisos en el propio fichero, la carpeta que los contiene tiene que tener el permiso de escritura.

Edición de cinco minutos después: acabo de caer en la cuenta de que en las instrucciones de una clase que subí a Github hace cinco años (phpLoginBlacklist) especifico claramente:

 It is recommended to provide a path outside the web document root (remember to give write permissions on that folder to your web server user).

Así que queda demostrado que en lo referente al sistema de ficheros de Linux mi memoria es equivalente a la del pez Dory. 🤦‍♂️