Plant the code seeds in the spring

El año pasado (2011) nos quedamos con ganas de participar en  la segunda edición de AbreDatos, un concurso de desarrollo de aplicaciones utilizando datos públicos cuyo principal objetivo es concienciar de la importancia que tiene que los organismos permitan el acceso ordenado a los datos públicos que manejan.

Seguimos investigando sobre esta corriente y llegamos al concepto de Gobierno Abierto u Open Government. Está basado en tres principios:

• Transparencia: En la rendición de cuentas por parte del gobierno, información sobre lo que se realiza y acceso a la información clara y sencilla que permita un control de las acciones del gobierno así como crear valor económico ya que esos datos pueden ser utilizados por terceros para generar riqueza.

• Colaboración: Referente a la cooperación con la ciudadanía, empresas, asociaciones. Incluso se habla de colaboración entre funcionarios y administraciones. Si en una administración poseen un buen software que lo compartan con el resto de administraciones. Aquí el software libre juega una gran importancia.

• Participación: Favoreciendo el derecho de la ciudadanía en formación de políticas públicas aprovechándose de la inteligencia de sus ciudadanos.

El Evento

Es momento de reflexionar y pensar en que un año acaba y otro empieza. Acostumbro a aprovechar estos momentos de vacaciones navideñas para realizar una retrospectiva personal, ver donde me encuentro y analizar si voy dando los pasos adecuados para llegar a donde quiero estar en un futuro.

Voy a repasar los momentos mas importantes de este 2011, sin otro particular que al estar por escrito pueda revisarlos con el paso del tiempo.

Mi 2011

• Mayo 2011: Uno de mis objetivos para el 2011 era aprender nuevos lenguajes de programación. Esto unido a mis ganas de viajar produjo que me planteara ir a una de las conferencias internacionales mas importantes de Ruby en Europa: El Euruko, que se celebraba en Berlin. Por desgracia nos quedamos sin entrada así que junto con @eamodeorubio y @mcberros nos embarcamos en la conferencia de Ruby alternativa: Eurucamp. Fue una gran experiencia que me permitió conocer un poco mas sobre esta comunidad y poco mas sobre el lenguaje Ruby.

• En Junio  tuvo lugar la Agile Open Space 2011. He conseguido romper mis miedos y junto con @rlaina presentamos una charla/debate sobre El Talento. Fue un gran paso para mi y una gran prueba, incluso participé en la grabación de un podcast resumen de la conferencia, algo que nunca había hecho antes. Gracias Raquel :-).

• En Agosto montamos un grupo de estudio de JavaScript. Aprovechando que empezaba el grupo de JavaScript de Madrid decidí enviar un Tuit por si alguien estaría en Agosto por Madrid intentar estudiar JavaScript. Pensaba que no seríamos mas de 4 personas. Incluso el bueno de @eamodeorubio ofreció su casa por si queríamos organizarlo allí. Pero cual fue mi sorpresa cuando se presentaron cerca de 30 personas a la primera reunión del grupo. Desde entonces no hemos parado. Gracias a @etnassoft, @pasku1 y @eamodeorubio que compartieron todo su conocimiento de JavaScript y gracias a tod@s los que lo hicisteis posible con vuestra asistencia semana a semana.

• Después del grupo de estudio terminó el verano. Decidí involucrarme mas intensamente en la coordinación del grupo de JavaScript. Desde hace un tiempo tenía la sensación de que mucha gente utilizaba JavaScript en su día a día pero no había un punto de encuentro para reunir a todos los programadores /frontends y demás profesionales en torno a JavaScript. Aprovechamos la repercusión del grupo de estudio para enlazarlo con MadridJS que se acababa de fundar a finales de Junio. En apenas seis meses de existencia ya somos mas de 200 miembros. Además a las últimas reuniones han asistido una media de 80 personas así que estamos muy contentos.

• En Septiembre tuvo lugar la XPWEEK organizada por uno de los mejores profesionales que conozco, @carlosble. Carlos me propuso colaborar en una Jornada  previa con una charla. Fue el salto definitivo a hablar en público en una conferencia, ese paso definitivo. Gracias Carlos por la llamada.

• En Septiembre me dieron la oportunidad en atSistemas de participar como Scrum Master en un proyecto. Aunque mi dedicación no es plena si que estoy disfrutando mucho de esta nueva labor intentándolo hacer lo mejor posible. Veremos los frutos a lo largo del 2012. Sin duda gracias a atSistemas por la confianza depositada en mi.

