Desmitificando – “El generador Java es difícil”

No es anormal encontrarse con usuarios GeneXus que le tienen “miedo” al generador Java.
Se cuentan historias terribles de usuarios que intentaron configurar y hacer funcionar un modelo Java web en la versión 9.0 de GeneXus y terminaron internados en el manicomio más cercano a su oficina.
Estas historias si bien nunca pudieron ser demostradas tienen su justificativo… Para lograr hacer funcionar un modelo Java web había que seguir los siguientes pasos:

• Configurar el camino al compilador Java
• Configurar el camino al interprete Java
• Configurar el camino al Make que seguramente uno no tenia instalado en su maquina por lo cual debía instalarlo previamente.
• Configurar el web application base URL.
• Agregar al classpath el driver JDBC
• Crear y configurar una web application en el servidor de servlets de su preferencia.
• Configurar las propiedades del modelo ‘servlet directory’, ‘static content base URL’, ‘static content directory seen from client’, teniendo en cuenta la web application previamente creada.
• Copiar gxclassr.zip y los archivos correspondiente al driver JDBC al dir lib de la web application previamente creada

Si alguna vez pasó por estos pasos y no es uno de los que fue internado seguramente sabe de lo que estoy hablando, si no tiene idea de lo que le estoy hablando seguramente la lista anterior le pareció lo suficientemente complicada o al menos extensa como para no intentarlo.

A pesar de fuertes presiones de parte de profesionales que obtenían grandes partes de sus ingresos dedicándose a configurar modelos Java a usuarios que no querían pasar por esa tortura; en la versión Rocha el configurar un modelo Java web es parte del pasado.

Veamos paso a paso como se fueron solucionados los distintos pasos de la configuración.

• Configurar el camino al compilador Java
• Configurar el camino al interprete Java
  Fácil, GeneXus se fija en el registry de Windows cual es el JDK de Sun mas nuevo que esta instalado en la maquina y se toma de ahí el compilador y el interprete.

• Configurar el camino al Make que seguramente uno no tenia instalado en su maquina por lo cual debía instalarlo previamente.
  Se empezó a usar un modelo de Make propio implementado por el archivo GXJMake.exe que viene con el generador, por lo cual ya no se tiene que configurar.

• Agregar al classpath el driver JDBC
  Se empezaron a distribuir con el generador drivers JDBC para los DBMSs que lo permiten. Los mismos están en el directorio drivers que esta bajo el directorio del generador. Todos los archivos que se encuentran ahí se agregan en forma automática al classpath, por lo tanto si el driver JDBC de su agrado no esta en esa lista, solo tiene que copiarlo ahí y se agregará en forma automática al classpath.

• Crear y configurar una web application en el servidor de servlets de su preferencia.
  Si el usuario tiene instalado en su maquina un tomcat 5.5 o superior toda esta configuración se hace en forma automática por parte de GeneXus, creando una web application con el nombre del modelo.

• Configurar el web application base URL.
• Configurar las propiedades del modelo ‘servlet directory’, ‘static content base URL’, ‘static content directory seen from client’, teniendo en cuenta la web application previamente creada.
• Copiar gxclassr.zip y los archivos correspondiente al driver JDBC al dir lib de la web application previamente creada
  Si se cumplió con el punto anterior de tener un tomcat 5.5 o superior todas estas configuraciones se hacen en forma automática teniendo en cuenta la web application creada por GeneXus previamente.

Resumiendo, en la versión Rocha de GeneXus si usted tiene un JDK de SUN instalado y un tomcat 5.5 o superior no tiene que configurar ninguna propiedad del modelo para poder prototipar usando el generador Java.

La crisis de Motorola

Si bien hace más de un año que se viene comentando sobre la crisis de la división de telefonía móvil de Motorola, yo personalmente me desayuné del tema hace poco.

Mi primera reacción fue la de incredulidad y luego me tiré a buscar en la red a ver si por algún lado se explicaba como podía ser que una empresa que supo estar en una posición tan cómoda del mercado ahora estuviera en problemas.

De todo lo que leí este artículo fue el que me pareció el más esclarecedor.
Si bien es un artículo bastante largo recomiendo su lectura a los que como yo esté interesado en ver como se fue dando la evolución de la actual crisis de la división de telefonía móvil de Motorola y cual podría ser su futuro.

http://www.mobile-review.com/articles/2008/motorola-strategy-fin-en.shtml

Día de compras… Sun compra MYSQL y Oracle compra BEA.

En el día de hoy se anunciaron dos compras… una mas esperada, la de BEA por parte de Oracle (8.5 billones de dólares), la otra mas inesperada (al menos por mi parte), la de MYSQL por parte de SUN (1 billón de dólares).

Oracle compra BEA
Sin querer ponerme en contra a nadie creo que el servidor de aplicaciones WebLogic de BEA es de los mejores del mercado y creo que el que tiene mas usuarios. Con la compra de BEA por parte de Oracle que pasará con WebLogic?... o mejor dicho que pasará con Oracle Application Server (competidor directo de WebLogic)?
Yo no creo que Oracle se quede con dos servidores de aplicaciones, pero con cual debería de quedarse?... Sin dudas una decisión complicada, si tuviera que apostar diría que de a poco irán matando al Oracle AS y le darán para adelante a WebLogic… El tiempo lo dirá.

Sun compra MYSQL.
Esta si que por ahora mucho no la entiendo… pero como no se nada de negocios no me extraña ;)
Pero si veo claras algunas cosas luego de este movimiento de Sun.
Creo que MYSQL sale fortalecido de esta venta, porque con el soporte de Sun atrás MYSQL será más considerado en ambientes empresariales.
A la vez con esto (de nuevo no me quiero poner en contra a nadie, así que fanáticos de PostgreSQL no me maten) creo que se le dio finalmente el golpe de gracia a PostgreSQL.
Además es de suponer que ahora Java estará mas pegado a MYSQL… que les parece un LAMJ en lugar de LAMP?... mmmm… creo que suena mas lindo LAMP ;)
Sun mas y mas se esta posicionando como una empresa de software que tiene el open source como bandera principal.

En definitiva, creo que es muy pronto para poder avizorar algo de estos movimientos pero seguro que van a traer cola.

El estado y su política informática.

En mis años de trabajo me ha tocado trabajar de una forma u otra en varias de las dependencias del estado, Ancap, Antel, Brou y BPS fueron algunas de ellas.Desde el comienzo siempre me chocó que no existiera una plataforma única de desarrollo. Cada dependencia desarrollaba sus sistemas usando distintas plataformas de desarrollo e incluso distintos motores de base de datos. Cada una ante un nuevo desarrollo hacia sus propias licitaciones y cada una seguramente tenia que estudiar por separado las distintas opciones presentadas que seguramente en mas de un caso serian las mismas. El conocimiento adquirido no era compartido entre ellas de ninguna forma. Las distintas dependencias del estado parecían trabajar por separado sin tener en cuenta que todas son parte de la misma “empresa” (el estado).

Siempre me pregunté porque no existía algo así como una agencia de informática del estado que brindara los lineamientos básicos que deberían cumplir los desarrollos a realizar en todas las dependencias del estado o por que no que se encargue de desarrollar todos y cada uno de los sistemas de cada una de las dependencias.
Lo veo como que dentro de una empresa en lugar de tener una única oficina de informática, cada área de la empresa (contaduría, recursos humanos, marketing, etc) tenga su propia área de informática y que cada una de esas áreas de informática tomen decisiones sobre las herramientas e interface grafica a usar para sus sistemas en forma independiente y que además no compartan el conocimiento entre ellos... un caos.

Estoy convencido que existiendo algo así como una única agencia de informática del estado haría que las cosas en cuanto a tecnología sean mucho mas eficiente, haría ahorrar mucho dinero al estado y por fin existiría una única política informática estatal. También estoy convencido que implementar algo así en el estado actual de las dependencias del estado es algo utópico, pero en este momento en el cual se esta hablando mucho en cuanto a reestructura del estado, por ejemplo en los impuestos y la salud, me pareció un momento propicio para escribir algo del asunto.
Además justamente hoy con el amigo Carriquiry en una reunión sobre otro tema el diálogo derivó hacia el tema de los sistemas del estado y cuando le exprese mi idea de una agencia única de informática me la critico un poco así que aprovecho a postearla acá a ver que opinan los lectores de este blog :)

Así da gusto!

Hace una semana que hemos liberado la beta 2 y sin lugar a dudas el equipo de desarrollo se merecía un festejo luego de trabajar tan arduamente para dicha liberación.
Fue así que sobre el viernes pasado con muy buen tino Mastro ofreció las instalaciones de su morada para realizar una reunión sobre el fin de semana. La idea sin dudas era muy buena, pero no tomó en cuenta el detalle de que hace varios fines de semana que veníamos trabajando, dejando de lado a la familia, por lo cual seguramente la gran parte de nosotros ya habíamos programado un fin de semana en familia. Fue así como casi todos fuimos cancelando la invitación por lo cual la reunión no se realizó.

De todas formas surgió otra propuesta que consistía en realizar un día de semana una reunión a la que dimos en llamar “pseudo-laboral” en la cual podíamos aprovechar para realizar el festejo de liberación de la beta 2 y además luego realizar la planificación de la RC y liberación de la Rocha.

Hoy fue el día de dicho evento!!!

Ya desde hace un par de días que lo veníamos preparando, se realizaría en el country Carmel (donde vive Mastro) que es un lugar ideal para realizar la parte “pseudo” de la reunión, léase jugar al tenis, bañarse en la piscina y porque no hacer algún fulbito. Surgieron algunos desafíos como el que realizaron Levin y Brown al tenis, apostando 3 kilos de masas para todo el grupo a ser abonadas por el perdedor del mismo.

Bien temprano fuimos arribando todos al country incluso algunos llegaron mas temprano de los que nos tienen habituados en un día de trabajo normal :).

De a poco cada uno se iba arrimando a realizar alguna actividad… Se podía ver al mismo tiempo un partido de truco, otro de “chin-chon”, partidos de tenis, de futbol y otros en la piscina.

Luego llego el momento del tan mentado desafío Levin-Brown. En realidad apenas empezaron los peloteos todos nos dimos cuenta que no era partido y que Levin iba a tener que pagar la apuesta sin lugar a dudas. Y fue así nomas, con un claro 6-1 Brown vapuleó al ahora deudor de 3 kilos de masas.

Llego la hora de la comida, todo muy bien organizado por Proto y Mastro. Sin dudas Proto ya nos demostró en reiteradas ocasiones (y esta fue una mas) que sabe lo que hace cuando se pone detrás de una parrilla. Nos deleito con un estupendo asado, cerdo, chorizo y morcillas por supuesto comprados en “su” Tienda Inglesa. La charla a la hora de la comida sin desperdicios, sobre todo cuando más de uno de los comensales dio cátedra sobre lo que es la noche montevideana y de otras ciudades locales y extranjeras.

Mientras degustábamos un rico heladito se empezó a preparar la parte laboral de la reunión.De esta parte no voy a contar mucha cosa, porque es secreto de estado :)…. Pero sin dudas tengo que mencionar la formidable siesta con ronquidos incluidos que se mandó Panizza mientras cada uno iba contando las cosas que para uno tenia que tener la versión liberada… eso si cuando llego su turno de hablar se despertó de una como por arte de magia.
Luego de varias horas de “amenas discusiones” sobre la planificación la reunión fue llegando a su fin.

Verdaderamente en días como el de hoy cuando uno baja las revoluciones se pone a pensar que tiene que estar agradecido a la vida por poder “trabajar” en lo que a uno le gusta y poder hacerlo en un ambiente laboral fuera de serie y con un grupo humano formidable.
Como dice el titulo de este post… Así da gusto!!!!

PD: Viste Brown que no puse nada sobre como te gane al tenis, no sea cosa que después digan que soy un baboso ;)

Recarga de webapplication en Tomcat

Tomcat es sin dudas uno de los motores de servlets mas usados para prototipar aplicaciones Java web generadas con Genexus.
Incluso en la versión Rocha GeneXus busca si está tomact instalado en la maquina de desarrollo y en caso de ser así realiza todas las configuraciones para que se cree en forma automática una webapplication con el nombre de la KB y se copie en forma automática todos los archivos para realizar la ejecución.
Muchas veces doy con personas que me cuentan que luego de estar un rato desarrollando en ese ciclo de implementación, ejecución, modificación y de nuevo ejecución notan que la memoria del tomcat se va a las nubes.
Este post intenta explicar porqué es que ocurre o puede ocurrir ese uso excesivo de memoria.

Una de las características que tiene tomcat es que usa una sola VM de Java para ejecutar todas las webapplication que existan dentro del mismo. Esto hace que cuando se baja, o se intenta recargar una webapplication no sea tan simple como bajar y subir una nueva VM, sino que se crea un nuevo classloader y se intenta liberar la memoria del classloader que antes era el encargado de ejecutar la webapplication. De esta forma si uno como programador no tiene cuidado puede dejar levantada toda la memoria del classloader si hay alguna de las clases que no puede ser liberada. Un caso muy común es programar usando singletons, en ese caso es seguro que cada vez que se baje o se reinicie la webapplication toda la memoria del classloader que maneja esa clase no va a ser liberada.
Como dije anteriormente este se ve acentuado sobre todo cuando se prototipa porque tomcat por defecto hace recarga de la webapplication cuando se mueve una nueva clase, entonces cada nueva clase que se mueve se suma toda la memoria del classloader que no pudo liberar.

Sobre todo para los usuarios GeneXus , que son los que mas leen este blog (eso espero ;)) es bueno saber que en las clases estándar del generador Java teníamos este problema porque hacíamos uso de algunos singletos. Ese comportamiento quedo solucionado a partir del U4 del generador Java de la versión 9.0 de GeneXus.

De todas formas puede pasar que la webapplication sigua sin liberar la memoria del classloader aunque se esta usando el U4 de Java. Generalmente las aplicaciones hacen uso de varias bibliotecas además de las clases estándar del generador… por ejemplo drivers JDBC o clases para el manejo de pdfs, etc. Si algunas de esta bibliotecas no libera sus clases entonces todo el classloader de esa webapp no se libera.
En ese caso la solución es copiar el jar o zip de esa biblioteca el directorio LIB general del tomcat en lugar del directorio LIB propio de la webapplication. Las clases que están en el LIB general del tomcat no se intenta “reciclar” cuando se reinicia una webapplication porque esas clases se cargan en otro classloader que es compartido por todas las webapplications.

Este último tip de copiar las bibliotecas que tienen este problema al LIB general del tomcat puede ser usado también en caso de estar usando las clases estándar de la versión anterior al U4 del generador Java. Eso si, en ese caso todas las webapplication GeneXus que están en el tomcat tienen que estar desarrolladas en la misma versión.

Gphone es en realidad Android

Hace tiempo que había rumores de que google estaba desarrollando un teléfono móvil, al cual se le llamaba GPhone.
Hoy nos enteramos que en realidad no era un aparato en lo que estaba google, sino que era una plataforma para teléfonos móviles a la cual llaman Android.
La plataforma es open source y tendría todo lo necesario para construir un teléfono celular. O sea no seria como dicen por ahí solo un sistema operativo para celulares basado en Linux que competiría con el Windows mobile.

Según dicen son mas de 34 compañías las que vienen trabajando en conjunto en este proyecto por más de 3 años, entre las cuales se encuentran Intel, Nividia, Motorola, LG, Samsung, Spring y T-Mobile.

Se esta anunciando el SDK para el 12 de Noviembre y los primeros apartitos basados en esa plataforma para la primera mitad del 2008.

No tengo dudas que esto será un éxito, considerando la pobreza general en términos de software que para mi tienen los teléfonos celulares hoy en día.
Y para todos los que alguna vez hemos intentado desarrollar aplicaciones para teléfonos móviles que tiene Java, seria un sueño vuelto realidad el tener una verdadera plataforma única en la cual algo que se desarrolla funcione de igual forma en todos los teléfonos que lo implementan.