Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




MTX_Anubis

#33057 Pues ahí tienes varias posibilidades:

  • Varias particiones y meter cada tipo en la particion que corresponda. Cada consumer se registra en las particiones que quiere consumir. Esta solución es muy mala y no es como está pensado para usar las particiones (que están pensadas para paralelizar y escalar de forma horizontal el consumo de mensajes). Además no podrías añadir más consumers del mismo grupo a una particion.

  • Cada consumer lee todo y filtra lo que le interesa (no lo quieres hacer).

  • Lo que se suele hacer: Tienes un consumer group de ese topic que redistribuye los mensajes a otros topics dependiendo del tipo.

De tal forma que tendrías el topic OrdenCompra, un consumer que lee todo y va metiendo los mensajes en los topics OrdenCompraCarnicería, OrdenCompraPescadería, etc...

Y la carnicería y pescadería y demás solo leerían de su topic.

No sé si con los Streams se pueden hacer otras cosas porque no los he usado (y de hecho hace mucho que no toco kafka así que quizá haya más formas de hacerlo)

3 respuestas
Kaledros
#33061MTX_Anubis:

De tal forma que tendrías el topic OrdenCompra, un consumer que lee todo y va metiendo los mensajes en los topics OrdenCompraCarnicería, OrdenCompraPescadería, etc...

Esto lo hicimos nosotros en la versión anterior del proyecto, antes de cambiar a Rabbit. Era un servicio sencillo, escalable y te solucionaba la papeleta muy bien.

2 respuestas
wdaoajw

#33061 #33062 se supone que Streams está para eso, pero nunca lo he usado

1 respuesta
desu

#33061 Si el fanout me parece el mas natural.

#33063 Exacto, en teoria el kafka stream te hace un fanout internamente gestionando todo esto y te ahorras de configurar las cosas a mano, pero no se como va.

Por eso pregunte, lo mismo hay otra alternativa XD

En mi cabeza la primera solucion ha sido kafka stream filtrando/branchin consumiendo de una state store.

Pero no lo he hecho nunca.

1 respuesta
JuAn4k4

#33064 La primera solución que se viene a la cabeza es hacer la jerarquía, pero vamos estas volviendo a pasar por Kafka todo. Otra solución es que el consumer sea genérico y sepa procesar las dos tres cosas (hacer pub/sub interno). Pero eso ya depende de cuánto de disperso sean los dominios de esos mensajes y cuantos tipos hay.

PaCoX

more topics

MTX_Anubis

#33062 Es la solución por defecto en las primeras versiones (antes de que metieran streams por lo visto). De hecho era un caso de uso que aparecía en su guía con el logging de una aplicación.

Todo se enviaba a logs y de ahí un group consumer lo iba distribuyendo a log_error, log_warning, log_blablabla

1
Ranthas

#33060 Que te gusta ingerir cosas, cochino

1
desu

Chavales, espectacular... haciendo TDD... en Java...

3 horas y no hemos conseguido que el mockito funcione...

Esto con alguien que pilota de tdd, java y mockito XD no se cuantos beans, configurations y mierdas.

al final le digo, bueno implementamos la interface e ya no??? XDDDDDDD

y eso vamos a hacer

edito: ya he acabado 6 minutos he tardado en hacer lo que hemos estado desde las 14h... XDDDDDDDDDDDDDD

putos javeros, opperos, tdderos y demas...

HAHAHAH

1 respuesta
isvidal

#33069 a ver desu aun resuena en el hilo tu mitico stream donde no pudiste levantar una maquina virtual con un hello world creo

1 respuesta
desu

#33070 2 horas vs 6 minutos

B

siempre quedará en mi memoria cuando en un directo de fast api se puso a consultar mi blog (sin saber que era mío)

5 1 respuesta
desu

#33072 y no conseguimos pasar del hello world...

da que pensar

4
Lifecasi0

Todo para decirnos que no sabe de java, ni de mockito.

JuAn4k4

Haciendo pair programming La mitad de devs se bloquea

1 respuesta
desu

#33075 es que hacer pair para algo que no tienes super claro es perder tiempo. imo.

yo prefiero hacerlo solo.

solo hago pair si estoy ense;ando algo que tengo claro.

el problema era, ponte a hacer tdd con spring boot, con mil beans y componentes, moqueando todo, con archivos de configuracion para dev/test/pre/pro y docker composes... todo a la vez XD

y yo le digo al final, a ver illo, esto yo lo haria poco a poco hard coded hasta que funcione... luego si eso lo voy pasando a archivos de config o lo que sea y mockeo al final para cubrir todo...

mucho tdd pero ha hecho la casa toda a la vez... de toda la vida se hardcodea todo guarro hasta que funcione lo mas facil y simple posible. ni mocks ni pollas de tdd.

1 respuesta
Kaledros

Vengo, digo que hacer unit tests cuando ya tienes el proyecto hecho no tiene nada que ver con TDD y me voy.

2 respuestas
B

#33077 TDD no es el TDD que tu conoces... realmente habla de "Tu Dios Desu"

1
desu

#33077 donde he dicho que hacer tdd sea eso tonto

1 1 respuesta
Kaledros

#33079

#33076desu:

