Media Net Software KIT Blog

Como sabeis, cada año se celebra en Amberes el Devoxx (antes conocido como JavaPolis). Como Medianet no se pierde una, este año me ha tocado a mí representarnos en este evento que ,sin duda, es el más importante en Europa relacionado con el mundo java. devoxx.com

Los días se repartían en dos bloques, los University days (lunes y martes) y los Conference days (resto de la semana).

En el primero de ellos, las charlas eran de tres horas de duración y estaban orientadas al aprendizaje, al estilo de clases magistrales impartidas por algún experto.

Algunas de las mejores charlas a las que asistí tuvieron que ver con Java EE 6 y SOA. En la primera de ellas, Antonio Goncalves se marcó una serie de demos para presentarnos las novedades de Java EE 6, os pongo algunas de las características que más me llamaron la atención:

- Servlets 3.0: Presentó las nuevas anotaciones @Servlet que, por ejemplo, eliminan la necesidad de declarar y configurar el servlet en el web.xml. Además, ahora, los servlets tienen soporte para peticiones asincronas.

- EJB 3.1: La principal novedad residía en lo que han llamado EJB Lite, que permite empaquetar un EJB dentro de un WAR. con ciertas limitaciones. También se ha simplificado el tema de las interfaces, ya que si no se usan no es necesario crearlas. Otro punto a favor es que ahora los EJBs de sesión pueden tener métodos asincronos simplemente usando la anotación @Asynchronous sin necesidad de hacer nada más. Por último han creado un nuevo servicio que llaman “Time Service” que usando la nueva anotación @schedule permite programar ,como si de un video se tratara, el EJB para lanzar sus métodos en un momento determinado, al estilo del comando cron de Unix.

- JPA 2.0: Se ha enriquecido JPQL para dar soporte a joins en subqueries con la clausula FROM. También se ha incluido un nuevo nivel de cacheo que se puede usar con la anotación @cacheable. Se han incluido nuevas posibilidades para realizar los bloqueos (Lock, Read and Lock, Lock and Read…)

- JSF 2.0: Ahora JSF 2.0 está integrado en Java EE 6.

- BeanValidation 1.0 : Este nuevo paquete presenta funcionalidad para validar beans usando notaciones del estilo @NotNull, @size, @valid…. Se integra con JPA 2.0 y JSF 2.0

- JAX-RS 1.1: Ahora soporta RESTFul services. Añade notaciones para especificar diferentes tipos MIME (@Produces(”image/jpeg”), @Produces(”text/plain”)…)

Si quereis ver una lista completa y detallada de todas estas novedades podeis hacerlo en http://java.sun.com/javaee/technologies/javaee6.jsp

Ahora mismo, el único servidor que soportará el 100% de la nuevas características de Java EE 6 es Glassfish (implementación de referencia) que estará disponible en versión v3 el 10 de Diciembre. Ya podeís estar atentos. https://glassfish.dev.java.net/

Como he comentado más arriba, otra clase magistral que me gustó especialmente por su claridad y por el enfoque, fue la impartida por Sang Shin evangelista de SUN.

Estuvo presentando, con multitud de ejemplos, los fundamentos de SOA. Desde lo que era un WSDL hasta las tecnologías que permitian orquestar e integrar los distintos servicios BPEL y JBI. Usando para ello Glassfish ESB y NetBeans 6.7.1, este entorno proporciona unos muy buenos editores para hacer el trabajo con estas tecnologías algo más sencillo. Incluso, al final le dió tiempo a montarse un Single Sign On federado usando OpenSSO.

Si quereis seguir esta charla y aprender más sobre un montón de temas relacionados con el mundo java podeis hacer sus estupendos tutoriales en javapassion.com

Al parecer, y según el siguiente articulo publicado en bloomberg
Google y Microsoft también se verán las caras en el cuadrilatero de los netbooks.

La nueva estrategia de Asus para sus nuevos netbooks es la de dotarlos con el sistema operativo Android, que hasta el momento tan solo era rival de los SS.OO. para moviles de Apple, Microsoft o Nokia.

Bien mirado, la apuesta de Asus por Android resulta completamente lógica. Buscaban un S.O. abierto (opensource), barato (gratis), y ligero (pensado para teléfonos móviles). La guinda del pastel la ponen la compatibilidad con las miles de aplicaciones creadas para Android y con los teléfonos móviles que en un futuro lleven este sistema operativo. ¿A quien no le gustaría tener en su teléfono móvil el mismo sistema operativo que lleva en su portatil?

Una de las ponencias de hoy ha tratado sobre OSGI. OSGI es un estándar de componentes dinámicos que pretende solucionar algunos de los problemas que presentan las aplicaciones JAVA cuando el número de librerías implicadas en las mismas y de dependencias entre estas es elevado (cuando digo elevado hablo de 50 o más librerías). La ponencia ha sido expuesta por Peter Kriens, artífice de este estándar. He de decir que ha sido de las mejores que he visto ya no solo por la claridad de la exposición, sino porque el pobre hombre se ha presentado incluso estando medio afónico.

Peter nos contó como todo parte del boom de Internet de finales de los 90. Por esas fechas Peter estuvo involucrado en un proyecto cuyo objetivo era hacer llegar a todos los hogares un ordenador que permitiera controlar vía Internet prácticamente todos los electrodomésticos y artilugios que nos rodean cotidianamente. Para ello su equipo creó un pequeño sistema empotrado con java integrado cuya misión era servir de servidor en esta infraestructura. Por aquellas épocas se pensaba que Internet iba a revolucionar el modo de vida de las personas incluso más de lo que lo ha hecho a día de hoy. Este sistema tenía que funcionar con gran diversidad de dispositivos diferentes que los diferentes fabricantes ofrecerían al mercado.

La heterogeneidad de los distintos dispositivos a integrar dio lugar a una serie de problemas:

• Se hacía tedioso y complejo mantener el classpath de las aplicaciones cuando el número de librerías era elevado. Un claro ejemplo es el de mantener un classpath con 500 librerías, las cuales a su vez dependen de librerías cuya única diferencia es la versión (y el nombre es el mismo).
• Dependencias demasiado mayadas. Esto es comprensible cuando las librerías de cada dispositivo son implementadas por distintos fabricantes siguiendo patrones de dependencia completamente heterogéneos. El modelo de paquetes de java no ayuda a esto ya que está concebido para dar una estructura lógica-funcional a las clases, y no para estructurar una aplicación en base a componentes.
• Necesidad de que la carga, descarga, puesta en funcionamiento y parada de los elementos que constituían una aplicación fuera dinámica. El funcionamiento de los ClassLoaders es completamente estático. Esto no era raro teniendo en cuenta que en aquella época Windows 98 era el último grito en sistemas operativos: un sistema operativo que te obligaba a reiniciar hasta cuando movías el ratón.

En base a estas necesidades se conciben los primeros modelos de aplicaciones orientadas a servicios, y en particular el estándar OSGI, cuya primera versión se publica allá por el 2000. $$$

El estándar OSGI plantea un modelo como el de la figura.

Los puntos más importantes a considerar son:

• Se plantea la creación de Bundles. Estos Bundles ofrecen una serie de servicios y engloban todas las librerías jar que estos últimos necesitan.

• Estos Bundles presentan una interfaz, y ocultan el resto de las librerías a ojos de otros Bundles. De esta manera no existe dependencia entre unos Bundles y otros más que a través de las interfaces públicas de los mismos. La determinación de qué librerías y que clases son públicas, y cuales son privadas, se especifica en un archivo de metadatos.

• La seguridad forma parte del modelo desde el comienzo. Toda operación de acceso a los servicios de un Bundle está asegurada por diseño.
• Los servicios son completamente dinámicos. Si un servicio cae el estándar contempla una parada ordenada de los otros servicios que dependen del mismo. También contempla una recuperación ordenada de los mismos. De este modo la caídas de conexión, desconexiones por falta de batería, etc; están contempladas.
• Un Bundle antes de arrancar diagnostica si el entorno en que se encuentra va a permitir su funcionamiento de manera clara, evitando de este modo problemas en tiempo de ejecución. Además diagnostica de manera muy clara los motivos al usuario para que pueda resolverlo.
• La carga de clases es más rápida porque OSGI implementa ClassLoaders especiales que únicamente buscan clases en la interfaz pública de los Bundles.

Si queréis saber más de este tema en la página de OSGI encontrareis más.

Hola a todos:

Como algunos de vosotros ya sabréis, Media Net ha decidido plantar una pica en Flandes (más bien dos) y enviarnos a Ángel Rey y a mí al Devoxx (anteriormente llamado Javapolis). Después de dos conferencias matutinas aprovecho un receso para comenzar a escribir este artículo.

Este no trata sobre nada del Devoxx: para esto ya habrá otros artículos. Este artículo trata sobre Mercurial: una herramienta de control de versiones. Esta herramienta la estamos implantando ahora mismo en el proyecto que estoy trabajando (desarrollo de calculadoras de productos financieros en tiempo real). En este artículo os describo el escenario que nos ha llevado a utilizarlo, y cuáles son nuestras impresiones después de probarlo. La explicación la realizo en modo FAQ.

¿Que es Mercurial?

Mercurial es un sistema de control de versiones que cuenta con las siguientes características:

• Es transaccional: Cada cambio sobre el repositorio se ejecuta atómicamente para todos los elementos implicados en el mismo; sean archivos, directorios y/o metadatos.
• Es un sistema distribuido: El histórico de los archivos gestionados no se encuentra en un único servidor centralizado al que los desarrolladores suben sus cambios. Cuando un desarrollador descarga los archivos de un proyecto de Mercurial, éste descarga además una copia completa del histórico de cambios. De esta manera el desarrollador es capaz de reproducir el estado de la aplicación en cualquier momento de su historia sin necesidad de conectarse a un repositorio centralizado.
• Desarrollado en python y algo de C.
• Funciona tanto en modo Push como en modo Pull; dando flexibilidad a las políticas de versionado a aplicar.

¿Por qué nos hemos decidido a utilizarlo?

Los motivos son los siguientes:

• El modelo de versionamiento de CVS no nos convencía. Hemos tenido bastantes problemas de inconsistencia cuando hemos querido descargar versiones anteriores de nuestro software desde el repositorio de CVS. Por otro lado, los desarrolladores de mi equipo se liaban mucho cuando bajaban una versión antigua de un archivo debido a que si posteriormente hacían un commit sobre una de las carpetas que contenía estos archivos, CVS creaba una nueva rama para estos de manera no transparente. En muchas ocasiones nos vimos en la necesidad de corregir estos problemas. En Mercurial la creación de una nueva rama (branch) forma parte del día a día. Toda descarga de fuentes es en realidad una nueva rama. Esto ha obligado a los desarrolladores de Mercurial a que la gestión de ramas sea muy eficiente.
• Los problemas que hemos tenido con CVS al resolver colisiones. En ocasiones han desaparecido cambios muy costosos de recuperar. De su desaparición nos enteramos solo después de ver que nuestras pruebas unitarias fallaban de manera estrepitosa durante la integración. Mercurial es muy conservador para esto: no se mete a resolver colisiones de manera automática, sino que deja esta responsabilidad siempre en manos del desarrollador.
• La posibilidad de clonar directorios de manera tan sencilla nos facilita realizar copias de seguridad con más frecuencia. Sacar una copia de seguridad del CVS era un suplicio; sobre todo teniendo en cuenta que la copia se realizaba para todos los proyectos del repositorio incluidos los de los proyectos con los cuales compartíamos el repositorio. En Mercurial clonar un repositorio es tan fácil como copiar archivos, y además toda clonación lleva asociado su histórico de cambios.
• CVS no es transaccional. Dado que la máquina en la que está ubicado tiene problemas de estabilidad nos ha ocurrido varias veces que una subida de cambios se ha aceptado solo parcialmente. Mercurial es completamente transaccional.
• Necesitábamos una herramienta cuyos requisitos de instalación a nivel de permisos de administración fueran los mínimos posibles. En nuestro proyecto actual el entorno de desarrollo que nos ha facilitado el cliente no es tal entorno “de desarrollo”, ya que ni lo controlamos nosotros, ni es un entorno aislado (hay como 30 aplicaciones haciendo pruebas sobre la misma máquina).
• No tenemos posibilidad de realizar pruebas de usuario en nuestros entornos de trabajo antes de subir los cambios a un repositorio porque nuestra aplicación se conecta con sistemas externos a través de APIs que solo están instaladas en el entorno de integración. Además algunas de las librerías utilizadas solo funcionan sobre Unix, mientras que nuestros entornos de trabajo son Windows.
• Los mercados de tiempo real tienen unas condiciones de trabajo que son continuamente monitorizadas por los operadores de los mismos. Una incidencia puede dar lugar a multas millonarias. Es fundamental que podamos reproducir cualquier versión de manera rápida para corregir cualquier error. Por otro lado necesitamos la facilidad de poder agregar o quitar funcionalidad hasta pocos días antes de publicar una versión. Mercurial permite reproducir cualquier versión del histórico a partir de cualquier clon de cualquier rama de cualquier entorno, incluido el de los desarrolladores, con lo cual es muy fácil reproducir incidencias de manera rápida. También permite agregar cambios de distintas ramas de desarrollo de manera sencilla e individual.
• La aplicación es altamente concurrente, paralela, multi-hilo, y calcula productos financieros en base a modelos complejos. Es ventajosa la capacidad que da Mercurial al responsable de una rama estable. No son los desarrolladores quienes suben los cambios a la rama estable (modelo push), sino que es el responsable de esta rama quien va demandando los cambios a las ramas de los desarrolladores (modelo pull). Esto permite probar las aplicaciones en ramas de prueba, y posteriormente integrar los cambios individuales solo cuando ya han sido probados y revisados.
• Uno de los problemas que veíamos al uso de Mercurial era la integración con eclipse. Clonar repositorios nos obliga a clonar los proyectos y el workspace de eclipse para poder trabajar. Por suerte existe un plugin (Merclipse) que realiza esta tarea.

¿Cómo funciona el control de versiones?

Cuando un desarrollador descarga un proyecto del control de versiones, en realidad lo que está haciendo es clonar el repositorio de origen. No existen diferencias entre ambos repositorios después de la operación. Haciendo un símil con subversión, es como si cada desarrollador tuviera un servidor de subversión instalado en su equipo. Este “servidor” contiene toda la información histórica del proyecto.

Al clonar el repositorio se crean dos espacios:

• Repositorio público: Contiene el histórico de cambios. Es visible desde otros repositorios.
• Espacio de trabajo: Se genera a partir del histórico. El desarrollador solicita un “update” de una versión determinada, y Mercurial actualiza el espacio de trabajo para que contenga los fuentes de dicha versión.

A la hora de trabajar, un desarrollador realiza los cambios sobre su espacio de trabajo. Cuando quiere poner los cambios a disposición de los demás, este los sube al repositorio público mediante el comando “commit”. Desde este momento los cambios están visibles desde otros repositorios. Hasta aquí el modelo de trabajo es similar al de un control de versiones centralizado con la diferencia de que el servidor es propio de cada rama.

Cuando llega el momento de sincronizar dos repositorios distintos Mercurial ofrece dos comandos: “push” y “pull”. Push se emplea cuando se desea transferir cambios desde un repositorio a otro, y Pull se emplea cuando se desea tomar desde un repositorio los cambios de otro repositorio. Este segundo modelo es más seguro porque permite que un responsable determine qué es lo que le interesa que su rama contenga.

Con estas herramientas un desarrollador tiene capacidad de clonar un repositorio estable, y a su vez clonar esta rama de nuevo para implementar cada nueva funcionalidad por separado. De este modo pueden probarse e integrarse las funcionalidades de modo independiente.

En el caso de nuestro proyecto actual las ramas existentes son las siguientes:

• Rama estable: Es la rama desde la que se generan las versiones publicables. Ubicada en la máquina de integración. Está bajo control del responsable de proyecto y solo toma cambios desde las ramas de desarrollo.
• Ramas de desarrollo: Cada desarrollador tiene una rama en la máquina de integración para subir y probar sus cambios. Esta rama se clona desde la rama estable al comienzo de cada iteración. Una vez probados, estos cambios se revisan para asegurar que se están cumpliendo las especificaciones de desarrollo y las buenas prácticas establecidas. Hecho esto el responsable de proyecto realiza un pull e importa los cambios sobre la rama estable.
• Ramas locales: Cada desarrollador tiene una rama local principal que se clona a partir de su rama de desarrollo al comienzo de cada iteración. El desarrollador puede clonar tantas ramas a partir de esta como estime oportuno. Idealmente una por funcionalidad.

¿En que se diferencia de subversion?

Subversion es un sistema que nos gusta, pero no respondía a nuestras necesidades porque:

• Únicamente se puede tener un repositorio central. No nos resuelve la papeleta de tener varias ramas en el entorno de desarrollo.
• El esquema de versionamiento y el sistema de ramificación es mucho menos flexible. Nos permite realizar menos adaptaciones. Con Mercurial las políticas de ramificación, mezclado y subida de cambios son un mero evento social.
• No es capaz de funcionar en modo pull. Solo admite modo push, y nos ha gustado mucho el control sobre los cambios que nos da este esquema de funcionamiento.

Está muy chulo todo esto, ¿pero donde está la pega?

Las pegas que yo veo son las siguientes:

• Requiere por parte de los desarrolladores un cambio de mentalidad a la hora de trabajar con el control de versiones.
• Al ser muy flexible permite hacer muchas cosas bien, pero también muchas cosas mal. Obliga a ser muy disciplinado. Un símil a lo que pasa con C++ y JAVA.
• Las herramientas de usuario aún no están tan maduras como pueden estar las de subversión, CVS, u otros controles más populares. Sin embargo la línea de comando se la han currado mucho y es muy sencilla, muy coherente, y muy intuitiva.

¿De dónde puedo descargarlo?

Podéis descargarlo desde http://www.selenic.com/mercurial/wiki/. En este sitio Web hay manuales (muy buenos), ejecutables, código fuente y guías de ayuda rápida.
El plugin de Merclipse lo podéis descargar de http://www.goldenhammers.com/merclipse/.
¿Tengo que hacer algo en especial para instalarlo?
Nada. Se instala mediante un instalador. Instalar y ejecutar.

Poco antes de que se ponga a la venta oficialmente el T-Mobile G1, el primer móvil con Android, Google hace público el código fuente de Android, tal como exige la licencia de algunos de sus módulos.

Justo antes de que se ponga a la venta oficialmente el T-Mobile G1, el primer móvil con Android, Google hace público el código fuente de Android, tal como exige la licencia de algunos de sus módulos.

Es una de las primeras plataformas móviles que está disponible de forma íntegra, que permitirá a los usuarios y desarrolladores sin ninguna restricción y con la única condición de contribuir con la plataforma.

Hoy se ha lanzado Android Market, la tienda de aplicaciones para este terminal.

Los desarrolladores podrán registrarse y subir sus programas a partir del próximo lunes 27, para ello deberán de pagar 25 dólares, una vez cumplido este requisito podrán poner a disposición de la comunidad todas sus aplicaciones, sin necesidad de validación o aprobación.

A partir de comienzos de 2009, también podrán comenzar a distribuir sus aplicaciones de pago, por cada venta se llevarán el 70 %, el resto irá a las operadoras y a la gestión de la facturación, Google dice que no se quedará con ninguna parte.

Ayer 6 de Octubre ha salido oficialmente Mono 2.0. Entre otras características y mejoras, Mono 2.0 da soporte para C# 3.0 y Linq. Además se ha completado la implementación de Windows.Forms 2.0, ASP.NET 2.0 (con todos sus respectivos controles) entre otras APIs. Así que sólo queda descargarlo aquí y cacharrear con él.

Por cierto y como curiosidad, a la hora de elegir la plataforma para la descarga, es posible descargar una imagen de VMWare con openSUSE 11.0 con Mono 2.0 incluido, ideal para no perder el tiempo montandolo y poder probarlo directamente.

Google acaba de presentar su browser, Google Chrome:

La versión beta ( hay algún servicio de Google que no sea beta? ) se puede descargar de:

link

Como adelanto publicaron el fin de semana pasado un comic que detalla cada una de las nuevas características y es la mejor forma de conocer el navegador y sus características, es bastante técnico y visual al mismo tiempo:

link al comic

En vez de detallar las features como en todos los blogs del universo propongo discutir qué impacto pueden tener algunas features y qué opináis de la “fragmentación de la web”, para abrir el tema:

Una de las características más comentadas es el aislamiento entre los distintos tabs abiertos, cada uno corre en su propio proceso y el browser actúa como “coordinador”. Con ésto se tienen aislados los espacios de memoria de cada tab y un cuelgue en uno no afectará a otro… pero a cambio cada uno de los tabs tendrá su propio tamaño mínimo de stack, el código que use se cargará repetidas veces en cada proceso… y toda comunicación entre tabs y con el “browser coordinador” será mucho más costosa al ser “remota”.

El motor de javascript, V8, lo venden como la próxima maravilla del mundo: corre en una máquina virtual, entiendo que se precompila a un bytecode en vez de interpretarse, contiene heurísticas para detectar paths de ejecución repetidos y optimizarlos… veremos si sufre de problemas de compatibilidad con otros browsers( que posiblemente sean porque éste sea más fiel a un Standard que otros ).

La cantidad de browsers que una aplicación web debe soportar sigue creciendo y creciendo, desde distintas versiones del mismo navegador a los distintos navegadores disponibles. Todos hemos sufrido páginas webs que no funcionan bien en algún browser, incluso hemos visto o participado en webs donde el código cliente tiene 2 ramas, una para IE y otra para FF…

Dónde está aquella supuesta facilidad de despliegue y esa multiplataforma cuando puedes tener 8-12 browsers distintos y donde sabes que en algún momento saldrá otra versión de algún otro que será más o menos standard y tendrás que retocar-actualizar-probar tu aplicación web.

Todo esto lleva a otra discusión, cómo hemos partido de “la web original”, una arquitectura pensada para transmitir cadenas de texto con formato y mostrarlas por pantalla ( algo así como un visor de documentos simples remoto, sin estado ) a una plataforma de de aplicaciones a base de capas y capas y cantidades inmensas de “pequeños hacks” donde cada uno a ido por su lado. Esa es la historia de la web para lo bueno y para lo malo

Y otra batallita distinta va a ser opinar sobre los intereses de Google, claramente es un paso más en intentar llegar a un Sistema Operativo Web, que corra sobre cualquier SO. Está claro que la transición entre la “página web” donde se mostraba texto con un formateo muy básico y la “aplicación web” necesita avanzar muchos aspectos del browser.

Del 4 al 9 de mayo ha tenido lugar la JavaOne 2008. Este evento es similar a los TechEd de Microsoft, y en el muestran los últimos desarrollos habidos en la plataforma Java, así como las tendencias que se perfilan a medio plazo.
Habían prometido colocar todas las sesiones en PDF para finales de mayo, pero parece que van con retraso y de momento solamente se pueden encontrar unas pocas.
Estas sesiones las podéis ver en JavaOne 2008 Sesiones.
De las que hay publicadas algunas de las que me han parecido más interesantes son:

Top 10 Patterns for Scaling Out Java Technology-Based Applications
JRuby: Why, What, How…Do It Now
Applications for the Masses by the Masses: Why Engineers Are an Endangered Species

Las del año pasado sí están completas…JavaOne 2007

La forma más sencilla de conocer cuál es la tecnología que da soporte a una página web es fijarse en su URL (ej.: si vemos “.php” será PHP o si vemos “.aspx” será ASP.NET…), pero aunque esto es una información valiosa, sería más interesante si pudiéramos conocer la versión precisa del software empleado, el sistema operativo…
(more…)

Aquí os dejo el powerpoint (pdf por si acaso) que seguimos durante la charla Introducción al sistema Eclipse del día de 3 de Abril.

Introducción al Ecosistema Eclipse.ppt

Introducción al Ecosistema Eclipse.pdf

Si alguien, asistiese o no la charla, quiere más información que no dude en comentarlo.