Búsqueda incremental en Eclipse

2 comentarios
Ultimamente me ha dado por redescubrir Eclipse. Que si plugins, atajos, templates,... es soprendente lo fácil que es descubrir una nueva o simplemente desconocida funcionalidad.

Lo último ha sido la búsqueda incremental, en inglés Incremental Find. Una funcionalidad más que recomendable para aquellos que encontréis mejorable el clásico diálogo de búsqueda del editor (Ctrl+F), sobretodo después de usar todos los dias el buscar de Firefox.

Para usar la búsqueda incremental sobre un fichero basta con abrirlo en el editor y pulsar Ctrl+J. Ojo porque no aparecerá ningún diálogo ni nada visual salvo la frase Incremental Find en la barra de estado. En ese momento tecleamos la palabra a buscar y Eclipse irá buscando según tecleamos. Para moverte entre las distintas ocurrencias puedes usar las fechas arriba y abajo.

Cómo hacer que Eclipse ignore una carpeta

1 comentarios
A veces la carpeta build puede hacerse muy molesta cuando trabajamos con Eclipse, como cuando estamos buscando un fichero con el atajo Ctrl-May-R y acabamos editando la copia contenida en la carpeta build o cuando Eclipse se pone a validar todos sus ficheros.

Para hacer que Eclipse ignore una carpeta basta con pulsar con el botón derecho sobre ella, seleccionar Properties y hacer click en Derived. Rápido y efectivo, aunque podría haber sido más intuitivo.

Buenas prácticas de uso de un sistema de control de versiones (i)

3 comentarios
[MOD 081109(2): Ficheros de configuración del ide]
[MOD 081109(1): Formatea tu código antes de subirlo]

Este post es una recolección de lo que yo considero como buenas prácticas para el uso de un sistema de control de versiones (en adelante SCV). Esta recolección es fruto de mi experiencia usando tanto CVS como Subversion en múltiples proyectos con equipos formados con desde 2 hasta 5 desarrolladores donde he visto de todo (bueno y malo) y además de lo que he podido aprender leyendo a otra gente, en especial el libro Pragmatic Version Control using CVS.

Aún así lo que a mi me parezca como buena práctica podría no serlo para otros o existir una manera mejor de hacer las cosas, así que estaré encantado de leer vuestros comentarios como siempre.

Updates

Antes de nada haz un update. No empieces a programar sin estar seguro de que tu copia local del proyecto está actualizada. Evitarás caer en conflictos con otras modificaciones ya realizadas y programar algo que ya ha hecho un compañero.

Analiza los cambios realizados por tus compañeros. No le des al botón y punto. Al menos en los ficheros relacionados con tu tarea actual.

Usa un cliente y editor potente, como el de Eclipse, para comparar tu copia local de un fichero con la copia remota del servidor.

Commits

No hagas commit de algo roto. Antes de subir algo, asegúrate de que como mínimo compila (perogrullo?), la aplicación se construye bien y el servidor arranca. Un par de pruebas facilonas estaría bien, si son tests automatizados y repetibles mucho mejor. Para nota si compruebas que los tests existentes relacionados no fallan. Matrícula si añades el javadoc y pasas antes un analizador de código, tipo checkstyle, para una revisión automatizada. Intenta ser lo más estricto posible con esto, sobretodo si no cuentas con un sistema de integración continua que detecte de forma automática los fallos que se van introduciendo en el proyecto, al final ese trabajo hay que hacerlo y sale mejor poco a poco y cuando las cosas están frescas que todo al final, la semana antes de la entrega.

Formatea tu código antes de subirlo. Con un ide decente es una simple combinación de teclas o un click de ratón y evitarás conflictos.

Realiza commits regularmente. En plena fase de desarrollo lo normal sería realizar al menos un commit al día. No dejes que se acumulen modificaciones de muchos días sin subir o te llevarás más de una sorpresa en forma de conflicto en todas tus modificaciones.

Comentarios

Comenta siempre tus commits. Por mucha pereza que te de, por inútil que creas que sea, comenta tus commits.

Usa comentarios inteligentes y normalizados. Por ejemplo, clasifica los comentarios haciendo que empiecen por los prefijos ADD para nuevas caracteristicas, MOD para modificaciones y FIX para bugfixes.

Si usas un gestor de issues, tipo Jira, Trac, Mantis, etc., indica en el comentario el identificador de los issues afectados. De este modo conseguirás trazabilidad entre los issues y el código.

Estructura de un proyecto en SCV

La estructura del proyecto en el SCV debe contener todo lo necesario para construir la aplicación una vez realizado el checkout. Esto implica que si el proyecto no usa un sistema que gestione y obtenga las dependencias, como Maven o Ivy, debes añadirlas a la estructura para que estén siempre disponibles.

