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

Ranthas #34981 May '22

#34978desu:
luego al implementar sobreescrives este puntero a la funcion...

Mucho puntero, mucho FP, pero hasta mis gatos escriben mejor.

Date un descanso, vacía la mente, vuelve a tus orígenes: bocadillo de nocilla, ver los motorratones de Marte por la tele y completar la serie de cuadernillos Rubio. Me lo agradecerás.

2 2 respuestas

Frave #34982 May '22 Montedamus

A mi me sacas del ABC de Python y ya todo me da pereza.

Wei-Yu #34983 May '22

me espero a que saquen Zig#, con un ad en ascii como MOTD al compilar

desu #34984 May '22

#34980 si necesitas ayuda para escribir 2 lineas de codigo...

HAHAHAHAHAHAHHAHAHAHAHAH

el objetivo es ense;ar a los fperos como tu que no hay magia

y que las discusiones de OOP y boberias del estilo es perder el tiempo...

solo son un par de punteros

imaginate lo estupido que suena hablar de abstract classes, de jerarquias de objetos y demas... si solo es ponerle el puntero al inicializar, y usar el que toca al ejecutar.

y tu preocupado por si tu CarFactory deberia extender Entity o implementar blah blah

HAHAHAHAHAHAHAHHA

#34981 soc catala

1 respuesta

r2d2rigo #34985 May '22 Inocente

#34984 como alguien que ha implementado un sistema de entity/component en "object oriented" C99 te puedo decir que tu "código elegante" es un saco de mierda como todo lo que sueles postear

Ese hack de, ni siquiera fpero, sino quinceañero autodidacta que se cree más listo que Linus Torvalds, hace aguas en cuanto lo sacas del use case trivial que expones.

1 respuesta

B

[Borrado] #34986 May '22

ha tardado en arrancar el lunes, pero esto promete

desu #34987 May '22

#34985 no te voy a dar mucha bola... que hack? si eso es un macro del kernel que lleva decadas ahi. y es como una vtable normal y corriente.

es elegante porque es facil de entender, implementar y para muchisimos casos no vas a tener problemas. los problemas empiezan cuando expones tu codigo generico a usuarios que no sabes lo que haran...

hoy en dia se usan fat pointers pero no creo ni que entiendas porque. porque dudo que sepas como funciona un compilador.

1 respuesta

r2d2rigo #34988 May '22 Inocente

#34987 "hoy en día" = sólo Rust para parchear el desastre andante que es como lenguaje. Los demás apuestan por métodos fiables desarrollados por gente con más experiencia que ego.

1 respuesta

desu #34989 May '22

#34988 que has googleado y te ha salido cosas de rust no? es que el nombre se ha quedado por rust...

HAHAHAHAHAHAHAHAHHA

buena manera de demostrar que no tienes ni idea

go lo usa, todos los lenguajes modernos y librerias modernas lo usan. zig lo usa. incluso haskell lo tiene para algunos casos... un fat pointer solo es una tecnica... como lo uses y para que dependera de ti XD

el problema que tus 2 neuronas nunca entenderan, no es la tecnica de implementacion (como has intentado ridiculizarme) el problema esta en asegurar que el uso de los FPEROS como tu, que no tienen ni puta idea, no se hagan da;o.

has atacado por el lado equivocado tontito, es como decir que usar un puntero es mala idea. mala idea para un fpero como tu. para mi es elegante, 2 lineas de codigo. y voila.

lo dejo aqui, porque esta claro que el bait te ha salido mal

Fyn4r #34990 May '22 Inocente

#34981

los motorratones de Marte

Dios que guapa estaba esa serie, si es que se nota que tienes toque

6 2 respuestas

desu #34991 May '22

#34990 putos boomers

en mi epoca mirabamos esto:

2 1 respuesta

neil90 #34992 May '22

#34991 Todavía se mira

1 respuesta

desu #34993 May '22

#34992 yo me espero a que terminen

me da pereza ir al dia, demasiado relleno

smarquezp #34994 May '22 Inocente

Hoy he tenido 35 minutos ocupados desde las 8 de la mañana, el resto, libre.

Bendito teletrabajo un lunes.

1

Kaledros #34995 May '22

#34990 La serie y el juego, que era una vil copia del Rock and roll racing pero molaba una barbaridad.

Una fortuna me dejé yo en esta maquina.

2

desu #34996 May '22

La joyita que he visto hoy:

En una libreria common.

struct BaseStruct {
    commonA int
    commonB int
}

En los proyectos que usan esta libreria:

// proyecto A

struct proyectoAStruct {
   base common.BaseStruct
   specific1 int
   specific2 int
}

// proyecto B

struct proyectoBStruct {
   base common.BaseStruct
   specificW int
   specificZ int
}

Captas la idea no?

Madre mia... Me rio por no llorar.

Diras no esta tan mal no? Pues faltan los serializers especificos... ProyectoA tiene su serializer y el proyectoB su otro serializer y lo que hacen es sobre escribir una funcion de la common... madre mia que sin sentido XDDDDD Lo que hace incluir una "jerarquia" sin sentido.

https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

Son 2 structs... 2 funciones... no es que tengas 150 structs que quieras simplificar o algo de "code duplication" y demas excusas que ponen los fperos no... Son 2 funciones... XD Los hijos de puta han hecho codigo generico en lugar de copy pastear 2 veces el codigo.. aix que hago ahora? lo tengo que re hacer todo... porque las abstracciones de mierda son eso, abstracciones de mierda.

La solucion en go es simplemente esta... para cada struct que quieres serializar solo lo tienes que pasar al serializer de la stdlib...

	var response MyStructA
	if err := json.NewDecoder(r.Body).Decode(&response); err != nil {
		return nil, err
	}

1 respuesta

Kaledros #34997 May '22

#34996

Programmer A sees duplication.

Programmer A extracts duplication and gives it a name.

This creates a new abstraction. It could be a new method, or perhaps even a new class.

3.Programmer A replaces the duplication with the new abstraction.

Ah, the code is perfect. Programmer A trots happily away.

Time passes.

A new requirement appears for which the current abstraction is almost perfect.

Programmer B gets tasked to implement this requirement.

Programmer B feels honor-bound to retain the existing abstraction, but since isn't exactly the same for every case, they alter the code to take a parameter, and then add logic to conditionally do the right thing based on the value of that parameter.

What was once a universal abstraction now behaves differently for different cases.

Another new requirement arrives.
Programmer X.
Another additional parameter.
Another new conditional.
Loop until code becomes incomprehensible.

You appear in the story about here, and your life takes a dramatic turn for the worse.

Esto es literalmente lo que nos ha pasado en mi antiguo curro tantas veces que por eso me he ido.

Afortunadamente, nosotros nos quedábamos en el punto 5 y cuando detectábamos una nueva necesidad simplemente refactorizábamos, pero es que no paraban de llegar nuevas necesidades porque no había nadie definiendo una mierda. Cuando no sabes bien lo que tienes que hacer y planteas abstracciones basadas en premisas incompletas al final te toca tirar el proyecto a la basura cada seis meses y volverlo a hacer. Y el problema de estas cosas es que nunca nadie se para a pensar en que igual más que refactorizar lo que se necesita es definir las cosas bien desde el principio, hacer algo escalable o que no cueste mucho de refactorizar y tirar millas. Y entonces abstraer.

1 1 respuesta

desu #34998 May '22

#34997Kaledros:
r lo que se necesita es definir las cosas bien desde el principio, hacer algo escalable o que no cueste mucho de refactorizar y tirar millas. Y entonces abstraer.

casi lo tienes, casi eres un jardinero: https://www.arnaudiaz.com/blog/engineers-as-gardeners/

las cosas NUNCA se definiran bien desde el principio

es como tener un hijo y planearle su vida, SU VIDA, hasta la universidad. sabes que no se va a cumplir verdad? el software es lo mismo

pero si, a la segunda parte, escribir codigo que es facil de re escribir, ahi esta una de las grandes claves de un buen programador.

esto es lo que me paso hace unos a;os con el becario que hacia haskell en typescript, no se si os acordais, pero ya conte como yo programo codigo que sea facil de tirar porque en unos meses cambiara, el hizo sus tipados raros... llego el momento de re hacer el codigo y... mis HAHAHAHAHAHAHA aun resuenan por la antigua oficina.

