Forem: Tomas Francisco Lingotti

Entrevistas en IT

Tomas Francisco Lingotti — Mon, 29 May 2023 00:03:13 +0000

Vamos a repasar los aspectos mas relevantes de un proceso de entrevistas en una compañía de IT. Desde el primer contacto hasta la resolución de ejercicios técnicos en vivo, algo que muchos desarrolladores están en contra, ya sea porque se aleja muchísimo de lo que es un trabajo o porque lo que hay que hacer en el día a día no tiene nada que ver con ese ejercicio que su respuesta esta replicada mil veces en internet. Incluso ChatGPT puede resolverlo en menos de 5 minutos.

Pero por otra parte, desde el punto de vista del entrevistador, puede ver nuestra manera de pensar, de comunicarnos, como reaccionamos ante determinada situación y como trabaja nuestra cabeza cuando tiene un problema en frente y si o si hay que resolverlo. O al menos intentarlo.

Comenzamos con algunos pasos:

Contacto

LinkedIn y referidos. No creo que mandando CV al mail de la página de careers sea una buena opción.
Agregar RRHH de esas empresas y tener el perfil lo mas atractivo posible (hay mucha info sobre eso). Mi único consejo es investigar sobre la empresa, lenguajes y tecnologías que usa y ver si mi perfil está alineado. Tener paciencia va a ayudar mucho.
Referidos: bueno, si ya tengo conocidos ahí dentro, pedir que deje nuestro CV por algún programa interno. En caso que no haya, directo a RRHH.

Etapas de la entrevista

Suelen ser varios pasos, incluso mas de uno para validar lo mismo. El primer screening es 100% cultural y repasar el CV, muchas veces es un trámite [ver apartado de QUE NO HACER].

En este punto podemos preguntarle a nuestro contacto como van a ser las siguientes etapas, eso nos ayuda a prepararnos mejor.

La temida "técnica"

Las entrevistas técnicas son todo un reto, pueden dividirse de varias formas, las mas comunes suelen ser primero un ping pong de preguntas y 45 minutos con algún ejercicio de programación en vivo o un diseño a alto nivel de una big tech, por ej Uber/Twitter/YouTube/gateway de pago. No se espera que sea un detalle exacto ni mucho menos, pero si lo actores principales, como escalar, modelos de datos correctos, separación de intereses y demás. Hay material sobre diseño en entrevistas, pero NADA supera la experiencia.
Los ejercicios de desarrollo, son los que vemos en HackerRank, Leetcode y similares. Muchas veces son textual extraídos de esos sitios. Esa práctica es clave para el una resolución rápida y efectiva. Muchas veces, no buscan que el algoritmo resuelva el 100% de los casos o que este optimizado. Pero si de buscar la mejor complejidad temporal (Big O) y que cumpla al menos los test cases de ejemplo.
- Duración: Largas, entre 1 y 2 horas seguro. Mantener agenda limpia esa mañana o tarde.

Estudiar/Prepararse

Conocer bien su CV, tecnologías que manejan, proyectos trabajados, challenges resueltos, como manejar ciertas situaciones, por ejemplo, no cumplir un deadline, un compañero “rompe” el CI el viernes a las 17.50, y cosas parecidas. Repasar experiencias y armar una buena narrativa ayuda y mucho.
Algoritmos y estructuras de datos. Practicar mucho, leer códigos con soluciones. Fundamental vero soluciones reales, en GitHub hay infinidad de snippets en todos los lenguajes y con muchos enfoques. Cuando nos trabamos con algo, tenemos que buscar la solución. No dedicar mas de 1 hora en un problema. Pasado este tiempo, vamos a ver como otros lo resolvieron y re-pensar nuestros errores.

Que no hacer

Llegar tarde 🕚, siempre calcular al menos 10 min de margen. Tener mic y cámara listos.
Hablar “mal” de una compañía pasada.
No estar dispuesto a escuchar o recibir feedback, esto incluso podemos no darnos cuenta, pero los entrevistadores tienen herramientas para detectar estas actitudes y es un NO FIT cultural seguro. Un ejemplo es no dejar hablar al entrevistador.
No saber a que se dedica la empresa a la que estamos aplicando. Una mínima investigación es necesaria.
No hacer preguntas. Capaz sea un punto intermedio, pero siempre hacer preguntas sobre la posición a ocupar, metodologías, como están compuestos los equipos, nos va a dar mucho mejor panorama a la hora de decidir. No estoy realmente seguro de que influya negativamente en la entrevista, pero si nos brinda mas información a nosotros.

Conclusiones

Salir bien en las entrevistas es un skill en si mismo, antes de aplicar al trabajo de nuestros sueños, tenemos que estar preparados y saber que nunca nos vamos a sentir seguros por completo, pero eso no nos tiene que impedir tener mucha confianza en nosotros mismos y encarar los procesos. Asi que a prepararse y ser pacientes que tarde o temprano, nuestra oportunidad va a aparecer.

El día de la entrevista, hay que mantenerse tranquilo y repasar mentalmente lo que vamos a decir, ya sea en nuestro idioma o en inglés.

HTTP y sus formas de comunicarse

Tomas Francisco Lingotti — Fri, 26 May 2023 18:13:36 +0000

Esta entrega va a estar dedicada a tecnologías y no implementaciones, pero aclaro que todos los métodos mencionados son capaces de ser usados con la gran mayoría de los lenguajes.

La idea principal es presentar todos las formas de comunicación sobre HTTP usadas hasta ahora y compararlas en sus aristas mas importantes.

Qué son y para qué los necesitamos?

Primero, tenemos que explicar brevemente que es HTTP(S). Por su siglas, es Hyper Text Transfer Protocol, la S es de Secure cuando los datos viajan cifrados.

Las paginas de internet se basan en este protocolo para mostrar los archivos que el navegador web interprete, por ejemplo, HTML, CSS, JavaScript, imágenes, PDF y un largo etcétera. Es decir, alguien pregunta usando una URL y un puerto (80 para http y 443/8443 para https) y un server nos devuelve los archivos que el cliente sabe interpretar.

Hasta acá, bastante fácil, de hecho es una arquitectura cliente-servidor estándar. Pero sabemos muy bien (y sino, lo aprendemos ahora) que los sistemas ya un poco mas grandes que una página estática, tenemos que armarnos de varias instancias, servicios web, comunicaciones asíncronas, real-time (near real time) y quien sabe cuantas cosas mas, que a veces no necesitamos, pero las usamos igual.

Ejemplo que si usamos todos, un chat, no podemos hacer la arquitectura normal que vimos en http, porque sería muy lento, además, no podríamos usar otras features como por ejemplo,si nuestro amigo está escribiendo, no seriamos capaces de ver que lo está haciendo si usamos la arquitectura descripta anteriormente.

Es por eso, que vamos a necesitar de mas y naturalmente diversas tecnologías para responder todas las demandas.

Vamos a ver:

gRPC (desarrollado por Google)
REST (representar recursos y estados [JSON])
Webosckets (canal de ida y vuelta)
GraphQL (alternativa interesante para escalar)

gRPC 🎯

Desarrollado por Google, pero open source, es un framework tipo plus and play, multiplataforma para comunicación de servicios. Es independiente al lenguaje base de programación y ofrece una serie de ventajas claras en casos de uso específicos, donde es casi siempre la mejor opción y no tiene rival. Las que mas se destacan son su eficiencia, la posibilidad de documentar con código (real) y versionar los modelos, uso de http v2, plugins de autenticación, métricas, checks de salud de las comunicaciones, load balancing y tracing.

que necesito y como funciona?

Dos cosas son claves, los protocol buffers (protobuf) que son el mecanismo de serialización - lo podemos comparar con los JSON de REST- y es 100% neutral a las plataformas, sistemas operativos y lenguajes y el compilador protobuf.

Así se define uno simple, la definición de un "objeto" Persona

message Person {
  optional string name = 1;
  optional int32 id = 2;
  optional string email = 3;
}

No solo definir estructuras, también interfaces con métodos, o sea el comportamiento que deseamos para nuestro servicio.

// The greeter service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

Esta definición va a ir en un archivo .proto.
Un buen lugar donde ver todo sobre protocol buffers es su sitio oficial y usar la version 3 (al menos a la fecha de publicación de este humilde artículo).

Ahora bien, dijimos que necesitábamos el compilador protobuf y el plugin gRPC para poder generar el código que soporte nuestros archivos proto (al menos en Go).

Para ejecutar el compilador, vamos a correr algo asi:

protoc --go_out=. --go_opt=paths=source_relative \
    --go-grpc_out=. --go-grpc_opt=paths=source_relative \
    proto/{nuestro_archivo}.proto

El resultado van a ser archivos .go que tienen toda la operatoria definida previamente.

Ventajas 👍

La principal, su rendimiento. El (des)serializado (cuando transformamos nuestro objeto Java por ej. para que viaje por la red, eso es serializar y la inversa es para leerlo cuando llega y convertimos los bytes a un objeto).
Usar http2 y su tecnología superior (multiplexación de canales, tasas de transmisión mas altas, etc)
Posibilidad de tunear los servicios de acuerdo a las necesidades:
- Sin streaming
- Streaming unario del servidor al cliente
- Streaming unario del cliente al servidor
- Streaming bidireccional

Esto corresponde al ciclo de vida de una request/response en http2 y gRPC, sugiero leer esta documentación para entenderlo mejor.

Última ventaja, es poder ser API-first y documentar los contratos, versiones y demás con el tooling de gRPC. Ademas, poder usar versiones viejas de las APIs sin mucho esfuerzo.

Desventajas 👎

Difícil de probar, básicamente traban en par cliente-servidor, por lo que ir a Postman o cURL no es una opción muy viable.
El código generado no es legible o entendible por nosotros.
Se requiere una nueva tecnología y dominarla puede llevar tiempo y errores.

REST 🎯

Es largamente usado en la industria y seguramente lo siga siendo. Es la primera opción a considerar a la hora de comunicar cliente y servidor.
En esta entrega, vamos a basar a REST con sus mensajes en JSON.

qué es y como funciona?

Ahora bien, que es REST, por sus siglas, REpresentational State Transfer. Quiere decir que vamos a presentar recursos y manipularlos a través de estados. Vamos a crear una interfaz uniforme, que sea fácil de entender y extender conforme nuestro servicio crezca en funcionalidades.

Esta interfaz se basa en reglas generales que no cambian en el servicio, esto hace que su comportamiento sea determinista tanto para los usuarios como para los desarrolladores. Algunos lineamientos aceptados son:
(cabe destacar que estos, como todo, tienen opiniones a favor y en contra. La clave es elegir uno y no cambiarlo).

Nombres de los recursos en plural para las URLs. Por ejemplo /users.
Todos los recursos deben ser únicos en su nomenclatura.
Usar los verbos HTTP para determinadas acciones. POST para crear, GET para leer, PUT para actualizaciones completas y PATCH para parciales. DELETE, claramente, para borrar.

En rest, decimos que un recurso es un conjunto de datos a los cuales le puedo aplicar algunos de los comportamientos mencionados anteriormente, usando URLs y los verbos. No es lo mismo un GET a /users que un POST.

Una feature que comparte REST y HTTP es que las respuestas se pueden cachear. Interesante punto para la performance.

Otros temas importantes son la idempotencia, el no-estado (conocido por stateless en inglés) y el tipo de contenido (header de content-type). Obvio que la seguridad, tokens y demás son otros puntos mas que interesantes, pero al haber tantas alternativas, es preferible dejarlo para otra entrega.

Idempotencia es una característica propia de los VERBOS, no de los recursos o de las URLs. Quiere decir que una acción (URL + verbo) puede repetirse N veces sin que tenga efectos en los recursos y obtener el mismo resultado una y otra vez. Por ejemplo si ejecuto DELETE /users/1, la primera vez, borro sin problemas, la segunda, no voy a borrar nada pero tampoco debería tener un error de vuelta, ya que ese ID ya fue borrado. Por eso decimos que DELETE si es idempotente.

Esto tenemos que tenerlo claro a la hora de programar.

En cambio, POST, no lo es, por que si enviamos 2 veces el mismo usuario, es natural que si obtengamos un error, porque no podemos tener 2 usuarios distintos con el mismo mail. Por eso POST no lo es.

STATELESS es una de las propiedades principales de REST, quiere decir que cada petición es totalmente autocontenida y no necesita información de su antecesora. Aunque no es 100% verdad (al menos para mi) porque en APIs que requieran estar autenticado, si tenemos que hacer una antes pera validar credenciales. Pero bueno podemos discutirlo en otro momento.

JSON JavaScript object notation, tal como en gRPC la comunicación era por binarios que eran el resultado de los archivos proto en REST vemos que JSON es el de facto para la industria. Los cuerpos de las peticiones tienen que tener un JSON válido para que pueda ser leído. Esto da mucha flexibilidad porque cualquier API puede leer mensajes de básicamente, cualquier cliente, siempre y cuando respete el contrato JSON acordado sumado a las mencionadas URL y verbo HTTP. Con este "triplete" tenemos ya toda la información necesaria para si sellar nuestro contrato y poder documentarlo. Para el estándar, esta OpenAPI para seguir como ejemplo.

Por último en REST, otras cosas a tener en cuenta, repasar y documentar.

Filtros
Paginación
Los recursos debería tener los links asociados para operar en él

Ventajas 👍

Cacheable
Fácil de implementar y nativo de todos los lenguajes, ya que se basa en HTTP, entonces, no necesitamos nada mas.
Ningún cliente de las APIs se va a quejar por usar REST con JSON.
Para probar, tampoco necesitamos nada, un Postman, cURL, un browser, cualquiera es válido.
Por lo general, front y back separados.
Es un FIT muy bueno para la gran mayoría de las apps data driven.

Desventajas 👎

Es difícil aplicarlo de forma "pura" en todo el proyecto. Si el servicio escala conforme pasa el tiempo, muchas veces tenemos casos de uso que no cumple con las especificaciones de REST, entonces tenemos que ir adoptando excepciones y licencias para cosas nuevas y puede terminar mal.
La documentación suele ser un dolor de cabeza importante.
Su performance no es óptima.

Websockets 🎯

Es una tecnología que permite la comunicación ida y vuelta en una sesión interactiva entre el cliente y el servidor.

Se basa en una serie de mensajes que esta API entiende, por ejemplo si enviamos solo texto (lo único que podemos enviar y que leer), un mensaje de cierre de conexión, apertura, ping para mantener la sesión abierta y alguno mas seguro debe haber, pero no los usé, ya sabiendo esos van a estar mas que bien.

Para usar en cualquier lenguaje de backend, vamos a necesitar alguna librería, ya que una implementación propia puede resultar costosa en términos de tiempo y traer algunos bugs difíciles de corregir, por eso recomiendo buscar alguna ya probada ahí afuera.

Tiene muchos casos de uso, al ser tan rápido (solo enviá pocos tipos de eventos) y bidireccional, muchos chats están implementados con websockets. Tenemos otros para enumerar.

Suscripción a tickets de la bolsa/criptomonedas (recibir el precio actualizado en forma de "feed").
Juegos multi jugador donde necesitamos muchos datos al mismo tiempo y con baja latencia.
Transmitir coordenadas en near-real-time.
Herramientas colaborativas (estilo google docs)
etc

Hay que tener en cuenta que algunos navegadores no soportan websockets, ni todas las implementaciones son iguales. Acá hay una buena docu de referencia.

Ventajas 👍

Velocidad de transmisión.
Facilidad para implementarlo.
Amplio soporte y herramientas.

Desventajas 👎

A veces no es tan trivial el debug, aunque Postman ya incluye request WS.
Los "internals" son complejos, ademas de que dependemos de librerías en el 99% de los casos.
No son persistentes, tampoco hay servicios cloud que provean algo así. Cierro el navegador y se cierra el websocket.

GraphQL 🎯

Que es?

Muy complicado responder, es varias cosas! Un framework para manipulación de datos, un motor de queries hasta incluso un lenguaje (exagerando un poco). Sabemos también que es opensource y desarrollado (al principio) por Meta. Para mi, lo podemos definir como una especificación para APIs.

Es una alternativa a REST, no veo como una evolución natural donde lo que tenemos en REST lo podemos llevar a GQL, ni al revés, hay que pensarlo así desde el principio o en el peor de los casos, reescribir los servicios.

La clave es que el cliente, con la query correcta, puede obtener los datos que necesita y nada mas, es decir, si tenemos un usuario en nuestro modelo que tiene 15 campos, podemos traer cualquier combinación de ellos, al contrario de REST, que el recurso viaja como una unidad, ya que desarrollar algo similar llevaría muchísimo trabajo.

Gran ventaja es la manipulación de datos tan granular que ofrece y con un esfuerzo dentro de todo bajo si ya venciste la curva de aprendizaje.

Otra ventaja es que es independiente a la fuente de datos, puede ser MySQL, mongo, etc, aunque esas conexiones queda para que nosotros las hagamos, no es plug-and-play ni mucho menos.

Pasos a seguir

Primero tenemos que definir un esquema (schema) donde describimos nuestro modelo. Al ser tipado, tenemos que declarar todos los tipos, nos queda de este estilo:

type User {
  id: ID
  name: String
}

type Project {
  name: String
  tagline: String
  contributors: [User]
}

Al definir las queries:

type Query {
  getProjects: [Project]
  getUsers: [User]
}

Y desde el cliente deberían enviar algo así:

{
 project {
   name
   tagline
 }
}

Y el resultado esperado en JSON:

{
 "data": {
   "project": [
       {
         "name": "Apollo 11"
       },
       {
         "name": "Mars-Rover"
       },
       {
         "name": "Challenger 1"
       }
     ]
 }
}

Todo el framework viene con un tooling importante. No en todos los lenguajes es igual, algunos tienen generadores de código o corren una UI para realizar las consultas GQL de forma muy sencilla.
El detrás de escena es el mismo, el motor funciona igual, las conexiones con las fuentes de datos también.

Ventajas 👍

Reducir drásticamente el numero de URLs, vamos a tener muchas menos (menos lineas == menos para mantener).
Escalabilidad garantizada.
Como los .proto, la documentación es mucho mas natural y versionada.
Reutilización de tipos de datos en los schemas.

Desventajas 👎

Curva de aprendizaje
No podemos hacer cache de respuestas, en REST si.
Mantener el schema de GQL puede no ser trivial para desarrolladores sin experiencia con el framework.

Bueno, hasta acá mi análisis, espero que les haya gustado, los espero en YouTube, Twitch y Discord!

PS: Comenten algún tema en particular si quieren que investigue y escriba!

Concurrencia en Go V

Tomas Francisco Lingotti — Wed, 10 May 2023 17:01:26 +0000

|1. | Modelo de concurrencia
|2. | Goroutines y canales
|3. | Wait Groups
|4. | Select y Worker pools
|5. | ErrGroup (error groups)

Primero, muchas gracias por leer la última entrega de concurrencia en Golang, en el índice encontrás todos los links para navegar entre los distintos posteos.

Que son los error groups?

Sabemos como son los errores en Go y que una parte importante es el famoso (para bien y mal en partes iguales) if err != nil {} entonces, si ejecutamos, básicamente, cualquier cosa que devuelva un error lo vamos a tener que manejar, aunque en un ambiente de múltiples goroutines nos surjen otras preguntas.

Que pasa si hay un error en una rutina? las siguientes deberían correr o no?
Supongamos que si corren, como recolecto los errores? un slice o map puede generar panic si se accede de forma concurrente.

Pueden ser más también dependiendo el contexto.

La verdad es que esas 2 preguntas, no van a tener una solución nativa, solo workarounds, pero ahi es donde llega error groups.
El paquete es de de Go, pero de los que tienen X, quiere decir que no es del core, sino que es eXternal. Lo encuentrar aca:

import "golang.org/x/sync/errgroup"

Una vez importado y ya declarado en nuestro go.mod, podemos inicializarlo de dos formas

ctx, _ := context.WithTimeout(context.Background(), 300*time.Millisecond)
g, ctx := errgroup.WithContext(ctx)

Para usar un contexto cancelable en X tiempo.

O sino, directamente la estructura (o su dirección de memoria)

eg := &errgroup.Group{}

Ahora, solo tenemos que identificar el trabajo que queremos realizar de forma concurrente y luego lanzar las rutinas, pero ahora, a través de los error groups.

Suponiendo que tengo unos documentos que quiero enviar a un servicio externo para que sean procesados.

docs, err := service.GetDocs()

for doc, _ := range docs {
  // 'g' declarado antes
  g.Go(func() error {
    result, err := service.ProcessDoc(doc)

    return nil
  })
}

Vemos que la forma de lanzar la rutina es diferente y ya no usamos la palabra reservada 'go'.
Como argumento, tiene una closure que devuelve un error, ahi es donde podemos manejarlo como mas nos convenga, sin la necesidad de tener que ornamentar nuestro código.

Ahora bien, tenemos que hacer algo con los resultados, sino lo perdemos; el alcance (o scope) de la función hace que no podamos accederlo desde "afuera" de la rutina.

La solución obvia es usar canales, que ya los estudiamos en nuestra lista. Para que sea "thread safe", vamos a usar otro método de los errorgroups. Pasamos al código.

resChan := make(chan DocResult)
docs, err := service.GetDocs()

for doc, _ := range docs {
  // 'g' declarado antes
  g.Go(func() error {
    result, err := service.ProcessDoc(doc)

    if err != nil {
      return err
    }
  resChan <- result
  return nil
  })
}

go func() {
  if err := g.Wait(); err != nil { // devuelve el primer err != nil
    // handle err
}

  close(resChan) // cerramos el canal
}()

El método Wait() va a esperar que todas las funciones que llamemos con g.Go() terminen. En caso de que ninguna tenga errores, siempre va a devolver nil, sino el que tengamos en nuestro servicio.

No olviden cerrar el canal una vez que no vamos a escribir mas en él, para evitar memory leaks.

Como nota, aca no lo repasamos, pero el contexto al ser carrier de una cancelación subyacente, podemos manejarlo también con un select para que, si desde algún lado lo dan de baja, no sigamos procesando.

Conclusiones

Vemos que es mas sencillo y natural (por así decirlo) manejar rutinas y errores con errGroup. Si bien no tiene todo resuelto en su propio mecanismo, es de fácil acople con otras soluciones como canales, select y demás para que tengamos a disposición todo su potencial. Es muy útil para pipelines o flujos mas complejos, fácil de leer y hacer debug.

Podemos encontrar muchas similitudes con los wait groups y está muy bien, ya que si son parecidos en su objetivo y semántica. Los casos de uso, por el contrario, podemos diferenciarlos y ahi tener mas herramientas a la hora de elegir una solución.

Espero que les guste y lo puedan usar en sus próximos proyectos.

Concurrencia en Golang IV

Tomas Francisco Lingotti — Thu, 27 Apr 2023 01:55:31 +0000

|1. | Modelo de concurrencia
|2. | Goroutines y canales
|3. | Wait Groups
|4. | Select y Worker pools
|5. | ErrGroup (error groups)

Para qué sirve select en Go?

Bueno llegamos a la cuarta entrega, en este caso vamos a esar hablando de la palabra reservada select y una pequeña implementación en un worker pool (vamos a explicar que es un worker pool).

Select es un bloque, tiene su sintaxis y su scope comprende todo lo que se ocupa dentro de sus llaves. Su función es el de poner en espera (o wait) a múltiples comunicacions a la goroutine que se está ejecutando, se va a liberar cuando se cumpla alguna de las condiciones que planteamos dentro de nuestro bloque. En otras palabras, en parte de nuestro código que podemos recibir mas de una rutina, es dónde vamos a usar el select.
La sintaxis básica es:

//...
select {
   //...
}

Nota importate: El select bloquea la rutina que lo contiene, muchas veces vamos a ver que nuevas goroutines lanzan un select, tengan esto muy en cuenta y hagan las pruebas necesarias para saber que no van a bloquear la rutina principal.
Nota importante II: No usen select vacios.

Ahora para agregarle algo interesante a nuestro select, dentro del bloque vamos a estar esperando por mensajes que lleguen a los canales que invoquemos. Funciona parecido a la cláusula switch, pero la condición es quien reciba el mensaje, no hace ningún tipo de pattern matching.

Vamos a una impl real

c1 := make(chan string)
c2 := make(chan string)

// enviamos el primer mensaje.
go func() {
    time.Sleep(1 * time.Second)
    c1 <- "one"
}()
// enviamos el primer mensaje.
go func() {
    time.Sleep(2 * time.Second)
    c2 <- "two"
}()
// con este select esperamos dos veces, uno por cada
// canal. Otra práctica común es tener un for infinito
// en una rutina separada para asi no bloquear a la
// principal.
for i := 0; i < 2; i++ {
    select {
    case msg1 := <-c1:
        fmt.Println("received", msg1)
    case msg2 := <-c2:
        fmt.Println("received", msg2)
    }
}

Aca vemos como en cada case, esperamos leer un mensaje de cada canal. Una vez que ocurra, vamos a salir del bloque.

Ahora, otro ejemplo que nos sirve como un daemon en nuestro servicio, que corra cada X tiempo y eternamente mientras la app este en ejecución.

import "time"
//
//
go func() {
        ticker := time.NewTicker(1 * time.Hour)
        for {
            select {
                case <-ticker.C:
                    //doSomething()
            }
        }
    }()

Este código nos asegura que cada una hora vamos a invocar a lo que nosotros le indiquemos. El ticker es un countdown que nos provee el paquete time, muy útil para estos casos.

Resumen del select

Bloquea a la rutina que lo esta ejecutando.
Cuando entra en un case, va a anular a los otros hasta que vuelva a ejecutarse el select (por eso es tan comun verlo en un for{} infinito).
Suelen ir dentro de una función anónima lanzada en una goroutine.

Worker pools, que son?

sabemos que un pool es una reserva, en este caso de workers. Ahora en nuestro código tenemos que identificar 3 cosas claras. 1) El pool 2) El worker y 3) El trabajo a realizar.
El objetivo va a ser que podamos procesar trabajo de forma concurrente, los worker que terminan su trabajo, van de nuevo al pool y así tratar de ahorrar recursos, además de tratar de trabajar más eficientemente.

Vamos a un poco de go.

type Unit interface {
    Job() error
}

Definimos lo que va a ser nuestra unidad de trabajo. Podríamos crear otras interfaces más y hacerlo mas polimórfico. No nos preocupemos por quien lo implementa, sera trabajo del cliente.

var jobQueue chan Unit // cola de trabajo compartida

type worker struct {
    pool  chan chan Unit
    jobCh chan Unit
}

func newWorker(pool chan chan Unit) *worker {
    return &worker{
        jobCh: make(chan Unit),
        pool:  pool,
    }
}

Acá ya tenemos un worker que va a pertener a un pool y escuchar a un canal de unidades de trabajo. El doble channel para el pool es para el registro y otro para activarlo.
La otra función, simplemete actua de constructor.

type pool struct {
    pool    chan chan Unit
    workers int
}

func NewPool(maxWorkers int) *pool {
    return &pool{
        pool:    make(chan chan Unit, maxWorkers),
        workers: maxWorkers,
    }
}

Ahora tenemos la struct de pool, que contiene el mismo canal que el worker y cuantos workers queremos crear, acompañado de su constructor.

Tenemos el esqueleto, ahora pasamos a la acción con los métodos.

func (d *pool) Run() {
    for i := 0; i < d.workers; i++ {
        w := newWorker(d.pool)
        w.start()
    }

    go d.dispatch()
}

Ya se ve algo interesante, por cada worker en que indicamos, vamos a crear uno, asignale el pool que ya teníamos y arrancarlo, veamos de que se trata.

func (w *worker) start() {
    go func() {
        for {
        // register the actual worker in the queue.
            w.pool <- w.jobCh
            select {
            case job := <-w.jobCh:
                // do the actual job here
                err := job.Job()

                if err != nil {
                    log.Println(err.Error())
                }
            }
        }
    }()
}

Para el método start, vamos a registrar el worker y luego con la cláusula select, vamos a esperar a que llegue un trabajo y realizarlo (sin saber que es, pero no nos importa). Todo esto en una nueva rutina por worker.

func (d *pool) dispatch() {
    go func() {
        for {
            select {
            case job, ok := <-jobQueue:
                if ok {
                    jobChannel := <-d.pool
                    jobChannel <- job
                }
            }
        }
    }()
}

Por último, el dispatcher que va a distribuir la carga de trabajo, cada vez que de la jobQueue, se toma uno disponible del pool y a ese worker (implícito en el job channel) se le asigna el trabajo. La job queue es un recurso compartido.

Código en el cliente

func main() {
    // init the shared data structure.
    splanner.InitQueue(20)

    // init the dispatcher & keep it listening.
    splanner.NewPool(15).Run()

    s := http.Server{}
    s.Addr = ":8080"
    http.HandleFunc("/jobs", JobHandler)
    log.Fatal(s.ListenAndServe())
}

func JobHandler(w http.ResponseWriter, r *http.Request) {
    log.Println("getting job...")
    q := r.URL.Query().Get("q")

    if q == "" {
        q = "default"
    }

    for a := 0; a < 100; a++ {
        work := HeavyWork{Name: q, number: a}
        splanner.AddUnit(&work)
        _, _ = w.Write([]byte(fmt.Sprintf("job %s %d done", work.Name, a)))
    }
}

type HeavyWork struct {
    Name   string `json:"name"`
    number int
}

func (p *HeavyWork) Job() error {
    time.Sleep(500 * time.Millisecond)
    fmt.Println(fmt.Sprintf("heavy job is running %d", p.number))
    return nil
}

Así de simple queda par ael cliente, tiene que implementar la interfaz Unit, con la funcion Job() y agregar la unidad de trabajo con una funcion exportada AddUnit que encola el trabajo. En main vemos el setup es extremadamente trivial.

El codigo completo, disponible en github

Conclusiones

Vemos el poder y flexibilidad que nos da el select para orquestar los workers y combinado con el pool, poder despachar rutinas, obtener métricas, etc etc.
No nos olvidemos que hay que estudiarlo, usarlo debidamente y sobre todo, probarlo en muchos escenarios para no llevarnos sosrpresas no gratas en producción.

Ya saben, si quieren sponsorearme, pueden hacerlo acá!

Seguridad en Golang

Tomas Francisco Lingotti — Tue, 25 Apr 2023 01:49:59 +0000

Cómo escribir código mas seguro en Go?

En esta ocasion, vamos a ver funciones de hash y de cifrado/decifrado con su principal diferencia. Como bonus, una repasada a las funciones pseudo aleatorias del lenguaje.

Intro
Hash con SHA512
Usos comunes del hashing
Cifrado y descifrado
Usos comunes del cifrado
Números aleatorios
Conclusiones

Intro

Para comenzar, tenemos el paquete Crypto de la stdlib nos va a proveer el 100% (casi siempre) de las utilidades que necesitamos. Por eso es importante tener a mano su documentacion oficial para solventar dudas de implementación y lograr entender los pormenores.
Segundo, pero igual de importante, es que esta operación es "one way", es decir, con el resultado no puedo volver hacia atrás y obtener el valor ingresado.

Hash con SHA512

Seguramente habrán visto la sigla SHA en algún lugar de la web, curso, etc, ésta corresponde a Secure Hash Algorithm y viene de larga data acompañándonos. Fue desarrollada en los Estados Unidos en el 2001, por la NSA y aprobada ese mismo año para su uso, existen variantes del algoritmo, comenzando por SHA-0 (luego vinieron 1, 2 y 3 que es la actual) y el 512 refiere al tamaño en bits de la "salida" o el digest en inglés.
EL funcionamiento básico es muy simple de explicar sin entrar en tecnisismos: recibe una entrada (arreglo de bytes) de cualquier tamaño y devuelve una palabra de siempre la misma longitud (en este caso 512 bits). Cabe destacar que la entrada puede ser realmente muy grande, segun los datos oficiales es de (2^128-1).

Ya sabemos como funcionan, ahora un pequño problema que nosotros no nos vamos a encontrar, pero si los involucrados en el desarrollo de estas fantásticas soluciones, fue que al tener un tamaño de salida definido y tanta capacidad para recibir muchos valores, se encontron con la no-grata sorpresa de que destintas entradas tenian como respuesta el mismo resultado, comúnmente llamadas colisiones.
La buena noticia es que a partir de SHA-2, no se volvieron a encontrar y es algo por lo cual no nos tenemos que preocupar.

Ahora pasamos un poco al código

// hashShortVersion simplemente usa la función para del package, devuelve slice de bytes, simple y efectivo.
func hashShortVersion(s string) string {
    hasher := sha512.Sum512([]byte(s))
    return fmt.Sprintf("%x", hasher)
}

// hasherVersion creamos una interface hash.Hasher, le asignamos una implemntación de sha512 y usamos el método sum de la interface. Nos puede servir para hacer composición o polimorfismo, el resultado es distinto al anterior.
func hasherVersion(s string) string {
    var hasher hash.Hash
    hasher = sha512.New()
    b := hasher.Sum([]byte(s))

    res := fmt.Sprintf("%x", b)
    return res
}

// binaryVersion convierte a binario nuestros datos.
func binaryVersion(s string) string {
    var hasher hash.Hash

    hasher = sha512.New()
    hasher.Write([]byte(s))

    m, _ := hasher.(encoding.BinaryMarshaler)
    _, _ = m.MarshalBinary()

    return string(hasher.Sum(nil))
}

Como expresan tanto el código y los comentarios, los resultados no son iguales ya que usan métodos/funciones distintas. El MarshallBinary() no es recomandable usar para guardar los datos en un storage "normal" como bases de datos relacionales, de documentos o archivos porque tiene un formato muy distinto, además de ser ilegible para los humanos y no podemos compararlos con el operador "==".

Usos mas comunes

Decíamos que las funciones hash, tienen como objetivo captar una entrada "digerirla" y devolver un resultado siempre del mismo tamaño. No importa si ingresamos un solo caracter, Don Quijote entero o todo el código fuente de el Kernel de Linux, la salida tiene siempre el mismo largo. Y como toda función pura, ante la misma entrada, vamos a tener la misma salida, es por eso que el uso mas común es el de garantizar la autenticidad de un software, cuando entregamos el SHA de un compilado o ejecutable, el usuario que lo descarga puede hacer el mismo proceso y validar que haya descargado el mismo que la documentación oficial dice.
Por otra parte, un uso muy común pero que no recomiendo, es para contraseñas, ya que existen tablas con muchisimos datos llamadas Rainbow tables que se usan para poder crackear contraseñas, por lo que no es un caso de uso muy acertado.

Bueno, hasta acá de hashing, ahora pasamos al cifrado

Cifrado y descifrado

LA principal diferencia con el hashing, es que aca si podemos volver a obtener lo que enviamos en un principio y la segunda, es que ante la misma entrada, podemos no obtener la misma salida (mientras menos colisiones haya, mejor) por sofisticadas funciones matématicas que se denomina sal (o salt en inglés) y es un conjunto de bits aleatorios que su objetivo es el de, justamente, cambiar el resultado ante los mismos valores de entrada.

ejemplos en código:

func Encrypt(s string) ([]byte, error) {
    return bcrypt.GenerateFromPassword([]byte(s), bcrypt.MinCost) // puede ser también defaultCost
}

func Decrypt(encryptedPassword, plainPassword string) error {
    return bcrypt.CompareHashAndPassword([]byte(encryptedPassword), []byte(plainPassword))
}

Bueno con este si que no nos podemos quejar, lo fácil y claro que es no deja margen de dudas.
Si prueban imprimir solo el string resultante varias veces con la misma entrada, pueden ver como obtienen distintos resultados.

Usos más comunes

Claramente el uso mas común (hace muchísimos años) es el de ocultar un mensaje y que un receptor pueda interpretarlo. En informática lo vamos a usar extensamente para contraseñas, tokens y valores que el usuario envía y son sensibles.

Números aleatorios

Antes de empezar a abordar el tema, no son aleatorios, son pseudo aleatorios y es una definición teórica que pueden ver explicado acá.

