Este blog no se muere

"porque el amor, cuando no muere mata; porque amores que matan nunca mueren"; que cantaba y canta Sabina y es un estribillo que me viene perfecto para enlazar el título de este blog con el día de San Ballantains. Si se han dado ustedes cuenta, acabo de utilizar uno de los estribillos más conocidos a lo largo y ancho de España para hacer lo que decía en el último blog: Manipular a la gente y hacerla pensar que tengo pensamientos profundos o cosas asi. Para parecer más profundo podría haber copiado toda la letra pero es que el cabrón de Sabina en este canción tambien dice "yo no quiero catorce de febrero / ni cumpleaños feliz" y me fastidia la asociación título - San Ballantains.

Asi que no puedo ocultarlo. Odio San Valentín. Me parece absurdo. Como dije a cierta persona en otro lado de internet, que el día de San Valentín sea "especial" implica directamente que la mayoría del resto de los días del año no lo son; y la vida de dos personas ha de ser realmente aburrida para que los días especiales de su vida sean los dictados por la sociedad y no por su propia iniciativa e imaginación. Pero no todo el mundo tiene iniciativa ni imaginación asi que comprendo perfectamente que haya gente que tenga que recurrir al día de San Valentín igual que los discapacitados recurren a la silla de ruedas. Quien mejor que los ejecutivos de las multinacionales para decirnos cómo y con qué productos debemos sentirnos felices. Si ellos conducen un BMW y viven en un chalet y no tienen que preocuparse de poder pagar la hipoteca el mes que viene, deben saber de felicidad más que nosotros.

La cosa es que en mi anterior post terminaba con un "Y hasta aquí llega este blog. No quiero hacerlo más largo". Alguien pensó que eso significaba que iba a cerrar el blog, y nada de eso, me refería a ese post en concreto.

Zona friki del post:

En slashdot publicaron el pasado una más larga y más que interesante entrevista con Jarod Jenson. Yo no sabía quien era antes de leer la entrevista, pero si no hubiera dicho que no lo se habría creado alrededor de mi una especie de halo de superioridad que podría haber utilizado para hacer que la gente se crea argumentos que no tienen ni pies ni cabeza (vale, ya me callo con la tontería esta de "como manipular", pero lo acojonante es que es verdad). El que si que se quien es es el entrevistador, Kirk McKusick, creador del logo de FreeBSD y desarrollador de su sistema de softupdates, uno de esos genios que cualquier proyecto quisiera tener

Es una entrevista larga, muy larga, pero recomiendo leerla. Aquí va un resumen porque se que habrá gente que no la leera: El tipo este fue administrador de Enron, allí estuvo a la cabeza de un proyecto para crear un programa de una aplicación de ecommerce de esas que son la leche. El tio parece que de lo que sabe es de encontrar y arreglar fallos de rendimiento en programas. Ahora tiene una empresa que se dedica a eso, a mirar programas de otros y a decirles por qué son tan lentos sus programas.

Y ahora aquí va una lista de las cosas que me llaman la atención de este tipo: En primer lugar, lo que cuenta de la aplicación de Enron esta. Empezó a desarrollarla y cuando estaba a mitad del desarrollo, decidió sacar a toda la gente que fuera posible y empezar a re-desarrollar toda la aplicación de cero utilizando todos los conocimientos que estaba teniendo con el desarrollo de la primera versión. Todo esto con la primera versión aun sin finalizar: Dejó a los programadores necesarios para sacar la versión 1 y se puso con la dos. If we had gone live and then just tried to go back and fix what is known bad code, then it wouldn't have worked. Starting from scratch was by far the best decision. Es decir, si hubieran intentado arreglar la primera versión, intentado mejorar una arquitectura diseñada mal desde el principio, no hubiera funcionado. Reescribirlo le ha llevado a que esa aplicación haya acabado siendo famosa por su velocidad y estabilidad y que haya tenido varios premios de la industria.

Luego cuenta cosas de lo que trabaja ahora, de decirles a los demás donde están sus fallos. La gente va y le dice: Tal programa va fatal, y por mucho que miramos el código no tenemos ni puta idea de qué pasa. La idea es que su empresa va, y se pone a hacer un diagnóstico del sistema: Utilizan herramientas de monitorización (mpstat, vmstat, y su preferida que parece ser Dtrace) para ir aislando el problema, y luego mirar el código para ver que pasa. Cuenta historias muy interesantes, como cierta aplicación que utilizaba el NotifyAll de java para notificar a un thread de algo. El notifyall despierta a todos los threads, y al tener la aplicación cientos de threads y pocos procesadores, se iniciaba una "carrera" por conseguir tiempo de procesador, por entrar en tal zona crítica para luego darse cuenta de que ellos no tenían que hacer nada...con tan solo borrar las tres letras "all" de "notifyall" el rendimiento subió por las nubes: 170%.

Luego está el caso de una aplicación matemática de montecarlo, que iba lenta; el programa tenía diez años y los programadores llevaban todos menos de uno trabajando en él. Le llamaron. Se puso a mirar. Se dió cuenta que el programita hacía muchas llamadas al sistema: Con dtrace averiguó que el programa estaba llamando miles de veces a "getenv" para saber las variables de entorno. Miró el código, y resulto que en loop principal del programa habían dejado código para que si exportabas una variable de entorno tipo "DEBUG", el programa generara información de depuración. Se les había olvidado quitarla, y el programa estaba continuamente llamando a getenv() para ver si había que sacar información de depuración, y los programadores habían estado monton de tiempo comiendose la cabeza con que si el algoritmo era bueno o no. Tiempo que tardó el tipo este en encontrar el problema: 3 minutos, mejora del 67%

Moraleja de todo esto: La gente es estúpida, y se puede ganar mucho dinero aprovechándose de la estupidez de la gente, y lo que es más impresionante: de forma legal. En este caso, de fallos obvios de programadores y de empresas que cansadas de sus programadores y agobiadas por las prisas de las fechas llaman a la empresa de este tipo a que les solucione la vida: I would say that the majority of the fixes that we do are fewer than 10 lines of code, either manipulating it some way, removing it, or adding it, to get major performance gains.. En una exposición reciente, puso un stand de su empresa con un reto: Llévenos sus programas, y en una hora o menos haremos que su programa vaya más rápido. De los 18 programas que les llevaron, 17 salieron con mejoras, y el que no salió era un programa de 227 lineas que calculaba MD5s doscientas veces en java y que pura matemática, poca carne donde morder y que no se molestaron. Si buscais en google podeis encontrar posts del tio en los foros de opensolaris, es un verdadero friki. No parece haber escrito ningún libro, pero desde luego ya le he mandado un email preguntando si va a escribir alguno o si puede recomendarme alguno