Etiqueta: JavaScript

  • El otro día respondí lo siguiente por nuestro Discord en un hilo [1] en el que se debatía si era 100% necesario escribir tests a la hora de escribir un código. Traigo el contenido aquí para no perderlo en el historial y tenerlo a mano.

    Yo me voy a tirar a la piscina y voy a decir que sí es posible escribir el código de un proyecto sin tests si lo pruebas a mano según lo estás desarrollando.

    Lo que no es posible hacer sin tests es mantenerlo. Porque cuando se hagan cambios en el software ya no va a ser el mismo software que el que has probado a mano cuando lo estabas desarrollando. Tendrías que probar a mano de nuevo todo el programa, y eso puede ser una pérdida de tiempo. ¿Cuándo entra un código en mantenimiento? En cuanto dejas de tener visible ese código después de escribirlo.

    Creo que la principal finalidad de los tests desde el punto de vista pragmático, más allá del «virtuosismo» de «soy guay, tengo tests, tengo buen coverage (JA)», es poder automatizar el poder comprobar que el software sigue funcionando bien conforme va pasando el tiempo de una forma automática y no intrusiva. Si hago un cambio de mantenimiento a un módulo de software quiero poder tener mi checklist ya implementada que me cubra todos los casos de uso de ese módulo de software para poder hacer la validación automáticamente y comprobar que no se introducen regresiones, o sea, que no he roto nada inesperado al hacer el cambio. (El software a veces se conecta de formas poco esperadas; cohesión siempre acaba habiendo y las interfaces de un módulo nunca son tan buenas como cabría esperar)

    [1] Para que este deeplink funcione hay que haberse unido antes al servidor.

  • Hace poco intentando resolver un problema en JavaScript*, puse en Google un par de palabras para describir mi problema esperando encontrar respuestas en Stack Overflow.

    El primer enlace apuntaba a un blog de Medium. No lo pude leer, porque la página me pedía registro.

    El segundo enlace apuntaba a otro blog de Medium. Tampoco lo pude leer, porque la página me volvía a pedir registro.

    El tercer enlace apuntaba a otro blog de Medium. Y no, no lo pude leer tampoco, porque la página otra vez insistía en pedir registro.

    Dejando a un lado que este tipo de páginas probablemente vulnere las normas de Google, a saber qué otros sitios web algún año se quitarán la careta después de convertirse en silos en los que la gente vuelca contenido.

    * Es casualidad que intente conectar JavaScript con Medium. Creo.

  • Una de las cosas bonitas de la GDPR es que casi obliga a las redes sociales y sitios similares a tener un sistema de exportado de datos. Y casi siempre lo hacen con algún formato estructurado como CSV, JSON o XML, fácil de procesar por un ordenador.

    Paralelamente, WordPress tiene el viejo confiable XML-RPC para crear posts de forma programática. Si no tienes mucha idea, recomiendan cerrar ese endpoint al exterior para evitar problemas. Pero en verdad, si sabes protegerlo, resulta muy práctico para crear posts a golpe de petición HTTP. (En teoría existe la API REST, pero bueno…)

    Con la ayuda de un cliente XML-RPC para WordPress que hay en NPM y de la API de Hacker News, hice en Node.js un script de un solo uso que crease una entrada por cada comentario y enlace enviado para enlazar hacia el comentario o la historia, siguiendo el modelo de sindicación PESOS de IndieWeb (Publish Elsewhere, Syndicate to Own Site). Le he puesto la etiqueta hn-import a la colección. ¿Cuál será el próximo archivo que importe?

    En sí la librería no es muy complicada de utilizar. Una vez tienes un cliente conectado es muy fácil chutarle un array de posts a crear (por ejemplo, procesar fila a fila un CSV o item a item un JSON o un XML). Primero se crea un cliente:

    const { createClient } = require("wordpress")
    
    const client = createClient({
      url: "https://example.com",
      username: "mi user",
      password: "mi password"
    })

    Luego definiendo el payload. Aquí es donde encuentro más cómodo crear un objeto JSON que declarar todo el chorizo XML de XML-RPC:

    const payload = {
      title: "El título de mi entrada",
      content: `
        <p>El contenido de mi entrada.</p>
        <blockquote>Aceptamos HTML.</blockquote>
        <p><a href="https://www.example.com">Y enlaces</a></p>
      `.trim(),
      status: 'publish', // podría ser 'draft' o 'private'
      termNames: {
        category: ['Categoría'],
        post_tag: ['tag 1', 'tag 2', 'tag 3'],
      },
      date: '2006-01-02 15:04:05',
      format: 'link' // podría ser 'aside', 'status', 'photo', ...
    }

    Y ya postear usando newPost. La librería es previa a promesas así que su único punto malo es que está orientada a callbacks.

    client.newPost(payload, (err, id) => {
      if (err) {
        console.error(err)
      } else {
        console.log(`ID del nuevo post: ${id}`)
      }
    })
  • thumbnail-maker es un port a HTML5 de mi template para crear miniaturas para los vídeos de makigas. Esta primera versión hace l justo y lo necesario para poder generar sobre la marcha miniaturas PNG de alta calidad usando el navegador web y save-svg-as-png.

    Parece que a raíz de emitir en directo su desarrollo por Twitch han empezado a aparecer parodias de mis miniaturas por el canal del servidor de Discord… 🥲

  • Un archivo TypeScript con el siguiente código fuente compila en mi ordenador:

    import Member from "../../Member";

    Sin embargo, mi código de CI de GitHub Actions falló con el siguiente mensaje de error:

    Error: src/lib/http/middlewares/member.ts(6,20): error TS2307: Cannot find module '../../Member' or its corresponding type declarations.

    Después de darle un par de vueltas, el veredicto es que, como por defecto el sistema de archivos de macOS no diferencia entre mayúsculas y minúsculas, en macOS, import Member from "../../member" e import Member from "../../Member" son equivalentes. GitHub Actions por defecto utiliza GNU/Linux, donde sí se diferencia por defecto entre mayúsculas y minúsculas, así que no lo tiene tan claro.

    Ugh. Lo peor es que hay software para macOS que espera que el sistema operativo no sea case-sensitive y que puede dar problemas si el disco duro en el que se instala macOS se configura para sí diferenciar mayúsculas de minúsculas.