Casos de Uso / Registro de Notas

El primer examen de Ingeniería del Software del semestre A2011 incluyó un problema en el que era necesario obtener un diagrama de casos de uso a partir de un enunciado dado.

El enunciado del examen se puede encontrar en el siguiente documento:

Examen_1_IS.pdf

Pensé que podía ser una buena idea publicar la solución a este problema del examen, en especial describiendo mi punto de vista al respecto.

Esta no necesariamente es la única solución, ya que en general, a lo largo de mi carrera me he encontrado con muchos estilos distintos a la hora de modelar casos de uso. Sin embargo, creo que es una buena solución, que describe de forma precisa (si es que eso es posible usando casos de uso) la funcionalidad del sistema. A continuación mi razonamiento y mi solución:

A) Un profesor puede registrar notas:

CURN_cu1

Figura 1

B) Cuando un profesor registra una nota es almacenada en una base de datos.

En lo que respecta al diagrama de casos de uso la información anterior es completamente irrelevante. Es decir, en “Registrar Notas” supongo que tendremos que almacenar la información en la Base de Datos, pero realmente no es de interés representarlo en el diagrama, como mucho se puede mencionar en la descripción textual del caso de uso.

C) Adicionalmente un profesor puede actualizar notas. Cuando esto sucede, primero debe seleccionar la asignatura y el estudiante y luego el profesor puede actualizar la nota. Finalmente la nota actualizada es almacenada en la base de datos.

En principio, esto es bastante simple, lo único que interesa aquí por los momentos es que el profesor puede “actualizar notas”. La parte de “seleccionar la asignatura y el estudiante” se puede incluir dentro del caso de uso “Actualizar Notas” sin ningún problema. La parte de la Base de Datos, por las razones ya mencionadas no es relevante para el diagrama.

El resultado hasta los momentos es:

CURN_cu2

Figura 2

D) Los estudiantes y los profesores pueden visualizar las notas.

Esto se resuelve con un actor adicional, y evidentemente, con un caso de uso adicional:

CURN_cu3
Figura 3

E) Las notas se pueden visualizar por asignatura (todos los estudiantes de una asignatura) y por estudiante (todas las asignaturas de un estudiante). En cualquier caso, si se están viendo las notas de una sección se debe poder filtrar por estudiante y si se están viendo las notas de un estudiante se debe poder filtrar por asignatura.

En el párrafo anterior resulta importante la funcionalidad “visualizar por asignatura” y “visualizar por estudiante”, así como “filtrar por estudiante” y “filtrar por asignatura”. Por lo pronto, la funcionalidad de “filtrar por estudiante” y “filtrar por asignatura” se considera incorporada dentro del caso de uso “Visualizar Notas”, por lo que el diagrama no se modificará. Sin embargo, es probable que más adelante se hagan algunas modificaciones al respecto.

Sobre a la diferencia entre “visualizar por asignatura y por estudiante” tenemos dos opciones, la primera es mantener el caso de uso “Visualizar Notas” y asumir que contiene tanto la funcionalidad de visualizar notas por asignatura como la de visualizar notas por estudiante. La segunda opción es separar el caso de uso en dos casos de uso: uno para la visualización de notas por asignatura y otro por estudiante. Se tomará la segunda opción ya que es la que pareciera aportar mayor claridad:

CURN_casos_uso_A1

Figura 4

Adicionalmente, se añadió una relación de herencia entre estudiante y profesor. Esto nos permite decir que todo lo que puede hacer un estudiante también lo puede hacer un profesor (pero no al contrario). De manera que en este caso si el estudiante puede “Visualizar Notas por Asignatura” y “Visualizar Notas por Estudiante” entonces el profesor también puede acceder a estos casos de uso. En principio ésta es una forma de simplificar un poco las relaciones entre los actores y los casos de uso estableciendo “jerarquías de usuarios”, en algunos casos puede ser buena idea, en otros no, depende del contexto. Además, esto tiene cierta relación con el concepto de “seguridad obligatoria” en un sistema (¿seguridad obligatoria? si mal no recuerdo se menciona con ese nombre en algún lugar del Navathe de bases de datos), es decir que funcionalidad puede o no puede acceder un determinado (tipo de) usuario, pero esto probablemente ya es tema de otra publicación.

