Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




desu

#34890 es como lo tengo.

Tengo una cache y cliente por endpoint porque va así al tener service discovery, load balancer, retry etc y un wrapper por servicio.

Igualmente la cache dentro del cliente necesita una nombre XD

1 respuesta
JuAn4k4

#34891 Entonces, solo “caché”, Que contradice lo que dije.

1 respuesta
frekaice

#34826 Lo que comentas de ir sin rumbo me recuerda a mi actual empresa y cada vez más cansado de dar vueltas en círculos. Muchos ánimos en la búsqueda de la siguiente!

Me tomo como apuntes lo del #34818 porque creo que a medio plazo voy a realizar un cambio

desu

#34892 pero tienes N caches...

type cachedService struct {
  clientA
  clientB
  clientC
  cacheA
  cacheB
  cacheC
}

cada cache y cliente por cada endpoint, puedes hacer esto

type cachedService struct {
  type A struct {
    client
    cache
  }

  type B struct {
   client
   cache
  }

  type C struct {
    client
    cache
  }
}

pero entonces si haces refactors cuesta mas, tienes las cosas potencialmente separadas, no sabes que cache es de que tipo, no tienes ningun beneficio en el layout, las llamadas no tienen el prefijo y como ya encapusles su uso en una funcion no sabras si son cacheadas o no.

otra alternativa es tenerlo generico, pero a la que quieras cambiar una implementacion concreta ya no te vale. y tendras que empezar a meter interfaces, lo que vas a acabar haciendo es implementando la API que tu client y cache the ofrecen XD. y volveras al paso 1).

yo lo hice generico y cuando termine lo deshare.

2 respuestas
Frave

#34894

yo lo hice genérico y cuando termine lo deshare.

uhh eso igual es muy de fpero eh yo no digo nada.

1 respuesta
desu

#34895 bueno era un claro ejemplo de parametrico...

type foo[T internal] struct {
   lock sync.Mutex
   data map[string]T
]

como sabia que despues la implementacion de algun metodo se complicaba porque T era algo complejo y necesitabas el trait internal me parecio buena prueba para go. ya que esto estaria en sus limites de capacidad.

comparado con traits no puedes extender un slice o un *T directamente, creo que neceistas un type alias pero lo deje ahi.

aunque se puedo hacer eh y en lugar de hacer 300 loc de copy pastes, te haces 100loc.

yo es que cuando veo que me acerco en territorio de disjuncion de traits, type encoding y demas.... pienso que es mejor no implementarlo. en este caso mi code base tiene 4 a;os y se que no va a cambiar lo que toco, por eso es un buen uso, pero new code no es una buena idea.

si no es una estructura de datos como mi caso, algo iterable o traversable, tiene poco sentido.

JuAn4k4

#34894 No puedes tener 3 clientes y 3 cachés si metes la caché dentro del cliente. De forma que al usar el cliente, de forma transparente usas la caché. Así tendras 3 clientes, y en cada cliente 1 cache. Con el patrón decorator puedes cambiar que caché se usa y como se usa de forma que ese comportamiento está separado de la impl del cliente. Incluso puedes meter L1 y L2 caché, yo he usado esto alguna vez, fichero en disco (L2) y en memoria (L1), la implementación es un delegate que usa mem-repo/file-repo y así tengo 73737 capas de abstracción

1 respuesta
desu

#34897 no entiendo. el cachedService llamalo cachedClient, para cada cachedClient tengo N endpoints (client) y para cada endpoint tengo su cache (cache).

lo que dices es lo que estoy implementando. mi cachedService/cachedClient es tu decorador.

mi cachedService, al usarlo, de forma transparente usa una cache. correctisimo. tanto la cache como el cliente son interfaces correcto tambien.

tengo un servicio para realizar llamadas, que para cada endpoint puedo usar un sd, retry, lb custom, y una cache custom. de hecho algunos de estos los vamos a pasar de poll a push despues del refactor.

newfag

¿Conocéis alguna página como evernote? Funciona fatal para según qué funcionalidades

2 respuestas
B

#34899 Hola leos, yo uso onenote

1 1 respuesta
newfag

#34900 Muchas gracias Jastro

Zoko

#34899

Notion

1 2 respuestas
B

#34902 hipster!

newfag

#34902 onenote me ha gustado bastante, busco un formato donde poder documentar cosas de forma ordenada, sin llegar a ser notas casuales ni tampoco un tfg

1 respuesta
TitoBurns

Notepad y arreando maldita panda de hipsters

Kaledros

#34904 Google Keep.

1
Leos

Roba una libreta para las notas que se te da bien lo de robar

7
desu

yo llegando al debate de fperos de hoy

en el bikeshedding de hoy, que usar para apuntar cosas que luego no vas a leer

1 respuesta
B

#34908 Que va, yo las cosas que no voy a leer las meto en la lista de lectura del navegador

4 1 respuesta
desu

#34909 deberia ser tu pagina de inicio, tuya y la de todos.

cargo el peso de la industria en mis hombros.

1
vivora

Sabéis de alguna web o API que te genere una persona con su foto aleatoria?

1 respuesta
newfag

#34911 https://generated.photos/face-generator/

1 respuesta
vivora

#34912 Para un TFG, entiendo que puedo utilizar estas imágenes sin ningún tipo de problema de licencia no?

1 respuesta
newfag

#34913 Imagino que mientras utilices su marca de agua no, no estoy seguro, deben matizarlo en sus condiciones.

1 respuesta
vivora

#34914 No he visto nada de fines educativos, tan solo fines comerciales, que no es el caso.

Wei-Yu

Entregué hace poco una prueba técnica offline en la que había una pregunta sobre un race condition. Os pongo un ejemplo parecido a nivel conceptual.

El sistema es un scheduler de mensajeros, en el que se busca mensajeros que tengan capacidad >= X para poder darles mercancía. El race condition que proponían se daría si, mientras se está haciendo esa búsqueda, uno de los mensajeros recoge un paquete y se actualiza su capacidad, anulando así la posibilidad de que pueda recoger el paquete que se le asignaría.

Ej. si un mensajero tiene capacidad 30 y mientras se está preguntando por los que tienen hueco para un paquete de 25, ese mismo mensajero coge un paquete de 10 y ya no tendría hueco para el que se le quiere asignar.

Alguien me aporta su razonamiento?

p.d: está entregadísima la prueba, pinky promise no haré trampas con las respuestas.

1 respuesta
Fyn4r

Esto es el problema de los barberos?

1 respuesta
Wei-Yu

#34917 según leo eso es acceder a un shared resource (el barbero) y con el mutex te lo quitas. Aquí el mutex según entiendo tendría que ser sobre el recurso entero que mantiene las refs de los mensajeros. Por ejemplo, si es una tabla te comes un table lock.

1 respuesta
MTX_Anubis

#34916 No entiendo muy bien la pregunta, el race condition es obvio si hay acceso en paralelo de lectura y luego de escritura. Es decir si por un lado funciona el scheduler y por otro el mensajero puede escoger paquetes.

Scheduler: Lista mensajeros con capacidad de >=25
Mensajero X con 30: Cojo paquete de 10
Scheduler: Asigna a mensajero X el paquete de 25 (mensajero X aquí tiene ya capacidad de 20, no de 30)

1 1 respuesta
PaCoX

un lock antes del check?
quitar la posibilidad de shared state reservando espacio antes de la recogida?