Facade o fachada es un patrón que simplifica la interacción con un sistema complejo.

Definición formal

Es un patrón de diseño estructural que proporciona una interfaz simplificada y unificada para un conjunto de interfaces de subsistemas complejos. Este patrón define una clase de alto nivel que hace que el subsistema sea más fácil de usar, ocultando su complejidad y ofreciendo una interfaz más conveniente para interactuar con él.

Ejemplo práctico

Piensa en un control remoto para la TV. La televisión tiene muchas funciones y configuraciones complejas dentro de ella, pero el control remoto te permite encenderla, cambiar de canal y ajustar el volumen de una manera muy simple. El control remoto es como la fachada, ya que te proporciona una forma sencilla de usar las funciones de la televisión sin tener que lidiar con su complejidad interna.

Mira esta imagen, se notará aún más el ejemplo, tienes el control remoto de un dispositivo de entretenimiento multimedia como lo es el Xiaomi MiBox

Aquí el control remoto (facade) tiene botones que te facilitan la vida, nota el botón "Netflix" que mediante un sólo clic (interfaz simplificada) te permite realizar de forma sencilla una operación compleja que consta de varias operaciones (subsistemas complejos).

Ejemplo del patrón Facade con C#

El escenario es el siguiente: Tienes un sistema complejo que maneja la compra de productos en una tienda en línea, y este sistema tiene múltiples subsistemas como Inventario, Pedido, y Envio.

Subsistemas complejos

// Subsistema 1: Inventario
public class Inventario
{
    public bool VerificarStock(int productId)
    {
        // Verificar stock del producto por su Id
        return true; // Aquí iría tu lógica, yo asumiré que hay stock.
    }
}

// Subsistema 2: Ordenes de venta
public class Pedido
{
    public void RealizarPedido(int productId)
    {
        // Colocar el pedido
        Console.WriteLine($"Pedido realizado para el producto {productId}");
    }
}

// Subsistema 3: Envíos
public class Envio
{
    public void EnviarPedido(int productId)
    {
        // Enviar el pedido
        Console.WriteLine($"Pedido enviado para el producto {productId}");
    }
}

Clase Facade

public class OnlineStoreFacade
{
    private Inventario inventario;
    private Pedido pedido;
    private Envio envio;

    public OnlineStoreFacade()
    {
        this.inventario = new Inventario();
        this.pedido = new Pedido();
        this.envio = new Envio();
    }

    public void ComprarProducto(int productId)
    {
    	//Aquí ocultas toda la complejidad de los subsistemas y expones ComprarProducto solamente
        if (inventario.VerificarStock(productId))
        {
            pedido.RealizarPedido(productId);
            envio.EnviarPedido(productId);
            Console.WriteLine("Compra completada con éxito");
        }
        else        
            Console.WriteLine("El producto no tiene stock");        
    }
}

Aplicación del patrón Facade

class Program
{
    static void Main(string[] args)
    {
        OnlineStoreFacade tienda = new OnlineStoreFacade();
        
        int productId = 1; // ID del producto a comprar
        tienda.ComprarProducto(productId); //Usas la interfaz simplificada

        Console.ReadLine();
    }
}

Explicación del código

Subsistemas: Tienes 3 subsistemas Inventario, Pedido, y Envio, cada uno con su propia lógica.

Clase Facade: La clase OnlineStoreFacade simplifica la interacción con estos subsistemas al proporcionar un único método ComprarProducto que se encarga de todo el proceso de compra.

Aplicación del patrón: En la clase Program, creas una instancia de OnlineStoreFacade y llamas al método ComprarProducto con el Id del producto. La fachada se encarga de verificar el stock, realizar el pedido y enviar el producto.

Este patrón de diseño, como has notado, es útil para ocultar la complejidad de un sistema y proporcionar una interfaz más amigable y fácil de usar.

El mismo ejemplo sin Facade

Los subsistemas complejos quedarían como están.

No existiría la clase OnlineStoreFacade.

Lo que cambiaría sería la clase Program.

class Program
{
    static void Main(string[] args)
    {
        Inventario inventario = new Inventario();
        Pedido pedido = new Pedido();
        Envio envio = new Envio();

        int productId = 2; // Id del producto a comprar

        // La lógica de compra queda expuesta
        if (inventario.VerificarStock(productId))
        {
            pedido.RealizarPedido(productId);
            envio.EnviarPedido(productId);
            Console.WriteLine("Compra completada con éxito");
        }
        else        
            Console.WriteLine("El producto no tiene stock");  

        Console.ReadLine();
    }
}

Espero que este ejemplo te haya ayudado a entender este patrón y recuerda que practicando es como te conviertes en un maestro. Puedes seguirme también en mi blog bravedeveloper.com donde hago ejemplos como éste y más!

Éxitos mis cracks! 🐿️🥳

Créditos de imagen de portada: Foto de Hugo Sousa en Unsplash

Las siglas que dan nombre a este estilo arquitectónico vienen de Representational State Transfer, o en español, Transferencia de estado representacional y fue propuesto en un trabajo de tesis, me refiero a la tesis doctoral de Información y ciencias de la computación (PhD) desarrollada en el año 2000 por Roy Thomas Fielding titulada "Architectural Styles and the Design of Network-based Software Architectures" en la Universidad de California, Irvine. Dicha tesis está disponible aquí por si quieras verla 😉.

Definición

REST es un estilo de arquitectura de software para realizar una comunicación cliente-servidor. Se apoya en el protocolo HTTP para la comunicación al servidor y los mensajes que se envían y reciben pueden estar en el formato de intercambio de datos JSON o también, aunque en menor medida, XML.

Principios de REST

Para que la comunicación hacia un API utilizando el estilo REST funcione, debe seguir una serie de principios, los cuales son:

• Interfaz uniforme o Uniform interface: Este principio postula que REST está basado en recursos y estos deben ser sustantivos en plural por ejemplo: productos, estudiantes, peliculas.
• Sin estado o Stateless: REST no tiene estados, esto quiere decir que una llamada al API es independiente de otra y no debe depender de ella, sin embargo sí se puede usar caché para reducir el tiempo de espera en consultas GET.
• Cliente-Servidor o Client-Server: El servidor hace el procesamiento del API y expone los recursos a uno o muchos clientes, que pueden ser una aplicación de escritorio, una página web entre otros. El cliente debe ser independiente del servidor y toda comunicación a él se debe dar mediante el API.
• Cacheable o Cacheability: Siempre que sea posible los recursos deben de ser "cacheables" ya sea en el servidor o en el lado del cliente. La respuesta del serivdor debe contener esta información sobre cuando es posible o no el uso del caché. Esto se hace para incrementar el rendimiento en el cliente y la escalabilidad en el servidor.
• Sistema de capas o Layered system: El servicio web debe tener una arquitectura de capas, donde su evolución sea completamente transparente para el cliente

Características de un API REST

Además de los principios arriba señalados, existen otros puntos a considerar los cuales vienen a ser características para todo API que implemente el estilo REST. Entre estos podemos considerar los siguientes:

• Operaciones específicas: Cada acción u operacion sobre un recurso está bien definido y tiene un claro propósito, no existen los endpoints "multifuncionales". Por ejemplo si un endpoint por ejemplo es para insertar nuevos productos, no debería también insertar clientes.
• Sintaxis estandarizada: Cada recurso es accesible únicamente desde su URI.
• HATEOAS: Proviene del acrónimo de Hypermedia As The Engine Of Application State (Hipermedia como motor del estado de la aplicación). Es un principio o restricción de diseño que tiene REST el cual establece por ejemplo la información que nos da el web api debe incluir links, por poner un ejemplo.
• Código bajo demanda o Code on demand : Esta es una característica opcional. El servicio web comúnmente utiliza y envía recursos estáticos, sin embargo también tiene la opción de enviar código fuente el cual se va a ejecutar en el cliente, típicamente Javascript.

Más allá de REST...

Y por si te lo hayas preguntado, ¿Existen acaso otras opciones aparte de REST? La respuesta es por supuesto, aquí te lo muestro mejor con una imagen:

Finalmente, y no menos importante, cabe aclarar un tema que es recurrente y sólo para que no te confundas como muchos. Escuchaste seguramente el término RESTful, ¿qué es?

Simple. Así como REST es el estilo de Arquitectura, RESTful es la implementación de dicha arquitectura.

Entonces por simple sentido común un API RESTful es un API que fue diseñada usando la arquitectura REST. Así de sencillo. En esta entrada que redacté también, puedes encontrar más información, espero te sirva!

Y ya sabes, si te ha gustado esta entrada considera compartirla con tu equipo de tecnología y tus amistades 🙌.

Créditos de imagen de portada: Foto de Meggyn Pomerleau en Unsplash.

Uno de los errores más comunes al ejecutar contenedores, es no establecer quotas o límites de uso de recursos a los contenedores, ocasionando que eventualmente tomen más recursos de los disponibles o desestabilicen el servidor.

Establecer límites de uso de disco duro

El comando docker run con la opción --storage-opt para establecer diferentes opciones de almacenamiento para el contenedor. Por ejemplo, para establecer un límite de almacenamiento de 10 GB para un contenedor, puede usar el siguiente comando:

docker run --storage-opt size=10GB <nombre-de-la-imagen>

También puede usar la opción --storage-opt para establecer límites en otros recursos de almacenamiento, como el número de archivos que se pueden almacenar en el contenedor o el tamaño máximo de un archivo individual. Para obtener más información sobre cómo establecer opciones de almacenamiento para un contenedor en Docker, consulte la documentación en el sitio web de Docker.

Establecer límites de uso de CPU y Memoria

Para establecer límites en el uso de CPU y memoria de un contenedor en Docker, puede usar el comando docker run con las opciones --cpus y --memory, respectivamente. Por ejemplo, para establecer un límite de uso de CPU de 0,5 y un límite de memoria de 512 MB para un contenedor, puede usar el siguiente comando:

docker run --cpus 0.5 --memory 512MB <nombre-de-la-imagen>

También puede usar las opciones --cpu-shares y --memory-swap para establecer límites adicionales en el uso de CPU y memoria. Para obtener más información sobre cómo establecer límites en el uso de recursos de un contenedor en Docker, consulte la documentación en el sitio web de Docker.

A continuación se presentan algunos ejemplos adicionales de cómo establecer límites en el uso de recursos de un contenedor en Docker:

• Para establecer un límite de uso de CPU de 1 y un límite de memoria de 2 GB para un contenedor, puede usar el siguiente comando:

docker run --cpus 1 --memory 2GB <nombre-de-la-imagen>

• Para establecer un límite de uso de CPU de 0,25, un límite de memoria de 256 MB y un límite de almacenamiento de 5 GB para un contenedor, puede usar el siguiente comando:

docker run --cpus 0.25 --memory 256MB --storage-opt size=5GB <nombre-de-la-imagen>

• Para establecer un límite de uso de CPU de 0,5, un límite de memoria de 1 GB, un límite de almacenamiento de 10 GB y un límite en el número de archivos almacenados en el contenedor (500 archivos), puede usar el siguiente comando:

docker run --cpus 0.5 --memory 1GB --storage-opt size=10GB --storage-opt max-files=500 <nombre-de-la-imagen>	

¿Qué puede pasar si no fijo límites?

Si excede los límites establecidos para un contenedor en Docker, puede provocar que el contenedor se detenga o se bloquee. Esto puede ocurrir si el contenedor intenta utilizar más recursos de los permitidos, como CPU, memoria o almacenamiento. Cuando esto sucede, el contenedor deja de responder y ya no se puede acceder a su contenido o funcionalidades.

Para evitar que esto suceda, es importante establecer límites adecuados en el uso de recursos de un contenedor en Docker. De esta manera, se asegura de que el contenedor no consume más recursos de los necesarios, lo que puede mejorar su rendimiento y estabilidad. También es recomendable supervisar el uso de recursos del contenedor en tiempo real, para poder detectar y solucionar cualquier problema que pueda surgir antes de que afecte su funcionamiento.

¿Cómo puedo monitorear el uso de recursos?

Para monitorear el uso de recursos de un contenedor en Docker, puede usar el comando docker stats. Este comando muestra información en tiempo real sobre el uso de CPU, memoria, almacenamiento y otros recursos de uno o varios contenedores en ejecución. Para usar el comando docker stats, sólo tiene que ejecutarlo en una terminal y proporcionar el nombre o el identificador de los contenedores que desea monitorear.

Por ejemplo, para monitorear el uso de recursos de un contenedor llamado my-container, puede usar el siguiente comando:

docker stats my-container

Esto mostrará información en tiempo real sobre el uso de CPU, memoria, almacenamiento y otros recursos del contenedor my-container. Si desea monitorear el uso de recursos de varios contenedores, simplemente proporcione los nombres o identificadores de todos los contenedores que desea monitorear. Por ejemplo:

docker stats my-container1 my-container2 my-container3

También puede usar la opción --no-stream para mostrar la información del uso de recursos de manera estática, en lugar de actualizarse en tiempo real.

Cuando se ejecuta este comando, se muestra una tabla con información sobre el uso de CPU, memoria, almacenamiento y otros recursos de cada contenedor. La tabla incluye la siguiente información:

• El nombre o el identificador del contenedor.
• El uso de CPU en porcentaje.
• El uso de memoria en bytes.
• El uso de almacenamiento en bytes.
• El número de archivos en el contenedor.
• El tamaño total de archivos en el contenedor.

Por ejemplo, si se ejecuta el comando docker stats para supervisar el uso de recursos de un contenedor llamado my-container, se podría ver algo como lo siguiente:

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
69e3f12cddcd        my-container        0.12%               1.536MiB / 1.952GiB   0.08%               1.87kB / 0B         0B / 0B             1

La tabla muestra información sobre el uso de CPU, memoria, almacenamiento y otros recursos del contenedor my-container. Si se supervisan varios contenedores, se mostrará una fila por cada contenedor.

Como dato adicional, también es posible sensar el uso de recursos de Docker en Prometheus y graficarlos en Grafana, pero esa es otra historia.

Si quieres aprender más sobre Docker, Docker Compose, Quotas y más cosas, te invito a nuestro curso de Docker para desarrolladores, donde aprender a utilizar Docker como un pro montando un entorno de desarrollo completo conformado por varios Microservicios mediante Docker Compose.

La función map de Java permite aplicar una función dada a cada elemento de una colección y devolver una nueva colección con los resultados. Esta función es muy útil para realizar operaciones como la transformación o filtrado de datos en una colección.

Por ejemplo, supongamos que queremos convertir una lista de cadenas en mayúsculas a minúsculas. Podríamos hacerlo de la siguiente manera:

List<String> words = Arrays.asList("the", "quick", "brown", "fox");

List<String> lowercaseWords = new ArrayList<>();
for (String word : words) {
  lowercaseWords.add(word.toLowerCase());
}

Esta implementación funciona, pero puede resultar verbosa y poco elegante. Con la función map, podemos hacer lo mismo de manera más concisa y clara:

List<String> words = Arrays.asList("the", "quick", "brown", "fox");

List<String> lowercaseWords = words.stream()
  .map(word -> word.toLowerCase())
  .collect(Collectors.toList());

En este ejemplo, primero obtenemos un Stream de la lista words, luego usamos la función map para aplicar el método toLowerCase a cada elemento del Stream, y finalmente usamos el método collect para recolectar los resultados en una nueva lista.

La función map también se puede utilizar con expresiones lambda, lo que permite aún más concisión en el código:

List<String> words = Arrays.asList("the", "quick", "brown", "fox");

List<String> lowercaseWords = words.stream()
  .map(String::toLowerCase)
  .collect(Collectors.toList());

