Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




Sphere

Hacía tiempo que no me encontraba un test de estos en un proceso de entrevistas:

Aaaaaand into the trash it goes.

3 respuestas
carracho

#54841 Decidido, Jugueton, Atractivo, Penetrante, Exacto, Chapado a la antigua, Gárrulo, Duro, Pulido

5
PhDfailer

#54841 has perdido la oportunidad de hacer un mensaje "encriptado" ofensivo con las iniciales de los adjetivos

o Feo, Fuerte y Formal

1
Fyn4r

> fácilmente excitable

Eso es para alejarte de las de RRHH?

1
frekaice

#54841 Hay buenas combinaciones

Lleno de confianza + Facilmente excitable + Humor cambiante + Chapado a la antigua

2
pineda

pero cuantas opciones hay? casi que prefiero una prueba técnica de 3h

1
PhDfailer

¿Me contratariais?

He tenido que buscar renuente en el diccionario

adj. Dificultoso, trabajoso. reacio, remiso, reticente, contrario, opuesto, refractario, rejego.

desu

Me describiría así:

Sociable, Modesto, Tranquilo, Pacífico, Paciente, Relajado, Simpático, Encantador

1 2 respuestas
PhDfailer

#54848

4
GaN2

#54848

5
Lecherito

4
Wei-Yu

para los no iniciados

me lo vi ayer y había bastantes cosas que no sabía del tema, aunque me habría quedado tan pancho sin saberlas (como los vídeos masturbándose en el coche)

1 respuesta
Dr_Manhattan
#54852Wei-Yu:

(como los vídeos masturbándose en el coche)

es que en cada post tienes que meter tu puntito raro, el del cringe, tu ISP tiene que estar flipando contigo

1 1 respuesta
Wei-Yu

#54853 bueno aquí el que nunca se ha grabado mientras se masturba

no engañas a nadie

1 respuesta
Dr_Manhattan

#54854 claro, para que lo vea soros o bill gates

1 1 respuesta
Konishi

#54855 visto lo visto, mejor ellos que un(a) influencer

2
Kaledros

Lo de mi curro ayer fue espectacular.

