Forem: Altaskur

¿Por dónde empezarías un proyecto? No, no es solo por la lógica

Altaskur — Mon, 28 Jul 2025 22:20:55 +0000

Hace unos días lancé una pregunta básica en un directo de Twitch: ¿Por dónde empezarías un proyecto? Me sorprendió la variedad de respuestas, así que decidí llevar la discusión a mis redes sociales para analizarla más a fondo.

Me llevé una amarga sorpresa: prácticamente había unanimidad, y esto no suele ser una buena señal.

Los resultados fueron bastante sorprendentes. De hecho, la mayoría de las respuestas coincidieron en algo que, para mí, fue una alarma.

✋ Ojo: esto no se trata de decirte que estás haciendo las cosas mal, sino de promover y defender la variedad de ideas y enfoques. Abrir la mente a otras formas de empezar un proyecto es una forma de enriquecer nuestro background y crecer profesionalmente.

En nuestro sector, nada está escrito en piedra y no hay verdades absolutas, así que ver que no hay confrontación de ideas no es precisamente buena señal.

Vamos a ver cómo se distribuyen las respuestas:

Análisis de la encuesta

La pregunta era sencilla: ¿por dónde empezarías un proyecto? Las respuestas:

A) Diseño

B) Lógica

C) UX - Experiencia de usuario

Déjame en comentarios tu respuesta, luego sigues leyendo.

Resultados de Instagram

Diseño → 10%

Lógica / funcionalidad → 80%

UX → 10%

Resultados de LinkedIn

Diseño → 8%

Lógica / funcionalidad → 69%

UX → 23%

Resultado final

Los resultados finales mostraron una clara preferencia por la lógica y funcionalidad, como se puede ver en las encuestas. Pero, ¿por qué? ¿Es esto realmente lo más importante al comenzar un proyecto?

Esto despertó una alarma dentro de mí, esperaba una serie de confrontaciones entre lógica vs UX vs UI.

Decidí investigar un poco más sobre mi audiencia. Gracias a las métricas de LinkedIn, descubrí que más del 48 % son personas sin experiencia, y otro 34 % son junior developers.

Lo siento, tenemos que hablar

Durante los estudios nos enfocan —y nos enfocamos— en sacar los ejercicios de tal manera que cumplan con la tarea o el examen. Y dado que estamos estudiando y debe poder ser evaluado, esto certifica que tienes esos conocimientos, muchas veces en tiempo récord.

En el mundo real esto no puede ser así.

Pero en el mundo real esto no es suficiente. Un proyecto no solo debe funcionar, sino también ofrecer una experiencia fluida y accesible para el usuario.

Y te pongo dos ejemplos de aplicaciones que has utilizado.

Comenzamos con un ejemplo: un juego, y no cualquier juego.

Minecraft

Ha sido el juego más jugado y vendido durante una década. Y aunque últimamente ha mejorado increíblemente su rendimiento, durante mucho tiempo —en la versión de Java— fue un gran dolor de cabeza por el alto consumo de recursos, FPS completamente inestables, además de que solo usaba un hilo de procesamiento para todo el trabajo y las mecánicas como la redstone pegaban tirones importantes. Esto se aleja mucho de la idea de "primero que funcione", y aun así, el juego ha sido líder.

¿Y por qué es tan usado si siempre ha funcionado mal y pedía demasiados recursos?

Entre muchas de las cosas que lo han mantenido líder, la que más destaco es su simplicidad y libertad. Puedes hacer lo que quieras, tiene gráficos sencillos que todo el mundo entiende, sin tutorial, incluso durante los inicios sin logros ni misiones. Es tan sencillo, tan fácil, que cualquiera en unos minutos puede empezar. Además, es tan versátil que tienes mil formas de jugar y usarlo. Tanto es así, que se ha utilizado en sectores como ventas y educación.

¿Te imaginas hacer esto mismo con juegos más elaborados como League of Legends? Estos juegos sí necesitan cierta complejidad para analizar. Tienes que aprenderte todas las mecánicas y combinaciones (que no son pocas), y además está en constante evolución.

En resumen, la experiencia de usuario en Minecraft ha sido increíble, y pocos juegos han logrado replicar algo similar.

Aquí puedes decir: "Bueno, esto es un juego, ¿no? No tiene nada que ver con desarrollar apps".

Pues... el concepto es el mismo. Pero aun así, te muestro otro ejemplo:

Instagram

Instagram, aunque tiene serios problemas de rendimiento, sigue siendo una de las aplicaciones más adictivas. Su éxito no radica en la perfección técnica, sino en la experiencia de usuario que ha logrado crear: es fácil de usar, simple, directa, y su diseño provoca que los usuarios se queden.

¡Vaya!... volvemos a otra app que funciona fatal, pero con una experiencia de usuario impecable, al menos en lo que se refiere a retención.

Podría ponerte ejemplos como Canva vs Photoshop, Figma vs Adobe XD o Windows vs Mac.

¿Cuándo funciona realmente funcionalidad primero?

Cuando la herramienta está totalmente enfocada a procesos internos, herramientas muy, muy técnicas y muy, muy de nicho. Ahí funciona perfecto.

Herramientas como Jira y administración de consolas como AWS, donde tienen una potencia técnica increíble y el usuario final va enfocado a su funcionalidad (aunque la primera debería ponerse las pilas en UX... es un dolor de cabeza, en serio).

Un criterio más realista

Basándome en comentarios que se hicieron, podríamos sacar un path más realista:

Primero, las matemáticas

Tener una lógica impecable y una experiencia de usuario perfecta no sirve de nada si la aplicación no es viable. Antes de comenzar a desarrollar, asegúrate de que el proyecto sea realizable y que haya un enfoque claro en la viabilidad.

Lo sé, esto se aleja muchísimo de estar estudiando, haciendo prácticas o siendo junior, pero ve ampliando ya tu horizonte.

Segundo, identificar el problema

Antes de escribir una sola línea de código, pregúntate:

¿Qué problema estamos resolviendo? ¿Qué solución podemos ofrecer?

Definir esto con claridad es el primer paso.

Ofrecer soluciones al problema

Y aquí sí: aquí entra todo documento técnico con la funcionalidad y, por supuesto, la experiencia de usuario. Y una vez tenemos todo esto claro, ya vamos a empezar con arquitecturas, stacks y diseño.

Antes de escribir una línea de código, pregúntate:

¿Hay una necesidad real? ¿Es viable económicamente? ¿Quién va a usar esto y cómo lo va a sentir?

Importante: no puedes crear una app que no se entienda, que no se sepa usar o que aporte más problemas al usuario final.

Recuerda: aportamos valor y hacemos que todo sea más accesible y cómodo. Por supuesto, como todo en nuestro campo, nada es fijo y todo cambia según el escenario, el proyecto y la finalidad.

Pero desde ya, olvídate de centrar todo en la funcionalidad.

Nuestro trabajo es aportar valor y solventar problemas.

No es solamente escribir código.

En resumen, nuestro trabajo como desarrolladores no es solo escribir código.

Es resolver problemas y aportar valor.

Si centramos todo en la funcionalidad sin tener en cuenta la experiencia del usuario, corremos el riesgo de crear soluciones complicadas que no sean útiles.

Y no, esto no va de decir qué está bien o mal. Se trata de abrir el debate, sumar puntos de vista y nutrir nuestro background para que, poco a poco, sepamos por qué hacemos lo que hacemos… y no solo cómo hacerlo.

¿Qué opinas? ¿Por dónde empezarías tú un proyecto?

¡Déjame tu respuesta en los comentarios!

🙌 Si te gustó este post, sígueme en mis redes.

¿Listo para el mundo real? Sube tu proyecto de 2º DAW/DAM a un VPS en pocos pasos

Altaskur — Mon, 07 Jul 2025 21:10:36 +0000

Tabla de contenidos

Motivación y prevención de errores típicos
¿Y para qué te vas a complicar con un VPS teniendo Netlify o Vercel?
Ventajas económicas y de aprendizaje
Pasos iniciales en DonWeb
- Comencemos
- Elige la imagen de sistema operativo
- Usuario Root
Acceso por SSH
Primeros pasos en tu VPS
Crear una snapshot (copia de seguridad)
Creación de usuario para deploy
Instalar NVM (Node Version Manager)
- Instalar Node.js LTS con NVM
- ¿Por qué instalar Node.js?
Instalar Nginx y por qué usarlo
Instalación básica de Nginx
Configuración de puertos en DonWeb
- Cómo configurar los puertos
- Pasos a seguir
- ¿Qué pasa si no configuras esto?
Preparar el acceso SSH para despliegue con GitHub Actions
- ¿Por qué necesitas esto?
- Pasos para configurar SSH para el usuario deploy
- Configurar GitHub Actions para usar la clave privada
Configurar un workflow de GitHub Actions para desplegar tu proyecto
Explicación del workflow de GitHub Actions paso a paso
- Configuración básica del workflow
- Disparadores del workflow
- Permisos y concurrencia
- Definición del trabajo (job)
- El paso de despliegue
- Configuración de la conexión SSH
- La lógica del script de despliegue
- ¿Por qué funciona tan bien esta lógica?
- Un detalle importante sobre los secrets
- Cómo funciona todo el proceso completo
Mejoras y optimizaciones avanzadas
🚀 ¿Quieres que haga una segunda parte sobre despliegue avanzado?
Solución de problemas comunes
- Error: "Permission denied" al hacer git pull
- Error: "Host key verification failed"
- Nginx muestra "403 Forbidden"
- El workflow se ejecuta pero no se actualiza la web
Conclusión

Estoy seguro de que si estás en 2º de DAW o DAM y te toca presentar tu proyecto final, has pensado en desplegarlo en un servidor, pensarás que te llevará mucho tiempo, además de no comprender del todo cómo funciona, así que seguramente has pensado en servicios como Netlify o Vercel, que son muy cómodos y fáciles de usar, pero... ¿Qué pasa si quieres algo más? O simplemente aprender a desplegar tu proyecto sin tanta magia por detrás. ¿Se supone que estamos aprendiendo a desarrollar no? Y el despliegue es una parte fundamental del proceso de desarrollo.

Motivación y prevención de errores típicos

Antes de meternos en faena, ¿qué ganas con todo esto? Lo principal es que te quitas riesgos importantes. El más común: tienes todo preparado, llega el día de la defensa y... sorpresa, al iniciar el proyecto en el portátil, no funciona. No te puedes hacer una idea de lo habitual que es eso, y créeme, no te quieres ver en esa situación.

Además, muy típico, cambios de última hora o llevas mucho desarrollado y no has probado nada.
Todo esto te lo puedes saltar usando un despliegue continuo con GitHub Actions (por ejemplo), así cada vez que subas cambios a tu repositorio, se desplegará automáticamente en tu servidor. Esto te ahorra tiempo y te asegura que siempre tienes la última versión funcionando.

¿Y para qué te vas a complicar con un VPS teniendo Netlify o Vercel?

Si solo necesitas publicar una web sencilla, funcionan perfecto. Pero si necesitas un backend completo, bases de datos, bots, tareas automáticas (cron), websockets... puedes montar lo que quieras, aunque sea raro, experimental o muy ambicioso. La única limitación es la capacidad de tu servidor.

Además, con un VPS tienes control total: puedes instalar lo que quieras, configurar el sistema a tu medida y optimizarlo para tu proyecto. No dependes de las limitaciones ni del template que ofrecen.

Ventajas económicas y de aprendizaje

Algo que me parece primordial y sobre todo al estar estudiando, no hay cobros sorpresa: pagas lo mismo cada mes, superes o no la capacidad del servidor. Es muy común en servicios de nube como AWS, Azure o Google Cloud, donde cobras por uso, cualquier fallo, descuido o vulnerabilidad puede hacer que te lleves una sorpresa desagradable al final de mes. Que ya sabemos que no tiene por qué pasar, pero te da muchísima más tranquilidad saber que apagas tu servidor, haces tus cambios y no te cobran más por ello.

Esto es sin duda fue mi principal temor cuando estaba estudiando DAW, aunque me gradué con los dos primeros Tier de AWS, ese temor siempre me ha frenado muchísimo a subir mis proyectos. Así que te muestro la opción más segura que encontré y que sigo aplicando en mis proyectos.

Y por último, el aprendizaje: vas a entender realmente cómo funciona el despliegue, la configuración y la administración de servidores, algo que marca la diferencia y suma muchos puntos cuando salgas al mundo profesional, independientemente de si tiras hacia front o back. Créeme que cuando aprendes que cuantas menos magias mientras estás creando tu base de conocimientos, más fácil te será adaptarte a cualquier tecnología o servicio que surja en el futuro (que te aseguro que van a venir).

Resumen: ganas control, flexibilidad y aprendizaje.

Para el post vamos a elegir https://donweb.com/es-es/cloud-server-altaskur como proveedor de servicios.

¿Por qué https://donweb.com/es-es/cloud-server-altaskur? Es una empresa conocida en Latinoamérica, tiene soporte en español, es sencilla de usar y, lo más importante, para este post he contado con su apoyo, que me ha facilitado un VPS para hacer las pruebas y capturas.

¿Y si tienes otro proveedor? Si tienes otros servicios (OVH, Hetzner, DigitalOcean, etc.), puedes seguir los pasos igual. Como te he comentado antes, las bases son exactamente las mismas; solo cambiarán pequeños detalles del panel.

Pasos iniciales en DonWeb

Ahora que lo tenemos todo decidido vamos a comenzar con la aventura. Desde este punto voy a dar por hecho que ya tienes una cuenta en DonWeb y has iniciado sesión en su panel de control, además de tener un VPS contratado.

Recuerda que puedes replicarlo con cualquier proveedor de VPS, los pasos son muy similares.

Puedes crear una cuenta en este enlace: https://donweb.com/es-es/cloud-server-altaskur

Comencemos

Una vez dentro del panel de https://donweb.com/es-es/cloud-server-altaskur y nuestro servidor contratado, vamos a configurar nuestro VPS para que esté listo para desplegar nuestro proyecto.

Elige la imagen de sistema operativo

Elige la imagen de sistema operativo. Selecciona "Instalación Mínima" con Ubuntu 24.04. Esto garantiza un sistema limpio y ligero, ideal para montar solo lo que necesitas.

Que además, si necesitas cualquier otro servicio, tienes muchas imágenes preconfiguradas, con todo disponible. Una de mis favoritas es la de node (que ya viene con node y pm2 instalado), pero para este post vamos a usar una instalación mínima de Ubuntu 24.04, que es la versión LTS más reciente y estable.

¿Por qué una instalación mínima y por qué Ubuntu? Básicamente Ubuntu es un sistema muy fácil de usar con una gran comunidad y documentación, así que si tienes cualquier problema seguro que con una búsqueda rápida encuentras la solución. Podríamos optar por una imagen como Debian (seguramente te lo dirán) porque es la más usada en servidores, pero en este post voy a intentar facilitarte las cosas ante cualquier problema que pueda salirte, y Ubuntu es una de las distribuciones más amigables y con más soporte.

¿Te apetece probar con Debian? 👀 No te juzgo, pensé igual que tú cuando estudiaba. ¡Adelante! Los pasos son muy similares, pero ten en cuenta que la configuración puede variar un poco.

Te recomiendo que una vez tengas hecha con Ubuntu pruebes otras distribuciones e imágenes.

Usuario Root

Crea la contraseña del usuario root. El panel te pedirá establecer una contraseña segura para el usuario root. DonWeb incluye un generador de contraseñas integrado bastante decente, aprovéchalo.

Por si no has estado muy pendiente en clase, el usuario root tiene acceso total a todo el sistema, así que no menosprecies este paso, vale. Es importante aunque no te lo parezca y además siempre puedes cambiarla más adelante.

Confirma y lanza la instalación. Haz clic en continuar y espera unos minutos (no suele ser más de 3 min, que es muchísimo menos de lo que tardas en hacerlo en VirtualBox). Durante este tiempo, el sistema se instala y prepara.

Una vez termine la instalación, tendrás acceso a tu VPS por SSH usando la IP, el usuario root y la contraseña que has puesto antes.

Y sin tener que especificar ni dominio de actualizaciones ni idioma del teclado ni nada de eso, como pasaba con VirtualBox.

Acceso por SSH

Conectarte por SSH a tu VPS te será muy familiar si has usado VirtualBox durante el curso (¡seguro que sí! 😊).

Y si no, ni te preocupes. Suponiendo que estás en un entorno Windows usa la PowerShell o si estás en Mac o Linux, abre la terminal.

¿Dónde están los datos de acceso? Ve al apartado de software y accesos en el panel de DonWeb. Ahí tendrás para copiar en tu terminal un comando como este:

ssh -p[tu puerto] root@[tu_direccion_IP]

El puerto (-p[tu puerto]) y la dirección IP pueden variar según tu VPS. Asegúrate de copiar los valores que te da DonWeb para tu máquina.

Primeros pasos en tu VPS

Ahora estamos en nuestro servidor y lo primero que vamos a hacer es actualizar la máquina. Para ello, ejecuta estos comandos en la terminal:

sudo apt update
sudo apt upgrade

Esto puede tardar un ratito, así que ten paciencia. Actualizar el sistema asegura que tienes todos los parches de seguridad y las versiones más recientes de los paquetes instalados y nos olvidamos de problemas de compatibilidad más adelante.

Crear una snapshot (copia de seguridad)

Cuando termine la actualización, lo siguiente es crear una snapshot. Así tendrás una imagen de tu sistema justo desde el inicio, por si algo falla más adelante y necesitas volver atrás.

Busca en el panel de DonWeb la opción de Snapshots o copias de seguridad y crea una nueva antes de seguir.

Creación de usuario para deploy

Ahora que ya tenemos preparada una versión limpia y actualizada de Ubuntu, vamos a dar el siguiente paso. No es recomendable usar Root. De hecho, cuanto menos lo expongamos mejor, ya que este tiene acceso total al sistema, así que lo primero que hay que hacer es crear un usuario nuevo para gestionar el servidor y el despliegue de tu proyecto.

Vamos a ello. Para ello vamos a crear un usuario, lo vamos a llamar deploy por el tema de semántica, pero puedes ponerle el nombre que quieras.

adduser deploy

Sigue las instrucciones para ponerle contraseña (puede ser distinta a la de root) y, si quieres, rellena los datos adicionales (puedes dejarlos en blanco pulsando Enter).

Después, añade este usuario al grupo sudo para que pueda usar permisos de administración cuando lo necesite:

 usermod -aG sudo deploy

Una vez tienes esto listo, sal de la sesión de root en la terminal y vuelve a conectarte, pero esta vez usando el usuario deploy que acabas de crear.

Para salir de la terminal como root, simplemente escribe:

exit

Ahora inicia sesión de nuevo por SSH, pero cambiando root por deploy y usando la misma IP y puerto que antes:

ssh -p[tu puerto] deploy@[tu_direccion_IP]

Introduce la contraseña del usuario deploy cuando te la pida.

Ahora que ya estamos dentro vamos a empezar a aprovisionar el servidor. Para ello vamos a instalar Node.js con NVM (Node Version Manager), Nginx como instalación mínima para poder desplegar tu proyecto de front y backend con node.

Instalar NVM (Node Version Manager)

Ahora que ya estás conectado como el usuario deploy, vamos a instalar NVM. NVM te permitirá instalar y gestionar diferentes versiones de Node.js de forma sencilla.

En la terminal, ejecuta el siguiente comando para descargar e instalar la última versión de NVM:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

Una vez termine, cierra y vuelve a abrir la terminal, o ejecuta el siguiente comando para cargar NVM en la sesión actual:

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

Para comprobar que NVM está instalado correctamente, ejecuta:

nvm --version

Si ves un número de versión, ¡ya lo tienes listo!

Instalar Node.js LTS con NVM

Ahora que tienes NVM instalado, vamos a instalar la versión LTS de Node.js. La versión LTS es la más recomendada para la mayoría de proyectos porque es la más estable y tiene soporte a largo plazo.

En la terminal, ejecuta:

nvm install --lts

Esto descargará e instalará la última versión LTS disponible de Node.js.

Para comprobar que la instalación se realizó correctamente y estás usando la versión LTS, ejecuta:

node -v
npm -v

Deberías ver los números de versión correspondientes.

¿Por qué instalar Node.js?

Instalar Node.js es necesario porque la mayoría de proyectos modernos de backend y muchas herramientas de frontend (como React, Angular, Vue, Svelte, etc.) usan Node.js para funcionar, tanto en desarrollo como en producción.

Además si tu proyecto está hecho con cualquier stack basado en JavaScript o necesitas ejecutar scripts asique necesitarás Node.js en tu servidor

En resumen: Instalar Node.js te garantiza que tu VPS puede ejecutar la mayoría de proyectos web actuales y es casi imprescindible para DAW/DAM hoy en día.

Instalar Nginx y por qué usarlo

Ahora que ya tienes Node.js instalado, vamos a instalar nginx.

¿Y por qué Nginx? Porque Nginx es un servidor web ligero, rápido y muy usado en producción.
Mucha gente te hablará de Apache, y es el servidor web más antiguo y conocido, ¿pero por qué Nginx? Es más ligero, y en la mayoría de los casos es más fácil de configurar y mantener.

Al igual que te dije con Ubuntu Vs Debian, Nginx es el más fácil, así que si quieres adentrarte con apache ¡Adelante! 👀 aunque te recomiendo que primero lo montes con Nginx así luego te sonará todo.

¿Y qué es esto de Nginx o Apache? Pues lo que hacen es servir tu página web, similar a un npm start de Node.js, pero a nivel de servidor de modo que hará tu proyecto accesible desde Internet.

No solo sirve para servir páginas web estáticas, sino que también puede actuar como proxy inverso para aplicaciones Node.js, gestionar certificados SSL, balancear carga entre varios servidores y mucho más.

Es compatible con SSL (HTTPS), por lo que es imprescindible si quieres usar certificados y servir tu web de forma segura.

En resumen: Nginx es un servidor web moderno versátil y ligero. Es una herramienta fundamental para desplegar aplicaciones web en producción, ya sea para servir archivos estáticos, actuar como proxy inverso o gestionar certificados SSL.

Instalación básica de Nginx

En tu terminal (con el usuario deploy, usando sudo), ejecuta:

sudo apt update
sudo apt install nginx

Cuando termine, puedes comprobar que Nginx está funcionando abriendo tu navegador y poniendo la IP de tu servidor: Deberías ver la página de bienvenida de Nginx.

Y ya está, ya tienes Nginx instalado y funcionando en tu servidor. Ahora puedes ver la página de bienvenida de Nginx en la carpeta /var/www/html, que es donde se guardan los archivos que Nginx sirve por defecto.

Configuración de puertos en DonWeb

Antes de seguir con el despliegue automático, hay un paso importante que muchas veces se pasa por alto: configurar correctamente los puertos en el panel de DonWeb.

¿Por qué es importante esto? Aunque tengas Nginx funcionando perfectamente en tu servidor, si los puertos no están abiertos en el firewall de DonWeb, nadie podrá acceder a tu web desde Internet. Es como tener una casa perfectamente amueblada pero con la puerta de entrada cerrada.

Cómo configurar los puertos

Ve al panel de DonWeb, busca la sección de Firewall o Configuración de puertos de tu VPS. Ahí verás una interfaz similar a esta:

Los puertos que necesitas abrir como mínimo son:

Puerto 80 (HTTP): Para que tu web sea accesible sin HTTPS
Puerto 443 (HTTPS): Para cuando configures certificados SSL
Puerto SSH: El que usas para conectarte (normalmente aparece ya configurado)

Pasos a seguir

Identifica los puertos necesarios: Para un proyecto web básico, necesitas el 80 y 443
Añade las reglas: En el panel de DonWeb, crea nuevas reglas para estos puertos
Configura el origen: Normalmente puedes dejarlo como "Any" (0.0.0.0/0) para que sea accesible desde cualquier lugar
Aplica los cambios: Guarda la configuración y espera unos segundos a que se aplique

¿Qué pasa si no configuras esto?

Si no abres estos puertos, aunque tu aplicación esté funcionando perfectamente en el servidor, cuando intentes acceder desde tu navegador verás errores tipo "No se puede conectar" o "Tiempo de espera agotado". Es uno de los errores más comunes y que más frustración genera, especialmente cuando todo lo demás está bien configurado.

💡 Tip importante: Si tu aplicación Node.js usa un puerto diferente (como el 3000), también necesitarás abrirlo en el firewall, o mejor aún, configurar Nginx como proxy inverso para que sirva tu aplicación a través del puerto 80/443.

Una vez tengas los puertos configurados correctamente, podrás acceder a tu servidor desde el navegador usando la IP que te proporciona DonWeb, y deberías ver la página de bienvenida de Nginx.

Preparar el acceso SSH para despliegue con GitHub Actions

Ya tenemos tanto backend como frontend preparados para desplegar y un servidor web disponible para servir tu proyecto.

Pero, ¿cómo vamos a subir los archivos de tu proyecto al servidor? ¿Y cómo vamos a hacer que GitHub Actions pueda desplegar automáticamente cada vez que subas cambios?
Para esto, vamos a configurar el acceso SSH para el usuario deploy que acabamos de crear.

¿Por qué necesitas esto?

GitHub Actions puede ejecutar scripts y comandos automáticamente cada vez que subes código (push).

Para que pueda copiar los archivos o ejecutar comandos en tu servidor, necesita conectarse por SSH sin pedirte la contraseña cada vez. Así te olvidas de hacer zips con el build del proyecto de ftp y subirlo manualmente. Esto normalmente se tarda mucho tiempo, son muchos pasos y cuantos más pasos más probable es que algo falle (sobre todo si lo haces a última hora 👀 que ya sabemos lo que pasa).

Por seguridad y automatización, se usan claves SSH, no contraseñas. Así no tienes que escribir la contraseña cada vez que quieras hacer un despliegue ni hardcodear la contraseña en tu repositorio de GitHub (que también te veo venir).

Pasos para configurar SSH para el usuario deploy

Entonces desde la terminal nos vamos a tu servidor VPS y vas a ejecutar el siguiente comando:

ssh-keygen -t ed25519 -C "deploy@tuproyecto"

Pulsa Enter en todas las preguntas (puedes poner una ruta o dejar la predeterminada y no pongas passphrase).

Copia la clave pública al servidor usando el siguiente comando (reemplaza los datos según tu configuración):

ssh-copy-id -p[tu puerto] deploy@[tu_direccion_IP]

Si no tienes ssh-copy-id, puedes copiar manualmente el contenido de ~/.ssh/id_ed25519.pub al archivo ~/.ssh/authorized_keys en el servidor, dentro del usuario deploy. Puede ser que tengas que crear o la carpeta .ssh o el archivo authorized_keys si no existen. Revísalo primero con un ls -la en la carpeta del usuario deploy.

mkdir -p ~/.ssh
echo "tu_clave_publica" >> ~/.ssh/authorized_keys

Una vez lo tenemos, vamos a asegurarnos de que los permisos son correctos:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Ahora ya podemos usar las claves SSH para conectarnos al servidor desde GitHub Actions sin necesidad de introducir la contraseña cada vez y comenzar a desplegar tu proyecto automáticamente.

Configurar GitHub Actions para usar la clave privada

Abre tu clave privada (por ejemplo, ~/.ssh/id_ed25519) con un editor de texto y cópiala entera.

Ve a tu repositorio en GitHub → Settings → Secrets and variables → Actions.

Crea un nuevo Secret llamado, por ejemplo, DEPLOY_KEY y pega ahí el contenido de la clave privada.

Y ya está, ahora tu GitHub Actions puede usar esta clave para conectarse a tu servidor y desplegar tu proyecto automáticamente.

Aún queda un paso más. Ahora mismo lo único que hemos hecho es guardar la clave privada en GitHub de manera segura, pero aún no le hemos dicho a GitHub Actions que la use y lo más importante no le hemos dicho cómo ha de usarla.

Configurar un workflow de GitHub Actions para desplegar tu proyecto

Aquí es donde empieza la fiesta realmente. Hay muchas formas de hacer esto y sobre todo ha de ser adaptado a tu proyecto, según estés usando Frontend con (React, Angular, Vue, Svelte, etc.) o Backend con Node.js (Express, NestJS, etc.) o cualquier otro lenguaje o framework. Cada uno tiene su propia manera de ser desplegado, así que eso tendrás que adaptarlo a tu proyecto.

Pero te voy a dar un ejemplo básico de cómo podrías configurar un workflow de GitHub Actions para desplegar tu proyecto al servidor usando un HTML estático simulando un build de un proyecto de frontend ya realizado.

📚 Contenido relacionado: Si tienes un proyecto Angular y quieres desplegarlo, puedes ver mi post sobre cómo desplegar Angular 19 en GitHub Pages. Esta enfocado a GitHub Pages pero puedes adaptarlo al VPS sin problema.

Lo primero necesitarás crear una carpeta en tu proyecto llamada .github/workflows y dentro de esta un archivo llamado deploy.yml o el nombre que quieras, pero con la extensión .yml. Aquí es donde vamos a definir el workflow de GitHub Actions que no es nada más que un conjunto de pasos que se ejecutarán automáticamente cada vez que subas cambios a tu repositorio.

Te dejo un ejemplo básico de cómo podría ser este archivo:

¿Quieres ver en detalle un workflow de GitHub Actions completo? o alguna tecnología en concreto? Dímelo en los comentarios y lo preparo para un próximo post.

name: 🚀 Deploy Web to VPS

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: "pages"
  cancel-in-progress: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: ⚙️ Execute Deployment SSH Command
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USERNAME }}
          key: ${{ secrets.VPS_SSH_KEY }}
          port: ${{ secrets.VPS_SSH_PORT }}
          script: |
            cd /var/www/html/
            if [ -d "[nombre proyecto]/.git" ]; then
              echo "El repositorio ya existe, haciendo pull..."
              cd [nombre proyecto]
              git pull
            else
              if [ -d "[nombre proyecto]" ]; then
                echo "Existe [nombre proyecto] pero NO es repo, borrando carpeta..."
                rm -rf [nombre proyecto]
              fi
              echo "Clonando repo..."
              git clone ${{ secrets.VPS_REPO_URL }}
            fi

Explicación del workflow de GitHub Actions paso a paso

Ahora que ya tienes el archivo YAML del workflow, vamos a explicar qué hace cada parte para que entiendas exactamente cómo funciona este despliegue automático.

Configuración básica del workflow

name: 🚀 Deploy Web to VPS

Aquí defines el nombre que aparecerá en la pestaña de Actions de tu repositorio de GitHub. El emoji es opcional pero ayuda a identificar rápidamente el workflow.

Disparadores del workflow

on:
  push:
    branches: [main]
  workflow_dispatch:

Esta sección define cuándo se ejecutará el workflow:

push: branches: [main] → Se ejecuta automáticamente cada vez que haces push a la rama main
workflow_dispatch → Te permite ejecutar el workflow manualmente desde la interfaz de GitHub

¿Por qué usar ambos? El automático te ahorra trabajo en el día a día, y el manual te da control cuando necesitas hacer un despliegue específico.

Permisos y concurrencia

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: "pages"
  cancel-in-progress: true

Permisos: Define qué puede hacer GitHub Actions en tu repositorio:

contents: read → Puede leer el código de tu repositorio
pages: write → Puede escribir en GitHub Pages (si lo usas)
id-token: write → Puede generar tokens de identidad para autenticación

Concurrencia: Evita que se ejecuten múltiples despliegues al mismo tiempo:

Si hay un despliegue en curso y haces otro push, cancela el anterior y ejecuta el nuevo
Esto previene conflictos y problemas de estado inconsistente

Definición del trabajo (job)

jobs:
  deploy:
    runs-on: ubuntu-latest

Aquí defines:

deploy → Nombre del trabajo (puedes tener varios jobs en un workflow)
runs-on: ubuntu-latest → El sistema operativo donde se ejecutará (GitHub proporciona la máquina virtual)

El paso de despliegue

steps:
  - name: ⚙️ Execute Deployment SSH Command
    uses: appleboy/ssh-action@v1

¿Qué es appleboy/ssh-action? Es una acción desarrollada por la comunidad que facilita ejecutar comandos SSH desde GitHub Actions. Es como si GitHub se conectara por SSH a tu servidor y ejecutara comandos automáticamente.

Configuración de la conexión SSH

with:
  host: ${{ secrets.VPS_HOST }}
  username: ${{ secrets.VPS_USERNAME }}
  key: ${{ secrets.VPS_SSH_KEY }}
  port: ${{ secrets.VPS_SSH_PORT }}

Estos son los GitHub Secrets que configuraste antes:

VPS_HOST → La IP de tu servidor
VPS_USERNAME → El usuario deploy que creaste
VPS_SSH_KEY → La clave privada SSH
VPS_SSH_PORT → El puerto SSH de tu servidor

¿Por qué secrets? Porque esta información es sensible y no debe estar visible en tu código público.

La lógica del script de despliegue

script: |
  cd /var/www/html/proyects/
  if [ -d "[nombre proyecto]/.git" ]; then
    echo "El repositorio ya existe, haciendo pull..."
    cd [nombre proyecto]
    git pull
  else
    if [ -d "[nombre proyecto]" ]; then
      echo "Existe [nombre proyecto] pero NO es repo, borrando carpeta..."
      rm -rf [nombre proyecto]
    fi
    echo "Clonando repo..."
    git clone ${{ secrets.VPS_REPO_URL }}
  fi

Vale, ahora vamos a lo que realmente hace este script cuando se ejecuta en tu servidor. Primero se mueve a la carpeta /var/www/html/ que es donde están los archivos que Nginx sirve por defecto. Una vez ahí, lo primero que hace es verificar si ya existe una carpeta con el nombre de tu proyecto y además si esa carpeta es un repositorio Git válido.

Si encuentra que ya tienes el proyecto ahí y es un repo Git, genial, solo hace un git pull para bajarse los últimos cambios que hayas hecho. Es súper eficiente porque no tiene que descargar todo otra vez, solo los archivos que cambiaron.

Pero si encuentra una carpeta con el nombre de tu proyecto pero resulta que no es un repositorio Git (esto puede pasar si algo se rompió antes o si pusiste archivos manualmente), lo que hace es borrar toda esa carpeta y empezar de cero. Mejor limpio que con archivos raros por ahí.

Y finalmente, si no existe absolutamente nada, pues clona el repositorio completo desde GitHub usando la URL que tienes guardada en los secrets.

¿Por qué funciona tan bien esta lógica?

Si ya tienes el proyecto desplegado, solo actualiza lo que necesita, que es mucho más rápido que estar bajando todo cada vez. Y si algo falló en algún momento (que pasa más de lo que te imaginas), no se queda ahí dando vueltas con archivos corruptos, simplemente borra todo y empieza fresh.

Además funciona igual de bien tanto si es la primera vez que despliegas como si ya llevas meses actualizando el proyecto. No tienes que estar pensando en casos especiales ni nada raro.

Un detalle importante sobre los secrets

Ojo que aparte de todos los secrets de SSH que configuramos antes, también vas a necesitar agregar VPS_REPO_URL en GitHub. Este es simplemente la URL de tu repositorio, algo como https://github.com/tuusuario/tuproyecto.git. Nada del otro mundo pero es importante no olvidarlo.

Cómo funciona todo el proceso completo

En resumen, cada vez que haces push a main, GitHub se da cuenta automáticamente y arranca todo el proceso. Crea una máquina virtual con Ubuntu (que es gratis, por cierto), se conecta por SSH a tu VPS usando todas las credenciales que guardaste de forma segura, ejecuta el script que acabamos de ver y boom, tu proyecto queda desplegado con la última versión.

¡Y ya está! Te olvidas completamente de estar subiendo archivos a mano, de hacer FTP, de comprimir carpetas y toda esa marabunta. Cada vez que hagas un cambio en tu código y lo subas a GitHub, automáticamente se despliega en tu servidor. Es como magia pero que realmente entiendes cómo funciona.

💡 Tip: Puedes personalizar este workflow según tu proyecto. Por ejemplo, si usas React, podrías añadir pasos para hacer npm install y npm run build antes del despliegue.

Como ves este script es muy básico y puedes adaptarlo y mejorar muchísimo. Te animo a que lo hagas, y si realmente quieres o tienes dudas, no dudes en preguntarme en los comentarios y preparo un post centrado sólo en GitHub Actions y cómo hacer despliegues más avanzados.

💡 Contenido relacionado: Si quieres ver un ejemplo práctico de GitHub Actions en acción, he creado un post sobre cómo desplegar Angular 19 en GitHub Pages desde GitHub Actions, donde explico paso a paso un workflow completo para proyectos frontend.

Mejoras y optimizaciones avanzadas

El workflow que acabamos de ver es funcional, pero hay muchas formas de mejorarlo. Aquí te dejo algunas ideas para que puedas expandir y optimizar tu setup:

🔒 Nota importante de seguridad: Este tutorial está enfocado en el aprendizaje y la funcionalidad básica. Para entornos de producción empresariales, considera implementar medidas adicionales como fail2ban, configuración de firewall más restrictiva, auditorías de seguridad regulares y políticas de acceso más estrictas.

🚀 ¿Quieres que haga una segunda parte sobre despliegue avanzado?

Estas son solo algunas ideas básicas. Si hay interés, puedo preparar un post completo cubriendo temas avanzados como

Seguridad avanzada: Configuración de fail2ban, certificados SSL automáticos con Let's Encrypt, hardening del servidor

Nginx avanzado: Configuración como proxy inverso, configuración específica de proyectos, load balancing, optimización de performance

Monitoreo y logs: Configuración de Grafana, Prometheus, gestión centralizada de logs

Bases de datos: Instalación y configuración de MySQL, PostgreSQL, MongoDB con backups automáticos

Dockerización completa: Convertir todo el setup a contenedores Docker con Docker Compose

CI/CD robusto: Tests automáticos, análisis de código, despliegues con aprobación manual

Entornos diferenciados: Configuración entornos de desarrollo, staging y producción con GitHub Actions

💡 Tip para proyectos robustos: Si quieres asegurar la calidad de tu código antes del despliegue, te recomiendo configurar herramientas de linting y formateo. Tengo un post completo sobre cómo crear un proyecto nuevo con ESLint, Stylelint, Commitlint y Husky que te ayudará a automatizar las verificaciones de calidad antes de cada commit.

¡Comenta si te interesa alguno de estos temas y veré cuál es el que más demanda tiene para hacer la segunda parte!

Solución de problemas comunes

Cuando empiezas con despliegues en VPS, es normal que te encuentres con algunos problemas. Aquí te dejo los más comunes y cómo solucionarlos:

Error: "Permission denied" al hacer git pull

Si tu workflow falla con errores de permisos:

# En tu servidor, asegúrate de que el usuario deploy es el propietario
sudo chown -R deploy:deploy /var/www/html/
sudo chmod -R 755 /var/www/html/

Error: "Host key verification failed"

Si GitHub Actions no puede conectarse por SSH:

# En tu servidor, regenera las claves SSH
ssh-keygen -R github.com
ssh-keyscan github.com >> ~/.ssh/known_hosts

Nginx muestra "403 Forbidden"

Si tu web no se ve correctamente:

# Verifica los permisos de la carpeta web
sudo chmod -R 755 /var/www/html/
sudo chown -R www-data:www-data /var/www/html/

El workflow se ejecuta pero no se actualiza la web

Verifica que los archivos están en el lugar correcto:

# Conecta por SSH y verifica
ls -la /var/www/html/[tu-proyecto]/
# Si es un proyecto con build, asegúrate de copiar los archivos compilados a la carpeta correcta

🔧 Tip de debugging: Siempre puedes conectarte por SSH a tu servidor después de un despliegue para verificar qué está pasando. Los logs de Nginx están en /var/log/nginx/ y puedes verlos con sudo tail -f /var/log/nginx/error.log

Conclusión

El proceso te va a llevar poco tiempo. Calculo que unas 2 horas si es la primera vez que lo haces, pero una vez lo tengas montado, cada vez que hagas un cambio en tu proyecto y lo subas a GitHub, se desplegará automáticamente en tu servidor sin que tengas que hacer nada más.

Y lo mejor de todo, te quitas de encima el miedo a que algo falle el día de la defensa. Tu proyecto estará siempre actualizado y funcionando, y tú podrás centrarte en lo que realmente importa: demostrar todo lo que has aprendido.

Recuerda darle las gracias a https://donweb.com/es-es/cloud-server-altaskur por el apoyo y por facilitarme un VPS para hacer las pruebas y capturas de este post. Si quieres probarlo, puedes crear una cuenta en DonWeb.

Y si tienes alguna duda o quieres que profundice en algún aspecto, ¡déjamelo en los comentarios!

Cómo desplegar Angular 19 en GitHub Pages desde GitHub Actions

Altaskur — Sun, 18 May 2025 15:02:11 +0000

Indice

Plantilla del workflow
Primer problema: Missing download info
Segundo problema: ¿Y si es mi custom domain?
Tercer problema: ¿Y si la ruta del proyecto?
Cuarto paso y solución: ¿Espera... qué estamos mandando al deploy?
Conclusión

En los últimos directos estoy desarrollando una Pokédex funcional con Angular 19, y quería aprovechar la ocasión para mostrar el proceso completo, incluyendo cómo hacer el despliegue automático con GitHub Pages mediante GitHub Actions

La idea era sencilla: que cada vez que terminara un directo y subiera cambios a la rama main, el proyecto se construyera automáticamente y se publicara en GitHub Pages. Algo más que suficiente para ir mostrando los avances sin tener que hacer deploys manuales.

La idea era perfecta... hasta que empezaron los problemas.

Como hacía tiempo que no montaba un flujo de despliegue con Angular y Pages, fui directo a buscar tutoriales (en pleno directo, claro 😅). Pero todos los que encontraba pedían configurar un token personal de GitHub para poder hacer el despliegue, y yo sabía —por experiencia— que eso ya no es necesario.

💬 Este post refleja un proceso personal de aprendizaje mientras desarrollo un proyecto propio. No representa ninguna práctica oficial.

Plantilla del workflow

Aquí te dejo la plantilla .yml que estoy utilizando y que puedes adaptar fácilmente a tu repositorio:

name: 🚀 Deploy Angular to GitHub Pages

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: 'pages'
  cancel-in-progress: true

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: 🧾 Checkout repository
        uses: actions/checkout@v4

      - name: ⚙️ Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - name: 📦 Install dependencies
        run: npm ci

      - name: 🛠️ Build Angular App
        run: npx ng build --configuration production --base-href "/[NOMBRE_DEL_REPOSITORIO]/"

      - name: 🧩 Add .nojekyll file
        run: echo "" > dist/[NOMBRE_DEL_PROYECTO]/browser/.nojekyll

      - name: 📤 Upload Pages artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: dist/[NOMBRE_DEL_PROYECTO]/browser

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: ⚙️ Setup GitHub Pages
        uses: actions/configure-pages@v4

      - name: 🚀 Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

Y no te olvides de ajustar el angular.json:

"options": {
  "outputPath": "dist/[NOMBRE_DEL_PROYECTO]",
  "baseHref": "/[NOMBRE_DEL_REPOSITORIO]/"
}

😉 Ahora que ya tienes la solución funcional, voy a contarte todo lo que pasó para llegar hasta aquí.

Primer problema: Missing download info

Al montar el workflow siguiendo algunos ejemplos que encontré por internet, me topé con el siguiente error:

Missing download info for actions/upload-pages-artifact@v3

Y claro, lo primero que pensé fue: ¿qué demonios significa esto? 🤯

upload-pages-artifact es una acción de GitHub que permite subir el contenido generado (por ejemplo, la carpeta dist de Angular) para que otra acción, normalmente deploy-pages, lo recoja y lo publique en GitHub Pages.

Hasta aquí todo bien, ¿no? Pues no.

A fecha de creación de esta entrada, la última versión de deploy-pages es la v4, así que normalmente la invocas con:

uses: actions/deploy-pages@v4

Pero aquí viene el plot twist: esta versión espera un formato de artefacto diferente al que genera upload-pages-artifact@v2, que es el que aún aparece en muchos tutoriales y ejemplos.

Primer golpe de realidad: me costó un buen rato descubrirlo, así que tenlo en cuenta cuando estés consultando documentación desactualizada o siguiendo ejemplos de hace unos meses.

Segundo problema: ¿Y si es mi custom domain?

Una vez solucionado el error anterior, la pipeline se ejecutaba correctamente y me lanzaba el siguiente mensaje:

Evaluate and set environment url
Evaluated environment url: http://altaskur.live/pokedex-angular/
Cleaning up orphan processes

¡Perfecto! 🎉 Ya lo tenía. Podía visitar la URL y acceder al proyecto... o eso pensaba.

Pero sorpresa: al acceder a la URL obtenía un 404.

¿Perdona? Si la pipeline decía que el despliegue se había hecho correctamente... ¿por qué no puedo acceder?

Mi primera sospecha fue que quizás el problema era el custom domain. GitHub Pages, por defecto, muestra las páginas usando la ruta [tu_usuario].github.io, pero puedes añadirle un dominio personalizado, como es mi caso (altaskur.live).

¿Entonces no estaba bien configurado? 🤔

Revisé otros proyectos que tengo activos usando GitHub Pages y todos estaban funcionando perfectamente. Así que descarté que el problema viniera del dominio.

Tercer problema: ¿Y si la ruta del proyecto?

En este caso, el nombre del proyecto de Angular y el del repositorio en GitHub no coinciden. Y pensé: ¿y si, al hacer el build, Angular está usando internamente el nombre del proyecto en lugar del nombre del repositorio?

Entonces, al acceder a la URL del deploy con el nombre del repositorio, evidentemente no podría encontrar los archivos... lo que causaría un buen 404.

En mi cabeza tenía todo el sentido del mundo, así que me puse a investigar.

Descubrí que en el archivo angular.json puedes establecer manualmente estos parámetros añadiendo lo siguiente:

"options": {
  "outputPath": "dist/[NOMBRE_DEL_PROYECTO]",
  "baseHref": "/[NOMBRE_DEL_REPOSITORIO]/"
}

Hice los cambios, subí el proyecto y...

Sorpresa: otro 404. 😩

Ya estaba desesperado. Probé unas cuantas combinaciones, rutas distintas, incluso nombres en minúsculas… casi doy el proyecto por perdido.

Hasta que…

Cuarto paso y solución: ¿Espera... qué estamos mandando al deploy?

Ya un poco harto, me puse a repasar conceptos.
La pipeline se ejecutaba sin errores, el build se completaba correctamente... Entonces, ¿el problema está en el deploy?

Lo siguiente que hice fue generar un build en local para ver qué estaba saliendo. En principio, todo parecía bien (aunque aquí estaba la clave, y yo aún no lo sabía).
Dentro de la carpeta dist, vi un directorio llamado browser, y ahí estaba el proyecto transpilado, listo para desplegar.
Lo abrí en el navegador: ¡todo funcionando! Bueno, salvo algún CORS... nada nuevo.

¿Entonces qué puede estar pasando?

Se me ocurrió entonces añadir unos logs al workflow para ver exactamente qué estaba subiendo:

  - name: Check output directory
        run: ls -lah dist/pokedex

      - name: Check browser directory
        run: ls -lah dist/pokedex/browser

      - name: Show index.html
        run: cat dist/pokedex/browser/index.html || echo "index.html NOT FOUND"

Y ahí lo vi, como un mazazo:
index.html NOT FOUND

Fijándome bien, caí en la cuenta de algo que había pasado por alto: la carpeta browser.

👀 Busqué información al respecto y, efectivamente, desde Angular 17, la estructura del build cambió y ahora el contenido a desplegar se encuentra dentro de esa carpeta browser.

Solo tuve que modificar el yml, apuntar bien al nuevo path, quitar los logs…
¡y por fin funcionando! 🎉

Conclusión

Después de unos cuantos tropiezos, errores 404, pruebas en directo y mucho ensayo-error, por fin logré tener mi proyecto de Angular 19 desplegado automáticamente en GitHub Pages usando GitHub Actions.
Y lo mejor de todo: sin tokens manuales ni pasos innecesarios.

Lo que parecía una simple tarea de CI/CD terminó siendo una masterclass práctica de versiones, rutas, estructuras de build y pequeños detalles que cambian según la versión de Angular.

Pero de eso se trata, ¿no? De ir aprendiendo a golpes... y luego dejarlo por escrito para no olvidarlo 😅.

¿Te ha pasado algo parecido? ¿Has tenido que pelearte con GitHub Pages o las nuevas versiones de Angular?
Cuéntamelo en los comentarios o compártelo si crees que a alguien más le puede ahorrar un buen rato.

Nos vemos en el siguiente directo, ¡o en el siguiente post! 👋

Tipar automáticamente Swagger/OpenAPI endpoints con NSwag

Altaskur — Sun, 30 Jun 2024 15:50:15 +0000

Tipar automáticamente Swagger/OpenAPI endpoints con NSwag

Tipar automáticamente Swagger/OpenAPI endpoints con NSwag
- ¿Qué es NSwag?
- ¿Qué necesitas?
- Instalación
- Configuración
- Generar Interfaces
- Final
- Redes

Si alguna vez has tenido que tipar las respuestas de tus endpoints, sabrás que muchas veces es una tarea bastante difícil y larga. ¿Te imaginas poder hacerlo de manera automática y en pocos segundos? En este artículo, te explicaré cómo usar NSwag y cómo prepararlo para añadirlo a tus proyectos frontend.

¿Qué es NSwag?

NSwag es una herramienta muy flexible que nos permite tipar automáticamente clientes API a partir del archivo de definición de OpenAPI, de una manera clara y precisa. Es especialmente útil para endpoints de cierta envergadura.

¿Qué necesitas?

NSwag está creado en C#, por lo tanto, necesitarás tener instalado el Framework .NET completo 4.6.2+ o .NET 6.0+ en tu sistema. Al instalar el paquete npm, se verificarán los requisitos necesarios y, en caso de faltar alguno, se te proporcionará un enlace directo a la web oficial de Microsoft, así que no te preocupes por eso.

Por supuesto, también necesitarás disponer de un Endpoint que cumpla con los estándares de Swagger/OpenAPI 2.0. Normalmente, estos archivos de definición Swagger se encuentran en la página de Swagger de tu endpoint, justo debajo del título.

Nos interesa el archivo .json que contiene toda la documentación de nuestro backend y con el que NSwag va a trabajar.

También disponemos de una interfaz gráfica para realizar la configuración, pero en nuestro caso nos vamos a enfocar en la generación manual a través de comandos, para así poder añadirlo al flujo de automatización.

Instalación

Ahora vamos a añadir este paquete a nuestro repositorio. Dado que esta herramienta es una ayuda al desarrollo y no tiene impacto en la versión final del cliente, la añadiremos a las dependencias de desarrollo.

npm install nswag --save-dev

Durante el proceso de instalación, si no tienes instalado el framework .NET necesario (como el Framework .NET completo 4.6.2+ o .NET 6.0+), el asistente te pedirá que lo instales. También proporcionará un enlace directo a la web oficial de Microsoft para que puedas descargarlo e instalarlo fácilmente.

Configuración

La herramienta va a consumir un archivo tipo config.nswag dónde añadiremos toda la configuración, en este artículo nos vamos a enfocar en sacar los tipados de nuestro endpoint, ya que la herramienta puede generar hasta las peticiones y los DTO del lenguaje, desde Typescript, a Angular, pasando por Jquery y C#

Voy a ponerte un archivo base que llamaremos config.nswag:

{
  "runtime": "Net80",
  "defaultVariables": null,
  "documentGenerator": {
    "fromDocument": {
      "url": "[la dirección del swagger.json de tu endpoint]",
      "output": null,
      "newLineBehavior": "Auto"
    }
  },
  "codeGenerators": {
    "openApiToTypeScriptClient": {
      "className": "{controller}Client",
      "moduleName": "",
      "namespace": "",
      "typeScriptVersion": 5.4,
      "template": "Fetch",
      "promiseType": "Promise",
      "httpClass": "HttpClient",
      "withCredentials": false,
      "useSingletonProvider": false,
      "injectionTokenType": "OpaqueToken",
      "dateTimeType": "Date",
      "nullValue": "Undefined",
      "generateClientClasses": false,
      "generateClientInterfaces": true,
      "generateOptionalParameters": false,
      "exportTypes": true,
      "wrapDtoExceptions": false,
      "exceptionClass": "SwaggerException",
      "clientBaseClass": null,
      "wrapResponses": false,
      "generateResponseClasses": true,
      "responseClass": "SwaggerResponse",
      "configurationClass": null,
      "useTransformOptionsMethod": false,
      "useTransformResultMethod": false,
      "generateDtoTypes": true,
      "operationGenerationMode": "MultipleClientsFromOperationId",
      "markOptionalProperties": true,
      "generateCloneMethod": false,
      "typeStyle": "Interface",
      "enumStyle": "Enum",
      "useLeafType": false,
      "extensionCode": null,
      "generateDefaultValues": true,
      "handleReferences": false,
      "generateTypeCheckFunctions": false,
      "generateConstructorInterface": true,
      "convertConstructorInterfaceData": false,
      "importRequiredTypes": true,
      "useGetBaseUrlMethod": false,
      "baseUrlTokenName": "API_BASE_URL",
      "useAbortSignal": false,
      "inlineNamedDictionaries": false,
      "inlineNamedAny": false,
      "includeHttpContext": false,
      "templateDirectory": null,
      "serviceHost": null,
      "serviceSchemes": null,
      "output": "src/app/api/interfaces.ts",
      "newLineBehavior": "Auto"
    }
  }
}

Asegúrate de cambiar la url del from document, tanto local cómo externa
y de cambiar el output de codeGenerators a la ruta que prefieras para guardar los typos de tu endpoint.

Generar Interfaces

Una vez tenemos el archivo de configuración podemos ejecutar nswag con el comando

npx nswag run ./config.nswag

Ahora podemos ir a la ruta de nuestro output y ver todos los tipos y enums de nuestro endpoint en nuestro caso sería src/app/api/interfaces.ts

Final

Pero esta herramienta no se queda aquí, puedes generar los DTOs, las peticiones y hasta los servicios de tu endpoint, todo de manera automática y en pocos segundos.

Si quieres saber más sobre esta herramienta, te recomiendo que visites la documentación oficial de NSwag.

¡Espero que te haya sido de ayuda! Si tienes alguna duda, no dudes en preguntar en los comentarios.

Y no te olvides de seguirme en redes sociales para estar al tanto de todas las novedades.

Redes

Twitter
Twitch
Instagram
Github
Otras redes

Crear un proyecto nuevo con Eslint, Stylelint, CommitLint y Husky

Altaskur — Fri, 21 Jun 2024 22:47:33 +0000

En este artículo vamos a ver cómo configurar tu proyecto utilizando herramientas de revisión de código y vamos a modificar Git para que podamos ejecutar estas herramientas antes de subir nuestro código al repositorio, asegurándonos de mantener unas reglas, estructuras y configuraciones que homogenicen y limpien nuestro código.

El comienzo
Formateador Airbnb
StyleLint y CommitLint
Husky
Package.json
Integración con Husky
Bonus Track: Comprobación de ramas
Repositorio de ejemplo
Final

El comienzo

Para comenzar, me centraré en el uso de Angular, esta configuración puedes adaptarla fácilmente en los frameworks más populares cómo React, Vite y Astro.

En este artículo vamos a usar la última versión de Angular disponible al momento de escribirlo, que es la 18. Para ello, comenzaremos creando nuestro proyecto usando:

ng new proyectoArticulo

Asegúrate de cambiar "proyectoArticulo" por el nombre que desees utilizar. Sigamos los pasos del Angular CLI. No es el objetivo de este artículo explicarte cómo funciona el CLI de Angular, así que te mostraré la configuración que he elegido para el proyecto:

He utilizado SCSS y no vamos a usar SSR.

Una vez finalice la creación del proyecto, pasamos a instalar la integración de ESLint con Angular usando el esquema @angular-eslint/schematics. Esta es una herramienta para el CLI de Angular, por lo que usaremos:

ng add @angular-eslint/schematics

De esta manera, al usar ng lint, directamente nos saltará ESLint.

Una vez instalado el Angular schematics, pasamos a la instalación de ESLint. Es muy popular el uso de Prettier cómo formateador de código junto a ESLint. Aunque este último puede modificarse, personalmente prefiero usar ESLint con las normas de formateo de Airbnb. Esta es una preferencia totalmente personal y es la que usaremos en el artículo.

Formateador Airbnb

Para instalar ESLint junto a las normas de Airbnb, necesitaremos un listado de paquetes:

npm install eslint-config-airbnb-base eslint-config-airbnb-typescript eslint-plugin-simple-import-sort --save-dev

Como ves, las estamos guardando en dev, ya que estas dependencias solo nos interesan en desarrollo y no tiene sentido añadirlas a la versión de producción.

¿Qué son todas estas dependencias? Hemos añadido la normativa de Airbnb a ESLint, la variante para TypeScript, y el último paquete es para ordenar las importaciones.

Una vez tengamos esto, podrás ver que se ha creado el archivo .eslintrc.json, que es el que usa ESLint para guardar su configuración.

Si utilizas “_” para declarar valores que no se van a usar, te recomiendo que añadas dentro de overrides >> rules:

"@typescript-eslint/no-unused-vars": [
  "error",
  { "argsIgnorePattern": "^_", "varsIgnorePattern": "^_" }
]

Ahora vamos a configurar la extensión simple-import-sort que hemos instalado anteriormente y, además, vamos a compatibilizar un poco las reglas de Airbnb con el convenio de Angular deshabilitando los default imports. Al igual que el paso anterior, esto va dentro de rules:

"simple-import-sort/imports": "error",
"simple-import-sort/exports": "error",
"import/prefer-default-export": "off"

Ahora añadimos a ESLint que use los paquetes que hemos descargado de Airbnb. Dentro de extends añadimos:

"airbnb-base",
"airbnb-typescript/base"

Una vez instalado ESLint, le indicaremos que ignore las carpetas node_modules y dist para evitar problemas tanto en las librerías como en el bundle de dist. Para ello, creamos el archivo .eslintignore y añadimos estas dos carpetas, similar a como haríamos con .gitignore, quedando así:

dist
node_modules

StyleLint y CommitLint

Una vez tenemos esto, vamos a instalar StyleLint y CommitLint:

npm install --save-dev stylelint stylelint-config-standard-scss
npm install @commitlint/cli @commitlint/config-conventional --save-dev

Verás que se ha añadido la carpeta de configuración de StyleLint al estilo de ESLint, pero en cambio para CommitLint no. Así que vamos a crearla:

Creamos el archivo .commitlintrc.json y dentro de este archivo debemos poner:

{
  "extends": ["@commitlint/config-conventional"]
}

Husky

Ahora vamos a instalar la herramienta que nos permite utilizar los hooks de Git para comprobar que todo nuestro código pasa las normas establecidas antes de subirlo al repositorio. Para ello, usaremos:

npx husky-init

El comando nos pedirá instalar la dependencia de Husky, por lo tanto, le decimos que sí. Una vez instalada, en el directorio raíz de nuestro proyecto tendremos la carpeta .husky con varios archivos dentro. El que nos interesa es pre-commit. Si lo abres, tendrás algo similar a esto:

# !/usr/bin/env sh
"$(dirname -- "$0")/_/husky.sh"
npm test

Como puedes ver, esto ejecutaría el comando npm test de nuestro proyecto antes de hacer el commit, y si estos presentan algún error, no nos dejará hacer el commit. Ahora nos faltaría añadir los formateadores de código.

Package.json

Ahora vamos a crear nuestros propios comandos para que Husky pueda ejecutarlos de una manera limpia. Para ello, nos dirigimos al archivo package.json y dentro de la propiedad scripts añadimos:

"lint:fix": "ng lint --fix",
"lint:scss": "stylelint src/**/*.scss"

Ahora tenemos nuestros linters preparados tanto para comprobar los archivos cómo para forzar estos cambios al subirlos al repositorio.

Integración con Husky

Vamos a añadir estas sentencias a Husky. Para ESLint es bastante sencillo, ya que solo necesitamos dirigirnos al archivo pre-commit del directorio .husky y añadir:

npm run lint
npm run lint:scss
npm run test

Tendrás algo cómo esto dentro del directorio .husky/pre-commit:

# !/usr/bin/env sh

. "$(dirname -- "$0")/_/husky.sh"

npm run lint
npm run lint:scss

Te preguntarás que pasó con CommitLint, para este último necesitamos añadirlo a través de la utilidad de comando de Husky para ello ejecutamos:

npx husky add .husky/commit-msg  'npx --no --commitlint --edit ${1}'

¿Por qué está dentro de commit-msg y no dentro de pre-commit como todo lo anterior?

El hook commit-msg se enfoca en la validación del mensaje de commit este se ejecuta después de que el mensaje de commit ha sido introducido, pero antes de que el commit sea finalizado, además de que nos permite obtener el nombre y el mensaje del commit.

Bonus Track: Comprobación de ramas

Es frecuente que no quieras subir los cambios directamente a tu repositorio y que estos sean aprobados mediante una pull request. Para esto, podemos crear nuestro propio script para comprobar en qué rama estamos y si podemos o no hacer commit.

Dentro de la carpeta .husky, añadimos el archivo prevent-commit.sh y dentro de este añadimos el siguiente código en sh:

# !/bin/sh

branch_name=$(git symbolic-ref --short HEAD)
if [[ "$branch_name" != feature* ]] && [[ "$branch_name" != test* ]]; then
  echo "Commits are only allowed on feature and test branches. Current branch: $branch_name"
  exit 1
fi

Como puedes ver, en la sentencia if he especificado que solo se pueda hacer commit en el caso de que la rama comience con feature o test, siguiendo siempre la estructura base de los conventional commits. Recuerda que puedes ampliarlo o cambiarlo según tu gusto o necesidad.

Ahora para ejecutar nuestro .sh debemos añadirlo al hook de commit-msg añadiendo la siguiente línea

bash .husky/prevent-commit.sh

Repositorio de ejemplo

Te dejo un enlace a un proyecto de GitHub vacío con la configuración que acabas de ver:

AngularConventionalCommitsTemplate

Final

Con este artículo tienes una estructura completa y avanzada del uso de linters y hooks de Git en un repositorio de Angular.

Espero que te haya sido de ayuda y que puedas aplicar estas configuraciones en tus proyectos. Si tienes alguna duda o sugerencia, no dudes en dejar un comentario.

¿Y tú? ¿Utilizas linters en tus proyectos? ¿Qué herramientas utilizas? ¡Déjame tu opinión en los comentarios!

Figma, Auto Layout

Altaskur — Mon, 01 Apr 2024 14:29:14 +0000

Figma Auto Layout

Continuamos con la serie de Figma; este tutorial es la continuación de Figma, conociendo la interfaz. Te recomiendo encarecidamente que, si no lo has visto, lo veas primero.

Figma Auto Layout
- Introducción
- Crear un Auto Layout
- Crear un frame
- Modificando el frame
- Propiedades de Auto Layout
- Flechas de dirección
- Espaciado entre elementos (Gap)
- Padding o borde interno
- Panel de alineación
  - Centrar elementos
- Barra de navegación
- Ajustar tamaño del frame a un contenedor Auto Layout
- Conclusión

Introducción

Una de las características principales de Figma es la capacidad de crear diseños escalables y hacer que los elementos se coloquen automáticamente en el contenedor.

Esta característica se llama Auto Layout y es tremendamente útil. Olvídate de tener que colocar los elementos manualmente; de esta manera, estarán perfectamente alineados y distribuidos.

Vamos a ver cómo funciona.

Crear un Auto Layout

Para indicarle a un frame que los elementos que contiene deben colocarse automáticamente, debemos seleccionar el frame y hacer clic en el botón de Auto Layout. En este ejemplo, vamos a crear una barra de navegación superior con tres elementos: un logo, un texto y un menú.

Crear un frame

Vamos a crear un frame. Podemos hacerlo haciendo clic en el icono de Frame en la barra de herramientas o pulsando la tecla F.