el fantasma del fpero HAHAHAHAHAH

tengo que admitir que yo al no haber visto esta fpeada por el codigo, tambien he cometido un error... XD porque tengo una interface que ahora ya no me vale... la tenia para testear... no cambia nada pero joder. hasta a mi me ha jodido esto porque lo he visto justo al final.

1 respuesta

JuAn4k4 #34999 May '22

Si vierais el código de mi empresa, clases de config que solo se pueden settear por json, ni con un new programaticamente se puede hacer nada. Y luego implementan un des-serializador que lee un fichero del sistema para setear valores y si no está ahí llama a una API.

Luego quieres hacer un clone para hacer un immutable copy o poder setear varias cosas de vez para que la config como tal no tenga race conditions donde sea inválida, pues o haces 400 hacks o rehaces software hecho por 8000 personas.

Entrada para el blog ese: Eliminar la magia.

1 respuesta

Kaledros #35000 May '22

#34998 Sí, claro, cuando digo definir no me refiero a tenerlo todo escrito en piedra desde el principio, eso es imposible. Siempre te encuentras cosas que cambiar porque te has pasado algo por alto.

A lo que me refiero es a no condicionar la arquitectura a nociones o conocimientos que sabes que están incompletos. Si te digo que tienes que diseñar tres funcionalidades de una API (endpoint, servicio, etc) y después de analizar la primera me empiezas a abstraer cosas lo más normal es que te pilles los dedos cuando tengas las tres funcionalidades analizadas y te encuentres con que has metido la pata y posiblemente te toque tirarlo todo a la basura.

Cuando esos cambios implican conocimiento de negocio pues bueno, algo de lo que has hecho te sirve, no has perdido el tiempo del todo. Pero cuando lo único que has hecho es funcionalidad técnica, nada de negocio sino arquitectura 100%, has tirado todo a la basura y no te ha servido de nada.

desu #35001 May '22

#34999 esa es nuestra codebase java XD

en go tengo los huevos de re hacer todo (que lo estoy re haciendo todo por cierto) pero en java me doy por vencido... convence a la gente de quitar sprint... que es el primer paso... nah.

a mi me la suda, en las CR mato a quien haga falta, que luego si quieren hacer merge adelante pero que sepan que esta mal, y luego si tengo que hacer algo voy a pasar la escoba y re hacer todo si me toca los huevos, me suda la polla estar 1 semana mas de trabajo.

es que llevo hoy por ejemplo ya 30 minutos bloqueado pensando en como arreglar esa liada... no deberia perder el tiempo en esto sabes? que eran 2 structs... haber escrito el codigo 2 putas veces copy paste cambiando el tipo cabrones XD

creo que una leccion que voy a sacar, es que cuando trabajas con gente, quizas nunca hay que meter ni interfaces ni nada, todo lo mas claro y facil posible... asi si alguien la ha liado no te afectara nunca... si no se puede confiar en la gente, mejor ser defensivo.

edit: soy un puto dios picando y puedo arreglarlo facilmente... pero si falla no devolvera errores XD pero bueno, al menos no es un full refactor de 1k loc

Kaledros #35002 May '22

A principios de año nos obliga la empresa a vincular el teléfono a nuestra cuenta de Google corporativa por lo de la autenticación en dos pasos. Le digo a mi jefe que paso de usar mi móvil particular para eso pero me dice que es por seguridad, etc. Pos bueno, ellos sabrán.

Llevo toda la mañana recibiendo códigos de autenticación por SMS con el mensaje en alemán e ignorando el Whatsapp de mi jefe para que por favor se los copie y pegue porque los de IT no pueden eliminar mi cuenta de Google corporativa. No sé si ignorarlo para siempre o decirle algo dentro de una semana.

1 respuesta

desu #35003 May '22

#35002 Anda no seas tontito y pasale el codigo.

1 respuesta

Kaledros #35004 May '22

#35003 Si su departamento de IT no sabe borrar una cuenta de Google sin consultarme eso es una espléndida oportunidad de aprendizaje. Les estoy haciendo un favor, van a aprender gracias a mí.

1