En éste código, vemos dos casos de uso muy comunes, el primero es obtener un string aleatorio dado un alfabeto. El parámetro de entrada es uno solo y corresponde a que tan larga debería ser la cadena resultante. Así de simple y sencillo.

La segunda función, es un poco mas de lo mismo, solo que generamos únicamente números y el parametro de entrada corresponde al límete superior sin incluir, es decir, si ponemos 1000, vamos a generar un número entre 0 y 999.

func GenerateRandomString(n int) (string, error) {
    const letters = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz-"
    ret := make([]byte, 0, n)
    for i := 0; i < n; i++ {
        num, err := rand.Int(rand.Reader, big.NewInt(int64(len(letters))))
        if err != nil {
            return "", err
        }
        ret = append(ret, letters[num.Int64()])
    }

    return string(ret), nil
}

func GenerateRandNum(n int) int64 {
    b, err := rand.Int(rand.Reader, big.NewInt(int64(n)))
    if err != nil {
        return 0
    }
    return b.Int64()
}

Con estos dos snippets ya tienen para cubrir bastantes casos.

Conclusiones

Aprendimos (o repasamos) las principales diferencias entre el hashing y el cifrado, tanto conceptualmente como implementaciones en Golang y sus usos mas frecuentes en la industria, también como el desarrollos académicos.
Por último, cubrimos brevemente que es y como se usa el paquete crypto.Rand y claramente, agregamos un poco de código.

Ya saben, si quieren sponsorearme, pueden hacerlo acá!

Handlers con timeouts en Go

Tomas Francisco Lingotti — Sat, 24 Dec 2022 23:45:03 +0000

En algunas oportunidades, vamos a necesitar un comportamiento muy determinístico en nuestras APIs, ya sea porque el negocio así lo requiere o los clientes. Tal vez, un comportamiento que se mantenga alejado de cualquier sorpresa, puede ser el máximo de duración que le queremos dejar como ventana para que un respuesta sea entregada, en caso de excederlo, ahora si como el título lo dice, devolvemos un timeout... pero, qué es un timeout?
En principio sabemos que contamos con 2 estados para representarlo, pero no se parecen mucho ya que están en centenas distintas, unos es 408 request timeout y el otro es 504 Gateway timeout.
Si leemos un poco las especificaciones, ninguno de los dos nos calza justo para lo que queremos, el 408 nos dice que el cliente "se tardó demasiado para enviar su request", desde la RFC dice lo siguiente:

The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.

Y para su contraparte del lado del servidor:

The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.

Entonces, para la responder la pregunta, concluimos que un timeout es que esperamos demasiado por algo, y no sucedió, ademas, lo consideramos un error.

Cómo hacemos nuestras funciones de Timeout?

En los lenguajes de programación modernos, encontramos built-in algunas formas de manejar estos casos de uso. En Golang, por ejemplo el paquete context tiene constructores para crear uno que expire y se cancele después de cierto tiempo.

Dentro del paquete net/http también nos encontramos con muchos timeouts como por ejemplo en la struct http.Client para hacer requests y http.Server es otra que tampoco se queda afuera de tener este tipo de configuración.

Por ahora, tenemos: context, http.Client y Server, servidores TCP y UDP, etc. Podemos resumir que siempre que haya una conexión hacia fuera (ya sea cliente o servidor) vamos a poder configurar un timeout.

Cómo nos sirven en los web handlers?

Antes, debemos aclarar que es un middleware, en cualquier lenguaje, ya que es un concepto y no una implementación específica de Golang.

Entonces, decimos que son funciones con la misma firma que un handler (o controlador web), que recibe los mismos parámetros para operar como una petición HTTP. Al ser iguales, nos permite ejecutarlo previamente de una forma sencilla y pre-ejecutar operaciones que nos ayuden a nuestro negocio. Un claro ejemplo son validaciones de token JWT, agregar request ID unicos, sumarle datos al contexto (esto si es mas estilo gopher).
En nuestro caso, vamos a tener un middleware que se encargue de reemplazar el contexto, por otro que tenga un timeout, para que no tarde mas de tanto tiempo y si no, falla. Nos va a ayudar a garantizar un tiempo de respuesta de máxima, por las buenas o por las malas.

Lo llevamos a código

Como middleware, podemos usar uno que ya existe y está dentro del paquete http, es http.Timeout y dentro de su firma, vamos a pasarle un http.Handler, el tiempo de espera que vamos a soportar y por último (este no me gusta mucho) un mensaje como string, donde nos quita un poco de flexibilidad, a mi entender, []byte nos daría un espectro mas amplio a la hora de retornar los valores.

Podemos implementarlo como un wrapper general a todo el multiplexer y que todos ejecuten el middleware, este tiene como ventaja que escribimos una sola vez, pero perdemos granularidad.

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        //....
    })
    muxWithMiddleware := http.TimeoutHandler(mux, time.Second*5, "timeout!")

    log.Fatal(http.ListenAndServe(":8080", muxWithMiddleware))
}

Por último, tenemos otro camino, para tener un control espercífico en cada handler que expongamos.

func main() {
    mux := http.NewServeMux()
    helloHandler := http.TimeoutHandler(wrapHandlerFunc(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        _, _ = w.Write([]byte("hello with timeout!"))
    })), time.Second*5, "timeout")

    mux.Handle("/", helloHandler)
}

func wrapHandlerFunc(handler http.Handler) http.Handler {
    wrapped := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "application/json")
        handler.ServeHTTP(w, r)
    })
    return wrapped
}

Conclusiones

Vemos la flexibilidad que tenemos para exponer funciones en un servior web que tenemos en Golang. Siempre nos da muchas facilidades y opciones, a su vez, puede ser un poco confuso porque no sabemos bien cual usar. Como pequeño consejo, no nos fritemos la cabeza pensando y comparando, tan solo elijamos una con un análisis superficial y despues nos queda el aprendizaje.

Para cerrar el tema técnico, estamos re-utilizando una funcion de la stdlib de Go, por lo que no es necesario que nostros pensemos esa lógica, también, muchos de los Frameworks web como Echo, Gin y Fiber (seguramente entre varios otros) ya traen sus middleware de timeout y es de una implementacion muy similar a la que acabamos de ver.

Espero que les haya gustado la explicación! nos vemos dentro de poco y cualquier tema que quieran que tratemos lo pueden dejar en comentarios.

Concurrencia en Golang III

Tomas Francisco Lingotti — Wed, 07 Dec 2022 22:04:50 +0000

|1. | Modelo de concurrencia
|2. | Goroutines y canales
|3. | Wait Groups
|4. | Select y Worker pools
|5. | ErrGroup (error groups)

WaitGroups, que son y para qué sirven?

Siempre me gusta comenzar los temas respondiendo estas dos preguntas, porque nos da un panorama general de que problemas nos ayuda a resolver y cuándo es mejor usar ésta tecnología.

Los WG son estructuras que nos permiten "alojar" rutinas (la cantidad que querramos) y -lo mas importante- poder esperar a que todas terminen. En resumen, es un mecanismo de sincronización de go-rutinas, donde podemos ejecutar todas las que sean necesarias y quedar a la espera a que la totalidad terminen.
Es muy útil cuando queremos paralelizar un trabajo pero tratándolo como una unidad, que una vez terminada, sigue el flujo normal de trabajo.

Para terminar la introducción, la struct de WaitGroup se encuentra en el paquete sync de la stdlib, no tenemos que importar nada.

Como se usan los wait groups?

Tenemos 3 métodos básicos que nos van a dar soporte a nuestra operación.

Vamos a mejorar el ejemplo que dimos en el post anterior, donde usábamos (mal) la función time.Sleep() para esperar que la goroutine termine. Ahora vamos a mostrar una forma correcta de hacer el mismo trabajo.

package main

import (
    "fmt"
    "sync"
)

var wg sync.WaitGroup

func main() {
    wg.Add(1)
    go doWork(&wg)
    wg.Wait()
    fmt.Println("exiting...")
}

func doWork(wg *sync.WaitGroup) {
    fmt.Println("hello world")
    wg.Done()
}

Esta si es la forma correcta de ejecutar un hello world en una goroutine. Vamos paso a paso:

definimos la variable wg que es de tipo sync.WaitGroup, yo aconsejo declararla así para mejor lectura, aunque wg := sync.WaitGroup{} también es correcto.
Dentro de main, donde lanzamos la rutina con el prefijo go (eso ya lo sabemos hacer), tenemos el método Add(), que tiene como parámetro de entrada un entero (se llama delta) y ahi le vamos a especificar con una precisión absoluta, cuantas goroutines se va a agregar a la lista de espera, la misma cantidad que se agreguen, van a ser las que terminen.
En caso de ejecutar muchas goroutines o que se lancen dentro de un bucle, en lugar de poner el numero exacto podemos igualmente siempre agregar 1; Por ejemplo:

// ...
for i, _ := range ints {
    wg.Add(1)
    go doWork(&wg, i)
}
// ...

Entonces, independientemente de la cantidad de ints vamos a agregar siempre de a una.
Acá otra recomendación para Add(), y es que admite números negativos, para decrementar la cantidad en espera, yo NO lo recomiendo usar a menos que sea un caso de uso exacto, puede llevar a problemas cuyas soluciones sean muy difíciles de encontrar.