F) Para que un usuario pueda ver las notas registradas debe de estar autenticado en el sistema, es decir, debe haber ingresado su nombre de usuario y su contraseña.

G) Para que un profesor pueda registrar o actualizar notas debe estar autenticado en el sistema.

Estos dos puntos son prácticamente el mismo y tienen una solución común. Generalmente resuelvo esto con un actor adicional y un caso de uso adicional:

CURN_casos_uso_A2
Figura 5

La idea es simple: “Usuario no Autenticado” tiene acceso al caso de uso “Ingresar al Sistema”, que es el que se encarga de autenticar al usuario (del modo que sea) y si el resultado es satisfactorio, es decir si las credenciales del usuario son válidas, entonces el usuario se transforma en un “Profesor” o en un “Estudiante” según sea el caso. Es posible que existan muchas otras formas de expresar esta situación, pero en este caso, ésta me parece bastante apropiada.

H) El sistema tiene que generar un reporte de notas por asignatura. Para esto, el profesor selecciona la asignatura y el sistema genera un PDF con todas las notas de la asignatura seleccionada.

I) Al igual que en el caso anterior, el sistema tiene que generar un reporte de notas por estudiante. Para esto, el profesor selecciona al estudiante y el sistema genera un PDF con todas las notas del estudiante seleccionado.

Estas son dos funcionalidades muy parecidas, sólo que en un caso se genera un reporte por asignatura y en el otro un reporte por estudiante. A pesar de las posibles similitudes, se van a manejar como dos casos de uso independientes. Por lo pronto, voy a ignorar las partes de “seleccionar la asignatura” y “seleccionar al estudiante”, asumiendo que se pueden describir dentro de los casos de uso asociados a los reportes respectivos:

CURN_casos_uso_B
Figura 6

Hasta aquí el diagrama transmite una idea bastante buena de la funcionalidad del sistema. Se puede decir que lo que sigue ya tiene aires de “lujo” y mucha gente puede pensar que es innecesario (y quizá en algunos casos tengan razón).

A continuación, se van a añadir un par de inclusiones y extensiones para reutilizar/separar algo de la funcionalidad común, que por fuerza, tal como está el diagrama va a ser necesario repetir en las descripciones de los respectivos casos de uso. En este sentido, como se dice en los puntos (C), (H) e (I) parece que seleccionar la asignatura y el estudiante son funcionalidades que se repiten, de modo que vamos a ponerlas en casos de uso aparte y a vincularlas usando una relación de inclusión:

CURN_casos_uso_C
Figura 7

De esta forma, es posible describir la funcionalidad común relacionada a “seleccionar estudiante” y “seleccionar asignatura” en sus propios casos de uso y reutilizarla desde donde sea necesaria. Sin embargo, el diagrama comienza a complicarse y aún faltan algunas cosas. Por ejemplo, no se ha considerado que es muy probable que para registrar notas también se necesite seleccionar el estudiante y la asignatura.

Otra funcionalidad interesante que quizá se pueda poner aparte es la relacionada con “filtrar por estudiante” y “filtrar por asignatura” tal como se expresa en (E). Esta funcionalidad es opcional, de modo que se puede vincular a los casos de uso correspondientes por medio de una extensión:

CURN_casos_uso_D
Figura 8

En este punto el enunciado comienza a agotarse, pero sin embargo, hay un par de cosas adicionales que resultan bastante evidentes:

1. Para “Visualizar Notas por Asignatura” hay que seleccionar la asignatura, y para “Visualizar Notas por Estudiante” hay que seleccionar el estudiante. Esto se puede lograr incluyendo “Seleccionar Asignatura” y “Seleccionar Estudiante”.

2. Para registrar una nota, es muy posible que sea necesario seleccionar la asignatura y el estudiante. Esto se puede lograr incluyendo los casos de uso respectivos ya mencionados.

Con estos últimos cambios el diagrama de casos de uso resultante es bastante difícil de leer, tal como se muestra a continuación:

CURN_casos_uso_E
Figura 9

En este punto, el diagrama de casos de uso tal como está es una “mala, pero muy mala idea”, el problema de legibilidad se debe a la bonita telaraña de inclusiones que tenemos, y se puede resolver separando el diagrama en varios diagramas más pequeños y simples tal como se muestra a continuación:

Diagrama 1 / Usuario No Autenticado

CURN_cu9A
Figura 10

Diagrama 2 / Profesor: Registrar + Actualizar Notas:

CURN_cu9B
Figura 11

Diagrama 3 / Profesor: Reportes

CURN_cu9C
Figura 12

Diagrama 4 / Estudiante y Profesor: Visualizar Notas por Asignatura

CURN_cu9D
Figura 13

Adicionalmente, es importante recordar que el diagrama de casos de uso no es lo verdaderamente importante a la hora de capturar requisitos. Un diagrama de casos de uso no es más que un artefacto que podemos usar para representar superficialmente la funcionalidad de un sistema, para tener una guía visual, un mapa general de su funcionalidad. Los diagramas de casos de uso sirven a la hora de tener una conversación informal con los clientes o con los colegas, permitiendo hacer una revisión general de la funcionalidad del sistema, dándole nombre y coordenadas (algo a lo que señalar) a la funcionalidad. En este sentido, es importante estar claros en que este tipo de de diagrama no permite capturar todos los detalles de la funcionalidad. Para esto existen muchos otros tipos de artefactos, entre los que se cuentan los casos de uso en si mismos, es decir, las descripciones textuales de los casos de uso. Todo esto sin considerar aún que esta visión ha cambiado y sigue cambiando, se ha enriquecido en mi opinión, con la visión aportada por los métodos / estrategias ágiles basados en historias de usuario (pero esto último y la relación que pueda tener con el problema actual es otra historia).

Finalmente, es importante recalcar, tal como mencioné al principio, que la solución y el diagrama pueden variar dependiendo de muchos factores: su autor, la cultura de la organización en la que se elabore, el contexto en el que se desea usar, los objetivos que se quieren satisfacer con el diagrama, etc.

Algunos autores preferirán organizaciones distintas de los casos de uso, otros preferirán diagramas más abstractos (como el de la figura 2), otros se sentirán contentos con diagramas más concretos como los que se obtuvieron al final, otros representarán la base de datos como un actor (cosa con la que no estoy de acuerdo), otros modelarán más cerca de la interfaz de usuario, otros considerarán modelar cerca de la interfaz de usuario un pecado mortal, otros englobarán múltiple funcionalidad en un sólo caso de uso asociado a varios actores, etc.

Ruido (Noise)

Ruido (Noise) es una película genial protagonizada por Tim Robbins y dirigida y escrita por Henry Bean

Tim Robbins interpreta a David Owen, un exitoso abogado de Nueva York que desarrolla una curiosa e insoportable sensibilidad al excesivo ruido al que algunas veces nos vemos expuestos en las ciudades (y curiosamente también en el campo), pero en especial al ruido generado por las alarmas de los automóviles. David decide actuar y hacer algo para resolver el problema, tomando caminos tan diversos que van desde llamar a la policía y quejarse, dedicarse al vandalismo, tomar los caminos legales, hasta finalmente (¿finalmente?) transformarse en “The Rectifier”, una extraña clase de justiciero del “underground” que resolverá el problema del ruido de una forma nada convencional.

La película es una mezcla deliciosa y extraña de comedia y drama, tocada en mi opinión con un poquito de anarquismo. Si bien el tema principal pareciera ser la contaminación por ruido, me parece que esto es sólo una excusa para explorar otros aspectos de la naturaleza humana y de la zoociedad actual (¿o es sociedad? esa es una palabra que nunca he sabido deletrear correctamente).

mafalda_zoociedad

En este sentido, algunos comentarios plantean que la película explora la forma en que los seres humanos reaccionamos frente a este tipo de problemas y la manera en que los resolvemos: primero reaccionamos irracional o emocionalmente, luego tratamos de racionalizar el problema, luego, si no podemos resolver el problema racionalmente (por las razones que sean) reaccionamos con frustración y por lo tanto de forma irracional y quizá violenta, etc. [lo siento, perdí el vínculo/referencia a este comentario, si alguien lo encuentra lo incluyo].

Si bien en relación al tópico de la película ambos enfoques anteriores son correctos, pienso que la película va más allá y plantea lo difícil que puede ser resolver en nuestras sociedades problemas básicos y elementales como el del ruido, fundamentalmente a causa de nuestra propia ignorancia, por lo difícil que es ver el problema, lo difícil que es actuar y lo duro que es convencer al vecino de que en verdad existe un problema, por el hecho de que la gente se acostumbra a las cosas: al ruido, a la basura en la calle o a tirar la basura por la ventana, a los disturbios de los encapuchados (esa es una oscura referencia al día a día de Mérida y la ULA), a la mediocridad, etc. y porque finalmente pareciera que vivimos en un mundo en el que a “nadie le importa un bledo” y nadie en el fondo hace algo al respecto. Una de las citas curiosas de la película en este sentido es:

People will look back on the way we live today and they will not understand how we put up with it.

Algunas de las críticas han sido malas y se pueden leer comentarios como ¿En qué estaría pensando Tim Robbins al aceptar este papel? y cosas así. Muchas de las críticas y los comentarios de la gente me ayudan a confirmar una hipótesis en la que he venido pensando últimamente: si las criticas y los comentarios son malos y la película se ve interesante… entonces de seguro es una de esas buenas películas ignoradas por las “masas”; lo opuesto es que si los comentarios generales son demasiado buenos probablemente estamos frente a un vacío y estúpido “éxito de taquilla”. Si, en efecto no se puede confiar mucho en las masas últimamente.

Tim Robbins me parece una excelente selección para el papel de David Owen. En mi opinión es un actor en extremo extraño (en el buen sentido) y versátil, que puede hacer cosas muy variadas que van desde The Shawshank Redemption o Code 46, pasando por papeles de “malo” como en Arlington Road o Antitrust, hasta papeles dramáticos de desequilibrado como en Mystic River, o apariciones muy cortas y extravagantes en películas como War of the Worlds.

Debo decir que me sentí muy identificado con la película y con el personaje, en realidad también soy un poco sensible al ruido y vivo en una ciudad en la que a la gente el ruido le importa cada vez menos. A eso le pueden añadir que también he tenido más de una vez la tentación de… bueno, de usar métodos poco o nada ortodoxos para resolver ese tipo de problemas… pero eso, ¡Supongo que es tema de otra publicación, o de otra película!

Cierro esta historia con la frase final de la película, que es en verdad muy ilustrativa:

Officer Moretti: What did he do?
Arresting Officer: Busted into a car who’s alarm was going off. Who’s gonna take him down to central booking?
Officer Moretti: He busted into a car cuz the alarm was going off? Jesus Christ, what if everybody did that?
Arresting Officer: If everyone did it, people would turn off their damned alarms, now wouldn’t they?

Pagarle menos de 1000$ a un profesor con doctorado: Priceless!

Hace unos días, encontré en la lista de correo de la universidad (y me refiero a la Universidad de Los Andes en Venezuela) un llamado a concurso para un cargo de profesor en el CESIMO. En verdad fue difícil evitar reír (o llorar) cuando vi el llamado al concurso.

