Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




Wei-Yu

relaja mr robot no me hagas un ju4nque0

Kaledros

Me vuelvo a Lo Regne por tema de médicos y resulta que tengo que volver a la oficina a hablar de temas de arquitectura y conocer al nuevo en persona. La parte buena es que trabajo en una empresa del primer mundo y el commuting de más de 30 minutos cuenta como jornada laboral. Como son dos horas y pico de viaje, mañana sólo curro cinco horas.

Leos

Proponer una solución para hacer bien una sincronización de datos porque mi equipo penso que era bueno tener una bd por cada microservicio pero después necesitar otra para otras apps y encima como una es un mongo envian lo que les sale de la polla y ahora me como yo el marron.

Un día más en la oficina

Me cago en el boom de microservicios y los que lo aplican porque es la moda sin saber ni como ni si les va a mejorar la architectura xdddd

3 respuestas
pineda

#31143 echale un ojo a debezium, igual te vale

2 respuestas
B

#31143 Como especialista en manejo de datos te deseo suerte

Leos

#31144 Me parece bastante interesante, se lo soltaré al lead a ver que le parece.

Pero te adelanto su respuesta, lo necesitamos para antes de ayer (llevan años con el problema y ahora de golpe no pueden hacer nada sin eso), hacemos la sync tirando de los eventos que ya tenemos y a reparar deprisa y corriendo cuando vaya petando la sync

1 respuesta
MTX_Anubis

#31146 realmente así es como se hace en arquitecturas con event sourcing. Cada microservicio se sincroniza mediante eventos.

Vuestro problema no es tanto ese como el no tener centralizados el schema de los eventos.

1 respuesta
Leos

#31147 El problema es que quisieron implementar esa arquitectura sin sentido, en la que crearon muchos micorservicios que tenían la misma responsabilidad y crearon sus schemas en mongo sin tener en cuenta nada anterior ni si se tenía que sincronizar.

Además de no mantener una sincornización con los eventos, por lo tanto los datos del mongo no concuerdan con la otra db, por decir no saben ni que campos deberían sincronizarse ni como llegan, que es uno de los percales que me estoy comiendo ahora.

Ahora están en fase de refactor quitando microservicios, haciendo guarradas en el mongo para intentar cuadrar todo.

Por eso me refería a que el problema es de los que intentan aplicar la última moda sin saber si es lo que mejor va para lo que nosotros hacemos.

2 respuestas
Wei-Yu

Luego en el cv pones que has diseñado una arch de microservicios, te sacas 20k más en el próximo curro y a montarle la trampa al siguiente.

1
Ranthas
#31143Leos:

Me cago en el boom de microservicios y los que lo aplican porque es la moda sin saber ni como ni si les va a mejorar la architectura xdddd

Yo me cagaría más en los que prefieren mongo sobre relacionales porque es lo más cool y luego se dedican a enviar basura, al mismo nivel que los malnacidos del any en Typescript.

1 respuesta
desu

#31138 me he puesto en un meeting a sacar los pelos de gato de la silla

he tardado 10 minutos en darme cuenta que tenia la cam puesta XD

#31148 el problema es que trabajas con pajeets que no saben hacer la O

no que sigan la ultima moda o que hagan microservicios

si tuvieseis un monolito tambien seria una mierda apestosa

en datascience hay un dicho: garbage in, garbage out

los FPeros tienen otro dicho: codigo in, garbage out

#31144 el producto no lo conozco, pero en el equipo detras de ese proyecto hay gente a mi nivel, recomendable minimo echarle un ojo

1 1 respuesta
Leos

#31150 También también, es otro dolor de cabeza, porque además no tienen ni un schema definido, ellos mandan toda la mierda y ya te buscaras la vida, además como es una bd antigua, te llegan los mismas colecciones con datos muy dispares xddd

1 respuesta
Leos

#31151 Toda la razón, pero un monolito aunque sea mierda, es menos mierda, mete a un pajeet en tema eventos, creación de bd para cada microservicio, lambdas, etc, y te puede generar más mierda de la imaginada.

Ranthas

#31152 Tiene que ser tronchante recibir dos tuplas de una misma colección y que se parezcan como un huevo a una castaña

1 respuesta
Leos

Tripleposteo porque puedo

Leos

#31154 Lo mejor es que no tienen en ningun sitio como pueden llegar, entonces de vez en cuando corren algún script o se corre solo porque no saben ni que existe y te manda un record de hace 5 años que hace petar todo porque el único campo igual que tiene es le id xddd

2 respuestas
Ranthas

