Forem: Lucho Peñafiel

I built a garage for my roomba with a ESP32.

Lucho Peñafiel — Tue, 20 Feb 2024 08:36:41 +0000

A few weeks back, my partner showed me this image, and I thought, "Alright, I can tackle this. And maybe make it a bit fancier. Challenge accepted."

Same IKEA box, different approach.

I purchased the same IKEA Hol side table, but I opted for a different strategy. The side door wasn't going to work for me because the vacuuming robot needs a clear path.

Requirements and research.

To make it cool (and a bit challenging for a non-professional like me, just a hobbyist), I set three goals for this project:

I should be able to open/close the door using Alexa.
The system should be able to detect when the robot is leaving its base and open the door.
The system should be able to detect when the robot is returning to its base and close the door.

For the first goal, I used SincrinPro, and it was a breeze. Not a big deal.

To tackle the next two goals, after exploring options, I settled on using an Infrared sensor. This way, I can determine when the robot is in or out of its base.

Proof of concept.

At this stage, it was time to code and start validating the plan.

I must say it worked quite well. The only issue I ran into is that the robot leaves the base faster than the actuator opens the door, but that's okay. I can live with it. In future versions, maybe I'll try to get another actuator that works faster.

Here you can find the code of this project.

Design and print the final PCB and the enclosure.

Once the system was tested and I was happy with it, I decided to design a PCB for it. This was my first time, so don't judge me. As I said, I'm not a pro, just a hobbyist.

After getting all the components mounted on the PCB, I designed the enclosure and 3D-printed it.

The final result turned out pretty good, and I'm more than happy with it.

Cómo usar Intersection Observer API en Next.js

Lucho Peñafiel — Mon, 18 Jul 2022 13:34:51 +0000

¡Hola! En este artículo vamos a ver cómo usar Intersection Observer API. Es una API del navegador que nos permite detectar cuando un elemento es visible en pantalla, o (y acá está lo bueno) cuando el elemento está por serlo, y con esto poder realizar alguna acción.

Hay varios casos de uso para esta API, como lazy loading de imágenes o implementar "infinite scrolling" pero en este artículo vamos a usar esta API para interactuar con elementos de nuestra UI a medida que el usuario va haciendo scroll.

En concreto 🧐 nuestro proyecto va a tener una serie de artículos y a medida que vamos avanzando por ellos, vamos a ir marcando como "activo" el título que corresponda.

Te dejo links a la demo del proyecto y al repositorio completo del proyecto en GitHub.

Empecemos

Lo primero que tenemos que hacer es crear nuestro proyecto en Next.js, y eso lo hacemos con el comando yarn create next-app.

Una vez que tenemos nuestro proyecto corriendo vamos a crear un directorio /components en el cual vamos a agregar dos componentes: Title y Article. De tal manera que queden así:

Title.js

import React from 'react'
import styles from '../styles/Title.module.css'

const Title = ({text, isActive}) => {
    return <li className={`${styles.title} ${isActive ? styles.active : ''}`}>{text}</li>
}
export default Title

Article.js

import React from 'react'
import styles from '../styles/Article.module.css'

const Article = ({ id, title, content }) => {
   return (
       <article className={styles.article} id={id}>
           <h2>{title}</h2>
           <p className={styles.content}>{content}</p>
       </article>
   )
}

export default Article

Usando nuestros componentes

Una vez que tenemos nuestros componentes, vamos a usarlos en el archivo index.js de tal manera que quede así:

import React, { useState } from 'react'
import Head from 'next/head'
import styles from '../styles/Home.module.css'

import Title from '../components/Title'
import Article from '../components/Article'

import data from '../data/data.json'

export default function Home() {
  const [activeArticle, setActiveArticle] = useState('01');
  return (
    <main>
      <ul>
        {data.titles.map(({title, id}) => {
          return <Title key={id} text={title} isActive={id === activeArticle} />
        })}
      </ul>
      <div>
        {data.articles.map(({id, title, content}) => {
          return <Article key={id} title={title} content={content} id={id} />
        })}
      </div>
    </main>
)}

Agregando la Intersection Observer API

Lo primero que tenemos que hacer es crear, enindex.js, nuestro observer, el cual recibe dos parámetros:

El primero es el call back que queremos ejecutar cuando la API detecte que el scroll está cerca del elemento a observar
El segundo es un objeto que nos permite configurar nuestro observer, podemos indicar qué tan pronto o tarde disparar nuestro call back, es decir, con qué porcentaje de visibilidad de nuestro elemento se debe ejecutar el call back.

Una vez creado nuestro observer, tenemos que indicarle qué elementos observar. Y como nuestro proyecto tiene varios artículos a observar, cada uno de ellos va a recibir por prop un observer, de tal manera que nuestro index.js quede así:

// imports..

export default function Home() {
  const [activeArticle, setActiveArticle] = useState('01');

  const handleIntersect = (entries) => {
    if (entries[0].isIntersecting) {
      setActiveArticle(entries[0].target.id);
    }
  };

  const createObserver = (target) => {
    const options = { threshold: 1.0 };

    const observer = new IntersectionObserver(handleIntersect, options);

    observer.observe(target);
  };

  return (
    <main>
      <ul>
        {data.titles.map(({title, id}) => {
          return <Title key={id} text={title} isActive={id === activeArticle} />
        })}
      </ul>
      <div>
        {data.articles.map(({id, title, content}) => {
          return <Article key={id} title={title} content={content} id={id} createObserver={createObserver} />
        })}
      </div>
    </main>
)}

Analicemos este código 🤔 .

La función handleIntersect es nuestro call back, esto quiere decir que es la función que se va a ejecutar cada vez que observer detecte que el elemento observado sea en visible.

Lo que hace este call back es tomar el ID del elemento observado y guardarlo en el state de la aplicación, el cual nos sirve para saber qué artículo es visible y así marcar como activo el título correspondiente.

Ya tenemos nuestro observer y call back creados, ahora solo nos queda usarlos. Y para eso, como dijimos anteriormente, debemos enviar por propiedad nuestro observer a cada artículo y ejecutarlo. Nuestro Article.js nos quedará de la siguiente manera:

import React, { useEffect, useRef } from 'react'
import styles from '../styles/Article.module.css'

const Article = ({ id, title, content, createObserver }) => {
    const el = useRef(null);
    useEffect(() => {
        createObserver(el.current);
    }, []);

    return (
        <article ref={el} className={styles.article} id={id}>
            <h2>{title}</h2>
            <p className={styles.content}>{content}</p>
        </article>
    )
}

export default Article

Y voilá, eso es todo 🥳.

Ya tenemos creado y configurado nuestro observer, y ya está siendo usado por cada elemento a observar.

Espero que puedas aplicar lo aprendido en este artículo en tus proyecto.

Eso es todo por ahora, nos vemos pronto 👋🏻.

¿Por dónde empezar a programar?

Lucho Peñafiel — Mon, 18 Jul 2022 13:34:41 +0000

"Quiero aprender a programar, ¿por dónde empiezo?" Esa pregunta me la hacen muy seguido y en este post voy a dejarte algunos consejos en base a mi experiencia.

Pero antes de eso, veamos algunos puntos a tener en cuenta.

Mitos y barreras

Existen mitos y creencias sobre la programación que alejan a la gente de este maravilloso mundo.

"Programar requiere mucha matemática."

Falso. La programación tiene muchas ramas o areas de especialidad, como la medicina (cirugía, dermatología, traumatología, etc.), y solo algunas de ellas requieren un mayor uso de cálculos matemáticos.

Hace unos días, en la app en la que estoy trabajando, tuve que realizar el cálculo matemático más complejo de mucho tiempo, y fue simplemente una regla de tres 😂.

"Para ser un programador/a necesitas ser súper inteligente."

Falso, total y completamente falso. Soy soy la prueba viviente de ello, soy bastante bol***. Todos podemos programar, lo único que necesitamos es tener ganas de aprender.

"Necesitas un título universitario para conseguir trabajo."

Falso. Una vez más, soy la prueba viviente de ello. Soy un desarrollador autodidacta, no tengo ningún título relacionado con ciencias de la computación y sin embargo tengo el trabajo de mis sueños ✨.

Ahora bien, esto podría verse como un caso aislado. Voy decirte que no lo es. Hoy cada vez son más las empresas que en sus ofertas de trabajo no incluyen como requisito tener un título relacionado a las ciencias de la computación. Esto es porque las empresas antes de contratarte necesitan que demuestres tus conocimientos y habilidades, y no que un título lo haga por vos. ¿Cómo se logra esto? Generalmente las empresas te van a pedir un portfolio con tus trabajos o te va a dar un challenge para resolver, o incluso ¡ambas cosas!

Lo que quiero decir con todo esto, no es que no tienes que ir a la universidad, en absoluto. Lo que digo es que hoy existe otra alternativa, y es 100% válida. Y una pequeña aclaración, no es el camino fácil, vas a necesitar estudiar, y mucho, pero vas a poder hacerlo a tu tiempo y ritmo.

¿Por qué querés programar?

¿Qué es lo que te motiva a querer programar? ¿Tienes una idea que quieres llevar a delante? ¿Querés hacer un cambio en tu carrera profesional?

No importa cuál es el motivo por el cual querés aprender a programar, todos son válidos. Incluso si lo querés hacer porque escuchaste que los salarios suelen ser altos. ¡Está perfecto!

Pero sí es importante que tengas claro que es lo que te motiva o qué querés hacer. Como dije antes, hay muchas ramas dentro del mundo de la programación, algunas con más oferta laboral que otra, algunas con curvas de aprendizaje más chica que otras, algunas con salarios más altos que otras.

Insisto, no es importante el motivo, pero si es importante que lo tengas claro, porque eso te va a ayudar a al principio.

Ahora si...

¿Por dónde empezar?

El mejor consejo que puedo darte es que encuentres un mentor/a que te guíe en tus primeros pasos. Para eso existen un montón de comunidades a las que te puedes unir y encontrar un mentor en función de lo quieres hacer, como Frontend Cafe, una comunidad de habla hispana que está en crecimiento o el Club de Chicas programadoras del cual soy parte.

Si no sabes muy bien qué es lo que querés, la programación web es un muy buen primer paso, ya que con pocas herramientas puedes ver resultados en poco tiempo. Esto es importante porque ver el resultado de las cosas que vas creando te va a dar motivación para seguir aprendiendo más y más cosas y quién te dice, a lo mejor la programación web es lo tuyo! 😉

Pero, si después de un tiempo, te das cuenta que definitivamente no lo es y decides cambiar, ¡puedes hacerlo! Puedes seguir probando con otros lenguajes u otras herramientas hasta que encuentres con lo que realmente te sientes más cómodo o cómoda. Y todo ese tiempo no es tiempo perdido, aprendiste muchas cosas y por sobre todo, aprendiste a identificar qué es lo que te gusta.

Eso es todo por ahora, nos vemos pronto 👋🏻.

Frontend developer: ¿Sólo debe maquetar?

Lucho Peñafiel — Mon, 18 Jul 2022 13:34:27 +0000

¡Hola! En este post quiero hablar sobre la pregunta ¿un frontend developer, sólo debe maquetar? y mi opinión sobre ella.

Antes de responder la pregunta, veamos algo de historia y de dónde surge esta duda. Hasta hace unos años, cuando el 99.99% de los sitios webs estaban construidos en PHP, el desarrollador tenía un perfil más fullstack (tema que veremos en otro post). Generalmente se construían web apps monolíticas donde PHP se usaba como generador de plantillas. Entonces, en ese contexto, o eras un desarrollador que hacía la maqueta y la lógica, o solo te encargabas del HTML y CSS, y el backend developer se encarga de desmenuzar ese código y ponerlo en las vistas de la aplicación.

Pero hoy, en la mayoría de los casos y para alegría de muchos, la cosa es diferente. ¿Un frontend developer debe maquetar? ¡Por supuesto! Debe sentirse extremadamente cómodo con HTML y CSS, pero desde mi punto de vista, eso es solo la base. Veamos algunas tecnologías y responsabilidades que entiendo que un frontend developer hoy en día debe dominar:

HTML

Lucho, ¿me estas tomando el pelo no? Pues no, HTML es un lenguaje sencillo de aprender pero que tiene muchos detalles, y no todos los conocen y dominan el arte de usarlos correctamente. Cuando digo "usarlo correctamente" me refiero desde definir el lenguaje de la página hasta evitar cosas como la divitis (divitis: dícese del uso indiscriminado del tag HTML <div>)y escribir HTML semánticamente correcto.

CSS

Parece una obviedad que CSS esté en esta lista, pero como dije más arriba, junto con HTML son las bases de un frontend developer. Debes sentirte cómodo usando media-queries, flex-box y grid.

JavaScript

Ahora sí se va poniendo interesante. Cuando digo JavaScript no me refiero a algún framework de moda como React, Angular, Vue, etc, me refiero a entender cómo funciona el lenguaje, entender the good parts y the tough parts.

No me mal interpretes, no estoy diciendo que no sea importante saber React, lo que digo es que tal vez en unos años estemos hablando de React como hoy lo hacemos de jQuery, y ¿qué tienen en común esas dos tecnologías? JavaScript.

Hoy JavaScript no solo se usa en la web, tiene muchos usos y ¡cada vez son más! Por lo que recomiendo que entiendas cómo funciona este lenguaje. Para esto a continuación dejo dos recursos que a mi me ayudaron bastante a lograr eso:

SEO

¿Por qué necesitas saber de SEO (del inglés Search Engine Optimization)? Porque en el 99% de los casos vas a querer que la web que estas construyendo sea visitada por la mayor cantidad de usuarios posibles.

Probablemente hayas entrado en discusiones eternas con equipos de marketing sobre SEO o algún cliente te haya dicho algo como "quiero que mi web aparezca primero en Google", y lograr que un sitio web se encuentre entre los primeros puestos de los resultados de búsquedas depende de muchos factores y de un gran y largo trabajo en equipo.

En este post no entraremos en detalle sobre todos los aspectos del SEO, pero es importante que conozcan los aspectos básicos del mismo y las buenas prácticas que contribuyen a un buen SEO. Comparto una guía de MOZ para ayudarles con esto.

Y en el caso de que luego quieras dar un salto más profundo sobre este tema, te recomiendo leer sobre datos estructurados.

Performance

A mí me gusta usar la frase "cuando navego un sitio web, me gusta sentir el viento en la cara" haciendo alusión a que el sitio web debe andar muy rápido. Pero la performance no es solo hacer que los sitios webs sean rápidos, sino también consiste en hacer que los procesos lentos parezcan rápidos.

Probablemente pienses que tu sitio web anda muy rápido, y tal vez así sea, pero debes entender que siempre hay margen para mejorar, la performance es algo con lo que debes estar comprometido a largo plazo. Para esto hay un muchas cosas que se deben optimizar, como imágenes, videos, fonts, renderizado, request y largo etc. A continuación dejo dos guías, con contenido de excelente calidad, que van desde conceptos básicos (cómo funciona internet) a detalles súper minúsculos pero súper importantes.

Accesibilidad

La accesibilidad no debe entenderse como una feature de tu sitio web, sino como algo integral del mismo.

Te invito a que mires mi post Accesibilidad: breve introducción hacia una web inclusiva en el cual introduzco los conceptos básicos y dejo recursos para profundizar más sobre el tema.

Nice to have

De mas está decir que todo lo que puedas aprender siempre es bienvenido, pero para ir terminando este post dejo una lista con otros temas que al dominarlos harán que des un salto de calidad como frontend developer:

Unit testing
Docker
CI/CD

Mejora cada día

Estudiar y dominar los temas mencionados anteriormente es un camino largo y puede llevar tiempo, mi intención no es agobiar, sino darles una guía con los temas y herramientas que a mí me hubiera gustado tener cuando entré en este mundo.

Y como último consejo que puedo darte es que seas curiosa/o, investiga, lee y aprende algo nuevo cada día. Como reza la famosa frase, nuca pares de aprender.

Eso es todo por ahora, nos vemos pronto 👋🏻.

Cómo implementar variable fonts

Lucho Peñafiel — Mon, 18 Jul 2022 13:03:32 +0000

Antes de aprender a implementar variable fonts, tenemos que entender qué son, y para esto primero debemos entender la diferencia entre estilo tipográfico y familia tipográfica.

Un estilo tipográfico es un tipo de letra único y específico, como puede ser regular o bold.

Un estilo tipográfico es un tipo de letra único y específico, como puede ser regular, o regular italic, o bold italic.

Dicho esto, podemos definir a las variable fonts como un solo archivo que contiene todos los estilos. Es decir, podemos tener la familia entera, dentro de un solo archivo.

Ahora si, vamo a codea.

1) Descargar una variable fonts.

Para este ejemplo vamos a descargar Roboto Mono desde Google Fonts.

Hacemos click en el botón "Download family", eso descargará un archivo comprimido.
Descomprimimos el archivo.
Vamos a tener un folder llamado Roboto_Mono y en su raíz un archivo RobotoMono-VariableFont_wght.ttf. Ese es nuestro archivo!

2) Definir la variable fonts.

Una vez que tengamos descargada nuestra font, necesitamos definirlas en nuestro proyecto y para eso usamos la regla @font-face de CSS de tal manera que nos quede algo así:

@font-face {
  font-family: 'Roboto Mono';
  src: url('/fonts/RobotoMono-VariableFont.ttf') format('truetype-variations');
  font-weight: 100 700;
}

Del código anterior, tienes que en cuenta dos cosas:

Si bien es un archivo .ttf el format es levemente distinto al que estamos acostumbrados.
En la property font-weight definimos el rango en el cual podemos mover el peso de la font. Acá no podemos definir cualquier valor, sino los que la font acepte. Google Fonts nos indica cuales son estos límites.

3) Usar las font definida.

Ya descargamos nuestra font y ya está definida, lo que resta simplemente es utilizarla y esto se hace igual que con cualquier otra font.

Por ejemplo:

p {
  font-family: 'Roboto Mono';
  font-weight: 548; /* Acá podemos usar cualquier valor entre 100 y 700 */
}

4) Optimizar, siempre optimizar.

Si llegaste a este punto sin problemas y ya tienes tus variable fonts andando, te recomiendo que pases por el post en el que doy algunos consejos sobre cómo optimizar tus fonts.

Web Performance: Imágenes

Lucho Peñafiel — Mon, 18 Jul 2022 10:39:18 +0000

Las imágenes representan al rededor del 50% del ancho de banda de un sitio web (ref.), por eso es que en este artículo vamos a hablar de ellas.

Veamos algunos puntos a tener en cuenta.

¿Realmente necesitas una imagen ahí?

Una imagen vale más que mil palabras. Seguramente escuchaste esa frase, y es una gran verdad, como también lo es el hecho de que un diseño simple y concreto transmite mejor lo que queremos decir, y performa mejor 😉.

Entonces, lo primero que debemos preguntarnos (o preguntarle a nuestros diseñadores) es si ese componente necesita de forma imperativa una imagen para funcionar.

Tal vez esa imagen podría ser reemplazada por un color plano, o un gradiente, y en ambos casos podríamos generar esto con CSS y ahorrarnos un montón de bytes de esa imagen.

Ojo, no estoy diciendo que elimines todas las imágenes de tu sitio web, sino que encuentres un equilibro entre el uso de las mismas y otros recursos.

Si luego de analizar las alternativas, llegas a la conclusión de que si o si necesitas una imagen ahí, perfecto, ¡tienes mucho trabajo que hacer!

Formatos

Cuando decidimos trabajar con imágenes, es muy importante que definamos el formato de la misma. Veamos algunos formatos y sus características:

JPG: se trata de un formato de imágenes optimizado. Tiene perdida de calidad.
PNG: se trata de un formato que además de admitir transparencias preserva la calidad de la imagen, pero suelen ser archivos muy pesados.
WebP: se trata de un formato relativamente moderno que fue impulsado por Google. Este formato acepta transparencias, no tiene perdida de calidad y se trata de archivos muy pequeños. Es el formato altamente recomendado y ya la mayoría de los browsers lo implementan. Ver compatibilidad.

Para asegurarte de que todos tus usuarios van a visualizar correctamente las imágenes, incluso los que visiten el sitio desde navegadores antiguos, puedes darle opciones de carga al browser mediante la etiqueta <picture> de la siguiente manera:

<picture>
  <source
    srcset="gatitos.webp"
    type="image/webp"
  />
  <source
    srcset="gatitos.jpg"
    type="image/jpg"
  />
  <img
    src="gatitos.jpg"
    alt="Gatitos jugando con una pelota."
    {* ¡SPOILER ALERT! *}
    loading="lazy" 
  />
</picture>

Dimensiones

Cómo las imágenes se cargan de forma asincrónica y continúan cargándose después de la primera pintura del DOM, si sus dimensiones no se definen antes de la carga, pueden provocar saltos o "reflujos" en el contenido de la página. Y esto tiene dos implicancias negativas:

El navegador debe volver a pintar el DOM y a realizar nuevos cálculos de los elementos que están a continuación de la imagen cargada.
Estos saltos son molestos para el usuario y generan una mala experiencia.

Ejemplos:

Imagen sin definición de tamaños genera "reflow" en el contenido.

Imagen con tamaños definidos no genera "reflow".

Carga diferida

Supongamos que nuestra página tiene tanto contenido que el usuario necesita hacer varios scrolls antes de llegar al final de la misma. Supongamos también que el usuario al ingresar, hizo click en alguna de las opciones del menú y navegó hacía otra página.

Entonces las imágenes que están en los componentes que solo se visualizan al hacer scroll el usuario nunca las vio, pero las tuvo que descargar igual, ¿no? Hm 🤔.

Para resolver este problema es qué tenemos que hacer uso de la carga diferida de imágenes, es decir, indicarle al browser que cargue las imágenes solo si el usuario las necesita. ¿Cómo hacemos esto? Tenemos dos maneras:

Los navegadores modernos (ver compatibilidad) implementan de forma nativa la carga diferida de imágenes, y para esto debemos usar el atributo <img loading="lazy" src="gatitos.jpg" alt="Gatitos jugando con una pelota" />. De esta manera, el browser solo cargará dicha imagen cuando el usuario se encuentre cerca de ella.
Haciendo uso de la API del navegador Interserction Observer, la cual nos permite hacer lo mismo que el punto anterior pero "programáticamente". Te dejo un link para que veas la documentación de esta API.

CSS

Muchas veces usamos imágenes como fondos desde CSS. No está mal hacer eso, en absoluto, pero te dejo algunas recomendaciones a tener en cuenta para cuando lo hagas:

El browser asigna una prioridad de carga más alta a las imágenes referenciadas en elementos <img> que las imágenes referenciadas desde CSS.
Las imágenes referenciadas desde CSS son invisibles a los lectores de pantalla, por lo tanto dichas imágenes no existirán para algunos usuarios.
Si el navegador ha determinado que una regla CSS que involucra un recurso externo no se aplica al documento como está construido actualmente, el navegador no lo solicita. Es decir, si defines una imagen dentro de una media query, esta solo se cargará cuando se aplique esa regla.

Y eso es todo por ahora, nos vemos pronto 👋🏻.

Web Performance - Cómo optimizar tus tipografías

Lucho Peñafiel — Fri, 20 Nov 2020 10:47:44 +0000

¿Por qué vamos a hablar de fuentes? Las fuentes y tipografías están en la web desde sus inicios, porque para esto fue creada, para compartir documentos.

Con el paso del tiempo se fueron agregando elementos de diseño como imágenes, grillas y fuentes personalizadas. Hoy en día no existe sitio web que no contenga texto, y en la gran mayoría estos se renderizan con fuentes personalizadas.

Entonces podemos afirmar con bastante seguridad que las fuentes son un recurso importante y debemos prestarle atención.

Pero, ¿cómo podemos hacer para mejorar la performance sobre este tema? Veamos algunos puntos a trabajar.

Self-hosted

Las fuentes deben ser self-hosted. Es decir, las fuentes deben ser parte de nuestro proyecto y debemos tratar de evitar a toda costa cargar fuentes de CND externas como por ejemplo de Google Fonts.

¿Por qué? Porque traer recursos desde orígenes externos genera nuevas conexiones HTTP y varios viajes de ida y vuelta a ese origen.

¿Viajes de ida y vuelta? What? 🤔 Te recomiendo este artículo si no sabes de que estoy hablando.

Subsetting & convert format

Los archivos de fuentes suelen ser super pesados. Cuando se descargan de Google Fonts generalmente una sola variante tipográfica pesa aproximadamente 250kb. Si necesitamos 4 variantes como regular, light, regular italic y bold por ejemplo, nuestro usuario debe descargar 1mb solo para leer el contenido. 😱

Entonces, lo primero que podemos hacer es un subsetting de las fuentes, es decir, eliminar todos lo glifos o caracteres que nada tienen que ver con el idioma del sitio que estemos construyendo. EJ: generalmente todo lo que no sea latín.

Ejemplo de la fuente Roboto

En este link te dejo una herramienta en linea para esto.

Una vez que limpiamos nuestras fuentes, podemos convertirla a formatos que estén optimizados para web, como WOFF y WOFF2.

Siempre debemos evitar el uso de fuentes TTF y EOT porque son archivos que por defecto no están comprimidos. El uso de este tipo de fuentes debe ser solo como fallback para dar soporte a navegadores antiguos.

Acá dejo otra herramienta en línea para esto.

Luego de aplicar un subsetting y convertidas a un formato optimizado para web, un archivo va a estar pesando entre 15kb y 20kb, una reducción impresionante. 😎

Preload

Bien, pasamos de tener un archivo de 250kb a un archivo que no supera los 20kb. OK, pero esos 20kb de todavía nuestro usuario tiene que descargarlos.

Para que esta descarga suceda lo antes posible, podemos hacer un preload a nuestro archivo de fuente para indicarle al navegador que se trata de un recurso prioritario y que empiece a cargarlo cuanto antes.

Ejemplo:

<link rel="preload" href="/fonts/roboto.woff2" as="font" type="font/woff2" crossOrigin="anonymous" />

font-display

Ya tenemos nuestras fuentes optimizadas e hicimos un preload de las mismas para que estén disponible lo antes posible.

Pero puede pasar que el contenido se pinte y por algún motivo la fuente todavía no se cargó. Entonces ¿el usuario no va a poder leer el contenido de nuestro sitio hasta que la fuente se cargue?. Y, ¿si la fuente se demora? o ¿nunca se carga?

Veamos un poco cómo funcionan los distintos navegadores en cuanto a la estrategia de renderizado de fuentes.

Safari oculta el texto hasta que la fuente se haya descargado. Chrome y Firefox ocultan el texto por 3 segundos, si en ese tiempo la fuente no se cargó, renderizan el texto con la fuente del sistema hasta que la fuente personalizada esté cargada.

En cualquiera de estos casos el usuario va a ver la pantalla en blanco por un tiempo.

¿Cómo podemos resolver este problema? ¡CSS al rescate! 🦸

La propiedad font-face sirve para indicarle al navegador qué estrategia seguir en cuanto a al renderizado de fuentes.

Los valores que acepta esta propiedad son auto, block, swap, fallback, optional. Pero el valor que nos interesa es swap, porque le indica al navegador que muestre el texto de manera inmediata con las fuentes del sistema, y cuando la fuente personaliza esté lista para usarse, haga el reemplazo.

Ejemplo:

@font-face {
  font-family: 'Roboto Mono';
  src: url('/fonts/RobotoMono-Regular.woff2') format('woff2');
  font-weight: 400;
  font-display: swap;
}

De esta manera nuestro usuario va a poder leer el contenido de nuestro sitio de manera inmediata, sin tener que esperar.

Variable fonts

Y cuando creías que ya no podías optimizar más, aparecen las variable fonts o fuentes variables.

Pero antes de definir que son las variable fonts, debemos entender la diferencia entre estilo tipográfico y familia tipográfica.

Un estilo tipográfico es un tipo de letra único y específico, como puede ser regular, o regular italic, o bold italic.

Una familia tipográfica es el conjunto de estilos.

Ahora que ya tenemos claro está diferencia, podemos definir a las variable fonts como un solo archivo que contiene todos los estilos. Es decir, podemos tener la familia entera, dentro de un solo archivo.

Eso es todo por ahora, voy a estar subiendo más artículos de web performance ⚡️

Nos vemos pronto 👋🏻

Accesibilidad: breve introducción hacia una web inclusiva

Lucho Peñafiel — Sat, 24 Oct 2020 09:51:18 +0000

Muchas veces al hablar de accesibilidad lo primero que pensamos es en hacer una sitio para personas con capacidad visual totalmente nula. Esto es correcto, pero solo en parte. ¿Por qué? Porque la accesibilidad consiste en que cualquier persona pueda usar e interactuar con nuestra web, sin depender de sus capacidades físicas.

En este artículo vamos a hablar sobre 4 puntos importantes en los que puedes trabajar para mejorar la accesibilidad de un sitio web:

1. Color y contraste

Trabajar sobre este punto significa lograr que el contraste de luminosidad entre el texto y el color del fondo sea lo suficientemente bueno para que el texto se pueda leer sin dificultad alguna.

Para medir si los textos son accesibles puedes usar las herramientas de desarrollador que provee Google Chrome.

Al posicionarte sobre un texto, Chrome te indica el de puntaje de contraste y con una marca verde si pasa accesibilidad.

Puntos a tener en cuenta:

Revisa tus textos y ajusta el color o tamaño de los mismos.
Puedes agregar sombras o fondos a los textos para generar más contraste.
No uses únicamente el color para transmitir información. Por ejemplo: si quieres indicar que hay un error en un input, no solo pintes sus bordes de rojo, sino también agrega un icono o algún mensaje.

2. Navegación por teclado

Cualquier usuario de nuestro sitio debe poder navegar e interactuar con él solo con el teclado, es decir, sin mouse o trackpad.

Abre tu sitio y pulsa la tecla tab para ir pasando de elemento en elemento y vas a comprobar si todo lo que haces con el mouse, puedes hacerlo con el teclado.

Puntos a tener en cuenta:

Nunca quites los estilos por defecto del focus. Si no te gustan, cámbialos por otros, pero nunca los quites.
Sí tienes un modal, arma un array con los elementos focuseables y genera un loop entre ellos. Al cerrar el modal vuelve el focus al mismo elemento que lo abrió.
Intenta diseñar la navegación por teclado.

3. HTML semántico

Debemos usar las configuraciones correctas y etiquetas apropiadas para el contenido apropiado.

Puntos a tener en cuenta:

Definir el lenguaje correcto del documento es muy importante para los lectores de pantalla.
Usar heading (h1, h2, h3, etc) de manera correcta, es decir, que el título sea grande no significa que siempre va a ser un h1.
El atributo alt de la etiqueta <img> debe contener un texto descriptivo de la imagen, ya que esto es lo que leerá el screen reader. Si el texto se coloca todo en mayúsculas, el lector de pantalla leerá letra por letra, y si se deja vació, el lector de pantalla omitirá esta imagen.
Usar las etiquetas <a> solo para navegaciones, no para acciones.
Usar <button> para acciones (abrir un modal, play de un video, etc) y no para navegar.
Evita bloquear el zoom en dispositivos móviles, piensa en mí, que ayer me recetaron anteojos nuevos 🤓.

4. Mejora día a día

Mejorar la accesibilidad de un sitio web no es algo que se logre de un día para otro, ni es algo que se hace una sola vez y ya. Debemos tomar la responsabilidad de mejorar continuamente la accesibilidad de nuestro sitio, ¡tus usuarios lo van a agradecer!

Para esto, les comparto una herramienta para analizar la accesibilidad de un sitio y una guía en la que puedes profundizar sobre estos y más temas de accesibilidad.

Eso es todo por ahora, nos vemos pronto 👋🏻.

Docker 101: ¿Qué es Docker y para que se usa?

Lucho Peñafiel — Mon, 28 Sep 2020 22:42:49 +0000

Antes de definir qué es Docker, quiero contarles un problema que tuvimos en un proyecto en el que estuve trabajando.

Con el equipo empezamos configurando nuestro proyecto, definiendo la arquitectura, luego pasamos a la etapa de desarrollo de componentes, test, etc etc. Cuando llegó el momento de hacer un deploy en los ambientes del cliente, nos enteramos que todo ese proceso lo hacían a mano. Entonces, con la idea de que quién vaya a realizar esos deploy lo haga de la manera más fácil posible generamos una documentación de cómo clonar el proyecto, cómo instalar las dependencias y como ejecutarlo.

Una vez realizado el deploy, nos encontramos con la sorpresa de que nuestra app no corría como debía correr. Luego de debuggear un rato detectamos que el servidor donde estaba corriendo la app tenía instalado la v.14 de Node.js, y nuestra app tenía un lockdown a la v.12 lo que generaba algunos problemas de compatibilidad.

¿Por qué les cuento esto? Porque esto es uno de los típicos problemas que Docker viene a prevenir que sucedan.

Ahora si...

¿Qué es Docker?

Docker puede definirse como una forma de empaquetar software para que pueda ejecutarse en cualquier hardware.

Siguiendo el caso anterior, Docker nos permite generar un paquete que contiene todo lo necesario, código fuente, configuraciones y las dependencias, para que nuestra aplicación funcione de la manera adecuada.

Sus principales partes

Docker tiene un montón de partes muy interesantes y útiles, como los volumens, pero en este artículo nos enfocaremos solo en las principales, que son:

Dockerfile: el Dockerfile es un archivo que sirve para indicarle a Docker cómo se debe construir la imagen del proyecto. En otras palabras, es la receta que Docker usa para generar un paquete con nuestra aplicación.
Image: es un template para ejecutar el proyecto en cualquier contenedor. Una imagen de Docker es nuestro paquete.
Container: un container es básicamente, una imagen en ejecución.

¿Cómo dockerizar?

Lo primero que tenemos que hacer es generar nuestro proyecto. Vamos a generar un simple archivo html y un server en express para servir este archivo.

Para esto, dentro del directorio donde vamos a trabajar, iniciamos un nuevo proyecto con npm init y dejamos todas las configuraciones por defecto, de tal manera que nos quede un package.json así:

{
  "name": "docker101",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Luciano Peñafiel",
  "license": "ISC"
}

Lo siguiente que vamos a hacer es crear un archivo index.html con un simple encabezado y lo colocaremos en un directorio que lo vamos a llamar build.

<!DOCTYPE html>
<html lang="es">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Docker 101</title>
</head>
<body>
    <h1>Hola mundo!</h1>
</body>
</html>

A continuación instalamos express ejecutando npm i express y creamos un archivo server.js que va a ser el encargado de servir nuestro html y agregamos un script en nuestro package.json para levantar este server.

const express = require("express");
const app = express();

app.use(express.static("build"));

app.get("/", (req, res) => {
  res.send("ok");
});

app.listen(3000, () =>
  console.log(`App listening on port http://localhost:3000`)
);

{
  "name": "docker101",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
        "start": "node server.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Luciano Peñafiel",
  "license": "ISC"
}

Listo, ya tenemos nuestra app. Ahora solo ejecutamos el comando npm start y vamos a tener ver nuestra app corriendo en el puerto 3000.

¿Y Docker?

Ahora llegó el momento de trabajar con Docker, y lo primero que tenemos que hacer es instalarlo desde la web oficial de Docker.

Una vez instalado y corriendo, ejecutamos en nuestra terminal el comando docker ps para ver todas las imágenes que están corriendo actualmente. De momento, no deberíamos tener ninguna, y obtener una respuesta así:

Lo siguiente es construir nuestro Dockerfile y para esto creamos en la raíz de nuestro repositorio un archivo con ese nombre (y sin extensión) con el siguiente contenido:

FROM node:12-alpine

WORKDIR /usr/src/app

COPY package*.json ./

RUN npm ci

COPY . ./

CMD ["npm", "start"]

Entendamos un poco este archivo. Primero que nada es muy importante entender que cada instrucción funciona como una capa, y Docker intentará mantener en caché cada una de ellas si nada se ha modificado, por lo tanto es recomendable poner primero aquellas capas que menos van a cambiar a lo largo del proyecto.

Todo Dockerfile empieza con el comando FROM que sirve para indicarle a Docker cuál va a ser la imagen base de nuestra imagen. Sí, cada imagen parte de otra imagen.

Lo siguiente que tenemos hacer es agregar el código fuente de nuestra app a la imagen. Para eso primero definimos la raíz del directorio usando la instrucción WORKDIR. Todo lo siguiente que hagamos va a comenzar desde esa ruta.

Luego vamos a instalar todas nuestras dependencias usando el comando COPY que recibe dos argumentos, primero lo que queremos copiar y al último la ubicación donde queremos copiar esos archivos.

Luego vamos a instalar todo lo que tenemos en nuestro package.json con el comando RUN npm ci.

Una vez instaladas todas nuestra dependencias, copiamos el código fuente de nuestra app. En este punto se presenta un problema, y es que en los pasos anteriores instalamos nuestras dependencias, lo que generó dentro de la imagen un directorio node_modules y al copiar todo lo que tenemos en nuestro código fuente, vamos a sobre escribir esos módulos y no es algo que queremos que suceda. Para esto creamos un archivo .dockerignore (si, igual que un .gitignore) y colocamos dentro node_modules.

Y por último le indicamos a Docker como debe inicializar nuestra app con la instrucción CMD, que es la instrucción por defecto de Docker para iniciar una imagen.

Una vez creado nuestro Dockerfile, ahora sí vamos a generar una imagen del proyecto, y esto lo hacemos con el comando docker build -t docker101:v1 .

¿Qué hace esto? Bien, docker build va a generar nuestra imagen, y con el flag -t docker101:v1 le asignamos una etiqueta a nuestra imagen y le indicamos que está en la versión 1.

Ahora si corremos el comando docker images vamos a ver todas las imágenes que tenemos en nuestro Docker con sus respectivos IDs.

Y por fin llegó la hora de ejecutar nuestra app dentro de un contenedor, esto lo hacemos con el comando docker run -p 3000:3000 docker101:v1 y voila, tenemos nuestra app corriendo en el puerto 3000.

¿Qué sigue?

La idea, siguiendo el ejemplo del principio, es entregarle a nuestro cliente todo empaquetado. Y ¿cómo hacemos esto? Bueno, hay muchas maneras de hacerlo, pero la más usada es subiendo nuestra imagen a un registry de imágenes como los es Docker Hub o GitHub Packages para que luego nuestro cliente pueda descargar la imagen.

Eso es todo por ahora, nos vemos pronto 👋🏻.