Feda /dev/ - No Javascript allowed

#22981 lo jodido es que programe todos los chorri algoritmos metaheuristicos cuantos hay. Estaría orgulloso si no fuesen todos lo mismo, tirar los dados y rezar para llegar a una solución que no de vergüenza xd

Veo que habéis comentado arquitectura hexagonal + DDD, a ver si os animáis un día en dar una clase en Twitch o recomendar literatura sobre el tema, que estoy empezando a leer sobre ello y cada vez me gusta más, aunque me cuesta materializarlo en forma de código.

#22987 es por entropía. Yo estas mierdas tenía que hacerlas a mano. Así te enterabas si o si de como se hacía. Edit: mejor la wikipedia en ingles que en español casi me da un algo. https://en.wikipedia.org/wiki/ID3_algorithm

#22987 hijo de puta como lo tienes implementado si ni sabes lo que hace?

Te da ese resultado por como funciona el algoritmo, te lo han explicado arriba.

Y te da el mismo resultado siempre porque es greedy.

Una manera de mejorar el algoritmo es pensarlo de esta manera. Greedy explora 1 nivel y se queda con lo mejor. Que pasaria si explorases 2 niveles de profundidad antes de tomar la decision? Que pasaria si explorases 3 niveles de profunidad? Es decir, miraria la entropia una vez explorados N niveles antes de quedarme con un nodo com padre y volver a seguir el algoritmo.

Vuelve a picar tu codigo pasando este nivel de exploracion por parametro y pruebale a meterle mas profundidad, te daran mejores arboles de decision.

Ten cuidado porque es un problema de combinatoria y crece exponencialmente.

Como puedes ver, no cuesta mucho mejorar la "inteligencia artificial" que hacían los abuelos.

Ah. si en lugar de hacer siempre el mejor (da igual cuantos niveles) le metes una probabilidad de random, acabas de descubrir la exploracion aleatoria y ya casi estas en el estado del arte actual. HAHAHAHAHAHAH

Venga ya que estoy te doy lo guinda del paste, si tiras algoritmos por encima de estos arboles de decision para ver que % de random y que nivel de exploracion necesitas para cada tipologia de arbol estas en el a;o 2020 publicando papers de NN sobre optimizacion y busquedas HAHAHAHAHAHHA CAMPO MUERTO. AI = HUMO PARA PAJEETS.

#22986 Tal cual dice #22991

"Like many things that have the potential to make you feel clever, e.g. machine learning, functional programming, DDD can easily be overused / used for the wrong reasons, at least if it's not mastered to a certain level.

When I first learned about DDD in 2008 or so, I was so proud of myself that each and every service was DDDified, which really put a huge mental burden on me and my team. It is not only that you have to think really deeply about your domain (which is usually a good thing) but you often come to a point where doing things the DDD way means a lot more work, e.g. creating Anti-Corruption Layers between bounded contexts. I spent so much time researching if I do things correctly and if the acknowledged prophets consider a design decision acceptable that coding started to hurt.

At some point however - and I think this what happens whenever you master something sufficiently - the penny dropped that the subtitle of the Eric Evans book "Tackling complexity in the heart of the software" really meant something: that DDD was a method for building complex software. The book itself - if you read it carefully as I did many years later - says explicitly that you should not use DDD for most parts of your system but only complex "core domains".

Nowadays, I am designing most services as "Transaction Scripts" again. Without feeling guilty. "

#22991 En la empresa se están planteando ir hacia aquí, y en mi caso me lo conozco de oídas por eso quiero estar al día.

Hasta el momento esa sobreingenieria que se hace es para desacoplar las capas y no tener una database-centric application (la idea no me parece mal), pero es cierto que empiezan a aparecer muchas interficies por todos lados con la historia del SOLID y me da respeto que microservicios pequeños que nunca van a evolucionar se conviertan en mastodontes por el "quizá algún día es necesario cambiar la base de datos"

#22992 Muchas gracias por la cita, leyéndola veo que sería el caso que quieren hacer en la empresa, y por lo tanto, un bad pattern para servicios pequeños y nada complejos. Me apunto el libro "Tackling complexity in the heart of the software"

#22997 habra que ver que representa ese ddd. pero ya te digo que ddd va de la mano de data oriented.

si tu en tu negocio vendes coches y por ese motivo tienes una entidad coche. no has entendido ddd.

es el mismo error que hacen los pajeets en el dise;o de entidades para persistir en tablas relacionales.

como en el mundo real un coche lo pueden vender, tienen la tabla coche y luego otra de ventas con la fecha y el foreign id. esto te lo ense;an en la universidad... esta mal. no han tirado una query ni analizado datos en produccion en su puta vida.

y viene de que no tienen casos de uso reales ni un negocio real que les ponga requerimientos. estos problemas de juguete luego los aplicas al mundo real y solo escribes boberia. pero bueno, cuando tu negocio es vender libros que quieres hacer? es lo que hay xico.

yo siempre he dicho que lo hago y tal, pero dada la confusion que existe, procedo a decir que no lo hago y es una mierda. XD prefiero ser precavido.

ah premio para los anormales que el mismo DTO que reciben por un webservice lo usan en negocio y lo persisten en db. premio. en este hilo tenemos minimo 4 que yo sepa.

por cierto el tema de las carpetas me tiltea mucho porque no saben lo que es un puto modulo ni como se compila un proyecto o que cojones están haciendo en sus lenguajes de mierda. el código se separa en carpetas dependiendo de como funcione tu lenguaje y tu compilador no hay mas.

#22998 por eso lo de "si de verdad intercambias alguna capa"
la realidad está en que luego no se cambia ninguna capa, no se reutiliza nada (se hace todo de cero de nuevo), no solo hay CocheEntitity, también el CocheDTO, CocheRepository, y como no, CocheController.

A mi estás cosas son las que más me chirrían en el curro