Primer dia de PiWeek VII Dia 0/1

Una vez más me he apuntado a la PiWeek, además en esta ocasión de Alea Soluciones también se ha venido Rubén (uno de los nuevos fichajes del equipo Bifer de Alea Soluciones).

Mi idea es, siempre que el presupuesto de formación me lo permita, me apuntaré a todas las ediciones  de PiWeek, puesto que una forma de aprender/experimentar que me está funcionando.

En esta ocasión pretendemos aprender a realizar gráficas en tiempo real renderizando en el frontend. En mi caso, quiero centrarme en aprender todo lo que pueda sobre frontend (HTML5, CSS3, js).
Esto lo incluyo dentro de mi objetivo de mejorar esa parte en los siguientes meses, para lo que además de la PiWeek, voy a intentar hacer algún proyecto mentorizado.

La suerte ha hecho que lo que teníamos pensado Rubén y yo encajase perfectamente con otro proyecto de renderización de gráficas para monitorización en 3d presentado por Enrique Paredes (@iknite) . Así que se ha decido juntar los dos proyectos. Además, parece que el proyecto le ha parecido interesante a David Villa  así que se ha apuntado.

De momento el primer se ha hecho un poco duro en mi caso, puesto que se ha mezclado el estar totalmente fuera de la zona de confort con temas logísticos que me han impedido llevar un horario muy normal....

Pero bueno, esto no es como empieza, es como acaba, así que seguiremos informado....

Podcasts/Talks 2014 30 Oct - 19 Nov

This time I have a good list of interesting talks:-)

• Polyglot Data (Greg Young) Good tips related to persistence, entities, events... Good explanation about the information lost when we only store the actual state of an entitiy instead the stream of events of the entity. There is no "best" database, only "best database for" some use cases. The benefits of separate bounded contexts and decide wich databases are the bests for this bounded context... Separation of reads from writes (CQRS). Lot of good stuff.
• Virtual Machines, JavaScript and Assembler (Scott_Hanselman) Very fun talk. Also gives an interesting overview of current technology (cloud, web, etc.).
• Our Responsibility to Defeat Mass Surveillance (Erik Dörnenburg and Martin Fowler) Inspirational talk about some of our responsibilities as developers.
• Embracing Uncertainty (Dan North) Very interesting talk to be aware of our aversion to uncertainty. We usualy make bad decisions in order to avoid the feeling of uncertainty.
• Are We There Yet? (Rich Hickey) Talk about the functional programming using immutable data structures and the benefits if this programming for systems requiring high concurrency.
• Consistency without consensus in production systems (Peter Bourgon) Very practical talk, about real systems using eventual consistency and a good/practical explanation about  CRDT data types.

Presentación Python Herencia vs Composición (Luke soy tu padre) PyConES 2014

Estas son las diapositivas de la charla corta que di en la PyConES 2014 (Zaragoza) sobre Herencia vs Composición en Python:

• Python Herencia vs Composición (Luke Soy tu padre)

Por si alguien se pregunta por qué no hice referencia al Liskov substitution principle  o por qué no di más ejemplos, tengo que decir que la charla duraba 10 minutos y la di a toda velocidad... Tanto que no se ni si me hice entender :-)

Cualquier feedback sobre el contenido de la charla o la forma de transmitir será muy bienvenida...

Articulos relacionados:

• http://www.eferro.net/2014/11/taller-diseno-modular-dirigido-por.html
• http://www.eferro.net/2014/09/votacion-talleres-charlas-para-la.html

Taller Diseño modular dirigido por pruebas

Preparado por: Nestor Salceda, Alberto Perez (Apa), Jaime Gil, yo mismo (eferro)
Basado en el taller creado por  Javier Acero, Guillermo Pascual

Aprenderemos a crear una aplicación en la que el negocio sea el centro y que la arquitectura emerja del propio proceso de creación (por supuesto usando TDD).

Enunciado:

Vamos a desarrollar el equivalente Maño de twitter, llamado "Cós". Podéis ver el enunciado completo en: https://github.com/aleasoluciones/pycones2014

Restricciones

• Haz lo más simple que pueda funcionar
• Escribe el mejor código que puedas
• No hagas más de lo que pide la funcionalidad
• No introduzcas infraestructura si la funcionalidad no lo pide explícitamente
• No dependas de librerías si la funcionalidad no lo pide explícitamente

Flujo

• Evalúa el impacto de cada funcionalidad
• Realiza los cambios que necesites para que la funcionalidad sea fácil de introducir
• Introduce la funcionalidad

Forma de trabajo:

• Trabajaremos en parejas, cada pareja con un portátil
• Estaremos para ayudar/responder dudas cuatro personas
• Haremos iteraciones

Requisitos:

• Portátil python 2.7/3.x virtualenv pip
• Conexión internet

Si quieres preparar el virtualenv usaremos las siguientes librerías:

• expects
• mamba
• doublex (Puede no ser necesario)
• librería http (Tornado, Flask, etc.)
• librería para persistencia (Pickle, durus, redis, sqlite, mysql, etc.)

Ejemplos de soluciones:

(Si puedes no verlas hasta después, mejor)

• https://github.com/nestorsalceda/pycones2014-solution
• https://github.com/eferro/pycones2014-solution
• https://github.com/jaimegildesagredo/pycones2014

PyConEs 2014 Zaragoza 

Sabado 8 a las 16:00, Sala4

Verbos vs Nombres

Flujo análisis (continuo) en un proyecto

• Centrar conversaciones en identificar comportamientos (behaviours). Intentamos identificar acciones, verbos, flujos, eventos. Viene fenomenal para OOP centrado en casos de uso o para un enfoque DDD y flujos de negocio complicados.
• Centrar conversaciones en identificar comportamientos concurrentes en el sistema. Nos obliga a identificar relaciones entre esos comportamientos y nos ayuda a hacer un diseño escalable y fácilmente implementable mediante servicios independientes que encapsulan estado y que se comunican mediante mensajes (perfecto para implementaciones con Actores, Pipelines, microservicios, etc.)

Como se puede ver estos dos enfoques se centran en las interacciones de los usuarios con nuestro sistema o las acciones del propio sistema (Verbos) y  no tanto en las entidades con las que trabaja (Nombres). 

Sin embargo el análisis más típico que se suele hacer en OOP (mal entendida por supuesto) se centra en identificar primero las entidades, perdiendo el contexto de las interacciones (mensajes, flujo, reglas, etc...)  derivando, no necesariamente, pero si típicamente, en modelos anémicos y pobres.

Conclusión:

Valoramos la identificación de las entidades (Nombres) con las que trabaja nuestro sistema, pero valoramos mucho más la identificación de los comportamientos (Verbos) que definen cómo interactuamos con nuestro sistema y qué tareas facilita.

Recordemos que los clientes NO quieren software/sistemas, quieren facilitar sus tareas o resolver sus problemas.

Nota adicional:

Este análisis de negocio se puede hacer a distintos niveles en el sistema, por lo que este enfoque de centrarnos en los verbos, nos puede servir para identificar servicios de nuestro sistema o eventos de negocio, o en un nivel mucho más cercano a una aplicación concreta para poder identificar los hilos de ejecución concurrentes o orientar el diseño hacia un sistema más reactivo.

Podcasts/Talks 2014 24-30 Oct

These are the most interesting talks I saw these last days:

• Life is easy. Why do we make it so hard? Jon Jandai at TEDxDoiSuthep Inspirational talk
• RubyRogues 178 Refactoring Ruby with Martin Fowler Quite entertaining episode with some interesting explanations/points about refactoring/reestructuring and the perverted use of the "refactoring" term.
• The art of destroying software Greg Young Some good points about the easy evolution of a system when the services are small enough to be understandables and to be rewritten without fear. 
• Crafted Design Sandro Mancuso Very interesting talk about architecture, general desing of an application. Very aligned with the DDD movement and the classic OOP architectures without framework coupling.
• The Next Decade of Agile Software Development J. B. Rainsberger  Reflexive talk about the agile message, the (real) impact, the misunderstanding of the message and our attitudes and practices. An opportunity to reflect.