Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




Kaledros

#51119 Con el Suchard ni asín.

desu
#51120desu:

El encapsulamiento esun concepto que se quedo deprecated en el 1980-1984 o asi.. No tiene ningun sentido. Lo que quieres es modulos y eso se invento sobre el 1985. Año arriba, año abajo. Hablamos de principios de los años 80s.

Que Java no tuvo modulos, y estaba atascado en "encapsulamiento" hasta Java 1.9. February 29, 2016. Motivo por el cual tambien tiene "private/public/protected", tiene mil historias que no valen para nada.

Osea que programeis con cosas mal diseñadas, llenas de malas practicas y anti patrones... y lo llameis ARQUITECTURA DE SOFTWARE y CLEAN CODE. No lo hace bueno.

Porque el mundo gira fuera de vuestras mentiras.

"una mentira repetida mil veces"...

El java contemporaneo, se escribe sin clases, SOLO RECORDS, porque los nuevos features se han diseñado pensando en que todo sera un record. Imaginate. Java ahora es ANTI OOP.

Fyn4r

Hemos cambiado los edits por responderse a si mismo

2
eXtreM3

#51120 pero quién ha hablado de mutar una variable? Me refería a mutación y persistencia en la BD, genio.

Buena suerte cogiendo un proyecto gordo con cientos o miles de entidades en el que cada una de ellas toque otra sin sentido o simplemente en la parte donde quiso el programador de turno del equipo en lugar de seguir una arquitectura limpia y clara.

"Esto tiene el estado X, en qué punto está ocurirendo esto?" Buscas en el editor algo como Entity->setStatus('w/e') y encuentras 800 ocurrencias. Y así con todo.

1 respuesta
desu

#51124 En ese caso tienes razon. Es bueno tener toda la mutacion en el mismo sitio y que se haga de la misma manera.

Pero no porque lo diga la arquitectura de software.

Porque lo dice el sentido comun y el razonamiento.

Esta demostrado cientificamente que la mejor manera de tener las cosas para encontrarlas despues es ordenandolas y poniendolas "donde las vayas a usar".

vas a cocinar? pues las sartenes las guardas en la cocina.
vas a salir a la calle? tienes un sitio donde tienes tu ropa para salir.

Y asi con todo. Las cosas no se guardan por el como ni el que son, sino el porque las utilizaras.

Esto esta cientificamente demostrado.

Pon mas ejemplos para el grupo de cosas que no sepas justificar o razonar sin usar la arquitectura de software.

La arquitectura del software es falaz y llena de sofismos baratos. Dandole la vuelta a las argumentaciones logicas y formales para vender libros y sacando falsas hipotesis con las que se hacen conclusiones erroneas.

Nombrar las carpetas de una manera u otra y poner las cosas ahi no te haran mejor programador.

1 respuesta
Lifecasi0

Ya lo decía Voltaire. El sentido común es el menos común de los sentidos.

1 respuesta
desu

#51126 “The poet only asks to get his head into the heavens. It is the logician who seeks to get the heavens into his head. And it is his head that splits.”

“Without education, we are in a horrible and deadly danger of taking educated people seriously.”

JuAn4k4

Voy a sacar un libro “dirty code”, y lo pongo con la marca registrada.

El memo es que más da hacer código de mierda mientras funciones si luego va a venir un 20añero fpero a decir que hay que reescribirlo de 0 igualmente, y lo intentarán dos veces, y se quedarán con tu mierda igualmente

1
eXtreM3
#51125desu:

En ese caso tienes razon.

Wow, esto me lo guardo :)

#51125desu:

vas a cocinar? pues las sartenes las guardas en la cocina.

Sí, pero en qué parte de la cocina? Si vas a la cocina de otro sabes dónde están las sartenes? Tú en tu casa puedes tener las sartenes donde quieras: debajo de los fogones, dentro del frigorífico, debajo del lavadero, encima de la campana, dentro del horno... incluso en todos esos lugares a la vez. Está bien para ti y tu caso particular? Sí, un caos organizado en el que sabes dónde se encuentra todo. Y eso asumiendo que tu cocina sea pequeña.

Si llega alguien nuevo a tu cocina crees que imaginará que dentro del frigorífico puede haber una sartén?

Y lo peor: que llegue alguien y te mueva las sartenes de sitio.

Pues igual con el software. Para proyectos lean está bien saltarse las reglas por el forro. Para proyectos serios donde haya un equipo en condiciones, o unificáis la manera de trabajar o vais a pagar las consecuencias -deuda técnica- en 1-2 años.

hda

#51112 ¿pero cuando nos denostas a los de FP es porque tú has estudiado algo superior? Aún fuere así no habría lugar para el clasismo.

¿O es que un tú, quizás sin estudios, denosta a los de FP por unas prácticas que considera incorrectas? Si es esto entonces no sostiene, pues se justifica con la práctica y la experiencia.

En definitiva, @desu: ni doberman ni San Bernardo, sino un chihuahua a quien le gusta mucho ladrar.

3 respuestas
desu

#51130 Yo? Solo soy un poeta

#51127desu:

“Without education, we are in a horrible and deadly danger of taking educated people seriously.”

1 respuesta
hda

#51131 de alcantarilla. Sí.

1 respuesta
crb2222

Lo que mas os jode, en el fondo, es que desu tiene razón

desu

#51132 Por que crees que un hombre mide su valia por los palacios o dineros que pose?

Tener mas no te hace mas.

Todos los hombres somos iguales ante Dios.

Yo un poeta, tu un fpero.

2 respuestas
hda

#51134 ¿Entonces te consideras hombre cultivado?

Abono veo de sobras en ti, pequeño padawan.

¡De la fp y a mucha honra!

1 respuesta
Seyriuu

#51134 Por el patrimonio que tiene diría yo

Dios no creo que exista, si existiera dios explícame por qué existen los fperos y los pajeets

Pos data: Qué cojones es un pajeet, o sea, la definción del diccionario desu

desu

#51135 No considero nada porque seria arrogante de mi parte. Solo soy. Solo existo. Como tu.

Crees que el Sol piensa si debe brillar?

El Sol brilla.

1 respuesta
hda

#51137 en tal caso desiste del clasismo, arrogante poetiso.

1 respuesta
Fyn4r

Recordemos:

Never a master, always a student

1 respuesta
PhDfailer

#51130 luego le dices que tienes más estudios que .y te denosta igual, no es cuestión de estudios

Es uno de los mejores trolls del foro, mis respetos

1 respuesta
hda

#51140 está claro. El problema no es su pantomima, él es nadie, sino la idea que representa. En verdad hay gente que se cree mejor que otra por el nivel de estudios que tiene. Como si significase algo; y la circunstancia, nada. Esto lo he vivido de cerca.

desu

#51138 podria, poesia para hda

podria, y ver como neron el incendio de mi amada roma
podria, y dejar que el tiempo acabe con mi memoria
podria, y seguir el hilo de ariadna
podria, y dejaros atonitos como cuando Anteo vio a Diana
pero como a alejandro que solo apeles pudo retratarlo
a hda mi deber de fpero es llamarlo

3
JuAn4k4

Pues yo discrepo:

Llamada a terceros en el código de aplicación? Si, es parte del negocio.

Llamada al storage directamente ? Si, hasta que necesites algo que justifique la abstracción ( un lock por ejemplo )

Etc

1 2 respuestas
desu

#51139 Bailan y bailan, giran y giran. Estos fperos nunca aprenden y caen y caen.

En la vida hay dias para la poesia, y hay dias para el boxeo.

Les das una master class de programacion, que estoy seguro que ninguno de aqui sabia, y te lo pagan asi.

El hombre siempre sera un desagradecido. Pecadores.

Les duele tanto su ignorancia y les averguenza tanto que pasan al ataque.

eXtreM3

#51143 dices que en un caso de uso (capa application) harías la implementación de un endpoint de terceros (capa infrastructure) ?

Muy bien, pon que tienes varios casos de uso implementando la API de AWS S3 por ejemplo como servicio de almacenamiento en nube. El día de mañana quieres cambiar el storage de S3 por el de Google. Te toca cambiar tooodos los casos de uso y sus implementaciones.

Las implementaciones deben ser lo más agnósticas posibles a las capas interiores, de hecho, las capas interiores no deben conocer cómo se hacen las implementaciones.

2 respuestas
Wei-Yu

#51143 YAGNI excepto en casos en los que sabes que YGNI imho, y hacer un wrapper sobre algo de infra como un cliente http no me parece nada super loco... apenas sobrecargas el código a nivel cognitivo.

es que hasta cuando sólo tienes una línea para llamar a la abstracción inferior tbh

desu

#51145 Te voy a pedir que nos hagas este ejemplo mejor.

Elige uno cualquiera: Google Cloud Pub/Sub , AWS SQS. O si quieres un Kafka o un RabbitMQ, el que te sientas mas comodo, da igual si es in-house o cloud.

Tengo que implementar un consumer y un producer que use uno de estos.

En el futuro quizas lo cambio o no, no lo se.

Como haces la ARQUITECTURA DE SOFTWARE?

PS: Ya te hago spoiler de que lo que vas a hacer esta mal y por eso te he pedido este ejemplo. Por si quieres pensarlo bien. Los blob storage mapean muy facil y son muy interoperables en general, porque los paths de s3 se han convertido en standard por ejemplo, aunque hay alguna diferencia que te putearia. Hazmelo con las queues.

#51145eXtreM3:

Las implementaciones deben ser lo más agnósticas posibles a las capas interiores, de hecho, las capas interiores no deben conocer cómo se hacen las implementaciones.

Esto no lo dices bien. Y me refiero a que no entiendo a que te refieres seriosamente.

La implementacion debe ser lo mas acoplada a la capa inferior posible, para que sea lo mas eficiente y rapida posible. Lo que puede o no puede ser agnostico es la API publica de esta implementacion (modulo, libreria). de esta manera el usuario de la libreria usa algo agnostico o no, pero la implementacion (libreria/modulo) es la mas rapida y eficiente.

1 respuesta
eXtreM3

#51147 Elijo rabbit: Event driven.

En principio bastaría con una clase consumer ubicada en Shared/Infrastructure que procese los eventos. En Shared/Domain podrías tener la interfaz que publique los eventos.

Cada evento ejecutaría uno (o más) listener ubicados en la infra de su correspondiente entidad: ie Citizen/Infrastructure/Listeners donde recibes el payload del evento y ejecutas la implementación.

Esto funciona y es correcto, te guste o no.

Eres muy pesado. La implementación del cloud háztela tú con los cojones.

1 respuesta
desu

#51148 Rabbit tiene diferentes delivery guarantees que kafka o pub/sub o sqs.

Como estas delivery guarantees no las tienes en rabbit, las vas a tener que hacer en codigo tu a manija, donde las metes? y da igual que elijas la mejor tecnologia posible, xq siempre te va a faltar algo. o va a mantener 10 colas distintas.

En el momento en que cambies la cola tu arquitectura de software se va a caer, porque estas colas no son interoperables, no puedes tener una public api agnostica que cubra todos tus casos. tus implementaciones van a leaker al dominio 100%. ademas de ser dominios incorrectos que has forzado. o tu cola era una puta mierda que no movia un 1% del trafico que deberia mover con los recursos que le metias. tu elijes.

Literalmente estamos en medio de una migracion de GCP pub/sub a AWS SQS. Te puedo enseñar cientos de proyectos hexagonales y demas meirda que ahora hay mas mierda que codigo que re-hacer. Eventos mal diseñados. Maquinas de estados que modelaban delivery guarantees que ahora no hacen falta. Etc etc.

Creo que tienes muy poquita experiencia en el mundo real. Deberias LEER MENOS y PROGRAMAR MAS.

En caso de tener trabajo, que dudo que lo tengas, deberias buscar un trabajo bueno y trabajar con equipos buenos.

1 respuesta
eXtreM3

#51149 desconozco cómo funcionan otros brokers de manejo de colas como los que mencionas, PERO YA TE ADELANTO que si cambiar rabbit por sqs implica que la arquitectura de tu proyecto se vaya a la mierda es porque la has diseñado terriblemente mal.

Las colas son totalmente ajenas a las capas de dominio y aplicación. Como mucho vas a tener que cambiar la implementación, y para de contar.

Y ahora te dejo, que estoy trabajando en el mundo real ;)

1 1 respuesta