Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




Ranthas
#27330MTX_Anubis:

meter un specification y joins es malo

Estas son las cosas que me matan, porque quienes suelen ir pregonando esto la SQL más complicada que han tirado en su vida es un select * from customers. Aunque supongo que cualquier excusa es buena para subirte al carro del approach de moda y montar CQSR aunque tu mierda de aplicación solo permita filtrar por dos campos.

Ahora sólo nos queda ver cuando tiempo durará esta moda hasta que llegue la siguiente

1 respuesta
Wei-Yu

coño pero te ponen ejemplos sencillos para no tener que explicarte el contexto del propio ejemplo y poder articular una implementación o una cara más pragmática del concepto, eso cae de cajón cabrones

"vamos a enseñarte un caso de uso real pero para entender el ejemplo tienes que trabajar 2 meses full time"

1 respuesta
desu

#27330 Es que estoy sufriendo para encontrar material sobre este tema.

Ando leyendo bastante de dise;os del mundo real. Por ejemplo acabo de verme esta de Twitter https://www.slideshare.net/nkallen/q-con-3770885

Es del 2010, pero fijate en los numeros que manejan... Ya son numeros barbaros. Soluciones sencillas. Me quedo con esta frase de la diapositiva 70.

Scalability solutions arent magic. they involve PARTITIONING, INDEXING and REPLICATION

Aun no he encontrado 1 buena justificacion de CUANDO METER COLAS Y POR QUE MOTIVOS TECNICOS CQRS / EVENTOS. Es decir, te dicen que hay que meter esto para desacolpar, para tener tal arquitectura, etc. Pero dime QUE PROBLEMA DE ENGINIERIA estas resolviendo. Que problema tenias con las alternativas y como lo solucionas mejor. Porque solo me estas hablando de arquitectura y de conceptos. Separar servicios, desacoplar consumidores y productores, blah blah. Todo es arquitectura/conceptual. Dime motivos TECNICOS de INGENIERIA. Ostia puta.

Tener colas o no dentro es una deicsion de arquitectura que te va a condicionar todo el modelado de todos tus servicios. No es una decision gratis. Ademas vas a a;adir brokers, vas a a;adir zookeeper o etc...

Luego se lo preguntas a gente que usa eventos y cqrs y tampoco te saben responder a nivel tecnico o no quieren. en este hilo por ejemplo mucha gente usa kafkal. esta pregunta la he hecho muchas veces y nunca me han dado la respuesta que espero. se van por las ramas.

Y como digo, mucha gente muestra su ignorancia de como funcionan las DB o las colas mismas a bajo nivel. Comente mi experiencia del otro dia. En una system design tenemos un escenario de bottleneck en DB. Su solucion meter una COLA. LOL? Perdona??? eso no soluciona la escritura. tansolo estas moviendo el problema a la cola... Y si quieres mover el problema la mejor opcion es una WAL que haga dunmp como comente el otro dia. Esa es la solucion simple y facil. meter un kafka y zookeeper es no tener ni puta idea de lo que haces.

#27332 eso no es cierto, es un contenido de baja calidad, mal explicado. con errores (quizas son lapsus / cosas mal dichas por estar improvisando). pero todo esto demuestra que no tienen ni idea de como van las cosas tecnicamente a bajo nivel. ni los pros/cons reals.

si quires contenido de calidad, lee blogs de enginieria de casos reales. pinteres, twitter, linkedin... veras que NO SON DIFICILES de entender. Al contrario SON MAS FACILES. Son implementaciones mas sencillas y faciles. Punto. ni colas ni ddd ni pollas de pajeet como tu.

3 respuestas
Wei-Yu

#27333 claro que los tech blogs son más sencillos de entender pero porque normalmente hablan de una solución concreta o algo muy muy acotado, no te dan un repaso bueno por la teoría y te ayudan a ponerlo en práctica, son cosas distintas.

2 respuestas
Kaledros
#27333desu:

estar improvisando

Este es el mayor problema y una cosa que no pasa en canales más profesionales, donde si la meten es a conciencia pero al menos no se van por las ramas y cada palabra que te dicen cuenta.

Ranthas

#27334 Porque ese tipo de soluciones, como CQSR, son para una serie de problemas específicos y acotados. La mayoría de aquí en su día a día no debería tener necesidad alguna de montar CQSR, pero ese tipo de "cursos", "publicaciones" o como quieras llamarlos te venden la """necesidad""" de montarlo.

1 respuesta
Wei-Yu

#27336 tampoco estoy muy puesto como para hablar de ello (lo de hablar mucho sabiendo poco se lo dejo a desu), pero entiendo que una solución a nivel de arquitectura responde a unas necesidades que muchas veces tienen poco de específico y acotado. Al final es una balanza en la que tienes que tener muchas cosas en mente, y entiendo qeu muchas veces son cosas con las que no estás familiarizado o a las que te tienes que anticipar y en un escenario concreto crees que XYZ será buena idea pero luego no tiene por qué serlo.

Y para qué engañarnos, hacer algo porque te apetece también está bien mientras no seas un talibán, que si tienes libertad creativa por qué no aprovecharla mientras no hundas el barco.

1 respuesta
vivora

#27337 Una cosa es tener libertad para hacer lo que quieras (que me parece bien, a modo de aprendizaje para un proyecto personal, aunque no aplique exactamente esa arquitectura, si quieres usarla, pues úsala) y otra cosa es hacer vídeos y exponerlos a la gente diciendo que tienen que aplicar TDD hasta para ir a mear y sino lo están haciendo mal.

1 respuesta
desu

Estáis desviando la discusión hacia arquitectura/conceptual.

Eso es precisamente lo que no quiero.

Dejad de hablar boberia, voy al barbero. Al regresar os pongo un ejemplo de lo que es una discusión de enginyeria / técnica. Porque los fperos veo que os perdéis en la superficie. Precisamente por esto, los de codely os venden sud cursos HAHAHAHAHA

B

.

Kaledros

A mí los de Codely, pudiendo ser muy mejorable, me solucionan muchas papeletas. Si en 20 minuts de vídeo salgo entendiendo una tecnología y a partir de ahí ya puedo tirar, prefiero eso a empezar leyendo documentación árida. Que el comité de pureza me denuncie si quiere, no me escondo.

1 1 respuesta
Fyn4r

#27341 Una búsqueda en YT tipo "<Tech> Crash Course" es lo mejor xd

1 1 respuesta
Lecherito

Soy el unico que va directamente a la pagina a leer la documentacion? xD

4 2 respuestas
eondev

#27343 se ve que si xDDDD

B

.

Kaledros

#27342 ¡Como lo sabes!

MTX_Anubis

#27331 Mira con lo de Zara, la gente quejándose de que había preguntas de SQL. Por Twitter un tío con 15 años de experiencia diciendo que con los ORM llevaba como 10 años sin picar una SQL xDDDDDDDDDDDDD

SQL es el puto lenguaje que debería ser universal (lo uses o no). Lo debería conocer todo el mundo.

#27333 Tal cual. Yo leí mucho de como se había escalado Twitter allá por el 2012-13 cuando me puse con Scala (era la única gran empresa que lo usaba masivamente). No solo Twitter; también Netflix, Tumbrl, Instagram, FB y unos cuantos más. No te puedo ayudar mucho porque ya sudo del tema, al final cada empresa ha hecho las soluciones in-house porque no había nada igual y encontrar los blogs ahora con la mierda que es Google es casi imposible. Recuerdo uno de Instagram que hablaban de sharding con PG.

Y los de los event-bus cqrs, ddd y sus mierdas pues eso, rescatando conceptos de hace 10 o 15 años (y que simplemente le dieron nombres a técnicas y diseños que ya se usaban con SOA). Redescubriendo santos griales y balas de plata.

#27334 El problema es cuando te hablan de MVC para criticarlo y venderte sus mierdas de DDD, te dicen que es del 2003. Te dicen que se inventó con Spring o Rails y te dicen que en MVC se usa el ActiveRecord pattern.

Y es que todo eso es mentira.

1 2 respuestas
B

.

1 2 respuestas
eondev

#27348 Hasta ellos mismos se contradicen en 2 videos distintos, menudos subtards

MisKo

Para cuando un Desudely ?? Asi podría ver sus masterclass en youtube.

Podría verme los resubidos de twitch, pero prefiero las cosas organizadas xD

Ranthas

#27347 Y a ver, si en tu curro no tienes que tirar SQLs porque es una mierda y con un ORM te es suficiente, es totalmente respetable, y es lo bueno que tiene esta profesión: tienes herramientas de todas las formas y colores para cada una de las necesidades que te puedan surgir.

El problema aparece cuando extrapolas ese curro de mierda a todos los curros del sector, porque piensas que la informática es configurar el IDE con colorines y llenar el node_modules de dependencias absurdas. Ya pasó con la moda de las NoSQL, iban a matar a las bbdd relacionales, etc, eran los mismos cantamañanas que hoy te dicen que tienes que meter DDD hasta en la sopa, que MVC es peor que el cáncer de colon y que los bloques switch son satánicos.

Al final se reduce a que si eres una persona con experiencia o curiosidad, vas a esquivar ese tipo de contenido como a un leproso, y si eres el picateclas average pues ahí estarás a tope gastandote 9,99$ semanales en el curso de moda que te han recomendado los gurús del picateclismo, del cuál no tienes ni idea de por qué o para qué usarlo, ejemplificando en su máximo expresión el latinismo "magister dixit".

desu

@wei-yu @MTX_Anubis @vivora @kaledros @Ranthas

Ya he vuelto del barbero, fresh as fuck. En el proximo stream vereis el corte.

La idea es, cuando usar CQRS motivado por una decision tecnologica.

Os hare un ejemplo facil y para toda la familia. Fperos incluidos.

Nota; No estoy siguiendo la historia ni nada, solo es un ejemplo para que se entienda.

Tengo un sistema A y un sistema B. Necesito comunicarme entre ellos. Mando un mensaje de A a B. B tiene que entender este mensaje. Para ello nos ponemos de acuerdo y hacemos un protocolo de serializacion/deserializacion que sabemos interpretar.

En lugar de tener para cada sistema su protocolo, y su compa;ia su protocolo, y tal y cual. La comunidad decide hacer un protocolo standard y animar a la gente a que lo use. Le llamamos JSON.

JSON es una solucion tecnologica a la serializacion y deseralizacion. En lugar de cada sistema/compa;ia/cluster de empresas usar su propio protocolo, todos vamos a una para tener interoperabilidad. Ademas se hacen librerias sobre este protocolo que son muy rapidas y eficientes.

Con esto ya hemos decidido CUSTOM PROTOCOL vs USAR JSON. Que a nivel de arquitectura, mas alto nivel, podria responder a la analogia, usamos una DB relacional o una NO SQL? Para que entendamos, es una decision tecnica. En este caso la relacional seria el estandard (SQL, tablas y relaciones) y la NOSQL la podriamos interpretar entre muchas comillas como algo mas custom. Hacemos dump de documentos/binarios y cada usuario lo interpreta como quiere.

Ahora vamos a darle un nivel mas de profundidad a nuestro protocolo de serializacion.

con los a;os han ido surgiendo alternativas, y estas se justifican con benchmarks, hay escenarios donde van mejor. si tienes mensajes muy pesados un protocolo, si tienes mucho de peque;os otro... la serializacion vs deserializacion ira mas rapido o mas lento. etc etc todo esto son JUSTIFICACIONES TECNICAS, JSON vs MESSAGEPACK vs PROTOBUFF? Cual es mejor y porque?

Por ejemplo googleando bencharmmks:

https://medium.com/@hugovs/the-need-for-speed-experimenting-with-message-serialization-93d7562b16e4
http://tutorials.jenkov.com/rion/rion-performance-benchmarks.html

Entonces yo aqui, puedo decidir, vale usare un standard porque no queiro re inventar la rueda y quiero tener buena interoperabilidad, luego ademas, decidio que quiero usar json por X y por Y motivos. A alto nivel esto seria que database relacional voy a usar, psql o mysql?

Ahora.

Este mismo razonamiento.

Desde el punto de vista TECNICO.

Hacedlo con EVENT DRIVEN, CQRS y COLAS.

1 respuesta
MTX_Anubis

#27348

Te dicen 2004 primero y luego se van a divagar a ver quien lo trajo antes.

MVC es un patrón que nace a finales de los 80 si no recuerdo mal, antes de que cualquier lenguaje de esos de los que habla se hubiera inventando.

1 respuesta
B

.

1 respuesta
aren-pulid0
desu