El cargo es para un profesor agregado a tiempo completo, que equivale a 36 horas semanales, en el área de Técnicas Avanzadas de Modelado y Simulación, cobrando un salario de… ¡TA-DA! 3.573,00 BsF. Para ser honestos, a ese salario hay que sumarle el bono de alimentación y quizá algún que otro bono menor y luego hacerle una buena cantidad de deducciones, correspondientes al seguro, CAMIULA, fondo de jubilaciones, etc. Estimo que al final el titular del cargo recibirá mensualmente como mucho unos 3.000,00 BsF más 700,00 BsF adicionales de bono de alimentación.

¿Qué es lo verdaderamente chistoso/triste del asunto? que el aspirante, entre muchos otros méritos, tiene que tener un título de doctorado… y si a estas alturas no me creen, aquí va una captura de pantalla del llamado al concurso (click en la imagen para ver el pdf original).

PagarleMenosDe1000USDAUnDoctor_PriceLess_thumb

Para los que no conocen muy bien el ambiente académico, resumiendo de forma general: Un título de doctorado es un título de estudios de postgrado que se obtiene estudiando cerca de 5 años luego de haber obtenido un titulo universitario, como por ejemplo un título de ingeniero o de físico, de médico, etc. Es decir, una persona con un título de doctorado tiene en sus espaldas entre 9 y 10 años (y quizá algunas veces un poco más) de estudios universitarios. Además, para obtener este título, hay que desarrollar un proyecto de investigación que, al menos en teoría, debe ser completamente inédito, es decir, que debe ser algo que nadie ha hecho antes. Como dice uno de mis personajes favoritos de la TV: “to boldly go where no man has gone before“. Por cierto que el contenido del concurso tampoco es nada trivial, como se aprecia aquí.

Adicionalmente, para los lectores internacionales, hay que aclarar cuanto vale un Bolívar Fuerte (¿fuerte?). La historia simple y oficial: 1 USD = 4.3 BsF. Es decir, el profesor del concurso va a ganar… y voy a hacer el cálculo directamente con el sueldo base …un total de 831 USD.

En este punto es cuando el lector dice “¡wow tan sólo 831 USD mensuales para alguien con un título de doctor!“, y aquí es donde yo digo “sí, y se pone peor“.

Si se quiere entender esos 3.573,00 BsF, hay que poner el valor del dolar en contexto (tengo la sensación que voy a disfrutar este párrafo, desde el punto de vista literario me refiero). El Dolar en Venezuela es un número complejo, y sí, me refiero al concepto matemático de números complejos.

Complex_number_illustration

El valor del dolar en Venezuela es un número del tipo a + b*i, donde el límite de b (la parte imaginaria) cuando t (el tiempo) tiende al día de hoy es = 4.3 BsF/$, pero el límite de a (la parte real) cuando t tiende al día de hoy es el valor de una lechuga verde, es decir, algo así como de 8.6 BsF/LechugaVerde. Lo que ocurre es que en el día a día de nuestro país los números imaginarios (i) no existen, es decir, no están definidos, por lo que nos tenemos que conformar con la parte real del número complejo a + b*i, es decir con a, que es más o menos el doble de la parte imaginaria.

Bueno, ya me dí el gusto, tenía tiempo queriendo escribir eso de los dolares (en Venezuela) como números imaginarios. En conclusión, ese profesor en realidad está ganando 415 Lechugas Verdes. ¿Ven ahora lo gracioso y trágico de la situación? Me han dicho (y no me consta de primera mano, pero la fuente es confiable) que en Argentina un cajero de un easy, quien definitivamente no necesita un doctorado, gana más o menos eso (y quizá que más).

En mi opinión, para que alguien con el perfil requerido en el concurso trabaje por esas sumas de dinero, se tiene que cumplir alguna de las siguientes condiciones:

  • Se es un mediocre (es triste tener mediocres en una universidad como la ULA).
  • Se es un iluso y/o un apasionado por el trabajo académico (para bien o para mal, la ilusión y la pasión por el trabajo académico son cosas que tienen cura: esposa, hijos, necesidades de alimentación, vivienda, etcétera).
  • Se es muy viejo para irse y abrirse camino en otro trabajo o se está muy cerca de la jubilación.

En lo particular, yo caigo en el segundo punto, es decir, soy (fui o cada vez soy menos) un iluso/apasionado por mi trabajo. Para este concurso en particular me imagino que ya tienen a un candidato, y conociendo a la gente del CESIMO, a la cual le tengo en general mucho respeto, estoy seguro de que es alguien muy competente que también cae en la categoría del segundo punto (iluso / apasionado).

How to emulate relational algebra division operator in SQL

I found this recently among my files while preparing a lecture on SQL for my Database Systems course. I wrote this on October 2010 and have not checked it since then, but I believe in the correctness of the information.
To my Spanish readers, I ask for your forgiveness, I need to write a few things in english from time to time to avoid getting clogged (Is it “clogged” the right word?).


This document answer a very common question related to the emulation of division operation from relational algebra using SQL. Despite how commonly it’s used, most of the RDBMs don’t support division operation out of the box, so it’s necessary to find a way to emulate it with the help of other supported relational algebra operators. The present document describes a way to do that.

If you want to know what does a relational algebra’s division operator do or want to know how to emulate a division from other relational algebra operators check here.

First, we create the following tables. The meaning of the information contained in the tables is not important, only their structure matters.

CREATE TABLE foo (
  id   INTEGER PRIMARY KEY,
  name VARCHAR(10) 
);

CREATE TABLE faa (
  id   INTEGER PRIMARY KEY,
  name VARCHAR(10) 
);

CREATE TABLE foofaa (
  id_foo INTEGER REFERENCES foo,
  id_faa INTEGER REFERENCES faa
);

This is basically a many to many relation between foo and faa:

+-----+ *    +-----+
| foo |------| faa |
+-----+    * +-----+

or if you like:

+-----+ 1  * +--------+ *  1 +-----+
| foo |------| foofaa |------| faa |
+-----+      +--------+      +-----+

For testing purposes, we’ll fill the tables with some data. This way, the next queries will return the following results:

SELECT * FROM foo;

 id | name 
----+------
  1 | X
  2 | Y
  3 | Z
(3 rows)
SELECT * FROM faa;

 id | name 
----+------
  1 | A
  2 | B
  3 | C
(3 rows)
SELECT * FROM foofaa;

 id_foo | id_faa 
--------+--------
      1 |      1
      1 |      2
      1 |      3
      2 |      1
      2 |      2
      3 |      1
(6 rows)

Then, we want to perform a division between (R):

SELECT foo.id, foo.name, faa.name FROM foo, foofaa, faa
  WHERE foo.id = foofaa.id_foo AND faa.id = foofaa.id_faa;

 id | name | name 
----+------+------
  1 | X    | A
  1 | X    | B
  1 | X    | C
  2 | Y    | A
  2 | Y    | B
  3 | Z    | A
(6 rows)

…and (S):

SELECT name FROM faa;

 name 
------
 A
 B
 C
(3 rows)

So, the operation would be R/S.

The expected result is a relation containing the row (1, X), which is the only one that is related to each and every “name” in (S) (see division).

To emulate this with other relational algebra operators (but in SQL), we have to cross product the attributes in R that are not in S with S. So basically, from the setup we have created we need to cross the content of table faa with the content of S. We’ll name the result of this operation T:

SELECT foo.id, foo.name, faa.name FROM foo, faa;

 id | name | name 
----+------+------
  1 | X    | A
  1 | X    | B
  1 | X    | C
  2 | Y    | A
  2 | Y    | B
  2 | Y    | C
  3 | Z    | A
  3 | Z    | B
  3 | Z    | C
(9 rows)

Then we need to make T-R to have all the elements NOT present in the original R. We’ll call this result U:

(SELECT foo.id, foo.name, faa.name FROM foo, faa)
  EXCEPT
(SELECT foo.id, foo.name, faa.name FROM foo, foofaa, faa
    WHERE foo.id = foofaa.id_foo AND faa.id = foofaa.id_faa);

 id | name | name 
----+------+------
  2 | Y    | C
  3 | Z    | B
  3 | Z    | C
(3 rows)

This looks right, in the sense that the row originally named Y has only related A and B, so in U we have only C, which is not related to Y. Z is related only to A so it’s not related to B and C, and finally, X is related to all entries in faa so it does not appear on the results of U.

Now we project only the attributes from U that belong to R and name the result as V (some aliases tricks where needed to do this):

SELECT x.id, x.foo_name FROM (                                    
  (SELECT foo.id, foo.name AS foo_name, faa.name AS faa_name FROM foo, faa)
    EXCEPT
  (SELECT foo.id, foo.name, faa.name FROM foo, foofaa, faa
      WHERE foo.id = foofaa.id_foo AND faa.id = foofaa.id_faa)) AS x;

 id | foo_name 
----+----------
  2 | Y
  3 | Z
  3 | Z
(3 rows)

And finally we do R-V to get the desired R/S result:

(SELECT * FROM foo)
  EXCEPT
(SELECT x.id, x.foo_name FROM (
  (SELECT foo.id, foo.name AS foo_name, faa.name AS faa_name FROM foo, faa)
    EXCEPT
  (SELECT foo.id, foo.name, faa.name FROM foo, foofaa, faa
      WHERE foo.id = foofaa.id_foo AND faa.id = foofaa.id_faa)) AS x);

 id | name 
----+------
  1 | X
(1 row)

That’s it, the result is R/S!

Sueño de una noche de AVM (parte 2)

En una publicación anterior escribí un poco sobre el AVM y sobre una pesadilla que tuve al respecto.

Si bien en esa publicación describí con cierto detalle el AVM nunca terminé de contar la pesadilla (¿Suspenso? ¿Marketing?).

En fin, mi pesadilla fue la siguiente:


Me encontraba en una sala, en contra de mi voluntad, siendo forzado a trabajar con personas con las que probablemente evitaría trabajar si tuviera la oportunidad. Resulta que yo era algo así como “el líder del proyecto” y “el consultor técnico”. En el fondo había una sensación implícita de que si el proyecto fracasaba todo iba a ser culpa mía. Si el escenario le suena conocido a algún líder de proyecto o consultor puede pasar por mi casa, con gusto nos tomamos unos tragos y luego le presto una soga…

goya_1

Básicamente el proyecto consistía en una aplicación de escritorio basada en Swing, usando los primitivos DAOs que recuerdo (¿pesadillas con la clase MAbstract?) y MS SQL Server de BD. Sin servidor de aplicaciones, sin SOA, sin desacoplar la lógica del negocio del cliente y con unos horribles “updaters” de la BD.

El problema era que en el fondo no lideraba nada ni asesoraba en nada. Es decir, si bien trataba de lograr que todo funcionara y procuraba sugerir diseños que sonaban razonables, en el fondo nadie me hacía caso. La gente venía y me consultaba y luego se iba y hacía lo que quería, que usualmente en el sueño eran cosas locas que atentaban contra el sentido común.

Me explico, como consultor técnico, uno puede enumerarle las opciones técnicas al cliente, explicando de cada una las ventajas, desventajas, riesgos, debilidades, fortalezas, etc. Inclusive, es posible aconsejar para cierto contexto, proyecto o producto sobre la opción más adecuada a utilizar. El problema era, que en la situación en la que me encontraba, no habían opciones… es decir, independientemente del contexto, lo único que podía escoger era… la arquitectura del AVM, que como mencioné en una publicación anterior no era mala, pero con el tiempo se degradó bastante.

Yo sabía que existían alternativas mucho mejores, clamaban en mi interior por salir, no dejaba de pensar en Hibenate, Spring, SOA, EJB, CLEDA, etc…

Pero simplemente no salían. Lo único que podía escoger era el diseño base del AVM.

Debo aclarar que el producto NO era el AVM. Era otro producto, que terminaba pareciéndose al AVM, pero que definitivamente no lo era. Ahora que lo pienso, también parecía haber un problema de requisitos, es decir, si les soy franco no tenía ni la menor idea de que diablos se trataba el producto y eso en particular era muy frustrante.

Como líder de proyecto, mi trabajo era organizar el trabajo, el grupo, planificar, etc. En general, lo que hace un líder de proyecto en el sentido clásico del término. El problema era que el equipo de desarrollo era muy grande, demasiado grande para el producto que se estaba desarrollando. Pienso que habían como 50-60 personas en la sala, cuando yo estaba seguro de que un pequeño grupo de 5 personas sería más que suficiente para el trabajo. ¿Ven el dilema? Otra cosa curiosa es que había comida en toda la sala. El lugar parecía una fiesta, había pizza y refrescos por todos lados y la gente comía de forma muy descuidada. No se porque, pero cada vez que iba a hablar con alguien, esa persona estaba mascando un trozo de bistec o llevándose a la boca un poco de ensalada.

goya_2

Bueno, quizá exageré un poco con la ilustración anterior…

Yo estaba seguro de que lo ideal era usar algún tipo de estrategia ágil, tenía planeado organizar las 50 personas en pequeños grupos de 5-6 personas, usar algo como Scrum y asignar a cada grupo pequeñas tareas. Suena loco y forzado pero sinceramente, creo que fue la mejor idea a la que mi subconsciente pudo llegar para compensar la locura de un proyecto de 5-6 personas desarrollado por 50-60. A decir verdad, dada la locura y lo surrealista de la situación, aún ahora despierto no creo que la estrategia fuese tan mala idea.

Pero aquí viene lo peor…

goya_3

Por más que se suponía que yo era el líder del proyecto, o al menos todos lo suponían, es decir, en lo que a mi respecta yo sólo quería salir corriendo de la sala (desastre) y era evidente que toda la responsabilidad iba a ser mía si algo salía mal, no tenía absolutamente ningún poder de dirección.

Era simplemente imposible organizar tareas, era imposible hablar con nadie del equipo (o del manicomio). Lo peor, era que había una mujer detestable, y esto lo digo sin pretender en lo absoluto ofender al género femenino, que iba como loca de un lado a otro, dando y gritando ordenes, que eran en general disparates, mirándome con cara de cómplice y guiñándome un ojo tanto en tanto… y simplemente no había nada que yo pudiera hacer para detenerla, era una criatura verdaderamente aterradora.

A decir verdad no se en que terminó todo. Si nos guiamos por el sentido común, entonces es evidente que terminó en desastre… pero en el reino del subconsciente uno nunca sabe.

Afortunadamente desperté y resultó ser de esos sueños (pesadillas) impactantes que uno recuerda y escribe. De hecho, releyendo mi texto pienso que la pesadilla fue mucho peor de lo que en verdad he logrado plasmar en estas líneas, mi descripción carece de los colores oscuros, el horror y la frustración necesaria.

Por cierto, si el infierno existe… seguro que esta pesadilla sería un buen tormento XD

goya_4

Todas las ilustraciones de este post son de Francisco Goya

De arriba a abajo, las obras se llaman “El tres de mayo de 1808”, “Saturno devorando a un hijo”, “Esto es peor” y “El sueño de la razón produce monstruos”.


Debo decir que no tengo nada en contra del AVM. Todo lo contrario. En el fondo recuerdo el proyecto con mucho cariño, fue una buena escuela en la que además pude compartir trabajo con buenos colegas. De alguna forma, quizá indirectamente, esta es mi retorcida manera de rendirle un homenaje al AVM.

¿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.