DEV Community: Joaquin "Florius" Azcarate

Inspiraciones

Joaquin "Florius" Azcarate — Sun, 31 Jan 2021 14:20:44 +0000

Te pasa de querer programar algo y no saber que? tengo un bloqueo de ideas hace tiempo, quiero hacer algo con xxx y no se me ocurre qué /cazzo/ hahcer

Así empezó la conversación con un amigo. Después de hablar un poco, creo haber destilado un par de ideas que me gustaría compartir

¿Por qué yo?

Q: Habiendo miles de otros posts de miles de otras personas -muchas mejor calificadas que yo-, por qué leer este?
A: Creo que mi enfoque es mucho más especifico del que eh encontrado: Proyectos personales de programación, cuyo principal driver (1) es aprender algo nuevo.

Prove it

En mi porfolio (florius.com.ar) podrás ver alguno de los proyectos más recientes y más interesantes. No son muchísimos, pero son algunos. Siempre estoy tinkering (2) con algo nuevo.

Fuentes de inspiración

Voy a separar la inspiración en 3 categorías, no porque una sea más "fácil" o menos costosa; si no porque he conocido personas que están muy entonadas con una u otra categoría, y tal vez alguna de esta resuene más contigo.

Level 1 - Directo

En el trabajo, me pasa a veces que estoy haciendo algo, y pienso

“Uh, esto sería super guay si fuese así”

Pero caigo en la realidad de que no habría forma que pueda completar el feature en el tiempo si hiciera todo ese cambio, ni que me aprueben un PR si agrego siete millones de bibliotecas 😅.
Entonces me lo anoto:
“Estaría bueno una aplicación que haga X o una biblioteca que haga Y”.

Tiene una aplicación real, concreta y directa (por eso el nombre); que si existiese la usaría aquí y ahora. Pero no existe.

Algunos ejemplos de esto mismo

GitHub :: koncierge 🔔: Necesitabamos segmentar clientes según un u otro atributo; entonces se me ocurrió que un DSL parecido al query-dsl de Mongo podría verse bien. Finalmente terminamos utilizando algo similar en produción!
GitHub:: Apples and Oranges: Tambien en el trabajo quería una forma de testear un código que tenía todos BigInts, algunos números tenían impuestos otros no; entonces no podía sumar libremente unos con otros; por lo que me ocurrió una librería para “tagear” objetos.
GitHub :: marble-OS: En la facultad, para probar y evaluar trabajos prácticos, muchas veces necesitabamos lanzar programas de manera sincronizada. La mejor herramienta hasta el momento era ser una persona alta que pueda presionar en dos computadoras diferentes la tecla ↵ Enter.

Para este tipo de proyectos, recomiendo siempre estar atento a hacerse este tipo de preguntas:

Este feature/bug/issue en el que estoy trabajando: ¿Tiene alguna parte súper interesante que podría extraer en su propia cosa?
¿Puedo desacoplar completamente esta sección de lógica en su propia cosa?
Veo que alguien tomó esta decisión de arquitectura; ¿por qué no lo habrán hecho diferente? ¿puedo hacerlo de otra forma?

Level 2 - Concretization

Otra “forma” que suelo descubrir nuevas ideas es encontrar un blog post o algo que sea una idea abstracta, y convertirla en algo más concreto.
No es casual que me guste mirar videos sobre matemática!

En esta categoría no empiezo de un proyecto como en la categoría anterior, si no que llego a un proyecto desde algo más abstracto.

Algunos ejemplos de mis proyectos que surgieron a partir de esta forma de encarar problemas:

GitHub:: Apples and Oranges # leyes de tags: Hace algunos 3 años vi una charla de “propagators” por YouTube :: Edward Kmett. Sumamente interesante! Adicionalmente semirretículos es un tema que eh dado en clase de Matemática Discreta; y nunca le encontré una aplicación tan directa y linda.
GitHub :: Tryhard # applicativos en todos lados _(warning: el código es un desastre, estaba trabajando en eso, pero otro proyecto se llevó toda mi atención por ahora 🙈): También viendo un video de YouTube :: Tsoding y la relación de Applicative y Monoid y como podríá usar esto para "sumar" resultados de OpenDota.
WIP rapt: También en un video de YouTube :: Computerphile (¿tendré un problema con la consumición de videos?) sobre onion routing, y encriptación en capas; junto con contraseñas y OTP (3). Se que tengo una idea ahí, pero creo que es muy parecida a Vault, de HashiCorp.

Para este tipo de proyectos recomiendo pensar cada vez que escuches o leas algo (no importa de que; no digo oque hay que solo hacer uso de matemática! Estoy seguro que otras ramas de la ciencia son tan aptas a esto.) pensar:

¿Cómo podría usar eso?
¿En qué universo esta idea sería útil?
¿Veo que dice que se puede usar en X e Y; se podrá usar en Z?

(bonus: Creo que este mentalidad ayuda mucho a adquirir nuevos conocimientos. Más que una atención pasiva sobre un tema nuevo)

Level 3 - Snapshot

A mi gusto, la mejor forma de inspiración: Cuando pienso solo en una interacción, en una pantalla, en un link.

GitHub :: es-dia-de-helado-de-fruta: Mi novia me dijo que hoy no era día de helado de fruta, porque hacía mucho frio. Sería ideal tener una página que le pueda pasar para demostrarle la temperatura
FrasaL: Tienes un amigo que habla español traduciendo literalmente verbos preposicionales del ingles? Dice cosas como “velocidad de dios” en vez de “buena suerte”, y quieres pasar una página como DeepL para ayudar a otras personas a comprenderle?
GitHub :: delCanioBot: Necesitas un bot que genere imágenes de Nicolás del Caño, a razón de el meme del año, Nico del Caño?

A veces estos chistes incluso terminan siendo aplicaciones de verdad, como una aplicación para coordinar car pooling (GitHub :: catapult).

No tengo una buena recomendación para estos proyectos "chistes", más que intentar hacerte pensar que no necesariamente un proyecto tiene que ser completamente serio; y son muchas veces estos proyectos que se combinan y que sirven de lugar para aprender nuevas tecnologías o metodologías. Y te podrían brindar un armazón para proyectos al futuro.

Level 9000 - Todas las anteriores

Lamentablemente, la “creatividad” no es un proceso súper directo. A veces algo sale por un lado, a veces por otro. A veces 2 ideas inconexas se conectan en una idea mejor.
Personalmente, me gusta escribir estas esbozos de ideas en un receptáculo físico. hay quienes prefieren un archivo en la computadora. Hay quienes tienen varios pre-ideas en la mente a la vez y nueva información decanta esas pre-ideas en un proyecto.

Gracias por tu tiempo, y espero que algo de todo esto te ayude a encontrar inspiración!

La imagen de la portada es de Jo Szczepanska en Unsplash

Glosario:
1: driver: Un factor que hace que suceda o se desarrolle un fenómeno particular.
2: tinkering: Intentar reparar o mejorar algo de manera casual o poco metódica.
3: otp: One-time password

Haskell para mentes imperativas

Joaquin "Florius" Azcarate — Thu, 03 Dec 2020 20:38:38 +0000

Foto de portada por Edurne Chopeitia en Unsplash

Browseando YouTube encontré una playlist con un nombre muy interesante: “Haskell for Imperative Programmers” en donde el autor Philipp Hagenlocher explica conceptos de Haskell en videos cortos, concisos, con varios ejemplos y hasta algunos ejercicios. Lo que me inspiró a pensar cómo podría aprender alguien que tiene raíces en un paradigma imperativo. Por suerte no tuve que usar mucho la imaginación, ya que yo comencé con lenguajes imperativos, y en mi trabajo utilizo mayoritariamente el paradigma de objetos.

En este post quiero explorar algunas cosas que creo que me hubiesen servido para aprender Haskell. Teniendo una base en algún lenguaje imperativo, usar esta para programar en Haskell.

Si crees que entras en esta categoría, continúa leyendo.

Prefacio

En este post haré uso de analogías y de patrones fuertemente asociados a la programación imperativa, de tal forma que la carga para aclimatarse al nuevo paradigma sea la menor posible, pero no considero esta la mejora forma de programar de forma funcional. Mi razonamiento es que: usando nuestro conocimiento previo ayude a comenzar a escalar la pendiente que es aprender un paradigma nuevo, y que esto a su vez dispare nuevas e interesantes investigaciones.

Variables

Veo muy comúnmente la cara de espanto cuando uno habla de un lenguaje, como Haskell, donde la inmutabilidad está por defecto. Prontamente surge la pregunta de “cómo puedo asignar una variable” o “como puedo cambiar el valor de un contador”.
Recordemos que Haskell es un lenguaje de programación Turing completo, así que no es que no se pueda hacer, solo que hay que reconocer que hay diferentes formas de afrontar un problema.

En Haskell, el símbolo = no representa una asignación, si no es más próximo a la idea matemática del = donde lo leemos (e interpretamos) como que algo es otra cosa.

En un lenguaje imperativo x = 3 lo leemos como “asignamos el valor 3 a la variable x”, donde en un paradigma funcional, lo deberíamos interpretar como “x es 3”. x no puede cambiar. x simplemente es.

Se que esta justificación suele no quitar el pavor. Tras indagar más a fondo, suelo descubrir que hay dos temas distintos (pero muy sobrelapados en los lenguajes imperativos):

Ponerle nombre a algo “intermedio”. Por ejemplo, si uno está escribiendo un método, y ve que hay una operación que se repite dos veces, suele ser considerado una buena práctica extraer lo común a una “variable” y ponerle nombre. Por ejemplo, podríamos empezar con un método:

Int foo(List<Int> xs) {
  if(xs.size() > 3)
    return -1;
  else
    return xs.size();
}

y luego refactorizar a algo como:

Int foo(List<Int> xs) {
  Int tamaño = xs.size();
  if(tamaño > 3)
    return -1;
  else
    return tamaño;
}

En este acaso tamaño si bien es una “variable”, su intención no es variar en el contexto de la función. Es tan común y útil poder aseverar sobre qué cosas no cambian, que en otros lenguajes existe la idea que las “variables” puedan ser constantes (vaya oxímoron). Como const en JavaScript y PHP, val/varen Kotlin, variables en mayúsculas en Python o final en Java.

Lectores atentos pueden reconocer un potencial problema en esta refactorización, en donde no podemos asegurar 100% que el método List::size() no cambia la lista, y que invocarlo 2 veces como en el código de “antes” podría no ser igual al código de “despues” en donde solo se invoca una vez. Dado que conocemos la semántica de List::size(), podemos descansar que no va a alterar la lista; pero a veces, por la naturaleza de la mutabilidad, esto lleva a problemas. Toda una categoría de problemas que simplemente no pueden ocurrir en un mundo inmutable 😉.

Esto mismo podríamos lograr en Haskell con palabras reservadas como let … in o where.

foo :: [Int] -> Int
foo xs = if length xs then
         -1
       else
         length xs

Y luego del refactor:

foo :: [Int] -> Int
foo xs =
   let tamaño = length xs
   in if tamaño > 3 then
         -1
       else
         tamaño

foo :: [Int] -> Int
foo xs = if tamaño > 3 then
         -1
       else
         tamaño
   where tamaño = length xs

Si bien hacen lo mismo, tienen sutiles diferencias a las entraré en detalle (pero si está aquí: Let vs. Where - HaskellWiki).

Cosas que cambian

El otro sabor de variables, es el de algo que cambia; y aquí, no tenemos suerte. No vamos a poder hacerlo. Pero eso no quita que podamos generar abstracciones para poder escribir algo que se parezca.

Pero antes de hablar de cosas que cambian, primero necesitamos estar de acuerdo en algunas convenciones. Cosas como

void bar(int* x){
    *x += 4;
}

En donde una función altera el valor que se le pasa son el mal, y no poder hacerlo es un feature (Aunque me encanta la idea de Pure destination-passing style in Linear Haskell cuando se apalanca del maravilloso sistema de tipos).

Algo mucho más sensible sería una función que tome el argumento y devuelva un nuevo número, resultado de la suma del argumento y 4.

Pero no siempre es tan sencillo. A veces tenemos varias mutaciones encadenadas, o unas que dependen de otras; por lo que podemos aplicar este algoritmo mental:
Cada vez que fuésemos a cambiar una variable, en realidad utilizaremos una nueva variable que sea el resultado del cambio, y de ahora en adelante, utilizar el nuevo nombre.

Por ejemplo, con la nueva herramienta de let … in:

def buzz (n)
  ret = n
  ret = ret % 3
  ret = ret +2
  ret = ret + 5
  ret > 3
end

buzz n =
  let 
       x0 = n
       x1 = x0 `mod` 3
       x2 = x1 + 2
       x3 = x2 + 5
  In x3 > 3

Si esta forma de escribir parece tediosa (lo es!), al final de la próxima sección volveremos sobre esto, pero todavía tenemos algo que podemos hacer. Revisemos qué es lo que es tan inconveniente: nombrar los pasos intermedios (x0 - x3) ¿Podemos no hacerlo?.

De esta forma nos acercamos a un patrón muy común en funcional, en donde uno tiene funciones intermedias que toman un valor, y devuelven “el nuevo” valor. Podemos concatenar estas operaciones (que hablan de cambios, no de variables).

Imaginemos el mismo ejemplo, pero vamos a re escribirlo en pequeñas funciones intermedias que cambien el valor.

buzz n =
  let f0 x = x `mod` 3
       f1 x = x + 2
       f2 x = x + 5
       f3 x = x > 3

       x0 = n
       x1 = f0 x0
       x2 = f1 x1
       x3 = f2 x2
  In f3 x3

Lamentablemente como es un ejemplo tan sintético, los nombres de las funciones intermedias serán malos; pero espero que puedan imaginarse que estas funciones sean cosas como incrementarEdad, extraerDinero u otro nombre más cercano al dominio de lo que esten programando.

Por ello voy a cambiar levemente el ejemplo para tener algo que sea más humanamente legible.

numeroValidador x = x `mod` 3
normalizarValidador x = x + 2
migrarCoeficiente x = x + 5
esValido x = x > 3

tarjetaValida n =
       x0 = numeroValidador n
       x1 = normalizarValidador x0
       x2 = migrarCoeficiente x1
  In esValido x2

Ahora podemos intentar pensar sobre nuestra tarjetaValida, donde lo que tiene que pasar es, en orden:

Dado un número pasado como parámetro (n)
Tomamos el número validador (x mod 3)
Lo normalizamos (x + 2)
Migramos el coeficiente (x + 5)
Y chequeamos que sea válido (x > 3)

Probablemente todavía no sea evidente, pero ahora podemos hacer un refactor de “inline” en cada variable intermedia (x0 - x3). Empecemos con x3 e iremos ineline-ando de a una

tarjetaValida n =
       x0 = n
       x1 = numeroValidador x0
       x2 = normalizarValidador x1
  In esValido (migrarCoeficiente  x1)

tarjetaValida n =
       x0 = n
       x1 = numeroValidador x0
  In esValido (migrarCoeficiente  (normalizarValidador  x1))

tarjetaValida n =
       x0 = n
  esValido  (migrarCoeficiente (normalizarValidador (numeroValidador x0)))

tarjetaValida n =
  esValido  (migrarCoeficiente (normalizarValidador (numeroValidador n)))

Esto se parece mucho más a la descripción funcional de tarjetaValida, pero está escrito “al revés”. Por razones como esta existen combinadores como &, donde hablando mal y pronto, éste es el operador de aplicación reversa.

tarjetaValida n =
  n &
  numeroValidador &
  normalizarValidador &
  migrarCoeficiente &
  esValido

Es interesante notar como todas nuestras funciones de “cambio” tienen la misma firma: :: Int -> Int. De forma más genérica, son funciones que toman un valor de un tipo, y devuelven algo del mismo tipo.

Aplicación parcial

Con el código que tenemos hasta aquí; podríamos cambiarlo para que migrarCoeficiente no siempre sume 5, si no que pueda ser parametrizable por una letra.
Sabiendo que hay una función que transforma una letra a un número ord :: Char -> Int
Podríamos cambiar migrarCoeficiente a:

migrarCoeficiente :: Char -> Int -> Int
migrarCoeficiente letra x = x + (ord caracter)

Ahora nuestra tarjetaValida no sufre muchos cambios:

tarjetaValida n =
  n &
  numeroValidador &
  normalizarValidador &
  migrarCoeficiente 'f' &
  esValido

Y eso fué gracias a la currificación de todas las funciones en Haskell!

A veces

Otro gran “hack” que nos permite la mutabilidad, es la de cambiar el valor, pero solo según un flujo de control. Algo como:

def qux(n):
  ret = n
  if(ret % 3):
    ret = 10
  return ret

En donde asignamos una variable que según uno u otro flujo de control puede cambiar. Siempre podremos reescribir esto de forma inmutable. Por ejemplo

qux n = if n `mod` 3 == 0 then 10 else n

Interesante notar que necesitamos un else que “deje todo como estaba”, pues no podemos “no hacer nada” en esta forma de escribirlo.

Monadas

(No podía ser un post de Haskell, y no mencionar a las monadas)

Una idea en la programación imperativa muy arraigada es que uno escribe una línea debajo de la otra, y esto hace que se ejecuten en ese orden.
Tan arraigada que casi no se considera una decisión del lenguaje, pero lo es! Es una decisión de diseño, y una que en un paradigma funcional es fácil escaparse.

Pero a veces, queremos ordenar una secuencia de cosas. Recordemos el ejemplo anterior de buz. Hay una monada (y probablemente miles de tutoriales de como implementarla) llamada “state” que representa una forma de secuenciar operaciones, e ir mutando un valor. Por lo que uno podría escribir algo mucho más parecido a la forma imperativa:

--            |----- Va a ir mutando un Int
--            v   v- va a retornar un booleano
buz :: State Int Bool
buz =
  get >>= (\ret -> set (ret `mod` 3)) >>
  get >>= (\ret -> put (ret + 2)) >>
  get >>= (\ret -> set (ret + 5)) >>
  get >>= (\ret -> return (ret > 3))

Cada ret en este caso solo existe dentro del lambda (todo lo que esté entre (\ y ))

Muchas veces se ven las monadas con el azúcar sintáctico de la notación do, que lo hace muy conveniente porque nos deja, como en un paradigma imperativo, escribir una línea debajo de la otra.

Monadas Cont.

Otra gran razón para implementar una secuencia de operaciones, es que estas puedan fallar. El fallo en cualquier renglón invalide toda la computación. Pensemos en métodos que podrían lanzar excepciones.
Para esto también existe una monada! Y podríamos escribir algo como:

func precio(itemConNombre nombre: String) throws {
        guard let item = inventario[name] else {
            throw Errores.noExiste(nombre: nombre)
        }

        guard item.cantidad > 0 else {
            throw Errores.fueraDeStock
        }

        item.price
}

De esta forma

data Errores = FueraDeStock | NoExiste String

buscar :: Inventario -> String -> Maybe Item
buscar = (...)

precio :: String -> Either Errores Int
precio nombre = do
    item <- maybe (Left (NoExiste nombre)) Right itemEncontrado -- (1)
    when (cantidad item > 0) (Left FueraDeStock)
    return precio item
  where
    itemEncontrado :: Maybe Item
    itemEncontrado = buscar inventario nombre

La idea de la función maybe es poder extraer el valor de un Maybe (algo que puede o no estar). En el caso de que pueda fallar, devolveremos un Left (recordemos, representaría como lanzar una excepción), y en el caso que hubiese un Item, devolveremos un Right.

De esta forma, no ejecutaremos el return hasta que no pasen las dos condiciones anteriores.

Getter y Setter

Por último, quiero tocar algo de modelado, y la parte de lo que menos quiero escribir, porque es la que más se separa del paradigma; pero no obstante puedo ver cómo alguien puede estar tentado a utilizar herramientas de modelado de paradigmas que ya conoce, y pensar en un record es parecido a un objeto. Pero si así fuera… donde ponemos los métodos de este objeto?! (Sin entrar en el mundo de lens).
No voy a objetar (🤭) porque se que yo lo hice durante mucho tiempo, así que mientras que sepamos que hay tela para cortar, por ahora puedo vivir con que pensemos que son objetos.

class Point
{
    public int edad;
}

podríamos escribirlo así:

data Persona = Persona { edad :: Int }

Y tendremos gratis la función edad :: Persona -> Int que “saca” la edad de una persona. Cual un getter, y la construcción:

cambiarEdad :: Int -> Persona -> Persona
cambiarEdad nuevaEdad persona = persona { edad = nuevaEdad }

Como un setter. Pero, como en OOP no estamos limitados a simplemente asignar el nuevo valor; podríamos hacer lo que queramos!

cambiarEdad :: Int -> Persona -> Persona
cambiarEdad nuevaEdad persona = persona { edad = nuevaEdad + 3 }

Podemos encontrar un patrón recurrente, donde tengamos funciones que terminen con el tipo: foo :: … -> Algo -> Algo. Si recordamos el ejemplo de tarjetaValida, todas las funciones intermedias que teníamos eran del tipo: :: Int -> Int, y el ejercicio al lector hubiera generado una función con el tipo: :: Char -> Int -> Int. Podemos pensar en toda esta familia de funciones como funciones que “alteran”. Además ahora ya sabemos cómo combinarlas!
Por ejemplo, concatenar listas (++) :: [a] -> [a] -> [a] en donde toma una primera lista y una segunda, y las “altera” (recordando que en realidad lo que hace es devolver una nueva lista) o tomar los primeros n elementos (take :: Int -> [a] -> [a]). Hay muchísimas funciones como estas, y probablemente escribamos tantas de estas como “métodos” podrían tener nuestros objetos, si lo modelamos en OOP.

class Persona(var edad: Int, var altura: Int) {
    fun crecer(años : Int) {
                 this.edad += años
                 this.altura += años*2
    }
}

data Persona = Persona { edad :: Int, altura :: Int }

crecer :: Int -> Persona -> Persona
crecer años persona = Persona { edad = edad persona + años,  altura = altura persona + (años * 2) }

Fin

Espero que con estas herramientas, el prospecto de programar en Haskell sea menos aterrorizador.

koncierge 🛎 :: Una librería para segmentar usuarios

Joaquin "Florius" Azcarate — Wed, 14 Oct 2020 13:50:58 +0000

Trasfondo

En donde estoy trabajando, cada nuevo feature o idea, pasa por un proceso de A/B Testing.
Normalmente lo que hacemos es:

Generamos una hipótesis del estilo: "Si los usuarios tuviesen una notificación cuando pasa X, entonces van a hacer Y más seguido".
Desatollamos esta notificación, o lo que sea.
Apuntamos a algún mercado para participar de esta prueba
Dividimos a la mitad de los usuarios de ese mercado, tal que vean e interactúen con en nuevo feature, mientras que la otra mitad (grupo control) no.
Esperamos dos semanas
Comparamos las métricas entre los dos grupos.

Este último paso puede llevar a miles de ramificaciones: Activamos el feature para toda la población. Cambiamos algo y volvemos a hacer una prueba. Lo deshabilitamos por completo porque nuestra hipótesis era incorrecta. Etc, etc.

Para la segmentación de la población, estamos usando un servicio de un tercero. A este servicio, ocasionalmente le brindamos la información de segmentación de nuestros usuarios.
Información como

El usuario 123 es de Madrid
para que luego, cuando queramos segmentar, podríamos segmentar solo usuarios de Madrid.

Este servicio externo, adicionalmente, solo nos provee acceso a las variantes (si un usuario pertenece al segmento, es parte del grupo de control, o es parte del grupo que participa) mediante un SDK para usar en móviles (iOS y Android).

Esto nos presentaba dos dificultades:

Si quisiéramos hacer un A/B Test en alguno de los micro-servicios de backend, no podríamos consultar a este servicio.
Si quisiéramos segmentar por algo de lo que no le habíamos informado al servicio, deberíamos compartirle toda esta nueva información para que este pueda segmentar.

Por esta situación, decidimos crear un micro-servicio que se encargue de segmentar y separar en variantes a nuestros usuarios.

Problemas

Rápidamente nos vimos enfrentados a resolver como hacer para obtener la información para segmentar.

Normalmente segmentamos por país, lo que sería sencillo hacer que el nuevo micro-servicio consultara con otro micro-servicio de información; y obtuviese el país del usuario.
Con esta nueva información, podríamos segmentar.

Lo que presenta un desafío interesante:

Como evitar que este micro-servicio crezca cada vez introduzcamos un nuevo micro-servicio que almacene alguna información del usuario?

Por eso, pensamos que podríamos delegar la responsabilidad de obtener el contexto del usuario, a quien consuma este micro-servicio; por lo que una llamada podría ser:

Dado el usuario 123, de Madrid; a qué variante pertenece?

De esta manera, es quien consume quien necesita saber todas las dependencias del experimento, y cada experimento puede tener dependencias distintas, de distintas formas de computarse, y el micro-servicio podría no crecer.

DSL (Domain-specific language - Lenguaje específico de dominio)

Ya sabíamos como querríamos que se comporte el micro-servicio, ahora necesitábamos una forma de expresar como querríamos segmentar nuestra población. Hacía poco estaba trabajando mucho con Mongo y se me ocurrió que un lenguaje de consultas como el de mongo podría ser interesante de explorar.
De tal forma que una segmentación como:

Quiero que solo participen del experimento EXP001, usuarios quienes sean de Madrid. De estos, la mitad estarán en el grupo de participando y el esto en control.

Se transformaría en:

{
  "EXP001": {
    "ubicación": "Madrid",
    "$children": {
      "participando": { "$rand": { "$gt": 0.5 } },
      "control": {}
    }
  }
}

Playground

De esta manera, quien consuma al micro-servicio debería proveer, al menos, la información de la "ubicación" del usuario.
Una posible consulta podría ser con el contexto:

{
    "ubicación": "Madrid",
    "userId": 5
}

El micro-servicio debería responder que pertenece al EXP001 (dado que la ubicación empareja con la definición), y podría pertenecer a la variante participando o control.
Los usuarios deberían estar distribuidos 50%-50%; dado que hay un 50% de probabilidad que un numero al azar, uniformemente distribuido entre 0 y 1 (como es $rand) sea mayor a 0.5.

Con esta idea, sabiendo que la intención era que el micro-servicio no dependiente de ninguna otra parte de arquitectura de nuestro ecosistema; se me ocurrió que podría desarrollarlo como una librería pública; por si alguien más tiene la necesidad que tuvimos nosotros.

koncierge 🛎

La librería está en GitHub/jazcarate/koncierge

Cover image by Nicolas Cool on Unsplash