¿40% de aumento y paro el lunes y martes?

El gobierno nos aumentó el salario en un 40%, y en respuesta, el lunes y martes hay paro nacional de universidades por 48 horas. Y por lo que he escuchado, se avecinan paros por 72 horas también.

Y yo, a decir verdad, estoy pensando seriamente sacar mi cartel de:

will_code_for_food_1

Ya me imagino los comentarios. – ¿De que se quejan? – dirán algunos. Otros seguramente nos tildarán de sinvergüenzas por hacer un paro después de un abrumador aumento del 40%.

En lo personal me conformo con decir que si bien un aumento del 40% ayuda a pagar las cuentas y las deudas, en el fondo no deja de ser más que un avance o una solución insignificante al problema salarial de los profesores de la universidad.

Para los que están algo distanciados del problema de las universidades públicas en Venezuela, o para aquellos que no viven en este país, debo explicar algunas cosas:

Primero, es necesario decir que vivimos en un país con una inflación promedio de un 28-35% anual, y cuidado si no más, es decir, esas son las probablemente bien maquilladas estadísticas oficiales. Respecto a esto, puedo decir que en los últimos cuatro años he visto algunos precios y servicios incrementarse en un 200-300%, y no estoy hablando de bienes y servicios de lujo, estoy hablando de cosas básicas y tontas: el alquiler de una habitación, el condominio del edificio en el que vivo, la comida y cosas así.

Si, si, ya me imagino a algunos diciendo que la culpa de la inflación es de los especuladores… Los especuladores son ese “rostro sin nombre”, nunca muy bien definido al que es muy fácil culpar de la propia incompetencia gubernamental. Por su puesto que en gran medida la culpa es de los especuladores, pero vamos a estar claros en algo: también es del gobierno que realmente no hace mucho para controlar a los especuladores.

Retomando el punto original, las universidades publicas autónomas han sufrido un asedio económico por parte del gobierno desde hace ya aproximadamente tres años.

Si bien no tengo información 100% precisa, la situación es más o menos que la universidad donde trabajo está funcionando hoy en día prácticamente con el mismo presupuesto del año 2007 (si me estoy equivocando les puedo asegurar que es de menos y no de más, es decir, es posible que inclusive sea el mismo presupuesto del año 2006). Ahora bien, si consideramos una inflación anual del ~30%… bueno, creo que eso lo dice todo.

No voy a decir que nuestras autoridades universitarias son precisamente “monedas de oro”, ni que la estructura institucional de la universidad sea perfecta, en verdad hay muchos problemas dentro de la universidad, problemas graves que deberían ser corregidos, estructuras que deberían ser derrumbadas y modificadas. Pero el punto es que independientemente de eso, involucrar a todos aquellos que hacemos vida en la universidad, trabajamos por ella y por el país, en una guerra política contra la estructura establecida no me parece en lo absoluto justo.

Tercero, a los docentes universitarios no nos aumentan… perdón, no nos habían aumentado el sueldo desde el año 2007, y cuidado si no desde el 2006 (yo entré a trabajar a principios del 2009 con un sueldo ya muy devaluado). Nuevamente, con una inflación aproximada del 30% anual, se estima que nuestro sueldo antes del aumento estaba por detrás de lo que debería ser en al menos un 140% (y quizá más). Pienso que cualquier posible deuda en este sentido y los números en general son ya tan grandes que quizá inclusive eso sea impagable ya.

A eso añadan algunos problemas adicionales:

No hay la adecuada reposición de cargos, es decir, no tenemos suficientes profesores. El departamento de computación (donde trabajo) sirve como ejemplo de esto, donde en verdad no sabemos como vamos a cubrir la carga académica el semestre que viene y mucho menos el año que viene. Supongo que tendremos que tomar medidas tales como abrir una asignatura un semestre si y otro no, cosa que seguramente no será muy popular y que terminarán perjudicando a los estudiantes.

Otro problema son las materias electivas. Es muy difícil abrir una asignatura electiva, en principio porque la mayoría de los profesores estamos demasiado ocupados cubriendo la carga de las asignaturas obligatorias (y tratando de obrar otros milagros). No es que no hayan electivas, algunas se logran abrir con mucho esfuerzo por parte de algunos profesores, otras porque las abren profesores jubilados que básicamente no tienen carga. La consecuencia de esto la sufrimos todos. Los estudiantes pierden en formación, no pueden seleccionar que electivas van a ver y tienen que conformarse con la pobre oferta existente, o por otro lado, terminan viendo electivas de otras opciones (Control o Investigación de Operaciones). También lo sufrimos los profesores que queremos formar gente en ciertas áreas (por ejemplo Computación Gráfica) para llevar adelante proyectos de investigación u otros productos, o que queremos explorar áreas nuevas aprovechando una asignatura electiva como oportunidad.

Finalmente, no hablemos de la actividad de investigación… Tratar de hacer investigación con serios problemas de remuneración, con familia, esposa e hijos, teniendo dificultades y haciendo malabares para pagar las cuentas, el mercado del mes, el alquiler, el colegio de los niños, etcétera, es casi imposible.

Ni hablar de asistir a una conferencia a presentar el resultado de un trabajo, o tratar de publicar un artículo en alguna revista internacional; todo esto es casi imposible, simplemente no hay dinero, o no hay dolares, y si es posible conseguirlos, normalmente están enterrados debajo de tal pila de burocracia que muchos de los esfuerzos para tratar de obtenerlos son inútiles.

Aún así, con mucho esfuerzo, todavía se hace algo de investigación e innovación (ver aquí, aquí, entre otros).

¿Y el sueldo? Bueno, no se el de los demás, pero aquí va el mío:

Tengo 10 años de experiencia en la industria de software y unos dos y medio en docencia. No voy a hablar de mí, si quiere saber sobre mi carrera, aquí está mi CV, juzgue querido lector por usted mismo. Sin embargo, si debo decir que he hecho muchas cosas y que aún puedo hacer muchas otras más. ¿Y cuánto estoy ganando? Antes del aumento 2000 BsF, después del aumento estimo que unos 2800 BsF, quizá con suerte 3000 BsF. Eso en dólares son más o menos unos $697 USD, y ojo, eso es con el dólar oficial, me refiero al dólar de mentira que es un lío conseguir. Como hasta hablar de esto es ilegal en mi país, lo voy a poner en estos términos: en realidad, a la fecha de publicar esta historia, estoy ganando unas 352 lechugas verdes. Es decir, según esto en algunos países de latinoamérica se podría decir que estoy ganando sueldo mínimo.

Aunque en realidad, tristemente, creo que el texto debería decir algo como “Computer Engineer will code for food and a plane ticket abroad”. (Y no es broma…)

will_code_for_food_2

Misterios de Munrrael

I’m writing this on English for two reasons: The first one is to practice my written English, so if you, reader, find any mayor mistakes through the text, please take a moment to comment this post and criticize it. The second one… well, I will not disclose the second one, I’ll only tell that right now I have some hopes on the second one.

Some times I hate my own English, I mean, when I think I have it exactly where I want it to be, I try to write something like this only to end very disappointed with the results (grrr!). My wife says that text is basically OK, she says it’s not so badly written, that I’m just a maniac perfectionist… I hope she is right.

Now to the topic

“Misterios de Munrrael” is a WEB based Massively Multiplayer Online Role-Playing Game (MMORPG). It was developed by four of my students along B2010 courses of Software Engineering and Database Systems. Those courses are taught using the RAIS teaching strategy, so the main objective to be reached at the end of both courses is the development of an usable product. The game is a “no flash nor applets” WEB based game so it has no stunning visual effects or 3D animations. Though it has very complex rules and it’s very feature rich considering it’s only a final course project developed by undergrad students.

Features are simple, very standard and common to many existing MMORPG games:

A player can register and create a set of five avatars at most. Each created avatar can either be Human, Elf or Dwarf. Avatars can also be Warriors, Wizards or Archers. Once the player has created an avatar, he can select it and enter in Munrrael’s world commanding his avatar through lots of features and adventures.

mist_mun_screen1_th mist_mun_screen2_th

(Click image to enlarge it)

Initially, avatars will have a set of fixed base skills, but the more the player uses his avatar, the more it gains experience, new levels and new skills.

mist_mun_screen3_th mist_mun_screen4_th mist_mun_screen5_th

(Click image to enlarge it)

Once in game, the avatar can move around Munrrael’s cities and around each city’s set of zones. The cities are arranged in a graph like structure and an avatar can’t go from it’s current city to every other city, it can only go to the adjacent cities. Also there is a gold cost required to travel from one city to another, so if the avatar has not enough gold then it’s stuck in the current city until he can collect enough gold to do the trip.

mist_mun_screen6_th mist_mun_screen7_th mist_mun_screen8_th

(Click image to enlarge it)

Also, there are resources, creatures, non-player characters and other avatars inside each zone, with whom an avatar can interact. Avatars can collect resources and combine them to create new equipment. For example, ten units of iron with one unit of wood and a “blacksmith service” bought from a blacksmith NPC can be combined to get a basic iron sword. Another example, one unit of healing herbs, five units of water and one bottle can be combined to create a healing potion. Allowed combinations and their results are constrained to a fixed set of recipes.

mist_mun_screen9_th mist_mun_screenA_th mist_mun_screenB_th

(Click image to enlarge it)

Avatars can also fight creatures and others avatars. In each combat an avatar will gain defense and attack experience. If an avatar wins a battle it might also earn some gold and some items. For example, an avatar will get between 2 to 5 gold coins and a rat tail if it wins a fight against a rat.

If an avatar fights against another avatar, then the winner of the fight will get all the gold carried by the looser and randomly some of it’s opponent belongings: weapons, armors, potions or any other item carried by the looser avatar. If a player don’t want to risk loosing his avatar’s gold or belongings in a fight, he can deposit his avatar’s gold in a bank and his belongings in a chest.

The game also allows buying and selling resources and items from or to other NPCs or avatars, generating this way some kind of economic system.

Now to the technical details

From the software point of view the game is implemented using a two tier architecture (sorry to disappoint you if you were expecting a three tier architecture, we lost the third tier somewhere in the middle). The first tier is the presentation / logic tier. It implements all the user interface and all the game logic.

The user interface is implemented in an MVC fashion using Nextapp Echo3, which is a framework / component library that allows implementing rich WEB applications without the need of writing JavaScript or HTML code. All the user interface is server-side coded in Java using an API very similar to Swing, then Echo3 takes care of generating all the needed JavaScript and HTML (Cool, isn’t it?). This comes very handy within the courses I teach because students are not required to know JavaScript or HTML to develop their projects, though they still can implement nice AJAX WEB user interfaces using Echo3.

There is also a persistence layer implemented using in-house developed Data Access Objects (DAO pattern). Though I teach ORM frameworks in my Database Systems course, I require my students to use DAOs instead of ORM frameworks like Hibernate. This is mostly because I want them to feel the pain of writing SQL and dealing with the required architecture to access the database. I need them to learn it the hard way before I can show them the easy way to go.

The next figure was taken from the project’s final document and shows the architecture:

mist_mun_arquitectura

The bottom line

“Misterios de Munrrael” is just only one of the games developed this way. Last two semesters two other MMORPG were also developed in the Software Engineering and Database Systems courses context: BloodTime a dark vampire based MMORPG and “Lanter Corps Academy” (LCA for short), which is a game based in the Green Lantern world created by DC Comics. Some screenshots of those games follows.

mist_mun_bt1_th mist_mun_bt2_th
mist_mun_lca1_th mist_mun_lca2_th

(Click image to enlarge it)

All the source code is GPL licenced and is published in the following google codes:

http://code.google.com/p/gsd-project/
http://code.google.com/p/bloodtimeproject/
http://code.google.com/p/lanterncorpsacademy/

Consider that the games are student projects, so some things may work well, and others might not even work at all. There is no support and no warranties. The only documentation on how to start the games can be found here.

If you plan to do anything with the games take in consideration that images used were taken from the Internet by the students without any kind of permission from authors. We believe that as non-commercial student oriented projects there will be no problems about this issue, but if you want to do something else with the games you may have trouble.

Also the games have been donated to the University Game Development Student Group (a weird translation of “Semillero de Programación de Juegos”), and I hope development will continue in the future. In fact, the initial development team of “Misterios de Munrrael” is already making changes to the source code and improving some aspects of the game architecture.

By the way, this semester we are also creating three games (sorry, only in Spanish), but this time we are not doing MMORPGs, I got bored of those the last semester, so we are exploring new frontiers :)


I really would like to thank the Misterios de Munrrael’s team: Anna Lezama, Alejandro Mujica, Miguel Flores and Fabio Paredes. I also would like to thank all the teams that made possible BloodTime and LCA during the B2009 and B2010 courses. All the developed products were a very interesting experience for me as a teacher, software developer and RAIS (project) executive chief.

Compañías y Productos RAIS en el A2011

Al momento de escribir este artículo ya llevo dos semestres aplicando RAIS. Para los que aún no lo saben, RAIS es una estrategia de enseñanza aprendizaje que hemos desarrollado en el grupo “puntoEDU” en la Universidad de Los Andes.

Tengo mucho que escribir sobre RAIS y los distintos semestres / cursos en los que he aplicado la estrategia, de modo que voy a tratar ir publicando poco a poco mis experiencias y reflexiones al respecto.

El semestre actual (A2011) va a ser mi tercer semestre usando la estrategia, y a decir verdad, la experiencia de aplicar RAIS por un lado es en extremo gratificante y por el otro es en extremo agotadora.

Es gratificante porque se ven resultados; verdaderamente muy buenos, y se que aún se puede lograr mucho más.

Es agotadora porque involucrarse en los proyectos de los estudiantes, colaborar en su dirección, ayudarles no sólo desde el punto de vista conceptual, sino desde el punto de vista técnico y organizacional, empujar y mantener todo razonablemente bajo control (digo razonablemente por aquello de que en el fondo el control no es más que una ilusión), experimentar nuevas formas de hacer las cosas y realizar ajustes sobre la marcha, administrar y moderar el foro, dictar cerca de 12 horas de clase semanales entre clases teóricas, prácticas, así como discusiones con las compañías sobre sus productos, grabar todas esas clases, prácticas y discusiones (este semestre me tocó ser camarógrafo), mantener actualizado este portal, etc, y todo a un ritmo verdaderamente infernal… bueno, resulta una experiencia agotadora, y eso que no estoy contando otras actividades adicionales a los cursos y a RAIS.

Y cuidado, porque en caso de que el párrafo anterior se preste para malas interpretaciones, debo decir que no me estoy quejando en lo absoluto, es decir, en verdad disfruto (mucho) esa “experiencia agotadora”, hago con mucho gusto todo el trabajo que implica llevarla adelante, y por lo pronto estoy muy contento con los resultados.

Pienso, más bien estoy seguro, de que más adelante y una vez logre afinar algunos aspectos en particular, la parte “agotadora” va a verse muy reducida y sólo va a quedar la parte “gratificante”. Claro, eso suponiendo, dada la crisis universitaria actual, que haya un “más adelante” para mi en la ULA, pero eso ya es harina de otro costal.

En esta publicación en particular quiero hablar un poco de las compañías con las que estoy trabajando este semestre.

En el A2011 tenemos tres productos (comunes a IS y BD) y tres compañías. Cada compañía está desarrollando un producto y cada una tiene una “división” de IS y otra de BD (o un departamento, dependiendo de como lo quieran llamar). Más adelante, en otro artículo, hablaré un poco de la forma en que se organizaron las compañías este semestre, de las diferencias con el semestre anterior y de las ventajas y desventajas de la estrategia de organización actual con respecto a la de semestres anteriores.

Las compañías son:

logos_A2011

En general, creo que las compañías están muy bien balanceadas y que los productos son verdaderamente interesantes. He tenido unas conversaciones bastante productivas con los gerentes, directores e ingenieros y poco a poco cada compañía va aclarando la visión del juego.

Hoy inclusive me di el gusto de jugar un rato con un prototipo (hecho en papel) del juego que va a desarrollar MagicRoot y en verdad debo decir que la mecánica del juego está tomando forma y resulta bastante atractiva. Si tenía alguna duda al principio sobre el tipo de juego, que en el fondo está basado en otro juego que se llama Triple Triad que creo tiene su origen en un mini-juego de Final Fantasy, creo que ya no la tengo.

demo_magicroot

CodeSolid hasta los momentos ha sido la compañía que entregó el mejor documento de visión del juego (aunque las otras compañías poco a poco están recuperando terreno). Inclusive se adelantaron un poco al contenido del curso, incluyendo algunos bosquejos de la interfaz de usuario. El producto de CodeSolid es en principio un juego de combate en el que dos jugadores (o dos bandos de jugadores) se enfrentan por turno unos con otros. La idea principal de este producto es concentrarse únicamente en lo relacionado a la parte de combate de un juego de rol, para de esta forma poder elaborar y experimentar en su máxima expresión con todo lo referido a este aspecto, permitiendo cosas como bandos de múltiples jugadores combatiendo con otros bandos, hechizos y ataques complejos, defensas elaboradas, etc.

Me gusta pensar que el juego de CodeSolid es a algo como $NOMBRE / Misterios de Munrrael (del semestre pasado) lo que Quake III Arena es a Quake, y creo que eventualmente ambos proyectos se pueden llegar a complementar.

Por cierto que la idea de CodeSolid me recuerda a los combates de Final Fantasy VII, y es curioso que los juegos de al menos dos de las tres compañías tengan algún tipo de raíz, conexión o reminiscencia con algún aspecto de Final Fantasy.

Thinking & Looking también tiene las ideas cada vez más claras. Esta compañía ha decidido desarrollar un juego que en lo personal pienso que promete mucho (¿será porque en el fondo tengo algo que ver con la conceptualización del juego?).

