Sin categoría

Como Docker y buenas prácticas me permiten poner en marcha mi entorno de desarrollo en tiempo record

Deja un comentario

Mi espacio de desarrollo puede ir conmigo a cualquier parte del mundo que tenga conexión a internet (de banda ancha). Obviamente, es mejor tenerlo todo instalado, que sea arrancar y ponerse en manos a la obra. Pero ¿qué pasa si necesito levantar el entorno de desarrollo en un equipo nuevo? Ya sea porque mi equipo se haya roto, lo he perdido o simplemente esté a kilómetros de donde estoy en este momento. Aquí, tener una serie de buenas prácticas me permite levantar mi entorno de desarrollo (o el de alguien de mi equipo) en tiempo record, y marca la diferencia entre estar parado o poder recuperar el control rápidamente.

[Hoy dejaré de lado la solución de tener todo virtualizado en un servidor y tener mi IDE (editor de código) en el navegador. @TODO escribir artículo sobre entorno de desarrollo virtualizado online].

0.- Documentar todo en el README

Ya sea para recordarme a mí mismo del futuro, o para pasarle el proyecto a un tercero, este es el lugar para explicar no solo de que va el proyecto sino como ponerlo en marcha. Ahí anoto además que dependencias necesita.

Un buen README es un documento de onboarding para nuevos miembros del equipo, y ese mismo puedo ser yo dentro de unos meses. Dejar ahí unas instrucciones claras y concisas: instalar esto, en este orden, configurar estas variables…. y todo listo. Muchos pasos se pueden automatizar con scripts, pero lo que no se pueda se deja anotado ahí.

1.- Repositorios de código online.

Obviamente, lo primero de todo es tener nuestro código versionado replicado fuera de nuestro equipo. En mi caso soy de Git, y tengo mi código en un servicio con repositorios privados. Pero también serviría cualquier otro sistema de versionado en un servidor (puede ser privado) disponible desde internet.

Friendly reminder: Usar un repositorio Git no invalida tener una copia de seguridad del código.

Tener un repositorio es vital para poder continuar por donde lo dejamos, incluso con código que no está terminado y no está corriendo en ninguna parte, quizá estamos aún a medias con algo en una rama. Clonamos y a tirar millas.

Eso si, si estamos en un equipo nuevo tendremos que generar algún sistema de acceso seguro (claves SSH o tokens, mejor evitamos las contraseñas), así que necesitamos poder tener acceso al admin del repo para poder añadirlas.

2.- No depender de la configuración local: Docker

Toda la configuración del entorno debe estar virtualizada. El código se ejecuta en un entorno controlado y parametrizado aislado de la máquina que lo aloja (obviamente la máquina que lo aloja tiene que tener recursos físicos suficientes, pero nos da igual el sistema operativo).

Una buena configuración de docker-compose nos permite tener múltiples servicios que se levantan con un solo comando: docker-compose up -d

Para poder correr múltiples servicios web en una sola máquina (y acceder a ellos) uso un proxy inverso: nginx-proxy. Esto me evita configurar puertos, cada proyecto tiene sus subdominio local (hay que configuarar el hosts/etc de turno). [@TODO escribir un artículo sobre como configurarlo]

3.- Creación de la base de datos: semillas y datos de prueba.

Esta parece una tontería, pero a la larga te da la tranquilidad. Una base de datos con datos controlados que tiene la información básica para que funcione la aplicación recién instalada (usuarios por defecto, configuraciones iniciales…), y luego datos de desarrollo que simulan y cubren variedad de casos de uso.

Si eres de los que desarrolla con la tranquilidad de un test que respalde su código, seguro que esta base la tienes cubierta. Disponer de una base de datos semilla coherente te asegura que los tests son consistentes entre máquinas y desarrolladores.

Pienso en estos seeds como un «snapshot mínimo» del proyecto: una pequeña dosis de información que hace que todo funcione a la primera.

4.- Configuración de entorno centralizada: .env

La configuración de cada proyecto es un mundo, cada framework y proyecto tiene sus peculiaridades, pero poder tener un fichero de texto plano en la raíz. Ahí van parámetros particulares del entorno. Todos los frameworks con los que he trabajado siempre les pongo una manera de acceder a un dotEnv.

Dejo un fichero .env.example con todas las variables enunciadas y en ocasiones dejo incluso ya rellena ahí la configuración del entorno de desarrollo. Así, solo es copiar el fichero, renombrarlo a .env y cambiar lo que sea necesario (p.e. ciertos datos sensibles que no se pueden dejar a la vista, o datos que cambian por cada desarrollador / entorno).

Con estas prácticas, y solo dependiendo del ancho de banda (para descargar el proyecto y sus dependencias y las imágenes de docker) puedo levantar un entorno de desarrollo en minutos, en lugar de horas.

¿Que otra buena práctica puedo añadir para que todo funcione como la seda?

tips

La importancia del directorio .well-known en nuestro servidor para conectar servicios de terceros

Deja un comentario

El directorio .well-known es un estándar definido por el RFC 8615 que actúa como un directorio especial ubicado en la raíz de un sitio web, accesible como /.well-known/. Sirve para almacenar archivos de metadatos y configuraciones importantes para diversos protocolos web, como validaciones de certificados SSL, configuraciones de seguridad, autenticación (OpenID, OAuth 2.0) y otras integraciones automáticas entre servicios y aplicaciones.

Este mecanismo permite que aplicaciones, navegadores y servicios automaticen procesos de configuración, validación y descubrimiento de servicios de forma estandarizada, sin necesidad de configuración personalizada para cada caso.

Por ejemplo, aquí podemos dejar archivos como security.txt para indicar como reportar vulnerabilidades, o carpetas como /.well-known/pki-validation/ usadas para validar la propiedad de un dominio al emitir certificados SSL.

Y sin duda es un avance de limpieza frente a dejar estos ficheros en la carpeta raíz.

Usos más habituales

Los usos más comunes del directorio .well-known están ligados a la seguridad, la validación de dominio y la interoperabilidad entre aplicaciones y servicios web modernos.​

  • Validación de certificados SSL/TLS: Autoridades certificadoras (como Let’s Encrypt) solicitan archivos específicos en subcarpetas como /.well-known/acme-challenge/ o /.well-known/pki-validation/ para verificar la propiedad de un dominio antes de emitir un certificado.
  • Validación de email: SMTP Strict Transport Security puede configurar que los servodres solo acepten correos cifrados. /.well-known/mta-sts.txt
  • Archivos de políticas de seguridad: Como security.txt, donde se publica información de contacto para reportar incidentes de seguridad en el sitio, según recomendación RFC 9116.
  • Descubrimiento de servicios de identidad: Protocolos como OpenID Connect y OAuth 2.0 usan rutas como /.well-known/openid-configuration o /.well-known/oauth-authorization-server para que las aplicaciones detecten automáticamente endpoints y configuraciones relacionadas con autenticación y autorización.​
  • Integración de aplicaciones móviles: Android y Apple utilizan archivos en /.well-known/ para validar que un dominio es legítimo y permitir enlaces universales o “deep links”.​
  • Cumplimiento legal y privacidad: Algunas normativas como GDPR han motivado la publicación de información de contacto y políticas de privacidad accesibles públicamente en este directorio.​

Todos estos casos facilitan la automatización, estandarización, y seguridad de procesos web, permitiendo que diferentes servicios interactúen sin intervención manual y de manera segura.

En general, lo ideal es crear esta carpeta y ficheros reales directamente en nuestro servidor y revisar que no hay reglas (en .htaccess o similar) que redirijan el tráfico a esta ruta, impidiendo servir los ficheros.

js, tips

La mejor manera de esperar a que el DOM esté listo y poder manipularlo

Deja un comentario

Aún recuerdo mis tiempos de jQuery (si, esa librería ha sido una gran herramienta durante mucho tiempo) en que había que esperar a $(document).ready() para garantizar que el DOM y las librerías habían cargado para poder ejecutar código y que todo funcionara.

Pero cuando empezamos a poner el javascript al final del HTML (si, fuera del Header) para aliviar los tiempos de carga provocamos que en realidad no hiciera falta esperar, porque si se había cargado ese código es porque ya se había parseado todo el DOM.

Pero ¿eso quiere decir que el DOM está listo? ¿que se han cargado todos los elementos? Pues se han cargado todos los elementos renderizados en servidor, PERO actualmente hay mucho renderizado que se hace en cliente (React, Angular… )

Así que si queremos manipular el DOM, necesitamos garantizar que existe ese elemento que queremos manipular. Puede que se lance un script cuando el DOM está listo pero necesite esperar a que ese elemento esté disponible.

La solución habitual es hacer un bucle con setTimeout que hace una comprobación cada cierto tiempo y se lanza a si mismo si no encuentra el elemento para intentarlo de nuevo.

function check() {
  if (!$('#elementId').size()){
    setTimeout(check, 200);
  } else {
    // el código a ejecutar
  }
}

Y esto puede que funcione, pero no es la manera más eficiente… y con los navegadores modernos puede que falle porque, cuando la pestaña / ventana no esté en primer plano puede que ahorren recursos y no corran ese código suficientemente «rápido».

Así que toca hacer una solución moderna para navegadores modernos, que no dependa de que la pestaña esté funcionando, o de que el timeout se ejecuta a tiempo. Y la respuesta es requestAnimationFrame

Se suele usar para animaciones, garantizando 60 refrescos por segundo. Pero también se puede usar para notificar al código que está esperando.

Así que usaremos algo como:

function check() {
  if (!$('#elementId').size()){
    window.requestAnimationFrame(check);
  } else {
    // el código a ejecutar
  }
}

Y aunque en teoría podría parecer que este código se comprobaría el DOM cada 1/60 de segundo para comprobar el elemento buscado, solo se hará una vez, cuando el elemento sea renderizado.

Y así es la manera adecuada de esperar a un elemento de DOM en los navegadores modernos.

Mas info: Swizec

git

git insteadOf: Jugando con las URLs en git

Deja un comentario

Si te dedicas al desarrollo, tienes que tener algún sistema de versionado de código. Cada cambio registrado, poder hacer ramificaciones de código, integrar código de varias personas…

También puede ser que empieces a tener muchos repositorios de código, y cada uno en un servicio distinto: github, gitlab, bitbucket… o alguno en tus propios servidores.

Hay gente que lo usa para acortar urls y no tener que acordarse de / tener que teclear toda la ruta a sus repositorios.

git config --global url."https://github.com/".insteadOf "gh:"

En mi caso este mecanismo me ha resultado útil cuando las políticas de seguridad del repositorio de trabajo han cambiado de poder usar unas urls a otras (podrían también haberse dado un cambio de ruta en el servidor). Pero no era plan de cambiar todas las referencias en las dependencias, hay demasiados proyectos.

Así, es tan fácil como indicarlo algo como:

git config --global url.https://bitbucket.project-x.info/.insteadof ssh://git@project-x.info:7899/

¿Y si tienes más que referencia a la misma url? Pues toca añadir más entradas a la config de tu cliente git con –add

git config --global --add url.https://bitbucket.project-x.info/.insteadof ssh://project-x.info:7899/

Esta configuración también se puede usar por proyecto añadiendolo al .gitconfig

+ info: Graphite | Kovrinic

wordpress

WordPress: No uses camelCase para tus shortcodes

Deja un comentario

En breve: no utilices camelCase para nombres de parámetros en los shortcodes de WordPress

He estado un rato dado vueltas a un código de shortcode que estaba haciendo. Quería inyectarle un contenido para que lo usara como una propo de schema para mejorar la semántica del código. Esa prop usaba camelCase y decidí que el parámetro llevase el mismo nombre para no liarme… pero cuando capturaba el recogía el parámetro me aparacía con el valor por defecto.

function shortcode_process($atts) {
	$atts = shortcode_atts( array(
		0 => null,
		'name' => null,
		'price' => null,
		'priceCurrency' => null,
	), $atts );
}

Y es que no sabía que los atributos del shortcode de WordPress se pasan a través de la función strtolower() de PHP.

Es raro que use camelCase en PHP, suelo usar snake_case (aunque últiamente en javascript uso camelCase), pero aquí quería usar el mismo nombre que la prop, y Schema.org marca las props en camelCase. Ha sido un rato rascándome las neuronas intentando averiguar si porqué un parámetro estaba pasando correctamente y el otro se quedaba con el valor por defecto, hasta que finalmente he pensado ¿y si es por el casing?

function shortcode_process($atts) {
	$atts = shortcode_atts( array(
		0 => null,
		'name' => null,
		'price' => null,
		'pricecurrency' => null,
	), $atts );
}

Y así era, resulta que los parámetros estaban siendo ignorados porque ya no coincidían con los nombres esperados después de ser convertidos a minúsculas por la función strtolower() antes mencionada.

Así que aquí te dejo la pista para que no pierdas el tiempo que he perdido. Utiliza nombres de propiedads en minúsculas/snake_case en el array shortcode_atts().

js, tips

Chrome dev tools: Como explorar un JSON

Deja un comentario

Si te dedicas al mundo del frontend, seguramente tienes que estar consultando un API REST que te devuelve documentos en formato JSON y en ocasiones querrás comprobar que lo que recibes es lo que esperar y poder explorarlo. Vamos a a ver un par de trucos para atacar rápidamente un JSON gigante usando las Developer Tools del navegador Google Chrome (o Chromium) y facilitarte la vida.

Truco 1: Cargar en el terminal

La consola de las Developer Tools no es solo l lugar donde probar el código, también podemos hacernos.

Con las DevTools abiertas, en la pestaña Network, realizamos la petición al API REST. Entonces abriremos el documento que hemos recibido y nos iremos a la pestaña preview y veremos el JSON en todo su esplendor. Entonces, seleccionando el elemento raíz, abrimos el menú contextual (botón derecho) y elegimos «Store to global variable».

Desde ese momento tendremos una variable (en mi caso fue temp1) con la que podremos trabajar en el terminal. Podremos hacer operaciones de array o de objeto sobre sus elementos y usar el autocompletado para hacer todo el path. Si escribimos el path y damos intro recibiremos el valor de ese elemento en el árbol JSON.

Truco 2: Extraer el path a un elemento

Un caso bastante habitual es tener un elemento bastante profundo en el árbol JSON y no querer tener problemas de erratas al transcribirlo. Puedes sacar el menú contextual del elemento y

Y puedes comprobar que está correctamente escibiendo en la consola:

temp1.PATH_COPIADO

Bola Extra: Una extensión para ver JSON.

Si no quieres tener que hacer el recorrido hasta las dev tools, y quieres ver directamente el JSON al llamar a su url en el navegador de una manera manejable, te recomiendo instalar JSON Formatter.

Truco: puedes expandir y contraer ramas pulsando ctrl para que lo haga con todas las del mismo nivel.

linux

Variables de entorno por carpeta de proyecto

Deja un comentario

Tenemos un proyecto que necesitamos que tenga una serie de variables de entorno. En producción no hay problema, porque cada máquina es específica para cda proyecto y tiene sus varaibles de entorno. Pero en el entorno de desarrollo podemos tener más de un proyecto en marcha y puede que ciertas variables se repitan o pisen entre proyectos. Entonces lo que necesitamos son variables de entorno por proyecto.

Una solución maravillosamente sencilla es tener un fichero de variables de entorno que se cargue al entrar en esa carpeta. Tendrá el mismo formato que nuestro clásico .bashrc. Para ello habrá que instalar el programa direnv (y que se cargue en nuestro .bashrc).

sudo apt-get install direnv && echo "eval "$(direnv hook bash)"" >> ~/.bashrc

Y en la carpeta raíz de cada proyecto tener un fichero .envrc con las variables de entorno que necesitamos.

.gitignore global

Por limpieza, lo ideal es que este (y otros ficheros propios de nuestra máquina de desarrollo) no estén ensuciando el .gitignore particular de cada proyecto. Así que para ignorar este fichero particular del control de versiones para cada proyecto (pero solo de nuestra máquina), en lugar de ignorarlo a nivel de proyecto podemos ignorarlos a nivel global. Para ello usaremos el comando:

git config --global core.excludesfile ~/.gitignore

Al añadir un fichero .gitignore a nuestra carpeta de usuario y añadir los ficheros «.envrc».

Bola Extra: dotenv

Idealmente, en muchos proyectos javascript utilizo dotenv. Una librería que añade variables de entorno en tiempo de ejecución. Si tu proyecto no es javascript o no usa dotenv, aquí tienes otra solución.

git

