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.