Vemos también que a la función doWork, le pasamos la dirección de memoria de la estructura wg. Esto es importante porque estrictamente queremos esa referencia y no modificar una copia, suele ser un error normal cuando empezamos a usar esta sincronización, este bien atentos a recibir punteros y pasar direcciones de memoria con '&'.
En doWork, invocamos a Done(), puede usarse con la palabra reservada 'defer' para que no repetirnos en caso de tener varias salidas o return y como su nombre lo indica, Done() lo debemos llamar cuando el trabajo está terminado. Internamente va a descontar en una unidad a la lista de espera y marcar esa tarea como finalizada.
Por último, el método Wait(), que va a detener el control del programa hasta que el contador de la lista de espera de 0( cero) y todas las rutinas hayan ejecutado la función Done().

Conclusiones

Los WG son un mecanismo excelente para garantizar completitud de N cantidad de goroutines, fácil de implementar y probar, ademas de que la encontramos en la stdlib, como la gran mayoría de cosas que vamos a ver en estos artículos.

Ya saben, si quieren sponsorearme, pueden hacerlo acá!

Concurrencia en Golang II

Tomas Francisco Lingotti — Thu, 01 Dec 2022 20:40:55 +0000

|1. | Modelo de concurrencia
|2. | Goroutines y canales
|3. | Wait Groups
|4. | Select y Worker pools
|5. | ErrGroup (error groups)

Goroutines e hilos recap

En el post anterior, vimos brevemente una comparación entre las goroutines y los threads, que no va mucho más allá, pero si para refrescar un poco la memoria vamos a repasarla:
Las rutinas: Son más livianas ( < 2 kb) por que no necesitan tanto espacio en RAM ni los datos en el registro para que el sistema operativo pueda identificarlo.
Son 100% manejadas por el runtime de Go.
Se comunican por medio de canales con otras rutinas.
Los Hilos: Son propiedad del sistema operativo.
Pesan alrededor de 1mb, tienen que mantener muchos datos para que el sistema operativo los identifique y pueda saber su estado.
La comunicación entre dos hilos es un proceso costoso, si bien excede a este post, pueden buscar más información buscándolo como "Context Switch".

Cómo ejecutar una rutina en Go

El lenguaje nos ofrece una mecánica muy simple que es agregar la palabra reservada go por delante de la función o método que queremos ejecutar.
package main

import "fmt"

func main () {
    go fmt.Println("hello world")
}

Claramente si ejecuta ese código, no va mostrar nada, o si, no lo se. Lo que si se es que no podemos garantizar nada.
¿Por qué no podemos ver el resultado?
La respuesta es fácil, pero por detrás se oculta toda la lógica de procesamiento de rutinas. Primero, hay que destacar que siempre al menos vamos a correr una rutina, cada vez que ejecutemos un programa en Go. Esta es la rutina principal que viene con la función main. Cada sentencia go que agreguemos, va a sumar una más a la existente.
Ya sabiendo que tenemos siempre una rutina (main) y que el runtime es quien se dedica, en parte, a dar el lugar de ejecución y mantener el ciclo de vida de las rutinas, es ahí donde tenemos la certeza de no garantía de ejecución; en otras palabras si al runtime se le ocurre correr la rutina con el Print del "hello world" puede que lo veamos en pantalla, aunque sigue siendo un proceso no determinista.
Vamos a plantear una solución rápida, usando la lib de golang, que es la funcion Sleep(), para que dentro de un tiempo razonable, le damos la oportunidad al scheduler que nos ejecute la goroutine y veamos el mensaje en pantalla (recuerden nunca hacer esto en un programa productivo, jamás)

package main

import (
         "fmt"
         "time"
)

func main () {
    go fmt.Println("hello world")

    time.Sleep(5 * time.Second)
}

Listo, ya le dimos 5 segundos, más que suficiente para que todo comience y termine.
Más adelante vamos a ver cómo podemos usar waitgroups, que es el mecanismo correcto para asegurarnos la finalización de los procesos.

Anatomía de los canales

Un canal es un tipo de dato nativo de Golang. se declara con la palabra reservada chan y tenemos que especificarle "de que va a ser ese canal", además tenemos otro dato opcional que especifica el tamaño (o buffer) del canal, es decir, que tantos mensajes puede tener en su buffer hasta que la escritura sea bloqueante.
Se crean con la función interna new().
Un ejemplo podría ser:
ch := make(chan string) // sin buffer
bufCh := make(chan string, 5) // con un buffer de 5 mensajes

La principal diferencia radica en el bloqueo a la hora de la lectura/escritura. Empecemos con los channels sin buffer o sin capacidad definida.
Repasamos qué es un bloqueo a nivel de goroutine, que es algo grave y de lo que el programa no va a poder recuperarse fácilmente. En esencia, la rutina va a quedar bloqueada, hasta que pueda ser desbloqueada (ya sea con una escritura o lectura del canal para que libere al canal y la rutina que no pudo operar), pero en caso de que las "rutinas que iban a desbloquear", hayan terminado, estamos en la presencia de un deadlock, y ahi si la ejecución de nuestro programa se detiene.
Para la escritura, va a ser siempre blocking, es decir que se va a completar la operación cuando la lectura se lleva a cabo, es la razón por la que los canales sin capacidad definida, tienen que escribirse en goroutines separadas a las de lectura.
Para la lectura también es blocking mientras no haya mensajes para leer. Entonces, si volvemos a la definición de bloqueo, una rutina podría quedar bloqueada si no tenemos bien desarrollado que primero escriba y después acceda a leer. En caso de que nos quede al revés, tenemos un deadlock.
Por eso decimos que los canales unbuffered son sincrónicos porque entre los dos, deben esperar ambas operaciones sucedan para realizar la comunicación.
Ahora vamos con los buffered:

Para la escritura, van a ser non-blocking a menos que el buffer esté lleno, en ese caso vamos a tener que "esperar" que otra rutina lea un mensaje para que salga del buffer, y ahí volvemos a tener espacio para uno más. En el ejemplo de arriba, en caso de que nadie los lea, el mensaje numero 6, no se podría efectivizar y la rutina quedaría bloqueada.
Para la lectura, también va a ser non-blocking a menos que el canal esté vacío.
Por eso decimos que la comunicación es asíncrona para los canales con capacidad definida.

Sintaxis para leer y escribir

Vamos directo al código para escribir:

func DoCalc(factor int, ch chan int) {
   value := db.GetValue() // tomamos un valor de la db
   // La sintaxis para trabajar en el canal es con el operador "<-".
   // Nos indica la dirección en la que se escribe el valor, por ej (ch <- "value"), vamos a escribir sobre canal, le estamos mandando un valor.
   // Por otro lado, el _channel_ puede asignar valores a variables, estructuras, etc, dependiendo de lo que contenga, por ejemplo (value := <- ch), decimos que leemos de un canal.
   ch <- value * int
}

Para la lectura es similar, aunque tenemos variantes
Podemos hacerlo con el operador, nos va a traer el dato, pero además podemos recibir un tipo bool, para saber si realmente fue una lectura exitosa o si el canal estaba cerrado, tenemos un zero value.

v, ok := <- ch
    // donde v es el valor del canal y ok nos permite saber si la lectura fue exitosa o no.

Es el mismo ejemplo pero sin el OK, no es necesario pedirlo. En algunos casos más recomendado que en otros.

v := <- ch

Es importante saber que tipo de canal vamos a usar (con capacidad o sin capacidad) y eso nos va a ayudar a estructurar mejor los mecanismos de lectura/escritura para evitar bloqueos. Aunque la mayoría se pueden solucionar con tests, pero siempre es conveniente tener los conceptos claros para saber lo que estamos haciendo.

Conclusiones

Tenemos las goroutines que se ejecutan fácilmente con la keyword go y una función o clausura, es rutina corre sobre un hilo (thread) del sistema operativo. La rutina principal es Main y siempre se ejecuta, cuando esta se corta, le comunica al sistema operativo si fue con código 0 (sin errores) o distinto de 0 dependiendo del error ocurrido.
Por otro lado, tenemos los canales que es el medio de comunicación de las rutinas. también es un tipo de dato nativo de Go, o sea que no tenemos que importar nada de afuera. Los canales pueden tener o no un tamaño y eso modifica la forma en que bloquea la lectura/escritura.
Para terminar, recuerden que es importante saber la naturaleza del problema y si es necesario usar más de un hilo de ejecución, y en caso de necesitarlos, también debemos saber que si los recursos están bien manejados, podemos tener un gran número de rutinas en un hardware que no sea el más caro o grande.

Si te gusto el contenido, podes sponsorearme aca!

Concurrencia en Golang I

Tomas Francisco Lingotti — Wed, 19 Oct 2022 20:09:50 +0000

En esta serie de posts, vamos a estar explicando varios temas relacionados a la concurrencia en Golang, desde cómo está pensada en el runtime hasta implementar patrones para resolver problemas.
En estas series, vamos a repasar los siguientes conceptos:

|1. | Modelo de concurrencia
|2. | Goroutines y canales
|3. | Wait Groups
|4. | Select y Worker pools
|5. | ErrGroup (error groups)

Ya que esta es la primera entrega, acá vamos.

Modelo de concurrencia

A diferencia de otros lenguajes, en Go tenemos goroutines (go rutinas) que nos permiten multiplexar trabajo por sobre un hilo de ejecución. Si bien eso suena a nada especial, la idea por detrás es que no vamos a crear Threads (hilos) directamente en el sistema operativo, sino que el runtime scheduler se va a hacer cargo de crear rutinas que vivan en un thread, de esa manera vamos a tener una relación MxN con hilos y rutinas. Por cada Thread vamos a poder ejecutar N goroutines.

Communicating Sequential Processes (o SCP) es el modelo teórico escrito y documentado por el científico Tony Hoare y donde Go basa su estructura principal. El paper no lo vamos a explicar en profundidad, primero por su complejidad y segundo porque Go solo toma algunos conceptos, no todo, pero pueden revisarlo aca si estan muy interesados en ver el corazón del proyecto, pero resumiendolo bastante, podemos concluir que es posible resolver concurrencia con dos primitivos que son:

Entrada
Salida

En un flujo donde podemos dejar plasmada de forma atómica una rutina, decimos que una entrada es información que puede sufrir un proceso para tener una salida. O sea una unidad básica de trabajo.
Si reunimos estos puntos, en una pieza de software quiere decir que también lo podemos llevar a un proceso de ejecución concurrente.

Dijimos que solo tomó prestados algunos conceptos, del paper inicial para el desarrollo del modelo de concurrencia y dentro de esa abstracción conceptual vemos el resultado tangible que se expresa en la semántica de Go con 2 mecanismos clave:

Goroutines (rutinas)
Canales Y capaz (esto a mi entender solamente) el select como herramienta built-in para sincronizar.

Go Scheduler

Es una parte muy importante del runtime de Go, es código C estáticamente linkeado dentro del binario que vamos a ejecutar. Sabemos que Go en su fase de compilación, nos genera un único archivo ejecutable en la máquina contenedora. Dentro del runtime van a coexistir las llamadas al sistema operativo como por ejemplo, creación de threads.
Dentro del Scheduler, una sección muy importante es el goroutine scheduler, que es quien se encargue de el procesamiento de las rutinas, conozca de su ciclo de vida y sea quien decida qué rutina ejecutar en cada turno, es por eso que nosotros como desarrolladores no podemos garantizar el orden de ejecucion y/o finalizacion de las goroutines.

En esta imagen vemos como es la comunicación desde el ejecutable para con el Kernel del SSOO.

Las goroutines son similares a los hilos del SSOO pero mucho más livianas ya que ocupan menos recursos y son manejadas por Go, en cambio los threads son propiedad del SSOO y su implementación cambia entre por ejemplo Windows y MacOS.
Otra diferencia es la comunicación entre ellos, para que dos goroutines se comuniquen, existe la herramienta built-in en Go conocida como channels, en cambio para los threads no existe algo nativo que sirva con el mismo propósito.
El tiempo que tardan en crearse también es muy distinto, ya que un thread necesita un stack de un MB de memoria en un Kernel std y muchos valores de los registros asociados para poder idenficarlo, mientras que una goroutine tiene un espacio en memoria de < 2 kb.

Aun así, las rutinas de Go están basadas en los threads, corren si o si en uno de ellos, es decir, no tenemos goroutinas en el sistema operativo, por eso podemos tener N rutinas por cada thread.

Conclusiones

Como conclusión en alto nivel, tenemos por un lado, el modelo de concurrencia de Golang está basado en entrada, proceso y salida, muy simple pero no menos efectivo.

Go tiene 2 técnicas para manejar concurrencia, goroutines y canales. Tiene varios otros más para sincronización, que ya vamos a ir revisando.

Goroutines y Threads se parecen en muchos aspectos, pero no son lo mismo. Las rutinas viven en los threads y por esa razón (principalmente) son mucho más livianas. En un programa Go podemos tener M threads X N goroutines (por ejemplo 2 threads y 100 goroutines). Cómo vemos en la primera imagen.

Por último, la arquitectura de Go que al compilar, además de todo nuestro código en el programa, va a hacer un static link de varias cosas más, entre ellas el runtime que va a ser quien se encargue del manejo pesado de las goroutines. Como su ciclo de vida, ejecución, "turnos", etc, y también otras operaciones con el sistema operativo.

Espero que les guste y hasta la próxima, con la siguiente entrega.

PS: sponsoreame aca si te gusto el contenido

JWT y Golang

Tomas Francisco Lingotti — Sat, 01 Oct 2022 17:37:34 +0000

Bien sabemos lo complicado que es cubrir el 100% de los casos de uso cuando hablamos de registro de usuario, autorización y autenticación. Eternas discusiones que nos consumen mucho tiempo y recursos para siempre dejar espacios en blanco que con el tiempo serán subsanados con nuevas versiones de nuestros servicios encargados de estas acciones. Siempre recomiendo, para cada desarrollo donde servidor y cliente están separados, tener un mecanismo basado en Tokens (puede ser JWT, puede ser cualquier otro) para garantizar la autenticidad de las peticiones.

JWT y REST

Siempre leímos que en REST cada petición tiene que ser independiente a su predecesora y sucesora, lo cual es falso para sistemas que requieran autenticación, que a su vez, corresponden a la gran mayoría de los que usamos en nuestras PCs y teléfonos; es muy difícil imaginar poder hacer una transferencia bancaria sin autenticarse primero o querer publicar una entrada en un blog sin antes dejar mis credenciales.

Entonces, tenemos una primera petición bien conocida, que es proveer nuestra identidad, sin importar de qué manera, SSO con Google, GitHub, email y password o biometría, le tenemos que dar algo para que el sistema confíe en que somos nosotros. En un futuro, voy a intentar redactar modelos de autenticación más sofisticados para servidores web.

Una vez validadas las credenciales, el servidor nos otorga una llave para nuestras sucesivas peticiones dentro del mismo dominio, que suele ser un token (un string o cadena de caracteres), con un formato específico que ambos entienden, firmado con un algoritmo (que ambos entienden) e información adicional que puede ser cualquier cosa, aunque se recomienda altamente no dejar nada sensible o que pueda llevarnos a conocer más acerca de quién era -el dueño- del Token.

Morfología del JWT

Sabemos por sus siglas en inglés, qué es JSON, es Web y es un Token, a su vez, cuenta con una estructura bien determinada en la cual se basa el mecanismo. Consta de 3 partes separadas por un punto y cada una de ellas contiene datos específicos, las librerías de los lenguajes nos ayudan a formar JWTs correctos y seguros. También, estas tienen una estructura JSON y están encodeadas en Base64.

Éstas partes son:

Headers -> dónde se encuentran el algoritmo de encriptación usado y el tipo de token.
Payload -> acá, se encuentran los datos que queremos transportar del usuario, el campo "sub" (de subject) es donde comúnmente se encuentra un identificador único. Podemos agregar los campos que necesitemos pero es muy importante no agregar nada sensible por un simple hecho; en caso de que el token quede comprometido, la información es totalmente accesible, ya que solo está en formato de Base64 (al igual que las demás partes).
Signature -> Este segmento valida la firma a la hora de verificar el token y si estaba sellado con una contraseña, debemos utilizar la misma, caso contrario el token va a ser detectado como inválido y por consiguiente, el cliente no podrá consumir el recurso seguro.

Esta imagen es de la web jwt.io donde pueden practicar como crear uno y validarlo.

Otros claims (campos) importantes en el payload de JWT son los de "iat" y "exp" que además del "sub" deben viajar siempre y corresponden a issued at (cuando se firmó) y expires at (cuando vence). Es muy común en sitios web ver el check de remember me, la gran mayoría de las veces esto es para firmar el token con un exp mucho mayor que si no estuviese checkeado.

Cómo lo hago en Golang?

En Go tenemos librerías muy fáciles de usar, mi consejo es usarlo como servicio e inyectar cuando sea necesario, para después usarlo como middleware, así su uso queda muy natural y desacoplado a la lógica de negocios.

Acá vemos para firmar el token, no necesitamos casi nada extra aparte de "github.com/golang-jwt/jwt", solo un secreto para firmar el token y los claims, que además de los estándar, podemos agregar los que necesitemos. Es importante tener en cuenta el tag json para que queden con el formato esperado.

La expiración del token queda grabada en esta firma también.

Ahora vemos como usarlo como un middleware en los web handlers y declarando como servicio

y con estos simples pasos ya podemos agregarlo a cualquier ruta como middleware, en caso de que estemos usando la std lib de Golang, en caso de usar algún framework web com o Gin, Fiber o Echo, vamos a tener que modificar un poco la firma, pero de lo contrario, ya está listo para ser implementado.

Si les gustó el contenido, me pueden sponsorear aca!

Qué es el Bloom Filter?

Tomas Francisco Lingotti — Tue, 13 Sep 2022 16:48:56 +0000

Hablamos de una estructura de datos no tan común pero que tiene casos de uso interesantes, ademas es una buena opción cuando queremos reducir el uso de memoria. Como es un filtro, la respuesta esperada es si por lo que estoy preguntando, se encuentra o no guardado en nuestros sistemas.

Con esto en mente, tenemos que saber que es una estructura probabilística, con dos resultados posibles, estos son:

Seguro que no ❌
Probablemente si 🤞

Si nos dice que no, es que no está y eso es seguro, pero no puede garantizar que sí, entonces si la respuesta es probablemente si vamos a tener que asegurarnos yendo a verificar por segunda vez, pero a otro lugar, no al filtro. Esto se puede dar por colisiones en funciones hash y también en que, al reducir el espacio en memoria, las colisiones van a estar presentes.

Ahora vemos como funciona

Hablamos de probabilidades, hashes, colisiones y demás, vamos a explicar con un caso concreto.

Supongamos que dev.to no quiere recomendarte un post que ya leíste en el ultimo tiempo, entonces, vamos a ir cargando los posts vistos en el filtro de una manera particular, que ahora detallamos.

Para nuestro filtro vamos a usar un arreglo (slice si sos gopher) con un numero que sepamos, en este caso 100, así no crece indiscriminadamente porque la idea principal es mantener nuestro uso de memoria, bajo. Usamos bool para representar 0 y 1.
Cada función de hash (podemos usar varias, recomiendo fuertemente más de una) va a devolver un numero entero como resultado y cada entrada va a ser representada por n números siendo n la cantidad de funciones de hash que usemos. Después todos los resultados van a traducirse en que ese mismo indice, va a quedar en true. Por ejemplo si tenemos un slice de 10 de bool y las tres funciones nos devuelven 2, 3 y 6 nos queda algo así:
[f][f][✅][✅][f][f][✅][f][f][f]

Entonces...

var filter [100] bool //100 para tener una buena distribución

Ahora las funciones hash

var h1 = func(i interface{}) int{...}
var h2 = func(i interface{}) int{...}
var h3 = func(i interface{}) int{...}

Si bien son placeholders, la idea es que tome cualquier valor y devuelva un entero que esté dentro del rango, por eso vamos a aplicar el operador modulo a la respuesta. Cualquier implementación que usemos, tenemos que saber que el resultado tiene que ser siempre el mismo ante la misma entrada, como una función pura y determinística.

index1 := h1("dev.to/post-x") % 100
index2 := h2("dev.to/post-x") % 100
index3 := h3("dev.to/post-x") % 100

filter[index1] = true
filter[index2] = true
filter[index3] = true

De esta manera ya queda resuelto como podemos escribir un bloom filter, para la lectura, básicamente es lo mismo, pero debemos preguntar si los indices son true y ahi tenemos cómo podemos estudiar las respuestas que vimos previamente.

Si algún indice nos da falso, sabemos que la URL que enviamos no esta en nuestro filtro.

Si todos los indices dan verdadero, decimos que probablemente si, ya que, al tener un array "chico" y que las funciones hash tienen colisiones, puede que otra URL haya generado los mismos números o algo mas fácil, puede ser este ejemplo:
La url 1 nos da el resultado 1, 3 y 6
La url 2 nos da el resultado 2, 5 y 7
la url 3 nos da el resultado 2, 3 y 7 -> nos da que sí son todos true, pero la url 3 en sí, no estaba guardada, por eso en el segundo check (puede ser una base de datos) nos da que no estaba.

Conclusión

El bloom filter es una buena opción para cuando queremos ahorrar tiempo y espacio. Puede usarse como alternativa de un hashmap o un cache, para hacer operaciones en memoria y evitarnos salidas de red. Espero que lo prueben en sus proyectos!

Hasta la próxima!

PS: sponsoreame aca si te gusto el contenido

SSE con Golang y Nats

Tomas Francisco Lingotti — Sun, 11 Sep 2022 16:12:42 +0000

Arquitectura orientada a eventos con dos servicios comunicándose mediante Nats y enviando eventos con Golang.

Qué es un Evento?

Para no ponernos muy técnicos innecesariamente, lo definimos como un suceso que queremos comunicarlo a otro servicio. Entonces es "algo" y vamos a enviarle esa información a alguien más.

Entonces, qué es SSE?

Server side events es un protocolo que envía mensajes donde un servidor es la fuente (eventsource), que funciona perfecto para las aplicaciones que quieran mostrar datos de forma continua (streams). Además, la información que vamos a mostrar depende de los eventos que vayan ocurriendo, es decir que al momento de la ocurrencia, el cliente (con un poco de suerte) vamos a poder ver la información enviada desde el servidor sin tener que refrescar la pagina.

Entonces vamos a conectarnos desde un browser a una URL y recibir mensajes sin necesidad de hacer nada más. Esto es conocido como XHR streaming, similar a las conocidas peticiones AJAX pero con un canal establecido y solo recibiendo eventos desde el servidor.

Tecnologías utilizadas

Para esta demo, elegimos Golang, sin frameworks y nats que es, según ellos, un software de conectividad cloud native y nosotros lo vamos a usar como un pub-sub, alguien publica un mensaje y otro(s) se subscribe al tópico para tener ya disponibles los mensajes. Es por eso que siempre hablamos de near real-time porque no podemos desprendernos de la latencia natural que existe en las comunicaciones, pero vemos que Go y Nats hacen muy bien su trabajo y con tan pocas lineas de código vamos a tener una ejecución rápida y eficiente.
Docker lo vamos a usar para nuestra demo local.

Nuestro caso de uso

Para el ejemplo, vamos a simular algunos drones están en un campo de batalla enemigo y escanean una zona en particular, obtienen información de las tropas, como cantidad de soldados, nivel de energía y experiencia (skill). Muchos drones en simultaneo van a estar enviando mensajes a través de nats, y el servicio de monitoreo los va a capturar, finalmente, vamos a ver los resultados en una web como streams de datos, cada vez que el monitor reciba un mensaje, lo procesa y lo envía por el canal de XHR streaming.
Recordemos que streaming es una extension de XHR que nos permite tener datos (bytes) disponibles al mismo momento que llegan, independientemente de un buffer que se los contenga.

Esta capacidad esta disponible en algunos browsers, no todos, por eso websockets sigue siendo muy popular pero de este modo tenemos conexión bidireccional, con el agregado HTTP que no tenemos usando websockets. Es por esto que vamos a tener que, mediante código, avisarle al cliente sí su navegador soporta nuestra operación.

Ahora si nos vamos al editor

En primer lugar vamos a definir el mensaje algunas estructuras y funciones.

Tanto Drone como Scan son para agrupar la info leída y las que componen la estructura de Message la vamos a usar para enviar el JSON.

Ahora para conectarnos a nats local y enviar mensajes, es muy fácil y casi imposible equivocarse. Va a correr sobre Docker.

Creo que no hace falta explicar mucho, lo unico importante de remarcar es el puntero a la conexion, ya que es una estructura y el subject que lo usamos como nombre del topico donde enviamos los mensajes.

Para ejecutar localmente, el docker compose es mas facil aun.

con un comando simple como docker-compose up ya vamos a tener una instancia local.

Con estas pocas lineas ya podemos enviar mensajes, ahora vamos a la otra sección, que es como vamos a recibirlos y mostrarlos.

servicio de monitoreo

Ya los drones están enviando sus scans, así que vamos a subscribirnos al tópico para leerlos.

Para conectarnos usamos lo mismo.

(ya vamos a usar el canal)

Acá vemos como nats nos da una firma con una closure para que hagamos el trabajo con el mensaje entrante. En nuestro caso se lo pasamos a otro canal (Nats también soporta nativamente la subscripción con canales en Go).

El método Listen() lo usamos de pasamanos y formateo, y el ReadForever() para que sea capturar todos los mensajes.
En main vamos a usar una goroutine separada para que readForever cumpla su trabajo.

Ahora pasamos a la última parte, enviar los streams al cliente web, en este caso un navegador.
Vamos a usar la interfaz Flusher() de Go que nos permite enviar los datos "en un buffer". Según la documentación, debemos validar en runtime si es posible hacer esta operación porque algunas implementaciones de los servidores web pueden no soportarlo.

Dentro del bucle infinito vamos a estar tomando todos los mensajes (podríamos usar la cláusula range también) y dandole un formato mas legible. La otra linea importante es Flush()para que realmente el mensaje se termine de enviar.

Por ultimo, no se olviden los headers, importante que el navegador conozca que no tiene que usar cache, mantener la conexión viva y que el content-type va a ser streaming.

Lo probamos

Podemos usar cualquier navegador y al tener los dos servicios corriendo, ingresamos a localhost:3335/listen (al menos asi lo tengo en mi GitHub y vamos a ver en tiempo real los eventos.

Conclusión

Como vimos, el patrón SSE es muy interesante y con muchísimos casos de uso aplicables. Con pocas lineas de código, lo hacemos realidad y es a prueba de fallas. No entramos en comparación detallada con otras tecnologías como websockets porque la idea era mostrar una alternativa, aunque siempre se tienen que evaluar ambas.

Espero que les haya gustado, los espero en comentarios y dejo todo el source: https://github.com/tomiok/nrt y si te gustó, podes sponsorearme aca.