Poner bonito tu perfil en Github con el README.md

Deja un comentario

Si estás metido en el mundo de la programación seguro que usas GIT como sistema de control de versiones, y la manera más cómoda de poner tener un repositorio online es usar sitios como Github (puedes tener ilimitados repositorios gratuitos si son públicos, pero tendrás que pagar si quieres tener repositorios privados), Gitlab o BitBucket. Recordemos que Github es propiead de Microsoft, aún así el código será de tu autoría y se respetará la licencia que desees compartirlo.

GitHub se ha convertido en una plataforma esencial para desarrolladores y profesionales de la programación, y tu perfil en esta plataforma es tu carta de presentación ante la comunidad. Una forma de destacar y presentarte de manera atractiva es a través de la creación de un archivo README en tu perfil de GitHub. Vamos a ver lo fácil que resulta poner bonito tu perfil de GitHub utilizando el archivo readme.md.

¿Qué es un archivo README?

Un archivo README es un archivo de texto en formato Markdown (extensión .md) que se utiliza comúnmente en proyectos de software para proporcionar información sobre el proyecto, instrucciones de instalación, documentación y otros detalles relevantes. Sin embargo, en el contexto de tu perfil de GitHub, el archivo README te permitirá compartir información sobre ti mismo con la comunidad.

Paso 1: Crear un repositorio para tu perfil

Para empezar, debes crear un repositorio con el mismo nombre que tu usuario en github. En mi caso queda algo como github.com/yondemon/yondemon. Si aún no tienes un repositorio, puedes crear uno en la web haciendo clic en el botón «+» y seleccionando «New Repository». Al usar la interfaz web ya te avisará que este es un repositorio especial que usarán para tu perfil.

Paso 2: Crear el archivo README

Ahora, debes crear un archivo con el nombre «README.md» en tu repositorio de GitHub. Atención: En el propio proceso de creación del repositorio puedes decirle que cree ya este archivo, en otros repositorios te lo rellenará con la estructura habitual de un fichero README de un proyecto, pero en este repositorio te pondrá un mensaje breve y oculto recomendaciones de texto.

Paso 3: Estructurar tu perfil README

El archivo README.md utiliza el formato Markdown para dar estilo al texto y agregar elementos como títulos, listas, enlaces e imágenes. Todo ello solamente con texto y un marcado especial a base de símbolos especiales como parénteis, corchetes y almohadillas, entre otros. Puedes utilizar una combinación de texto, imágenes y enlaces para crear una presentación visualmente atractiva de tu perfil.

Puede ser interesante incluir algunas de estas secciones en tu perfil README:

  1. «Acerca de mí»: En esta sección, puedes describir tu trabajo, intereses y experiencia en el campo de la programación. Puedes hablar sobre los lenguajes de programación que dominas, tus proyectos anteriores o cualquier otro detalle relevante que desees compartir. También puedes poner enlaces a redes sociales o foros donde pueden encontrarte.
  2. «Contribuciones destacadas»: Aquí puedes resaltar algunos de tus proyectos o contribuciones en los que te sientas orgulloso. Proporciona un breve contexto sobre cada contribución, explicando para que sirven, y por qué son significativas.
  3. «Guía para obtener ayuda»: Si estás involucrado en comunidades de programación o tienes experiencia en algún tema en particular, puedes incluir enlaces y recursos para que otros desarrolladores puedan obtener ayuda en esas comunidades.

Paso 5: Utilizar elementos de estilo y formato

