Quizás el título de este post pueda dar lugar a equívocos. Obviamente, una de las consecuencias de refactorizar suele ser la reducción del código. A lo que me refiero con “eliminar código es refactorizar” es a erradicar toda señal de código innecesario en una aplicación.

Las preguntas a hacerse

1. ¿Se utiliza este código en alguna parte de la aplicación?
2. ¿Es el código parte de un plugin y se utiliza en otras aplicaciones?
3. ¿Se utiliza o no se utiliza?

Si la respuesta es no, no,no

Si te pareces a Amy Winehouse borra ese código.

Borrar código es bueno. Eliminas puntos de fallo. Reduces el número de tests necesarios. Abrevias la documentación. Es decir: reduces el ruido en tú aplicación.

Y si te arrepientes más adelante de borrarlo

Usa el control de versiones… ¿o no estás usando ninguno?

Asís y yo hemos decidido hablar un poco sobre JRuby en el seminario introductorio de Rails del jueves, ya que esperamos que la mayoría de los asistententes vengan del mundo Java.

Para preparar el material he vuelto a revisitar la página del proyecto que tenía un poco abandonada. Me ha sorprendido lo mucho que han avanzado y como han mejorado la integración con Java. Es bastante sencillo:

include Java
import 'java.util.ArrayList'

list = ArrayList.new
list.add "uno" 
list.add "dos" 
list.add "tres" 
list.each do |n|
  puts "num: #{n}" 
end

list.class.name # => "Java::JavaUtil::ArrayList
list.java_class.name # => "java.util.ArrayList" 

Esto y mucho más, en el wiki. La verdad, crear ventanas swing desde jirb hace que un escalofrio te recorra toda la espalda. Curioso cuanto menos.

NOTA: Un día de estos pruebo a desplegar alguna de nuestras aplicaciones con JRuby en un Tomcat utilizando Goldspike y os cuento.

Trabe Soluciones está creciendo. Ahora que nos vamos a mudar a unas oficinas más amplias tenemos una vacante. La oferta de trabajo que estamos distribuyendo es la siguiente.

Buscamos personas para trabajar en A Coruña.Trabe te necesita

Nos gustaría que supieses desarrollar aplicaciones web MVC con J2EE y Ruby on Rails, que controlases de HTML, CSS y Javascript, que tuvieses conocimientos de diseño gráfico, que administrases servidores, que te sintieses cómodo en Linux, que te gustase usar software libre,...

Si esto te describe ven corriendo. En caso contrario, no te preocupes, valoramos la experiencia que tengas, pero también nos interesa tu pasión y tus ganas de aprender, de trabajar de una manera diferente, de asumir responsabilidades y de crecer con nosotros.

Te ofrecemos unas excelentes condiciones. Todo lo que te ofrecen el resto de ofertas de trabajo y mucho más: horario flexible, oficina céntrica(nada de polígonos), plantilla joven, café a media manaña, no llevamos corbata ni traje... Nos importa tu calidad de vida.

Si quieres saber más de nosotros, puedes echar un vistazo a nuestra web (http://www.trabesoluciones.com) o a nuestro blog (http://4trabes.com), o directamente contactar con nosotros para plantearnos cualquier duda (contacto@trabesoluciones.com).

Esperamos tu curriculum en rrhh@trabesoluciones.com.

Ya han llegado los primeros CVs. ¿A qué esperáis para enviar el vuestro?

Sí amigos, Struts no está muerto, quizás superado, pero no muerto. Y como las cosas son así, hoy vamos a aprender (a la velocidad del galgo) como “montárnoslo” para servir feeds RSS desde nuestras acciones Struts utilizando la librería RomeRSS.

¿Para qué qerríamos hacer esto en lugar de servir los RSS a través de un Servlet específico? Sencillo. Para reaprovechar toda la infraestructura que tengamos montada para nuestra aplicación: superclases Action con comportamiento común, una cadena de filtros de preprocesado, etc, etc.

Mejor con un ejemplo. Vamos a procurar hacer las cosas de manera correcta, así que vamos a encapsular el uso de RomeRSS en una clase RSSFeeder para desacoplar nuestra aplicación de la librería. Algo así…

public class RSSFeeder {

    private HttpServletRequest request = null; 
    private HttpServletResponse response = null
    private SyndFeed feed = null;

    public RSSFeeder(HttpServletRequest request, 
            HttpServletResponse response) {

        this.request = request;
        this.response = response;      

        this.feed = new SyndFeedImpl();
        this.feed.setFeedType("rss_2.0");
        // ... más inicialización ...
    }

    public void setTitle(String title) {
        feed.setTitle(title);    
    }     

    // ... Y toda una "pléyade" the métodos set para establecer 
    // el contenido del RSS

    public void writeFeed() throws RSSFeederException {
        try { 
            response.setStatus(HttpServletResponse.SC_OK);
            response.setContentType("application/xml;charset=utf-8");

            Writer writer = response.getWriter();                    
            SyndFeedOutput output = new SyndFeedOutput();
            output.output(feed, writer);    
        } catch(Exception e) {
            throw new RSSFeederException(e);
        }
    }
}

No me paro en la generación del feed. Quién tenga interés por saber como se trabaja con RomeRSS puede echarle un ojo a su wiki.

Ahora nuestra acción de Struts…

public abstract class ExampleRSSAction extends BaseAction {

    public ActionForward doExecute(ActionMapping mapping,
            ActionForm form, HttpServletRequest request,
            HttpServletResponse response)
            throws IOException, ServletException, RSFeederException {

        RSSFeeder rssFeeder = new RSSFeeder(request, response);            
        rssFeeder.setTitle("Example feed");
        // ... Más y más construcción del feed ...
        rssFeeder.writeFeed();

        return null;
    }
}

BaseAction es una clase plantilla que contiene código centralizado para la gestión de errores y otras cosas (el comportamiento común, vamos). Sus hijas sólo implementan el método doExecute que contiene la “chicha” de la acción.

Por último, el mapping en el satánico struts-config.xml.

<action path="/rss/example" 
    type="com.trabesoluciones.app.controller.actions.rss.ExampleRSSAction" 
    scope="request"/>

Listo. Tras el churro de código, la explicación. El secreto del éxito de esta empresa es romper el ciclo normal de Struts de petición, acción y forward/redirect (las acciones suelen devolver un objeto ActionForward). Para ello, nuestro feeder escribe directamente en el Writer de salida del servlet y nuestra acción devuelve un mágico null.

Y no lo olvidéis: si esto fuera un código de verdad: ¡¡COMENTARIOS!!

Hace ya algunos meses os hablamos de un interesante modo de conseguir URLs bonitas sin depender de Apache. Como se comenta en ese post, URLRewriteFilter puede ayudarnos a conseguir ese propósito.

Hoy nos hemos encontrado con un problema con las outbound rules: siguiendo escrupulosamente la documentación proporcionada en la página de URLRewriteFilter, no era posible hacer que las outbound rules con parámetros funcionasen correctamente. Según la documentación del filtro, una outbound rule se escribe tal que así:

<outbound-rule>
    <from>^/world.jsp?country=([a-z]+)&city=([a-z]+)$</from>
    <to>/world/$1/$2</to>
</outbound-rule>

Tras un buen rato tirándonos de los pelos y haciendo todo tipo de experimentos se nos encendió una lucecita. "¿Acaso el '?' no tiene un significado específico en una expresión regular?¿No habría que escaparlo? Y escribimos la expresión escapando el '?':

<outbound-rule>
    <from>^/world.jsp\?country=([a-z]+)&city=([a-z]+)$</from>
    <to>/world/$1/$2</to>
</outbound-rule>

Y todo comenzó a funcionar ,con las limitaciones inherentes a este tipo de solución (que veremos en algún post futuro) pero correctamente.

En algún post anterior david o asis, no recuerdo cual de los dos, habló acerca de algunas cosas básicas para sobrevivir a Netbeans. En este post voy a hacer un breve repaso de algunos shortcuts absolutamente imprescindibles para sobrevivir a Eclipse. Como ando un poco apretado de tiempo, incluiré solo 3 shortcuts en este post, los pata negra.

ctrl+shift+r: Open Resource

Básico entre los básicos. Nos permite abrir cualquier recurso que tengamos en nuestro workspace. No me gusta nada la palabra recurso, pero parece que está asentada, así que habrá que asumirla :(. Un recurso es básicamente cualquier fichero que viva en nuestro workspace. Es un sistema de búsqueda rápido y eficaz, se pueden utilizar comodines y ahorra muchísimo tiempo con respecto a buscar por el árbol de clases. Utilidad creciente con el tamaño de los proyectos. Cuando el proyecto es grande puede experimentarse algún episodio de apreciación distorsionada de la velocidad de esta herramienta (ver post sobre velocidad psicológica).

ctrl+shift+t: Open Type

Nos permite abrir un tipo. En un contexto Java, que es donde suelo utilizar Ecipse, nos permite abrir rápidamente cualquier clase o interface definida en nuestro workspace. Personalmente lo utilizo bastante menos que el anterior, pero también es imprescindible. Aglutina las mismas virtudes que el anterior y se muestra como un arma de precisión a la hora de localizar esa inner class que se resiste a ser localizada

F4: Jerarquía

Mi atajo favorito cuando aterrizo en un interface. F4 nos muestra la jerarquía de clases asociada al elemento activo. Además de la utilidad obvia, para mi esta vista tiene una utilidad extra bastante interesante. En el menú contextual que aparece al pulsar el botón derecho del ratón sobre cualquier elemento de la jerarquía, tenemos la opción "Copy Qualified name", que resulta bastante cómoda para cosas como modificar tu log4j.properties.

Algún día editaré una segunda parte con otro puñado de ellos. Mientras tanto, podéis hacer vuestras contribuciones en forma de comentarios :D

Este es uno de esos artículos "de propósito específico". Supongo que los que trabajen en entornos "con mucha burocracia" entenderán mejor por qué no siempre es posible tocar el apache. La idea de este post es ver como podemos tener una funcionalidad decente de reescritura de URLs directamente en el contenedor de aplicaciones.

La pieza clave para conseguir nuestro objetivo es UrlRewriteFilter, que como sus propios autores proclaman "Es un filtro basado en mod_rewrite válido para cualquier contenedor estándar de aplicaciones JEE que permite reescribir URLs antes de que lleguen a nuestro código". Y además funciona.

El filtro es muy sencillo de instalar, tan solo son necesarios unos pocos pasos muy sencillos:

• Guardar el jar en el lib de nuestra aplicación.
• Modificar el web.xml para que haga uso del filtro:

<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>WARN</param-value>
    </init-param>
</filter>

<filter-mapping>
  <filter-name>UrlRewriteFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

• Incorporar en el WEB-INF de nuestra aplicación un fichero urlrewrite.xml, que contendrá las reglas para las reescrituras

Una vez realizados estos pasos solo nos queda escribir las reglas que consideremos necesarias en nuestro caso. El fichero urlrewrite.xml de ejemplo incluye nociones básicas al respecto. A modo de ilustración, para convertir una URL como /searchPage.do?term=casco&locale=es&make=honda en algo como /es/honda/que-contengan/casco, necesitaríamos una regla como la siguiente:

<rule>
  <from>/([a-z]+)/([a-zA-Z0-9]+)/que-contengan/(.*)</from>
  <to>/searchPage.do?term=$3&locale=$1&make=$2</to>
</rule>

Con estos sencillos pasos ya tenemos un soporte decente para construir URLs bonitas en aplicaciones Java, sin tener que hacerlo todo "a mano" ni depender del Apache.

Ya está disponible la nueva versión de la librería de cifrado Jasypt que como mayor novedad ofrece integración transparente con Spring Security (ACEGI). Más información en la página de Jasypt.

Un amigo, y en ocasiones compañero de andanzas de las 4 trabes, hasta ahora más conocido por sus maravillosas fotografías ;-) nos ha anunciado la publicación de su última criaturilla, Jasypt.

Bromas aparte, Jasypt es una de esas herramientas que le facilitan a uno la vida a la hora realizar las siempre tediosas tareas relacionadas con el oscuro mundo de la criptografía. Entre sus características más interesantes:

• Sigue los estándares y normas marcados por RSA tanto para message digesting como para cifrado basado en clave, que el API de Java de por sí no sigue.
• Es thread-safe por lo que evita todos los problemas relacionados con la concurrencia.
• Se puede usar de forma sencilla en un contenedor IoC como Spring.
• Se integra con Hibernate 3 de forma transparente.
• Permite que los usuarios avanzados que lo necesiten lo configuren según sus necesidades, mientras que otros usuarios pueden usarlo directamente sin configuración adicional.

“Easily add strong, well designed encryption to your projects… “
“Transparently persist encrypted data with Hibernate… “
“Seamlessly integrate with IoC containers like Spring…”

En resumen, reduce el trabajo necesario para realizar tareas de cifrado frente al uso del API de Java. Yo personalmente lo probaré y haré el oportuno reporte de impresiones a su autor.

Sun ha anunciado la publicación de la versión final de JSE6 que ya está disponible para descarga. Será interesante ver la acogida que recibe esta nueva versión de Java en un momento en el que el uso de la versión anterior (JSE5) aun no está muy extendido.

Por otra parte, Google ha publicado la última versión de su Web Toolkit bajo licencia Apache2.0, la noticia se puede ver en el blog de Google Web Toolkit.