¡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.


Hola chicos, he estado un poco ausente últimamente, es porque he estado trabajando en la configuración de un proyecto que estoy abordando, un sitio web de comercio electrónico personalizado.

## Antecedentes

**Mi hermana tiene un negocio local en Argentina** llamado [By Maruja](https://www.instagram.com/bymaruja/) que lleva el nombre de mi abuela. Ella **vende accesorios para mujeres como aretes, collares** y cosas por el estilo. Por el momento, **tiene una tienda de [Tienda Nube](https://www.tiendanube.com/), este proveedor** es como Shopify y otros en el sentido de que **le permite crear su propia tienda con una plantilla predefinida y hacer un poco de personalización ligera, agregue sus productos y tenga todo configurado sin contratar a un diseñador, un desarrollador o pagar por separado los costos del servidor**.

Desafortunadamente, después de un tiempo llega a un punto en que **sitios como este no cubren sus necesidades o simplemente agregan demasiado costo mensual** para que sea viable para las pequeñas empresas en condiciones económicas inciertas. Entonces, dado que mi esposa es Diseñadora Gráfica (ella ya diseñó la marca) y yo soy un Desarrollador de Software, **decidimos echarle una mano y crear una solución** que satisfaga las necesidades de su negocio mientras que nosotros tengamos un proyecto realmente agradable para mostrar en nuestros portfolios.

## Las necesidades

* **Estilo y experiencia a medida**.
* **Fácil de agregar nuevos productos y cambiar el texto y las imágenes del sitio**.
* **MercadoPago como la principal plataforma de pago** (¿qué demonios es MercadoPago?).
* **Menos de 5 dolares al mes** de mantenimiento (espera, ¿qué?) (Sin el costo del dominio).

Ahora, te estarás preguntando qué demonios está pasando, ¿no? Quédate conmigo, voy a dar las presentaciones adecuadas.

Los dos primeros son bastante normales, ¿verdad? ella quiere tener un sitio web/tienda que coincida con la marca de la empresa, que pueda personalizarse fácilmente cuando haya nuevos productos en existencia o cuando entren en juego las promociones.

### MercadoPago

[MercadoPago](https://www.mercadopago.com.ar/) es el primero que los lectores de EE. UU./UE podrían preguntarse qué demonios es esto. En América Latina, no tenemos ningún sitio web designado para [Amazon](https://www.amazon.com/) al que podamos recurrir cuando queremos comprar cosas en línea. La mayoría de las veces los vendedores no envían a América Latina, o si lo hacen, aplican tarifas gigantescas. Incluso si pasas por alto todos estos problemas, algunos países, como Argentina, tienen restricciones muy fuertes sobre los productos importados, debes pagar una multa de hasta el 50% del precio del producto y, a veces, los productos quedan varados en la aduana y pierdes tu dinero.

No se pierde toda esperanza, hay otra opción, una compañía llamada [MercadoLibre](https://www.mercadolibre.com.ar/). Básicamente tienen el monopolio de las compras en línea en muchos países latinoamericanos. Tienen oficinas en 18 países y emplean a unas 8000 personas. Esta compañía tiene su propia plataforma de pago llamada **MercadoPago que admite la mayoría de las tarjetas de crédito, transferencias directas e incluso pagos en cuotas mensuales**. Al menos en Argentina, la mayoría de las personas usan este servicio para comprar en línea, en su sitio web u otras plataformas (también debido al hecho de que el gobierno cobra una tarifa del 30% sobre los pagos realizados con sistemas de pago extranjeros).

### Por debajo de 5 dólares al mes

Puedes estar pensando, este tipo se volvió loco, finalmente sucedió. Escúchame, **para una pequeña empresa que recién está comenzando, los costos fijos pueden ser mortales**, especialmente en un país que tuvo una inflación del 54% en el último año. El costo actual es simplemente demasiado teniendo en cuenta el hecho de que las posibilidades que ofrecen estos sitios son limitadas.

## El análisis

Comencé reduciendo las opciones en función de las limitaciones que tiene el proyecto:

**MercadoPago como plataforma de pago**.

* Shopify
* Wordpress + Woocommerce
* Sitio web personalizado con integración a la API de MercadoPago

**Por debajo de 5 dolares al mes de mantenimiento**.

* Woocommerce (Tal vez)
* Sitio web personalizado con integración a la API de MercadoPago

**Estilo y experiencia a medida**.

* Wordpress + Woocommerce (tengo que aprender WordPress y es stack)
* Sitio web personalizado con integración a la API de MercadoPago

**Fácil de agregar nuevos productos y cambiar el texto y las imágenes del sitio**.

* Wordpress + Woocommerce
* Otras soluciones de comercio electrónico/CMS
* Sitio de administración personalizado

Después de mirar varias posibilidades, me pareció que mis dos opciones principales eran Wordpress + Woocommerce o crear algo personalizado.
**Mi principal problema con Wordpress fue que primero no sé nada al respecto. Me iba a llevar mucho tiempo aprender cómo construir un sitio web completamente funcional y desplegarlo de forma segura en un servidor**, tampoco estaba seguro de poder mantener los costos por debajo de los 5 dólares.

**Decidí ir a un sitio web personalizado**. Pero no todo va a ser personalizado, todavía quiero evitar tener que lidiar con la autenticación de administrador, tener un sitio de administración personalizado para mantener o tener un servidor con una base de datos para mantener.

## El tech stack

En el último año, he estado construyendo mi propio sitio web/blog con Gatsby y deployando en Netlify, así que aprendí a amar el poder del [JAMstack](https://jamstack.org/). Pensé que esto podría encajar bien con el patrón, así que comencé a evaluar opciones que cumplirían los requisitos mencionados anteriormente.

**Sitio web**

* Gatsby
* Next.js

**Capacidades de comercio electrónico / CMS**

* Sanity.io (generosa cuota gratuita)
* DatoCMS (generosa cuota gratuita)
* Prismic (generosa cuota gratuita)

**API para la integración**

* Funciones serverless de Next.js (generosa cuota gratuita)
* Funciones de Netlify (generosa cuota gratuita)

**Hosting**

* Netlify (mayormente gratis)
* Vercel/Now.sh (mayormente gratis)

**No importa el camino que tome, me dara un sitio web súper elegante y rápido, con capacidades de administración, implementado en un alojamiento de calidad con prácticamente 0 costos**.

Al final, **fueron las diferencias entre Gatsby y Next.js las que definieron la decisión, Gatsby es un generador de sitio estático**, lo que significa que el sitio se construye cuando se envía un commit al repositorio y luego se sirve como contenido estático cada vez que alguien llama a nuestra URL, esto es excelente para los costos y el rendimiento del servidor, pero se vuelve complicado cuando hay información que puede cambiar a menudo, en nuestro caso, ese cambio es el stock de nuestros productos.

Cada vez que se realiza una compra, el stock se actualiza en nuestro CMS y se debe activar una compilación en el sitio web de Gatsby para mostrar el stock correcto. **Next.js, por otro lado, es una navaja suiza, tiene generación de sitios estáticos, pero también tiene renderización del lado del servidor e incluso puede funcionar como una aplicación de normal de React**, esto significa que podemos adaptar las páginas a nuestras necesidades específicas y solo usar recursos del servidor cuando sea necesario.

Entonces, aunque Gatsby tiene algunas ventajas bastante buenas, como complementos para la carga de imágenes de manera performante y la integración con Sanity, decidí que Next.js era el más adecuado para lo que queremos construir.

El tech stack completo en el momento de escribir es:

* [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/) para probar
* [Sanity.io](https://www.sanity.io/)
* [Vercel/Now.sh](https://vercel.com/)

Y fui por la siguiente arquitectura:

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

Cuando un usuario accede al sitio web, los productos se renderizaran en el servidor desde Sanity y se cargarán en el sitio web.
Cuando un usuario quiere comprar algo, una función serverless se pondrá en contacto con la API de MercadoPago y generará el enlace apropiado para pagar en su plataforma.
Una vez completado el pago, el hook de la API de MercadoPago notificará a otra función serverless que actualizará el stock en Sanity.

## El equipo

He estado haciendo sesiones de programación en pares de manera semanal con un amigo que durante los últimos 6 meses ha estado tratando de cambiar las carreras de la enseñanza al desarrollo de software, es un tipo increíblemente apasionado y tiene un futuro brillante por delante, pero hemos estado luchando por encontrar ejemplos reales para trabajar. Por el lado de mi esposa, durante los últimos meses, ha estado ayudando a una amiga común, principalmente mejorando su CV como Diseñadora y dando un ojo extra a sus proyectos independientes.

Me sentí muy aliviado cuando nos ofrecieron una mano en este proyecto, ya que tenía dudas de que pudiéramos llevarlo a cabo por nosotros mismos en un tiempo razonable. Entonces nuestro equipo es:

* [Yo](https://www.patferraggi.dev/), desarrollador de software.
* [Manuel Aceituno](https://github.com/Acemanu412), desarrollador de software.
* [Sofia Toso](https://sofiatoso.com/), diseñadora visual /UX.
* [Thanh-Hông LÊ (Camille)](https://medium.com/@thanhHong0702) diseñadora de UX.

## Próximos pasos

En las próximas semanas, haremos un buen progreso en diseño e implementación. Escribiré una serie de artículos que explicarán cómo creamos la estructura del proyecto, cómo nos integramos con Sanity y MercadoPago, cargamos datos reales en nuestro sitio web, creando el carrito y el pago, y finalmente deployando. Si te gusta a dónde va esto, házmelo saber a continuación en los comentarios. Si tienes alguna sugerencia para el proyecto, soy todo oídos, hágamelo saber a continuación. Como siempre, si te gustó este artículo, comparte y subscribite a mi newsletter 😀