Como comentaba antes, además de la estructura básica del archivo README, puedes utilizar elementos de estilo y formato para hacer que tu perfil sea más atractivo visualmente. Algunas opciones que puedes considerar incluyen:

  • Utilizar encabezados de diferentes niveles (usando #) para organizar el contenido y resaltar las secciones principales.
  • Utilizar listas con viñetas o numeradas para resumir tus habilidades o logros destacados.
  • Agregar enlaces a tu perfil de redes sociales o a otros proyectos relevantes.
  • Incorporar imágenes y capturas de pantalla relevantes para ilustrar tus proyectos o logros. (Puedes subir las imágenes al mismo repositorio).

La presentación de tu perfil de GitHub es una oportunidad para mostrar tu personalidad y habilidades a la comunidad. Experimenta con diferentes estilos y formatos para encontrar el que mejor se adapte a ti. Poner bonito tu perfil de GitHub utilizando el archivo readme.md es una excelente manera de presentarte de manera atractiva ante la comunidad de desarrolladores y el mundo en general. Aprovecha esta oportunidad para compartir información relevante sobre ti, destacar tus contribuciones y proporcionar recursos útiles. ¡Haz que tu perfil sea único y representativo de tu trabajo y pasión por la programación!

Mas información en «Github: Managing your profile README»

css

HTML: ¿Conoces el tag «METER» ?

Deja un comentario

Atentos a esta maravilla. La etiqueta <meter> (soportada por todos los navegadores) podemos describir de manera semántica cualquier cosa que se está midiendo: el estado de algo, un resultado; y el navegador lo mostrará de manera gráfica.

Con este código de Sven Wolfermann, podemos darle el estilo que queramos gracias al poder de manejar elementos gráficos en SVG y adaptarlo al típico caso de mostrar una reseña con estrellas.

Código: https://codepen.io/maddesigns/details/oQoMre/

css, tips

[WebDevTip] Forzar el refresco de CSS (y javascripts) cacheados

Deja un comentario

[Vía: Force CSS changes to “go live” immediately | Mark on WordPress]

TL;DR Un sencillo truco, cada vez que se actualiza el fichero, se le añade su fecha detrás de la interrogación. Este parametro GET no se utiliza para nada, pero al cambiar la URL el navegador no la tiene cacheada y deber refrescar ese contenido. Mientras no se cambie el fichero la URL no cambiará.

Cuando actualizas el archivo style.css de tu tema de WordPress, es posible que hayas notado que tienes que «forzar la recarga» de tu sitio en el navegador para ver los cambios. Esto se debe a que el navegador guarda una copia del CSS en caché en tu disco duro. Dependiendo de cómo esté configurado tu servidor, es posible que no verifique una nueva versión de la hoja de estilos durante un par de horas o incluso más tiempo. Incluso si fuerzas la recarga para ver los cambios, los visitantes que hayan accedido previamente a tu sitio aún podrían obtener la versión anterior del CSS. Una forma de solucionar esto es «versionar» tu archivo CSS, agregando ?v=123 al URL en el elemento de tu hoja de estilos. Sin embargo, hacer esto manualmente cada vez puede resultar tedioso, por lo que aquí te presento una manera mucho mejor de hacerlo:

<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); echo '?' . filemtime( get_stylesheet_directory() . '/style.css'); ?>" type="text/css" media="screen, projection" />

Con este código, se actualizará automáticamente la parte final ?12345678 cada vez que modifiques el archivo. ¡Boom! Ahora todos verán instantáneamente tus cambios.

Explicación del código

El código utiliza la función filemtime() para obtener la fecha de modificación del archivo style.css. Luego, se agrega esta información al URL del enlace a la hoja de estilos mediante echo '?' . filemtime( get_stylesheet_directory() . '/style.css'). Al hacerlo, se crea un nuevo valor después del signo de interrogación que cambia cada vez que se realiza una modificación en el archivo CSS.

De esta manera, cuando actualices el archivo style.css, el URL de la hoja de estilos cambiará automáticamente y el navegador del usuario solicitará la nueva versión en lugar de usar la versión en caché.

Beneficios de forzar el refresco del CSS

Al versionar el archivo CSS de esta manera, garantizas que los cambios realizados se muestren instantáneamente a los visitantes de tu sitio web. Ya no tendrás que preocuparte por los usuarios que siguen viendo la versión anterior del CSS debido a la caché del navegador. Además, si trabajas en colaboración con otros desarrolladores o si tienes un equipo de mantenimiento de tu sitio web, todos podrán ver rápidamente las actualizaciones realizadas sin tener que realizar acciones adicionales.

Forzar el refresco del CSS es una técnica muy útil para asegurarte de que los cambios que realizas en tu hoja de estilos se reflejen inmediatamente en tu sitio web. Mediante el versionado automático del archivo CSS, te aseguras de que los visitantes vean siempre la última versión y evitas problemas causados por la caché del navegador. ¡Utiliza este método y olvídate de las dificultades para ver tus cambios en tiempo real!