Saturday, July 26, 2014

Impresiones Go (golang)


Tal y como todos sabéis (después de la paliza que he dado durante estos días) durante la PiWeek me dedique a aprender el lenguaje Go.

Este post resume mis sensaciones sobre este lenguaje en el poco tiempo que lo llevo usando. Desde luego estas son mis opiniones, son intransferibles y cambian con el tiempo... (como todo).
:-)

Me ha gustado

  • Facilidad de expresar concurrencia. Esta parte en realidad me ha encantado, definir patrones de concurrencia usando comunicación por canales ha resultado muy sencillo y en nada de tiempo he desarrollado soluciones que solo de pensar en desarrollarlas y depurarlas en C++, me da dolor de cabeza. (Entiendo que los patrones aprendedidos en la ErlangCamp con actores y todo lo leído sobre sistemas distribuidos ha ayudado a que resulte fácil).
  • Me ha encantado la eficiencia en memoria de las soluciones generadas (comparando con el equivalente en python, ruby o en java).
  • Da gusto ver los ocho cores aumentando y disminuyendo su carga de forma uniforme. :-)
  • Generar  binarios estáticos o dinámicos que sólo dependen de la libc o la libpthreads es una delicia, sobre todo cuando tienes máquinas con distintas versiones de linux. Los despliegues se simplifican de forma brutal... quedando reducidos a un scp :-)
  • Orientación a Objetos, muy sencilla, siempre y cuando estés acostumbrado a hacer diseños en los que predomine la composición. Si eres de los que piensas que Orientación a Objetos es diseñar jerarquías, estás en un problema (en mi opinión, tanto en Go, como en cualquier otro lenguaje Orientado a Objetos).
  • Inferencia de tipos, hace que tengas las ventajas de un lenguaje estáticamente tipado sin tener toda la verbosidad.
  • Gran cantidad de documentación de alta calidad (charlas, ejemplos, libros). Esto desde luego tiene que ver con que han decido estabilizar la versión 1.x del lenguaje y ser muy conservadores en cuanto a los cambios.
  • El compilador es MUY rápido y el ecosistema es muy simple, lo que permite que el flujo de trabajo en cuanto a trabajo con tests, y feedback casi instantáneo, sea muy similar a trabajar con lenguajes dinámicos como python y ruby.

No me ha gustado

  • Aunque es algo más difícil, puedes liarla con los punteros. 
  • Se da bastante flexibilidad para cualquier solución de concurrencia, incluidas algunas formas de solventarlas que pueden ser peligrosas (Mutexes que dejemos sin cerrar, semáforos, etc). Por otro lado el lenguaje 
  • Evidentemente es un lenguaje de un nivel de abstracción bajo/medio, que permite estar en contacto con los tipos de datos a nivel de procesador y usar los recursos de una forma eficiente, pero en ocasiones echo de menos construcciones más expresivas y compactas de otros lenguajes de más alto nivel (bloques ruby, list comprehension python, etc.)
  • La sintaxis para los mapas se me hace poco legible.
  • Por supuesto, soy un enamorado de los lenguajes dinámicos, por lo que en algunas ocasiones me siento encorsetado al definir las estructuras de datos. Pero supongo que es por cómo suelo programar...
  • Si nos salimos de el tipo de aplicaciones para los que fue inventado, vamos a echar en falta bibliotecas potentes, aunque entiendo que eso es cuestión de tiempo.

No tengo opinión clara

  • Control de errores, sensación no definida, por un momento,  parece demasiado verboso, por otro lado parece buena idea obligar a los desarrolladores a que piensen en los errores...
  • La parte de testing integrada en el core del lenguaje y las herramientas me parece una gran idea, pero no los he usado como para tener una opinión formada sobre su funcionamiento.

Otros comentarios

  • Si estás acostumbrado a hacer objetos pequeños y facilitar el reuso por composición en Golang no vas a tener ningún problema.
  • Los escenarios en los que Go creo que es una opción muy viable son:
    • Aplicaciones de alta concurrencia y que requieran escalabilidad.
    • Aplicaciones reactivas y centradas en eventos.
    • Aplicaciones de networking.
    • Sistemas de monitorización, de control.
    • Lenguaje de sistemas
  • Escenarios en los que veo que hay mejores opciones:
    • Lógica de negocio complicada
    • Sistemas de información con flujos muy complejos
    • Existen tipos de aplicaciones en los que se van a echar en falta bibliotecas (pero esto dependerá de hacia donde evolucione la comunidad).
  • Lenguajes/entornos para los que creo que es un buen competidor
    • Susituto de Node
    • Susituto de C++ en aplicaciones de red y lenguaje de sistemas
    • Rust
    • Lenguajes dinámicos (python/ruby) para sistemas escalables o programación de sistemas

Go no es un lenguaje no hecho para hipsters. Aunque lo parezca porque es muy reciente y está consiguiendo mucha tracción, se trata de un lenguaje muy conservador, con una sintaxis simple y con pocas funcionalidades a nivel de lenguaje.
Parece que han decido que solo introducen funcionalidades al lenguaje en caso de que todos los diseñadores/desarrolladores del core estan de acuerdo, por lo que en general se añaden muy pocas cosas.
Se han centrado en tener la versión 1.0 y la van a mantener la compatibilidad durante varios años. Esto permite que se creen muchos recursos de gran calidad (charlas, libros, etc), cosa que no se ha visto con otros lenguajes que evolucionan mucho más rápido.

Patrón para la concurrencia :-)

Conclusiones

Creo que Go esta para quedarse, tienen muchos y grandes apoyos, y cubre una necesidad real (concurrencia y paralelismo, en un entorno de desarrollo y necesidades para despliegue extremadamente sencillo)
Es un lenguaje suficientemente bueno, centrado en un mundo escalable y reactivo, muy estable y que está creciendo a una velocidad de vértigo con una gran comunidad.
Es un lenguaje sin construcciones muy avanzadas y es un gran paso para desarrollos concurrentes y paralelos sin resultar disruptivo, de forma que lo más probable es que obtenga un gran exito (bueno, en realidad creo que ya lo está teniendo).

En esto de los lenguajes es lo de siempre:
"There are only two kinds of languages: the ones people complain about and the ones nobody uses". Bjarne_Stroustrup

Recursos Go:

Para empezar:
Más información de calidad:
Otros recursos interesantes:
Charlas recomendadas:

Enlaces relacionados:

Monday, July 21, 2014

Conclusiones PiWeek / Brutal :-)


Tengo que decir que la PiWeek ha sido para mi uno de las semanas más intensas y de más retorno de la inversión que he tenido en bastante tiempo.

En mi caso pretendía aprender GoLang y tengo que decir que el objetivo ha sido cumplido con creces. No quiero decir que ahora domine el lenguaje, pero sin duda puedo decir que ahora estaría en condiciones de empezar un proyecto que se pudiese poner en producción y creo tengo las nociones necesarias de los conceptos más importantes (concurrencia expresada mediante procesos ligeros (gorutinas), comunicación por canales, los diseños share nothing, etc)

Resumiendo, que hace mucho tiempo que no era capaz de centrarme toda una semana en aprender algo, en un ambiente en el que todo el mundo está entusiasmado por crear, aprender, construir... innovar.

Desde el punto de vista de empresa creo que es una forma muy barata de impulsar la innovación, de fomentar el trabajo en equipo y de crear nuevos productos. Por poner un ejemplo, en una sola semana, he visto proyectos que pueden ser perfectamente un nuevo producto, yo mismo he aprendido una nueva tecnología a un nivel que no podría conseguir en un curso y ahora mismo me veo con capacidad de aportar todo lo aprendido en mi empresa. Seguramente pudiendo ahorrar mucho coste en cierto tipo de proyectos.

Vamos, que desde el punto de experiencia personal, de cumplimiento de expectativas y de retorno de la inversión, le doy una puntuación de:

9/10


El juego de la perfección. Para que la PiWeek fuese la mejor opción para la innovación personal y la innovación tecnológica, y por tanto un gran paso para la dominación mundial por parte de los nerds, falta mejorar los siguientes puntos:
  • Preparar proyectos con un poco más de antelación, para que se pueda generar interés en los proyectos (internamente en Kaleidos puede que se genere, pero desde fuera es mucho más complicado).
  • Logística de telecomunicaciones para que sea más sencilla la incorporación de proyectos realizados desde otras sedes.
Otra posibilidad es impulsar la actuación más local para que se expanda la idea de forma más global. Es decir, dar más peso para que se generen sedes en otras ciudades que actúen como centros de innovación, como actúa Kaleidos en el caso de Madrid.


Desde luego, me he quedado encantado y seguro que voy a intentar repetir la experiencia en las siguientes convocatorias...

Muchas gracias Kaleidos por la idea y la puesta en práctica


Enlaces relacionados:

Saturday, July 19, 2014

Diario PiWeek Dia V (El desenlace final)

Hoy era el último día de la PiWeek y el ambiente que se notaba era entre festivo y de nerviosismo. Todo el mundo estaba cerrando las últimas tareas o preparando la demo/presentación.

En nuestro caso, la verdad es que el jueves teníamos ya implementado las dos soluciones que pretendíamos hacer, así que lo único que podíamos hacer era abrir el proyecto e intentar meter más funcionalidad o seguir leyendo y autoformandonos en Go, y dado que yo soy más bien de asegurar, no quise tocar el código y simplemente he pasado la mayor parte de la mañana leyendo sobre Go y debatiendo sobre temas de agilidad con Yamila.   :-)

A punto de empezar las demos
A las doce y media se paso ha realizar las demos de los proyectos. Recordemos que uno de los requisitos de la PiWeek es que en la demo se presentase un sistema/aplicación funcionando. No vale con presentaciones, tiene que ser algo real, algo funcionando. Esta regla te obliga a tener unas expectativas reales y gestionar muy bien el tiempo del que dispones.

Las demos me han gustado mucho puesto que no había podido seguir el avance de los proyectos durante la semana y algunos estaban muy currados y podrían ser perfectamente la base de un producto.

Una cosa me ha quedado clara, una aplicación servidora con interfaz de linea de comando no es muy impactante precisamente. Quizás podríamos haber generado gráficas en tiempo real o algún tipo de medida de rendimiento para que se viesen más claramente las ventajas que hemos tenido por desarrollar en Go. O mostrar parte del código para que se viese lo fácil que ha sido expresar la concurrencia.

Todos los proyectos me han parecido muy interesantes y esto no es por ser un pelota, lo digo de forma sincera. Había de todo, pruebas concienzudas de tecnologías, proyectos de integración, posibles productos para publico masivo, webs de contenido especifico, integración de sensores y hardware, aplicaciones móviles, webs, bases de datos, multitud de lenguajes, multitud de tecnologías, etc.
Una de las presentación ha tenido incluso música en directo creada expresamente para la ocasión. Contra eso está claro que no se puede competir :-)

Presentación con música en directo (flipa!!!!)

Por cierto, muchas gracias Yamila por apuntarte al proyecto, se aprende muchísimo más en compañía y además así ha resultado mucho más fácil completar toda la funcionalidad que pretendíamos :-)
Un gusto trabajar contigo.






Enlaces relacionados:

Thursday, July 17, 2014

Diario de PiWeek IV (Jueves)

Nuestro logo de proyecto
Hoy la verdad es que se ha dado muy bien, hemos terminado todos los hitos funcionales que nos habíamos planteado al comienzo del proyecto.

Por lo que una vez preparada la demo que vamos a hacer mañana, hemos podido ir estudiando como podemos hacer el código más idiomático. Recordemos que el objetivo principal es aprender Go, asi que todo lo que podamos aprovechar esta tarde y mañana antes de la demo, para seguir aprendiendo será perfecto.




Yamila se ha currado el servidor http y sus correspondientes pruebas y yo he terminado las pruebas del servicio por amqp. La verdad es que en ambos casos no se ha dado mal.

El diseño que ha quedado es el siguiente: dispone de un motor de consultas snmp asíncrono, que a partir de un canal de peticiones snmp, las despacha para diversos workers creados por cada destino y que se balancean la carga permitiendo hasta un máximo prefijado de operaciones snmp por destino. Una vez realizada la consulta snmp, la respuesta se devuelve por otro canal.
Por supuesto este canal de salida está desordenado, puesto que se ponen en el canal de salida en cuanto termina de realizarse la petición snmp y eso dependerá totalmente del host destino y de la consulta snmp.

Usando este motor de consultas se han creado dos servidores:

  • amqpsnmpqueries (pasarela amqp/snmp)
  • snmphttpserver (pasarela http/snmp)

amqpsnmpqueries


Partiendo de una cola AMQP (en rabbitmq) de peticiones snmp, publica en un exchange AMQP las respuestas a las peticiones. En este caso, la aplicación es casi un uso directo del motor de consulta snmp asincrono.

Diseño interno amqsnmpqueries. 

snmphttpserver


Permite realizar consultas snmp por http. En este caso dado que cada cliente quiere una respuesta sincrona a su petición exite una capa de adaptación que apartir de las salidas desordenadas se encarga de despachar cada respuesta al cliente correcto.
Diseño interno snmphttpserver

En un plano más mundano, Kaleidos ha invitado a unas riquísimas empanadas de Milan Dopico que hemos disfrutado en la azotea.
Cualquiera que me conozca sabe que disfruto con esas cosas como un cerdito en la charca :-)



Y mañana demo!!!  La verdad es que hay unos proyectos chulisimos y estoy deseando ver hasta donde han llegado...
Por mi parte, con el nuestro hemos cumplido, puesto que creo que las bases de Go como para desarrollar algo que vaya a producción están asentadas.

Enlaces relacionados:

Wednesday, July 16, 2014

Diario de PiWeek III (Miercoles)

Artista con las tizas...
Tercer día de la PiWeek, hoy hemos comenzado los primeros prototipos para interactuar con el servicio usando AMQP y http.
De momento sólo tenemos algunas pruebas, pero creo no debería ser demasiado difícil enganchar las piezas.

Hoy después de repasar el punto en el que estamos en el proyecto, decidimos dividir el trabajo y abrir dos vías de forma simultanea, una para amqp (que he empezado yo) y otra para el servicio http que ha empezado Yamila.

Por desgracia, Yamila, fue requerida por una urgencia (de fuera de PiWeek) y no tubo todo el tiempo disponible.

Hasta ahora mis sensaciones con respecto a Go son:

  • Permite expresar muy bien la concurrencia de un programa
  • El tratamiento de errores, se me hace pesado (supongo que porque es tan divertido como documentar :-) )
  • Por otro lado, la velocidad de desarrollo es muy buena en este tipo de problemas, aunque se nota que tenemos una falta de conocimientos brutal, puesto que aunque las cosas funcionan no tienen para nada pinta de ser muy idiomaticas. Asi que creo que nos queda mucho que aprender sobre como organizar el código, los paquetes y como abstraer y reusar usando iterfaces.
  • En cualquier caso, suelo preferir hacer algo que funciona y luego ir iterando verificando que sigue funcionando. Así que nos centraremos en tener el servicio amqpsnmp y httpsnmp y ya nos preocuparemos de refactorizar haciéndolo más idiomatico y reusable.

A última hora...
No solo de programar vive el PiWeekero y también se ha celebrado un campeonato en la pequeña recreativa que hay en la oficina.

Entre pomodoro y pomodoro, puede echar un vicio...

Mañana más...

Enlaces relacionados:

Tuesday, July 15, 2014

Diario de PiWeek II (martes)

Segundo día de la PiWeek y el proyecto a toda marcha...

El lenguaje Go nos esta resultando fácil y nos está permitiendo con muy poco coste solventar los problemas de concurrencia.
Aparentemente la aplicación es robusta y se ejecuta de forma paralela en todos los cores sin tener que añadir nada de código.

Al igual que ayer, hemos generado algunos deadlocks, en muchos de los casos por intentar escribir en canales sin buffers de los que todavía no existe un lector.
En cualquier caso, han sido fáciles de detectar y de solventar.

Todavía no hemos empezado con temas de interfaces, pero cada vez se me hace más evidente que con un buen diseño el core es reusable para otro tipo de operaciones de red.

Hoy, no he acaparado tanto el teclado y creo que hemos avanzado en conocimiento los dos.

Lo que a estas alturas tengo claro es que verbalizar problemas de concurrencia y sincronización es bastante complicado, por lo que creo que Go hace un trabajo excelente en permitir expresar en código esa concurrencia de forma más o menos sencilla (teniendo en cuenta lo difícil que es en otros lenguajes).

Bueno, mañana más....

Enlaces relacionados:

Monday, July 14, 2014

Diario de PiWeek I

Llegue a las 9:00 a Kaleidos y ya estaba casi todo el mundo cerrando su participación en los proyectos. En mi caso, parece que la proyecto para aprender Go le ha convencido a Yamila Moreno por lo que se ha apuntado al mismo....

Inicialmente parecía que Antonio de La Torre tenia interés, pero después de la primera reunión en la que he comentado un poco por encima como funciona snmp, el interés a decaído y finalmente ha decido pasar a otro proyecto que seguramente sea más interesante. :-)

Total, que nos hemos embarcado Yamila y yo con el proyecto.

Hemos empezado por montar el entorno de desarrollo en el equipo de Yamila y conseguir algunos temas de logística como teclado, monitor y acceso a wifi. Posteriormente nos hemos metido en el fregado y hemos empezado por mirar el código que tenia yo desarrollado de días anteriores.

Y ya por fin hemos comenzado a desarrollar, aunque en esto tengo que decir que sin darme cuenta he acaparado bastante el teclado :-(  Mañana no pasará. Lo siento, Yamila.

Es muy gratificante poder trabajar y contrastar las ideas sobre como hacer algo con alguien que cómo tú está fuera de su zona de confort. Creo que esto ayuda mucho a hacer las preguntas más absurdas o las suposiciones más raras sin temor a quedar mal, puesto que los dos estamos en el mismo punto :-)

El resto del día se ha pasado familiarizándonos con la forma de usar canales y funciones concurrentes y haciendo cambios muy pequeños de forma que el avance fuese lento pero seguro y que sirviese para ir afianzando conceptos.

El uso de canales para la sincronización me gusta tanto o más como me gustaron los mensajes entre procesos en erlang.

Durante el proceso:

  • Hemos generado dos dead locks
  • Nos hemos liado con la sintaxis de Go unas cuantas veces
  • Hemos en muy poco tiempo realizado un programa con bastantes hilos de ejecución sin generar un caos muy grande (punto para Go)

Resultado:

  • Entorno de compilación en los dos equipos
  • Trello con bastante contenido
  • Esqueleto de aplicación en el que cada comando se despacha a una cola por destino en el que procesaran un numero máximo de procesadores concurrentes
  • Main de prueba que acepta comandos en texto por la entrada estandard
  • Ejecución de snmpwalk sin ningún tipo de control de errores y sin almacenar el resultado, solo limpiándolo en pantalla.

Bonus point

Algunos otros proyectos tenían cierto interés en seguir prácticas de DDD en su implementación y aprovechando que nosotros estamos usando muchos de esos conceptos en el desarrollo en Alea Soluciones, realice una presentación medio improvisada sobre DDD en python.
Creo que ha resultado de interés y estaré al tanto para ver si alguno de los proyectos realiza una implementación de ese tipo.
Junto con el tema de DDD hemos visto también como estamos haciendo el testing unitario y como la arquitectura que usamos nos permite postergar las decisiones.


Mañana, mas y mejor...


Enlaces relacionados:

Diario de PiWeek 0

Este viernes pasado fue la presentación de proyectos para la PiWeek. En esa presentación los participantes presentan los proyectos en los que quieren trabajar durante la semana, e indican el tipo y numero de participantes que pueden necesitar para llevar a cabo el proyecto...

Se genera un ambiente muy divertido en el que se produce una especie de subasta inversa de proyectos y skills, en que cada uno intenta generar tracción alrededor de su proyecto para conseguir que otros participantes se apunten a colaborar.
En esta ocasión fue especialmente gracioso ver como varios proyectos se intentaban disputar la participación de un diseñador, que parece que es conocido de anteriores PiWeeks por realizar unos diseños espectaculares :-)

Una vez presentados los proyectos, la gente muestra su interés inicial en uno o más proyectos, y tiene todo el fin de semana para decidir en que proyecto participará finalmente.

Realmente es el lunes a primera hora cuando se terminan de cerrar los participantes de cada proyecto.

Esta era la segunda presentación de proyectos en la que he asistido, aunque la primera en la que presentaba un proyecto. En mi caso, presente con el nombre de Go, Forrest Go!!! una aplicación para realzar consultas snmp de forma concurrente y paralela que servirá de  hilo conductor a un proceso de aprendizaje de lenguaje Go (aprendiendo golang en la piweek)

El proyecto se podrá seguir en:



Enlaces Relacionados:

Monday, July 07, 2014

Aprendiendo GoLang en la PiWeek

Este año, en el equipo estamos autogestionando nuestro presupuesto de formación por lo que cada uno que debe proponer los eventos/cursos/formaciones a las que quiere asistir al resto del equipo y entre todos se decide que es lo que se va ha hacer.

En mi caso, aparte del AOS 2014 de Valladolid, y seguramente de la PyCon.Es de Zaragoza, he decido que una buena forma de mejorar como desarrollador es aprender un nuevo lenguaje y que mejor forma de hacerlo que dentro del marco de la http://piweek.com/ organizada por Kaleidos.

Para los que no lo conozcan, la PiWeek (Personal Innovation Week) es una idea de la gente de Kaleidos que consiste en durante una semana parar de realizar trabajo "facturable" para la empresa y dedicarse a la innovación, pero desde un punto de vista personal, en el que cada uno decide sobre qué quiere trabajar.

Solo tiene dos reglas:
- Solo puedes usar software libre
- El viernes de esa semana tienes que mostrar el producto realizado durante esa semana

Así que esta semana que viene, dentro de la http://piweek.com intentaré aprender http://golang.org para la creación de servicios de red de alta concurrencia.
En concreto, voy a intentar desarrollar:


El objetivo es conseguir soltura de desarrollo en Go para entornos concurrentes y poner en práctica muchos de los patrones de concurrencia y comunicaciones vistos en Erlang, Go y los que actualmente suelo implementar en python.

Si alguien va ha participar en la http://piweek.com y comparte alguno de estos objetivos estaría encantado de que trabajásemos juntos, en los servicios propuestos u en otros, dado que el objetivo es el aprendizaje.

Otra opción podría ser un servicio de check de servicios http, pero eso dependerá de si hay alguien más interesado...

En el siguiente panel tengo la intención de gestionar los avances del producto
https://trello.com/b/JQxhbtfa/eferro-piweek2014


Gracias a Kaleidos por estas ideas geniales
 y sobre todo gracias por compartirlas....


Referencias:




Sunday, July 06, 2014

AOS 2014 Valladolid

El pasado 6 y 7 de junio asistí al AOS2014 en Valladolid, para el que no lo sepa el AOS (Agile Open Space) es una de las dos eventos a nivel nacional que realiza al año Agile Spain
Un Open Space es un formato de des-conferencia auto-organizada por los propios asistentes donde no está definida la agenda previamente.
Esta definición de Open Space que he leído en cachirulovalley deja claro que es una conferencia, en que todo lo que sucede es resultado de los propios asistentes. Por lo que aunque en este post voy a dejar mis sensaciones, cualquier cosa que refleje, para bien o para mal, es simplemente lo que tenia que pasar en ese momento y con esos asistentes.

Era mi tercer AOS, y como siempre es uno de los eventos que espero con más ilusión puesto que además de encantarme el formato de Open Space es uno de los eventos donde más se invita a interactuar y compartir y eso para mi es importante.

Resultado resumido:

Me lo pase genial. No aprendí mucho, aunque si que centre algunas ideas... Aproveche a salir un poco de mi zona de confort y apuntarme a dinámicas y sesiones en las que normalmente no me suelo apuntar.
Y también me di cuenta que cuando estoy con temas que me gustan soy bastante brasas (así que mis disculpas a los afectados :) )
Tanto el viaje, como el alojamiento fue en grupo y la experiencia fue muy enriquecedora. El alojamiento nos salio un poco rana, pero ese es otro tema.

Equipo desarrollo Alea Soluciones
(@apa42 @eferro @pasku1 @jaimegil @nestorsalceda)

Resultado un poco más pormenorizado:


  • Es el primer AOS en el que he podido disfrutar del ambiente de tarde/noche, en anteriores había viajado con un Bebe por lo que las prioridades eran otras :-)
  • Fuimos todo el equipo de desarrollo de Alea Soluciones y eso en si mismo es fantástico, por todo lo que se comparte y se debate.
  • Me gusto que al final hubiese algunas sesiones algo más técnicas y dedicadas a temas de desarrollo (aunque me sigue pareciendo que son insuficientes, cosa que me sorprende, puesto que la mayor parte de los asistentes se dedican al desarrollo de software, o eso dicen :-)  )
  • Como soy un desastre no apunte las sesiones a las que asisti, pero si que me acuerdo de las sensaciones que tuve...
  • Me gusto especialmente la sesión Daily standup el musical @giropa832 
  • También me gusto el taller sobre refactoring que organizaron @istepaniuk  @pasku1
  • Como siempre, recordé de cuanto comparto con muchos de los compañeros de profesión con los que me encuentro sistemáticamente en este tipo de eventos.
  • Por otro lado, la hospitalidad de los organizadores fue fantástica y se preocuparon de que tanto durante el evento como después del evento nos sintiésemos como en casa.
  • Presente la sesión "de test unitarios de clases a tests unitarios de funcionalidad" en la que compartimos como hacemos TDD actualmente y como fue la evolución. Creo que aporto ideas a los asistentes y por el debate generado, creo que gusto.

Y ahora para poder expresar las cosas que creo que son mejorables, el "juego de la perfección". 
Yo a este AOS 2014, le doy un 8, y para ser un 10, creo que debería mejorar lo siguiente:
  • El segundo día, el tiempo de las presentaciones de las sesiones se fue de las manos, por lo que fue un lio de votación.
  • Me falto la retrospectiva final y quizás alguna dinámica de cierre (aunque soy consciente lo difícil que es hacerlo con tanta gente). Pero un evento ágil sin retrospectiva, me resulta raro.
  • La comida de los dos días de picnic fue exactamente igual (un poco aburrido). Aunque me encanto la posibilidad del picnic que ayuda mucho a juntarse y charlar.
  • En algunos momentos el barullo era molesto, sobre todo cuando se intentaron hacer varias sesiones en el espacio principal.
  • Me faltaron más sesiones sobre técnicas de desarrollo, profesión, desarrollo de software, etc. (No solo de abrazar arboles vive el agilista :-) )

Muchísimas gracias a todos los organizadores 



Me quedo esperando con ganas al AOS del año que viene... 
Nos vemos por Asturias...