Así  como las plataformas de desarrollo van evolucionando, los paradigmas en que éstas están basadas van recreándose, adecuándose a las nuevas exigencias, otro tanto ocurre con las bases de datos

Sin embargo, en este último caso la evolución es más silenciosa y no pocas veces termina pasando desapercibida. Quizás esto sea atribuíble a que las tecnologías de bases de datos, por estar ligadas a unos pocos aspectos concretos del software (persistencia, inteligencia de negocios, etc) no suelen despertar en los desarrolladores el mismo nivel de interés que el que logran las plataformas de desarrollo. Plataformas como Java EE o .NET, pero también el stack conocido como LAMP (por Linux, Apache, MySQL y un enjambre de lenguajes hasta hace un tiempo compuesto por PHP, Python y Perl, pero ahora Ruby se sumó a la partida) también contemplan acceso a datos en una forma más general la que, además, sirve para el resto de las otras cosas. Así es como las bases de datos, finalmente, no generan la misma atracción

Como consecuencia, tenemos el riesgo de caer en "pecados" como el que me referí alguna vez: Repudio de la Infraestructura (Infrastructure Repudiation) y creer que todo es absolutamente soluble desde la plataforma programable y el resto es algo circunstancial que, de poderse evitar, debería hacerse. Al respecto quiero decir que si bien en Java o en C# podemos programar clases y métodos de manipulación intensiva de datos de una misma fuente, como alternativa a poner esa lógica en la base de datos misma, el bandwith involucrado así como también la posibilidad de que nuestro entorno general de programación no alcance los mismos niveles de optimización para la manipulación intensiva de datos puede hacer que ambos lados de la aparente ecuación no sean realmente tan iguales. Nada más, al respecto. Sólo algo a tener en cuenta. Hay que medir y confirmarlo o refutarlo

Por consiguiente a veces caemos sin mala fe en vicios innecesarios como los de creer que las limitaciones que alguna vez tuvieron las bases de datos nunca fueron resueltas ni se espera que lo vayan a ser alguna vez. Eso es falso ya que en la medida que el segmento de las bases de datos, comercialmente hablando, sigue teniendo una demanda competitiva, tanto los principales vendors así como los jugadores de segunda línea siguen investigando, perfeccionando y evolucionando sus ofertas de manera de hacer la diferencia frente a los demandantes que, finalmente, los decida a optar por ellos

En este post quiero comentar algunas viejas deficiencias que las bases de datos presentaron alguna vez, hoy superadas pero que conversando por ahí sé de más de un caso que no se dieron por enterado (señoras y señores, estoy hablando también de mí: caigo en ese vicio reiteradamente y espero con este post expiar mis culpas)

"ALTER TABLE No Hay Que Hacer Porque Es Caro"

El primer hecho que luego quedó en mito es la creencia de que el comando ALTER TABLE se ejecuta pesadamente porque debe recrear los datos de la tabla alterada, la que queda lockeada durante esa reconstrucción. En efecto, hace 10 años atrás la información de los registros de la mayoría de las bases de datos se guardaba en forma contigua. Por consiguiente si teníamos que modificar la estructura de una tabla (tipicamente el comando ALTER TABLE de SQL), esto iba a implicar una reescritura de todos los registros de dicha tabla, basándonse en el nuevo esquema -si la tabla tenía muchos registros esto era, me acuerdo, desalentador-

Hoy eso es parte de un pasado que seguramente aquellos que se adentraron en el maravilloso mundo de las bases de datos terminando el siglo pasado (digamos, 1999, año 2000 o después) ni lo llegaron a conocer

Lo cierto es que allá por el 2001 con Alejo, amigo y arquitecto también, nos perdimos los dos un proyecto porque el cliente nos pedía especialmente resolver un problema de rendimiento que tenía su aplicación, ya que habilitaba a los usuarios a definir "columnas virtuales" en los esquemas de las tablas-entidades de negocio

Su workaround para evitar la reescritura de registros era meter esas columnas virtuales como filas en la siguiente forma: suponete que la tabla a customizar era la tabla CLIENTES. Supongamos también que el usuario había generado como columnas virtuales COLOR_CABELLO y CANTIDAD_HIJOS. Este buen amigo, entonces, llevaba en una tabla extra algo como la que te muestro a continuación:

Como notarás: la última columna ("Valor") era de tipo VARCHAR para poder alojar practicamente cualquier tipo posible de valor. Había, claro, otra tabla más (o meta-tabla en realidad) para alojar el esquema de las columnas virtuales (siguiendo el ejemplo, era la meta-tabla donde se indicaba que la tabla CLIENTES tenía una columna virtual llamada "COLOR_CABELLO" de tipo VARCHAR, otra llamada "CANTIDAD_HIJOS" de tipo INT, y así

La consigna era, a nivel de aplicación, no complicar la lógica de acceso a un registro como el de CLIENTES -incluyendo sus columnas extendidas- con toda la plomería de acceder a estar columnas que en realidad se guardaban en filas. Cuestión que esta gente había hecho toda una biblioteca de acceso donde parseaban cada columna virtual según su metadato, y sacaban hacia afuera registros de primera clase, lineales... aunque con una performance de cuarta

Este cliente que nos llamó estaba desesperado por eso, porque esta aplicación él la vendía, y sus -a su turno- clientes estaban que se lo querían comer crudo. Alejo entonces le propuso migrar hacia un contexto donde cuando el usuario confirme un nuevo esquema de columnas, estas ya no serían virtuales sino que la aplicación reaccionaría emitiendo un ALTER TABLE en la tabla elegida para extender su esquema directamente en el motor de la base de datos. Nuestro cliente inmediatamente nos destacó que mientras el usuario que modifica esquemas está haciendo lo suyo, el resto de los usuarios accede en forma concurrente a la tabla, de modo que la complejidad de ejecución de un ALTER TABLE iba a llevar las cosas a una crisis inmensamente peor porque en ese caso se lockearía la tabla entera por un período (minutos? tal vez horas?) inaceptable. Además, normalmente el usuario que modificaba el esquema alteraba una columna, salvaba, alteraba otra, salvaba, y así se podía pasar un par de horas modificando esquemas. Vale la pena aclarar que el cliente se quedó bastante asombrado de la propuesta insólita, onda "yo creía que estos eran dos expertos que me iban a enseñar a resolver este bardo y resulta que les tengo que enseñar el abecé de las bases de datos"

Lógico, Alejo -con la tranquilidad que lo caracterizó siempre- le explicó que el comando ALTER TABLE no iba a producir ese resultado que el cliente temía, y que de hecho en cualquier base de datos de las de más conocidas, los valores de las columnas de un mismo registro no necesariamente se almacenan consecutivamente y que, a decir verdad, el único que sabía cómo almacenar y dónde había dejado cada cosa es el motor de la base de datos, de manera que la base de datos ya hacía lo que nuestro cliente hacía a manopla -a diferencia de que, y esto lo digo yo, en el caso de la base de datos, esa lógica fue escrita por gente que investigó científicamente el tema, le hizo tuning a los resultados, elaboró mecanismos para atenuar el peor caso estadístico, promover el caso favorable (al que optimizó), etc-

El cliente nos despidió con un "ok, nos vemos" y no nos volvió a devolver llamados. Sencillamente no nos creyó y por esa incredulidad se perdió la oportunidad -y nos la negó a nosotros- de optimizar su instalación

"Las Claves Principales Se Generan Por Programa"

No es éste el único caso de evoluciones truncas debido a la incredulidad (que es una forma de ignorancia). Otro ejemplo similar es el de la generación de valores únicos a ser usados como claves principales (Principal Key o PK las que, inherentemente, no admiten duplicados). En tiempos precámbricos, las bases de datos si bien permitían designar columnas como clave principal, no ofrecían mecanismo alguno en el que delegar la tarea de generar valores unívocos

A consecuencia de eso, normalmente estas claves se solían elegir de tipo numérico entero de manera de ir generando claves únicas mediante el mantenimiento de un contador en alguna tabla aparte (normalmente una tabla de parámetros de configuración). De esta manera, añadir un nuevo registro a la base de datos implicaba por lo menos tres operaciones con registros:

• Uno para leer -lockeándolo- el contador
• Otro para grabarlo -liberándolo- luego de sumarle 1 (uno)
• Un acceso final para añadir el nuevo registro usando como clave principal el resultado de la suma

Si esta lógica era controlada desde la capa de acceso a datos, externa a la base de datos, estábamos entonces hablando de tres accesos a la base. Un poco mucho si cada inserción requería tres accesos, por lo que los más intrépidos se animaban a adentrarse en el fascinante mundo de los procedimientos almacenados (stored procedures o SPs) que presentaban una doble ventaja respecto de la lógica de manipulación de datos ejecutada offshore:

• Los SP quedan compilados y por consiguiente se ejecutan más rápido que comandos SQL individuales que deben ser interpretados cada vez (frente a esto plataformas como Java han ofrecido la alternativa del java.sql.PreparedStatement, un comando SQL individual que se compila al crearse y a partir de ahí puede reutilizarse; pero no es comparable al SP: está limitado a un sólo comando SQL y además esa compilación expira con la conexión a la base, por lo que una cualquier otra conexión deberá compilar el propio, con el consiguiente consumo de recursos, en definitiva, compartidos)
• Las extensiones a SQL para soportar SP estaban fuertemente enfocadas en el dominio de manipulación de datos, y optimizadas para tal fin. Por este motivo, siempre que se usen para manipulación intensiva de datos, la aplicación podía alcanzar mejores niveles de escalabilidad que si una lógica equivalente era escrita en la capa de acceso a datos de la aplicación. Desafortunadamente una lectura rápida e imprecisa de esto último lleva a varios a creer que en realidad la idea de los SP era poner la lógica, atención, de negocio lo más al fondo posible (esto es, en la base de datos) porque así se iban a alcanzar niveles de reusabilidad sorprendentes. Una salida un tanto cara, en la medida en que SQL extendido para soportar SP no llega a alcanzar ni la versatilidad ni la riqueza de un lenguaje de programación de propósito general (por caso, hay pocos ejemplos de SP orientado a objetos -y en forma limitada, por ejemplo herencia: bien, gracias-, o basados en paradigmas superadores del paradigma estructurado). Por otro lado, tirar demasiada carga de ejecución de lógica de cómputo en la base de datos tampoco era una idea muy inteligente por el hecho de que escalabilidad y alta disponibilidad, hablando de motores de bases de datos, se alcanzan por caminos diferentes que en los middleware o servidores de aplicación tradicionales. Acá hablamos de mirroring y/o clustering, ambas estrategias para datos altamente disponibles. No para capacidad de cómputo altamente disponible

Como contrapartida, los SP suelen no ser portables entre diversos motores de bases de datos, y esto desalentó particularmente a los devotos de la plataforma Java -más que nada imbuídos del leit motiv de Write Once, Run Anywhere ("Escribilo Una Sola Vez y Correlo en Todas Partes")- porque les resultaba inaceptable que, habiendo logrado una aplicación que pueda correr sin modificaciones en ambientes Linux como Windows (mentira: eso sólo si Sun le otorgó a tu aplicación la distinción "100% Pure Java"), cómo era posible que la portabilidad quede resignada por culpa de la base de datos? Esto a más de uno -me incluyo- los motivó a escribir la lógica de manipulación de datos enteramente en la capa de acceso a datos cayendo -una vez más- en el antipatrón de Repudio de la Infraestructura

Pero volvamos a la generación de valores unívocos para claves principales. Venía contando que al principio las bases de datos te dejaban a la buena. Años más tarde algunas bases de datos incorporaron la característica conocida como test-and-set (una traducción literal quedaría incoherente: preferentemente la voy a llamar "leer actualizando"). La función test-and-set resumía los dos primeros pasos mencionados antes (de leer un valor, grabandolo incrementado en uno), devolviendo al llamador el nuevo valor del contador. De esta forma podíamos insertar, como valor para la clave principal, el resultado devuelto por la función test-and-set

Tipos Secuenciados

Posteriormente las bases empezaron a ofrecer la posibilidad de definir directamente la clave principal de las tablas como de un tipo que se autogeneraba en la medida en la que los registros eran insertados. En Oracle este tipo de columnas podía lograrse mediante el comando CREATE SEQUENCE. En SQL Server, como en el resto de las bases de datos principales, este tipo de columnas estaba soportado pero la sintaxis era completamente particular (no estándar). En SQL Server 2005 la clave principal se definiría, por ejemplo, así

Id INTEGER NOT NULL IDENTITY (1, 1)

En este ejemplo, Id es el nombre de la columna, INTEGER es el tipo, y en el caso mío -SQL Server 2005- acepta un valor máximo equivalente a 2^31-1 (dos a la treinta y uno, menos 1; o sea 2.147.483.647). Pero lo que especialmente da la pauta es el modificador del final: IDENTITY (1, 1). Lo que indica es que la columna Id va a recibir valores comenzando de un valor inicial equivalente a 1 (conocido como semilla o seed), y posteriormente el motor de base de datos continuará generando identidades incrementando en 1 el última valor calculado

Claro, si el que manipula ese valor es el motor de la base... cómo nos enteramos qué valor le quedó finalmente a la clave principal? En SQL Server, en particular, la variable de sistema @@IDENTITY va a estar guardando el último identificador generado en tu sesión (eso quiere decir que si en una sesión concurrente se generase otro registro, ambos @@IDENTITY estarán retornando -adecuadamente- valores diferentes)

Este mecanismo de generación de claves principales por la técnica de la semilla y el valor de incremento es adecuadamente bueno y altamente recomendable en aquellos casos que tengas total control sobre tu base de datos y/o el/los servidor/es donde resida (me refiero a que se trate de servidores donde tengas autorización para hacer BACKUP y especialmente RESTORE de tu base en una forma más o menos sencilla -obviamente en un momento planificado y comunicado a los usuarios, pero me refiero a que no tenés que conseguir cinco niveles de firma para poder ejecutar estos comandos de alcance masivo a toda la base. Si ése es tu caso, esta estrategia de generación de claves principales te va a andar bien y es muy recomendable, por cuanto los valores que genera son relativamente memorizables (probablemente no te acuerdes las claves de todos los clientes, eso está claro, pero si justo estás haciendo algo con "Juan Pérez" y de casualidad tenés que ingresar su código a manopla, te podés acordar del número por unos instantes)

En cambio, si no tenés facilitado el acceso a resguardo y restauración de tu base de datos, y de alguna forma tenés que replicar o exportar los registros de un servidor a otro, lamento decirte que este mecanismo no te va a ayudar demasiado en la medida que no se pueden importar masivamente estas columnas secuenciadas con los valores ya fijados: el motor de la base de datos te va a importar el resto de las columnas, en tanto que a la clave principal la va a seguir generando usando el valor actual de la semilla y el incremento. Como consecuencia, no tenés ninguna garantía de que las PKs resultantes van a coincidir con las originales. Si esta clave principal era referenciada como clave foránea (foreign key o FK) desde otra tabla, estas referencias van a quedar apuntandote para cualquier lado (probalo si querés, pero te aseguro que ya me pasó )

Habrá alguna forma de generar claves únivocas pero que no necesariamente estén relacionadas entre sí y se puedan mover de un lado al otro?

Identificadores Globalmente Únicos

Tu salvación para este caso existe, aunque no te va a resultar tan sencillo acordarte valores de memoria, y yo te diría que no vas a zafar de apelar al copy/paste. Porque el otro mecanismo de generación de valores unívocos que hoy la mayoría de las bases de datos, aunque nuevamente cada una a su modo, implementan algo conocido como Identificador Universalmente Único (Universally Unique Identifier o UUID). Si bien como tipo de dato es un estándar sancionado por la Organización de Estándares Internacional (ISO) y hasta hay sugerencias del algoritmo a aplicar para generar claves universalmente únicas como su nombre lo explicita, la probabilidad de repetir valores no es 0 (cero) absoluto. Pero es muy baja de todas formas. Este tipo de datos consiste en 16 bytes, lo que es decir que tenemos 2 a la 128... alrededor de 3,4 por 10 a la 38 claves distintas. La especificación de ISO sugiere, en su apéndice A, un mecanismo de cómputo basado en el reloj del sistema como semilla. Microsoft particularmente, que viene usando UUID desde mediados de los 90 (te habrá llamado la atención, ya por Windows 98, esas tiras raras de números hexa que aparecían en medio de las claves de la Registry -ver figura 2-) usa la "MAC address" de la tarjetas de red junto a una combinación con la hora del sistema

Figura 2 - Un día "común" en la Registry de Windows

Este mecanismo le ha valido a la compañía de Redmond varios reproches, en la medida en que sería posible rastrear desde que equipo en Internet se generó determinado GUID (por Globally Unique Identifier o Identificador Globalmente Único, tal como Microsoft llama al UUID de ISO) y de hecho así se pudo atrapar al que liberó al gusano Melissa (que la sacó barata pero no zafó de la cárcel, ver pormenores del caso en figura 3)

En SQL Server 2005 para que tu clave principal sea de este tipo de datos la tenés que definir como uniqueidentifier en lugar de INTEGER y, contrariamente a los secuenciadores, acá sí tenés que insertar el valor de la columna mediante la llamada a la función NEWID(). Te conviene llamar primero a la función, asignándole el valor a un parámetro de salida de tu SP, y entonces insertar ese valor a la clave principal

Como te contaba hace un rato, estos valores no están secuencialmente relacionados sino que se generan independientemente. Esto entonces no impone restricciones al tipo de clave principal y -tengas o no posibilidades de hacer   o al menos importar o exportar registros y esquemas-, vas a poder copiarlos entre bases de datos equivalentes en distintos servidores sin alteraciones al valor de la clave principal

La contra de este tipo de datos, como también te comentaba recién, es que es muy compleja (digamos "imposible" y no exageramos) de memorizar por lo que si tenés que chequear listados, cotejando el valor de esta columna, o mismo si la tenés que ingresar a mano o dictarsela a alguien -cada tanto te va a pasar, esperemos que poco- la cosa se ve no tan atractiva

Epílogo

Te voy a pasar más data sobre estos temas a medida que me vaya (y me vayan) apiolando de mas novedades

 Hace  un par de semanas atrás liberaba la segunda edición del boletín "extraoficial" para Arquitectos de Software. La idea del mismo era contar las diez (10) cosas que más me gustaron del último mes respecto de todo lo que hay del interés general de arquitectos de Software, con la consigna de que no estuvo Microsoft involucrada en ese contenido (a ver, sí puede ser contenido acerca de productos y servicios de la compañía de Redmond eventualmente, pero no que Microsoft los produjo directamente o a través de terceros)

Ahora llega el momento de contar, desde aproximadamente el 15 de Marzo hasta el 15 de Abril pasados, las diez (10) cosas que Microsoft liberó, nuevamente del interés general de arquitectos como vos y yo. Acá vamos

1	Se Puede Realmente Aplicar Web 2.0 en la Empresa? Si yo pensara que no, ni perdería el tiempo en poner este webcast en esta selección de diez piezas más importantes para arquitectos. Mi amigo Mohammad, aquel de la presentación de Vista y Office para arquitectos (ex arquitecto de Sun ligado a la industria financiera) nos cuenta un poco que es Web 2.0, qué suele tener una aplicación web normalmente para ser considerada del tipo "2.0", y finalmente nos explica cómo una industria como la financiera (banca, seguros, etc) puede capitalizar sus beneficios A continuación, podés seguir explorando ASP.NET AJAX en la banca, webcast perteneciente a la misma serie que el de Mohammad
2	eXtremme Programming, SCRUM y Cía en el Nuevo Centro de Desarrollo Ágil para Arquitectos Con el padrinazgo de Peter Provost, Jefe de Desarrollo de Patterns and Practices, hemos inaugurado una nueva sección en el portal de Arquitectura, con contenido para aquellos que quieran explorar mecanismos iterativos de integración frecuente de código, en proyectos bajo plataforma Microsoft. Aunque la página ya se lanzó, no es que va a quedar así. Hay contenido que en estos momentos se está preparando y que no tienen que ver necesariamente con el lado feliz de los métodos ágiles sino precisamente con el lado amargo. Siendo que estas metodologías se basan mucho en el cara a cara, es inevitable que choques de personalidades surjan. Y si eso pasa, cómo solventarlo? ... Jodido, eh? Bueno, lo otro que queremos proveer en un futuro próximo son plantillas de procesos ágiles para instalar y usar en Visual Studio Team Foundation Server
3	Querido Mainframe, Te Vinimo a Desenchufá Cuántas veces habremos dicho que "habría que hacerlo si se pudiera, pero no se puede"? La realidad marca otra cosa, y es que más allá de la robustez de los mainframes, se han venido creando en las últimas décadas varias empresas, muchas de ellas muy exitosas, que no saben de mainframes. Los mainframes no son imprescindibles. Esa es la realidad. Lo que pasa es que es más difícil apagar el mainframe cuando éste viene clasificando y llevando todo desde tiempos retoños. Sin embargo he venido sabiendo de casos de antiguas compañías, voluminosas, que lo están haciendo. Se puede hacer. En este webcast se bosqueja cómo empezar y cómo Microsoft te puede apoyar a mover procesos de misión crítica a una infraestructura potente y no por eso de mantenimiento tan costoso En el interín, mientras vas tomando acciones para quitarle al mainframe responsabilidades de a poco, te mostramos acá cómo podés integrar procesos en plataforma Windows mediante los conectores de Microsoft para IBM z/OS y AS/400 (iSeries). Esta tecnología se conoce como Host Integration Server y podés leer más sobre ella acá
4	Health Modeling: Gratis con este Número una Herramienta de Modelado para Administración de Procesos Quizás nunca te llegaste a meter a fondo con Modelos de "Salud" de Procesos, por lo que te recomiendo un excelente documento introductorio acá. En dos palabras, un modelo de "salud" de un sistema y sus componentes define y parametríza estados en los que un sistema o sus componentes están "sano" y estados en los que no. Por ejemplo, la impresora sin papel está en estado "no disponible", y podríamos por ende decir que el sistema no está "sano". Lo mismo si el tiempo promedio normal de una transacción es de 400 milisegundos, pero las cincuenta últimas han demorado 600 msegs. Y así sucesivamente La herramienta que te ofrecemos acá te va a permitir definir de una manera sencilla estos modelos, estableciendo indicadores a instrumentar (como eventos, contadores de performance, etc). Después vas a poder exportar tu paquete de administración a MOM 2005 (ahora System Center Operations Manager 2007). Pavada de tool!
5	Herramienta para Regeneración de Bases de Datos SQL Server 2005 Te voy a contar algo que me pasó hace poco a mí, y cómo esta herramienta me salvó. Yo tenía mi basesita SQL Server corriendo en forma local, y era el tipo más feliz de la vida. Le tomaba un back up todos los días y vivía tranquilo, nunca tenía ningún drama. Hasta que una vuelta me dice mi jefe "la base ésa que tenés la tenés que publicar en un servidor externo". El server es de un tercero al que le alquilamos, no el server entero -en tal caso podríamos administrarlo como se nos de la gana- sino el derecho a hostear una base de datos allí. El tema es que al no tener permisos totales sobre ese servidor, yo no puedo hacer BACKUP o RESTORE de la base remota. Cómo hago entonces? Esta herramienta extrae el esquema de mis tablas, índices, constraints, etc, y por supuesto los datos. Y con eso la turra genera un script Transact-SQL!! Salvado el hombre, te cuento. Espero que vos puedas decir lo mismo si te venía pasando ésta
6	Gerencia de Desarrollo: Cómo Pasar de Punto a Banca en la Consideración del Resto de la Organización Este webcast, a pesar de lo que el nombre sugiere, no trata precisamente de Desarrollo de Software. O sí, en última instancia sí. Pero en realidad trata acerca de la puesta a punto de una infraestructura óptima para que la Gerencia de Desarrollo (y Mantenimiento) de Software y sus integrantes puedan colaborar mejor entre sí, sea más sencillo tener visibilidad del status del proyecto y de su impacto del negocio en general Parece guiterreada pero miralo y decime si no vale la pena intentarlo (excepto que estés cómodo y quieras seguir como hasta hoy)
7	Software Factories: Desarrollo de Clientes Web en Serie, en Serio Este webcast detalla paso a paso cómo las buenas prácticas y recomendaciones incluídas en la Web Client Software Factory liberada el pasado Enero te permiten obtener resultados potentes en plazos cortos, algo impensable años atrás. Esto contempla las últimas tecnologías web liberadas por Microsoft: ASP.NET 2.0 y ASP.NET AJAX 1.0 Estas software factories que libera Patterns and Practices, son las llamadas software factories horizontales Lo de horizontal hace referencia a que varios distintos tipos de industria pueden apoyarse en las mismas En cambio, una software factory vertical es específica de un dominio (industrial) dado Posteriormente a ese webcast, Don Smith, padre de la Software Factory para Servicios Web (liberada en Diciembre pasado), grabó lo suyo. Podés acceder a eso haciendo click acá
8	Object/Relational Mapping (O/R-M): NHibernate Directo de Fábrica Oren Eini es pendejo, no tiene más de 25 años (un bebé para mí, claro). La cosa es que a su edad ya debe tener más líneas de código escritas que todos nosotros juntos. Oren se dedica a hacer frameworks. Los frameworks que después nosotros usamos Uno de ellos, el NHibernate (la portación del exitoso Hibernate de Java a la plataforma .NET) lo tuvo bastante ocupado este último tiempo, y acá viene ahora a mostrarnos lo que se puede hacer con él Es muy valorable el rol que han jugado acá los entrevistadores, Carl Franklin y Richard Campbell, que no se pusieron en el papel de aduladores sino que más bien tuvieron una posición crítica la mayor parte del tiempo Aunque debo decir que, al final, Oren zafó. Bien el rusito
9	Vistazo Técnico al Próximo Windows Server "Longhorn" Este webcast te presenta la arquitectura de la futura versión del sistema operativo servidor de Microsoft, con sus mejoras de productividad de administración y rendimiento de ejecución (claro, esto seguramente te va a llamar más la atención si sos arquitecto de infraestructura, aunque no te va a venir mal conocerlo si sos arquitecto de soluciones) Cuando lo termines de ver acá está la segunda parte, donde se muestra una característica nueva llamada Network Access Protection (NAP) y mejoras al servicio de terminales (Terminal Services)
10	Interoperabilidad entre Java EE y .NET: Qué Hay de Nuevo, Viejo? Amén de todo el material que hemos venido publicando hasta el momento (incluyendo el libro de Simon), habida cuenta de que ambas plataformas han seguido evolucionando, muchas de las tecnologías, consideraciones y recomendaciones no es que sean hoy inválidas, pero sí quizás obsoletas. Siguen funcionando, pero hoy hay nuevas y mejores maneras de comunicar aplicaciones .NET 3.0 y Java Enterprise Edition 5 El expositor, un lujo tenerlo acá nuevamente, el señor Mohammad Akif, como dije más arriba, ex Sun Microsystems, hoy Arquitecto de Microsoft

 Hace  unos pocos meses atrás, con Simon hacíamos el llamado a propuestas para el track de Arquitectura de Software del próximo TechEd 2007 a realizarse en Orlando los primeros días de Junio. Teníamos después que seleccionar 20 (veinte) sesiones, y con Simon teníamos miedo de no recibir ni 18 propuestas. El año pasado Simon había hecho la convocatoria sólo -yo recién estaba "inmigrando" a Redmond- y había recibido cincuenta (50) propuestas. "Yo creo que podríamos igualar esa cifra" me decía con cierta incredulidad

Bueno. Se equivocó

No fueron cincuenta. Fueron ciento sesenta (160) respuestas al llamado!! En otras palabras, se más que triplicó el número de interesados!! Sólo me queda decir GRACIAS / MERCI / THANK YOU / GRAZIE y ojalá supiera decirlo también en hebreo, turco, indio, japonés y en los idiomas de todos los países que mandaron propuestas

Ahora, logicamente, después de la euforia inicial y disipados el frente de tormenta de no tener qué ofrecer durante el evento, vino la siguiente realidad: cómo elegir entre tantas propuestas las veinte a exponer? Si al menos se hubiera dado que más allá de la cantidad abrumadora sólo un diez, quince por ciento (10-15%) hubiese sido rescatable, listo. Pero no era el caso!! Todas las propuestas que leía me resultaban irresistibles!! No exagero: se me hacía agua la boca de poder contar con una gran mayoría de las propuestas recibidas. Pero sólo veinte slots, un garrón!!

Entonces lo discutimos internamente en la comisión seleccionadora y arribamos a los siguientes criterios:

• Privilegiar, por sobre lo que a nosotros nos gustaría mostrarle al público, contenidos demandados por el perfil promedio de asistente -tomando como "promedio" el feedback recibido en años anteriores-
• Para que te des una idea de ese perfil "promedio", si son arquitectos de soluciones, dedican una parte importante a escribir código; si son arquitectos de infraestructura, dedican una parte importante a operar y monitorear procesos, servidores, recursos de hardware, etc. Por consiguiente, presentaciones de un nivel 300 o 400, donde no sólo hay una introducción a modo de revisión de un concepto sino más bien ejemplos de código, demos ejecutables, etc, serán preferibles por sobre las de nivel 200 (lo que no dejó afuera a las propuestas de este nivel, sino que tuvieron que scorear por otras cualidades)
• Privilegiar voces externas por sobre la palabra "oficial" de Microsoft. Esto generó mucha polémica interna y debate, ya que algunos defensores de poner más caras de Microsoft al frente sostenían que si el público iba era porque quería conocer información de primera fuente, secretos, mejores prácticas, etc. Los que, como en mi caso, apoyábamos darle prioridad a las caras externas, lo hacíamos confiando en que la gente allá afuera tiene la experiencia del mundo real, de proyectos concretos hoy implementados y en producción. Con cosas que pudieron haber salido bien y otras que no, y eso es lo importante: un buen balance entre lo que sí y lo que no de nuestra plataforma. Si, en cambio, quien presenta trabaja en los grupos de producto de la compañía, te ofrecerá otra presentación más de Contoso (una compañía hipotética que siempre es tomada de ejemplo para la demo empresarial que sea). El ejemplo de Contoso o Adventure Works le puede servir para entender un concepto a la gente que normalmente toma una decisión, pero esa gente no necesariamente es el tipo de público hands-on que te comentaba en los puntos anteriores. Este público quiere recibir contenidos que cuando vuelvan a sus trabajos se pueda aplicar en forma inmediata, tangible. Existe un área de Servicios en Microsoft que sí trabaja con clientes y partners en proyectos verídicos, del mundo real, de manera que sí tienen bastante para ofrecer y compartir (particularmente MCS, Microsoft Consulting Services). Y así lo pusimos en práctica: de los oradores de Microsoft, la mayoría son consultores que pasan más tiempo en las oficinas de los clientes -donde en muchos casos les asignan cuenta en dichas corporaciones- que en las oficinas de la propia subsidiaria de Microsoft para la que trabajan
• Finalmente, acá vino la decisión más difícil que hubo que tomar, se decidió privilegiar aquellas propuestas de oradores con buena experiencia (probada) en eventos anteriores. Atención que no dije "con experiencia probada" sino "con buena experiencia probada". Es decir, no alcanzaba con decir "anteriormente me invitaron a hablar a las conferencias tal y tal" sino "me invitaron y acá están los números con que me calificaron". Fue jodido hacer esto porque fue el principal divisor de aguas. Lo cierto es que la idea era garantizar que los oradores que llevamos realmente van a deslumbrar al público

Te va a interesar saber finalmente quiénes fueron los elegidos. Tomá nota porque esta reunión de personalidades se ha visto pocas veces. Veamos:

El track de Arquitectura se completa con muchas otras sesiones más y también charlas-debate con tiza y pizarrón. Te invito a que lo revises completo en esta dirección:

https://www.msteched.com/public/sessions.aspx (tenés que seleccionar la opción "Architecture" en la lista desplegable "Track")

Nos encontramos en Junio en Orlando?

A la izquierda, el -hasta ahora- último libro
de David Platt. A su lado, la tercera edición
del libro presentación de .NET para arquitectos

 Acabo  de terminar de leer "Why Software Sucks... and What You Can Do About It" ("Por Qué el Software Apesta... y Qué se Puede Hacer al Respecto") de David Platt (Addison Wesley, 2007). Este Platt vive en Ipswich, Massachussets (Estados Unidos), por ende es sólo una coincidencia que se llame igual que el jugador del Manchester United y la selección inglesa

Platt, para los que no hayan tenido el gusto antes, es una suerte de Enrique Pinti de la Ingeniería de Software, en el sentido que logra comunicar verdades de nuestro quehacer diario en una forma muy pero muy graciosa (para los que viven en Chile, Enrique Pinti es el Coco Legrand argentino). Y al igual que después de ver a Pinti, al otro día de haber visto y oído a Platt sentís como cierta depresión: ya te decantó lo que te dijo el día anterior, ya lo procesaste y lo que te queda es una realidad amarga. Pero igual, a tomarse la vida con humor

Como muestra va este botón: ya en la introducción a "Introducing Microsoft .NET" (la edición en español se llama "Así es Microsoft .NET", Microsoft Press, 2003), el autor enuncia su "segundo lema de Platt", de la siguiente manera

"La cantidad de merda que anda flotando por ahí tiende a mantenerse constante. Si lograste sacarte una buena porción de merda de encima, es porque seguramente se estará enterrando en ella alguien más"

Te paso el contexto en que el autor enuncia este postulado: Platt estaba comentando la idea detrás del concepto de código administrado (managed code) por entorno de ejecucion de lenguajes común (Common Language Runtime o CLR) de la plataforma .NET, con facilidades tales como recolección de basura (garbage collection) de memoria liberada, chequeo dinámico de tipos (type checking) al asignar referencias a objetos (punteros, bah), etc. Platt estaba tratando de advertirnos que por mucho nosotros, como desarrolladores, no tuviesemos que meter líneas de código especialmente para eso, no quería decir que entonces esa lógica ni siquiera se iba a ejecutar. Sí que lo iba a hacer y en este caso es el CLR el ejecutor de esa lógica. La observación no es menor: que el recolector de basura desasigne toda la memoria liberada nos garantiza que no quedará memoria perdida (algo que en Lenguaje C o C++ era tan difícil de detectar que en la práctica se solía abandonar la búsqueda y, cada tanto, reiniciar la aplicación de manera que sea el sistema operativo el que se encargue de hacer borrón y cuenta nueva). Platt dice entonces que a pesar de esa garantía, si nos la pasamos creando objetos y luego quitándoles alcance (scope), si bien esa memoria se recuperará, el recolector de basura competirá con nuestra aplicación por el uso de la CPU. En otras palabras, el rendimiento general de la aplicación puede degradarse por el overhead agregado por el CLR

Casualmente mi post de la semana pasada hablaba de buenas y malas prácticas con mapeadores entre objetos y tablas relacionales (Object/Relational Mappers, u O/R-Ms). El segundo lema de Platt podría ser un post-mortem de ese post: por mucho que tu O/R-M esté haciendo ese mapeo que vos te querés evitar, ese mapeo ocupa tiempo (de ejecución) y espacio (en memoria, tanto de datos como de código). Ahorrarse de escribir código puede no estar excento de problemas de rendimiento

Si te estás preguntando qué podría llegar a decir el "primer lema de Platt", te lo paso al toque, y decime si en la práctica no es así:

"El tiempo total de duración de un proyecto es equivalente a tres veces la estimación inicial de duración del mismo, incluso si se había aplicado este lema al estimar"

"Por Qué el Software Apesta..." es ante todo una crítica a la autosuficiencia de los desarrolladores de software, haciendo aplicaciones que ellos créen que van a ser maravillas que el mundo les agradecerá por siempre, cuando en el fondo desde sus mismas interfaces de usuario están descuidados los más mínimos detalles de ergonomía y usabilidad. El autor cita ejemplos a la vista de todos: buscadores web, aplicaciones web para envío y seguimiento de encomiendas, una cadena de cafeterías, etc

Conversando con Paula, mi mujer, acerca de este libro -Pau es ingeniera de software también, y su especialidad está en normas y procesos, seguimiento y control de calidad (*)-, ella discrepó acerca del destinatario de esta crítica: en todo caso el desarrollador de software es un programador. No un experto en usabilidad. Sin invalidar que el software apesta, como señala Platt, Paula sugiere que en todo caso la dirección de desarrollo de estas aplicaciones debería considerar el rol de diseñador de interfaz de usuario -rol que debiera ser puesto en práctica por un experto en usabilidad-, de manera tal que los desarrolladores se encarguen de implementar sus lineamientos. No suena malo el exhorto de la receptora de mis desayunos diarios (**)

La realidad es que cuantos más expertos le agregamos a un proyecto (seguridad, acceso a datos -el DBA, bah-, ahora usabilidad) es probable, o sea no posible sino probable que pase efectivamente, que la complejidad del proyecto sea mayor y por ende el plazo de entrega. Pero en función de la calidad de los resultados es algo que no debe dejar de considerarse (lo digo y me viene a la memoria un proyecto en el que trabajé allá por el 2001, que ya tenía plazo de entrega prefijado -y de hecho si nos demorábamos, por una cláusula contractual, el cliente tenía derecho a pagar menos por el producto terminado en función de la demora-, cuestión que allí teníamos un experto en usabilidad, para ello posgraduado en el MIT, que sugería que el usuario ingresara localidades de la Argentina mediante clicks en un mapa de dicha república. Claro, yo era el programador así que me comía las uñas de escuchar esas ideas, seguramente geniales, si codificarlas dependía de mí y en plazos aceptables. Afortunadamente el cliente rechazó esa idea ya que varias localidades caerían de la escala del mapa, además que aún haciendo drill down de áreas de todas maneras requeriría de precisión de parte del usuario, además que alargaría la distancia de los clicks respecto de ingresar la localidad de una lista descolgable -de todas formas, inmensa-)

Quizás otra solución sería introducir en los planes de estudio de las carreras, nociones de usabilidad. Aunque no creo que esto no se esté haciendo ya y, de todas maneras, no sería suficiente ya que la Usabilidad como disciplina -si bien conlleva mucho de sentido común- no es algo que se pueda adquirir en una materia de la facu. Poner más materias de usabilidad no sería solución: los planes de estudio ya son lo suficientemente complejos y las especialidades también muy variadas como para poner tanta presión sólo en una de ellas

Si de otras disciplinas se trata, el libro se completa con los endebles mecanismos de seguridad que los desarrolladores ponen en el código creyendo que los hackers se van a dejar intimidar por un par de contramedidas. De nuevo, mi postura al respecto es coincidente con la de Platt en cuanto a que tenemos un déficit allí. Sin embargo descreo que sea realista y/o pragmático esperar que el desarrollador sea el experto capaz de tacklear esa amenaza. Más bien me muestro partidario de someter a la aplicación en vías de desarrollo, a revisiones (walkthroughs) de seguridad, aplicando por ejemplo las checklists que el comité de Patterns and Practices puso a nuestra disposición años atrás; eventualmente con la herramienta para modelado de amenazas que mencioné en el Boletín Oficial de Arquitectura #1

Como sea, no le resto seriedad a Platt en cuanto a los puntos grises del software, desde el punto de vista de quienes lo usan (usamos). Platt no se conforma sólo con culpar a los desarrolladores (los geeks u homo-lógicos, como se los llama hoy a los otrora conocidos como nerds de las ciencias de la computación). Particularmente en el capítulo 5 la crítica es más bien para el usuario, y su positivismo de que en realidad a nadie le interesa recolectar información de uno mismo (realizando, de esa manera, transacciones bancarias por Internet sin tomar recaudos de que su contraseña pueda viajar no encriptada, o que por su dirección IP, la que le asigna el proveedor de banda ancha, se puede reconstruir la historia de todas las cosas que anduvo buscando por Internet, sitios de niñas ligeras de indumentaria que visitó -incluyendo particularmente en cuáles de ellas se detuvo para conocer mayores detalles-, así como la eliminación de esas barreras que el sistema operativo pone por defecto a todo elemento sospechoso que pueda llegar al navegar por la web -entre ellos, aplicaciones que entran de polizón-). A mí me consta, yo tengo amigos que -sólo voy a citar uno de los innumerables casos que conozco- entregan su usuario y contraseña de Hotmail a esos programas que hay en la web que le ofrecen a uno, a cambio, ubicar quiénes nos borraron del Messenger (hoy Windows Live Messenger). Si sos de la partida, escuchame una cosa gil de estopa: al revelar tus credenciales a estos "buena onda", ellos entran al servidor de Messenger con lo que vos le habilitaste, se hacen de tu lista de contactos (en donde salimos nosotros, turro! Gracias por vendernos) de manera que desde tu cuenta nos mandan mails con SPAM y otros "servicios" no solicitados, a los que nosotros como incautos podemos pisar el palito dado que el mail nos llega enviado... desde tu cuenta, nabonga

Más aún, sabés que estos tipos después venden (sí, cobran plata por ello) tus credenciales a terceros que a su vez hacen lo mismo? Y como pueden entrar a tu correo, eventualmente pueden tomarse la molestia (total que pueden perder) de revisar si vos no te mandás a vos mismo alguna credencial -por ejemplo de tu banco en línea, no sea cosa que te la olvides; o eventualmente ver si no estás recibiendo mails de confirmación de algún servicio que sí hayas comprado, de manera de conocer tus hábitos de consumo y así ofrecerte otros-. Claro, con todo puede pasar que no te moleste si eso es así. Pero por lo menos, si me tenés en tu lista de contactos, no des acceso a mí tan fácil

...

En definitiva, el libro de Platt habla de todos estos vicios que como desarrolladores y como usuarios cometemos. Él es mucho más gracioso que yo para contarlo, y no por eso menos realista. Platt, además, es un confiado de que el software que apesta se puede mejorar, y te ofrece casi al terminar una serie de iniciativas para que seas vos mismo el que impulse, de la gente que te provea software sea quien sea ésta, que lo mejoren. Platt dedica especial atención al caso Microsoft, compañía ésta que despierta algo de admiración por la posición dominante que logró alcanzar y mucho de rechazo por la misma razón. Platt señala cómo Microsoft hoy está cambiando, al sentirse amenazada por los titanes que van surgiendo y se han ganado sus propios sitiales de privilegio, sino que además amagan despojarla de sus antiguas conquistas (el Internet Explorer como navegador más usado; el Office, etc). Platt no ahorra críticas al gigante del software, sin embargo separa lo que es el antagonismo justificado y constructivo de un mejor rol que Microsoft puede jugar -tanto allí donde aún lidera como en aquellos segmentos donde claramente va a la saga-, de lo que es mera crítica olvidable (e improductiva)

De esto último, Platt también menciona casos de antagonistas ocasionales de la compañía de Redmond, con estrategias que en apariencia iban a ser irresistiblemente adoptadas y a la vez iban a permitir que no siga pasando que la mayor parte de los computadores corra el sistema operativo de uno sólo de los oferentes. El autor hace un balance de las consecuencias de esas estrategias... y en algunos casos de los que pisaron el palito y se subieron

También hace un reconocimiento -capítulo aparte- de que a Microsoft solemos pegarle en la modalidad "palo porque bogas, palo porque no bogas". Coincido nuevamente con Platt: hace poco Pablo, un viejo amigo mío de la época en que ámbos integrabamos el llamado "Club OS/2" impulsado por IBM Argentina -no me creés? Pucha que sos cabeza dura: entrá acá-, me comenta "estoy metido a full con AJAX, le tengo mucha fé a esa tecnología. Claro, no creo que vos puedas decirme nada al respecto: Microsoft ni apoya ese estándar, para variar"

Le comento que Microsoft una semana antes habían liberado en forma gratuita la versión 1.0 de ASP.NET AJAX a lo que me responde "claro, como ven que puede generar interés, liberan una herramienta gratuita para que todos los giles se metan, total es gratis, y así Microsoft después los vaya tirando de nuevo a su plataforma"

Criticar a Microsoft porque regala algo (sea ASP.NET AJAX, sea las versiones Express de Visual Studio) contrasta con la crítica que se le hace por vender otros productos (tal el caso del Office, el Windows mismo, etc)

Volviendo a mi amigo Pablo, su sorpresa fue desagradable cuando le comenté que en realidad la tecnología AJAX surgió de una antigua facilidad incorporada por Microsoft en su versión 4 de Internet Explorer: el agente XMLHttpRequest. Su primera reacción fue de incredulidad. Pero cuando le mostré sitios que respaldaban que los orígenes de AJAX se remontan a Microsoft, me dijo "lógico: lo hicieron para romper estándar con Netscape y hacerse así del mercado de los navegadores"

En síntesis, como dice Platt, "palo porque bogas, palo porque no bogas"!! (damned if you do, damned if you don't): al principio Pablo criticaba a Microsoft por su presunto "no querer subirse a algo al que el resto de la industria se subía". Minutos más tarde, convencido de que esto era falso y que Microsoft había sido en todo caso el innovador, su crítica se había transformado en "monopolizador que se abusa de su posición de privilegio para anular toda chance de competencia". Quedamo así, Pablito... suerte con OS/2 (que, dicho sea de paso, las primeras versiones las hizo Microsoft a pedido de IBM)

...

Platt está presentando su libro en forma viral -te anticipo que va a dar un chalk talk en el próximo TechEd de Orlando-. Recientemente ofreció un keynote de unos cuarenta y cinco minutos basados en el contenido del libro. Afortunadamente eso está disponible para descargarse en el formato del Windows Media Player (o no, Microsoft monopolizando otra vez). Attenti porque el link que te voy a pasar no es para clickear directamente sino para hacer click con el botón derecho y de ahí darle a "Guardar como..." ("Save As..."), ya que el video pesa unos 363 MB. Por ende, hacé click con el botón derecho acá y, como te explicaba, elegí "Guardar como..." ("Save As...")

Eventualmente podés escuchar, acá al toque, una entrevista que dos ingenieros de software (también investigadores y a la vez reporteadores a lo Ron Jacobs) le hicieron al loco Platt. Por favor entrá por acá. Esta entrevista dura 1:20 hora

Finalmente, si venís medio apurado, también podés oir de boca de Platt una intro a su libro de algo así como 8:35 minutos, haciendo click acá

_________________________
(*) Paula hasta hace un año atrás formaba parte de la primera empresa chilena en certificarse en CMMI nivel 5, años atrás (ella fue parte del equipo evaluado por el comité representativo del SEI)

(**) Mujeres... descubrí que despertándola con un café cada mañana conseguía demorar su primeros reproches hacia mí hasta 5 minutos antes de separarnos para ir cada uno a su trabajo. Despertarla sin el café adelantaba los mismos, por así decir, lamentos desde ese mismo instante y por el resto del día. Eventualmente este patrón de diseño te podría llegar a servir si, como yo, sos casado o vivís en pareja

 Sinceramente  no creí que me iba a costar tanto seleccionar 10 noticias posta para los que, como vos, yugan de diseñar, modelar, hacer pruebas de concepto, convencer a jefes de proyecto, gerentes, e incluso desarrolladores, de las bondades de una estrategia

Fue doloroso descartar tanto material tan bueno, lo cierto es que para ser justo esta vez puse una cota de no más de un artículo por sitio de contenido. Y a la vez adopté el criterio de no dejar pasar contenidos que hicieran referencia a una plataforma específica en un modo tal que no fuese trasladable a otras plataformas similares

Antes de ir a los hechos, quiero recomendar a cualquiera que lea este boletín, que trate de entrar a todas las notas, aunque hayan sido hechas por una compañía x o en otra tecnología que la que trabaja habitualmente. Las elegí, a pesar de estar varias clavadas en una plataforma específica, de manera tal de que le abra el bocho al que trabaje en la plataforma que sea, acerca de los problemas actuales y las formas de resolverlos disponibles

Ahora sí