lunes, julio 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:

sábado, julio 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:

jueves, julio 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:

miércoles, julio 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:

martes, julio 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:

lunes, julio 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: