Seeya there!

Hoy toca hablar de patrones, o mejor dicho, de anti patrones. Esas cosas que se deben evitar por norma general.

Mucha de la gente que venimos de lenguajes procedurales (vaya palabro…) tipo C, tendemos a pensar de esta forma a la hora de programar en Java. ¿Por qué? Por que C no es un lenguaje orientado a objetos. Para representar en C un dato usamos lo siguiente:

typedef struct point { int x,y; } point;
....
y usamos punto.x
Así que cuando vamos a un lenguaje orientado a objetos tendemos a hacer cosas de este tipo:

public class Casa{
private String nombre;
private boolean alquilada;
private boolean habitable;
public void setNombre()...
public String getNombre()...
public void setAlquilada()...
public boolean isAlquilada()...
....
}

public class Persona{
private String nombre;
private List casas;
public void setNombre()...
public String getNombre()...
public void setCasas()...
public List getCasas()...
}
..
List casasNoAlquiladas= new ArrayList();
for(Persona persona: personas){
for (Casa casa : persona.getCasas()){
if (! casa.isAlquilada() && casa.isHabitable()){
casasNoAlquiladas.add(casa);
}
}
}


….

¿Cuál es el problema con esto? Pues que estamos utilizando las clases de negocio como simples estructuras de datos. Hemos avanzado en la tecnología, ¡ Avancemos en su uso también! Vale, siempre lo has hecho así, te sientes cómodo con esta solución ¿Con qué problemas te vas a encontrar?

• Lógica de negocio dispersa por toda la aplicación, seguramente incluso repetida.
• Complejidad a la hora de hacer las clases controladoras
• Estamos exponiendo la forma en que mantenemos las casas al exterior. Solo debemos exponer las entities, no los value objects! (esto daría para otro post)
• ¿La lista de casas que devolvemos es inmutable? ¡Cuidado!
• Sumando todo lo anterior: Más complejidad = más bugs, además de menos extensible

Bueno y ¿Cómo lo solucionaríamos? Muy fácil, introduciendo la lógica de negocio en las clases de negocio:

public class Casa{

….

private final String nombre;
private boolean alquilada;
private boolean habitable;
public String getNombre()...
public void setAlquilada()...
public boolean isAlquilada()...
public boolean isAlquilable(){
return (! casa.isAlquilada() && casa.isHabitable());
}

….
}

public class Persona{
private String nombre;
private List casas;
public void setNombre()...
public String getNombre()...
public void setCasas()...
public List getCasasAlquilables(){
List list= new ArrayList();
for (Casa casa: casas){
if (casa.isAlquilable()) list.add(casa);
}
return list;
}
}
..
List casasNoAlquiladas= new ArrayList();
for(Persona persona: personas){
casasNoAlquiladas.addAll(persona.getCasasAlquilables());
}

Más fácil ¿Verdad? Si no conocías este error común, seguro que ahora te vienen a la memoria un montón de casos en los que podrías ahorrar mucho en código y hacerlo mucho más extensible.

Otro ejemplo: En cierto cliente, hace un cierto tiempo y haciendo cierta aplicación De una clase muy importante en el modelo (Entity) sacabamos unos cuantos informes. En un momento dado, me pidieron que si se podía cambiar cierta lógica a la hora de generar los informes. Mi respuesta fue: tardo 2 segundos (y uno para pulsar ctrl+shif+T en Eclipse!! ). ¿Por qué? Porque mi clase de ese entity tan importante tenía lo siguiente:

List<Dato> getSubObjetosQueCumplenCiertaCondiciónDeNegocio(){
for....{
if (obj.condicion1() && obj.condicion2() && entity.....)

lista.add(...)
…

}
}


Lo que me pedían era un cambio de negocio. Yo había entendido mál, un objeto de tipo Dato debía de cumplir obj.condicion() && obj.condicion3(), pero el cambio no suponía el menor esfuerzo. ¿Cuánto hubiese costado si hubiesemos tenido este código disperso por toda la aplicación?

Se puede discutir si incluir los DAO dentro del objeto de negocio es bueno o malo (Rails y Grails lo hacen), si algúna lógica concreta debería ir en los controladores, pero al menos este tipo de cosas creo que pueden ayudarte bastante.

Bueno, no se si ha quedado claro, hoy no he dormido mucho y estoy muuuuuy cansado

(within a while body)

...
if (log.isDebugEnabled()) log.debug("Parsing line " + (lineNumber++));
...
lineNumber used here
...

You might be wondering: what´s wrong with it? Well, it turns out that this sort of construction it could become extremely difficult to spot in certain conditions. Imagine a hypothetical situation where this code is not working properly in the production environment, and meanwhile the developer in charge of this block of code -the guy as cool as a cucumber- is totally sure about the correctness of it. Okay, you got it, you may be thinking of me: “How noob this guy is!”; but Hey!, sometimes you are toiling late in the night and this kind of bugs pass unnoticed until you receive an email from your Development Manager muttering:

Subject: Potential bug

I have come across with this statement -incidentally- while surfing the code. Beware that the log will be printed out only if the log level is set to DEBUG, so the lineNumber variable won´t be incremented.

All the best,

Your Development Manager

Guess which level the Production Support had established in their environment? Fortunately, I started off saying “Imagine a hypothetical situation …“.

And no matter how many people share it, the idea is not diminished. When I hear your idea, I gain knowledge without diminishing anything of yours. In the same way, if you use your candle to light mine, I get light without darkening your. Like fire, ideas encompass the globe without lessening their density.

Sometimes, in this hectic world, you realise that your knowledge about a subject has increased considerably, and probably at that moment you are an expert on it. The “problem” now is how you ought to handle that situation in regards to your team mates. You can keep such expertise for your own benefit, considering them a sort of nuissance, if not worse. But that is not supportive. As I see it, helping your co-workers is a professional duty, no matter the reason. No matter the guy. You must do it because you must do it. And that´s all. There shouldn´t have to exist more reasons besides that one. Yeah, I know, there are lotsa situations where excuses arise in order not to help someone, but anyway I think it is a good principle to start with. Write it down in your tickler file.

Nonetheless, there are some important benefits of being supportive and willing to give others a hand:

1. You can cause a great impact in the morale of your huddle, because your positive attitude might make them want to better themselves in turn. The overall competence of your team spikes. Betcha! That´s good for you as well. If this doesn´t work, pull out.
2. You may think you are an expert. Believe me: even experts are requested to answer questions they don´t know about! IMHO, I consider this awesome. The search for those answers permits you to assimilate unexplored areas of the topic on discussion. Therefore, you are gaining more insight, which is always neat. For example, the other day someone asked me about subversion, and how this system performs the merging. I thought I had that under control. I explained to him the basics of the merging in subversion, the reason it should be called diff-and-apply instead of merging, how two revisions from the origin and destination trees are applied to the working copy, and so on. So far, so good. All the same, point in time, he asked me how a merge was actually applied to a specific file in the working copy. That was kinda going thorugh bad times, because I didn´t understand it seamlessly, hence I wasn´t able to provide him with an answer. Well, in fact, I had to look up that section in a subversion book, read it thoroughly, sink in all that stuff, and lastly give to him the right answer. I could have told him to grab a book and look it up. That would have been a lazy behaviour and, what it´s much worse, I would still be thinking I have that part under control now. It´s wonderful not to be an expert in nearly anything, isn´t it?
3. Corollary: the rest of the team come to trust they can rely on you when they feel they´re dead in the water.

Corollary to the last Corollary: Be nice

In the search of an alternative to JUnit, in relation to the testing of our classes, we -Mikel and I- decided to give TestNG a try. This testing framework takes advantage of a useful feature introduced in the release 5.0 of the Java Language: the annotations. In addition, it provides a rich set of facilities to ease the unit and integration testing of Java classes, like groups and data providers. Unfortunately, these are very well explained in the home page of the project, so let´s consider them as being out of the scope in regards to the main thread of this post.

The Problem

What we want to have: test cases running within a transactional context AND take advantage of the TestNG facilities. The former is neatly addressed by a class named AbstractTransactionalSpringContextTests, present in the Spring´s mock package. The latter, well, pretty obvious. What it isn´t so obvious is the way to combine both. Why? TestNG does not provide a direct way to surround the test cases with a transaction, so a rollback action is performed at the end of every test. This way, we are able to avoid side effects between test executions, because one test inserts a row and the next one didn´t expect it, or because a database row is updated between executions breaking some assertions, or because … you get the idea. When we decided to start using TestNG as our main framework for testing, this absence lead us to ask Cedric Beust, the TestNG project leader, about some way to accomplish with the transaction stuff. He responded us very kind and rapidly, recommending to implement the rollbacking in an @AfterMethod method.

TransactionRollbackTearDownTestCase

Note: for this class’s name origin, take a look at this site

Probably Cedric is completely right, but we like how AbstractTransactionalSpringContextTests does its business, and of course, the integration with the Spring´s IoC in order to inject the dependencies to the test classes. For that reason, we have come up with an adapter class, which permits us to run TestNG test cases within the transactional context provided by the Spring class. It is kinda adapter because we change the way the class AbstractTransactionalSpringContextTests is used (i.e. inheriting from it), right now we can extend from the new base class and define our test cases as the usual TestNG manner (i.e. through the use of annotations). It is not an adapter as in the software design patterns.

The class is named TransactionalRollbackTearDownTestCase, and following there is a diagram of its relationships:

The code of this class could prove more descriptive than me trying to explain how it does its job:

package com.centuryminds.test;

import org.springframework.test.AbstractDependencyInjectionSpringContextTests;
import org.springframework.test.AbstractTransactionalSpringContextTests;

import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;

/**
 * Base test class which permits: 1) Inject dependencies defined in a Spring
 * context. The aforementioned dependencies must be declared as protected
 * members 2) Perform a rollback action after every test. Basically, it
 * acts as an adapter between the TestNG test case structure and the facilities
 * provided by the class {@link AbstractDependencyInjectionSpringContextTests}
 * in the Spring package
 *
 * @see AbstractDependencyInjectionSpringContextTests
 * @see AfterMethod
 * @see BeforeMethod
 */
public abstract class TransactionRollbackTearDownTestCase extends
		AbstractTransactionalSpringContextTests
{

	/**
	 * Test Fixture
	 *
	 * @throws Exception if a error occurred during the fixture execution
	 * @see {@link AbstractDependencyInjectionSpringContextTests#setUp()}
	 * @see {@link AbstractDependencyInjectionSpringContextTests#setPopulateProtectedVariables(boolean)}
	 */
	@BeforeMethod
	protected final void before() throws Exception
	{
		setPopulateProtectedVariables(true);
		super.setUp();
	}

	/**
	 * Test Teardown
	 *
	 * @throws Exception if a error occurred during the teardown execution
	 * @see {@link AbstractDependencyInjectionSpringContextTests#tearDown()}
	 */
	@AfterMethod
	protected final void after() throws Exception
	{
		super.tearDown();
	}
}

As it can be seen, this class is really simple. It defines two final methods, both TestNG-annotated which delegate the test fixture and teardown actions to the underlying parent implementation. Therefore, every time a test case method is going to be executed, before() will inject the dependencies defined in the Spring context and will create and start a new transaction context. The method tearDown() in turn will perform a rollback action just after the test ends.

Extending the Hierarchy

Obviously, the class above is not enough: where are the dependencies to be injected defined? We have to tell AbstractTransactionalSpringContextTests where to look for them. This can be achieved by a subclass of TransactionalRollbackTearDownTestCase, for example:

package com.centuryminds.test;

/**
 * Base test class that specifies the spring contexts containing the dao
 * definitions. The subclasses must provide an implementation of the method
 * {@link #getConfigLocations()}, specifying the files with the spring contexts
 * holding the definitions of the dao and its dependencies
 */
public class BaseDAOTestCase extends TransactionRollbackTearDownTestCase
{
	/**
	 * @see org.springframework.test.AbstractDependencyInjectionSpringContextTests#getConfigLocations()
	 */
	@Override
	protected String[] getConfigLocations()
	{
		return new String[] { "classpath:applicationContext-datasource.xml",
				"classpath:applicationContext-service.xml" };
	}
}

The Actual Test Class

One important benefit of the separation above is that we could define several BaseDAO* classes, each one of them declaring its own context set. Let´s see an example DAO test class extending from BaseDAOTestCase:

package com.centuryminds.test;

import java.util.HashSet;

import org.testng.annotations.Test;

import com.threefish.aquarium.dao.hibernate.GenericHibernateDAO;
import com.threefish.aquarium.model.Role;
import com.threefish.aquarium.model.User;

/**
 * Tests for RoleDAO
 */
public class RoleDAOTest extends BaseDAOTestCase
{
	/** role dao */
	protected GenericHibernateDAO roleDAO;

	/** role */
	private Role role;

	@Test
	public void testCreate() throws Exception
	{
		int amount = roleDAO.findAll().size();

		// let's create a new role to persist
		role = new Role();
		role.setName("testrole");
		role.setDescription("Master of Universe");
		role.setUsers(new HashSet());

		roleDAO.makePersistent(role);

		assertNotNull(role.getId());
		assertEquals(amount + 1, roleDAO.findAll().size());
	}

	@Test
	public void testSuccessfulGet() throws Exception
	{
		role = roleDAO.findById(Long.valueOf(1));

		assertEquals("admin", role.getName());
	}

	@Test
	public void testUpdate() throws Exception
	{
		role = roleDAO.findById(Long.valueOf(1));
		role.setDescription("Super Administrator Role");
		roleDAO.makePersistent(role);

		assertEquals("Super Administrator Role", role.getDescription());
	}
}

The RoleDAO test class makes use of a custom generic DAO framework, but despite that I think it is pretty self-explanatory. We shall try to explain the generic DAO related interfaces and classes in another post when we get a chance, but for now we have enough.

The test methods are executed within a transaction per test method, which is rollbacked at the very end of it. So, the role insert in the first test (testCreate()), would be rollbacked and future tests depending on the initial state (i.e. the state before testCreate() ran) wouldn´t be affected. We accomplished with the goal of executing the test cases in isolation. Thanks Spring! We accomplished with the goal of using some of the features offered by TestNG. Thanks to you as well!

Future

We are aware about the drawbacks of this solution, and we are pretty sure about the fact that there must exist a more sophisticated solution out there, hence we are very willing to listen to your suggestions to improve the general structure of our current one. We’ll stay tuned …

“It seems hard to justify the huge amount of funds spent in this bridge, getting it ready for The Big One*, when one of our core goals consists of changing its external appearance nothing whatsoever“

* Referring to the earthquake likely to happen in California

Para mi debut en el blog, voy a contar brevemente mis primeras impresiones con mi nueva consola: Nintendo Wii. Soy un jugador casual de videojuegos a quien le gusta, sobre todo, jugar con sus amigos de vez en cuando. Aunque en estos momentos no tengo demasiado tiempo libre (tengo pendiente por leerme el Java Concurrency In Practice y la especificación de OSGi) me he comprado la consola sin dudarlo.

Después de estar una horas jugando la RedSteel en el salón, tipico mata-mata en primera persona, sólo puedo decir que es una pasada. La capacidad de inmersión en el juego es espectacular, gracias al mando. Esto de poder apuntar con el mando como si fuera una pistola le da una nueva vida a los “shot´em up”. Estoy deseando ver las aplicaciones del Wiimando en otro tipo de juegos.

Por otro lado, no he visto ningún problema para jugar con un proyector. Leí hace poco un post que decía que había problemas para jugar con la Wii en un proyector. Al parecer comentaba que existía perdida de precisión en el mando, debido a las distancia y al tamaño de la pantalla generada por el proyector. Yo he encontrado insignificante la perdida de precisión del mando en un proyector y queda compensada por el tamaño de la imagen

Por ultimo, este fin de semana voy a comprobar como de divertido es jugar con los amigos. Veremos si la consola pasa la prueba de la jugabilidad. Va a tener un duro juez, un amigo que piensa que el último juego divertido es el Emilio Butrageño del Amstrad CPC y que los juegos actuales son demasiado complicados.

Bueno, espero seguir contando más cosas, aunque creo que después de esto no me van a dejar volver escribir. A por cierto, este es mi Mii. He salido muy favorecido.

Basically, the programs written in functional languages like Lisp or Haskell are based on function definitions. I don´t want, by no means, to give a thorough explanation of the features that functional languages offer because, among other things, I am not an expert on such languages (although I´d like to). I am writting this because not until I tried to implement some probs kinda recursive-natured, did I find how quick & fun this kind of programming style is.
Let´s set out to implement a naive algorithm for sorting lists in Haskell, so for a given input list, we get the corresponding sorted list. The function sort takes an argument of type list and returns a new list representing the former one in order.

-- Sort a list
sort :: Ord a => [a] -> [a]
sort [] = []
sort (x:xs) = insert x (sort xs)

The first line comprises the function definition, which takes a list of elements of type a, and returns the same type ([a] -> [a]). The string “Ord a” restricts the potential members of the list to types compliant with the ordering rules (integers for instance). But this is Haskell specifics, not very appealing. Let´s go to the implementation. The second line is the implementation of the function for an empty list, which in turn returns an empty list.
Lokking over the last line, we can notice that it defines how a non-empty list, (x:xs) being x the first element and xs the remainder, is going to be sorted. For that, it makes use of a new function named insert. Here you are:

-- Insert an element in to a list, maintaining the order
insert :: Ord a => a -> [a] -> [a]
insert y [] = y:[]
insert y (m:ms)    | y <= m = y:(m:ms)
                   | y > m     = m:(insert y ms)

This second function takes two arguments, the first one being an element of type a, and the other a list of elements of the same type. Same type restrictions as in the parent function. The return value is another list. The trivial case (insert y [] = y:[]) concatenates an element with an empty list. The general case says (last two lines): “if the element to insert is less or equal than the first element in the list, concatenate them. Otherwise, join the first element in the list with a recursive call using the same element and the remaining elements in the list”. Easy ha!

Let´s see the recursive call stack for this execution:

sort [9, 3, 5]
       |
insert 9 (sort [3, 5])
       |
insert 9 (insert 3 (sort [5]))
       |
insert 9 (insert 3 (insert 5 (sort [])))
       |
insert 9 (insert 3 (insert 5 []))
       |
insert 9 (insert 3 5:[])
       |
insert 9 (3:5)
       |
3:(insert 9 5:[])
       |
3:5(insert 9 [])
       |
3:5:9:[]
       |
[3, 5, 9]

Yay! Some may argue that this implementation is time-taking, that it does too many recursive calls even for small inputs. A complete resource waster. I couldn´t do anything else but agree with that, but, you know what? I don´t care! It´s just this code´s neatness what makes me feel thrilled. I look at it and I think: “Ey dude! It´s as pretty as a picture!”. If you still feel like sprucing it up, a good starting point could be this one.

Another good point in the functions above is that I didn´t say that the input list had to hold numeric elements! Surprisingly (not for an expert), the following execution outputs a nice result (guess why?):

sort ["Water", "The", "Dead", "In"]

... (call trace left out)

["Dead","In","The","Water"]

For the most part, this is what I wanted to show here. Isn´t it worth the hassle? At least for me, no doubts.

String query=”select user, pass from user where user=’”+user+”‘ “;

Si introducimos como usuario pepito, tenemos que se ejecuta:

select user, pass from user where user=’pepito’

¡Fenomenal! …¿Fenomenal? y si en vez de usar pepito pongo ‘;drop table xxxx; — , ¿Qué pasa?

select user, pass from user where user=”; drop table xxxx; — ‘

¡Fenomenal! Nos acabamos de cepillar la tabla xxxx;

Vale, entonces es cuando pensamos, pues filtramos todos las comillas simples. Y entonces es cuando viene nuestro mejor cliente, el señor O’Brian y decide que si nuestro sistema no acepta su nombre quizás es que no merecemos que se gaste dinero en nosotros. Así que bueno, aceptamos ‘, pero sustituimos ‘ por ” en todos los literales.

Encones tenemos algo así:

insert into xxxx values … O”Brian ….

Y en BD queda como O’Brian.

Joder. ¡Somos buenísimos! Hemos arreglado el problema del SQL Injection con sustituir ‘ por ” doble… ¿o no?

Imaginamos que una vez tenemos un usuario en nuestra BD, luego utilizamos dicho dato para hacer otras queries a su vez (Ej.:”Dame todas las compras del usuario X”). Como solo securizamos las queries que tenían entrada de usuario, resulta que seguimos teniendo la siguiente query:

query=”select * from compras where usuario=’”+usuario+”‘”;

¡Y ya la tenemos montada otra vez!

Resulta que como protegemos la query de entrada pero, una vez almacenado el registro, guardamos el texto sin proteger, tenemos otra vez el mismo problema.

Conclusión 1 : Protege TODAS LAS QUERIES, no solo las que crees que son de entrada.

¿Filtramos solo las comillas simples?

Bueno, quizás tengas algo así:

String id= xxxxx

query=”select * from tabla where id=” +id;

Siendo el id numérico en la BD. Pues ya la tenemos montada, no nos hacen falta comillas para nada.

Podemos dar a id el valor de id, o algo peor id; drop table xxxx; o quitamos el resto del filtrado con — o /** **/ (Comentario en SQL) ,etc.

Otra: en mysql por ejemplo 9e3 es 9000, cuidado con pensar que limitando el tamaño del parámetro podemos conseguir algo…

Conclusión 2: Son vulnerables TODOS los campos, repasa todos y cada uno de los campos

Otro error común es pensar, bueno, nuestro modelo de datos es complejo, nadie va a adivinar el nombre de las tablas y de los campos…¡MAL! Pueden sacarlos si los errores de BD se sacan directamente al usuario. Ahh vale, tu siempre rediriges a una página de error, estas a salvo…¡EEEERRROOOOOR! Se pueden sacar por inferencia. ¿Cómo? Con sentencias condicionales:

select case when condicion then ‘menor’ else ‘mayor’ end;

Es decir, devolvemos un texto o otro dependiendo de la condición.

Así la condición puede ser, dame el primer bit de cierto campo. Y el then/else un elemento de diferenciación. Donde la “diferenciación” pueden ser varias cosas:

• Esperas de tiempo diferente
• Variar la respuesta
• Devolver error en uno y en otro no (Ejemplo: el campo a devolver es un numérico y en uno devolvemos 3 y en otro ‘caca’ o más fácil: “select case when condición then 37 else 37/0″)

Además pueden atacar a las tablas de metadatos donde se almacenan las descripciones de las tablas, etc.

Por tanto…

Conclusión 3: Nuestro sistema no es invulnerable porque “ocultemos” los nombres de tablas y campos.

Hay unos cuantos caracteres más que filtrar. SQL es un lenguaje y por tanto hay muchas formas de hacer las cosas, así que si usas Java lo mejor es utilizar Prepared Statements.

Un presentación sobre el tema aquí.

UPDATE: Rubén me envía este enlace. Guía para desarrollo Web seguro. Imprescindible.

Lo mejor que tiene es que es facilísimo poner un servlet a escuchar en una url, vamos, cosa de niños. Bueno, no me enrollo más, aquí va el código:

import java.io.IOException;

import javax.servlet.Servlet;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;

import org.mortbay.jetty.Server;
import org.mortbay.jetty.servlet.Context;
import org.mortbay.jetty.servlet.ServletHolder;

...

server= new Server(8080);
Context root = new Context(server,"/contexto",Context.SESSIONS);
root.addServlet(new ServletHolder(new Servlet(){
 public void destroy() {}
 public ServletConfig getServletConfig() {return null;}
 public String getServletInfo() {return null;}
 public void init(ServletConfig arg0) throws ServletException {}
 public void service(ServletRequest request, ServletResponse response)

         throws ServletException, IOException {
     response.getOutputStream().write"HOLA MUNDO"getBytes());
 }
}), "/servlet");
server.start();

 ...

Y ya tenemos nuestro servlet escuchando en http://localhost:8080/contexto/servlet. Este servlet tampoco hace mucho, pero da una idea de lo fácil que puede ser poner a escuchar un servlet en un Jetty embebido.

Este post esta totalmente basado en uno de Joel Spolsky, concretamente éste; y mi experiencia de haberlo puesto en práctica. Te recomiendo leer no solo ese post, sino cada uno de los posts que tiene en su blog, ¡Son buenísimos!

La solución

¿Planificación Ágil? Sí, es lo que tiene el término “ágil”, ahora todo lo que tenga que ver con el desarrollo de software tiene que ser ágil: metodologías ágiles, testing ágil, agilidad ágil… Así que, ¡Qué demonios! Planificación ágil, o como no morir en el intento de planificar un proyecto.

¿Cómo planificamos? Pues de la forma más fácil…¡Con Excel! No necesitamos tener ninguna herramienta hipercompleja (leáse Ms Project), no necesitamos pagar miles de euros. Lo único que necesitamos es una mínima organización, y esto lo conseguiremos con Excel y una cierta disciplina.

Eres un fanático del Open Source, un vago y maleante que solo utiliza ese sistema operativo de hackers llamado Linux. ¿ Solo se puede planificar ágilmente con un producto de MS ? ¡No! Todo lo que cuento se puede realizar perfectamente con Open Office, de hecho tengo dos versiones, una para OO y otra para Excel. La única limitación es que, aunque OO permite tablas pivotadas, no permite gráficas pivotadas. Pero bueno, esto es un poco pijada (o no…), además supongo que en versiones posteriores de OO incluirán gráficas pivotadas. ¡Así que ya no hay excusa! ¡Arranca tu LFS y planifica tus proyectos de forma ágil con OO!

La forma más sencilla de organizar las tareas de un proyecto sería realizar una lista de TO-DOs (Cosas por hacer), esto lo podemos hacer con un simple fichero de texto, ¡Incluso con papel y boli! (No olvidéis nombrar tan avanzada herramienta la próxima vez que os pregunten en una entrevista que utilizáis para planificar). Aunque una lista de TO-DOs es válido para proyecto pequeños, enseguida vemos que necesitamos “catalogar” dichas tareas, repartirlas entre los miembros del equipo, estimar horas, etc. Por tanto, en vez de utilizar un fichero texto conviene utilizar una hoja de cálculo, lo cual nos va a permitir extender nuestro “modelo de datos” del planificador.

Partiendo de la idea inicial de usar una lista de tareas podemos extender “el modelo” con los siguientes campos:

• Funcionalidad: Una funcionalidad es algo visible para el cliente, una historia de usuario si nos ponemos XP-ianos. Una funcionalidad va a estar compuesta de tareas.
• Tarea: Nuestro elemento más básico, un elemento de nuestra primitiva lista de TO-DOs.
• Número secuencial: Útil para referenciar la tarea de forma unívoca. Imagina que tienes una tarea “Documentación módulo RSP” y otra “Documentación módulo SRP”, ¿Verdad que no querrás que haya una confusión porque alguien creyó leer otra cosa?
• Estado: ¿La tarea ha comenzado? ¿Se terminó? Es importante guardar el estado de cada tarea. El estado debe ser catalogado (PENDING, STARTED, DONE) para permitir su filtrado. Si además incluimos un formato condicional (Si “PENDING” entonces color rojo) miel sobre hojuelas.
• Criticidad: ¿Tiene el mismo riesgo poner una imagen en un jsp que la conexión con el backend de nóminas? Seguro que el cliente piensa que cambiar el jsp es más importante, pero esta tarea no tiene ninguna dificultad y la podemos afrontar en cualquier momento. Por tanto asignaremos una criticidad CATALOGADA (LOW, MID, HIGH) a cada tarea. Con esto podremos hacer preguntas tan útiles como: ¿Cuántas tareas críticas están pendientes o sin terminar? Vaya, parece que esto del Excel empieza a dar su juego ehh.
• Persona: Sería fantástico hacer como Juan Palomo: yo me lo guiso, yo me lo como. Pero normalmente tenemos un equipo de proyecto, y por tanto las tareas las realizarán diferentes personas. Por tanto, añadamos una columna que diga quién realizará la tarea x. Este campo también debe ser CATALOGADO. ¿Por qué? ¿Cuántas formas hay de escribir mi nombre? M. Alcón, Miguel Alcón, Mikel Alcón, Mikel Halcon ( Sí, estoy harto de responder: “Alcón, sin H“). En definitiva, si tenemos un catálogo de desarrolladores, únicamente nos permitirá elegir entre los desarrolladores de la lista. Ahora ya podemos hacer unas cuantas preguntas más a nuestro planificador: ¿Cuántas tareas tiene pendientes el desarrollador X? ¿Quién tiene las tareas críticas?, etc.
• Estimación original: ¿Cuánto tiempo estimamos que durará la tarea? Planifica siempre en horas y no asignes más de 30 o 40 horas a una tarea, cuantas menos mejor ¿Por qué? Para obligarte a definir el plan con un nivel alto de detalle. Recuerda que huíamos de las planificaciones del estilo “Diseño 2 semanas”. Es más fácil acertar si sabemos exactamente qué vamos a realizar, en esto consiste realmente la planificación ¿Verdad?
• Estimación real: El que tiene boca se esquivoca equivoca, y planificando te equivocarás, y al principio mucho más. Así que actualiza la estimación real a medida que avanza la tarea. Si pensabas que la tarea x iba a durar 10 horas, pero ahora, con el framework Hiberspring AOP Edition 3.0.1.5, lo puedes realizar en 5 horas; o al revés, te has encontrado con un imprevisto, ¡Actualiza la estimación real! Nos permitirá tener una visión real del estado de la tarea.
• Tiempo consumido: ¿Cuántas horas llevas consumidas en la tarea? Este campo nos permitirá preguntas tan interesantes como: ¿Cuanto le queda a esta tarea? (Estimación real – Tiempo Consumido) ¿Cuánto le queda al proyecto en general? (SUM (Estimación Real) – SUM (Tiempo Consumido)) ¿Cuántas horas le quedan en tareas asignadas al desarrollador X?
• Restante: Hemos visto que el tiempo que le queda a una tarea es Est. Real – Tiempo Consumido. Por tanto añadamos una columna con ese valor calculado automáticamente.
• Desvío: Entre la estimación original y la real hay una diferencia. ¿Cuántas horas más ha costado esta tarea? Precalculemos el valor Estimación real – Estimación original.
• Desvio %: ¿Es lo mismo retrasarse 2 horas en una tarea de 1 hora que en una tarea de 20? No. Pues entonces precalculemos este valor: Estimación real / Estimación original y lo pondremos en formato porcentual:
  • 100 % : Estimación Real = Estimación Original. Perfecto
  • <100 %: ¡Hemos tardado menos! Cliente contento y nosotros planificaremos de forma más precisa la próxima vez.
  • >100% : Empiezan los problemas, ¿La tarea es crítica? ¿Quién la tiene asignada? Utilizaremos el formato condicional para asignarles colores de fondo dependiendo del desvío (Ej.: Amarillo 101% a 105%, Naranja 105% a 115%, Rojo >115%)

Ahora ya podemos saber cuáles son las tareas que más retrasos están produciendo, tanto en niveles absolutos como porcentuales, sabemos cuáles son los desarrolladores que más se están retrasando, cuánto tiempo le queda al proyecto, etc. En definitiva, tenemos controlado el proyecto.

La cosa podría quedar más o menos así:

Como habrás podido comprobar la mayoría de los campos son catalogados. Esto nos permitirá realizar agrupaciones y filtrados de los datos.

¿Se pueden hacer cosas más complejas ? Sí, poniendo fechas de inicio y de fin, tareas bloqueantes, etc. Lo único que tienes que tener en cuenta es que deberás utilizar macros de Excel, no pongas este tipo de campos para ser modificados manualmente, porque conseguirás que te dé pereza actualizar la planificación. Lo campos a rellenar deben ser los mínimos y que no requieran pensar más que en la planificación. Nada de “en qué fecha me pongo si la tarea dura 30 días y hay un fin de semana de por medio”. O utilizas una macro o no utilices estas fechas. Además para la mayoría de proyectos este tipo de fechas no te van a servir para nada. Tu objeto de medida es horas que quedan de desarrollo.

Tampoco hay que emocionarse y empezar a añadir campos a diestro y siniestro. Añade según necesites. De la misma forma, solo añade métricas calculadas que realmente te sean útiles, no añadas algo del estilo (Estimación Original – Estimación Real)*Número de letras del nombre del desarrollador/ PI. Recuerda, puedes ir evolucionando el “modelo de datos” según lo necesites.

Una vez que tenemos la parte técnica resuelta queda la parte metodológica… ¿Cómo coño usamos esto!? Las directrices a seguir serían éstas:

• Que los desarrolladores que van a realizar las tareas sean los que, generalmente, hagan la estimación original. ¿Por qué? Por dos motivos, el primero que nadie sabe mejor cuanto va a costar hacer un trabajo que la propia persona que va a hacerlo. El segundo motivo es más psicológico: para que la persona asignada se responsabilice de su tarea. Nunca te podrá decir algo como ¡Me diste poco tiempo!.
• Cada mañana actualiza la planificación. Tu protocolo a seguir cada mañana debería ser el siguiente:
  • Café (Imprescindible, sustituible por té, colacaos, infusiones y bebidas calientes varias. Podrá ser acompañado de galletas, donuts o cualquier artículo de bollería industrial)
  • Reunión con los miembros del equipo, de la siguiente forma:
    • ¡DE PIE! ¿Por qué ? Las reuniones de pie tienden a ir a lo concreto, nadie aguanta mucho sin asentar las posaderas. Si no me crees, compruébalo quedándote de pie 2 horas seguidas, es una experiencia única.
    • Con pizarra. Ayuda a exponer lo que tenemos en mente sin perder el tiempo ni hacérselo perder a los demás. Todo queda más gráfico con un dibujo y minimiza el esfuerzo del resto del equipo para comprendernos.
    • Cada miembro expone el estado de sus tareas y las modificaciones a la planificación (Estimación real y consumido). El jefe de proyecto actualiza la planificación.
    • Se asignan nuevas tareas
    • ¿Dudas? ¿Bloqueos entre tareas? Se comentan y se anotan en la hoja Excel.
  • El jefe de proyecto actualiza la hoja Excel y recalcula las métricas.
  • Consultar las métricas para ver el estado del proyecto, si no es periódicamente por lo menos hacerlo regularmente.
• Repito, planifica a nivel de horas, no caigas en la tentación de hacer planificaciones a nivel de días, semanas o incluso peor, meses. Perderás el control del proyecto y te estarás autoengañando.
• Evita los bloqueos entre tareas. No querrás tener desarrolladores parados porque la tarea x no ha terminado, ¿Verdad?
• Evita que los recursos compartidos se conviertan en elementos bloqueantes:
  • ¿La BD, que usa todo el equipo, se ha caído? ¿Alguien ha cambiado el modelo y los demás no tienen dichos cambios? Seguro que te suena este tipo de problemas. Pon una BD para cada desarrollador, si no puedes permitírtelo crea protocolos que eviten o minimicen estos problemas.
  • Cada desarrollador debe poder ejecutar el código en su propia máquina (Sea un exe, un aplicación web con Apache o con un servidor de aplicaciones por cada desarrollador). No hay excusas, el coste es ridículo.
  • ¡Usa control de versiones! Lo mismo, no hay excusas. Y que nadie, absolutamente nadie suba algo al repositorio sin haber probado tanto sus cambios como la integración con el resto.
  • Relacionado con lo anterior. Genera pruebas unitarias, de regresión, validación, integración etc. Que puedan ejecutarse de manera automática. Imprescindible. Si lo unimos con el punto anterior tenemos que: Nadie, absolutamente nadie, suba algo en el repositorio sin que las pruebas pasen correctamente. He visto equipos de más de cinco personas paradas porque la versión en el SCM tenía un fallo bloqueante.
• Evita los bloqueos dentro de tareas: Este es la principal fuente de retrasos en los proyectos (Además de los proyectos mal planificados, of course). Programadores que se quedan atascados durante horas con un problema. Haz ver a los miembros del equipo que no están solos en su cruzada, si alguien se bloquea durante más de 15 minutos con un problema ¡Que solicite ayuda a alguien del equipo! Tampoco es cuestión de que el equipo entero se ponga a buscar durante dos horas el carácter “<” que falta en un html, pero generalmente alguien conoce la solución porque ya se enfrentó con ella antes. Eso sí, con un límite, no es cuestión de que la misma persona esté ayudando todo el rato a los demás, dejando su trabajo de lado, o de que se pase dos días intentando solucionar el problema de otro.
• Añade una tarea “debug”, que sirva de colchón ante imprevistos. Al final del proyecto haz la resta Estimación Original Debug – Desviación Horas Total Proyecto, te ayudará a dar un tamaño correcto a la tarea colchón en siguientes proyectos. ¿Qué tamaño debe tener? Debería tener, al menos inicialmente, un tamaño no menor al 50% de horas del proyecto.
• Utiliza las tablas pivotadas para calcular totales y subtotales (Total de horas por desarrollador, total de horas por tarea,etc.). Usa las gráficas pivotadas: de un vistazo podrás ver el estado del proyecto.

Espero que estos consejos os permitan planificar mejor (o simplemente planificar). Lee el artículo de Joel, es mucho más completo. Además, yo intento escribir con gracia, pero solo él lo consigue .

Queda pendiente de subir un fichero Excel de ejemplo como adjunto. Dada mi nulidad blogeril, tendré que investigar cómo hacerlo.

Con respecto al curso, no puede recomendarlo, porque ha comenzado esta semana, así que si aún no te has apuntado, estás a tiempo. Sólo te exige 2-4 horas como mucho a la semana. Nada como volver con aquello que crees saber para descubrir nuevas cosas y afianzar conocimientos.

public RuntimeException()

public RuntimeException(String message)

public RuntimeException(String message, Throwable cause)

public RuntimeException(Throwable cause)

Como se puede observar, dos de los constructores de esta clase admiten un argumento java.lang.Throwable, por tanto cuando usemos esta clase en la versión 1.4 no perderemos la traza de llamadas de las excepciones. Ahora veamos las signaturas de los constructores de esta misma clase en la versión 1.3:

public RuntimeException()

public RuntimeException(String message)

Ahora ya sabemos que la exception chaining fue un añadido a la versión 1.4 del JDK a la clase RuntimeException. En el subproyecto Commons Lang existe una jerarquía de clases que nos ayudan a establecer una pila de llamadas previa en el constructor de una excepción. En concreto, son las clases NestableRuntimeException y NestableException del paquete org.apache.commons.lang.exception:

Estos son los constructores de la clase NestableRuntimeException:

public NestableRuntimeException()

public NestableRuntimeException(String message)

public NestableRuntimeException(String message, Throwable cause)

public NestableRuntimeException(Throwable cause)

Equivalentes a los de la clase RuntimeException, de forma que funciona como tal y además mantiene una referencia a un objeto Throwable, con lo que simulamos la funcionalidad añadida a la versión 1.4 pero en un entorno compilado para la 1.3. Ahora simplemente podremos definir nuestras propias subclases de NestableRuntimeException o NestableException, sin miedo a que obtengamos errores de compilación debido al overriding de los constructores no existentes en la 1.3, pero sí en la 1.4. Ahora que lo digo, yo he sufrido dichos errores debido a que en mi IDE (Eclipse normalmente) no configuro el proyecto para compilar las fuentes contra la 1.3 (cuando ha de desplegarse en un entorno de JDK 1.3, claro). Aunque ya voy aprendiendo. Considero siempre una buena práctica configurar el entorno de desarrollo a semejanza del entorno destino, en la medida de lo posible.

* También se aplica a la clase java.lang.Exception

En una de las entrevistas de trabajo que hice hace tiempo me preguntaron que herramienta usaba para diseñar. Yo, ni corto ni perezoso, le respondí: Papel y boli. El entrevistador pareció sorprendido, quizás esperaba una respuesta del tipo “Uso Rational Rose junto con Together más {ponga aquí su herramienta favorita}”. Seguro que estas herramientas son muy útiles, de hecho yo las he utilizado más de una vez, pero creo que en este mundillo hay una sobrevaloración de las herramientas frente a las personas. Parece que es más importante saber utilizar el Rational Rose que saber hacer buenos diseños.

¿Y por qué cuento todo esto? Porque en el terreno de las planificaciones de software hay una herramienta, de esas “imprescindibles”, llamada MS Project que todo Jefe de Proyecto “debe” de conocer. Se usa para todo: Las ofertas llevan un project asociado, una vez iniciado el proyecto el jefe del proyecto se hace otro project, a su vez este pide a sus desarrolladores un project. ¡Y ya tenemos el belén montado! Nadie actualizará esas planificaciones en la vida, su único objetivo era el de aparecer en un papel para justificar que la entrega es sí o sí para el día X.

Las planificaciones con Project nacen viciadas desde su origen. Primero nos ponen una fecha y nosotros hacemos el paripé para calzar todo lo que tenemos que hacer en esa planificación.

Me encantan esas planificaciones del tipo:

1. Análisis (2 meses) (Consultor Pepito)
2. Diseño (4 meses) (Analista de 2ª Juanito)
3. Desarrollo (4 meses)
   1. Web (2 meses)
      1. Gestión de usuarios (2 semanas) (Programador Menganito)
      2. Portal de acceso al empleado (2 semanas) (Becario Fulanito)
      3. Procesos de backend (1 mes) (¿Adivinan? ¡Fulanito y Menganito!)
      4. etc.
4. etc.

¡Que bien!, nuestra planificación está lista y milagrosamente cumple los plazos acordados con el cliente (O aquella moto que vendió el comercial de turno tomándose unas cañas plácidamente con el cliente).

Pero analicemos detalladamente esta planificación:

• Nace viciada de origen. Nuestro único objetivo fue cumplir los plazos, por eso utilizamos una herramienta basada principalmente en fechas (Gantt).
• No está basada en criterios racionales: ¿En que nos basamos para planificar los procesos de Backend en un mes? ¿Hemos tenido una revelación divina? ¿Rappel está en nuestro equipo de proyecto? Este tipo de planificaciones me recuerda a un tipo de mi barrio, un poco raro, que decía que iba a hacer un software de diseño de circuitos que iba a ocupar…¡ 14 diskettes! ¡Y no sabía programar! La diferencia entre esta persona y nosotros es que, nosotros no vemos una media de 5 ovnis al día cuando tomamos el café en la terraza, ni creemos en puertas interestelares (¿No dije que era un tipo raro!!??). Y por tanto debemos ser más serios con lo que hacemos.
• No es detallada: Por la causa anterior. Una planificación no se debe hacer nunca a semanas, ¡ Y menos a meses! Hacer una planificación no detallada es como decirle al cliente “Mira, no tengo ni idea de cuanto vamos a tardar, pero te voy a mentir para que te quedes más tranquilo. El proyecto ya se retrasará luego, como todos” (¡Lo peor es que con muchos clientes funciona!).
• Es una referencia/restricción, no una herramienta: Una vez hecho, rara vez se actualizará (siendo muy optimistas). Solo servirá como herramienta de presión para los integrantes del equipo (esto daría para otro post). ¿Cual es el estado del proyecto? ¿Cuanto falta para acabar? ¿Que desarrollador tiene más carga de trabajo? Nuestro project no nos responderá a ninguna de estas preguntas. No está actualizado y esta lleno de suposiciones (benditos eufemismos). Vaya paradoja, ¡La herramienta de planificación no nos sirve para planificar!
• No tenemos soporte para feedback: Al planificar nos vamos a confundir. Seguro. No existen las planificaciones que encajan como anillo al dedo. Solo podemos minimizar el desvío. ¿Crees que puedes hacer una planificación para el año que viene el mismo día a la misma hora? Cuando planificamos a grandes escalas de tiempo es inevitable confundirse. Influyen muchos motivos: No conocemos bien los requisitos, la tecnología es nueva, etc. Aunque en los siguientes proyectos no podremos presagiar muchos de los problemas que encontraremos, si que podemos prever ciertos desvíos. Por ello es importante almacenar las horas que realmente se imputaron a cada tarea. Debemos aprender de nuestros errores.

Entonces, ¿No vale para nada el MS Project? ¿Hay que huir de ellos como el demonio? Yo no llegaría a tanto, simplemente hay que tener en cuenta sus limitaciones y las implicaciones que tiene. En ciertos proyectos grandes, con muchas dependencias, puede estar justificado su uso. Pero para proyectos pequeños y medianos existen mejores herramientas. ¡Pero esto lo dejo para el siguiente post!

Para acabar, como reza el título de este post … ¡Bienvenidos!