Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




PaCoX

#35189 te tienes que meter en google, hay la mitad son como tu, dev con egos astronómicos llenos de envidias y celos, con los reportes anónimos a flor de piel xD

pineda

las salidas en moto son eco friendly

1
desu

#35190 luego te paso mis slides. Tengo la intro hecha.

2 respuestas
r2d2rigo

#35134 la primera norma de fedadev es hacer lo opuesto a lo que salga por la boca de desu.

3
Ridote

#35193 oye te has preguntado alguna vez como habiendo malformaciones genéticas super raras nunca se ha visto a una persona cuyos pelos de las piernas fueran gruesos como los pelos de la cabeza? Es curioso

1 respuesta
eondev

#35195 no me has visto tú las piernas

2 1 respuesta
vago_21

#35196 es lo que pasa con la naturaleza, dios te quitó el pelo de la cabeza y te lo puso en la espalda/orejas/piernas

desu

no me acordaba que @eondev era calvo

2
vago_21

Creéis que es posible preparar la certificación de Scala-Spark en dos semanas? Tengo el examen el 4 de junio y hoy he acabado con todas las prácticas de la uni que tenía también las entregas en esa fecha

newfag

Desu porrero

1 respuesta
desu

#35200 viernes, 21h, a fuera la gente en el estadio de futbol gritando, escucho la gente en las terracitas bebiendo sus champus y pidiendose algo pa cenar.

yo aqui, haciendo un deploy para que me dejen de llegar putos pages de mierda

me cago en los fperos sin toque de s3 que cojones habran tocado

2 respuestas
Kaledros

#35201 Te lo cambio por tener la casa hasta arriba de familia política y niños gritando. Estoy por bajarme al parque con el mac a estudiar.

JuAn4k4

#35201 ¿Pero si a S3 no le pasa nada no ? Vamos nos hubiéramos enterado todos.

1 respuesta
wdaoajw

#35193 esto que enseñas es tribasico, a mi me toca ensenar la parte de moda. Sli, Slo, SLA, error budget, burn rate y cómo planificar esa mierda en los sprints de los devs

1 respuesta
desu

#35203 pues ayer con el support de aws salio que java por defecto no hay exponential backoff, lo he puesto en un hotfix que aun no he desplegado .. XD

es algo de S3 muy sutil, porque no hemos cambiado nada de trafico pero de repente en algunas availability zones tenemos bursts de 500.

han tocado algo por su lado pero es tan peque;o para su trafico que siguen estando al 100% de availability, e imagino que poca gente tiene el trafico que tenemos nosotros para que se note.

si tirandoles su maximo de req/s permitidas nunca hemos tenido problemas, el mismo numero de POST, el mismo tama;o de payload etc etc xq desde ayer peta?

esto lo hablo en mi talk de metricas por cierto que le comento abajo a @wdaoajw esto seria un claro ejemplo de detectar un cambio externo a tu poblacion de sampleo. siendo tu poblacion todos los datos que tu generas internamente. si un user cambia su patron de trafico esto no deberia afectar a tu CPU media por ejemplo, porque deberias tenre un sistema auto escalable. en este caso han tocado algo sutil a s3, que nos ha obligado a empeorar nuestro servicio con exponentials backoffs y seguramente tendremos que tocar algunos timeouts.

#35204 si eso tambein lo hago en las slides crack, el burn rate a que te refiers? a un rate de errores? o calcular el % de errores que esta bien dejar pasar? ese concepto lo lei en el libro de SRE de google, los budget, no me gusto mucho esa idea y no la recomiendo para nadie, ni siquiera google XD eso no deberia venir de negocio sino analisis de datos.

esto lo ense;o usando data science / data analytics. ya puse un ejemplo, si tengo N request/s, que % de error es asumible? que ventanas para calcular medias tiene sentido? cada cuanto tengo que cambiar los thresholds? como detecto AUTOMATICAMENTE que un threshold de alerta se ha quedado anticuado... Esto ultimo no lo hace nadie salvo yo que soy un puto dios.

como poner thresholds de alertas segun el tipo de distribucion. es la clave. esto son cosas que la gente hace a ojo o por experiencia, yo explicaba un poco las mates. al final es data science muy muy basico...

si quieres un dia abro stream y comentamos las mias.

lo de planificar en sprint de devs no he entendido que es.

2 respuestas
JuAn4k4

#35205 Nosotros tenemos límites muy por encima de los que ofrecen para todo. Las AZs si se rompen mucho, igual que las redes y máquinas. Nuestro tráfico está en us-east, aunque a s3 no tiramos mucho salvo para levantar máquinas y tal.
¿ Lo del % no es estadística ? No recuerdo bien pero me suena los intervalos de confianza tenían algo que ver.

wdaoajw

#35205 básicamente un team define un SLO, que no es más que decir, voy a tener 99% de availability por ejemplo. A partir de eso definen como medir availability, que podría ser simplemente N de request 5xx / request totales.

Todo lo que no cumpla el umbral del 99% empezará a quemar error budget (a un determinado Burn rate en base a la cantidad de errores) y si consumes todo tu error budget el team "no puede" sacar nuevas features a prod sin arreglar el veneno que hayan metido que este generando esos errores 5xx

1 respuesta
desu

#35207 si eso es de google sre

para mi es que no tiene sentido, porque si yo defino una feature y la saco voy a cumplir los SLO. o no he llegado a los criterios minimos XD

y luego tengo tests de regresion, si hago una feature que me jode los 5xx obviamente no se ira a prod... o me jodes otra cosa lo detecto ahi... no en prod.

y si se da el caso de introducir un bug, obviamente si me jodes una SLO se trata como bug y tengo que hacer un bugfix... eso tambiene sta cubierto...

asique no le veo el sentido a tenerlos.

en google los tienen porque es una manera artificial de controlar a los middle management empujando nuevos feature para sacar puntos de impacto. en las empresas grandes todo se mide en impacto, sacar un feature es la manera mas facil, asi que les da igual tener features de mierda que vayan mal ... por eso google metio esa regla, entre otras.

te recomiendo este libro: https://news.ycombinator.com/item?id=31224545

todo lo que hace google me parece horrible y mala practica

igualmente si das una charla me gustaria escucharla, a ver como aplicais eso en una empresa peque;a y que beneficios teneis.

1 respuesta
wdaoajw

#35208 empresa alemana top 1 de seguros a nivel Europa, pequeña pequeña no es.

Estamos en fase de escalar tanto a nivel de features como de equipos y desde management llegan estos requisitos así que toca aplicarlos

1 respuesta
vivora

.

desu

#35209 q triste cuando management toma decisiones tecnicas en lugar de ingenieros

tiene todo el sentido del mundo entonces lo q dices, gente que no tiene ni puta idea siguiendo a google porque es google, y van 319813581309 millones de empresas

JuAn4k4

¿ Por qué casi nadie programa con máquinas de estado ?

2
PaCoX

será coña no? xD

Kaledros

He escupido el agua. La foto del segundo sale cortada, el chiste está en la parte que no se ve.

1 1 respuesta
JuAn4k4

#35214 Siempre he pensado que era parodia exagerada, no se, imagino que será más de lo mismo.

1 respuesta
Wei-Yu

a este me lo encontré porque YouTube me echó un vídeo suyo defendiendo a rusia cuando invadió ucrania esta última vez (qué absurdo suena decir "invadir un país esta última vez")

pensaba que era clickbait pero me lo vi (sorrynotsorry) y tiene pinta de que es así de imbécil sólo que sabe que es "controversial" y se aprovecha

GaN2

#35215 creo que le ha comido el personaje

desu

tiene razon

la mujer no esta hecha biologicamente para trabajar

pero hoy en dia lo puede hacer sin problema y es un requerimiento para las clases sociales bajas

tiene razon

la mujer tiene la mente desarrollada para otro tipo de trabajos

pero no se puede generalizar de esa manera porque hay mujeres muy competentes

no tiene razon generalizando

en mi caso todas las mujeres que he coincidido han sido grandes profesionales, siempre lo he dicho, buen toque, mente analitica, creatividad... muy por delante del fpero medio. si es cierto que programando suelen ser mas malas, pero compensan con otros puntos. ahi tambien tiene razon.

GaN2

‘Yo no soy machista pero…’

2
JuAn4k4

Teniendo en cuenta que la mayoría de devs son incompetentes, no es raro asumir que otra gran mayoría de mujeres dev también lo sean.

3

Usuarios habituales