La dura vida del programador de oído

Rodol programa de oído. Ya sabéis, ese tipo de persona que harto de haberse pelado el culo programando en todo lenguaje en todo mar conocido, se mosquea como un mono cuando las cosas no tienen sentido. Y entonces programa de oído y se pone a blasfemar en voz alta contra el compilador. “¡Venga, no me jodas! ¿Pero quién coño pensó esto? ¿Estás de coña? ¡Joooooooooooder!”. Ya sabéis, programa de oído.

Normalmente sabemos que Rodol está programando por la cantidad de exabruptos que exhala y, dependiendo del volumen y calidad de los mismos, la importancia y/o prisa que tiene con ese trabajo.

A Rodol le caen las cosas más rarunas. Migrar librerías .Net a código C++ o Delphi para meter un módulo en un servidor que no tenga el framework, desarrollar funciones o módulos en ASM para Windows, programar los retos hacking con los árboles LDAP, hacer sistemas de monitorización para Windows Mobile autenticados digitalmente o integrar aplicaciones con Exchange. Así que siempre le toca programar de oído.

Y así andaba esta semana, programando de oído un Exchange Server 2010 SP1 para integrarlo con una aplicación que lo usa para gestionar alertas y workflow de documentos por medio de carpetas públicas, cuando soltó un epíteto que bien podía haber sido el epitafio del proyecto y me hizo preguntarle qué le sucedía.

- “Que me está vacilando esto, le digo que me dé una lista de carpetas, compruebo que no esté vacía y cuando invoco un método de la primera de la lista me dice que la lista está vacía”.


Figura 1: El código del demonio
Será por cualquier cosa, pensé, que al final siempre hay alguna explicación por medio. Ya sabéis, una autenticación que falta, una transformación de datos necesaria para invocar el método, o lo que sea, que así funciona este negocio.

- “¿Has buscado el código de error en la MSDN Library?”, contesté solo por si, como el Doctor House, necesitara oirse en voz alta y le hiciera falta alguna oreja que escuchar.

- "Sí, y me he partido la caja. Mira, éste es el error que me devuelve el compilador".


Figura 2: El código de error que devuelto
- "Y esto es lo que me dice la MSDN Library del código de error".


Figura 3: Código de error no usado
La verdad es que, encontrarse un código de respuesta que no se usa, que además aparece documentado es un poco de coña y da a entender que alguien no ha hecho los pertinentes deberes. O el desarrollador de la nueva API de Exchange Server 2010 SP1 no ha informado de que sí que lo están usando, o el que ha hecho la documentación se ha olvidado de actualizarla.

¿Y ahora qué se hace? Pues seguir probando, porque está claro que el proyecto tendrá que acabarse, así que Rodol tendrá que hacer magia otra vez y seguir buscando, primero el problema, para después encontrar la solución. Así es la dura vida del programador de oído.

Saludos Malignos!