Saturday, September 26, 2009

El castigo justo

Via Andrés Diplotti me encontré con una campaña para que el gobierno británico pida disculpas por la condena sufrida por Alan Turing.

La historia de Alan Turing, el hombre que rompió el código nazi (*), el hombre que ayudó a sentar las bases de las reacciones retroalimentadas ( el libro de John Gribbin 'Así de Simple' es muy recomendable y que ganas me acaban de dar de escribir sobre la ley exponencial y su aplicación al análisis de performance del software) es interesante y triste.

Los comentarios se escriben en el manchester evening news como reacción a la noticia dan un poco de asco. Desde el energúmeno que dice que Turing no se jugaba la vida como lo hacían los soldados (mi antimilitarismo visceral me tienta a escribir que de energúmenos que intercambien balazos el mundo está lleno, mientras que de genios que rompan la codificación enemiga, sienten las bases de la informática y todo lo que decíamos antes, en cambio, venimos escasos) hasta el que cree en el absolutismo de las leyes diciendo que Turing rompió las leyes vigentes en su época y que por lo tanto las disculpas no son necesarias. La misma lógica que nos llevaría a concluir que Kaltenbrunner no rompió las leyes vigentes en su época por lo que su condena fue injusta.

Turing, como Oscar Wilde años antes, fue condenado por gay. Así de ridículo, así de inadmisible. Hace unos pocos días, Gordon Brown se disculpó por la condena. No va a traer a Turing ni a todos los que han sufrido semejante injusticia de vuelta, ni siquiera va a salvar a los que las sufren hoy en varios lugares del planeta, pero aún así es un paso necesario: que un estado reconozca los abusos que ha cometido, y los reconozca como abusos es una condición necesaria para que no se repitan (dije 'necesaria', no 'suficiente')

Por estar guiada por imbéciles, la humanidad perdió todo lo que Alan Turing podría haber dado para mejorar nuestra vida (no me cabe la menor duda que los avances científicos son el factor que más incidencia tiene en nuestra calidad de vida). Terrible para el pobre Alan, pero un castigo castigo justo .

(*)
sí, claro, los polacos lo hicieron antes, solo que muchas veces tardaban más tiempo que el que tardaban las órdenes en volverse obsoletas... y el objetivo de la criptografía no es hacer ilegible el mensaje desde acá hasta la muerte térmica del universo, sino que el tiempo requerido para romper el código haga la empresa inútil

Sunday, September 20, 2009

La crisis como oportunidad

- En la moto la carrocería sos vos
- El problema que tenemos es que no hay documentación
- Acá lo que hace falta es calidad institucional
- Acá el problema es el clientelismo político
- Lo que sucede es que el gobierno no quiere mejorar la educación para gobernar un pueblo ignorante


Podría seguir citando frases así de pelotudas, pero mi preferida es la del título. Me gusta, me fascina esta frase tan común entre vendedores de cursos, libros y seminarios que nos entregan la verdad revelada, que se revela, precisamente, como un par de obviedades genéricas escondidas detrás de un lenguaje altisonante. Creo que le gana a las boludeces que puede decir mi abuela, a las de un project manager medio burócrata, a las que dicen periodistas analfabetos funcionales dedicándose temas que superan su capacidad de análisis y formación, o incluso a las que dice un tachero (conductor de taxis) haciendo análisis sociológicos.

"La crisis como oportunidad" es un título que copa seminarios, artículos de revistas de negocios, cursillos y demás timos cuando empiezan a asomar las primeras amenazas de crisis. No creo que sea para sorprenderse, al fin y al cabo la crisis también afecta a los vendedores de amuletos y brujerías, aunque, claramente, menos que a los vendedores de cosas realmente útiles.


La frase en cuestión se basa, supongo, en una idea con algo de lógica: una crisis cambia el statu quo de un sistema, lo sacude un poco, hace caer a quienes tenían lugares establecidos y eso abre espacios que antes estaban cerrados. Puede que el mecanismo base funcione, pero tomarlo con el optimismo que intentan desplegar quienes titulan así sus trabajos se asemeja a pensar, en el medio de un terremoto, 'que bueno! en el futuro habrá más plazas y espacios verdes!". Los espacios se abren con sangre y muertos y antes de alegrarnos livianamente conviene pensar si vamos a contar cadáveres o vamos a ser uno.

Decía, puede que sea cierto que en las crisis es donde se puede ganar más. Lo podemos ver pensando en el inversor que compró propiedades en argentina en 2002 y las vendió en 2007. Cuando hacemos retrospectivas pensamos que lo que terminó por pasar era inevitable y que deberíamos haberlo sabido: pero no estábamos condenados al éxito en 2002, ni siquiera estábamos condenados a los sojodólares que entraron en malón entre 2003 y 2007 y crearon lo que crearon. La crisis fue una oportunidad, sí, pero los espacios se abrieron estaban regados de sangre, sufrimiento, quiebras, desempleo y pobreza. El hecho de que, pasada la crisis, tendamos a pensarla solo como oportunidad (o a sobrevalorar ese aspecto) se explica un poco por el sesgo de retrospectiva.

En realidad, este post esta recorrido por una pregunta. Digo, yo, que usualmente (al menos en persona, ignoro la imagen que doy en este blog) parezco un tipo con opiniones bastante establecidas, no estoy seguro de que papel podría jugar el optimismo en nuestro desarrollo y crecimiento. Conviene ser el optimista que ve la crisis como oportunidad? O es mejor tener los pies sobre la tierra y recordar que la sangre que riegue una nueva oportunidad podría llegar a ser la propia?. Cuando uno escucha a los triunfadores, ese grupo tan difusamente definido (o en realidad, cuando se habla de ellos), se recuerda que fueron gente optimista, que siempre creyó en su triunfo. Por supuesto que se trata de un problema de sesgo de selección: por cada optimista triunfador hay unos cuantos optimistas en el cementerio... Aún así, la pregunta persiste.

Wednesday, August 26, 2009

Muchos Mitos

Como comentaba hace un tiempo, estoy trabajando con Sql Server. Eso no solo implica cambiar de motor y olvidar algunas cosas que en Oracle estaban desde la década pasada (me olvidaba de una en el post anterior: poder hacer inserts masivos desde variables en memoria, y poder hacer updates masivos a secas), sino también cambiar de comunidad, leer otros libros, otros blogs, hablar con otra gente.

Además de mi pequeño berrinche por perder algunas features que me han gustado, he notado algo peor: la comunidad de Sql Server es notablemente más pobre que la comunidad de Oracle. Y no lo digo porque no haya personas como Tom Kyte, Craig Shallahamer, Jonathan Lewis o Cary Millsap (porque, por ejemplo, Kalen Delaney evidentemente sabe de que habla), sino porque hay un concepto que en la comunidad de Oracle está bastante claro y que la de Sql Server no parece haber descubierto: la gestión de performance por índices agregados no sirve. Pareciera a veces que a los muchachos de Sql Server les falta leer a Neil Gunther.

Los libros de performance de Sql Server que estoy leyendo insisten, todos, con la vieja y ridícula idea de hacer una linea base de indicadores cuando tu sistema anda bien y luego detectar desvíos sobre esos indicadores, así, de alguna manera, detectarías los problemas de performance antes de que sucedan viendo los síntomas antes de que se manifiesten en el ambiente productivo. Y cuando tenés un desvío, apretás el botón rojo ponés la batiseñal en el cielo y al rato vienen superman y linterna verde (bueno, nadie es perfecto) a rescatarte.

Esta idea tiene varios problemas. Diría que esta idea solo tiene problemas. Y en todos los niveles. Empecemos.

Primero, establecer una linea base de indicadores cuando tu sistema anda bien es una quimera, por varias razones: a veces llegás, como consultor experto en performance, como DBA, como arquitecto, como galeote o lo que fuera a algún lugar donde, si las cosas anduvieron bien, vos jamás las viste. Otras, el sistema cambia lo suficiente como para que la línea base se desactualice antes de que tenga validez estadística (esto implica mayor funcionalidad que implica más carga que requiere una actualización en hardware: o dicho de otra manera, el software cambia). Y a veces (esto es particularmente cierto en las puntocom), no se necesita que cambie el sistema, tan solo cambia el patrón de uso por alguna condición comercial o del entorno.

Otro problema tiene que ver con que el conjunto de indicadores de un sistema corriendo no es un sistema de ecuaciones con solución única. Es decir, que un sistema puede andar bien con varias combinaciones de indicadores. El único indicador razonable para medir la performance es el tiempo de respuesta en relación a la carga de trabajo: si el resto cambia pero mi tiempo de respuesta es razonable, entonces está bien independientemente de lo que diga el hit ratio, la tasa de inserción, la cantidad de log file syncs (o como se llamen en Sql Server) o lo que fuera.

Por último (cerrando los problemas que se me ocurren ahora, no pienso poder abarcarlos todos), muchas veces los indicadores no sirven para nada. El indicador más exitoso en esto de no tener ninguna utilidad práctica es el hit ratio (calculo que porque es el más fácil e intuitivo). Cary Millsap explica por qué el hit ratio no es un buen indicador, demostrando que un hit ratio muy alto puede ser problemático. Particularmente nunca vi un caso así, pero sí vi bases con hit ratios 'bajos' (de alrededor del 70%) que soportaban sistemas que escalaban muy bien y con excelente tiempos de respuesta.

El problema con el hit ratio es el viejo problema de confundir correlación con causalidad. A veces, ciertos problemas que degradan la escalabilidad y los tiempos de respuesta, también bajan el hit ratio, lo que no quiere decir que todos los problemas de performance lo hagan ni que un hit ratio menor al 90% solo pueda ser causado por algún problema. Lo mismo se aplica a cualquier indicador.

Millsap usa el siguiente ejemplo: supongamos dos conjuntos de consultas que obtienen exactamente el mismo conjunto de datos. El primero luego de correr en un sistema tiene un 99% de hit ratio y el segundo un hit ratio de 90%. Es mejor el primero?. Depende: supongamos que el primero hizo 10000 lecturas (entre lógicas y físicas) y el segundo 100. Millsap aclara que "el hecho de que acceder a memoria sea 10000 veces más rápido que acceder a disco no significa que una lectura lógica (resuelta en el caché) sea 10000 veces más rápida que una lectura física (en los datafiles)". Más aún, si tenemos consultas que leen inecesariamente una y otra vez los mismos bloques, el hit ratio será alto.

Por supuesto, mis rápidos comentarios sobre el artículo de Millsap no son excusa para no leerlo. Incluso si no se trabaja con Oracle, los conceptos se aplican a cualquier base de datos.

Resumiendo, los mejores indicadores (debería decir 'únicos indicadores') de la performance de un sistema son sus tiempos de respuesta y su capacidad de escalar, no un hit ratio o una esotérica combinación de indicadores. Ignoro cuanto tiempo tardará la comunidad de Sql Server en darse cuenta de esto. Tal vez cuando tengan que soportar un volumen realmente alto.

Monday, August 17, 2009

El mejor argumento

Me gustan los debates filosóficos. Y me gustan, entre otras cosas, porque a diferencia de las discusiones en donde hay algo en juego (como en el trabajo, en política o en la ética aplicada, por ejemplo) se pueden mencionar los buenos argumentos del contrincante sin arriesgar nada.

Puedo, por tanto, mencionar el mejor argumento de los que creen en la hipótesis dios. Por supuesto que no me refiero a uno al que le importamos y que, como diría Mark Twain, ronronea como un gato mimoso cuando escucha que le dedican horribles cantos desafinados. Me refiero al 'gran diseñador indiferente': ese que estableció las reglas y se desentendió del asunto y que es tan imposible de demostrar como de negar y cuyos efectos en la realidad serían perfectamente imperceptibles (dice Leonardo Moledo a coro con Gregorio Klimovsky, con mucha razón, que no existen diferencias prácticas entre creer en este último dios y en ninguno).

Tengo que hacer un esfuerzo para cortar las digresiones, que si hay un tema que las favorece es este y mencionar el argumento: la irrazonable efectividad de las matemáticas en las ciencias naturales. Este concepto fue propuesto por Eugene Wigner, maravillado ante la increíble manía del universo físico de dejarse modelar por construcciones matemáticas. La matemática es algo que construimos nosotros, decía Wigner, y por lo tanto es asombroso que el mundo físico, que nosotros no creamos, se explique tan bien por ella. Alguien, concluye Wilder, nos ha dado un regalo (inmerecido, se apura a aclarar en un arranque de modestia religiosa) magnífico: que una construcción humana explique aquello que los humanos no creamos. Alguien nos ha dado una sutil, hermosa, y maravillosa pista de su existencia. Casi que me gustaría creer en un dios con tan buen gusto y tan sofisticado, que gusta de dejar hermosas y crípticas pistas de su existencia.

Razones para maravillarse no faltan. En muchos casos (no me animo a decir 'en casi todos' por falta de conocimiento), la construcción matemática precedió a la utilización física. Einstein estaba buscando una construcción matemática para modelar sus espacios curvos y se encontró con un trabajo de Gauss que tenía, en ese momento, doscientos años y que no era más que un jueguito matemático. Otro ejemplo asombroso es el de Werner Heisenberg que encontró un modelo para explicar las transformaciones cuánticas: la aritmética de matrices, que existía como jueguito matemático desde, por lo menos, ciento cincuenta años de Heisenberg (y de la sospecha de la teoría cuántica).

Me gusta el argumento, y me parece el mejor de los argumentos a favor de la existencia de dios. Aún así, creo que no es suficiente. Siento vergüenza al meterme en un debate que supera mi capacidad y formación por bastante, pero creo que el realismo matemático es la explicación correcta: la matemática no se inventa, sino que se descubre. Y como la matemática existe en la realidad (se descubre), puede demostrar el asombroso paralelismo que demuestra con la física sin la existencia de ningún generoso y sutil dios que nos permita describir el universo con un invento nuestro.

Si existiera una civilización extraterrestre lo suficientemente avanzada como para tener ciencia, crees que tendrían una matemática igual o distinta a la nuestra? me preguntaron una vez. Mi respuesta fue que 'tendrían la misma, naturalmente', y en ese momento me convencí que la única forma de que tuviéramos una matemática idéntica sería que ésta exista en la realidad. Aunque yo hubiese preferido que la matemática se derivara de la lógica formal, el realismo matemático tenía el terrible atractivo de refutar el mejor argumento a favor de la hipótesis dios.

Por supuesto, el efecto de la irrazonable matemática se da en la física y las ciencias con base física (química, por ejemplo). Nada dice que se de en la economía. Entre otras cosas, porque la irrazonable es la economía y no hay ninguna efectividad en ella que nos asombre.

Sunday, July 19, 2009

Ombligología

O el arte de mirarse el ombligo. Si hay algún lector, sirva esto de advertencia.

Andrés me ha pasado un meme. Hasta este preciso momento, la única definición que venía a mi cerebro cuando alguien pronunciaba la palabra meme era la metáfora propuesta por Richard Dawkins para explicar el concepto de selección natural en un contexto no biológico. Otro ejemplo de selección natural no biológica ha sido el propuesto por el inconmensurable Stanislav Lem en su magnífica novela (permítaseme la redundancia: magnífica novela de Stanislav Lem es redundante) Invencible. No viene al caso, pero siempre está bueno recomendar a Lem.

Pero volvamos a los memes: Richard Dawkins se propone demostrar que el mecanismo de selección natural sobre unidades de replicación pequeñas que sufren variaciones aleatorias funciona perfectamente, y no solo en la biología. Para eso toma como unidad de selección las ideas o conceptos: los bautizó 'memes' y propuso un mecanismo de replicación de los memes mejor adaptados. Ojo, no se trata de los memes más benéficos, sino de los mejor preparados para su propia supervivencia: los memes (o ideas, o prejuicios, o conceptos que albergamos) pueden ser perjudiciales para nosotros, sus anfitriones... tal como la conducta cortoplacista que nos sale tan naturalmente nos pone en peligro.

El concepto de meme después lo tomaron Susan Blackmore, Daniel Dennett y otros más. Dawkins, después de algunas idas y vueltas, parece haber aceptado con gusto que su metáfora sea la base del desarrollo de una nueva teoría, de acuerdo a lo que dice en 'El Capellán del diablo'.

Yo creo que la metáfora de los memes es algo más que una buena metáfora. Digo, al fin y al cabo seguimos creyendo (la primera persona es retórica, por cierto) en un señor de barba muy poderoso que se preocupa por lo que hacemos y que está dispuesto a premiarnos y a castigarnos. Pero prometí alejarme de terrenos procelosos en este blog, y en el próximo post me dedicaré a otro mito, muchos menos nocivo que el mentado de pasada más arriba.

