Google ha decidido dejar un poco de lado Java para crear sus aplicaciones móviles y ha sorprendido gratamente con una aplicación nativa para móviles S60 de su Google Maps para móviles, que concretamente soporta de forma nativa el GPS del Nokia N95.

Se nota que la aplicación es nativa, principalmente al arrancarla, es casi instantáneo en mi Nokia N95. Una vez encendida comenzará a bajarse los mapas de Google, ahí, la rapidez, ya dependerá de la conexión de cada uno.

Lo que si me he fijado es que cuando le pides la posición GPS en modo vista satélite te da la posición en la que el cree que estás, mientras cuando se la pidas en el callejero te situa en la calle más cercana a la posición en la que crees que estás. Supongo que esto le puede causar algún despiste en calles que estén muy pegadas. Aunque de todas formas, esto es un fallo típico en cualquier sistema de GPS.

Por último, también indicar, que al igual que la versión anterior, Google Maps para móviles también calcula rutas de un punto a otro, aunque no te guía estilo TomTom

Vía: All About Symbian

Como mañana me marcho para Amsterdam voy a limpiar hoy un poco las pestañas del Firefox. No me apetece que a la vuelta además de los miles de entradas por leer en todos los blogs a los que estoy subscrito, también tenga un montón de pestañas que revisar.

• Cambia el logotipo de la compañía de móviles en tu Nokia N95, he mirado por encima el manual y parece un poco lioso… por si os queréis entretener un ratito.
• CorePlayer para Symbian el próximo miércoles: Coreplayer Mobile es un reproductor de divx, xvid, mp3, ogg… para móviles basados en Windows Mobile. Ahora van a sacar su versión para Symbian S60. Podrá ser usada en móviles como el N80, N95, N93… vamos, todos los S60, S60 v3, UIQ, UIQ v3
• Programas gratuitos de navegación GPS, existen muchas alternativas comerciales de programas que te guíen de un punto A a un punto B gracias a un GPS, pero también las hay gratuitas, principalmente basadas en Java y funcionando con GPS vía bluetooth o el integrado como el del N95 u el E90.

• Microsoft llega a Symbian: A partir de ahora, en las opciones de descarga de software de algunos modelos, se podrán instalar programas para acceder a servicios de Windows Live (mesenger, hotmail…)

  Nokia customers who own the Nokia N73, N76, N80 Internet Edition, N93i, and the N95 multimedia computers can get the Windows Live services via the Download! application in the following countries; Denmark, Finland, France, Germany, Netherlands, Norway, Spain, UK, Sweden, Saudi Arabia and the UAE.

• Todos los artículos de All About Symbian de como usar la salida de televisión del Nokia N95
• Versión de Jaiku para S60, yo soy usuario de Twitter principalmente y realmente desearía una aplicación como esta disponible nativamente para Twitter en mi N95.
• Trucos para el Nokia E90 (Vía: All About Symbian)
• Usando el MP3 Trimmer para crear tonos de llamada en Mac OS X, por si quieres poner en tú móvil la música de tus serie favorita o cosas así (Vía: Nokia N95 Blog
• Cómo editar video en el N95, un vídeo que te enseña como usar el editor de vídeo que viene en el Nokia N95, vágame la redundancia (Vía: Nokia N95 Blog)
• Muchos Nokias N95 juntos

Puff… tengo montones de pestañas abiertas, tengo ganas de cerrarlas para hacer un pelín de limpieza en mi Firefox y estoy un poco vago, he decidido juntar todo aquí en una única entrada.

• Math4Mobile son un conjunto de aplicaciones en Java desarrolladas por la Universidad de Haifa. Las aplicaciones pueden ser probadas en su propia página web, tienen programa de ajustes de datos, representaciones gráficas, resolución de ecuaciones… (Vía: Noticias de Yoigo)
• Trucos para el Nokia N95 Tiene algunas cosas que me parecen un poco tontas de mencionar, pero en general no está mal (Vía: N95 Blog).
• Twibble y Google Earth: Personalmente no me gusta Twibble, no entiendo como estos clientes Java de Twitter no soportan acentos o “ñ”. Aunque este con soporte de GPS es la mar de interesante. (Vía: N95 Blog).

• Comparación s40 y s60, realmente desde que estoy usando el Nokia N95 me gusta más el interfaz que el de los móviles s40, como el de mi Nokia 6280. Pero aún así, hay cosas que hacía este que echo de menos en los s60, y que comentan claramente en el artículo enlazado al principio, como por ejemplo

  the time is only visible on the home screen of S60, this isn’t the case with S40 where the time is everywhere

  Todo son detalles pequeños como ese, pero en los detalles son de lo más importante en un uso diario de un dispositvo.

• Symbian-Guru en su odio y amor a Shozu. Personalmente me encanta Shozu, probablemente sea la aplicación que más me gusta de todas las que uso con mi móvil. El problema es que chupa demasiada memoria ram, según Symbian-Guru. Realmente este es uno de los problemas más grandes que tienen algunos modelos de móviles Nokia s60, aunque parece que ya están añadiendo más memoria en nuevos modelos, realmente por el precio de esta en el mercado, bien podían meterle mucha más y olvidarnos de este tema de una vez por todas (Vía: All About Symbian).
• iPhone IM - Just not practical yet. El uso de programas de mensajería instantánea en el Nokia N95 no me lo he planteado en ningún momento. Usar un teclado con texto predictivo para chatear debe ser el mayor coñazo del mundo. Sin embargo, el iPhone, con su teclado virtual completo, sería ideal. Una pena que nadie pueda programar una aplicación para esto como es debido.

Opera ha sacado una versión beta de su próximo navegador web para móviles, el Opera Mini 4, el cual yo he probado en mi Nokia N95. Para descargarlo, simplemente tenemos que usar el navegador web de serie que venga con el móvil y ir a la siguiente dirección: mini.opera.com/beta. En ese momento empezará el proceso y descarga del navegador.

Una vez instalado, la primera vez que se ejecuta pide hacer una serie de tests de velocidad de conexión. En ese momento fue cuando la aplicación casco. No es algo a tener en cuenta todavía dado que es una versión beta. La segunda vez que lo ejecuté me mostró las diversas opciones de configuración posibles. El objetivo es que tu ajustes lo que quieras ver de calidad frente a velocidad de acceso y bytes descargados. Opera Mini funciona detrás de un proxy. Toda petición web pasa por ese proxy donde todas las imágenes serán reducidas de tamaño antes de ser enviadas al móvil. Esto ahorra bastante el tráfico de datos, que a parte de ganar velocidad de acceso, además, si estamos pagando por byte descargado, nos puede ahorra mucho dinero a finales de mes.

Una vez configurado todo a nuestro gusto, las próximas veces que ejecutemos el navegador nos preguntará a donde queremos ir. Nos permite buscar en Yahoo, tiene una serie de bookmarks por defecto y después nos mostrará el historial de páginas visitadas.

Así es como se ve mi página, y si pinchamos en zoom, veremos ampliado el recuadro que se marca ahí.

Lo único que eché en falta fue una opción para ver la página con la pantalla girada, aunque esto puede que aparezca en la versión definitiva del navegador. El renderizado de las páginas web de la versión 4 es muy superior a lo que se veía habitualmente en la versión 3 del mismo, donde el layout de la página se perdía por completo. Realmente, debido a la rapidez del mismo, creo que esta beta se ha convertido en una de las aplicaciones que más voy a usar a partir de ahora con el móvil.

Más análisis de este navegador en: Into Mobile: Opera Mini 4 Beta Review (Verdict: Mobile application of the year) (en inglés).

Vía: All About Symbian

La semana pasada ocurrió uno de los eventos más esperados para todos los maqueros, la keynote de Steve Jobs en la WWDC. Muchos esperaban una máquina nueva, pero yo personalmente vi lo que esperaba ver: Steve Jobs hablando de Leopard, el nuevo sistema operativo que Apple lanzará en Octubre. Tampoco esperaba que Steve Jobs me contase algo revolucionario, después de todo no es un programador y nunca entra en los detalles técnicos, solamente nos muestra fucionalidades y cosas gráficas bonitas. Yo aquí voy a dar mi opinión en varios aspectos.

De entrada, y después de dos versiones de sistema operativo Panther y Tiger que tenían algunas capas de 64 bits, parece que Apple ha decidido convertir su sistema operativo en un sistema operativo completo de 64 bits. Por mucho que a Steve Jobs le guste decir que son los primeros haciendo las cosas, se olvidaron por completo de que Linux y otros sabores de Unix ya son sistemas completos de 64 bits que también pueden ejecutar código de 32 bits sin problemas… pero bueno, su mensaje estaba dirigido al mundo de Windows Vista. De todas formas, parece ser que Apple no ha portado todas sus librerías, se han dejado a Carbon por el camino. A pesar de que Apple está promoviendo cada vez más el uso de Cocoa entre los programadores, aún hay mucha gente que usa Carbon en sus aplicaciones. Así que la gente tendrá que empezar a actualizar para aprovechar al máximo sus aplicaciones en sistemas modernos (yo por el momento, con un Macbook Pro de primera generación, seguiré una temporada en un mundo de 32 bits, dado que el procesador que llevo no es de 64).

Otra cosa en la que si parece que mejora el nuevo sistema es en el soporte de procesadores de varios núcleos. Esto es una muy buena noticia para todo el mundo que tenga procesadores Intel. Cada vez es más importante que el sistema operativo y programas que tengamos en ellos sepan como aprovechar los múltiples núcleos con los que vienen, cosa que es más fácil de decir que de hacer.

Apple ha mejorado bastante el Finder (veremos si da resultados). El Finder siempre ha sido una de las aplicaciones que más quejas ha recibido de los usuarios de Mac. Ahora Apple se ha puesto las pilas. Me gusta la idea de que automáticamente te muestre otros ordenadores compartiendo algo en la red, me facilitará bastante el trabajo diario. El uso de por parte del Finder de algo parecido al CoverFlow de iTunes también me gusta, junto con Quicklook parece que ya tenemos una forma fácil de previsualizar documentos sin tener que recurrir a terceras aplicaciones, o acabando con 30000 ventanas abiertas de Vista Previa.

Ahora que estoy haciendo la tesis doctoral, soy un paranoico de las copias de seguridad, y TimeMachine me viene que ni pintado, eso sí, su interfaz me parece horrible, me recuerda a las primeras aplicaciones de Windows 95 que llenaban toda la pantalla con imágenes feas por que no sabían que hacer con ella. Su funcionalidad tiene toda la pinta de tener todo lo que esperas de una aplicación de este tipo.

¡Por fin!, eso es todo lo que se puede decir, ¡por fin! un Unix como Mac OS X tendrá escritorios virtuales. Spaces hace lo que otra aplicaciones gratuitas para Mac ya hacían, pero desde luego, después de 6-7 años, ya iban siendo horas de ver algo así de la mano de Apple.

La integración de iCal con el estándar CalDAV también me resulta interesante y práctica para mucha gente. Yo por el momento no creo que me sea de mucha utilidad.

Si algún día cumplo mi autopromesa que me hice cuando compré el Mac, la de aprender a programar en él, ya le echaré un vistazo al nuevo Api Core Animation, aunque me temo que para esto hace falta tener gusto gráfico para hacer cosas decentes, de lo cual yo carezco totalmente. Por otro lado, el profiler Xray haciendo uso de DTRACE de Sun tiene muy buena pinta. Como dije, para cuando aprenda a programar en Objective C -la esperanza nunca se pierde.-

Y ya que hablamos de programación, parece que Java va a sufrir una profunda mejora en el nuevo sistema operativo. Todo apunta a que la Java 6 que venga con Leopard será completamente de 64 bits (si el procesador lo permite) y trabajará con gráficos vectoriales para ser completamente independientes de la resolución.

Y hablando de Sun. En Apple les ha gustado su sistema de ficheros ZFS. Leopard tiene soporte para lectura del mismo. Supongo que son unos primeros pasos para irlo testeando, para usarlo más adelante como sistema de alto rendimiento frente al actual HFS+. ZFS es un proyecto de código abierto, y es bastante común para Apple usar este tipo de código que supongo que les facilitará mucho tener que diseñar por ellos mismos cosas desde cero.

Voy terminando… las stacks tendré que probarlas para ver si me resultan prácticas. Realmente hasta que uno usa una cosa de esas no sabe si le van hacer la vida más complicada, más fácil o dejarlo como estaba. En cuanto a los cambios gráficos del escritorio, muy bonitos pero no creo que me faciliten mi trabajo diario.

El resto de cambios, iChat, Dashboard, Mail, Safari, son aplicaciones que no uso, y que no creo que vaya usar por el momento, así que tampoco entro a valorarlos. Eso ha sido más o menos todo lo que tenía que comentar…

Hace unos días que volví a empezar a escuchar podcast y me he encontrado con The Java Posse, un podcast dedicado al mundo del lenguaje de programación Java, con la últimas noticias y entrevistas a gente del mundo Java, si eres programador de Java y no tienes problemas con el inglés tal vez te interese.

Vía: JavaHispano.

—–

Atención: Esta noticia es sobre el lenguaje de programación Java, y un auténtico coñazo para aquellos que no programan, así que si ese es tu caso, se te recomienda que te muevas a otro post que aquí no hay nada que ver.

En mi trabajo habitualmente programa en Java, y como todo programador de Java sabe, nuestra vida sería muy difícil sin el trabajo de la gente del grupo Apache, utilidades como Ant, Tomcat, Jakarta Commons se han convertido en imprescindibles… y yo he descubierto estos días una pequeña joya que aun no tiene versión definitiva: Apache Jakarta Commons Betwixt.

El viernes necesita guardar una gran cantidad de información en una aplicación para pasarlas a otra aplicación desarrollada por mi. Había trabajado un poco con Digester para leer ficheros XML pero me dí cuenta que este proyecto solamente “digiere” XML, no lo crea, así que decidí ver si había otra solución fácil de usar dentro del gran abanico que ofrece Jakarta Commons, y allí estaba Betwixt.

Betwixt es capaz de generar automática con unas pocas líneas de código un fichero de Java a partir de POJOS y/o JavaBeans. Con solamente estas líneas de código, ya podía guardar cualquier tipo de objeto a disco:

             Writer outputWriter = new FileWriter(filename);             BeanWriter bWriter = new BeanWriter(outputWriter);             bWriter.setEndOfLine("\r\n");             bWriter.setIndent("\t");             bWriter.enablePrettyPrint();             bWriter.write(graphToStore);             outputWriter.close(); 

Y todo un Grafo, con sus Vértices y Ejes, representados por sus sendas clases, dentro de un bonito fichero XML.

Ahora estaba el problema de volver a leer eso en la otra aplicación, iba a mirar Digester cuando vi, que Betwixt además de almacenar lee, y con otras pocas líneas de código ya tenía mi fichero XML convertido a objetos Java.

             InputStream inputStream = new FileInputStream(filename);             BeanReader beanReader = new BeanReader();             beanReader.getXMLIntrospector().setWrapCollectionsInElement(false);             beanReader.registerBeanClass(Graph.class);             return (Graph) beanReader.parse(inputStream); 

Y de esta forma tan simple podía mover todo un mapa de objetos de una aplicación a otra, sin tener que usar librerías complejas de XML o serializar a fichero en un formato que solamente Java podría leerlo de nuevo.

—–

El año pasado compré el libro Hibernate in Action escrito por los propios creadores de Hibernate. El libro me ha encantado, es ameno y conciso, fácilmente te explica como Hibernate resuelve el problema de mapear objetos Java a bases de datos relaciones, y por que optaron por ciertas implementaciones en vez de otras.

Pero el mundo de la informática no para, y desde que se edito el libro se ha publicado la versión Hibernate 3.0 con la 3.1 a punto de caer, y la especificación de EJB 3 también esta más cerca. Por ello los autores han decido preparar una segunda edición del libro que tenga en cuenta estos cambios. Por otro lado también van incluir cambios en la estructura del mismo para corregir detalles que vieron cuando hicieron un curso sobre Hibernate donde seguían la estructura del libro.

We’ll update the book for Hibernate3 and EJB3, and based on the feedback we got from readers and during training (our first Hibernate training last year was following the books structure) we’ll make some major changes:

* the “Toolset” chapter will be removed and integrated into a new beginners tutorial that also shows the new Eclipse-based and Ant tools, with a hands-on basic project setup

* a new chapter will be added with best practices, patterns, and general tips & tricks - this will include a lot of FAQs from the forum and our customers, such as caching tricks, metadata-driven applications, dealing with large values, complex deployment scenarios, etc.

* more illustrations will be included with many mapping examples

So, you can expect quite a lot of new content, especially wrt EJB3 API usage for all of you who want to learn the new interfaces and lifecycle (it’s easy if you know Hibernate…) and more best practices.

Vía: In Relation To…

—–

Usualmente en mi trabajo uso Eclipse para programar en Java. En estos días se esta celebrando la EcliseCon2005 y han puesto en su página web las traspas de las conferencias y tutoriales, a primera vista parecen bastante interesantes:

Tutoriales.

Presentaciones.

Vía: Java Hispano.

—–

Como cada año nuevo, mucha gente suele proponerse unos cuantos objetivos que cumplir. Hace algún tiempo que cada vez estoy leyendo más sobre Test-Driven Development (TDD) que lo podríamos traducir como algo así “desarrollo guiado a través de tests”, y es que vamos a confesarlo, aunque yo estudie la carrera de Físicas, realmente estoy trabajando como programador, lo cual tiene algunas desventajas, como la de que uno se autoenseña a programar, después de la lectura de muchos y muchos manuales y libros. Test-Driven Development aparece como un concepto que se adapta a mi forma de trabajar y, en un principio, me ayudaría a escribir mejor código. Así que uno de mis primeros objetivos este año va a ser intentar perfeccionar mi uso de dicha técnica. Para ello, me he encontrado con este interesante libro que he empezado a leer hoy mismo, se titula: “JUnit in Action”, y nos comenta todos los entresijos y algunos consejos de “Best-Practices” para el uso del framework de test JUnit. Por cierto, uno de los autores tiene un blog en el cual habla de la programación de Java, sobre todo, por lo poco que he podido ver, en el desarrollo usando tests. Citando el libro, la motivación de usar TDD es la siguiente:

Nobody wants to write sloppy code. We all want to write code that works - code that we can be proud of. But we’re often distracted from our good intentions. How often have you heard this: “We wanted to writes tests, but after two weeks our momentum dropped, and over time we stopped writing them”. This book (JUnit in Action) will give you the tools and techniques you need to happily write quality code.

Bueno… una vez termine de leer el libro ya os diré si yo conseguí cumplir dicho objetivo ;-).

—–

Me he encontrado con este interesante artículo, publicado en On Java, “The Hidden Gems of Jakarta Commons, Part 1″ que nos introduce y recomienda el uso de Jakarta Commons. Jakarta Commons son una serie de librerías de Java desarrolladas por los chicos de Apache para resolver problemas comunes que se encuentran a la hora de desarrollar aplicaciones Java, tales como manejo de ficheros XML, manejo de colecciones, entrada/salida de datos y un largo etc… por mi parte, si hace un par de años tuviese disponible Jakarta Commons Math me habría resuelto unos cuantos problemas. Hablando de Jakarta Commons Math, en la página web de O’Reilly tenéis un capítulo de muestra del libro Jakarta Commons CookBook, ese capítulo es el dedicado a Jakarta Commons Math, con una serie de recetas para el uso diario de esta librería.

—–

Bueno, como prometí la semana pasada, continuo con mis posts sobre el segundo congreso de JavaHispano, que al paso que voy los terminaré para cuando ya empiece la décimo quinta edición de este congreso. El segundo y último día del congreso decidí sacar alguna que otra foto para amenizar un poco mis posts en el blog. Aquí tenéis las fotos que saque ese día

Dos fotos de la “pequeña” pancarta que señalaba el edificio donde se celebraba el congreso de entre todos los edificios del campus del la Universidad Rey Juan Carlos.

También tenían carteles pegados por la paredes…

Y aquí el lugar donde se celebró la inscripción, el proceso era bastante rápido si ya estabas preinscrito, puesto que consistía únicamente en mostrar tu código de barras para que te diesen todos los regalitos que tenían preparados: mochila, camiseta, tarjeta del congreso, varias revistas, actas del congreso en cd y diversos artículos de propaganda de las empresas patrocinadoras.

Aquí esta el escáner de códigos de barras por el que te hacían pasar cada vez que entrabas en una conferencia, supongo que para mantener algún tipo de control de asistencia. También se pueden observar los equipos de radio para escuchar la versión traducida de las conferencias impartidas en inglés.

Una vista de una de las salas de conferencias, la más grande de las dos que había, eso sin contar la sala demos, a la cual nunca fui en todo el congreso, por lo tanto no sé decir si era más grande o pequeña que esta sala.

Aquí tenéis dos fotos de Alexandre Vasseur durante su conferencia titulada “Annotation driven AOP”. Alexandre Vasseur es una de las personas involucrada durante los últimos años en el desarrollo del concepto de Aspect Oriented Programing. A parte de esto, es coautor del famoso AspectWerkz, una de las alternativas que existen para Java a la hora de realizar programación orientada a aspectos.

Por último también le saque otra foto durante la conferencia de uno de los empleados de CompuWare, Ruud Grotens. Realmente la conferencia no me interesó mucho puesto que nos habló de una nueva herramienta de CompuWare para el desarrollo de aplicaciones J2EE a base de patrones. Yo realmente tengo la intención de no aprender nada de EJB2 a no ser que me haga falta para ganarme el pan.

