#Podcast -About Software Architect, Design, MicroServices and how to stay focus (and 40º fever as a plus !) Spanish

jedi-kitten-battle-animated

Hi !

New podcast, we are in number 19 and this one, with some great professionals: JuanMa (@gulnor) and Omar Del Valle (@omarvr72). And we scheduled ourselves to talked a little about Software Architects. That was the initial idea, however when I added my 40º fever, we move the conversation to another set of topics:

  • ¿Are the Software Architects bad for the Software Industry?
  • ¿Why we talk about Architectures for Back End architectures? Front End architectures are real also
  • ¿Should we mix Architecture designs? Even if they are bad for the business
  • Visual Studio as development tool
  • Micro Services, this is not a silly topic. In the wrong hands it could create a lot of pain!
  • Monolithic App in process to be “migrated” to a Micro Services approach. Another way to move “centralized problems” to “shit everywhere”
  • ¿How we should sell an architecture choice to a client?

While we were talking we also commented some unusual stuff like Gang of Four and they great Design Patterns book, the great Carlos Peix and his TDD materials, Jimmy Bogard and his Mediator; and more.

I hope you enjoy this one. PODCAST LINK

Greetings @ Toronto

El Bruno

References

#Podcast – NTN 19 – Sobre Arquitecturas, diseños, MicroServicios y ser un poco realistas (con 40º de fiebre que siempre ayuda!)

jedi-kitten-battle-animated

Hola !

Nuevo episodio, ya el número 19 y esta vez tengo la suerte de estar con JuanMa (@gulnor) y con Omar Del Valle (@omarvr72) para hablar un poco sobre Arquitectura de Software. En realidad esa era la idea inicial, cuando le sumé mis 40º de fiebre pues salieron otros temas que han sido bastante interesantes. Por ejemplo:

  • ¿Cuánto daño han hecho los arquitectos de software?
  • ¿Por qué cuando hablamos de arquitecturas siempre hablamos de backend, existen arquitecturas de FrontEnd?
  • ¿Debemos mezclar diseños de arquitectura? Inclusive si los mismos afectan negativamente a una solución de negocio
  • Visual Studio como herramienta de trabajo
  • Micro servicios, no son una tontería. En malas manos pueden hacer mucho daño.
  • App monolíticas que se “migran” a MicroServicios. O como es más fácil tener problemas centralizados o ya que la “mierda esparcida en varios sitios” es más difícil de limpiar
  • ¿Cómo justificas una decisión de arquitectura en un cliente?

En el camino han surgido referencias a Gang of Four y su libro de patrones, al gran Carlos Peix con sus cursos de TDD, Jimmy Bogard y su Mediator; y muchos otros temas. Como siempre, una vez que tomamos el ritmo adecuado, es una pena tener que cortar!

Espero que lo disfruten. PODCAST LINK

Saludos @ Toronto

El Bruno

References

#Humor – Maybe you don´t get the idea behind #containers and #microservices

Hi !

qwqewqdqw

If your final implementation of microservices is something like this, I need to suggest you to listen carefully on the podcasts on Microservices and Containers.

Greetings @ Toronto

El Bruno

Source: http://www.darkroastedblend.com/2006/12/biggest-ships-in-world-part-3.html

#Podcast – Introduction to #Microservices (spanish)

image

Hi !

I’ve got the idea to do a MicroServices podcast since a couple of weeks. And thanks to the post I wrote about Master de FrontEnd de LemonCoders, I’ve get back in touch with Pedro J Molina. And, you know, Pedro is a reference on this, so we decided to record this podcast.

In this episode, we talk about what are microservices and the correct context to work with this. We review some basic concepts, like security, tools, frameworks, APIs managements and more. Some other topics like  DDD, agile architectures, SCRUM y Continuous Delivery also were part of the talk. And, we of course get back to the references of Netflix, Amazon and Azure.

At the end, we make some guess on the future of this, and if this will really make a mark on the way that we develop apps today.

Ir a descargar

I hope you enjoy this, I need to share that I learn a lot in less than an hour !

Some technologies:

2 videos of Pedro about Microservicios and Docker.

Greetings @ Toronto

-El Bruno

References

#Podcast – Introducción a #Microservicios

image

Hola !

Desde hace un tiempo andaba con ganas de hablar de Microservicios, y gracias al post que escribí sobre el Master de FrontEnd de LemonCoders, retomé el contacto con Pedro J Molina. Y claro, Pedro es una persona de las que más sabe sobre el tema, así que cuando dije grabar … ya estábamos poniendo fecha para grabar este podcast.

En este episodio, comentamos un poco qué son los microservicios y el contexto en el que se deben tratar los mismos. Desde conceptos de seguridad básicos, hasta las herramientas, frameworks, gestión de APIs, y otros temas que son inherentes a los microservicios. Conceptos como DDD, arquitecturas emergentes, SCRUM y Continuous Delivery también cayeron en el camino. Y, como no podía ser de otra manera, las referencias básicas de Netflix, Amazon y Azure fueron parte de la discusión.

Pedro también nos llevó a la interesante discusión sobre Monolito primero o microservicios primero. Y al finalizar, hablamos un poco sobre si esto es una moda pasajera, o es algo que realmente dejará huella en la forma en la que hacemos aplicaciones en estos días.

Espero que lo disfruten, yo he de decir que he aprendido mucho en menos de una hora!
Ir a descargar
Algunas Tecnologías comentadas:

Y finalmente 2 videos de Pedro sobre Microservicios y Docker.

Saludos @ Toronto

-El Bruno

References

 

[#ALM] Why not use branches or not do something not useful in your app devs

Hello!

Since there are several people who have been amazed with my statement on not to use branches, I better explain this a little more. To do this I’ll share a story which happened to a cousin brother of the brother-in-law of a neighbor, called Paco.

-Paco had a request Milagros (his customer) to make an iOS app for a 15 days promotion of a beauty cream for hands. This promotion started in little over 2 months.

-In this type of projects Paco usually worked with Lucia, she is an UX expert, and also knew how to manage iOS apps

-Paco (cool!) is a Xamarin developer, so taking advantage of Visual Studio Online, Paco gave permissions to Lucia and Milagros in a VSOnline instance

-Paco coordinated with Lucia and Milagros to work in 2 sprints, each one will be a 3 week duration. He also is defining this time box thinking in the leap between Sprints and possible changes. At the end they all agreed on this model.

-Paco create the basic elements and they started to use TFS as repository, work was started!.

-After of the 2nd Sprint, Milagros was Happy Happy with the application, so she give a GO to Paco and Lucia to coordinate with the Marketing team for the publication and promotion of the application.

So here ends the story of Milagros, Lucia and Paco and I asked myself…

Where are the branches? Maybe nowhere, Paco never had the need to use branches; SO HE DIDN’T CREATED!

Caution! I do not mean that create and use branches is bad. For sure Paco when he was testing or making changes, had a local Git repo with his changes, tests, branches, etc; but why does he have to create a branch to share with Lucia and Milagros?

This bring us to the bases of the branch managing: if we work in an app will not have later versions, why do you have to create a DEV – MAIN – RELEASES schema?  At this point there is no idea that the application will have continuity so … what for?.

One of the excellent features of TFS and GIT is that anytime you can create a branch and start working with branches. So when the the scenario request this feature, you can start and define a scheme of branches.

Proably you think that this sample is kind of crazy (It is!). I’m trying to share a message in the background: not add XYZ to you apps when you are creating applications, if XYZ does not add value to the application that you are creating!. For example, why create an app that supports multiple cultures? if you know that that is not necessary.

If when a Sprint ends, the PBIs changes, get new changes; PO puts on the table new features that require changes in the architecture or the way of working… don’t feel bad, the architecture will emerge naturally to accommodate those changes.

What you should not do is to think in advance in scenarios that do not apply and that only complicate your application. The phrase that sums up all this, leaves the app architecture and the app itself to emerge and to adapt with the same time as the business context of the app, … and obviously relies on your team and let the team to decide.

Note: If a dev writes applications regardless of the bases of a good app developer, as for example a correct exceptions management, it is to cut off his fingers. Once a developer replied “I did an application that handles exceptions correctly because the PO not asked for this “… This serves to measure the quality of a person and also is a good opportunity to test the edge of a Katana.

Saludos @ Home

El Bruno

image image image Google

[#ALM] Porque no usar ramas o no te pases 4 pueblos con lo que haces con tus desarrollos

Hola!

Ya que hay varias personas que se han quedado asombradas con mi declaración de no usar ramas, mejor les cuento lo que le pasó al primo del hermano del cuñado de un vecino, llamado Paco.

– Paco tuvo una petición de un Milagros (un cliente) para hacer una app para iOS para una promoción de 15 días de una crema para manos. Esta promoción comenzaba dentro de poco más de 2 meses.

– En este tipo de proyectos Paco trabajaba con Lucía que era una experta en UX, y además sabía como gestionar apps para iOS

– Paco (lo flipas) era un Xamarin developer, así que aprovechando Visual Studio Online, Paco dió de alta a Lucia y a Milagros en VSOnline

– Paco se coordinó con Lucia y Milagros para trabajar en 2 sprints de 3 semanas. Teniendo en cuenta el salto entre Sprints y los posibles cambios, todos estuvieron de acuerdo en este modelo.

– Paco creo los elementos básicos de trabajo y utilizando TFS como repositorio comenzaron a trabajar.

– Luego del 2do Sprint, Milagros estaba Happy Happy con la aplicación, así que le dió el visto bueno a Paco y Lucia para coordinar con el equipo de Mkt la publicación y promoción de la aplicación.

Pues aquí termina la historia de Milagros, Lucia y Paco y yo me preguntó …

¿Dónde están las ramas? Pues en ningún lado, Paco NO TUVO NECESIDAD DE CREAR RAMAS; ASI QUE NO LAS CREÓ !!!

Ojo, con esto no quiero decir que crear ramas sea malo. Seguramente Paco cuando hacía pruebas o cambios, tuvo un repo local de Git con sus cambios, pruebas, branches, etc; pero ¿para crear una rama que compartiría con Lucía y Milagros?

Vamos al escenario más básico: si además es una app que no tendrá versiones posteriores, ¿para qué crear un esquema DEV – MAIN – RELEASES? Si en este momento no hay seguridad de que la aplicación tenga continuidad.

Una de las features excelentes de TFS y de GIT, es que en cualquier momento puedes crear una rama, asi que; si se presenta el caso de una versión posterior o una con nuevas funcionalides, EN ESE MOMENTO CREAS UN ESQUEMA DE RAMAS.

Si piensas que el ejemplo está muy agarrado de los pelos (que lo está!); voy a intentar con el mensaje de fondo: No metas XYZ cuando creas aplicaciones, si XYZ no aporta valor a la aplicación que se está creando!. Por ejemplo, ¿para que crear una app que soporte múltiples culturas? si desde el día cero sabes que eso no es necesario.

Si luego al finalizar un Sprint, los PBIs cambian, surgen nuevos; el PO pone sobre la mesa nuevas funcionalidades que requieren cambios en la arquitectura o la forma de trabajo … tranquilo, la arquitectura emergerá de forma natural para dar cabida a esos cambios.

Lo que NO DEBES HACER es pensar por adelantado en escenarios que no apliquen y que solo compliquen tu aplicación. La frase que resume todo esto, es DEJA QUE LA ARQUITECTURA Y TU APLICACION EVOLUCIONE A MEDIDA QUE LA MISMA SE ADAPTA AL NEGOCIO … y obviamente confía en tu equipo y deja que sea el equipo el que decida.

Nota: Dicho esto, si alguno escribe aplicaciones sin tener en cuenta las bases, como por ejemplo una correcta gestión de exceptiones, es para cortarle los dedos. Es increible como una vez un developer respondió “no hice una aplicación que maneje excepciones porque el PO no lo pidió” … esto sirve para medir la calidad de una persona y para probar el filo de una Katana.

 

Saludos @ Home

El Bruno

image image image Google

[#SCRUM] Arquitecture must emerge (f#@*s* the classic architects!)

Hello!

Merry Christmas and if someone did not understand the title, is “Forget the architects!“. During recent years, when I worked in large organizations; I always found the “Architecture Team”. This team can be formed by one or more people and they are usually the ones in charge of great architecture decisions for the teams that finally develop products or applications.

This process is usually very bureaucratic, and this means that development teams have to wait X time (let’s say 3 months) before they can start to build software. In addition to all the problems that this waterfall approach includes; the more general scenario is that when the construction of software starts, changes and modifications must have to be implemented by the architecture team, then shared with team development and… back to start.

That’s break with all the principles for practices like SCRUM. A team that practices SCRUM let’s that architecture emerges as the software is built. Although we are accustomed to planning aspects of architecture, must understand that this approach does not leave out the architecture of software but instead it focus on provide value to the software at the same time that the software is built.

This is not an easy task and requires very good skills in a team (Professional, not amateur teams); Personally I still don’t feel comfortable without an initial design. Surely the first steps will be false, and we will have to return back several times before finding the right approach. However, this is the basis of an emergent process (planning incremental or incremental design). We have to accept the reality of not knowing all the variables that affect us as a team at the beginning of the project and one time assumed this reality start to work (and to rework in many cases). Finally, we have to understand that the benefits of the rework are when the product begins to take shape.

Of course that all this work / rework should be without impairing the quality with good practices such as continuous integration, BDD, etc. Here I refer to the great Rodrigo Corral when he wrote about “the quality in the software is not optional” (long time ago but still a great post).

A phrase or principle which is good to take into account if you want to get started with this approach is

Think Big, Act small, Fail fast and Learn Rapidly

This quote is from the book “Lean Software Development” of Mary and Tom Poppendieck and it represents the basic principles with which a team must work in only 4 sentences. If you move it to the day of a developer, you will understand it right away; and if you think about it from the point of view of a “software architect”, you will see that the principle is the same.

Another important point to keep in mind is that all decisions of architectures should be supported by code. The role of experts in Visio is not longer needed, emerging architectures are those that are part of a product, with its set of tests and finally proven product that is built. I’m not saying that it is necessary to forget about diagrams and drawings, but these diagrams represent existing code, which is where actually lives a product .

Note: In this regard, Visual Studio ALM does an excellent job!

Resources:

  • My vision about the cone of uncertainty (link)
  • The quality of the software is not optional (link)
  • The Land that Forgot scrum by Uncle Bob (link)

Greetings @ La Rancherita

The Bruno

imageimageimageGoogle

[#SCRUM] Arquitecturas emergentes (f#@*s* the classic architects!)

Hola!

Feliz Navidad y si algún malpensado no entendió el título, es “Forget the architects !!!”. Durante los últimos años, en grandes organizaciones siempre me he encontrado al “equipo de arquitectura”. Este equipo, puede estar formado por una o más personas y usualmente son los encargdos de tomar grandes decisiones de arquitectura para los equipos que desarrollan productos o aplicaciones.

Este proceso suele ser muy burocrático, y esto significa que los equipos de desarrollo tienen que esperar un tiempo X (digamos 3 meses) antes de poder a comenzar a construir software. Además de todos los problemas que tiene un enfoque waterfall como el que describo, la situación mas general es que cuando se comienza la construcción de software, surgen cambios y modificaciones que tienen que ser implementadas por el equipo de arquitectura, luego compartidas con el equipo de desarrollo y … de vuelta a empezar.

Los 2 párrafos anteriores rompen con todos los principios que proponen prácticas como SCRUM. Un equipo que practica SCRUM deja que la arquitectura emerja a medida que se construye el software. Si bien estamos acostumbrados a planificar los aspectos de la arquitectura, debemos comprender que este enfoque no deja de lado la arquitectura de software sino que deja que la misma vaya aportando valor al software que se construye a medida que el mismo avanza.

Esto no es una tarea fácil y requiere de equipos altamente suficientes (equipos profesionales no aficionados); personalmente yo todavía no me siento cómodo sin un diseño inicial. Seguramente los primeros pasos serán en falso, y tendremos que volver sobre los mismos varias veces antes de dar con el enfoque correcto. Sin embargo, esta es la base de un proceso emergente (en inglés queda mejor incremental planning o incremental design). Tenemos que aceptar la realidad de no conocer todas las variables que nos afectan como equipo al principio del proyecto y una vez asumida esta realidad comenzar a trabajar (y a hacer rework en muchos casos). Finalmente tenemos que comprender que los beneficios del rework se ven cuando el producto comienza a tomar forma.

Por supuesto que todo este trabajo / rework se debe realizar sin perjudicar la calidad con buenas prácticas como integración continua, BDD, etc. Aquí me remito al gran Rodrigo Corral cuando escribió sobre “la calidad en el software no es opcional” (y mira que tiene años el post). Una frase o principio que es bueno tener en cuenta si quieres comenzar a trabajar con este enfoque es

Think Big, Act small, Fail fast and Learn Rapidly

(traducción by el Bruno: Piensa en grande, actúa en pequeño, equivócate a menudo y aprende rápidamente)

Esta frase del libro “Lean Software Development” de Mary y Tom Poppendieck representa en 4 sentencias los principios básicos con los que un equipo debe trabajar. Si lo trasladas al día a día de un desarrollador, lo comprenderás enseguida; y si lo piensas desde el punto de vista de un “arquitecto de software”, verás que el principio es el mismo.

Otro punto importante a tener en cuenta es que todas las decisiones de arquitecturas tienen que estar soportadas por código. Se acabó el rol de los expertos en Visio, las arquitecturas emergentes son aquellas que son parte de un producto, comprobadas con su set de tests y finalmente probadas por el producto que se construye. No digo que es necesario olvidarse de diagramas y de dibujos, sino que estos diagramas representan código existente, que es donde realmente vive un producto.

Nota: En este aspecto Visual Studio ALM hace un trabajo excelente !!!

Recursos:

  • Mi visión sobre el cono de incertidumbre (link)
  • La calidad en el software no es opcional (link)
  • The Land that scrum Forgot by Uncle Bob (link)

Saludos @ La Rancherita

El Bruno

image image image Google

Patterns and Practices Security Wiki

Otra cosita interesante en Channel9.

Esta vez, presentan online Patterns and Practices Security Wiki, donde podemos ver los aportes y sugerencias para el desarrollo de aplicaciones seguras, que surgen de la gente de Microsoft y que nosotros mismos podemos complementar. Si nunca has usado un Wiki, hay un pequeño manual de instrucciones y ejemplos de utilizacion del mismo.

Saludos