Discusiones sobre omegaUp

Hemos abierto un grupo de discusión de Google para hablar sobre problemas técnicos durante el desarrllo de omegaUp y debatir los nuevos features que los colaboradores están pensando en implementar.

Si quieren seguir las discusiones, los invitamos a unirse aquí:

https://groups.google.com/forum/#!forum/omegaup-discusion

También pueden postear sus propias preguntas o peticiones si así lo desean.

Cambios en el ranking

Continuando con los cambios en el ranking de omegaUp, a partir de hoy sólo los problemas resueltos marcados como públicos van a contar puntos para calcular el score. Este cambio es con la intención de hacer el ranking más justo con problemas visibles a todos.

De igual forma, el Coder del Mes también será calculado sólo con problemas públicos.

Desafortunadamente varios competidores cayeron bastantes posiciones en el ranking. Ayúdenos a convencer a su problemsetter favorito a que los problemas se publiquen al finalizar los concursos.

omegaUp presentado en la International Olympiad in Informatics 2014

IOI Journal

 

Del 13 al 18 de Julio del 2014 se llevó a cabo la International Olympiad in Informatics (IOI) en Taipei, Taiwán. En paralelo a la IOI, el comité organiza la publicación de la revista IOI Journal donde los países participantes pueden publicar artículos sobre la olimpiada en general, tanto técnicos como reportes y explicaciones de cómo es la olimpiada alrededor del mundo. Dichas publicaciones se presentan durante la IOI, en la IOI Conference.

Este año México participó en el IOI Journal Volumen 8 con la presentación del paper de omegaUp:

omegaUp: Cloud-Based Contest Management System and Training Platform in the Mexican Olympiad in Informatics
L.H. CHÁVEZ, A. GONZÁLEZ, J. PONCE. 

El paper explica la motivación y el funcionamiento detrás de omegaUp. Es un buen documento introductorio para quienes deseen apoyar en el proyecto. También pone a omegaUp como pionero en el uso de la nube y seccomp-bpf para evaluadores de concursos en líneaEl resto de los papers publicados este año y en años pasados está aquí.

 

El nuevo ranking de omegaUp

Con este commit hemos introducido un cambio significativo en la forma de calcular el ranking general de omegaUp. Ahora no sólo es importante cuántos problemas ha resuelto un usuario sino que también estamos incluyendo la dificultad de cada uno de esos problemas. La dificultad es inversamente proporcional a la cantidad de soluciones completas (AC) que tiene ese problema.

Para ser más precisos, estamos definiendo los puntos que da un problema así: P_i = \frac{100}{log_2(N+1)}, donde N representa la cantidad de ACs que tiene un problema. Entre más ACs tenga un problema, menos puntos va a valer. Sólo estamos contando a lo más 1 AC por usuario para evitar que las soluciones de una misma persona afecten artificialmente los puntos de score del problema.

El score que usamos en el ranking esta dado por la suma de los puntos de todos los problemas que un usuario ha resuelto con AC.

Este nuevo sistema implica que los scores ahora son dinámicos: con cada problema que un usuario resuelva se va a afectar el score de otras personas que ya hayan resuelto el mismo problema anteriormente. La única manera de subir el score es resolviendo más problemas ya que, con el tiempo, el valor que otorga cada problema va a decaer.

También agregamos una columna en la lista de problemas disponibles, Puntos para ranking, que ayuda a los usuarios a saber qué problemas atacar y cuánto valen en este nuevo sistema. Es importante notar que el valor que se muestra es el actual: en el momento que resuelvas un problema, los puntos que otorga van a cambiar.

Qué te parece el nuevo sistema? Subiste o bajaste en el ranking? Déjanos tus dudas y sugerencias en los comentarios.

 

 

 

Aventuras en el evaluador, parte 1

Como parte de los propósitos de año nuevo, me dispuse a hacer un refactor masivo del código con el cual se evalúan y ejecutan las soluciones en omegaUp. Habían muchas motivaciones para hacer la actualización: tener un sandbox más moderno, eliminar un montón de código duplicado, mejorar las pruebas, el logging, el paralelismo en los jueces, cómo se despliega el tiempo y la memoria, el desempeño de los envíos, soportar C++11 y más lenguajes. Son muchísimos cambios, así que haré dos posts explicándolos: este post se centrará en los cambios que se hicieron en la arquitectura de jueceo y el siguiente se enfocará únicamente en el nuevo sandbox.

