DEV Community: Alejo Villores

Microservicios, lo que aprendí.

Alejo Villores — Tue, 27 Dec 2022 13:45:07 +0000

Introducción

Estos últimos cuatro meses, encaramos un proyecto bastante grande a como veníamos trabajando en los últimos 4 años de facultad. La consigna principal era simular un ambiente de trabajo para un junior/trainee, es decir, uno llega y se encuentra con miles de cosas por aprender y aplicar en poco tiempo.

El proyecto constaba de realizar una aplicación mobile utilizando una arquitectura de microservicios, ésta debía estar implementada en al menos dos lenguajes de programación diferentes y utilizando dos tipos de bases de datos distintas. Sumado a esto, debíamos desarrollar un panel de administradores web.

En el equipo eramos 5 personas, todos sin experiencia previa de ese nivel. Estas son las cosas que observe y aprendi, por afuera de lo desarrollado.

Compromiso de equipo

Comenzamos proponiendo en un Notions diferentes convenciones que íbamos a utilizar para poder estar todos alineados, en las primeras semanas preparamos los repositorios y propusimos utilizar los Boards que permite GitHub utilizando las diferentes Historias de Usuarios como Issues.

La principal observación que vi es que es muy difícil generar que cada integrante del equipo siga a raja tabla el proceso, como se refleja esto? Principalmente se pueden ver Issues cerradas pero sin estar en el board, branches muertas y falta de milestones en cada semana de desarrollo.

Tecnologias

Como equipo, nos encontramos que debiamos aprender muchisimas cosas nuevas en poco tiempo, como siempre, al ser la primera vez las cosas cuestan mucho mas. No tuvimos problema en aprender las herramientas nuevas, si confieso que a mi parecer la inexperiencia hacia que varias implementaciones sean rústicas, pero creo que eso va mejorando a medida que uno desarrolla y usa aquella tecnología cada vez mas.

En nuestro caso utilizamos.

Python - Fast API
NodeJS - Express
Postregs SQL
MongoDB
Firebase
Datalog
React Native
Expo
React

Despliegue y Testing

Desarrollar utilizando TDD es algo de lo que venimos haciendo hace varios cuatrimestre, son pocos los que de verdad siguen aplicando test, muchos para safar implementa a prueba y error. Esto es algo común en aplicaciones de consola pequeñas, pero en una app web mas grande es algo arriesgado, es por eso que nos propusimos testear lo que mas se pueda.

Para el despliegue utilizamos Okteto, que utiliza kubernetes y a partir de un docker-compose.yml levanta el ambiente. Tiene una versión FREE que para nuestro proyecto la verdad que venia excelente.
Tuvimos dos ambientes, el local, utilizando contenedores de Docker y el de producción. Hubiera sido eficiente también tener uno de test.

Una cosa que notamos positiva de los microservicios, es que teníamos quizás alguno caído pero como la aplicación no lo utilizaba, esta podía estar funcionando correctamente, lo cual con un monolito esto no es posible.

Desarrollo

Para completar con lo pedido planteamos una arquitectura de 5 servicios + una API GATEWAY

Al estar trabajando con microservicios, podíamos dividirnos los servicios y avanzar mucho mas rápido que al ser un monolito.
La complicación estaba en la conexión de datos entre servicio. Con esto quiero decir que las restricciones de las claves foráneas entre servicio es algo a tomar con pinzas, a diferencia de un monolito que solo utiliza una db.

La seguridad también fue algo a tener en cuenta ya que todos los servicios tenían que estar alineados para entender los mismo JWT que tenia el usuario.

Utilizamos firebase para la autenticación segura. Al principio nos complicó la extensa documentación que tiene pero le pudimos agarrar la mano.
Aqui se ve el flujo que utilizamos para el servicio de administradores.

Conclusión

Creo que hicimos un buen trabajo, pusimos mucho esfuerzo y compromiso, logramos cumplir con las historias de usuarios obligatorias del trabajo y muchas electivas que aportaban usabilidad.
Quedaron algunas deudas técnicas para un futuro pero la aplicación quedo bastante buena y como equipo, estamos orgullosos de nuestro trabajo.

Basta de usar else innecesarios!

Alejo Villores — Wed, 27 Apr 2022 15:30:23 +0000

Cuantas veces hemos visto código de condicionales del tipo

def myFunction(){
   if (condition1){
     do something ...
   }else{
     do another thing
   }
   return result

Si bien, no es algo que este mal, podemos refactorizar nuestro código para que el flujo de la lectura sea mas placentera.

Para poder realizar esto, lo que haremos es tomar lo que esta dentro del else, y ponerlo abajo del if, será ahora una consecuencia de que no se haya cumplido el if, que cambiará solo si la condicion se cumple.

Miremos un ejemplo sencillito

Usando if/else

def dividirEnteros(divisor, dividendo){
   if (divisor == 0){
     print("No se puede realizar dicha operacion")
     return -1
   }else{
     resultado = dividendo / divisor
    return resultado   
   }

Usando solo if

def dividirEnteros(divisor, dividendo){
   resultado = 0
   if (divisor == 0){
     print("No se puede realizar dicha operacion")
     return -1
   resultado = dividendo / divisor

   return resultado

Veamos que si lo extendemos a casos mas complejos, su potencial aumenta.
Imaginemos que tenemos que checkear que ciertos datos esten correctos, algo que es muy comun de ver es una cadena de if anidados

def myFunction(){
   if (condition1){
     si condicion1 se cumple, miro la condicion 2
     if (condition2) {
        si la condicion 2 se cumple, miro la 3 y asi hasta n...
        operaciones
     }
     else {
       operar distinto
     }
   }
   }else{
     do another thing
   }
   return result

Luego de 2 ifs, la cosa se pone pesada para comprender la función.
La solución a esto, es proponer un sistema de capas de control, cada capa tendrá una condicion que representa un nivel.De esa manera nuestro código queda de la siguiente manera.

def myFunction(){
   inicializacion...
   if (!condition1){
     hacer cosas
   }
   hacer otras cosas

   if (!condition2) {
     hacer cosas
   }
   ...
   hacer otras cosas
   return result

Integración Continua

Alejo Villores — Wed, 03 Mar 2021 14:26:14 +0000

La integración continua es una práctica de desarrollo de software donde los miembros de un equipo integran su trabajo con frecuencia, al menos una vez al día.

Cada integración es verificada por una compilación automatizada para detectar errores lo más rápido posible. Muchos equipos encuentran que este enfoque conduce a problemas de integración significativamente reducidos y permite que un equipo desarrolle software cohesivo rápidamente.

Hoy en día existen muchas herramientas de código abierto para trabajar con la integración continua. Por ejemplo, en nuestro último proyecto usamos CI Travis.

Prácticas de integración continua

MSSR (Maintain a Single Source Repository), esto significa que el proyecto completo debe estar todo en un repositorio.
Automatice la compilación, utilice las herramientas gratuitas para que su trabajo sea más rápido y seguro.
Haz que tu compilación se auto testee.
Cuando trabajamos con un equipo, comprometernos todos los días con la línea principal de nuestros proyectos informa a los otros desarrolladores sobre los cambios. Por tanto, la ** Integración continua ** permite a los miembros del equipo conocer los cambios rápidamente.
Repare las compilaciones falladas de inmediato.
Prueba en un clon de los entornos de producción..
Automatizar despliegues.

La integración continua puede reducir los riesgos, facilitar la búsqueda de errores y ayudar con la comunicación del equipo.

para obtener más información sobre Integración continua, sugiero leer a Martin Fowler

Continuos Integration

Alejo Villores — Wed, 03 Mar 2021 14:16:40 +0000

Continuos integration is a software development practice where members of a team integrate their work frecuently, at least one time per day.

Each integration is verified by an automated build to detect errors as quick as posible. Many teams finds that this approach leads to significantly reduced integration problems and allow a team to develop cohesive software rapidly.

Nowadays there are a lot of open source tool to work with continuos integration. For example,in our last project we used CI Travis.

Practices of continuos integration

MSSR (Maintain a Single Source Repository), this mean that the complete project should be all in one repository.
Automate the build, use the free tools to make your work faster and safer.
Make your build self testing.
When we are working with a team ,commiting everyday to de mainline of our projects tells the other developers about the changes. So Continous Integration allows teammembers to know changes quickly.
Fix broken builds immediately.
Test in a clone of the production enviroments.
Automate deployments.

Conclutions

Continuos integration can reduce risks, make you find bugs easier and helps with the team comunication.

for more information of Continuos Integration I suggest to read Martin Fowler

Buenas prácticas

Alejo Villores — Mon, 25 Jan 2021 22:28:03 +0000

Las buenas prácticas de la programación.

En este artículo hablaremos de lo que son las buenas prácticas a la hora de trabajar en equipos con otros desarrolladores, la intención de este post NO es hablar sobre los principios SOLID sino, que hablaremos sobre hábitos que todo programador debe conocer para poder estandarizar y entenderse con su equipo al momento de escribir código.

Partamos de una serie de ítems que nos ayudará a organizarnos un poco.

Legibilidad

Como todo desarrollador sabe, el código se escribe una vez y se lee muchas veces, es por eso que la legibilidad es muy importante a la hora de trabajar.
Sangrías, espacios, intention-revealing names, etc. Estos son algunos conceptos que hace que el código no parezca un espagueti y sea mas fácil de leer/entender a para los demás.

Comentarios

Un código no necesita comentarios para que otro lo entienda si éste esta escrito correctamente y sigue los pasos del item anterior por lo que es correcto decir que escribí de manera que el código hable solo...

No sorprender

En el mundo de la programación la simpleza es lo mejor que puede haber a la hora de escribir software por lo que evitar sorprender con algoritmos complejos para problemas simples es lo ideal.

Idiomas

Este tema es complicado pero a la hora de escribir funciones, nombres y clases evitemos utilizar mezclas de lenguajes ya que genera malentendidos en la lectura del código. En lo personal me gusta nombrar a los getters y setters en español ya que facilita muchísimo a la hora de leer.

Índices

Los índices tradicionalmente y globalmente son i,j,k por lo que evitemos cambiarlos si es que vamos a compartir nuestro trabajo a otras personas.

Variables booleanas

A la hora de utilizar variables booleanas es convenientes pensarlas en positivo, por ejemplo encontrado, terminado,etc.

Estos son las buenas prácticas que yo aprendí.
Me encantaria saber cuales son las que ustedes aprendieron y saben asique sus comentarios y opiniones son bienvenidas.

Saludos!

Test-Driven-Development

Alejo Villores — Wed, 06 Jan 2021 22:07:03 +0000

Primero hablemos sobre el desarrollo comenzando por las pruebas, éstas acarrean algunas ventajas, tanto de orden técnico como metodológico. Aquí algunos ejemplos:

Al escribir antes las pruebas, las mismas se convierten en especificaciones de lo que se espera como respuesta del objeto ante el envió de un determinado mensaje. Por lo tanto, no se debería codificar nada que no tenga su prueba de antemano, de modo tal de no implementar nada innecesario.
Al ir definiendo de a una prueba a la vez, tenemos un desarrollo incremental genuino, definido por pequeños incrementos que se corresponden con funcionalidades muy acotadas.
Permiten independizarse del factor humano, con su carga de subjetividad y variabilidad en el tiempo haciendo que sean mas optimas y precisas.
Al necesitar éstas un costo muy bajo para poder ser ejecutadas, generan que el programador genere un hábito de testear y a su vez le de cierta confianza en que su código esté correcto o pase la prueba.

Y el TDD? Ahí va...

Ésta forma de trabajar fue propuesta formalmente por el señor Kent Beck donde habló sobre una práctica de desarrollo denominada Test-Driven-Development.
Ésta práctica nos obliga a pensar a través de la interfaz necesaria antes de desarrollar

Según Beck TDD incluye tres practicas fundamentales:

Test-First: Escribir las pruebas antes del código.
Automatización: Las prubas deben correr con la mínima intervención humana.
Refactorización.

Muy lindo hasta ahora pero, cuales son los pasos para aplicar TDD?
Pasos para aplicar TDD

Escribir el test, el cual no pasará.
Agregar el mínimo código posible para que la prueba pase.
Refactorizar.

Fácil no? Claro que si!.
De esta manera el desarrollador podrá avanzar de manera mas lenta pero segura... siempre hay que tener en cuenta hacer baby steps.

Partes del post fue obtenido del libro del Profesor
Carlos Fontela de la Facultad de Ingeniería de la Universidad de Buenos Aires.