Una horda de devs (lo menos quince) trabajando durante un mes en una tarea cross-team (añadir un campo en EL objeto de dominio, un objeto que pasa por absolutamente todas partes, cinco o seis servicios, medio centenar de topics y una docena de procesos críticos. Se planea la cosa, se van haciendo cambios incrementales, se testea, todo guay.

La tarea implica la creación de una tabla auxiliar en la que se van a volcar 150M de registros de un .csv, de lo que se encargan dos devs que deben cobrar sus buenos 80K. Ayer a las 10 de la mañana comienza la carga. A las 11, reunión de emergencia. Esos 150M de registros tardarán una semana en persistirse. No, no sabemos como acelerarlo. No, no tenemos ni idea de si se puede paralelizar. Nosotros pensábamos que iba a ser más rápido y varios "ejque" más.

Ya ni siquiera entro a valorar el hecho de que tíos que ganan 80K ni hayan sido capaces de prevenir esto ni sean capaces de solucionar el problema. Tampoco voy a entrar en el hecho de que esto no va a hacer que ningún mando se replantee cosas acerca de procesos de selección o cursos obligatorios de DB para que esto no vuelva a pasar porque eso sería hacer su trabajo y jajajá te imaginas. Tampoco quiero saber como esta gente pasa sus revisiones anuales si luego en cuanto hay que sacar la cabeza de su trinchera se cagan encima.

Mi duda es por qué se considera normal en algunos sitios que un dev no tenga ni puta idea de BD más allá de hacer CRUD, crear alguna tabla ocasional y ya.

1 5 respuestas
JuAn4k4

#54857 Y nadie se planteó meter los datos antes en una tabla temporal ? Y en la migración hacer un insert + select

1 respuesta
Kaledros

#54858 ESTA es la tabla temporal XDDD

desu
#54857Kaledros:

Esos 150M de registros tardarán una semana en persistirse

Están insertando indexando seguro

HAHAHAHAHAHAHAHAHHA

Lo mejor es que la solución es tan fácil que cualquier fpero de este hilo la sabe.

HAHAHAHAHAHAHA

Y por ultimo hablar de 150M de registros como si fuesen muchos...

HAHAHAHAHAHAHAH

1 1 respuesta
Seyriuu
#54857Kaledros:

Tampoco voy a entrar en el hecho de que esto no va a hacer que ningún mando se replantee cosas acerca de procesos de selección o cursos obligatorios de DB

Como todos ya sabéis mi experiencia en empresas se limita a empresas cárnicas, desconozco en el resto de empresas, pero en mi experiencia, jamás se ofrecen cursos que realmente sean útiles.
Los únicos cursos útiles que se han realizado es coger a uno que no se dedica a dar cursos pero lleva 10 años en la empresa y decirle que enseñe como usar las herramientas, métodos o procedimientos que son totalmente propios de la empresa y que lo grabe en vídeo para dárselo a todo el que entre nuevo no vaya a ser que demos el curso dos veces.

Cursos que te enseñen a normalizar bases de datos y hacerlas bien? ni uno.
De hecho, fliparíais lo mal que están las bases de datos en bancos y aseguradoras, como tienen las claves mal hechas, como la misma información se guarda en 15 tablas distintas "por comodidad", etc.

Ahora, por ejemplo, seguramente me ponga con Java (springboot creo) para llevar proyectos de backend que sean las "nuevas" tecnologías del banco en vez del mainframe de siempre, pero ya me han adelantado que "no necesito entenderlo a nivel técnico" y yo me vuelvo loco, lo normal sería que tuviera unos mínimos conocimientos técnicos, que me enseñaséis a hacer cuatro cosas básicas que al final todos los procesos del banco son iguales, pero no no, no hace falta, ponte a dirigir el proyecto, hacer valoraciones y defender ante cliente qué se puede o no se puede hacer sin que te demos ni un mínimo de formación técnica xD

Kaledros
#54860desu:

Están insertando indexando seguro

Ni he querido averiguarlo, era viernes y no era mi problema. Es RDS, así que además añádele la variable de poder tirar al suelo la DB de producción si le das demasiada caña.

JuAn4k4

Me la juego, van registro a registro, leyendo del CSV y haciendo insert, con índices y seguro les salta OOM leyendo el fichero cuando vayan a terminar. Seguro que han usado Hibernate o similar. Mis dies.

2 2 respuestas
desu

Además RDS, a saber como está configurado el cluster, no vayan a estar saturando la CPU y afectando a prod todas las otras queries jeje.

#54863 Ah y cuando les peta el CSV vuelven a empezar por el principio porque no saben que han insertado jeje

1 respuesta
Kaledros

#54864 Un par de alertas de lag en el cluster no negaré que saltaran.

#54863 Esa es una de mis principales quejas: ¿por qué para meter un .csv en una BD estás usando Java + Spring Boot? ¿Te ha obligado alguien o es que no sabes hacerlo de forma más eficiente? Esa y la de por qué no escalas hasta el techo la máquina de la BD para que, si vas a hacerlo por las malas, al menos no la tires.

carracho

Menos mal que se lo pensaron al llegar a 150M de entradas en un csv... podrían esperar a lo que da de si el sistema de archivos que usen antes de pensar en cambiar. Son ganas de querer complicarse... :B

privet

Quitando las payasadas que comentáis, volvamos a un tema serio
Os dejo todo el fin de semana para argumentar cual creéis que podrá ser la razón. Salu2

1 respuesta
wdaoajw

#54857 pues el día a día de todas las empresas.

Y luego a llamar a los DevOps o dbadmins(si es que hay de estos, que son más raros de ver que un perro verde) porque no tenemos ni zorra de que está pasando.

Al menos entiendo que tendrán read réplicas para no tumbar el performance de cara al cliente

2 2 respuestas
desu
#54868wdaoajw:

Al menos entiendo que tendrán read réplicas para no tumbar el performance de cara al cliente

HAHAHAHAHAHAHHAHAHAHAHAHAHAHAHHAHA

3
Runig666

#54868

Al menos entiendo que tendrán read réplicas para no tumbar el performance de cara al cliente

Si son buenos en el mejor de los casos tienen una replica para hacer las copias de seguridad y hace meses que ni las copias ni la replica funciona correctamente.

Las buenas practicas en las empresas te las preguntan por si cuando te digan que no tienen ni zorra de lo que les estas diciendo te va a dar un parraque o no.

Usuarios habituales