En medio de toda esta vorágine es difícil no dejarse llevar por la desesperación y el desánimo de verlo todo perdido y querer huir, ¡sálvese quien pueda! ¡vayámonos a otra parte de Europa que en Alemania o Inglaterra estas cosas no pasan! Que conste que en ningún momento pretendo criticar a aquellos que toman la decisión de marcharse ya que creo que se necesita valor para tomarla, pero da pena pensar que sea la única alternativa para no hundirse en este barco.

Pero toda acción tiene su reacción, y la reacción de la gente a todo esto ha sido inmediata. Las calles de Madrid y por lo que he podido leer por twitter las de otras muchas ciudades se han llenado de gente que ha salido a la calle a protestar. Pero las manifestaciones y este tipo de cosas debo decir que no encajan con mi forma de ver las cosas porque aunque se muestra el descontento, la mayoría de las veces no permite que se planteen soluciones y sin ellas, no arreglamos nada.

Pero como Ghandi dijo: “Sé el cambio que quieres ver en el mundo”. Por eso, desde que leí este post de Agustín Cuenca llevaba pensando que yo también tenía que cambiar mi actitud y buscar una forma de ayudar y gracias al empujón que nos ha dado Javier Ramírez que ha sido el promotor y craedor de la idea ha salido a la luz esto:  http://javier-ramirez.com/curso-gratuito-solidario-ruby-on-rails.html

Lo que queremos hacer es simplemente donar nuestro tiempo libre y esfuerzo a intentar ayudar a alguna gente a la que quizás tras introducirla en el mundo de Ruby on Rails (que sabemos que actualmente tiene bastante demanda) le pueda ser más fácil encontrar un trabajo. Esta es una iniciativa personal de Javi que ha compartido con sus compañeros de trabajo porque dada la temática ha considerado que podíamos serle de ayuda y nosotros hemos recogido el guante encantados, pero detrás de ella no se esconde ningún afán comercial.

De momento parece que la idea ha gustado mucho y realmente espero que todo esto sirva para algo porque ser de ayuda puede ser tan sencillo como compartir las cosas que sabes hacer, así que espero que ya te estés preguntando: Y yo, ¿con qué puedo ayudar?

Empezamos con un breve repaso histórico a las herramientas de “build”.

Partimos en el año 2000 cuando fue lanzado Apache Ant, una herramienta donde prima la configuración sobre la convención, basado en xml y en general muy verbosa aunque también muy flexible pero sin gestión de dependencias.

A continuación llegamos a Maven, justo al contrario, un modelo de convención sobre configuración, también basado en xml aunque menos verboso y con el avance en la gestión de dependencias, aunque es menos flexible.

Y aterrizamos por fin en Gradle. Una herramienta de construcción de software que combina la flexibilidad de Ant con las convenciones de Maven. En ella podemos utilizar Groovy a través de un DSL y crear tareas sin descuidar la convención. El uso de Groovy nos permite reducir el número de líneas de código y además, al ser código, puedes hacer cosas como trazar, testear, etc.

Y una vez presentados a los contrincantes, pasamos al combate Maven vs Gradle:

Round 1: Xml vs código

Mientras Maven se basa en xml y siempre tienes que escribir una serie de etiquetas para realizar ciertas tareas, Gradle te permite hacer lo mismo pero con código.

Round 2: Convención sobre configuración.

Aunque ambos parten de convenciones, Gradle permite extender la convención con Ant, Groovy, tipos, orden por dependencia entre tareas(no dependiendo del ciclo de vida como en Maven).

Round 3: Ciclo de vida

El ciclo de vida de Maven tiene muchas etapas: validate, compile, test, package, integration-test, verify, install, deploy… mientras que el ciclo de vida de Gradle sólo tiene 3 fases: inicialización, configuración y ejecución.

Round 4: Scripting

Realizar scriping en maven es un infierno y si quieres utilizarlo acabas embebiendo código en el xml. Sin embargo, en Gradle, el propio script es código con lo que puedes importar plugins o clases de utilidad ya creadas.

Round 5: Dependencias

Maven es la referencia en la gestión/distribución de dependencias y por ello Gradle delega en Maven/Ivy para gestionarlas, aunque hay que tener cuidado porque cambia la nomenclatura de los ámbitos.

Round 6: Soporte IDE

Maven ha ido añadiendo soporte para entornos como Nerbeans, Eclipse e IntelliJ y Gradle, a pesar de su corta vida, tiene ya soporte para Netbeans (aunque limitado), para Eclipse (STS) y también para IntelliJ.

Round 7: Multiproyecto

Mientas que en Maven se declara un pom.xml padre con los hijos y se hereda tanto la configuración como las propiedades, en Gradle se separa la declaración de hijos de las configuraciones de herencia.

Viendo este enfrentamiento coincido con las conclusiones de Mario de que Gradle tiene grandes ventajas y creo que puede ser una herramienta muy potente y de la que se puede sacar mucho provecho, así que espero tener más tiempo para profundizar en ella y mientras tanto agradezco a Mario que se haya preparado esta estupenda introducción.

Gracias a @albertovilches podéis ver el vídeo entero de la charla en estos enlaces:

El sitio en el que se ha realizado, la Escuela Universitaria de Informática de la Universidad Politécnica de Madrid, creo que era bastante bueno porque aunque un poco alejado del centro tiene buena comunicación por metro, cercanías y bastante aparcamiento si vas en coche, algo importante si tienes previsto juntar a más de 1000 personas en un evento.

Aunque para algunas personas tener tanto donde elegir es un problema porque puedes perderte muchas cosas, a mí me parece un acierto que se propusieran tantos tracks (7 más un taller a algunas horas) porque así es más difícil que en algún momento no haya ninguna charla a la que te apetezca entrar. Yo organicé mi día intentando asistir a charlas enfocadas a HTML 5 y desarrollo para móviles ya que me gustaría meterme más a fondo con ello. Lástima que no todas las charlas se pudieran grabar y hubo alguna que me perdí porque el aforo del aula ya estaba sobrepasado con creces.

Me chocó un poco la forma un poco impersonal en que vi a gente tratar la oportunidad de hacer llegar tu currículum a las empresas patrocinadoras (Oracle, Microsoft, Medianet, Atlassian, Bq, VILT, Coritel, Extrema, IBM, Tuenti, Paradigma, Amazon, Telefónica y Mozilla) dejando únicamente una hoja de papel en una caja sin intercambiar ni una palabra con los representantes de las empresas que estaban allí.

En esta ocasión no voy a detallar las distintas charlas a las que asistí, quizás cuando tenga más tiempo y me ponga a llevarlas a la práctica voy creando entradas más cortas en las que entre más en materia, sólo quería resumir un poco mi experiencia y animar a quien se lo perdió a que vaya la próxima vez aunque esta sé de buena tinta de gente que hizo un gran esfuerzo por acudir, como la gente de la Universidad de Córdoba que salió de Córdoba a las 2:30h en autobús rumbo a Madrid y tras el evento vuelta a Córdoba, ¡eso sí que son ganas!

Lo primero a tener en cuenta es que no fue una charla como tal, casi se podría decir que como no había demasiado tiempo pasamos directamente al turno de preguntas, ya que al inicio de la charla nos solicitó a los asistentes que le propusiéramos las preguntas que queríamos que él contestara para así poder centrarse en nuestras inquietudes. Y estas fueron las preguntas que se propusieron y las respuestas dadas:

¿Cuándo es el momento de ir a ver a un inversor?

Hay distintos tipos de inversores para las distintas etapas de un proyecto. Cuando se tiene hecho el plan de negocio y se tiene montado un equipo es el momento de ir a hablar con un Business Angel, antes de eso, para conseguir algo de dinero es mejor acudir a FFF (Family, friends or fools) porque hasta que la idea no está cuajada en un plan de negocio no se puede evaluar. Cuando ya tienes capital vas al venture capital o capital de riesgo y cuando tienes beneficios con otro. En cada etapa tienes que ir a hablar con un inversor porque dependiendo del inversor te preguntará distintas cosas sobre el estado del proyecto y es importante que cuando hables con un inversor sepas contestar a las preguntas que él te haga.

¿Qué se puede esperar de un inversor?

El inversor sólo debe aportar dinero, porque participa en muchos proyecto a la vez y no puede estar presente en cada uno de ellos. De él solo cabe aportar dinero. El inversor pone dinero y el emprendedor “curra” y luego le devuelve el dinero multiplicado al inversor pero el inversor no añade valor, captura valor.

¿Qué espera sacar el inversor de un proyecto?

Tiene que multiplicar por 10 o por 20 su inversión. Porque si de cada 10, 9 le salen mal, necesita cubrir con el que sale bien las pérdidas de los restantes. Para que un negocio sea invertible tiene que tener un potencial increíble, que no es lo mismo que un negocio viable.

¿En cuánto tiempo espera el inversor el retorno?

Entre 6 y 7 años.

¿En qué se fija un inversor?

Hay algunos que son intuitivos simplemente. Hay otros que son sistemáticos. Evalúan un proyecto de internet igual que un bono de inversión. Su modelo es  una ecuación racional y sistemática en la que el emprendedor no importa, importan únicamente 6 variables.

1. Viable: Si tiene un mercado(clientes, pero clientes con nombres y apellidos identificando así quiénes abren la cartera) clave.
2. Ventaja competitiva clara: No hay nada más peligroso que decirle a un inversor que no tienes competencia porque seguro que esa idea se le ha ocurrido a alguien y el inversor puede pensar que no tienes ni idea del mercado en el que estás. Aunque a veces puede que sea verdad, pero el inversor prefiere negocios donde sí hay competencia. No puedes tampoco decirle al inversor que es que los grandes son tontos y no saben aprovechar el mercado.
3. Factible: Lo puedes hacer con el equipo que tienes y ahora. Se necesita un equipo multidisciplinar y complementario.
4. Hay que explicar por qué es el momento de hacer tu idea “ahora”. ¿Qué ha cambiado para que se haga posible algo que antes no era?
5. Invertible: Tiene que ser escalable, muy escalable.
6. Salida: El dinero entra ahí para salir. La salida es cómo se traduce a euros el valor que se va a invertir.

El estereotipo de emprendedor lo tienen tanto los buenos como los que han fracasado, por eso no sirve como criterio para decidir sobre la inversión, sino solo se invertiría sobre consultores. Lo ideal sería poder hacer una evaluación del proyecto sin dejarte influir por la impresión que te dan las personas, ya que quien te lo presente puede que haya tenido un mal día.

¿Hasta cuándo está el inversor?

Todo inversor en cuanto entra está deseando salirse. Lo normal es que el inversor no tenga interés en dedicarle ni un minuto al proyecto y menos interés aún en controlarlo. Si el proyecto no funciona, no vale la pena que el inversor dedique su dinero y el emprendedor su tiempo.

¿Por qué las empresas cuanto más crecen más dinero necesitan?

Porque lo que más cuesta es crecer.

En estos momentos hay dinero para financiar el crecimiento muy rápido. Cuando se ve que un proyecto puede escalar y se puede replicar muy rápido los inversores están deseando darle dinero.

¿Negocios, tendencias o modas?

 El inversor no tiene ni idea, eso es cosa del emprendedor. Lo bonito de este negocio es que es imprevisible, no se trata de anticiparse, sino de intentar navegarlas.

¿Idea o equipo?

Es como en la fórmula 1, ¿qué es más importante el coche o el piloto? Aunque el emprendedor haga mucho, si el modelo (que no la idea) no vale, no tiene salida. Y de igual forma, si la idea vale, pero no tiene el equipo para realizarla, tampoco va a salir adelante.

¿Concepto o números?

Un concepto sin números es como una visión, algo que un inversor no entiende. No quiere decir que haya que traer muchos números y traer muchas hojas de Excel, pero es importante la cuenta de la vieja: ¿por qué es un buen negocio? ¿por qué vale la pena invertir?¿dónde está el multiplicador del dinero? Es mejor primero probar en pequeñito el modelo y luego cuando se vea que funciona lo haces crecer.

¿Se puede empezar con 18000 euros?

Sí, es un momento increíble para emprender porque para testar un modelo y ver si es bueno muchas veces basta con ese dinero.

Y eso fue todo lo que le dio tiempo a contar, ¡que no fue poco!

Para mí que estoy un poco verde en estos temas me resultó una charla muy útil y me aclaró muchos conceptos que espero recordar y tener presentes si algún día mi musa quiere que se me ocurra una buena idea sobre la que montar un negocio .

El encargado de inaugurar esa iniciativa fue Alberto Vilches, que tuvo la difícil labor de vender Groovy y Grails a unos desarrolladores Java algo reacios a cambiar (¡o que se hacían los reacios a cambiar para ponérselo difícil a Alberto!).

Hubo gente que siguió en directo la charla a través de una página que se habilitó a tal efecto, e incluso algunos hicieron preguntas a distancia para que David Bonilla las retransmitiera. Pero si te lo perdiste no te preocupes, puedes encontrar el vídeo aquí. Apenas le faltan cinco minutillos que se perdieron por los nervios del directo y de la primera vez.

Albertó empezó a contarnos cómo era su relación con Java y cómo su paso a Groovy.

Lo que nos contó fue que de Java les gusta su sintaxis de estilo C pero sin punteros y con recolector de basura, también que es multiplataforma y ser un lenguaje orientado a objetos. Para desarrollo de aplicaciones web en Java se tienen Servlets, JSP, JDBC… y muchas otras herramientas que hacen que sea un lenguaje bueno para la web. Además, más adelante empezaron a aparecer muchos patrones y muchas cosas en J2EE que hacían la vida más fácil, pero que a veces ofrecían soluciones a problemas que no tenían, introduciendo complejidad y se dependía demasiado del IDE que se utilizara para desarrollar. Para esos temas el OpenSource aportó muchas soluciones (Maven, Ant, Hibernate, Struts, Spring) pero el desarrollo seguía sin ser demasiado rápido.

Así que se necesitaba una solución que permitiera hacer desarrollos RAD, había que hacer aplicaciones y hacerlas ya, y Grails nació en este contexto para cubrir el hueco que Java dejaba sin cubrir, el desarrollo RAD en Java, desarrollando aplicaciones utilizando la máquina virtual.

Grails utiliza como lenguaje principal Groovy, aunque también puedes utilizar clases Java, utiliza herramientas para el patrón MVC como Spring MVC, sus vistas en lugar de estar en ficheros JSP están en ficheros GSP (aunque también podemos utilizar ficheros JSP), tiene herramientas de testing y es muy extensible con plugins. Además es más divertido que Java porque como tienes que escribir menos código le dedicas menos tiempo a escribir código y más tiempo a pensar en los problemas del negocio, y también al haber menos líneas de código las posibilidades de cometer un error y las líneas a revisar cuando se produce uno son menos.

Alberto nos contó la estructura de una aplicación Grails, puesto que se basa en convención sobre configuración: sus controladores, sus servicios, sus vistas y sus clases de dominio y nos hizo algunos ejemplos para que viéramos los distintos elementos en acción.

Y durante la charla se plantearon algunas preguntas bastante interesantes:

- ¿Qué otras opciones se pueden encontrar para el desarrollo de aplicaciones rápidas en Java? Según Alberto lo más parecido que existe es el framework Play que incluye muchas de las cosas que aporta Grails y lo siguiente más parecido Spring Roo, que te permite generar la estructura del proyecto, pero en su opinión ninguna es tan buena como Grails ni puede competir con él en velocidad de desarrollo.

- ¿No dificulta encontrar los errores que sea dinámico? Ciertamente puede dificultar encontrar algunos errores y por ello es realmente importante hacer muchas pruebas unitarias, ya que los lenguajes dinámicos te obligan a ser más disciplinado en ese tema. Y si tienes una aplicación muy mal hecha y sin tests, es mejor rehacerla ya que puedes tener serios problemas.

- ¿Se puede luchar contra el modelo anémico en Grails? Su respuesta fue que no hay ningún problema puesto que puedes añadirle a las clases del modelo cualquier método, aunque me hubiera gustado discutir más sobre ese tema porque creo que tiene bastante más miga, no sólo por los métodos que puedas crear, sino por poder delegar en colaboradores que le puedas inyectar. Espero tener la oportunidad de profundizar más en este tema ya que es algo a lo que me estoy enfrentando ahora y no tengo del todo claro cómo tratar.

- ¿Grails o Rails? La ventaja que tiene Grails frente a Rails es que corre sobre la máquina virtual de Java y te puedes aprovechar de la gran comunidad que tiene detrás, además de que la curva de aprendizaje viniendo de Java es menor.

A mí me pareció una charla estupenda y de la que pude sacar algunos puntos en claro que me vienen muy bien para el trabajo que tengo que hacer en Wiseri. El formato se irá refinando poco a poco para intentar hacerlo más colaborativo, pero dado el caracter introductorio que tenía esta charla creo que no había mucho margen de colaboración a parte de ir viendo de forma práctica las cosas y el ir introduciendo las preguntas tanto de los asistentes presenciales como de los asistentes virtuales ¡que en algunos momentos llegaron a ser 22!

Es de agradecer que se hagan cosas de este estilo y también el estupendo catering que tuvimos gracias a SixServix y que nos sirvió de comida y de merienda post-charla. Espero poder asistir a otras, ¡aunque intentaré no acaparar siempre una plaza para mí!

Debo decir que al principio dudé de si apuntarme puesto que mi perfil es técnico, pero sentía una cierta curiosidad por esto del coaching y la gestión de equipos, así que al final me animé, ¡y me alegro de haberlo hecho!

Como en todo Open, el viernes, tras una presentación de Raquel Laina (@rlaina) y Rachel Davies(@rachelcdavies), que fueron unas grandes anfitrionas del evento, empezamos a proponer los temas para las sesiones del sábado.

En esta ocasión sí que me animé a plantear una sesión, quería que la agente me ayudara a definir qué es un coach y cuáles son sus tareas, y como Rodrigo Corral(@r_corral) y Roberto Canales(@rcanales) tenían dudas parecidas ya que se planteaban también qué es un coach y qué no y si los coach son psicólogos, decidimos juntarlas todas en una misma sesión.

El tablón quedó definido y preparado, aunque iría sufriendo algunas modificaciones durante el día siguiente.

Había cuatro salas y daba tiempo a cuatro sesiones por la mañana y tres por la tarde, pero al final como no salían más sesiones decidimos dejar la última hora libre para que así la gente que venía de fuera y tenía que volverse el sábado a casa pudiera irse antes.

También aproveché para hacerle una foto a los principios de los Open Space ya que teniéndolos en cuenta es como se saca más partido a este tipo de eventos.

El sábado llegamos con muchas ganas, aunque con algo de sueño, pero con ayuda del café, el té, el zumo y los pastelitos varios que nos estaban esperando a nuestra llegada nos pusimos las pilas enseguida, ¡listos para comenzar con las sesiones!

Circle of 7, de Adrián Silva (@scyldinga)

Adrián empezó introduciéndonos qué era eso del Círculo de 7, un grupo de mujeres que se unió para buscar formas de ayudar a otras mujeres, un ejemplo de círculo de apoyo. Aquí hay una entrevista en la que cuentan mucho sobre ellas. La idea de Adrián era presentar ese círculo y plantear que quizás podría existir algo así para que las personas que se dediquen al coaching puedan apoyarse en otras personas y consultar nuevas opiniones y puntos de vista sobre los problemas con los que se encuentran en su camino. Empezamos a discutir de que puede ser cierto que el coach a veces se sienta solo y necesite de alguien a su alrededor con quien poder contar para que le ayude, pero muchas veces no tiene a quien pedir ayuda u opinión o con quien compartir las alegrías de los éxitos. Enrique Comba(@ecomba) propuso que contáramos con gente que conozcamos para hablar con ellos, aunque no sean personas que estén cerca, para ello tenemos herramientas como Skype. Pero, aunque hables con una persona un rato, ¿es de utilidad esa charla?¿puede alguien aconsejarte sin tener la misma información que tú tienes de primera mano? Creo que sí, y muchos de los allí presentes también, porque si la técnica del patito de goma funciona en los programadores, ¿por qué no va a funcionar con los coach? Y si además se lo cuentas a otra persona, te puede contestar, cosa que espero no me haga nunca un patito de goma :p. Además, Roberto Canales también apuntó otro dato relacionado con la programación neurolingüística, y es que a veces ante un problema tú ya tienes una solución pensada, pero necesitas que alguien te la reafirme.

Así que vista la necesidad que tenemos de hablar con otras personas, Adrián comenzó a hacer una lista para que todo aquel que estuviera dispuesto a escuchar lo que alguien quisiera contarle se apuntara y yo ya dije que quien quiera puede contar conmigo, ¿se apunta alguien más?

¿Qué es un coach?¿Qué no es?¿Qué funciones tiene?¿Son psicólogos? Rodrigo Corral, Roberto Canales y yo.

Esta es la sesión que tenía en mente desde el principio, ya que era la información que quería obtener de este evento. La primera definición de un coach con la que empezamos fue que un coach es un Scrum Master poco involucrado, cuya misión es la de guiar en el camino pero sin ser miembro del equipo para de esta forma tener una visión desde fuera. Es alguien que hace de mentor. Un coach es la persona que sirve de motivación para que se adquieran compromisos que sin una motivación externa no se alcanzarían, tiene que transmitir entusiasmo y saber hacer llegar los principios ágiles consiguiendo hacer que la gente sea consciente de la necesidad del cambio, tiene que ser capaz de aportar soluciones a los problemas claros y conducir las discusiones en los problemas en los que sea necesario discutir y sobre todo tiene que ser una persona que haga una escucha activa de lo que le cuentan las personas a quienes tiene que ayudar.

Pero en una empresa existen casi siempre distintos niveles, y según el nivel en el que te encuentres posees mayor visión en anchura o mayor visión en profundidad de distintos temas (no es igual la perspectiva que tiene el director de la empresa que el jefe de un equipo). Ante esto surge una pregunta, ¿entonces puede una sola persona ayudar en todos los niveles? Mi conclusión después de todo lo que se estuvo hablando es que una sola persona no te vale para todo, que si alguien quiere un coach tiene que saber para qué lo quiere y buscar una persona con las cualidades que necesite, porque no es lo mismo aconsejar a un equipo de desarrollo que al director de la empresa.

Otra forma de hacer retrospectivas, Raquel Laina

Las retrospectivas son una parte importante del proceso seguido en metodologías ágiles ya que nos permite revisar el camino que estamos haciendo para descubrir qué estamos haciendo bien, y seguir haciéndolo, y qué es lo que está fallando, para poder corregirlo, sin embargo, el modelo ‘tradicional’ de retrospectiva de cosas buenas/malas/mejoras a veces se queda corto y no se le saca todo el partido que se podría a esa reunión.

Raquel nos contó que ya se había encontrado con ese problema y había empezado a buscar otras formas de hacer las retrospectivas que facilitaran la colaboración de los miembros del equipo. La primera opción que probó consistía en hacer reuniones para preguntar a a los miembros del equipo qué tal les había ido la semana, utilizando un pomodoro para que las reuniones no se hicieran demasiado largas, pero este método tampoco le permitió obtener la información necesaria para mejorar en el proceso. Lo siguiente que probó fue a ir haciendo mapas conceptuales con los problemas encontrados consiguiendo que el equipo los fuera diciendo en una tormenta de ideas. Los problemas obtenidos los relacionaban unos con otros y se agrupaban en bloques grandes para de esta forma tener una visión más clara del problema, así que este método le resultó mejor que los anteriores, pero quería saber qué otros métodos podíamos proponer para hacer retrospectivas de otra forma.

Una de las cosas que se dijeron y que me pareció muy importante es que puede ser bueno recordar en cada retrospectiva el por qué es tan importante esa reunión, que todo el mundo tenga presente que esa reunión no es para buscar culpables, sino para que el equipo pueda revisar y mejorar para la siguiente iteración.

¿Y cómo se consigue que la gente tenga presente las cosas que han ido mal a lo largo de esa iteración? Hay quien se va haciendo una lista en el momento en que ocurren las cosas y después cada uno puede llevar su lista a la retrospectiva, o también hay quien cada vez que algo va mal lo apunta en un post-it que coloca junto al tablón para seleccionar de ahí el día de la retrospectiva las cosas que hay que mejorar o también simplemente dejar al equipo reflexionar al principio de la reunión. Personalmente me gusta más la de los post-its porque así no dependes de que cada miembro del equipo se acuerde de hacer su lista y además están más presentes.

Ya hemos obtenido las cosas que han fallado y les hemos buscado posibles soluciones, ¿qué hacemos para que no caigan en el olvido? Para esto me encantó una solución que alguien dijo y que consistía en poner en el tablón las cosas que se habían seleccionado para mejorar de forma que si cualquier miembro del equipo veía que no se estaban cumpliendo pudiera decirlo en la reunión diaria porque teniéndolas bien visibles es más fácil que la gente las tenga en cuenta.

Así que salieron muchas ideas que son fácilmente aplicables para mejorar nuestras retrospectivas y sacarles el mayor partido.

Overcoming the dip, Enrique Comba

En esta charla Enrique nos dibujó una gráfica parecida a esta:

En ella se muestra cómo puede estar relacionada la productividad de un equipo en el proceso de aprendizaje. Cuando se parte de un punto, el inicio, se está acostumbrado a trabajar de una forma y cuando se empieza a aprender algo nuevo primero hay un período de un poco de caos, para pasar después a un período en el que el equipo empieza a producir menos, pero no porque las nuevas técnicas no funcionen, sino porque en el proceso de aprendizaje es normal que haya una época en la que las cosas van peor, hasta que poco a poco se va aprendiendo y muy lentamente se van produciendo mejoras hasta que se llega a la meta planteada. Ante este problema surgen muchas preguntas: ¿cómo consigues que la gente no corra de vuelta al punto inicial en cuanto noten que no están mejorando inicialmente sino empeorando?¿cómo vendes que después de llegar a la meta se necesita que pase un tiempo hasta que se recuperen las pérdidas producidas por el aprendizaje y solo después de ese período obtendrás beneficios?¿cómo convences de que dependiendo del estado en el que se encuentre el equipo puede no merecer la pena el cambio porque el coste va a ser tan grande que posiblemente no se recupere?

De todas esas preguntas la única para las que salieron respuestas fue a evitar que el equipo vuelva al punto de partida. Una de las posibles formas puede ser que haya alguien con peso en la empresa que se haga responsable de los problemas y que el equipo sepa que esa persona va a evitar que nadie les meta presión o les recrimine a ellos el ir más lento y también para evitar esa tentación de volver a lo seguro es necesario que los cambios sean graduales y poco a poco para que la curva sea un hueco pequeño y no un socavón insalvable.

¿Y cómo saber después del camino que has llegado a tu meta? Cuando usas la práctica a la que querías llegar cuando llegan los momentos de estrés.

Después de tanta charla el hambre ya empezaba a apretar, pero por suerte los organizadores se encargaron de prepararnos esta deliciosa comida que nos sirvió a todos para reponer fuerzas.

Y en el ratito que quedó después de comer mientras algunos fomentaban charlas espontáneas que surgían en distintas salas, otros aprovechaban para poner un poco de orden en las ideas recibidas en el día.

Pregunta de la felicidad o el milagro nocturno, Roberto Canales

Cuando Roberto propuso esta charla nos dejó bastante intrigados con qué era eso de la pregunta de la felicidad, ¡quién no iba a querer saberla! La idea se basa en inteligencia afirmativa, no fijándote en lo que está mal, sino en cómo solucionarlo. Por ello el milagro consiste en lo siguiente:

Imagínate que por la noche ocurre un milagro y que cuando te levantas por la mañana todos tus problemas han desaparecido y eres completamente feliz, ¿qué habría cambiado?

Él aseguraba haber podido aplicar este ‘milagro’ no solo al trabajo, sino también a su vida personal, porque una vez descubres las cosas que habrían cambiado al despertarte tu tarea es intentar pequeñas medidas para propiciar que esos cambios ocurran, de modo que con pequeños cambios llegues a ser más feliz. ¿No puede ser esta una buena forma de empezar a hacer coaching?

¡Animaos a hacer este milagro realidad vosotros también!

Agile Coach Dojo, Rachel Davies

En esta sesión lo que Rachel nos propuso era practicar, igual que se practica en los Coding Dojo, pero no a escribir código, sino técnicas de coaching. Para llevar a cabo esta tarea nos dividimos en dos grupos de cuatro y en cada grupos nos repartimos los siguientes roles:

• 2 coach
• 1 persona que necesita el coach
• 1 observador

La dinámica entonces consistía en que la persona que necesitaba coaching hablara con las personas que hacían el papel de coach y estas intentaran cumplir con su labor, mientras el observador únicamente atiende a cómo están realizando su labor para, al terminar el tiempo establecido, poder dar una visión externa de cómo ha visto que se han ido desarrollando las cosas. Después se rotan los papeles para que cada uno pueda estar en cada uno de ellos.

Para mí fue una actividad muy divertida y de la que aprendí mucho porque en la primera ronda me tocó hacer de coach y la verdad es que no sabía ni por donde empezar pero pude sacar muchas cosas en claro con las indicaciones que el observador me dio y con las impresiones que tuve yo al verme en los otros papeles. Si os interesa el tema y tenéis la oportunidad de juntaos unos pocos os animo a que lo probéis!

En la retrospectiva hicimos una ronda en la que cada uno de los asistentes contaba un poco sobre con qué idea venía y qué cosas se llevaba o qué cosas cambiaría y prácticamente lo único que algunas personas habrían cambiado habría sido que no hubiera tantos tracks, así que creo que se puede afirmar que fue un éxito.

Gracias a Eden Development, a Decide, Raquel Laina y Rachel Davies por este evento porque, aunque no me vaya a dedicar profesionalmente a ser únicamente un coach, para mí ha sido una gran oportunidad de aprender muchas cosas que sé que puedo aplicar en mi día a día para intentar que mejore el entorno en el que me encuentre, haciéndome más feliz a mí misma y a los de mi entorno.

La idea, si no me equivoco, surgió en la retrospectiva del AOS2010, donde una de las cosas que se dijo fue que se habían echado en falta temas técnicos y se pensó la idea de que quizás se podrían hacer más eventos de ese estilo sin necesidad de estar meses organizándolo ni pensarlo para que sea algo para 200 o 300 personas. Así que dicho y hecho, Jesús Jiménez se puso manos a la obra y demostró que no hace falta mucho para organizarlo, buscó un sitio en el que poder juntarnos y no se buscó ni patrocinadores ni nada, total, ¡qué son 15 euros para cada uno de nosotros!¡Gracias por el esfuerzo!

Fuimos llegando tempranito para poder aprovechar el día.

La asistencia no estuvo nada mal porque al final fuimos unos 50 asistentes y en cuanto estuvimos todos empezamos a proponer temas. En esta ocasión creo que estuvimos más moderados a la hora de proponer y no salieron demasiados temas, pero aún así hubo mucho donde elegir durante todo el día.

El tablón inicial quedó creado, pero como aún quedaban algunos huecos contando como sitios de reunión el pasillo, la cocina, la cafetería de al lado o cualquier otro sitio que se nos ocurriera se dejó abierto para que si a alguien se le ocurría algún tema nuevo fuera libre de añadirlo al tablón. Esta vez, guiados por el consejo de Enrique Comba, no hicimos ninguna votación ni nada para así empezar más rápido, simplemente pusimos todas las charlas que fueron saliendo en el tablón y si luego hacía falta cambiar alguna de sala por la afluencia de gente se cambiaba y punto.

¡Y comenzamos!

La primera charla en la que me metí se titulaba “Doctor, Doctor… Modelo Anémico” y había sido propuesta por Kinisoftware y Jacegu.

En ella inicialmente se dio una definición simple y directa sobre qué es un modelo anémico: tener objetos del dominio con únicamente métodos getters y setters, sin más lógica, únicamente contenedores de datos. Empezamos a discutir por qué este modelo de datos no es bueno y se mostraron unos cuantos argumentos:

• Te cargas la encapsulación (¿de qué te sirve tener las propiedades de esa clase privadas si realmente las estás haciendo públicas con los getters y setters?).
• Estás usando clases como estructuras.
• Estás creando una capa de contenedores de datos y otra capa para actuar sobre esos objetos, poniendo la lógica de negocio lejos de los datos.

¿Y qué tenemos que hacer para buscar tener un modelo bueno? Pues por ejemplo seguir los consejos del “Tell, Don’t Ask” y la Ley de Demeter para decir a los objetos que hagan cosas en lugar de preguntarle a los objetos por elementos de su estado interno.

Un ejemplo gracioso respecto a esto que propuso Alfredo Casado es que si vas a pagar la compra en una caja no le das al cajero tu cartera para que el cajero saque el dinero de ella, sino que le das directamente el dinero, de igual forma nuestros objetos debería encargarse de dar la información necesaria, no de dar otros elementos para que otro desde fuera sea quien tenga que obtener la información.

Respecto a esto alguien preguntó que por qué el getter era malo y la respuesta fue simple: el getter no es malo, lo malo es usarlo para exponer los atributos internos de una clase para que alguien desde fuera opere.

Pero un problema que nos encontramos cuando intentamos evitar modelos anémicos es que podemos acabar creando objetos demasiado grandes y con demasiada responsabilidad y la única solución que hay es estar en contacto con el cliente todo lo posible para encontrar un buen diseño del dominio y para ir buscando objetos pequeños que respondan a preguntas pequeñas en lugar de tener un objeto que responda a todas tus preguntas.

¡Es duro pero hay que intentar ponerlo en práctica!

La siguiente charla en la que estuve fue “Mockear” propuesta por Emma.

En esta charla partíamos de la pregunta de si era buena realizar tests con mocks o no. Al principio no entendimos bien de dónde surgía la duda hasta que empezamos a aclarar algunos términos y es que antes de pensar si mockear o no tuvimos que explicar un poco algunos términos de los distintos tipos de dobles de objetos que algunos no estábamos viendo como diferentes pero que en el planteamiento de la charla sí eran diferentes:

• Stub: Permite manejar los resultados esperados en las llamadas a un objeto.
• Mock: Doble de un objeto que permite definir las llamadas que se esperan se produzcan sobre el objeto. Se tienen que definir las llamadas esperadas antes de la llamada que se está probando y luego las verificaciones en la zona de comprobaciones. Además, si se realiza una llamada sobre el doble que no se encuentra definida entre las esperadas el test falla.
• Spy: Es el doble de un objeto que almacena las llamadas realizadas a métodos de este objeto para poder verificar en la zona de comprobaciones si se han realizado las llamadas deseadas. Cuando se producen llamadas a métodos no esperados no falla el test y si devuelve algo el método, se devuelve un valor por defecto(por ejemplo null).

¿Y cuándo usar cada uno? Pues todo depende del problema al que te enfrentes, si quieres probar a qué métodos se llama asegurándote de que no se produce ninguna llamada más de las que estás comprobando, si sólo quieres asegurarte de que una llamada se realiza sin importarte si se hacen más llamdas o si quieres asegurar que un objeto devuelva un resultado.

Además hay que tener en cuenta que en los tests con mocks, stubs o spies el test queda acoplado al código, ya que si cambian las llamadas que estás haciendo el test puede fallar. Por ello, estos objetos dobles pueden servir para diseñar el código y olvidarte de una parte con la que tienes que integrar el código y que no depende de ti, pero es peligroso usarlos sin control ya que puedes caer en crear demasiados colaboradores dentro del código.

También hay veces que te puede interesar no recurrir a estos dobles de objetos, sino crearte tú tu propio doble del objeto que quieras probar, incluso es una técnica necesaria cuando quieres probar algunos métodos que los dobles no te dejan como el “toString”.

Así que la conclusión de esta reunión yo creo que fue que tienes que usar cada herramienta cuando realmente la necesites, no usar una siempre por el hecho de haberla aprendido y también que el mejor momento para usar estos dobles es antes de hacer el código puesto que si los escribes después es muy posible que hagas un test totalmente acoplado al código escrito que replique las llamadas realizadas en el código.

La siguiente charla en la que me metí fue “Código Expresivo” propuesta también por Kinisoftware y Jacegu, que llevaban tiempo hablándolo con Alberto Peña a quien al final la gripe le tuvo en cama gran parte del día.

La idea de esta charla era hablar un poco sobre el Clean Code, un libro que muchos consideran que debería darse a un programador nada más aprender a programar.

Uno de los puntos importantes que se tratan es sobre el “naming”. Es importante enseñar a nombrar las cosas desde el principio ya que si no eres capaz de ponerle nombre a algo es porque realmente no sabes lo que hace.

Pero si estás implementando en una clase un patrón de diseño, ¿deberías indicarlo en el nombre de la clase? Aquí hubo algo de discusión, ya que aunque en el libro se hace, quizás puede llevar a poner nombres que no sean realmente significativos para el dominio.

¿Y cómo de largos deberían ser los nombres? Lo mejor es buscar un equilibrio entre la longitud del nombre y que sea suficientemente expresivo y sobre todo tener en cuenta que si aparecen cosas como “y” u “o” en los nombres hay que repartir responsabilidades. En el libro se autoimpone una restricción de 120 caracteres para evitar tener nombres demasiado largos que pasen a ser ilegibles.

¿Y cómo se manejan los distintos niveles de abstracción con la legibilidad del código en un lenguaje natural? Está claro que escribiendo código tiene que haber código y que hay partes del código que al final tienen que tener nuestros algoritmos, lo importante es que en cada nivel de abstracción tengas un nivel homogéneo de información de forma que que se pueda leer de forma horizontal y cuando un usuario que esté leyendo el código quiera más información sobre una parte en concreto pueda navegar de forma vertical para ir encontrando una información más específica. Por ejemplo no sería coherente un código que fuera:

if (x + y == 4 && esDivisiblePorDos(x))

También tuvimos mucho en lo que entrar en materia cuando empezamos a hablar sobre el tema de excepciones, las cuales siempre deberían usarse para tratar casos excepcionales y no para controlar el flujo de una aplicación, aunque se acabó el tiempo y no tratarlo tanto como nos habría gustado.

En la siguiente hora me quería meter en una propuesta de Germán que me pareció muy interesante sobre programar unos robots para hacer una guerra de robots. Lo malo es que cuando llegué a la sala ya estaba bastante llena y no vi mucho sitio para meterme con mi ordenador y desistí, además fuera me encontré con gente con la que tenía ganas de charlar aprovechando la oportunidad de juntarnos y se nos fue la hora volando (¡en estos eventos es difícil no liarte hablando con la gente!)

Pero en la última sesión tenía claro que quería ver un poco de Clojure, así que me metí en la sesión “Clojure Koans“.

En esta sesión nos pusimos manos a la obra con más ganas que experiencia a experimentar con las Clojure Koans utilizando el formato de randori. Aunque sólo nos dio tiempo de hacer unas cuantas estuvo bastante bien como toma de contacto con Clojure, ya que para mí que vengo principalmente de lenguajes con orientación a objetos un primer vistazo a Clojure asusta jeje.

Después de las charlas hicimos una pequeña retrospectiva en la que valoramos el esfuerzo de Jesús para organizar todo y por demostrar que no hay que organizar mucho para hacer un evento de este tipo, algunas personas lamentaban que no se hubiera programado más, mientras que a otras les pareció positivo haber podido hablar y discutir sobre temas técnicos y hubo también discrepancias con si empezar temprano había sido buena o mala idea, pero qué se le va a hacer, nunca llueve a gusto de todos.

Fue un día como siempre divertido e instructivo, como no puede ser de otra forma cuando estás rodeada de gente que tiene tanto para enseñar y compartir. Hubo gente nueva que no había asistido antes a eventos de este tipo y eso es bueno porque quiere decir que la comunidad ágil crece y los desarrolladores preocupados por su profesión aumentan. Lo que sentí fue la poca participación femenina, ya que sólo estábamos 4 chicas y ninguna cara nueva, todas ya integrantes de las Agile-Girls, ¡habrá que predicar más!

Los libros de Ojo Mágico son unos libros que contienen una serie de fotografías en las que fijándose con determinadas técnicas se pueden ver figuras en 3D. En su página web hay más información y algunas imágenes que van publicando periódicamente.

Estas imágenes están basadas en esteogramas , una ilusión óptica con la que se crea sensación tridimensional en base a los distintos puntos de vista que tiene  cada ojo al mirar una imágen.

Yo los descubrí hace unos 17 años, cuando siendo niña mi padre me regaló el primer libro de Ojo Mágico y aún me sigue resultando algo muy curioso. Pero lo que he descubierto hoy, aunque seguro que existe desde hace mucho, es esta página en la que puedes dibujar tus propias imágenes y no he podido resistir la tentación de crear una que espero que os guste a aquellos que os animeis a intentar verla.

Para aquellos que os animeis a intentar verlo y que no conozcais las técnicas os las pongo:

Método 1

Sujeta la lámina de forma que te toque la nariz (en este caso tendrás que hacerlo con el monitor de tu computadora). Relaja tus ojos y fija la vista en el espacio, como si miraras a través de la imagen. Ponte cómodo/a para observarla, sin mirarla fijamente. Cuando estés relajado/a, y sin cruzar la vista, aleja la lámina de tu rostro (en este caso, retira la cabeza del monitor) un par de centímetros cada 2 o 3 segundos. Sigue mirando a través de la lámina (monitor). Párate cuando la tengas a una distancia correcta para leer. Cuando empiece a “entrar”, es necesario ser muy disciplinado/a porque, instintivamente, intentarás fijar la vista en la lámina (monitor) más que mirar a través de ella. Si no lo consigues, empieza de nuevo. Si la empiezas a ver, intenta mover lentamente la mirada por la imágen para intentar buscar el contorno de la figura.

Método 2

Mira fijamente la imagen a distancia de leer de manera que se nuble un poco la visión. Transcurridos unos segundos, percibirás la profundidad y, a continuación, desplazando la vista sobre la ilustración, distinguirás la imagen en tres dimensiones (3D), que se revelará como una foto instantánea.

Bueno, ¡contadme si la veis y si os gusta !

Del año que se nos escapa me llevo muchas cosas buenas:

• Aunque fue hace dos años cuando comencé a involucrarme en temas nuevos creo que este año me ha servido para crecer aún más tanto en lo profesional como en lo personal y mucho de ello se lo debo a @AlfredoCasado quien tiró un poco de mí hasta que conseguió que cogiera carrerilla.
• He conseguido involucrarme un poco más (con mayor o menor éxito en algunas cosas) en las iniciativas y actividades organizadas por la gente de la comunidad de agile-spain.
• He podido dar por finalizados algunos asuntos que arrastraba de hace tiempo y que parecía que nunca iban a terminar.
• Me parece un gran logro personal haber conseguido iniciar este blog con el que me presenté y gracias al que he conocido a mucha gente nueva.
• Me alegro de haber podido mover un poco la iniciativa de las agile-girls y de haber encontrado un grupo de chicas con las mismas ganas o más que yo de hacer cosas y de intentar demostrar que las mujeres en la informática no somos un mito jeje.

Pero de este año también hay algunas cosas que toca mejorar y que son mis propósitos para el año nuevo:

• Creo que profesionalmente en algunos aspectos he caído en la desidia y espero ponerle remedio lo antes posible  porque quiero disfrutar de lo que hago día a día ya que elegí esta profesión para ganarme la vida porque es lo que me gusta.
• Este año, además, seguiré buscando maestros de los que aprender, quizás no serán los ‘maestros artesanos’ porque no hayan alcanzado la perfección, pero sé que hay mucha gente que puede enseñarte y aportarte algo.
• También quiero dedicarle más tiempo a este blog y poder añadir más contenido porque aún tengo algunos posts que prometí escribir, como la continuación a la entrada sobre Jasmine, que por unas cosas o por otras se siguen quedando en mi tintero.
• ¡Y dejo constancia públicamente de que tengo intención de que el 2011 no termine sin que yo tenga la L de conductora en mi poder!
• Y cómo no: leer, leer y leer un poco más, que tengo muchos de estos libros pendientes.

No son muchos propósitos, pero algunos son bastante ambiciosos, y lo más importante de todo, como ha dicho kini entre sus objetivos para el nuevo año, es que espero poder llevarlos a cabo rodeada de esa maravillosa gente que se va cruzando en mi camino y con la que no sólo comparto profesión.

¡Feliz 2011 a todos, y cuidado esta noche con las uvas!

• Agile Testing: A practical Guide for Testers and Agile Teams
• Analisys Patterns: Reusable Object Models
• AntiPatterns: Refactoring Software, Architectures and Projects in Crisis
• Beyond Software Architecture: Creating and Sustaining Winning Solutions
• Clean Code: A Handbook of Agile Software Craftsmanship
• Continuous Integration: Improving Software Quality And Reducing Risk
• Debug It!: Find, Repair, and Prevent Bugs in Your Code
• Design Patterns: Elements of Reusable Object-Oriented Software
• Effective Java: Programming Language Guide
• Emergent Design: The Evolutionary Nature of Professional Software Development
• Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
• Implementation Patterns
• Java Puzzlers: Traps, Pitfalls, and Corner Cases
• Object-Oriented Software Construction
• Patterns of Enterprise Application Architecture
• Practices of an Agile Developer: Working in the Real World
• The Pragmatic Programmer: From Journeyman to Master
• Pragmatic Unit Testing in Java with JUnit
• Refactoring Databases: Evolutionary Database Design
• Refactoring HTML: Improving the Design of Existing Web Applications
• Refactoring to Patterns
• Refactoring: Improving the Design of Existing Code
• Release it! Design and Deploy Production-Ready Software
• Ship it! A Practical Guide to Successful software Projects
• Structure and Interpretation of Computer Programs
• xUnit Test Patterns: Refactoring Test Code
• The Timeless Way of Building

También aprovecho esta entrada para poneros al día de los próximos eventos que van a organizarse en Madrid porque estamos que no paramos:

30-12-2010: Reunión del grupo Madrid.rb(@madridrb) que va a tener como tema un Coding Dojo guiado con @ecomba. Podeis ver la información aquí.

04-01-2011: Reunión del grupo MadriAgil que también tendrá como temática un Coding Dojo en el que esperamos contar con @ecomba y @plagelao.

08-01-2011: Después de los Reyes (que seguro que vendrán cargados de regalos para todos porque hemos sido muy buenos )  tendremos un Open Space que @jjballano se ha encargado de gestionar de maravilla. Las plazas iniciales están cubiertas, pero si estáis interesados, apuntaos que existe la posibilidad de que se abran más o de que haya bajas de última hora. Aquí teneis la información.

¡Espero veros por alguno de los eventos!