Después de levantarme el miércoles 15 de Diciembre a las 5 de la mañana para poder coger el vuelo a Madrid desde Santiago de Compostela, llegué a la capital a eso de las 8:30 de la mañana. Después de hablar con Abraham, uno de los organizadores del evento, por teléfono, me comenta que la mejor forma de llegar a Móstoles es a través de Metro, bajando desde Barajas hasta Móstoles, un trayecto que dependiendo de como se cojan los enlaces de líneas de metro lleva una hora y unos 15 minutos. Una vez en Móstoles me dirijo a la Universidad Rey Juan Carlos, donde se celebraba el segundo congreso de JavaHispano. El campus universitario de la Universidad Rey Juan Carlos daba la impresión de que se había construido hace poco, todo parecía bastante nuevo, sin que los alumnos tuviesen mucho tiempo de destrozarlo un poco. Una vez en el recinto universitario busco el edificio donde se celebra el congreso, el cual estaba marcado con una enorme pancarta.
Lo primero que hago es inscribirme, para ello enseño mi código de barras y me dan una tarjeta de identificación con mi nombre más código de barras junto con una cinta para llevarla colgada del cuello y el programa del evento, al mismo tiempo la gente de la organización me comenta que todavía no tienen listas las bolsas de regalo por asistir al congreso, pero que por la tarde ya podría solicitarlas simplemente enseñando mi tarjeta de identificación. Como ya eran las 10:30 y las charlas ya envían empezado, decido meterme en la primera puerta que vea para empezar a ver que se iba a hablar en este congreso. Me sorprendió un poco el control que hacían cada vez que entrabas y salías de una conferencia, puesto que tenías que enseñar tu tarjeta con el código de barras, supongo que sería para hacer estadísticas para ver que conferencias fueron las que realmente interesaban a la gente.
Resulta que me entré en una conferencia que daba uno de los empleados de la compañía Borland, y que se titulaba: «Auditoría estática y dinámica de código Java». El empleado de Borland (lo siento, pero no llegue a tiempo para oír su nombre), estaba hablando sobre distintas herramientas de Borland para evaluar el rendimiento de diverso código Java, ya sea en su fase de ejecución, como analizando el propio código. Comentó que dichas herramientas estaban tanto preparadas para ser usadas en su entorno de programación, JBuilder o para el proyecto Eclipse. También habló un poco de una buena política de programación, recomendó el uso de test unitarios para cercioranos desde el comienzo que el código va funcionar y que no hay que andar preocupándose desde el principio en la optimización del código, sino, dejarlo para momentos concretos, lo cual dará lugar a un código mucho más limpio y legible.
Durante la conferencia de Borland revisé el horario de conferencias y me dí cuenta que me perdí la conferencia de mi amigo y compañero de trabajo Abraham Otero Quintana, que estaba dando su charla al mismo tiempo que los de Borland, desde aquí pedirle disculpas por ese despiste mio, realmente tenía intención de ir a su charla. A las 11:00 me cambié de sala, después de pasar por los oportunos chequeos de códigos de barras, para asistir a otra conferencia de una empresa relacionada con el mundo de Java, en este caso Bea, titulada: «Apache Beehive. Desarrollo rápido de aplicaciones J2EE».
Nada más entrar en la sala de conferencias nos «asaltaron» la gente de marketing de Bea, regalándonos un bolígrafo y un cuestionario, que amablemente nos pidieron que cubriésemos. Uno de sus ingenieros (creo que era ingeniero), Sergio Álvarez, fue el encargado de hablarnos del proyecto open source Apache Beehive. El responsable de Bea nos aclara que Apache Beehive es la respuesta a varias críticas y necesidades que tenía su compañía. Una de las críticas era que Bea no colaboraba con la comunidad Open Source, lo cual hacen ahora con este proyecto. Por otro lado, necesitaban algo que hiciese más fácil la programación de proyectos J2EE, cuya dificultad en algunas ocasiones, hacen que la gente opte por alternativas menos potentes pero más fáciles de implementar, como la plataforma .Net de Microsoft. También, moviendo Apache Beehive a Open Source conseguían evitar tener que esperar al JCP a que optase o no por su propuesta, haciendo así que la comunidad se moviese hacia una alternativa concreta como ha sucedido con el caso de Hibernate (bueno, el no nombró Hibernate, este es un ejemplo mío para ilustrar el problema). Ya centrándonos en Apache Beehive, comentó que esta compuesto de 4 componentes:
- Presentación: La parte de presentación está basada en Struts, todo esto usando anotaciones y metadatos (JSR-175).
- Web Services: Esta hace uso de las anotaciones definidas en el estándar JSR-181.
- Java Controls: Para acceder a APIs y recursos externos de forma sencilla (ej: a una base de datos).
- XML Beans: Esto realmente es un proyecto independiente de Apache, Apache Beehive lo usa para procesar toda la información almacenada en formato XML.
Por otro lado, comenta que Bea considera ahora que Apache Beehive es un proyecto independiente y que progresará según la Apache crea necesario, y, que ellos darán soporte a Apache Beehive en sus servidores de aplicaciones y herramientas de desarrollo, añadiendo aquellas cosas que ellos consideren oportunas para dar más valor a sus productos. Por otro lado, también comentan que para desarrollar con Apache Beehive no hace falta productos de Bea y para ello ponen como ejemplo el proyecto aun no acabado: Eclipse Pollinate. Por otro lado animan a cualquiera a colaborar, ya sea programando, usándolo o reportando bugs. Al final de la charla, a los que cubrimos el formulario se nos regaló una grapadora y un mechero, ambos con el logotipo de Bea, y a las tres personas que hicieron preguntas, se les regalo un kit de evaluación de productos de Bea, que debía pesar lo suyo.
Después de esta segunda cha
rla se produce un descanso, lo cual también fue bastante importante, en esos momentos yo tenía bastante hambre, dado que había desayunado a las 5:00 de la mañana. Al terminar el descanso procedo a ir a mi tercera charla de la mañana: «Integración continua utilizando herramientas open source», la cual es impartida por Jesús Pérez, miembro del Agile Software Development User Group Spain. El ponente nos introduce en el concepto de desarrollo a través de integración continua y de diversas herramientas open source para lograr dicho objetivo. La integración continua intenta resolver problemas habituales en el desarrollo de un proyecto, tales como: «En mi máquina funciona» (en el momento que se lo enseñas al cliente en su máquina de producción y el programa no actual como era esperado), «Fecha final del proyecto impredecible», «Imposibilidad de repetir instalaciones», «Despliegues costosos por la necesidad de incorporación de procesos manuales», «Constante repetición de las pruebas de forma manual». La idea de la integración continua es ir desarrollando el software en todo momento dentro de un entorno real, donde dicho software será testeado a través de test unitarios automáticos. El ponente afirma que siguiendo este proceso de desarrollo se mejoran los siguientes procesos de un proyecto: «Identificación de fallos mucho más pronto», «Minimiza la búsqueda de fallos colaterales» (Usualmente de la integración de distintas partes del proyecto desarrolladas por distintos equipos o del despliegue posterior en la máquina de producción), «Minimiza el ciclo de pasar de desarrollo al entorno de producción» y da más «Confianza en el código desarrollado».
Para poder conseguir el objetivo de integración continua, Jesús Pérez nos introduce una serie de herramientas que usan ellos en la compañía que trabaja. Los objetivos a conseguir con dichas herramientas son los siguientes: «Control de Versiones», «Pruebas automatizadas» y «Proceso de construcción automatizado». Introduce la necesidad de usar un buen programa de Control de Vesiones (CVS), lo cual es imprescindible para proyectos que se ponen continuamente en producción, dado que nos permite ver fácilmente los cambios introducidos en el desarrollo así como la creación de diferentes líneas de desarrollo de un mismo programa. Como servidor CVS nos recomienda Subversión, especialmente por su control de ramas de desarrollo (como nota personal decir que cada vez estoy escuchando buenos comentarios de este programa y lo cual hace que cada vez tenga más ganas de probarlo). Después de el CVS comentó sobre la necesidad de crear pruebas automatizadas, para ello recomienda el uso de Test-Driven Development (TDD). Aplicar TDD no es tan fácil como parece, dado que implica bastantes cambios en la metodología que la gente suele usar para programar, pero los beneficios son obvios. Como utilidades para realizar TDD comentó varias, empezando por JUnit, Easymock, StrutsTestCase, MockObjects, DBUnit, Cactus, HTTPUnit, Canoo WebTest y JUnitPerf. Otro de los aspectos importantes de la integración continua es la automatización de procesos, lo cual añade las ventaja de hacer el sistema portable a distintas plataformas (sin tener que depender de un IDE concreto). Por supuesto, para desarrollar esta tarea se habla de Apache Ant. Para la automatización de tareas también menciona Apache Maven, el ponente comenta que esta última utilidad se construye sobre Apache Ant para ofrecernos implementación de alto nivel sobre los temas de un proyecto. Y como joya de la corona, nos presenta el proyecto: CruiseControl. CruiseControl es un framework para integración continua; a través de un fichero de configuración XML se puede programar a CruiseControl para que utilizando la última versión del programa que existe en el CVS se pasen todos los test de forma periódica, que informe de los resultados a través de una interfaz web, que envíe mensajes (e-mail, mensajería instántanea, semáforos…) de si la actual versión del programa del CVS pasa todos los tests, si alguien introduce un cambio que produce fallos, notificar al programador correspondiente y darle la lata hasta que lo solucione.
El ponente, Jesús Pérez, aporta los siguientes consejos para los equipos que desarrollo que quieran implementar esta politica: obviamente, la introducción de este tipo de sistemas de desarrollo debe hacerse de forma gradual, o la gente no se adapta a ellos. Asumir que nunca va a existir un buen momento para introducirlos, por que cuanto antes se introduzcan mejor. Obviamente la introducción de estas políticas de programación también presenta sus problemas, hay que crear una cultura de pruebas lo cual nunca es fácil y automatizar algunas partes del desarrollo puede que sea complicado. Al mismo tiempo recomienda que si se introduce esta polítca de desarrollo, es recomendable no introducir nada nuevo en el CVS si CruiseControl informa que todavía hay errores sin resolver, especificar un tiempo máximo que se puede seguir desarrollando sin solventar un error. Obviamente tiene que haber un responsable que se encargue de supervisar el proceso de integración continua. Al final concluye que la integración continua permite crear grupos de desarrollo mucho más ágiles.
La última conferencia a la que asistí por la mañana fue: «JVMTI, Creación avanzada de profilers de aplicaciones on la nueva API de Tiger». La charla fue impartida por el estudiante de ingeniería informática Daniel González. Daniel González forma parte del grupo desarrollador de un programa llamado: Java TraceIt, que es un depurador y optimizador de aplicaciones Java. En su charla nos introdujo al nuevo protocolo introducido en la última versión de Java que nos permite comunicarnos con la máquina virtual. Esto se puede usar para dos cosas, por un lado proporciona un modo común para controlar la máquina virtual (depuradores de código) y por el otro permite la creación de Profilers, los cuales permiten el análisis de cuellos de botella en nuestro código (análisis de memoria y análisis de uso de CPU), esto es usado por soluciones como: OptimizeIT Profiler, Eclipse Profiler Pluging o su propia implementación Java TraceIt. El pon
ente continua hablandonos de todas las posibilidades de que ofrece los profilers en Java 5.0 para la creación de optimizadores de código.
Bueno, hasta aquí mi segundo informe sobre el segundo congreso de JavaHispano, también existe otro post sobre la conferencia del congreso titulada: Taming the Tiger. Cuando tenga otro rato libre continuo hablando sobre estas conferencias, que aun me quedan 1 mañana y dos tardes por narrar.
—–
