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

desu #34711 May '22

@wei-yu

HAHAHAHAHAHA

el dise;o de apis esta mas que masticado, voy a darte unos consejitos que se me han ocurrido con el debate de hoy:

la encapsulacion es una mala practica deprecated desde los 80
no default hells
inyeccion de dependencias siempre
nunca inyeccion de contenedores u OOP (deprecated)
entran interfaces salen tipos concretos
validar es mala practica, siempre parsear
romper rapido y que el usuario se entere
no crear abstracciones, resolver tu problema de la manera mas explicita posible
no hacer branchings en implementacion
no resolver en runtime lo que sabes en comptime
data flow de librerias > frameworks
config > argumentos > pipe stdin/stdout > variable de entorno solo como ultimo recurso (no deberian usarse nunca hoy en dia)
escuela de LISP > escuela UNIX, usar solo las cosas que han funcionado de UNIX como ultima opcion para no romper algo, las que he puesto del kernel o que se usan en stdlibs. pero romper si se va de las manos. i.e kernel cada X a;os.

No se si me dejo alguno.

MTX_Anubis #34712 May '22 :psyduck:

#34704 El DDD se basa en un principio: El dominio de un negocio es demasiado complejo como para que se pueda haber un sólo modelo. Esto ocurre en la realidad: La visión que se tiene de un cliente en una empresa no es igual para el departamente de ventas que para el de shipping que para otro departamento que quizá ni si quiera conozca la existencia de clientes (no la usa en su trabajo).

Le sumamos además que a la hora de modelar un dominio siempre se pierde información (se hace siempre incapié en hacer explícito lo implícito, que no viene al caso pero es parecido a lo que está hablando @desu xD), a la hora de implementarlo se vuelve a perder información por simple limitaciones tecnológicas.

Así que el DDD busca esas áreas donde se puede aplicar un sólo dominio (en una empresa se suelen identificar con departamentos). Qué es un bounded context? Una separación lógica u operacional donde un conjunto de reglas y procesos aplican sobre un sólo dominio. Así es más o menos la definición formal y estos bounded context van a cambiar conforme cambie la empresa.

Y esto se hace para que pudan evolucionar de forma independiente porque los requisitos y la evolución de cada subdominio va a cambiar con el tiempo y tomarán caminos distintos. Además te ayuda a ponerle foco en lo importante y el resto que son genéricos o que aportan poco valor, si encuentras algo que ya haga algo parecido y te pudes apañar con ello mejor.

Como descubrirlos? Hablando mucho con los clientes o gente de negocio y preguntándoles mucho. Además de crear un lenguage común para todo el mundo se entienda y hablen el mismo idioma, el "lenguaje ubicuo" xD. No es tan sencillo de modularizar una aplicación por funcionalidades.

Y el problema es que la mayor parte de la literatura que te encuentas no se centra en esto, se centra en cómo implementar los bounded context y como se comunican, vas a ver un montón de mierda de CQRS, event bus y hexagonal y nada de hacer una reunión de desarrolladores y expertos para ver como coño identificar esos bounded context.

1 2 respuestas

Ranthas #34713 May '22

#34712MTX_Anubis:
Y el problema es que la mayor parte de la literatura que te encuentas no se centra en esto, se centra en cómo implementar los bounded context y como se comunican, vas a ver un montón de mierda de CQRS, event bus y hexagonal y nada de hacer una reunión de desarrolladores y expertos para ver como coño identificar esos bounded context.

Porque admitir esto significa admitir que la ingeniería del software como tal es una "ciencia" condenada y que bajo ningún concepto debería denominarse "ingeniería".

Luego te das cuenta que Dijkstra decía lo mismo a finales de los 80 y te percatas de que llevamos 40 años dando vueltas en círculos y perdiendo conocimiento a puñados. Y la prueba fehaciente la tienes en la mierda de literatura existente, cuando la divulgación tiene un nivel tan fecal, sabes que no va a pasar nada bueno.

5 1 respuesta

desu #34714 May '22

ojala te pudiese dar mas manitas, que gran post rata asquerosa.

#34713Ranthas:
Porque admitir esto significa admitir que la ingeniería del software como tal es una "ciencia" condenada y que bajo ningún concepto debería denominarse "ingeniería".

jardineria********

https://www.arnaudiaz.com/blog/engineers-as-gardeners/

la palabra que buscas es jardineria. los ingenieros de software SOMOS jardineros. yo soy jardinero de software. artista. y jardinero.

como bien dices, la realidad es que en los 70s tenemos dise;o unix, 80s forth, lisp... siempre hemos modelado los problemas pensando en memoria y cpus... la gran mentira de los 90 y 00 con la OOP ha sido un gran golpe a la industria. la OOP que ni siquiera es real OOP que seria Erlang y elixir...

evans con DDD tampoco ayuda mucho, en su dia no entendia que estaba mal del libro pero ahora es claro cristalino. desde que soy en el top 0.0001% programar es facil. aunque la idea de hexagonal y demas no es mas que dise;o modular de los 80 aplicado a apis y microservicios, eso esta bien.

mike acton en el 08 lo dijo genial, las 3 gran mentiras:

https://cellperformance.beyond3d.com/articles/2008/03/three-big-lies.html

(Lie #2) Code should be designed around a model of the world

NOOOOOOOOOOOO NUUUUNCAAAA

#34713Ranthas:
perdiendo conocimiento a puñados. Y la prueba fehaciente la tienes en la mierda de literatura existente, cuando la divulgación tiene un nivel tan fecal, sabes que no va a pasar nada bueno.

Por eso mi blog ahora mismo es el mejor contenido en informatica contemporanea. seguramente es de los mejores blogs del planeta.

tengo un par de posts en proceso.

me cuesta cargar con el peso de las industrias a mi espalda, pero poco a poco...

Kaledros #34715 May '22

#34712MTX_Anubis:
Y el problema es que la mayor parte de la literatura que te encuentas no se centra en esto, se centra en cómo implementar los bounded context y como se comunican, vas a ver un montón de mierda de CQRS, event bus y hexagonal y nada de hacer una reunión de desarrolladores y expertos para ver como coño identificar esos bounded context.

Iba a decir que esto nos ha pasado factura a nosotros, pero en realidad nos ha atropellado como un tren de mercancías.

El CTO y el PO estaban más centrados en las tecnologías que había que usar que en resolver problemas como ese (definición de la API, requirements de negocio, use cases, integraciones, etc) y eso ha llevado a muchos reboots y refactorizaciones de la arquitectura porque los requirements no estaban bien definidos y se han encontrado errores fundamentales por falta de análisis. Y es lo que dices, toda la literatura y toda la divulgación al respecto se basa en el qué y no en el cómo. No necesito que cada libro me explique qué es la arquitectura hexagonal, explícame cuándo se usa y qué se necesita para poder implementarla.

1

PaCoX #34716 May '22 Ant queen

#34708 pero que hablas flipao xd relaja la raja Arnau.
No me compares una system API con tu payment api. A lo mejor algún día te toca hacer una política de breaking changes y te das cuenta del tema, o si evolucinas y te toca lidiar con una pública que usen millones de personas, ya me dirás xd.

2 1 respuesta

desu #34717 May '22

#34716 paquito. podria ser tu hijo y tengo mas toque que tu... la edad de los dinosaurios ya ha pasado... aporta o aparta.

el tema de ayer ya quedo zanjado, hoy le toca a @vago_21 animar el hilo con debate.

Es mi wp, esta to guapo

spoiler

B

[Borrado] #34718 May '22

creéis que hay algo que esperar de esta industria?

paulinho #34719 May '22

A mi lo que de verdad me intriga es de donde carajos salió la moda de informáticos llenando sus portátiles de stickers.

2 1 respuesta

_Rpv #34720 May '22

#34719 Es una forma de reconocerse entre elles.
Así se puede ver de lejos en que mierda trabaja sin tener que entablar conversación o chuparse les polles entre elles.

B

[Borrado] #34721 May '22

p.

1 4 respuestas

eondev #34722 May '22 Rawe Ceek

#34721 tranqui que quien necesita ver un videotutorial no te va a quitar el curro

3 respuestas

B

[Borrado] #34723 May '22

#34722 no me preocupa que me quiten el curro, me preocupa la decadencia, soy uno más en la rueda

1 respuesta

Wei-Yu #34724 May '22

#34722eondev:
tranqui que quien necesita ver un videotutorial no te va a quitar el curro

igual sí

PaCoX #34725 May '22 Ant queen

#34721 quizas estas en el sector equivocado

1 respuesta

eondev #34726 May '22 Rawe Ceek

#34723 nah, la decadencia es normal en todo lo que se masifica. Pero a mí me la pela, siendo un inútil noname puedes destacar sobre el average joe solo por ser un frikazo.

Wei-Yu #34727 May '22

seguro que luego pasáis las culturales con ese autismo y yo no

reeeeeEEEEEEEEEee

3

Fyn4r #34728 May '22 Inocente

antes el desarrollo de software era otra cosa

Antes todo esto era campo, IT edition

9

B

[Borrado] #34729 May '22

#34725 creo que no, cambié radicalmente de sector en diciembre, pero me encuentro la misma sensación pero en otro trabajo que aporta "más valor"

newfag #34730 May '22

#34722 ¿insinúas que tú no has visto tutoriales?

1 respuesta

eondev #34731 May '22 Rawe Ceek

#34730 nunca he tenido paciencia de ver 1 min seguido sin ponerme de mala ostia la verdad xD

Ojalá videos con transcripción

1 respuesta

PiradoIV #34732 May '22 Brongster

#34731 El truco está en verlos a 1.5x.

1 respuesta

Martita- #34733 May '22 Last Sorcerer Standing

Mediavida, el lugar donde se aprende a programar sin mirar documentacion.

Los verdaderos programadores, salvadores de la industria.

2

Kaledros #34734 May '22

#34721vago_21:
antes el desarrollo de software era otra cosa

Y ya no se hace música como la de antes, ya no se hacen películas como las de antes, etc. Es lo que tiene que se democratice el acceso a las herramientas de creación, que cambia la forma de hacer cosas porque hay mucha más gente haciéndolas. Y eso sólo puede ser bueno.

1

B

[Borrado] #34735 May '22

veo que no entendéis o no queréis entender lo que intento exponer, puede que hasta no haya explicado bien lo que pienso de la industria actual, por mí podemos dejar el tema

2 respuestas

eondev #34736 May '22 Rawe Ceek

#34732 ojalá algún día se pueda hacer control + f a un vídeo

1 respuesta

desu #34737 May '22

#34736 miras los captions y haces ctrl + f, ahi te sale el timestamp

#34735 asi se siente amigo vago

sacas un tema y la gente responde cosas completamente distintas

y el culpable eres tu

1 respuesta

Kaledros #34738 May '22

#34735 Entiendo que echas de menos un propósito más elevado o un nivel de artesanía en esto de picar código. Me parece bien. Pero no podemos meter en el mismo saco a toda una industria que va desde poner satélites en órbita hasta pintar stickers en una pantalla, son productos diferentes con requisitos diferentes, tiempos diferentes y que básicamente sólo tienen en común que usan código en algún momento.

2 respuestas

Fyn4r #34739 May '22 Inocente

artesanía

DINDINDIN!! Premio para el caballero por acertar la palabra mágica del hilo, artisan.

B

[Borrado] #34740 May '22

#34737desu:
sacas un tema y la gente responde cosas completamente distintas

pues sí, y ya ni creo que creando un tema a parte se pueda discutir sobre este tema de forma adulta

#34738Kaledros:
Entiendo que echas de menos un propósito más elevado o un nivel de artesanía en esto de picar código

exacto, y también originalidad

1 respuesta

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales