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.

Que maestro!

Me gusta encarar proyectos de reingeniería de aplicaciones: tienen algo de candor iluminista (*) por eso de la confianza en el futuro, no se escucha el solapado o no tan solapado pedido del cliente de arreglá tres horas la mierda que nosotros hicimos en seis meses , y por supuesto, uno supone que se le ocurrirá una idea genial en diez minutos que será mejor que el diseño evolutivo que tiene encima una aplicación que hace quince años corre sin problemas ( tendencia innata al creacionismo, o a la irracionalidad, que es lo mismo, que tiene uno).

La idea de diseño evolutivo está tomada de la idea de la evolución de las especies: una aplicación que está andando, sufriendo cambios desde hace diez o quince años y que pasó por ocho presidentes, dos devaluaciones, cuatro incautaciones de depósitos, siete burbujas con sus correspondientes explosiones, doce cambios importantes en la legislación impositiva y miles de cambios menores ha hecho un fantástico trabajo de adaptación al medio. Claro que, en definitiva, el relojero es ciego, por lo que en el proceso adaptativo se generan características que hoy se revelan imperfectas, o directamente como boludeces. Algunas de estas imperfecciones evolutivas son imperfecciones porque cambió el entorno y lo que antes era una ventaja hoy no lo es. Otras siempre han sido malas pero la desventaja que suponen no ha sido incompatible con la supervivencia, todavía.
Así, haciendo arqueología en una aplicación que estábamos reingenierizando, dimos con una obra, no del relojero ciego, sino del diseñador corto. Llegamos a una tabla que se llamaba algo así como xtmaetr, y sus campos eran algo así como:

• ID (bien, lógico, normal)
  
• XTMAEDECR (puedo deducir que la descripción)
• XTMAE_1
• ...
• XTMAE_9

Los ID eran correlativos, y el resto de los campos no tenían absolutamente ningún patrón: un mismo campo tenía una fecha en un registro, para pasar a tener una sucesión ininteligible de caracteres en el siguiente. Le preguntamos al padre de la criatura, quien orgulloso nos repondió: "esta tabla es el maestro". El maestro de qué? El maestro de todo, el master of the universe, alfa y omega, la real y lo posible, el sonido y la furia. A ver si me explico: esa tabla tenía todos los artículos, todos los clientes, todas las sucursales, todas las provincias, y así siguiendo, con un campo "tipo" que decía si estábamos en presencia de un cliente o de una pieza de repuesto de un motor diesel. Definitivamente, un maestro.

Una pena que no llevaran la idea un poco más allá y se limitaran a tener una tabla, como lo explica Tom Kyte: uno no tiene que diseñar nada, ni saber de diseño, ni conocer las características del software de base que está usando, simplemente tiene que hacer algo genérico.


(*) la entrada de la wikipedia de iluminismo no es correcta. Uso en este post a iluminismo como sinónimo de ilustración.

Lóbulo temporal

Quien convenció al mundo, o al menos a algunos IT Architects, que el uso de tablas temporales era una buena idea??!?.

No creo que sea una práctica extremadamente común (el mundo no funcionaría) pero me he encontrado con algunos casos: la última vez, el otro día.

El asunto era más o menos así: una típica aplicación de guarda-recupera-datos, que es lo que hacen, pese a la pretención de los amantes de las multicapas, la mayoría de las aplicaciones comerciales (la existencia de Business Objects que son solo un pasamanos, o peor aún, que implementan cosas que la base de datos hace mucho mejor, será tema para otro post).

La maravilla de la informática con la que mi triste figura dio el otro día tenía un bloque con la siguiente lógica (bueno, sabrán disculpar el exceso del lenguaje que significa llamar 'lógica' a eso):

• El usuario identificado en la sesión podía ser de tipo A o B
  
• Se generaba un número único de operación (con una secuencia)
  
• Si el usuario era de tipo A, se obtenian datos de la Tabla A con una condición y se insertaban en la Tabla TMP agregándole a cada registro de la Tabla TMP el identificador generado anteriormente (así no se mezclaban los datos entre sesiones, no vayan a creer que era una chapuza)
• Si el usuario era de Tipo B, insertaba igualmente en la Tabla TMP pero pero obteniendo los datos de la Tabla B
  
• Para finalizar, hacía un join entre la Tabla TMP, filtrando por el ID de operación, y otra tabla, agregando proyecciones y otras cosas para finalizar mostrando unos pocos resultados.
• Al finalizar, borraba, vía delete, los registros de la Tabla TMP con el ID de operación (obviamente, no podía hacer un truncate porque la tabla la usaban unas cuantas sesiones)

Este portento del ingenio humano en forma de aplicación informática transformaba así una consulta en dos consultas, más unos cuantos inserts, más idéntica cantidad de deletes. Eso sí, la muestra de destreza tecnológica tenía un motivo: la reutilización de código ( no es claro como se reutiliza el último query, más todos los deletes? Que no debieran existir es apenas un detalle que no debe opacarnos la alegría que nos causa reutilizar código), y la lógica de la aplicación, que haría que si esto fuera una única query sería demasiado complicada ( es claro que es mucho más sencillo seguir un código que hace en muchas líneas lo que se podría hacer en una ).

En la contemplación y admiración de tal muestra de capacidad e inventiva pasé unos días, la semana pasada: los gustos hay que dárselos en vida.