Feda /dev/ - No Javascript allowed

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

#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.

#34899 Hola leos, yo uso onenote

#34899

Notion

#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

yo llegando al debate de fperos de hoy

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

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

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

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.

#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.