Redondeando en Java

Si os habéis encontrado alguna vez con la necesidad de redondear un número en Java, habréis visto que no existe un método directo para hacerlo

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.

Anuncios

27 febrero 2010 at 12:54 am Deja un comentario

Alerta de contenido no seguro en Internet Explorer

Estábamos desplegando una aplicación en un servidor seguro y al probar con Internet Explorer recibíamos en todas las páginas el siguiente mensaje.

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.

15 enero 2010 at 9:06 pm 2 comentarios

Error en la comparación de String con la librería de tags de Struts2

Os voy a comentar un pequeño error que nos puede descolocar un poco cuando tratamos de comparar cadenas mediante la librería de etiquetas de Struts2 en nuestras páginas JSP.

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.

17 diciembre 2009 at 11:12 am 5 comentarios

Manifiesto “En defensa de los derechos fundamentales en Internet”

Lo primero disculparme a los lectores del blog por una entrada nada tecnológica. Y más si son de fuera de España.

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:

Manifiesto ‘En defensa de los derechos fundamentales en Internet’

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.

4 diciembre 2009 at 9:43 am 1 comentario

JUnit: Herramienta indispensable para el desarrollo Java

Hoy voy a hablar de una herramienta que debería ser de uso común para el desarrollo. Estoy hablando de JUnit, la librería de pruebas unitarias más utilizado en entornos Java.

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”.

Nuevo Test JUnit

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).

junit_2_320x360

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).

junit_3_320x360

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:

junit_4

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.

23 octubre 2009 at 8:51 am Deja un comentario

Pequeña introducción a Git

Git es un sistema de control de versiones al igual que CVS, Subversion y otros.

Git fue diseñado por Linus Torwalds (creador de Linux) para utilizarlo en el desarrollo del núcleo de Linux. En su sección de descargas podemos encontrar entre otras, enlaces a versiones para Linux (en rpm o deb), MacOS y Windows (a través de Cygwin o del proyecto MSysGit que provee instalables completos e incluso una versión portable).

Si venimos desde un enfoque más clásico como CVS o Subversion, la principal diferencia que aporta Git es que es un sistema distribuido. ¿Y qué quiere decir distribuido?. Pues que a diferencia de CVS o Subversion podemos trabajar con nuestro control de versiones aunque no estemos conectados a una red, ya que es como si tuviésemos el servidor en nuestra propia máquina. De esta forma está diferenciado lo que son las acciones con nuestro repositorio y las que llevamos cabo con repositorios remotos (ese sería el estilo CVS).

git_1

