los caballeros que dicen NI!

Saliendo de la crisálida

2011-09-15T08:05:00.000-07:00

Cuando trabajamos en un equipo ágil, ¿A que nos referimos exactamente con mejora continua?

¿La capacidad de dar cada vez mejores soluciones tecnológicas? Todos sabemos que los desarrolladores muchas veces pecamos de querer “rizar el rizo”. Se nos puede ir de las manos, y la satisfacción y el ego personal nos llevan a hacer cosas sólo porque se pueden hacer.

¿El aumento de la velocidad? Un aumento indiscriminado de la velocidad nos puede llevar a un descenso de la calidad si no lo tratamos adecuadamente, y todo el mundo sabe que esto es “pan para hoy y hambre para mañana”. Los bugs de ayer nos restan velocidad en el sprint de mañana.

¿Aumento de la calidad? Cierto es que aumentando la calidad de nuestro código, de nuestras entregas... vamos a ser un equipo mucho más rápido. Pero tampoco hay que obsesionarse en exceso montando sistemas automáticos exagerados, para no perder de vista el compromiso del sprint.

Lo que yo entiendo por mejora continua es: mejorar el funcionamiento como equipo. No podemos tener al especialista y único conocedor de partes importantes de la aplicación porque nos lleva a dependencia excesiva de un individuo en concreto. No podemos saltarnos los criterios de calidad del equipo, porque las buenas intenciones se suelen quedar en eso, buenas intenciones. Tenemos que encontrar una “norma” de trabajo con la que todo el equipo esté cómodo y que nos salga de manera natural, no podemos depender de tareas que pueden caer en el olvido.

Poco a poco, retrospectiva a retrospectiva, debemos tender a crear un entorno de trabajo en el que nos sintamos cómodos porque: ¡un equipo feliz es un equipo que funciona!

Quien apoya tu teoría

2011-09-13T10:07:00.001-07:00

Cuando estamos desarrollando una aplicación informática queremos saber que nuestro código es bueno, que funciona como queremos, que no vamos a encontrarnos nada inesperado. Para ello existen las pruebas automáticas (test unitarios, de integración).

Ahora bien cómo podemos demostrar que algo que tanto nos gusta nos como es hacer pruebas automáticas de nuestro software da el resultado esperado. Evidentemente demostrando que no tenemos errores. Esto suena obvio a la par que arbitrario.

Una forma de apoyar el hecho (que no teoría) de que realizar pruebas automáticas sobre nuestro software nos va a dar los resultados de los que tanto se habla (y muchos somos unos convencidos, y la mayoría unos escépticos) es la cobertura.

La cobertura es una medida que nos indica el grado de código de una aplicación que está “testeado”. Con una herramienta adecuada podemos obtener estadísticas tales como: que cantidad de líneas de código hay testeadas en una clase o paquete, cual es la cobertura de las condicionales (if, switch, for, try-catch...) de nuestro código... De esta manera conocemos un dato mas sobre lo buenas o malas que son nuestras pruebas automáticas de código.

En mi opinión (experiencia personal) el hecho de realizar muchos test “sin ton ni son” por sí sólo no te evita el cometer errores ni te garantiza que pruebes lo que realmente quieres probar. Sin embargo el hacer unos BUENOS test en combinación con mantener siempre una alta cobertura de código te va a proporcionar todas las ventajas de las que tanto se ha oído hablar en el mundo del testeo de software.

Lo sugerido para una nueva aplicación es mantener siempre una alta cobertura poniendo un mínimo obligatorio (70%, 80%, 90%...) al gusto del consumidor, del que no se pueda bajar. Como siempre consensuado por el equipo que va a desarrollar la aplicación y va a hacerla perfec... con el mínimo de bugs posible.

Realizando un problema con TDD

2010-03-19T07:06:00.000-07:00

Desarrollo guiado por pruebas, o Test-driven development (TDD) es una práctica de programación que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). ( wikipedia ) para el que no sepa de que va.
Voy a tratar de explicar de forma sencilla los conocimientos que he adquirido sobre esta técnica, sobre todo en la última semana motivado por un curso. Este curso lo impartió Carlos Ble, que además es el autor de un libro muy interesante sobre el desarrollo utilizando TDD, el único en castellano. Para todo el que quiera saber más es preferible que consulte los trabajos de Carlos que sabe mucho mas que yo al respecto.

Bueno dada una pequeña introducción sobre que es TDD voy a prensentar el ejemplo que se me ha ocurrido desarrollar. Posiblemente no sea el mejor ejemplo, pero me ha parecido muy didáctico para un primer contacto con TDD.

Tenemos una clase coordenada (Coordinate.java) a la que le vamos a incluir un método compareTo. Éste método funcionará de manera similar al de la clase String. Pero para ello, antes de empezar a implementar la funcionalidad vamos a implementar un test con jUnit (CoordinateComparationTest.java), y creamos un método de test nuevo (testCompareCoordinatesSame). El método tratará de comparar dos coordenadas que son iguales.

@Test
public void testCompareCoordinatesSame() throws Exception {
//Data
Coordinates coord1 = new Coordinates(0.00, 0.00);
Coordinates coord2 = new Coordinates(0.00, 0.00);
//Execution
int greater = coord1.compareTo(coord2);
//Assertions
assertEquals(0, greater);
}

Como podemos ver el test tiene tres partes diferenciadas:

Creación de los datos de prueba.
Ejecución del método a testear.
Comprobación del o los resultados.

Después de implementar el método de test nos encontramos con que el metodo compareTo nos sale en “rojo”, es decir, el método no existe. Pues bien procedemos a crear un método compareTo en la clase Coordinate.java con el código mínimo necesario para que exista el método. (Nos referimos con código mínimo al código necesario para dar solución a una cuestión, en este caso evitar el error: no existe método...).

/**
* Compares two Coordinates
*
* @param coord2
* the other coordinate
* @return result == 0 if both are equal; result > 0 if first is higher; in
* other case result < 0
*/
public int compareTo(Coordinates coord2) {
return -1;
}

Ahora que ya tenemos el método creado procedemos a lanzar los test. Comprobamos que ha fallado, puesto que esperábamos un 0 (ambos iguales) y nos devuelve un -1. Ahora si, procedemos a implementar la funcionalidad que nos devuelva un 0 al comparar dos coordenadas iguales.

public int compareTo(Coordinates coord2) {
int res = -1;
if (this.equals(coord2)) {
res = 0;
}
return res;
}

Al volver al lanzar el test debería pasarlo sin problemas. Para esto nos hemos valido del método equals de la clase (para ello debe estar implementado).

Pues bien, seguimos con el siguiente caso, que pasa cuando tenemos dos coordenadas cuyas latitudes sean diferentes. Pues creamos un nuevo método que pruebe dos coordenadas cuyas latitudes sean diferentes.

@Test
public void tesCompareCoordinatesFirstHigherLatitude() throws Exception {
//Data
Coordinates coord1 = new Coordinates(1.00, 0.00);
Coordinates coord2 = new Coordinates(0.00, 0.00);
//Execution
int greater = coord1.compareTo(coord2);
//Assertions
assertTrue(greater > 0);
}

Ahora lanzamos el test y comprobamos que ha fallado nuevamente. Procedemos igual que antes, vamos a implementar este caso, la primera latitud es mayor que la segunda.

public int compareTo(Coordinates coord2) {
int res = -1;
if (this.equals(coord2)) {
res = 0;
} else if (this.getLatitude() > coord2.getLatitude()) {
res = 1;
}
return res;
}

Ahora procedemos de la misma manera, lanzar el test y recoger los frutos.

El siguiente caso sería comprobar que pasa cuando dos coordenadas tienen la misma latitud y distinta longitud.

public void tesCompareCoordinatesSameLatitudeFirstHigherLongitude()
throws Exception
{
//Data
Coordinates coord1 = new Coordinates(0.00, 1.00);
Coordinates coord2 = new Coordinates(0.00, 0.00);
//Execution
int greater = coord1.compareTo(coord2);
//Assertions
assertTrue(greater > 0);
}

Nuevamente el procedimiento es el mismo, lanzar el test, comprobar el resultado y en caso de ser negativo volver a implementar la funcionalidad necesaria.

public int compareTo(Coordinates coord2) {
int res = -1;
if (this.equals(coord2)) {
res = 0;
} else if (this.getLatitude() > coord2.getLatitude()) {
res = 1;
} else if (this.getLatitude() == coord2.getLatitude() &&
this.getLongitude() > coord2.getLongitude())
{
res = 1;
}
return res;
}

Una vez lanzados los test (es importante lanzar todos cada vez para ver que no hemos perdido funcionalidad ya implementada) y comprobar que han pasado correctamente, iríamos a comprobar mas casos: la segunda latitud mayor que la primera, ambas longitudes iguales y la segunda longitud mayor... Y si los test no pasan implementar la nueva funcionalidad.
En este caso parece que toda la funcionalidad posible ya se ha implementado (hay que asegurarse con los casos de test propuestos). Con lo cual la funcionalidad estaría terminada y cubierta ante posibles bugs, y hemos asegurado (o al menos intentado) que el problema se ha resuelto con el mínimo código posible.

Mejorando un poco el rendimiento

2010-03-18T01:22:00.000-07:00

Muchas veces, cuando estamos escribiendo código seguimos una serie de prácticas que en ocasiones pueden perjudicar al tiempo de ejecución de la aplicación.
Un ejemplo muy claro puede ser en la ejecución de un bucle:

for(int i = 0; i < oneList.size(); i++){
***
}

Cada vez que pasamos por el bucle consultamos el método size que es mas lento que por ejemplo:

int size = oneList.size();
for(int i = 0; i < size; i++){
***
}

La mejora de rendimiento si que es cierto que es mínima, pero todo depende de lo grande que sea la lista en este caso, si hay bucles anidados...
El primer fallo que podemos ver en esta solución es: ¿Qué pasa si alguien modifica la variable size? pues muy simple, "la hemos liado". Sin embargo la solución a esta cuestión es evidente:

final int size = oneList.size();

Nos aseguramos que nadie pueda modificar la variable.

Podemos utilizar esta "mejora" en otro caso similar a este:

for(int i = 0; i < oneObject.getList.size(); i++)

En este caso podemos observar que el número de accesos es mucho mayor, y puede aumentar considerablemente, por lo que la mejora de rendimiento al refactorizar, ahora si, se podría tener mas en cuenta.

Podemos aplicarlo no sólo a bucles si no a llamadas que veamos repetidas a lo largo de todo el método:

if(oneObject.getOneProperty().getValue() != null)
print(oneObject.getOneProperty().getValue());

Simplemente extraemos ese value a una variable.

Si desarrollamos con algunos IDEs muchas veces nos ofrece funcionalidades que nos permiten refactorizar el código una vez editado. Por ejemplo, en Eclipse, al seleccionar la porción de código y pulsar la combinación de teclas alt + shift + L nos extraería una variable a partir de una expresión, y la sustituye cada vez que se la ha llamado, por el nombre de la variable. Funciona fráncamente bien pero aconsejaría revisar lo que hace antes de darlo por válido...

Se puede hacer algo similar con los Strings en java. Cuantas veces nos hemos encontrado algo similar a esto:

String a = 1 + " " + " " + 2 + " " 3 ***

Cada vez que nos encontramos con un " " o "lo que sea" estamos creando un nuevo String (en otra entrada hablaremos sobre la suma de Strings y cómo mejorarlo utilizando StringBuffer) con la consecuente pérdida de rendimiento. Podemos símplemente extraer una constante para la clase que contenga ese valor y llamarla siempre que estemos tentados de crear una nueva, así sólo la creamos una vez. También es posible utilizar una clase que contanga constantes comunes para toda la aplicación. Sería algo similar a esto:

private static final String ESPACIO = " ";
***
String a = 1 + ESPACIO + ESPACIO + 2 + ESPACIO 3 ***
***

Hablando con personas mas y menos experimentadas en esto de la programación hemos tenido cierto debate, entre que la mejora puede ser mínima y que el código puede ser mas complicado de entender. Yo soy partidario de utilizar ésta técnica pero tampoco afirmo que sea lo mejor, eso lo dejo en manos de que cada persona o grupo de trabajo encuentre la técnica que mejor le venga.

Múltiples monitores

2008-04-09T13:15:00.000-07:00

Cuando trabajamos con ordenadores solemos tener muchas ventanas abiertas y superpuestas. Si estamos trabajando en una necesitamos ver el contenido de otra y nuestro monitor termina por quedarse pequeño. Muchas ventanas nos sirven para obtener información lo que ocurre en otra y con un monitor e incluso con un monitor mayor no podemos ver todo con un golpe de vista.

Una solución adecuada es la de añadir un nuevo monitor a nuestra mesa de trabajo. Hoy en día la mayoría de tarjetas gráficas soportan trabajar con 2 (en ocasiones mas) monitores sin necesidad de utilizar 2 ordenadores.

Algunos de los posibles usos:

Un diseñador de páginas web puede escribir el código que genera sus páginas en un monitor y en un segundo monitor visualizar en "tiempo real" el resultado de su trabajo. Además cada monitor puede tener una resolución de pantalla diferente.

Un programador puede escribir código en un monitor y ver la salida de datos en en segundo.

Y para los aficionados a la fotografía, las aplicaciones de retoque fotogáfico suelen tener muchas paletas y barras de herramientas que podemos mover al segundo monitor y tenerlas visibles en todo momento.

Y dejando volar la imaginación podemos encontrarle muchas mas utilidades, sino siempre podemos hacer algo asi:

Y algunos (sobre todo tus jefes) dirán: ¿Y todo esto para qué? pues ~~para continuar con el rigor científico que caracteriza a este artículo~~ hay un estudio que circula por la red que demuestra que la productividad puede aumentar entre un 20% y un 30%.
~~Nosotros lo podemos justificar como queramos ante los jefes, padres o parejas sentimentales, pero no nos engañemos, la finalidad de todo esto es chulear y jugar al Doom.~~

Compartición de ficheros fácil y rápido

2008-04-09T03:33:00.000-07:00

PipeBytes es un servicio web muy fácil de utilizar que nos permite intercambiar archivos con un amigo (bueno no hace falta que sea amigo). Creo que se basa en algún protocolo p2p (de esos que por lo visto son clandestinos y sólo utiliza la gente de mal vivir).

Las ventajas respecto a otro sistema es que sólo necesitas un navegador web (recomendado firefox, opera, konqueror...).

El funcionamiento es sencillo: Si quieres compartir un fichero previamente lo tendremos que subir desde nuestro equipo y pasar el enlace al interesado. Una vez aceptado el interesado la transfererencia, cuando ésta finaliza por el motivo que sea el fichero se borra del servidor, para volver a compartirlo habrá que subirlo nuevamente.

La url es la siguiente:
http://host01.pipebytes.com/

Para mas información visitad la página.