Valorando a los miembros de un equipo de desarrollo software

El otro dia leyendo mis feeds acabe dando con esta matriz para evaluar a los miembros de un equipo de desarrollo software. No se que pensareis vosotros, pero a mi me parece excesivo, muy excesivo. Debe ser que soy un amante de lo simple, pero el caso es que yo sólo valoro 3 características en los miembros de un equipo de desarrollo y por extensión en un equipo en general.

Mis 3 características son:

• Aptitud
• Actitud
• Sociabilidad

Puede parecer excesivamente general pero no creo que haga falta más y quizás también pueda resultar chocante que sólo haya una característica técnica. Voy a entrar en detalle con cada una...

Aptitud
Es la capacidad máxima que tiene una persona de sacar trabajo adelante en un entorno ideal. Es decir, el talento o lo competente técnicamente hablando que es una persona.

Actitud
Es la fuerza mental o disposición de una persona para trabajar en un entorno no ideal. Porque el entorno nunca es ideal. La información nunca llega correcta de primeras ni a tiempo, los requisitos cambian, el servidor se cae, hace calor, se gana poco, mi ex-pareja me hace la vida imposible, [ponga aquí su queja],... etc. A veces es asombroso ver como cae en picado el rendimiento de una persona talentosa pero con una actitud débil ante situaciones adversas.

Además una persona con una actitud negativa no sólo afecta a su propio rendimiento, también al de sus compañeros.

Sociabilidad
Mide lo bien que se lleva una persona con otras personas y en especial con el resto del equipo. Afecta directamente en el ambiente de trabajo. Pasamos muchas horas a la semana en el curro y el ambiente hay que cuidarlo mucho. Un ambiente bueno y sano mejora el rendimiento.

Concluyendo...
A la hora de valorar las características lo hago en una escala de -3 a +3. Para valorar al equipo en global saco la media de todos sus miembros. Cuidado con la gente que resta.

Está claro que la aptitud tiene que ser positiva, sobretodo para equipos que realicen nuevos desarrollos o trabajen con tecnologías muy punteras y haya que buscarse la vida. No se debe tolerar que nadie reste aquí aunque buscar el máximo en aptitud para todos los miembros de un equipo puede ser hasta contraproducente. Demasiados egos sueltos y tareas 'poco atractivas' que alguien tiene que hacer.

La actitud y la sociabilidad deben cuidarse de forma global a todo el equipo. Pero mucho ojo con las personas que resten aquí porque un cáncer en el equipo puede reventar todo un proyecto.

Generador de gifs de progreso

El otro día teniamos que poner la típica animación de progreso para amenizar la espera al usuario mientras nuestra última aplicación prepara un informe realmente costoso. Yo en principio sólo había pedido que se reutilizará la típica animación del circulito que ya tenemos. De ahí mi sorpresa cuando mi compañero me llama para que elija que animación me gusta más y me enseña este generador online de gifs de carga o progreso: http://www.loadinfo.net/.
La verdad que fue todo un punto por su parte. Da gusto ver como los miembros de tu equipo evolucionan y demuestran iniciativa.

Volviendo a la herramienta, tiene 132 animaciones diferentes donde elegir, 3 tamaños diferentes (16x16, 24x24 y 48x48) y te permite definir el color de la figura y el fondo.

UPDATE el gif alojado en blogger no se movía y lo he tenido que subir a http://www.imageshack.us/, un servicio gratuito de alojamiento de recursos multimedia.

Un test para probar todos tus mapeos Hibernate

No hay tiempo para hacer tests

Es la excusa del desarrollador que aún no ha probado las ventajas del testing unitario. Yo personalmente opino que hay muchos tests que lo que hacen es precisamente (y entre otras cosas) reducir considerablemente la duración de un proyecto, sacando a la vista los bugs de codificacion o incluso defectos del diseño en plena fase de desarrollo, cuando el programador tiene el código fresco en su mente y antes de que puedan causar males mayores. Sin duda, el momento más eficiente de resolver estos defectos y no tener que esperar a tener una pantalla de la aplicación para poder probar el código.

Pero este post no pretende ser un alegato a favor del testing, ni siquiera del testing unitario. Sólo quería dejaros el siguiente código para poder testear todos los mapeos Hibernate de vuestros proyectos de un modo rápido y eficaz.

Map metadata = sessionFactory.getAllClassMetadata();
for (Iterator it = metadata.values().iterator(); it.hasNext();) {
   EntityPersister persister = (EntityPersister) it.next(); 
   Query q = session.
      createQuery("from " + persister.getClassName() + " c");
   q.iterate();
}
assertTrue(true);

Como veís es muy sencillo, hace un select para cada clase entidad Hibernate del proyecto.

He supuesto que la clase del test tiene un método setUp donde se crea una sessionFactory asociada a la configuración Hibernate de test y se obtiene un objeto session de ella. Y luego en el tearDown se liberan los recursos. Si usais Spring ésto no tendrá ningún misterio para vosotros. Por si acaso os dejo el código improvisado de una clase base en junit de la que pueden heredar vuestras clases test para Hibernate sin Spring.

public abstract class HibernateTestBase extends TestCase {

protected Session session;
protected SessionFactory sessionFactory;

protected void setUp() throws Exception {
   super.setUp();
   Configuration config = new Configuration().
      configure("/hibernate-test.cfg.xml");
   sessionFactory = config.buildSessionFactory();
   session = sessionFactory.openSession();
}

protected void tearDown() throws Exception {
   super.tearDown();
   session.close();
   sessionFactory.close();
}
}

En definitiva, se trata de un test muy rápido de construir y que os ahorrará mucho tiempo desarrollando entidades Hibernate. Pero no es perfecto, sólo prueba que los mapeos que has configurado se corresponden de verdad con una tabla y columnas que existen en la base de datos. Tiene los siguientes puntos débiles:

• Cuantos más registros haya en las tablas, más lenta será la ejecución del test. Una opción es borrar todos los registros antes de empezar el test y al terminar hacer un rollback.
  
• Si existieran registros que rompen las relaciones entre clases definidas el test fallará, aunque los mapeos sean correctos. La opción anterior también evitaría este punto.
  
• No comprueba que el mapeo sea semánticamente correcto. Es decir, el atributo apellido1 podría estar mapeado a una columna APELLIDO2 y mientras dicha columna exista el test no fallará. Para evitar ésto no queda otra que hacer tests individuales para cada clase.
  

Revisiones de código automatizadas con Eclipse (II): Cómo crear tu propia configuración en CheckStyle

En mi anterior post de Revisiones de código automatizadas con Eclipse aproveché para hacer una mini presentación de varios de los plugins más conocidos de Eclipse para analizar código Java. Posteriormente yo decidí usar el plugin de David Schneider para CheckStyle, principalmente por la facilidad con la que puedes configurar tu propio juego de reglas.

Al final lo que intentas con este tipo de herramientas es asegurarte de que el código de tus proyectos sigue un mismo estilo que asegura un mínimo de calidad y, sobretodo, facilita su mantenimiento. Ahora bien, un estilo es algo subjetivo de por sí y necesita definirse, así que cuanto más facil sea definirlo mejor. Otras ventajas significativas son su facilidad de uso, que los mensajes de las reglas están en castellano y la posibilidad de implementar tus propias reglas.

Instalación
Instalar el citado plugin de CheckStyle en Eclipse es tan sencillo como ir a la opción Help -> Software Updates -> Find and Install. Añadir como Remote Site la url: http://eclipse-cs.sourceforge.net/update/ e ir dándole al botón de siguiente...

Crear una nueva configuración
Una vez instalado puedes configurarlo de forma global en la opción Window -> Preferences -> CheckStyle. Aunque tambien puedes configurar cada proyecto individualmente.


Desde esta pantalla puedes crear tus propias configuraciones o juegos de reglas desde cero o copiando una ya existente. Las configuraciones iniciales (Sun y Sun-Eclipse) no pueden modificarse. Tambien puedes exportar/importar configuraciones e indicar la que se usará por defecto.

Añadiendo reglas
Llegados a este punto selecciona tu nueva configuración y pulsa el botón Configure. En la pantalla de configuración podrás examinar el conjunto de reglas disponible, añadir y parametrizar las reglas de tu elección. Uno de los parametros más importantes es la prioridad. Existen tres niveles de prioridad para las reglas que se comparten con los mensajes del propio Eclipse: error, advertencia e información.


El conjunto de reglas disponible es muy completo y está clasificado en los siguientes grupos:

• Comentarios Javadoc: facilitar el mantenimiento pasa por comentar el código, pero luego los comentarios también hay que mantenerlos... CheckStyle tiene muchas reglas para los javadoc y es muy flexible. Te permite, por ejemplo, obligar a comentar los nombres de clases, todos los métodos menos los get/set y los atributos públicos.
  
• Convenciones de nombres: puedes definir una expresión regular para el nombre de todo. En este punto yo copio las reglas de Sun.
  
• Cabeceras: expresiones regulares para la cabecera de los ficheros.
  
• Imports: reglas para los import, como no usar *, imports sin usar, etc.
  
• Violaciones de tamaño: define un máximo para el tamaño de tus clases, métodos, líneas y número de parametros de un método.
  
• Espacios en blanco: un montón de reglas para definir donde se ponen espacios en blanco y tabuladores en el código.
  
• Modificadores: establece un orden para los modificadores y evita modificadores innecesarios.
  
• Bloques: reglas para los bloques de codigo y sus llaves.
  
• Problemas en la codificación: aquí hay de todo, desde malas prácticas tipo asignaciones internas y posibles fuentes de bugs como definir un método equals que no es el equals(Object), a cosas más estéticas o pijillas, como que el default sea el último elemento en un switch o parentesis innecesarios.
• Diseño de clases: varias reglas sobre el diseño de interfaces y clases, con especial atención en las excepciones.
  
• Duplicados: te permite definir un mínimo de líneas para buscar codigo duplicado en tus clases.
  
• Métricas: define máximos para métricas como complejidad ciclomática, complejidad de expresiones lógicas, npath, líneas de código seguidas sin comentar y dependencia de clases.
  
• Misceláneo: variables final, indentación, un buscador de expresiones regulares y varias cosas más.
  
• J2EE: reglas para EJBs.
• Otros: internos a CheckStyle y activados por defecto.
  
• Filtros: para eventos de auditoria del propio CheckStyle, no hace falta mirarlos.

Cómo usar CheckStyle
La configuración que indiques por defecto se asignará inicialmente a todos tus proyectos, aunque puedes configurar cada proyecto individualmente con una, varias o ninguna configuración.

Además puedes elegir entre tener CheckStyle activado todo el tiempo o usarlo a petición. Todo ello pulsando el botón derecho sobre el proyecto y yendo al menú de CheckStyle. Conforme se incumplan reglas irán saliendo los mensajes correspondientes en la vista Problems de Eclipse ordenados por prioridad y en español!

Pero una vez instalado el plugin, creada la configuración y distribuida entre los miembros del equipo, pasa a ser responsabilidad del programador usar la herramienta y autorevisar su código. Y aquí empieza lo difícil, ¿cuántas reglas y de qué tipo permitirás que no se cumplan en un commit? ¿qué hacer cuando alguién no cumple con las revisiones? ¿cómo detectarlo? ¿todo esto se puede automatizar un poco más?

La única respuesta que tengo cierta es para la última pregunta: sí, con integración continua... pero eso será ya otro post.

Cambio de look

El otro día di con esta 'deliciosa' lista de recursos CSS y perdiendome entre enlaces acabé dando con una plantilla para Blogger que no he podido evitar instalar para mi blog. La anterior era mía y se notaba demasiado que lo mio no es el diseño web... Espero que os guste!

Diseño original por the undersigned | Adaptación a Blogger por Blog and Web

Cómo usar parametros para un webservice en Axis2

Practicamente cualquier aplicación medio seria necesita usar parametros de configuración. Un webservice no iba a ser diferente.

Alternativas hay para todos los gustos o más bien para todas las necesidades, desde crear un fichero properties para ese par de parametros de configuración a uno xml para configuraciones algo más estructuradas. Incluso he llegado a ver usar el fichero properties-service.xml de JBoss. Una mala práctica que no aconsejo, mejor el properties o xml empaquetado dentro de la aplicación y evitamos ataduras innecesarias.

Pero en el caso de desarrollar un webservice con Axis2, el propio Axis2 nos ofrece otra alternativa: el fichero services.xml del propio webservice.

Veamos un ejemplo de cómo almacenar parametros de configuración simples y complejos dentro del fichero services.xml:

<service name="miWebservice">
   <description>La descripcion de mi webservice</description>
   <parameter name="ServiceClass">path.to.my.ServiceClass</parameter>
   <parameter name="UnParametroSimple">UnValorSimple</parameter>
   <parameter name="UnParametroComplejo">
      <mailconfig>
         <username>Raska</username>
         <password>caracola</password>
         <host>http://mail.mydomain.org</host>
      </mailconfig>
   </parameter>
   <operation name="operacion">
   </operation>
</service>

Y ahora para obtenerlos hay que hacer uso de la clase MessageContext, obtener el contexto actual y usar el método getParameter teniendo en cuenta que estamos recuperando objetos de tipo OMElement. Un código para el ejemplo anterior seria el siguiente:

MessageContext msgContext = MessageContext.getCurrentMessageContext();
Parameter parametroSimple = msgContext.getParameter("UnParametroSimple");
Parameter parametroComplejo = msgContext.getParameter("UnParametroComplejo");

System.out.println("Parametro Simple " + parametroSimple.getParameterElement().getText());
System.out.println("ParametroComplejo " + parametroComplejo.getParameterElement());