En este caso, estamos usando una referencia de método en lugar de una expresión lambda para aplicar el método toLowerCase. Esto es equivalente a la implementación anterior, pero es aún más conciso y legible.

En resumen, la función map es una herramienta muy útil en Java para aplicar una función dada a cada elemento de una colección y devolver una nueva colección con los resultados. Es una forma concisa y legible de realizar operaciones de transformación o filtrado en colecciones de datos.

Si quieres aprender más sobre Java, Colecciones y Lamdas, te invitamos a nuestro curso de Java Core y Mastering Java Collection y nuestro curso Java Lamdas.

Para crear un servicio que te permita cargar un archivo usando Spring Boot, primero debes crear una interfaz de servicio que declare el método que se encargará de cargar el archivo. Por ejemplo:

public interface FileUploadService {
  void uploadFile(InputStream inputStream);
}

Luego puedes implementar esta interfaz en tu clase de servicio y proporcionar la lógica para cargar el archivo en el método uploadFile(). Por ejemplo:

Guardar el archivo en un disco local

@Service
public class FileUploadServiceImpl implements FileUploadService {

  private final String UPLOAD_DIR = "/path/to/upload/directory";

  @Override
  public void uploadFile(InputStream inputStream) {
    try {
      byte[] bytes = IOUtils.toByteArray(inputStream);
      Path path = Paths.get(UPLOAD_DIR + "/" + UUID.randomUUID().toString());
      Files.write(path, bytes);
    } catch (IOException e) {
      // manejar excepción
    }
  }

}

Guardar el archivo en AWS

Otra alternativa sería tomar ese mismo archivo y guardarlo directamente en un storage de AWS:

@Service
public class FileUploadServiceImpl implements FileUploadService {

  @Value("${aws.accessKey}")
  private String accessKey;

  @Value("${aws.secretKey}")
  private String secretKey;

  @Value("${aws.s3.bucketName}")
  private String bucketName;

  @Override
  public void uploadFile(InputStream inputStream) {
    try {
      BasicAWSCredentials awsCredentials = new BasicAWSCredentials(accessKey, secretKey);
      AmazonS3 s3Client = AmazonS3ClientBuilder.standard()
          .withCredentials(new AWSStaticCredentialsProvider(awsCredentials))
          .build();

      ObjectMetadata metadata = new ObjectMetadata();
      metadata.setContentType("application/octet-stream");
      metadata.setContentLength(inputStream.available());

      PutObjectRequest request = new PutObjectRequest(bucketName, UUID.randomUUID().toString(), inputStream, metadata);
      s3Client.putObject(request);
    } catch (IOException e) {
      // manejar excepción
    }
  }

}

En este ejemplo, se crea un cliente AmazonS3 utilizando las credenciales de AWS proporcionadas en el archivo de configuración de la aplicación. Luego se crea un objeto ObjectMetadata y se establece el tipo de contenido y el tamaño del archivo. Finalmente, se crea un objeto PutObjectRequest que contiene la información del archivo, incluyendo el nombre del bucket de S3 en el que se desea guardar el archivo, el InputStream del archivo y el objeto ObjectMetadata creado anteriormente. Luego se llama al método putObject() del cliente AmazonS3 para guardar el archivo en el bucket de S3.

Implementar el Controller

Luego puedes inyectar la implementación del servicio en cualquier componente de tu aplicación que necesite cargar un archivo, como un controlador de Spring MVC, y llamar al método uploadFile() proporcionando el InputStream del archivo que se desea cargar. Por ejemplo:

@Controller
public class MyController {

  @Autowired
  private FileUploadService fileUploadService;

  ...

  @PostMapping("/upload")
  public void handleFileUpload(@RequestParam("file") MultipartFile file) {
    fileUploadService.uploadFile(file.getInputStream());
  }

}

En este ejemplo, se asume que el controlador está manejando una solicitud de carga de archivos enviada mediante un formulario HTML utilizando el enctype multipart/form-data. El archivo se recibe como un parámetro de la solicitud y se proporciona al método uploadFile() del servicio mediante el método getInputStream() del objeto MultipartFile.

Probar el servicio mediante CURL

Para cargar un archivo en un servicio de Spring Boot mediante una solicitud curl, debes enviar una solicitud POST al endpoint del servicio que maneja la carga de archivos y proporcionar el archivo en el cuerpo de la solicitud utilizando el enctype multipart/form-data. Por ejemplo, si el endpoint del servicio es /upload y el archivo se llama file.txt, puedes usar el siguiente comando curl:

curl -X POST -F "file=@file.txt" http://localhost:8080/upload

En este caso, se está enviando una solicitud POST al endpoint /upload en el host localhost en el puerto 8080. El archivo se proporciona en el cuerpo de la solicitud utilizando el enctype multipart/form-data y se especifica mediante el parámetro file y el valor @file.txt, lo que indica que el archivo se llama file.txt y se encuentra en el directorio actual.

Tenga en cuenta que este comando curl es solo un ejemplo y debería ser adaptado según sea necesario para cumplir con las necesidades específicas de la aplicación. Por ejemplo, podrías necesitar proporcionar información de autenticación si el servicio está protegido por autenticación.

Si quieres aprender más sobre como crear API REST de forma profesional, te inviamos a nuestro curso Mastering API REST con Spring Boot, donde aprenderás todo lo necesario para crear un API desde cero, con seguridad, validaciones, DTO y las mejores prácticas de la industria.

A diferencia de lo que uno puedo llegar a pensar, Spring boot proporciona diferentes formas de validar los request, que van desde mecanismos simples, hasta complejas estructuras de clases de validación. En este artículo trataremos de explicar los más utilizados y como los puedes implementar en tus proyectos.

Validación de párametros mediante Bean Validator

La primera forma es usando anotaciones de validación en los parámetros del método del controlador. Por ejemplo, si quieres validar que un parámetro de tipo String no sea nulo ni vacío, puedes usar la anotación @NotNull y @Size:

@PostMapping("/api/example")
public ResponseEntity<String> example(@NotNull @Size(min = 1) String param) {
    // Tu código aquí
}

Si hay varios parámetros que necesitan validación, puedes usar la anotación @Valid en el parámetro que contiene las anotaciones de validación. Por ejemplo:

public class ExampleForm {
    @NotNull
    @Size(min = 1)
    private String param1;

    @NotNull
    @Min(1)
    private Integer param2;

    // getters y setters
}

@PostMapping("/api/example")
public ResponseEntity<String> example(@Valid @RequestBody ExampleForm form) {
    // Tu código aquí
}

La anotación @Valid ayuda a que Spring Boot valide el request antes de ejecutar el método, lo cual es de grán ayuda a evitar que incluse se ejecute el método, sin embargo, abrá ocasiones donde será mejor controlar nosotros mismo el momento exacto de la validación, es por ello que podemos implementar el método de esta otra forma:

@PostMapping("/api/example")
public ResponseEntity<String> example(@Valid @RequestBody ExampleForm form) {
    ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
	Validator validator = factory.getValidator();


	Set<ConstraintViolation<ExampleForm>> violations = validator.validate(form);
	if (!violations.isEmpty()) {
    	// Se encontraron violaciones, procesa las violaciones aquí
	}
}

Bean Validation proporciona un conjunto de anotaciones que puedes usar para validar los atributos de una clase. Algunas de las anotaciones más comunes son:

• @NotNull: indica que el atributo no puede ser nulo.
• @Size: indica el tamaño mínimo y/o máximo permitido para un atributo de tipo String o Collection.
• @Min y @Max: indican el valor mínimo y/o máximo permitido para un atributo numérico.
• @Email: indica que el atributo debe ser una dirección de correo electrónico válida.
• @Past y @Future: indican que un atributo de tipo Date o Calendar debe ser una fecha en el pasado o en el futuro, respectivamente.
• @Pattern: indica un patrón que debe cumplir un atributo de tipo String.
• @DecimalMin y @DecimalMax: indican el valor mínimo y/o máximo permitido para un atributo de tipo BigDecimal.
• @NotEmpty: indica que un atributo de tipo String, Collection o Map no puede ser vacío.

Por ejemplo, si tienes una clase que representa un formulario de búsqueda de libros, puedes usar las anotaciones de validación para validar que el título del libro no sea nulo ni vacío, que el precio mínimo y máximo sean números válidos y que la fecha de publicación sea una fecha en el pasado:

public class BookSearchForm {
    @NotNull
    @NotEmpty
    private String title;

    @DecimalMin("0.00")
    @DecimalMax("9999.99")
    private BigDecimal priceMin;

    @DecimalMin("0.00")
    @DecimalMax("9999.99")
    private BigDecimal priceMax;

    @Past
    private Date publicationDate;

    // getters y setters
}

Toma en cuenta que el API de Bean Validator no es parte de Spring Boot, por lo que será necesario agregar la librerías a tu archivo POM.

<dependency>
    <groupId>javax.validation</groupId>
    <artifactId>validation-api</artifactId>
    <version>2.0.1.Final</version>
</dependency>

Clases de tipo validador

Una forma es creando una clase de tipo Validator y registrándola como un bean en la aplicación. La clase Validator tiene un método "supports" que indica qué tipo de objetos puede validar y un método "validate" que recibe el objeto a validar y un objeto de tipo Errors, en el que se pueden agregar los errores de validación encontrados. Por ejemplo:

public class ExampleFormValidator implements Validator {

    @Override
    public boolean supports(Class<?> clazz) {
        return ExampleForm.class.equals(clazz);
    }

    @Override
    public void validate(Object target, Errors errors) {
        ExampleForm form = (ExampleForm) target;
        if (form.getParam1() == null || form.getParam1().trim().isEmpty()) {
            errors.rejectValue("param1", "field.required", "El campo param1 es requerido");
        }
        if (form.getParam2() == null || form.getParam2() < 1) {
            errors.rejectValue("param2", "field.invalid", "El campo param2 es inválido");
        }
    }
}

Para usar el validador, debes registrarlo como un bean en la aplicación y usar la anotación @InitBinder en el método del controlador para asociar el validador a los parámetros que deben ser validados. Por ejemplo:

@RestController
public class ExampleController {

    private final ExampleFormValidator validator;

    public ExampleController(ExampleFormValidator validator) {
        this.validator = validator;
    }

    @InitBinder("form")
    public void initBinder(WebDataBinder binder) {
        binder.setValidator(validator);
    }

    @PostMapping("/api/example")
    public ResponseEntity<String> example(@Valid @ModelAttribute("form") ExampleForm form) {
        // Tu código aquí
    }
}

Controlar los errores de validación

Cuando se produce un error de validación, Spring Boot lanzará una excepción de tipo MethodArgumentNotValidException. Puedes manejar esta excepción de varias formas, como por ejemplo creando una clase de tipo @ControllerAdvice que maneje la excepción y devuelva una respuesta adecuada al usuario. Por ejemplo:

@ControllerAdvice
public class ValidationErrorHandler {

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<String> handleValidationErrors(MethodArgumentNotValidException ex) {
        List<FieldError> fieldErrors = ex.getBindingResult().getFieldErrors();
        // Crea una respuesta adecuada basada en los errores de validación
        return ResponseEntity.badRequest().body(/* Tu respuesta aquí */);
    }
}

Si quieres aprender más sobre el desarrollo de API con Spring Boot, no te puede perder nuestro curso Mastering API REST con Spring Boot, donde aprenderás a crear un API REST desde cero con seguridad (JWT), validadores, DTO y las mejores prácticas de la industria.

Si desea agregar filtros dinámicos a un servicio de Spring Boot, puede hacerlo utilizando la interfaz Specification de JPA. La interfaz Specification le permite construir consultas dinámicas en función de los parámetros proporcionados.

Por ejemplo, supongamos que tiene una entidad User con los atributos firstName, lastName y email. Si desea crear un servicio que pueda buscar usuarios por cualquiera de estos tres campos, utilizando filtros dinámicos, podría hacer algo como esto:

public class UserSpecification implements Specification<User> {

    private String firstName;
    private String lastName;
    private String email;

    public UserSpecification(String firstName, String lastName, String email) {
        this.firstName = firstName;
        this.lastName = lastName;
        this.email = email;
    }

    @Override
    public Predicate toPredicate(Root<User> root, CriteriaQuery<?> query, CriteriaBuilder cb) {
        List<Predicate> predicates = new ArrayList<>();

        if (firstName != null) {
            predicates.add(cb.equal(root.get("firstName"), firstName));
        }

        if (lastName != null) {
            predicates.add(cb.equal(root.get("lastName"), lastName));
        }

        if (email != null) {
            predicates.add(cb.equal(root.get("email"), email));
        }

        return cb.and(predicates.toArray(new Predicate[predicates.size()]));
    }
}

Luego, en su servicio, puede utilizar la clase UserSpecification para construir una consulta dinámica utilizando los parámetros proporcionados. Por ejemplo:

public List<User> findUsers(String firstName, String lastName, String email) {
    UserSpecification spec = new UserSpecification(firstName, lastName, email);
    return userRepository.findAll(spec);
}

De esta manera, puede proporcionar cualquiera de los tres parámetros de búsqueda al servicio, y la consulta se construirá dinámicamente en función de los parámetros proporcionados.

Si desea obtener más información sobre cómo utilizar la interfaz Specification en Spring, puede consultar la documentación oficial de Spring.

Si quieres conocer más sobre Spring boot y JPA, te invitamos a nuestros cursos profesionales de Mastering API REST con Spring boot y Mastering JPA con Hibernate, para aprender como un pro a dominar estas tecnnologías.

El Time Zone se refiere al zona horaria que se utiliza para manejar las fechas y horas en una aplicación basada en Spring Boot. El Time Zone se utiliza para asegurarse de que las fechas y horas sean consistentes en todas las partes de la aplicación y que se reflejen correctamente para los usuarios en diferentes zonas horarias.

Por ejemplo, si un usuario en Nueva York está utilizando una aplicación basada en Spring Boot que se ejecuta en San Francisco, es posible que las fechas y horas que se muestren en la aplicación se refieran a la hora local de San Francisco en lugar de a la hora local de Nueva York. Esto puede ser confuso para el usuario y puede causar problemas en la aplicación si no se maneja correctamente.

Para solucionar este problema, Spring Boot permite especificar la zona horaria en la que se ejecuta la aplicación. Esto se hace mediante la configuración del Time Zone en el archivo de configuración de la aplicación. Una vez que se ha establecido la zona horaria, Spring Boot se encarga de asegurarse de que todas las fechas y horas sean interpretadas correctamente en relación a esa zona horaria, lo que permite que la aplicación funcione correctamente para usuarios en diferentes zonas horarias.

Aquí hay algunos ejemplos de cómo se puede utilizar la configuración del Time Zone en Spring Boot:

• Si su aplicación se ejecuta en Nueva York y desea que las fechas y horas se interpreten en relación a la zona horaria de Nueva York, puede establecer el Time Zone en "America/New_York" en el archivo de configuración de la aplicación.
• Si su aplicación se ejecuta en Londres y desea que las fechas y horas se interpreten en relación a la zona horaria de Londres, puede establecer el Time Zone en "Europe/London" en el archivo de configuración de la aplicación.
• Si su aplicación se ejecuta en San Francisco y desea que las fechas y horas se interpreten en relación a la zona horaria de San Francisco, puede establecer el Time Zone en "America/Los_Angeles" en el archivo de configuración de la aplicación.

En cada uno de estos casos, Spring Boot se encargará de asegurarse de que las fechas y horas se interpreten correctamente en relación a la zona horaria especificada en la configuración. Esto permitirá que la aplicación funcione correctamente para usuarios en diferentes zonas horarias.

Como establecer el Time Zone

Primero, debes configurar el TimeZone en tu archivo de propiedades de Spring Boot. Puedes hacerlo agregando la siguiente línea al archivo application.properties:

spring.jackson.time-zone=America/Mexico_City

En lugar de especificar el TimeZone en el archivo de propiedades, también puedes configurarlo en tu código Java. Para hacerlo, puedes agregar la siguiente línea en tu archivo de configuración de Spring Boot:

@Bean
public Jackson2ObjectMapperBuilder jacksonBuilder() {
    Jackson2ObjectMapperBuilder b = new Jackson2ObjectMapperBuilder();
    b.timeZone(TimeZone.getTimeZone("America/Mexico_City"));
    return b;
}

Si deseas establecer el TimeZone en una aplicación Spring Boot que utiliza JPA (Java Persistence API), puedes hacerlo agregando la siguiente línea en tu archivo de configuración de Spring Boot:

@Bean
public JpaProperties jpaProperties() {
    JpaProperties jpaProperties = new JpaProperties();
    jpaProperties.setDatabaseZone(TimeZone.getTimeZone("America/Mexico_City"));
    return jpaProperties;
}

O en el caso de UTC

spring.jackson.time-zone=UTC

@Bean
public Jackson2ObjectMapperBuilder jacksonBuilder() {
    Jackson2ObjectMapperBuilder b = new Jackson2ObjectMapperBuilder();
    b.timeZone(TimeZone.getTimeZone("UTC"));
    return b;
}

@Bean
public JpaProperties jpaProperties() {
    JpaProperties jpaProperties = new JpaProperties();
    jpaProperties.setDatabaseZone(TimeZone.getTimeZone("UTC"));
    return jpaProperties;
}

Establecer el Time Zone desde la línea de comandos

Para establecer el TimeZone desde la línea de comandos en una aplicación Spring Boot, puedes usar el parámetro spring.jackson.time-zone en la línea de comandos al iniciar tu aplicación. Por ejemplo, si quieres establecer el TimeZone a UTC, puedes usar el siguiente comando:

java -jar my-app.jar --spring.jackson.time-zone=UTC

Si quieres establecer el TimeZone a America/Mexico_City, puedes usar el siguiente comando:

java -jar my-app.jar --spring.jackson.time-zone=America/Mexico_City

También puedes usar el parámetro user.timezone para establecer el TimeZone en la JVM. Por ejemplo, si quieres establecer el TimeZone a UTC, puedes usar el siguiente comando:

java -Duser.timezone=UTC -jar my-app.jar

Si quieres establecer el TimeZone a America/Mexico_City, puedes usar el siguiente comando:

java -Duser.timezone=America/Mexico_City -jar my-app.jar

En resumen, el Time Zone en Spring Boot es una configuración importante que se utiliza para manejar correctamente las fechas y horas en una aplicación basada en Spring Boot y asegurarse de que se interpreten correctamente en relación a la zona horaria en la que se encuentran los usuarios.

Para detener un contenedor de Docker, puedes usar el comando docker stop seguido del nombre o ID del contenedor que deseas detener. Por ejemplo, si deseas detener un contenedor llamado "mi_contenedor", puedes usar el siguiente comando:

docker stop mi_contenedor

Si no conoces el nombre exacto del contenedor que deseas detener, puedes usar el comando docker ps para ver una lista de todos los contenedores en ejecución en tu máquina. Esto te mostrará el ID y el nombre de cada contenedor, lo que te permitirá detener el contenedor que desees de manera precisa.

Por ejemplo, si ejecutas el comando docker ps, puedes ver una salida similar a esta:

CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES 
2f72b9733ccd  nginx  "nginx -g 'daemon of…"  3 minutes ago  Up 3 minutes  80/tcp  nginx_1

En este ejemplo, el contenedor tiene un ID de 2f72b9733ccd y un nombre de nginx_1. Para detener este contenedor, puedes usar el siguiente comando:

docker stop 2f72b9733ccd

O bien, puedes usar el nombre del contenedor en lugar del ID:

docker stop nginx_1

Ambos comandos detendrán el contenedor y lo sacarán del estado de ejecución. Si deseas volver a iniciar el contenedor, puedes usar el comando docker start seguido del nombre o ID del contenedor que deseas iniciar.

Puedes aprender más sobre Docker en muestro curso para Docker para desarrolladores, donde aprenderás desde instalar, ejecutar contenedores, crear tus própias imáges, subir tus imágenes a Docker Hub y utilizar Docker Compose para levantar un ambiente de Microservicios.

Una de las cuestionas más relevantes al momento de diseñar muestro modelo de bases de datos es definir la llave primaria, sin embargo, esta acción casi siempre ovedece más a una necesidad de integridad que a un identificador real para el negocio.

Solo por poner algunos ejemplos, si creamos un tabla para libros, seguramente pondremos una columna autoincrementable llamada id o libro_id, cuando en realidad todos sabemos que el identificador del mundo real de un libro es el ISBN, del mismo modo, si creamos una tabla para guardar a las personas, vamos a crear una tabla similar con el id o persona_id, cuando en realidad el identificado sea el número de identificación de cada país, llamese CURP o DNI según cada país.

Si bien la estrategia de poner un identificado númerico ayuda mucho a consultar con mayor velocidad los registros y hacerlo de forma más uniforme, la realidad es que en el múndo moderno donde vivimos, muchos de los registros se buscan por su identificador del mundo real, es decir, lo que conocemos como Natural ID o Identificador Natural.

Por ejemplo, si estas leyendo este artículo, podrás observar que la URL de esta página sea algo así como https://codmind.com/blog/table-id-vs-natural-id, lo que quiere decir que en realidad el artículo está siendo buscado por su nombre (los guinos medios son para hacerlo amigables para el naveador) y no por un ID.

Otro ejemplo muy utilizado son las API, por ejemplo, imagina que estas desarrollando un servicio para crear un cobro recurrente a los usuario. Veamos como se vería un request con los IDs tradicionales:

{
  "moneda": 10,
  "precio": 199,
  "pais": 3,
  "status": 1,
  "frecuencia": 1
}

El request anterior, en realidad requiere de varias entidades externas, como es la moneda, el país, el status y la frecuencia de cobro, en este sentido, podrías decir que moneda=10 sería como decir moneda=USD, pais=3 sería US, status=1 sería activo y frecuencia=1 sería mensual. En este sentido, accediendo a la información mediante el id de la tabla y no mediante el Natural ID, lo cual haría la vida más simple para los usuario de nuestra API, la cual se podría ver de esta otra forma:

{
  "moneda": "usd",
  "precio": 199,
  "pais": "MX",
  "status": "activo",
  "frecuencia": "mensual"
}

Quiero que observer detenidamente estos dos request y cual crees que tenga más sentido para un usuario ageno a la aplicación y te darás cuenta que el natural id comienza a cobrar sentido.

¿Cómo se implementan un natural id?

La realidad es que el ID número que ya conocemos no esta peleado con el natural id, al contrario, pueden coexitir en una misma tabla, de esta forma, tenemos tablas que tiene el ID de siempre y una columna que puede funsionar con natural id. Si bien esta columna se puede llamar como sea, ya que dependera de cada tabla, la idea es que debe estar marcada como única, para impedir que existe otro registro con el mismo natural id, de la misma forma, deberemos crear un índice que  ayude a realizar búsquedas más rápida sobre ese campo.

Como podemos apreciar en el diagrama anterior, las tablas  Monedas, Status , Paises y Frecuencias cuanta con una columna que funciona como ID númerico y tenemos adicional una columna nombre que funciona como natural id. Esta útima columna, podrás apreciar que esta dentro de los índices marcada como única, lo que garantiza que cuando yo busque un registro por natural id siempre obtenga 0 o 1 registro, pero nunca más de 1.

Si vemos esto a nivel de aplicación, podríamos tener servicios que busquen los registros por su natural id, algo así:

public void suscripcion(SuscripcionRequest req) {
	
    Moneda moneda = monedaService.findByNombre(req.getMoneda())
    	.orElseThrow(() -> new RuntimeException("No existe la moneda" ));
        
    Pais pais = paisService.findByNombre(req.getPais())
    	.orElseThrow(() -> new RuntimeException("No existe el país" ));
    
    Frecuencia frecuencia = frecuenciaService.findByNombre(req.getFrecuencia())
    	.orElseThrow(() -> new RuntimeException("No existe la frecuencia" ));
        
    Status status = statusService.findByNombre(req.getStatus())
    	.orElseThrow(() -> new RuntimeException("No existe el status" ));
        
    Suscripcion suscripcion = Suscripcion.build
    	.moneda(moneda)
        .pais(pais)
        .frecuencia(frecuencia)
        .status(status)
        .precio(req.getPrecio())
        .build();
        
    suscripcionService.save(suscripcion);

}

Podrás apreciar que la capa de controladores busca las relaciones por natural id y luego la asigna al objeto suscripción para terminar persistiendola.

Conclusiónes

Como podemos observar implementar un natural id no implica nada adicional de lo que ya hacemos, ya que por lo general muchas de las tablas ya cuenta con una columna que puede funcionar como natural id, solo faltaría agregar la restricción de único y not null para asegurar la integridad de los datos.

En esta, mi primera entrada en este reconocido blog, estaré tocando el tema de los principios SOLID, para tener los conceptos más claros, ya que es una de las preguntas más comunes en las entrevistas de trabajo para desarrolladores de software y además te permitirá tener una buena base en la programación orientada a objetos. Ya he escrito acerca de este tema y he recibido feedback, aprovechando eso trataré de manejar el tema con palabras sencillas y prácticas para una comprensión rápida del tema 😉.

El aprender estos principios SOLID te supondrá una ventaja competitiva respecto a la docena de programadores que pugnan también por el mismo puesto que tú y una vez dentro del trabajo te ayudará a que tu código sea más mantenible, organizado, legible y escalable, eso es invaluable con el tiempo y te hará más fácil tu trabajo a mediano plazo, además que estarás cumpliendo con un estándar de calidad mínimo en la industria del software y de la empresa misma, todo esto te hará más valioso y deseable como desarrollador para las empresas y eso significa que puedes tentar un cheque más grande a fin de mes ¡provecho!.

La palabra SOLID es un acrónimo de las primeras letras de los 5 principios que veremos a continuación, fueron propuestos por Robert Martin en el 2000 (aquí recomiendo entre otros un libro de él), estos principios son guías y buenas prácticas a seguir para obtener un código de calidad, aun teniendo en cuenta esto, no debemos aplicarlos a rajatabla o forzar su aplicación en nuestro código porque hay ocasiones en los que podemos prescindir de alguno de sus principios por practicidad.

Hay que tener en cuenta que si forzamos la aplicación de estos principios SOLID podríamos hacer más mal que bien a nuestro código porque resultaría más confuso, intrincado e innecesariamente complejo, lo que hay que buscar es el equilibrio entre practicidad/calidad en nuestro código. Hazlo con buenas prácticas, hazlo simple, hazlo efectivo.

Single Responsibility Principle (SRP)

Este principio postula que una clase debe tener sólo una razón para existir, con esto evitamos la mala práctica conocida como la "clase dios" o "super clase" en la cual queremos que una clase haga más de una cosa, y pensamos que esto es bueno, que la clase haga de todo y tratamos de hacerla todo poderosa y que con parámetros en sus métodos hagan diversas funcionalidades, y hasta puede que nos sintamos orgullosos de ello  sin embargo estamos cayendo en un vicio.

Un ejemplo de cómo aplicar este principio es evitar hacer consultas SQL desde una vista, ya que estaríamos añadiendo una responsabilidad de acceso a datos a una clase cuya responsabilidad primaria es la de mostrar controles e interfaces al usuario.

Open Close Principle (OCP)

Este principio dice que nuestro código debe ser abierto a la extensión y cerrado a la modificación, esto lo logramos aplicando el polimorfismo y la abstracción. En buen cristiano esto significa que si a un bloque de nuestro código por ejemplo un método le queremos añadir una nueva funcionalidad esta debe añadirse mediante agregarla en nuestro código no mediante cambiar todo el código existente a la ligera, esto nos obliga a manejar nuestras funcionalidades con código modular por llamarlo de alguna manera y no estar sobre-escribiéndolo o parchándolo si queremos añadir una funcionalidad o feature nuevo.

Liskov Substitution Principle (LSP)

Este principio se define así: "Si S es un subtipo de T, las apariciones de tipo T en un programa pueden ser reemplazadas por otra de tipo S sin que el funcionamiento del programa se vea alterado". Esto quiere decir que sólo debemos derivar o heredar de una clase para añadir funcionalidades, nunca para modificar lo existente, o en otras palabras una clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas.

Interface Segregation Principle (ISP)

En el caso de este principio, no debemos dar más información de la necesaria a los módulos para funcionar. Esto se logra mediante separar las interfaces. Un ejemplo clásico de este principio es el de la transacción de un cajero automático postulado en el libro "Desarrollo de Software Ágil: Principios, patrones y prácticas" de Robert Martin, este ejemplo trata sobre la interfaz de usuario para un cajero automático, que maneja todas las peticiones (como consulta de saldos o retiros), y cómo esta interfaz necesita ser segregada en interfaces más específicas y más concretas.

Dependency Inversion Principle (DIP)

Este principio nos dice que debemos reducir la dependencia entre los módulos de nuestra aplicación, los módulos no deben ser los encargados de crear los objetos con los que trabajan sino que deben ser creados por alguien más y pasárselos a un constructor para que los use cuando quiera.

Este principio está muy relacionado con la buena práctica de Inyección de dependencias que puedes aprender más en esta entrada. Que tu código y su estructura sea tan SÓLIDOS como una montaña!

Pues bien, de momento lo que te toca a ti es investigar y repasar los conceptos aquí repasados estimado lector, pero sobre todo ponerlos en práctica, y ya sabes comparte si te aportó valor esta entrada crack! 💪😊

El pensamiento ágil, más allá de ser algo que esté escrito como metodología, es una forma de vida que invita a estar atento a la incertidumbre en la gestión, abrirse a los cambios repentinos y reaccionar con  entregas frecuentes de productos que les resulten útiles a quienes los pagan y utilizan.

A primera vista, resulta seductor trabajar con este esquema. Sin embargo, la agilidad es una herramienta de gestión más, que surte nuestro repertorio profesional, y que no resuelve todos los problemas. Esta idea se extiende a todos los ámbitos de su aplicación: en proyectos, en cadena de abastecimiento, en estrategia, en auditoría, en recursos humanos, en desarrollo de software, en operaciones, en desarrollo organizacional, entre otras aplicaciones.

Bajo esta premisa, y tomando como piedra angular los principios del Manifiesto Ágil, se presentan seis escenarios concretos en los que no es tan buena idea aplicar la agilidad, porque su uso como medicina podría resultar peor que la enfermedad.

Sin más preámbulos, no es tan buena idea aplicar la agilidad cuando:

1.       No se conoce las motivaciones de los usuarios

Conocer el segmento de usuarios es uno de los primeros pasos en cualquier tipo de gestión, incluyendo la agilidad. Se recomienda tener muy claro a quién involucrar y entender qué intereses tiene cada uno de estos individuos; esto se basa en los principios ágiles de: satisfacer al cliente, trabajar con individuos motivados y comunicar cara a cara la gestión. Para cumplir esto, se recomienda levantar información primaria y secundaria sobre sus rasgos de comportamiento, sus estructuras organizacionales formales, círculos informales de poder, las anécdotas que influyen en su comportamiento, los ritos y símbolos que los diferencia, entre otros.

Después, se esperaría entender los niveles de apoyo y auspicio que se requiere de los individuos de los segmentos en cuestión. Con este entendimiento, entonces se podría diseñar alguna estrategia de involucramiento en el momento que la gestión lo requiera. De no realizar lo descrito, se corre el riesgo de omitir algún resultado esperado, y, en consecuencia, no entregar un trabajo que agregue valor.

2.       No se entiende el problema objetivamente

En segundo lugar, se recomienda entender el problema desde la perspectiva de nuestro segmento, y más importante aún, desde los intereses formales de la organización. Esto significa conocer la causa raíz de aquello que se percibe como problema, de tal forma que nuestra solución resuelva tanto lo visible como lo invisible para el cliente y los usuarios. De omitir esta consideración, se desperdiciarán los recursos finitos, y posiblemente, se empeorará el problema en el corto y largo plazo.

Una de las formas objetivas de entender el problema, es rastrear la causa raíz hacia los elementos organizacionales que se deben crear, mejorar o eliminar. Esto a su vez, se lo puede analizar usando buenas prácticas de arquitectura empresarial que identifica los procesos, tecnologías o las estructuras organizacionales que se relacionan con el problema. Finalmente, se recomienda que esta evaluación arquitectónica considere el contexto de los objetivos estratégicos de la organización que se afectarán de manera positiva o negativa con nuestro accionar.

3.       No se tiene mano de obra técnicamente calificada

De manera textual, la agilidad demanda “la atención continua a la excelencia técnica y al buen diseño…”. Esto tiene dos implicaciones profundas. La primera es que, sin competencias técnicas de excelencia, no es posible entregar frecuentemente productos bien hechos. No confundir con la multidisciplinariedad, ya que el equipo puede ser multidisciplinario, pero con pobres competencias técnicas.

La segunda implicación, es que la agilidad no exime al gestor la tarea de realizar un buen diseño de ingeniería. Frecuentemente, se observan actividades de agilidad que se limitan a realizar ejercicios de creatividad, y bajo las implicaciones presentadas, esta tiene que ir acompañada (y validada) del pensamiento duro ingenieril.

4.       No es algo novedoso o complejo

Como se dijo al inicio de este artículo, la agilidad nace en respuesta a la incertidumbre de los requerimientos de la gestión. Es decir, ante lo desconocido se espera responder con flexibilidad para satisfacer requerimientos que se darán (o cambiarán) sobre la marcha en un contexto de costos y plazos previamente determinados.

Sin embargo, si la naturaleza de la gestión o trabajo a realizar es: repetitiva, recurrente, de baja complejidad, bien conocida, de poca envergadura, de bajo presupuesto, de mínima importancia estratégica o estable desde el punto de vista tecnológico y operativo, entonces no se necesita ser ágil. De no hacerlo así, se desperdiciarán tiempo y recursos en actividades frecuentes de identificación y definición para cosas que ya se conocen y que no ameritan ese esfuerzo. Esto no implica que no se realicen entregas frecuentes, pero esta situación cae en otro tipo de gestión que no es ágil al 100%. Por lo tanto, si no hay novedad en la gestión entonces se recomienda considerar el uso de enfoques tradicionales o híbridos de trabajo, que son eficientes frente al uso de recursos y situaciones de baja complejidad.

5.       No se mide el rendimiento financiero

Otro principio de la agilidad es la medición de productos efectivos. Adicionalmente, y en función de demostrar valor fehacientemente, se recomienda extender la medición al ámbito financiero. Es decir, con nuestra propuesta de solución debemos estar en la capacidad demostrar el "antes y el después financiero" de la organización o segmento social. Esto se recomienda hacer incluso, si se trata de una iniciativa sin fines de lucro o un proyecto social.

En caso de omitir esta recomendación, se podría caer en el terreno del juicio de valor, la opinión y la ambigüedad. Recordemos que en los negocios (y en las iniciativas sociales) la perspectiva financiera es la dominante, porque tenemos el deber profesional de demostrar el nivel de ahorro, incremento de ingresos o, monetizar el valor social entregado (necesario para tocar las puertas de organismos de financiamiento). Como profesionales en gestión, incluyendo a la tecnología y la agilidad, tenemos la obligación -de al menos- estimar los costos y los beneficios financieros de la solución propuesta.

6.       La madurez empresarial es emergente

La madurez empresarial se podría entender como el nivel de rigurosidad y formalidad para operar. No confundir con burocratizar o empapelar la gestión. Rigurosidad quiere decir que está claro lo que hay que hacer organizacionalmente (no me refiero al alcance de un proyecto), que las responsabilidades y roles están formalmente definidos, que los niveles de calidad están establecidos, que el resultado a conseguir se mide y se demuestra, y que las cosas se adaptan con un criterio de negocio.

Entonces, el error más común es encajar una forma rigurosa de trabajar en una cultura organizacional emergente informal. Esto conlleva a desperdicio de recursos, frustración y deterioro de la motivación. Como profesionales de la gestión -incluyendo de la agilidad- adaptamos lo que dicen los libros -y principios- en base a nuestro criterio profesional, y en base a los demás puntos narrados en este artículo. Evidencia de omisión de este punto es seguir cualquier metodología como libro de cocina, sin cuestionar elementos organizacionales internos y externos para adaptar los principios de gestión.

Comentarios finales

La agilidad es una herramienta muy útil de gestión, que finalmente es solo eso, una herramienta más. Nos permite reaccionar ante la incertidumbre, y que como toda herramienta, no es de uso para todos los casos ni para todas las ocasiones. Su aplicación efectiva requiere la presencia de una serie de factores críticos que la soportan y potencian: conocimiento formal a la organización, excelencia técnica en la materia, capacidad de medición operativa y financiera, entre otras.

Argumentando desde el Manifiesto Ágil, se evidencia que la agilidad va mucho más allá de los ejercicios de lluvia de ideas, armado de prototipos o dinámicas de motivación. He de ahí, la invitación a revisar este manifiesto como una lista de chequeo que permita identificar las capacidades que se deben desarrollar previo a la aplicación efectiva de la agilidad, de lo contrario, podría no ser tan buena idea su uso en nuestras organizaciones. (O)

CV

En este artículo crearemos una API REST con Spring Boot, una tecnología de Spring, cabe mencionar que Spring framework es la tecnología más utilizada para la plataforma Java.

Con Spring Boot nos facilitamos las configuraciones como las dependencias de conexión con la base de datos, despliegue del servidor, entre otras.

Utilizaremos MySQL como nuestro gestor de base de datos y maven como el gestor de la aplicación.

Crear el proyecto con Spring Boot

Como lo hemos dicho anteriormente utilizaremos la tecnología Spring Boot, esta nos facilitara las configuraciones y solo tendremos que enfocarnos en el código de nuestra aplicación.

Para iniciar con nuestro proyecto lo realizaremos con spring initializr.

Descripción de los campos:

Project: Seleccionamos el gestor de nuestra aplicación maven o gradle, utilizaremos maven

Languaje: Elegimos con qué lenguaje queremos trabajar, utilizaremos Java

Spring Boot: Seleccionamos la versión con la que queremos trabajar, se deja la que está por default

Project Metadata: Aquí ingresamos el nombre de nuestro proyecto

Packaging: Seleccionamos el empaquetado de nuestra aplicaciones

Java: Seleccionamos la versión de Java

Dependecies: Aquí buscaremos las dependencias que necesitemos, buscamos y agregamos las que se muestran a continuación.

Damos clic en Generate para descargar el proyecto, una vez descargado lo descomprimimos.

Para el desarrollo de la aplicación utilizamos Spring Tool Suite (STS), en este IDE importamos el proyecto como Existing Maven Projects

Nos aparecerá un archivo pom.xml, marcamos el check y damos clic en next.

Nuestro proyecto (STS) empezará a descargar las dependencias que seleccionamos anteriormente, estas se encuentran en el archivo pom.xml

La Base de datos

Esta será la estructura de nuestra base de datos.

En el archivo application.properties con la siguiente ruta de acceso: src/main/resources/ agregamos el string de conexión para ingresar a la base de datos que creamos anteriormente.

spring.datasource.url=jdbc:mysql://localhost:3306/test?serverTimezone=UTC
spring.datasource.username=root
spring.datasource.password=

spring.jpa.show-sql=true

Desarrollo de la API

La siguiente estructura de paquetes es la que creamos para la aplicación.

La clase DemoApplication.java

Es la clase que arranca cuando iniciamos la aplicación.

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.data.jpa.repository.config.EnableJpaAuditing;

@SpringBootApplication
@EnableJpaAuditing
public class DemoApplication {

	public static void main(String[] args) {
		SpringApplication.run(DemoApplication.class, args);
		
	}
	
}

La clase Person.java

La entidad de nuestro objeto Person, esta clase va a mapear los atributos como campos en la base de datos.

package com.example.demo.model;

import java.util.Date;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.EntityListeners;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;
import org.springframework.data.annotation.CreatedDate;
import org.springframework.data.jpa.domain.support.AuditingEntityListener;

@Entity
@Table(name = "users")
@EntityListeners(AuditingEntityListener.class)
public class Person {
	@Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	private Long id;
	private String name;
	
	@Column(name = "user_name")
	private String userName;
	
	@Column(name = "date_registry")
	@CreatedDate
	private Date date;
	
	public Person() {

	}

	public Person(Long id, String name, String userName, Date date) {
		this.id = id;
		this.name = name;
		this.userName = userName;
		this.date = date;
	}
	
	public Long getId() {
		return id;
	}

	public void setId(Long id) {
		this.id = id;
	}

	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}

	public String getUserName() {
		return userName;
	}

	public void setUserName(String userName) {
		this.userName = userName;
	}

	public Date getDate() {
		return date;
	}

	public void setDate(Date date) {
		this.date = date;
	}

	@Override
	public String toString() {
		return "Person [id=" + id + ", name=" + name + ", userName=" + userName + ", date=" + date + "]";
	}

}

La clase PersonRepository.java

Esta clase nos ayuda a realizar operaciones en nuestra base de datos sin escribir tantas líneas de código, Spring Data realiza esto por nosotros, operaciones como delete, save, findAll, son algunos de los métodos que realiza automáticamente.

package com.example.demo.repository;

import java.util.List;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.repository.query.Param;
import org.springframework.stereotype.Repository;
import com.example.demo.model.Person;

@Repository
public interface PersonRepository extends JpaRepository<Person, Long>{
	
	List<Person> findByName(@Param("name") String name);
	
}

La clase PersonController.java

Esta clase le indica a spring que la clase va a ser un controlador de una API Rest, nos proveerá de todos los métodos para un CRUD.

package com.example.demo.Controlller;

import java.util.List;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.DeleteMapping;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.PutMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import com.example.demo.model.Person;
import com.example.demo.repository.PersonRepository;

@RestController
@RequestMapping("/api")
public class PersonController {
	
	@Autowired
	private PersonRepository repository;
	
	
	@GetMapping("/persons")
	public List<Person> allPersons(){
		return repository.findAll();
	}
	
	@GetMapping("/person/{name}")
	public List<Person> findByName(@PathVariable("name") String name) {
		return repository.findByName(name);
	}
	
	@PostMapping("/person")
	public Person createPerson(@RequestBody Person person) {
		return repository.save(person);
	}
	
	@PutMapping("/person/{id}")
	public Person updatePerson(@PathVariable int id ,@RequestBody Person person) {
		return repository.save(person);
	}
	
	@DeleteMapping("/person/{id}")
	public void deletePerson(@PathVariable("id") Long id) {
		repository.deleteById(id);
	}
}

Para realizar las pruebas correspondientes vamos a utilizar postman una aplicación para probar api's.

Realizamos una prueba para almacenar un nuevo registro, para esto utilizamos un método POST.

Con el método POST nosotros podemos almacenar nuevos registros en nuestra base de datos.

Probamos la petición Get

Esta petición get nos traerá todos los registros

Prueba de la petición Get con parámetro

Con la petición Get con parámetro name, podemos buscar un objeto Person por medio del name.

Prueba para actualizar un registro

Este es el registro que queremos actualizar.

A continuación con el método PUT, actualizamos el registro

Este es una API Rest muy sencilla, pero cuando recien estan empezando, sirve de mucho para entender como Spring maneja las anotaciones quienes nos ahorran líneas de código.

Recuerda que puedes aprender a crear API REST de forma profesional con nuestro curso Mastering API REST con Spring boot, donde te enseñaremos desde cero a crear un API REST completa, con las mejores prácticas.

Revisando Get on board (pagina de empleo chilena) se puede apreciar varias ofertas laborales que piden java y ¿Spring? (ninguna oferta que pida Java developer no incluye Spring Boot como requerimiento)

Spring es un framework para backend que se puede usar con Java, Kotlin y Groovy, Spring framework existe para facilitar la creación de aplicaciones, simplificando la estructura del proyecto y mejorando la velocidad de una aplicación empresarial.

¿Qué es una aplicación empresarial?

Una gran aplicación con fines comerciales, que será usada por muchas personas.

Es compleja de hacer, debe ser escalable (Dar la posibilidad de ser modificada sin generarle pesadillas a lxs encargadxs de mantenerla), brindarle comodidad y seguridad al usuario.

¿Spring = Spring Boot?

Negativo, no son lo mismo, Spring Boot funciona con Spring core (Spring framework).

Spring Boot es una variación de Spring que viene con la configuración, que anteriormente, se tenía que hacer a mano, facilitando mucho el desarrollo con Spring, permitiendo al programador no tener que configurar nada, solo va a tener que echar código y pedir ayuda en Stackoverflow.

¿Dónde aprender Spring Boot?

En Codmind tenemos un curso de Mastering de API REST con Spring Boot, aprenderas conceptos claves como ¿Qué es una API REST?, después, daras tus primeros pasos con Spring Boot creando varias APIs REST y así fortaleces los conocimientos que conseguiste en este curso.

Este video es una clase del Mastering, es gratis, te invito a darle una oportunidad y calmar tu curiosidad.

Muchas gracias por leer y hasta la próxima.

Github cambio el nombre de la rama principal. Antes se llamaba master, ahora se llama main, una palabra más corta y que no se puede usar de manera ofensiva.

En Git sigue llamandose master la rama principal. En el flujo de desarrollo esto puede generar conflicto por tener en 2 herramientas distintas, la misma rama principal con diferentes nombres.

Todo tiene solución

Se arregla con cambiar el nombre de la rama, estando en un directorio donde este un archivo .git y posicionandonos en la rama master, corremos el siguiente comando:

git branch -m main

Listo, con este cambiamos el nombre de la rama master a main, ahora esta igual que en Github. Comodamente podemos hacer push al repositorio en Github y no habra que hacer un pull request (esto ahorra tiempo, el tiempo es dinero).

¿Esto es para siempre?

Me hice esta pregunta al enterarme de la noticia, un cambio en la integración de Git con Github, herramientas basicas para cualquier tipo de programador.

Respuesta corta: Negativo, Es probable que Github hable con Git para arreglar diferencias.

Respuesta larga: Github a ido aplicando estos cambios por fases, es decir, poco a poco para que que no sea un cambio brusco, además, escribir un comando significa invertir segundos en eso, segundos que se pueden usar en otra cosa, por ejemplo, ver algunos de los cursos que ofrecemos en codmind. Al final, main es mucho mas corto que master y creo imposible asociar "main" con algo ofensivo.

Me despido e invito a ver esta situación como una prueba, una prueba fiable de la alta probabilidad de cambios en el mundo IT.

Link de referencia

Anuncio del cambio