La opción de desactivar el ping HTML en el navegador desaparece en Chromium y derivados

Hace muchos años que las webs registran el origen de su tráfico. Sin embargo no hace tanto que la recopilación de datos empezó a estar cada vez más cotizada. Los datos son dinero, y si no que se lo digan a Google, Facebook o Twitter, cuyo negocio real es la publicidad segmentada: les ofrecen a los anunciantes un público receptivo, el cuál seleccionan a través de esos datos que recopilan desde sus servicios “gratuitos”.

Con la implantación del estándar HTML5 ha aparecido una nueva opción que permite controlar cuáles son los enlaces en lo que el usuario hace click, y cuáles no. Hasta la fecha desde el navegador podíamos controlar si queríamos que esos “datos de ping” se enviasen, pero las últimas noticias dicen que muchos de los navegadores van a dejar de soportarlo. La realidad es que es sólo uno el que lo abandona: Google Chrome, lo que no debería resultar raro: es el producto de Google y a Google se le paga en datos. El problema es otro: en los últimos años la mayor parte de los navegadores han ido abandonando su independencia y construyendo directamente sobre le núcleo de Código Abierto de Chromium.

Muchos de lo que me leéis no tenéis ni idea de la tortura que es pelearse para que cualquier aplicación web que hagáis se visualice correctamente en todos los navegadores, especialmente cuando algunos no siguen los estándares (Internet Explorer y yo jamás nos llevaremos bien, nunca llegó a implementar EcmaScript 6 y la retrocompatibilidad es un infierno), por lo que una estandarización es bienvenida, pero que la mayor parte del control de la experiencia de la web esté en manos de un único jugador no puede ser bueno. La imagen lo ilustra claramente 🙂

El reto de los 10 años en los navegadores: antes Chrome, Internet Explorer, Opera y Firefox. Ahora Chromium, Chromium, Chromium y Firefox

Actualmente solo Firefox y Brave permiten evitar esta funcionalidad, y el primero los lleva deshabilitados por defecto. La decisión sobre qué sucede con vuestros datos, es vuestra.

Anuncios

Enredando con Gitlab para montar una página web estática con NodeJS

Hace tiempo que tenía ganas de enredar con el sistema de integración continua de Gitlab. Para quien no este puesto, Gitlab es un servicio Git alternativo a GitHub, solo que libre en su totalidad. Podéis compararlo con el producto de WordPress en el sentido de que puedes tener tu espacio en la versión .com, o bien descargarte el código y montarte tu propia versión en tu propia maquina, modificándolo al gusto. El extra de Gitlab, además de las virtudes del software libre, y de que Microsoft no lo controle, es que trae su propio sistema de integración y despliegue, por lo que no necesitas utilizar una tercera parte: puedes hacer que al subir tu código se realicen las pruebas, preparen informes, y lo despliegue mediante un contenedor (tecnología docker o kubernetes, al gusto).

Mi proyecto para este caso era generar una página web estática, un pequeño blog en Hexo que transforma archivos en notación markdown a HTML. Hay otras alternativas, pero tenía ganas de actualizar mis conocimientos de maquetación de NodeJS, ya que en mi vida laboral tiendo a utilizar versiones obsoletas para corregir errores de aplicaciones con un tiempo. Para crearlo usé las siguientes herramientas:

  • Git: control de versiones creado por Linus Torvalds.
  • NVM: para gestionar las versiones de NodeJS instaladas en mi sistema y poder alternar entre ellas a gusto. Hay un instalador para Windows.
  • VSCodium: una versión construida del código abierto de Visual Studio Code para manejar el código más cómodamente. Si leéis la licencia veréis que al compilarlo Microsoft añade sus extras de telemetría los cuales no están en la parte abierta, y yo estoy encantada de haber encontrado un proyecto que me ahorre el esfuerzo de compilarlo a mano para no tener que sufrir la parte turbia. Desde que Microsoft compró GitHub usar Atom o VSCode es prácticamente lo mismo, y el segundo ha demostrado tener mejor rendimiento.

Nota: Me gusta bastante trabajar desde consola, pero obviamente podéis usar el gestor de terminal o la interfaz gráfica de Git que más os guste (Sourcetree, Smartgit, Gitkraken). Todas son opciones muy dignas pero ninguna realmente libre, de ahí que mi explicación vaya directamente sobre terminal.

Un blog personal generado con hexo

¡Pues manos a la obra! Lo primero fue colocar la versión de NodeJS a la última estable y comprobar que está correctamente instalada. Desde terminal sería:

nvm install
nvm list

Lo siguiente generar el proyecto git en Gitlab y clonármelo en mi local.

git clone https://gitlab.com/usuario/code-notepad

Tras eso pasaría a instalarme Hexo vía npm, el gestor de paquetes por defecto de NodeJS.

npm install hexo-cli -g

Y con esto entramos en el maravilloso mundo de Hexo. Lo primero es crear un blog.

hexo init blog
cd blog
npm install

Si queremos almacenar imágenes propias en los artículos que escribamos, tendremos que habilitar la creación de una carpeta con esa función. Esto se puede hacer valor el valor del fichero _config.yml que marca esto a cierto.

post_asset_folder: true

Y probamos que todo funciona como esperamos, desplegándolo mediante un único comando haciendo click en la dirección URL que nos devuelve el terminal.

hexo server

Después podemos instalar algún tema. Hay un repositorio estupendo, y es tan fácil como descargar y colocarlo en la carpeta themes.

Yo en particular soy una fanática de los diagramas de flujo de mermaidJS, que me permiten completar mis notas de programación con gráficos. De ahí que añadiese el plugin correspondiente vía npm.

npm i hexo-filter-mermaidjs

Y luego lo configurase en los 2 siguinetes pasos.

1. En la sección de plugins de _config.yml añadí:

# mermaid chart 
mermaid: ## mermaid url https://github.com/knsv/mermaid 
  enable: true  # default true 
  version: "7.1.2" # default v7.1.2 
  options: 
    #startOnload: true  // default true

2. Al final de footer.ejs de la plantilla del tema a usar, añadí:

<% if (theme.mermaid.enable) { %>
  <script src='https://unpkg.com/mermaid@<%= theme.mermaid.version %>/dist/mermaid.min.js'></script>
  <script>
    if (window.mermaid) {
      mermaid.initialize({theme: 'forest'});
    }
  </script>
<% } %>

Por último queda añadir el fichero de integración continua añadiendo en la raíz un fichero .gitlab-ci.yml. Este fichero usará un contenedor docker con una imagen de NodeJS 10.15.3, donde instalará Hexo, contruirá los paquetes, generará la la página y la desplegará en Gitlab pages el contenido de la rama master él solito.

image: node:10.15.3

cache:
  paths:
    - node_modules/

before_script:
  - npm install hexo-cli -g
  - test -e package.json && npm install
  - hexo generate

pages:
  script:
    - hexo generate
  artifacts:
    paths:
      - public
  only:
    - master

Con esto tenemos el esqueleto listo: a subir el código a Gitlab, y tras esto cualquier subida lanzará la integración continua, dejando como resultado la página lista en la dirección “tuUsuario.gitlab.io/code-notepad”.

git commit -a -m "Base del sistema"
git push

Así que a generar un primer artículo desde el interior de la carpeta source. Desde aquí podemos ir escribiendo los artículos en sintaxis markdown.

cd source
hexo new post "primer articulo"

Esto nos genera un fichero en sintaxis Markdown con la siguiente cabecera. Los valores cambiamos al gusto para que se ajusten a lo que deseemos en nuestro blog para título, fecha, y etiquetas para ordenar el contenido:

---
title: primer artículo
date: 2018-04-17 10:00:00
tags: [Etiqueta1, Etiqueta2]
---

Podemos colocar las imágenes en la carpeta homónima (en este ejemplo “mi primer artículo”). Para referenciar las imágenes usamos la siguiente sintaxis:

{% asset_img "imagen.jpg" "Descripción de la imagen" %}

Y con esto ya estamos listos, commit y push en cuanto estemos listos, y Gitlab pages se encargará de publicarlo por sí solo. ¿No está mal, eh?

El cementerio de Google

Esta es la semana del fin de Google+, una buena propuesta en la que se invirtió una enorme cantidad de recursos, para luego ser ejecutada de un modo muy desafortunado.

La red social se une a una larguísima lista de productos que a lo largo de los años, la cul está recogida en la web Killed by Google, y a estas alturas no sé vosotros, pero yo siento bastante desconfianza respecto a la longevidad de cualquier nuevo producto o servicio que lancen.La web "Killed by Google"

Desde mi punto de vista es un proceso que empezó con la muerte de Google Reader y Feedburner, movimiento que consideré motivado por intentar forzar el paso a Google+. Se abandonó el mantenimiento adecuado de Blogger en favor de las páginas y comunidades de su red social, y esto nos ha legado es una imagen de desolación: una plataforma de blogs anticuada y desconectada para fomentar una red social que es historia. Pensad luego en Google Chat, construído sobre un protocolo abierto y luego sustituído por Hangout, de protocolo cerrado al estilo Microsoft. O quizás en Google Now o Google Glass, tan anunciados a bombo y platillo y ahora en medio de la nada.

