Downloading content…

Hace tiempo empecé a trabajar en una “agile shop” (una empresa de desarrollo de software usando metodologías ágiles), bueno en realidad no es la primera vez que veo algo así, cuando fuí a Estados Unidos me tocó trabajar en un ambiente ágil pero a pesar de que eran muy agiles y todo no le ponian nombre a su metodología. Aqui tiene nombre y ese es… pom pom pooom… SCRUM.

SCRUM es un sabor de las afamadas metodologias ágiles, de que se trata todo esto? bueno es relativamente “fácil” de explicar, y digo “fácil” por que creanme que es mucho mas sencillo que CMMI o RUP (metodologias no agiles)

Pongamos una pequeña pausa, ¿ok?

¿Qué es una metodología ágil?

Metodología: Forma de hacer algo, es un proceso o una guía de pasos a seguir.

Ágil: Adaptable, rápido, flexible, etc.

Metodología ágil: Es una forma adaptable, rápida y flexible de hacer las cosas. En el desarrollo de software se le conoce por que es una forma de desarrollar sistemas adaptandote rápidamente a los cambios y entregando continuamente un producto funcional.

OYEEEEE… espera… entonces ¿como hacian las cosas antes? ¿Como era el mundo “no ágil”?

Bueno. De entrada la mayor parte del mundo sigue sin ser ágil, así que en vez de decir como era el mundo es un como es el mundo.

El mundo es horrible. (pero eso ya lo sabian)

Hace tiempo para garantizar la seguridad (y por seguridad me refiero mas a “certeza”) en el desarrollo de software se crearon procesos que permitian a la gente entender como se hacia un sistema.

• Se hacian consultas y propuestas de lo que se queria hacer. normalmente en juntas de minutos, horas o dias.
• Se hacian negociaciones sobre los requerimentos que podian tomar dias, semanas o meses.
• Se sacaba una bola de cristal (bueno no tanto así) y se planeaba cuanto tiempo iba a tomar hacer algo, esto tambien puede tomar dias, semanas o meses.
• Se les entregaba un machote de documentos a los desarrolladores (ahora si trabajen) y se les decia cuanto tiempo se podian tardar en cada tarea (si, se les decia, te vas a tardar X tiempo en hacer esto), normalmente en este paso las estimaciones siempre decian que el sistema era realizable en menos tiempo de lo que realmente se tarda uno asi que resultaba en dias, semanas o meses de ir los sabados y domingos a trabajar.
• Una vez terminado se hacian pruebas.estas tardaban horas minutos o segundos para compensar el retraso de los inutiles desarrolladores.
• Se implementaba la solución en los sistemas finales que tomaban horas o dias de estar rezando.

¿Dudas?

Yo tambien tengo muchas.

Sobre todo una: ¿Como es que alguien mas sabe cuanto me tardo en hacer algo? son gurus? shamanes? brujos?

Bueno no, son CONSULTORES CAPACITADOS CERTIFICADOS, RESPALDADOS POR FAMA INTERNACIONAL Y QUE GANAN 10 VECES LO QUE CUALQUIER DESARROLLADOR MORTAL. woooooooooooooooooooooooooooooooooow

En fin, el proceso funciona, creanlo o no.

Y funciona por que lo hemos hecho funcionar, ya sabemos que esperar, que vamos a tener que trabajar de más, que van a estimar de menos, que si firmamos que vamos a hacer algo, solo vamos a hacer eso, y si queda mal, si no es lo que el cliente queria, ni modo, por que el firma que se va a seguir ese proceso y está de acuerdo con el. Este proceso le da certeza al desarrollo a cambio de hacerlo inflexible ya que si el cliente necesita algo extra, ni modo, tendrá que ser hasta el final, por que hay un plan y hay que hay que seguirlo.

Es un mundo horrible (y ahora lo acaban de comprobar)

Bueno bueno bueno. ¿Pero que propones?

Las metodologias agiles por supuesto, de eso se trata este post (bueno la segunda mitad del mismo)

Las metodologias agiles proponen algo distinto y mucho mas arriesgado (por eso no son tan populares) pero mucho mas eficientes cuando se quiere hacer algo nuevo.

La idea principal es.

• Juntarse con el cliente y preguntarle mas o menos que quiere y hacer una sesion de lluvia de ideas, que pida hasta las perlas de la virgen si eso es lo que el quiere.
• Ahora con esa listotototototota de cosas le preguntamos: Que de todo esto es lo más importante.
• El cliente responde: TODOOOO,
• y tu le dices, va. ok todo, pero solo podemos hacer mas o menos esto en 15 dias.
• El cliente sacado de onda se responde “15 dias??? pero en 15 dias no alcanzarias a hacer nada”
• Tu respondes “si y no, podemos hacer algo, y lo vas a ver funcionando en 15 dias, solo elige una cosa de todo lo que me dijiste”
• El cliente incredulo elige algo, no muy grande no muy chico. mas o menos bien.

Y aqui empieza la diversión. Ahora ya tenemos algo de prioridad suprema. vamos con los desarrolladores y les decimos que es lo que el cliente quiere, todo mundo sabe que eso no es TOOOODO lo que el cliente quiere y que esa petición es solo un pedacito de un todo que asusta a cualquiera, pero. El objetivo a corto plazo es: Hacer lo que el cliente pide ahora.

Aqui es realmente cuando el proceso inicia:

• El equipo de desarrollo empieza a desarrollar, planear y hacer el sistema de inmediato basandose en solo esa pequeña parte que el cliente eligio.
• Lo que el cliente pide se divide en tareas que puedan hacer personas simultaneamente, tareas pequeñitas y que sepamos mas o menos que tan dificil son.
• Mientras tanto le preguntamos al cliente que es lo siguiente que le gustaria ver.
• El cliente elige y se prepara el camino para la siguiente iteración
• El equipo termina lo que pueda en esos 15 dias, dejando algo FUNCIONANDO al final.

No se si ven la diferencia? En una metodologia agil no se adivina cuanto tarda en hacerse un sistema, eso se sabe siempre, lo que se adivina es que tanto se puede hacer en X tiempo y una vez que algo se termina se valida se implementa y se entrega bonito y acabado.

Suena como un mundo ideal ¿noooooo? pues no lo es. “not quite” es mejor pero no es ideal.

Requiere de mucho control para el descontrol y de muchas prácticas de programación locas que puede que no a todos les guste. Test Driven Development (Con este excelente libro: Test Driven By Example), Pair programming, Continous Integration (chequen hudson por ejemplo), etc.

Ahora vamos a un ejemplo real, ¿va?

Un ejemplo de metodología con nombre y apellido: SCRUM

La idea escencialmente es la misma de arriba, todos los requerimentos del usuario son escritos en historias de usuario que son los pequeños bloques de principio a fin que hacen algun tipo de funcionalidad, por ejemplo, el usuario quiere logearse al sistema, el usuario quiere poder agregar otro usuario, el usuario quiere poder borrar un usuario. Ahi vieron 3 historias distintas, todas son una funcionalidad especifica.

Ahora esas historias se estiman, la estimación no la hace un gurú la hace el equipo. Como? simple: primero se le muestran las historias y el equipo por concenso dice cual es la más fácil de hacer. Esa será nuestra historia de dificultad 1. ahora se va por las historias y se pregunta: Esta historia, ¿Cuantas veces más dificil es que la historia de dificultad 1?. Si es el doble tiene una dificultad de 2, si es 4 veces mas complicada es un 4, etc… lo que se recomienda es que se usen valores de 1,2,4 y 8… si algo es más grande que eso tal vez valga la pena dividir la historia en pedazos mas pequeños.

Entre los bloques sean mas pequeños no solo son más fáciles de desarrollar sino que tambien son más fáciles de estimar.

Ahora el equipo empieza a trabajar…

Toman un estimado “a la macha” de cuanto pueden hacer y empiezan…

Dia a dia, se hace una micro junta (Que se le conoce como SCRUM) de maximo 10 minutos donde todos los desarrolladores dicen:

• Que hice ayer?
• Que voy a hacer hoy?
• Hay algo que me impida hacer eso?

De esa manera todo mundo está enterado de lo que está pasando.

Al final de los 15 dias lo que haya terminado el equipo se suma. y se obtiene un numero de historias terminadas, pero sobre todo de puntos de dificultad terminados. a eso se le llama: VELOCIDAD.

Asi que digamos que un equipo logra hacer 50 puntos. entonces podemos deducir que mas o menos haran eso consistentemente cada 15 dias.
Si un sistema tiene 1500 puntos en total tomaria: 30 iteraciones de 15 dias para terminarse o bien: 450 dias.

Eso si no cambiara nada PEEEERO

Aqui empieza lo mágico de las metodologías agiles.

Cada vez que se termina un “sprint” (periodo de 15 dias, aunque algunos equipos usan 20 o 10 dias) se presenta el producto “terminado” y se pregunta si es lo que se esperaba, si no, se agregan los cambios al siguiente sprint, si si lo es entonces continuamos, PEEERO, continuamos con lo que nos diga el cliente, y como va a tener estimados de las historias de su sistema el cliente ahora va a elegir los siguientes 50 puntos que quiere que se hagan, obviamente es una desición consensual ya que el equipo ayuda al cliente a elegir aquello que le de valor a su negocio y que le permita al equipo desarrollar más rápido el sistema.

Y si el cliente cambia de opinion o algo no le gusta no se pierde mas que 15 dias de trabajo. Digamos que al cliente le gustaria mejor que se puedan hacer compras online a que se puedan registrar a una mailing list, no problem, eso se agrega en el siguiente sprint. Si eso implica dejar fuera unas historias pues así será, si requiere crear nuevas pues se hace y se estiman las nuevas historias.

En si eso son las metodologias agiles, y en el ejemplo anterior SCRUM.

Ahora bien, yo creo que no son tan usadas no por que sean malas o no funcionen, estas metodologias realmente funcionan, las grandes empresas van migrando poco a poco a estas metodologias por que saben que entregan resultados, sin embargo aun no se adoptan completamente. Por que?

Yo creo sinceramente que la industria detras de las “no agiles” es muy fuerte y hay inversiones muy fuertes en ellas, se crean certificaciones millonarias para que las empresas cumplan con standares que les permitan minimizar riesgos y darles un titulo de  “empresa certificada con CMMI level 3” que te asegura cierto control.

Eso aun falta un poco aqui. ADEMAS de que la cultura agil desmotiva los esfuerzos de certificar a la gente ya que no deberia ser un requerimento, o se sabe o no se sabe, (pero eso lo veré en otro post lo prometo, por que este ya está muy largo)

En fin, yo les digo por experiencia. Funcionan, y funcionan muy bien. (como la sección amarilla :p)

Espero les sea útil para ver que no todo son procesos labrados en piedra, rigidos y pesados.

Download Complete

Downloading content…

Hoy estaba haciendo unas cuantas pruebas de unidad en Java con JUnit con el afán de hacer correctamente el “test driven development” ya saben, esa super tendencia que están tomando desarrolladores modernos a lo largo y ancho del mundo que dice que siempre debemos de hacer el test primero y despues el codigo para cada una de nuestras clases, de esa manera nos aseguramos que la clase jale (funcione) como esperamos que funcione.

La idea es muy buena y no solo se restringe al uso de JUnit, ya que una prueba es en escencia un bloque de codigo ejecutable por si mismo que si falla arroja un error y truena (falla) y si funciona pues no hace nada. de esa manera sabes cuando algo falla.

Bueno regresando a TDD (test driven development), como pueden imaginar esta forma de trabajar tiene muchas virtudes ya que si no las tuviera nadie la usaria, entre tantas cosas facilita hacer pruebas ya que las TIENES que hacer antes de empezar a programar en la implementación, esto evita que se descuide el unit testing (pruebas de unidad), pero no falta el caso en el que pensamos en el problema y no podemos pensar en una prueba obvia que nos lleve a implementar una solución y terminamos escribiendo la solución, un tanto compleja pero sin pruebas.

La ironia de la vida, es más fácil solucionar algo y decir “confia en mí” a escribir algo y demostrarlo con pruebas “confia en las pruebas”.

Pero que es bueno probar y que no?

Yo diria que todo debe de ser probable. Algunos dirán lo mismo, otros tantos dirán que pruebes lo posible, Kent beck (casi creador de toda esta tendencia) dirá que no todo es bueno probarlo (pero yo creo que ya chochea y se ha vuelto más pragmático).

Pero que implica probar TODO.

implica que te las vas a ver negras. como dirian: estas jodido, you are in deep shit.

Por que?

por que cosas simples las puedes probar facilmente, y eso te va a llevar a escribir codigo simple lo que es bueno, pero no siempre tan sencillo como quisieramos.

Pero.

PEEEERO

que hay de cosas mas “tru tru” (de truculentas) como:

• Threads
• Interfaz gráfica
• Conexiones a base de datos
• Conexiones a web services
• Acceso a sistema de archivos
• Acceso a dispositivos externos
• Entre otros demonios menos benevolentes.

Aqui es cuando estamos en DEEP SHIT

y algunos dirán que no es probable y lo dejes así… pero vamos a ver un caso interesante y de profunda reflexión

Acceso a base de datos.

Supongamos que usas JDBC, y vamos a probar que lo hagas correctamente.

Como le haces?

Bueno primero que nada tienes que evitar un pecado capital:

– Crear la conexión a la base de datos directamente en tu código.

Connection conn = DriverManager.getConnection(url, user, passwd);

si ponen eso se acaban de condenar a no poder probar en paz

su solución en el método donde vayan a hacer uso de la conexión pidanla por parametro

Ahora. Connection es una interfaz. no?

para probar podemos mandar una implementación hecha por nosotros de la interfaz. eso definitivamente va a funcionar. no?

entonces sobreescriben el metodo createStatement() para regresar una implementación chacarrona (hechiza( hecha por nosotros)) en la que sobreescribimos los metodos necesarios para crear un query.

Ahora entonces creamos el metodo executeQuery en nuestra implementación chacarrona para que si no le mandamos un query esperado aviente una excepción (asi sabremos que la prueba no pasa), despues si nos dan el query que queremos regresamos de nuevo otro implementación chacarrona ahora de un resultset.

And so on…

Si, hay herramientas que hacen esto por nosotros, está por ejemplo Mockito, JMock, EasyMock, que nos permiten hacer stubbing (escencialmente lo de implementar a medias una interfaz o clase, aunque el termino va un poco mas allá).

Un momento…

Hagan la prueba…

Hagan la implementación…

Se van a dar cuenta de algo bien raro, su prueba parafrasea la solución. Estan escribiendo en su prueba la forma en la que quieren que se implemente algo.

Estan colocando, quiero que el programador tenga un objeto connection, y que pida un statement, al statement le pida un resultset con este query, y que el query se transforme en esto…

Algo se ve raro ahi no?

Una prueba deberia solo ser el lineamiento de lo que queremos que haga una pieza de codigo, nos dice que quiere, no el como.

Esta prueba parece que es el como…

Ahora está mal eso? YO no lo sé. Por el momento las sigo haciendo y tengo ese extraño sentimiento de que algo anda mal. ese sentimiento de que algo está demasiado repetido o que está demasiado especifico, que mi prueba encadena al programador, lo desnuda, lo golpea y lo esclaviza. (chale que raro suena eso)

En fin, pues chequenlo por ustedes mismos y si encuentran una respuesta a como hacer este tipo de pruebas menos… restrictivas, diganme.

Download complete.

Downloading tutorial…

On this series:

• Events.
• Java Swing MVC application model
• Java Swing MVC app model redux (not yet)

Ok, I began this series the wrong way… If you remember some time ago I posted about some MVC model that might work with swing but I think to understand that more I have to go a little more through the process of creating an application covering some tools and concepts that might come in handy.

So this is the first one.

Ok. Events. what are they and why do you care?

Events are a way to implement the Observer pattern so an Object A that depends on Object B can change its state when Object B notifies Object A. What it mostly means is that you can have an object depend on another to listen for changes on it then we can do some stuff on the main object.
Why do we care? well mostly to invert control, this is another design pattern, the most famous is dependency injection (spring anyone?) but the other way of inverting control is through events. How is this possible? when an object requires the other to change something it doesn’t invoke the operation directly on the object, instead it fires an event, then the object listening can do some stuff. This pattern enforces decoupling since nothing happens if we don’t have an observer since it is not required to have one in order for our code to work, we just notify and if no one listens no problem, our job is done to the point we notify.

This has also something to do with the question: Who really cares if something changes on me?

let’s have this scenario: You have a person object that is displayed on a form (the form is done in swing), then some external code beyond our control changes the person object. How do we change the form to reflect the actual changes?

we can add the refresh operation to the external code. BUT that would mean that we need to add some functionality and add a rigid dependency on the external code to the view. BAD

we can add the refresh functionality to our person object. BUT that would impose a dependency on every person object. WORSE

we can add an event to the person object so that it can notify whoever who wants to be refreshed without knowing who is actually listening. Mmmm… a little verbose but this is the point of event driven inversion of control.

Lets get to the root of the implementation.

First lets think of how to do this. In java we use classes (anonymous and inner are most common) on C# we use delegates (but there is an actual event construct for that)

Lets focus on java:

for this to work we need:

• An Event object that will handle the add/remove listener, and fireEvent method that will be invoked in the observable
• An EventArgument or EventObject that will hold information of how the event was fired and will travel from the observable to the observer.
• A Listener interface so we can handle the events inside the observer.

for starters we will create the interface (believe me it will be easier)

public interface Listener {
public void handleEvent(Object eventArg);
}

We dont need to create an EventArg we will use Object for now

Then finally the EventObject, this is simply a wrapper for a list, and the fire event will just do the handleEvent method on all the elements on the list:

public class Event{
private List<Listener> listeners = new ArrayList<Listener>();
public void addListener(Listener l){ listeners.add(l); }
public void removeListener(Listener l){ listeners.remove(l); }
public void fireEvent(Object eventArg){
for(Listener l : listeners){
l.handleEvent(eventArg);
}
}
}

And thats it… is it?

well how do we use it anyway?

in the class that is observable we need a reference to an event for every event that we need to launch. lets retake the person example.

class Person{
…. some stuff
private Event personModified = new Event();

…

public Event getPersonModifiedEvent(){ return personModified; } // no setter we dont want that.

}

ok so now when we change a property we just send the event, right?

class Person{
… more stuff
public void setName(String name){
this.name = name;
personModified.fireEvent(this);
}
…
}

That simple line will notify every listeners that a change occured without knowing who they are.

How do we listen to changes?

check this out:

class Meh{
… some complex code.
public void initOrWhateverThatRunsOnce(){
Person p = ______ // whatever way you have this object.
p.getPersonModifiedEvent().addListener(new Listener(){
public void handleEvent(Object eventArg){
refresh();
}
});
}

….

private void refresh(){
…… // some really complex code you must write.
}

}

since it is an inner anonymous class it has access to all the methods outside it, this is the power of inner classes but you may implement a different solution, this is just the basic way it is used, even swing uses this as the preferred approach.

Now this is real basic event handling this will work but surely is suboptimal, the main objective here is explaining the idea and how can you implement your own event framework, with more than this. First think about the event parameters, how can we use generics there?, then think about the event object, synchronization, etc. Then think about not returning an instance of Event on the getPersonModifiedEvent method, instead return an interface that just contains the add/remove methods. then use generics on the listeners, etc.

As you can see you can set the limit. and obviously you have the final say on using them or not. I would consider them since its a different way of notifying changes to views and related objects, they can sure save you a lot of problems, and I have seen several advantages: They are easy to test, as they decouple classes they are make other classes easy to test as well, they separate concerns on the classes since every class knows what to listen and are likely to do their stuff right there instead of telling someone else to do it for them.

Ahhh! also, there are some event frameworks out there already, I’ve heard spring has some, so take a look, also the bean spec of the JDK contains something about events.

Happy coding.

Download complete.

Downloading article…

Ok, so long ago we came with a complex problem of how to make a swing application model that works and that can be tested efectively, this has proven to be more complex than what we thought at the start.

So this may seem a bit complicated at the start but this is what we managed to acomplish:

The main idea is having everything separated in our swing app and doing a kind of MVC

So we have 4 main components in this model:

• The View (swing frames, panels, buttons and all that stuff)
• The controller (classes that invoke actual functionality or modify the model)
• The notifier (A class that will notify the view that something happened and that the view should change its state)
• The model (our model classes that do the actual work)

So now how do this works?

The idea is that your dependencies look like that.
The view depends on the controller and the notifier, the controller depends on the model and the notifier, the model has no dependencies, the notifier has no dependencies as well.

Do something looks weird? how is the view updated? i think you can understand that the model has no dependencies, but shouldn’t the notifier depend on the view?

NO… and thats the whole point.

The notifier and the view have an observer pattern inside, the view observes the notifier, the notifier will relay all the necesary information to the view through events that will be triggered from some external source.

This allows plugability and most important

TESTABILITY

The view can be tested. The only thing it does is relaying user interactions to the controller, so we can mock the controller and assert that the invocations occurs (using fest maybe or by plain java)
The controller can be tested we can mock both the model and the notifier, so the controller just do some stuff and in the end notifies.
The notifier is even easier, since we can have just mock listeners assigned to it and check that if the class is notified the event is thrown.
The model can be tested without any dependency as well…

Why this way?

Well there are a couple of reasons, one of the main ideas is achieving inversion of control and allowing linear dependencies, circular dependencies are hard to manage and often lead to failures in configuration.

– I promise that i will update this as soon as I finish another post about inversion of control using events.

– SideNote: Yes this is MVC the only difference is the “where it happens” on normal MVC the controller updates the view. here is no exception, but the controller just screams that a change has occured and then the view has to update itself.

– I will put a tutorial too sometime.

Download complete.