La lógica de TopCoder es un poco distinta a la de los maratones de programación de la ACM, entre las diferencias encontramos que, existe un sistema diferente de evaluación de problemas (por puntajes y tiempo), e incluso de formato en el código fuente (Se definen reglas estrictas acerca de los nombres de las clases y métodos).

Para ingresar en TopCoder es necesario tener Java instalado en nuestra maquina, ya que funciona mediante Applets o Java Web Start (el cual recomiendo). A pesar de que el sistema (de ahora en adelante “la arena”) funcione muy bien, la parte de edición de código fuente no es la mas idonia para trabajar en competencias bajo presión.

Para solucionar este problema, los programadores de TopCoder ofrecieron la posibilidad de implementar Plugins que se adaptan a la arena y permiten mejorar los editores de texto (o incluso no usarlos del todo). A continuación explicaremos como instalar y configurar algunos Plugins para mejorar nuestra productividad a la hora de realizar competencias dentro de TopCoder.

1. Obtener el archivo .jws que carga la arena en nuestro computador

   Para obtener la aplicación de la arena, debemos acceder a este link (Como indicamos anteriormente, se debe tener Java instalado para que este funcione).

   

2. Ingresar al sistema (o registrarse en caso de que no nos encontremos registrados)

   En el caso de que no se encuentre registrado en el sistema, siga las indicaciones de la aplicación para registrarse

3. Descargar los Plugins que harán tu vida más fácil

   Entre los Plugins que puedo recomendar, se encuentran CodeProcessorv2.0, FileEdit y moj

4. Configurar los plugins dentro de la arena

   Para instalar los Plugins dentro de la arena se deben seguir los siguientes pasos:

   • Acceder al menú de “Options” y luego la opción “Editor”

     

   • Al abrirse la ventana de editores, debe presionar click en el botón “Add”, esto abrira otra ventana donde deben ingresar el nombre del editor (CodeProcessor en nuestro caso), en el campo EntryPoint, debemos colocar “codeprocessor.EntryPoint”, y en el campo classpath, al presionar el botón “Browse” debe buscar todos los Plugins (archivos .jar) que descargo en el paso anterior

     

   • Una vez instalado el nuevo editor, presionamos click en el botón “Configure”, se abrirá una nueva ventana donde se debe especificar en el campo “Editor EntryPoint” el valor “fileedit.EntryPoint”, luego presionamos el botón “Add” y en la nueva fila creada asignamos el valor “moj.moj”. Lo que hacemos aquí, es usar CodeProcessor como un manejador de Plugins, que permite usar varios Plugins (en este caso FileEdit y moj) simultaneamente.

     

   • Para configurar los plugins de FileEdit y moj, se debe presionar a los botones “Configure”, ahi se tendrán diferentes opciones dependiendo de cada Plugin

     

   • Para finalizar, ingrese a la configuración de FileEdit, y en la pestaña de “Code Template”, en la opción de C++, ingrese el siguiente contenido

     $BEGINCUT$
     
     /*
     $PROBLEMDESC$
     */
     
     $ENDCUT$
     
     #line $NEXTLINENUMBER$ "$FILENAME$"
     #include "string"
     #include "vector"
     #include "algorithm"
     #include "map"
     #include "iterator"
     #include "iostream"
     #include "sstream"
     #include "cstdio"
     #include "cmath"
     #include "cstdlib"
     #include "queue"
     #include "stack"
     
     using namespace std;
     
     class $CLASSNAME$ {
     
       public:
     
       $RC$ $METHODNAME$($METHODPARMS$) {
     
       }
     };
     
     $BEGINCUT$
     $TESTCODE$ 
     
     $DEFAULTMAIN$
     $ENDCUT$
     

     

5. Ahora… a programar

   Una vez instalados y configurados los Plugins, al momento de abrir un problema dentro de la arena, verá que el editor de texto no se encuentra en el programa de la arena, mas bien se muestra un log de acciones. Lo que ocurre es que el contenido del problema es descargado, y con este se genera un archivo que contendrá el enunciado del problema, junto con una implementación que contiene el template establecido en la configuración del FileEdit (que cambiará dependiendo del problema) y un main que ejecuta las pruebas del problema.

   

OK, ¡suficiente habladera de tonterias!. Una forma de remediar esto es agregar otro protocolo (como TCP/IP) encima al programa original que recolectaba las temperaturas de todos los sensores, es decir lo convertimos en un servidor.

Lo primero es decidir si queremos usar un protocolo existente o si queremos reinventar la rueda; Para este experimento decidí que usar un protocolo existente con algunas modificaciones era lo más sencillo (Daytime, RFC686):

• El servidor escucha en el puerto 1973 (cualquiera sirve si está libre ;)).
• El cliente envia un paquete (vacio o no) al puerto 1973 en la máquina en donde corre el servidor
• El servidor recibe el paquete y lo descarta. Envia de vuelta uno nuevo con una lista temperatura de todos los sensores que ha escuchado hasta el momento
• El servidor no envia más temperaturas

El protocolo es sencillo, es puro texto (con una cabecera el cual el cliente utiliza como validación):
HEADER SENSORID1 SENSORCOUNT1 TEMPERATURE1 UNITS1 SENSORID2 SENSORCOUNT2 TEMPERATURE2 UNITS2 ...

Siempre es bueno encapsular los paquetes de un protocolo en una clase, para hacer más fácil su manejo:

El siguiente paso es decidir como codificar y decodificar el mensaje que enviamos a traves de la red; En el mundo Java podemos usar RMI, Sockets + Serialization sin embargo me pareció mejor utilizar UDP, por lo pequeño de los mensajes además de que no requiero las características extras de TCP, y no serialización (hay que ser MUY cuidadoso cuando se implementa, no es sólo decir que la clase implenta la interfaz "Serializable"):

Si, una interfaz la cual va a implementar el codificador especifico (código aquí). De esta manera, si cambiamos el protocolo (usamos Java + Serialization por ejemplo), nuestra aplicación sólo tiene que cambiar la declaración del codificador concreto y listo.

¿Que viene después? Ah, envenenar al cliente original que capturaba la temperatura; Ahora va a ser un servidor El cual:

• Va a capturar constantemente nuevas temperaturas desde la inalámbrica de los sensores en una hebra separada
• Va a enviar todas las temperaturas disponibles a quien se las pida

Si bien el código del servidor no es muy largo (haga click aqui para verlo completo) prefiero mostrarle sólo las piezas críticas:

Si, el servidor no es muy robusto ni soporta un gran número de clientes a la vez (es iterativo), pero para jugar un rato está bien :)

Bueno, si aún no le ha dado un ataque leyendo todo este código lo invito a que vea el cliente (código completo aqui) . Muy sencillo (sólo imprime por pantalla las temperaturas) sin embargo tiene una caracteristica muy importante: No tiene ninguna dependencia con el código de Sentilla:

Bueno, ahora lo que queda es ponerse a jugar conectándole otros sensores e incluso volviendo más inteligentes a los sensores.

¿Y ustedes que piensan? Intercambio de ideas y código van de la mano :)