Sube los ficheros propios de configuración del ide sólo si es el oficial de tu organización. Un proyecto debe poder construirse de forma automática e independiente a cualquier ide por lo que no hace falta incluir los ficheros de configuración del proyecto dentro de ningún ide para cumplir con la buena práctica anterior. Sin embargo, como a los junior suele costarles demasiado configurar un proyecto en un ide, suele ser relativamente útil subir los ficheros de configuración del ide oficial de la empresa aunque contraproducente porque entonces los junior si que nunca aprenden y cambiar la ruta del JDK puede convertirse en un trauma.

No subas ficheros que son generados de forma automática como parte del propio ciclo de construcción del proyecto, como los ficheros .class, javadoc, reports o el mismo war. Como norma diría que se debe ignorar la carpeta build completa. Aquí yo hago siempre una excepción que son los ficheros .java generados a partir de un fichero wsdl, yo suelo añadirlos en la estructura SCV porque no me gusta bajarme un proyecto que no compila de primeras, no suelen cambiar con frecuencia y además su generación puede llegar a ser bastante lenta.

Conflictos

Analízalos con calma. Aunque el primer instinto es llamar al que hizo el último commit, la mayoría de los conflictos suelen ser triviales y con ayuda de un editor potente y un poco de atención podrás resolverlos solo.

Si necesitas ayuda pídela. Aún así puede que necesites ayuda, llevas poco tiempo en el proyecto, aún eres un junior, el fichero ha cambiado totalmente, crees que han podido introducir un bug,... no pasa nada, mejor que llames a tu compañero y lo resolvais juntos antes de meter la pata con tu código y el suyo.

Comenta el código una vez resuelto el conflicto si has modificado su funcionalidad. En la próxima actualización tu compañero verá que has cambiado su código, mejor que lea el motivo en el propio código antes de que te dedique algún bramido.


Esto sería todo para una primera parte, he dejado los temas avanzados y más interesantes como tags, branches y merges para una próxima segunda parte.

Cómo crear un logger AOP con Spring2

4 comentarios
Una de las muchas ventajas de Spring es lo mucho que te facilita usar Programación Orientada a Aspectos (AOP)en tus proyectos. En este post explicaré como implementar un aspecto que realice la funcionalidad de logging con Log4j y Spring2. En resumen, se trata de asociar 2 trozos de código, uno se ejecutará antes y el otro justo después, a los métodos Java que se requiera para realizar la función de logging.

Preliminares

Lo primero es preparar el proyecto. Para ello hace falta realizar las siguientes acciones:
  • Copiar a la carpeta lib del proyecto al menos los módulos spring-aop.jar, spring-beans.jar, spring-context.jar y spring-core.jar, localizados en la carpeta dist/modules de tu instalación de Spring framework.
  • Copiar a la carpeta lib del proyecto las dependencias aopalliance.jar, aspectjweaver.jar, cglib-nodep-xxx.jar. Éste último puede que ya lo tengas incluido si estás usando Hibernate. Las encontrarás todas en la carpeta lib de tu instalación de Spring framework con dependencias.

Implementar el aspecto

El siguiente paso es implementar el aspecto con la funcionalidad de logging antes y después de la ejecución de los métodos objetivo (target). Para ello basta con crear una clase Java que implemente los interfaces org.springframework.aop.MethodBeforeAdvice y org.springframework.aop.AfterReturningAdvice de Spring AOP para sobreescribir así los métodos before y afterReturning que se ejecutarán antes y depués, respectivamente, de los métodos objetivo y mediante un logger de Log4j realizarán el logging.

Un ejemplo muy sencillo de esta clase, llamémosla example.util.AopLogger, sería el siguiente:
public class AopLogger implements MethodBeforeAdvice, AfterReturningAdvice {

private static final Log logger = LogFactory.getLog(AopLogger.class);

public void before(Method method, Object[] args, Object target) throws Throwable {
logger.debug(method.getDeclaringClass().getName()
+ "." + method.getName() + "...");
}

public void afterReturning(Object returnValue, Method method, Object[] args, Object target) throws Throwable {
logger.info(method.getDeclaringClass().getName()
+ "." + method.getName() + "... OK");
}
}

Configurar AOP en Spring2

El último paso es configurar el aspecto en Spring para asociarlo a los métodos de las clases Java que se requiera. Este paso es muy sencillo si utilizamos el namespace aop de Spring2. El siguiente fragmento de un fichero de configuración Spring 2.5 muestra como configurar la clase AopLogger para hacer logging de los métodos públicos de todas las clases del paquete example.services del proyecto.
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd">

<aop:config>
<aop:advisor pointcut="execution(* example.services..*.*(..))"
advice-ref="aopLogger" />
</aop:config>

<bean id="aopLogger" class="example.util.AopLogger" />
[...]
</beans>

La consecuencia de usar AOP es clara, te evitas escribir el código de ejecución de un servicio transversal por todas tus clases Java, en este caso ha sido el logging pero también auditoria, autenticación, autorización, control transaccional, etc. Las ventajas son inmediatas, mayor modularidad, separación de conceptos y comprensión del código.

Puedes consultar más información sobre AOP y Spring, incluyendo otros ejemplos de puntos de ejecución, aquí.