DEV Community: Gino Luraschi

React v19, unboxing! 📦

Gino Luraschi — Mon, 23 Dec 2024 22:31:00 +0000

Introduccion

React v19 acaba de salir. Hoy en día, es una de las bibliotecas más populares del mundo, destacada por su simplicidad y su eficiente manejo del DOM. Este año se lanzó una nueva versión, y aquí te traigo todas las novedades, con ejemplos prácticos, como siempre, pero en español 👀.

Actions

Las Actions son transiciones asincrónicas que realizas, como llamadas al backend para actualizar estados. Esta novedad facilita el manejo de formularios en React, incorporando nuevos hooks, como por ejemplo el useTransaction():

Cómo manejábamos los formularios antes:

// Before Actions
function UpdateName({}) {
  const [name, setName] = useState("");
  const [error, setError] = useState(null);
  const [isPending, setIsPending] = useState(false);

  const handleSubmit = async () => {
    setIsPending(true);
    const error = await updateName(name);
    setIsPending(false);
    if (error) {
      setError(error);
      return;
    }
    redirect("/path");
  };

  return (
    <div>
      <input value={name} onChange={(event) => setName(event.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>
        Update
      </button>
      {error && <p>{error}</p>}
    </div>
  );
}

Con el uso de useTransaction()

// Using pending state from Actions
function UpdateName({}) {
  const [name, setName] = useState("");
  const [error, setError] = useState(null);
  const [isPending, startTransition] = useTransition();

  const handleSubmit = () => {
    startTransition(async () => {
      // Esta transicion es una llamada a una API asincrona
      // Aca isPending = true
      const error = await updateName(name);
      if (error) {
        setError(error);
        return; // Aca isPending = false
      }
      redirect("/path"); // Aca isPending = false
    });
  };

  return (
    <div>
      <input value={name} onChange={(event) => setName(event.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>
        Update
      </button>
      {error && <p>{error}</p>}
    </div>
  );
}

Nuevos hooks

useActionState

Una manera de simplificar los llamados a las Actions es utilizando el nuevo hook useActionState

// Using <form> Actions and useActionState
function ChangeName({ name, setName }) {
  const [error, submitAction, isPending] = useActionState(
    // los valores del campo son los nombres de los inputs
    async (previousState, formData) => {
      // isPending es true
      const error = await updateName(formData.get("name"));
      if (error) {
        return error; // esto settea el error, isPending es false
      }
      redirect("/path");
      return null; // isPending es false
    },
    null
  );

  return (
    <form action={submitAction}>
      <input type="text" name="name" />
      <button type="submit" disabled={isPending}>
        Update
      </button>
      {error && <p>{error}</p>}
    </form>
  );
}

New hook: useOptimistic

El nuevo hook useOptimistic se utiliza para cambiar el resultado de un valor mientras se realiza una petición, sin necesidad de esperar el resultado y siendo optimista respecto al resultado esperado de la petición.
En este ejemplo se muestra cómo podemos establecer el nombre antes de realizar la petición:

function ChangeName({ currentName, onUpdateName }) {
  const [optimisticName, setOptimisticName] = useOptimistic(currentName);

  const submitAction = async (formData) => {
    const newName = formData.get("name");
    setOptimisticName(newName); // Aca se muestra el nombre actual antes de confirmarse el cambio
    const updatedName = await updateName(newName);
    onUpdateName(updatedName); // Aca confirmamos el cambio del nombre
  };

  return (
    <form action={submitAction}>
      <p>Your name is: {optimisticName}</p>
      <p>
        <label>Change Name:</label>
        <input
          type="text"
          name="name"
          disabled={currentName !== optimisticName}
        />
      </p>
    </form>
  );
}

React DOM

Actions

Como vimos en useActionState, ahora el campo del formulario puede recibir nuevos atributos, como action y formAction, para trabajar con <form>, <input> y <button>.

Algo interesante al trabajar con acciones es que, cuando el formulario se envía correctamente, React resetea automáticamente los formularios. Si deseas resetear el formulario manualmente, puedes llamar a requestFormReset de la API del React DOM.

New hook: useFormStatus

Otra herramienta interesante que se suma a esta nueva versión de React es el hook useFormStatus, que permite utilizar el campo isPending de los hooks mencionados anteriormente. Esto es útil cuando tenemos, por ejemplo, un componente de carga. Podemos utilizar el estado del formulario padre para mostrar y ocultar este componente de carga. La forma de utilizar este hook puede ser la siguiente:

// Este componente es llamado desde donde se implemente nuestro formulario
import { useFormStatus } from "react-dom";

function LoadingComponent() {
  const { pending } = useFormStatus();
  return pending ? <>Loading...</> : <></>;
}

useFormStatus lee el estado del formulario padre como si fuera un Context Provider.

Nuevas APIs

use

En la nueva versión de React se agregó use para leer recursos en tiempo de renderizado.

Por ejemplo, podemos leer una promesa con use y React suspenderá el renderizado hasta que la promesa se resuelva:

const DataComponent: React.FC = () => {
  const user = use(fetchUser()); // fetch user es asincrono

  return (
    <div>
      <h1>{user.name}</h1>
    </div>
  );
};

export default DataComponent;

SSG y Server components

Para Static Site Generation (SSG), React agregó 2 nuevas APIs:

prerender
prerenderToNodeStream

En cuanto a los server components:
Los Server Components de React permiten renderizar componentes anticipadamente en un entorno separado del cliente o del servidor SSR, llamado "server" en los React Server Components. Pueden ejecutarse una vez durante la construcción en un servidor CI o por solicitud en un servidor web. React 19 incluye todas las características de los Server Components, lo que permite a las bibliotecas compatibles usarlas como dependencia con una condición de exportación react-server para frameworks con arquitectura Full-stack React.

Los actions en SSR:
Las Server Actions permiten que los Client Components llamen funciones asincrónicas ejecutadas en el servidor. Al definir una Server Action con la directiva use server, el framework crea automáticamente una referencia a la función del servidor y la pasa al Client Component. Cuando esta función se llama desde el cliente, React envía una solicitud al servidor para ejecutarla y devuelve el resultado.

Algunas mejoras en React 19

ref as a prop
Ahora podes acceder a ref como una prop para functional components:

import React, { forwardRef, useRef } from "react";

// Aca recibimos ref como prop
const MyInput = forwardRef((props, ref) => {
  return <input type="text" placeholder={props.placeholder} ref={ref} />;
});

const MyForm = () => {
  const inputRef = useRef(null);

  const focusInput = () => {
    if (inputRef.current) {
      inputRef.current.focus();
    }
  };

  return (
    <form>
      <MyInput placeholder="Escribe algo..." ref={inputRef} />
      <button type="button" onClick={focusInput}>
        Focalizar Input
      </button>
    </form>
  );
};

export default MyForm;

En el futuro se eliminara forwardRef.

Diffs for hydration errors
También se eliminarán algunos errores en la consola en el momento de la hidratación (Más info aquí)

`<Context>` como Provider

Ahora se utliza <Context> en lugar de <Context.Provider>:

const CartContext = createContext('');

function App({children}) {
  return (
    <CartContext value={{ cart, addItem, substractItem, removeItem, cleanCart }}>
      {children}
    </CartContext>
  );  
}

Cleanup functions para refs
Ahora React 19 soporta el retorno de una funcion para limpiar los ref callbacks:

<input
  ref={(ref) => {
    // ref es creado
    // mi codigo
    // Este codigo se ejecuta cuando el componente es quitado del DOM
    return () => {
      // codigo de limpieza
    };
  }}
/>

useDeferredValue ahora acepta un valor inicial
Se agrego una nueva opcion para inicializar el valor de un deferredValue

function Search({deferredValue}) {
  // El valor inicial es ''
  // Se planea un inicio tardio para el valor de query
  const value = useDeferredValue(deferredValue, '');

  return (
    <Results query={value} />
  );
}

Soporte para metadata
Ahora se agrego el soporte para metadata en React que antes solo se podia hacer en el tag <head> o a traves de librerias:

function BlogPost({post}) {
  // En el componente articulo estamos definiendo meta y link, que antes no se podia
  return (
    <article>
      <h1>{post.title}</h1>
      <title>{post.title}</title>
      <meta name="author" content="Josh" />
      <link rel="author" href="https://twitter.com/joshcstory/" />
      <meta name="keywords" content={post.keywords} />
      <p>
        Eee equals em-see-squared...
      </p>
    </article>
  );
}

En cuanto a las hojas de estilo:
Ya sean externas o en línea, requieren una ubicación cuidadosa en el DOM debido a las reglas de precedencia. Esto complica su uso dentro de componentes, lo que lleva a cargar estilos lejos de los componentes o a usar bibliotecas que gestionen esta complejidad. React 19 simplifica este proceso con soporte integrado para hojas de estilo, permitiendo especificar su precedencia. React gestiona el orden de inserción en el DOM y asegura que, si son externas, se carguen antes de mostrar el contenido que depende de ellas.

function ComponentOne() {
  return (
    <Suspense fallback="loading...">
      <link rel="stylesheet" href="foo" precedence="default" />
      <link rel="stylesheet" href="bar" precedence="high" />
      <article class="foo-class bar-class">
        {...}
      </article>
    </Suspense>
  )
}

function ComponentTwo() {
  // Esta hoja de estilo sera insertada entre foo y bar
  // En caso de existir una hoja de estilo igual en otro componente, solo se incluira una
  // Ademas se inluyo la posibilidad de renderizar asincrona
  return (
    <div>
      <p>{...}</p>
      <link rel="stylesheet" href="baz" precedence="default" />  
      <link rel="stylesheet" href="bar" async={true} precedence="high" />
    </div>
  )
}

Durante el renderizado del lado del servidor (SSR), React incluirá la hoja de estilo en el

para garantizar que el navegador no pinte el contenido hasta que esta se haya cargado. Si la hoja de estilo se detecta tarde, tras iniciar el streaming, React la insertará en el del cliente antes de mostrar el contenido de un límite de Suspense que dependa de ella. Durante el renderizado del lado del cliente (CSR), React esperará a que las hojas de estilo recién renderizadas se carguen antes de comprometer el renderizado, y si el componente se renderiza en varios lugares de la aplicación, React incluirá la hoja de estilo solo una vez en el documento.

Como actualizar?

Para actualizar hay una guia de actualizacion de React donde se explica detallado como hacerlo.

Fuente

Nada de esto es obra mía, solo es una pequeña traducción y resumen de lo que hay en este post en inglés: React v19

Conclusion

Se agradece la lectura y espero que les ayude. Algunas aclaraciones importantes:

Utilicé los ejemplos de la página porque me parecieron muy claros; otros los intenté adaptar a un ejemplo más práctico, y otros los generé con mi amigo GitHub Copilot.
Varios textos los generé con IA, mi nuevo gran amigo. Cualquier comentario o sugerencia siempre es bienvenido.

Composición vs Herencia

Gino Luraschi — Wed, 25 Sep 2024 01:11:51 +0000

Introducción

La herencia y la composición son dos conceptos fundamentales en la programación orientada a objetos (POO), pero se utilizan de manera diferente y tienen propósitos distintos. El objetivo de este post es repasar esos propositos, y algunas cosas a tener en cuenta a la hora de elegirlos.

Conceptos de la herencia

Cuando pensemos en aplicar la herencia en nuestros diseños, tenemos que entender:

Definición: En la herencia, una clase (llamada clase derivada o subclase) puede heredar propiedades y comportamientos de otra clase (llamada clase base o superclase). La clase derivada puede extender o modificar la funcionalidad de la clase base.
Relación: Es una relación "es un" (is-a). Por ejemplo, si tienes una clase "Vehículo" y otra clase "Automóvil", la clase "Automóvil" es una subclase de "Vehículo".
Ventajas: Promueve la reutilización de código y permite la extensión fácil de funcionalidades.

Conceptos de la composición

En cambio, si pensamos componer objetos entre sí:

Definición: En la composición, un objeto contiene otros objetos y delega parte de su funcionalidad a ellos. En lugar de heredar, una clase utiliza instancias de otras clases para lograr su funcionalidad.
Relación: Es una relación "tiene un" (has-a). Por ejemplo, si tienes una clase "Motor" y una clase "Automóvil", la clase "Automóvil" puede tener un objeto de la clase "Motor".
Ventajas: Mayor flexibilidad y menor acoplamiento entre clases. Cambios en una clase no afectan directamente a la otra.

Por qué composición sobre herencia?

La pregunta de si la composición es mejor que la herencia o viceversa es un tema debatido en el diseño de software. Ambos enfoques tienen sus ventajas y desventajas, y la elección depende del contexto y los requisitos específicos del proyecto. Aquí te presentaré un ejemplo donde la composición puede ser preferible a la herencia.

Vamos a explorar un ejemplo en Java que ilustre cómo la composición puede ser preferible a la herencia en ciertos casos. Supongamos que estamos trabajando en un sistema de procesamiento de pedidos en una tienda en línea.

Enfoque con Herencia:

Primero, consideremos un enfoque utilizando herencia para representar diferentes tipos de productos que se pueden comprar, como libros y electrónicos:

// Clase base para productos
class Producto {
    String nombre;
    double precio;

    Producto(String nombre, double precio) {
        this.nombre = nombre;
        this.precio = precio;
    }

    void procesarPedido() {
        System.out.println("Procesando pedido para " + nombre);
    }
}

// Clase para productos electrónicos que hereda de Producto
class ProductoElectronico extends Producto {
    String modelo;

    ProductoElectronico(String nombre, double precio, String modelo) {
        super(nombre, precio);
        this.modelo = modelo;
    }
}

// Clase para libros que hereda de Producto
class Libro extends Producto {
    String autor;

    Libro(String nombre, double precio, String autor) {
        super(nombre, precio);
        this.autor = autor;
    }
}

Este enfoque funciona, pero ¿qué pasa si necesitas introducir nuevos tipos de productos o agregar funcionalidades específicas para ciertos tipos de productos?

Enfoque con Composición:

En lugar de depender completamente de la herencia, podríamos utilizar la composición para manejar diferentes tipos de productos de manera más flexible:

// Clase para productos
class Producto {
    String nombre;
    double precio;

    Producto(String nombre, double precio) {
        this.nombre = nombre;
        this.precio = precio;
    }

    void procesarPedido() {
        System.out.println("Procesando pedido para " + nombre);
    }
}

// Clase para productos electrónicos que utiliza composición
class ProductoElectronico {
    Producto producto;
    String modelo;

    ProductoElectronico(String nombre, double precio, String modelo) {
        this.producto = new Producto(nombre, precio);
        this.modelo = modelo;
    }

    // Puedes agregar lógica específica para productos electrónicos si es necesario
    void procesarPedidoEspecifico() {
        System.out.println("Procesando pedido específico para " + producto.nombre);
    }
}

// Clase para libros que utiliza composición
class Libro {
    Producto producto;
    String autor;

    Libro(String nombre, double precio, String autor) {
        this.producto = new Producto(nombre, precio);
        this.autor = autor;
    }

    // Puedes agregar lógica específica para libros si es necesario
    void procesarPedidoEspecifico() {
        System.out.println("Procesando pedido específico para " + producto.nombre);
    }
}

En este enfoque, cada tipo de producto tiene una instancia de la clase Producto, lo que permite compartir la lógica común para procesar pedidos. Además, cada tipo de producto puede tener su propia lógica específica mediante métodos como procesarPedidoEspecifico(). Este diseño es más flexible y facilita la introducción de nuevos tipos de productos o la modificación de la lógica específica para cada tipo sin afectar la jerarquía de herencia.

Cuando aplicar herencia?

Si bien la elección entre herencia y composición en el diseño de software depende del contexto y de los requisitos específicos del problema que estás abordando. Aquí hay algunas situaciones en las que podrías considerar la herencia como una opción más apropiada que la composición:

Relación "es-un": La herencia es especialmente adecuada cuando hay una relación clara de "es-un" entre las clases. Si una clase B es una versión más específica o especializada de una clase A, entonces la herencia tiene sentido. Por ejemplo, si tienes una clase Vehiculo y una clase Automovil, la relación "es-un" es clara, ya que un automóvil es un tipo de vehículo.

class Vehiculo {
    // ...
}

class Automovil extends Vehiculo {
    // ...
}

Reutilización de código: La herencia permite la reutilización de código, ya que la clase derivada hereda los miembros y métodos de la clase base. Esto puede ser beneficioso cuando hay una cantidad significativa de código común entre las clases relacionadas.

class Animal {
    void comer() {
        // Lógica común para comer
    }
}

class Perro extends Animal {
    void ladrar() {
        // Lógica específica para ladrar
    }
}

Polimorfismo: La herencia es fundamental para la implementación del polimorfismo, que permite a las clases derivadas proporcionar implementaciones específicas de los métodos heredados de la clase base. Esto es útil en escenarios donde necesitas tratar objetos de clases derivadas de manera uniforme.

class Figura {
    void dibujar() {
        // Lógica común para dibujar una figura
    }
}

class Circulo extends Figura {
    void dibujar() {
        // Lógica específica para dibujar un círculo
    }
}

class Cuadrado extends Figura {
    void dibujar() {
        // Lógica específica para dibujar un cuadrado
    }
}

Extensiones de funcionalidad: Si estás extendiendo o especializando funcionalidad existente, la herencia puede ser más natural. Por ejemplo, si estás desarrollando una biblioteca y proporcionas una clase base con una funcionalidad básica, los usuarios de tu biblioteca pueden derivar de esa clase base para extender esa funcionalidad.

Que pasa si hacemos una mala herencia?

Si seguimos evaluando los pros y los contras de la herencia, uno de los problemas que puede surgir de una mala herencia es que violaríamos el Principio de Segregación de Interfaces, que indica que los clientes no deberían verse obligados a depender de interfaces que no utilizan. Si una interfaz se extiende de manera que incluya métodos que no son relevantes para todas las implementaciones, los clientes que utilizan esa interfaz podrían verse forzados a implementar o depender de métodos que no necesitan, lo que puede llevar a un diseño menos limpio y más difícil de mantener.

Conclusión

En resumen, la herencia se centra en la relación "es un" y se utiliza para modelar jerarquías de clases, mientras que la composición se centra en la relación "tiene un" y se utiliza para construir objetos complejos a partir de otros objetos más simples. Ambos enfoques tienen sus casos de uso específicos y se eligen según la estructura y la naturaleza de las relaciones en el diseño del software.

Multi-hilos en Java

Gino Luraschi — Thu, 26 Oct 2023 07:27:48 +0000

Introducción

La programación multihilo en Java permite a los desarrolladores crear aplicaciones que pueden realizar múltiples tareas simultáneamente. Cada tarea se ejecuta en su propio hilo, que es una unidad de procesamiento independiente. Los hilos permiten que una aplicación sea más receptiva, eficiente y capaz de aprovechar múltiples núcleos de CPU en sistemas modernos.

Java proporciona un sólido soporte para la programación multihilo a través de su API de concurrencia, que incluye clases y herramientas que facilitan la creación y gestión de hilos. Los hilos en Java se pueden utilizar para realizar tareas en segundo plano, procesamiento paralelo, tareas de larga duración y otros escenarios donde la concurrencia es necesaria.

Sin embargo, la programación multihilo también introduce desafíos, como la sincronización de hilos para evitar condiciones de carrera y problemas de concurrencia. La comprensión de los conceptos de sincronización, exclusión mutua y manejo seguro de recursos compartidos es fundamental en la programación multihilo en Java.

Hilos en Java

En Java, un "thread" (o hilo) es una unidad básica de ejecución que forma parte de un proceso más grande. Cada programa de Java se ejecuta en al menos un hilo, que generalmente se denomina "hilo principal" o "main thread". Los hilos permiten que una aplicación realice múltiples tareas de manera simultánea o en paralelo, lo que mejora la eficiencia y la capacidad de respuesta de la aplicación. Aquí hay algunos puntos clave sobre los hilos en Java:

Hilo Principal (Main Thread): Cuando ejecutas una aplicación de Java, se crea automáticamente un hilo principal que inicia la ejecución del programa. El método main de la clase principal se ejecuta en este hilo.

Creación de Hilos: Puedes crear hilos adicionales en Java de varias maneras, pero una de las más comunes es extender la clase Thread o implementar la interfaz Runnable. Los hilos creados de esta manera pueden realizar tareas en segundo plano y ejecutar código en paralelo.

Paralelismo y Concurrencia: Los hilos pueden usarse para lograr el paralelismo (donde las tareas se ejecutan verdaderamente simultáneamente en múltiples núcleos de CPU) o para la concurrencia (donde las tareas se alternan en la CPU para simular la simultaneidad). Java proporciona una API de concurrencia rica que facilita la administración de hilos y la sincronización de acceso a recursos compartidos.

Sincronización: La programación multihilo puede llevar a problemas de sincronización, como condiciones de carrera o bloqueos. Java ofrece mecanismos de sincronización, como synchronized y objetos bloqueo (Lock), para garantizar el acceso seguro a recursos compartidos entre hilos.

Beneficios de los Hilos: Los hilos se utilizan para mejorar la capacidad de respuesta de las aplicaciones y aprovechar la capacidad de procesamiento multicore de las CPU modernas. Se utilizan en aplicaciones que requieren ejecución simultánea de tareas, como aplicaciones gráficas, servidores web, aplicaciones de red y mucho más.

Los hilos en Java son unidades de ejecución que permiten que las aplicaciones realicen tareas concurrentes y paralelas. El uso adecuado de hilos puede mejorar el rendimiento y la eficiencia de las aplicaciones, pero también plantea desafíos de concurrencia que deben abordarse con cuidado. Java proporciona herramientas y bibliotecas para trabajar de manera segura y eficaz con hilos.

Herramientas en Java para la programación multihilo

Threads

Para la implementación de threads Java nos provee una suite de clases como por ejemplo la interfaz Runnable para crear elementos que van a correr en hilos, y justamente la clase thread que ejecuta los hilos.

Para este ejemplo pensemos el caso de un navegador que en el main principal carga una página, y a través de 2 hilos renderiza y descarga las dependencias. Para crear y ejecutar 2 hilos, nuestras clases tienen que extender de la interfaz runnable, y las mismas se tienen que instanciar (o poner una instancia) dentro de la creación de nuestro thread.

package multithreads;

public class App{

    public static void main(String[] args) {
        //...
        System.out.println("Loading web page..."); 
        Thread renderApp = new Thread(new RenderPage()); // Declaramos nuestro hilo para renderizar la página
        Thread downloadDependencies = new Thread(new DownloadDependencies()); // Declaramos el hilo para descargar las dependencias

        // Ejecutamos en paralelo
        renderApp.start();
        downloadDependencies.start();

        System.out.println("Finishing web page loading...");
    }
}
// RenderPage.java
package multithreads;

public class RenderPage implements Runnable{ // Cuando implementamos un runnable tenemos que implementar el método run() 

    @Override
    public void run() {
        System.out.println("Rendering app");
    }
}
// DownloadDependencies.java
package multithreads;

public class DownloadDependencies implements Runnable{ // Cuando implementamos un runnable tenemos que implementar el método run()
    @Override
    public void run() {
        System.out.println("Download dependencies....");
    }
}

Synchronized

La palabra clave synchronized se utiliza para crear bloques de código o métodos que están sincronizados o bloqueados, lo que significa que solo un hilo (thread) puede acceder a ese código o método a la vez. Esta característica se utiliza en programación concurrente para evitar problemas de concurrencia, como condiciones de carrera y accesos simultáneos a datos compartidos, que pueden llevar a comportamientos inesperados y errores en aplicaciones multi-hilo.

Cuando marcas un bloque de código o un método como synchronized, estás indicando que solo un hilo a la vez puede ejecutar este bloque o método, lo que garantiza la exclusión mutua. Esto es útil en situaciones en las que varios hilos pueden intentar acceder o modificar datos compartidos al mismo tiempo. El uso de synchronized ayuda a prevenir problemas de concurrencia, ya que otros hilos deben esperar su turno para acceder a la sección crítica del código.

En el siguiente ejemplo vemos como tenemos un carrito de compras al que podemos agregarles productos en paralelo, suponiendo que desde 2 clientes queremos agregar productos, para evitar una condición de carrera con la lista de productos hacemos que el método para agregar productos sea síncrono:

package multithreads.syncronized;

public class App {

    public static void main(String[] args) {
        final Cart cart = new Cart();

        // Creamos dos hilos que intentarán agregar elementos a la lista simultáneamente
        Thread thread1 = new Thread(() -> {
            cart.add("Prod 1");
        });

        Thread thread2 = new Thread(() -> {
            cart.add("Prod 2");
        });

        // Iniciamos los hilos
        thread1.start();
        thread2.start();

        // Esperamos a que ambos hilos terminen
        try {
            thread1.join();
            thread2.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}
// Cart.java
package multithreads.syncronized;

import java.util.ArrayList;
import java.util.List;

public class Cart {
    List<String> products = new ArrayList<>();

    public synchronized void add(String prod) {
        this.products.add(prod);
    }
}

Atomic

Los tipos atómicos en Java, como AtomicInteger, AtomicLong, y AtomicReference, se utilizan para realizar operaciones de manera atómica, lo que significa que garantizan que ninguna otra operación se puede ejecutar al mismo tiempo en el mismo dato, evitando problemas de concurrencia.

En este ejemplo veremos cómo utilizar el contador atómico para un caso similar al carrito, en este caso vemos que tenemos un item al que se puede estar llamando de forma concurrente de distintos clientes, para evitar la condición de carrera y tener de forma correcta la cantidad de ítems, utilizamos un contador atómico:

package multithreads.atomic;

public class App {

    public static void main(String[] args) {
        // Create cart
        // Add some items
        final Item item = new Item("Prod 1");

        // Creamos dos hilos que intentarán agregar elementos a la lista simultáneamente
        Thread thread1 = new Thread(() -> {
            for (int i = 0; i < 100; i++) {
                item.add();
            }
        });

        Thread thread2 = new Thread(() -> {
            for (int i = 0; i < 100; i++) {
                item.add();
            }
        });

        // Iniciamos los hilos
        thread1.start();
        thread2.start();

        // Esperamos a que ambos hilos terminen
        try {
            thread1.join();
            thread2.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println(item);
    }
}
// Item.java
package multithreads.atomic;

import java.util.concurrent.atomic.AtomicInteger;

public class Item {
    private final String name;
    private final AtomicInteger quantity;

    public Item(String name) {
        this.name = name;
        quantity = new AtomicInteger();
    }

    public String getName() {
        return name;
    }

    public AtomicInteger getQuantity() {
        return quantity;
    }

    public void add() {
        this.quantity.incrementAndGet();
    }

    @Override
    public String toString() {
        return "name='" + name + '\'' +
                ", quantity=" + quantity;
    }
}

ReentrantLock

ReentrantLock en Java es una implementación de la interfaz Lock que proporciona un mecanismo más flexible y poderoso para sincronización de hilos en comparación con synchronized blocks o métodos. A diferencia de synchronized, ReentrantLock permite la reentrada, lo que significa que un hilo que ya tiene el candado (lock) puede volver a adquirirlo sin causar un bloqueo, lo que es útil en situaciones específicas.

En este ejemplo, los dos hilos comparten una instancia de ReentrantLock para asegurarse de que solo un hilo pueda imprimir un número a la vez. La reentrada permite que el mismo hilo vuelva a adquirir el candado sin bloquear si ya lo tiene. Esto evita bloqueos y garantiza que los hilos no se bloqueen entre sí en la exclusión mutua.

Para este ejemplo, vamos a agregar 10 productos en 2 hilos distintos, al imprimir veremos que los productos se van agregando en un distinto orden al preestablecido:

package multithreads.reetrablocks;

public class App {
    public static void main(String[] args) {
        Cart cart = new Cart();

        // Hilos concurrentes intentan imprimir números del 1 al 10 de manera segura
        Thread thread1 = new Thread(() -> {
            for (int i = 1; i <= 10; i++) {
                cart.add("Thread 1 - prod " + i);
            }
        });

        Thread thread2 = new Thread(() -> {
            for (int i = 1; i <= 10; i++) {
                cart.add("Thread 2 - prod " + i);
            }
        });

        thread1.start();
        thread2.start();
    }
}
// Cart.java
package multithreads.reetrablocks;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.locks.ReentrantLock;

public class Cart {
    ReentrantLock lock = new ReentrantLock();
    List<String> products = new ArrayList<>();

    public synchronized void add(String prod) {
        lock.lock();
        try {
            System.out.println("Adding product " + prod);
            this.products.add(prod);
        } finally {
            lock.unlock();
        }
    }
}

Conclusión

En resumen, la programación multihilo en Java es una técnica poderosa para mejorar la eficiencia y la capacidad de respuesta de las aplicaciones al permitir la ejecución simultánea de múltiples tareas. Java proporciona las herramientas y las API necesarias para aprovechar esta funcionalidad de manera efectiva, pero es importante comprender y gestionar adecuadamente la concurrencia para evitar problemas de sincronización y errores.

Novedades en Go 1.21 🚀

Gino Luraschi — Thu, 17 Aug 2023 04:53:27 +0000

Introducción

Después de la versión 1.20, Go lanza la versión 1.21 con algunas pequeñas novedades para explotar un poco más el lenguaje, como siempre la nueva versión tiene retrocompatibilidad con versiones anteriores, por lo que cambiar a la nueva versión no debería impactar en lo que ya tengamos hecho. Sin más vamos a revisar cuales son las novedades en esta versión:

Cambios en el lenguaje

Min y Max

En esta nueva versión de Go encontramos funciones nuevas integradas como min y max, el cual toma un listado de valores y los compara devolviendo mínimo o máximo respectivamente.

package main

import "fmt"

func main() {
    x := 10
    y := 15
    mn := min(x, y) // m is the smaller of x and y
    fmt.Printf("The min is %d \n", mn)
    mx := max(x, y, 10) // m is the larger of x and y but at least 10
    fmt.Printf("The max is %d \n", mx)
    c := max(1, 2.0, 10) // c == 10.0 (floating-point kind)
    fmt.Printf("The max is %f \n", c)
    f := max(0, float32(x)) // type of f is float32
    fmt.Printf("The max is %f \n", f)
    // var s []string
    // _ = min(s...)// invalid: slice arguments are not permitted
    t := max("", "foo", "bar") // t == "foo" (string kind)
    fmt.Printf("The max is %s \n", t)
}

Clear

Otra novedad de la nueva versión de Go, es la función clear

package main

import "fmt"

func main() {
    var mapToClear = map[string]int{"k1": 1, "k2": 2, "k3": 3}
    clear(mapToClear) // Elimina todos los pares Key-Value (len(m) == 0)
    fmt.Printf("%v \n", mapToClear)
    var arr = []int{1, 2, 3, 4}
    clear(arr) // Vuelve todos los elementos al valor Zero del tipo
    fmt.Printf("%v \n", arr)
    /*
        var t = struct {
            // Name       string // Dato invalido para limpiar
            mapToClear map[string]int
        }{
            // Name:       "test",
            mapToClear: map[string]int{"k1": 1, "k2": 2, "k3": 3},
        }
         clear(t) // No se puede hacer esto, tira un error ya que t debe ser del tipo map o slice
    */
}

Otras cositas del lenguaje

En cuanto a los genéricos, se hicieron mejoras en cuanto a la inferencia de los tipos. Ahora se incluye una explicación sobre el proceso y como funciona en la documentación oficial.

Algo que planean hacer, que esta incluido en la version 1.21 de Go como experimental, es arreglar la captura de variables en los ciclos for, para eso recomiendan ir al caso escrito en LoopvarExperiment

Novedades de la SDK

Paquete log/slog

una de las cositas más interesantes que sumó esta nueva versión es el nuevo paquete log/slog para logging, el cual agrega funcionalidades a nuestro logging sin necesidad de sumar una librería:

package main

import (
    "log"
    "log/slog"
)

func main() {
    slog.Info("hello", "count", 3)
    // 2009/11/10 23:00:00 INFO hello count=3
    log.Println("hello", "count", 3)
    // 2009/11/10 23:00:00 hello count 3

    slog.Info("hello", "count", 1)
    // 2009/11/10 23:00:00 INFO hello count=1
    slog.Error("hello", "count", 2)
    // 2009/11/10 23:00:00 ERROR hello count=2
    slog.Warn("hello", "count", 3)
    // 2009/11/10 23:00:00 WARN hello count=3
    slog.Debug("hello", "count", 4)
    // 2009/11/10 23:00:00 DEBUG hello count=4

    // Print as json
    h := slog.NewJSONHandler(os.Stderr, &slog.HandlerOptions{Level: slog.LevelDebug})
    slog.SetDefault(slog.New(h))
    slog.Debug("it's a debug log")
}

Paquete slice

Nuevo paquete slice para manejo de slices justamente, esta incluye funcionalidades interesantes como métodos de ordenamiento o de búsquedas:

package main

import (
    "fmt"
    "slices"
)

func main() {
    arr := []int{8, 2, 4, 5, 1}
    slices.Sort(arr) // Es mutable, por lo que cambia el array original
    fmt.Println(arr) // [1 2 4 5 8]

    index, found := slices.BinarySearch(arr, 2)
    fmt.Println(found, index) // true 1
}

Paquete maps

Tambien se suma un nuevo paquete maps para los mapas pero con menos funciones:

package main

import (
    "fmt"
    "maps"
)

func main() {
    mapEx := map[string]int{"k1": 1, "k2": 2}
    mapClone := maps.Clone(mapEx)
    fmt.Println(mapClone) // map[k1:1 k2:2]

    equal := maps.Equal(mapEx, mapClone)
    fmt.Println(equal) // true
}

Paquete cmp

Tambien se agrega un nuevo paquete cmp para comparar elementos:

package main

import (
    "cmp"
    "fmt"
)

func main() {
    // -1 if x is less than y,
    // 0 if x equals y,
    // +1 if x is greater than y.
    x := 5
    y := 10
    res := cmp.Compare(x, y)
    fmt.Println(res) // -1
    res = cmp.Compare(y, x)
    fmt.Println(res) // 1
    res = cmp.Compare(5, x)
    fmt.Println(res) // 0

    isLess := cmp.Less(5, x)
    fmt.Println(isLess) // false
    isLess = cmp.Less(x, y)
    fmt.Println(isLess) // true
}

Profile Guided Optimization

La herramienta Profile Guided Optimization (PGO) anunciada en la versión 1.20 ahora está disponible sin necesidad de habilitarla. Con esta herramienta vamos a poder construir paquetes más optimizados. Incluso se ha medido el impacto en varios programas y se ve mejoras del 2% al 7%.

Mejoras en la performance

Además de lo mencionado en PGO, podemos ver:

El compilador de go fue reconstruido en la nueva versión con PGO habilitado, lo que logró hacerlo 2-4% más rápido dependiendo del sistema que lo ejecute.
Debido a la mejora en el Garbage Collector, se detecta una reducción del 40% en la latencia de cola.
Ahora la recolección de runtime/trace ahora reduce el costo para arquitectura arm64 y amd64.

Conclusión

Estas son algunas de las novedades que podemos detectar de la nueva versión de go, para más detalle puede ir a leer el blog oficial en https://go.dev/blog/go1.21. Espero les ayude este resumen a poder comprenderlo.

Escribir Golang como un Senior

Gino Luraschi — Sun, 11 Jun 2023 08:01:02 +0000

Introducción

Este post es una traduccion del post Write Go like a senior engineer, cuando lo leí me resultó interesante para compartirlo a partir del titulo, ya que toca varios puntos importantes cuando programamos en Go que son interesantes de profundizar. A esta lectura y comentarios como siempre, le agrego algunas cositas en base a mi experiencia.

Los parámetros en Go son pasados por valor

Por defecto, golang acepta pasajes por valor en sus funciones, lo que significa que lo que se recibe en la función es la copia del valor que pasamos. Esto impide que el valor de la estructura que estamos pasando mute dentro de la función a la que estamos llamando.
Veamos un ejemplo:

package main

import "fmt"

type Operation struct {
    Value float64
}

// Recibimos la operación y le "agregamos los impuestos"
func addTaxes(operation Operation) {
    operation.Value += operation.Value * 0.21
}

func main() {
    operation := Operation{Value: 100}
    // Llamamos a la función que agrega los impuestos
    addTaxes(operation)

    fmt.Printf("The total amount is: %f \n", operation.Value)
}

Al terminar esta función, detectamos que el valor no muto, con esto queda demostrado que el pasaje es por valor. En cambio, si quisiéramos modificar el valor de la operación, deberíamos recibir el puntero (la referencia al struct operation) como lo vemos a continuación:

package main

import "fmt"

type Operation struct {
    Value float64
}
// Ahora la función recibe la referencia a una `Operation`
func addTaxes(operation *Operation) {
    operation.Value += operation.Value * 0.21
}

func main() {
    operation := Operation{Value: 100}
    // Ahora se envia la direccion de memoria de `operation`
    addTaxes(&operation)

    fmt.Printf("The total amount is: %f \n", operation.Value)
}

En este caso si vemos que el valor muta ya que estamos cambiando el valor de la referencia, y no de una copia.

Usar punteros (pero no abusar)

Operador `*` y operador `&`

Como vimos en el ejemplo anterior, a la hora de manejarnos con punteros, podemos utilizar los símbolos * y &, pero que significa cada uno?

El operador * es la declaración de un puntero, por ejemplo podriamos tener la siguiente declaracion:

var operation *Operation

Lo cual significa que la variable operation, es del tipo puntero de Operation.
En cambio, el símbolo & significa, pasar el valor del puntero de una variable, o la inicialización del puntero de una estructura:

// Aca creamos un puntero a una nueva estructura del tipo Operation
operation = &Operation{Value: 100}
// Aca pasamos la referencia, o locación de memoria de la variable operation
addTaxes(&operation)

Aunque en el post original, diga

If you’re ever wondering “should I use a pointer here?” the answer is probably “Yes.” When in doubt, use a pointer.

Yo prefiero evitar punteros, esto lo voy a explicar en un post posterior porque hay tela que cortar.

Valor `nil`

El valor nil es el valor cero de los punteros en Go, una de las causa de los panic en go, debido a que a veces se trabaja con punteros nulos no chequeados. Esta es una de las causas por las cuales intento evitar punteros, porque se necesita ese check previo a la ejecución:

// `operation` es `nil`
var operation *Operation
// Al no estar chequeado, en el método nos arroja el panic
addTaxes(operation)

Para evitar esto, tenemos que chequear y asegurarnos que el puntero no será nulo de la siguiente forma:

    // `operation` es `nil`
    var operation *Operation
    // Estamos chequeando para evitar `operation == nil`
    if operation != nil {
        addTaxes(operation)

        fmt.Printf("The total amount is: %f \n", operation.Value)
    }

Declarar interfaces donde las vayas a usar

Las interfaces en Golang son explícitas, por lo que no es necesario declarar de donde se extienden, esto significa, que para poder extender de una interfaz, solo es necesario implementar sus métodos, veamos un ejemplo:

// UserRepository es el contrato que debemos cumplir
type UserRepository interface {
    FindByID(id string) User
    Save(user User)
}

// Esta será nuestra estructura que herede de la interfaz,
// notemos que no es necesario aclarar que extiende 
// de UserRepository
type SQLUserRepository struct {
}
// FindByID y Save son los métodos que implementamos para poder extender
func (S SQLUserRepository) FindByID(id string) User {
    panic("implement me")
}
func (S SQLUserRepository) Save(user User) {
    panic("implement me")
}

Esa es la forma de crear interfaces, cómo podemos asegurarnos de que nuestra clase cumple el contrato, tenemos 2 opciones:

// La primera que suelo hacer, es crear un constructor
func NewSQL() UserRepository { // ← this is the line
    return SQLUserRepository{}
}
// La segunda, es una recomendación escrita en el post
var _ UserRepository = (*SQLUserRepository)(nil)

Preferir tests en tablas, pero no hacer de más

En mi experiencia desarrollando Golang me he encontrado y he tenido que luchar con estos tests, no porque estuvieran mal hecho, sino que es muy difícil mantenerlos en el tiempo si la lógica de los métodos es compleja. Si, para probar entradas y salidas de tests funcionan perfectamente:

func Multiply(n1, n2 int) int {
    return n1 * n2
}
// Test de Multiply
func TestMultiply(t *testing.T) {
    cases := []struct {
        name           string
        n1             int
        n2             int
        expectedResult int
    }{
        {
            name:           "Multiply 2 numbers",
            n1:             2,
            n2:             4,
            expectedResult: 8,
        },
        {
            name:           "Multiply by 0",
            n1:             0,
            n2:             10,
            expectedResult: 0,
        },
    }

    for _, it := range cases {
        t.Run(it.name, func(t *testing.T) {
            result := Multiply(it.n1, it.n2)
            if result != it.expectedResult {
                t.Error("Result different, it'll fail")
                t.Fail()
            }
        })
    }
}

En este caso, se puede ver un test simple, al cual a medida que agregamos casos, no se modificará tanto el código. Por lo cual para estos casos, creo que funcionan perfectos.

Cuándo evitar la tabla de tests?

Es muy fácil encontrar momentos en los que las tablas de tests se pueden evitar, mayormente cuando la complejidad del método es grande. En mi experiencia me he topado con tablas de tests en las cuales se empiezan a mockear elementos de los distintos casos de uso, y en donde cada caso apunta a algo diferente. Ya no alcanza con una entrada o salida, ahora tenemos que configurar algo más! Les propongo un ejemplo que me he encontrado:

func TestUserSaver_Execute(t *testing.T) {
    cases := []struct {
        name        string
        user        User
        saver       UserSaver
        expectedErr string
    }{
        //...
    }

    for _, it := range cases {
        t.Run(it.name, func(t *testing.T) {
            err := it.saver.Execute(it.user)
            if len(it.expectedErr) > 0 {
                if err != nil {
                    if err.Error() != it.expectedErr {
                        t.Errorf("We expected the error: %s", it.expectedErr)
                        t.Fail()
                    }
                } else {
                    t.Errorf("An error was expected %s", it.expectedErr)
                    t.Fail()
                }
            }
        })
    }
}

En este caso la lógica es realmente compleja, para un método que realmente es simple. Por otro lado, si el caso de uso sigue incrementando su dependencia con otros componentes, los test se irán modificando. En un momento, si llegásemos a encontrar un bug, por experiencia propia, es muy complejo poder entender los tests y poder corregir ese problema.

Fuentes para seguir mejorando

Así como en el post original, quiero recomendarles una de las mejores guías para escribir go:

Effective Go

Conclusión

El objetivo de este post es aprender, y seguir aprendiendo, me parece una buena fuente para compartir con quien quiera seguir mejorando en su día a día en el lenguaje, toca puntos con los que me he cruzado y he luchado, por lo que dejó parte de mi experiencia por si a alguien le ayuda. Si conocen de otros puntos a sumar, bienvenidos sean, agradezco sus reacciones para poder motivarme a seguir compartiendo este conocimiento con todos los gophers de la comunidad hispana.

Herramientas para manejar Rutinas de Go

Gino Luraschi — Fri, 12 May 2023 03:31:44 +0000

Introducción

Como expliqué en algún post anterior, Golang ofrece herramientas muy interesantes y útiles, que nos ayudan a desarrollar nuestras aplicaciones. Por otro lado, también mencioné que Golang ofrece muchas facilidades para manejo de concurrencia, acá veremos algunas de esas herramientas que harán de nuestro trabajo concurrente más robusto.

Herramientas

En este post vamos a mencionar solo 3 de las muchas herramientas que ofrece Go para el manejo de concurrencia, sin entrar demasiado en detalle, próximamente planeo adentrarme un poco más en estos.

Rutinas de Go

Primero para entender cómo son y cómo funcionan las rutinas en golang, escribí sobre esto en un post anterior.

Canales

Partiendo de lo que son rutinas (threads virtuales livianos) los canales son, como su nombre lo índica, canales de comunicación entre estas rutinas, es una herramienta poderosa, porque cuando empezamos a ejecutar nuestras rutinas en paralelo, a veces nos encontraremos con la necesidad de compartir recursos entre estas rutinas.
Ante todo el slogan de la concurrencia en Golang es "No comunicarse compartiendo la memoria, compartir la memoria al comunicarse."
Habiendo dicho esto, podemos partir del siguiente ejemplo que ilustra el funcionamiento de un canal en Go:

package main

import (
    "bufio"
    "fmt"
    "os"
)

func main() {
    messages := make(chan string)

    // Acá se ejecuta la rutina y se pasa el canal
    go sendString(messages)

    // Acá se recibe el valor que se envío por el canal
    // Y se guarda en la variable msg
    msg := <-messages
    // Mientras esperamos recibir algo en el canal `messages` el thread queda bloqueado
    fmt.Printf("Message received %s", msg)
    fmt.Println("Another actions...")
}

func sendString(msg chan string) {
    text := readFromConsole()
    // Dentro del canal, enviamos el valor por el canal
    // Y seguimos el hilo de nuestra rutina
    msg <- text
}

func readFromConsole() string {
    reader := bufio.NewReader(os.Stdin)
    fmt.Print("Enter text: ")
    text, _ := reader.ReadString('\n')
    return text
}

En este ejemplo, vemos cuando nuestro método sendString pasa al canal msg el valor del texto que leímos por consola. Luego, en el thread principal de la función main al recibir el valor, desbloqueamos el thread principal que queda bloqueado.

Wait Groups

En cuanto a los wait groups, podemos definir sincronía entre los canales de manera que podamos ejecutarlos y esperar en caso de haber dependencia entre ellos. El funcionamiento es tan simple como declarar nuestro WaitGroup y después agregar rutinas a nuestro WaitGroup, posteriormente tenemos que avisar a nuestro grupo que cada rutina terminó.

package main

import (
    "fmt"
    "sync"
    "time"
)

func main() {
    var resp1 string
    var resp2 string
    // Declaramos nuestro WaitGroup
    wg := sync.WaitGroup{}
    // Avisamos que el límite será 2 rutinas
    wg.Add(2)
    go func() {
        resp1 = askToService1()
        // Avisamos que esta rutina terminó
        wg.Done()
    }()
    go func() {
    resp2 = askToService2()
        // Avisamos que esta rutina terminó
        wg.Done()
    }()
    // Esperamos a que las ejecuciones terminen
    wg.Wait()
    // Seguimos la ejecución
    fmt.Printf("Response 1: %s\n", resp1)
    fmt.Printf("Response 2: %s\n", resp2)
    fmt.Println("Another actions...")
}

func askToService1() string {
    time.Sleep(3 * time.Second)
    return "Hello"
}

func askToService2() string {
    time.Sleep(4 * time.Second)
    return "Bye bye"
}

Este es un caso práctico que hemos desarrollado en una de mis experiencias laborales, por lo que es un caso práctico y concreto sobre el uso de WaitGroup.

Mutex

Mutex es un término propio de ejecuciones del sistema operativo que se empeña para evitar las condiciones de carrera, lo que haremos es crear mutex para saber cuando un recurso está siendo accedido por otro hilo de ejecución. De esta manera, bloqueamos un recurso, y en caso de que ese recurso ya esté bloqueado vamos a esperar a que esté disponible.

package main

import (
    "fmt"
    "sync"
)

type Service struct {
    // Este mutex será el que bloquee el recurso `counters`
    mu       sync.Mutex
    counters map[string]int
}

func (svc *Service) increase(counterName string) {
    // Acá es donde bloqueamos el recurso
    // En caso de estar bloqueado por otra rutina, esperamos hasta desbloquearlo
    svc.mu.Lock()
    // El defer nos permite ejecutar el comando al terminar la función
    // Y con el mutex.Unlock() desbloqueamos el recurso
    defer svc.mu.Unlock()
    svc.counters[counterName]++
}

func (svc *Service) doIncrement(name string, limit int) {
    for i := 0; i < limit; i++ {
        svc.increase(name)
    }
}

func main() {
    c := Service{
        counters: map[string]int{"counterA": 0, "counterB": 0},
    }

    var wg sync.WaitGroup

    wg.Add(3)
    go func() {
        c.doIncrement("counterA", 1000)
        wg.Done()
    }()
    go func() {
        c.doIncrement("counterA", 1000)
        wg.Done()
    }()
    go func() {
        c.doIncrement("counterB", 1000)
        wg.Done()
    }()

    wg.Wait()
    fmt.Println(c.counters)
}

En el ejemplo, se nota como c.doIncrement("counterA", 1000) es prácticamente accedido al mismo tiempo 2 veces, para no pisar su valor, el mu.Lock() va a esperar hasta que se desbloquee el recurso.

Conclusión

En este post repasamos algunas de las herramientas de Go para manejo de concurrencia, pero también existen otras herramientas que posiblemente veremos más adelante. Así mismo, planeo adentrarme en más detalle acerca de estas herramientas, por lo que te recomiendo suscribirte y estar atento a los siguientes posts 😊 🔧

Clean Code, opinion personal 🤓

Gino Luraschi — Thu, 04 May 2023 05:55:19 +0000

Introducción

En este comienzo del 2023 me decidí a leer "Clean Code" de Robert C. Martin, a quien Wikipedia lo define:

Robert Cecil Martin (n. 1952, coloquialmente conocido como Uncle Bob) es un ingeniero de software y autor estadounidense, reconocido por desarrollar varios principios de diseño de software y ser uno de los coautores del Manifiesto Ágil. Martin es autor de varios artículos y libros. Fue editor de la revista C++ Report y primer director de la Agile Alliance.

En este post, voy a compartir mi opinión personal acerca de este libro, cualquier comentario es bienvenido para seguir discutiendo acerca de esto para compartir con quienes quieran seguir aprendiendo y mejorando en su carrera.

Opinión personal

La realidad es que muchos de los conceptos y recomendaciones hechas en el libro las he aprendido en base a mi experiencia. Como la experiencia es relativa, y esto me ha tomado mis 7 años de carrera (y muchas cosas las sigo aprendiendo), puedo decir que me hubiera gustado haberlo podido leer antes, este libro tiene buenas prácticas muy interesantes para incorporar y aplicar a lo largo de nuestra carrera como profesionales. Debemos hacer nuestro código lo mejor posible, no solo por las personas que vendrán, sino porque nosotros mismos podemos ser una de esas personas. ¿Te ha pasado de leer tu propio código días después y no entenderlo?

Algo que me queda muy marcado del libro, es el hincapié en la regla del boy scout:

“Siempre deja el lugar de acampada más limpio que como lo encontraste”

Secciones más interesantes

En cuanto a las secciones más importante que encontré, les recomiendo las siguientes:

Meaningful names: Recomendaciones y prácticas sobre cómo elegir nombres de manera correcta para nuestros componentes.
Functions: Sugerencias para poder organizar y construir las funciones con buenas prácticas de manera que podamos entender nuestro código en el futuro.
Comentarios: En nuestro código a veces subestimamos el poder de nuestros comentarios, lo ideal no es no escribir comentarios, sino hacerlo de la forma correcta. En este caso este capítulo nos da recomendaciones para escribirlos de forma correcta y cómo poder evitarlos.
Formatting: Como formatear nuestro código, y que tener en cuenta a la hora de como formatear nuestro código. Además se entra en detalles del formateo vertical y horizontal.
Error Handling: En cuanto al error handling se describen como manejarlo en nuestro flujo del código, y como no manejarlo.
Testing: El testing es algo fundamental en nuestro código, justamente nos ayuda a verificar que el código funcione de la manera que esperamos. Al igual que el código productivo, se necesita tener un código limpio y claro para poder entender los tests que escribimos.
Classes: En este capítulo se describen buenas prácticas para nuestras clases, y que tener en cuenta a la hora de crearlas en base a los principios SOLID.

Varias de estas secciones las he repasado a nivel universitario hace poco tiempo, insisto en que si las hubiera aprendido antes, esto me hubiera facilitado decisiones de diseño y desarrollo de código en mi carrera.

Conclusión

En mi opinion, recomiendo leer el libro, tal vez no completo ya que también hace mucho énfasis en código Java, y si no están trabajando con Java, tal vez no valga la pena entrar en detalles de Java del todo, pero de igual manera siempre son bienvenido los ejemplos.
Como último dejo abierto para que cada quien lea este post, pueda dejar su comentario para compartir su opinión o punto de vista.

Streams en Java

Gino Luraschi — Fri, 14 Apr 2023 02:25:06 +0000

Introducción

Para salir un poco de Go, hoy vamos a ver algo que no está incluido en la lib de Go, pero que es una buena herramienta a utilizar en lenguajes de programación cómo Java, Javascript, Kotlin entre otros, esta herramienta son los streams. Estos se utilizan para manipular colecciones de datos como los Arrays de la manera en que lo hace una arquitectura pipeline o ETL (extract, transform and load data).

De donde vienen?

Los streams provienen de la programación funcional, donde se los definen como:

Un paradigma de programación declarativa basado en el uso de verdaderas funciones matemáticas. En este estilo de programación las funciones son ciudadanas de primera clase, porque sus expresiones pueden ser asignadas a variables como se haría con cualquier otro valor; además de que pueden crearse funciones de orden superior (o sea tomar una o más funciones como entrada, o devolver una función como salida).

En resumen, la programación funcional se reduce al uso de funciones para manipular datos. A continuación veremos como hace Java para manipular distintos arreglos de datos.

Aclaración

Los streams de datos son inmutables por lo que generan nuevo streams y el array original no cambia en ningún momento.

Java

Si recorremos la API de Java para streams, nos encontramos con los métodos que podemos utilizar para la manipulación de arrays. Para eso vamos a ver los métodos más comunes.
Ante todo para esto vamos a crear un nuevo arreglo:

public static void main(String[] args) {
    // Generamos un array con los numeros de 1 al 1000 
    List<Integer> integers = new ArrayList<>();
    for (int x = 1; x < 1000; x++) integers.add(x);

    // El codigo irá aca.
}

A partir de este mapa generamos los siguientes ejemplos.

Filter

Cuando ejecutamos el filter en java, vemos que este recibe un tipo de clase Predicate<T> que dentro tiene un método test() que devuelve un booleano, este método test es necesario para evaluar cada ítem del arreglo. Para no alarmarse de crear una nueva clase que extienda de Predicate, podemos utilizar una función lambda(o sea una función de orden superior) dentro de la función filter:

// Acá podremos filtrar nuestros valores pares
// val -> val%2 == 0 es nuestra función lambda 
// que devuelve un booleano
integers.stream().filter(val -> val%2 == 0);

Esto retornará un stream con los ítems que cumplen la condición dentro de la función lambda.

Map

En cuanto a la función map() vemos que recibe una Function<T,R> que acepta un tipo de dato (el item del array) y devuelve un resultado, formando un nuevo array con los cambios aplicados para cada item del array inicial. Un ejemplo sería sumar un número más a cada uno de nuestros ítems:

// A cada item del mapa le sumaremos un numero
// x -> x+1 es nuestra función lambda que devuelve 
// un integer para generar nuestro array de integers
integers.stream().map(x -> x+1);

For Each

El forEach es una de las funciones más utilizadas en Java, y significa que por cada ítem aplicaremos una acción. La característica de esta función es que no nos genera un array nuevo, por lo que es una "función terminal". Esta función recibe un Consumer<T> que solo acepta los items, pero no devuelve nada. Un ejemplo es mostrar por pantalla los ítems:

integers.stream().forEach(item -> System.out.println(item));

¿Mejoran el código?

Si llevamos esto a un ejemplo en Java, podemos ver que la sintaxis cambia y se ve un decremento en la cantidad de líneas utilizadas para hacer lo mismo con los streams.

// For convencional
for (int i: integers){
    if (i%2 == 0) {
        int res = i+1;
        System.out.println(res);
    }
}
// Con el stream
integers.stream().
    filter(item -> item%2 == 0).
    map(item -> item +1).
    forEach(System.out::println);

La diferencia en este caso, no solo la encontramos en cuanto a las líneas de código, sino también en cuanto a la sintaxis que se puede leer de manera más corrida.

Son más eficaces?

Como mencionamos antes, el ForEach es una función terminal, pero no es la única, también encontramos el count()(para contar los elementos de un stream) o el collect(Collector)(para recolectar los elementos, por ejemplo en un nuevo array).
Estas funciones terminales, son las funciones que van a ejecutar cada una de nuestras iteraciones, a este mecanismo se lo denomina Lazy Evaluation. Veamos el ejemplo:

integers.stream().
    filter(item -> item%2 == 0).
    filter(item-> item%3==0).
    count();

En este caso, al ejecutar el count, se va a iterar cada ítem del array, filtrando los numeros pares, y luego filtrando los divisibles por 3, item por item. A esto, se le puede agregar la ejecución en paralelo, haciéndolo más eficaz y rápido:

integers.stream().parallel().
    filter(item -> item%2 == 0).
    filter(item-> item%3==0).
    count();

Conclusión

En este post, repasamos los conceptos sobre Streams apicables a Java, pero tambien se pueden hacer en Javascript. Los stream son una herramienta muy útil para escribir código performante, pero además, para poder hacerlo más fácilmente legibles.

Genericos en Go

Gino Luraschi — Tue, 14 Mar 2023 01:26:05 +0000

Introducción

Go ha ido evolucionando a través de los años, incluyendo herramientas interesantes en las últimas versiones. Una de estas herramientas son los genéricos, algo que ya existía en otros lenguajes de programación, pero no en Golang, y que es algo que podemos explotar para nuestro beneficio.

¿Qué son los genéricos?

Los genéricos permiten que nuestras funciones o estructuras de datos puedan ser creadas de diferentes tipos, que se definen en su forma genérica.

Ejemplo simple en java

En java, podemos tener como ejemplo los Arrays del paquete Utils:

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        Bag<Apple> applesBag = new Bag<>();
        applesBag.add(new Apple());
        applesBag.add(new Apple());
        applesBag.add(new Apple());
        System.out.println("Quantity of apples: " + applesBag.elementsQuantity());
        Bag<Orange> orangesBag = new Bag<>();
        orangesBag.add(new Orange());
        System.out.println("Quantity of oranges: " + applesBag.elementsQuantity());

    }

    static class Bag<K> {
        // Aca definimos una lista de K que estará en nuestra bolsa
        final List<K> listOfElements;

        public Bag(){
            listOfElements = new ArrayList<>();
        }

        public void add(K element) {
            listOfElements.add(element);
        }

        public int elementsQuantity(){
            return listOfElements.size();
        }
    }

    static class Apple {}
    static class Orange{}
}

En nuestro ejemplo en java creamos una bolsa personalizada, en donde podemos poner lo que queramos del tipo K, en este caso nuestro K puede ser tanto Apple como Orange.

¿Se podía hacer antes?

En golang solo los tipos nativos como map, slices y punteros entre otros podian ser genéricos, por lo que podiamos crear por ejemplo un map[string]int o un []int, la forma de hacerlo antes, era crear un tipo para cada estructura:

package main

import "fmt"

func main() {
    applesBag := new(ApplesBag)
    applesBag.add(Apple{})
    applesBag.add(Apple{})
    applesBag.add(Apple{})
    fmt.Printf("Quantity of apples: %d\n", applesBag.elementsQuantity())
    orangesBag := new(OrangesBag)
    orangesBag.add(Orange{})
    fmt.Printf("Quantity of oranges: %d\n", orangesBag.elementsQuantity())
}

type ApplesBag struct {
    apples []Apple
}
type Apple struct{}

func (bag *ApplesBag) add(apple Apple) {
    bag.apples = append(bag.apples, apple)
}

func (bag *ApplesBag) elementsQuantity() int {
    return len(bag.apples)
}

type OrangesBag struct {
    oranges []Orange
}
type Orange struct{}

func (bag *OrangesBag) add(apple Orange) {
    bag.oranges = append(bag.oranges, apple)
}

func (bag *OrangesBag) elementsQuantity() int {
    return len(bag.oranges)
}

De esta forma vemos como tenemos que crear un Bag para cada elemento, repitiendo código por cada tipo diferente que hagamos.

Como se hace ahora

Con la modificación que nos brinda la nueva SDK de Go, podemos hacer esto de una forma sencilla:

package main

import "fmt"

func main() {
    applesBag := Bag[Apple]{}
    applesBag.add(Apple{})
    applesBag.add(Apple{})
    applesBag.add(Apple{})
    fmt.Printf("Quantity of apples: %d\n", applesBag.elementsQuantity())
    orangesBag := Bag[Orange]{}
    orangesBag.add(Orange{})
    fmt.Printf("Quantity of oranges: %d\n", orangesBag.elementsQuantity())
}

// Tenemos una sola estructura Bag del tipo K
type Bag[K any] struct {
        // Que solo guarda objetos del tipo K
    objects []K
}

func (bag *Bag[K]) add(obj K) {
    bag.objects = append(bag.objects, obj)
}

func (bag *Bag[K]) elementsQuantity() int {
    return len(bag.objects)
}

type Orange struct{}
type Apple struct{}

De esta manera, el día de mañana nuestro código queda lo suficientemente desacoplado para crear objetos e instancias de Bag, y no tener que crear un objeto y un bag para cada tipo.

Conclusión

Si en algún momento nos vimos con la necesidad de tomar este approach de Golang y no contábamos con esta solución, ahora vemos que llegó y podemos aprovecharla. Seguramente con el transcurso del tiempo empiezan a llegar nuevas herramientas igual de interesantes y útiles, seguimos a la espera de facilidades como las de manejar errores y otras cosillas más.

Variables Globales en Golang, si o no?

Gino Luraschi — Fri, 24 Feb 2023 07:02:04 +0000

Introducción

Hace un tiempo me encontré en mi trabajo la utilización de variables globales, y aunque en este post vamos a hablar sobre la utilización en Golang, considero que esto se puede aplicar tranquilamente a cualquier lenguaje de programación.

Por que no?

La utilización de variables globales suele ser muy peligrosa y si no se utiliza con cuidado podemos llegar a tener ciertos efectos colaterales en nuestro código, algunas de las razones por las que debemos evitar esto es:

Difícil entender el programa: Al tener variables globales, podremos perder el hilo de nuestro programa, haciendo que este se vuelva inentendible. En particular por la siguiente razón.
Podemos cambiar la lógica en cualquier lugar de nuestro código, por cualquier razón: Al tener una variable global, debemos pensar en todos los usos y modificaciones que tendremos en el código productivo. Además, debemos considerar que un cambio que hagamos en una variable global se puede llegar a propagar por toda la aplicación, por lo que estamos acoplando piezas de nuestro código, lo cual causa el siguiente punto.
Reducción de modularidad y flexibilidad: Para este caso, tendremos en cuenta el ejemplo de que si varios módulos comparten una variable global, no podremos modificar la misma sin tener en cuenta los demás módulos. Lo cual hace perder flexibilidad si deseamos hacer nuestros módulos independientes.

Por que si?

Aunque se deben evitar estas variables, suelen ser útiles en ambientes en los que queremos declarar una constante que mejorará la lectura de nuestra aplicación, un ejemplo en la lib de go es time.go:

const (
    Layout      = "01/02 03:04:05PM '06 -0700" // The reference time, in numerical order.
    ANSIC       = "Mon Jan _2 15:04:05 2006"
    UnixDate    = "Mon Jan _2 15:04:05 MST 2006"
    RubyDate    = "Mon Jan 02 15:04:05 -0700 2006"
    RFC822      = "02 Jan 06 15:04 MST"
    RFC822Z     = "02 Jan 06 15:04 -0700" // RFC822 with numeric zone
    RFC850      = "Monday, 02-Jan-06 15:04:05 MST"
    RFC1123     = "Mon, 02 Jan 2006 15:04:05 MST"
    RFC1123Z    = "Mon, 02 Jan 2006 15:04:05 -0700" // RFC1123 with numeric zone
    RFC3339     = "2006-01-02T15:04:05Z07:00"
    RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"
    Kitchen     = "3:04PM"
    // Handy time stamps.
    Stamp      = "Jan _2 15:04:05"
    StampMilli = "Jan _2 15:04:05.000"
    StampMicro = "Jan _2 15:04:05.000000"
    StampNano  = "Jan _2 15:04:05.000000000"
)

En la lib de Go se exponen los distintos formatos de fecha preconfigurados, para permitirnos una mejor lectura del código y declaración de valores constante para toda la aplicación.

Forma de evitarlas: Pasando instancias desde un contenedor

Una forma de evitarla es tener una sola instancia e inyectarla al construir nuestros structs o clases, de esa forma tendremos controlado la utilización de las mismas, y nos dará la ventaja de poder mockearlas en caso de ser necesario, además en los tests, tendremos esa dependencia satisfecha.
Acá un ejemplo:

package db

import "github.com/go-pg/pg/v10"

var db *pg.DB // Nuestra variable global, la cual probablemente inicializamos en el mail.go

type Customer struct {
    ID       int
    Name     string
    LastName string
}

func SaveCustomer(cust Customer) error {
    // Al ejecutar nuestro test si no satisfacemos `db` esto va a fallar por un nil pointer
    _, err := db.Exec("insert into customers (id, name, lastname) values (%d, %s, %s)", cust.ID, cust.Name, cust.LastName)
    if err != nil {
        return err
    }
    return nil
}

// Un aproach es crear una estructura y poder inyectar la dependencia por constructor

type CustomerRepository struct {
    db *pg.DB
}

// NewCustomerRepository crea un repositorio y le inyecta
// la DB, por lo que en nuestro test
// si siempre usamos el constructor
// lograremos satisfacer esa dependecia
func NewCustomerRepository(db *pg.DB) CustomerRepository {
    return CustomerRepository{
        db: db,
    }
}

func (repo CustomerRepository) SaveCustomer(cust Customer) error {
    // En este caso, db de repo deberia estar satisfecha porque le inyectamos la DB en el constructor
    _, err := repo.db.Exec("insert into customers (id, name, lastname) values (%d, %s, %s)", cust.ID, cust.Name, cust.LastName)
    if err != nil {
        return err
    }
    return nil
}

Otra forma de evitarlas: Patron Singleton

Una forma de evitar tener variables globales, es la utilización del patrón singleton, esta nos permite tener una instancia de una sola variable, la cual se inicializa sólo la primera vez, por lo tanto nos permite tener siempre la sola instancia en nuestra aplicación.
Un ejemplo de esto, puede ser la inicialización de una conexión a una DB:

package db

import "github.com/go-pg/pg/v10"

var db *pg.DB

func GetDB() *pg.DB {
    if db == nil {
        db = pg.Connect(&pg.Options{
            Addr:     "localhost:5432",
            User:     "postgres",
            Password: "password",
            Database: "testdb",
        })
        // outside we need defer db.Close()
    }
    return db
}

Aca vemos como al hacer el GetDB si nuestra variable de instancia es nula, se inicializa la primera vez.

package main

import "postgres/db"

func main() {
    connection := db.GetDB() // Si es nula, se inicializa la DB
    _, err := connection.Exec("insert into customers(...) values (...)")
    if err != nil {
        panic(err.Error())
    }
    // ...
    connection := db.GetDB() // Es la misma conexión que arriba.
    _, err := connection.Exec("insert into products(...) values (...)")
    if err != nil {
        panic(err.Error())
    }
}

Note: Ambos script están en Gist de Github

Singleton, es un antipatrón?

En algún post futuro, prometo hablar por que se lo considera un antipatrón...

Conclusión

Como desarrolladores de software, estamos atentos a lo que vemos en nuestro día a día, acá revisamos porque las variables globales no nos ayudan mucho en el día a día, y aunque hay mejores formas de poder evitarlas, tenemos que considerar la mejor forma de hacerlo.
De paso, quiero recomendar que sigan (La regla del Boy Scout)[https://deviq.com/principles/boy-scout-rule] que en principio nos dice que debemos dejar el campo (código) en mejores condiciones del que lo recibimos. A veces cuesta, pero lo mejor es siempre poder hacer ajustes a medida que esté a nuestro alcance.

Rutinas en Golang

Gino Luraschi — Fri, 10 Feb 2023 06:13:20 +0000

Introducción

La principal ventaja de Golang, es la facilidad con la que se puede manejar multithread virtuales, a diferencia de otros lenguajes como Java, que incorpora la interfaz Thread o Javascript que lo hace a partir de las promesas.

Que es un thread?

En sistemas operativos, un hilo o hebra (del inglés thread), proceso ligero o subproceso es una secuencia de tareas encadenadas muy pequeña que puede ser ejecutada por un sistema operativo. (Wikipedia)

Estos procesos, suelen ser ejecutados por varios cores de un microprocesador, por lo que si se tiene un procesador multicore, estos procesos pueden ser ejecutados por más de un core. Los sistemas operativos proveen un scheduler que lanza y administra estos hilos de ejecución, y los gestiona para evitar condiciones de carrera.

Go Rutinas == Threads ligeros

Las rutinas de Golang suelen ser threads ligeros, ejecutados por núcleos virtuales generados por el runtime de Golang.

Paralelismo vs Concurrencia

Por que en Golang se usa la concurrencia y no el paralelismo? La principal diferencia es que 2 tareas son paralelas cuando se ejecutan al mismo tiempo, estas tareas son ejecutadas con 2 cores de un mismo procesador físico, por lo que es posible poder ejecutar 2 instrucciones al mismo tiempo.
Sin embargo, cuando una aplicación es concurrente en Go, el runtime de Go genera thread virtuales dentro de un mismo core, por lo que las instrucciones de los 2 thread virtuales se ejecutan en el mismo core, pero entrecruzadas, por lo que termina siendo un paso a paso.

Ejemplo:

Thread 1      | Thread 2
--------------|--------------
Instrucción 1 | 
Instrucción 2 | 
              | Instrucción 3
Instrucción 4 | 
              | Instrucción 5
...

Scheduler (o planificador del SO)

El scheduler es la parte del sistema operativo que se encarga de seleccionar a qué proceso se asigna el procesador y durante cuánto tiempo.
Algunas de sus tareas que podemos enumerar son:

Llevar el control de estado de cada proceso, decidiendo que proceso utilizará el procesador y cuanto tiempo lo hará. Esto evitará que haya ciertos procesos que utilicen todo el procesador.
Establecer el contexto de ejecución a la vez que se le asigna un proceso al procesador.
Por último, quitará el procesador del proceso, guardando el contexto para una ejecución posterior.

En pocas palabras, el scheduler del SO toma la carga del trabajo y la reparte sobre los recursos que posee.

Sistema Operativo vs Go Runtime

El planificador del sistema operativo, es capaz de ejecutar procesos en paralelo, es decir en distintos cores del procesador, mientras que el Go Runtime crea hilos virtuales para poder ejecutar los comandos de forma concurrente, uno detrás del otro, es decir cada hilo de ejecución ejecutara sus instrucciones en el mismo core del procesador que la otra.
En este caso, encontramos que el Runtime de Go utiliza el scheduler del SO.

Ejemplo

Cómo no todo es teoría, acá veamos un ejemplo práctico:

package main

import (
   "fmt"
   "time"
)

func say(word string) {
   for j := 0; j < 5; j++ {
      time.Sleep(time.Millisecond * 100)
      fmt.Println(word)
   }
}

func main() {
   go say("Hello")
   say("world")
}

En este caso vemos que nuestro hilo principal ejecutará el say("world") mientras que nuestra rutina ejecutará el say("hello"). Si ejecutamos estas instrucciones nos daremos cuenta del resultado:

Link al ejemplo

Conclusión

Por último, dejo algunas conclusiones:

Las Go rutinas son más ligeras que threads: Esto se debe a que las go rutinas ocupan un stack space de 2 KB, lo cual es extremadamente más compacto que los 2 MB que implican el tamaño fijo del stack space del OS Thread.
No abusar de las rutinas: Como todo en exceso es malo, llegar a tener muchas rutinas puede llegar a serlo. Es importante tener un control de las mismas, ya que en algún momento, si deseamos cancelar la ejecución de nuestro programa, podemos llegar a encontrarnos con varias rutinas ejecutándose y ocupando recursos que deseamos, estén libres.
Se pueden controlar con Go Tool Trace: De la mano con el punto anterior, podemos utilizar el Go Tool Trace para poder controlar nuestras rutinas. Pero esto lo hablaremos en algún post posterior.

Refactors y Migraciones: Pros... Y más pros!

Gino Luraschi — Thu, 24 Sep 2020 16:21:45 +0000

Hace un par de semanas en mi trabajo me toco hacer una migración de una tecnología a una versión un poco más reciente (la tecnología era un fwk de Go y una imagen de Docker interna de la empresa). Además me toco hacer refactor de varias partes del proyecto más que nada porque había flujos que no quedaban del todo claro. En base a eso, decidí hacer un pequeño listado de cosas a tener en cuenta para hacer y/o motivar a seguir mejorando y evolucionando los proyectos.

Migraciones

Arranquemos hablando de las migraciones. He trabajado en proyectos en los que, creo yo, no se atacaron a tiempo las migraciones, por lo que el proyecto crecía muy lentamente y al no tener tecnología nueva, este problema hacia muy difícil conseguir desarrolladores que quieran participar en el proyecto, entre otras cosas. Algunos de los pros de atacar migraciones son:

Facilidad para encontrar desarrolladores: Los programadores suelen buscar oportunidades para crecer, está posibilidad se da si se trabaja con tecnología nueva. Por lo que las migraciones nos dan esas ventajas de ser atractivas para nuevos candidatos.
Mejoras continuas: Es probable que si una tecnología saca una versión nueva, venga con arreglos de bugs, mejoras de seguridad o nuevas features que podrían llegar a ser útiles. Siempre es una ventaja este punto.
Mayormente tiene más soporte: Es posible, que la tecnología nueva tenga más soporte, por lo que hay blogs, posts o documentación en donde se sacan muchas dudas sobre bugs y funcionamiento de las features.

Nota: Las migraciones son super recomendadas, y se recomienda hacerlas seguido. Esto porque si empieza a haber muchos cambios en versiones, se vuelve engorroso y complicado empezar a hacer cambios. Se recomienda hacerlo seguido.

Refactors

Los refactos son mejoras en el código desarrollado, entiéndase que a veces hacemos cosas rápido, o con el tiempo nos damos cuenta que se pudo haber hecho mejor o simplemente tenemos más experiencia. Por ende, es muy importante el cambio en el código y esto mismo ayudará a ahorrar horas de desarrollo posteriormente. Los refactors deben hacerse SIEMPRE, siempre que sea posible, vale la pena dedicarle un par de horas a mejorar estos flujos que tal vez no los podemos entender, o simplemente podemos hacerlos de una mejor forma.

Conclusión

Siempre que sea posible, es necesario y muy positivo este tipo de cambios y mejoras. No escatimes horas que podrías invertirlas mejorando tu código o tu tecnología.

DEV Community: Gino Luraschi

React v19, unboxing! 📦

Introduccion

Actions

Nuevos hooks

useActionState

New hook: useOptimistic

React DOM

New hook: useFormStatus

Nuevas APIs

use

SSG y Server components

Algunas mejoras en React 19

<Context> como Provider

Como actualizar?

Fuente

Conclusion

Composición vs Herencia

Introducción

Conceptos de la herencia

Conceptos de la composición

Por qué composición sobre herencia?

Cuando aplicar herencia?

Que pasa si hacemos una mala herencia?

Conclusión

Multi-hilos en Java

Introducción

Hilos en Java

Herramientas en Java para la programación multihilo

Threads

Synchronized

Atomic

ReentrantLock

Conclusión

Novedades en Go 1.21 🚀

Introducción

Cambios en el lenguaje

Min y Max

Clear

Otras cositas del lenguaje

Novedades de la SDK

Paquete log/slog

Paquete slice

Paquete maps

Paquete cmp

Profile Guided Optimization

Mejoras en la performance

Conclusión

Escribir Golang como un Senior

Introducción

Los parámetros en Go son pasados por valor

Usar punteros (pero no abusar)

Operador * y operador &

Valor nil

Declarar interfaces donde las vayas a usar

Preferir tests en tablas, pero no hacer de más

Cuándo evitar la tabla de tests?

Fuentes para seguir mejorando

Conclusión

Herramientas para manejar Rutinas de Go

Introducción

Herramientas

Rutinas de Go

Canales

Wait Groups

Mutex

Conclusión

Clean Code, opinion personal 🤓

Introducción

Opinión personal

Secciones más interesantes

Conclusión

Streams en Java

Introducción

De donde vienen?

Aclaración

Java

Filter

Map

For Each

`<Context>` como Provider

Operador `*` y operador `&`

Valor `nil`