Sobre el método usado para generar ficheros .zip

¡Oh! ¡Qué bonito!

Casi a título de inventario. Una necesidad frecuente en el mundo de la informática es el empaquetado (reunir varios ficheros/documentos para su distribución, por ejemplo, de manera conjunta) y la compresión (hacer que lo guardado ocupe el menor espacio posible).

En History, Explanation and Implementation nos cuentan el caso del formato zip que no es especialmente bueno ni moderno, pero que se puede entender bien con la voluntad adecuada. Incluye ejemplos de código:

This article explains how the Zip file format and its compression scheme work in great detail: LZ77 compression, Huffman coding, Deflate and all. It tells some of the history, and provides a reasonably efficient example implementation written from scratch in C.

La forma en que trabaja este método de compresión es extraer la información común, codificarla adecuadamente y sustituirla por códigos más breves cuando aparezca.

One way of compressing text is to maintain a list of common words or phrases, and replace occurrences of those words in the text with references to the dictionary. For example, a long word such as “compression” in the original text might be represented more efficiently as #1234, where 1234 refers to the position in the word list. This is known as dictionary-based compression.

Interesante.

Automatización de lo que se ve en el perfil de GitHub

Imagen de la página Programar me relaja y además me gusta hacer pruebas, aunque el tiempo disponible no sea demasiado. También me gustaría incluir en esta bitácora algunas de esas pruebas, por si le sirven a alguien para algo, que es algo que necesita todavía más tiempo. Esta entrada pretende mostrar una de esas pruebas, que permite actualizar automáticamente el perfil de GitHub gracias a algunas características que han incluido recientemente en esa ‘red social’ de desarrolladores.

Lo que cuento se basa en las indicaciones que se pueden encontrar en Building a self-updating profile README for GitHub (sigo el sitio de Simmon Willison desde hace mucho tiempo y fue una sorpresa agradable descubrir la receta y otras inspiraciones) y también en How I Built A Self-Updating README On My Github Profile (en este caso encontrado gracias a una búsqueda de Google y con algunas ideas de diseños más atractivos, al menos para mi).

GitHub ha lanzado recientemte el léeme del perfil (README) que permite utilizar markdown para incluir información personalizada en el perfil del usuario. Basta con crear un repositorio público nuevo con el nombre del propio usuario (en mi caso, github.com/fernand0/fernand0 e incluir un fichero README. GitHub utilizará este fichero para mostrarlo en nuestra página de perfil.

Siendo un repositorio, uno puede preguntarse (al menos Willison lo hizo) si puede automatizar algunas tareas relacionadas con el mismo. Y nos cuenta como esto es posible gracias a una acción de GitHub (GitHub Action) que se define en el fichero build.yml.

No voy a entrar en mucho detalle, pero contiene:

  • Formas de ‘disparar’ acciones (en nuestro caso, cuando se hace un push o basado en el tiempo, con la sintáxis del crontab).
  • Después, permite ejecutarlas (dónde se ejecuta -sistema y entorno de desarrollo, incluyendo instalación de paquetes si es necesario-: en mi caso en una Ubuntu con el lenguaje Python) y algunas cosas más (por ejemplo, definir TOKENS necesarios para realizar determinadas acciones -en nuestro caso, utilizar el Graph QL API de GitHub).
  • Finalmente, utilizar el resultado de esas acciones para generar la información que aparecerá en nuestro perfil (Fundamentalmente hacer un push si ha habido cambios).

Sobre mi actividad en el propio sitio, decidí incluir información relacionada con repositorios (contribuciones -mínimas- a los de otros proyectos y a mis propios repositorios públicos). Sobre otra actividad, pensé en incluir las últimas entradas en mis dos bitácoras más activas (incluye esta) y se muestran en la página.

El código de actualización está en build_readme.py (versión en el momento de escribir esta entrada del código basado en el de Willison, las partes mejor realizadas son mérito suyo, las más feas son mis propios ‘apaños’).

Para mostrar la información de los repositorios, como decía arriba, se utilizan el Graph QL API de GitHub con un token personal (en ‘Settings’ de la cuenta de GitHub podemos buscar la opción de ‘Developer settings’ y allí crear lo que llaman ‘Personal access tokens’. Luego hay que darle los permisos adecuados para este token (en mi caso los de usuario, los de workflow, y los de lectura y escritura en un repo -así a ojo, creo que son los necesarios; si no funciona ya nos dirá cuáles necesitamos-).

Para que el sistema que ejecuta nuestro programa tenga acceso al token podemos usar los ‘settings’ del proyecto (estos son los míos, pero se entiende, espero) y allí ir a la opción de ‘Secrets’ donde podemos dar de alta la información secreta que necesitemos.

En mi caso, la información que se muestra sobre la actividad en GitHub está en la pregunta:

query MyQuery {
  user(login: "fernand0") {
    repositoriesContributedTo(last: 20, orderBy: {field: PUSHED_AT, direction: DESC}) {
      edges {
        node {
          name
          description
          projectsUrl
          pushedAt
        }
      }
    }
    repositories(last: 10, orderBy: {field: UPDATED_AT, direction: ASC}, privacy: PUBLIC) {
      edges {
        node {
          name
          description
          projectsUrl
          owner {
            login
          }
          pushedAt
        }
      }
    }
  }
}

Para construirla GitHub nos proporciona una herramienta muy útil, que es el ‘GitHub GraphQL API’ que simplifica mucho la tarea de probar las preguntas.

Para mostrar la información de las bitácoras, utilizo el paquete ‘feedparser’ que ya usábamos hace algún tiempo en Publicar en Facebook las entradas de este sitio usando Python para extraer la información, formatearla y añadirla al README.

Por otro lado, de Hoffman he mirado los simbolitos sociales (y he descubierto Shields.io que parece un sistema de generación de logos utilizando SVG y otros trucos; he usado algunos que ya tenía Hoffman y he ‘añadido’ otros que no existían, no se qué sucederá) y el formato en una sola columna (Willison tiene una tabla con tres columnas que no se ven muy bien, por ejemplo, en el navegador de un teléfono móvil).

¿Qué pasará a partir de ahora?

Probablemente seguiré jugando con el aspecto para dejar uno que me convenza del todo y, tal vez, añada algún servicio más. Uno evidente es el de Twitter, pero podría ser otra cosa.

Si alguien necesita ayuda con algún paso, puede leer con calma las entradas recomendadas y también preguntar, si lo que necesita no es muy diferente de lo que se puede ver aquí.

Los procedimientos almacenados y los sistemas

Centro de Exposiciones del Centro de Conocimiento sobre servicios públicos electrónicos. Almacenamiento. En seguridad informática siempre se habla de los procedimientos almacenados como un mecanismo para evitar el problema de la inyección de SQL. En What have the STORED PROCEDURES ever done for us? defienden se pueden conseguir ventajas como:

Your application is only aware of that one database account that can only execute SP required by your application and nothing more.

That application account can’t access data at all directly.

That application account is created and managed by another database account with a higher level of privileges and that is stored and protected much more securely.

Esto es, el principio del mínimo privilegio.

Además, también beneficios desde el punto de vista de las prestaciones.

Well, this one is easy, everyone knows that at least - STORED PROCEDURES will give you performance gain.

Mantenibilidad, porque nos permiten hacer depuración sin tener que usar el sistema completo.

Execute the STORED PROCEDURE that serves that screen and examine the data. If data contains the bug, then you know that the problem is within the STORED PROCEDURE, if it doesn’t then the bug is somewhere within the application layer.

Disponibilidad, puesto que también nos permiten detectar y corregir determinados problemas en la base de datos.

I may have already mentioned above that you can patch a bug in STORED PROCEDURE without having to stop anything. Hence, availability.

Un recordatorio, presentado de forma llamativa.

Machine Learning para elegir un método de compresión

Semáforos En el mundo de los programas ‘inteligentes’, una aproximación con una cierta tradición es aplicar esa inteligencia a la toma de decisiones cuando algunos parámetros pueden cambiar y probar todas las opciones es una tarea difícil o costosa.

De esto hablaba shrynk - Using Machine Learning to learn how to Compress aplicado al tema de la compresión de información (esto es, hacer que ocupe menos espacio). Hay muchos métodos de compresión y unos son mejores que otros cuando los datos tienen unas ciertas características:

Different algorithms exist for different types of data, such as images, video, audio, but also text and general purpose files. Any data can be compressed as long as there is a pattern to use.

Y el ‘machine learning’ es una buena herramienta de ayuda a la decisión. En este caso, se utilizan métodos ya conocidos de compresión y se evalúa su comportamiento frente a los datos disponibles.

For each file, it will apply the compression and gather the values for each compression algorithm on size, write and read columns and converts them to z-scores: this makes them comparable at each dimension and is a novel approach as far as I know. The lowest sum of z-scores given the user weights gets chosen as a classification label. Let’s see that in slow-motion.

En lugar de decidir ‘a mano’ o por algún méitodo más costoso, este sistema permite elegir un método suficientemente bueno.

Since having to come up with manual rules for when to use which compression would be very complex and time costly, this was a great case for machine learning. It’s very scalable, as when a new compression algorithm shows up on the market, shrynk will be able to benchmark that one and no new rules have to be figured out.

Curioso.

Make y makefiles siguen siendo herramientas de actualidad

Construcción Sigo manteniendo algunos viejos Makefiles de proyectos en C que sigo necesitando. Resuelven bien un problema concreto que es el de gestionar las dependencias entre ficheros que continen código y las bibliotecas que hay que generar a partir de ellas, en qué orden y qué es necesario compilar después de cambiar alguna parte del proyecto.

Por eso me gustó leer The Language Agnostic, All-Purpose, Incredible, Makefile que aporta una visión actual del programa Make y cómo lo usa el autor.

Este programa existe desde 1976 y mucha gente piensa que ya está obsoleto:

Make was born in 1976, making it one of the oldest tools in a programmer’s toolkit. Any tool that has been around this long is bound to have a mythology, stories, and examples that would be intimidating to someone unfamiliar with it. Additionally, I think many of us have written it off as no longer relevant, as we are not writing C programs, after all. Allow me to show you why it should not be intimidating, and furthermore, is applicable to your everyday workflow as an engineer.

El programa trabaja con objetivos, tiempos y reglas basadas en lo que se necesita para alcanzar esos objetivos:

This section is just a summary of what we just arrived at. The properties of satisfaction for a target.

The target must exist. The target’s timestamp must be newer than the timestamp of the target’s prerequisites. The prerequisite targets must be satisfied.

Un buen recordatorio.

Teoría de la probabilidad y gestión de sistemas

Laplace fue un matemático interesado en la estadística La teoría de la probabilidad analiza aspectos como cuántas veces tiene que ocurrir un suceso para que se obtena un determinado resultado. Hechos poco probables deberían ocurrir pocas veces (que no significa que no puedan ocurrir) y el problema puede aparecer cuando ‘damos muchas oportunidades’ para que finalmente el hecho suceda. En un sistema informático estamos continuamente ‘tirando los dados’: se trata de hacer muchas veces procesos repetitivos, para evitar tener que repetirlos nosotros a mano. De esto nos hablaba Some Useful Probability Facts for Systems Programming centrándose en el caso de la programación de sistemas.

Por ejemplo, si en un servicio en línea hay una probabilidad de que suceda un incidente cada 20 días, la forma en que se distribuyan esos sucesos nos afectarán de manera desagradable e inevitable de vez en cuando.

If an online service has a production incident once every 20 days on average, then (assuming unrelated incidents) just over a third of 20-day periods will be dead quiet, just over a third will have the “ideal” single incident, while a quarter of 20-day periods will be extra stressful. In the real world, production incidents are even more tightly clustered because they’re not always independent.

Lectura interesante.

Modelo de Seguridad en programas informáticos de la OWASP

The pila seguridad En el mundo de la seguridad del software hay dos modelos de madurez (esencialmente, modelos basados en lo que hacen distintas empresas y organizaciones, como guía para lo que deberíamos estar haciendo el resto. Por un lado está el Building Security In Maturity Model (BSIMM) y el Software Assurance Maturity Model (SAMM).

El primero proviene de un grupo de expertos de la industria y ha tenido varias versiones en los últimos años. El segundo, fue promovido por la OWASP (Open Web Application Security Proyect) y yo casi lo daba por muerto.

Sin embargo, a principios de este año se anunció OWASP SAMM version 2: Analyze and improve organizational security posture, lo que significa que han vuelto a avanzar.

“This is a really important release for the project team. After three years of preparation, the team, our SAMM community, and through the help of our sponsors we now have an effective and measurable way for all types of organizations to analyze and improve their software security posture,” said project co-leaders Seba Deleersnyder and Bart De Win.

Interesante.

¿Te interesan los navegadores web? Una lista de recursos

Santander. Velero En esta ocasión traemos una recopilación de recursos sobre navegadores, Demystifying Browsers donde el autor (ericlaw) nos habla, desde su experiencia de programador de extensiones, de diversos recursos para conocer mejor cómo funcionan estas herramientas y las cosas que podemos mirar.

I’m increasingly often asked “Where do I learn about browsers?” and I haven’t had a ready answer for that question.

Como siempre, para aprender hace falta curiosidad, ganas de explorar y obstinación.

Tiene una sección sobre lo básico (Fundamental Understanding), otra sobre libros, y herramientas. También recomienda leer el código, recorrerlo, compilarlo si nos sentimos con fuerza, mirar las bases de datos de fallos, …

Finalmente, una lista de blogs, gente a la que seguir, y algunos recursos más.

Si te interesa el tema, lo tienes que leer.

OAuth 2.0 y OpenId. Autorización e identidad entre servicios.

Recibido. Acceso electrónico de los ciudadanos a los servicios públicos A pesar de que sigue usándose ampliamente el usuario ya la contraseña (y su ‘glorificación’, el certificado digital), lo cierto es que hay formas más intersantes de dar acceso a recursos. En An Illustrated Guide to OAuth and OpenID Connect hablan de estos mecanismos que permiten dar acceso a recursos sin tener que difundir o utilizar todo el rato el usuario y la contraseña. El usuario atento habrá visto cómo necesita, a veces, autorizar el uso de un recurso (en Google, Twitter, Facebook y otras redes sociales) que es justamente eso: OAuth nos permite identificarnos ante un servicio para dar permiso a otro (o a una aplicación que se conecta al mismo) con el objetivo de poder realizar determinadas acciones). Por eso nos avisan de cosas como que la aplicación podrá leer, modificar o lo que sea que va a hacer. Además de liberarnos de tener que poner nuestra clave y contraseña en esos sitios y aplicaciones (las ponemos directamente en el servicio en cuestión), nos permite una gestión más eficaz:

  • Si cambiamos la contraseña no será necesario (al menos no siempre) reintroducirla en todas las aplicaiones.
  • Si queremos revisar/modificar o cancelar quién puede acceder a nuestra información lo podremos hacer en el sitio del servicio y no en el del que hace uso de ello.

En esa entrada se hace una muestra gráfica de cómo funciona el mecanismo y me pareció interesante para compartirla aquí.

OAuth está diseñado para la autorización, esto es, dar acceso a datos y características. En algunos casos puede ser necesario, además, proporcionar información sobre el usuario (identidad). En esto entra en juego OpenID, donde se puede compartir esta información. Y también hay una demostración gráfica de las capacidades y el funcionamiento.

Interesante.

Estructura y funcionamiento de Unix

2020-04-14: Actualización. El enlace estaba mal, corregido.

Centro de Exposiciones del Centro de Conocimiento sobre servicios públicos electrónicos. Pantalla simulación perforadora de fichas. Otro artículo sobre el funcionamiento de herramientas que utilizamos. En How Unix Works: Become a Better Software Engineer un resumen sobre el funcionamiento del sistema operativo Unix.

Empieza con la filosofía:

  • Escribir programas que hacen una cosa y la hacen bien.
  • Escribir programas que trabajan bien juntos (sin salida extra, sin interactividad).
  • Escribir programas para manejar flujos de texto, que es un interfaz universal.

Let’s start at the core - the philosophy behind Unix.

Write programs that do one thing and do it well. Write programs to work together. (no extra output, don’t insist on interactive input) Write programs to handle text streams, because that is a universal interface.

Luego habla de procesos, ficheros, el sistema de ficheros y un buen resumen del sistema en general.