Eclipse DemoCamps

No sé bien cómo he llegado hasta una lista de eventos llamados Eclipse DemoCamps pero, una vez más, he constatado que no hay ninguno organizado en España. ¿Alguien se anima? (La Fundación Eclipse ayuda, entre otras cosas, con 20 dólares por cabeza para la comida)

Hablar inglés es fácil... si sabes cómo

Hay toda una serie de palabras que empleamos en nuestra vida diaria y sobre las que no solemos hacer reflexión alguna porque forman parte de nuestro bagaje cultural común: el español. Sin embargo, en nuestra profesión solemos leer e incluso utilizar palabras de otros idiomas sin esa reflexión implícita o explícita. Voy a tratar de poner mi granito de arena en este asunto: modestamente y reconociendo de antemano que ni soy filólogo ni nada por el estilo.

Para ello a comenzar una serie de entradas en las que pretendo discutir sobre un término en particular y sobre el que, probablemente, algunos tengáis una opinión diferente. Os propongo realizar esa reflexión sobre el uso de esas palabras en público para así enriquecer nuestros propios puntos de vista.

Accountability

From the WordReference Supplement © 2008 WordReference.com:


accountability:

accountability

nf

responsabilidad

Esta palabra es el título del capítulo 2 del libro "Analysis Patterns" de Martin Fowler. Asimismo, es una palabra clave en el resumen del perfil de Kent Beck en LinkedIn:

My goal is to program well on teams and to encourage improvement in my
profession. I am actively working on becoming more transparent and
accountable in my work and improving my skills designing incrementally
and interacting with people.

Quería comenzar por esta palabra (y no por otras que puedan resultar más evidentes, como "feedback" o "refactor") porque también quiero que sirva de declaración de intenciones: ésta es una palabra que no solemos usar (ni en inglés ni en español) pero cuyo significado es muy profundo y tiene que ver con otras palabras que usamos con cierta ligereza, como calidad o profesionalidad. También es una excusa para comentar que (¡¡POR FIN!!) he comenzado a leerme el "Analysis Patterns" de Fowler y que me parece probablemente el libro técnico más recomendable que he leido jamás.

Accountability significa responsabilidad, pero en el sentido de compromiso, es decir, según el DRAE (Diccionario de la Real Academia Española):

responsabilidad.

1. f. Cualidad de responsable.

2. f.
Deuda, obligación de reparar y satisfacer, por sí o por otra persona, a
consecuencia de un delito, de una culpa o de otra causa legal.

3. f. Cargo u obligación moral que resulta para alguien del posible yerro en cosa o asunto determinado.

4. f. Der.
Capacidad existente en todo sujeto activo de derecho para reconocer y
aceptar las consecuencias de un hecho realizado libremente.

Real Academia Española © Todos los derechos reservados

responsable.

(Del lat. responsum, supino de respondĕre, responder).

1. adj. Obligado a responder de algo o por alguien. U. t. c. s.

2. adj. Dicho de una persona: Que pone cuidado y atención en lo que hace o decide.

3. com. Persona que tiene a su cargo la dirección y vigilancia del trabajo en fábricas, establecimientos, oficinas, inmuebles, etc.

Real Academia Española © Todos los derechos reservados


En mi opinión, tanto Fowler como Beck usan "accountability" y por tanto "responsabilidad" en el sentido de "Cualidad de responsable".



Fowler habla de los objetos y las responsabilidades que asumen dentro
de un modelo, mientras que Beck habla de sí mismo como profesional
dentro de un equipo de desarrollo. Fowler aplica la primera acepción del DRAE (Obligado a responder de algo o por alguien) mientras que Kent se refiere a sí mismo y por tanto debemos aplicar la segunda acepción (Dicho de una persona: Que pone cuidado y atención en lo que hace o decide).

Resumen

Bueno, la verdad es que no tengo mucho tiempo para escribir este post porque acabo de tener un niño (el segundo) y, como comprenderéis, estoy muy, muy liado. Sin embargo, no quería dejar pasar más tiempo y hacer un breve (brevíssssimo) resumen.

Tener un bebé

Ya no recordaba lo que es tener un bebé en casa, pero aquellos que aún no lo sepáis... ¡¡AÚN ESTÁIS A TIEMPO!! Tened siempre presente que para aprender algo no es necesario pasar por ello. :-)

Ahora lo que me toca es la peregrinación por las distintas ventanillas de la administración para que el mundo entero se entere de que Adrián Beas está en el mundo. Bffff, que pereza... ¿a nadie se le ha ocurrido que esto es una oportunidad de negocio tan buena como la de los que entran en tu habitación del hospital para hacerle fotos al bebé?


Agile Spain

Agile Spain ha rearrancado y parece que el incipiente "movimiento agilista" empieza a calar en España.

Hemos abandonado la vieja lista de correo de Yahoo! por la nueva de GoogleGroups con el objetivo de tener un poco más de control (y evitar cosas como el SPAM) y, sobre todo, tener una visión más fresca de cuántos somos realmente (puesto que muchas de las cuentas de la vieja lista están abandonadas).

Gente como Ricardo Roldán o Jorge Ferrer están contribuyendo decisivamente a recuperar la vieja plataforma de http://www.agile-spain.com y ya están pensando en toda una serie de mejoras. Tenemos un calendario de eventos (donde podemos encontrar cursos o citas interesantes), una bibliografía recomendada (y a medida que vayamos consiguiendo colaboraciones proactivas, también comentada), recursos (intentaremos que etiquetados para luego poderlos buscar y navegar)...

Por otro lado, también hay sugerencias por parte de otros miembros de la lista para establecer colaboraciones, p.ej. Xavi Albadalejo nos comenta sobre http://proyectosagiles.org y alguna otra que ahora mismo siento mucho no poder recordar.

Finalmente, decir que no sólo hay españoles en el grupo sino también de argentinanos y chilenos. Creo que nos debemos alegrar (y mucho) de que estemos consiguiendo atraer también a compañeros de profesión a las que nos une una lengua tan rica como el español. Se me ocurre que quizás deberíamos pensar en cambiar el nombre de Agile Spain por Agile Spanish, pero en ese caso sería más correcto renombrarnos a ¿"Agilismo Español"?... mejor lo dejamos así... ;-)


Curso de SCRUM

El martes estuve en medio curso de Scrum organizado en Madrid por Proyectalis e impartido por Angel Medinilla. Me temo que la Ley de Murphy hizo acto de presencia en mi vida e implacablemente acabó con mi presencia en el curso. Ya se sabe: "Si puedes tener un niño durante un curso de Scrum, lo tendrás." :-)

En cualquier caso, os recomiendo el curso que imparte Ángel porque no sólo saldréis con una idea muy completa Y PRÁCTICA de lo que es Scrum sino que además pasaréis un par de días muy amenos, en compañía de otros profesionales que, como vosotros, estáis en busca de esa otra manera de hacer.

Por cierto, que no se me olvide: un saludo a Emilio Bravo (que está en el GoogleGroup de Agile Spain y al que pude conocer en persona).

Orden EHA-451-2008

Me acabo de enterar por casualidad de que ha cambiado la norma según la cuál se forma el NIF (Número de Identificación Fiscal). Sinceramente, desconozco los detalles que han cambiado respecto a la norma anterior, aunque está publicado en el BOE como ORDEN EHA/451/2008 desde el mes de Febrero.

De hecho, hay empresas a las que la Agencia Tributaria les está cambiando el NIF de oficio; así que he pensado que quizás sería interesante publicarlo por si alguien tiene pensado usar el NIF como clave única e inmutable en el tiempo de una empresa en sus diseños. Otro día hablaremos del patrón Esencia, del que sólo he encontrado dos referencias escritas: un viejo artículo de 1998 y un apartado del "Analysis Patterns" de Fowler.

Refactoring en Español (4)

Hace ya un par de semanas que publiqué la última entrega de "Refactoring en Español". Voy a seguir con el ejemplo de Fowler en el libro "Refactoring" por el punto donde lo dejamos.

Removing Temps


Antes de comenzar hacemos el siguiente refactor "sintáctico".


Reordenamos en Customer.statement para poner juntas estas lineas y poder cambiar
lo siguiente:

  Enumeration<rental> rentals = _rentals.elements();
  while (rentals.hasMoreElements()) {
   Rental each = (Rental) rentals.nextElement();
   ...
  }

por:

  for (Rental each: _rentals ) {
    ...
  }

TESTS. Sí, aunque sea un cambio trivial, refactorizar consiste en hacer pequeños cambios pero siempre muy seguros; por eso lanzamos las pruebas unitarias cada vez que realizamos un cambio en nuestro código.


A partir de aquí podemos ver más claramente la necesidad/posibilidad de
trabajar sobre las variables totalAmount y frequentRenterPoints.

Primero trabajamos con totalAmount y creamos el método getTotalCharge como sigue:

 /**
  * Rolls over the list of rentals calculating
  * the total amount to be charged.
  * 
  * @return
  */
 private double getTotalCharge() {
  double totalAmount = 0;
  for (Rental each: _rentals ) {
   totalAmount += each.getCharge();
  }
  return totalAmount;
 }

Obsérvese que lo hacemos replicando el bucle que recorre la lista de Rentals y
moviendo el código que suma la cantidad correspondiente del bucle original al
del método (que se ejecuta al final del bucle original y fuera de éste).


Este cambio es conceptualmente difícil de concebir e implementar (este ejemplo es
un ejercicio de laboratorio y en la práctica nos podemos encontrar con casos mucho
más difíciles de ver).

El método statement queda como sigue después de este cambio:

 public String statement() {
  int frequentRenterPoints = 0;
  String result = "Rental Record for " + getName() + "\n";
  for (Rental each: _rentals ) {
   frequentRenterPoints += each.getFrequentRenterPoints();
   // show figures for this rental
   result += "\t" + each.getMovie().getTitle() + "\t"
     + String.valueOf(each.getCharge()) + "\n";
   totalAmount += each.getCharge();
  }
  // add footer lines
  result += "Amount owed is " + String.valueOf(getTotalCharge()) + "\n";
  result += "You earned " + String.valueOf(frequentRenterPoints)
    + " frequent renter points";
  return result;
 }

TESTS. En este caso está más justificado que nunca puesto que no se trata de un cambio nada trivial.


A continuación aplicamos la misma receta a frequentRenterPoints

El método statement queda finalmente como sigue:

 public String statement() {
  String result = "Rental Record for " + getName() + "\n";
  for (Rental each: _rentals ) {
   // show figures for this rental
   result += "\t" + each.getMovie().getTitle() + "\t"
     + String.valueOf(each.getCharge()) + "\n";
  }
  // add footer lines
  result += "Amount owed is " + String.valueOf(getTotalCharge()) + "\n";
  result += "You earned " + String.valueOf(getTotalFrequentRenterPoints())
    + " frequent renter points";
  return result;
 }

TESTS. No olvidemos ejecutarlos después de cada cambio.


Finalmente, incidir en el comentario que hace Fowler sobre el hecho de que, tras este
cambio, tenemos tres bucles que recorren tres veces la lista de Rentals. Esto lo
tendremos en cuenta cuando estemos mejorando el rendimiento, pero no ahora porque
lo que nos preocupa es mejorar el diseño (sin incumplir con los requisitos), y con
los cambios efectuados hemos mejorado el diseño y la legibilidad del código, lo
que nos llevará a reducir los errores y aumentará la reusabilidad. (El ejemplo de
Fowler es muy bueno: ahora podemos escribir un método htmlStatement que imprime
el recibo en formato HTML, pero reutilizando todo el código que no tiene que ver
con la estética del mismo).

Artesanía del Software

Acabo de terminarme una presentación en InfoQ titulada "Fostering Software Craftsmanship in a Corporate Setting" (en castellano sería algo así como "Fomentando la Artesanía del Software en un Entorno Empresarial"). Scott Dillman se pregunta qué es ser un "Software Professional" y a partir de ahí presenta una serie de consejos sobre cómo crear un entorno donde la creación del software (y los creadores) sean un bien apreciado y respetado.

Como está en inglés y es un poco larga, voy a tratar de hacer un pequeño resumen.

La artesanía consiste en:

• tomar responsabilidades
• aprender continuamente
• rechazar la especialización
• enorgullecerse del trabajo bien hecho
• transmitir el conocimiento
• cumplir con los estándares de la profesión

En particular, cuando habla de estándares, Dillman se refiere a aquellas técnicas y buenas prácticas reconocidas por todos (como TDD, integración continua, patrones de programación, etc).

Dillman propone un camino para introducir la creación artesanal del software en las empresas, frente a la "presunta" creación industrial que creen hacer ahora. Este camino consiste en tres pasos fundamentales:

1. Evaluar
   
2. Educar
3. Medir

Lo primero es conocer con qué "materia prima" se cuenta antes de proponer ningún cambio. Para ello se proponen entrevistas con los líderes técnicos, cuestionarios para los desarrolladores (para saber qué conocimiento y prácticas -buenas o malas- tienen) y establecer métricas a partir del proceso de integración continua. Me gustaría destacar que Dillman propone guardar estas métricas en base de datos para así poder aplicar técnicas de "business intelligence" para sacar conclusiones más ricas que las que podamos tener de los informes más bien simples que podamos obtener de un CruiseControl, p.ej.

La parte que más me ha interesado es la educativa. Dillman propone una serie de iniciativas que se pueden crear en una empresa con el objeto de mejorar las habilidades de los desarrolladores:

• Programación en pareja
• Recursos centralizados (como wiki, foros, bibliotecas, etc.)
  
• Sesiones educativas
• Craftsmanship Day (algo así como "El Día de la Artesanía")
• 10% del tiempo
• On-team mentoring (algo así como "Ponga un mentor en su equipo")

Las sesiones educativas me han interesado especialmente y voy a listaros varias de las propuestas que hace Dillman:

• Teasers (que se traduce por bromas o rompecabezas), y que se trata de breves consejos (más o menos prácticos) que idealmente caben en una página.
  
• Lightning talks (o "charlas relámpago") que, en apenas media hora, deben introducir un tema muy por encima.
• Tech talks (o "charlas técnicas") son presentaciones de una hora en las que se explica con algo más de detalle un tema, pero sin llegar a profundizar "hasta el fondo".
• En los Workshops (o talleres) se trabajan los conceptos en la práctica.
• Un Coder's Dojo (es como un gimnasio de programación) donde se aplica el lema "Para mejorar debes practicar". El concepto de "code kata" es realmente interesante (aunque no es nuevo) puesto que consiste en poner a prueba nuestras habilidades como desarrolladores (desde el análisis y el diseño hasta la programación) mediante sesiones cortas en las que se trata de resolver un problema muy concreto y acotado.

El "Craftsmanship Day" es un día que se puede dedicar a una combinación de las anteriores sesiones educativas, a fomentar la participación en la creación de contenidos comunitarios, etc.

El concepto de "10% Time" consiste en que los desarrolladores tienen un porcentaje de su tiempo para emplearlo libremente en cualquier iniciativa personal. A Google, que dedica un 20%, no le va nada mal porque muchos de estos proyectos personales terminan llegando al público.

Finalmente, la idea de los "Test Mercenaries" (que podéis ver en la presentación "Agile@Google") me parece muy buena puesto que consigue distribuir el conocimiento práctico. Es una forma de "mentorizar" de una manera muy ordenada y productiva.


En fin, he tratado de sintetizar todo lo que he podido. Espero que os sea útil.