También hay más fotos en un post que hice hace tiempo y que se llama: Taming the Tiger, que tiene fotos de la última conferencia del congreso.

—–

Chequeando los distintos feeds rss a los que estoy subscrito me he encontrado con esta API de Java que probablemente me venga bien para mi futuro trabajo con grafos: Java Universal Network/Graph Framework.

—–

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 charla 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 ponente 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.

—–

Realmente debería empezar mi crónica de mi experiencia en el segundo congreso de JavaHispano por el principio, pero primero voy a hablar de su última conferencia. Esto es debido a que no tuve tiempo de tomar muchas notas, la verdad es que estuve más interesado en prestar atención a los ponentes, y no quiero dejarme nada en el tintero… digo teclado.

Uno de mis principales motivos que realmente me convencieron para ir al congreso de JavaHispano, a parte de que conocía a uno de los organizadores en persona, era poder ver una conferencia de dos de los arquitectos de la arquitectura de Java: Neal Gafter y Joshua Bloch. Para poner unos pocos datos biográficos, Neal Gafter actualmente trabaja para Google, aunque hace poco trabajaba para Sun donde se encargaba del desarrollo y soporte de herramientas de compilación del lenguaje Java (javac, javadoc, javah, javap…). También ha participado en el desarrollo de una de las APIs introducidas en Java 5.0: Generics (JSR14). Probablemente, más famoso sea el nombre de Joshua Bloch, al menos para mí, debido a su famoso libro de Java: Effective Java Programing Lenguage Guide, en el cual se muestran 57 pautas concretas para diseñar y escribir programas en Java. Joshua Bloch fue arquitecto dentro del “Core Java Platform Group” en Sun Microsystems, donde diseño importantes APIs de la plataforma Java, como java.util.Collections y java.math.

Bueno, pues centremonos ahora en la conferencia, realmente ellos habían preparado dos conferencias, una primera titulada: “Taming the Tiger” y otra titulada: “Still More Programing Puzzlers”. En la primera de las conferencias se centraría en explicar las nuevas características de la nueva versión de Java, J2SE 5.0, también conocida como Tiger; en ella explicarían importantes características como: generics, enums, autoboxing, for-each, varargs, static import y annotations (metadatos), al mismo tiempo aclarando cuando es conveniente usarlos y cuando no. La idea de la segunda charla consistía en proponer diferentes rompecabezas de programación al público para que estos comentasen que hacía ese pedazo de código, donde ellos después explicarían lo que realmente hacía y especificarían donde estaban los errores en esa porción de código, básicamente una forma divertida de aprender nuevos detalles sobre Java. Como realmente no tenían tiempo de dar las dos charlas, preguntaron al público cual de ellas preferían, y como el público no dio un voto decisivo, al final se usó el método de la moneda, cara o cruz, y la charla ganadora fue: “Taming the Tiger”, que la gente de JavaHispano tradujo como “Domesticando al Tigre” (aquí me gustaría hacer mención a que ninguno de los ponentes hablaba castellano, pero la organización del congreso, conociendo este problema, contrató un servicio de traducción para poder solventar este pequeño escollo lingüístico para aquellas personas que no tuviesen suficiente conocimientos de inglés).

Como comenté anteriormente, la conferencia se centró en explicar las nuevas características del J2SE 5.0 y en como usarlas. Empezó hablando Joshua Bloch, comentó que la idea principal de la nueva especificación era crear una programación más amistosa, dándole mayor soporte lingüístico a Java y sin sacrificar compatibilidad hacia atrás, es decir, cualquier programa que funcionase en Java 1.4 o 1.3 funcionará en Tiger, con la excepción de si ese programa usa una clase llamada enum, término que se introduce en la nueva especificación del lenguaje a partir de la versión 5.0. Una vez introducido el índice de la charla, Joshua Bloch le dio paso a Neal Gafter para que nos hablase sobre Generics.

Neal Gafter nos comento que Generics facilita la vida a todo el mundo que trabaje con java.util.Collections, destacando sobre todo el nuevo for-each loop como uno de sus añadidos favoritos a la nueva especificación. Nos presenta el nuevo interface de Collections para explicarnos los cambios que se producen por la introducción de Generics. Para recalcar aun más el nuevo concepto, se nos presenta una pequeña porción de código que usa Generics y Autoboxing, Quiero anotar que durante toda la conferencia, tanto Joshua como Neal se hicieron preguntas uno al otro para destacar los puntos más curiosos del ejemplo que estaban mostrando, un detalle que me pareció curioso fue la explicación del significado de los “:” del for-each loop, por ejemplo:

 List<ObjectX> lista = new ArrayList<ObjectX>();  ...  for(ObjectX objectX : lista) { ... }  

Si nos fijamos en la línea del bucle for, esos “:” puntos se traducen como “in”, lo cual quiere decir que es el “objectX” de la colección “lista”. Al final Neal Gafter concluye diciendo que deberíamos usar Generics y el for-each loop siempre que se pudiese en nuestro código, con una excepción, en el caso de que se necesite compatibilidad hacia atrás, hacia una máquina virtual más antigua que la Java 5.0. En el caso de autoboxing, es decir, la automática conversión de tipos primitivos (int, boolean,…) a sus equivalentes como objetos (Interger, Boolean…) sin necesidad de hacer un cast, también se puede usar sin problemas, pero tiene una penalización de rendimiento, aunque si no es en caso de cálculos científicos, se pueden usar por que facilitan bastante la lectura del código.

Después le toco el turno de Joshua Bloch de hablar sobre enums, donde destaco que gracias a ellos programas de cierta complejidad pueden llegar a simplificarse fácilmente, tal como sucede con otros lenguajes de programación. Para ello introdujo dos ejemplos, uno usando enums para la construcción de un programa que baraja cartas y reparte un número “n” de las mismas a distintas personas, consiguiendo la construcción del programa con una pequeñísima porción de código fuente. También para destacar más aspectos, puso otro ejemplo usando un programa para calcular el peso de diferentes personas en diferentes planetas del sistema solar (para ello uso de broma el “sobrepeso” de su compañero Neal, que el estimó en unos 100 kilogramos). A parte también explicaron como añadir funcionalidades a cada uno de los componentes del enum. También hablaron un poco de EnumSet y EnumMap que hacen lo equivalente que Set y Map pero con objetos que extienden del tipo enum. Al final, Joshua Bloch recomienda usar enums siempre que se conozcan todas las posibles cosas que deben ir en esa lista ordenada, por ejemplo, el orden de una baraja de cartas, se sabe desde el momento que se escribe el programa, y es algo que no va a cambiar durante la ejecución del mismo, añadiendo o quitando nuevos elementos.

Las dos últimas características novedosas que añade Java 5.0 fueron introducidas por Neal Gafter, que son varargs y static import. Para VarArgs usó diversos ejemplos, como el printf, que ahora se ha introducido en Java y que da la misma funcionalidad que en C/C++, también puso un ejemplo para un hipotético testeador estilo JUnit usando Varargs, obviamente, con un código muy sencillo. Por otro lado nos comentó el uso de static import con un ejemplo muy típico, hasta el momento cuando en Java querías usar una constante como PI, debías hacer algo así:

 r = Math.cos(2*Math.PI); 

Lo cual hace un poco complicada la escritura y lectura del código. Ahora se puede reescribir como:

 // Es mejor importar solo PI o cos, sin importar todo java.lang.Math import static java.lang.Math.*;   ...  r = cos(2*PI); 

Con lo que no hace falta andar repitiendo Math.PI o Math.cos por todo nuestro código. Tanto para varargs como para static import, nos recomiendan que lo usemos muy cuidadosamente, teniendo muy claro que ese es el momento y lugar correctos para usarlos.

Por último, Joshua Bloch habló de Metadata o annotations como también se le conoce. Comenta que la anotaciones pueden ser leídas a través del código fuente del programa, a través del fichero compilado .class o en tiempo de ejecución a través del API de reflection. Las anotaciones pueden ser usadas por muchas razones y para ello el nos retoma el ejemplo del testeador introducido por Neal, y nos explica que ahora ya no es necesario hacer cosas como en JUnit de empezar todos los métodos por “test” para que JUnit sepa que ese método es un test, si no usar una anotación, lo cual facilita la lectura del código y produce un código mucho más limpio.

Como conclusión, tanto Neal como Joshua nos comentan los siguiente: “Tiger is all about you, the programmer. Better programs with less effort”.

Después hubo un turno de preguntas, algunas de ellas para felicitarles por su trabajo en el desarrollo de JAVA, otras para preguntarles por su nuevo trabajo en Google, a lo cual contestaron que en Google se usan básicamente 3 lenguajes de programación, Java (uno de los sitios donde lo usan es en los banners publicitarios), C/C++ y Python (cada vez tengo más interés por aprender este lenguaje), y que no están haciendo ningún navegador web. Por otro lado, creo que fue Carlos Sanchez (si me equivoco que alguien me corrija) el que le pregunto por que Joshua Bloch, como diseñador del API de collections, escribió un método llamado .size() para recuperar el tamaño de una lista en vez de llamarlo .getSize(); pregunta que yo me he hecho en alguna ocasión. Realmente me gustó la respuesta de Joshua Bloch, comentó que suele haber dos visiones en cuanto a escribir métodos en un lenguaje orientado a objetos: una primera que lo ven todo como un bean, y por lo tanto los métodos para conseguir un valor deberían empezar por get, y otra, como la suya que diferencia las cosas que pueden tener métodos get y set, como puede ser el nombre de una persona dentro de una hipotética clase usuario (.getName() y .setName()), o, como en el caso de size en una lista, que no es una propiedad que pueda tener un setSize(), dado que a la lista se le añaden o quitan objetos, y es eso lo que define su tamaño, por lo tanto el método se llama .size(). También le preguntaron si creían que ahora Java iba detrás de .Net y C#, dado que con la versión 5.0 se le añadieron algunas propiedades que ya existían en C# desde el principio; ellos comentaron que eso no era así, que ya había propuestas de añadir eso a Java desde hace más de 4 años, lo que sucedía, es que todo lo que se añade a Java tiene que ser aprobado por el JCP, y eso llevaba tiempo. Por otro lado, Joshua comentó que llevaba tiempo intentando añadir esas características a Java, pero que nadie parecía tener prisa en ello, hasta que Microsoft se la añadió a C#, con lo cual, gracias a ello, ellos consiguieron implementar esas nuevas y útiles características en Java.

Bueno, antes de acabar con este post, aquí tenéis unas cuantas imágenes de la conferencia:

Aquí tenéis una imagen antes de que empezasen a dar la conferencia, el de la izquierda y de camisa azul es Neal Gafter, y el de la derecha, trabajando en el PowerMac es Joshua Bloch.

Al principio de la charla, ambos destacandonos las mejoras introducidas en Java 5.0.

A mitad de la charla, hablando sobre enums.

Al fina de la charla, componentes de JavaHispano comentaron más información sobre el proyecto JavaHispano y animaron a la gente a colaborar. Neal Gafter y Joshua Bloch escucharon atentamente esos comentarios, el único problema es que no entienden nada de castellano.

Después de la conferencia me tuve que marchar corriendo a pillar mi avión de vuelta a Santiago de Compostela, con lo cual no se si Joshua Bloch y Neal Gafter quedaron explicando al resto de la gente los de los rompecabezas, lo cual sería una pena que me lo hubiese perdido, pero es que los aviones no esperan.

—–