Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




aren-pulid0

#11940 cuanto te mide el sueldo?

1 respuesta
afhn

#11941 por encima de la media española xd

Lifecasi0

Tampoco es difícil.

1
afhn

Sólo pocos podrían decir por encima de la media nigeriana. xdd

1
desu

He seguido los consejos de padre y del abuelo.

Ando leyendo: Kafka definitive guide (lo puedes encontrar en google)

Y ahora entiendo todo mucho mejor y las respuestas que me disteis.

Es un buen libro creo para empezar, no es muy pesado. Trata todo sobre dos puntos de vista:

Que es kafka y como usarlo para desarrollar, lo que yo busco.
Sistemas, configuraciones, clustering... esto no me lo estoy leyendo pero es importante.

Estoy haciéndome un resumen si alguien lo quiere que me lo pida y se lo comparto.

El tema de sistamas/configuraciones me parece muy interesante y la verdad es critico para que todo funcione, no hacer sobre iniginieria etc… pero no le puedo dedicar tiempo y no es mi problema ahora mismo xd

Tan solo me ha surgido una duda relacionada con el tema de usar kafka como stream-table duality y recrear db o eventos. Esto he leído que es mala practica: https://news.ycombinator.com/item?id=23206566

1 respuesta
Fyn4r

Mucho me cabrean a veces las putas reuniones, creo que no hay nada que odie más que sentir que me están haciendo perder el tiempo. Ya, debería cambiar de sector xD

Explicas una movida "esto falla por X, Y, Z, voy a modificarlo siguiendo tal estrategia". 5 minutos despues: "Oye que esto está mal, fíjate en X,Y, Z". Es que le cortaba una mano

1 1 respuesta
_Rpv
#11946Fyn4r:

5 minutos despues:

y durante una semana el mismo tio, en todas las dailies, putos consultores

MTX_Anubis

#11945 Lo más importante como te dijo eisen es la configuración de los topics y sus particiones. El resto de configuraciones (producers/consumers) puedes hacerlas con prueba/error y ajustarlas a lo que más te convenga. Para un uso básico funciona bien las configuraciones por defecto y no debería darte ningún problema.

Sobre lo que dices el problema es que no sé a qué idiota se le ocurrió usar kafka como DB. Yo lo he usado desde la verisón 0.7 y desde luego aquello era un infierno de bugs y en el primer proyecto fue lo que más probelmas nos dio, tanto que no se me ocurre guardar un offset en kafka en la vida aunque hayan arreglado las 200 formas en las que se perdían.

Se puede usar como logger, se diseñó para eso precisamente y puedes guardar ahí todos los eventos si te da la gana (o guardarlos en otro sitio y ya está), pero que no sea un core de tu app, que sea un añadido y externo a tu app por ejemplo por si necesitas hacer una regresión en algún punto en el tiempo para comprobar cualquier cosa. No sé en qué cabeza entra usar un sistema de colas de mensajes como DB, pero bueno tampoco entiendo por qué alguien no usaría un PG como db principal y luego adicionalmente otros sistemas nosql para mejorar rendimientos pero nunca como core.

Pero bueno es que soy especialito y fan de las bd relacionales, con todo lo que ayudan de verdad no entiendo como hay grupos que intentan evitarlas xD

2 2 respuestas
wdaoajw

#11948 es que lo relacional no es agile

desu

#11948 Quizás hago un post con todas mis dudas cuando acabe o creo un hilo.

Lo de kafka como DB por suerte no lo hacemos.... pero no me hubiese extra;ado xd

Ahora estoy leyendo sobre los commits y offsets y los problemas de doble lectura o perdidas. De momento el segundo punto de "configuración" a parte de las particiones por topics para escalar que me he encontrado que tengo que vigilar. Ya que esto afecta al código que tengo que escribir.

Cosas como configurar producers y consumers me la sudan, broker en general tambien, lo del cluster me la suda (con 1 te basta y te sobra para la mayoria de casos)... Si en el futuro necesito algo concreto ya lo aprendere...

La verdad ayer en lugar de rascarme los huevos todo el día debería haber empezado el libro, porque hoy no creo que me lo acabe... xd Llevo 2h 30min y me he leído 102 pags de 322... Pero me esta gustando mucho el libro la verdad, le pongo un 7/10.

2 respuestas
Ranthas

Se m acaba de soltar la E dl teeclado, donde estan esos pelacables cuando son necesarios

1 respuesta
JuAn4k4

#11950 Consumers idempotentes y te quitas mil problemas de exactly once delivery y double reads

isvidal

#11951 https://www.pcgamingrace.com/products/gmmk-full-brown-switch

Kaledros
#11950desu:

kafka como DB

wtf, ¿eso se hace?

2 respuestas
Wei-Yu

te toca buscar si hay un "E as a service"

2
desu

#11954 Si pero sobretodo pensando en reconstruir la DB a partir de los eventos de kafka por ejemplo. El problema es que acabas re implementando una base de datos relacional a mano xd.

Se hace y bastante.

1 respuesta
Wei-Yu

xabale que en este sprint, o en los dos-tres próximos, se analizará si podemos actualizar un poco mysql para poder tener vistas materializadas

vaya pasote el futuro es hoy

Saiko9

#11954 He visto hacerlo, y acabo pasando lo que dice #11956

Un puto desastre, no se si en una startup molona se podrá hacer, en una telco ya os digo que no xD.

1 respuesta
Kaledros

#11958 No se me ocurre un caso de uso donde no sea mejor usar un mongo o hasta una sql de toda la vida, la verdad.

1 respuesta
desu

#11959 Del libro que estoy leyendo por ejemplo.

Can we prevent faulty records from ever making it into the pipeline? Can we recover from records that cannot be parsed? Can bad records get fixed (perhaps by a human) and reprocessed? What if the bad event looks exactly like a normal event and you only discover the problem a few days later?

Because Kafka stores all events for long periods of time, it is possible to go back in time and recover from errors when needed.

Si abusas pues...

Ni idea del tema por mi parte la verdad, hay cosas que tocara reconstruir desde el stream pero muchas otras no. Tengo pendiente leer mas del tema. No me importa demasiado el tema de fallos pero tengo curiosidad por eso de ser algo que la gente hace mal. Seguramente yo tambien lo haga mal en algun caso de uso... Never a master.

1 respuesta
Kaledros

#11960 Buf, pero eso es reconstruir una DB a partir del log de transacciones, es pervertir completamente el propósito de una herramienta.

What if the bad event looks exactly like a normal event and you only discover the problem a few days later?

Tanto si "bad event" significa evento mal formado como si significa evento con datos rotos/mal formados/incongruentes eso se debería comprobar mucho antes de montar el evento. Un evento sólo debería crearse una vez los datos han sido saneados y comprobados, no meterle lo primero que llega y hala, p'arriba y que se apañe el receptor.

1
B

Me parece Kafkiano! yo voy sobrao con BroadcastChannel API hulio!! y como soy un alpha dev me implemento mi propia solución de gestión de mensajes.
Todo persistido en una No-SQL ... por que como repito, soy puro alpha.

isvidal

y el hilo de kafka pa cuando

2 respuestas
r2d2rigo

#11963 ya hay uno https://www.mediavida.com/foro/libros-comics/kafka-dat-jerk-465363

B

.

B

Me he creado mi propia libreja para consultar listas de diccionarios por medio de dominios en notación polaca.

records = [{name: 'Pepe', age: 12, dead: true, type: 1}, {name: 'Laura', age: 35, dead: false, type: 2}, {name: 'Federica', age: 87, dead: true, type: 3}];

query(records, ['&','|', ['age', '>', 10], ['type','in',[2,3]], ['dead','=',false]]);

Resultado:

[{name: 'Laura', age: 35, dead: false, type: 2}, {name: 'Federica', age: 87, dead: true, type: 3}]

Cunde o no cunde? es parecido a como trabaja Odoo pero del lado del cliente :D

1 3 respuestas
brew

Que pereza meter los parámetros así

eondev

#11966 la verdad, esos proyectitos están divers, pero no lo veo nada útil xD

desu

#11966 https://ramdajs.com/

1
aren-pulid0

#11966 pff que pereza y que poco legible

algo mejor seria:

records.filter( type__in=[1,2], age__gt=12 )

Usuarios habituales