Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




desu

@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

#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
#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

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
#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

#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

#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

B

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

paulinho

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

#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

p.

1 4 respuestas
eondev

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

3 respuestas
B

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

1 respuesta
Wei-Yu
#34722eondev:

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

igual sí :new_moon_with_face:

PaCoX

#34721 quizas estas en el sector equivocado

1 respuesta
eondev

#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

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

reeeeeEEEEEEEEEee

3
Fyn4r

antes el desarrollo de software era otra cosa

Antes todo esto era campo, IT edition

9
B

#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

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

1 respuesta
eondev

#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

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

1 respuesta
Martita-

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

Los verdaderos programadores, salvadores de la industria.

2
Kaledros
#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

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

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

1 respuesta
desu

#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

#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

artesanía

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

B
#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