Plant the code seeds in the spring

El pasado 14 de abril fui invitado por l@s chic@s de Cylicon Valley para dar una charla relacionada con el movimiento Agile. Creo que el 2012 va ha ser clave en España para todo lo relativo a este tema. Va a ser el año de la consagración o de la debacle total quien sabe, pero si es cierto que la gente ya no se muestra indiferente al movimiento. En mi día a día, son muchas las personas / clientes / empresas que me preguntan y quieren saber mas y eso es bueno porque, por lo menos, indica curiosidad y ganas por saber.

Desde mi punto de vista de los últimos 3 años dedicado a este tema, creo que hay mucho misticismo y falsas concepciones. Con esta charla pretendía romper algunos falsos pensamientos, mitos y leyendas urbanas sobre el agilismo. Incluso, me he enterado hace poco que hay una corriente bautizada como “post-agile” que mas o menos pretende quedarse con la esencia del movimiento y no caer en todas estas falsas concepciones que podemos tener. Me quedo con la idea de que la gente está madurando las ideas. En España apenas está comenzando todo esto, como para plantearnos algo de “post-agile” :-).

Respecto a la charla, la aderecé con una serie de dinámicas con las que intenté que los asistentes interiorizaran algunos conceptos planteados. Por el feedback recibido, tanto en persona como por Twitter, parece que gustó bastante este formado así que habrá que repetirlo en algún otro momento.

Hace unos meses (muchos si) organizamos una charla relacionada con los gobiernos abiertos y el open data que magistralmente impartió Alberto Gómez Toribio. Aunque con un poco de retraso aquí os dejamos el material y las transparencias que utilizó.

• Video de la charla: http://vimeo.com/35306539
• Código de la aplicación que hizó: https://github.com/gotoalberto/TrenConRetraso/tree/OpenData18E
• Transparencias: http://www.slideshare.net/gotoalberto/opendata18e

Agradecemos a Alberto todo el esfuerzo realizado y a la Sala Camón por permitirnos organizarlo allí.

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