#31156 Tienen una combinación difícil de superar, eh, microservicios, nosql, 0 data sanitazion, creo que sólo falta lo de pizza rancia los viernes y mesas de pin pon en la oficina para tener escalera de color

1 respuesta
pineda

#31156 con todo el cariño eh, pero no mires atrás, corre, corre lejos

1 respuesta
Wei-Yu

hostia vaya percal jaja

Kaledros
#31148Leos:

sin tener en cuenta nada anterior ni si se tenía que sincronizar

En mi curro pedí al jefe de mi jefe que me pusiera por escrito la frase "performance is not an issue" y que se diera por enterado de que en el momento en que lo fuera tendríamos que tirar la app a la basura. Guardo ese correo impreso porque me la veo venir.

2 1 respuesta
Leos

#31157 Lo único bueno es el remoto, no se si los que vayan a la ofi cuando la abran harán eso xD

#31158 Estoy actualizando cv para empezar a correr sin mirar atrás

#31160 Mira aunque tengas ese correo se la sudará el te lo dije... Yo aquí ya a veces le he tenido que decir a mi lead, analiza la tarea bien antes de mandármela, porque se le queja un departamento y cambia toda la feature, después se le queja otro y vuelta a cambiarla, le dije mira antes de mandármela que tal si la analizas o analizamos, reunimos a todos los departamentos implicados y llegamos a una solución conjunta?

Pues nada, me hizo caso una vez, después ha vuelto a hacer lo mismo, vaya rage llevo encima

desu

por hoy, ya estamos.

voy a empezar a trackear el tiempo que curro (sigo incluyendo el tiempo en que leo mis papers y mis cosas random) para compararlo con mis antiguas estadisticas, no creo que este entre 2-4h como antes, mas bien estare sobre las 4-6h creo.


25% tiempo personal
13% tiempo "corporativo", mierdas que no aportan al equipo como meetings de onboarding
63% tiempo equipo, curro

y clasifico entre "dev", "doc" (leer/escribir) y "meetings" (asistir/preparar)

Wei-Yu

un hilo en twitter bueno y cortísimo sobre el que llevo pensando una semana y media

pongo lo que para mí es el highlight

importante para el que esté empezando o intentando cambiar de tercio

2 2 respuestas
isvidal

#31163 He sacado esto de eso ( no se como ) y me ha flipado porque es de 1980, incluso antes de Internet:

Eso si que es predecir el futuro

3 2 respuestas
Slowbro

#31164 No reconozco el autor pero me ha recordado tela a este

Wei-Yu

No sé por qué pero me recordó un artículo que leí en el que hablaba de la automatización desde una perspectiva distinta. El ejemplo era una granja de ganado que se había informatizado; un montón de procesos como la comida o agua que antes eran manuales ahora eran automáticos. El "lado oculto" de esa bonanza tecnooptimista era cómo se pivotaba de un ritmo natural (entendido como centrado en la vida orgánica) a uno que seguía el marcado por sistemas de alertas y monitorizaciones que podían fallar o requerir intervención en momentos aleatorios. No era una crítica ni nada así, si no una observación poco común de cómo cambia la situación. A ver si lo encuentro.

edit: aquí está
https://strelkamag.com/en/article/reporting-from-automated-landscapes

Technologies and new forms of labor marketed to free human bodies in fact contribute to their permanent uptime.

1 respuesta
Fyn4r

#31166 Hace un mes tuve una reunión con una granja que quería un piloto sobre eso, tienen más sensores las vacas que un puto F1

MTX_Anubis

#31163 Lei una vez a uno que escribió sobre algo que leyó en un libro, la historia era algo así:

Un maestro alfarero japonés divide la clase en 2 grupos:
A un grupo les 15 días para hacer un solo jarrón y se les califica por el resultado de éste.
Al otro grupo les da 15 días para hacer el mayor número de jarrones que puedan y se les califica por el numero de jarrones aceptables que hayan hecho.

El segundo grupo acabó haciendo jarrones de mejor calidad que el primero y es al punto que quería llegar el maestro, que sabía que iba a ocurrir eso. La práctica hace al maestro.

1 respuesta
Kaledros

#31164 Pues cuando leas a Arthur C. Clarke hablando de internet en los 60, de enseñanza usando ordenadores personales y de trabajo remoto vas a flipar XD

Also, acabo de descubrir que VSC sirve como editor de LaTeX y estoy como un niño con zapatos nuevos.

1 respuesta
B

#31169 yo uso typora con tu tema nord, también tiene editor LaTeX, me parece lo mejor esa herramienta

1

Usuarios habituales