Que trae de nuevo Eclipse Luna

Como todos los años, viene mi review de que puede parecer interesante en la nueva versión de Eclipse. Este año eligieron una palabra bien "castellana", le tocaba a la letra "L" (el nombre anterior había sido Kepler y el anterior Juno): Luna.

Lo más llamativo de esta versión es el soporte para java 8, pero ya veremos eso con más detalle. Inicialmente podemos apreciar un nuevo logo mucho más flat, acorde a estos tiempos. El splash-screen es mucho más chico y sobrio que antes, me parece acertado el cambio, lo hace más serio y más maduro. A simple vista parece mucho más rápido que las versiones anteriores, seguramente asociado a las mejoras que continuamente se implementan relacionadas a la performance.

Para repasar, comenzaremos con las mejoras en la plataforma, lo primero que llama la atención, es tener por fin el soporte para split editors, algo que es muy interesante y se puede acceder con un par de atajos de teclado.

Otra cosa interesante es el agregado de un nuevo tema dark, a simple vista me parece muy bueno, pero no me gusta como quedan algunos iconos, ya que se ve que quedan pixeles blancos en el borde (algunos fueron rearmados con formato png, pero quedan varios con problemas de transparencia todavía), es algo que deberían mejorar. Lo bueno, sin embargo, es que al fin lograron implementar de que no sea necesario reiniciar la IDE para que tome los cambios del nuevo tema seleccionado.

Nuevo theme

Otra de las cosas nuevas es que ahora hay dos modalidades para las vistas minimizadas, una que es la original, en la cual se muestran "flotando" sobre las demás vistas, cuando uno hace click en el ícono correspondiente; y una nueva en la cual en vez de mostrar la vista superpuesta, se muestra en su ubicación original. Personalmente creo que me sigo quedando con la versión original ya que prefiero que no afecte el layout de las demás vistas.

Otro de los pequeños detalles que si hacen la vida del programador un poco más fácil, es la opción de abrir un explorador de windows en la ubicación en la que se encuentra un archivo. Para acceder a esa opción, click derecho sobre el archivo, "Show in" y luego "System Explorer".

Bueno, luego moviéndonos a las mejoras para los desarrolladores java, la estrella es el manejo de la sintaxis nueva que trae java 8. Lo mejor es la conversión automática de código que puede representarse de mejor manera usando expresiones Lambda. Se puede hacer en un método específico o a nivel global.

Soporte para expresiones lambda

También se puede convertir de expresiones block a expresiones body de un solo paso y ver el método implementado por la instancia de la interfaz utilizada, simplemente pasando el mouse por encima del símbolo "->" o el "::".

Con la venida de las anotaciones de tipo (JSR 308), el compilador de eclipse lleva el análisis de posibles NullPointerExceptions al siguiente nivel, ya que prácticamente puede detectar todos los errores de este tipo en tiempo de ejecución. Solo es necesario utilizar las anotaciones @Nullable y @NonNull de forma correcta en la definición de los parámetros de los métodos.

El depurador también ganó nuevas características relacionadas a lo nuevo que trae java 8, como por ejemplo poner breakpoints adentro de las expresiones lambda.

Eso en lo que respecta a una pasada muy por arriba de las cosas nuevas en la versión base. También como es de costumbre, hay numerosos cambios en todo el ecosistema de plugins de este megaproyecto.

En fin, me parece que este año se notan un poco más las mejoras que en lo que fue kepler, más que nada por lo que es java 8. Igualmente se nota que el esfuerzo se imprime sobre los plugins y no sobre la IDE que sigue bastante parecida a la primer versión.

Alguna otra funcionalidad que valga la pena mencionar?

Saludos!

Evolución de las versiones de JAVA y .NET a lo largo del tiempo

Suelo tomar entrevistas a desarrolladores, y una pregunta que solía hacer hace unos años, era que me cuenten las diferencias que había (por ejemplo) entre las versiones de JAVA 1.4 y 5.0. Era un buen ejercicio como para repasar algunas de las características más usadas y además me parecía interesante ver como los candidatos me "presentaban" esas características. Los programadores más experimentados solían poner una cara de "al fin agregaron esto o esto otro", y los que no venían muy bien o no les interesaba, dejaban pasar cosas importantes sin ni siquiera mencionarlas.

Me pasaba algo parecido con la plataforma .NET de Microsoft, no se porque, a mi me pareció siempre interesante ver que cosas nuevas van agregando a los lenguajes y herramientas de trabajo que usamos todos los días a lo largo del tiempo.

Pensando un poco en todo eso, me propuse hacer un repaso de las características más sobresalientes de las dos plataformas, pero para no hacer tan aburrida la cosa, armé un timeline:

Las imágenes son clickeables y agregué en cada release algunas notas acerca de las características más importantes de cada uno.
Opinan que los releases son lo suficientemente frecuentes? Que versión de cada plataforma les pareció más interesante?

Fuente: Wikipedia

Maven: Como cambiar la versión de mi proyecto

Una de las quejas que suelo escuchar con respecto a Maven, es acerca de lo complicado que puede ser mantener las versiones de nuestros proyectos y componentes, actualizadas. Es verdad, si uno intenta hacerlo manualmente (es decir tocando "a pata" los pom.xml), es bastante engorroso y error-prone.

Hasta hace un tiempo existía una manera de, por ejemplo, incrementar la versión de todos los componentes, usando el plugin Release de Maven, pero ese plugin les da miedo a todo el mundo (es uno de los plugins más potentes y complejos).

Otra manera que he visto que se ha usado bastante, de mantener las versiones, es usar variables definidas dentro de los pom.xml padre, las cuales se replican en todos los pom.xml hijos. Si bien esta manera parece a primera vista, cómoda y elegante, si la ubicamos dentro de un contexto de releases frecuentes, involucrando a servidores de integración y sobre todo, al plugin de Release, termina siendo un problema, ya que no conozco manera de que dicho plugin "entienda" esas variables.

Digamos, pasando en limpio: es una forma más simple de seguir toqueteando los pom.xml de forma manual. Pero sigue siendo lo mismo.

Otro problema que tiene el enfoque anterior es que si estamos visualizando un pom.xml hijo, no sabemos cual es la versión actual, no nos queda otra que "subir" al pom padre y verlo ahí. De esto se deriva, de que si conseguimos ese pom.xml de algún artefacto, tampoco a primera mano, no tenemos forma de saber que versión es.

Corolario: La versión siempre debería estar presente en los pom.xml, el uso de variables para esto no es una buena idea.

Esto nos lleva al principio, como podemos hacer para trabajar con las versiones de los pom.xml, sobre todo cuando los proyectos son cada vez más y más grandes?

Y esto es solo la punta del iceberg, no hablamos acerca de, por ejemplo, como trabajar con las versiones de las dependencias de nuestros proyectos.

Ejemplo: pasaron 2 años de que nuestro proyecto está funcionando, y queremos mantener actualizadas las versiones de las dependencias, como hacemos? investigamos una por una cual es la última versión y vamos incrementando las mismas en cada sección dependencies de cada pom? ... y que pasa si nuestro proyecto tiene 50 modulos diferentes? como hacemos para incrementar las versiones de todos de forma simple?

Lo mismo para los plugins de maven que estamos usando ... en fin, debería existir algo para lidiar con estos temas, no?

Maven Versions Plugin

Por suerte hoy en día existe un buen plugin para trabajar con las versiones de nuestros proyectos. Este plugin tiene muchos goals, en los cuales destaco los siguientes:

• versions:display-dependency-updates: Muestra por pantalla las nuevas versiones que existen en los repositorios que usamos, de cada una de las dependencias de nuestros proyectos.
• versions:display-plugin-updates: Idem anterior, pero de los plugins de maven que utilizamos.
• versions:update-parent: Actualiza la versión de nuestro "pom padre" para que apunte a la última versión disponible. Esto es muy útil si contamos con un "super pom" en nuestra organización con definiciones comunes a todos los proyectos.
• versions:set: Este es el goal más interesante y más útil: lo que hace es justamente cambiar la versión de nuestro proyecto a nivel global. Es decir, si los componentes de nuestro proyecto tienen dependencias entre sí, las mismas también se actualizan.
• versions:use-releases, versions:use-next-releases y versions:use-latest-releases: sirven para reemplazar las versiones snapshots por releases, incrementar al próximo release o directamente reemplazar las versiones por el último release disponible
• versions:use-next-snapshots y versions:use-latest-snapshots: Lo mismo que lo anterior pero con SNAPSHOTS
• versions:commit y versions:revert: Permiten implementar todos estos cambios de forma pseudo-transaccional, es decir, si no estamos conformes con los cambios (o el proyecto no compila, o no corre) podemos volver a las versiones originales de los pom.xml

En fin, existen otros goals más, pero con estos ya se puede trabajar bastante bien con versiones de proyectos grandes de forma segura y rápida.

Se animan a usarlo?

Eclipse Kepler: Que hay de nuevo?

Hola, les cuento que si bien ya pasaron unos días que salió esta nueva versión de Eclipse, recién ahora me pude tomar unos minutos y pegarle una mirada.

Comencé leyendo un poco en los famosos New and Noteworthy, y la verdad que me quedó un sabor a poco en la boca. Esperaba más para un año de desarrollo de esta poderosa IDE.

Igualmente uno de los cambios que más promocionan son varias mejoras en la performance, por lo que me lo descargué y comencé a usarlo en algunos proyectos y comparar la velocidad con la versión anterior (Juno). Apenas lo descargué y lo utilicé, vi que el splash-screen es muy similar al anterior (Juno), no hubo un gran rediseño en esa parte.

Luego cuando terminó de cargar, noté que el look & feel sigue siendo el mismo que Juno, tampoco hubo un gran avance ahí. Lo primero que hago es sacarle el look & feel por defecto, y activar el clásico, ya que el nuevo no me gusta.

