## 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 😀


Do you need Design Patterns in Functional Programming?

¿Necesitas patrones de diseño en la programación funcional?

¡Hola chicos! ¿como han estado? En las últimas semanas, he estado en proceso de entrevistas para puestos de desarrollador de **C#**.

Trabajo con **ASP.NET Core** todos los días, lo que significa que cuando estoy en casa no elijo **C#** como lenguaje de practicas. Por esto mismo, el código **C#** que tengo en mi Github es bastante antiguo y pertenece a los primeros años de mi carrera.

Así que decidí usar los desafíos de programación que me brindan los empleadores para crear un código **C#** más nuevo para mi Github y, al mismo tiempo, crear una buena guía que puedan seguir mejorando su desarrollo personal.

***

## ¿Qué esperar de este tutorial?

Al final de la serie, tendremos un microservicio con las siguientes características:

* Integrado a `MongoDB`
* Arquitectura en capas con una clara separación de responsabilidades
* Documentación de la API
* Soporte de Docker
* Tests unitarios

## Introducción

Tenemos una pequeña empresa, vendemos 💻. Cada vez que se vende una computadora nueva debemos registrar el pedido con el monto y el cliente que lo compró.

Vamos a crear un pequeño microservicio que se conecta a una instancia de [MongoDB](https://www.mongodb.com/) y nos permite crear/leer/actualizar/eliminar pedidos y también obtener algunos cálculos adicionales sobre el gasto de los usuarios.

Nuestro modelo de `Order` o `Pedido` será el siguiente:

```json
{
  "id": "guid",
  "userId": "guid",
  "cantidad": "int"
}
```

## Definición básica

Comenzamos creando una aplicación web **ASP.NET Core 3.1** con la plantilla de API y la compatibilidad con Docker habilitada en Visual Studio 2019.

![ApplicationTemplate](https://dev-to-uploads.s3.amazonaws.com/i/0sldfc9i411ztnje7t6c.png)

Una vez creado, veran un modelo y un `Controller` para un `WeatherForecast`, que es la forma de la plantilla predeterminada de mostrarles que hay una API lista para usar.

![InitialStatus](https://dev-to-uploads.s3.amazonaws.com/i/20daydhqd7cjp13vhhg6.png)

Después de eliminar el código predeterminado, comenzamos creando nuestro modelo y un `OrdersController` básico. Comenzaremos por el `POST` y el `GET`, entonces podremos probar la creación y obtención de pedidos.

```csharp
    [Route("v1/[controller]")]
    [ApiController]
    public class OrdersController : ControllerBase
    {
        /// <summary>
        /// Retrieves all orders
        /// </summary>
        /// <returns>a list with all the orders available</returns>
        [HttpGet]
        public async Task<IEnumerable<Order>> GetAll()
        {
            throw new NotImplementedException();
        }

        /// <summary>
        /// Retrieves the order that matches the id supplied
        /// </summary>
        /// <returns>one order model</returns>
        [HttpGet("{orderId}")]
        public async Task<ActionResult<Order>> Get(Guid orderId)
        {
            throw new NotImplementedException();
        }

        /// <summary>
        /// Creates a new order
        /// </summary>
        /// <returns>the newly created order</returns>
        [HttpPost]
        public async Task<ActionResult<Order>> Post([FromBody]OrderCreateUpdate orderRequest)
        {
            throw new NotImplementedException();
        }
    }
```

En el código anterior, creamos los endpoints `GetAll`,`Get` y `Post`, también incluimos comentarios para la API pública y ya hemos versionado nuestra API usando la nomenclatura `v1/[controller]` en los endpoints. Si estan prestando atención, es posible que hayan notado que el `Post` tiene un modelo que aún no hemos definido, `OrderCreateUpdate`.

Cuando creas elementos en una base de datos, no se debe proporcionar un `OrderId`, ya que el pedido aún no existe, entonces es una buena práctica separar el modelo de API en dos para que estos puedan cambiar de forma independiente. Este es el modelo para `OrderCreateUpdate`:

```json
{
  "userId": "guid",
  "cantidad": "int"
}
```

```csharp
        public Guid UserId { get; set; }
        public int Amount { get; set; }
```

## Conexión a la base de datos

Por ahora, en lugar de crear una base de datos local o jugar con Docker desde el comienzo, usaremos una base de datos en línea como las proporcionadas por [MongoDBAtlas](https://www.mongodb.com/try).

De vuelta en el proyecto, necesitamos encontrar una manera de configurar los ajustes para conectarnos a nuestra base de datos, lo hacemos usando el [Patrón de opciones](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/options?view=aspnetcore-3.1) que trae **ASP.NET Core**. Definimos la siguiente configuración:

```csharp
    public class OrdersServiceOptions
    {
        public string DatabaseConnectionString { get; set; }
        public string DatabaseName { get; set; }
        public string CollectionName { get; set; }
    }
```

Ahora que tenemos nuestra configuración lista, podemos pasar a crear nuestro primer [Repositorio](https://docs.microsoft.com/en-us/aspnet/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application) que tendrá la responsabilidad de conectarse a nuestra instancia `MongoDB`.

Este es el código de nuestro `OrdersRepository`:

```csharp
    public class OrdersRespository
    {
        private readonly IMongoDatabase database;
        private readonly IMongoCollection<Order> collection;
        private readonly ILogger<OrdersRespository> logger;

        public OrdersRespository(IOptions<OrdersProcessingServiceOptions> options, ILogger<OrdersRespository> logger)
        {
            if (options == null)
            {
                throw new ArgumentNullException(nameof(options));
            }

            var configuration = options.Value;
            var client = new MongoClient(configuration.DatabaseConnectionString);

            this.database = client.GetDatabase(configuration.DatabaseName);
            this.collection = database.GetCollection<Order>(configuration.CollectionName);
            this.logger = logger;
        }
    }
```

Como pueden ver, el `Repositorio` crea la conexión con a `MongoDB` usando las opciones de configuración que definimos anteriormente, también acepta un `logger` que vamos a usar mas tarde. A continuación, crearemos los métodos que usaremos para obtener y crear `Pedidos`.

```csharp
        public async Task<Order> GetOrder(Guid orderId) => await collection.Find(x => x.Id == orderId).FirstOrDefaultAsync();

        public async Task<IEnumerable<Order>> GetAll() => await collection.Find(_ => true).ToListAsync();

        public async Task<Order> CreateOrder(Order order)
        {
            try
            {
                await collection.InsertOneAsync(order);

                return order;
            }
            catch (Exception ex)
            {
                logger.LogError(ex.Message, ex);
                return null;
            }
        }
```

Los 3 métodos son muy simples, obtenemos un solo pedido por id, obtenemos todos los pedidos y creamos un nuevo pedido (con el `logging` adecuado si falla la creación). Después de agregar estos métodos, creamos una interfaz de este repositorio para que podamos comenzar a usar la [Inyección de dependencias](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-3.1) que viene con **.NET Core**.

```csharp
   public interface IOrdersRespository
    {
        Task<Order> GetOrder(Guid orderId);
        Task<IEnumerable<Order>> GetAll();
        Task<Order> CreateOrder(Order order);
    }
```

## Conectando las piezas

Volvamos a nuestro `Controller` y hagamos las llamadas adecuadas a nuestro `Repository`.

```csharp
    [ApiController]
    [Route("v1/[controller]")]
    public class OrdersController : ControllerBase
    {
        private readonly IOrdersRepository ordersRepository;

        public OrdersController(IOrdersRepository ordersRepository)
        {
            this.ordersRepository = ordersRepository;
        }

        /// <summary>
        /// Retrieves all orders
        /// </summary>
        /// <returns>a list with all the orders available</returns>
        [HttpGet]
        public async Task<IEnumerable<Order>> GetAll()
        {
            return await ordersRepository.GetAll();
        }

        /// <summary>
        /// Retrieves the order that matches the id supplied
        /// </summary>
        /// <returns>one order model</returns>
        [HttpGet("{orderId}")]
        [ProducesResponseType(StatusCodes.Status200OK)]
        [ProducesResponseType(StatusCodes.Status404NotFound)]
        public async Task<ActionResult<Order>> Get(Guid orderId)
        {
            var result = await ordersRepository.GetOrder(orderId);

            if (result == null) return NotFound();

            return Ok(result);
        }

        /// <summary>
        /// Creates a new order
        /// </summary>
        /// <returns>the newly created order</returns>
        [HttpPost]
        [ProducesResponseType(StatusCodes.Status201Created)]
        [ProducesResponseType(StatusCodes.Status400BadRequest)]
        public async Task<ActionResult<Order>> Post([FromBody]OrderCreateUpdate orderRequest)
        {
            var order = new Order()
            {
                Amount = orderRequest.Amount,
                UserId = orderRequest.UserId
            };

            var result = await ordersRepository.CreateOrder(order);

            if (result == null) return BadRequest();

            return StatusCode(201, result);
        }
    }
```

Agregamos la dependencia del `IOrdersRepository` en el constructor y lo usamos desde los endpoints. También manejamos diferentes respuestas dependiendo del resultado del `Repositorio` y definimos explícitamente las posibles respuestas usando los `ProducesResponseType`.

## ¿El resultado de hoy?

`POST`

![POST](https://dev-to-uploads.s3.amazonaws.com/i/4idtrl7pjox48hhr8s4p.png)

`GET`

![OBTENER](https://dev-to-uploads.s3.amazonaws.com/i/puhluqh6303n6elif4pj.png)

`GET ALL`

![OBTENER TODOS](https://dev-to-uploads.s3.amazonaws.com/i/zvr7b6z43jap340sbtx7.png)

Si tienen algo de experiencia en la construcción de API modernas, probablemente esten en shock. ¿Este tipo realmente va a usar el mismo modelo para la API y la base de datos? ¿va a llamar al repositorio desde el controlador? ¿Por qué todo está en el mismo proyecto?

No se preocupen, nos encargaremos de todo antes de que termine esta serie, les prometo que va a ser algo que valga la pena poner en su Github 😉

***

Eso fue mucho, lo sé, tampoco entré en detalles de todos los patrones de aplicación usados ​​ya que hubiera sido imposible, pero en cada patrón usado hay un enlace a la guía oficial sobre cómo implementarlo en **ASP.NET Core**, los tutoriales de Microsoft son muy buenos y les darán los detalles que faltan.

Espero que les haya gustado esta primera parte, en la siguiente agregaremos `Actualizar`, `Eliminar`, el endpoint de información combinada y si hay tiempo también comenzaremos a separar mejor las responsabilidades y puliremos nuestro servicio.

Como siempre, si te gustó o no, házmelo saber en los comentarios y compártelo en las redes sociales 😀


Building a microservice with C#, .NET Core and MongoDB

Creando un microservicio con C#, .NET Core y MongoDB

Ayer estuve navegando en una de las comunidades de desarrolladores en línea donde suelo pasar el rato y noté que había un debate muy intenso sobre de qué se trata escribir buen código. Como de costumbre, los términos [Patrones de diseño](https://en.m.wikipedia.org/wiki/Design_pattern), [Código limpio](https://en.m.wikipedia.org/wiki/Robert_C._Martin) y [SOLID](https://en.m.wikipedia.org/wiki/SOLID) eran lanzados en una lucha feroz de términos de programación. Estaba claro que el público era principalmente programadores orientados a objetos. De repente, alguien comenzó a hablar sobre Programación Funcional, yo al ser programador de OOP que está en su camino para absorber todo lo que pueda de la manera Funcional, me senti intrigado.

Esta persona argumentó que SOLID y los patrones de diseño son cosas de programación orientada a objetos (OOP) y que no se relacionan bien con la programación funcional (FP).

Este argumento quedó atrapado en mi cabeza, así que decidí escribir sobre él para expresar mi opinión personal. Dado que tengo dos opiniones diferentes sobre SOLID y Patrones de diseño, hoy, solo cubriré SOLID, aunque seguro cubriré los Patrones de diseño en un futuro cercano.

Comencemos con algunas introducciones.

***

## ¿Qué es SOLID?

> SOLID es un acrónimo mnemónico para cinco principios de diseño destinados a hacer que los diseños de software sean más comprensibles, flexibles y mantenibles

Fueron introducidos por primera vez por Robert C. Martin a principios de la década de 2000 en su paper [Principios de diseño y Patrones de diseño](https://fi.ort.edu.uy/innovaportal/file/2032/1/design_principles.pdf) y son los siguientes:

* Principio de responsabilidad única

* Principio abierto-cerrado

* Principio de sustitución de Liskov

* Principio de segregación de interfaz

* Principio de inversión de dependencias

## ¿Cómo se usan en OOP y FP?

Vayamos uno por uno y veamos cómo se aplican a ambos paradigmas.

### Principio de responsabilidad única

**"Un objeto solo debe tener una única responsabilidad, es decir, solo los cambios en una parte de la especificación del software deben poder afectar la especificación del objeto".**

Tradicionalmente, cuando las personas hablan sobre este principio, piensan en las clases (aunque la idea original proviene del desarrollo de UNIX), piensan en extraer el comportamiento en múltiples clases y manejar una separación adecuada de las preocupaciones.
Aunque los lenguajes de programación funcionales no tienen clases, el mismo principio es válido. Las funciones deben ser pequeñas piezas de código reutilizables que puedes componer libremente para crear un comportamiento complejo.

Esto se puede extraer de casi cualquier cosa, una vez que sus funciones son pequeñas, los módulos donde se ubican también deben formar un cierre cohesivo que solo hace una cosa y lo hace bien.

Mientras una función, clase o módulo tenga solo una razón para cambiar, entonces está aplicando este principio.

### Principio abierto-cerrado

**"Las entidades de software ... deberían estar abiertas para la extensión, pero cerradas para la modificación".**

Este principio generalmente se relaciona instantáneamente con la herencia. Una clase padre bien definida que tiene funcionalidad y los hijos de esta clase extienden o reutilizan la funcionalidad mencionada. En realidad, solo significa que deberíamos poder reutilizar y extender el código sin tener que modificar la implementación original.

En lugar de usar la herencia, la Programación Funcional logra esto usando dos herramientas. Composición para crear nuevos comportamientos a partir de funciones previamente definidas y funciones de orden superior para cambiar la funcionalidad en tiempo de ejecución. Por cierto, si estas interesado en leer más sobre estos temas, puedes consultar mi serie [Programación funcional para el desarrollador orientado a objetos](https://www.patferraggi.dev/blog/2020/jan/programacion-funcional-para-oop/).

### Principio de sustitución de Liskov

**"Los objetos en un programa deben ser reemplazables con instancias de sus subtipos sin alterar el funcionamiento de ese programa".**

Nuevamente, cuando las personas piensan en este principio generalmente la primera idea que se les ocurre es que si la clase de los padres tiene algún comportamiento, sus hijos no deberían romper ese comportamiento, pero este no es el único caso aplicable. LSP también se aplica en caso de que usemos programación genérica o paramétrica donde creamos funciones que funcionan en una variedad de tipos, todos tienen una verdad común que los hace intercambiables.

Este patrón es muy común en la programación funcional, donde se crean funciones que abarcan tipos polimórficos (también conocidos como genéricos) para garantizar que un conjunto de entradas se pueda sustituir sin problemas por otro sin ningún cambio en el código subyacente.

### Principio de segregación de interfaz

**"Muchas interfaces específicas del cliente son mejores que una interfaz de propósito general".**

Esta es fácil, pero muchas personas, incluidas las que me llamaron la atención sobre el tema, se apegan demasiado a la palabra "interfaz" y se refieren automáticamente al concepto de interfaces en lenguajes como C# o Java, piensan que si no tienes interfaces, entonces este principio no se puede aplicar.

En realidad, cada interacción entre componentes se realiza mediante una interfaz. Cuando utilizas funciones de un módulo, estas utilizando la interfaz eliminada de ese módulo, incluso si estamos en un lenguaje de tipo dinámico, esa interfaz todavía existe. El punto de esto es que la forma de crear módulos (o clases o interfaces o API o lo que sea) debe ser coherente, debe proporcionar una forma clara de hacer las cosas en lugar de muchas, y debe exponer solo lo que es necesario para que los usuarios puedan realizar la tarea específica.

### Principio de inversión de dependencia

**"Uno debe depender de abstracciones, \[no] de concreciones".**

En lenguajes como C#, esto se logra mediante el uso de dos herramientas. Una es crear interfaces para definir contratos de una funcionalidad predefinida. El otro es usar la inyección de dependencias para que los usuarios de esa funcionalidad no creen instancias manuales de la clase concreta, sino que reciban una instancia de la interfaz a través de su constructor y solo llamen a los métodos apropiados en la instancia.

En la programación funcional, las abstracciones son la forma predeterminada de manejar el código, las funciones también son abstracciones, especialmente en la programación funcional donde nos preocupamos más por la "forma" de los datos en lugar de a qué tipo específico están conectados. Esto crea la posibilidad de cambiar libremente la implementación en tiempo de ejecución pasando funciones como parámetros a otras funciones o incluso devolviendo funciones como resultado del cálculo.

***

Espero que les haya gustado mi opinión sobre SOLID y la Programación Funcional. Si deseas ver una comparación directa entre implementaciones de patrones de diseño en OOP y FP, hágamelo saber a continuación en los comentarios
😀

Como siempre, si te gustó esta publicación, compártela en las redes sociales.


Do the SOLID principles apply to Functional Programming?

¿Los principios SOLID se aplican a la programación funcional?

Durante muchos años creí que lo único que constituía ser profesional era que me pagaran por hacer algo. Practiqué Muay Thai durante muchos años, por lo que ser un luchador profesional significaba que me pagaran por luchar (aparte del hecho de que usas menos protecciones durante las peleas y, a veces, los rounds son más largos).

En una vida anterior, en una carrera anterior, un profesor universitario me dijo que un profesional no hablaría sobre las cosas de las que no tenía conocimiento, que no mentiría. Pensé que era una idea genial, así que la agregué a mi definición, curiosamente el otro día un amigo me dijo que no hablo mucho, pero cuando lo hago siempre digo algo inteligente, por lo que el profesor podría haberme influenciado más de lo que me di cuenta en ese momento.

Hasta hace unos años, pensaba que era un desarrollador profesional, no fue hasta que leí [The Clean Coder](https://www.amazon.es/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073) por Robert C. Martin, también conocido como `Tío Bob`, que comencé a analizar mis procesos, mis acciones, mis errores y me di cuenta de que tal vez no me estaba ajustando a los estándares correctos.

En este artículo, señalaré mis errores pasados ​​y cómo creo que debería comportarse un verdadero profesional.

## El falso profesional

Durante los primeros 2 años como desarrollador de software "profesional", trabajé en varias empresas de consultoría, todo tenía que hacerse rápidamente, a veces no había equipo de control de calidad, a veces no había diseñadores, todo tenía prisa y la situación era puro estrés, pero esas no son excusas. Por falta de confianza en mí mismo, he sido empujado a producir un trabajo por debajo de la media, pero fui yo quien dejó que sucediera.

* Por pereza, entregué un software defectuoso a sabiendas.
* No escribí una sola prueba unitaria en 2 años.
* No produje el mejor código que pude, busqué la solución rápida y fácil varias veces, trayendo futuros errores y problemas.
* He aceptado "intentar" cumplir con ciertos plazos incluso cuando sabía que era imposible hacerlo, incluso trabajando fines de semana completos varias veces.
* Acepte ciertas soluciones de personas que no tenían la capacidad técnica suficiente para comprender las implicaciones reales.
* Por mi propio comportamiento, he visto código podrido hasta el punto en que el desarrollo de aplicaciones se vuelve increíblemente lento.
* He perdido el tiempo durante las horas de trabajo.
* Pensé que era obligación de mi empleador enseñarme las herramientas y prácticas adecuadas para mi trabajo.

Durante esos años pensé que así era trabajar como desarrollador, quiero decir que todos a mi alrededor hacían lo mismo, los proyectos no tenían pruebas, la gerencia tomó todas las decisiones sobre cómo deberían implementarse las cosas y cuándo. Mi palabra como desarrollador no fue respetada ni un poco y ahora finalmente entiendo por qué.

Estoy bastante seguro de que no soy el único en la comunidad que ha hecho esto, he hablado con muchos desarrolladores a lo largo de los años para saber que esto no es extraño.

Desafortunadamente, estoy empezando a pensar que no tenemos una profesión. No tenemos un conjunto de reglas, un conjunto de prácticas comunes, una ética que todo desarrollador debe seguir para ser considerado un profesional. Tampoco tenemos una organización común que tome las medidas necesarias cuando un desarrollador se comporta en contra de nuestro conjunto común de estándares.

## Las reglas

No estoy de acuerdo con todo lo que dice `Tío Bob`, pero sí estoy de acuerdo en que hasta que esto suceda, al menos deberíamos comenzar a comportarnos como profesionales. Aquí hay algunas reglas que ha señalado:

* El código que produzco siempre será mi mejor trabajo. No permitiré a sabiendas que se acumule código defectuoso, ya sea en comportamiento o estructura.
* Produciré, con cada lanzamiento, una prueba rápida, segura y repetible de que cada elemento del código funciona como debería.
* Haré lanzamientos frecuentes y pequeños para no obstaculizar el progreso de los demás.
* Mejoraré sin miedo y sin descanso mis creaciones en cada oportunidad. Nunca los degradaré.
* Haré todo lo que pueda para mantener la productividad de mí mismo y de los demás lo más alta posible. No haré nada que disminuya esa productividad.
* Me aseguraré continuamente de que otros puedan cubrirme y que yo pueda cubrirlos.
* Produciré estimaciones que sean honestas tanto en magnitud como en precisión. No haré promesas sin certeza.
* Nunca dejaré de aprender y mejorar mi oficio.

## El verdadero profesional

Desde que esos problemas se volvieron claros para mí, me he estado comportando en contra de un conjunto más alto de estándares, he caído en la comunidad de `Software Craftsmanship`.

Cada pieza de código que produzco tiene un conjunto de pruebas adjuntas. Como el proyecto no tenía pruebas, comencé a hacer pruebas por mi cuenta y a mejorar el código, eventualmente, el equipo se unió y ahora tenemos una cobertura de código bastante buena.

Cuando escribo una `bugfix` no busco la solución fácil, primero encuentro la mejor implementación, a veces sucede que la mejor implementación no es viable debido a restricciones externas, pero esa decisión se toma mediante un análisis consciente, no por pereza.

Si alguien que no pertenece al equipo de desarrollo intenta imponerme una fecha límite, analizo si esa fecha límite es factible, si no es así, mantengo mi posición y digo que bajo esos requisitos esa fecha límite simplemente no es posible, entonces trato de encontrar un compromiso que pueda funcionar para ambas partes.

Durante mis horas de oficina, siempre trabajo. Es mi trabajo hacerlo, me pagan por hacerlo. Nada que discutir.

Aunque hay ciertas situaciones en las que tu empleador es responsable de pagarte para mejorar (si, por ejemplo, necesitas aprender cierta tecnología para poder implementarlo en la empresa), no dejo mi mejora general a mi empleador, yo estoy en control de mi carrera.
Cuando voy a casa leo libros, escucho podcasts, programo otros paradigmas y lenguajes, es mi responsabilidad y también es muy divertido 😉

***

Debo decir que hasta ahora mi carrera ha mejorado mucho desde que cambié mi mentalidad, mis colegas y compañeros de trabajo me han reconocido, me he responsabilizado por mis triunfos pero también por mis errores. Ser profesional no es fácil, es mucho más fácil no tener ningún tipo de estándares para ti mismo, pero hacerlo de manera incorrecta tampoco tiene recompensa.

Espero que te haya gustado el artículo, avísame en los comentarios si has visto a otros o incluso a ti mismo comportarte así antes, ¿crees que me falta algo? házmelo saber en los comentarios.

Si te gusta esta publicación, compártela en las redes sociales 😀


Are you sure you are a professional developer?

¿Estás seguro de que eres un desarrollador profesional?

Hola chicos, ¿cómo han estado? Ha pasado casi un mes desde mi último artículo y debo decir que he estado luchando por concentrarme. Creo firmemente en el autoanálisis y la mejora continua, pero últimamente no he estado en la cima de mi juego.

Esta próxima publicación será un poco extraña, no es lo que suelo publicar. En lugar de dirigir el contenido en una determinada dirección, esta será una conversación conmigo mismo, tratando de hacerme recordar cuáles son mis valores y por qué hago las cosas que hago. Aún así, espero que vean algunas cosas en ustedes mismos y obtengan algo positivo, incluso si solo es para darse cuenta de que todos pasamos por problemas y falta de motivación.

***

Todos los días nos despertamos y decimos, hoy es el día, hoy seremos mejores, haremos ejercicio, comeremos sanamente, aprenderemos, y cada día pasa y se consume un día más.
Nos quedamos en la cama porque nos sentimos cómodos allí, debajo de las sábanas el mundo es más agradable. Sin responsabilidades, sin obstáculos en nuestro camino, sin gente mala, pero tambien sin alegría, sin satisfacción.

¿Te trajeron a este mundo para sentirte cómodo? quedarte en la cama y dejar pasar el tiempo? Recuerda que el tiempo es precioso, siempre lo supiste. `Memento Mori`, recuerda que eres mortal. No hay evidencia clara que muestre que hay algo más después de esto, probablemente esta es la única vida que tendras.

Y sé que la vida no ha sido fácil, pero tampoco ha sido tan mala. No eres el tipo de luchador que se rinde después de algunos golpes. Nariz rota, mandíbula rota, mano rota, y todavía estamos aquí lanzando golpes, si eso no funciona siempre podemos hacer clinch 😉. Sé honesto contigo mismo, ¿realmente la vida te está knockeando o simplemente te estás rindiendo? no hay nada que te impida alcanzar tus objetivos, ser la persona que quieres ser. Excepto tal vez vos mismo.

¿Cuál es el punto de quejarse?

Recuerda, hay dos tipos de cosas en la vida, las cosas que puedes controlar y las cosas que no puedes controlar. Si no puedes controlarlo, entonces no tiene sentido preocuparse por ello, porque no hay nada que puedas hacer al respecto.
Si, por otro lado, el problema está bajo tu control, ¿con quién te quejás? tienes la solución en tus manos, deja de quejarte y vuelve al trabajo.

¿Por qué malgastas el esfuerzo mental en pensar en lo que sucederá en el futuro?

Revisa tus objetivos. ¿Podría ser que estás poniendo demasiadas expectativas en los resultados? ¿Son realmente tan importantes los resultados? Es mejor medir el éxito por las acciones que realizas, por cómo te comportàs en función de tu propio conjunto de valores. Sabes qué es lo correcto, deja de preocuparte por lo que la gente pueda pensar y comienza a concentrarte en no deshonrarte y vivir a tu máximo potencial.

Esto no es un reproche, has hecho cosas buenas, has estado muy concentrado antes y tienes la autoestima necesaria para rendir al máximo de tus habilidades. El pasado es pasado, no tiene sentido culparte por los errores cometidos. En este mismo momento, puedes mejorar, ser mejor que ayer.
El hombre sabio vive sin remordimientos porque cada acción que toma se realiza mediante el uso de la razón, no espera nada y nada le sorprende. En este mismo momento, las virtudes son accesibles para ti como lo son para todos los seres humanos.

No intentes ser perfecto, solo trata de ser mejor cada día y deja que el futuro se cuide solo. Fracasarás en el futuro, volverá a suceder, lo prometo. No tiene sentido reiniciar desde cero cada vez que esto sucede. Como lo hacemos en el desarrollo de software, iteremos en nuestra vida, nuestras decisiones y nuestras virtudes.
Prueba, refactorización, mejora.

¿Vale la pena estar enojado?
A lo largo de la vida, conocerás personas que son groseras, egoístas y desleales, pero recuerda que las personas no son malas por naturaleza, simplemente no conocen nada mejor. Todos intentan hacer lo mejor que pueden con la información que tienen a la mano. ¿Es justo enojarse con las personas 'malas' cuando eres uno de ellos?

La vida humana es lidiar con el conflicto, sucederán muchas cosas hasta tu último aliento, en lugar de perder esos preciosos segundos en enojarte, mejor sonreír, ser amable, podrías dejar la vida ahora mismo, así que concéntrate en mejorar la vida para ti y los que te rodean

Mañana te despertarás como un hombre mejor, limpiando el dolor y enfocándote en lo que está frente a ti. Es hora de volver al ring.

![get up](/get-up.jpg)

***

Si te quedaste hasta el final de esta publicación, muchas gracias 😀. Es extraña y lo sé, pero necesitaba expresar mis pensamientos con palabras y, a lo largo de los años, he encontrado que escribir es la mejor manera de hacerlo. Espero que veas algunas luchas comunes entre mi vida y la tuya, te invito a hacer esto y compartirlo.

Como siempre, si te gustó la publicación, compártela en twitter y otras redes sociales. Te veo la proxima semana.


Winning a battle against yourself

Ganar una batalla contra ti mismo

¿Hola chicos, que hay? Han pasado algunas semanas desde que hablamos sobre este proyecto, por lo que podrían estar pensando que el proyecto se derrumbó, déjenme decirles que eso está lejos de suceder.

Hemos estado trabajando muy duro y haciendo un buen progreso en algunos fundamentos que nuestra aplicación necesita cubrir. Hoy les mostraré cómo usamos todo el poder de [Sanity](https://www.sanity.io/) para **hacer que nuestra página de inicio sea configurable y cargar imágenes de una manera bastante genial**, así que sin más preámbulos, vamos a eso.

***

## Los requisitos

Cada sitio web debe tener una página de inicio, por suerte para nosotros, nuestro equipo de diseño nos proporcionó diseños muy pulidos usando Figma que nos permitió verificar todo más rápido y estar siempre sincronizados. Se ve algo como esto:

![Página de inicio](/design.png)

Adjuntos a este diseño, los primeros requisitos comenzaron a aparecer.

* **Hacer la página de inicio configurable.**
* **Todas las imágenes deben cargarse de manera eficiente.**

Esos son grandes desafíos, pero [Sanity](https://www.sanity.io/) proporciona todo lo que necesitamos para implementarlos.

## Hacer una página configurable

Aquí lo que vamos a hacer es hacer algún tipo de esquema en [Sanity](https://www.sanity.io/) que permitirá al usuario definiar las propiedades de configuración, elegir las imágenes, el texto y hacer que nuestra página de inicio tenga todo lo que necesita para renderizar desde esa configuración.

Primero, definiremos 3 esquemas, uno para la `home`, uno para el `hero` y otro para las `categories`.
Para la página de inicio, comenzamos definiendo el título de la página de inicio, una propiedad del tipo `hero` y una propiedad del tipo `array de category`

```javascript
export default {
  name: "homeSettings",
  type: "document",
  title: "Home sections",
  __experimental_actions: [/*'create',*/ "update", /*'delete',*/ "publish"],
  fields: [
    {
      title: "TituloPagina",
      name: "homePageTitle",
      type: "string",
      readOnly: true,
      hidden: true,
    },
    {
      title: "Hero",
      name: "hero",
      type: "hero",
    },
    {
      title: "Categorias",
      name: "categories",
      type: "array",
      of: [{ type: "category" }],
    },
  ],
  initialValue: () => ({
    homePageTitle: "Configuración Home",
  }),
}
```

Para el `hero` definimos la imagen, el título, el subtítulo, el texto en el botón y la URL del botón.

```javascript
export default {
  name: "hero",
  type: "document",
  title: "Hero",
  __experimental_actions: [/*'create',*/ "update", /*'delete',*/ "publish"],
  fields: [
    {
      title: "Imagen",
      name: "image",
      type: "image",
      options: {
        metadata: ["lqip"],
      },
    },
    {
      title: "Titulo",
      name: "title",
      type: "string",
    },
    {
      title: "Subtitulo",
      name: "subtitle",
      type: "string",
    },
    {
      title: "Texto del boton",
      name: "buttonText",
      type: "string",
    },
    {
      title: "Url del boton",
      name: "buttonURL",
      type: "string",
    },
  ],
}
```

Finalmente, definimos un tipo llamado `category` que usaremos para hacer una lista de categorías que sea dinámica y editable.

```javascript
export default {
  name: "category",
  type: "document",
  title: "Categoria",
  __experimental_actions: [/*'create',*/ "update", /*'delete',*/ "publish"],
  fields: [
    {
      title: "Imagen",
      name: "image",
      type: "image",
      options: {
        metadata: ["lqip"],
      },
    },
    {
      title: "Nombre",
      name: "name",
      type: "string",
    },
  ],
}
```

Como cereza del postre, hacemos algunas modificaciones en cómo Sanity muestra los tipos dentro del `studio`:

```javascript
import S from "@sanity/desk-tool/structure-builder"
import { MdSettings } from "react-icons/md"

export default () =>
  S.list()
    .title("Content")
    .showIcons()
    .items([
      S.listItem()
        .title("Configuración Home")
        .child(
          S.document()
            .schemaType("homeSettings")
            .documentId("homeSettings")
        )
        .icon(MdSettings),
      // Add a visual divider (optional)
      S.divider(),
      // List out the rest of the document types, but filter out the config type
      ...S.documentTypeListItems().filter(
        listItem =>
          !["homeSettings", "hero", "category"].includes(listItem.getId())
      ),
    ])
```

Con esto obtenemos el siguiente resultado:

![Texto alternativo](/settings2.png)
![Texto alternativo](/settings.png)

Como puedes ver, **obtenemos una interfaz de usuario agradable con la capacidad de configurar todos los datos que queremos que use nuestro sitio, manteniendo un modelo separado para nuestros productos**. Esto también se ocupa del hecho de que solo podemos definir una configuración, no hay forma de crear un documento de inicio adicional.

Entonces, ¿cómo usamos esto en nuestro sitio web? si recuerdas nuestro episodio anterior, logramos llevar los productos de [Sanity](https://www.sanity.io/) al sitio web simplemente haciendo una consulta con el cliente JavaScript de [Sanity](https://www.sanity.io/), no hay diferencia aquí aunque la consulta es un poco más complicada.

Desde nuestra aplicación Next.js hacemos lo siguiente:

```javascript
export const getServerSideProps = async () => {
  const sanityResult = await sanity.fetch(
    `
    *[_type == "homeSettings"][0]{
      categories[] {   	  
        ...,
         "asset": image.asset-> {
            url,
            metadata 
         }
      },
       hero {
           ...,
         "asset": image.asset-> {
            url,
            metadata 
         }
       }
     }
  `
  )

  return { props: { ...sanityResult } }
}
```

Recuperamos todo el modelo `homeSettings`, observemos cómo estamos transformando las imágenes en un tipo de dato especial llamado [Asset](https://www.sanity.io/help/asset-metadata-field-invalid), será volvera claro por qué hacemos esto cuando nos encarguemos del siguiente requisito.

A partir de aquí, solo creamos una aplicación de React normal que usa esos valores para mostrar las imágenes y el texto, tan pronto como el administrador cambie algo de sanity studio, los cambios se reflejarán automáticamente en nuestro sitio web. Por cierto, si deseas verificar cómo estamos progresando, puedes consultar la implementación de nuestra master branch [aquí](https://by-maruja.now.sh/).

## Cargando imágenes de la manera correcta

Este es un tema complicado, hay toneladas de artículos y enfoques sobre cómo se deben cargar imágenes en un sitio web, hoy consideraremos dos problemas y veremos cómo implementamos las soluciones usando Sanity.

Lo primero que queremos considerar es que **para imágenes como la del `hero`, estas pueden ser súper grandes, lo que hará que nuestro sitio web se cargue muy lentamente. El enfoque estándar para este problema sería cargar la misma imagen en 3 tamaños diferentes y cargar cada una cuando sea apropiado.**

Este es un buen enfoque, pero en realidad, no podemos esperar que el usuario lidie con todas esas molestias. Afortunadamente, Sanity nos proporciona transformaciones de imagen directamente desde su API, puedes ir [aquí](https://www.sanity.io/docs/image-urls) si deseas leer más sobre el tema.

Pero, ¿qué significa esto para nosotros? muy simple, al ejecutar métodos desde el cliente JavaScript de Sanity podemos hacer que Sanity se ocupe del problema de proporcionar el tamaño de imagen correcto, solo tenemos que encargarnos de cargar la imagen con la mayor resolución que queramos admitir y después de eso Sanity se encargara de todo por nosotros. Veamos como.

En nuestro tag de imagen regular, definimos un `srcset` para proporcionar imágenes responsive, pero en lugar de tener los 3 archivos diferentes, pedimos 3 anchos diferentes al cliente Sanity.

```javascript
 srcSet={`
     ${builder.image(image).auto('format')?.width(600)} 600w,
     ${builder.image(image).auto('format')?.width(1000)} 1000w,
     ${builder.image(image).auto('format')} 2000w
`}
```

Súper fácil ¿verdad? Tal vez te preguntes, de qué se trata ese `auto('format')`, esa es otra gran cosa que podemos hacer con Sanity.

No podemos esperar que el usuario cargue la imagen en un formato que sea bueno para nuestro sitio web, por lo que al incluir esa llamada, si el navegador admite `webp`, devolverá la imagen usando ese formato, que es el mejor para la web .

¿Es suficiente? bueno, pensemos en ello por un minuto. Ahora las imágenes se cargarán dependiendo de la resolución que tengamos en el dispositivo, lo cual es excelente, pero aún estamos lidiando con el hecho de que **si la conexión a Internet es lenta, las imágenes tardarán una eternidad en cargarse** y la interfaz de usuario tardará años en cargarse y lucira raro mientras carga.

Para resolver este problema, hay dos cosas que podemos hacer, la primera es **Lazy Loading**. Esto significa que las imágenes se solicitarán a Sanity solo cuando las necesitemos. **Si la imagen no se ve en el viewport entonces, no se bajaran las imágenes**.

Para implementar esto, hay dos opciones, puedes hacer tu propio componente o usar una biblioteca como [React Lazy Loading Image Component](https://www.npmjs.com/package/react-lazy-load-image-component). En nuestro caso, todavía no hemos decidido si la biblioteca cubre todas nuestras necesidades asi que estamos manteniendo ambas implementaciones hasta estar seguros.
Con estos cambios, nuestras categorías de productos solo se cargarán una vez que nos desplazamos hacia abajo en nuestra página de inicio.

Finalmente, el último cambio que necesitamos es usar **Low Quality Image Placeholder (LQIP). Un LQIP es solo una versión borrosa muy pequeña de su imagen que se carga primero y se muestra inmediatamente mientras la real se carga en segundo plano. Cuando se carga la imagen real, se reemplaza el placeholder por la imagen real**. Esto permite que nuestro sitio web se vea bien mientras esperamos que se descarguen las imágenes.

Para eso, vamos a usar el `Asset` que mencionamos anteriormente. Sanity crea automáticamente un LQIP para nosotros como metadata de los asset de imagen. Lo único que tenemos que hacer es pedirlo al cliente y usarlo dentro de nuestro componente de imagen. Vamos a hacerlo:

```javascript
import { getImageAsset } from '@sanity/asset-utils';

src={getImageAsset(asset).metadata.lqip}
```

¿No me digas que no fue fácil? Veamos el resultado:

![página de inicio borroneada](/blur.png)

No se tu pero estoy super contento con el resultado 😀

***

Eso es todo, este fue un largo ejemplo práctico, así que quiero agradecerte mucho por quedarte conmigo hasta el final. Creo que te da una buena idea del tipo de cosas que puedes lograr usando un CMS como Sanity dentro de tu proyecto. Por cierto, tengo 0 afiliaciones con Sanity, pero tener este proyecto me está haciendo amar su increíble producto.

Si te gustó mi artículo y esta serie, por favor comparte y házmelo saber en los comentarios 😀


Let's build a custom e-commerce with the JAMstack

Creando una Aplicación de E-commerce con el JAMstack

Hola chicos, ¿cómo han estado? hoy voy a compartir con ustedes cuánto he progresado en estos 6 meses, analizar qué podría haber hecho mejor y qué cambios quiero hacer a mi plan, por cierto, si no han leído mi artículo anterior sobre desarrollo profesional pueden leerlo [aquí](https://www.patferraggi.dev/blog/2019/dic/planeando-2020/)

***

## El plan original

### 1. Volverme relativamente cómodo con la programación funcional.

* \~~Terminar el libro [Learn you a Haskell for great good](http://learnyouahaskell.com/).~~
* \~~Hacer un Snake Game como [este](https://www.youtube.com/watch?v=bRlvGoWz6Ig) pero en Haskell.~~
* \~~Volver a leer el libro [Mostly adequate guide to functional programming](https://mostly-adequate.gitbooks.io/mostly-adequate-guide/).~~
* \~~Volver a hacer el Snake Game pero con JavaScript.~~
* Leer el libro [Functional programming for the object oriented programmer](https://leanpub.com/fp-oo).
* Volver a leer el libro [Structure and interpretation of computer programs](https://web.mit.edu/alexmv/6.037/sicp.pdf).
* Aplicar programación funcional dia a dia en mis proyectos de JavaScript/TypeScript.
* Tener un proyecto personal con un lenguaje funcional para desarrollar cierta expertise en el(Elixir, Elm, Clojure o F# son los que tengo en mente por ahora).

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

* Leer [The imposter's handbook series](https://bigmachine.io/products/the-imposters-handbook/) por completo.
* Leer y estudiar [Clean Architecture](https://www.amazon.com/-/es/Robert-C-Martin-ebook/dp/B075LRM681).
* Leer [Domain Driven Design: Tackling complexity in the heart of software](https://www.amazon.com/-/es/Eric-Evans/dp/0321125215).
* Leer [Implementing Domain Driven Design](https://www.amazon.com/-/es/Vaughn-Vernon/dp/0321834577).
* Diagramar y analizar diseños de proyectos en los que actualmente trabajo y buscar posibles maneras de mejorarlos.

### 3. Volverme un frontend decente, no solo un backend dev que hace frontend.

* \~~Pagar una suscripción a [Frontend Masters](https://frontendmasters.com/).~~
* \~~Aprender sobre reactive functional programming (Rxjs).~~
* \~~Terminar los estilos de mi sitio personal y blog para ganar experiencia con CSS y animaciones.~~
* Meterme a fondo en el framework que utilice en mi trabajo, por el momento Angular.

### 4. Conseguir un trabajo remoto.

* \~~Aplicar a trabajos en sitios como [WeWorkRemotely](https://weworkremotely.com/) y muchos otros.~~
* \~~Aplicar a trabajos en compañías en las que me gustaría trabajar que ofrezcan trabajo 100% remoto.~~
* \~~Practicar Code Katas para pasar las coding interviews en sitios como [HackerRank](https://www.hackerrank.com/) (soy particularmente malo haciendo este tipo de entrevistas lamentablemente).~~
* Leer [Cracking the coding interview](https://www.amazon.com/-/es/Gayle-Laakmann-McDowell/dp/0984782850).

### 5. Escribir mínimo 1 blog post en Español a la semana.

* \~~Planear el tiempo dentro la semana para volverme metódico a la hora de escribir.~~
* \~~Escribir una lista de ideas para posibles artículos, a medida que surjan.~~
* \~~Documentar mi progreso con respecto a la programación funcional y la arquitectura de software.~~
* Escribir tutoriales para solidificar conocimientos.

### 6. Dar al menos 1 charla en alguna meetup.

* Crear una lista de temas posibles para dar una charla y elegir uno en el cual me encuentre interesado.
* Preparar la charla y darla quizás online a modo de práctica.
* Dar la charla primero en mi compañía actual enfrente de gente que conozco.
* Asistir a meetups con regularidad para ponerme en contacto con los organizadores.
* Asistir a meetups con regularidad e interactuar con otros miembros para superar el miedo y la ansiedad.

***

## La revisión

**1. Volverme relativamente cómodo con la programación funcional**

He progresado mucho en este campo, realicé algunas de las tareas que me propuse con respecto a este tema, también asisti a un curso sobre Category Theory y leí parte (no todo) de un libro sobre el tema que me dio un terreno común para comprender mejor otros conceptos.

También hice el [Curso de Functional JavaScript Light](https://frontendmasters.com/courses/functional-javascript-v3/) de Kyle Simpson en Frontend Masters, es muy bueno, muy claro, es un enfoque no BS que realmente me gusta. Todavía no he leído el libro, pero apuesto a que también es genial.

Después de leer [Mostly adequate guide to functional programming](https://mostly-adequate.gitbooks.io/mostly-adequate-guide/), también comencé a hacer algunos proyectos usando [FP-TS](https://github.com/gcanti/fp-ts), una biblioteca para hacer programación funcional en TypeScript y actualmente estoy usándolo en un sitio web e-commerce que estoy creando.

Después del proyecto de e-commerce, probablemente elegiré un lenguaje puramente funcional como Elm, Clojure o F # y obtendré tanta experiencia real como pueda.

Ahora que ya pase por esto, diría que saltar directamente a Category Theory probablemente no fue una buena idea, tuve que leer temas varias veces para entenderlos y me sentí realmente desanimado varias veces, no fue hasta que comencé a hacer JavaScript funcional y escribir sobre ello que me di cuenta cuánto había aprendido.

**2. Profundizar en arquitectura de software y ciencias de la computación**

Bien, no hice nada aquí, nada en absoluto. Me he centrado tanto en otras cosas que fue muy difícil alinearme con esto. Tengo los libros en mi Kindle, así que me centraré en este tema la segunda parte del año, no quiero posponerlo porque sé lo interesante que podría ser y cuánto podría ayudar a mi carrera ahora que estoy alcanzando mi sexto año como desarrollador.

**3. Volverme un frontend decente, no solo un backend dev que hace frontend**

Entonces, todavía soy un tipo de backend que hace algo de frontend, pero mis habilidades y mi confianza han crecido enormemente en los últimos meses, desde entonces reconstruí mi sitio web/blog y ahora estoy creando desde cero un sitio web e-commerce completo. También cambié de puesto en mi trabajo actual para trabajar principalmente como frontend, de cualquier manera todavía reviso los pull requests de backend y de vez en cuando creo algunas API de asp.net core.

Este e-commerce va a ser muy importante para mí, soy parte de un equipo y lo estamos construyendo desde cero, pero necesito ocuparme de todo, construir cada componente, hacer SSR, administrar imágenes, fuentes, implementar, cree una estructura flexible para que pueda evolucionar con el tiempo.

Después de este proyecto, estoy pensando en abordar otro tipo de sitio web creado con Elm para poder matar dos pájaros de un tiro.
Aparte de eso, tomé un curso en Udemy sobre RX.js que fue muy útil para mi estresante primer mes como desarrollador frontend a tiempo completo.

**4. Conseguir un trabajo remoto**

Aquí he estado luchando, a principios de año tuve toneladas de malas entrevistas y comencé a dudar mucho de mis habilidades, todavía no tengo un trabajo remoto y estoy sufriendo el síndrome del impostor. Aún así, estoy tratando de cumplir con mi plan:

1. Haz un Kata o Coding Challenge al día.
2. Aplica a trabajos dos veces por semana.

Tengo que admitir que las ofertas de trabajo se han visto afectadas por Corona, pero creo que decir eso es solo una excusa, no he puesto suficiente esfuerzo en esta tarea. Mejoraré de ahora en adelante, **no hay otra manera que ser consistente** como hago con todo lo demás.

**5. Escribir mínimo 1 blog post en Español a la semana**

Bueno, si miras los números, verás que fallé en esta tarea, ahora estamos en la semana 23 del año y solo tengo 16 artículos escritos en 2020. Así que me quedo corto en 8, eso está bien. Tengo que admitir que algunos días ha sido difícil averiguar sobre qué escribir, no quiero volver sobre los mismos temas una y otra vez, pero también tengo que admitir que ha resultado ser muy útil para mi aprendizaje. Me di cuenta de esto cuando escribía sobre programación funcional, era una oportunidad para revisar los conceptos y explicarlos como me gustaría que alguien me lo hubiera explicado.

Todavía tengo 6 meses, en la segunda parte de este año, intentaré ponerme al dia e ir más allá.

**6. Dar al menos 1 charla en alguna meetup**

He hecho 0 progresos en este, definitivamente es uno que va a ser difícil para mí, soy un tipo muy introvertido, por lo que incluso ir a los organizadores y hablar con ellos será complicado, cuando las cosas se normalicen, voy a acelerar hablar en una meetup local, probablemente sobre programación funcional 😀

***

## La dura verdad

Ahora que he analizado cuáles eran mis objetivos al comienzo del año y marqué exactamente lo lejos que he llegado, empiezo a sentirme mejor con mi progreso. Para ser honesto, las últimas semanas han sido difíciles, he estado luchando con falta de motivación, pérdida de impulso y la sensación de tirar todo y simplemente comer pizza y no hacer nada.

Afortunadamente no dejé de leer, son libros como las Meditaciones de Marcus Aurelius o incluso "Libros técnicos" como The Clean Coder de Uncle Bob que me recuerdan por qué estoy haciendo esto. Es mi oficio, es mi meta en la vida, es sin duda lo que más disfruto, más que jugar, hacer Muay Thai, comer, dormir, etc. Así que debo despertarme, levantarme y hacer lo que me corresponde.

Te dejaré con dos fragmentos de los libros mencionados anteriormente:

Meditaciones:

> Al amanecer, cuando tenga problemas para levantarse de la cama, díganse: "Tengo que ir a trabajar, como ser humano. ¿De qué tengo que quejarme si voy a hacer para lo que nací?" ¿las cosas que me trajeron al mundo para hacer? ¿O es para esto para lo que fui creado? ¿Acurrucarnos bajo las mantas y mantener el calor? "

> ¿Entonces naciste para sentirte "bien"? ¿En lugar de hacer cosas y experimentarlas? ¿No ves que las plantas, los pájaros, las hormigas, las arañas y las abejas realizan sus tareas individuales, ordenando el mundo lo mejor que pueden? ¿Y no estás dispuesto a hacer tu trabajo como ser humano? ¿Por qué no estás corriendo para hacer lo que tu naturaleza exige?

> No te amas lo suficiente. O también te encantará tu naturaleza y lo que exige de ti. - Marco Aurelio

The Clean Coder:

> Tu carrera es tu responsabilidad. No es responsabilidad de tu empleador asegurarse de que seas comercializable.

> No es responsabilidad de tu empleador capacitarlo, enviarlo a conferencias o comprarle libros. Estas cosas son tu responsabilidad. Ay del desarrollador de software que confía su carrera a su empleador.

> Algunos empleadores están dispuestos a comprarte libros y enviarte a clases de capacitación y conferencias. Está bien, te están haciendo un favor. Pero nunca caigas en la trampa de pensar que es responsabilidad de tu empleador.

> Si su empleador no hace estas cosas por usted, debe encontrar la manera de hacerlo usted mismo.

> Tampoco es responsabilidad de su empleador darle el tiempo que necesita para aprender. Algunos empleadores pueden proporcionar ese tiempo. Algunos empleadores incluso pueden exigirle que se tome el tiempo. Pero nuevamente, te están haciendo un favor, y deberías estar apropiadamente agradecido.

> Tales favores no son algo que debe esperar.
> Le debe a su empleador una cierta cantidad de tiempo y esfuerzo. En aras de la discusión, usemos el estándar estadounidense de 40 horas por semana. Esas 40 horas deben dedicarse a los problemas de su empleador, no a sus problemas.

> Debe planear trabajar 60 horas por semana. Los primeros 40 son para su empleador. Los 20 restantes son para ti. Durante estas 20 horas restantes, debería estar leyendo, practicando, aprendiendo y mejorando su carrera. - Robert C. Martin

***

Realmente espero que hayas disfrutado de mi revisión de mis objetivos profesionales para 2020 y que te aliente a perseguir tus propios objetivos, el tiempo pasa, es ahora o nunca 😀


Planning my career development for 2020 - 6 months review

Como planeo el desarrollo de mi carrera para 2020, review de mitad de año

¿Hola chicos, que hay? Como parte del equipo de desarrollo de Maruja, hemos estado trabajando muy duro para hacer realidad el proyecto que analizamos en el último artículo, por cierto, si no has leído el primer artículo, te sugiero que comiences con ese porque hoy vamos a profundizar en la implementación.

Comenzaremos **configurando el proyecto de Next.js y la integración básica con Sanity y MercadoPago**. Entonces, sin más preámbulos, comencemos.

***

## La puesta en marcha

Como mencioné en la primera parte, decidimos usar el siguiente stack:

* [Next.js](https://nextjs.org/)
* [TypeScript](https://www.typescriptlang.org/)
* [Styled Components](https://styled-components.com/)
* [Jest](https://jestjs.io/) + [Enzyme](https://enzymejs.github.io/enzyme/) for testing
* [Sanity.io](https://www.sanity.io/)
* [MercadoPago](https://www.mercadopago.com.ar/)
* [Vercel/Now.sh](https://vercel.com/)

Afortunadamente, la configuración inicial es bastante sencilla, creamos una aplicación de Next con el siguiente comando:

```shell
npm init next-app by-maruja-ecommerce
```

Esto creará el siguiente proyecto de inicio, sin ninguna de las plantillas que trae Next.js. Después de eso, agregar TypeScript es pan comido, instalamos los TypeScript y los tipos de Node.js:

```shell
npm install --save-dev typescript @types/react @types/node
```

Y creamos un archivo `tsconfig.json` vacío:

```shell
touch tsconfig.json
```

Después de eso, si iniciamos la aplicación, el `tsconfig.json` será completado por nosotros y todo estará listo para funcionar. Instalar styled-components también es bastante sencillo, solo un comando:

```shell
npm install styled-components babel-plugin-styled-components @types/styled-components
```

Con Jest and Enzyme es donde las cosas se ponen un poco más complejas, por suerte siempre hay alguien que lo ha hecho antes que tú, y encontré [este gran artículo de Halil Kayer que me funcionó como por arte de magia](https://medium.com/@kjaer/setting-up-jest-and-enzima-para-typecript-next-js-apps-ce383167643).

Ahora viene la parte divertida, **las integraciones**.

## Sanity.io

Sanity tiene muy buena documentación e incluso algunos proyectos de ejemplo que usan Next.js, me referiré a un artículo en la página de Sanity que fue muy útil para crear el servicio y el Sanity Studio, puedes leerlo [aquí](https://www.sanity.io/blog/build-your-own-blog-with-sanity-and-next-js).

Después de crear el Studio y tener instalada la biblioteca de cliente de Sanity en nuestro proyecto, procedemos a crear nuestro primer esquema, **el producto**.

```javascript
import { BsBag } from "react-icons/bs"

export default {
  title: "Producto",
  icon: BsBag,
  name: "product",
  type: "document",
  fields: [
    {
      title: "Nombre",
      name: "name",
      type: "string",
    },
    {
      title: "Precio",
      name: "price",
      type: "number",
    },
    {
      title: "Stock",
      name: "stock",
      type: "number",
    },
    {
      title: "Imagen",
      name: "image",
      type: "image",
    },
  ],
}
```

Como puedes ver aquí, **definimos todas las propiedades que tendrá un producto en nuestro Sanity Studio. Nombre, precio, stock e imagen**, incluso el icono del menú usa 'react-icons' que viene por defecto con Sanity. Nuestro Studio se ve así:

![Product Sanity](/product.png)

La interfaz de usuario es súper simple y fácil de usar, **con nuestro esquema definido podemos crear múltiples productos y almacenarlos en Sanity**, en los siguientes artículos recuperaremos la lista de productos para mostrar nuestro catálogo en nuestro sitio web.

Por ahora, solo crearemos una pequeña prueba en nuestra página Index:

```jsx
const Index = (product: Product) => {
  const [buttonText, setButtonText] = useState("")

  return (
    <Layout>
      <Container>
        <Main>
          <p>
            Nombre: {product.name} - Stock: {product.stock} - Precio:{" "}
            {product.price}
          </p>
          <img src={urlFor(props.image)} alt="hero image" />
        </Main>
      </Container>
    </Layout>
  )
}

Index.getInitialProps = async () => {
  return sanity.fetch(
    `
    *[_type == "product"][0]
  `
  )
}
```

**En este ejemplo, solo recuperamos el primer producto (el único que tenemos actualmente) usando el lenguaje de consulta de Sanity (también puedes usar GraphQL), lo pasamos a nuestro componente de React que representa nuestra página Index y mostramos el nombre, el stock y precio dentro de un párrafo**.

**Luego, cargamos la imagen**. Para esto Sanity tiene una gran biblioteca que hará el trabajo por nosotros, primero ejecutamos el siguiente comando:

```shell
npm install @sanity/image-url
```

Y luego agregamos el siguiente código:

```jsx
import imageUrlBuilder from "@sanity/image-url"
import { SanityImageSource } from "@sanity/image-url/lib/types/types"

const builder = imageUrlBuilder(sanity)

export const urlFor = (source: SanityImageSource) => builder.image(source).url()
```

Después de algunos estilos para que tenga el tamaño adecuado, nuestra página se ve así:

![página después de cargar el producto](/producto-result.png)

Muy bien, ¿verdad? **el cliente de Sanity incluso tiene algunas funciones y propiedades que puedes usar para crear imágenes con el tamaño correcto sobre la marcha**, probablemente tendremos que lidiar con eso en los siguientes artículos.

## MercadoPago

Construir la integración con MercadoPago no fue tan fácil como esperaba, aunque la [Referencia de API](https://www.mercadopago.com.ar/developers) es bastante buena, carece de ejemplos y no hay ningún tipo de @types para obtener cierta compatibilidad con TypeScript en el [SDK oficial de MercadoPago JavaScript](https://www.mercadopago.cl/developers/es/guides/sdks/official/js/).

Después de algunas horas de buscar un ejemplo, mirando otros proyectos de código abierto que usan el servicio y "logeando" muchas cosas, seguí adelante e hice una pequeña definición de tipos para cubrir los metodos que vamos a usar para generar el enlace de pago. Con este enlace vamos a redirigir al usuario a la plataforma de MercadoPago para que se pueda procesar el pago.

```typescript
declare module "mercadopago" {
  export function configure(options: ConfigureOptions)
  export const preferences: Preferences

  export interface ConfigureOptions {
    client_id?: string
    client_secret?: string
    access_token: string
    sandbox?: boolean
    show_promise_error?: boolean = true
  }

  export interface PaymentItem {
    title: string
    description: string
    quantity: number
    currency_id: Currencies
    unit_price: number
    picture_url?: string
  }

  enum Currencies {
    ARS = "ARS",
  }

  export interface MercadoPagoResponse {
    response: {
      init_point: string
      sandbox_init_point: string
    }
  }

  export interface MercadoPagoPaymentRequest {
    items: PaymentItem[]
    back_urls?: {
      success: string
      pending: string
      failure: string
    }
    auto_return?: string
    external_reference: string
    expires: boolean
  }

  export interface Preferences {
    schema: {
      additionalProperties: false
      properties: PaymentRequest
    }
    partnersHeaders: true
    create: (data: MercadoPagoPaymentRequest) => MercadoPagoResponse
    save: Function
    update: Function
    get: Function
    findById: Function
  }
}
```

Después de definir esos tipos, seguímos adelante y creamos la [ruta API Next.js](https://nextjs.org/docs/basic-features/typescript#api-routes) que usaremos en nuestra aplicación para llamar a MercadoPago cuando se desea proceder con el pago. Definimos un pequeño servicio que funcionará como una capa entre la biblioteca del cliente de MercadoPago y nuestro código:

```typescript
import { configure, MercadoPagoPaymentRequest, preferences } from "mercadopago"

export function configureMercadoPagoSDK() {
  configure({
    access_token: process.env.mercadoPagoAccessToken,
  })
}

export const createPreferenceLink = async (data: MercadoPagoPaymentRequest) =>
  preferences.create(data)
```

Y lo llamamos desde nuestra ruta API:

```typescript
import { NextApiRequest, NextApiResponse } from "next"
import {
  configureMercadoPagoSDK,
  createPaymentLink,
} from "../../lamda-services/mercadopago.service"

export default async (req: NextApiRequest, res: NextApiResponse) => {
  configureMercadoPagoSDK()

  const result = await createPaymentLink(req.body)?.init_point
  res.json(result)
}
```

Después de eso, simplemente agregamos un botón y un párrafo y hacemos una llamada a nuestra ruta API desde nuestro Index. Nuestro código se ve así:

```jsx
const Index = (product: Product) => {
  const [buttonText, setButtonText] = useState("")

  const contactCreatePayment = () => {
    axios
      .post("/api/create-payment", paymentDataRequest)
      .then(result => setButtonText(result.data))
  }
  return (
    <Layout>
      <Container>
        <Main>
          <p>
            Nombre: {product.name} - Stock: {product.stock} - Precio:{" "}
            {product.price}
          </p>
          <Img src={urlFor(product.image)} alt="product" />
          <button type="button" onClick={contactCreatePayment}>
            Call MercadoPago
          </button>
          <br />
          <p id="buttonText">{buttonText}</p>
        </Main>
      </Container>
    </Layout>
  )
}
```

¿Y cuando hacemos clic en el botón en la pantalla? Voilà

![Enlace de MercadoPago](/mercadopago.png)

En los siguientes artículos, crearemos componentes reales y comenzaremos a construir la interfaz de usuario para nuestro sitio web.

***

Wow, eso fue mucho para asimilar, lo siento si fue una introducción dura, desafortunadamente, un artículo no es suficiente para guiarte en cada paso, como configurar ESLINT para TypeScript o agregar los estilos con styled-components. Si deseas ver un curso o un video tutorial donde veamos cada paso de la construcción de un proyecto, hágamelo saber en los comentarios a continuación y considera subscribirte a mi newsletter al final de este artículo, esa será la mejor manera de contactarte cuando eso suceda 😀

Si te gustó este artículo y cómo va la serie hasta ahora, compártelo.
