Forem: Wako

Limitar Gorutinas Con Semáforos

Wako — Thu, 10 Aug 2023 06:05:03 +0000

Problema

Tenemos cierto número de tareas que podemos manejar de manera concurrente. Dichas tareas podrían ser el envío de correos electrónicos, procesar archivos o consultas a bases de datos. Da igual. Son tareas que requieren un tiempo considerable para su ejecución y para poder hacer más rápido el proceso decidimos escribir código concurrente para manejar dichas tareas. Este código concurrente espera poder ejecutar n cantidad de tareas de manera paralela.

Para este ejemplo revisaremos el problema al que me enfrenté en mi proyecto togray. El cual es una herramienta CLI para poder editar múltiples imágenes para aplicar filtros como escala de grises y saturación.

Después del proceso de pedir información al usuario por la línea de comandos, verificar los directorios y archivos tenemos la problematica del procesamiento de imágenes de manera concurrente.

func Run(flagPath string) {
    path := getBasePath(flagPath)
    pictures := getImagesNames(path)
    numberOfPictures := len(pictures)
    if numberOfPictures == 0 {
        log.Printf("There are no images to process")
        return
    }

    wg := sync.WaitGroup{}
    wg.Add(numberOfPictures)

    for _, picture := range pictures {
        go func(picture *Picture) {
            process(&wg, picture)
        }(picture)
    }

    wg.Wait()

}

En el proceso declaramos un waitGroup con el número total de gorutinas a ejecutar. Esto en su momento funcionó muy bien. Ejecuté el programa con algunas imágenes pequeñas en una computadora con procesador M1 y no hubo mayor inconveniente. El problema vino cuando ejecuté el proceso con una gran cantidad de imágenes de gran tamaño y peso, todo en una computadora con un procesador AMD bastante modesto. Ahí fue cuando noté que el proceso consumía todos los recursos de mi sistema operativo y tuve que reiniciar mi PC.

Semáforos

Un semáforo ayuda a limitar el número de tareas concurrentes que puede manejar nuestro equipo de cómputo. Es decir, limitamos el número de tareas que podrán realizarse en paralelo permitiendo así que ciertas tareas se completen antes de iniciar el resto.

Solución

Golang nos proveé de primitivos para poder manejar patrones y programación concurrente más fácilmente. Entre ellos están los channels, que se encargan de la comunicación entre gorutinas.

Con los channels básicamente tenemos una gorutina dueña, la cual se encarga de crear el channel, darle información o pasar el channel a otra gorutina. Y una gorutina que consuma el channel la cual sólo debe preocuparse por saber cuando es que el channel está cerrado.

waitChan := make(chan struct{}, n)

Con esta instrucción podremos crear un channel de una struct vacía la cual permitirá n gorutinas ejecutándose a la vez. Este semáforo será responsable y permitirá controlar la ejecución de nuestras gorutinas, permitiendo ejecutar n a la vez. De esta manera el resto tendrá que esperar que el channel tenga espacio para una tarea más.

for _, picture := range pictures {
    waitChan <- struct{}{}
    go func(picture *Picture) {
        process(&wg, picture)
        <-waitChan
    }(picture)
}

Notar como es que antes de ejecutar nuestra gorutina nuestro channel recibe información de una struct vacía. Y antes de terminar la gorutina nuestro channel libera el espacio previamente asignado.

Solución completa

func Run(flagPath string) {
    path := getBasePath(flagPath)
    pictures := getImagesNames(path)
    numberOfPictures := len(pictures)
    if numberOfPictures == 0 {
        log.Printf("There are no images to process")
        return
    }

    maxProcess := getMaxProcess()
    waitChan := make(chan struct{}, maxProcess)
    wg := sync.WaitGroup{}
    wg.Add(numberOfPictures)

    for _, picture := range pictures {
        waitChan <- struct{}{}
        go func(picture *Picture) {
            process(&wg, picture)
            <-waitChan
        }(picture)
    }

    wg.Wait()
}

Conclusión

Limitar el número de goruinas que podrá ejecutar tu equipo nos brinda la oportunidad de poder tener más control sobre nuestro hardware y el cómo procesará nuestra información. De esta manera podemos encontrar un buen balance y performance sin correr riesgos de agotar nuestros recursos. Si notas que en tu entorno hay problemas de performance puedes ir probando el número adecuado de tareas para realizar de forma concurrente.

Puedes encontrar otro ejemplo de semáforos aquí.

Introduccion a Golangci Lint

Wako — Sun, 27 Nov 2022 03:41:23 +0000

Cuando comencé a aprender Go por allá en el 2017 me fascinó la cantidad de herramientas de desarrollo que Go nos brinda en su instalación. Una de estas herramientas siendo gofmt, la que más llamó mi atención en ese momento. Una herramienta CLI que reescribía nuestro código fuente en el formato estándard aprobado y recomendado por la comunidad. A diferencia de otros lenguajes Go nunca tuvo debates sobre una guía de estilo, siendo fmt la norma recomendada y diseñada por las mismas personsas que diseñan el lenguaje.

Sin embargo, aunque gofmt nos permite formatear nuestro código utilizando un diseño estandard aún así necesitamos una herramienta externa para poder establecer otras normas para nuestro código. Chequeos como: número de líneas o argumentos por funciones, elementos nos utilizado o casteos innecesarios son algunos ejemplos que necesitan una herramienta más personalizable.

Ahí es donde entra golangci-lint. Golangci-lint es por si mismo un ejecutor de una colección de diferentes linteres. Es decir, no es un linter por si mismo, sino que utiliza diferentes linters escritos por la comunidad de Go para poder ofrecer en un solo paquete el uso de estas herramientas.

Cuenta con diferentes opciones de instalación para macOS, Linux y Windows; así como scripts de instalación en herramienta de CI/CD para utilizarlas en nuestros pipelines. Además de esto también cuenta con un plugin de asdf para poder configurar diferentes versiones con esta herramienta.

Una vez con la herramienta instalada podemos confirmarlo con:

$ golangci-lint version
golangci-lint has version 1.49.0 built from cc2d97f3 on 2022-08-24T10:24:37Z

Configuración

Esta herramienta puede configurarse con archivos escritos en documentos de tipo yml, taml, toml o json. Lo que nos permite tener configuraciones personalizadas por proyectos así como globales. Simplemente tendremos que colocar estos archivos en la raíz de nuestros proyectos o definir un path durante la ejecución; de otro modo golangci-lint buscará un archivo de configuración global en el directorio del usuario. Si un archivo de configuración no es encontrado se utiliza la configuración por defecto.

Podemos configurar cosas como timeout, ejecución concurrente, revisión de archivos de tests, archivos o directorios a ignorar (muy útil para ignorar cosas como vendor o archivos generados), formato de salida, etc. Además de estas opciones sobre la configuración de la herramienta podemos configurar en este archivo el conjunto de linters a ejecutar para analizar nuestro código. Esto es muy importante en caso de que querramos agregar o quitar linters a la configuración y ejecución por defecto.

Ejemplo

Para este ejemplo utilizaremos el siguiente archivo de configuración:

linters:
  enable:
    - errcheck
    - funlen
    - gofmt
    - gosimple
    - ifshort
    - predeclared

linters-settings:
  funlen:
    lines: 20
    statements: 20
  gofmt:
    simplify: true

run:
  skip-dirs:
    - .git
    - vendor

Y analizaremos el siguiente programa:

package main

import (
    "fmt"
    "strconv"
)

func Foo() {
    fmt.Println("foo")
    fmt.Println("foo")
    fmt.Println("foo")
}

func Bar() {
    fmt.Println("foo")
    fmt.Println("foo")
    fmt.Println("foo")
}

func Example() (string, error) {

    n := 1

    n = 100

    n = 10

    if n < 100 {

        res, _ := strconv.ParseComplex("", 1)

        // Lorem.
        // Lorem.
        // Lorem.
        // Lorem.
        // Lorem.
        // Lorem.
        // Lorem.
        // Lorem.
        // Lorem.
        // Lorem.
        // Lorem.
        // Lorem.
        // Lorem.
        // Lorem.
        // Lorem.

        fmt.Println(res)

    }

    return "Example", nil
}

func main() {
    Foo()
    Bar()
    Example()
}

En este ejemplo contamos con tres funciones de prueba las cuales tienen diferentes problemas. El código compila y si verificamos con gofmt está escrito de manera correcta siguiendo la guía de estilo de Golang. Sin embargo con golangci-lint podemos verificar alguna cosas de las cuales puede que nos querramos hacer cargo antes de hacer commit de nuestros cambios.

$ golangci-lint run
main.go:58:9: Error return value is not checked (errcheck)
        Example()
               ^
main.go:20: Function 'Example' is too long (32 > 20) (funlen)
func Example() (string, error) {
main.go:22:2: ineffectual assignment to n (ineffassign)
        n := 1
        ^
main.go:24:2: ineffectual assignment to n (ineffassign)
        n = 100
        ^
main.go:30:38: SA1030: 'bitSize' argument is invalid, must be either 64 or 128 (staticcheck)
                res, _ := strconv.ParseComplex("", 1)

La ejecución nos da diferente información sobre los errores encontrados como: nombre del archivo y línea de código, descripción del error y nombre del linter. La línea main.go:20: Function 'Example' is too long (32 > 20) (funlen) nos da un error interesante: (32 > 20) es la comparación del número total líneas de código en nuestra función contra el número permitido en el archivo de configuración. Si cambiamos nuestra configuración podremos ver como este mensaje desaparece de la lista de errores.

linters-settings:
  funlen:
    lines: 100
    statements: 100

$ golangci-lint run
main.go:58:9: Error return value is not checked (errcheck)
        Example()
               ^
main.go:22:2: ineffectual assignment to n (ineffassign)
        n := 1
        ^
main.go:24:2: ineffectual assignment to n (ineffassign)
        n = 100
        ^
main.go:30:38: SA1030: 'bitSize' argument is invalid, must be either 64 or 128 (staticcheck)
                res, _ := strconv.ParseComplex("", 1)

Pero lo ideal sería cambiar nuestro código para que se adapte a nuestras reglas, no al revés. Así que regresaré la configuración a la original de 20 líneas.

linters-settings:
  funlen:
    lines: 20
    statements: 20

El código fuente tiene que ser modificado para poder cumplir con los estándares ya establecidos. Después del cambio podemos ver el nuevo archivo:

package main

import (
    "fmt"
    "log"
    "strconv"
)

func Foo() {
    fmt.Println("foo")
    fmt.Println("foo")
    fmt.Println("foo")
}

func Bar() {
    fmt.Println("foo")
    fmt.Println("foo")
    fmt.Println("foo")
}

func Example() (string, error) {
    if n := 10; n < 100 {
        res, _ := strconv.ParseComplex("", 64)
        fmt.Println(res)
    }

    return "Example", nil
}

func main() {
    Foo()
    Bar()

    if _, err := Example(); err != nil {
        log.Fatal(err)
    }
}

Con el archivo modificado y cumpliendo con todas las configuraciones golancgi-lint ya no debe de mostrar ningún error en su ejecución.

$ golangci-lint run
$

Más automatización

Algunos linters son más simples que otros. Algunos reglas de configuración como de archivos en el formato de gofmt, comentarios y líneas en blanco pueden ser reparados fácilmente con el flag --fix durante la ejecución de la herramienta. Esto es principalmente útil si es la primera vez que ejecutas el linter en un codebase amplio, permitiendo poder reparar todos esos errores durante la primera ejecución sin tener que hacerlo a mano modificando los archivos nosotros mismos.

Conclusión

Contar con estándares establecidos para nuestro código es muy importante, sobre todo para cuando trabajamos con más personas. De esta manera las organizaciones pueden mantener un mismo estilo de codificación siguiendo tanto las normas y guías de la comunidad oficial así como personalizar las propias. Para más información sobre golangci-lint pueden consultar su sitio oficial.

Básicos Erlang / Elixir: La elegancia de match operator y aridad múltiple

Wako — Fri, 23 Sep 2022 06:25:50 +0000

Erlang y Elixir son lenguajes que me han impresionado bastante y que recientemente me he tomado más tiempo para explorar. Ambos lenguajes de programación son sumamente poderosos por sus paradigmas funcionales y concurrentes. Siendo Elixir un lenguaje de programación basado en Erlang pero con una azúcar sintáctica similar a Ruby.

Algunos de los conceptos básicos en ambos lenguajes son pattern matching y aridad. La combinación de ambos nos permite tener código limpio y expresivo.

Pattern Matching

Es la acción de revisar que una secuencia de identificadores siga un patrón otorgado. Esta comparación tiene que ser exacta para poder ser válida.

iex(1)> x = 1
1

Este es el ejemplo más sencillo de pattern matching. En otros lenguajes esta operación sería conocida como una asignación. Donde a x se le asigna el valor 1. Pero en Erlang y Elixir esto se conoce como pattern matching. Siendo x un identificador no declarado éste intenta hacer match con su patrón de la derecha. Este patrón al hacer match hace un vínculo entre a y 1.

iex(1)> a = 1
1
iex(2)> 1 = a
1
iex(3)> 2 = a
** (MatchError) no match of right hand side value: 1

iex(3)>

Lo que está pasando es que se hizo un pattern matching entre a y 1. Siendo así que a hace un match con este valor. En la segunda línea podemos ver 1 = a lo cual es correcto, ya que a tomó este patrón. Pero en 2 = a tenemos el error ** (MatchError) no match of right hand side value: 1 ya que al intentar hacer el pattern matching entre el valor de la izquierda con el patrón de la derecha estos no coinciden. No hay un match entre 2 y a ya que a anteriormente hizo un match con 1.

Veamos un ejemplo más complejo. Tenemos una lista de números al cual se aplicará pattern matching para almacenarlos en identificadores:

iex(1)> [a, b, c] = [1, 2, 3]
[1, 2, 3]
iex(2)> a
1
iex(3)> b
2
iex(4)> c
3
iex(5)>

Tenemos una lista de elementos [a, b, c] del lado izquierdo a la cual se aplicará pattern matching contra el patrón [1, 2, 3]. De esta manera tenemos en cada uno de los identificadores el valor correspondiente de la derecha con el que hizo match. Pero ¿Qué pasa si el patrón de la izquierda no coincide con el de la derecha?

iex(1)> [a, b, c, d] = [1, 2, 3]
** (MatchError) no match of right hand side value: [1, 2, 3]

iex(1)> [a, b] = [1, 2, 3]      
** (MatchError) no match of right hand side value: [1, 2, 3]

iex(1)>

El primer error nos indica que no existe un cuarto elemento en el patrón de la derecha cuando intenta hacer match con el patrón de la izquierda el cual sí contiene un cuarto elemento.

El segundo error indica el patrón de la izquierda contiene únicamente dos elementos cuando el patrón de la derecha contiene tres.

Se puede escribir mucho más artículos enteros sobre pattern matching. Pero espero que con estos ejemplos haya quedado claro que nos permite comparar patrones extrictos para poder acceder a sus valores.

Aridad

Wikipedia define aridad como:

En el análisis matemático, la aridad de un operador matemático o de una función es el número de argumentos necesarios para que dicho operador o función se pueda calcular.

En Erlang y Elixir la aridad de una función es parte de la firma de la misma. Esta aridad nos permite identificar funciones por el número de sus parámetros.

Por ejemplo. Una función de suma con aridad 2 y aridad 3 se ven así:

def sum(a, b)
def sum(a, b, c)

Nuestras funciones se identifican como sum/2 y sum/3. De esta manera podemos exportarlas o importarlas.

El poder de pattern matching y aridad

De la misma manera a que la aridad nos permite definir una función del mismo nombre dependiendo sus parámetros, pattern matching nos permite hacer algo similar. Pudiendo así definir múltiples veces la misma función dependiendo el match que se realiza en sus parámetros.

Por ejemplo:

def fac(0), do: 1
def fac(n), do: n * fac(n-1)

Gracias a la combinación de estas dos propiedades podemos separar la lógica de la función dependiendo del valor del parámetro recibido. En este caso cuando fac reciba como argumento el valor 0 la función retornará 1. En cambio cuando fac reciba cualquier otro valor n se realizará el cálculo de n *fac(n-1) utilizando recursividad.

En un lenguaje como Go tendríamos que recurrir a algo

func fac(n int) int64 {
    if n == 0 {
        return 1
    }

    return int64(n) * fac(n-1)
}

Donde tendríamos que tener un bloque if para poder dividir la función y así obtener dos resultados dependiendo el valor del parámetro. ¿Qué pasa con funciones más complejas? En lenguajes "tradicionales" tendríamos que meter condiciones dentro del cuerpo de nuestras funciones para así poder obtener diferentes resultados dependiendo su parámetro. Pero aprovechando la ventaja que nos da pattern matching y la aridad de las funciones en Erlang y Elixir podemos escribir código como los siguientes ejemplos.

def eat_ghost?(true, true), do: true
def eat_ghost?(_, _), do: false

def exp(x, n), do: exp(x, n, 1)
def exp(_, 0, acc), do: acc
def exp(x, n, acc), do: exp(x, n - 1, x * acc)

En conclusión: Erlang y Elixir nos ofrecen desde sus características más básicas herramientas muy poderosas parar poder escribir código limpio y descriptivo.

Tips de Go: Cómo concatenar texto de forma eficiente

Wako — Sat, 17 Sep 2022 08:14:23 +0000

En ocasiones es necesario unir dos o más cadenas de texto en una sola. Qué mejor que hacerlo de una manera eficiente. La manera "tradicional" o como haríamos en otros lenguajes es concatenar cada elemento a una cadena de texto. Para esto utilizaríamos el operador += en una cadena de texto para añadir cada elemento de nuestra colección.

res := ""
for _, f := range fields {
  res += f
}

Es un código simple, pero no muy eficiente. Crearemos un benchmark para demostrarlo. Para esto crearemos en un archivo de pruebas una función que nos ayudará a tener data de prueba. Utilizaremos faker para generar datos falsos.

func createFakeDataForBenchmark(b *testing.B) []string {
    b.Helper()
    faker := faker.New()
    n := 100_000
    res := make([]string, n)

    for i := 0; i < n; i++ {
        line := faker.Person().Name()
        res[i] = line
    }
    return res
}

Nuestra función de data falsa nos creará un slice de 100,000 nombres. El cual será utilizado en nuestro benchmark.

func BenchmarkConcat(b *testing.B) {
    fields := createFakeDataForBenchmark(b)
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        res := ""
        for _, f := range fields {
            res += f
        }
    }
}

Ejecutaremos nuestro benchmark y guardaremos los resultados en un archivo txt.

$ go test -bench=. -count=20 > old.txt

De esta manera nos aseguramos de que ejecutemos 20 veces nuestro benchmark y cada resultado lo almacenamos en nuestro archivo old.txt.

$ cat old.txt
goos: darwin
goarch: arm64
pkg: testGo
BenchmarkConcat-8              1    10799521250 ns/op
BenchmarkConcat-8              1    8960573042 ns/op
BenchmarkConcat-8              1    8948590917 ns/op
BenchmarkConcat-8              1    9240871750 ns/op
BenchmarkConcat-8              1    9568445417 ns/op
BenchmarkConcat-8              1    9483034167 ns/op
BenchmarkConcat-8              1    9359205584 ns/op
BenchmarkConcat-8              1    9431272208 ns/op
BenchmarkConcat-8              1    9284579833 ns/op
BenchmarkConcat-8              1    9633018708 ns/op
BenchmarkConcat-8              1    9615555208 ns/op
BenchmarkConcat-8              1    9435577625 ns/op
BenchmarkConcat-8              1    9472732667 ns/op
BenchmarkConcat-8              1    9526675042 ns/op
BenchmarkConcat-8              1    9425694959 ns/op
BenchmarkConcat-8              1    9336684417 ns/op
BenchmarkConcat-8              1    9773708583 ns/op
BenchmarkConcat-8              1    9535284291 ns/op
BenchmarkConcat-8              1    9922773833 ns/op
BenchmarkConcat-8              1    9593992500 ns/op
PASS
ok      testGo  191.381s

Podemos notar que nuestro benchmark fue ejecutado 20 veces y cada una de ellas la función pudo realizarse una única vez. Demorando una cantidad de tiempo considerable para concatenar unas 100,000 cadenas de texto.

Ahora haremos unos cambios a nuestra solución para hacerla más óptima. Para esto utilizaremos un string builder. La cual es una estructura de la biblioteca estándar la cual está optimizada para el manejo de cadenas de texto.

Nuestro benchmark utiliza esta estructura para concatenar eficientemente cada uno de los elementos de nuestra data falsa. Para esto se vale del método WriteString.

func BenchmarkConcat(b *testing.B) {
    fields := createFakeDataForBenchmark(b)
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        var res strings.Builder
        for _, f := range fields {
            res.WriteString(f)
        }
    }
}

De igual manera ejecutamos y almacenamos el resultado de nuestro benchmark en un archivo de texto.

$ go test -bench=. -count=20 > new.txt

A simple vista podemos ver una diferencia significativa entre ambos archivos.

$ cat new.txt
goos: darwin
goarch: arm64
pkg: testGo
BenchmarkConcat-8            627       1920271 ns/op
BenchmarkConcat-8            621       1924366 ns/op
BenchmarkConcat-8            619       1936682 ns/op
BenchmarkConcat-8            610       1938242 ns/op
BenchmarkConcat-8            613       1950456 ns/op
BenchmarkConcat-8            680       1554438 ns/op
BenchmarkConcat-8            868       1580795 ns/op
BenchmarkConcat-8            794       1563124 ns/op
BenchmarkConcat-8            747       1529450 ns/op
BenchmarkConcat-8            733       1536551 ns/op
BenchmarkConcat-8            732       1532616 ns/op
BenchmarkConcat-8            781       1568152 ns/op
BenchmarkConcat-8            790       1535016 ns/op
BenchmarkConcat-8            745       1536268 ns/op
BenchmarkConcat-8            843       1746608 ns/op
BenchmarkConcat-8            736       1533825 ns/op
BenchmarkConcat-8            786       1583720 ns/op
BenchmarkConcat-8            619       1712188 ns/op
BenchmarkConcat-8            802       1550521 ns/op
BenchmarkConcat-8            751       1589650 ns/op
PASS
ok      testGo  30.768s

Donde en el benchmark anterior nuestros resultados no pasaban de una ejecución en este caso tenemos hasta un total de 868 ejecuciones. Pero para poder comprobar de una manera más óptima el resultado de nuestros benchmarks utilizaremos la herramienta benchstat.

$ benchstat old.txt new.txt

name      old time/op  new time/op  delta
Concat-8   9.48s ± 5%   0.00s ±17%  -99.98%  (p=0.000 n=18+20)

Benchstat nos da información acerca del promedio de cada uno de nuestros benchmarks. La columna delta nos indica una dismunución en tiempo de ejecución entre nuestra prueba old y nuestra prueba new. Siendo una reducción de -99.98% de tiempo bastante significativo entre nuestras dos soluciones. Siendo así strings.Builder la solución más óptima para este tipo de situaciones.

Así que ya lo sabes. La próxima vez que tengas que crear una cadena de texto concatenando varios elementos no utilices la manera "clásica" y utiliza en su lugar un string builder.

Leer un archivo de configuración para tu aplicación de Go

Wako — Sat, 18 Jun 2022 22:05:08 +0000

¿Qué es un archivo de configuración?

Un archivo de configuración es un archivo de texto plano que puede ser modificado por el usuario para dar ciertos parámetros de configuración a una aplicación. Un ejemplo de estos serían los archivos de configuración de Apache o el archivo de configuración de Git.

¿Existe algún formato específico?

No, no existe ningún formato específico. Bien podría ser un xml, un yml, un json o incluso existen programas que crean su propia sintaxis para sus archivos de configuración. Para este ejemplo usaremos un archivo json.

Nuestro proyecto

Tendremos un proyecto de ejemplo con el siguiente árbol de directorios:

.
├── Makefile
├── cmd
│   └── app
│       └── main.go
├── config
│   └── config.go
├── config.json
├── go.mod
└── service
    └── foo.go

Definiendo nuestro paquete de configuración

Este paquete se encargará de leer nuestro archivo de configuración. Además tendrá que hacerlo una sola vez, ya que la configuración con cambiará durante la ejecución de nuestra aplicación.

Para esto tenemos que aplicar un patrón de diseño conocido como singleton. Lo cual crea una única instancia de un tipo de dato en nuestra aplicación.

Dentro de config/config.go creamos una estructura para almacenar la información de nuestra configuración y un puntero de la misma.

type Config struct {
    Name string `json:"name"`
    Age  int    `json:"age"`
}

var config *Config

Exponemos una función llamada GetConfig la cual retorna un *Config. Dentro de esta función revisamos que el puntero config declarado anteriormente se encuentre vacío.

if config == nil {
  log.Println("Loading config file...")
}

Una vez asegurados que config no contiene información podemos abrir el archivo de configuración utilizando el path del archivo. En este ejemplo el path se pasa directamente, pero bien podría tomarse de una variable de entorno para definir otra ruta de archivo.

file, _ := os.Open("config.json")
defer file.Close()

Una vez abierto el archivo se crea un decoder de tipo JSON para poder leerlo. Y en caso de error se colocan valores por defecto en una variable de tipo Conf.

decoder := json.NewDecoder(file)
var conf Config
err := decoder.Decode(&conf)
if err != nil {
    conf.Name = "Default Name"
    conf.Age = 21
}

Para poder pasar los valores de la variable conf al puntero config creamos un Sync.Once.

var config *Config
var once sync.Once

Y dentro de nuestra función de GetConfig utilizamos once para poder pasar nuestra info a config.

once.Do(func() {
  config = &Config{
    Name: conf.Name,
    Age:  conf.Age,
  }
})

Y por último GetConfig retornará config después de nuestra validación.

func GetConfig() *Config {
    if config == nil {
        log.Println("Loading config file...")
        file, _ := os.Open("config.json")
        defer file.Close()

        decoder := json.NewDecoder(file)
        var conf Config
        err := decoder.Decode(&conf)
        if err != nil {
            conf.Name = "Default Name"
            conf.Age = 21
        }

        once.Do(func() {
            config = &Config{
                Name: conf.Name,
                Age:  conf.Age,
            }
        })
    }

    return config
}

Utilizando nuestra configuración

Nuestro cmd se encargará únicamente de iniciar nuestra aplicación llamando la función Start dentro de service/foo.go.

package main

import "config/service"

func main() {
    service.Start()
}

Y service/foo.go tendrá la funcionalidad de nuestra aplicación. Donde llamaremos a GetConfig para obtener nuestra configuración.

Dentro de la función Start llamaremos por múltiples veces a GetConfig y notaremos que la inicialización del puntero sólo sucede una vez.

Obtenemos la configuración y la utilizamos para imprimir un mensaje en pantalla. Además ejecutamos las funciones foo y bar.

func Start() {
    conf := config.GetConfig()
    fmt.Printf("Hello %s. You are %d years old.\n", conf.Name, conf.Age)
    foo()
    bar()
}

Dentro de foo y bar haremos algo similar. Obtendremos nuestra configuración y la utilizaremos para imprimir un mensaje en pantalla.

func foo() {
    conf := config.GetConfig()
    fmt.Printf("Hello from foo> %s | %d\n", conf.Name, conf.Age)
}

func bar() {
    conf := config.GetConfig()
    fmt.Printf("Hello from bar> %d | %s\n", conf.Age, conf.Name)
}

Compilamos el proyecto y podemos ver que el log colocado dentro de GetConfig sólo se muestra una vez. Además podemos notar que se están utilizando los valores por defecto colocados en el manejo del error en GetConfig. Esto porque no existe aún el archivo config.json dentro de nuestro proyecto.

$ make compile
$ ./app                
2022/06/18 16:50:40 Loading config file...
Hello Default Name. You are 21 years old.
Hello from foo> Default Name | 21
Hello from bar> 21 | Default Name
$

Creamos el archivo config.json con el siguiente contenido:

{
  "age": 29,
  "name": "Wako"
}

Y ejecutamos el programa de nuevo. No es necesario compilar.

$ ./app      
2022/06/18 16:53:18 Loading config file...
Hello Wako. You are 29 years old.
Hello from foo> Wako | 29
Hello from bar> 29 | Wako
$

De esta forma es fácil proveer de nuestros programas de Go archivos de configuración. Pueden encontrar el código completo aquí. Además acá pueden ver un ejemplo más complejo aplicado a un generador de arte digital.

Usar pruebas de caja negra para encontrar bugs en nuestro código con Go

Wako — Mon, 29 Nov 2021 01:20:15 +0000

Las pruebas de caja negra:

Como ejemplo vamos a tener una función que se encargará de enmascarar un número de tarjeta de crédito. De manera que si de entrada tenemos 1234567890123456 la salida sea 1234XXXXXXXX3456.

func Mask(card string) string {
    log.Println(card, len(card))

    start := card[0:4]
    between := strings.Repeat("X", 8)
    end := card[12:]
    res := fmt.Sprintf("%s%s%s", start, between, end)

    return res
}

Hacemos una prueba unitaria

func TestMask(t *testing.T) {
    t.Run("success", func(t *testing.T) {
        res := Mask("1234567890123456")

        if len(res) != 16 {
            t.Log("len should be 16")
            t.Fail()
        }

        if res != "1234XXXXXXXX3456" {
            t.Log("wrong output")
            t.Fail()
        }
    })
}

Ejecutamos la prueba y pasa. Tenemos nuestro código al 100% y aparentemente todo está bien. ¿El error? Estamos probando con inputs que sabemos que tendrán un resultado exitoso.

Golang tiene un paquete llamado quick, el cual nos brinda herramientas para hacer pruebas de caja negra.

Por ejemplo la función Check

func Check(f interface{}, config *Config) error

Lo que hace esta función Check es tomar una función que retorne un bool (f) y ejecutarla n veces con valores aleatorios. Estos valores aleatorios, el número total n y demás valores son configurables a través de la estructura Config.

Como se mencionó con anterioridad, la función f debe retornar un bool. Pero ¿Qué debe realizar esta función? Dentro de esta función f debemos ejecutar nuestra función Mask y comprobar que los valores que esperamos de nuestra prueba unitaria se cumplan.

f := func(card string) bool {
    res := Mask(card)

    expectedLen := len(res) == 16

    return expectedLen
}

Como la función f se ejecutará un número de n veces utilizando valores aleatorios como argumentos no podemos esperar que el resultado de Mask sea siempre 123456789123456 por lo que la prueba del resultado esperado se omite.

Para crear la estructura Config podemos crear una función de ayuda como la siguiente:

func getConfig(t *testing.T) quick.Config {
    t.Helper()

    src := rand.NewSource(time.Now().Unix())

    return quick.Config{
        MaxCount: 100,
        Rand:     rand.New(src),
    }
}

De esta manera podemos reutilizar la función en caso de ser necesario o crear más pruebas de este tipo.

t.Run("random cards", func(t *testing.T) {
    f := func(card string) bool {
        res := Mask(card)

        expectedLen := len(res) == 16

        return expectedLen
    }
    cfg := getConfig(t)

    if err := quick.Check(f, &cfg); err != nil {
        t.Error(err)
    }
})

Dentro de este bloque de pruebas definimos nuestra función f, conseguimos la configuración y ejecutamos quick.Check utilizando estos valores. Comprobamos que en caso de error fallemos la prueba.

Al ejecutar el conjunto de pruebas vemos que tenemos un error:

2021/11/28 15:55:47 1234567890123456 16
2021/11/28 15:55:47 򶐡񦂅󡟗񸎏ꌞ򢬳񫭌򭵳򺓶󷢸⇴󟀱󦲚򹽉񱥢򠼯񇕛𯂴􆥆񕃩򮙖􃚬򠦞􈂰񉗡򹳯򶠃󍭙򧓦􁸺򌋺򓧐񁬼񉛯󜠬񌺼񘊳㶱𓺬󎙻鐎􋀓󸋈𑿽 175
--- FAIL: TestMask (0.00s)
    --- FAIL: TestMask/random_cards (0.00s)
        mask_test.go:34: #1: failed on input "\U000b6421\U00066085\U000e17d7\U0007838fꌞ\U000a2b33\U0006bb4c\U000add73\U000ba4f6\U000f78b8⇴\U000df031\U000e6c9a\U000b9f49\U00071962\U000a0f2f\U0004755b\U0002f0b4\U00106946\U000550e9\U000ae656\U001036ac\U000a099e\U001080b0\U000495e1\U000b9cef\U000b6803\U000cdb59\U000a74e6\U00101e3a\U0008c2fa\U000939d0\uf16c\U00041b3c\U000496ef\U000dc82c\U0004cebc\U000582b3㶱\U00013eac\U000ce67b鐎\U0010b013\U000f82c8\U00011ffd"
FAIL
exit status 1
FAIL    tctest  0.002s
go exited with status code 1

El primer log corresponde a la prueba controlada con un input de 1234567890123456, mientras que el segundo log corresponde a una prueba ejecutada por Quick con un valor aleatorio.

Se puede observar que el input de Mask fue una cadena de texto de 175 caracteres, muchos de los cuales ni siquiera se pueden interpretar en el terminal.

Al ejecutar las pruebas una vez más tenemos un error diferente.

2021/11/28 17:34:14 1234567890123456 16
2021/11/28 17:34:14 򣝦 4
--- FAIL: TestMask (0.00s)
    --- FAIL: TestMask/random_cards (0.00s)
panic: runtime error: slice bounds out of range [12:4] [recovered]
    panic: runtime error: slice bounds out of range [12:4]

goroutine 8 [running]:
testing.tRunner.func1.2({0x50e1a0, 0xc000018300})
    /home/wako/.gvm/gos/go1.17.3/src/testing/testing.go:1209 +0x24e
testing.tRunner.func1()
    /home/wako/.gvm/gos/go1.17.3/src/testing/testing.go:1212 +0x218
panic({0x50e1a0, 0xc000018300})
    /home/wako/.gvm/gos/go1.17.3/src/runtime/panic.go:1038 +0x215
tctest.Mask({0xc000016264, 0x4})
    /home/wako/Datos/Codigo/Go/src/gotestquickmask/mask.go:14 +0x1b9
tctest.TestMask.func2.1({0xc000016264, 0x1})
    /home/wako/Datos/Codigo/Go/src/gotestquickmask/mask_test.go:25 +0x1e
reflect.Value.call({0x4fcf80, 0x523498, 0x4fb220}, {0x51873b, 0x4}, {0xc00000c0a8, 0x1, 0x1})
    /home/wako/.gvm/gos/go1.17.3/src/reflect/value.go:543 +0x814
reflect.Value.Call({0x4fcf80, 0x523498, 0xc00004a690}, {0xc00000c0a8, 0x1, 0x1})
    /home/wako/.gvm/gos/go1.17.3/src/reflect/value.go:339 +0xc5
testing/quick.Check({0x4fcf80, 0x523498}, 0x0)
    /home/wako/.gvm/gos/go1.17.3/src/testing/quick/quick.go:290 +0x233
tctest.TestMask.func2(0xc0001209c0)
    /home/wako/Datos/Codigo/Go/src/gotestquickmask/mask_test.go:33 +0x52
testing.tRunner(0xc0001209c0, 0x5234a0)
    /home/wako/.gvm/gos/go1.17.3/src/testing/testing.go:1259 +0x102
created by testing.(*T).Run
    /home/wako/.gvm/gos/go1.17.3/src/testing/testing.go:1306 +0x35a
exit status 2
FAIL    tctest  0.004s
go exited with status code 1

Sun Nov 28 17:34:14 2021
----------------

Dentro de este error podemos observar que nos indica que ocurrió un panic.

panic: runtime error: slice bounds out of range [12:4]

Esto se debe a que a la nuestra función intenta acceder al índice 12 de una cadena de texto de 4 caracteres.

De esta manera podemos observar como el pasar como input valores aleatorios nos ayuda a encontrar bugs los cuales tal vez no se habían considerado.

Para solucionarlo tenemos que modificar nuestra función y volver a ejecutar las pruebas para comprobar la validez de nuestro programa.

Para asegurarnos que el resultado sea una cadena de texto de 16 caracteres y el que la función no caiga en un panic al acceder a los índices, podemos asegurarnos de validar el input de la función.

func Mask(card string) (string, error) {
    log.Println(card, len(card))

    if len(card) != 16 {
        return "", errors.New("card length should be 16")
    }

    start := card[0:4]
    between := strings.Repeat("X", 8)
    end := card[12:]
    res := fmt.Sprintf("%s%s%s", start, between, end)

    return res, nil
}

En esta nueva implementación agregamos un returno a nuestra función, este segundo retorno nos indicará sobre algún error dentro de nuestra función.

if len(card) != 16 {
  return "", errors.New("card length should be 16")
}

En caso de que la longitud del input sea diferente de 16 caracteres devolvemos un error. Esto evitará el panic y resultados no deseados.

Comprobamos el error durante la primera prueba

t.Run("success", func(t *testing.T) {
    res, err := Mask("1234567890123456")

    if err != nil {
        t.Log("err shuold be nil")
        t.Fail()
    }

    if len(res) != 16 {
        t.Log("len should be 16")
        t.Fail()
    }

    if res != "1234XXXXXXXX3456" {
        t.Log("wrong output")
        t.Fail()
    }
})

De esta manera aseguramos que en el caso de mandar como input 1234567890123456 no ocurrirá un error.

Para la segunda prueba debemos agregar la validación del error y utilizarlo como parte de la lógica del return de la función f.

t.Run("random cards", func(t *testing.T) {
    f := func(card string) bool {
        res, err := Mask(card)

        if err != nil {
            return len(res) == 0
        }

        expectedLen := len(res) == 16

        return expectedLen
    }
    cfg := getConfig(t)

    if err := quick.Check(f, &cfg); err != nil {
        t.Error(err)
    }
})

De esta manera ejecutamos las pruebas y observamos que ambas pruebas pasan.

2021/11/28 17:55:36 񂲫򈐾򓜧𻺹嫁򂆆🚒𾮹娅󪐿􋇢򦹸򽮝򖷌󹬰񦌤􋛝񁶠󙡯⾗񅗜󮍿򩡢 89
2021/11/28 17:55:36 𥋚󸈋򪋦񉸩 19
2021/11/28 17:55:36 񛃎󧳿𶒡𿓗󌳙򈱊􀍬󢪢񬔩𪼖𷞛𦴒󞞚񡨧󚥪󑑢񃵞𷱄 72
2021/11/28 17:55:36 󪼐󽠄󀳑𞀷󼦏򷜰𪂺񁪬􃭿񡒎򩝽뱣򒰛񋆛󕂴񭃆򊓨𤛊𾗗񉑤󹐸񣨨󈄀񘬾񦚠򵮤󙤎𛻻򧪴򅻠𻅋򀠰񍿫񔶈򫄣񠖑󧟞𜡼򪴉򫣜򰩮񋏊񦁙𯵩 175
2021/11/28 17:55:36 󖕎􈾌񢘘򃇂𯎊񐲂㻊󎅰󾀢􈸲􋁜恒򏡎򭣪񃨓𛦦󟌻񂺢ᢇ󹾍Ⅻ񭉳󻀯𑖬􆀷𧶲𪱺򬳼𒨱򐓙󶬺󘂴󉁣򼅬񵗎󮿼񦀘򉢽 148
2021/11/28 17:55:36 ꎓ򐎾򴘁񚝌󘨌񡭒񝠦񦵄󙬷𲝢󛨒񋹧𶵔𐪺򝪲𯱐񆚵񓄕𦈠򡳝󞳁𧉜󚔞󯺍𩾱󶟏񂃣𭖸򸂗𭷶󘗲󨂎󠠋󛶞 135
2021/11/28 17:55:36 򝹵񝳡󀯻񮩵𫔗󯼶񚡸񷎓况󡜘𸗟󝔸񗬿񢘥񳜖򯗲򠾠򙵮򷉾񊥋񰄼𭞒ᯡ󒈁 95
2021/11/28 17:55:36 񥏲𿾾𪅿󲝀󟥒􉢫𭠘񟾕󽥸話񄆛󜲚󤱷򰋚𒢙򯉆󆸪㫖󑳸𑬩𺶽񘁉巢㲶 93
2021/11/28 17:55:36 򈦄񻸙񘥇񀧲󜊷󷒹󼲧 28
2021/11/28 17:55:36 򇐦򎑴𒼸񟱬򛠂򟖒𧔙𧰺򿲴 36
2021/11/28 17:55:36 󂟅󎘕𬟈󆗡𾨴񮿀򂁼򙬖򌪬󂯑򇜇򀿸񎸩򡁇򿑌󡤋񽤽򧦥𵻧󗜑򩰷𐳤 91
PASS
ok      tctest  0.002s

En apariencia todo quedó perfecto, las pruebas pasan con valores predecibles y aleatorios. Pero hay un problema por resolver, nuestra función Mask debería procesar tarjetas de crédito y devolverlas en un formato donde aparecen los primeros 4 dititos, seguidos de 8 X y finalizando con los últimos 4 digitos.

Para esto podemos valernos de una expresión regular para asegurarnos que nuestros datos se entregan en el formato correcto.

var (
    validMask = regexp.MustCompile(`^\d{4}[X]{8}\d{4}$`)
)

Aplicamos la validación a nuestra primera prueba:

t.Run("success", func(t *testing.T) {
    res, err := Mask("1234567890123456")

    if err != nil {
        t.Log("err shuold be nil")
        t.Fail()
    }

    if len(res) != 16 {
        t.Log("len should be 16")
        t.Fail()
    }

    if res != "1234XXXXXXXX3456" {
        t.Log("wrong output")
        t.Fail()
    }

    if !validMask.MatchString(res) {
        t.Log("res does not pass the regular expression")
        t.Fail()
    }
})

Comprobando que el resultado esperado cumpla con la expresión regular, de caso contrario la prueba deberá fallar.

Dentro de la función f validamos la expresión regular de la siguiente manera:

f := func(card string) bool {
    res, err := Mask(card)

    if err != nil {
        return len(res) == 0
    }

    expectedLen := len(res) == 16
    passRegex := validMask.MatchString(res)

    return expectedLen && passRegex
}

Al ejecutar las pruebas vemos el siguiente error:

2021/11/28 18:25:05 1234567890123456 16
2021/11/28 18:25:05 𻳩򱕽񘥁񥗠󠆉󧭲󊒢󁩍񆾜󐰢󒈛峓󤴦󬗻䤥򟻾󛸡񮜒󩕚󡹆򨠋򠤨󽨓􊧤񜦆򔶚󼄦󙌉𒭝 114
2021/11/28 18:25:05 񏡽񞺋󘗗􊍮򝾮񳢃󠩊󙘗󕱞򌗉󆦿򜳇󓑹򹇖񳮸₍𾚩􂫫󹷵򹇳񫱭򉑤󰽜󦔬𴪭򃾡𧢻򁳲𲁮􊁐񅉮񣼉󞶆󦫉󛈧򲐴 143
2021/11/28 18:25:05 𢹊𭟆򷣁񚙯󝦰􊞕󝎧񝁇򥗂񝯢򒢮򙙺󄔉񫰫󉻜󳯙񾜜񠴯񈼰񉮗񿻣򲛩𸶊񍖎񴩰󰿢񆝒禧󦿩󁇱򣹮񏯘􈆗󆚕󂇏򳟴򫒧񂒒򏂅񄛛䔅 162
2021/11/28 18:25:05 󔌜󞱪𯉝򏪮󯰃􋾤뱯󣛤󇆡𿢘ꕗ󺡼򗫹𻗜񼏜񧂹񢸔󒸈񇶐򩂓󵑄񚱤򬫭𤲛踇𙉹񎒌󬫱񺽒𕊡󟑲󫄼󹟕񺎬񓎵񍥔򝻾󧗨󆪚󞶩򎰤󌫪 165
2021/11/28 18:25:05 񧆜󤁭𱛒󅩞莩𳆦񁫚񮾁󌲽򗪘󱳉󳒒𴸽𗭨򏺮򫎘󯿄𐓨򷬭𕅿􈀲𑀣꭭좉𔣴𬕰󫎧񬷱򇦗򾊘񊫶򻅏񇖂򃉆񞏤񇘅 141
2021/11/28 18:25:05 􈁢򪄹񪋈𭎯񪥐𤌢𘶾񰫔︁򷅴 39
2021/11/28 18:25:05 񄌊㗎􊵥󸕞񲪃󓼷񛐇󔠑񟪵𨯈񑼫񯚯񮎑򴲓򾸮󭶘񨉘󫩊𤘚𥒛󒀗𤇝񫃢񗦑𬺧򘗜𽾿𼘎𐵵񠀠񒠛򋨺򲴸󖨒􋰴򂐳򬨭񯗵񿡱􍅌񋍪𔈾𗝮񯸀󏮆򲊂𻮓 187
2021/11/28 18:25:05 򞽩򿇯𬓋􀗽 16
--- FAIL: TestMask (0.00s)
    --- FAIL: TestMask/random_cards (0.00s)
        mask_test.go:49: #8: failed on input "\U0009ef69\U000bf1ef𬓋\U001005fd"
FAIL
exit status 1
FAIL    tctest  0.002s
go exited with status code 1

Vemos que la función de valores aleatorios se ejecutó varias veces. Las primeras veces se enviaron cadenas de texto cuya longitud no es 16, por lo tanto caen dentro de la validación de la longitud del input. Sin embargo vemos que la prueba fallida manda un texto de 16 caracteres:

2021/11/28 18:25:05 򞽩򿇯𬓋􀗽 16

El cual hace que la prueba falle ya que el resultado no cumple con nuestra expresión regular.

Para solucionar esto debemos implementar la expresión regular dentro de nuestra función:

func Mask(card string) (string, error) {
    log.Println(card, len(card))

    if len(card) != 16 {
        return "", errors.New("card length should be 16")
    }

    start := card[0:4]
    between := strings.Repeat("X", 8)
    end := card[12:]
    res := fmt.Sprintf("%s%s%s", start, between, end)


    if !validMask.MatchString(res) {
        return "", errors.New("card no regex")
    }

    return res, nil
}

En caso de que la validación de nuestra expresión regular falle vamos a retornar una cadena de texto vacía y un error.

if !validMask.MatchString(res) {
    return "", errors.New("card no regex")
}

Volvemos a ejecutar las pruebas y vemos que en esta ocasión todas nuestras pruebas pasan:

2021/11/28 18:32:18 򢧊▿򠰾񻐔򭇿򑶎󋺟󼈱 31
2021/11/28 18:32:18 󔄴򾀈񛐹󦟴󈖀󮪞𔿪񍇜񮙁𧕚𬢢򄾝񪡼󗜰 56
2021/11/28 18:32:18 񒧹񹳆񢆊򣀥򝅞󇏬򶆴򀕗􊅇񝟄󁆬󑪣񰛋𞚭󃈜 60
2021/11/28 18:32:18 󿕏򂻛󉫩󔽂򂲰䰸󺂵򖜲𾀵򡫒󺕾𵇠񸭶򼮖뚴󕎇񲼖󢀕󯻝􄤳񢏢񨢣俷𚙛񪾝񿘝𡈨򃪂𼸊󤄸򝽗㥺󩁨𬊴򺡽򲥈 140
2021/11/28 18:32:18 𼥸򜶿䰑𽎟񧈶򢝤󽽔󈓚򼒓󲅬򋆠򞟡釼󺽳󋐺𻈚򖛤𔓶򭭘󴰓񴊇𸊮򯗪𬁏񣶗򳞈􎵏𒦥胦񤹮򄌪󅘾񡁐򠎪򺨢񤅛񖲡򪢂󰳢󃰋񻻻 161
2021/11/28 18:32:18  0
2021/11/28 18:32:18 򷬅󂦕򀝰𯸖񼓐򰒶􊭥񦸘򙱠󂑦𮩗񄑦󚶌𚋁ᄴ򞝕󠊟𡼆 71
2021/11/28 18:32:18 񬱛󊛻𝙦񶘢򹲐򚀕𽟷𐘃􂒚𽷻񊈦󟢯񌌅򦫨򾼺򿾏񻈆󟶼񒬶񢊮𰞰𖓞𑘞󆽕񾨈񞇺򙖎񏈝񖼺񭇷 120
2021/11/28 18:32:18 󢬪𨋰󵪥􋤚󵂮򯔸򠟜󘓉􄳪򠟗񼰗󴤢􌳖򒟸񙮯񥯮򺉊󾭻󩻮򥲔򚑙򆸥񅒾򭭱󔷽󐚡򁭁𐊒󰇕𚓱򉕻򜻜𶀿񓘪򰒟򷆐􀸼񾉕 155
2021/11/28 18:32:18 􈤈񞈫󜼜󛛠򉖎뷆󝽻򍽀󮿢戝🧑򽷓󽸃𢹓󇜫񷨮򱦐𢴡 70
2021/11/28 18:32:18 󦔸򗯝򺌕񢏠򸍌󐯚򶦬񱄠񺭗񭟐񾟽񪄷񕧋󻴀󃊈񎺑󤅉򈊬򠳸􃨪󾲎񪼢𽖭񭿫𨳌괏󜢧󁗬󿏏󻧟 119
2021/11/28 18:32:18 󲯠𝹫󙹘򣉰񽇿𳛽򏀴 28
2021/11/28 18:32:18 􁠒󙟄󪪿񁣻𵒹񬴋󥨺򯉭𗮴񯪳񾸮񀬭򗤒󸸘󜟫𠿈򰅣
PASS
ok      tctest  0.006s

De esta manera podemos valernos de herramientas de pruebas de caja negra para poder comprobar los caos de uso de nuestras funciones. Y así poder evitar posibles bugs que podemos omitir por seguir el Happy Path de nuestra aplicación.

Pueden consultar el código guente del ejemplo en el siguiente enlace de Github.