h1

Rompiendo una relación codependiente (Parte 3)

12/14/2010

Wizdoc [Icon By Buuf]  Tips & Tricks.

Siguiendo con la “Gesta Revolucionaria” que me ha llevado a realizar algunos viajes a San Diego para traernos código aplicativo a México y tropicalizarlo desde aquí sin depender del corporativo, la semana antepasada logramos un avance significativo:

Project @ Local NetBeans

El proyecto instalado y corriendo en mi laptop. (Click en imagen para ver a mayor escala)

Nos costó un día completo de trabajo lograr la puesta a punto del ambiente de desarrollo, incluyendo IDE y herramientas anexas – ant, maven, subversion – así como el código fuente, servidor de aplicaciones, base de datos y un sistema de mensajería empresarial necesarios para el correcto funcionamiento de la aplicación.

Después de instalar todo en mi lap y tratar de hacerlo correr, sólo me botó algunos errores debido a un curioso bug de la versión 1.6.0_16 de Java:



  @Test
  public void testLocalizableEnum()
  {
    Locale en = new Locale(“en”);
    Locale es = new Locale(“es”);
    String englishNo = LocalizedEnum.YES.getDisplayName(en);
    String spanishNo = LocalizedEnum.YES.getDisplayName(es);
    Assert.assertEquals(“English YES”,“yes”,englishNo);
    Assert.assertEquals(“Spanish YES”,“si”,spanishNo);
    spanishNo = LocalizedEnum.YES.getDisplayName(es);
  }

Unit test fail
Código fuente de un componente del proyecto y error desencadenado al ejecutar el correspondiente test unitario.

La prueba unitaria revienta porque sólo carga el archivo de propiedades internacionalizadas en español. Lo extraño del asunto es que a los desarrolladores nunca les había aparecido semejante error, aplicándome la tradicional “es que sí jala en mi máquina”. Después de buscar un rato y hacer algunas pruebas, me di cuenta que la JVM siempre toma como “lenguaje por defecto” la localidad en la que se encuentra la máquina, pero no carga la versión en otros lenguajes a menos que explícitamente se indique dicha localidad… en inglés:



  @Test
  public void testLocalizableEnum()
  {
    Locale.setDefault(new Locale(“en”)); //Required to run on non-en machines
    Locale en = new Locale(“en”);
    Locale es = new Locale(“es”);
    String englishNo = LocalizedEnum.YES.getDisplayName(en);
    String spanishNo = LocalizedEnum.YES.getDisplayName(es);
    Assert.assertEquals(“English YES”,“yes”,englishNo);
    Assert.assertEquals(“Spanish YES”,“si”,spanishNo);
    spanishNo = LocalizedEnum.YES.getDisplayName(es);
  }

Código fuente del mismo componente estableciendo el local por defecto en Inglés. La ejecución de este código no genera error alguno.

Y bueno, ya después de dejar todo corriendo de manera satisfactoria, definí conjuntamente con el Lead Programmer de San Diego algunos manuales de instalación, que podrán usar los desarrolladores para instalar en sus máquinas todo lo que necesita el proyecto para programarlo y desplegarlo en la máquina local. Sin embargo, de momento México no tomará por completo las riendas del código debido a dos “pequeños” inconvenientes:

• Si tomáramos la responsabilidad por el proyecto, el único que estaría “picando teclas” sería yo mismo, pues nadie por aquí conoce las “tripas” del código; máxime que necesitamos un plan de transferencia que incluya la contratación y capacitación de al menos dos programadores de buen nivel debido a que los recursos ya existentes están ocupados en otros proyectos.

• En este momento, el sistema está presentando problemas de desempeño, debido a malas decisiones de diseño tomadas cuando se conceptualizó la aplicación. Aquí pinté mi raya, pues eso de “toma al monstruo y ráscate con tus uñas” me parece una jalada: hablé con la gente de San Diego afirmando que adicionalmente a un plan de transferencia, México debe recibir una aplicación estable para poder entrarle de lleno al soporte y construcción.