El juego de Thinking & Looking se llama Greed Treasure y está basado en una idea que tuve al final del semestre pasado. En general el juego original de mi idea se llamaba “Ataque al Castillo” y estoy seguro de que Thinking & Looking va a tomar la visión base de ese juego y la va a consolidar y enriquecer con elementos que de seguro no puedo ni imaginar en este momento. El producto es muy para “red social” y pienso que puede llegar a ser muy adictivo. Ya están desarrollando y afinando el concepto por medio del foro y creo que poco a poco la esencia del producto va a ir tomando forma. Por cierto que en el documento inicial de la visión del juego me llamaron mucho la atención unos dibujos muy bonitos hechos a lápiz y luego digitalizados por alguno de los integrantes de la compañía (la verdad no se bien aún quien es el artista, pero me pareció un lindo toque:

dibujos_tl

Espero que los productos este semestre den frutos y que para julio (o septiembre) podamos divertirnos con los juegos de cada compañía, la concepción de los tres juegos me gusta mucho y creo que prometen cosas interesantes.

Los Pequeños Bailarines Azules

De tanto en tanto me gusta escribir cuentos cortos.
Este lo escribí entre Septiembre y Octubre del 2010.


Empezaron a salir del desagüe. Primero uno, después otro. Uno tras otro, comenzaron a formar un hilo de pequeños bailarines azules. Al principio sólo se movían alrededor del desagüe, poco a poco comenzaron a danzar, siguiendo una hipnótica y continua serie de pasos, moviéndose hacia el centro y luego alejándose, girando hacia un lado y luego hacia el otro, y finalmente volviendo a empezar.

001Blue-lo

Blue Painter by David Cottingham.

¡Parecían pequeños derviches danzarines!

El azul de sus cuerpos brillaba con las pequeñas gotas de agua que les cubrían, parecían diminutas joyas de un vestido imaginario que envolvía sus cuerpos, y sus reflejos, en el agua del lago circundante al desagüe generaban un efecto alucinante de hilos de oro y plata alrededor de toda la danza.

Yo estaba allí de pie, los miraba maravillado, me sentía completamente hipnotizado con los círculos y movimientos que hacían, como si representaran una magia oculta, poderosa y olvidada, pero que sin embargo hacía años sospechaba que existía, e incluso anhelaba encontrar. Se trata de esa clase de cosas que uno sabe que algún día va a encontrar, pero no sabe cuando, ni en que forma, ni que va a ocurrir cuando la encuentre.

Sentía en mi cabeza un chisporroteo, un golpeteo sincronizado con cada paso que daban alrededor del desagüe, podría afirmar que escuchaba la música que danzaban, lo que no resulta disparatado considerando que estaba viendo pequeños bailarines azules danzando de un lado a otro.

…bam, bam, tan, tan, bailaban y bailaban, bailaban y hacían círculos, se acercaban al centro y se alejaban, una y otra y otra vez… ¡entonces!

No se porqué, el embrujo se rompió.

Bajé la manivela del retrete y los pequeños bailarines se fueron de golpe por el desagüe.

Más nunca los volví a ver, más nunca volví a encontrar esa magia: oculta y poderosa, pero ahora ya olvidada.


In the process of looking for a picture for this small tale I found a painting by David Cottingham titled Blue Dancer. I fell in love with the picture, specially because I believe it’s perfect for this tale. I’d like to thanks to Mr. Cottingham for granting me permission to reproduce his painting here.

¡Sueño de una noche de AVM! (parte 1)

Anoche tuve un sueño. Más bien creo que fue una pesadilla. Soñé que nuevamente estaba involucrado, de la forma más bizarra que se puedan imaginar, en un proyecto de desarrollo que tenía algo que ver con el AVM.

AVM

El AVM es un producto en el que trabajé junto a varios colegas entre el 2003 y el 2006 aproximadamente. Para esa época estaba desarrollado en Java (tengo entendido que luego lo migraron a .NET) y la última vez que lo vi, tenía poco más de 100k líneas de código. Para la época, creo que era una pequeña joya, al menos yo aprendí mucho de ese producto, tanto cosas buenas que luego replicaría en otros productos, como cosas malas que luego trataría de evitar. Creo que la compañía aún existe, se llamaba Amarant-IT, conste que de alemán no entiendo ni una palabra.

Voy a resumir la tecnología / arquitectura a grandes rasgos para no escribir mucho:

  • Implementado en Java.
  • Dos capas: presentación y persistencia, la lógica de negocio estaba, salvo en algunos cálculos muy específicos, incrustada en la capa de presentación (si, feo).
  • La capa de presentación estaba implementada en Swing.
  • La capa de persistencia estaba implementada con unos DAOs desarrollados “in-house”.
  • Al principio, se usaba un framework de reportes desarrollado “in-house” (¿AbiReports?), luego los reportes se migraron a JFreeReport (que creo ya no existe).
  • Soportaba I18N (Alemán, Inglés).
  • La base de datos era MS SQL Server 2000, u Oracle.
  • El cliente como ya lo he insinuado se conectaba directamente a la base de datos, es decir, no había una capa intermedia (algún web service o algun servidor de aplicaciones).

Ahora voy a detallar los puntos importantes.

La capa de persistencia estaba formada por unos primitivos aunque efectivos DAOs. Creo que los DAOs fueron desarrollados por un colega a quién le tengo mucha estima (pero no estoy seguro si fue él en verdad quien los implementó), y dados mis conocimientos de arquitectura de software (diseño orientado a objetos) de la época, creo que en su momento eran toda una obra de arte. Hoy en día se que definitivamente se puede programar algo mucho mejor.

Como ya dije, los DAOs eran una obra de arte, lo que NO era una obra de arte era la documentación, o mejor dicho, la forma en que la gente los usaba. Es decir, si se utilizaban de la forma correcta podían ser muy eficientes… si se usaban de la forma incorrecta, entonces eran un desastre en potencia. Y un desastre en potencia fueron en su mayoría. Supongo que por razones económicas, al proyecto le “metió mano” mucha gente y mucha de esa gente utilizó los DAOs de forma incorrecta, generando un sin fin de inconvenientes, disparates y parches.

Debo decir que nosotros no fuimos ningunos santos, al principio nos costó bastante entender la forma en que se usaban los DAOs y definitivamente lo hicimos mal, contribuyendo a nuestro modo con el desastre. Sin embargo, con el tiempo aprendimos a usarlos bien y poco a poco resolvimos el problema. De tanto en tanto, pienso en esto y definitivamente me gustaría saber lo que hubiera pasado de haber tenido la oportunidad de sacar los DAOs del medio e implementar la capa de persistencia con Hibernate o algo similar (y eso estuvo a punto de hacerse más de una vez).

Sobre la capa de presentación, recuerdo que se usaban algunos componentes de IU que básicamente eran mejoras o envoltorios de los componentes básicos de Swing. Recuerdo que estos componentes cambiaron de nombre muchas veces (por razones que son desconocidas para mi) y que el último nombre con el que los conocí fue el de AbiBeans. Los componentes hacían cosas muy tontas pero útiles, tales como añadir soporte de I18N a los textfields para que pudieran interpretar números en diferentes formatos y tonterías de ese tipo en general útiles. Recuerdo que el Grid (¿JTable?) básico de Swing también tenía algunas mejoras interesantes.

Sin embargo, el componente más importante de todos se llamaba LEA (click en la imagen para agrandar):

FrmLEA_th

Creo que el nombre LEA venía de List Edit A¿XXX? (¿Architecture?), donde no recuerdo exactamente que significaba la A. Era básicamente un CRUD, es decir, un componente que permitía fácilmente y con poco esfuerzo implementar un Create / Retrieve (Read) / Update / Delete para una tabla particular de la base de datos. Pienso que en su momento llegué a estar obsesionado con ese componente, es decir, era tanto el trabajo que ahorraba que bastaba simplemente con heredar de una clase, reescribir las funciones adecuadas y listo; uno tenía un formulario para listar, filtrar, crear, editar y eliminar los registros de una tabla de la BD.

Al final fue tal mi obsesión que lo reimplementé y mejoré una y otra vez, aunque finalmente ninguna de mis implementaciones realmente llegó a usarse, pero en el camino aprendí mucho, al grado que mucho de eso influenció mi trabajo posteriormente en el framework CLEDA (Create, List, Edit, Delete Architecture… ¿les suena?).

Si les soy sincero, nunca supe exactamente lo que hacía el AVM… se que calculaba el monto que tenía que pagar una empresa de producción o de servicios por concepto de impuestos por razones de reciclaje. Es decir, la empresa hacía cierto producto (o prestaba cierto servicio) y el AVM calculaba la cantidad de desechos (el impacto en términos de basura) que ese producto tenía en el ambiente. Luego calculaba el impuesto que tenía que pagar la empresa dependiendo de la cantidad de productos vendidos del país de Europa en el que operara y de la legislación vigente en ese país. Chris: si alguna vez lees esto ¿estoy en lo correcto?

Suena raro, viniendo de alguien que trabajó activamente en el proyecto como programador, el no saber exactamente lo que el software hacía, pero esa era la realidad en ese entonces y lamentablemente creo que es la realidad en muchos proyectos de software. El trabajo en realidad era simple: nos decían “queremos estas pantallas implementadas con estos campos” y nosotros las implementabamos. “Queremos estos reportes con estos campos” y nosotros los implementabamos, “queremos estos cálculos…” y bueno… nosotros los implementabamos.

Una de las cosas que recuerdo con más cariño es hacer los “actualizadores” de la base de datos (y si, estoy siendo sarcástico cuando uso la palabra “cariño”). De versión en versión, mucha gente hacía muchos cambios a la BD y nadie se tomaba la molestia de anotar que cambio había hecho. Al final, cuando se iba a sacar la nueva versión a producción… ¿adivinen que? ¡exacto! Era necesario migrar la base de datos de los clientes de la versión anterior a la versión actual.

Era entonces cuando se programaba un “updater” o un actualizador o como lo quieran llamar, que actualizaba una BD de la versión anterior a una BD de la nueva versión. El cliente corría la nueva versión, el AVM se daba cuenta de que versión de BD tenía instalada el cliente y pedía permiso al cliente para hacer los cambios, si el cliente aceptaba, entonces el “updater” hacía los cambios.

Como no habían registros de los cambios en la BD de una versión a otra, el proceso de programar el “updater” era un verdadero dolor de cabeza. Por cierto, la moraleja aquí es llevar un registro de los cambios que se le van haciendo a la BD.

¿Cómo se resolvía el problema entonces? De forma simple pero engorrosa: se hacía “dump” del esquema viejo de la BD (los CREATE TABLE, etc.) y un “dump” del esquema nuevo. Luego, hacía lo que me gustaba llamar un “diff humano”, es decir, abría dos editores de texto uno al lado del otro y tabla por tabla, comparaba las diferencias estructurales, campos nuevos, campos eliminados, tablas nuevas, las tablas eliminadas, etc. El resultado iba a un reporte muy básico (para tener en blanco y negro las diferencias) y a la implementación de una clase que se encargaba de hacer la actualización. En ese entonces no se escribían los ALTER TABLES directamente, sino que utilizábamos el patrón command (** alargo la mano, tomo el Gamma y verifico que el nombre del patrón sea correcto**) para hacer las actualizaciones en la BD. En otras palabras, teníamos una clase (muy grande por cierto, tanto que el eclipse se atoraba) en la que escribíamos comandos (otras clases), que metíamos en una cola y que eventualmente ejecutaban los ALTER correctos dependiendo si la base de datos era MS SQL Server u Oracle.

Otra de las cosas de las que estoy orgulloso dentro del AVM es del PLO (¿Package Loading Optimizer? Creo que el PLO merece un post aparte, pero al menos voy a decir a grandes rasgos que era un módulo (¿plug-in?) del AVM que permitía optimizar la distribución de cajas en una paleta de carga. Era bastante interesante ya que el producto generaba un reporte que mostraba la forma en que debían ser cargadas las distintas cajas en la paleta, así como una vista 3D que mostraba la distribución de las cajas la en la paleta de forma interactiva.

En fin, creo que esta entrada ya está quedando muy larga, así que me despido por los momentos… Se preguntarán: ¿qué pasó después de todo con la pesadilla? Bueno, les juro que ya la tengo escrita, así que a diferencia de otros sueños, éste no se me va a olvidar (aunque quizá desearía olvidarlo), pero por lo pronto, me parece que la pesadilla va a tener que esperar a otro post.