Luego, lo primero que hice fue descargar los plugins que más uso (subclipse, springide, hibernate-tools, vaadin, etc.), usando el Eclipse Marketplace. Como novedad, no fue necesario instalar Maven, ya vino con el soporte para esta herramienta incluida en la distribución. Como mala noticia, el plugin de Vaadin no funcionó, ya que no puedo abrir las pantallas para editarlas visualmente :(

Entre tantos reinicios y la mar en coche, note un poco más de velocidad, que haciendo la misma tarea en Juno, pero quizá puede ser un error de percepción.

Mientras instalaba los plugins, repasé las New and Noteworthy, y esto es lo que me pareció más interesante:

• Posibilidad de convertir de forma automática los if-then-else en sentencias switch
• Convertir los ifs, en ifs invertidos con sentencia return, para simplificar el código.
• Mejor manejo de herencia de anotaciones @Nullable
• Análisis de anotaciones @NonNull y @Nullable
• Análisis más avanzado para posibles resource leaks (ejemplo: dejar streams abiertos)
• Mejoras varias para la visualización de javadocs a nivel de paquete

Sustituir if-then-else con switch

Esto si hablamos de las mejoras de la IDE sin tener en cuenta los proyectos satélites, los cuales son los más jugosos. Acá lo interesante es que EGit se libera como parte de la distribución core, lo cual habla acerca de la importancia cada vez más creciente de Git en el mundo del desarrollo.

WTP (versión 3.5) tiene varios cambios, entre ellos soporte para Java EE 7, y las versiones más recientes de JSF, JPA y WebServices.

También anunciaron una nueva versión de Eclipse Orion, la IDE 100% web para desarrollar en Javascript. 

Personalmente creo que estaría bueno una versión para desarrollar en JAVA, ahí creo que estaríamos hablando de algo realmente impresionante.

Volviendo a las cosas que probé, una de ellas, fue abrir un workspace creado con Juno, no tuve ningún problema, lo abrió perfectamente sin tirar ningún error, lo cual es bueno para adoptarlo rápidamente.

Conclusión: muy pocos cambios para justificar un año de desarrollo. Si bien es una ide super completa y estable, creo que, o tienen que invertir más en marketing, anunciando de forma un poco más clara las cosas nuevas de los proyectos satélites, o bien dedicarse a agregar características más innovadoras.

Ahora no me parece extraño que en Google hayan elegido abandonar a Eclipse como IDE para desarrollar extensiones para construir aplicaciones en Android, y hayan migrado a InteliJ Idea.

Ustedes encontraron alguna otra característica interesante?

Nos leemos!

Plugins Imprescindibles para Jenkins

Hola, hoy quiero hablar un poco acerca de uno de los proyectos que personalmente más me gustan: Jenkins. Soy seguidor de este server de integración continua, desde que tenía otro nombre (Hudson) y luego fue renombrado (hablé acerca del tema en otro post).

Para los que no lo conocen, se trata de un Servidor de Integración Continua, muy poderoso (prácticamente el más usado a nivel mundial) y además open-source y con una comunidad muy activa (tienen releases semanales).

Para comenzar no me parece mal contarles acerca de algunos plugins que creo que son muy interesantes y hasta imprescindibles, si queremos montar uno de estos servers para tener mayor control en la construcción de proyectos JAVA (inicialmente, más adelante les voy a contar acerca de como construir proyectos .NET también). Voy a obviar los más conocidos (plugins de reportes de cobertura, PMD, CPD, etc.):

• ThinBackup Plugin: Este plugin sirve para programar de forma automática la tarea de hacer backup de la configuración de nuestro servidor. Obviamente se pueden hacer backups manuales en cualquier momento, y también recuperar cualquiera de los creados previamente. Tiene muchas cosas interesantes, como por ejemplo la posibilidad de armar backups incrementales, backups full, borrar backups viejos, etc. Muy completo y necesario para quedarnos tranquilos de no perder toda la configuración que tanto tiempo nos lleva armar.
• Build Failure Analyzer: Este plugin es bastante reciente, pero lo encuentro muy útil. Permite definir patrones recurrentes en los logs de builds que fallan, definiendo el nombre de la falla y una descripción. De a poco podemos ir armando una base de conocimientos de fallas de build, lo que le sirve a los desarrolladores para identificar rápidamente la causa de un fallo. Está bueno tenerlo instalado cuanto antes, entonces de a poco vamos armando una buena base de fallas conocidas.
• Configuration Slicing Plugin: Este plugin lleva unos años, pero es muy útil a medida que la cantidad de jobs de construcción va creciendo y se torna dificil de manejar. Este plugin permite cambiar algunas opciones de configuración de los jobs de forma masiva, evitándonos tener que ir uno por uno, cambiando lo que queremos en cada job. Imprescindible.
• Contitional Build Step Plugin: Este plugin es muy poderoso y muy útil si queremos automatizar tareas. Lo que hace es básicamente darnos la opción de partir nuestro job en múltiples pasos los cuales son opcionales, basados en la evaluación de una condición, las cuales se pueden elegir desde varias disponibles, como por ejemplo, la evaluación del valor de una variable de entorno, de un parámetro, etc. Muy útil en la medida de que nos animemos a hacer cosas cada vez más complejas.
• Monitoring: Este plugin implementa Java Melody en nuestro servidor. Java Melody, es una de las plataformas de monitoreo de aplicaciones Java más completas que conozco, del mundo open-source. Permite monitorear prácticamente todos los aspectos interesantes de nuestro server (uso de memoria, cpu, disco, etc.) para encontrar y diagnosticar problemas. Muy recomendable.
• Sectioned View Plugin: Este plugin si bien no es tán útil al principio, a medida que empezamos a tener una gran cantidad de job, se vuelve necesario. Permite definir "Secciones" en las cuales mostrar los jobs que machean una expresión regular. Es una buena manera de categorizar los jobs, por proyectos / clientes / etc.
• Shelve Project Plugin: Este plugin es interesante para los que no quieren perder absolutamente nada de información: permite hacer un backup y eliminar los jobs viejos que no se usan más. También se puede volver a recuperar el job de una forma fácil y simple. Lo interesante es que almacena el job en formato comprimido, para ahorrar espacio en disco.
• Validating String Parameter Plugin: Cuando nuestros jobs comienzan a ser más complejos (sobre todo cuando armamos jobs que hacen tareas automatizadas), seguramente vamos a necesitar parámetros cada vez más complejos. Este plugin permite agregar condiciones de validación a los parámetros, para evitar cometer errores al ingresarlos. Por ejemplo, si necesitamos una url de svn como parámetro, podemos definir una expresión regular simple, para evitar que se ingresen urls mal formadas. Permite poner mensajes de validación específicos por cada validación.

Bueno, con estos tienen un buen vistazo de algunos plugins no tan conocidos quizá, pero no por eso dejan de ser bastantes útiles. Quedaron muchos otros fuera del análisis, pero bueno, los veremos más adelante.

Conocen algún otro que les parezca imprescindible tener?

Nos vemos en el próximo post.

PD: A propósito, hacía tiempo que no tiraba algo al blog, prometo volver a la carga! ... de paso para los que visitaban antes el sitio, hice un rediseño para hacerlo más amigable, espero que les haya gustado!

Herramientas para acceder a recursos del servidor

Hoy voy a contarles de un par de herramientas que me parecieron interesantes, para cuando tenemos el caso de que en algún entorno (producción / preproducción / etc.), se nos dificulta acceder a recursos necesarios para poder mantener nuestros aplicativos. En este caso apunto a dos recursos en particular: el filesystem y la base de datos.

Accediendo al Filesystem

En este caso, me encantó la simplicidad de esta herramienta, no se trata de nada más ni nada menos que un simple archivo .jsp El proyecto en particular del que les hablo es jsp File Browser.

Es básicamente una JSP (y opcionalmente una hoja de estilos) que si la agregamos en nuestro aplicativo JEE, nos ofrece un simple pero poderoso FileBrowser del lado del server. Para instalarlo simplemente tenemos que copiar dicha página en cualquier directorio del contenido web de nuestros aplicativos java. Luego para acceder simplemente tipeamos accedemos a dicha jsp directamente. 

Obviamente que una alternativa válida, es embeberla dentro de un iframe, y dejarla disponible como una opción de menú a la cual, solo los administradores pueden acceder.

La jsp nos permite poder browsear el filesystem del server, pero ademas, poder aplicar las siguientes acciones:

Operaciones de archivos y directorios: Create Dir, Create File, Move File, Copy Files, Rename File, etc. Creo que son bastante autoexplicativas

Upload File, para subir archivos Download Selected Files as a Zip, nos permite descargar los archivos como un zip

Además podemos visualizar los archivos (viene muy bien para, por ejemplo, ver los logs de nuestro aplicativo) y tambien nos da la opción de editar archivos.

Accediendo a la base de datos

En este caso les voy a contar de algo un poco más completo que la herramienta anterior.

Se trata de un explorador de base de datos web. A diferencia del anterior estamos hablando de todo un aplicativo web, que se puede descargar e instalar como una aplicacion web java (archivo .war).

El proyecto en cuestión es dbideas. Está basado en el exitoso framework web extjs.

Es interesante porque muchas veces es complejo poder alcanzar las bases de datos de ciertos entornos, entonces mediante esta herramienta podemos hacerlo mientras podamos acceder a dicho server vía web. Permite gestionar múltiples conexiones a diferentes bases de datos, y soporta varios dialectos. 

La interfaz recuerda a proyectos tales como DBVisualizer y SQuirrelSQL, pero vía web. Obviamente que con muchisimas menos funcionalidades. Igualmente permite ejecutar sentencias SQL arbitrarias y sentencias de modificación de la estructura de la base de datos. Además en diferentes pestañas se puede ver información de Primary Keys, Foreign Keys, etc. En este caso, quizá, lo conveniente es modificar el archivo web.xml y agregar restricciones de seguridad para que solo usuarios administradores puedan acceder.

Las dos herramientas parecen viejas, y no descarto probablemente de que haya mejores y más actualizadas, pero en poco tiempo fue lo mejor que pude encontar para necesidades puntuales que estaba teniendo. Un detalle no menor, es que las dos están disponibles para su uso gratuito.

Espero que les haya interesado y nos vemos en el próximo post!

Que son las transacciones declarativas?

Varios conocen como se configuran las transacciones en Spring o frameworks similares, pero no muchos saben las ventajas por las cuales conviene utilizar este tipo específico de demarcación de transacciones. Voy a intentar contarles un poco acerca de que problemas soluciona este tipo de configuración, en contraposición a manejar las transacciones de forma programática.

Hace mucho, mucho tiempo, en una galaxia muy lejana, los programadores se encontraron frente al desafío de tener que lidiar con transacciones, según la definición wikipedista: "Una transacción es una interacción con una estructura de datos compleja, compuesta por varios procesos que se han de aplicar uno después del otro. La transacción debe realizarse de una sola vez y sin que la estructura a medio manipular pueda ser alcanzada por el resto del sistema hasta que se hayan finalizado todos sus procesos."

El enfoque programático

Para poder permitir que esa estructura a "medio manipular" pueda ser alcanzada por el resto del sistema, el primer aproach, fue el de utilizar dos sentencias para poder definir el inicio y el fin de la porción de código que lidiaba con un fragmento transaccional: es decir los famosos "begin" & "commit", con su infaltable contraparte "rollback".

Esas tres sentencias se usaron por mucho tiempo para manejar transacciones, y hoy en día mucha gente piensa que es la forma mediante la cual hay que lidiar con las mismas. En realidad no hay problemas en utilizar esto, pero a medida que los sistemas aumentan en complejidad, comienzan a notarse las falencias de este enfoque.

El primer gran problema es que claramente esto se trata de un "aspecto" del código que desarrollamos, y como tal, puede traer problemas si no es siempre tratado de similar manera. Por lo tanto es necesario implementarlo de forma separa de nuestro código para evitar olvidos o la posibilidad de codificarlo de forma diferente para cada funcionalidad.

Pero el verdadero gran problema es que el código tiene a complicarse mucho, si tenemos el caso de varias clases con diferentes métodos de lógica de negocio que se invocan entre sí. Cuando esto sucede, lo que normalmente se requiere, es que los métodos puedan "compartir" las transacciones entre sí, de tal manera de que solo uno de los métodos la inicie (el primero en ser invocado por la capa de presentación) y luego los otros utilicen este contexto transaccional ya creado. Esto normalmente se conoce como "propagación" de la transacción.

Si esto no se implementa de una forma declarativa, es decir "declarando" como cada método va a utilizar el aspecto de la transaccionalidad, es muy dificil de lograr un comportamiento similar, sin caer en el caso de tener que usar varios flags que se pasen como parámetro y cadenas de if que aumentan su complejidad a medida de que se van encadenando más y más métodos.

Declaremos

Utilizando Spring, como framework de inyección de dependencias, existen tres maneras de utilizar el enfoque declarativo, al momento de definir las transacciones de nuestro código:

• Utilizando Proxys: Este es el enfoque más antiguo. Lo que hacemos es generar de forma dinámica un sustituto de nuestro Servicio, que lo que hace es agregar el manejo de transacciones, antes de cada método que respete un patrón de nombres que podemos especificar. Estos proxys se definen de una manera similar a la siguiente:

1:       <bean id="abstractTransactionManager" abstract="true">  
2:            <property name="transactionAttributes">  
3:                 <props>  
4:                      <prop key="save*">PROPAGATION_REQUIRED,ISOLATION_READ_COMMITTED</prop>  
5:                      <prop key="remove*">PROPAGATION_REQUIRED,ISOLATION_READ_COMMITTED</prop>  
6:                      <prop key="update*">PROPAGATION_REQUIRED,ISOLATION_READ_COMMITTED</prop>  
7:                      <prop key="ejecutar*">PROPAGATION_REQUIRED,ISOLATION_READ_COMMITTED</prop>  
8:                      <prop key="*">PROPAGATION_REQUIRED,readOnly,ISOLATION_READ_COMMITTED</prop>  
9:                 </props>  
10:            </property>  
11:       </bean>  
12:       <bean id="feriadosManager" parent="abstractTransactionManager" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">  
13:            <property name="target">  
14:                 <bean id="feriadosService" class="com.example.mysystem.service.FeriadosService">  
15:                      <property name="feriadosDAO" ref="feriadosDAO" />  
16:                 </bean>  
17:            </property>  
18:            <property name="transactionManager" ref="transactionManager_gateweb" />  
19:            <property name="proxyTargetClass" value="true" />  
20:       </bean>  

• Utilizando Spring AOP: Como Spring tiene el "poder" de instanciar nuestras clases, el mecanismo de proxys se puede implementar de una forma aún más dinámica, definiendo la teoría de aspect-oriented-programming, con el sabor de Spring:

1:       <tx:advice id="commonTxAdvice" transaction-manager="transactionManager">  
2:            <tx:attributes>  
3:                 <tx:method name="save*" propagation="REQUIRED" />  
4:                 <tx:method name="remove*" propagation="REQUIRED" />  
5:                 <tx:method name="delete*" propagation="REQUIRED" />  
6:                 <tx:method name="update*" propagation="REQUIRED" />  
7:                 <tx:method name="execute*" propagation="REQUIRED" />  
8:                 <tx:method name="*" read-only="true" />  
9:            </tx:attributes>  
10:       </tx:advice>  
11:       <aop:config>  
12:            <!-- Pointcut -->  
13:            <aop:pointcut id="servicePointCut" expression="execution(* com.example.mysystem.service.impl.*.*(..))" />  
14:            <!-- Advisor -->  
15:            <aop:advisor advice-ref="commonTxAdvice" pointcut-ref="servicePointCut" />  
16:       </aop:config>  

De esta manera no es necesario recordar envolver a nuestros beans de servicio con un proxy transaccional, ya que se hace de manera automática de acuerdo al nombrado de los paquetes y de los nombres de los métodos. Esta manera es, según mi opinión, la mejor, ya que requiere mucho menos código y es más fácil de implementar.

• Utilizando anotaciones: En este caso, utilizamos una anotación sobre el servicio que queremos que posea un comportamiento transaccional. La anotación utilizada es @Transactional:

1:  @Transactional  
2:  public class DefaultFooService implements FooService {  
3:    Foo getFoo(String fooName);  
4:    Foo getFoo(String fooName, String barName);  
5:    void insertFoo(Foo foo);  
6:    void updateFoo(Foo foo);  
7:  }  

Lo bueno de todo esto, es que los tres approachs se pueden usar side-by-side, sin ningún problema.

Igualmente hay que recordar, que dependiendo del enfoque, hay que tener en cuenta algunas configuraciones especiales. Lo mejor es, después de este artículo, pegarle una leída a la documentación oficial, que debería ser el primer lugar al cual referirse cuando se quiere conocer como se implementa algo utilizando un framework basado en una comunidad.

Antes que me olvide: no nos olvidemos que spring no es el primer framework y/o estándar en aplicar esta forma de manejar las transacciones, esto ya se viene implementando de una forma similar, desde los tiempos de los EJBs. Otros frameworks de DI, también tienen aproachs similares.

Nos vemos en el próximo post!

Eclipse Juno: Primeras impresiones

Todavía me estoy descargando la nueva versión de eclipse, pero ya tengo ganas de escribir un poco acerca de lo que pude advertir en las notas de lo nuevo que trae este release de una de las IDES más usadas para programar en lenguaje JAVA, y algunos otros como PHP, C++, etc.

Eclipse es un megaproyecto que, seguramente como a varios colegas, prácticamente me acompañó en toda mi vida de programador JAVA. Cuando me refiero a megaproyecto, me refiero a que ya tiene más de 20 años, lo cual no es poco en la vida de una IDE. También me refiero a que en realidad no es un único proyecto isolado, sino que es una organización incubadora de pequeñas joyas (como Mylyn, WTP, etc.) que viven dentro del ecosistema del mismo nombre.

Para los que no lo conocen (si es que hay alguien) o que no siguen los releases, hace un tiempo que se adoptó el formato de releases sincronizados anuales, con un nombre relacionado a lunas, dioses antiguos o científicos famosos. Esto fue necesario por la enorme cantidad de proyectos con versiones que dependen entre si (por ejemplo ahora fue un release de 72 proyectos simultáneos).

Nuevo y que valga la pena anotarlo

Leyendo un poco las famosas New and Noteworthy, lo primero que vemos es que despues de mucho tiempo, se optó por hacer un profundo rediseño del look & feel. La razón es adoptar un enfoque más moderno, y ocultar un poco de líneas, sobre todo en los elementos que no tienen el foco. Personalmente por lo que pude ver en las capturas, no me parece feo, pero me da la impresión de que tiene muchos espacios no aprovechados.

Relacionado a la usabilidad, pareciera que todos los elementos son un poco más flexibles. Ahora las vistas se pueden situar en el espacio de los editores, esto viene muy bien para vistas que muestran mucha información (como por ejemplo la Problems View). También se pueden disponer de forma dividida, para poder maximizar un editor, y al mismo tiempo tener una vista en la misma zona. Relacionado a esto, ahora los editores se pueden desatachar y convertirse en ventanas independientes.

Una cosa que me pareció curiosa, es que se puede seleccionar una intersección de vistas, y arrastrando se pueden dimensionar varias vistas al mismo tiempo.

Una de las cosas que por mucho tiempo diferenció a eclipse de otras IDEs, es que mantiene un "estado" de los archivos, interno e independiente de lo que ocurre por fuera de la IDE. Es decir que si uno tocaba un archivo con un editor externo, luego al trabajar con Eclipse, era necesario hacer un "refresh" (F5) sobre el mismo, para que tome los cambios. Ahora en esta nueva versión, existe un mecanismo habilitado por defecto, que lo que hace es hacer esa actualización de forma automática y en background.

Con respecto a lo que me pareció más llamativo, de lo nuevo que trae para los desarrolladores JAVA, tenemos resaltado de las llaves que engloban al código sobre el cual estamos parados (antes solo se hacía cuando estábamos parados sobre una de las llaves), posibilidad de asociar un editor a los archivos .class que no tienen código fuente asociado (antes era para todos los .class), detección de leaks cuando trabajamos con recursos y diferentes análisis para cuando trabajamos con las anotaciones @NonNull y @Nullable.

En fin, no son muchas cosas (igualmente acá estamos hablando solamente del core de la IDE, probablemente existan muchos más cambios en los proyectos satélites como WTP, etc.), pero vale la pena probarlo, ya que probablemente junto con estos new features, probablemente haya muchos bugfixes.

Terminé de bajarlo, asi que lo pruebo y les cuento!

El software libre en acción

Hace muchos años, desde que conocí el concepto de software libre, pase por varias etapas. Al principio: me preguntaba constantemente: cómo puede ser rentable y mantenible una idea semejante?, luego de un tiempo, de comenzar a sacudirme de encima todos los preconceptos que un joven freelancer amateur puede tener encima, comencé a darme cuenta de la importancia de las ideas sobre el código, y la importancia que puede tener alguien, por entender realmente el producto o servicio que desarrolla, mantiene y vende. Finalmente pase a entender que gracias al software libre, la relevancia de las ideas y las ganas de llevar a la realidad lo que uno tiene en la cabeza, superan ampliamente al concepto tan antiguo de que el código es algo similar a una cosa física que uno construye y vende.

Pero bueno, volviendo un poco al post, tenía ganas de contarles acerca de tres casos diferentes en magnitudes, pero relacionados entre sí, que a mi entender, demuestran como gracias al software libre, se pueden superar barreras que con software pago y licenciado, no se podían pasar.

CASO 1: DB DESIGNER

Hace unos años, cuando estaba comenzando a desarrollar un sistema, me tocó elegir algún soft, en lo posible gratuito, para poder hacer diseño de modelo de datos, y llegué al DB Designer. Era una herramienta interesante, porque permite trabajar cómodamente con diagramas que podían crecer bastante en tamaño, sincronizar con la base de datos los cambios, generar los scripts de generación de tablas con muchas opciones diferentes, etc. Como el proyecto en cuestión, debía correr contra una base MySQL, pude usar sin problemas la herramienta, ya que estaba específicamente diseñada para trabajar con dicho RDBMS. En realidad esto era un problema, ya que si hubiese necesitado otro Vendor de base de datos, no hubiese podido utilizarla.

Hace poco me surgió una necesidad similar, pero para PostgreSQL, y, habiendo olvidado de esa restricción, opté por descargar DBDesigner para trabajar. Cuando quise hacer una exportación, recordé de que solo funcionaba con MySQL. Fue entonces que visité la página de FabForce, incrédulo de que después de tanto tiempo no hubiesen desarrollado algún plugin, o algo parecido, para poder exportar a otra base … pero nada.

Después de un par de búsquedas, me encontré con DBDesigner Fork. Como su nombre lo indica, se trata de un fork, que agrega soporte para muchas bases de datos, entre ellas PostgreSQL. Luego de descargarla, pude importar el modelo y lograr lo que necesitaba.

CASO 2: TWITTER Y SU VERSIÓN DE MYSQL

Si bien estamos hablando de otra magnitud, es algo, a mi parecer, comparable.

Hace poco me enteré de que Twitter publicó un fork de MySQL con algunas características interesantes, como por ejemplo:

• Nuevas variables de estatus para el motor INNODB
• Optimización del acceso a memoria no uniforme (NUMA)
• Timeout de las querys del lado del servidor
• Exportación y restauración del pool de conexiones de manera más liviana
• Optimización para dispositivos SSD

Me pareció una muy buena idea, y una muy buena movida por parte de twitter. Tomar algo que es bueno, adaptarlo para mis necesidades, y retroalimentar a la comunidad con este desarrollo.

CASO 3: JENKINS

Bueno, para los fanas como yo de la integración contínua, esto no es algo desconocido.

El proyecto Hudson, construido prácticamente entero, por uno de mis ídolos, Kohsuke Kawaguchi, comenzó como uno de los desarrollos open-source de SUN, quien luego fue adquirido por Oracle. Luego de la adquisición, Kohsuke deja la compañía, pero continúa trabajando en el proyecto. Oracle intenta influenciar el proyecto, de tal manera que cambia un poco la visión que el creador y mentor tenía sobre el producto, por lo cual él, y la comunidad de desarrolladores de extensiones, deciden hacer un fork del proyecto, cambiándolo de nombre. Pasa a llamarse Jenkins.

Cuando me enteré de esta decisión, no pude evitar pensar, de que prácticamente nadie se tomaría el trabajo de actualizar algo que ya de por sí funcionaba bien, a una versión ya no sponsoreada por el gigante Oracle, con otro nombre, y probablemente con muchos problemas de incompatibilidades.

Estaba muy equivocado, el fork estuvo excelentemente planificado, el swap era extraordinariamente simple, prácticamente no hubo incidencias, y gran parte de la comunidad comenzó a seguir a este branch, se siguieron creando muchísimos plugins más, y los mejores plugins continuaron siendo actualizados bajo este nuevo emprendimiento.

En fin, son tres casos de miles, diferentes entre sí, que me recuerdan que cuando uno desarrolla una pieza de software, lo que hace es materializar la idea del producto que uno tiene en su mente, si a esto le sumamos las ganas y la fuerza de la motivación, el software libre puede ayudar a mantener vivas nuestras creaciones y ayudar a que todos usemos estas herramientas para mejorar lo que hacemos día a día.

STAND for Android: Un buen comienzo

Investigando un poco acerca de si existía algún buen archetype para desarrollar una aplicación en Android, llegué a este proyecto que me pareció interesante. STAND for Android, sirve principalmente para comenzar un buen desarrollo, con todas las herramientas para hacerlo sólido.

Utiliza Maven, para controlar el ciclo de vida del proyecto, versiones, dependencias, etc.

Permite crear proyectos con configuraciones predefinidas de forma óptima, como ser logging, testing, etc.

Opcionalmente, las aplicaciones generadas pueden crearse ya listas, para ser publicadas en el android market.

Para comenzar a utilizarlo, es muy simple para los que están acostumbrados a utilizar el plugin de archetypes de maven, simplemente hay que correr alguno de los comandos indicados en el sitio de stand.

Luego de ejecutar algunos de los archetypes, se generará un proyecto multimódulo, con un apartado especial para los tests de integración.

Obviamente ya viene preconfigurado para usar el plugin de maven para android, y tambien todas las configuraciones necesarias para poder sacarle el provecho a las extensiones de eclipse para trabajar con Android.

Es interesante el apartado de tests de integración, ya que uno de los módulos generados está listo para correr este tipo de tests sobre la nueva aplicación.

Todo lo que vimos hasta ahora es la parte de creación de un proyecto en blanco para poder empezar a trabajar, pero eso no es todo. Ademas existen otros cuatro frameworks interesantes:

• Rindirect: Es un plugin de maven, que permite facilitar la reutilización de codigo, a traves de varios proyectos diferentes, solucionando los problemas conocidos de dependencias y colisión de paquetes.
• Androlog: Es una pequeña libreria para tener logging dentro de nuestras aplicaciones Android
• Marvin: Es una libreria de testing unitario, que permite facilitar la creación de tests complejos, sobre todo relacionados a la ejecución de actividades, etc.
• Roboject: Es un framework de inyección de dependencias mediante anotaciones para Android.

En fin, un conjunto interesante de herramientas para no tener que reinventar la rueda.

Maven: Dependencia entre wars

Por lo general, en todo proyecto empresarial JAVA, surge al momento de definir la arquitectura del aplicativo, definir el concepto de modulo, subsistema, y por que no, sistema. Al momento de tomar estas definiciones con un aplicativo en particular, surgen muchas maneras de realizar esta división, pero si tenemos en mente el stack de tecnologías JAVA estándares, para la Web, en algún momento, sobre todo dependiendo del tamaño del proyecto, vamos a llegar a la pregunta del millón: conviene separar mi capa de presentación por módulos?

Desde el comienzo, incluido en todo lo que nos ofreció el stack de tecnologías para aplicaciones empresariales de JAVA, nunca hubo un buen soporte para realizar esto, que a simple vista resulta prácticamente básico, poder “partir” mi aplicación en módulos independientes, pero en cierta manera “unidos” entre si, mediante el concepto de aplicación empresarial. Si bien se podían embeber varios paquetes “war” dentro de un único bundle “ear”, eran aplicaciones prácticamente independientes, y, era muy difícil por ejemplo, reutilizar código, ya que un WAR no es una librería (JAR) como tal.

Con la aparición de Maven, el WAR comenzó a ser un módulo más, por lo que surgió naturalmente el concepto de tratarlo como un paquete de código en si. De todas maneras los primeros intentos por lograr la tan ansiada dependencia, no vinieron de los plugins “core” sino de terceros, por ejemplo el goal maven:uberwar de cargo, o el plugin warpath de AppFuse.

Estos plugins si bien lograban su cometido, no eran la forma más natural de poder establecer dependencias entre los módulos WAR y así lograr por ejemplo, la reutilización de código de capa de presentación.

Igualmente ustedes dirán, “pero si queremos reutilizar, porque no metemos el código en librerías JAR?”, el problema viene justamente por lo que decía al principio, hasta hace no tanto, el estándar JEE, no permitía que, por ejemplo, las páginas JSPs u otros recursos WEB vengan embebidas en librerías. Si podríamos reutilizar ese código y tener en un componente principal recursos comunes, y en otros componentes simplemente referenciarlos, se disminuiría un montón el código de varias aplicaciones similares o módulos de una aplicación grande.

Otro problema venía por el lado de las IDEs, si bien podíamos resolverlo quizá, con los plugins que mencioné anteriormente, la IDE por lo general no se “daba cuenta” de esta dependencia, y había que lograr que funcione usando trucos extraños.

La solución

Por suerte se logró solucionar este problema con la última versión del plugin que administra la construcción de archivos war de maven, el maven-war-plugin.

Ahora para poder reutilizar código, podemos usar tranquilamente la dependencia entre wars, que funciona de la siguiente manera.

Supongamos que tenemos un proyecto WAR, denominado “proyecto-comun”, el cual posee clases y recursos comunes a ser reutilizados en otros modulos WAR.Además tenemos un proyecto WAR, denominado “proyecto-nuevo”, el cual necesita reutilizar clases bases y recursos existentes en el proyecto anterior. Para lograr la dependencia, tenemos que agregar las siguientes configuraciones: En el “proyecto-comun”, debemos agregar lo siguiente en el pom.xml:

 <plugin>  
      <groupId>org.apache.maven.plugins</groupId>  
      <artifactId>maven-war-plugin</artifactId>  
      <configuration>  
           <attachClasses>true</attachClasses>  
           <webModule>  
                <groupId>com.miempresa</groupId>  
                <artifactId>proyecto-comun</artifactId>  
                <contextRoot>/proyecto-comun</contextRoot>  
           </webModule>  
      </configuration>  
 </plugin>  

Acá lo importante es el tag “attachClasses”, que le dice a maven que cree un artefacto secundario con las clases del proyecto, las que más adelante nos van a servir para poder compilar el mismo.

Luego en el “proyecto-nuevo”, tenemos que agregar lo siguiente:

 <dependency>  
      <groupId>com.miempresa</groupId>  
      <artifactId>proyecto-comun</artifactId>  
      <version>1.0.0-SNAPSHOT</version>  
      <type>jar</type>  
      <classifier>classes</classifier>  
 </dependency>  
 <dependency>  
      <groupId>com.miempresa</groupId>  
      <artifactId>proyecto-comun</artifactId>  
      <version>1.0.0-SNAPSHOT</version>  
      <type>war</type>  
 </dependency>  

La primer dependencia, indica que las clases se deben compilar teniendo en cuenta el JAR generado automáticamente por el primer proyecto, y la segunda, que luego de compilar, primero copie los recursos del war anterior y luego sobre ese, los recursos del war actual, reutilizando archivos jsps, css, imagenes, xmls, etc.

Lo bueno de esta técnica, es que funciona correctamente con Eclipse (por las dudas usar siempre la última versión), utilizando el plugin m2eclipse, que por el momento es lo mejorcito que existe para trabajar con proyectos maven. La IDE correctamente interpreta la dependencia, y si tenemos los dos proyectos importados, ni siquiera hay que ejecutar el comando “mvn install” sobre el “proyecto-comun” para que tome los cambios, los toma automáticamente.

Que falta

De todas maneras existen algunos puntos sin resolver todavía:

• No tenemos soporte para “mergear” el archivo web.xml, por lo que el web.xml del “proyecto-comun” va a ser pisado por el del “proyecto-nuevo”
• Hay que tener cuidado de no crear clases en los mismos paquetes y con los mismos nombres, porque van a ser ignoradas (suponiendo que el application server le de prioridad a las clases del directorio “classes”)

Igualmente es una mejora substancial con lo que había antes, y permite tratar el código de presentación, prácticamente como si se tratase de una librería común, respetando su propio ciclo de vida, relacionado a las versiones, empaquetado, etc.

AppScale: Despegándose de AppEngine

Leyendo un poco acerca de las particularidades de Google AppEngine, llegué a este proyecto que me pareció bastante interesante.

AppScale es un conjunto de herramientas que permiten correr aplicaciones diseñadas para Google AppEngine, pero utilizando otras plataformas de servicio en la nube, como Amazon EC2.

Me pareció interesante el concepto, ya que da mucha tranquilidad a los que están montando servicios y posibles negocios en la nube de google. No tuve la oportunidad de probarlo, pero por la documentación, la idea es que se trata de un aplicativo instalable en un Linux (Ubuntu), que permite agregar aplicaciones listas para ser deployadas en AppEngine.

La distribución trae directorios por cada lenguaje que soporta la plataforma (go, java y python), en los cuales hay varios ejemplos para tomar como base. Igualmente hay que tener en cuenta que no todos los servicios son soportados. Se puede consultar la grilla de compatibilidad para ver el detalle por lenguaje. 

Igualmente lo que me parece más interesante es el soporte del Datastore y del Blobstore, ya que eran características que si uno las utilizaba, no permitía migrar fácilmente a otro tipo de plataforma. También se pueden descargar máquinas virtuales preconfiguradas, listas para ser instaladas en las plataformas de virtualización más conocidas. Incluso tiene una versión pública de imagen lista para ser utilizada en Amazon EC2 o Eucalyptus.

Excelente para perderle el miedo a AppEngine.

WebSphere+Eclipse

​Hace poco me enteré que IBM liberó una versión de WebSphere 7.0 para desarrolladores, y también el toolkit para poder utilizarlo en eclipse.Me embarqué en la tarea de bajarme las herramientas y probarlo.Para instalar el plugin de eclipse, la cosa fue bastante simple, ya que utilice el Eclipse Marketplace y lo pude instalar sin problemas (aunque la descarga es importante y lleva un tiempo acorde al tamaño). Un comentario importante: es probable que cuando reinicien el Eclipse luego de instalarlo, les advierta que es necesario utilizar la JDK de IBM. Este error lo solucionan más adelante cuando tengan instalado el servidor, ya que viene con la JDK embebida.Luego vino la parte complicada, ya que es necesario tener instalado el servidor (el plugin no trae incorporado un server express o algo parecido).Para ello es necesario instalar el IBM Installation Manager. Luego de instalarlo probablemente les pida actualizarlo, lo cual se puede hacer sin problemas. Luego es probable que no les cargue la lista de repositorios (a mi me paso por la autenticacion del proxy). Pero luego uno puede editar los repositorios y ahi si agregarlo. En este caso use este: 

• http://www.ibm.com/software/repositorymanager/V8WASDeveloperILAN

Luego de varios diálogos lo pude instalar finalmente. Les paso los links:

• http://www.ibm.com/developerworks/downloads/ws/wasdevelopers/
• http://marketplace.eclipse.org/node/131344

Luego de algunas pruebas logré hacer andar WebSphere en Eclipse, perfectamente. El único problema fue que quería intentar hacer andar la versión 7.0 (supuestamente era posible según los nombres y comentarios de las versiones de los plugins publicados en el Eclipse Marketplace), pero solo pude hacer funcionar la versión 8.0.

Si bien WebSphere no es un server open-source, y quizá no tan utilizado, para los que tienen que trabajar desarrollando aplicaciones que funcionen en dicho server, es una buena idea tenerlo listo para poder hacer pruebas en una de las IDEs más utilizadas hoy en día.

Hasta el momento no había otra opción, más que utilizar Rational Software Development Platform, entorno con licencia comercial, muy pesado (+4GB) y con altos requerimientos de hardware.

Testeando cron expressions: CronMaker

Intentando entender algunas expresiones complicadas de quartz, llegué a este sencillo pero interesante servicio: CronMaker.Es un sitio web que permite construir y testear las cron expressions de quartz.
Para poder construirlo se puede seleccionar si se quiere que la expresión sea cada minuto, hora, dia, semana, mes, etc. Pero lo más interesante ​es la posibilidad de tener un "preview" de las cron expressions con el boton "Calculate next dates".

Preview de la cron expression

Un sitio interesante para bookmarkear.