Ese paper del minuto 30 lo postee yo en este mismo hilo. Esta gente nos lee desde hace tiempo y se que mucho de su contenido lo han robado. De nosotros y de otros blogs tipicos. De hecho tengo un par mas de videos fichados, a partir del a;o 2020 donde cosas que yo he posteado en este hilo, lo comentan en sus videos a los meses. Pero bueno a otro tema. Que esta gente roba material de bloggeros y lo repite como loros sin pensar es sabido. Lo unico que saben hacer. Son incapaces de pensar por ellos mismos y sacar argumentos y conclusiones usando sus pocas neuronas. las tienen ocupadas pensando en como sacarle el dinero a una empresa paco como pccomponentes o a un fpero de guadalarajara.

En todo ese video dejan claro que no saben lo que es un modulo. 1h hablando de como colocar las carpetitas y no entienden que en un lenguaje de verdad esto afecta a la compilacion incremental y el linking.

Es que no tienen ni puta idea de nada.

Cada vez que un masilla analfabeto sin estudios habla de arquitectura y su mayor preocupacion es como ordenar los ficheros y carpetitas solo se retrata ante el resto. Porque desde ese momento, cualquier persona como yo que os lee. Pensara que sois unos energumenos que no tinen ni puta idea de programacion. Pero ni puta idea.

Y si ademas te grabas en video y vendes cursos con estas bobadas... En fin.

Los vende humos tienen que pagar facturas tambien, dejad de postearles como fuentes o material de calidad cuando no lo son. Si quereis citar a alguien como material de calidad citadme a mi o a mi blog.

2
aren-pulid0

codely ens roba

2 1 respuesta
desu

#27357 El miudev es el mas cantoso de todo.

Coge el blog de alguien. lo ense;a en stream y lo comenta.

hay otro youtuber famosete que hace videos de "AI" (que no tiene ni putisima idea) que tambien hace eso, coge un articulo y te lo traduce XD no aporta nada XD

son incapaces de crear contenido, solo saben ladrar y ladrar y ni entienden lo que dicen.

es que si vas a citar algo o referenciar que sea para construir una nueva argumentacion o aportar algo de nuevo. como por ejemplo yo lo hago. el otro dia os di una clase en fp donde le di mi version a la literatura de type driven. no copie nada salvo la primera slide que es de un curso de FP de la cornell.. todo lo demas original por mi. tratando de aportar una nueva prespectiva a los blogs y videos que ense;an fp.

y puedo hacer esto porque al menos entiendo lo que leo. el anormal medio de este hilo ni entiende los blogs como para ponerse a pensar por el mismo y jugarsela con sus propias teorias. si a duras penas os sabeis limpiar el culo cuando vais a cagar. mejor seguid viendo videos de codely para aprender donde poner los archivos .java, en que carpetita toca. el tema de packages de java 9 mejor no lo comentamos que no importa, total, ni saben que existe ni que cojones es. imagino que no deben saber ni lo que es un compilador ni como funciona un compilador moderno.

por ejemplo, te podria grabar un video de 30 minutos, explicandote porque DDD es una mierda y esta mal. Contenido que no leeras en internet porque es mio. Mio, no leido ni adaptado ni nada. Mis conclusiones porque no soy un <140 IQ que a duras penas sabe abrir un IDE y darle a autogenerar codigo. La idea facil, conceptual vs data and use oriented. La he comentado muchas veces por aqui. El DDD que predican y ense;an se basa en "buenas practicas" de arquitectura y adaptar tu codigo a patrones de dise;o culturales que estais forzando. Esto es una mierda. El DDD solo sirve la parte de domain y context bound para relacionarlo con type driven design. Toda programacion y toda arquitectura debe ser data oriented / use case oriented. Una fuente, el link de twitter que he puesto antes o cualquier empresa que no sea de cuenco arroncistas. ni ddd ni event driven ni pollas. se resuelve el problema lo mejor que se puede y a otra cosa. los problemas de como nombrar las carpetitas os lo dejamos a vosotros masilleros.

1 respuesta
Lecherito

Pero si de normal los frameworks/librerias tienen un quickstart que es a;adir la dependencia y un hola mundo. A partir de ahi ya puedes ir buscando las cosas que necesitas e ir descubriendo. No entiendo los videos, se tarda el doble

1 respuesta
Fyn4r

#27359

se tarda el doble

O más de hecho, pero en ocasiones te encuentras con que en un vídeo (o una entrada de blog tb) resumen los "puntos clave" del tema, eso cunde bastante

1 respuesta

Usuarios habituales