Poco a poco me está gustando más Groovy, a priori, se puede pensar que como es un lenguaje de programación dinámico es un lenguaje sencillo, nada más lejos de la realidad.

Es un lenguaje que tiene una sintaxis parecida a Java pero con sus añadidos resulta más compleja, existe un documento donde se nombran las principales diferencias entre Groovy y Java. Además, usando Groovy contamos con la ventaja de que podemos aprovechar el conocimiento que ya tenemos, además de por su sintaxis, por su integración con librerías java.

Además, me gustan las capacidades dinámicas del lenguaje y su ExpandoMetaClass para añadir comportamientos a una clase(añadir métodos, atributos y constructores usando closures), me falta empezar a utilizar estas features del lenguaje a las que les tengo ganas :) y que me ayuda a pensar cómo estarán desarrolladas algunas partes de grails.

Para empezar a "jugar" con el lenguaje no puedo dejar de recomendar los artículos que escribió Andrés Almiray en groovy.org.es de Introducción a Groovy(partes 2 y 3), dónde explica con detalle muchas de esas diferencias entre Java y Groovy.

A raíz de unos comentarios en javahispano, en el que se discutían algunas razones de porqué no hay JUGs en España, surgió la idea de tratar de re-arrancar el grupo de usuarios java que en su día había en Zaragoza.

Para esto hemos creado un grupo en google llamado ZaragozaJUG, la idea es tener un sitio dónde nos podamos comunicar los programadores java (o interesados en la plataforma java) y ver si "sale algo". De inicio la intención es hacer reuniones informales periódicamente para charlar sobre temas relacionados con la plataforma, al estilo cadius, y cómo no tomar unas cañas ;). Más adelante, si hay gente y ganas, ya se verá si se trata de ir haciendo algo más "serio".

Como curiosidad en este momento en el grupo, de la gente que más o menos conozco y sin haber demasiada, ya se ve una combinación interesante de conocimientos habiendo programadores que trabajamos con web, otros con TDT y, sino me equivoco, al menos también con móviles.

Si eres de Zaragoza o vives cerca de esta ciudad, y te interesa formar un JUG (o al menos conocer a un grupo de gente con intereses parecidos y tomar unas cañas) inscríbete en el grupo.

UrlRewriteFilter es un filtro que se basa en el mod_rewrite de Apache HTTP Server, para permitir el uso de urls amigables en aplicaciones J2EE y que hacía bastante tiempo que tenía pendiente de probar.

La forma de usar este filtro es realmente sencilla, simplemente debemos añadir el filtro a nuestro web.xml:

<filter>
    <filter-name>UrlRewriteFilter</filter-name>
    <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
    <init-param>
        <param-name>logLevel</param-name>
        <param-value>INFO</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>UrlRewriteFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Y debemos tener en el directorio WEB-INF el archivo urlrewrite.xml, donde configuraremos nuestras urls amigables. Por ejemplo si quisieramos cambiar unas urls de struts como miaction.do?identificador=1 para que fueran más amigables para los buscadores por ejemplo de esta forma miaction/1.

<rule>
  <from>^/miaction/([0-9]+)$</from>
  <to type="forward">/miaction.do?identificador=$1</to>
</rule>

Hay varios ejemplos de uso en la web del proyecto si quieres ver otras situaciones más concretas dónde utilizar este filtro.

He acabado, al fin, de leer el libro The Pragmatic Programmer. Es un libro que debería leer cualquiera que trabaje como programador, ya que se dan una serie de consejos para mejorar en nuestro trabajo y no se centra en un lenguaje en concreto, aunque se ponen algunos pequeños ejemplos de código en Java, C y Perl.

Es un libro de buenas prácticas generales de programación, esto lleva a que algunos temas se toquen de manera algo superficial, aunque si profundizara el libro sería muchísimo más extenso. Para mi el libro ha resultado inspirador, sobre todo porque gran parte son buenas prácticas en cuanto a la actitud de un programador (no des excusas provee opciones, no te repitas, prueba tu software, piensa críticamente sobre tu trabajo...).

Otras ideas que resultan interesantes son la automatización de procesos (realización de pruebas, generación de código, generación de documentación...) o la organización de código (separa vista y modelo, diseña usando servicios, refactoriza pronto y a menudo, diseña para probar, diseña con contratos...).

En conclusión, es un libro muy recomendable, donde se encuentran algunas ideas que ya conoceremos, pero que en muchas ocasiones no aplicamos, y que resulta fácil de leer gracias al uso de metáforas o de ejemplos

Hace ya algún tiempo que ando tocando algunas cosas de Spring framework. Un framework que simplifica el desarrollo de aplicaciones J2EE, que entre otras cosas nos permite desacoplar partes de nuestro código gracias a Spring IoC.

A raíz de un post en programania, en donde explican dos formas de integrar spring con struts, voy a aprovechar para explicar aquí las otras dos alternativas para hacerlo.

• Nuestros Actions deben extender de ActionSupport: de esta forma se facilita la obtención del contexto de spring manualmente, que es la forma más sencilla de hacerlo. El problema, evidentemente que de esta forma las Actions de struts quedan muy aclopadas a spring.
• Usando DelegatingRequestProcessor (o en el caso de usar Tiles DelegatingTilesRequestProcessor): le pasamos el manejo de las acciones a spring sobre-escribiendo el RequestProcessor de struts. De esta forma desacomplamos los Actions de spring, aunque nos puede surgir el problema que vayamos a usar un RequestProcessor propio, por lo que deberíamos usar el DelegatingActionProxy, que es la forma que explican en programania.

La pega que surge al delegar el manejo de los Actions a Spring con DelegatingRequestProcessor y DelegatingActionProxy, es que hay que definir en el beans.xml nuestros actions de struts. En el primer caso, en el struts-config definiremos (como siempre) nuestros actions, por lo que deberemos mantener las mismas actions en dos XML diferentes, sólo cambia que definimos:

controller processorClass = "org.springframework.web.struts.DelegatingRequestProcessor"

mientras que en el segundo, para cada action de struts-config le pondremos el type DelegatingActionProxy:

type = "org.springframework.web.struts.DelegatingActionProxy"

En conclusión, es recomendable delegar el manejo de las acciones a spring aunque tengamos que mantener dos XML diferentes, ya que la integración es más transparente y además tendremos la opción de utilizar Spring AOP. Mientras que extender de ActionSupport resultaría útil para utilizar varios contextos de spring distintos.

Para encontrar una explicación mucho más detallada y con ejemplos, en developerWorks hay un artículo disponible.