El primer cambio que se va a notar es que el servidor donde se hospeda la página principal ya no califica envíos! Gracias a nuestros queridos empleadores, conseguimos un par de máquinas virtuales gratuitas con Linux en Azure que se utilizarán exclusivamente para correr programas de los concursantes. Estas máquinas son menos poderosas que el servidor que usábamos antes, pero gracias a que el nuevo sandbox tiene muchísimo menos overhead, la diferencia será casi negligible. Una de las consecuencias de esto es que la página va a ser un poco más responsiva y los veredictos serán más rápidos. Esto también trae seguridad, porque aunque quisieran hacer trampa, ahora será casi imposible: las máquinas donde se ejecuta código de concursantes ya no son las mismas máquinas donde están las salidas esperadas :).

Otro cambio grande es la manera en la que se mide y reporta la memoria que consumen los programas. Antes la ejecución del programa se detenía cada cierto tiempo para poder medir exactamente cuántos bytes estaban siendo utilizados. Ahora para bajar el overhead del sandbox, la política de medición es mucho más laxa y sólamente se toman en cuenta los bytes de memoria privada del programa: esto excluye la librería de C estándar, el código ejecutable del programa, y algunas constantes. En Java, la manera en la que se establece el límite de memoria no cambió (así que cualquier envío que fuera MLE antes lo seguirá siendo), pero ahora para que se vea más bonito el reporte, se excluye de la cuenta la memoria ocupada por la máquina virtual de Java. Hablando de Java, la causa #1 de errores de compilación antes se reportaba como Runtime Error: usar un nombre de clase que no es “Main”. Ahora se reporta como error de compilación y se te indica que la clase se debe llamar Main.

Todos los runtimes y compiladores fueron actualizados. Ahora usamos GNU GCC 4.8, Java OpenJDK 7.0, Free Pascal 2.6, Ruby 1.9, Python 2.7, Glorious Glasgow Haskell Compiler 7.6 y Karel 1.1. Soportamos ahora sí todos los features de Java 7 (bienvenido sea el operador diamante), y agregamos la opción para compilar en C++11 (posiblemente en un futuro eliminemos la versión anterior de C++, gnu++03, cuando el soporte de C++11 sea lo suficientemente maduro).

El bug más feo que se arregló fue uno en el cual si habían más de 2 jueces conectados, únicamente se usaban dos, desperdiciando mucho tiempo y poder de cómputo. Esto únicamente ocurría durante concursos muy grandes, pero era bastante molesto para nosotros. También habían muchos errores con el manejo de la cola de espera, tanto de los jueces para poder compilar envíos, como la de los envíos que esperan un juez disponible. El resultado es que donde antes habían esperas de varios segundos, ahora aún en periodos donde la cola está llena las máquinas que juecean estarán esperando únicamente ~20 milisegundos entre envíos en lo que se les asigna algo para hacer.

Después de aproximadamente 80 commits en nuestros varios repositorios, espero que disfruten nuestra nueva y mejorada infraestructura (que en realidad debería ser totalmente invisible si hice bien mi trabajo).

Seguridad: IE en Windows XP

Debido a un reciente cambio para mejorar la seguridad de la conexión a omegaUp, hemos decidido dejar de soportar oficialmente IE en Windows XP, a pesar de que sabemos que aún sigue siendo el segundo sistema operativo más común a nivel mundial[1]. Si aún están obligados a usar Windows XP, por favor utilicen algún navegador moderno (Chrome, Firefox u Opera) o alguna versión portátil.

Para los interesados, el cambio consistió en hacer un par de optimizaciones para nginx[2], para reducir el tiempo de espera al primer byte, y actualizar la configuración de TLS: se quitaron SSLv2 y SSLv3 (que ya se consideran inseguros), se agregaron TLSv1.1 y TLSv1.2, se eliminó RC4 como algoritmo de cifrado, y ahora se prefiere ECDHE como algoritmo de intercambio de llaves para proveer Perfect Forward Secrecy[3].

Referencias

  1. Reporte NetMarketShare, Enero 2014:
  2. Optimizing NGINX TLS Time To First Byte (TTFB) – igvita.com
  3. Perfect Forward Secrecy – Wikipedia