Document your stuff

Me gusta pensar que este espacio es un reflejo del principio de IndieWeb; un espacio que me sirve para documentar lo que voy aprendiendo. Aquí vas a encontrar notas sobre front-end, enfocado en HTML, CSS, accesibilidad, entre otras cosas; te podés suscribir al RSS feed.

Glen Maddern - Styling React Apps with Styled Components

Repasando styled-components volví a ver el video de Glen Maddern, Styling React Apps with Styled Components, donde hace un show & tell de las motivaciones que llevaron a la creación de styled-components y además, repasa los diferentes features.

Es interesante volver a ver hacia atrás y ver la evolución de las herramientas que usamos y ver como algunos temas, CSS-in-JS por ejemplo, se van volviendo parte del flujo normal de trabajo; igual espero que de manera nativa podamos tener las mismas ventajas que ofrece el no tan querido CSS-in-JS.

Robustness and least power

As a general rule, it’s always worth asking if you can accomplish something with a less powerful technology:

  • Instead of using JavaScript to do animation, see if you can do it in CSS instead.
  • Instead of using JavaScript to do simple client-side form validation, try to use HTML input types and attributes like required.
  • Instead of using ARIA to give a certain role value to a div or span, try to use a more suitable HTML element instead.

Debug images without alt attribute with CSS

Pequeño tip, debuguear imagenes que no tienen el atributo alt usando CSS.

img:not([alt]) {
  outline: 2px dashed pink;
}

Responsive Typography - Jamstack Conf

Estoy tratando de ponerme al día con CSS, y hoy me encontre con este video sobre Responsive Typography de Mandy Michael en el que explica que son Variable Fonts, algunos casos de uso y sus beneficios, y fue como WOW.

Algunos recursos:

Mostrar las notas y highlights del Kindle

¿Cómo mostrar las notas y highlights del Kindle? He estado dandole vueltas a esta pregunta, y suena como un buen problema a resolver.

On keeping a logbook

En el 2018 leí Steal like an artist de Austin Kleon, y una de las cosas que más me gustó fue la idea de tener un logbook. En el 2019 llevé uno, y para este año tengo otro; hoy me encontre con un post de 2010, previo al libro, en donde Kleon habla un poco del concepto y la idea detrás de tener un logbook, fue bastante refrescante; conectar los puntos de por donde pasamos y recordar ...the distance the ship traveled.

Retomando los meetups de DrupalCR

Algo bueno que ha dejado la pandemia es la cantidad de meetups, conferencias y eventos que se han movido a modalidad virtual, y para la comunidad de DrupalCR no ha sido diferente. El pasado 6 de Mayo retomamos los meetups mensuales, a la fecha hemos realizado tres, y el próximo es el 18 de Junio.

Todas las charlas van a estar disponibles en el canal de Youtube de DrupalCR.

Modern CSS Solutions

Mantener el footer fijo al final de la pantalla y columnas de igual altura, son dos viejos problemas que son complejos de solucionar con solo CSS; en la serie de posts publicados en Modern CSS Solutions for Old CSS Problems cubren estos viejos problemas, con soluciones modernas.

Responsive web design turns ten

Hoy 25 de Mayo cumple 10 años de haber sido publicado el artículo “Responsive Web Design”. La frase fue usada por primera por Ethan Marcotte en la charla “A Dao of Flexibility”

En el post Responsive web design turns ten hay detalles historicos sobre el nacimiento del concepto, good stuff.

Generar slug en Gatsby

Hasta hace unos días, este sitio web corría sobre Drupal, por diferentes razones lo migre a Gatsby y lo moví de un servicio de hosting a Vercel, la experiencia ha sido muy buena, más que todo porque me ha permitido aprender.

Aparte del contenido, queria mantener sin varianción la URL de cada post, por la sencilla razón de que, los links a estos post continuen funcionando, como dice Chris Coyier URLs are the single greatest feature of the web.

Un pequeño problema que me encontré al migrar el contenido fue que, el slug default generado por Gatsby no se ajustaba a lo que necesitaba, porque los post los tengo agrupados por año, un folder por año, entonces las URLs me quedaban algo como <dominio>/<year>/<path> y necesitaba que fuera <dominio>/<category>/<path>

El slug

El slug ó path, es la pieza de la URL que identifica, en un formato amigable y de fácil lectura, la sección específica de un sitio web, por ejemplo, la URL completa de este post es https://leivajd.com/nota/generar-slug-gatsby, el slug es la última parte /nota/generar-slug-gatsby.

En un CMS es común poder personalizar el slug y es algo que damos por hecho. Con Gatsby, la generación del slug va a depender del data source que estemos usando, por ejemplo, si estamos usando algún tipo de headless CMS no hace falta generar el slug, como sí es necesario hacerlo cuando el contenido viene de archivos markdown.

Generar slugs

Todo el contenido de este sitio viene de archivos markdown, así que, necesite generar y personalizar los slugs de los posts para que coincidan con los originales. Un paso atrás antes de hablar más sobre slugs.

Gatsby permite generar secciones/pages de manera programatica, es decir, podemos hacer un query con GraphQL para obtener la data y relacionar esa data a un template específico, en este caso, el template de post; cómo crear páginas de manera programatica esta documentado y también es parte del tutorial paso a paso de cómo crear un sitio web con Gatsby.

El slug es fundamental, porque es la manera mediante la cual podemos acceder a ese contenido que generamos programaticamente. En la documentación se cubre el como generar slugs, y depende del plugin gatsby-source-filesystem, mismo que se usa en la configuración de consumir contenido desde archivos mardown.

Algunas opciones de como generar el slug cuando el contenido viene desde archivos mardown.

Agregar el slug en metadata

Posiblemente la manera más sencilla es, agregar el slug en la metada de cada archivo markdown, algo como:

---
slug: "/nota/generar-slug-gatsby"
date: "2020-05-24"
title: "Generar slug en Gatsby"
---

Y después consumir el slug, como se hace en la guía Adding Markdown Pages.

Usar onCreateNode para generar el slug

Podemos usar la función onCreateNode de gatsby-source-filesystem, la cual se ejecuta cuando se crea un node (en mi caso un post), y nos permite agregar un field nuevo. El ejemplo de abajo es de la documentación:

const { createFilePath } = require(`gatsby-source-filesystem`)

exports.onCreateNode = ({ node, getNode, actions }) => {
  const { createNodeField } = actions

  if (node.internal.type === `MarkdownRemark`) {
    const slug = createFilePath({ node, getNode, basePath: `pages` })

    createNodeField({
      node,
      name: `slug`,
      value: slug,
    })
  }
}

El ejemplo anterior hace lo siguiente:

  • se condiciona a que el slug se cree solo cuando el tipo del node es MarkdownRemark
  • se usa la funcion createFilePath para generar el slug basado en el path (ruta) del archivo. Por ejemplo, si la ruta del archivo es 2013/intro-sass.md, el método retorna algo como /2013/intro-sass/
  • se usa la funcion createNodeField para agregar el field slug al nodo que se esta creando

Usar los datos del node para generar el slug

Basado en el punto anterior, y usando la función onCreateNode se puede extraer del node la informacion que se necesite para armar el slug. En mi caso, la metada del markdown se ve algo asi:

---
path: "/generar-slug-gatsby"
date: "2020-05-24"
title: "Generar slug en Gatsby"
type: "nota"
tags: ["JAMstack", "Web"]
---

Y la implementación es algo como esto:

  • se condiciona a que el slug se cree solo cuando el tipo del node es MarkdownRemark
  • se extraen los fields (type y patch)
  • se usa la función createNodeField para agregar el field slug al nodo que se esta creando
exports.onCreateNode = ({ node, getNode, actions }) => {
  const { createNodeField } = actions

  if (node.internal.type === `MarkdownRemark`) {
    const type = node.frontmatter.type
    const path = node.frontmatter.path

    createNodeField({
      node,
      name: `slug`,
      value: `/${type}${path}`,
    })
  }
}

Para no olvidar:

JavaScript cumple 25 años

Este mes JavaScript cumple 25 años, y este paper JavaScript: The First 20 Years cuenta un poco sobre la historia, evolucion y diseño del lenguaje.

Google Developers: Café con Paco con Juan Pablo Buriticá

Juan Pablo Buriticá (@buritica), quien ha dirigido múltiples equipos distribuidos de ingeniería, habla sobre los retos y oportunidades que enfretan los equipos en estos tiempos de pandemia.

Algunas notas:

  • Preocuparse primero por la salud fisica y emocional de los miembros del equipo y de sus familias, si las necesidades basicas de los miembros no estan satisfechas, es imposible ser productivos.
  • Entender que no estamos trabajando desde casa, estamos encerrados en casa tratando de trabajar; las condiciones y distracciones son diferentes en estos tiempos de Covid-19
  • Redefinir que es alto rendimiento en estos tiempos de pandemia. No se puede esperar que un equipo de alto rendimiento sigue produciendo el mismo valor pre-covid19.
  • Tener objetivos claros y que el equipo se adueñe de ellos, si es importante en tiempos "normales", en este momento es mas relevante.
  • Confiar en el equipo, no hay peor cosa que micro management. Un equipo distribuido requiere que confiemos en la gente con que trabajamos, sino se confia en esa gente o no la contratemos o talvez no estemos calificados para liderar
  • Organizar la semana para trabajar de Lunes a Jueves, asi el Viernes se puede usar para ver todos los temas personales; hay que aceptar que el trabajo no a seguir pasando de la misma forma.
  • Menos reuniones, no todos vamos a poder estar presentes en el mismo momento y depender mas en comunicacion asincrona.
  • Hay que tomarselo con calma, no es una epoca para obsesionarnos en productividad sino en comunidad.

Barreras para la accesibilidad web: degradados de color y lenguaje inclusivo

Vicent Sanchis: Barreras para la accesibilidad web: degradados de color y lenguaje inclusivo, una de las charlas del WordCamp España 2020, en el sitio web estan los videos de todo el evento.

Sobre el uso del atributo lang

El atributo de HTML lang especifica el idioma principal del contenido de un documento; para establecer el idioma que se quiere usar, se debe agregar el atributo a la etiqueta <html>:

<html lang="es">
  ...
</html>

El otro caso de uso para el atributo lang es cuando tenemos pedazos de texto que están escritos en un idioma diferente al idioma principal del documento, por ejemplo:

<html lang="en">
  ...
  <body>
    <p>This page is written in English.</p>
    <p lang="es">Pero este texto es en español.</p>
  </body>
</html>

El atributo acepta como valor, normalmente, dos letras; en el artículo ISO 2 Letter Language Codes tienen una lista de los diferentes valores. De toda esa lista los únicos que he usado son en para contenidos en ingles y es cuando es español.

Es muy fácil olvidarse de este atributo, creo que la razón es porque no tenemos claro para que sirve. En el post, ¿Por qué usar el atributo de idioma?, dan una explicación completa de los beneficios y se puede complementar con On Use of the Lang Attribute de Adrian Roselli.

Algunas razones por las que debemos usarlo:

  • Hyphens. Al usar lang obtenemos el beneficio de tener soporte para guiones (Hyphens). El soporte va a depender del browser que estemos usando, pero es un beneficio al fin para browsers modernos y se asume que estamos usando hyphens: auto en nuestro CSS.
  • Accesibilidad. Es un beneficio para usuarios de screen reader porque permite pronunciación adecuada del contenido.
  • Utilizar el atributo lang es un requisito nivel A de WCAG
  • Traducción. Abajo queda un extracto del artículo ¿Por qué usar el atributo de idioma?, vale la penar leerlo todo.

Las herramientas de traducción pueden utilizar los atributos de idioma para reconocer páginas o secciones de un texto en un idioma específico, y ajustar automáticamente el proceso de flujo de trabajo o proteger el texto de los cambios que pueda realizar el traductor en las herramientas de traducción.

Agregar DNS records en Vercel

Update 23/06/2020: Vercel tiene nuevo feature, actualizar DNS Records desde el UI, nice.

Hace un par de meses empece a usar Vercel.com, anteriormente llamado ZEIT, como servicio para hospedar landing pages y sitios web, el servicio esta maacute;s que recomendado.

Parte de la migración incluye actualizar los Nameservers en el proveedor de los dominios, y usar los de Vercel. Agregar un dominio a uno de los proyectos hospedados en Vercel es sencillo, esta bien documentado y se hace desde el panel de administración. El problema que encontré fue con los DNS records, al momento de escribir este post, actualizar los DNS no se puede hacer desde el panel de administración, esta es la solución:

  1. Instalar el CLI de Vercel.
  2. Inspeccionar que los settings del dominio sean correctos: vercel domains inspect <domain>
  3. Agregar los DNS records usando el comando: vercel dns add

