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.
miércoles, 16 de enero de 2008
miércoles, 2 de enero de 2008
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 :)
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 :)
jueves, 13 de diciembre de 2007
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 ;)
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 ;)
miércoles, 21 de noviembre de 2007
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.
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.
lunes, 5 de noviembre de 2007
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.
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.
miércoles, 3 de octubre de 2007
GeneXus for dummies
Hace algún tiempo estaba junto a un gran amigo haciendo un asado en el fondo de casa. Solemos reunirnos regularmente junto con su mujer y su hijo que se lleva muy bien con mi niña.
Entre papitas, maníes y whisky la charla derivó al trabajo y en determinado momento hizo la pregunta que seguramente muchos de los que lean este post alguna vez escuchó por parte de un outsider … ¿Pero que es lo que hace a GeneXus algo único?
Si alguno se enfrentó a esa pregunta o alguna similar estará de acuerdo que no es algo fácil de explicar, por lo cual enseguida intenté pensar en alguna analogía que me permitiera trasmitir las bases de GeneXus a una persona que sabe poco y nada de computación. Esto es más o menos lo que me salió:
Los programadores para “escribir” las aplicaciones que usas en tu maquina utilizan lo que llamamos un lenguaje de programación. A los lenguajes de programación los podes ver como idiomas, por ejemplo chino, japonés, ingles, francés, etc. Digamos que para aprender a programar tienes que aprender un idioma en particular y aprender a usar las reglas sintácticas y semánticas de ese idioma.
En un determinado momento hay algunos idiomas que se puede decir que son los que están de moda y son los más usados por los programadores; pongamos por ejemplo el inglés y el chino. El problema es que cada cierto tiempo esos idiomas se vuelven obsoletos y los programadores necesitan empezar a utilizar otros idiomas para poder escribir sus aplicaciones, por ejemplo japonés y francés. Esto trae muchos problemas claros a los programadores, pero los más importantes son:
· Se necesita aprender los nuevos idiomas.
· Se necesita reescribir toda la aplicación del chino al japonés por ejemplo.
La idea es que Genexus propone otro idioma al cual podríamos llamar esperanto. Internamente además GeneXus tiene un traductor que permite traducir del esperanto a los leguajes más usado en el momento, por ejemplo inglés y chino. A su vez GeneXus garantiza a sus usuarios que a medida que vayan saliendo nuevos idiomas realizará nuevos traductores del esperanto a esos nuevos idiomas.
Con esto GeneXus resuelve los problemas que había mencionado anteriormente:
· Solo se necesita saber un idioma… el esperanto
· No se necesita reescribir toda la aplicación cuando se quiera tener el programa en uno de los nuevos idiomas.
Adicionalmente el esperanto es un idioma mucho mas fácil de aprender y en el cual hay que escribir muchas menos palabras para expresar una idea.
Por ejemplo para “describir” un automovil en un idioma al cual podríamos llamar español hay que escribir algo así :
· Un auto es un vehículo que se impulsa mediante un motor que usa combustible. Tiene una caja de cambios, un caño de escape, frenos, embrague, volante, velocímetro, cuenta kilómetros, etc….
En esperanto (el idioma de GeneXus) esto lo podríamos describir como:
· Un auto es un vehículo para transportar personas de un lugar a otro.
Esto luego por medio del traductor GeneXus al español se traduce a lo escrito en primer lugar.
Hasta acá notaba que mi amigo escuchaba atentamente, pero en realidad seguramente estaba mas preocupado en que no se quemaran los chorizos y estaría pensando para que caramelos habré hecho esa maldita pregunta… Yo mientras tanto pensaba que más o menos había explicado la multiplataformidad y facilidad de programación de GeneXus… me falta explicar las reorganizaciones y estoy cumplido. …
Pensé, pensé, pero no se me ocurría ninguna analogía para explicar las reorganizaciones sin confundir a mi interlocutor y teniendo en cuenta que ya hace un rato que estaba hablando y si lo seguía haciendo iba a dejar todo el asado quemado la deje por ahí.
Pregunte entonces… entendiste mas o menos?Si, si dice mi amigo…. Los chorizos ya están prontos no?... dijo mi amigo como para cambiar de tema.
Pa… este loco no entendió nada, pensaba para mí. Fue ahí cuando me dice… Che, lo que seria una pegada seria poder hacer un traductor de alguno de los idiomas de moda a esperanto no? así podes hacer que esa gente que no usaba GeneXus pueda pasar sus aplicaciones a lo nuevos idiomas y ya quedan enganchados con GeneXus.
Sin lugar a dudas mi amigo es una persona muy inteligente! :)
Entre papitas, maníes y whisky la charla derivó al trabajo y en determinado momento hizo la pregunta que seguramente muchos de los que lean este post alguna vez escuchó por parte de un outsider … ¿Pero que es lo que hace a GeneXus algo único?
Si alguno se enfrentó a esa pregunta o alguna similar estará de acuerdo que no es algo fácil de explicar, por lo cual enseguida intenté pensar en alguna analogía que me permitiera trasmitir las bases de GeneXus a una persona que sabe poco y nada de computación. Esto es más o menos lo que me salió:
Los programadores para “escribir” las aplicaciones que usas en tu maquina utilizan lo que llamamos un lenguaje de programación. A los lenguajes de programación los podes ver como idiomas, por ejemplo chino, japonés, ingles, francés, etc. Digamos que para aprender a programar tienes que aprender un idioma en particular y aprender a usar las reglas sintácticas y semánticas de ese idioma.
En un determinado momento hay algunos idiomas que se puede decir que son los que están de moda y son los más usados por los programadores; pongamos por ejemplo el inglés y el chino. El problema es que cada cierto tiempo esos idiomas se vuelven obsoletos y los programadores necesitan empezar a utilizar otros idiomas para poder escribir sus aplicaciones, por ejemplo japonés y francés. Esto trae muchos problemas claros a los programadores, pero los más importantes son:
· Se necesita aprender los nuevos idiomas.
· Se necesita reescribir toda la aplicación del chino al japonés por ejemplo.
La idea es que Genexus propone otro idioma al cual podríamos llamar esperanto. Internamente además GeneXus tiene un traductor que permite traducir del esperanto a los leguajes más usado en el momento, por ejemplo inglés y chino. A su vez GeneXus garantiza a sus usuarios que a medida que vayan saliendo nuevos idiomas realizará nuevos traductores del esperanto a esos nuevos idiomas.
Con esto GeneXus resuelve los problemas que había mencionado anteriormente:
· Solo se necesita saber un idioma… el esperanto
· No se necesita reescribir toda la aplicación cuando se quiera tener el programa en uno de los nuevos idiomas.
Adicionalmente el esperanto es un idioma mucho mas fácil de aprender y en el cual hay que escribir muchas menos palabras para expresar una idea.
Por ejemplo para “describir” un automovil en un idioma al cual podríamos llamar español hay que escribir algo así :
· Un auto es un vehículo que se impulsa mediante un motor que usa combustible. Tiene una caja de cambios, un caño de escape, frenos, embrague, volante, velocímetro, cuenta kilómetros, etc….
En esperanto (el idioma de GeneXus) esto lo podríamos describir como:
· Un auto es un vehículo para transportar personas de un lugar a otro.
Esto luego por medio del traductor GeneXus al español se traduce a lo escrito en primer lugar.
Hasta acá notaba que mi amigo escuchaba atentamente, pero en realidad seguramente estaba mas preocupado en que no se quemaran los chorizos y estaría pensando para que caramelos habré hecho esa maldita pregunta… Yo mientras tanto pensaba que más o menos había explicado la multiplataformidad y facilidad de programación de GeneXus… me falta explicar las reorganizaciones y estoy cumplido. …
Pensé, pensé, pero no se me ocurría ninguna analogía para explicar las reorganizaciones sin confundir a mi interlocutor y teniendo en cuenta que ya hace un rato que estaba hablando y si lo seguía haciendo iba a dejar todo el asado quemado la deje por ahí.
Pregunte entonces… entendiste mas o menos?Si, si dice mi amigo…. Los chorizos ya están prontos no?... dijo mi amigo como para cambiar de tema.
Pa… este loco no entendió nada, pensaba para mí. Fue ahí cuando me dice… Che, lo que seria una pegada seria poder hacer un traductor de alguno de los idiomas de moda a esperanto no? así podes hacer que esa gente que no usaba GeneXus pueda pasar sus aplicaciones a lo nuevos idiomas y ya quedan enganchados con GeneXus.
Sin lugar a dudas mi amigo es una persona muy inteligente! :)
domingo, 30 de septiembre de 2007
Medir, ajustar, monitorear.
Acá viene mi primer post técnico…
Sobre el final del cara a cara de java del último evento recomendé a los asistentes el uso de JMX. Una vez fuera de la sala una asistente me preguntó si tenía algo escrito sobre JMX en mi blog. Mi respuesta con un poco de verguenza…. “No tengo blog”.
Internamente me prometí que cuando empezara mi blog uno de los primeros post iba a ser sobre JMX en GeneXus y aquí estamos.
JMX (Java Management eXtensions) es una tecnología que permite monitorizar y administrar aplicaciones hechas en Java. Sobre .NET existe algo similar llamado WMI.
GeneXus hace uso de esa tecnología para hacer dos tipos de cosas en las aplicaciones generadas: Monitorear y medir la performance general.
Cuando estamos hablando de medir la performance general nos referimos a lo siguiente:
Encontrar las sentencias SQL que se ejecutan mas veces, las que tienen peor tiempo promedio, las que ocupan mas tiempo total de la aplicación, etc.
A la vez permite encontrar medidas similares para el caso de procedimientos.
Mi recomendación siempre es la de hacer un stress test antes de poner una aplicación en producción y sobre ese stress test analizar las medidas que nos tira JMX. De esa forma podemos analizar las sentencias SQL mas problemáticas y podemos realizar alguna tarea en el DBMS, o cambiar el código GeneXus para que la sentencias generada sea mas eficiente o porque no? usar cache de datos sobre esa tabla en caso de ser posible.
Como dije anteriormente lo otro que nos permite el uso de JMX en GeneXus es el monitorear el comportamiento de la aplicación.
A diferencia de la parte de performance que claramente es una tarea para hacer antes de poner una aplicación en producción, la tarea de monitoreo es sobre todo una operación para realizar sobre producción.
Entre las cosas que se pueden monitorear están, el uso del pool de conexiones, el estado de cada una de las conexiones a la base de datos, el estado del cache de datos, etc.
Además se pueden realizar operaciones en caliente sin tener que bajar la aplicación, como ser aumentar el tamaño del pool de conexiones o matar alguna conexión problemática.
A modo de ejemplo un posible caso de uso podria ser el encontrar un loqueo en la aplicación. Podriamos por ejemplo ver en el DBMS cuales son las conexiones que estan loqueadas, luego ir a buscar esas conexiones en JMX, y ver cada una de las conexiones cual es la sentencias que esta ejecutando y cual es el procedimiento que esta ejecutando esas sentencias. Eso tal vez nos permita encontar un posible error de programación.
Adicionalmente JMX permite el programar “alarmas”. Esto quiere decir disparar alguna acción como por ejemplo mandar un mail o un SMS a algún administrador en caso de que alguno de los medidores este dando un valor no deseado, por ejemplo que haya contención en el pool de conexiones o que alguna sentencia SQL fundamental en la aplicación este dando tiempos no esperados.
Todo lo anterior pretendió ser una explicación “marketinera” sin ir al detalle de la implementación, ni de su configuración en GeneXus, sino más bien para incitar a los desarrolladores de aplicaciones GeneXus a su conocimiento y su uso.
Los detalles para su uso los pueden encontrar en esta dirección:
http://wiki.gxtechnical.com/commwiki/servlet/hwiki?Application+Monitoring+and+Management%3A+using+a+JMX+or+WMI+monitor,
Sobre el final del cara a cara de java del último evento recomendé a los asistentes el uso de JMX. Una vez fuera de la sala una asistente me preguntó si tenía algo escrito sobre JMX en mi blog. Mi respuesta con un poco de verguenza…. “No tengo blog”.
Internamente me prometí que cuando empezara mi blog uno de los primeros post iba a ser sobre JMX en GeneXus y aquí estamos.
JMX (Java Management eXtensions) es una tecnología que permite monitorizar y administrar aplicaciones hechas en Java. Sobre .NET existe algo similar llamado WMI.
GeneXus hace uso de esa tecnología para hacer dos tipos de cosas en las aplicaciones generadas: Monitorear y medir la performance general.
Cuando estamos hablando de medir la performance general nos referimos a lo siguiente:
Encontrar las sentencias SQL que se ejecutan mas veces, las que tienen peor tiempo promedio, las que ocupan mas tiempo total de la aplicación, etc.
A la vez permite encontrar medidas similares para el caso de procedimientos.
Mi recomendación siempre es la de hacer un stress test antes de poner una aplicación en producción y sobre ese stress test analizar las medidas que nos tira JMX. De esa forma podemos analizar las sentencias SQL mas problemáticas y podemos realizar alguna tarea en el DBMS, o cambiar el código GeneXus para que la sentencias generada sea mas eficiente o porque no? usar cache de datos sobre esa tabla en caso de ser posible.
Como dije anteriormente lo otro que nos permite el uso de JMX en GeneXus es el monitorear el comportamiento de la aplicación.
A diferencia de la parte de performance que claramente es una tarea para hacer antes de poner una aplicación en producción, la tarea de monitoreo es sobre todo una operación para realizar sobre producción.
Entre las cosas que se pueden monitorear están, el uso del pool de conexiones, el estado de cada una de las conexiones a la base de datos, el estado del cache de datos, etc.
Además se pueden realizar operaciones en caliente sin tener que bajar la aplicación, como ser aumentar el tamaño del pool de conexiones o matar alguna conexión problemática.
A modo de ejemplo un posible caso de uso podria ser el encontrar un loqueo en la aplicación. Podriamos por ejemplo ver en el DBMS cuales son las conexiones que estan loqueadas, luego ir a buscar esas conexiones en JMX, y ver cada una de las conexiones cual es la sentencias que esta ejecutando y cual es el procedimiento que esta ejecutando esas sentencias. Eso tal vez nos permita encontar un posible error de programación.
Adicionalmente JMX permite el programar “alarmas”. Esto quiere decir disparar alguna acción como por ejemplo mandar un mail o un SMS a algún administrador en caso de que alguno de los medidores este dando un valor no deseado, por ejemplo que haya contención en el pool de conexiones o que alguna sentencia SQL fundamental en la aplicación este dando tiempos no esperados.
Todo lo anterior pretendió ser una explicación “marketinera” sin ir al detalle de la implementación, ni de su configuración en GeneXus, sino más bien para incitar a los desarrolladores de aplicaciones GeneXus a su conocimiento y su uso.
Los detalles para su uso los pueden encontrar en esta dirección:
http://wiki.gxtechnical.com/commwiki/servlet/hwiki?Application+Monitoring+and+Management%3A+using+a+JMX+or+WMI+monitor,
Suscribirse a:
Entradas (Atom)