Así entonces, San Diego realizará un “major refactoring” durante el siguiente release de la aplicación y modificará el módulo con problemas de desempeño que nos están sacando canas verdes, antes de entregarlo.

Desempeño: un poco más de cerca

¿A qué problema de desempeño nos estamos enfrentando? Primero un poco de background: Resulta que la aplicación se construyó de manera inicial como una prueba de concepto, demo o maqueta que permitiría recibir peticiones desde terminales móviles (celulares) y mostrar de primera instancia un GPS track and trace:

GPS Track and Trace Example

Un ejemplo de track and trace empleado por un GPS en conjunto con una terminal móvil. (Fuente: diggles.com)

El detalle es que el componente que recibe los mensajes desde las terminales móviles fue pensado precisamente como un demo, utilizando mensajes UDP (User Datagram Protocol) sobre un protocolo de transmisión conocido como TFTP (Trivial file transfer Protocol). Para 1,000 unidades móviles o menos esto es relativamente fácil de gestionar, pero una vez que se llega a un volumen de 8,000 unidades o más, los problemas se tornan cada vez más complejos:

• El protocolo UDP es de muy baja prioridad dentro del ecosistema de redes debido a que su naturaleza es de transporte no fiable de datagramas y por ello, cuando la red celular llega a saturarse, los mensajes UDP son los primeros que quedan “al final de la cola”.

• Debido a que UDP no maneja “sesiones” ni “estados”, sólo es posible saber que el mensaje llegó al destinatario debido a un mensaje de reconocimiento de recibo o acknowledge, que también está en UDP. Si la terminal móvil no recibe el ack correspondiente, enviará otro mensaje. Esto complica la situación, pues es posible saturar la red con múltiples mensajes duplicados.

• Adicionalmente, cuando la red “vuelve a la normalidad”, llega al servidor TFTP un auténtico bombardeo de mensajes UDP que es necesario procesar, convirtiendo a dicho componente en un cuello de botella y generando a su vez retrasos en la entrega de la información a los demás subsistemas de la plataforma, como mapas de track and trace, reportes y web services que hacen uso de la información procesada.

Todo esto está provocando que después de una falla en la red – Telcel es bastante malo en su servicio, pero es el único en México con suficiente cobertura – algunos clientes llamen molestos preguntando por qué aparece en el mapa como “manejando vehículo” si lleva estacionado más de 20 minutos. Y por supuesto, de este lado todos estamos como calzón de sexoservidora: de arriba a abajo tratando de depurar las colas o reiniciando los servidores.

Siguientes pasos

¿Qué deberemos hacer durante los próximos días? Como es la costumbre, a los desarrolladores originales se les indicó que en vez de “perder el tiempo” documentando los módulos que conforman el sistema, mejor se dedicaran a generar código productivo encima del prototipo ya generado. Esto claro está, resultó en los esqueletos que actualmente tenemos en el closet. Así que tenemos al menos dos tareas de alta prioridad por resolver en conjunto entre México y San Diego:

• Realizar pruebas de concepto que nos ayuden a determinar esfuerzo, tiempo y costos necesarios para cambiarnos a TCP (Transmission Control Protocol) y FTP (File Transfer Protocol). Esto es como demoler un lado de la casa para reconstruirlo desde cero, pero es necesario si queremos soportar un mayor número de unidades.

• Documentar la plataforma, generando un diagrama de arquitectura detallado. Aunque talachudo, no es muy complicado; un diagrama de este tipo nos permitirá detectar posibles cuellos de botella y al generarlo tendremos una buena oportunidad de conocer al detalle el funcionamiento interno de la solución.

Así entonces, el mundo no se detiene. Seguimos chambeando con el afán de mejorar y crecer. ¿Hasta dónde llegaremos? Sólo el tiempo lo dirá.

One comment

  1. […] una aplicación de rastreo, monitoreo y seguridad logística, muy parecida a otra que hemos traído desde Estados Unidos a México desde hace tiempo. La gran diferencia radica en que mientras la […]



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: