He who has a why to live can bear almost any how.

Friedrich Nietzsche.

«Muchas personas me preguntan cómo hacer algo. Yo solía decírselo hasta que me di cuenta de que incluso después de haberles dicho cómo hacía algo yo, con frecuencia no lo hacían. Luego me di cuenta de que no es el cómo lograr algo, sino el porqué lograrlo lo que es más importante. Es el porqué lo que te da el poder para hacer el cómo».

Robert Kiyosaki en Retírate joven y rico. Vía blog de Francisco Alcaide, No es el «cómo» sino el «porqué».

Es decir, ejecutando el siguiente código en España e informando user.createdOn como “01/01/2013 12:00:00″ :

1
2
3

<h:outputText value="#{user.createdOn}">
    <f:convertDateTime pattern="dd/MM/yyyy HH:mm:ss" type="both" />
</h:outputText>

se pintará en pantalla “01/01/2013 10:00:00″. Pero lo que es peor, en Portugal (está en la zona horaria GMT+1) pintaría “01/01/2013 11:00:00″ (creo, no me he desplazado a Portugal para probarlo ).

Y lo que es peor, si estás desarrollando en España y finalmente tu código se despliega y ejecuta en otro país, el resultado será….

Para solucionar esto (ñapa) en España podemos poner la zona horaria en el código:

1
2
3

<h:outputText value="#{user.createdOn}">
    <f:convertDateTime timeZone="GMT+2" pattern="dd/MM/yyyy HH:mm:ss" type="both" />
</h:outputText>

Aunque lo suyo sería que timeZone fuera una variable más a informar desde el servidor, porque sino cuando por ejemplo registremos un evento en el servidor persistiendo new Date(), al visualizar esa fecha se visualizará incorrectamente en clientes que no estén en la misma zona horaria que el servidor, complicando (innecesariamente) una lógica tan habitual como formatear una fecha.

¿Por qué no me gustará ningún código de Sun? ¿Por qué no respetaré las certificaciones de Sun?

Awesome ScreenShot es una extensión gratuita tanto para Firefox como para Chrome y Safari para tomar pantallazos del contenido de tu navegador de una forma sencilla, elegante y potente.

Sin duda es una herramienta que mejorará la comunicación entre los usuarios (es que no me funciona cuando pincho el botón!) y los desarrolladores.

Sin embargo hay 3 razones por las que Subclipse brilla más que Subversive:

• Están más involucrados en la evolución de la tecnología SVN.
• Es significativamente más sencillo realizar un merge.
• Soportan mejor cambios externos realizados por otros clientes SVN o directamente la línea de comandos.

La segunda razón sí que la considero suficiente para decantarme por Subclipse ya que hacer un merge es el punto más débil de SVN frente a GIT.

• Atomicity, all or nothing, if one part of the transaction fails the entire transaction fails. Required when there is more than one Resource Manager. Example of two phase commit, marriage, both partners must return ok.
• Consistency, any transaction will bring the database from one valid state to another. The bride can not become married to another broom after her ok if her broom fails and another one gives ok.
• Isolation, can be executed concurrently but appear to execute serially.
• Durability, when a transaction commits its result remains and must survive failures.

Sacado de la charla “Transactions: Over Used or Just Misunderstood?“, de Mark Little de JBoss en InfoQ.

Sin embargo, el teorema de Brewer nos condena a convivir con el fallo si queremos escalar nuestro sistema, para lo cual utilizamos transacciones que se conforman con que eventualmente nos encontraremos en un estado consistente y con ofrecernos respuestas aproximadas, cumplen con el acrónimo BASE:

• Basic Availability
• Soft-state
• Eventual consistency

Baste decir que cuando hablamos de J2EE no hablamos de “Java v2 Enterprise Edition” sino de “Java v1.2 Enterprise Edition“, pero todo el mundo (incluido yo) utiliza J2EE en lugar de simplemente JEE o J7EE (para referirnos a la versión 1.7 que es la actual de Java). Por cierto, cuánta falta hace que llegue por fin una versión 2.0 de Java!!!

Una de estas áreas de mejora es el mal uso de un concepto tan común como “duplicar” un objeto. La mayoría de las pesonas que leen este código,

1
2
3

Person personA= new Person();
personA.setName("Juan");
Person personB = personA;

piensan que personB es una copia de personA, dos objetos diferentes pero con los mismos valores, porque los humanos interpretamos la línea 3 como “Crear un nuevo objeto del tipo Person llamado personB que inicalizamos con los valores que tiene el objeto llamado personA”, o simplemente decimos “Copiar personA a un nuevo objeto del tipo Person llamado personB” pero queremos decir “Duplicar” en lugar de copiar.

Sin embargo Java se comporta de un modo diferente al esperado ya que la JVM interpreta esa línea de diferente forma. Si ahora realizamos un cambio en personB, comprobaremos asombrados cómo personA también ha cambiado!!!

4
5

personB.setName("Luisa");
//En este punto personA.getName() devolería "Luisa" y no "Juan".

¿Por qué? Porque lo que realmente significa para la JVM la conflictiva línea 3 anterior, es “Crear una nueva variable del tipo Person llamada personB y asginar la misma referencia que tiene la variable personA“, o simplemente “Copiar la referencia (y no el contenido) de personA en una nueva variable del tipo Person llamada personB“. El resultado es que tenemos dos variables apuntando a una única referencia (espacio en memoria) en lugar de dos variables independientes con sus respectivas y diferentes referencias (espacios de memoria). Así, cuando una de las dos variables cambia, cambian las dos. Sí, Java se orienta más a punteros que a objetos, que es más útil en programación a bajo nivel y para ahorra unos bits; no en vano Java se basó en C.

Entonces, Java no facilita una funcionalidad para duplicar objetos?!?!?! Java ofrece un interfaz Clonable, pero no su imlementación. Ocurre lo mismo para comparar dos objetos o comprobar si dos objetos son iguales o imprimir los valores de un objeto, te obliga a escribirte tu propia implementación para estas funciones de uso común, más común (para un desarrollador) que las interpretaciones estándares, ralentizando el desarrollo al escribir código de poco valor añadido y propenso a los bugs pero sobre todo complicando el mantenimiento ya que tiene que evolucionar al tiempo que evoluciona el negocio.

O utilizar implementaciones genéricas que son peligrosas.

Duplicación de objetos genérica

Podemos implementar nuestra propia solución genérica para solucionar esta laguna de Java, o podemos utilizar soluciones ya existentes. Así org.apache.commons.beanutils.BeanUtils parece ofrecernos la solución:

Person personB = null;
try {
	personB = (Person) BeanUtils.cloneBean(personA);
} catch (Exception e) {
	e.printStackTrace();
}

En este caso funcionaría, y ahora al volver a ejecutar un cambio en personB no cambiamos personA.

Pero qué pasa si el objeto Person tiene a su vez otros objetos, como por ejemplo un objeto User?

@Test public void duplication2Test2 () {
	User userA;
	Person personA, personB;
	personA = new Person();
	personA.setName("nameA");
	userA = new User();
	userA.setUsername("usernameA");
	personA.setUser(userA);
	personB = personDuplication.duplication2(personA);
	personB.setName("nameB");
	personB.getUser().setUsername("usernameB");
System.out.println("duplication1Test - personA.name = " + personA.getName());
System.out.println("duplication1Test - personB.name = " + personB.getName());
System.out.println("duplication1Test - personA.user.username = " + personA.getUser().getUsername());
System.out.println("duplication1Test - personB.user.username = " + personB.getUser().getUsername());
	Assert.assertEquals(personA.getName(), "nameA");
	Assert.assertEquals(personB.getName(), "nameB");
	Assert.assertEquals(personA.getUser().getUsername(), "usernameA");
	Assert.assertEquals(personB.getUser().getUsername(), "usernameB");
}

Este Test falla. La razón es simple, BeanUtils duplica las variables primitivas y las variables de tipos de Java como Boolean, Integer o String (que es la que se utiliza en el ejemplo), pero en lugar de duplicar los objetos que nosotros implementamos (como el usado en el ejemplo User) está copiando su referencia.

Duplicación profunda de objetos genérica

Una forma sencilla es serializar nuestros objetos y desearializarlos en nueva instancia, para lo que podemos utilizar org.apache.commons.lang.SerializationUtils. La parte negativa de esta solución es que nuestros objetos deben ser serializables (implementar el intefaz Serializable), y también todos los objetos que los componen, y también todos los objetos que componen a estos, y también… por lo cual es una solución con peligros de cara al mantenimiento evolutivo.

Por fin, la siguiente implementación pasaría el test anterior:

public Person duplicationPerson(Person personSource) {
	Person personTarget = null;
	try {
		personTarget = (Person) SerializationUtils.clone(personSource);
	} catch (Exception e) {
		e.printStackTrace();
	}
	return personTarget;
}

Lo podríamos hacer más genérico sustituyendo el tipo Person por Serializable. Más potencia, más peligro.

Por ejemplo para monitorizar nuestra aplicación deberíamos saber qué niveles de trazas disponemos, así que en alguna clase deberíamos declarar las siguientes constantes públicas:

public static final int DEBUG = 1;
public static final int INFO = 2;
[...]

Esta solución es poco eficiente (penaliza mucho el consumo de memoria, alto acoplo entre componentes, difícil refactorización…).  Además si quieres persistir una traza en base de datos, la columna del nivel de trazas debería ser una foreign key a una tabla diccionario que contiviese los niveles de trazas permitidos para preservar la integridad referencial.

Este mismo ejemplo se puede aplicar a otra multitud de casuísticas, tan a priori inmutables como el sexo, provincias, prefijos telefónicos o incluso casos más variables con el tiempo pero tan habituales como los roles de los usuarios o los tipos de documentos de identidad aceptables.

En la última década he visto diversas soluciones para utilizar estas tablas diccionarios en nuestro código implementadas por IBM, o por estudiantes recién salidos de la carrera. Pero desde la aparición de los tipos enumerados en la versión 1.5 de Java, los enum se han extendido como la manera más eficiente, elegante y más óptima para representar este tipo de datos. Ligado al desarrollo y aceptación de JPA, persistir y recuperar este tipo de datos nunca fue más fácil.

JPA asume que los enumerados que persistes se implementan de forma estándar. Es decir pares de códigos – descripciones en las que el código es un int y la secuencia comienza en cero.

Para el ejemplo de presentar los niveles de la entidad Traza, el enumerado que deberíamos implementar de forma estándard podría ser:

public enum TraceLevelType {
	TRIVIAL, MENOR, NORMAL, IMPORTANTE, CRITICO;
}

que representaría la tabla diccionario  :

ID - KEY
0 - TRIVIAL
1 - MENOR
[...]

Sin embargo no siempre vamos a poder optar por esta solución estándard, por ejemplo si no somos los propietarios de la base de datos o si la tabla se comparte con otras aplicaciones / equipos / organizaciones, si hay que ofrecer compatibilidad hacia atrás…

Un ejemplo de problema para nuestro caso es si a los dos meses de estar en producción necesitamos la necesidad de añadir un nuevo nivel de traza (pej WARNING), tratamos los niveles de traza de forma jerárquica (asumimos que a mayor id mayor importancia), y nuestro nuevo nivel es un nivel intermedio entre normal e importante.

Es decir que para implementar la tabla diccionario de niveles de traza no estándard:

ID - KEY
10 - CRITICO
20 - IMPORTANTE
[...]

Podríamos utilizar el enum

public enum TraceLevelType {
	CRITICO (10), IMPORTANTE (20), NORMAL (30), MENOR (40),
	TRIVIAL (50);
}

Pero no bastaría para que JPA persistiera y recuperase correctamente nuestras entidades Traza.

Una solución sería persistir el nombre del enumerado en lugar del código, que aunque no me entusiasma y seguramente tendrías un encontronazo con tu DBA, sí solventa el problema y es una solución versátil para mantener la aplicación. En la entidad traza utilizaríamos para mapear la columna:

@Column(name = "LEVEL")
@Enumerated(EnumType.STRING)
private TraceLevelType level;

Otra solución sería explicitar la relación entre código y clave de cada nivel de traza dentro del enum. Así continuamos persistiendo el código, lo que es más eficiente.

public enum TraceLevelType {
	CRITICO (10), IMPORTANTE (20), NORMAL (30), MENOR (40),
	TRIVIAL (50);
 
	private long idType;
 
	private TraceLevelType (long id) {
		this.idType = id;
	}
 
	public long getIdType() {
		return idType;
	}
 
	public static TraceLevelType parse(long id) {
		TraceLevelType level = null; // Default
		for (TraceLevelType item : TraceLevelType .values()) {
			if (item.getIdType() == id) {
				level = item;
				break;
			}
		}
		return level;
	}
}

Y la entidad Traza quedaría:

@Column(name = "LEVEL")
private Long level;
[...]
public TraceLevelType getLevel() {
	return TraceLevelType .parse(this.level);
}
public void setLevel(TraceLevelType level) {
	this.level = level.getIdType();
}

Sí, lo sé, hay static metido de por medio, hay un break, pero no he encontrado una solución mejor hasta la fecha para esta casuística. Se te ocurre una solución mejor?

ToStringBuilder class belongs to org.apache.commons.lang library.

No suelo copiar y pegar en este blog, sí enlazo y ahora retuiteo, pero esto me parece tan reseñable y tan a tener en cuenta por mí mismo ahora, que no puedo por menos que copiar los 10 rasgos comentados por el autor. El artículo original por supuesto es más recomendable por que está más desarrollado. Leételo.

10 rasgos que definen a las personas que consiguen resultados

1. Son personas que tienen claro lo que quieren.
2. Son personas de Acción.
3. Son personas disciplinadas.
4. Son personas que no pierden el Foco.
5. Son personas que tienen paciencia.
6. Son personas que ponen la responsabilidad en ellos mismos.
7. Son personas que tienen una fuerte Determinación.
8. Son personas mentalmente sana.
9. Son personas que se mueven en entornos adecuados.
10. Son personas que tienen una actitud de mejora continua.

Resulta que una de las tareas que habíamos definido era borrado de usuarios, lo implementé y testeé, pero ahora nos hemos dado cuenta que esta funcionalidad no se quiere, lo que se desea es un borrado lógico de los usuarios por lo que esta funcionalidad ya implementada y testeada deja de tener sentido.

• Desde luego, debe eliminarse del código de producción de la aplicación (típicamente src/main/java) para que un usuario no lo pueda utilizar.
• Podríamos definir un entorno de pruebas transaccional que haga simplemente rollback al acabar, por lo cual esta funcionalidad en concreto tampoco debería archivarse dentro del código de pruebas (típicamente src/main/test).
• Tampoco es un código tan reutilizable como para almacenarlo en la arquitectura o una clase de utilería.

Sin embargo resulta y resultará útil para realizar pruebas web en el entorno de pruebas : me creo mi usuario, hago lo que tenga que hacer para probar otras funcionalidades, y luego lo borro (en cascada) y borrando toda su actividad dejando el entorno como si nada hubiese ocurrido, lo cual aunque se trate de un entrono de pruebas, es algo de agraceder para que no interfieras con los datos de otros compañeros. Peligroso en otros entornos, pero útil en pruebas.

Para explicar la situación con una analogía del mundo de la construcción, esta mesa ya no va a añadirse al edificio, no me resulta útil para comprobar la integridad del edificio, pero me resulta útil para mantener el edificio operativo, puedo subirme a ella y cambiar las bombillas del techo.

Mi duda aquí es qué hacer con esta funcionalidad en concreto, ya implementada y testeada,  o más en general con el típico código que implementa funcionalidades que no debe subir a producción pero sí te puede resultar útil mientras construyes, testeas, monitorizas o supervisas (y que no son test, aunque eso de hacer test en España está muy mal visto).

Deberíamos implementar este código ad hoc, testearlo, usarlo y luego borrarlo? Deberíamos almacenarlo? Dónde debería estar ese código?

Mi respuesta:

• Debemos conservarlo. Si es funcional (está testeado) y me ha resultado útil una vez es probable que me vuelva a resultar útil en el futuro, y es probable que a otro compañero presente o futuro le resulte útil de nuevo.
• Debemos conservarlo fuera de la carpeta de producción (títpicamente src/main/java) para que nunca pueda publicarse, es decir no vale comentarlo, tarde o temprano alguien commiteará con el código descomentado, y de pruebas (típicamente src/main/test).

Yo lo que suelo hacer es crearme otro paquete (suelo llamarlo src/iplusd/java y/o src/support/java) que no se utiliza al ensamblar el artefacto entregable (vamos, el jar o war), y almacenar allí este tipo de código pero vigilándolo para que no se convierta en un cajón desastre ni se complique tanto como para que haya que documentarlo o crear apis o…

Y tú, qué haces ante este tipo de situaciones?

Objetivo primario equivocado

El objetivo principal que me ha movido a intentar crear la empresa ha sido quedarme en Salamanca, lo que supone una restricción innecesaria y a medio plazo creo que ha sido la principal razón de mi fracaso. Debí centrarme en crear una empresa viable, sin importar la localización geográfica, y en un futuro vivir en Salamanca y teletrabajar.

Encontrar las personas adecuadas

Todo es más fácil si te rodeas de las personas adecuadas, colaboradores, empleados, socios, proveedores, clientes… Yo, jugador de equipo que adora estar rodeado de gigantes, me he sentido muy solo y grande en Salamanca.

Ha supuesto una tremebunda decepción a nivel profesional, sobre todo por las altas expectativas que tenía en mi querida ciudad doblemente universitaria (pública y privada). Quizás sea yo, que no he sabido encontrarlas o reconocerlas? Quizás. Pero la mayor empresa de software salmantina fue nuestro proveedor, y sin objetar nada a nivel humano (públicamente), su trabajo fue para donar a un museo: todas las malas prácticas posibles, en 3 meses quitamos la mitad de las líneas de código, rebajamos el peso de 80 megas a 20, el tiempo de arranque de 03:30 minutos a 0:30… Tardamos 6 meses en incorporar a un desarrollador junior. Sinergia es una palabra desconocida en esta ciudad.

Aunque me duela en el alma, Salamanca no es lugar para emprender software.

Comunicación primero

Soy una persona medianamente multidisciplinar: sé un poco de todo, y pensaba que yo mismo podría cubrir todas las áreas mientras encontraba a otra persona y no sería un técnico que piensa que por saber manejar un destornillador puede crear una mesa, y crear una empresa de venta de mesas.

Sin embargo caí en un error fundamental. Pensé que puedo competir en un mercado con un producto mejor y más barato, así que estoy creando un producto y luego ya me esforzaría en abrir el mercado. Pero cuando hice el estudio de mercado a posteriori he descubierto que  no solo que había docenas de soluciones, algunas gratuitas, sino que oh sorpresa, se trata de un mercado menguante en el que migrar es muy costos.

En breve publicaré el proceso de desarrollo de un nuevo producto, que empezaré a seguir en el futuro.

Enfocarse

Sabía que no debía ofrecerme a prestar servicios, es decir a hacer páginas web, porque me distraían del objetivo principal de construir un producto que vender y revender, fue un error consciente por razones no profesionales. Además tengo abiertos dos proyectos y ninguno publicado, junto con dos colaboraciones con otras empresas : mucho tiempo y esfuerzo para pocos resultados y premios.

¿Quieres ayudarme con alguno? Busco preferiblemente a un partner para el área de comunicación, pero cualquier ayuda se agradecería

Surecat

Por un lado ya tengo casi acabado desde el punto de vista técnico un proyecto muy majo, muy útil y podría fácilmente pasar una fase beta ya mismo; pero le falta comunicación, no sé qué contar de él.

• Creo que lo llamaré “Surecat“, por similitud al plugin de Maven “Surefire“, por introducir certeza (Sure) en el ámbito de las pruebas y desarrollo, y por homenagear a mis gatos (cat). Bien es cierto que quizás debería llevar alguna referencia a Test, QA o CI.
• Su apellido me está bloqueando. Es una aplicación? Es un Framework? Es un Plugin? “Mejora tu proceso de Integración Continua: + comunicación interna, + automatización de pruebas, + calidad de tu software.” Sí, lo sé, es abstracto, largo, y cutre. Además tiene que estar en inglés.
• La comunicación será en inglés. En España somos muy machos, programamos a calzón quitado, pelo en pecho y una cerveza en la mano, los test son para principiantes y pringaos, así que esta aplicación sobra en España.
• Funciona muy bien sobre JUnit o sobre el framework de test de Spring, pero puede mejorar cualquier otro framework. Su extensión a otros lenguajes de programación no parece difícil, pero solo tengo dos manos.

Cabe destacar que ha sido mi primer desarrollo de cero utilizando TDD, y ha sido una experiencia muy negativa que me ha hecho replantearme la opinión que me merecen destacados profesionales de nuestra industria. Pero esto para otro post, ya que supongo que será polémico y habrá que razonarlo suficientemente.

GesPYME

Aplicativo para llevar la gestión de tu pequeño o mediano negocio, ya seas autónomo o empresario. El nombre es evidentemente temporal. Todas los posibles usuarios de este producto me han comentado su disgusto con sus actuales aplicaciones por sus errores, mal interfaz, elevados precios y pésimo soporte, así que yo creía que había mercado y que podía hacerlo mejor que los competidores a pesar de las dificultades (diferentes y variables legislaciones y negocios).

La parte técnica de negocio y persistencia está muy cuca, una arquitectura basada en Spring + Hibernate muy genérica, potente, extensible y fácil de entender. Había automatizado el modelado de datos con MySQL Workbench e Hibernate Tools (aún no disponible para Eclipse Juno!) para generar y mantener actualizados el modelo y la base de datos de forma gráfica.

Al llegar a la capa de vista me he encontrado con un iceberg estupendo. He decidido utilizar Java Swing porque la voy a hacer de momento una aplicación de escritorio por razones de negocio, y porque así el día de mañana implementarlo en GWT debería ser fácil, me estoy encontrando sapo tras sapo.

Verborrea de código y framework muy rudimentario y rígido, tengo el triple de líneas de código en la capa de vista que en todo el resto de la aplicación, y aún no he resuelto dos problemas funcionales importantes y genéricos : botones en las tablas de datos e inyección de los controladores en los elementos de vista.

Justicia? Gratuita? Dicho sea de paso, necesité contratar un abogado para realizar las gestiones ya que me fue imposible encontrar la ayuda necesaria en los propios juzgados. Cuando pregunté a un funcionario cuántas copias de mi denuncia debía entregar en el registro, la respuesta fue “es evidente cuántas, una para cada parte”, sin conseguir ninguna aclaración a tan sabia respuesta. Por cierto, en el registro no supieron decirme ni siquiera la perogrullada anterior. La respuesta correcta debería ser “cero, pásate por el registro y te toman declaración, redactan la denuncia, hacen las copias, las compulsan y se encargan de entregárselas a cada parte”.

A día de hoy Fogasa no nos ha pagado,  pero además no sabemos aún cuánto (ni cuándo) cobraremos ya que durante el proceso el Gobierno cambió la cantidad cubierta por este fondo para el salario a prácticamente la mitad y aunque debería no ser retroactivo nos tememos lo peor; eso sí, no me toques mi indemnización, que se ve es más importante que el salario por la (nula) reacción de los trabajadores a este despropósito.

El día 3 de Diciembre tenía que fichar el paro por segunda vez, pero se me pasó y fiché el 10 de Diciembre, lo que me ha hecho perder la subvención de Diciembre. Esta semana voy a empezar a moverlo, no para recuperar esa cantidad sino para intentar evidenciar la injusticia e inutilidad de un sistema que me penaliza por buscar trabajo (firmé un nuevo contrato el 13 de diciembre después de dos semanas de negociaciones). Aunque la cifra de 6 millones de parados ya habla por sí sola.

Parece que olvidamos que el Fogasa o la prestación por desempleo no son caridad, no son un favor que nos hace el Estado, sino que son seguros por los que hemos estado cotizando durante años pagando unas cotizaciones sociales altísimas en relación con lo recibido a cambio e injustas hasta el punto en que nunca los contrataría si fuesen opcionales o privados, máxime después de dejarnos en la estacada cuando son necesarios.

Desde luego si Larra levantase hoy la cabeza, no vería mucho cambio en la Administración Pública. Dejo a vuestra consideración la necesidad de un juzgado para poder cobrar lo que es nuestro, de un abogado para que un juzgado reconozca una deuda y disuelva un contrato, los plazos (nos dijeron que no es normal que el proceso fuese tan rápido), el cambio posiblemente retroactivo sobre la cantidad cubierta por el salario y el no cambio sobre la cantidad cubierta por las indemnizaciones, así como el patético sistema del inútil SEPE/ECYL…

Y eso que no he hablado de la educación, ni del despropósito de la nueva zona urbanizable del cementerio de Salamanca, ni de las ruinosas cuentas de nuestro Ayuntamiento, Comunidad y Estado, ni de la no separación de poderes, ni de… Pero permitidme insistir, la culpa no es de políticos, es tuya, es mía, es nuestra.

El mundo no es como es; el mundo es como lo hacemos todos nosotros, todos los días.

Cámbiate a ti para cambiar al mundo.

Aprovecho para comunicaros que me he dado de alta dos cuentas de twitter, una que utilizaré para temas personales (@yoyoooyoy1) y otra para temas profesionales (@jcalvosanchez).

Por defecto no puedes hacerlo en Eclipse, debes ir a Preferences > General y activar el check de “Show heap status”.

Relacionado, voy a echar un ojo al Memory Analyzer de Eclipse.

Jane un ejemplo perfecto de resilencia sobre cómo superar en evento traumático. Sufrió un golpe en la cabeza mal curado, lo que la obligó a batallar literalmente por su vida durante un año, pero este importante trauma en su vida la ha convertido en una mejor persona, lo que llama crecimiento post-traumático en contrapartida a estrés post-traumático.

En esta charla nos, cuenta de una manera clara y muy documentada, su experiencia traumática, cómo la superó y cómo su experiencia nos puede beneficiar a todos nosotros sin necesidad de pasar por un calvario durante todo un año.

A traumatic event doesn’t doom us to suffer indefinitely. Instead, we can use it as a springboard to unleash our best qualities and lead happier lives.

Para lograr sacar provecho de su traumatismo, Jane diseñó un juego, Super Better (“Super mejor”), que ha refinado con otras personas en situaciones vitales críticas. El juego te propone 4 simples quest a realizaar cada hora:

1. Super Better Quest 1: Resilencia física. Elegir entre levantarse y andar 3 pasos o levantar los manos formando un puño tan alto como puedas durante 5 segundos. Mejora la capacidad de esfuerzo y recuperación del cuerpo.
2. Super Better Quest 2: Resilencia mental. Elegir entre chascar los dedos exactamente 50 veces o contar desde cien hacia atrás en pasos de 7 (100, 93, 86…). Mejora el foco mental y la fuerza de voluntad.
3. Super Better Quest 3: Resilencia emocional. Elegir entre si estás en un interior busca una ventana y mira fuera (si estás fuera mira dentro) o busca una imagen de algún cachorro. Gestionando 3 emociones positivas por cada 1 emoción negativa mejoramos nuestra salud y habilidad para superar cualquier obstáculo.
4. Super Better Quest 4: Resilencia social. Elegir en estrechar la mano de otra persona durante 6 segundos o dar las gracias a alguien (aunque sea vía electrónica). Mejora la confianza en los demás y el deseo de ayudar.

Roles

• Product Owner. Responsable del Valor del proyecto, y de la gestión del Product Backlog.
• Scrum Master. Responsable de la produtividad, madurez y enfoque del equipo. Supervisión de la pila de producto, y comunicación con el Product Owner para pedirle aclaración de las dudas que pueda tener, o asesorarle para la subsanación de las deficiencias que observe.
• Equipo. O Equipos, cuyos miembros son multifuncionales y se autogestionan.

Artefactos

• Producto, es el sistema en construcción, tanto el ya construido y operativo como el trabajo por realizar.
• Incremento, es la parte o subsistema que se produce en un sprint y se entrega al Product Owner completamente terminada y ”’operativa”’.
• Product Backlog. Es una Pila de trabajo (ordenada por prioridad) dinámica que contiene las historias de usuario a implementar y que definirán al sistema.
• Sprint Backlog. Es el conjunto de trabajo obtenido del Product Backlog que el Equipo y el Product Owner deciden incluir en la próxima iteración y que generará un Incremento en el Producto.
• Burndown Chart. Gráfico que muestra el avance y trabajo restante de la Iteración.

Actividades

• Sprint Planning. Reunión entre el equipo y el Product Owner para elegir qué trabajo se va a entregar al concluir la iteración.
• Daily Técnico. El equipo comparte brevemente (5 ó 10 minutos) el estado y progreso de su trabajo, así como las dificultades que se va encontrando.
• Sprint reviews. Demo en la que el equipo muestra al Producto Owner el trabajo completado durante la iteración, sobre el propio trabajo completado.
• Sprint retrospectives. Reunión en la que el equipo busca formas de mejorar el producto y el proceso.

Proceso

1. El Product Owner crea la Pila priorizada de trabajo del Producto.
2. En la Planificación de la Iteración, se crea la Pila de trabajo de la Iteración a partir del tope de la Pila de trabajo del Producto, y el equipo dedice cómo se implementará.
3. El equipo dispone de un plazo de tiempo para completar su trabajo, Iteración típicamente de 2 a 4 semanas, pero se reune diariamente para controlar el progreso.
4. Durante todo el proceso, el ScrumMaster mantiene al equipo enfocado en su meta.
5. Al finalizar la Iteración, el trabajo es potencialmente entregable.
6. La Iteración concluye con una Revisión y una Retrospectiva.
7. Se repite nuevamente desde el segundo paso.

Referencias

• [ENG] Scrum en Scrum Alliance.
• [ENG] Scrum Master in under 10 minutes, video de Axosoft, creadores de la herramienta de gestión OnTime basada en Scrum.
• [ESP] Flexibilidad con Scrum, un libro en formato PDF gratuito escrito por Juan Palacio de la siempre recomendable Navegapolis.

Washington nació en el seno de una familia adinerada de terratenientes en Virginia, en la que pronto fallecieron su padre Augustine (cuando Washington tenía 11 años) y su hermano mayor Lawrence (cuando Washington tenía 20 años) quién heredó el rol de padre. Se educó únicamente en América bajo la tutela de varios maestros en un estilo de vida tranquilo, de trabajos de sol a sol diarios, organizando a sus trabajadores y planificando las siguientes temporadas. Esta educación se reflejó posteriormente no solo en su estilo de liderazgo, sino también en su visión de Mount Vernon, su plantación, como un adelanto del paraíso en la tierra. Su amor por la tierra le llevó a tomar como primera profesión la topografía, reconociendo, cartografiando y registrando terrenos inexplorados como funcionario público, habilidad que posteriormente le resultó muy útil en el arte de la guerra.

Tras la muerte de su hermano Lawrence su posición como General Adjunto en la milicia estatal fue dividido en cuatro oficinas, siendo nombrado Washington responsable de una de ellas con el rango de Mayor (estos rangos no estaban homologados en el ejército regular inglés), comenzando a sus 21 años de edad su carrera militar luchando junto al ejército regular inglés en las guerras contra los franceses e indios por el control de Ohio. A pesar de que su primera expedición acabó en derrota y captura, y de que su segunda expedición como ayudante de campo del veterano general inglés Braddock resultó un desastre [1] debido a la falta de experiencia del general en combate en tierras vírgenes, Washington fue muy tenido en cuenta durante la campaña y su actuación tras la derrota organizando los restos del ejército y retirándose de una forma ordenada, le sirvieron para ser promocionado a Coronel y Comandante en Jefe de las milicias de Virginia a sus 23 años de edad.

Al mando de la primera unidad militar americana a tiempo completo, que contaba con alrededor de 1.000 hombres, sus órdenes fueron proteger las fronteras de Virginia, labor en la que destacó respecto a otras colonias cuyas milicias estaban formadas por unidades a tiempo parcial. A sus 26 años de edad, renunció a su cargo retirándose a Mount Vernon para hacerse cargo de sus obligaciones y negocios personales.

Durante esta época Washington ya gozaba de una gran reputación militar a nivel colonial y americano, así como un elevado estatus social, que se ampliaron como consecuencia de su exitosa actividad mercantil (favorecida por el matrimonio a sus 27 años de edad con la adinerada viuda Martha Dandridge Custis), su asentamiento en la élite social estatal [2], su elocuencia y dialéctica, así como su compromiso como ciudadano, hasta llevarle a iniciar su carrera política a sus 33 años de edad ingresando en la asamblea estatal y siendo uno de los líderes del movimiento colonial que buscaba el reconocimiento de igualdad entre colonos y ciudadanos ingleses. Este conflicto comenzó con la sanción del primer impuesto directo sobre las colonias (la Ley del Timbre en 1765), fue escalando uniendo a las colonias en el I Congreso Continental, y derivó finalmente en el conflicto armado entre las dos partes conocido como Guerra de la Independencia de los EEUU o Revolución Americana.

El II Congreso Continental en 1775 aprobó la formación del Ejército Continental y el nombramiento unánime de Washington como Comandante en Jefe del mismo en a sus 43 años de edad. Un año después, Washington fue uno de los padres de la Declaración de Independencia de los EEUU a sus 44 años de edad. El conflicto armado finalizó 8 años después con el reconocimiento por parte del Imperio Británico de la independencia de los EEUU en el Tratado de París de 1783. Partiendo en clara desventaja, con tropas inexpertas y una permanente escasez de dinero, equipo militar, ropa e incluso comida (se estima que de las 25mil bajas totales durante la campaña, unas 10mil bajas fueron por inanición y unas 7mil más por enfermedades), sin armada, aplicando tácticas de desgaste que le valieron el sobrenombre de Fabio, se logró una victoria contra todo pronóstico ante el mayor ejército y armada del momento gracias a la guerra en Europa entre la alianza española y francesa contra el enemigo común inglés y la alianza con Francia en 1778 (y aunque Irving no lo menciona también España).

El nacimiento del nuevo estado americano no fue inmediato. Finalizado el conflicto armado desapareció el enemigo común de las 13 colonias y con su libertad debían escoger entre convertirse en 13 estados o una coalición de estados o una solución mixta de confederaciones. Washington influyó decisivamente durante estos años, presidiendo a sus 55 años de edad la convención que dio a luz la Constitución de 1787 la confederación se convirtió en nación con el apoyo de la mayoría de los ciudadanos, pero aún hoy persisten entre los ciudadanos corrientes en contra de un poder federal fuerte.

Este liderazgo unionista le valió la elección unánime como Primer Presidente de la nación en 1789 a sus 57 años de edad, con John Adams como vicepresidente. En su primer mandato fue muy cuidadoso, siendo consciente de que todo lo que hacía establecería un precedente, alejando al gobierno de las formas de gobierno europeas (República vs Monarquía), eligiendo a su equipo, delegando y resolviendo conflictos entre los dos partidos que surgieron (partidarios de Alexander Hamilton y partidarios de Thomas Jefferson). La asunción de la deuda de la guerra por parte del gobierno federal fue el primer paso para ejecutar su derecho a imponer impuestos federales, precisamente para sufragar dicha deuda, lo que generó un movimiento de resistencia armado conocido como la Rebelión del Whiskey, que fue sofocado enérgicamente pero sin apenas muertes.

Al finalizar su primer mandato en 1793 volvió a ser elegido unánimemente para un segundo mandato. Formalizó las relaciones y el comercio con Gran Bretaña con el Tratado de Jay de 1794 a la vez que mantuvo una estricta neutralidad en la guerra entre la Francia revolucionaria y los ingleses, pero se encontró con una gran oposición interna ya que el pueblo quería unirse a Francia por la afinidad a su gobierno, en devolución a la ayuda prestada y por algunos incumplimientos ingleses del Tratado de París.

Al finalizar este segundo mandato renunció a presentarse a la reelección y distribuyó un pequeño texto de despedida publicado por todo el país y aún hoy recordado en el Senado, conocido con el título de “Despedida de Washington” (Washington’s Farewell Address, cuyo texto original puedes consultar aquí). La sensación de una guerra inminente contra Francia por las debilitadas relaciones causadas por el Tratado de Jay le llevó a aceptar un último servicio en 1798 como Comandante en Jefe para preparar un ejército que sirviese en una emergencia.

George Washington, salvo por el último servicio público mencionado, consiguió su objetivo de retirarse de la vida pública en su plantación de Mount Vernon, viviendo una vida tranquila dirigiendo su plantación hasta su muerte en 1799 a los 67 años de edad.

Campañas durante la Revolución Americana

• Asedio americano a Bostón.
• Desembarco inglés en New York.
• Victoria en Trenton y rapiña en New Jersey.
• Campaña en el Norte: Ticonderoga y Saratoga.
• Pérdida de Philadelphia.
• El cabal de Conway.
• Campamentos en Morristown y Valley Forgue.
• Victoria en Yorktown.
• Desmobilización del ejército federal.

Notas

[1] La humillantemente derrota de Braddock ha sido ampliamente estudiada ya que su rival era muy inferior en número, equipamiento, experiencia y mando. La determinación de un oficial francés en tomar el mando de un destacamento para preparar una emboscada convenció al comandante francés a última hora, cuando el ejército de Braddock esta a escasos kilómetros del fuerte que ocupaba, dado que no tenía nada que perder al estar decidido a rendir el fuerte sin condiciones. Tan a última hora tomó la decisión que a la expedición franco-india no le dió tiempo de tomar posiciones y se topó con la vanguardia de Braddock, comandada por Gates, poco después de haber cruzado un río. Al oir los disparos una parte del cuerpo central de Braddock se apresuró en cruzar el río, topándose con la vanguardia que se estaba retirando y haciendo fuego contra los pocos que se habían quedado

[2] Durante su estancia en Mount Vernon, Washington llegó a invitar a unas 2.000 personas de alto rango social, mientras ordenó tratar al resto de personas de una manera civilizada pero manteniéndoles en una prudencial distancia para que la familiaridad del trato no socavase su autoridad.

La obra es voluminosa, muy bien documentada y contextualizada, y resulta muy fácil de leer. Incluso hay momentos en los que echas de menos más datos del contexto histórico y personajes claves. Sin duda es muy recomendable aunque exija paciencia para llegar al final.

Próximamente publicaré los datos biográficos de George Washington.

Siento el mayor desprecio por las personas que son capaces de planificar medidas que no se atreven a poner en práctica.

Joseph Reed

Lo que no se consigue en casa, nunca puede tener éxito fuera.

George Washington

WebWhiteBoard.

Necesario

Lógicamente disponer de un piloto funcional. Para ello deberán estar acabadas las capas de control y vista.

Una planificación de visitas. Quiero cerrar dos en Salamanca y dos en Lugo, una en Ávila, y luego buscar algo más por ahí, preferiblemente el noreste.

Dedicar 80 horas, preferiblemente de calidad!

Estaría bien…

Que el piloto fuese una versión portable. Para ello debería instalar una base de datos, crear el esquema de la aplicación y disponer de un ejecutable, y todo esto para cualquier sistema operativo.

Que la empresa tuveria un nombre, así como el producto.

Empezar a documentar un poquito.

Para mejorar en un futuro cercano

Máquinas virtuales, automatizar back ups.

Crear un generador automático de código. Cuando en el futuro vaya añadiendo funcionalidades, hay bastante código que puede ser automatizado (crear y configurar daos, servicios, controladores e incluso parte gráfica), y podría aprovechar mi suricata para parametrizar este programa. Lo ideal sería integrarlo con eclipse desarrollando un plugin, pero…

Un site web, pero previamente se necesitaría tener al menos un nombre, el de la  empresa o el del producto.

El mayor logro de esta iteración ha sido simplificar el proyecto, que ahora tiene un alcance claro y definido para esta primera fase piloto, y una hoja de ruta clara.

La capa de vista no se ha completado, pero sí ha arrancado. La razón por la que no se ha completado es porque he decidio convertir mi capa de vista de pruebas en una capa de vista “clásica”, para poder vender la capa de vista que yo quiero como una mejora, y por tanto necesita más detalles que si fuese una simple colección de enlaces. De momento emplearé Swing. También he decidido que incluir una capa de controladores. ya que ahora la capa de vista será de producción y no de pruebas.

Sobre máquinas virtuales, nombres y tareas comerciales, cero avance, en parte debido a la escasa creatividad de esta semana y en parte debido a que las obras en la oficina me han obligado refugiarme en un lugar… poco productivo.

En Spring v03.xx tenemos las siguientes posibilidades de popular beans mediante etiquetas:

@Resource, es una etiqueta especificada en la Java Specefication Request JSR-250 (Common Annotations for the Java^TM Platform). En Spring, inyectará la dependencia por nombre. Es decir, buscará dentro del contexto un bean cuyo nombre coincida con el nombre de la variable etiquetada. En el Contenedor IoC, un bean puede tener uno o más identificadores (puede tener aliases), pero todos ellos deben ser únicos en el ámbito del contenedor.

@Autowired, es una etiqueta especificada por el propio framework de Spring. En Spring, inyectará la dependencia por tipo. Es decir, buscará dentro del contexto un bean cuya clase coincida con el tipo de variable etiquetada.

@Inject, es una etiqueta especificada en la Java Specefication Request JSR-330 (Dependency Injection for Java). Es intercambiable por la etiqueta @Autowired siempre que su JAR esté en nuestro classpath.

La inyección de dependencias por tipo puede encontrarse con que dentro del mismo contexto existan más de un bean con el mismo tipo. Un ejemplo sería si tenemos un bean llamado administrador del tipo persona, otro bean llamado superadministrador del tipo persona, y una variable de tipo persona etiquetada con @Autowired o @Inject. Estos casos se utiliza la etiqueta @Qualifier para discriminar por nombre el bean que deseamos cargar, ya que el nombre sí que es único dentro del contenedor.

Ojo, porque la implementación de la etiqueta @Qualifier de la JSR-330 es distinta a la de la etiqueta @Qualifier de Spring v03.xx.

En resumen

¿Cuál es la mejor forma de inyectar dependencias en Spring 3? ¿Mediante configuración XML, mediante código Java, mediante anotaciones de Spring o mediante anotaciones de JSR-330? Pues la respuesta, como casi siempre en este tipo de preguntas, es que depende de la situación

Relacionado

@Required, esta etiqueta simplemente indica que la propiedad anotada debe ser populada en tiempo de configuración, es decir cuando se carga el contexto de Spring, bien mediante Autowiring o bien mediante configuración del bean en el XML. Si no es populada, entonces Spring lanza una excepción.

Notas

Ver la documentación original de Spring 3:

• The Inversion of Control Container.
• Autowiring collaborators, que incluye además los modos en los que trabaja.
• Annotation-based container configuration.

En versiones anteriores a v03.xx no existe diferencias entre las etiquetas.

Tengo que simplificar el proyecto, por lo que generaré un modelo de base de datos más simple, y comenzaré a construir de cero el proyecto sobre él.

Una vez construida la capa de servicio, y asegurada que funciona mediante sus correspondientes test, entonces construiré la capa de vista muy simplificada. La capa de control por ahora es opcional, no me preocupa ahora mismo que la vista llame a los servicios.

Algo tendré que investigar al menos sobre máquinas virtuales, para tratar de poner orden en el desaguisado de sistemas que manejo actualmente.

También tengo que empezar a dedicar tiempo a tareas fuera del ámbito técnico, esta semana será de calentamiento para tareas comerciales.

Finalmente, tengo que buscar nombre tanto para el producto como para la empresa, el objetivo es tener tres candidatos para uno de ellos.

• Backup: HECHO – De momento utilizaré HV como soporte para los backups de los datos, combinado con TrueCrypt. Debo mover a la carpeta Usuarios/Helmantica todos los datos a securizar, y extraer los datos a no securizar.
• Servidor SVN: HECHO – Respecto al servidor de SVN, de momento utilizaré VisualSVNServer sobre mi notebook con Windows 7. Ha sido muy simple, en 1h estaba todo hecho.
• Time Track: HECHO – Para corregir el problema del escaso tiempo dedicado al proyecto, he buscado algún software gratuito que me pudiese ayudar a registrar el tiempo exacto dedicado, para luego poder tomar las correspondientes medidas. Después de evaluar varios, de momento me voy a quedar con Task Coach, aunque quería que fuese más kanban-style o al menos pomodoro-style. A esta tarea le he dedicado 2h.
• Integración Continua: FAIL + POSTPUESTO – Respecto al servidor de Integración Continua, me he puesto un poco al día (Hudson vs Jenkins) y de momento he optado por Jenkins. Lo he instalado y configurado, pero no he conseguido que me de luz verde al proyecto porque aunque se descarga los ficheros fuente de configuración, no los incluye en el classpath del ejecutable y por tanto falla los test al intentar abrirlos. Por otro lado he decido postponer la I.C. básicamente porque de momento no tengo que integrar en un proyecto con un desarrollador ¿Por qué entonces le he dedicado ahora este tiempo? Porque en el futuro el proyecto generará varios artefactos (distintas versiones, pej una para desktop otra para webapp), y un servidor de I.C. creo que me será de mucha ayuda.
• Cloud, de momento no.

Los tres primeros días de la semana estuve pasando mi CV a formato Europass, creándolo en inglés en el mismo formato, actualizando mis CVs on line y echando un ojo al mercado, que está paradísimo.

Los sistemas de la empresa han crecido y se han complicado enormemente, hay que poner orden y ver cómo sobrevivir sin un segundo ordenador. De momento tenemos un servidor SVN, uno de Integración Continua (que no entrará en servicio de momento), otro de backup, otro de apoyo (por ejemplo para tickets) y otro para cada entorno de desarrollo (con un servidor MySQL y un tomcat). Además de momento una workstation (con su propio servidor MySQL y tomcat). Todo esto de momento dentro de la misma máquina!!!

Además me he dado cuenta que la primera iteración es más ambiciosa de lo que debería ser, voy a rebajar la complejidad del proyecto lo máximo posible.