En principio es una solución muy recomendable si queremos mantener un versionado en nuestra máquina de desarrollo (en este caso sólo utilizaremos los comandos entre desarrollo y el repositorio propio del esquema. Vamos a ver un pequeño resumen de los comandos que utilizaríamos en este caso.

  • Lo primero que necesitamos es configurar nuestro usuario:

    git config --global user.name "Don Nadie"
    git config --global user.email "don.nadie@test.com"

  • Para crear un repositorio nos situaremos en el directorio principal de nuestro proyecto (o en uno vacío si es un proyecto nuevo) y haremos:

    git init

    y si el proyecto está empezado añadiremos los archivos mediante

    git add .
    git commit -m "Mensaje" (Si no se le pasa -m nos pedirá un mensaje, ya que es obligatorio)

    con lo que ya tendremos todo nuestro proyecto bajo el control de versiones.

  • Para el ciclo de desarrollo normal, primero se añaden los cambios al índice (es como un almacén intermedio que almacena todos los cambios) y luego lo persistiremos en el repositorio.

    git add ruta/fichero Añade el fichero nuevo o modificado al índice
    git commit Persiste los cambios que tenemos en el índice al repositorio (nos pide mensaje)
    git commit -a Hace el paso al índice y el commit en un solo paso

  • Para ver el estado del desarrollo podemos utilizar los siguientes comandos:

    git status Muestra el estado de la rama de desarrollo
    git diff Muestra las diferencias entre la rama de desarrollo y el índice
    git diff --cached Muestra las diferencias entre el índice y el HEAD (último commit)
    git diff HEAD Muestra las diferencias entre la rama de desarrollo y el HEAD
    git log Nos muestra un historial de los commits del repositorio

  • El trabajo con ramas es muy sencillo en Git.

    git branch test Crea una rama de nombre “test” a partir de la actual
    git branch Nos muestra las ramas existentes y la rama en la que nos encontramos (cuando hacemos git status también nos muestra la rama en la que nos encontramos)
    git checkout test Nos sitúa en la rama test
    git merge test Si nos hemos situado en la rama master (la rama principal, en la que empezamos) nos combina los cambios en la rama test con esta rama

Git también tiene gran potencia para compartir el código con otros desarrolladores, aunque este caso lo dejaremos para otra entrada.

Por último no quisiera terminar esta entrada sin decir que Git no es el único control de versiones distribuido. También Mercurial o Bazaar nos pueden servir para los mismos fines e incluso pueden ser más sencillas si estamos acostumbrados a CVS.

3 septiembre 2009 at 8:10 pm Deja un comentario

Estructura de directorios en Linux

En esta entrada vamos a intentar explicar un poco la estructura de directorios en Linux, concretamente la que se define en el FHS (Filesystem Hierarchy Standar) que es un estándar definido por un grupo de organizaciones (entre ellas empresas como HP, Red Hat o IBM). Eso sí, luego cada distribución es un mundo, y los estándares no se siguen al 100%.

Si listamos el contenido del directorio raiz en nuestro Linux (mediante cd / nos situamos en el raiz y con ls hacemos el listado) veremos algo similar (en este caso es mi Xubuntu a lo siguiente.

LinuxFHS_1

Los directorios que nos encontramos son los siguientes:

  • bin: Es el directorio en el que encontramos los principales ejecutables del sistema.
  • sbin: Contiene ejecutables reservados al superusuario.
  • boot: El directorio boot contiene los elementos necesarios para el arranque del sistema.
  • dev: En Linux los dispositivos como particiones de discos duros, modems, terminales y demás se representan como un fichero. El directorio dev continene dichos elementos (devices en inglés).
  • etc: Este directorio contiene la configuración de nuestro sistema.
  • home: Dentro de este directorio se encuentran los directorios de los distintos usuarios del sistema. Es algo similar al Documents and Settings de los sistemas Windows.
  • lib: En este directorio se encuentran librerías de uso común por distintas aplicaciones como los ejecutables de bin y sbin.
  • media: En media se suelen montar los elementos no permanentes tales como memorias usb o cdroms. Este es un directorio de relativamente uso reciente, aunque yo las distribuciones que uso ya lo utilizan.
  • mnt: Este directorio antiguamente se utilizaba para montar casi todo. Hoy en días según el FHS se debe utilizar para montajes temporales por parte del administrador.
  • opt: En este directorio se debería instalar el software de terceras partes. Sería algo similar al “Archivos de Programa” o “Program Files” de Windows.
  • proc: Este es un directorio virtual en el que el núcleo y otros procesos muestran su estado. Por ejemplo el archivo uptime mantiene el tiempo que lleva en funcionamiento el sistema.
  • root: Es el directorio personal del superusuario.
  • srv: En srv según el estandar se deberían situar los ficheros que sirve nuestro sistema (a través de un servidor web o ftp por ejemplo). Sin embargo no está demasiado difundido su uso.
  • sys: Otro directorio virtual que es utilizado por los elementos conectados al sistema, como los elementos Plug and Play.
  • tmp: Es el directorio de uso temporal del sistema.
  • usr: Este directorio es toda una estructura de directorios estáticos (no varían) que contiene tanto software como otros recursos. Podría ser compartido entre varios sistemas.
  • var: Otra gran estructura de directorios, aunque contrariamente a usr, la información que se almacena en var es variable, como por ejemplo los logs del sistema.

Como podemos ver, no es una estructura sencilla ni especialmente intuitiva, por lo que no es de extrañar que algunas distribuciones como por ejemplo Gobolinux utilicen una estructura completamente diferente.

24 julio 2009 at 8:24 am Deja un comentario

Entradas antiguas Entradas recientes


Mi perfil

View Miguel Orbegozo's profile on LinkedIn

Feedjit

Feeds

Otros…

BlogESfera Directorio de Blogs Hispanos - Agrega tu Blog

Bitacoras.com

Add to Technorati Favorites