Espero este año 2012 poder actualizar algo más. No me pongo objeivos, pero peor que 2011 será difícil.

Por eso publico una imagen que circula por las redes sociales y que a mi modo de ver resumen muy bien el origen de los movimientos. Con el contenido de este manifiesto estoy completamente de acuerdo.

Prometo recuperar próximamente la temática del blog.

Si hace un año estaba bastante satisfecho de la marcha del blog, este segundo año no lo estoy tanto. Mi insatisfacción se refiere sobre todo a lo poco que he publicado este año. Cambios laborales y personales (mi segundo hijo) me hacen tener menos tiempo que dedicarle a esto. Sigo aprendiendo cosas pero no saco el tiempo para compartirlas con vosotros. Así que como propósito de enmienda o en grande en esa lista TODO tengo el conseguir ese tiempo para publicar al menos una vez al mes (lejos ya de la entrada o dos entradas semanales que me ponía como objetivo en un principio).

En cuanto a datos de acceso, sigo estando bastante contento. El promedio de visitas diarias ha subido y está en el entrono de las 80, con un record de 174 visitas en un día y 40.945 visitas totales. Para mí está bien.

En cuanto a temas, CakePHP sigue caliente (a ver si le dedico alguna entrada en un futuro próximo).

De nuevo daros las gracias a todos los que visitáis Tus Ceros y Mis Unos, ¡permaneced a la escucha!.

Partimos de un servidor Hudson instalado (y con una JDK y Ant configurados) y un proyecto que utilice Ant para su construcción (tendremos su build.xml que compila las fuentes y crea un jar por ejemplo).

Por ahora vamos a integrar tres herramientas de análisis estático de código: PMD, CPD (integrado en PMD) y FindBugs. Necesitaremos descargar y extraer en un directorio ambas herramientas.

Partimos de un script de Ant como el que sigue:

<?xml version="1.0"?>

<project name="TCYMU" default="compile" basedir=".">

	<property name="src.dir" value="${basedir}/src"/>
	<property name="lib"	value="${basedir}/lib"/>
	<property name="classes"	value="${basedir}/classes"/>

	<target name="clean" description="Limpia el proyecto">
		<delete dir="${classes}"/>
		<delete dir="${dist}"/>
	</target>	

	<target name="init" description="Crea el directorio de compilacion y destino" depends="clean">
		<mkdir dir="${classes}"/>
		<mkdir dir="${dist}"/>
		<path id="compile.class.path">
			<pathelement path="${lib}/*.jar"/>
		</path>
	</target>	

	<target name="compile" description="Compilacion" depends="init">
		<javac debug="on" srcdir="${src.dir}" destdir="${classes}" classpathref="compile.class.path"/>
	</target>

</project>

Crearemos una nueva tarea en Hudson, introduciremos un nombre y seleccionaremos la opción de “Crear un proyecto de estilo libre”.

Después seleccionaremos una JDK, configuraremos el control de versiones (en mi caso Subversion) y en la sección de “Ejecutar” seleccionaremos “Ejecutar Ant” e introducimos el nombre de nuestra tarea de Ant para compilar. Con esto ya podríamos lanzar la primera ejecución en Hudson para comprobar que funciona.

Para integrar los tres análisis voy a utilizar una misma estrategia basada en variables de entorno que nos permitirá que nuestra configuración Ant sea válida tanto en local como en el servidor Hudson. Para ello en la configuración de Hudson definiremos dos variables de entorno que apunten a los directorios de PMD y FindBugs.

Hecho esto modificamos el build.xml para incluir las nuevas tareas:

<?xml version="1.0"?>

<project name="TCYMU" default="compile" basedir=".">

	<property environment="env"/>
	<property name="src.dir" value="${basedir}/src"/>
	<property name="lib"	value="${basedir}/lib"/>
	<property name="classes"	value="${basedir}/classes"/>
	<property name="reports" value="${basedir}/reports"/>

	<taskdef name="pmd" classname="net.sourceforge.pmd.ant.PMDTask">
		<classpath>
			<pathelement location="${env.PMD_HOME}/lib/pmd-4.2.5.jar"/>
		</classpath>
	</taskdef>

	<taskdef name="cpd" classname="net.sourceforge.pmd.cpd.CPDTask">
		<classpath>
			<pathelement location="${env.PMD_HOME}/lib/pmd-4.2.5.jar"/>
		</classpath>
	</taskdef>

	<taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask">
		<classpath>
			<pathelement location="${env.FINDBUGS_HOME}/lib/findbugs-ant.jar"/>
		</classpath>
	</taskdef>

	<target name="clean" description="Limpia el proyecto">
		<delete dir="${classes}"/>
		<delete dir="${dist}"/>
	</target>

	<target name="cleanReports" description="Elimina el directorio de compilacion y destino">
		<delete dir="${reports}"/>
	</target>

	<target name="init" description="Crea el directorio de compilacion y destino" depends="clean">
		<mkdir dir="${classes}"/>
		<mkdir dir="${dist}"/>
		<path id="compile.class.path">
			<pathelement path="${lib}/*.jar"/>
		</path>
	</target>	

	<target name="compile" description="Compilacion" depends="init">
		<javac debug="on" srcdir="${src.dir}" destdir="${classes}" classpathref="compile.class.path"/>
	</target>

	<target name="pmd">
		<mkdir dir="${reports}"/>
		<pmd rulesetfiles="ruleset.xml">
			<formatter type="xml" toFile="${reports}/pmd.xml"/>
			<fileset dir="${src.dir}">
				<include name="**/*.java"/>
			</fileset>
		</pmd>
	</target>

	<target name="cpd">
		<mkdir dir="${reports}"/>
		<cpd minimumTokenCount="50" format="xml" outputFile="${reports}/cpd.xml">
			<fileset dir="${src.dir}">
				<include name="**/*.java"/>
			</fileset>
		</cpd>
	</target>

	<target name="findbugs" depends="compile">
		<mkdir dir="${reports}"/>
		<findbugs home="${env.FINDBUGS_HOME}"
	              output="xml"
	              outputFile="${reports}/findbugs.xml"
	    	      jvmargs="-Xmx1024m">
			<sourcePath path="${src.dir}" />
			<class location="${classes}" />
		</findbugs>
	</target>

</project>

Las novedades que presenta son bastantes:

• Configuro la propiedad environment para tener acceso a las variables de entorno.
• Configuramos un nuevo directorio que albergará el resultado de los distintos análisis. Es el directorio que he llamado reports.
• Defino las tareas Ant que se incluyen con PMD y FindBugs mediante la etiqueta taskdef, y buscando los jars a través de las variables de entorno.
• Defino la tarea pmd indicando xml como formato de salida, el directorio que contiene el código fuente y el archivo de salida. PMD puede realizar análisis en base a un buen número de reglas. Podemos configurar las reglas que utilizaremos bien mediante etiquetas anidadas en la tarea Ant o mediante un archivo separado de reglas (lo que se indica en la tarea Ant como rulesetfiles). En mi caso he utilizado para probar la configuración que aparece bajo “Add some rule references to it” en la sección de crear un conjunto de reglas en la web de PMD. En el siguiente enlace podemos encontrar más información sobre la configuración de PMD.
• Defino la cpd de forma muy parecida a la de pmd. Se indica xml como formato de salida, el directorio que contiene el código fuente y el archivo de salida. Para CPD no hay archivo de reglas. En el siguiente enlace se puede encontrar más información sobre la configuración de CPD.
• Defino la tarea Ant para FindBugs. Además de directorio de fuentes y archivo y formato de salida, necesitamos indicarle el directorio de instalación de FindBugs y el directorio donde encontrar las clases compiladas ya que FindBugs las utiliza para su análisis. Por este último motivo declaramos la tarea de findbugs dependiente de la de compilación. Más información en el capítulo de tarea Ant de FindBugs.

Para la integración necesitaremos instalar algunos plugins para Hudson. Iremos al apartado de plugins dentro de la configuración de Hudson e instalaremos Static Analysis Utilities, PMD Plug-in, Duplicate Code Scanner Plug-in y FindBugs Plug-in.

Por último modificaremos la configuración de nuestra tarea Hudson. En la sección de “Acciones para ejecutar después” activaremos el visualizador de PMD, CPD y FindBugs. En la configuración de ant lanzaremos las tareas cleanReports, pmd, cpd y findbugs.

Tras mandar a Hudson que nos ejecute el proyecto obtendremos una salida similar a la siguiente:

y podremos ver detalles de nuestro análisis siguiendo los enlaces:

Hasta aquí esta entrada que seguro no será la última sobre Hudson, seguid atentos.

Parece ser que en Oracle RAC la URL de conexión a la BBDD mediante JDBC no permite una de sus versiones clásicas. Así por ejemplo una conexión del estilo:

jdbc:oracle:thin:@<HOST>:1521:<SID>

no funciona saltando la siguiente excepción:

java.sql.SQLException: Listener refused the connection with the following error:
ORA-12505, TNS:listener does not currently know of SID given in connect descriptor
The Connection descriptor used by the client was:
...

Para solucionarlo podemos utilizar la otra forma corta de url que aparece por ejemplo en este listado de formatos de conexión JDBC (en inglés ):

jdbc:oracle:thin:@//<HOST>:1521/<SID>

También podemos utilizar una URL en formato largo:

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<HOST>(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=<SID>)))

Si tenemos varios servidores deberíamos poner una URL en el siguiente formato:

jdbc:oracle:thin:@<HOST1>^<HOST2>:1521:<SID>

jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=<HOST1>) (PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=<HOST2>) (PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=<SID>)))

aunque esto último no lo he podrido probar lo he visto en el JUG de Padova (en inglés ).

Espero que le pueda servir de ayuda a alguien.

A veces se hace multiplicando pasando a entero y dividiendo, pero no es una forma fiable.

La forma de hacerlo sería mediante el método setScale de la clase java.math.BigDecimal:

public static double round(double value, int decimalDigits) {
	BigDecimal bd = new BigDecimal(value);
	bd = bd.setScale(decimalDigits, BigDecimal.ROUND_HALF_UP);
	return bd.doubleValue();
}

Tenemos varias opciones a la hora de redondear que podemos ver en la documentación de BigDecimal.

Espero que os ayude.

Este mensaje indica que en la respuesta a nuestra petición segura https se acceden algunas partes mediante el protocolo no seguro http. Esto es un riesgo de seguridad y por eso nos alerta.

Tras varias pruebas intentando localizar el contenido no seguro di con una gran entrada de Eric Lawrence sobre el tema del contenido no seguro ( en inglés) que me ayudó a solucionar el problema.

Por un lado desde el punto de vista del navegador podemos hacer que no nos aparezca la ventanita. Evidentemente no es la solución óptima el obligar a que el navegador no nos muestre un aviso de seguridad, pero para un aprieto (una demo por ejemplo) nos puede ayudar. Para ello abrimos las opciones del navegador (“Herramientas->Opciones de Internet”) y vamos a la pestaña de “Seguridad”. En la parte de “Internet” pulsamos “Nivel personalizado…” y buscamos la opción de “Mostrar contenido mixto”. Cambiamos de “Preguntar” a “Habilitar”.

Como desarrolladores debemos preocuparnos de que si nuestra aplicación va a ejecutarse bajo https nuestras páginas no llamen a contenido no cifrado. Para descubrir si hacemos peticiones http podemos utilizar el Web Developer para Firefox o una buena herramienta que también descubrí gracias al post mencionado anteriormente como es Fiddler.

En nuestro caso y tras ver que no hacíamos ninguna llamada http descubrimos que lo que ocurría es la posibilidad que señala Eric en su sitio. Parece ser que Internet Explorer marca como contenido no seguro una llamada a JavaScript del estilo:

<br /> &lt;script type=&quot;text/javascript&quot; id=&quot;contentloadtag&quot; src=&quot;javascript:void(0)&quot; &gt;<br />

Con eliminar el parámetro src se solucionará el problema. Una de las librerías JavaScript que utilizábamos tenía una llamada de ese tipo.

Espero que os sea útil.

Si hacemos una comparación con Strings al estilo de:

<s:if test="propiedad == 'SI'">
  <div>Mostrar texto</div>
</s:if>

obtendremos el resultado esperado (mostrará el texto si nuestra propiedad vale “SI”), pero si la comparación es:

<s:if test="propiedad == 'S'">
 <div>Mostrar texto</div>
</s:if>

veremos que aunque nuestra propiedad valga “S” no aparece el texto. Es decir, que cuando hacemos comparaciones de Strings de un sólo carácter nos falla. La responsable es la librería OGNL que evalúa las expresiones ya que al encontrar se un sólo carácter lo toma como un tipo Char y no un String.

Para solucionarlo nos basta cambiar las comillas:

<s:if test='propiedad == "S"'>
  <div>Mostrar texto</div>
</s:if>

o bien escapar las comillas dobles:

<s:if test="propiedad == \"S\"">
  <div>Mostrar texto</div>
</s:if>

Espero que le pueda servir a alguien.

Aunque un poco tarde (¿todavía no lo ha leído todo el mundo?) yo también me quiero adherir al manifiesto que se ha creado en respuesta a la posible inclusión en la Ley de Economía Sostenible (parece que lo único importante son los nombres de las leyes, luego el contenido…) de la posibilidad de cerrar páginas web sin intervención del poder jurídico. Si ya en muchas ocasiones uno duda (¿sólo duda?) de la independencia del poder jurídico mal pinta la cosa si hasta se lo quieren saltar.

Por eso yo me adhiero al siguiente manifiesto:

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de Internet manifestamos nuestra firme oposición al proyecto, y declaramos que:

1.- Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.

2.- La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.

3.- La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.

4.- La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.

5.- Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.

6.- Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.

7.- Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.

8.- Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.

9.- Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.

10.- En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Las pruebas unitarias consisten en desarrollar código para probar una determinada funcionalidad de nuestra aplicación.

Vamos a ver un pequeño ejemplo. Supongamos que estamos haciendo una librería matemática que incluye una funcion para calcular el factorial de un número. Podría ser una clase parecida a la siguiente:

package org.tcymu.util;

public class MathLibrary {
	public static int factorial(int n) throws IllegalArgumentException {
		int response = 1;

		if (n < 0) {
			throw new IllegalArgumentException();
		}

		if (n > 0) {
			response = n * factorial(n - 1);
		}

		return response;
	}
}

En esta entrada voy a utilizar las facilidades que da Eclipse gracias a su integración con JUnit. Para ello en la vista package sobre la clase que queremos probar hacemos botón dereco -> “New” -> “JUnit Test Case”.

Nos aparece la siguiente ventana en la que seleccionamos “New JUnit 4 test” (tened en cuenta que JUnit 4 necesita Java 1.5 o superior).

Podemos ver que nos propone un nombre para la clase de pruebas, así como un paquete y una carpeta de fuentes (por defecto propone el mismo paquete que las fuentes, aunque podríamos elegir otro). También podemos seleccionar que nos cree los siguientes métodos de apoyo para preparar el entorno de los test o liberar recursos:

- Métodos setUp y tearDown. Los ejecuta antes de llamar a cada método de prueba en esa clase. La secuencia sería setUp, metodo1Test, tearDown, setUp, metodo2Test, tearDown.

- Métodos setUpBeforeClass y tearDownAfterClass. Estos métodos se ejecutan antes y después de todos los métodos de la clase. La secuencia sería setUpBeforeClass, metodo1Test, metodo2Test, tearDownAfterClass.

A continuación nos pide los métodos que queremos probar. En este ejemplo seleccionamos el método que queremos probar (factorial) y ninguno de los métodos de apoyo (en nuestro sencillo ejemplo no necesitamos crear ni liberar nada).

Tras finalizar y si no tenemos la librería JUnit 4 en el Build Path nos la añade. Y por último crea el esqueleto de la clase de prueba:

package org.tcymu.util;

import static org.junit.Assert.*;

import org.junit.Test;

public class MathLibraryTest {

	@Test
	public void testFactorial() {
		fail("Not yet implemented");
	}

}

Hay que destacar que lo que realmente convierte al método en un test que ejecutará JUnit es la anotación Java @Test, al igual que lo que marcaría a los métodos de apoyo serían anotaciones como @BeforeClass, @AfterClass, @Before y @After.

Podemos observar que el método testFactorial sólo contiene la línea fail("Not yet implemented"); , por lo que si ejecutamos el test (mediante botón derecho sobre la clase de pruebas y “Run As” -> “JUnit Test” se nos abre la vista de JUnit con el siguiente resultado:

Por tanto es hora de implementar nuestra prueba para pasar la barra al ansiado color verde. Básicamente se hacen comprobaciones de los resultados esperados frente a los recibidos mediante la clase org.junit.Assert (documentación Javadoc de JUnit).

package org.tcymu.util;

import static org.junit.Assert.*;

import org.junit.Assert;
import org.junit.Test;

public class MathLibraryTest {

	@Test
	public void testFactorial() {
		Assert.assertEquals(1, MathLibrary.factorial(0));
		Assert.assertTrue(1 == MathLibrary.factorial(1));
		Assert.assertEquals(24, MathLibrary.factorial(4));
		Assert.assertEquals(720, MathLibrary.factorial(6));

		boolean excepcionLanzada = false;
		try {
			MathLibrary.factorial(-1);
		} catch (IllegalArgumentException e) {
			excepcionLanzada = true;
		}
		Assert.assertTrue(excepcionLanzada);
	}

}

Vemos que utilizamos varios métodos para comprobar que se obtiene el resultado esperado. También podemos ver cómo probamos que se lanza la excepción esperada cuando el argumento no es válido (creo haber leído en algún sitio que se iba a mejorar la prueba de excepciones en próximas versiones, pero no consigo localizar la noticia).

Una vez que se ejecutan la prueba con éxito (la barrita verde) sabemos que el método funciona como nosotros esperamos. Ahora tras cualquier cambio en el código volveríamos a ejecutar JUnit para comprobar que no hemos roto nada. Esto nos da una gran seguridad a la hora de meter mano o refactorizar métodos complejos.

Por último no quisiera terminar la entrada sin nombrar un par de temas relacionados con las pruebas unitarias.

- Una buena prueba debe ser repetible (se debe de poder lanzar cuantas veces queramos sin afectar a nada). Por ello cada vez más se automatizan las pruebas en los procesos de integración continua de forma que antes de generarse una versión de una aplicación se corren todas las pruebas para dicha aplicación.

- Existe un modelo de desarrollo que promueve que primero se escriban las pruebas y después el código. Es el llamado Desarrollo Guiado por Pruebas o Test Driven Development (TDD).

Espero que os haya gustado esta pequeña introducción.