Además pude asistir a la Conferencia Agile Spain 2011 celebrada en Castellón y a diferentes Open Spaces sobre temáticas variadas que me han aportado diferentes visiones. Gracias a tod@s l@s organizadores de estos eventos.

Objetivos para el 2012

• Intentar seguir mejorando mi profesión. Hay muchas pequeñas cosas que cada uno puede hacer en su círculo mas íntimo para intentar mejorar su “mundo real”. Yo seguiré trabajando pasito a pasito para intentar conseguirlo tanto desde dentro de mi empresa como fuera.

• Apoyar las comunidades locales de desarrollo, tanto participando en reuniones como intentando organizar algún sarao. Os habéis enterado del CodeMotion verdad?

• Que la comunidad JavaScript en España se mueva, crezca y demos mucho que hablar.

• Seguir aprendiendo e intentando ser mejor profesional

¡¡ FELICES FIESTAS A TOD@S!! Y Feliz 2012. Nos vemos

En los anteriores artículos de la serie os hemos hablado de los elementos que componen un ecosistema de software así como de posibles soluciones para su puesta en marcha. En este artículo trataremos de describir como encajan los ecosistemas de software con las metodologías ágiles.

Las metodologías ágiles surgieron hace unos cuantos años tratando de resolver los problemas que existían (existen) en el desarrollo de software. El cambio fundamental con respecto al modelo tradicional es que el ciclo de vida es iterativo e incremental. Esto implica dos cosas:

1. Trabajamos en ciclos de duración constante (iteraciones).
2. Al final de cada iteración entregamos una porción del producto / proyecto potencialmente desplegable, es decir, que podamos poner en producción si quisiéramos.

¿Qué podemos hacer?

Analizando la situación anterior debemos dedicar mas tiempo al desarrollo. Una solución sencilla podría ser ampliar la duración de la iteración a tres semanas pero, queremos seguir conservando la duración a dos ya que queremos conservar el feedback continuo del usuario. Tampoco podemos acortar mucho tiempo en las reuniones ya que estas ayudan al equipo a planificar y analizar los problemas que van apareciendo. Por tanto, necesitamos bajar el tiempo en el que el equipo prepara versión.

Aumentando la productividad

El principal problema del equipo es que realiza el esfuerzo de sacar versión (integrar funcionalidades al fin y al cabo) al final de la iteración. Además como gran parte de la preparación es manual se realiza de forma lenta y, en algunos casos, con errores en el proceso que obligan a empezar desde cero la preparación.

Necesitamos un sistema automático que realice esta ardua labor de integración diariamente. Has leido bien si, DIARIAMENTE, porque si algo cuesta hacerlo es mejor llevarlo a cabo con frecuencia para evitar sustos y sobre todo evitar problemas.

La integración continua consiste justamente en esto: Integrar de forma diaria los cambios producidos en el código.

¿Cómo puedo hacer integración continua?

Podemos llegar a realizar integración continua si y solo si:

1. Tenemos automatizado el ciclo de vida de nuestro proyecto (compilación, construcción, pruebas, despliegue, etc).
2. Contamos con un ecosistema de software con los elementos suficientes para poder realizar el proceso de preparación de versión de una forma automática.
3. Contamos con un juego de pruebas automatizado que nos permita detectar fallos en el código. Sin este juego de pruebas nunca estaremos haciendo integración continua sino simplemente construcción continua de software que es bien diferente.

Conclusiones

Bola Extra

Aquí os dejo un webinar en el que participé en el que os hablo de todas estas cosas. La duración es de una hora.

En mi anterior post describía los principales elementos que componen un ecosistema de software. En esta segunda parte quiero adentrarme mas en detalle en como poder crear uno de estos ecosistemas de una forma fácil.

Podemos intuir que la creación de un ecosistema de software es una labor en la que hay que invertir bastante tiempo. No solo en la creación inicial que podríamos decir que no es complicada, sino, también en el posterior mantenimiento y administración de dicha infraestructura.

La pregunta entonces es: ¿Cuánto tiempo y dinero debo invertir para conseguir esta mejora que necesita mi software?

No tengo una respuesta clara ya que depende mucho de los conocimientos con los que contemos al respecto y los diferentes productos que queramos incluir. Enumeremos a groso modo estos gastos:

• Necesitamos un administrador de sistemas con bastantes conocimientos de programación que se encargue de la instalación y mantenimiento de la infraestructura. Aunque no sea a tiempo completo. No se cuanto puede cobrar un buen sysadmin que controle de sistemas y desarrollo. Pongamos que es a tiempo parcial: 400 € /mes.

• Hardware: Importante, necesitamos “el hierro” donde instalar todo. Supongamos tambien que compramos un servidor de tamaño medio para dar el servicio que necesitamos. Por propia experiencia necesitamos una máquina con varios procesadores, 4 GB de RAM y 2TB de disco duro por lo menos. Esto puede costarnos en torno a 2000 € aproximadamente.

• Costes eléctricos: Pues las máquinas tienen que estar las 24 horas funcionando así que supongamos unos 30 €/mes.

• Backups y estación SAI, realmente varian mucho el precio en función del modelo y las prestaciones pero si que necesitaremos un sistema sobre el que realizar los backups y una buena estación SAI por si algo falla no se nos apaguen los servidores y tengamos una desgracia. Coste aproximado de 300€.

¿Qué puedo hacer?

¿Qué es Clinker?

Si te dedicas al mundo del desarrollo de software desde hace algún tiempo (años), seguro que alguna vez ha pasado por tu mente eso de ¡Quiero mejorar mi forma de hacer software!

Existen muchos puntos de mejora en cualquier organización / equipo / persona que se dediquen a crear software. Este artículo pretende centrarse en uno de los aspectos que más facilmente puede aportar esa mejora que estas buscando.

La  creación de software es una labor compleja que muchas veces se encuentra mas cerca del caos que de la ingeniería. Para  mejorar la forma de hacer software hay muchos aspectos en los que trabajar:

- Las personas, muchas veces nos olvidamos de ellas y proponemos metodologías y métricas que se olvidan de que somos personas. Si algo me gusta del movimiento agile es que centra gran parte de su esfuerzo en las personas. Pero de esto no voy a hablar en este artículo.

- La relación con mis clientes y proveedores es sumamente interesante e importante. Lo ideal en estos casos es trabajar con transparencia, confianza y sinceridad haciendo partícipe a mi cliente o proveedor de una relación en la que ambos ganemos. No siempre es posible partir de estos principios cuando comienza una relación. Los contratos ágiles son una buena aproximación para empezar esa relación en la que todavía no hay una confianza. Pero de esto no voy a a hablar en este artículo.

- La calidad del software, no nos olvidemos que lo  que hacemos es construir software y que, este sería uno de los primeros puntos en los que debemos trabajar. Extreme programming (XP) con TDD e Integración Continua son un bueno punto de partida, u otras técnicas no recogidas en XP como BDD, principios SOLID, DDD y un sin fin de técnicas y principios que evitaran que el software que generemos tenga una baja calidad y, por tanto, sea caro de mantener. Pero, de esto no voy a hablar en este artículo.

- Los ecosistemas de software, entendidos como el espacio de trabajo con un  conjunto de herramientas. Y  de esto, querido lector, es justamente de lo que quiero hablar en este artículo.

Sin mas, vamos al grano.

¿Qué es un ecosistema de software?

Una definición formal de ecosistema podría ser:

Espacio de trabajo en el que conviven un conjunto de herramientas que acompañadas de unas buenas prácticas permiten modelar una metodología de trabajo.

En definitiva, es el conjunto de herramientas que me permiten trabajar. Esto incluye, servidores de integración, repositorios, herramientas de análisis, etc.

Manuel Recena en su blog cuenta con un artículo muy bueno que explica un poco mas en detalle que es un ecosistema de software.

Elementos que componen un ecosistema

Vamos a analizar los elementos mínimos que, desde mi punto de vista, necesitaría un ecosistema. Como mi experiencia es en Java los elementos que aquí se enumeran son válidos para este lenguaje, pudiendo ser algunos prescindibles si trabaja con otro tipo de lenguajes:

• Repositorio de código o control de versiones: ¡Claro!, es lógico, pero aunque parezca algo evidente, en pleno siglo XXI hay todavía proyectos en los que no se utiliza control de versiones. Yo mismo he tenido la “suerte” de participar en alguno de estos proyectos hace unos cuantos años. Os podéis imaginar el caos que vivíamos día a día ya que un repositorio de código permite llevar el control sobre el código (gestión de conflictos, versionado, etc). Actualmente existen dos grandes familias:
• Repositorios centralizados: Donde el código se encuentra almacenado en un servidor central donde cada desarrollador sube y sincroniza el código. Los principales existentes son CVS y sus derivados y Subversion (SVN).
• Repositorios distribuidos: Donde cada desarrollador cuenta con un repositorio en local y puede compartir código con otros repositorios. Los mas utilizados son Git, Mercurial y PlasticSCM.

• Automatización del ciclo de vida del proyecto: El ser humano no está preparado para realizar tareas automáticas. Y es que podemos realizar estas tareas de forma repetitiva varias veces pero a medida que las ejecutamos con mas frecuencia nos distraemos y perdemos efectividad. Por tanto, todo aquello que sea repetitivo y no aporte valor directo debe estar automatizado. La compilación, construcción, ejecución de test, despliegue, análisis de código deberían ser tareas automáticas que una máquina pueda repetir sin perder la efectividad de un humano. Herramientas como Maven, Ant , Gradle, escrita en Groovy, nos ayudan con esta tarea de automatización.

• Gestión de dependencias: Normalmente los proyectos están compuestos de librerías externas. En muchos casos el número de dependencias es tal que su gestión se complica. Automatizar esta gestión con alguna herramienta que nos permita incluir todas nuestras dependencias en nuestro proyecto nos evitará mas de un quebradero de cabeza. Maven, Ant con Ivy o Gradle mencionadas anteriormente también nos pueden ayudar con esta gestión.

• Repositorio de artefactos: Si los repositorios de código almacenan nuestro código fuente, los repositorios de artefactos almacenan las dependencias con los artefactos (librerías) que necesitan nuestros proyectos de tal forma que sean accesibles de forma interna y sin necesidad de conexión con repositorios externos a través de internet. Archiva, Nexus o Artifactory son algunos de los mas utilizados en el mundo Java.

• Análisis estático de código: No somos perfectos y, por tanto, nuestro código tampoco. Necesitamos herramientas que analicen el código y nos permitan detectar duplicidades, malas prácticas e ineficiencias varias. Checkstyle, PMD, Findbugs son algunas herramientas. Las puedes encontrar englobadas en SONAR.

• Gestión de incidencias: Y es que nuestro software tiene defectos y mejoras que hay que implementar. Por ello, en alguno momento necesitaremos gestionar esos defectos y mejoras para saber su estado en todo momento. Sistemas como Trac, Jira o Redmine nos permiten de forma mas o menos cómoda llevar el control de todo esto.

• Entorno de QA: Donde permitir que los equipos de calidad y testing o incluso el propio usuario final puedan realizar pruebas de aceptación, usabilidad y funcionalidad de nuestro software.

• Sistema Single Signon: No queremos tener diferentes usuarios y contraseñas para cada una de nuestras herramientas. En nuestro ecosistema podemos instalar algún sistema que permita realizar la labor de autenticación una sola vez y propagarla al resto de sistemas.

• Wiki: Y es que lo de escribir toda la documentación en un documento WORD que queda desactualizado en el mismo momento que se comparte con el resto son cosas del pasado. Necesitamos contar con sistemas online que permitan mantener la documentación del proyecto actualizada y accesible desde cualquier punto. Nosotros usamos Xwiki o MediaWiki que es la que utilizan en Wikipedia.

Los días 20 y 21 de Octubre se celebró la segunda Conferencia organizada por la asociación Agile Spain, más conocida como CAS. Organizada en la Universidad Jaime I de Castellón con una asistencia alrededor de 250 personas entre asistentes, ponentes y organización.

Con un programa variado, pudimos encontrar charlas técnicas como “TDD una guía de supervivencia” de Alfredo Casado donde contó su experiencia aplicando TDD en un proyecto real. Con talleres más técnicos como el de Enrique Amodeo sobre SOLID refactor, pasando por charlas relacionadas con la motivación de equipos y las retrospectivas a cargo de Joserra Díaz o los contratos ágiles de Xavi Albadalejo. Podéis encontrar muy buenos resúmenes con diferentes puntos de vista en las referencias de este post.
Destacar la variedad de perfiles que encontramos y es que el movimiento Agile va mas allá de una metodología o una moda, afecta a toda la organización, desde dirección hasta desarrolladores.

Las Keynotes

Las keynotes recayeron sobre dos ponentes reconocidos internacionalmente. El primer día Xavier Quesada nos habló sobre “El último momento responsable” y la importancia de hacer las cosas bien ya que cuando algo sale mal generamos baja calidad y desperdicio (de tiempo, recursos, etc). En definitiva, cuantas menores veces hagamos las cosas mal mejor para nuestro producto, proceso, organización.

En la keynote del segundo día J.B Rainsberger dio un repaso a las prácticas de Extreme Programming y la orientación al cliente que deberían tener todos los desarrollos. Mediante técnicas como BDD podemos conseguirlo. Me quedo con una frase que dijo sobre cómo empezar el cambio: “Elige la gente motivada para el cambio, dale la oportunidad, ponle el reto, y espera”. Dicho de otra forma, no podemos cambiar a la gente / organizaciones que no quieran cambiar, así que centremos nuestros esfuerzos en las que si lo desean.

Mis premios CAS 2011

Por intentar ser un poco original he decidido otorgar mis premios para aquellos ponentes que destacaron especialmente. And The Oscar goes to:
- Vanesa Tejada: Premio a la ponente revelación por su excelente exposición de las diferentes técnicas visuales que podemos utilizar.
- Enrique Comba: Premio a la mejor puesta en escena. La llamada de “Uncle Bob” fue muy buena.

- David Bonilla: Premio al mejor efecto sonoro en una presentación (y por lo divertida, original e instructiva que fue).

- Joserra Díaz: Premio “doblete” por ser el único ponente que tuvo dos sesiones (por algo será).

- Enrique Amodeo: Premio a la charla más práctica, en la que se “picó tecla” y todo.

- Al resto de ponente: Premio a la valentía porque subirse a un atril no es nada fácil.
Por último, me gustaría agradecer a la organización el gran trabajo que han realizado durante los meses previos y, por supuesto, durante el desarrollo de la misma. ¡ENHORABUENA!.
También agradecer a los patrocinadores por confiar en el evento y apoyarlo y, por supuesto, gracias a TODOS los que decidisteis asistir y que con vuestra presencia lo hicisteis posible.

Conclusiones

Ahora empieza lo importante, el paso adelante. Os animo a que compartáis con vuestros compañeros, jefes, clientes vuestra experiencia en la conferencia y que empecéis a llevar a cabo acciones concretas de mejora en vuestros equipos, departamentos, organizaciones porque como dijo Xavi Gost: “Tú eres el cambio que estabas esperado”.
Yo ya he empezado…y tú, ¿a qué esperas?.

Referencias

Todos los recursos: posts, fotos y enlaces de interés.
https://sites.google.com/site/agilespain/referencias/conferencia-agile-spain-2011?pli=1

Bonus Track

Este año contamos con BonillaTV y aquí tenéis un video resumen de la conferencia. Además salgo en el video y todo, el video no tiene desperdicio. Hay que verlo hasta el final.

Video BonillaTV: CAS 2011

El 23 de Junio de 1912 nació Alan Turing. Se le conoce como uno de los padres de la informática e inteligencia artificial definiendo formalmente  conceptos como algoritmo y computación utilizando para ello lo que se conoce como Máquina de Tuning. Todo informático que haya pasado por la Universidad seguro que ha oído hablar de él ya que su Máquina es objetivo de estudio en varias asignaturas.

Como matemático Inglés participó activamente en la Segunda Guerra Mundial realizando un gran trabajo de criptoanálisis en el centro de Bletchley Park, donde tuvo un papel decisivo en el análisis de mensajes de Enigma, el sistema utilizado por los alemanes para sus comunicaciones.

Este año, en el que se cumplen 100 años de su nacimiento, se le rinde homenaje con diferentes actos que tendrán lugar en diferentes puntos de mundo. Podéis encontrar mas información en la web oficial.

Han pasado ya dos semanas desde que empezamos el Grupo de Estudio de JavaScript y no puedo estar mas contento por la buena acogida que ha tenido y la gran participación. Personalmente estoy aprendiendo mucho de este “desconocido” lenguaje.

Para la tercera reunión, el bueno de Enrique Amodeo nos ha propuesto un sencillo ejercicio para trabajar algunos de los aspectos que hemos ido viendo. Como ya no se empezar a programar si no tengo un test que falle, me vi en la obligación de buscar alguna forma de hacer TDD en JavaScript. Hay muchos y muy buenos frameworks de testing para JavaScript pero, dada la sencillez del ejercicio me parecía demasiado utilizar una librería específica.

Así que después de leerme el  artículo de Carlos Benitez sobre la consola de Firebug decidí que esta sería mi “herramienta de TDD” para este ejercicio.

Aquí os dejo los test que deberéis ejecutar junto con el código de la solución en la consola de Firebug. No he guardado los “baby steps” que fui dando pero siempre partí de un test que fallaba antes de implementar nada de código.

Código de los test:

// TEST for execute into a Firebug console
// TEST for execute into a Firebug console

console.group("Anything is a param")
    console.assert("" == concatenate(3),"When param is 3, Then returns ''");
    console.assert("" == concatenate(3.2),"When param is 3.2, Then returns ''");
    console.assert("" == concatenate("hola"),"When param is 'hola', Then returns ''");
    console.assert("" == concatenate(function(){}),"When param is function(){}, Then returns ''");
console.groupEnd();

console.group("There isn't elements");
    console.assert("" === concatenate(),"When param is , Then returns ''");
    console.assert("" === concatenate([]),"When param is [],Then returns ''");
console.groupEnd();

console.group("Array with strings");
    console.assert("hola" === concatenate(["hola"]),"When param is ['hola'], Then returns 'hola'");
    console.assert("hola,que,tal" === concatenate(["hola","que","tal"]),"When param is ['hola','que','tal'], Then returns 'hola,que,tal'");
	console.groupEnd();

console.group("Array with array elements");
     console.assert("" === concatenate([[]]),"When param is [[]], Then returns '' ");
     console.assert("hola" === concatenate([["hola"]]),"When param is [['hola']], Then returns 'hola'");
     console.assert("hola,soy,luis" === concatenate([["hola","soy","luis"]]),"When param is [['hola','soy','luis']], Then returns 'hola,soy,luis'");
console.groupEnd();

console.group("Array with array and string elements");
      console.assert("hola,soy,luis" === concatenate(["hola",["soy","luis"]]),"When param is ['hola',['soy','luis']], Then returns 'hola,soy,luis'");
      console.assert("hola,soy,luis,y,estoy,bien" === concatenate(["hola",["soy","luis"],"y","estoy","bien"]),"When param is  ['hola',['soy','luis'],'y','estoy','bien'], Then returns 'hola,soy,luis,y,estoy,bien'");
console.groupEnd();

console.group("Array with arrays of arrays and string elements");
    console.assert("hola,soy,juan,fernandez,y,no,tengo,dinero" === concatenate(["hola", ["soy", ["juan", "fernandez"] ], "y", ["no", "tengo", ["dinero"] ] ]),"When param is ['hola', ['soy', ['juan', 'fernandez'] ], 'y', ['no', 'tengo', ['dinero'] ] ], Then returns 'hola,soy,juan,fernandez,y,no,tengo,dinero'");
console.groupEnd();

Código JavaScript resultante:

var concatenate = (function(){
//Private properties
var params;

function hasElements(){
return params.length>0;
}

function createString(){
var res = "";
for(var i=0;i<params.length;i++){
res += params[i];
if(isLastParam(i)){
res+=",";
}
}
return res;
}
function isLastParam(p1){
return (p1<params.length-1);
}

//Public
return function (parameters){
var result = "";
params = parameters &amp;amp parameters.isArray()?parameters:[ ];

if(hasElements()){
result = createString();
}
return result;
}
})();

Aquí tenéis el código con alguna prueba mas en mi GitHub.

Conclusiones

Mi conclusión es que a veces no es necesario buscar herramientas potentes para solucionar problemas sencillos. Lo que nunca deberemos olvidar es nuestra manera de trabajar, que en mi caso es siempre ESCRIBIENDO PRIMERO LOS TEST.

Enlaces de interés

• Tenéis este excelente podcast de Carlos Blé y Guillermo Pascual donde se hablan de muchas de estas herramientas.
• Por si alguien ve un poco raro el código, simplemente he utilizado el patrón “Módulo” para simular los comportamientos público y privado en JavaScript.

La foto es de la primera reunión del grupo de JavaScript en Madrid On Rails

Disclaimer

La solución solo funciona en navegadores compatibles con ECMASCRIPT 5, en el código de GitHub podéis encontrar mas soluciones compatibles con todos los los estándares

Actualización: Aquí tenéis la web del grupo: https://gejs.jottit.com para consultar toda la información.

Parece que JavaScript está pegando fuerte. Ha dejado de ser ese lenguaje que nadie sabe muy bien como funciona y con el que validamos formularios y hacemos algún efectito chulo, para pasar a ser un lenguaje en el que se basa el último estándar de la web como es HTML5. David Bonilla lo explica muy bien en uno de sus últimos post donde habla de porqué quiere aprender JavaScript.

El hecho es que ni siquiera había leido el artículo de David cuando pasó por mi cabeza la idea de montar un grupo de estudio de este lenguaje. Después de hacer el anuncio por Twitter para ver un poco si sería de interés, me encontré con una gran acogida y sobre todo con algunas preguntas que contestar. Así que allá vamos, voy a intentar explicar lo que desde mi punto de vista espero del grupo de estudio:

¿Qué es un grupo de estudio?

Simplemente un grupo de personas que deciden juntarse para estudiar un tema común. Ya existen otros grupos de estudio que se reúnen para estudiar patrones o diferentes lenguajes. Lo que tiene que quedar claro es que es un grupo de ESTUDIO, es decir, exige justamente eso estudio. Es algo que debes tener presente antes de decidir asistir.

¿Por qué montar un grupo de estudio?

Porque estudiar algo uno solo es lento y tedioso y muchas veces acabamos por abandonar. Lo que pretendo con este grupo es intentar que entre todos aprendamos desde cero este lenguaje.

Dinámica del grupo

Después de consultar con varias personas que han participado en grupo similares he llegado a la conclusión de que me gustaría que el grupo de estudio tuviera las siguientes características:

• Partir desde cero. Se trata de aprender el lenguaje y que mejor que empezar por los fundamentos del mismo. Así cualquiera que quiera unirse podrá hacerlo.
• Una reunión a la semana de 2 horas máximo puede ser mas que suficiente. Cada una de ellas intentaríamos ver un tema diferente.
• Grupo público. Esto quiere decir que no vamos a crear una lista de correo o algo similar. Cualquiera que tenga una duda que lo exponga públicamente bien por Twitter, Blogs, Github pero que cualquiera pueda consultarlo en cualquier momento. Así conseguiremos que no haga falta asistir presencialmente para poder aprovechar todo lo que hagamos.
• Trabajar durante la semana en los ejercicios propuestos para a la semana siguiente poder sacar conclusiones y avanzar mas rápido.

Temario

Los grupos de estudio que conozco se reúnen con un libro como punto de partida. Aquí se nos plantea el problema de que hay muchos libros. Quizás sea interesante ir cogiendo capítulos de diferentes libros para ir completando un temario ideal. A mi personalmente creo que me gustaría tratar:

A partir de aquí podemos llegar hasta donde nosotros mismos queramos y explorar todos los aspectos del lenguaje que considere el grupo.

Lugar

Todavía no tenemos lugar para reunirnos. Me gustaría que por lo menos la primera reunión contar con un proyector para ver código y ver los conceptos fundamentales. Ya tenemos sitio.El resto de reuniones podemos ir viendo en función de la afluencia de gente.

También hay gente de fuera de Madrid que se ha interesado en participar. Vamos a ver si podemos grabar las reuniones o por lo menos capturar la pantalla para que no perdáis detalle de lo que hablemos.

Este es mi planteamiento inicial. Cualquier sugerencia será bienvenida.

Ahora solo falta concretar una fecha y un lugar. Me ofrezco voluntario para dirigir la primera reunión y hacer una exposición del primer tema, aunque espero que sea participativo y entre todos vayamos avanzando.

Por último agradecer a @plagelao por sus sugerencias. Podéis consultar sus post sobre dos grupos de estudio en los que ha participado:

- Grupo de estudio de SICP

- Grupo de estudio del libro 7 languages in 7 weeks

Última actualización:

Aquí tenéis todos los detalles del grupo: https://gejs.jottit.com

Este año en Pamplona, en las excelentes instalaciones del CEIN, se ha celebrado el Tercer Open Space, el AOS2011.

Tablero con todas las sesiones

Asistí a las siguientes sesiones:

• Retrospectivas con @joserra_biko
• Ecosistema Ruby para no Rubistas con @amuino.
• Ejemplos de implantación de metodologías ágiles.
• User Stories (Marco de Biko)
• Rompe la rutina con @kinisoftware

No voy a hacer un resumen de las sesiones en las que estuve ya que podéis encontrar varios post que cubren prácticamente todas.

La idea de este post (de ahí el título) es contar el AOS desde un punto de vista mas personal.

Reflexiones personales

Tercer Open Space al que asisto y distintas sensaciones al finalizar cada uno de ellos:

• El primero fue en Madrid, el AOS de las inquietudes, las ganas, la curiosidad.
• El segundo en Barcelona, el AOS de la confirmación de que algo había empezado.
• El tercero, el de la consolidación, constatación de que algo está cambiando, es una realidad el movimiento.

He notado mucha mas gente hablando de cosas sentidas y vividas en primera persona. Esto del agilismo no es una utopía, ni una moda, ni algo que solo la gente “de fuera” puede hacer. Ya hay muchas empresas (pocas todavía seamos realistas) y muchos profesionales (un porcentaje bajo en comparación con todos los profesionales que la formamos) que practican y usan todo lo relativo al mundo agile. Unos hacen Scrum, otros Kanban, otros simplemente conocen TDD y están esperando el momento donde utilizarlo, o quizás algunos se han animado a instalar un servidor de Integración continua pero poco a poco, entre todos, vamos asimilando el cambio de cultura que implica pasar del mundo tradicional al ágil.

La mejora continua, las ganas de seguir avanzando es algo que se palpó en todo momento, bien con algunas sesiones específicas o bien por los comentarios de pasillo. No quiero pecar de optimista, esto sigue evolucionando y todavía falta mucho. Solo hemos andado un paso mas del largo camino para mejorar nuestra profesión.

Nuevas iniciativas como el Intership propuesto por  @hell03610, que pretende crear una red de intercambios de profesionales que fomenten las experiencias en diferentes ambientes, constantan el nivel de madurez que vamos adquiriendo. Grupos locales como el de Navarra surgen y movimiento y mas movimiento en el resto de España.

Mi pequeña aportación

Pizarra final de la charla sobre el Talento

En lo personal, este año quería avanzar, quería participar de alguna forma, poner mi pequeño granito de arena. Así que junto con Raquel Laina (@rlaina) nos animamos a presentar una sesión. Nada técnico, quería huir un poco de ese perfil. No por nada en concreto, simplemente quería probarme en otros temas que nada tuvieran que ver con lo que hago todos los días en mi trabajo.

Después de varios mails semanas antes del AOS decidimos hacer una sesión que hablase sobre el talento. ¿Por qué? Porque es algo que me interesa mucho. Siempre me gusta estar rodeado de talento, aprender de los mejores. Eso me causa preocupación ya que no es fácil encontrarlo y retenerlo.

Los puntos que tratamos fueron:

• Definición del talento
• ¿Necesitamos talento?. EL TALENTO NUNCA ES SUFICIENTE
• Identificación del talento interno. OBSERVA A TU ALREDEDOR, ESTÁ MAS CERCA DE LO QUE PIENSAS.
• Búsqueda del talento externo. SE ATRACTIVO
• Conserva el talento que ya tienes. RETOS

Teníamos algún punto mas pero no dio tiempo. La gente participó bastante y salieron varias ideas interesantes (proceso de Tuenti, Facebook)…Os dejo una foto de la pizarra con todas las ideas que fueron saliendo.

¿Qué me llevo del AOS?

• Acciones concretas. El lunes puse en práctica parte de lo aprendido con @joserra_biko en su taller de Retrospectivas.

En el taller de Retrospectivas (Cortesía de @amaliahern)

• Ideas del taller de @kinisoftware “Rompe la rutina”…algunas cosas las pondremos en práctica dentro de poco.

• Un libro, el Agile Coaching de Rachel Davids y Liz Sedley (cortesía de @pepellou. Gracias).

• Conversaciones de pasillo, cervezas ágiles y buena gente. He conocido en persona a cracks como @Programania, @iceoverflow, @mariotux, @pepellou y todo AGIL-AZ y muchos mas que ni siquiera recuerdo su nombre.

• Me voy con la sensación de que todavía hace falta implicar mas a las empresas, los clientes, los compañeros para darles a conocer todas nuestras ideas.

Conclusiones

El agilismo está aquí y ha venido para quedarse. Cada año aumenta el número de empresas / equipos / personas que comprenden sus beneficios y deciden dar el salto hacia su implantación. Este tipo de eventos crean comunidad y propician que las comunidades locales se animen y generen mas y mas eventos.

Si aún no lo tienes claro te invito a que visites la web Agile Spain y su lista de correo. Hay un montón de gente encantada de resolver cualquier duda.

Enlaces relacionados

Podéis encontrar varios resúmenes y fotografías en el site oficial del evento.

También Carlos Blé (@carlosble) grabó un podcast con algunas de las personas que participamos en el evento. Puedes escuchar a Vicenç García (@vgaltes), Rubén Bernárdez (@rubenbpv), Rodrigo Corral (@r_corral) Jorge Uriarte (@jorgeuriarte), José Ramón Díaz (@joserra_biko), José Manuel Beas (@jmbeas) y yo mismo (@ialcazar)