Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




RubberDuck
#58949desu:

Muchos de aquí han cambiado de carrera varias veces. De frontend a backend o viceversa. De datos a devops o de sistemas a videojuegos. No pretendas tener un plan perfecto y rígido.

Sí, todavía no tengo ninguna pretensión, la verdad. Solo coger unas buenas bases que me den la confianza para después tirar por el camino que más acorde a mis necesidades vea. Sobre todo lo que me preocupa es eso, que el trabajo no sea hacer año tras año lo mismo con la sensación de que no te está costando nada, que simplemente eres un mono tecleando con cero dificultad delante del PC.

2 respuestas
HeXaN

Qué bonito, todavía está en la fase en la que se cree que el trabajo es algo más que un mecanismo para rellenar la cartera de dinero.

13 1 respuesta
newfag

#58951 Si no tienes proyectos personales vas a sentir que eres un mono picando teclas, si tienes proyectos personales vas a sentir mono por picar teclas

1
aren-pulid0

Aprende lo que se pague, haz proyectos que se parezcan en la medida de lo posible a lo que hay en las empresas, estate a la última y a subir €€€

Luego ya buscas cómo completarte

2
RubberDuck

Edit: acabo de leer las normas y yo preguntando aquí en serio xD

1 respuesta
newfag

#58955 Evidentemente cada experiencia es singular, pero sí esto te acaba entusiasmando vas a hacerlo con mucho gusto. Y efectivamente, nunca tocas techo, por más que domines técnicamente la programación solo tendrás las herramientas, lo que hacer con ellas ya es cosa tuya.

2
aren-pulid0

Somos jardineros, @desu pásale tu blog al chavalillo

Kaledros

#58951 Piensa que no todo tiene por qué ser programar, el verbo "desarrollar" es más que picar código. Te puede gustar desarrollar un producto, por ejemplo, y eso es más que programar, es añadir features, eliminar lo que no funciona, guiarse por datos reales, etc.

1
desu

Se que cree que le estábamos trolleando adorable

HAHAHAHHA

Estos chavalines... veras cuando cumplas los 30 la ostia

Kaledros

Tengo una lista de frases que cuando las oigo en el curro no auguro nada bueno. Una de ellas es "este código se puede simplificar" porque cada vez que oigo decir eso un motivao sin faena acaba cogiendo un código perfectamente legible y convirtiéndolo en una única expresión indescifrable.

1 2 respuestas
pantocreitor

#58960 pa que quieres que sea descifrable???
Si eso código nunca jamás se volverá a tocar

1
Fyn4r

#58960 Cuando la frase que te viene a la cabeza no es "o arreglo esto o búscate a otro que mantenga el proyecto", es que no hace falta cambiar nada

1 respuesta
Kaledros

#58962 Ayer me pego todo el día con un filtro con su poco de mala sombra (si X flag es true pero la fecha es posterior a 2021 haz esto, si es anterior pero la flag es false comprueba que la luna no esté en cuarto creciente, etc). Me quedan dos funciones con un if-else y dentro tres ifs anidados. Obviamente se puede simplificar, es Kotlin, puedo hacer que sea sólo una expresión, pero así es más legible y no tiene nada de malo anidar tres ifs dentro de un if-else por mucho que diga Martin Fowler. Una cosa así:

if(condition1){
  if condition2 return A
  if condition3 return B
  if condition2 return C
} else {
  return D
}
return null

Abro PR y a mi compañero workaholic le salta el TOC y me dice que esos bloques se pueden simplificar. Le digo que así es más legible. Me dice (de buen rollo) "pues como hoy no tengo mucho trabajo me bajo la rama y lo hago yo". Le digo que tiene mi bendición.

Lleva dos horas refactorizando y no es capaz de que le pasen los mismos tests que a mí sí me pasaban ayer.

2 respuestas
desu

#58963 sois unos fperos los dos. los dos sois malos:

if condition => return A

vs

if condition => return cfg_A => if cfg_A => return A

de esta manera tendríais la configuración del comportamiento separado y seria imposible que os petasen los tests.

si tuvieseis el codigo de la segunda manera mapeando las condiciones a las configuraciones esta MR nunca habria existido para empezar, y seria imposible que le petasen unos tests, porque o simplificas el if de las condiciones => cfgs o el if de las cfgs => funciones.

en fin, seguid hablando mierda de vuestros compañeros como lo hacéis xq son muy malos, en lugar de entender que sois dos cerdos bañandose en la misma ciénaga.

2 respuestas
Soltrac

#58964 Me quedo con la manera del fpero, que manía con darle vueltas a 5 líneas de código.

2 3 respuestas
Fyn4r

Por eso hay que hacer que las PRs modifiquen 8 ficheros y 300 líneas de código, nadie hace preguntas

1
Kaledros

#58965 Ha hecho EXACTAMENTE de lo que me he quejado. Asombroso.

PaCoX

yo leo eso y me entran picores

if(condition1){
  if condition2 return A
  if condition3 return B
  if condition2 return C
} else {
  return D
}
return null

5 return y dead code en 8 lineas

desu

#58965 no es darle vueltas a nada, es hacerlo bien. las condiciones no se llevan nunca a runtime xq es una mala practica XD

adamas la mayoria de veces es parsear un archivo de config o una request al inicio de la petición...

yo te aseguro que me programas esa mierda y te digo lo de parsear la principio, para tener un struct valido y simplificar la logica, desacoplar configuración de runtime, y me dices que es darle 5 vueltas al codigo y NO HIRE

de toda la vida el codigo se pasea antes de hacer nada para ver si es valido, y cuando lo parseas sabes lo que tienes que ejecutar... tener nidos spaghetti en runtime con condicionales si que es darle 5 vueltas al gato porque no sabes programación basica

que la verdad, el chico este no ha ido a la universidad y se nota... xq esto es de primero de clean code...

parse dont validate

desu

"que mania con darle vueltas a 5 lineas de codigo"

subnormal

Konishi

Ya que lo ha mencionado desu, ¿Cómo llevan en vuestra empresa el tema de configuraciones que haya que cambiar en caliente?

Llevo un par de curros donde las acaban teniendo en BBDD de una forma u otra y acaba siendo un desmadre, entre no forzar a documentarlo bien y que acabas con mucha config que tocar para replicar un caso específico estoy hasta las narices de que hagan las cosas así.

2 respuestas
desu

#58971 define que casos de uso necesitas cambiar en caliente...

#58971Konishi:

Llevo un par de curros donde las acaban teniendo en BBDD de una forma u otra y acaba siendo un desmadre, entre no forzar a documentarlo bien y que acabas con mucha config que tocar para replicar un caso específico estoy hasta las narices de que hagan las cosas así.

Todas lo hacen mal y tienen pipelines de despliegue nefastas.

Tocar una variable de configuración en runtime es algo que quizás haces 1 vez al año y para troubleshooting.

Pensaba que eso del devops en 2024, despues de 14 años dando por culo con conferencias y blog posts de mierda ya estaba masticado.

2 respuestas
pantocreitor

#58971 secrets de kubernetes para cosas delicadas y configMaps para cosas estándar. Tenemos un pipeline estándar para que salte solo si se sube un cambio a una rama de algún entorno nuestro se ejecute sola o la podemos tirar manualmente si estamos haciendo pruebas en otras ramas, este pipeline actualiza el configMap y redespliega los deployments afectados.
En entornos de cliente (nuestro entorno de prod es básicamente una demo para enseñarle a los clientes o para hacer pruebas) está el pipeline pero solo se puede usar de manera manual por lo que tengo entendido.

#58972 this xD

Edit: por cierto, en producción que yo sepa no se toca nada en caliente a no ser que alguien haya metido la pata, pero por suerte no ha pasado en los casi 2 años que llevo currando aquí.

1 respuesta
Wei-Yu

yo en prod nunca lo he hecho, quizás cambiar una feature flag?

pero normalmente para probar cosas en entornos de prueba le cambio el configmap al despliegue con kubectl y ya

desu

#58973 esto no es cambiar en caliente.

denimH

#58964 No me entero y chagpt no me ayuda mucho, explicalo pa tontos a ver si asi lo pillo :pray:

Konishi

#58972 en algunos casos son valores que condicionan salidas en sistemas físicos y lo quieren así para que no haya que desplegar porque puede cambiar por factores externos sin preaviso y hasta múltiples veces al día. Cuando es por cosa de negocio o un proveedor externo no queda otra que tenerlo ASAP y con el mínimo de afectación posible.

En otros casos que me duelen más son cosas como necesitar múltiples cambios en configuraciones para pasar a usar una nueva feature o hacer un rollback de algo. En este punto sé que el problema principal es el diseño, pero tampoco veo como eliminar la necesidad por completo.

PD: en cuando cambie de trabajo despotricaré a gusto y más de uno se descojonará.

Wei-Yu

puede cambiar por factores externos sin preaviso y hasta múltiples veces al día

los puzzles del scorn dan menos sida que eso

pantocreitor

Estaba pensando una cosa que no sé si es posible con spring y es el cambiar de base de datos en caliente, porque sí que tenemos servicios que leen igualmente de un configMap y si se actualiza puedes hacer que tire el singleton de config y le reinicie con los nuevos valores, pero no me suena haber cambiado nunca la DB en caliente nunca.

1 respuesta
Konishi

#58979 yo lo que me he planteado es cambiar cosas a través de actuator, pero cuando lo necesité en su día para una prueba en un entorno de un cliente no lograba acceder y con el pifostio que había no supe por dónde tirar. Para temas en plan cambiar el nivel de log de un componente específico me parece útil.