En mi caso, necesitaba agregar los registros para poder usar Gmail, fue algo como esto:

vercel dns add <domain> '@' MX ASPMX.L.GOOGLE.COM 1
vercel dns add <domain> '@' MX ALT1.ASPMX.L.GOOGLE.COM 5
vercel dns add <domain> '@' MX ALT2.ASPMX.L.GOOGLE.COM 5
vercel dns add <domain> '@' MX ALT3.ASPMX.L.GOOGLE.COM 10
vercel dns add <domain> '@' MX ALT4.ASPMX.L.GOOGLE.COM 10

Hay que reemplazar <domain> por el nombre de dominio :P

En la documentacion del CLI estan los detalles de cada comando, y la propagación de los Nameservers y los DNS records fue cuestión de un par de horas.

Entrevista a Guillermo Rauch, CEO de Vercel

Guillermo Rauch, CEO de Vercel, hablando sobre la inversión de US$21 millones que recibieron, de donde viene el nombre Vercel, el futuro del front end y más. Me gusta mucho como reitera la importancia de un hipervínculo.

Mobile First, gratis

El libro de Luke Wroblewski, Mobile First, se puede leer de manera gratuita en línea.

Gatsby JS Crash Course

Crash course de Gatsby, cubre la instalación básica y como usar markdown como fuente de los datos para un blog, ó similar.

Introducción a PWA

Mi charla sobre Introducción a PWA fue aceptada en el WordCamp San José 2019, evento que se realizó los días 7 y 8 de Setiembre. Si hay feedback ó sugerencias para mejorar la charla y/o mi manera de exponer, me pueden tuitear @leivajd ó escribir a leivajd [@] gmail.com.

Slides: Introducción a PWA

Abajo quedan los recursos que he usado como base para trabajar y que son la base de la charla.

Lectura obligatoria

El punto de partida, la documentación "oficial":

Sobre PWA

The name isn’t for you and worrying about it is distraction from just building things that work better for everyone. The name is for your boss, for your investor, for your marketeer.

La cita anterior es de Frances Berriman, de su post Naming Progressive Web Apps, buena lectura. También vale la pena leer Progressive Web Apps: Escaping Tabs Without Losing Our Soul, de Alex Russell, son lecturas que tiran una luz sobre el origen del nombre.

Entre más leía y probaba Services Workers, más miedo me daba quedar "atrapado" con un Service Worker defectuoso. Esto me llevo a meterle tiempo a encontrar como "matar" un Service Worker, aquí quedan algunos links interesantes:

Publicar en Play Store

Google permite que un PWA se publique en Play Store, bajo el concepto de Trusted Web Activities (TWA).

Con estos post hay que validar que aún aplique, hace 3 meses eran válidos, a hoy no sé.

Herramientas

  • Progressive Web App Checklist - Google.
  • What Web Can Do Today. Util para visualizar el estado de APIs disponibles en el browser.
  • Serviceworke.rs. Un cookbook de MDN.
  • PWA Builder. Un proyecto comunitario de Microsoft.
  • Workbox. Es una serie de librerias y modulos de Node que nos permiten facilitan integrar la creación del Service Worker, usando Webpack ó Grunt, y crear estrategias de cache sin tanto boilerplate.

What makes someone a good front-end developer?

The least important skills for a front-end developer to have are technical ones.

La parte técnica se puede aprender, y se aprende trabajando, buen artículo.

TL;DR:

  • Problem-Solving: just breaking a big thing into smaller parts and tackling them one at a time
  • Googling: being able to craft a search term that gets to the root of what you want to do and finds valuable content online is a real, valuable skill.
  • Critical Thinking: sort the signal from the noise and make more informed decisions is super important. It’s also a skill that you’ll suck at at first and get better at over time as you gain more experience.
  • Empathy: empathetic web development means understanding that users bring many different experiences and abilities with them, and building things accordingly.
  • Communication: the developers who are most effective at working on teams are not always the best coders. They’re the best communicators.
Desarrollo y contenido por José David Leiva 2012 - 2020 / RSS