Siempre que creemos un frame, vamos a renombrarlo para que sea más fácil identificarlo. Es importante tener una buena convención de nombres desde el principio. En este caso, Barra de navegación. Créeme, esto es muy importante; si no cuidas bien el naming, se te va a ir el proyecto de las manos rápidamente.

Fíjate en que en la imagen de la barra izquierda de Figma, aparece el icono de una almohadilla # y el nombre del frame. Quédate con este detalle; según el tipo de elemento o las propiedades que tenga, este icono cambiará. De este modo, de un simple vistazo, podemos hacernos una idea de la disposición de los elementos.

Modificando el frame

Una vez que tenemos nuestro frame, vamos a darle un pequeño borde para poder verlo mejor, ya que ahora mismo es invisible.

Esta vez nos dirigimos a la barra de propiedades o CSS, y nos dirigimos al + de la sección de Stroke para añadir un borde predeterminado.

Ahora veremos que tiene un borde de 1px de color negro puro.

Nos vamos al panel de opciones y al igual que hicimos con el borde, nos dirigimos a la barra de propiedades y hacemos clic en el + de Auto Layout.

Propiedades de Auto Layout

Antes de irnos a las propiedades del Auto Layout, tenemos que fijarnos en algo que acaba de cambiar y que normalmente solemos pasar por alto. En el panel de propiedades del Frame, justo donde se indica el ancho W y el alto H (Weight y Height en inglés), veremos la palabra "Hug" abrazo en inglés.

Auto layout coloca el tamaño del frame adaptable de forma predeterminada.

¿Por qué abrazo? Porque nuestro frame se va a adaptar al tamaño de los elementos que contiene, "abrazándolos", comportándose como una envoltura. Vamos a cambiar esto y a decirle que queremos un ancho fijo.

Ahora que ya tenemos nuestro Frame con Auto Layout y con un ancho fijo, vamos a añadir los elementos que va a contener. Creamos tres Frames de 20 x 20, con un Fill de color negro y los llamamos Logo, Texto y Menú.

Te tiene que quedar algo así:

Una vez tengamos esto, vamos a dirigirnos al panel de propiedades y continuamos desde ahí.

Flechas de dirección

En el panel de Auto Layout, verás tres flechas de dirección: hacia abajo, hacia la izquierda y otra que parece volver al punto de inicio. Con esto te puedes ir haciendo una idea de su funcionalidad. Estas flechas le dicen al Frame de qué manera se van a colocar los elementos que va a contener.
Si vienes de un perfil de desarrollo, esta opción en CSS es igual que la propiedad flex-direction.

Orientación	Flecha	Panel	Resultado
Vertical
Horizontal
Adaptable

Como puedes ver en la tabla anterior, las flechas de dirección nos indican cómo se va a colocar y en el panel de Auto Layout podemos ver que el icono de color azul cambia según la orientación que le hayamos dado.

¿Recuerdas que te dije que te fijaras en el icono de la barra izquierda? Pues es el mismo icono que aparece en el panel de propiedades. De esta manera, podemos saber de un simple vistazo la disposición de los elementos.

Pero esto no es todo. En el panel de Auto layout, podemos ver que existen más opciones: Horizontal Gap, Horizontal padding y Vertical padding. Estas opciones nos permiten ajustar la separación entre los elementos (Gap) y el espacio que hay sobre y debajo de los elementos (Padding).

Si vienes del desarrollo, esto te sonará bastante, ¿verdad? Es exactamente el mismo comportamiento que la propiedad Flexbox de CSS.

En cambio, si vienes del diseño, cómo ves, ya te estás familiarizando con los conceptos de desarrollo sin darte cuenta, además de hacer la vida más fácil para el desarrollo. Ahora vamos a identificar estos elementos y a ver cómo se comportan.

Espaciado entre elementos (Gap)

Cómo hemos visto antes, el "Gap" es el espacio horizontal que hay entre los elementos. Para modificarlo, tenemos que hacer clic en el número que aparece al lado del icono de Gap y escribir el valor que queremos. En este caso, vamos a poner 20.

Fíjate bien mientras escribes el valor o lo estás modificando; resulta que en el elemento en sí va a aparecer unas líneas de color rosa que te indican el espacio que va a haber entre los elementos. Este detalle suele pasar desapercibido, pero es realmente útil y está presente en muchos de los elementos de Figma.

Mientras modificas las propiedades de un elemento, Figma te muestra una vista previa de los cambios, en rosa.

Con esta modificación, acabamos de provocar un desbordamiento en nuestro diseño, ya que el Frame no tiene el tamaño suficiente para contener los elementos, provocando que la parte que va sobrando se oculte.
En desarrollo, esto se conoce como overflow; en Figma, por defecto, lo tenemos en hidden, oculto.
Para cambiar esta propiedad, por ejemplo para hacer un scroll, tenemos que ir a la propiedad de Clip content y desactivarla.

De esta manera podemos ver el desbordamiento.

Clip content oculta el contenido que se desborda del frame. Es igual que la propiedad overflow de CSS.

Padding o borde interno

El padding es el espacio que hay entre el borde del frame y los elementos que contiene.
Lo podemos identificar en el panel de Auto Layout, justo debajo de gap con los iconos de un cuadrado entre líneas. Según la orientación de las líneas, nos indica si el padding es horizontal o vertical.

Además, tenemos un tercer icono; este nos permite modificar el padding de cada uno de los lados del frame de manera independiente. Si hacemos clic en el icono, veremos que aparecen cuatro campos de texto, uno para cada lado del frame.

Cómo puedes ver, el icono del cuadrado se mantiene, representando al frame, solo que ahora hay una sola línea representando el padding de cada lado.

El padding es el espacio que hay entre el borde del frame y los elementos que contiene.

Intenta jugar con el padding y el gap para entender cómo se comportan y afectan a los elementos.

Quiero recordarte que si mantienes el ratón en la propiedad que estás modificando, Figma te muestra una previsualización de los cambios que estás realizando.

Recuerda que Figma te muestra una previsualización de los cambios que estás realizando.

Panel de alineación

¿Qué ocurre si queremos centrar los elementos en el frame o queremos separarlos de manera uniforme? Pues para eso tenemos el panel de alineación, que nos permite alinear los elementos de manera uniforme, centrarlos o separarlos de manera uniforme.
Si vienes del desarrollo, esto te sonará a la propiedad justify-content y align-items de CSS.

Ahora veremos cómo se comporta el panel de alineación. Vamos a centrar los elementos en el frame y, por último, separarlos de manera uniforme. Así podremos crear nuestro menú de navegación.

Centrar elementos

El panel de alineación es muy intuitivo; dentro de él, verás que tienes distintos puntos. Cada punto representa el alineamiento de los elementos. Si queremos centrar los elementos en el frame, tenemos que hacer clic en el punto central.

Panel	Resultado

Te recomiendo que juegues con las distintas opciones para que veas cómo se comportan los elementos.

Ahora bien, necesitamos que nuestra barra de navegación se adapte a los elementos de su tamaño; de esta manera, tendremos un frame responsive teniendo un frame a la izquierda, otro a la derecha y el logotipo en el centro.

Para ello, seleccionamos el punto central y hacemos doble clic. De esta manera, los elementos se adaptarán al tamaño del frame. En desarrollo, esto es igual a la propiedad space-between de CSS.

Panel	Resultado

Aquí puedes ver que han pasado varias cosas. Aparte de alinearse los elementos adaptándose al contenedor, el gap ha cambiado a Auto, indicando esto mismo.

Barra de navegación

Ahora solo tenemos que adaptar el frame al tamaño de nuestro diseño. Recuerda que usamos el preset del iPhone 13 & 14.

Te dejo las propiedades del frame para que puedas replicar el diseño.

Ahora bien, según lo que acabamos de ver, ¿no te parece raro tener que alinear nuestra barra de navegación al frame principal? Si a nuestro frame principal le establecemos cómo auto layout, podemos hacer que nuestra barra de navegación se acomode al frame principal, haciendo ahora nuestro diseño responsive.

Solo nos quedaría decirle a nuestro frame Barra de navegación que se adapte al tamaño del frame principal. ¿Cómo hacemos esto?

Ajustar tamaño del frame a un contenedor Auto Layout

Si seleccionamos nuestra barra de navegación y hacemos clic en el ancho w (width en inglés), veremos que aparece una nueva opción, Fill container. Si hacemos clic en esta opción, nuestro frame se adaptará al tamaño del frame principal, siempre y cuando este tenga Auto Layout.

Al activar esta opción, la propiedad de ancho quedará "desactivada", y el frame se adaptará al tamaño del frame principal. ¿Probamos a cambiar el tamaño del frame principal a ver qué pasa?

Cómo puedes ver, el frame se adapta al tamaño del frame principal. De esta manera, podemos hacer que nuestro diseño sea totalmente responsive.

Conclusión

Con esto, ya tendríamos nuestro diseño responsive, con una barra de navegación que se adapta al tamaño de nuestro diseño.

¿Qué te ha parecido? ¿Te ha resultado útil? ¿Quieres que hable de algo en concreto? ¡Déjamelo en los comentarios!

Figma, Conociendo la interfaz

Altaskur — Thu, 28 Mar 2024 19:41:54 +0000

Figma, Conociendo la interfaz

Figma, Conociendo la interfaz
- Contenido de la entrada
- ¿Qué es Figma?
- ¿Por qué hacer esta entrada?
- ¿Qué diferencia a Figma de otras herramientas de diseño?
- Introducción ¿Cómo diablos consigue esto?
- ¿Cómo empezar a utilizar Figma?
- Ui del home de Figma
- Un nuevo proyecto, interfaz de Figma
- Comenzamos a trabajar en Figma
- Modificando Frames
- Alineación
- Posición
- Auto layout y Grid layout
- Capas o layers
- Fill, Stroke y Effects
- Export
- Final

Contenido de la entrada

En esta entrada vamos a explorar qué es Figma, por qué es tan popular y cómo empezar a utilizarlo. También planeo agregar más entradas explicando las distintas funcionalidades de Figma, como la creación de componentes, estilos, etc. El objetivo es proporcionar una guía en capítulos cortos y fáciles de seguir.

¿Qué es Figma?

Lo primero que debes saber es: ¿Qué es Figma? Si no has estado viviendo bajo una piedra, probablemente hayas escuchado sobre Figma, pero si necesitas una explicación, aquí va. Figma es una herramienta de diseño de interfaces que funciona como una aplicación web, lo que significa que no necesitas instalar nada en tu ordenador. Esta característica te permite trabajar desde cualquier lugar y en cualquier plataforma, siempre y cuando tengas acceso a Internet.

🫡💻 No necesitas instalar nada en tu ordenador.

¿Por qué hacer esta entrada?

Uso Figma casi todos los días y me gustaría tener una guía de referencia para consultas rápidas y para ayudar a cualquier persona que quiera comenzar a utilizar Figma.

Entrada no patrocinada 😅 que ya quisiera yo.

¿Qué diferencia a Figma de otras herramientas de diseño?

Figma tiene varias ventajas, pero la principal, en mi opinión, es su enfoque orientado a la programación. Esto significa que tiene funcionalidades que acercan el diseño al flujo de trabajo de la programación.

Introducción ¿Cómo diablos consigue esto?

Si tienes el perfil de diseño, la idea de "programación" puede intimidarte un poco 😅, pero no te preocupes, Figma está diseñado para hacerlo accesible para todos.

No te asustes, no es tan complicado.

Figma está orientado al diseño de componentes, tokens, variables, etc. 👀 Esto significa que puedes crear componentes y reutilizarlos en diferentes partes de tu diseño, además de poder crear estilos globales que se pueden modificar en un solo lugar.

Esto agiliza el trabajo y garantiza un diseño más consistente y escalable. (Olvida la necesidad de copiar y pegar el mismo botón mil veces y tener que modificarlo en mil lugares diferentes).

Realizas un cambio y se refleja en todos los lugares.

Además, Figma cuenta con una función llamada "Auto layout" que ajusta automáticamente los elementos al contenido que contienen. 🤯

Los elementos se ajustan automáticamente al contenido que contienen.

También puedes trabajar de forma colaborativa y en tiempo real con otras personas, dejar comentarios, controlar versiones y marcar elementos como listos para pasar a desarrollo o no.

Puedes trabajar en tiempo real con otras personas.

Por último, puedes preparar tus diseños para crear presentaciones interactivas sin necesidad de escribir una sola línea de código. Puedes crear prototipos, animaciones, etc., y compartirlos con cualquier persona que tenga el enlace.

Si tu perfil es de programación, tampoco te costará adaptarte a Figma, ya que comparte muchas similitudes con los flujos de trabajo de desarrollo. Personalmente, encuentro que esta familiaridad facilita mucho el proceso de diseño.

Puede parecer abrumador al principio, pero una vez que te acostumbras a trabajar de esta manera, no querrás volver atrás. Además, Figma se integra muy bien con otras herramientas de diseño y desarrollo, como LottieFiles y VSCode, así que no tienes que abandonar tus herramientas favoritas; puedes combinarlas perfectamente.

Se integra muy bien con otras herramientas de diseño y desarrollo.

¿Cómo empezar a utilizar Figma?

Voy a asumir que ya te has registrado en la plataforma de Figma. Si no lo has hecho, ¿a qué estás esperando? 😅 Dirígete a
Figma.com y regístrate.

Prefiero comenzar desde un espacio de trabajo nuevo, aunque la primera pantalla puede resultar un poco intimidante. Por lo tanto, vamos a crear un nuevo espacio de trabajo.

Vamos a crear un nuevo espacio de trabajo. 🚀

Verás algo como esto:

Ui del home de Figma

Podemos identificar tres secciones principales:

Barra de navegación izquierda: Aquí encontrarás tu perfil, tus espacios de trabajo, espacios favoritos, proyectos compartidos y grupos de trabajo.

En este momento, nos interesa principalmente la sección "Drafts", donde se guardan los proyectos que aún no has compartido con nadie.

Empezaremos a trabajar en un borrador.

Es como la unidad mínima, así que no te preocupes por la palabra "borrador" 😅

Barra de navegación superior: Aquí encontrarás botones para crear un nuevo proyecto, crear un nuevo Jamboard, importar un archivo y acceder a proyectos recientes.

No nos enfocaremos en Jamboard ni en la importación de archivos en esta entrada, así que nos centraremos en la creación de un nuevo proyecto. Si quieres que cubra estos temas en otra entrada, déjame saber en los comentarios.

Espacio de trabajo: Aquí verás todos tus proyectos, podrás filtrarlos, buscarlos, etc. En este momento, estará vacío, pero vamos a cambiar eso. Dirígete a la esquina superior derecha y haz clic en "Desing new file", luego selecciona "Drafts".

Un nuevo proyecto, interfaz de Figma

Ahora verás algo cómo esto:

Puede que veas algo ligeramente diferente, ya que tengo una configuración personalizada, pero no te preocupes, lo iremos explorando poco a poco.

Lo importante es que te familiarices con tres conceptos:

Barra de herramientas superior: Aquí encontrarás el menú de Figma, las herramientas de diseño, la opción de compartir y la opción de presentar.

Barra de herramientas izquierda: Aquí encontrarás una lista de los elementos de tu diseño, como frames, componentes, etc. Me gusta llamarlo el panel de HTML, porque es como si estuvieras viendo el código HTML de tu diseño.

Área de trabajo: Aquí es donde verás tu diseño y donde trabajarás.

Barra de herramientas derecha: Aquí encontrarás opciones de diseño, como colores, estilos, etc. Me gusta llamarlo el panel de CSS, porque es como si estuvieras viendo el código CSS de tu diseño.

Comenzamos a trabajar en Figma

Ahora que conoces la interfaz de Figma, vamos a empezar a trabajar en un diseño, veremos los diferentes elementos, los posicionaremos y les daremos estilos.

La unidad mínima de trabajo en Figma es el Frame. Un frame es un contenedor que puede ser un elemento de diseño por sí solo y puede contener otros elementos, como otros frames, componentes, textos, etc.

Para crear un frame, vamos a la barra de herramientas superior y hacemos clic en el botón "Frame", que tiene el icono de una almohadilla o hashtag (#).

Verás que la interfaz cambia, especialmente en la barra de herramientas derecha, donde verás las opciones para este elemento que aún no hemos creado, pero ya estamos viendo sus opciones.

Una de las características que más me gusta de Figma son los tamaños predefinidos que puedes utilizar, adaptados a diferentes plataformas, físicas y digitales, además de poder crear tus propios tamaños.

Elige el tamaño que más te convenga. Personalmente, seleccionaré el tamaño "iPhone 13 & 14" dentro de la categoría "Phone", ya que será más fácil hacer una captura de pantalla y compartirlo.

Esto es muy importante, y aunque no lo utilizarás ahora, es útil familiarizarse con los atajos de teclado, especialmente para elementos como el Frame que utilizarás con frecuencia.

La tecla F es el atajo de teclado para crear un Frame.

Si deseas conocer más atajos de teclado, puedes encontrarlos en el icono de interrogación (?) en la esquina inferior derecha de la interfaz.

Modificando Frames

Ahora que ya tienes un Frame, vamos a ver cómo modificarlo, es decir, cómo cambiarle el tamaño, la posición, etc.

Barra de Herramientas derecha | barra de propiedades

Vamos a analizar esta barra por secciones:

Alineación

La primera sección es la de alineación. Aquí puedes alinear el elemento con respecto a los demás, de manera similar a como lo harías en un procesador de textos o en una herramienta de edición de imágenes.

Posición

La segunda sección nos permite posicionar el elemento, cambiar sus anchos, rotarlo y aplicar un borde. Explicaré los elementos de izquierda a derecha y de arriba hacia abajo.

Los primeros elementos son los de posición según los ejes de coordenadas X e Y, es decir, la posición horizontal y vertical respectivamente.

Además de poder cambiar el tamaño del elemento, tanto de ancho como de alto, con Width (W) y Height (H) en inglés, respectivamente.

Por último, tenemos la opción de rotar el elemento y aplicar un efecto de redondeo a las esquinas.

Auto layout y Grid layout

Estas dos opciones son súper interesantes ya que te permiten alinear automáticamente los elementos. Las veremos en próximas entradas, pero por ahora no te preocupes por ellas.

Capas o `layers`

Si estás familiarizado con programas de diseño como Photoshop, Illustrator, Sketch, etc., ya sabrás a qué me refiero con capas. Si en cambio vienes de un perfil de programación, esto lo podrás entender como el método de fusión de elementos z-index y backdrop-filter en CSS.

Fill, Stroke y Effects

Relleno, Borde y efectos. Aquí podrás cambiar el color de relleno, el color del borde y añadir efectos como sombras, desenfoques, etc.

Export

Por último, la opción de exportar. Aquí podrás exportar el elemento como imagen, SVG, PDF, etc. Esto es muy útil y básico para poder compartir tus diseños con otras personas y añadirlos al proyecto de desarrollo.

Final

Con esta entrada hemos visto qué es Figma, nos hemos familiarizado con la interfaz y hemos creado nuestro primer Frame. Además, hemos visto cómo modificarlo y las diferentes opciones de diseño disponibles.

En la próxima entrada profundizaremos en cada opción y exploraremos los distintos resultados, además de ver auto layout.

Si te ha gustado la entrada, no dudes en compartirla. Y si tienes alguna duda, sugerencia o petición, déjala en los comentarios.

Siguiente paso conocer Auto Layout

TuiCSS Tutorial - parte 2

Altaskur — Mon, 11 Mar 2024 14:20:36 +0000

Segunda parte del tutorial de la librería TuiCss, En esta parte veremos los componentes de Utilidad y veremos algún ejemplo.

Estructura del tutorial

Elementos de estructura
Componentes de Utilidad [actual]
Componentes generales (por hacer)
Elementos de formulario (por hacer)
Clases utilidad (por hacer)
Ejemplos (por hacer)

Índice

Componentes de utilidad
Background
Border
Shadow
Scrollbar
Temas
Colores

Componentes de utilidad

En este tutorial veremos como alterar los elementos para añadir o eliminar características como color, fondo o sombras.

Background

Quizás una de las más importantes, añade un fondo de puntos simulando un monitor de tubo, suelen recomendar añadir la case al html para cambiar toda la página.

Tenemos catorce fondos diferentes divididos en dos bloques según el fondo de la matriz de puntos:

Puntos	Fondo
tui-bg-blue-black	tui-bg-blue-white
tui-bg-green-black	tui-bg-green-white
tui-bg-cyan-black	tui-bg-cyan-white
tui-bg-red-black	tui-bg-red-white
tui-bg-purple-black	tui-bg-purple-white
tui-bg-yellow-black	tui-bg-yellow-white
tui-bg-orange-black	tui-bg-orange-white


<!-- Estructura -->

<!-- Html -->
<html class="tui-bg-blue-black"></html>

<!-- Screen -->
<section class="tui-screen-800-600 tui-bg-blue-black">
    ...
</section>

Border

Recomendado para el componente fieldset y controlamos el tipo de borde de este componente, tenemos 4 tipos de borde:

Tipos
.tui-border-double	.tui-border-solid
.tui-border-dotted	.tui-border-dashed

Shadow

Con esta clase podemos controlar la sombra de los componentes window, panel y button. Cambiando posición, tamaño o directamente eliminar la sombra.

Posición   
.tui-shadow-left    
.tui-shadow-left-1    
.tui-shadow-left-2   
.tui-shadow-left-3    
.tui-shadow-left-4 
.tui-shadow-left-5

Tamaño
.tui-shadow
.tui-shadow-1
.tui-shadow-2
.tui-shadow-3
.tui-shadow-4
.tui-shadow-5

Eliminación
.tui-no-shadow

Scrollbar

Con las palabras de la wiki oficial

This is just applied for Google Chrome browser unfortunately.

Podemos cambiar el estilo de la barra de scroll pero sólo en Google Chrome, tenemos disponibles los siete colores de la librería:

.tui-scroll-cyan
.tui-scroll-green
.tui-scroll-red
.tui-scroll-purple
.tui-scroll-yellow
.tui-scroll-white
.tui-scroll-orange

Temas

Por defecto tenemos una serie de configuraciones para todo lo que hemos visto anterior mente, llamadas temas, tenemos seis temas disponibles:

.primary
.secondary
.success
.danger
.warning
.info

Colores

Si con esto no tienes suficiente TuiCSS nos brinda una serie de nueve colores en dos variantes; en la variante de 255 colores y la variante de 168, basadas en las aplicaciones de MS-DOS.

los colores disponibles son:


.black-[variante]
.blue-[variante]
.green-[variante]
.cyan-[variante]
.red-[variante]
.purple-[variante]
.yellow-[variante]
.white-[variante]
.orange-[variante]

Tan solo tienes que sustituir [variante] por la variante de 255 o 168 colores y puedes aplicar estos colores en todas las propiedades con el sufijo de color.

<div class="tui-panel black-255">
</div>

Podemos ponerlos en las siguientes clases:

<color>
<color>-text    
<color>-border
<color>-hover
<color>-text-hover
<color>-border-hover

TuiCss Tutorial - parte 1

Altaskur — Sun, 10 Mar 2024 18:46:59 +0000

Primera parte del tutorial de la librería TuiCss, voy a enfocar en cuatro partes:

Estructura del tutorial

Elementos de estructura [Actual]
Componentes de utilidad
Componentes generales (por hacer)
Elementos de formulario (por hacer)
Clases utilidad (por hacer)
Ejemplos (por hacer)

En esta parte veremos que es TuiCSS y los elementos estructurales.

TuiCSS

TuiCss es una librería de CSS enfocada a crear interfaces basadas en la tabla de ASCII cómo MSDOS y en Turbo Vision Framework, es un proyecto OpenSource creado por el usuario @vinibiavatti1 en GitHub con 7 colaboradores y a la fecha de este post, el último commit fue Jul 19, 2023.

Índice

Ejemplos
Elementos estructurales
- tui-screen
- tui-window
- tui-panel
- tui-divider
- tui-statusbar
- tui-table
- tui-navbar

Imagen de ejemplo

Elementos estructurales

Son todos los elementos que te ayudarán a crear tu composición, como pantallas, ventanas, divisores, barras de estado y por supuesto ¡tablas!

tui-screen

Este es el elemento principal de las vistas, con él establecemos el tamaño de pantalla que vamos a representar, lo más común es usar el tamaño de pantalla estándar de la época 800x600

No te preocupes también podemos crear diseños responsive

Elementos que añade:

/* .tui-screen */
.tui-screen{
    position: relative;
    overflow: hidden;
}

Estructura:

<!-- Screen -->
<section class="tui-screen-800-600">
    ...
</section>

Tamaños que admite:

.tui-screen-640-480
.tui-screen-800-600
.tui-screen-1024-768

tui-window

Con el podemos representar las distintas ventanas, según el estilo que quieras representar podemos combinarlo con la clase fieldset que agrega un borde al rededor.

Elementos que añade:

/* tui-window */
.tui-window{
    display: inline-block;
    position: relative;
    padding: 1px;
    box-shadow: 10px 10px #000;
}

Estructura:

<!-- Window -->
<section class="tui-window">
    ...
</section>

tui-panel

Exactamente igual que tui-window salvo que este no está pensado para representarse con un borde de la clase fieldset si no que podemos añadirle los elementos tui-panel-header y tui-panel-content

Elementos que añade:

.tui-panel{
    display: iline-block;
    position: relative;
    padding: 1px;
    box-shadow: 10px 10px #000;
}

Estructura:

<section class="tui-panel">
    <div class="tui-panel-header">
        ...
    </div>
    <div class="tui-panel-content">
        ...
    </div>
</section>

tui-panel-header

Indicado para añadir un título.
Elementos que añade:

.tui-panel-header{
    padding-top: 2px;
    display: block;
    background: #fff;
    text-align: center;
}

tui-panel-content

Añade un padding de 12px

tui-divider

Un divisor vertical, se suele representar con la etiqueta span

.tui-divider{
   display: block;
   border-bottom: 2px solid #fff;
}

<span class="tui-divider">
    ...
</span>

tui-status-bar

Está pensada para añadir acciones rápidas o texto informativo.
contiene.

tui-statusbar-divider

Añade un divisor vertical.

.tui-statusbar-divider{
    border-right: 2px solid #000 ;
    display: inline;
    margin: 0 3px;
}

<div class="statusbar">
    ...
</div>

tui-table

¡Tablas!
Como buen diseño retro no podrían faltas las tablas.

El funcionamiento es el mismo sólo tenemos que añadir la clase .tui-table aunque admite una serie de modificaciones.

Podemos añadir un hoover a la tabla, decirle que se resalten los elementos pares o cambiar la barra de separación.

.hovered-{color} striped-{color}

Colores
blue	green	cyan	white
red	purle	yellow	orange

<!-- Table hovered -->
<table class="tui-table hovered-cyan">
    ...
</table>

Ahora ya puedes continuar con la parte dos del tutorial

Componentes de utilidad

React, Animando un Texto con useRef() desde la carga del componente

Altaskur — Fri, 16 Feb 2024 16:06:40 +0000

Recientemente, quise añadir un toque animado a mi proyecto final en React, inspirado por una animación compartida por la creadora de contenido Mewtru.
Aquí está el efecto que capturó mi atención:

La idea inicial era trasladarlo de JavaScript a React, y automáticamente pensé en utilizar useRef para lograrlo. Sin embargo, como es común en el mundo del desarrollo, las cosas no siempre siguen el guion previsto, y los desafíos surgieron justo al cargar el componente.

Problema al cargar el Componente

La sorpresa y el motivo de este post, llegó al momento de cargar el componente, la consola lanzaba el mismo error.

"append is not defined divElement is null"

En un principio, sospeché de algún error de sintaxis, Sin embargo tras revisar el código y revisarlo repetidamente, el problema se mantenía con el mensaje is null.

te dejo parte del código para que veas como estaba todo definido.

const div1 = useRef(null);
const div2 = useRef(null);

useEffect( () =>{
   const words = "@property - example";

   const ANIMATION_DURATION = 4000;

   const characters = words.split("").forEach((character, index) => {
      const createElement = (offset) => {
      const div = document.createElement("div");
      div.innerText = character;
      div.classList.add("character");
      div.style.animationDelay = `-${index * (ANIMATION_DURATION / 16) - offset
      }ms`;
      return div;
  };

  div1.current.append(createElement(0));
  div2.current.append(createElement(-1 * (ANIMATION_DURATION / 2)));
});

},[]}

Esta es la raíz del problema, div1 y div2 son null siempre.

La incógnita

Mi primera suposición fue que quizás no le estaba dando tiempo al hook de "vincularse" con el contenido. Sin embargo, el contenido de useEffect() se ejecuta al inicio del componente después de que todo se ha cargado, según la documentación oficial de React:

React will generally let the browser paint the updated screen first before running your Effect.

A pesar de esto, el problema persistía, y el mensaje null seguía apareciendo. La confusión se apoderaba de mí: ¿por qué sigue siendo null?

Solución

Después de explorar múltiples fuentes en la web y consultar a distintas inteligencias artificiales sin obtener resultados significativos, finalmente encontré una solución:

En el useEffect() forzar a comprobar si los useRef() están definidos, en ese caso ejecutar el código. Te dejo el código completo:

useEffect( () =>{

    if(div1 && div2){
       const words = "@property - example";

       const ANIMATION_DURATION = 4000;

       const characters = words.split("").forEach((character, index) => {
          const createElement = (offset) => {
              const div = document.createElement("div");
              div.innerText = character;
              div.classList.add("character");
              div.style.animationDelay = `-${index * (ANIMATION_DURATION / 16) - offset}ms`;
              return div;
          };

          div1.current.append(createElement(0));
          div2.current.append(createElement(-1 * (ANIMATION_DURATION / 2)));
        }
    });

},[]}

Resolución

¡Y funcionó! 🎉🎉 el componente cargaba correctamente, y la animación entraba. Aún no consigo entender porque hay que forzar al useEffect() a que se definan los useState() si este se ejecuta después de renderizar todo. además de como consigue esa reactividad, si el useEffect() está definido para que se ejecute sólo al montar el componente.

¿Te ha pasado alguna vez, o sabes lo que está ocurriendo? no dudes en dejarlo en comentarios.

Referencias

Descubriendo la magia de las Guard Clauses

Altaskur — Mon, 05 Feb 2024 11:21:08 +0000

No me di cuenta de cómo el desarrollo Backend había cambiado mi forma de programar hasta el Jueves 1 de Febrero de 2024.

El momento de la revelación

No fue sino durante una conversación con mi profesor que me di cuenta de que no estaba utilizando la clásica estructura de if-else. Este episodio me desconcertó por completo e instigó una investigación sobre el tema. Nunca me había cuestionado el uso de esta estructura de manera consciente; simplemente la aplicaba de forma automática al verla en los ejemplos.

¿Qué estaba usando?

Descubrí que en una estructura básica de código, colocaba las negaciones al principio y cancelaba el flujo de la función con un return. A continuación, te muestro cómo lo estaba utilizando en una función para registrar a un usuario:

const singInUser = async (req, res) => {
  try {
    const { email, password } = req.body;
    const user = await Users.findOne({ email });

    if (!user) return res.status(404).json({ error: 'Usuario no encontrado' });

    const isMatch = await user.comparePassword(password);
    if (!isMatch) return res.status(401).json({ error: 'Contraseña incorrecta' });

    const token = generateToken(user.email, user.name);
    return res.status(200).json({ token });
  } catch (error) {
    console.log(error);
    return res.status(500).json({ error: 'Ocurrió un error durante la solicitud' });
  }
};

Transformar esto en un conjunto de if-else anidados crearía un laberinto de condiciones difícil de mantener. Al inicio de mi investigación no encontraba nada al respecto; sólo encontraba formas de devolver varios elementos dentro de una función, lo que se aleja completamente del objetivo.

Necesitaba un Rescate

No fue hasta que pude hablar sobre el tema con @programacon_es que me sugirió que buscara por las "Guard Clauses", y aquí comienza mi aventura.

¿Qué són las Guard clauses?

Las Guard Clauses, también conocidas como "early returns" o "return early", son estructuras de control de flujo en programación que se utilizan para mejorar la legibilidad y simplicidad del código al evitar anidaciones excesivas de condicionales. En concepto, estas estructuras se utilizan para evitar el uso de anidaciones excesivas y mejorar la simplicidad y legibilidad del código.

Pongamos un ejemplo teórico

Podemos escribir las cláusulas de error y negativas al principio, no solo mejorando la legibilidad sino también interrumpiendo el resto del código, lo que contribuye a una mejor optimización del mismo.

function validarContrasena(contrasena) {

  if (!contrasena) {
    return "La contraseña no puede estar vacía.";
  }

  if (contrasena.length < 8) {
    return "La contraseña debe tener al menos 8 caracteres.";
  }

  if (!/\d/.test(contrasena)) {
    return "La contraseña debe contener al menos un número.";
  }

  return "La contraseña es válida. ¡Bien hecho!";
}

Veamos una alternativa con if-else.

function validarContrasena(contrasena) {

  if (!contrasena) {
    return "La contraseña no puede estar vacía.";
  } else {

    if (contrasena.length < 8) {
      return "La contraseña debe tener al menos 8 caracteres.";
    } else {

      if (!/\d/.test(contrasena)) {
        return "La contraseña debe contener al menos un número.";
      } else {
        return "La contraseña es válida. ¡Bien hecho!";
      }
    }
  }
}

Aunque observamos un cambio evidente, no siempre es lo más indicado. Como en todo en programación, el abuso de estas cláusulas puede ser contraproducente y generar fácilmente el efecto contrario, generando un código sucio. Veamos también un ejemplo.

function calculateScore(player) {
  if (!player) {
    console.error("Jugador no especificado");
    return null;
  } else {
    if (!player.score) {
      console.error("Puntuación del jugador no encontrada");
      return null;
    } else {
      if (player.score < 0) {
        console.error("Puntuación del jugador negativa");
        return null;
      } else {
        return player.score * 100;
      }
    }
  }
}

¿Entonces en que casos podemos usarlo?

Es importante darle un uso moderado, en casos simples y directos teniendo en cuenta siempre el uso de otras estructuras, recuerda el uso de los comentarios en caso de ser necesario.

¿Has experimentado con Guard Clauses en tus proyectos? ¡Comparte tu experiencia en los comentarios!

Referencias

Despidiéndome de Console.log

Altaskur — Fri, 02 Feb 2024 01:37:39 +0000

El dilema

Llevaba tiempo con la idea de replantearme el uso de console.log() en mis proyectos de estudio. Las evidencias provenían de cuatro actores clave: ESLint, con sus persistentes advertencias, indicándome que no era la mejor práctica; mi propia sospecha de que debía existir una alternativa más eficiente; y, por último, la insistencia de mi profesor de entregar las prácticas sin la presencia de console.log(), emulando así un entorno de producción más estricto.

Demasiado bueno para ser cierto

Desde el principio, me limité a utilizar dos enfoques. El más rápido: /* eslint-disable no-console */ al inicio del documento. Como alternativa, prescindir completamente de su uso, mejorando así la estructura y legibilidad del código.

No nos engañemos, evitar el uso de console.log() bajo la excusa de mejorar mis habilidades de desarrollo ha sido una idea que ha alimentado mi ego durante este año y medio. Aunque seguía intuyendo que debía haber algo más. Claro, el uso de debugger estaba ahí, pero console.log() seguía siendo más simple y rápido de implementar. No me convencía completamente como alternativa directa.

History Time

Los eventos de desarrollo suelen ser oportunidades mágicas de aprendizaje. Un día, durante el OpenSourceJam en Alicante, esta revelación llegó de manera inesperada.

Evento: OpenSourceJam Alicante.
Fecha: 18 de Noviembre de 2023.

Junto a otras dos personas, contribuíamos al código abierto. Mi tarea consistía en desarrollar un pequeño crawler con Express.js y Puppeter para obtener datos de eventos Tech. Del otro lado, Noe y Cesar trabajaban en el frontend con Next.js.

La sorpresa llegó cuando Cesar, con una sonrisa pícara, anticipando que me iba a gustar lo que tenía que decirme, mencionó algo sobre mi Pull Request en GitHub. En ese momento, me encontraba abrumado y luchaba por comprender lo que estaba diciendo.

Mi curiosidad se disparó cuando, tras actualizar la rama y ejecutar el proyecto, vi por consola:

Server running on port 3000

En verde y negrita, pero sin rastro de console.log(). En ese momento, mis sospechas se confirmaron: existía una alternativa viable y eficiente. Continuamos con el proyecto, y la lección quedó grabada.

Después de un tiempo

Ha pasado un tiempo desde ese episodio y fue hoy, durante la revisión del Backend de mi proyecto final de 2ºDAW, donde tuve el flashback. Tenía mi console.log('Server running on port 3000'); junto a la cláusula /* eslint-disable no-console */ y no pude aguantar más. Me dirigí al repositorio del evento y descubrí algo muy sencillo, rápido y que implementaré como mínimo a partir de ahora.

El código

Nos encontramos en /src/utils/logger.js y podemos encontrar estas simpáticas líneas:

import chalk from "chalk";

const { log } = console;

export default {
  info: (...args) => {
    log(chalk.blue(...args));
  },
  error: (...args) => {
    log(chalk.red(...args));
  },
  warning: (...args) => {
    log(chalk.yellow(...args));
  },
  success: (...args) => {
    log(chalk.green(...args));
  },
};

¡Había deconstruido console.log() y creado su propia versión! 👀 La librería chalk.js añade colores y decoraciones a la terminal.

Terminal string styling done right

y un ejemplo de uso del mismo proyecto:

logger.info(`Saving ${records.length} events`);

El método ofrece mensajes más amigables con el desarrollador y ESLint no se queja más.

Aún así, mi curiosidad me ha empujado a encontrar formas más elegantes y prácticas como Winston y el log4js; este último me sonaba porque saltó a la palestra hace tiempo por fallas de seguridad, pero no profundicé más al respecto.

Conclusión

Despedirme de console.log() no va solo de seguir ciertas convenciones o reglas, sino de elevar la calidad y la estética del código. Continuaré con otra entrada explicando cómo voy a añadir Winston al proyecto.

¿Tienes alguna anécdota sobre la transición de console.log() a otras alternativas? ¡Me encantaría escuchar tus historias!

Enlaces:

Evento: OpenSourceJam web
Proyectos: Crawler, Frontal
Perfiles: Cesar Noe
Librerías: Chalk winston, log4js
Noticia Relacionada: Omicrono Portal de noticias