Charla sobre ExpertCoder en la UNT

El viernes 6 de Mayo a las 11:00 am voy a presentar una charla en la Universidad Nacional de Tucumán (Argentina). El título de la misma será "Generación de Código usando Software Libre - el enfoque de ExpertCoder".

La charla se dará en la Quinta Agronómica, más precisamente en el Laboratorio de Redes de Computadoras.

Si bien el enfoque se pondrá en la generación de código con ExpertCoder, voy a colar alguna que otra diapositiva mencionando a MonoUML.

Desde luego, están todos invitados.

ExpertCoder: problemas de desempeño resueltos

Hace unos días mencioné que la librería para UML 2.0 provista por ExpertCoder tenía unos problemitas de desempeño. Acabo de subir unos cambios al CVS; he cambiando radicalmente la manera de serializar los elementos, y he añadido varias características que permiten el ahorro de memoria.

En realidad, iba a hacer un post explicando las manganetas a las que tuve que recurrir, pero estoy sumamente cansado.

Si hay algunos usuarios de la librería por ahí (les recuerdo que MonoUML la usa), por favor cuéntenme como les fue con estos cambios.

Indignante

Recién me entero de un programa impulsado por el gobierno argentino para que las computadoras personales estén al alcance de aquellos menos favorecidos. A primera vista suena muy bien, pero en cuanto vemos las especificaciones de los equipos notamos que vienen con Windows XP preinstalado.

Considerando que se trata de 10 millones de máquinas, lo primero que se nos viene a la cabeza es el ahorro que se podría haber hecho en cuanto al costo de las licencias del sistema operativo. Pero inmediatamente después, pensamos en la enorme oportunidad perdida para el desarrollo del software libre en Argentina, ya que los nuevos usuarios aprenderán a utilizar Windows y sus aplicaciones propietarias, con lo cual se afianza aún más el círculo vicioso de usuarios sin conocimiento de otra cosa, lo que impone a las empresas a usar software propietario, lo que a su vez hace que la gente no aprenda ninguna alternativa, cerrando el círculo.

En este sentido, yo comparto la forma de pensar de Richard Stallman, en cuanto a que el problema del costo es superficial. ¿Qué le estamos enseñando a la gente que compra estas máquinas? básicamente, que la piratería es una forma de vida, ya que alguien cuya única alternativa para acceder a una computadora es pagar 40 pesos por mes (unos 14 USD) no creo que pueda desembolsar el costo de una licencia de MS-Office para transformar su PC en una herramienta útil. Ya se que existe OpenOffice, pero está claro que a esta gente se le está ocultando este tipo de información. ¿Y con respecto a la forma de vida colaborativa, en comunidad, de generosidad con nuestros vecinos? Todo tirado por la borda.

Tal vez necesitamos más gente con calce en las altas esferas del gobierno, el cual probablemente pertenezca al grupo de aquellos que ignoran la capacidad y simplicidad que han alcanzado las aplicaciones de software libre y código abierto (FOSS). Afortunadamente no es tan así ya que hay gente, como Marcelo Elías, que está al tanto del problema y tiene una opinión bien definida. De más está decir que recordaré su nombre a la hora de emitir mi voto en el futuro.

A pesar de la bronca que siento en este momento, tengo en claro que lo que debemos hacer es evangelizar más y despotricar menos.

Problemas de desempeño en EC

En estos días hemos estado poniéndole carga a MonoUML, gracias a una aplicación de ingeniería inversa que está haciendo Mario.

El programa genera un modelo UML a partir de un ensamblado, metiéndose bastante en detalle en todos los elementos afectados, tanto propios del ensamblado como referenciados directa o indirectamente. Esto hace que se obtenga información minuciosa de, por ejemplo, toda la mscorlib.dll.

Esto permitió detectar varios problemas:

• Alto consumo de memoria: aproximadamente 3,5 KB de RAM por cada clase vacía (!!!).
• Demoras para deserializar modelos grandes.
• Demoras tremendas para eliminar, por ejemplo, un paquete completo con todas las referencias a este y a sus los elementos contenidos.

Estos problemas surgen como resultado de la implementación actual de la librería para UML 2 de ExpertCoder (EC), que evidentemente necesita una revisión.

Yo creo que el quid de la cuestión está relacionado a la infraestructura para mantener los esquemas de propiedades de UML que se monta cada vez que se crea un objeto. Esta infraestructura permite que el valor de una propiedad pueda ser un subconjunto del valor de otra (ejemplo: todo Element tiene un conjunto de comentarios llamado ownedComment, que es un subconjunto de otro atributo llamado ownedElement; la idea es que todo elemento de ownedComment pertenece también a ownedElement).

Considero que, para solucionar este problema, debe implementarse un esquema perezoso de instanciación de esta infraestructura, de manera tal que se genere en tiempo de ejecución sólo para las propiedades que son realmente utilizadas.

Este fin de semana haré unas pruebas preliminares, tratando de optimizar Package, Class, DataType, Property y Operation, ya que son los elementos de modelo más utilizados en los ejemplos que tengo a mano, y si puedo bajar considerablemente el consumo de memoria y los tiempos de deserialización, aplicaré los cambios al resto de las clases.

Será un trabajo pesado y doloroso, pero es necesario hacerlo.