Ahora, al punto sobre el meme de Andrés: que puedo ser?. No se, diría. A mi edad, pasados los 30, no tengo derecho a conjeturar que puedo ser algo que no soy (no dije 'a lograr algo que no logré', dije 'a ser algo que no soy'). Y que soy?. Bueno, a veces soy demasiado negativo, tengo gran facilidad para ver las fallas en lo que miro. Tampoco soy de una única manera siempre, pero a veces soy irritable. Me irritan las frases hechas, me irritan los eslóganes y los pensamientos de peluquería (y me irritan porque se escapan de las peluquerías), soy sarcástico y a veces me vuelvo ofensivo. Y como este blog en anónimo, también puedo hablar bien de mí sin que sea pedantería: soy un buen integrante de casi cualquier equipo, soy hábil en lo que hago (y en casi nada más), puedo abstraer conceptos y tirar relaciones razonables entre conceptos aparentemente alejados, y soy un buen autor de metáforas. Claro que para buenas metáforas, están los libros de Stanislav Lem... ya lo recomendé antes?

Saturday, July 11, 2009

Yo no hago eso en público

"Math is like sex. It's something you shouldn't do in public."
--K. Cunningham (estuve toda la semana diciendo que era de Daniel Dennet. Y no se quien es Cunningham)

"Physics is to mathematics as sex is to masturbation"
--R. Feynmann (de esta estoy seguro)


La verdad es que de ambas frases, solo la primera viene a cuento. La segunda la agrego porque me gusta la comparación, y porque me gusta la matemática. Incluso, no veo en la frase ningún contenido peyorativo hacia la matemática: está claro que es la base de la física, y no podés ser un buen físico si no manejás razonablemente bien la matemática. Es decir, la comparación de la frase es perfecta.

Pasada esta pequeña introducción algo adolescente, puedo ir al punto: me encontré estas últimas semanas con un tipo de personaje, simpático si tenemos suerte, insoportable la mayoría de las veces: el matematicofílico. Este curioso personaje no puede dejar de vocear, casi diría de apostar, las complejidades de los algoritmos que ve por ahí. Es capaz de gritar, desde tres escritorios de distancia 'ese algoritmo tiene complejidad (n)* log(n)!!'. Por supuesto, nadie tiene ganas de ponerse a analizar sus afirmaciones.

Me queda claro que nadie determina en cinco segundos la complejidad de un algoritmo, al igual que nadie puede formalizar un problema combinatorio en cinco segundos. No importa, el matematicofílico es capaz de hacer ambas cosas: puede gritar 'eso es una combinatoria sin repetición de 4 en 8!', o puede proferir el grito de guerra del algoritmo que mencionaba antes, y salir de la discusión, contento de haber sido capaz de iluminarnos con su sabiduría, sabiendo que ahora tenemos una luz para guiarnos a hacer software más performante. Gracias totales.

He encontrado más de un tipo de matematicofílico: desde el chanta absoluto (el otro día, mi amigo P. me hacía acordar de A., uno que calificaría de chanta e indeseable) hasta este que inspiró el presente artículo, que cuando programa lo hace bien, que es un tipo que realmente sabe de informática y que ha cursado la mejor carrera de informática que se da por estas pampas.

De todas formas, existe un pequeño detalle: en este caso, el matematicofílico le pone un parche primoroso a algo que son solo harapos. Y pone la energía en el lugar equivocado. Me explico: el software que solemos hacer, sin ser CRUD crudo, se lleva la parte del león del procesamiento en la base de datos. Del tiempo total de las transacciones, un porcentaje abrumador se consume en la base de datos. Más aún, la base de datos (estamos hablando de MS SQL Server, pero lo mismo sería cierto si estuviéramos hablando de Oracle con su maravilloso RAC) es el componente con escalabilidad horizontal más complicada.

El matematicofílico entonces, decía, gasta su energía en optimizar una parte pequeña del problema, mientras descuida las cagadas que hacen los programadores
cuando acceden a los datos, él incluido, que es bueno cuando hablamos de generar código.

Ignoro por qué, pero el patrón de pensar la base de datos como una caja negra misteriosa que, no importa lo que hagamos, siempre responderá igual está extendidísimo. Y no hablo de los malos programadores, sino de los buenos. El origen de ese problema?. Ni idea.

Monday, June 15, 2009

Enamorándome

Disclaimer: post técnico.

El oráculo siempre me ha parecido la base de datos que, por mucho, aventajaba a sus competidores. Por esas cosas del fanatismo, tenía pocos argumentos porque siempre había trabajado con Oracle, salvo algunas cortas pesadillas donde mi disgusto por la nueva base podía tener que ver más con mis costumbres y hábitos que con la diferencia real entre ellas.

Ahora, trabajando con Sql Server, mi gusto por Oracle se está transformando en enamoramiento. Enamoramiento, claro, como el de un tanguero: llorando por lo perdido. O como canta Serrat, no hay nada más amado que lo que perdí.

Y que perdí?. Esto perdí:
  • En Oracle, de toda la vida, un lector no se bloquea porque otro proceso escriba. Sql Server lo incorpora a partir de 2005. Antes, si queríamos hacer que un lector no se bloqueara por un escritor podíamos leer los bloques sucios (no comiteados).
  • En Oracle, el profiler no agrega carga adicional, tanto que si no fuera por el espacio en disco, uno lo podría tener siempre prendido.
  • En oracle el profiler da datos agregados y también da un listado de los eventos generados por esa sesión: por ejemplo, puedo ver una línea por cada bloque que leyó una consulta, viendo a que tablespace fue. En Sql Server solo tengo valores agregados por consulta. Y que para que quiero ver a donde leyó cada bloque?... por ejemplo para saber si está yendo al rollback (o a la tempdb en Sql Server) para leer consistente. Como me entero en el profiler de Sql Server si el problema es que un stored procedure está recibiendo parámetros innecesariamente largos y la demora está en la transferencia de red? (cosa que me ha pasado en Oracle). Más genéricamente, la comunidad de Sql Server parece que todavía está haciendo análisis de performance por indicadores (tema para otro post, mientras tanto, se puede leer online el primer capítulo del libro de Cary Millsap , particularmente la página 6).
  • En Oracle, existe un paquete, llamado DBMS_STATS (por cierto, si googlean algo de Oracle y caen en oracle-dba.com dba-oracle.com (*), sepan que su autor sabe muy poco de lo que habla), que permite generar estadísticas de las tablas para probar que plan elegiría el motor con otros, hipotéticos, juegos de datos. En Sql Server hay un mecanismo no documentado que permite exportar estadísticas de una tabla que ya existe. El mecanismo de Sql Server genera una larga sucesión de números en hexa que tienen codificados, de alguna manera y claramente inaccesible al resto de los mortales (muy Microsoft's way) las estadísticas. O sea, si querés sacarte una duda sobre una situación hipotética, esperá a que se produzca (sin mencionar lo incómodo que es pedirle al DBA algo cada cinco minutos)
  • Oracle tiene RAC, que no es un mecanismo de snapshots, por más que los admiradores de Sql Server lo intenten comparar con la replicación. RAC no es replicación de snapshots, RAC es un mecanismo por el cual varias instancias de bases de datos pueden acceder a los mismos archivos de datos. Y anda muy pero muy bien.
  • En Oracle puedo correr un debug contra los stored procedures sin necesidad de comprar un producto adicional. En Sql Server necesito una de las versiones de 'gama alta' del Visual Studio.
  • Oracle anda en varios sistemas operativos. Sql Server en uno (concedámosle ese status a Windows)
  • En Oracle, hay un UTL_MATCH, para calcular distancias entre strings que hasta implementa el algoritmo Jaro-Winkler. En Sql Server, claro, lo podés hacer.
  • En Oracle existe una API armada que incluye muchísimas funciones típicamente necesarias, en Sql Server se pueden hacer (con la extensión del CLR en 2005). Un ejemplo?... expresiones regulares (lo que ocurre, emho, es que los programadores windows se enteraron de la existencia de las expresiones regulares hace unos pocos años)
Supongo que habrá más diferencias, que iré disfrutando con el correr de las semanas.

Update: me comenta mi amigo P. que el dominio de la empresa de Burleson está mal, que el correcto es dba-oracle.com. En el link de su nombre hay un artículo de alguien que sí sabe sobre la ignorancia de este tipo. En la página de Jonathan Lewis hay bastante sobre Don Burleson.