El proceso de registro en JavaOne

Hola a todos,

Para no redundar en lo mismo, les dejo el enlace a mis impresiones sobre JavaOne del 2008. La experiencia fué realmente interesante.

• Nuevo progresos con JavaFX y el nuevo plugin del JDK para los browser
• OpenJDK

Yo voy a estar el Lunes en el Java University, metiendome un puñal en JavaFX y Swing. Si el tiempo lo permite colocaré algunas de mis impresiones sobre la conferencia.

¡Lo cierto es que ando más emocionado que muchacho comiendo moco! :)

Debido a que los cupos son limitados y no todos en la oficina pueden ir de gratis :-(, estoy tratando de optar por una entrada vía el concurso de to2blogs (Como dice Aníbal: “Las probabilidades de que ganes la entrada aumentan exponencialmente si participas”). Si se alinean los planetas y me gano la entrada, espero que Negroponte pueda mencionar sus experiencias en la identidad digital en la Web, pudiera incluso citarlo en la presentación del TEG.

Amanecerá y veremos.

Al trabajar sobre las fechas en los Form Helpers de Rails, hemos conseguido un bug bastante peculiar, tiene mucho que ver con el uso de los helpers para crear varios elementos de una misma clase de Objetos; este consiste incialmente en colocar un par de corchetes ([]) alrededor del nombre del objeto que queremos crear, de esta forma podemos enviar multiples objetos de una vez en el request del Navegador.

Por ejemplo, cuando tenemos el siguiente codigo en un archivo rhtml (en Rails 2.0 sería html.erb)

Esto dibujaría un HTML de la siguiente forma:

Si se dan cuenta, pueden ver que los selects generados no poseen los [] en el nombre, de hecho los ignora por completo. Esto trae como consecuencia de que cuando se cree el objeto de Persona vía mass-assignment

se genere un error difícil de detectar en el código de nuestro proyecto. Después de "googlear" un poco, me di cuenta que es un bug registrado desde hace 2 versiones, por suerte conseguí un patch que me sirvio perfectamente para solucionar este problema.

Les dejo el link del ticket en caso de que lo necesiten:
http://dev.rubyonrails.org/ticket/10551

Mongrel es un webserver escrito en Ruby, donde los cuellos de botella fueron optimizados en lenguaje C. Es pequeño, ligero y sencillo de usar.

Basado en el mismo parser de Mongrel, pero usando Ruby/EventMachine (Ruby y C++) para acelerar la parte del I/O a nivel de redes y Rack para la interface con los frameworks crearon Thin.

¿El beneficio? Consistentemente maneja los requerimientos HTTP más rápido, en mis pruebas informales efectivamente se puede hablar consistentemente de entre un 15% y un 25% de mejora en los tiempos dependiendo del escenario.

Ya algunos desarrolladores hicieron unas pruebas en producción en sitios pequeños, encontraron un bug en el parsing de los headers HTTP que llevó al release de la versión 0.5.1 (LOLCAT) que además incorpora compatibilidad con Ruby 1.9.

Si están usando Ruby on Rails y quieren probarlo es tan sencillo como:

Y ejecutan en la raíz de su aplicación Rails:

O si quieren que tome el ambiente de producción para hacer benchmarks:

Con Monit monitoreo consumo de recursos, carga sobre el servidor, conectividad y estado de archivos en filesystem. La herramienta es bien útil y fácil de configurar.

¿Qué no me gusta de Monit? Que en el caso de monitorear por ejemplo un clúster de Mongrels, hay repetir toda la configuración para cada instancia y hay cosas que es difícil (sino imposible) expresar mediante los archivos de configuración de Monit.

Intentando instalar Monit en Debian Etch en un VPS me topé con el error:

El bug debería estar resuelto en la versión 4.8.1 sin embargo no le encontré la vuelta, y es que tampoco se la busqué mucho porque estaba loco por probar God: like monit, only awesome, así que decidí probarlo.

Lo primero que hay que decir es que aún le falta, lo que es lógico siendo una versión 0.6, sin embargo funciona perfectamente.

Una de las primeras cosas que extrañé fue que no tuviera soporte para una condición (Condition) que me permitiera monitorear si el código de una respuesta HTTP sobre un URL determinado era diferente de un 200 OK. Sin embargo, lo que si provee en esta versión es la habilidad de expresar una condición a través de una función anónima (lambda).

De esta forma ni siquiera tenemos que extender los Conditions que provee Godpara agregar uno que acepte un URL y un código de respuesta HTTP esperado, sino que sencillamente podemos pasar el bloque de código que será evaluado para determinar si el proceso monitoreado debe ser reiniciado o no.

En mi caso además quería asegurar que la respuesta se diera en menos de un segundo, y al final quedó algo como esto:

La gran ventaja que tiene God, sobre Monit es que se le saca el jugo a Ruby para poder expresar que es lo que vamos a monitorear, qué acciones vamos a tomar y bajo que condiciones.

Como les comenté sólo es una versión 0.6, y aún hay mucho por hacer, pero es Ruby así que siempre lo pueden extender fácilmente para conseguir lo que ustedes quieran.

Desde hace varios meses la gente se preguntaba dónde estaba la aplicación que soportara el uso de OpenID, al parecer esta es.

Sin embargo me parece bien interesante que Darcs 2 empiece a asomarse al ruedo con un primer prerelease, que apunta a ofrecer mejoras sustanciales a este SCM.

Entre las mejoras que estarán a prueba, están el nuevo formato "hashed" del repositorio que previene ciertos problemas y optimiza algunas operaciones, particularmente con soporte para caché de los patches.

El algoritomo que maneja los merges previene que Darcs se quede "pegado" intentando resolver conflictos, adicionalmente hay un cambio fuerte relacionado con la semántica de patches idénticos y la forma en que las dependencias contra estos se resuelven.

Como decimos en Venezuela, "amanecerá y veremos", ya que aún es temprano para saber el impacto real de estos cambios.

Nginx es popular actualmente como frontend o load balancer para clusters de Mongrels corriendo aplicaciones Ruby On Rails. Realmente funciona, después de que uno lo instala y los configura puede olvidarse de él.

Mucha gente termina montando Nginx desde los fuentes porque la versión de Nginx en stable en stablees la 0.4.13 es relativamente vieja* y el sistema de administración de paquetes de Debian es algo así como el "secreto mejor guardado del Caribe".

De cualquier manera si quiere instalar la versión 0.5.30 o la 0.5.33, estas están disponibles en testing y sid respectivamente, no tienen que hacerlo desde los fuentes.

Cortesía de Jose, las instrucciones para seguir el paquete desde testing son:

Crear o agregar al archivo /etc/apt/preferences:

Agregar los repos de testing en /etc/apt/sources.list, en general sencillamente tomen los que apuntan a etch, los copian y reemplazan etch por testing o sid si fuera el caso. En la máquina que yo estaba instalando:

Y finalmente:

En general esto les va a requerir nuevas versiones de libc6, libssl, locales, tzdata y un par de librerías más, que pueden requerir de reiniciar un par de serivicios.

* En realidad no es que sea vieja, es que los rusos echan código como locos ;-)

IBM: +1
http://www.ibm.com/developerworks/java/jdk/dst/index.html

Microsoft: +1
http://www.nuevahoravenezolana.com/

Red Hat/Fedora: +1
https://bugzilla.redhat.com/show_bug.cgi?id=410101

Sun Microsystems: 0
http://java.sun.com/javase/timezones/

Algunos se preguntarán por qué a Sun no le doy puntos, y es sencillo, lamentablemente para obtener su fix para Java necesitas llamar al Centro de Soporte Técnico, cosa que hice de inmediato, para simplemente obtener la respuesta de que necesito tener un contrato de soporte y si quería tener contacto con un vendedor para tratar el tema.

Pero no se preocupen, la idea de esta entrada en este blog es la de dar soluciones y no solo quejarme :-P. La última versión disponible en el sitio de Sun de la herramienta de update es la versión 1.3.0 que no incluye el cambio de Venezuela del pasado 9 de diciembre, y como la licencia de la herramienta prohíbe explícitamente la ingeniería reversa, simplemente busque otro camino. Desde hace un poco más de un año Sun empezó el proceso de convertir Java en Software Libre, y la primera distribución en incluir parte de lo que será Java 7 es Fedora (llamada IcedTea), recurrí al código fuente de este localizado en los mirrors de Fedora

Tras examinar el proceso de build, se puede notar que al igual que en Linux/Unix se utiliza el comando zic para trasformar la base de datos Olson de Zonas horarias, en OpenJDK hay un programa Java en openjdk/j2se/make/tools/javazic que realiza la misma tarea pero generando el formato específico para los JVM de Sun. Utilizando este compilador y usándolo con el archivo southamerica localizado en la base de datos Olson más reciente, se generan una serie de archivos, del cual nos interesa es America/Caracas, el cual puede sustituir a $JAVA_HOME/jre/lib/zi/America/Caracas (Este cambio fue probado en JVM de Sun 1.6.x)

Ahora, por qué 0 puntos es vez de -1, porque gracias a OpenJDK fue fácil realizar este cambio, de alguna manera u otra Sun ayudó a que fuese posible, El poder del Software Libre en acción.

NOTA: antes de que pregunten :-P ¿por qué Java requiere tener la base de datos internamente y no usar la del OS?, sencillo, no todas los sistemas operativos incluyen APIs para obtener la zona horaria que incluya el histórico de los cambios, por ejemplo, El fix de Windows solo incluye una nueva zona horaria al sistema, pero no lleva un histórico de que Venezuela estaba a -4:30 de UTC antes del año 1965, Windows solo tiene información del offset con UTC actual, en cambio las APIs de Java permiten hacer transformaciones de Zona horaria para cualquier fecha y hora. Por esta razón aplicaciones como Ms Office deben ser actualizadas por separado.

De todos modos he añadido un Bug a Fedora a ver si es posible hacer que IcedTea pueda usar una base de datos externa o en lo posible separar los archivos que vienen dentro de IcedTea al RPM de tzdata de tal forma de que el cambio sea centralizado. https://bugzilla.redhat.com/show_bug.cgi?id=418101

El archivo "Caracas" lo pueden conseguir en:

http://www.marcanoonline.com/downloads/java/zi/Caracas