Luis es un crack, realmente incide en la calidad del software y diseño en un pais en el que casi nunca se pone atencion sobre esto. Parte de unos fundamentos solidos y es critico con lo que llama la postmodernidad, algo en lo que me ha convencido. El enfoque de sus clases de patrones me parece muy acertado, alejandose del codigo y centrandose en lo que cada patron soluciona. Sin bling bling, todo coherencia. Luego todos querran ser jefes de proyecto al ver que con menor esfuerzo ganaran mas, y asi nos luce el pelo. Cuando por la parte tecnica para aspirar a sueldos importantes buscan hombres orquesta...
Es increible la claridad con la que explica Luis, felicitaciones y muchas gracias a Miguel Angel por convencer a un gran profesor para compartir toda su experiencia y su claridad mental.
Buenas tardes, saludos, luis tiene razon en cuanto a lo que dice de la arquitectura hexagonal, vayan a a leer el articulo de tal alistair, ni el mismo se entiende. Me viene con el cuento de cambiar e inventar nombre raros, que si actores secundarios, adaptadores, que si izquierdo, derecho, etc. Pero como se puede tomar en serio un articulo que dice cosa como esta: "Qué es y qué no es exactamente un puerto es en gran medida una cuestión de gusto. En un extremo, cada caso de uso podría recibir su propio puerto, produciendo cientos de puertos para muchas aplicaciones. Alternativamente, uno podría imaginar fusionar todos los puertos primarios y todos los puertos secundarios para que solo haya dos puertos, un lado izquierdo y un lado derecho" Es cuestion de gusto, y el diseno ? y los principios pa cuando ?. "No parece que haya ningún daño particular al elegir el número "incorrecto" de puertos, por lo que sigue siendo una cuestión de intuición. Mi selección tiende a favorecer un pequeño número, dos, tres o cuatro puertos, como se describe anteriormente y en los Usos conocidos." Pero por favor doctor es en serio ? "El Principio de Inversión de Dependencia de Bob Martin (también llamado Inyección de Dependencia por Martin Fowler) establece que “los módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deberían depender de abstracciones. Las abstracciones no deben depender de los detalles. Los detalles deberían depender de las abstracciones”. El patrón ''Inyección de dependencia'' de Martin Fowler ofrece algunas implementaciones. Estos muestran cómo crear adaptadores de actor secundario intercambiables. El código se puede escribir directamente, como se hizo en el código de muestra del artículo, o usar archivos de configuración y hacer que el marco SPRING genere el código equivalente". Esto ya se sabia acomplamiento. "On the Criteria To Be Used in Decomposing Systems into Modules" de Wayne Stevens y Peter Pinson, publicado en 1974. Otra cosa el principio de inversion de dependecia de bob martin ? también llamado Inyección de Dependencia por Martin Fowler ? Ni fowler ni bob martin. y tampoco inversion ni inyeccion. El principio abierto cerrado y quien lo propuso fue Bertrand Meyer aconsejo leer su libro "Object-Oriented Software Construction" del 88, y principio de Sustitución de la doctora Liskov "Program Development in Java. y todo esto soportado por lo que publicaron Larry Constantine y Ed Yourdon en su libro rojo "Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design" que habla de la cohesion esto fue en 1979, o sea que Mr. Cockburn lo tuvo que haber leido ya tenia 32 anos para ese entoces. pero luego al final del articulo, viene y me dice que no es hexagonal, que no tiene ni forma, ademas tiene muchos lados, que no me joda, pero si ese senor era muy serio, habia escrito un libro de Writing Effective Use Cases, buen libro, un libro que seguro se baso en lo que ya habia hablado ivar jacobson. Ahora bien, lo lamentable de todo esto es que la juventud que esta comenzando en el mundo del software se encuentra con estos lios, que se han montado todos estos inrresponsable solo por querer vender libros. La aquitecrura del software, no es ma que alta cohesion, minimo acoplamiento,es separar por capa, partir, dividir, modularidad que ya lo habia hablado DeMarco y Melo, y con estilo arquitectonico MVC*, aplicado por Trygve Reenskaug, para poder organizar sus proyectos, Lo te quiero decir, es que esta historia, ya se habia contado, desde mucho antes, asi que solo por cambiar los nombres a la parte de un carro, no me puedes venir a decir, que tu te lo inventaste o esta aportando algo, repito este cuento ya se sabia, puedes leer el articulo publicado por Jack Reeves en el 2003, en la revista C++. Quisiera saber que opinion tenia Michael Swaine de ese articulo. Para uno enterarse, tenemos que leer libros pero libros bueno, dejar escuchar tanto a los loros youtuber, y los cuentos a media de blogeros e influencer. Presten atencion a senor luis si realmente se quieren enterar del cuento real y puedan comprender todo este mundo tan complejo como es el software
Hola que tal ? Quisiera saber si hay algun libro para recomendar a cerca del diagnostico de necesidades de informacion en organizaciones. Muchas gracias ! Si algun lector de este comentario sabe de algun libro.
36:00 Me gustaría tener una charla con Luis porque el término Adaptor en Arquitectura Hexagonal no tiene nada que ver con vistas. Precisamente, el término Adaptor en Arquitectura Hexagonal es exactamente lo que el explica con el tema de los enchufes.
Buenas tardes, andrian saludos, vete a leer el articulo de tal alistair, ni el mismo se entiende. Me viene con el cuento de cambiar e inventar nombre raros, que si actores secundarios, adaptadores, que si izquierdo, derecho, etc. Pero como se puede tomar en serio un articulo que dice cosa como esta: "Qué es y qué no es exactamente un puerto es en gran medida una cuestión de gusto. En un extremo, cada caso de uso podría recibir su propio puerto, produciendo cientos de puertos para muchas aplicaciones. Alternativamente, uno podría imaginar fusionar todos los puertos primarios y todos los puertos secundarios para que solo haya dos puertos, un lado izquierdo y un lado derecho" Es cuestion de gusto, y el diseno ? y los principios pa cuando ?. "No parece que haya ningún daño particular al elegir el número "incorrecto" de puertos, por lo que sigue siendo una cuestión de intuición. Mi selección tiende a favorecer un pequeño número, dos, tres o cuatro puertos, como se describe anteriormente y en los Usos conocidos." Pero por favor doctor es en serio ? "El Principio de Inversión de Dependencia de Bob Martin (también llamado Inyección de Dependencia por Martin Fowler) establece que “los módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deberían depender de abstracciones. Las abstracciones no deben depender de los detalles. Los detalles deberían depender de las abstracciones”. El patrón ''Inyección de dependencia'' de Martin Fowler ofrece algunas implementaciones. Estos muestran cómo crear adaptadores de actor secundario intercambiables. El código se puede escribir directamente, como se hizo en el código de muestra del artículo, o usar archivos de configuración y hacer que el marco SPRING genere el código equivalente". Esto ya se sabia acomplamiento. "On the Criteria To Be Used in Decomposing Systems into Modules" de Wayne Stevens y Peter Pinson, publicado en 1974. Otra cosa el principio de inversion de dependecia de bob martin ? también llamado Inyección de Dependencia por Martin Fowler ? Ni fowler ni bob martin. y tampoco inversion ni inyeccion. El principio abierto cerrado y quien lo propuso fue Bertrand Meyer aconsejo leer su libro "Object-Oriented Software Construction" del 88, y principio de Sustitución de la doctora Liskov "Program Development in Java. y todo esto soportado por lo que publicaron Larry Constantine y Ed Yourdon en su libro rojo "Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design" que habla de la cohesion esto fue en 1979, o sea que Mr. Cockburn lo tuvo que haber leido ya tenia 32 anos para ese entoces. pero luego al final del articulo, viene y me dice que no es hexagonal, que no tiene ni forma, ademas tiene muchos lados, que no me joda, pero si ese senor era muy serio, habia escrito un libro de Writing Effective Use Cases, buen libro, un libro que seguro se baso en lo que ya habia hablado ivar jacobson. Ahora bien, lo lamentable de todo esto es que la juventud que esta comenzando en el mundo del software se encuentra con estos lios, que se han montado todos estos inrresponsable solo por querer vender libros. La aquitecrura del software, no es ma que alta cohesion, minimo acoplamiento,es separar por capa, partir, dividir, modularidad que ya lo habia hablado DeMarco y Melo, y con estilo arquitectonico MVC*, aplicado por Trygve Reenskaug, para poder organizar sus proyectos, Lo te quiero decir, es que esta historia, ya se habia contado, desde mucho antes, asi que solo por cambiar los nombres a la parte de un carro, no me puedes venir a decir, que tu te lo inventaste o esta aportando algo, repito este cuento ya se sabia, puedes leer el articulo publicado por Jack Reeves en el 2003, en la revista C++. Quisiera saber que opinion tenia Michael Swaine de ese articulo. \ Para uno enterarse, tenemos que leer libros pero libros bueno, dejar escuchar tanto a los loros youtuber, y los cuentos a media de blogeros e influencer.
Luis es un crack, realmente incide en la calidad del software y diseño en un pais en el que casi nunca se pone atencion sobre esto. Parte de unos fundamentos solidos y es critico con lo que llama la postmodernidad, algo en lo que me ha convencido. El enfoque de sus clases de patrones me parece muy acertado, alejandose del codigo y centrandose en lo que cada patron soluciona. Sin bling bling, todo coherencia. Luego todos querran ser jefes de proyecto al ver que con menor esfuerzo ganaran mas, y asi nos luce el pelo. Cuando por la parte tecnica para aspirar a sueldos importantes buscan hombres orquesta...
Sí, Luis nos ha hecho cambiar la forma de pensar a muchos y con ello hemos escalado en calidad y profesionalidad.
Es increible la claridad con la que explica Luis, felicitaciones y muchas gracias a Miguel Angel por convencer a un gran profesor para compartir toda su experiencia y su claridad mental.
Sí, tenemos una suerte inmensa de poder contar con Luis!!
Esas explicaciones de los patrones con esos ejemplos son oro puro, gracias!
Gracias!
Estuvo muy bien explicado, bastante conciso, muchas gracias por el aporte
Muchas gracias por su tiempo!! Saludos desde Buenos Aires, Argentina..🙇♂️🙋🏻♂️
Es un capo don Luis !!
Buenas tardes, saludos, luis tiene razon en cuanto a lo que dice de la arquitectura hexagonal, vayan a a leer el articulo de tal alistair, ni el mismo se entiende. Me viene con el cuento de cambiar e inventar nombre raros, que si actores secundarios, adaptadores, que si izquierdo, derecho, etc. Pero como se puede tomar en serio un articulo que dice cosa como esta:
"Qué es y qué no es exactamente un puerto es en gran medida una cuestión de gusto. En un extremo, cada caso de uso podría recibir su propio puerto, produciendo cientos de puertos para muchas aplicaciones. Alternativamente, uno podría imaginar fusionar todos los puertos primarios y todos los puertos secundarios para que solo haya dos puertos, un lado izquierdo y un lado derecho"
Es cuestion de gusto, y el diseno ? y los principios pa cuando ?.
"No parece que haya ningún daño particular al elegir el número "incorrecto" de puertos, por lo que sigue siendo una cuestión de intuición. Mi selección tiende a favorecer un pequeño número, dos, tres o cuatro puertos, como se describe anteriormente y en los Usos conocidos."
Pero por favor doctor es en serio ?
"El Principio de Inversión de Dependencia de Bob Martin (también llamado Inyección de Dependencia por Martin Fowler) establece que “los módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deberían depender de abstracciones. Las abstracciones no deben depender de los detalles. Los detalles deberían depender de las abstracciones”. El patrón ''Inyección de dependencia'' de Martin Fowler ofrece algunas implementaciones. Estos muestran cómo crear adaptadores de actor secundario intercambiables. El código se puede escribir directamente, como se hizo en el código de muestra del artículo, o usar archivos de configuración y hacer que el marco SPRING genere el código equivalente".
Esto ya se sabia acomplamiento. "On the Criteria To Be Used in Decomposing Systems into Modules" de Wayne Stevens y Peter Pinson, publicado en 1974.
Otra cosa el principio de inversion de dependecia de bob martin ? también llamado Inyección de Dependencia por Martin Fowler ?
Ni fowler ni bob martin. y tampoco inversion ni inyeccion. El principio abierto cerrado y quien lo propuso fue Bertrand Meyer aconsejo leer su libro "Object-Oriented Software Construction" del 88, y principio de Sustitución de la doctora Liskov "Program Development in Java. y todo esto soportado por lo que publicaron Larry Constantine y Ed Yourdon en su libro rojo "Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design" que habla de la cohesion esto fue en 1979, o sea que Mr. Cockburn lo tuvo que haber leido ya tenia 32 anos para ese entoces.
pero luego al final del articulo, viene y me dice que no es hexagonal, que no tiene ni forma, ademas tiene muchos lados, que no me joda, pero si ese senor era muy serio, habia escrito un libro de Writing Effective Use Cases, buen libro, un libro que seguro se baso en lo que ya habia hablado ivar jacobson.
Ahora bien, lo lamentable de todo esto es que la juventud que esta comenzando en el mundo del software se encuentra con estos lios, que se han montado todos estos inrresponsable solo por querer vender libros. La aquitecrura del software, no es ma que alta cohesion, minimo acoplamiento,es separar por capa, partir, dividir, modularidad que ya lo habia hablado DeMarco y Melo, y con estilo arquitectonico MVC*, aplicado por Trygve Reenskaug, para poder organizar sus proyectos, Lo te quiero decir, es que esta historia, ya se habia contado, desde mucho antes, asi que solo por cambiar los nombres a la parte de un carro, no me puedes venir a decir, que tu te lo inventaste o esta aportando algo, repito este cuento ya se sabia, puedes leer el articulo publicado por Jack Reeves en el 2003, en la revista C++. Quisiera saber que opinion tenia Michael Swaine de ese articulo.
Para uno enterarse, tenemos que leer libros pero libros bueno, dejar escuchar tanto a los loros youtuber, y los cuentos a media de blogeros e influencer. Presten atencion a senor luis si realmente se quieren enterar del cuento real y puedan comprender todo este mundo tan complejo como es el software
Buen comentario!!
Gracias Luis y Desarrollo web vamos mejorando el diseño. vamos bien
Gracias!!
Muy util la manera de enfocar la explicacion. Muchas gracias, Luis.
Gracias Laura!
Buen video luis, estoy muy de acuerdo excelente!!!
Buenisimo
Buenas, me podrian decir que libro es ese? Muy buena explicacion, gracias.
Maestro Luis Fernández
¿dónde podemos descargar ese html?
Buenas, estará disponible para la descarga el documento utilizado durante la clase? muchas gracias.
Sí, lo tienes como material en el máster de escuelait escuela.it/masters/master-programacion-diseno-software
@@deswebcom ¿Pero si el master ha finalizado qué opciones se tienen?
El siguiente mes entro al Master si o si.
Miguel Angel, planean algún máster de IA con Luis?... Creo que sería tremendo.
Hola! pues de momento no tenemos planes.
Cuando el dice "Esto lo hablamos en principios de diseño" ¿Está habando del curso de principios SOLID o de otro curso?
Perdón, en tiempo donde dice eso es 2:10:52
Hola que tal ? Quisiera saber si hay algun libro para recomendar a cerca del diagnostico de necesidades de informacion en organizaciones. Muchas gracias ! Si algun lector de este comentario sabe de algun libro.
A mi no se me ocurre...
ese wey fuma más que chino en quiebra 😂😂😂
jajaja
Calidad
👍
36:00 Me gustaría tener una charla con Luis porque el término Adaptor en Arquitectura Hexagonal no tiene nada que ver con vistas. Precisamente, el término Adaptor en Arquitectura Hexagonal es exactamente lo que el explica con el tema de los enchufes.
Buenas tardes, andrian saludos, vete a leer el articulo de tal alistair, ni el mismo se entiende. Me viene con el cuento de cambiar e inventar nombre raros, que si actores secundarios, adaptadores, que si izquierdo, derecho, etc. Pero como se puede tomar en serio un articulo que dice cosa como esta:
"Qué es y qué no es exactamente un puerto es en gran medida una cuestión de gusto. En un extremo, cada caso de uso podría recibir su propio puerto, produciendo cientos de puertos para muchas aplicaciones. Alternativamente, uno podría imaginar fusionar todos los puertos primarios y todos los puertos secundarios para que solo haya dos puertos, un lado izquierdo y un lado derecho"
Es cuestion de gusto, y el diseno ? y los principios pa cuando ?.
"No parece que haya ningún daño particular al elegir el número "incorrecto" de puertos, por lo que sigue siendo una cuestión de intuición. Mi selección tiende a favorecer un pequeño número, dos, tres o cuatro puertos, como se describe anteriormente y en los Usos conocidos."
Pero por favor doctor es en serio ?
"El Principio de Inversión de Dependencia de Bob Martin (también llamado Inyección de Dependencia por Martin Fowler) establece que “los módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deberían depender de abstracciones. Las abstracciones no deben depender de los detalles. Los detalles deberían depender de las abstracciones”. El patrón ''Inyección de dependencia'' de Martin Fowler ofrece algunas implementaciones. Estos muestran cómo crear adaptadores de actor secundario intercambiables. El código se puede escribir directamente, como se hizo en el código de muestra del artículo, o usar archivos de configuración y hacer que el marco SPRING genere el código equivalente".
Esto ya se sabia acomplamiento. "On the Criteria To Be Used in Decomposing Systems into Modules" de Wayne Stevens y Peter Pinson, publicado en 1974.
Otra cosa el principio de inversion de dependecia de bob martin ? también llamado Inyección de Dependencia por Martin Fowler ?
Ni fowler ni bob martin. y tampoco inversion ni inyeccion. El principio abierto cerrado y quien lo propuso fue Bertrand Meyer aconsejo leer su libro "Object-Oriented Software Construction" del 88, y principio de Sustitución de la doctora Liskov "Program Development in Java. y todo esto soportado por lo que publicaron Larry Constantine y Ed Yourdon en su libro rojo "Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design" que habla de la cohesion esto fue en 1979, o sea que Mr. Cockburn lo tuvo que haber leido ya tenia 32 anos para ese entoces.
pero luego al final del articulo, viene y me dice que no es hexagonal, que no tiene ni forma, ademas tiene muchos lados, que no me joda, pero si ese senor era muy serio, habia escrito un libro de Writing Effective Use Cases, buen libro, un libro que seguro se baso en lo que ya habia hablado ivar jacobson.
Ahora bien, lo lamentable de todo esto es que la juventud que esta comenzando en el mundo del software se encuentra con estos lios, que se han montado todos estos inrresponsable solo por querer vender libros. La aquitecrura del software, no es ma que alta cohesion, minimo acoplamiento,es separar por capa, partir, dividir, modularidad que ya lo habia hablado DeMarco y Melo, y con estilo arquitectonico MVC*, aplicado por Trygve Reenskaug, para poder organizar sus proyectos, Lo te quiero decir, es que esta historia, ya se habia contado, desde mucho antes, asi que solo por cambiar los nombres a la parte de un carro, no me puedes venir a decir, que tu te lo inventaste o esta aportando algo, repito este cuento ya se sabia, puedes leer el articulo publicado por Jack Reeves en el 2003, en la revista C++. Quisiera saber que opinion tenia Michael Swaine de ese articulo. \
Para uno enterarse, tenemos que leer libros pero libros bueno, dejar escuchar tanto a los loros youtuber, y los cuentos a media de blogeros e influencer.
Hay un vídeo entero de Luis al respecto th-cam.com/video/glQlG-MeX4w/w-d-xo.html