Google ya no es la empresa que era: hace tiempo que el usuario, la web y los protocolos abiertos quedaron atrás; si no monetiza en un breve periodo de tiempo, en vez de refinar el producto pasa a intentar implantarlo agresivamente para conseguir rechazo y finalmente aplicar la guillotina. Y esta actitud probablemente le pase factura con Stadia.

El uso de Carbon: bonitas capturas de código, pero excluyente

Tanto en blogs como microblogs de programación se está generando la tendencia de incluir capturas de pantalla con código fuente francamente bonitas, y curioseando el origen de estas imágenes descubrí que provienen de un proyecto llamado Carbon, cuyo código se encuentra disponible en GitHub.

Una captura de la página web de Carbon

El coloreado sintáctico es una gran ayuda visual para los programadores, el cuál nos facilita la comprensión de su estructura de un sólo vistazo, pero a la hora de compartir los ficheros fuente me encuentro entre las personas que recomiendan no hacerlo mediante de capturas de pantalla, o si se toma tal decisión por ciertas razones de peso, como por ejemplo razones de espacio en el estado de un microblog (por ejemplo Twitter podría no tener los caracteres suficientes), tal imagen debería ir acompañada de un enlace donde esté en texto. Digo esto principalmente por 2 razones:

  • La primera es por generosidad hacia otros programadores: codificar es un proceso creativo en el que editamos, ejecutamos y probamos diferentes versiones del código. Con una imagen se obliga a reescribir, lo que es ineficiente, además de que la resolución podría no ser buena o no adaptarse bien a la pantalla del dispositivo.
  • La segunda es por accesibilidad: una imagen es un elemento visual, y no todos los usuarios de Internet pueden ver: las herramientas de accesibilidad no pueden “leerles la imagen” a no ser que tengan un valor de texto alternativo, lo que no todos los sistemas, por no hablar de los usuarios, proveen.

Intentemos pues ser generosos y respetuosos, recordando proveer una versión escrita para una buena difusión. La imagen es genial, pero hay quien realmente necesita las 1000 palabras, y la situación no tiene por qué ser mutuamente excluyente.

Aterrizando en tabletop.social en Mastodon

He sido una usuaria bastante feliz de mastodon.cloud durante meses. La que comenzó como una instancia (servidor) francesa después pasó a manos japonesas, teniendo un espectacular aumento de volumen a cada error de las grandes redes privativas, véase Twitter y sus cambios en el timeline o Tumblr y el sistema automático de contenido inapropiado con cientos de falsos positivos. El exceso descontrolado de afluencia debió de acabar definitivamente con la paciencia del administrador, el cual decidió traspasar sus poderes, para acabar estos en manos de una empresa japonesa y desapareciendo el Patreon de mantenimiento.

El encontrarme de la noche a la mañana con unos términos y condiciones en legalés que no terminan de dejar claro qué pasa con mis datos ni cómo se subvenciona el servidor (si no se paga por él de alguna manera, las probabilidades de que nuestros datos son el producto son astronómicas) me resultó bastante desagradable, lo que me llevó a invertir tiempo buscando un nuevo hogar en el Fediverso. Tras revisar múltiples condiciones y el comportamiento de los administradores de varias instancias, finalmente me decidí por tabletop.social, cuyo adorable banner podéis observar abajo.

tabletop.social

El ser una instancia con condiciones de uso similares a las que tenía originalmente en mi nodo, junto al hecho de que la temática principal del servidor es muy de mi gusto de cara al timeline local me parece una maravilla. Así que ahora en vez de ruido, trolls de la migración masiva española y el festival de rabos de exiliados de Tumblr, el feed de mi servidor lo tengo arte y reseñas de juegos de mesa, juegos de ordenador, o anécdotas de los procesos creativos en el desarrollo. de nuevos proyectos El extra de la facilidad de migración de servicio entre instancias de Mastodon también ha ayudado a que resulte un proceso bastante inocuo: me pude llevar sin problemas mis datos mediante una petición de todo mi contenido, y llevarme unos CSV (hoja de cálculo) con mis seguidores, listas, silenciados, bloqueos… que cargan inmediatamente en la nueva instancia para tenerlo todo listo en pocos minutos, con la salvedad de los usuarios en modo protegido los cuáles deben reautorizar tu acceso. La cuestión es que en menos de 8 horas todo estaba listo de nuevo.

El cambio de ambiente ha sido muy saludable: el usuario medio de esta instancia comparte estados federados que se ajustan a la temática del servidor, dejando sin federar su contenido personal evitando así que el feed local de la instancia se desvíe de su objetivo principal. El uso de content warning es muy civilizado: lo justo para no herir sensibilidades pero sin caer en la tontería. Sumándose esto a que la administración está regulada mediante un equipo y que no está superpoblado, podría considerar que es la mejor decisión de redes sociales que he tomado en mi vida. Niveles de tranquilidad, felicidad y frikismo: altos.