Los sistemas de control de versiones se basan en poder calcular de manera eficiente la diferencia entre dos ficheros. En How different are different diff algorithms in Git? hablan justamente de eso.

Identifican tres casos de uso de estas diferencias y comparan sus prestanciones.

From our systematic mapping, we identified three popular applications of diff in recent studies.

Fundamentalmente: recolección de métricas, identificar la introducción de fallos (bugs) y obtener parches (patches). Con dos algoritmos, Myers e Histogram.

In our empirical analyses, we conduct three comparisons based on the most popular usages of git diff found in our mapping study: collecting metrics, identifying bug introduction, and getting patches. We investigate the disagreement between two diff algorithms: Myers and Histogram, and take a manual measurement of their quality in generating the diff lists.

Lectura interesante.

Un ejercicio curioso en Getting a program right, in nine episodes donde Bertrand Meyer nos acompaña donde desarrolla un programa sencillo y lo va mejorando mediante técnicas de verificación formal.

Aunque el testing ha ganado muchos adeptos hay que recordar lo que decía Dijkstra: las pruebas pueden demostrar la presencia de errores, no su ausencia.

in fact, I have always thought that the inevitable Dijkstra quote about testing — that it can only show the presence of errors, not their absence

Esto no es hablar mal de las pruebas, es sensacional poder encontrar partes de nuestros programas que están mal.

La verificación aporta otro tipo de valores, y de eso va lo que se puede leer allí. El programa es una búsqueda binaria, que es un concepto fácil de entender, pero no tan sencillo de hacer complemtamente bien.

Interesante.

De la mano de blockchain han venido los smart contracts: se trata de ‘programas’ o ‘codificaciones’ de intenciones, condiciones y consecuencias que gracias a esta tecnología permitirían que determinados contratos puedan ejecutarse sin necesidad de que los humanos intervengan (en la realización de los hechos del contrato en sí, se entiende).

Desde la ignorancia informada, uno siempre ha pensado que si se ha de codificar determinadas condiciones de la vida en un contrato la cosa ya es suficientemente compleja. Si a eso le añadimos la ejecución automatizada, es probable que haya que hilar más fino. Y, claro, aparecen los bugs y las vulnerabilidades.

De esto hablaban en Las 5 vulnerabilidades más habituales de los Smart Contracts y lo más gracioso es que los fallos se parecen mucho a los de los programas ‘normales’.

• Errores aritméticos con números enteros

Desbordamientos, falta de precisión, …

• Vulnerabilidades del límite de block gas

El límite de block gas es la forma que tiene Ethereum de asegurarse de que los bloques no crezcan demasiado. Simplemente significa que los bloques están limitados en la cantidad de gas que las transacciones contenidas en dichos bloques pueden consumir. En pocas palabras, si una transacción consume demasiado gas nunca cabrá en un bloque y, por lo tanto, nunca se ejecutará.

En determinadas circunstancias esto provoca que haya instrucciones de los contratos que nunca llegan a ejecutarse.

• Falta de parámetros o controles de precondición

Si hace falta que algo se cumpla a la hora de ejecutar un contrato, debemos estar seguros de que los datos que se reciben son adecuados.

• Frontrunning

El frontrunning potencial es probablemente el tema más difícil de prevenir en nuestra lista de vulnerabilidades comunes. Este puede definirse como la apropiación de una transacción no confirmada, y es consecuencia de la propiedad de transparencia del blockchain.

• Bugs de lógica simples.

No hace falta buscar, de todas formas, fallos muy sofisticados. Parece que es frecuente encontrar:

… el problema más común que detectamos es la presencia de errores simples en la lógica del smart contract. Estos errores pueden ser el resultado de una simple errata, una mala comprensión de la especificación o un error de programación mayor …

Interesante.

Esta entrada habla de Python, pero a veces por desconocimiento (o comodidad) no utilizamos todas las características de nuestros lenguajes favoritos y me pareció de interés.

En Reduce Memory Usage and Make Your Python Code Faster Using Generators hablan de los generadores, como un mecanismo para gastar menos memoria y generar un código más eficiente en Python.

Técnicamente, un generador es una función que utiliza yield en lugar de return nos dice el autor.

A generator looks a lot like a function, but uses the keyword yieldinstead of return. Let us take an example for better understanding.

Cuando hacemos una llamada tenemos un valor, pero con algunas característias interesantes. Por ejemplo, la función next(), que nos devolverá el siguiente valor generado por la función original (esto es, es una función que nos puede ir proporcionando valores sucesivos).

The important thing to note is how state is encapsulated within the body of the generator function. You can also step through one by one, using the built-in next() function:

En Python podemos utilizar la función range() para generar una sucesión de valores, que genera(ba) un coste importante (según el tamaño, claro) en espacio y tiempo al ejecutarse. Aunque allí no se dice, que hace mucho tiempo que teníamos xrange() y que en Python 3 range() también es un generador, con lo que el problema no sería tal.

En todo caso, parece que casi siempre merece la pena evaluar las consecuencias de las estructuras que utilizamos.

Uno de los consejos que se dan siempre en criptografía, es no inventar nada. El tema es suficientemente complejo para que alguien con poca experiencia pueda equivocarse y hacerlo mal. En Rolling your own encryption. What could possibly go wrong? hacen un pequeño recorrido (con código en Python) por diversos métodos de cifrado a modo de divertimento (y sin ninguna garantía de calidad).

Encryption is tricky to get right. Because some data and communications might be very sensitive or even life-critical for people, beginners are often - and quite rudely- shunned away from playing around with how it works. But if people don’t learn by making bad ciphers, they will have difficulty understanding why the good ones are good.