Hace un buen tiempo que no escribo nada, de hecho han pasado más de 3 años desde mi último artículo, la verdad que la vida se interpone en el camino y es difícil seguirle el ritmo a todo, acomodar las prioridades y dedicarse a las cosas que uno le gusta.

Si me preguntas que estuve haciendo estos años? La verdad que no puedo decirte una cosa puntual, esto hasta me da vergüenza.

* No terminé de aprender un lenguaje de programación funcional.
* No soy un experto en computer science o algoritmos, de hecho sigo teniendo esas cosas en mi lista de metas para este año.

Pero seamos más específicos!, miremos linkedin, donde estaba en Marzo de 2021, cuando escribí mi último artículo?

* Acababa de entrar a Proxyclick, mi segundo trabajo en Bélgica, luego de haber estado los últimos 3 años en Xpenditure, intentando pasar a trabajar full remoto.
* Tenía 5 años de experiencia pero no me sentía un senior, que va, todavia no me siento senior. Hoy mirando para atrás diría que probablemente era un sólido intermediate (semi senior en Argentina)
* Mi stack principal era C# en el backend y Angular en el frontend. JavaScript/TypeScript y React era algo que usaba en proyectos personales pero no tenía experiencia profesional con estos lenguajes.

Y que paso despues?

* Trabajé en Proxyclick remoto hasta 2023, incluso termine mudándome a España y seguí trabajando para ellos como contractor (autónomo). Luego conseguí otro trabajo con una empresa americana
  en la que estuve 1 año, y ahora estoy de vuelta en una empresa Belga, remoto, trabajando con muchos ex compañeros de Xpenditure, la empresa que me dio la primera oportunidad fuera de Argentina.
* Ya estoy pisando los 9 años de experiencia, tengo un puesto de senior full stack pero me cuesta sentirme un senior, trabajo en un producto complejo con gente extremadamente capaz por lo que me termino comparandome con ellos.
* Mi stack principal es TypeScript y React. Como objetivo personal quiero aprender Golang pero me esta costando sentarme a programar.

Mirándolo así la verdad es que me es más sencillo comparar donde estaba antes, que sabía y que no.
Durante estos años trabajé sobre arquitecturas distribuidas, blockchain, encare proyectos grandes yo solo e incluso tuve desarrolladores con menos experiencia bajo mi dirección.
Trabaje con managers que cambiaron mi perspectiva del software para siempre (shoutout a JP y Danny, espero tener el placer de volver a trabajar con ustedes algun dia)

Hice cientos de entrevistas, coding challenges, leí libros, intenté aprender lenguajes y fracaze, hice proyectos personales, e incluso hice algo de dinero con alguno de ellos.

Entonces, ¿Por qué estoy escribiendo otra vez? ¿Cual es el objetivo? La verdad que hay varias razones:

* Compartir mis opiniones, hablar de temas que me resultan interesantes, esperando que me comenten o contacten para hablar del tema.
* Ayudarme a estudiar, es mas facil para mi sentarme a programar y estudiar si se que después tengo que escribir al respecto acá, es una manera de armarme un proceso de aprendizaje.
* Me ayuda con el imposter syndrome, es fácil perder de vista el progreso si no se lo trackea, un blog es una manera de mantener este registro.

Además del blog mantendré un [repositorio](https://github.com/Raagh/learning) para marcar lo que aprendo.
Así que espero tener muchos artículos listos en el futuro, enfocandome en distributed systems, golang, software architecture y algunas otras cosas como mindset, linux y teclados mecánicos 😊

Si hay algún tema que te gustaría que cubriera por favor no dudes en escribirme un comentario.

Hasta la próxima


Levantarse despues de un KO

Hola chicos, ¿cómo han estado? ¿yo? He estado trabajando mucho en un nuevo proyecto que estoy construyendo con la ayuda de un amigo, no discutiré los detalles aquí, pero probablemente me escucharán hablar de ello muy pronto. Hoy quiero hablar sobre una de las selecciones tecnológicas que hice para construir este proyecto.

Necesita construir una API, usando node, usando TypeScript, he escuchado muchas cosas geniales de este framework de backend llamado [Nest.js](https://nestjs.com/) pero no lo había probado yo mismo. Ahora, después de una semana de programar la API, tener varios endpoints, autenticarse, conectarse a una base de datos y todo eso, les daré mi opinion. Pero comencemos desde el principio.

***

## ¿Qué es Nest.js?

De la documentación en sí obtenemos esta respuesta:

> Un marco progresivo de Node.js para crear aplicaciones del lado del servidor eficientes, confiables y escalables.

Eso no dice mucho, ¿verdad? bueno, en mis propias palabras, Nest.js es un framework de Node.js construido sobre [express.js](https://expressjs.com/) y [TypeScript](https://www.typescriptlang.org/) que viene con una fuerte opinión sobre cómo se deben construirse las API. Dado que es muy opinionado, proporciona una estructura, una CLI y una cantidad casi infinita de herramientas que te permiten crear API profesionales muy, muy rápido.

Supongo que sería como Django para Python o asp.net Core para C#.

## ¿A qué se parece?

Bueno, como con la mayoría de los frameworks de API, Nest.js define los endpoints a través de una entidad llamada `Controller`.

```typescript
import { Controller, Get } from "@nestjs/common"

@Controller("cats")
export class CatsController {
  @Get()
  findAll(): string {
    return "This action returns all cats"
  }

  @Get(":id")
  findOne(@Param("id") id: string): string {
    return "This action returns one cat"
  }
}
```

Para mí, viniendo de C#, ver esto en JavaScript es un placer, pero supongo que puede ser extraño para ustedes, los noders, así que permítanme explicarles todas las cosas magicas que están sucediendo allí.

Este `Controller` creará 2 endpoints en las rutas `{url}/cats` y `{url}/cats/{id}`, el id de la url en el segundo endpoint se asignará automáticamente al parámetro id en el método. Estos tipos de etiquetas `@Get()` se llaman decoradores y hay un montón de ellos, puedes usarlos para definir el método HTTP, para obtener propiedades, para definir la autenticación, básicamente lo que quieras.

**Pero, ¿dónde escribes tu lógica de negocio? podras preguntar.** Bueno, Nest.js te tiene cubierto, para eso usarás una entidad llamada `Service`

```typescript
import { Injectable } from "@nestjs/common"
import { Cat } from "./interfaces/cat.interface"

@Injectable()
export class CatsService {
  private readonly cats: Cat[] = []

  create(cat: Cat) {
    this.cats.push(cat)
  }

  findAll(): Cat[] {
    return this.cats
  }
}
```

Nada demasiado extraño aquí, excepto, ¿qué está haciendo ese decorador `@Injectable` ?. Nest.js viene con `Dependency Injection` de forma predeterminada, este decorador define qué dependencias se pueden inyectar en otros componentes a través de sus constructores.

**Esto parece que va a terminar siendo una gran cantidad de código, ¿hay una manera fácil de administrar las dependencias?** sí, la hay. Puedes empaquetar la funcionalidad usando Módulos, son como Módulos de node, pero en Nest.js puedes tener `Controllers`, `Services` y más dentro de un Módulo que representa una funcionalidad especifica, luego inyectar ese módulo completo en otros para usarlo allí.

```typescript
import { Module } from "@nestjs/common"
import { CatsController } from "./cats.controller"
import { CatsService } from "./cats.service"

@Module({
  controllers: [CatsController],
  providers: [CatsService],
})
export class CatsModule {}
```

**No veo ninguna mención de cómo conectar una base de datos, ¿hay algo así?**. ¿No te dije que Nest.js es bastante obstinado? como tal, viene con una forma de trabajar con bases de datos. Entra [TypeORM](https://typeorm.io/#/) a la cancha.

En lugar de hacer consultas manualmente usando SQL, usamos un Modelo Relacional de Objetos. Para trabajar con la base de datos, definimos las entidades de la base de datos que luego se usarán para crear las tablas al iniciar la API y usamos los `Repositorios` creados en base a nuestro modelo de base de datos.

```typescript
import { Entity, Column, PrimaryGeneratedColumn } from "typeorm"

@Entity()
export class Cat {
  @PrimaryGeneratedColumn()
  id: number

  @Column({ length: 500 })
  name: string

  @Column("text")
  color: string
}
```

## Parece súper complicado, ¿para quién es?

Mentiría si dijera que todos los que empiecen a jugar con Nest.js serán productivos de inmediato.

* Nest.js sigue un patrón muy orientado a objetos, que no es algo que veamos muy a menudo en el mundo de JavaScript.
* Si solo conoces los lenguajes tipados dinámicamente, será difícil hacer un cambio debido a que Nest.js usa TypeScript.

Por otro lado, si vienes de un lenguaje como C#, TypeScript te hara sentir como en casa (en realidad fueron diseñados por el mismo programador). Además de eso, si vienes de esa rama probablemente usaste un framework como asp.net Core y sabes exactamente qué es un `Controller`, probablemente creaste una arquitectura en capas y usaste la palabra `Service` para definir tu lógica de negocio incluso antes de ver una sola línea de código usando Nest.js.

**Pero nunca he hecho backend, ¿puedo tomar Nest.js como mi primer proyecto?** Depende.

Nest.js será más fácil para ti si vienes de Angular que si vienes de React.

Todos los patrones arquitectónicos de Module, Dependency Injection, Decorator que utiliza Nest.js están muy inspirados en Angular, son casi como primos, y si vienes de Angular, ya conocerás TypeScript, por lo que elegir Nest.js será una decision obvia.

***

## Conclusión

Probablemente sepas que voy a decir que realmente me gusta Nest.js, bueno, sí, parece un gran framework para crear API's de node.js confiables, proporciona toneladas de funcionalidad lista para usar, y si deseas hacer algo especial, su documentación es simplemente excepcional. Si vienes de uno de los orígenes que mencioné anteriormente o simplemente quieres aprender algo nuevo, definitivamente te recomendaría que pruebes Nest.js 🤞.

Como siempre, si te gustó esta publicación, compártela, ¿has probado Nest.js? ¿Quieres saber algo específico? avísame a continuación en los comentarios 🙂


One week with Nest.js, is it good?

Una semana con Nest.js, ¿está bueno?

Durante bastante tiempo he estado pensando en comprarme mi propia computadora portátil. Durante los últimos 3 años y medio he estado usando una Macbook Pro que pertenece a mi empleador (bueno, ahora mi empleador anterior).
La computadora funcionó bien, tiene un gran rendimiento, una gran pantalla, un trackpad increíble (aunque un teclado terrible), Windows 10 funcionó muy bien usando `Parallels`. Pero durante bastante tiempo no me sentí cómodo con varias cosas.

## El problema

0. La computadora no era mía. Alguien tenía un dicho sobre lo que podía y no podía hacer con la computadora.
1. El sistema operativo funcionaba muy bien cuando no lo tocaba demasiado, una vez que quería instalar un conjunto de herramientas poco populares (hola `haskell-language-server` 👋) se te acaba la suerte.
2. Sabía que tendría que devolver mi computadora una vez que cambiara de trabajo, lo que hizo que me diera pocas ganas de personalizar e instalar cosas porque sabía que tendría que comenzar desde cero luego.
3. MacOS, como la mayoría de los sistemas operativos, no son personalizables, aparte del fondo de pantalla, tal vez un fondo oscuro y algún tinte que generalmente no hay mucho mas que haer. Siendo un tipo que pasó años probando ROMs personalizadas en Android hasta el punto de compilar las suyas propias, no podia soportarlo más.

Entonces, después de considerar mis opciones y verificar mi cuenta de ahorros, decidí que era hora de comprar una computadora portátil, la primera en mi vida, e instalar Linux una vez que la tenga.

***

## La búsqueda

De hecho, pase meses buscando la computadora portátil adecuada, soy un bastardo quisquilloso, así que no iba a comprar cualquier computadora portátil Linux.

Debo decir que viniendo de un MacBook Pro, la búsqueda fue más difícil de lo que pensé. Puedo haber odiado a Apple en los párrafos anteriores, pero la verdad es que Apple fabrica productos excelentes, probablemente no la mejor computadora portátil en ninguna categoría específica, pero sí un paquete atractivo en general.
Solo me di cuenta de esto una vez que comencé a buscar una alternativa de Win/Linux.

Estas son las cosas que quería en orden de importancia:

0. I7 o AMD Ryzen 7/9
1. 32 GB de RAM (en mi MacBook pro tenía 32 GB y sentí la diferencia al ejecutar toda mi configuración de desarrollo con 16GB)
2. Buen soporte de Linux
3. Teclado en inglés de EE. UU. (Vivo en Bélgica y es muy difícil encontrar uno, la mayoría de las computadoras portátiles Win10 vienen con AZERTY belga/francés 🤮; Apple te permite elegir la distribución de teclado que desees sin importar donde vivas).
4. Pantalla >= 13,4 pulgadas de relación 16:10 y resolución 2k+(una vez que pruebas esto no hay vuelta atrás)
5. Cuerpo completo de aluminio (digan lo que quiera, pero la calidad de construcción de Apple es increíble, excepto por el teclado)
6. Lo suficientemente ligero para llevar a todos lados en mi mochila.
7. Buen teclado, gran trackpad
8. Linda

Después de meses de búsqueda, encontre solo dos opciones que cumplirían más o menos con estos requisitos.

> [La Lenovo Yoga Slim 7i Pro](https://www.ubergizmo.com/2021/01/lenovo-yoga-slim-7i-pro-ces-2021/) y la [Dell XPS 9310](https://www.dell.com/en-us/shop/dell-laptops/new-xps-13-laptop/spd/xps-13-9310-laptop).

Sí, sé que me van a recomendar otra computadora portátil, como una Thinkpad. La Yoga Slim 7Pro con AMD? tal vez la Razr Book? el Slimbook 14? Los he mirado todos y si consideras todas las cosas en la lista, notaras que todas las demás computadoras portátiles no cumplen algo.

## El ganador es...

Este viaje comenzó alrededor de junio de 2020, en diciembre todavía no tenía computadora portátil. Estaba atrapado en un ciclo de investigación y espera a que saliera un nuevo modelo o algún proveedor oscuro me ofreciera lo que estaba buscando y que pueda ser entregado a Bélgica. Finalmente, después de unas vacaciones refrescantes, decidí no esperar más y compré mi Dell XPS 9310 i7 32GB 4k 1TB NVME. Es perfecto, ¿verdad?

No tan rápido, hay cosas que desearía que fueran diferentes. 4k es demasiado, 2/3k hubiera sido perfecto para una computadora portátil de este tamaño. El modelo de 32GB viene con algunos problemas en Linux que explicaré más adelante. Realmente no me gusta la fibra de carbono que Dell usa en el interior, preferiría que se quedara con todo de metal, Dell tardó un mes en entregarla.

Pero esas son quejas menores. La computadora portátil me está brindando algunos momentos felices que me gustaría compartir con ustedes.

Después de recibir mi computadora portátil, opté por Windows 10 y Ubuntu 20.04 en dual boot.
Oye, si quieres ir a Linux, ¿por qué no ir a Arch? o Arco? o Manjaro? o PopOS?. Bueno, de nuevo, la computadora portátil no es perfecta.

Antes de comprarla, sabía que el modelo de 32 GB era un poco diferente del modelo Developer Edition de 16 GB con soporte oficial de Linux.

Solo Dios sabe por qué, pero Dell tuvo la brillante idea de utilizar otra tarjeta inalámbrica para el modelo de 32 GB. En lugar de optar por el antiguo y totalmente compatible AX201 o el AX1650, Dell decidió incluir el AX500-DBS, que cuando se lanzó el portátil aún no estaba incluido en el kernel de Linux. Sabía que se estaba trabajando para incluirlo, así que seguí adelante y lo compré de todos modos.

El controlador ahora está incluido y de a poco las distribuciones están fusionando los cambios tanto en el kernel de Linux como en el paquete de firmware de Linux. Probé muchas distribuciones y hasta ahora solo he logrado WiFi y Bluetooth completamente funcionales en Ubuntu 20.04, ni siquiera en 20.10.

Eso ya fue toda una experiencia, una patada frontal en los dientes de lo que es vivir bajo Linux, múltiples formateos, varias distribuciones, red mediante usb tethering, kernels, firmware, heathers, de todo. Después de establecerme con algo funcional, esta es mi configuración actual:

![Linux desktop](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jj6a3k1y5uosbjntz5ce.png)

![Linux tiling](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mvb7mdg5nlbz31r1l38e.png)

* Ubuntu 20.04
* Dracula Theme: GTK, GnomeShell, Vscode, GnomeTerminal, Chrome.
* PopOS Shell (tiling and app searcher)
* Eliminado atajo de actividades

# El exterior también cuenta

Una de las cosas que odiaba de la idea de cambiar de portátil era que use muchos stickers geniales en mi portátil de trabajo (como un tonto).
Suena estúpido, pero para mí, eso fue un gran problema. Afortunadamente, guardé duplicados de/logré sacar los stickers que más valoro (algunos de conferencias y meetups en mi país de origen que no volvere a conseguir).

Aquí hay una imagen de la vieja computadora portátil:

![Old laptop](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/byup38df0p15cxs87cwi.jpg)

Y este es mi nuevo bebé:

![My baby](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5r3urnt5tydcm5u68d9c.jpg)

Realmente me encanta ese nuevo aspecto, tengo un sticker de [TUX](https://en.wikipedia.org/wiki/Tux_%28mascot%29) guardado para el centro de la computadora y estoy esperando conferencias para conseguir el resto.

***

## Conclusión

Después de toda esa lucha, debes estar pensando, wow, este tipo realmente se está arrepintiendo de su decisión. Bueno, para nada, la computadora es mía. Gane la libertad de hacer lo que quiera con ella y tener una configuración de desarrollo bastante agradable que puedo llevar conmigo a todas partes. Las posibilidades de tener un entorno que me haga feliz de usar todos los días están simplemente ligadas a mi interés en aprender más sobre el sistema operativo.

Continuaré explorando y configurando, esta computadora estará conmigo durante muchos años y este viaje solo ha comenzado.

Espero les haya gustado este post, si les gustó o quieren contarme su propia historia por favor háganlo en los comentarios. Y no olviden compartirlo 🙂


New laptop, new OS. My adventure going Linux starts here.

Nuevo portátil, nuevo sistema operativo. Mi aventura en Linux comienza aquí.

La semana pasada terminé este gran libro que comenzamos a leer en el trabajo para nuestro club de lectura, se llama ["El ingeniero efectivo"](https://www.amazon.com/Effective-Engineer-Engineering-Disproportionate-Meaningful/dp/0996128107), si no lo has leído, definitivamente deberías considerarlo.

El libro tiene toneladas de buenas conclusiones, pero una que realmente me impactó fue el concepto de optimización para el aprendizaje. La idea de priorizar el aprendizaje sobre todos los demás asuntos, así que profundicemos un poco en el tema, ¿de acuerdo?

***

## Introducción

Como ya sabrás si sigues mi blog es que soy un gran defensor de cuidar tu carrera, las cosas que aprendes y cómo diriges tu desarrollo personal.

El autor del libro llega incluso a decir que debes dedicar el 20% de tu tiempo al aprendizaje, pero \*\* ¿qué significa realmente optimizar para el aprendizaje? significa elegir, entre un conjunto de caminos definidos, el que más te enseñará \*\*. El aprendizaje es una inversión que paga a largo plazo, pero es algo en lo que siempre debes concentrarte.

Hasta el momento de leer este libro, consideraba esta idea como necesaria para tener éxito en la industria del desarrollo de software y como una forma divertida de pasar tu tiempo libre.

Pero hay algunas cosas que no consideré al seguir este camino, estas son:

* Cuántos lugares hay para optimizar
* Cómo su crecimiento puede dirigirse a otros

## Optimización en múltiples frentes

Hay algunas formas de aprendizaje preestablecidas, ¿todos las conocemos verdad? Estoy hablando de ir a la escuela, tomar cursos, leer un libro, aprender un nuevo lenguaje de programación, hacer un tutorial en línea.

Estos son los primeros que me vienen a la mente cuando leo sobre siempre seguir aprendiendo, pero hay algunas cosas que me encontraron con la guardia baja.

### Elige el trabajo adecuado

A lo largo de mi carrera en el desarrollo de software, siempre me he centrado en elegir el siguiente trabajo que llevaría mis habilidades al siguiente nivel, al principio esto lo hacia inconscientemente.

Después de un año y medio en el mismo trabajo, me aburría, cuando eso pasaba, me empezaban a molestar muchas cosas y terminaba cambiando a un nuevo y emocionante rol. Me tomó algunas posiciones darme cuenta de que el problema era que después de ese tiempo dejaba de aprender, mi trabajo se volvia repetitivo, resolviendo errores en los mismos sistemas una y otra vez.

Ahora siempre elijo el próximo trabajo por lo que puedo aprender de la empresa, las tecnologías y, especialmente, el equipo. Quiero trabajar en sistemas que me muestren algo que nunca antes vi, quiero trabajar con personas más inteligentes o con más experiencia que yo. Si soy el más tonto del grupo, estaré feliz, porque eso significa que hay mucho potencial para aprender.

No me malinterpretes, no estoy diciendo que debas elegir un trabajo que no te pague lo suficiente para vivir solo por aprender algo nuevo, pero una vez que se satisfacen las necesidades básicas, el conocimiento siempre es un mejor pago que algunos billetes extra.

### No evites los golpes duros 🥊

¿Sabes cuál es la mejor forma de aprender? al fallar, al ser criticado, por alguien que denuncia tus errores.

Cuando eso sucede, no te rindes, no te quejas, solo escuchas. ¿Hay algo esencial que aprender aquí? a estas alturas ya elegiste un trabajo con mucha gente muy capacitada, ¿por qué no aprovechar ese hecho?

Me sorprendió hasta dónde se puede seguir esta regla. Tienes dos desarrolladores en tu equipo, uno no presta mucha atención cuando hace revisiones de código y el otro es mortal en el hilo de comentarios, ¿cuál eliges? Eliges al oponente más fuerte, por supuesto, una vez que te golpeen en la cara un par de veces, aprenderás cómo evitar ese gancho de izquierda.

Lo mismo se aplica cuando alguien te ofrece un nuevo código que no entiendes o la posibilidad de asumir un proyecto, no lo dudes, salta sin miedo a un nuevo código, sumérgete e intenta aprender todo lo que puedas.

## ¿Eres un equipo de una sola persona?

En primer lugar, es una mala idea, los equipos unipersonales significan que no te cuestionan sobre tus decisiones y no puedes ver tus puntos ciegos.

Entonces, supongamos que ya lo descubriste y que eres parte de un equipo que incluye varios desarrolladores, un product owner, una persona de control de calidad e incluso un diseñador.

¿Cuánto puedes progresar si solo estás interesado en ti mismo? Por lo general, cuando hablo de superación personal me olvido de mencionar que la mejora penetra a tu alrededor y afecta a otras personas cercanas a ti. Ayudar a los demás es una excelente manera de generar un crecimiento exponencial.

Puede ser mediate programar en pareja con otro desarrollador, asesorar a un nuevo chico que se une al equipo o, como lo hicimos en mi trabajo actual, leer un libro en equipo y discutirlo.

No tiene que estar relacionado con el trabajo, puede ser escribir cosas en un blog como lo estoy haciendo ahora, que espero que ayude a otros y, al mismo tiempo, me ayuda a solidificar mis conocimientos y aclarar mi mente después de un largo día de trabajo.

A veces traer tu mejor juego no es suficiente si el resto del equipo está sufriendo, es mejor que seas un jugador de equipo, no una estrella.

***

## Conclusión

Este fue uno breve, pero espero poder darte algo en qué pensar cuando te concentres en el próximo proyecto de aprendizaje o en la creación de la siguiente feature, busca en lugares donde no hayas chequeado antes, ¿hay algo allí que te de un impulso extra?

Espero que les haya gustado este blog post, por favor compártela y contame en los comentarios, si no te gusto también me gustaría saberlo, como dije, es una gran oportunidad para aprender 🙂


Optimize for learning

Optimizar para el aprendizaje

Una de las cosas que me tomó un tiempo darme cuenta, desafortunadamente, fue que no estaba solo ahi afuera.
Yo era un programador en la naturaleza, caminaba atrapando errores, leyendo documentación y desarrollando productos geek, algunos de ellos que a la gente realmente le gustaban, pero todavía me sentía bastante solo.

![imagen](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4udgtcr7nnvhoioq4snz.png)

Eso cambió para mejor en el último año y medio, déjame decirte por qué.

***

# Introducción

Me di cuenta de que había un grupo completo de personas como yo, que se sentían raras al hablar de software, algunos de ustedes probablemente no tengan un grupo de amigos que compartan los mismos gustos que ustedes.
Compartes artículos que a nadie le importan o te entusiasma una nueva tecnología de la que ninguno de ellos ha oído hablar, o tal vez recién estás comenzando y necesitas orientación o ayuda adicional sobre algún tema específico.

Bueno, déjame decirte, NO ESTÁS SOLO, hay muchos de nosotros que vivimos de esta manera y, afortunadamente, hay una manera de conocernos, **Comunidades de Desarrollo**. El hecho de que estes leyendo esta publicación aquí ya es un buen comienzo, pero es solo el comienzo.

## ¿Qué tipo de comunidades?

No, no estoy hablando de una vieja choza en el bosque donde todos cultivan su propia comida y programan proyectos de código abierto, aunque eso tampoco suena como una mala idea 🤔.

Hay toneladas de lugares donde podes conocer a otras personas del campo de TI, discutir, relacionarse, hacer amistades.

### Meetups

Antes de que el Corona llegase, comencé a ir a meetups, ya sabes, algunos chicos y chicas que escuchaban una charla, discutían sobre software y comían pizza. Sí, amigo mío, esa era LA buena vida, y no lo supimos hasta que se fue.

Los días de las reuniones en persona han pasado a la historia hace rato ya, pero eso no significa que las meetups todavía no estén disponibles. El buen y antiguo [sitio web de meetup](https://www.meetup.com/) todavía funciona, muchas meetups todavía siguen en pie, aunque en línea. Empieza poco a poco, elije tu ciudad, la tecnología que realmente te guste, y apreta el boton de busqueda.

¿Que hice yo? Yo soy de Buenos Aires, Argentina, y quería relacionarme más con personas que les gustase JavaScript, así que mi elección en ese entonces fue [Meetup.js Buenos Aires](https://meetupjs.com.ar/). Después de 3 años, hace unos dias coloqué otro de sus stickers oficiales en mi nueva laptop. Asi de importante fue.

![Texto alternativo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1repgy5efkfb74b3zhlf.jpg)

Tal vez al revisar mis stickers notes un patrón, [Full Stack Antwerp](https://www.meetup.com/es-ES/fullstackantwerp/) suena como una meetup tambien, bueno, lo es. Dondequiera que vaya, habrá una nueva meetup para ir y nuevas personas que conocer.

### Conferencias

Las conferencias son más difíciles para conocer personas, todos están muy ocupados apresurándose para la próxima charla y por lo general no puedes hablar con muchos de ellos, aunque el almuerzo es la oportunidad perfecta para hacerlo.

Lo sé, lo sé, no hay conferencias en persona en ninguna parte. Entonces, tal vez ahora sea el momento adecuado para ayudar a participar en conferencias en línea. Ten la sensación de cómo son y qué tipo de charlas se presentan allí, ¿crees que puedes ir a una cuando todo vuelva a la normalidad? Ahora hay más conferencias en línea gratuitas que nunca, sentite libre de poner los pies en el agua sin el riesgo de ahogarte.

También es una gran oportunidad para conocer, al menos por su nombre, a las personalidades de nuestra industria, tal vez una nueva tecnología, un nuevo libro, algo que de otro modo te perderías.

### Comunidades en línea de Slack y Discord

Sí, no puede ser más simple que esto. Un chat moderado donde todos los desarrolladores pueden expresar sus opiniones y compartir sus pensamientos. Creo que este es el mejor lugar para hacer amigos en este momento.

Muchos podcasts y temas comparten sus propias comunidades de Slack para angloparlantes. Algunas son [Functional Programming Slack](https://fpchat-invite.herokuapp.com/) y [The Complete Developer Network](https://completedevelopernetwork.com/).

El año pasado me uní a una comunidad de Discord para técnicos de habla hispana, si me has estado siguiendo probablemente ya me escuchaste mencionarlos una o dos veces antes. Se llama [frontendcafe](https://frontend.cafe/), pero no dejes que el nombre te engañe, hay mucho más que frontend sucediendo allí. Backend, IT, Hardware, Frontend, Linux, práctica de inglés, Algoritmos, Diseño, incluso algún grupo de hábitos saludables y un canal donde puedes unirte mientras trabajas y escuchar música (sí, como un verdadero espacio de coworking).

Unirme a esta comunidad me ha ayudado a conocer gente fantástica. Expatriados como yo, esparcidos por Europa, gente de mi tierra con la que fuimos a comer pizza cuando estaba visitando a mis padres (y para que pudiera conseguir un sticker de frontendcafe, por supuesto).

He conocido gente con la que puedo hablar sobre tecnología, sobre deportes, sobre inversiones, sobre escribir, lo que sea que realmente me haga cosquillas en el cerebro. En momentos como estos, en los que las relaciones son difíciles de conseguir, especialmente en un país diferente al de origen, esto se ha vuelto invaluable para mí.

No solo eso, sino que me ha brindado algunas oportunidades que nunca pensé que podría tener. Desde que me incorporé yo:

* Hablé sobre mi experiencia al mudarme a otro país en una transmisión en vivo de Twitch.
* Di una charla sobre aprender y mejorar tu carrera a través del automejoramiento para una ONG en Argentina.
* Me uní a freeCodeCamp como escritor.
* Actualmente me reúno con desarrolladores que necesitan una ayuda adicional como parte de un programa de tutoría dos veces por semana.

## Bien, conoces gente, ¿cuál es tu punto?

Esto puede sonar como un alarde, pero no lo es. No soy una persona extrovertida, no tengo muchos amigos y generalmente tengo miedo de hablar con otras personas fuera del mundo virtual, pero ser parte de estas comunidades en línea me ha ayudado a darme cuenta de que hay muchas personas como yo, así que estoy usando esto como práctica.

Con el tiempo, las cosas volverán a un estado previo al "Corona", y cuando eso suceda, me aseguraré de llevar las cosas que aprendí mientras estaba encerrado para conocer gente nueva y también para conocerlos a todos ustedes en persona. No podes equivocarte con 🍕, 🍻 y 💻.

***

Espero que te haya gustado esta publicación del blog, si te gustó, no olvides compartirla y contarme sobre ella en los comentarios.
Si no te gusto también me gustaría escuchar tu aporte, por favor hacelo en los comentarios, respondo a cada uno de ellos 🙂


There are others like you out there

Hay otros como tu ahi afuera

Cuando comencé mi carrera como desarrollador de software hace más de 6 años, estaba asustado, asustado por cometer un error, borrar algo que no debía, hacer mal código o perderme algunas cosas importantes mientras desarrollaba una función nueva del producto.

Si esperabas una historia en la que contara cómo no sucedió ninguna de estas cosas y todo estuvo bien y no deberías preocuparte, este no es ese tipo de historia, no habrá ningún final feliz e irreal aquí.

***

### Algunos errores que cometí hasta ahora

Tomé mi segundo trabajo como desarrollador cuando tenía menos de un año de experiencia. En mi primera semana, rompí con éxito la base de datos de producción, siendo un consultor, lo que provocó que algunos empleados del cliente y yo mismo tuviéramos que quedarnos durante el fin de semana comprobando el alcance del daño que causé. Pasé un sábado entero arreglando entradas rotas en otros sistemas y restaurando copias de seguridad de bases de datos. ¿Qué estaba haciendo exactamente con el acceso de producción en mi primera semana?, hasta el día de hoy todavía no lo sé.

Durante años he escrito código que no funciona, produje errores y entregue las features incorrectas. Construcciones defectuosas, entornos dañados, bloqueo del trabajo de otras personas y lanzamientos retrasados.

En mi tercer trabajo (menos de 2 años de experiencia) no logré lanzar a producción una característica en la que habiamos estado trabajando durante meses, cuando finalmente la puse en producción, estaba plagada de errores, algunas partes del flujo de trabajo no se podían usar en absoluto.

En mi cuarto trabajo (alrededor de 3 años de experiencia) asumí la tarea de construir un microservicio para una función que nuestra empresa necesitaba para sobrevivir los años siguientes.
Aunque estaba a cargo de construirlo, tenía miedo de fallar, así que dejé muchas decisiones a alguien técnicamente más capaz que yo, alguien con años y años de experiencia.
Esa decisión nos guio a través de una fase de implementación increíblemente complicada con toneladas de características que en realidad no necesitábamos y no hicieron más que complicar el código y la implementación. Antes de dejar esa empresa, me encargué de "Refactorizar" ese servicio y de simplificar en gran medida la cantidad de cosas que tenía que hacer, la implementación fue excelente y quedamos muy contentos con la implementación.

### ¿Aprendí algo?

Todos estos errores que cometí me dieron algunas experiencias que nunca olvidaré, y seguro que aprendí de esos errores.
Aprendí a verificar 20 veces antes de ir a la implementación, aprendí a escribir pruebas unitarias y pruebas de integración, cómo hacer pruebas de humo en entornos de ensayo, cómo hacer que mi código sea resistente para que las fallas en una función no hagan caer todo el sistema.

Aprendí cómo interactuar con el equipo control de calidad, obtuve algunas ideas sobre cómo prueban el producto para que pueda hacer verificaciones adicionales antes de que el problema le salga a otra persona.

Aprendí a responsabilizarme del código en el que trabajo, a responsabilizarme de los errores y hacer un esfuerzo adicional para corregirlos.

Aprendí a cuestionar los requerimientos y no solo a construir ciegamente una especificación que me tiran en el escritorio, a hacer preguntas y tratar de resolver problemas en lugar de ser solo un mono que programa.

También me ha enseñado qué tipo de desarrollador senior quiero ser:
¿quieres ser el tipo que le grita al desarrollador jr por cometer un error? (sí, esto, lamentablemente, pasa)
¿o prefieres ser tú quien lo entienda y lo haga crecer?
¿Ves un problema causado por un miembro del equipo como su culpa o como un problema causado por un proceso que NOSOTROS, como equipo, debemos solucionar?

Gracias a esos errores y a las personas que me han ayudado en el camino, aprendí el tipo de desarrollador que quiero ser:

Alguien que se enorgullece de su oficio, alguien que ama ayudar a los demás y ve los errores no como fracasos sino como nuevas oportunidades de aprendizaje, alguien que se preocupa deliberadamente de asegurarse de que las funciones se entreguen a tiempo con la calidad adecuada.

### Eres un senior, ¿y ahora qué?

Me encantaría decirte que los errores dejan de suceder cuando te conviertes en senior, desafortunadamente, ese no es el caso, nunca dejarán de suceder, la espada de Damocles siempre estará ahí colgando sobre tu cabeza.

Incluso hoy casi tengo un ataque al corazón cuando por un momento pensé que uno de mis scripts de base de datos locales se estaba ejecutando en la base de datos de staging en lugar de en mi instancia local de Docker, todo en mi segunda semana en un nuevo trabajo.

No pasó nada, sabía que tenía el archivo de configuración adecuado apuntando a mi instancia local, estaba verificando la base de datos mientras se ejecutaba el script y tomé las medidas adecuadas para revertirlo si algo hubiera estado mal, pero cuando vi registros de errores en el canal de staging digamos que dudé un poco de mí mismo 😂. Al final, fue solo que los logs para el entorno de desarrollo y el de staging iban a parar al mismo canal, eso es todo.

***

Mi punto con esta publicación de blog no es asustarte, es para hacerte saber que todos cometemos errores, lo que diferencia a los desarrolladores es cómo toman esos errores y qué hacen con las lecciones aprendidas.

Si le gustó esta publicación del blog, compártala y contamelo a continuación en los comentarios. ¿Qué errores ha cometido en su carrera? Me encantaría escucharlos para que podamos reírnos juntos.

Hasta pronto 😀


Mistakes come for Juniors and Seniors alike

Los errores vienen tanto para los Junior como para los Senior

Hola chicos, ¡el 2021 finalmente está aquí!. Ha sido un año duro pero ahora es el momento de volver a planificar todo, de anotar en un papel lo que quiero aprender o hacer este año.

Si has estado siguiendo las publicaciones de mi blog durante algún tiempo, sabras que soy un gran fanático de establecer metas, planificar, trackear y, por supuesto, HACER.

El año pasado me concentré en demasiadas cosas y aunque logré bastantes de las cosas que me propuse, también noté que la presión de no alcanzar lo que esperaba me empujaba hacia atrás. Este año voy a ir un poco más ligero en la cantidad de cosas pero no en el esfuerzo, llamémoslo simplemente tener una dirección "mejor".

Empecemos ya, ¿de acuerdo?

***

## 1. Sentirse cómodo escribiendo al menos en un lenguaje de programación funcional

El año pasado pasé bastante dando vueltas, yendo de libro en libro, buscando lenguajes, hablando con gente, haciendo pequeñas pruebas en diferentes entornos. Para este año he tomado la decisión de concentrarme en aprender `Haskell`, al menos al principio. Este será mi plan de estudios inicial:

* Leer el [Haskell Book](https://www.goodreads.com/book/show/25587599-haskell-programming-from-first-principles).
* Leer [A type of programming](https://atypeofprogramming.com/).
* Leer [Aprenda Haskell por el bien comun](http://learnyouahaskell.com/).
* Leer [Teoría de categorías para programadores](https://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/).
* Hacer al menos un proyecto personal de tamaño moderado con Haskell.
* Explorar otros lenguajes como Elm, PureScript, F#, Clojure.
* Leer [Programación funcional para el programador orientado a objetos](https://leanpub.com/fp-oo).
* Releer [Estructura e interpretación de programas informáticos](https://web.mit.edu/alexmv/6.037/sicp.pdf).

Al separar un gran objetivo en tareas más pequeñas y concisas, no necesito preocuparme por qué hacer a continuación, solo sigo el plan, si algo no va bien, resuelvo el problema y continúo.

## 2. Mejorar en arquitectura de software y la ciencias de la computación

El año pasado no me concentré en esto en absoluto, el año pasado tuve la idea de que quería aprender más sobre frontend, así que cambié de puesto en mi trabajo y me convertí en desarrollador frontend. Eso me enseñó que no estoy tan interesado en el frontend después de todo, jaja.

* Leer [La serie de manuales del impostor](https://bigmachine.io/products/the-imposters-handbook/).
* Leer y estudiar [Clean Architecture](https://www.amazon.com/-/es/Robert-C-Martin-ebook/dp/B075LRM681).
* Leer y estudiar [Domain Driven Design: Abordar la complejidad en el corazón del software](https://www.amazon.com/-/es/Eric-Evans/dp/0321125215).
* Leer y estudiar [Implementación de Domain Driven Design](https://www.amazon.com/-/es/Vaughn-Vernon/dp/0321834577).
* Asumir un proyecto en el trabajo donde pueda diseñar un sistema desde cero.
* Crear un proyecto personal utilizando los conceptos aprendidos, mientras se esquematiza la arquitectura.
* Participar en discusiones de arquitectura en mi nuevo puesto para aprender sobre sistemas distribuidos.

Comencé el año con una nueva posición, un nuevo trabajo como desarrollador de software senior en un lugar con algunas decisiones complejas y muchos sistemas geniales con los que jugar. Voy a aprovechar esta oportunidad para aprender todo lo que pueda de los nuevos miembros de mi equipo y, al mismo tiempo, intentaré aumentar mis propios conocimientos sobre el tema.

## 3. Mejorar la escritura

El año pasado escribí muchos blog posts, incluso algunas que me colocaron en la parte superior de la lista en comunidades increíbles como CodeNewbie, pero incluso asi no estoy conforme.

![CodeNewbie 100k](/code.jpg)

Empecé fuerte pero al final, la búsqueda de un nuevo trabajo y mis otros objetivos se interpusieron. Este año mi objetivo es tener menos cosas en las que concentrarme, ¡pero hacerlas con el máximo esfuerzo !.

* Planificar determinadas fechas durante la semana en las que voy a escribir.
* Tener una lista de temas sobre los que pueda escribir para poder elegir uno de la pila cuando llegue el momento.
* Escribir al menos 2 publicaciones de blog a la semana.
* Escribir sobre lo que estoy aprendiendo para solidificar conocimientos.

## 4. Mejorar mi participación en la comunidad

Este año me uní a una hermosa comunidad llamada [FrontendCafe](https://frontend.cafe/), gente increíble de Argentina y otros países de América Latina (y gente de España también 😀). Este año quiero seguir reuniéndome con desarrolladores de todo el mundo pero quiero dar especial atención a las personas de la comunidad hispanohablante, específicamente a aquellos que no tienen los medios para aprender cosas nuevas o que enfrentan algunos de los problemas que enfrenté cuando estaba comenzando en esta industria.

* Dar más mentorias en [FrontendCafe](https://frontend.cafe/) y fuera de la comunidad de habla hispana.
* Dedicar más tiempo a ayudar a nuevos usuarios y a utilizar mi rol como miembro del Staff en [FrontendCafe](https://frontend.cafe/).
* Ir a meetups (si vuelven).
* Dar una charla en una meetup local (si vuelven).

***

Como pueden notar algunas de las cosas son las mismas que ya dije en la planificación de 2020 y eso está bien. No alcancé el nivel que quiero alcanzar en muchos temas, así que este año me enfocaré aún más en ellos.
Otros temas han desaparecido por completo, eso también está bien. Después de 2020 aprendí algunas lecciones sobre mí mismo, sobre lo que me gusta y en qué temas quiero invertir más de mi tiempo.

Espero que les guste mi planificación para el 2021, si es así, compártela y escribelo a continuación en los comentarios. ¿Tienes un plan similar? Me gustaría leerlo, los comentarios también son el lugar perfecto para eso.

Hasta pronto 😀


Planning my career development for 2021

Planificando el desarrollo de mi carrera para 2021

El 8 de octubre de 2014 sucedió algo increíble, algo que cambiaría mi vida para siempre. Hace 6 años comencé a escribir código.
En ese entonces, yo era un estudiante de Economía de 25 años que trabajaba en un banco, en cambio, decidí cambiarme a una carrera de Ingeniería de Software y dejar mi trabajo para asistir a un Bootcamp de un mes de `Accenture`.

Había escrito mi primera línea de código unos meses antes. Era un `Hello World` básico escrito en C, pero ese día todo cambió, comencé a aprender a programar a diario, tenía el enfoque y la intención de convertirme en desarrollador de software. Fue ese día que encontré mi verdadera vocación en la vida, me di cuenta de que podía hacer esto para siempre y nunca aburrirme. Hasta ahora esta afirmación ha sobrevivido al paso del tiempo.

Un poco más de un mes después, estaba comenzando un trabajo como desarrollador de software en trainee/jr mientras aún intentaba comprender los conceptos que leí en [C# en profundidad de Jon Skeet](https://csharpindepth.com/).

***

## ¿Qué cambió?

### En mi carrera

En estos años, muchas cosas han cambiado, tuve 4 trabajos como Desarrollador C# y al mismo tiempo contribuí al frontend aprendiendo HTML + CSS + Javascript, luego pasé a Angular.js y finalmente a Angular. Actualmente, trabajo como desarrollador full-stack enfocándome en C# y Angular.

Aunque he tenido algunos momentos en los que me concentré efoncado en otras cosas además del desarrollo de software, el aprendizaje ha sido una constante en esta experiencia. Esta carrera ha despertado algo dentro de mí que nunca antes había sentido, este fuego ardiente que es un impulso para siempre mejorar.

* Programación orientada a objetos
* Programación funcional
* Desarrollo backend
* Desarrollo frontend
* Teoría de categorías
* Ciencias de la Computación
* Arquitectura de software

He estado por todos lados pero nunca dejé de seguir el proceso de aprendizaje. Con suerte, nunca se detendrá.

### En mi vida personal

Esta carrera me ha traído gente increíble a mi vida, la mayoría de mis amigos son profesionales en una u otra área del desarrollo de software.

Ahora también tengo la posibilidad de usar mi experiencia para ayudar a otros, soy miembro de varias comunidades de desarrollo de software y, a menudo, doy tutoría en mi tiempo libre.

Crecí en Argentina, la situación allí siempre ha sido difícil. Después de poco menos de 3 años trabajando como desarrollador en Argentina, decidí buscar trabajo en Europa y me mudé. Gracias a esta carrera pude mejorar drásticamente mi calidad de vida, visitar países que solo había visto en mis sueños y brindarle una vida mejor a mi esposa.

***

Sé que mi carrera recién está comenzando, 6 años probablemente no parece nada para los veteranos de la industria. Ha sido todo un camino, uno que pretendo recorrer hasta mi último día, no puedo esperar a ver qué traerá el futuro y qué aprenderé mañana.


Happy Developer Birthday to me!

¡Feliz cumpleaños como desarrollador para mí!

## Introducción

Desde finales del año pasado, me estoy metiendo en la Programación Funcional (FP), todavía soy muy malo en eso.

Encuentro algunos conceptos muy difíciles de entender, las cosas todavía se sienten muy poco naturales, pero a lo largo de este proceso, comencé a notar algunas cosas que hacemos regularmente en la programación orientada a objetos (OOP) que son mucho más fáciles de implementar en lenguajes de programación funcionales, requieren menos código y, a veces, la implementación viene por defecto proporcionada por el propio lenguaje.

En un artículo anterior, hablé sobre cómo se aplican los principios SOLID a FP, puedes leerlo [aquí](https://www.patferraggi.dev/blog/2020/jul/solid-funcional/), hoy voy a hacer un análisis similar pero con respecto a los Patrones de Diseño, específicamente algunos de los se mencionan en el [libro GoF original](https://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional-ebook/dp/B000SEIBB8)

***

### Strategy Pattern

Comencemos con la definición original:

> El patrón de estrategia es un patrón de diseño que permite seleccionar un algoritmo en tiempo de ejecución. En lugar de implementar un solo algoritmo directamente, el código recibe instrucciones en tiempo de ejecución sobre cuál usar.

La estrategia permite que el algoritmo varíe independientemente de los clientes que lo utilicen.

¿Como se ve esto?

![Texto alternativo](/strategy.png)

En los lenguajes de programación orientada a objetos, esto generalmente implica clases separadas para cada estrategia y todas implementan una interfaz común, luego otra clase hace uso de la interfaz de estrategia sin saber realmente qué implementación de estrategia se ha seleccionado en tiempo de ejecución, con esto separamos las responsabilidades de seleccionar el algoritmo y las diferencias en la implementación entre estrategias teniendo la posibilidad de seleccionar una u otra durante el tiempo de ejecución.

En FP, este patrón se vuelve extremadamente fácil de implementar y requiere mucho menos código. Voy a usar JavaScript, pero puede ser igualmente fácil de implementar en lenguajes completamente funcionales.

```javascript
const strategy1 = () => {
  console.log("run strategy 1")
}

const strategy2 = () => {
  console.log("run strategy 2")
}

const consumer = runStrategy => {
  /*
  Hacemos otras cosas
  */

  runStrategy()
}

const selectedStrategy = condition ? strategy1 : strategy2

consumer(selectedStrategy)
```

Como puedes ver, en FP, el patrón de estrategia se vuelve tan simple como pasar una función como parámetro. Hay mucho menos código involucrado porque no tenemos que depender de clases o herencia para lograr la misma funcionalidad.

### Factory Pattern

> El patrón de fábrica es un patrón que utiliza métodos para lidiar con el problema de crear objetos sin tener que especificar la clase exacta del objeto que se creará. Esto se hace creando objetos llamando a un método de fábrica, ya sea especificado en una interfaz e implementado por clases secundarias, o implementado en una clase base y opcionalmente anulado por clases derivadas, en lugar de llamar a un constructor.

En los lenguajes de programación orientada a objetos, esto generalmente implica clases separadas que encapsulan la lógica de negocio referida a la creación de objetos y que pueden decidir qué objeto crear durante el tiempo de ejecución. Esto a menudo implica establecer parámetros específicos en el objeto creado dependiendo de lo que queramos instanciar.

En FP, este patrón se vuelve extremadamente fácil de implementar:

```javascript
const behavior1 = () => {
  console.log("do behavior 1")
}

const behavior2 = () => {
  console.log("do behavior 2")
}

const factory = condition => {
  /*
  Do other stuff
  */

  if (condition) behavior1

  return behavior2
}
```

Como puedes ver, las funciones de orden superior nos dan una solución simple nuevamente, en lugar de que el comportamiento sea definido por clases y una herencia, simplemente devolvemos una función que encapsula el comportamiento u objeto deseado.

### Decorator Pattern

> El patrón de decorador es un patrón de diseño que permite agregar comportamiento a un objeto individual, de forma dinámica, sin afectar el comportamiento de otros objetos de la misma clase. El patrón de decorador suele ser útil para adherirse al principio de responsabilidad única, ya que permite dividir la funcionalidad entre clases con áreas de interés únicas.

En los lenguajes de programación orientada a objetos, se envuelve un objeto en otro y proporcionamos una funcionalidad adicional que el original no tenía, sin modificar realmente su implementación, además, puedes elegir en tiempo de ejecución qué funcionalidad necesita agregar al objeto existente.

En FP esto se logra mediante `Composición`, una de las ideas centrales de FP es separar la funcionalidad en pequeñas funciones que se pueden componer para formar otros comportamientos, por lo que en lugar de tener una clase que envuelva a otra, tomamos pequeñas funciones como bloques `LEGO` y los ponemos todos juntos para crear un nuevo comportamiento. Veamos un ejemplo:

```javascript
const compose = (...fns) => x => fns.reduceRight((v, f) => f(v), x)

function isBiggerThanThree(value) {
  return value > 3
}

function mapBoolToHumanOutput(value) {
  return value ? "yes" : "no"
}

const biggerThanThreeAndMapOutput = compose(
  mapBoolToHumanOutput,
  isBiggerThanThree
)

biggerThanThreeAndMapOutput(3)
```

En este ejemplo, definimos dos funciones que hacen una pequeña cosa y luego se componen para generar un nuevo comportamiento, mientras se aplique la composición, podemos seguir agregando más funcionalidad a la mezcla 😀

### Observer Pattern

> El patrón de observador es un patrón de diseño de software en el que un objeto, llamado sujeto, mantiene una lista de sus dependientes, llamados observadores, y les notifica automáticamente de cualquier cambio de estado, generalmente llamando a uno de sus métodos.

Este patrón se basa en la idea de Push vs Pull. En lugar de que un objeto compruebe constantemente si el estado de otro ha cambiado, el segundo objeto notifica a todos los demás cuando su propio estado ha cambiado.

En FP, este es un patrón muy utilizado en forma de `Callbacks`, `Events` y `Observers` . También se utilizan mucho en bibliotecas como [RX.js](https://rxjs.dev/) para `Programación funcional reactiva`

Me referiré a una respuesta a "¿Qué son las Callback?" en Stack Overflow.

![Devolución de llamada](/callback.png)

### Singleton Pattern

> El patrón singleton es un patrón de diseño de software que restringe la instanciación de una clase a una instancia "única". Esto es útil cuando se necesita exactamente un objeto para coordinar acciones en todo el sistema. El término proviene del concepto matemático de singleton.

En los lenguajes de programación orientada a objetos, esto implica crear una instancia estática de un objeto para que esté disponible en todas partes sin instanciación y asegurarse de que si alguien intenta instanciarlo nuevamente, se devuelva la instancia ya creada.

En FP, este patrón se vuelve completamente innecesario, no hay un estado global que deba exponerse a toda la aplicación, ya que los datos están completamente separados de las funciones. Además, todas las funciones existen en un namespace global, siempre son accesibles, toman parametros y devuelven un resultado sin afectar el mundo exterior.

## Conclusión

Como puedes ver, parece que algunos de los patrones que han evolucionado dentro del mundo de OOP parecen dar a estos lenguajes los beneficios que FP obtiene de forma gratuita, sin perder las cosas que caracterizan a OOP como el control sobre el estado y los datos.

Hay algunos otros patrones que no mencioné porque encajan en las soluciones propuestas por los ejemplos anteriores.

***

A medida que continúe en mi viaje hacia la programación funcional, probablemente encontraré más ejemplos y casos que se ajusten a esta suposición mía. Si te gustó este artículo, házmelo saber en los comentarios para seguir escribiendolos.

Y por favor no olvides compartirlo 😀