ponte a hacer tdd con spring boot, con mil beans y componentes, moqueando todo, con archivos de configuracion para dev/test/pre/pro y docker composes

1 respuesta
desu

#33080 eso es lo que ha querido (e intentado) hacer el. TDD y ademas haciendo todo eso en spring boot con autowiring con beans y pollas.

yo le he dicho al termina, que por mi, a mi estilo, (EL MEJOR) haria el codigo poco a poco guarro y facil con test minimos, luego refactorizas lo hardcoded por las configs, y al final de todo si quieres cubrir mas casos a;adir mocks cuando ya esta toda la base dise;ado

venga va, no nos enfademos, quizas me he explicado mal y los fperos no sabeis programar mucho

los que me habeis visto programar en STREAM y leais mi BLOG sabeis que defiendo la filosofia forth e iterar las cosas muchas veces. como por ejemplo hacia joe amstrong creador de erlang

https://github.com/lukego/blog/issues/32

"Joe wrote amazingly simple programs and he did so in a peculiar way. First he wrote down the program any old way just to get it out of his head. Then once it worked he would then immediately create a new directory program2 and write it again. He would repeat this process five or six times (program5, program6, ...) and each time he would understand the problem a little better and sense which parts of the program were essential enough to re-type. He thought this was the most natural thing in the world: of course you throw away the first few implementations, you didn't understand the problem when you wrote those!"

como puedes escribir tests sin antes haber explorado el problema... si no has hecho muchas soluciones nunca ENTENDERAS el problema.

los tests solo deben a;adirse para evitar regresiones.

Hacer TDD es como ser virgen, ver 10 videos porno al dia y luego hacerte coach sexual, ense;ando a los fperos a como hacer correr a su pareja.

Wei-Yu

yo tengo muchas ganas de hacer pair programming pero aún no pude )):

sólo hice un par de veces antes de empezar a currar que tenía menos idea ahora si cabe y bueno medio medio xd

pero en el curro me apetece un montón

JuAn4k4

Competitive debugging https://twitter.com/rawkode/status/1493963894624337929

desu

Se me atraganta spring, algun experto en la sala? Abro stream y me echa una mano?

Quiero tener N packages, con N contextos. Que hago autowire automaticamente, sin beans de la config. Solo quiero leer las configuration properties de la carpeta resources.

Es decir quiero tener una clase Foo, con un field name = ${foo.name}. Y que en application.yml definir foo: name: "foo-name"
Lo mismo pa Bar y asi...

@Component
public class Foo {
  public String name;
}

// application.yml
my:
  foo:
    name: "foo-name"

Quiero poder hacer:

@Autowired
Foo foo // que aqui se configure el name

public void main() {
	System.out.println(foo.name); // aqui printar "foo-name"
}

El objetivo final es tener contextos independientes en los tests. PAra cada paquete un contexto. Asi no hace falta definir los beans ni cargar mierda que no necesito en el contexto.

1 respuesta
Kaledros

#33084 ¿No te vale con hacerte una clase de configuración por cada package que instancie todo eso al arrancar y lo sirva como singletons?

1 respuesta
desu

#33085 Eso lo he mirado... No estoy seguro. Pero quizas vas bien encaminado y es la unica manera de lograr esto. Porque para hacer autowire si o si neceistas un bean.

No tengo ni idea de como hacerlo...

MI objetivo final, por si ayuda es tener este tutorial: https://www.baeldung.com/spring-boot-kafka-testing

La parte de kafka-embedded.

Como creo una configuracion con los beans de esa mierda? Ni idea. Aqui ando. Con un proyecto vacio de spring mirando de entender como va XD

edit: Abri stream si alguien se quiere pasar a ayudar XD

1 respuesta
Kaledros

#33086 Nosotros hacíamos (en pasado, porque nos dio problemas de acoplamiento y lo quitamos, pero puedes probar) una clase de configuración por package que implementaba ApplicationContextAware. Eso te obliga a implementar setApplicationContext(), pero como lo anotabas con @Configuration te hacía el autowire automático.

Luego sólo tenías que declarar el método que quisieras y llamar al ApplicationContext. Así:

@Configuration
public class MyApplicationContext implements ApplicationContextAware {

  protected ApplicationContext context;

  @Override
  public void setApplicationContext(@NonNull ApplicationContext applicationContext)
      throws BeansException {
    this.context = applicationContext;
  }

//...

public <T extends OurPropertiesInterface> T getProperties(Class<T> propertiesClass) {
    return this.context.getBean(propertiesClass);
  }

Luego defines las properties para que las coja del application properties:

@Configuration
@ConfigurationProperties(prefix = "my.prefix")
public class MyPrefixProperties implements OurPropertiesInterface{
  //...
}

Y cuando necesites una MyPrefixProperty haces MyApplicationContext.getProperties(MyProperties.class) y a correr.

1 1 respuesta
desu

#33087 pff no me tira ni el junit5 ... tengo un test con assert(true) y no se ejecuta... XDDDDDD

vincen

Alguien de aquí trabaja para bbva? Que habéis liado?

2 2 respuestas
PaCoX

mejor app de banca del mundo ®

1 respuesta

Usuarios habituales