Feda /dev/ - No Javascript allowed | Página 1575

Tuskus #47221 Jul '23

#47218 Mentalidad de pobre, yo esos 10 euros te los reinvierto en cryptos y ganó millones.

3

B

[Borrado] #47222 Jul '23

Tu dame los 10 pavos, que aunque no los necesite sabré en qué gastármelos bien

r2d2rigo #47223 Jul '23 Inocente

Pero que coño hacéis escribiendo estos tocho posts un sábado a las 6 de la tarde, salid por ahí a follar o algo joder

3 1 respuesta

paulinho #47224 Jul '23

Vuestro amigo se acaba de cargar Twitter y se la pela

1 respuesta

Soltrac #47225 Jul '23 MV Wizard

#47223 por fin alguien sensato.

Yo ya llevo varios copazos. Que solo se está desde la cima

2

Konishi #47226 Jul '23 :psyduck:

¿A cuanto estará el nuevo tick para saltarse la limitación?

Yo apuesto por 2 tiers, 9.99 y 19.99 al mes.

PhDfailer #47227 Jul '23

#47224 que ridiculez

JuAn4k4 #47228 Jul '23

#47216 Joder macho, ahora te comes el “es probable que pase algo” por el forro de los cojones, y lo del rendimiento del equipo te lo has inventado. Pueden pasar mil cosas, no tiene por qué ser el rendimiento, los cambios salen más lentos, o lo mismo no. Si te inventas la mitad de las cosas que luego refutas, eso si se llama falacia del hombre de paja. Y he dicho también que puede que sea por cosas normales y no accionables o incluso esperarás. Ahora somos 3 menos en el equipo, las features de ahora no requieren PRs, hay mucho toil, etc… muchas cosas pueden aféctar a una métrica, la métrica solo te indica que hay algo que le está haciendo cambiar, y si no es esperado, entonces no está de más ver que es. Y a eso se le llama insight.

Te pongo un ejemplo práctico real: Número de incidentes en cada mes con severity.
Dime que no vale para nada y te diré que si vale, como insight.

1 respuesta

desu #47229 Jul '23

#47228JuAn4k4:
Te pongo un ejemplo práctico real: Número de incidentes en cada mes con severity.
Dime que no vale para nada y te diré que si vale, como insight.

No vale absolutamente para nada.

Lo que tu llamas insight es una falsa sensacion de control y poder.

Si el insight (que lo llamare por su nombre: metrica) no es accionable, y esa accion no la realizas para correjir otra metrica que conoces que es afectada por la primera, no vale para nada.

De hecho hay libros enteros dedicados en estadistica y probabilidad a este tema.

https://en.wikipedia.org/wiki/Correlation

Formally, random variables are dependent if they do not satisfy a mathematical property of probabilistic independence. In informal parlance, correlation is synonymous with dependence. However, when used in a technical sense, correlation refers to any of several specific types of mathematical operations between the tested variables and their respective expected values. Essentially, correlation is the measure of how two or more variables are related to one another. There are several correlation coefficients, often denoted ρ \rho or r r, measuring the degree of correlation. The most common of these is the Pearson correlation coefficient, which is sensitive only to a linear relationship between two variables (which may be present even when one variable is a nonlinear function of the other). Other correlation coefficients – such as Spearman's rank correlation – have been developed to be more robust than Pearson's, that is, more sensitive to nonlinear relationships.[1][2][3] Mutual information can also be applied to measure dependence between two variables.

Defineme esa matriz de metricas donde las PRs y demas afectan al equipo... O a lo que tu quieras. A ver que yo vea los datos y pongamos en practica las formulas a ver si lo que dices es cierto o solo eres un sucio mentiroso.

1 respuesta

JuAn4k4 #47230 Jul '23

#47229 Entonces esa métrica no te ayuda a saber si el servicio tiene muchos o pocos incidentes ? Para poder establecer un oncall rotation o modificarlo, añadiendo gente nueva con menos experiencia en el servicio ? Te ayuda a saber si es más o menos estable (no a predecirlo).

Pero que yo no estoy relacionando la métrica con nada, eso lo estás haciendo tú porque sino no te vale tu argumento.

1 respuesta

desu #47231 Jul '23

#47230

#47230JuAn4k4:
esa métrica no te ayuda a saber si el servicio tiene muchos o pocos incidentes ?

Esa metrica POR SI MISMA NO. Ni ninguna otra metrica.

#47216desu:
y yo te digo que hay tantas metricas y factores que no estas considerando en la ecuacion que es una perdida de tiempo hacer ese razonamiento

Necesitas tener un sistema de variables bien montado, completo, definido, y en estos casos siempre corres el riesgo de la variable temporal altera la topologia del problema y las metricas subyacentes.

- por ejemplo, ahora en lugar de hacer features estas resolviendo bugs que requieren mas tiempo

por ejemplo, ahora ha entrado un chico nuevo al team y haceis onboard y dedicais menos tiempo a desarrollo

por ejemplo, estais en periodo de vacaciones y el equipo esta al 50% de rendimiento

por ejemplo, ha habido una restructuracion de la empresa que os ha efectado

por ejemplo, antes mediais el tiempo de mergear PRs del producto A, y desde hace una semana trabajais en el producto B, A y B no son comparables en complejidad etc.

por ejemplo, antes hacias PRs mas pequeñas y ahora haceis mas grandes porque sube el tiempo de mergear PRs pero baja el numero de deploys

Ademas todas estas metricas deben seguir una serie de propiedades para poder utilizarse debidamente y hacer probabilidad de manera correcta.

#47230JuAn4k4:
Entonces esa métrica no te ayuda a saber si el servicio tiene muchos o pocos incidentes ?

Defineme matematicamente que significa "mucho" y "poco" y donde pones el threshold de alerta.

Es que no es posible de manera independiente hacerlo XD

1 respuesta

JuAn4k4 #47232 Jul '23

#47231 Puedes comparar con otros servicios, uno tiene 3 alertas a la semana, otro 2 al año, durante los últimos 5 años. No significa que vayan a seguir así, pero puedes decir que uno tiene más que el otro por lo general, y uno es más estable que el otro. Aquí comparas la misma métrica en diferente servicio. Que no es estadísticamente correcto? Bueno..

1 respuesta

desu #47233 Jul '23

#47232 El mismo servicio no es comparable consigo mismo en el tiempo.

Hace 2 años estaba escrito en Java, ahora lo habeis re-escrito en Go, en el futuro quizas es Rust.
Hace 2 meses tenia 10 features, hoy 20 features, mañana 5 features.
Hace 2 semanas estabamos en la version 2.6 de una libreria, hoy estamos en la version 3.4 de esa libreria (aplicar por todas las librerias posibles)

Imaginate querer comparar multiples servicios. Incorrecto.

*nota: obviamente hay maneras correctas de considerar estos cambios incrementales, como el de las librerias, concepto de ruido o error por ejemplo.
**nota sobre la nota: porque si reducimos al absurdo esta argumentacion nada es comparable. ahi es donde toma juego la estadistica y la probabilidad. que son las herramientas formales para realizar analisis.

Es lo que he dicho de instantaneo vs temporal. Si algo es instantanea no tienes suficiente informacion, si cojes un rango de tiempo mayor, el servicio ha cambiado tanto que no es comparable. Cualquier tipo de comparacion es falaz.

Para poder realizar estas comparaciones el sistema no debe cambiar. Porque si el sistema cambia las metricas no son las mismas en el tiempo.

Un ejemplo de otro campo. Pones un sensor para medir volumen de agua en un tubo. Si un dia cambias el tubo y le pones uno de mas grande o pequeño. NO PUEDES COMPARAR lo que tenias anteriormente. Tienes que volver a empezar a recolectar metricas. No puedes tomar decisiones basandote en el pasado.

Esto lo veia bastante cuando trabaja en machine learning.

#47232JuAn4k4:
Aquí comparas la misma métrica en diferente servicio

La misma metrica en el mismo servicio, en el tiempo no es comparable. Refutado. Imaginate otro servicio.

#47232JuAn4k4:
Que no es estadísticamente correcto? Bueno..

No solo no es correcto. Es una mala practica. La gente se cree que por tener muchas metricas, o muchos datos (big data), o realizar decisiones "data-driven" que le llaman van a ser "mejores". Eso no es asi. Esto es un claro ejemplo de burocracia y bullshit jobs en gran empresas. Alguien necesita justificar su trabajo y en lugar de hacer "trabajo" hace "meta-trabajo".

En este caso (1) copiar a grandes empresas diluye la responsabilidad, si en 1 año nos vamos a la quiebra podemos decir "hicimos lo mismo que el resto". (2) da sensacion de poder y control a los managers.

isvidal #47234 Jul '23

Scroll scroll

16

desu #47235 Jul '23

perdon por enseñar a los analfabetos a leer

a veces me olvido que os gusta enorgulleceros de ser ignorantes y tontos

vuestra vanidad por la mediocridad no tiene limites

1 respuesta

JuAn4k4 #47236 Jul '23

#47235 Es comparable, lo que pasa que no entiendes ni lo básico y llamas analfabeta a la gente. El mismo servicio escrito en Java o en Go los puedes comparar bajo la misma métrica de incidentes,
, aunque los incidentes sean self-inflicted, o dependiendo de la infraestructura o lo que sea, da lo mismo que sean absolutamente diferentes. Puedes compararlos a nivel de incidentes y podrías llegar a justificar la subida de incidentes porque AWS ha tenido un mal año (encuentras la CAUSA) de que la métrica cambie. No tiene que significar que el servicio sea mejor/peor, que yo creo que sacas las conclusiones tú de antemano y dices que son inválidas, toma claro.

En tu ejemplo del tubo, pones uno más gordo y esperas que la métrica de volumen suba, sin embargo baja. Dime que no te dice nada y que no vale para nada, estarás mintiendo para mantener tu bias de ego.

1 respuesta

privet #47237 Jul '23

Buenas noches

Wei-Yu #47238 Jul '23

https://forum.nim-lang.org/t/10312

3 1 respuesta

Fyn4r #47239 Jul '23 Inocente

Hostia ese tendría avatar de rana en MV

1

desu #47240 Jul '23

#47236 que si yo no se matematicas y toda la gente que ha hecho mates las ha hecho mal y los cientos de miles de libros de mates estan equivocados.

para ti la razon que es lo que quieres. porque no publicas un libro de matematicas? eres el nuevo socrates.

o empieza editando la wikipedia que esta todo mal.

he puesto ejemplos para tontos y aun asi no lo has entendido. de verdad, leete un libro de matematicas o algo porque se nota que ya estas mayor y tienes el cerebro atrofiado. eres incapaz de encadenar dos razonamientos coherentes seguidos.

en ese post de mierda has vuelto a poner ejemplos de metricas y causas que no estas midiendo de nuevo no entiendes lo que es un puto sistema de variables. y demuestras solo tu ignorancia en lo que hablas. para variar en este hilo de mentecatos.

"las mates estan todas mal, mi polla manda porque soy informatico y un abuelo, asi que lo que yo digo vale mas que todas las mates del mundo"

con esa capacidad de razocinio y dialogo engañaras a tus hijos y los 4 fperos del hilo que ambos se cagan en los pañales, pero yo no soy un imbecil.

me follo los axiomas porque programo en java HAHAHAH

1 respuesta

JuAn4k4 #47241 Jul '23

#47240 Te voy a llamar Sr. Falacias, Usas todas las falacias formales en tus razonamientos.

2 respuestas

TheBrotha #47242 Jul '23

#47241 es que esta aprendiendo a ser product manager

3

desu #47243 Jul '23

#47241 buen ad hominem

1 respuesta

Wei-Yu #47244 Jul '23

https://blog.jetbrains.com/idea/2023/06/intellij-idea-2023-2-eap-7/

meten una integración muy basiquita con language server protocol en la beta de intellij idea

a ver cómo evoluciona esto en los próximos años

isvidal #47245 Jul '23

#47238 jajajajajajaj

PhDfailer #47246 Jul '23

.

4 respuestas

desu #47247 Jul '23

#47246PhDfailer:
Compañero está 4 puestos por encima tuyo

No te esta pidiendo ayuda. Te lo esta ordenando educadamente. Jerarquia.

1 respuesta

B

[Borrado] #47248 Jul '23

#47246 ayudarle, no entiendo el problema

1 1 respuesta

isvidal #47249 Jul '23

#47246 que tipo de jerarquia teneis como para que un picateclas como tu o yo este 4 puestos por encima? 4 puestos por encima en cualquier empresa normal es el CTO o CEO

1 respuesta

Kaledros #47250 Jul '23

#47246 Puedes dejar prod rota mientras señalas al responsable y te ríes, pero yo qué sé, sabes.

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales