Joseph Ottinger ha escrito en TheServerSide un post sobre la duplicación de esfuerzos en la industria del desarrollo de software.

El post se centra en diferentes librerías del mundo open source, con la misma finalidad o con finalidades muy parecidas y la "duplicación" de esfuerzo al desarrollar estas librerías. Algunas razones que da son:

• Falta de conocimiento de alguna librería existente.
• Falta de amplitud de percepción.
• Diferencia de opinión de cómo debería trabajar la librería.
• El antiguo proyecto puede no estar mantenido.

Otras razones que he visto por las que se han desarrollado librerías y frameworks dentro de empresas han sido: no encontrar una librería que cubriera unas necesidades determinadas, que las librerías existentes no se consideraran lo suficiente maduras, o que no hubiera una empresa detrás que diera confianza en su mantenimiento. Por otro lado, también conozco a algún "raro" que crea sus propias librerías en casa por pura diversión :).

Personalmente, me encanta poder tener múltiples opciones a elegir y probar varias de ellas, tratando de encontrar sus puntos fuertes y débiles. Aunque hay casos como el de los frameworks web, con la gran cantidad que hay (tanto Java como Php), que siempre queda la duda de haber hecho la mejor elección para desarrollar un proyecto.

Leo en el blog de Dani Torres, que este jueves 3 se juntan dos eventos en Zaragoza, por un lado el cocktail cadius del mes de abril y por otro el primer encuentro de usuarios de Panoramio.

Para hacer el evento todavía más interesante, hará acto de presencia Eduardo Manchón, co-fundador de Panoramio y empleado de Google en Zurich.

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.