Devs Lives #1 Daniel Ramos Acosta | Hablemos de arquitectura

Transcripción

• Audio: https://www.ivoox.com/devs-lives-1-daniel-ramos-acosta-hablemos_mf_86086007_feed_1.mp3
• Fuente: retranscripcion automática desde audio con mlx-community/whisper-large-v3-turbo
• Nota: esta versión mejora el ASR respecto a los subtítulos de YouTube, pero todavía no incluye diarización real de hablantes.

[No identificado] (00:00:21): Bienvenidos a Devs Lives, episodio número 1. Bienvenidos al canal. Mi nombre es Adrián Ferrera González, desarrollador en Lean Mind y bueno, la idea es traeros este podcast donde vamos a charlar con diferentes personas del sector. Vamos a hablar con ellos, que nos cuenten un poquito sobre su vida, sus experiencias, conocerlos un poquito más y sobre todo que nos ayuden a crecer profesionalmente. Conocer sus distintos puntos de vista, qué valoran, qué no valoran, pero sobre todo vamos a intentar pasar un buen ratito. Vamos a empezar a entrar en terreno pantanoso, a hacer ciertas preguntas

[No identificado] (00:00:58): Y que la gente se moje. Y dado el aire desenfadado que le queremos dar, cómo no, cómo no iba a contar yo con uno de mis grandes amigos, una de las personas que más aprecio y una de las personas con las que me aventuré en mi primera aventura de crear un canal de YouTube, Daniel Ramos Acosta. Bienvenido al episodio número 1. Chaval, qué tal, cómo estás? Bienvenido. ¿Qué tal, Adri? Pues yo bien, bien aquí, medio dormido todavía porque es por la mañana, pero bueno, contento, contento de estar aquí, de estar aquí contigo.

[No identificado] (00:01:32): Bueno, va a salir guay además que tú sabes que a mí me gusta hablar y contar cosas. Así que bien, bien, bien. Te he traído engañado, eh, las cosas como son. Yo te dije, no, venga, vamos a hacer un podcast, no sé qué, ta, ta, ta, nada, nada. Al final nos calentamos rápido los dos. Sí, sí, sí. Bueno, pues venga, vamos a empezar un poquito. Yo te conozco, somos como uña y carne, somos bastante buenos amigos, diría yo, pero probablemente igual que la gente no me conoce a mí, pues tampoco te conozca mucho a ti, así que cuéntame, ¿quién es Daniel Ramos Acosta?

[No identificado] (00:02:12): Pues Adri, yo, pues eso, soy Daniel Ramos Acosta, empezando por ahí, ¿no? Y nada, yo, pues soy desarrollador en general, diría yo, tanto, es que full stack es una palabra que no me gusta, ¿no? Pero bueno, sí, al final estoy más enfocado al back ahora mismo, ¿no? Aunque bueno, también he controlado la parte de front, incluso parte de sistemas, de Kubernetes, Docker y todo eso también un poquito, ¿no?

[No identificado] (00:02:38): Y nada, bien, respecto a todo el tema de desarrollo, la parte que más me gusta es todo este movimiento de software craftsmanship que hay, ¿no? Todo el tema de dejar el código lo mejor posible, que sea súper legible, todo este tema, ¿no? Me apasiona mucho todo eso. Y nada, bien, un poco eso.

[No identificado] (00:02:57): Curioso, curioso, me resulta muy curioso porque hace tres años más o menos cuando trabajábamos juntos, estaba súper enfocado en el front, ¿no? O sea, venías de trabajar en el front, en a tope, y me alegra un montón ese cambio, esa evolución, ¿no? Pasaste de tocar React y desde mi punto de vista yo te he admirado siempre mucho con respecto a eso. Fuiste la persona que me enseñó React, de hecho, me hiciste cambiar de Angular, cosa que al principio te odié y después te amé lo más grande.

[No identificado] (00:03:34): Después hablaremos un poquito de esas anécdotas y cómo pasó, pero me sorprende mucho, me sorprende mucho. ¿Qué crees que te ha incitado a tener ese cambio de desenfocarte un poquito del front y empezar a tocar de todo, de cantarte por el tema del craftsmanship? ¿Cómo lo ves? ¿Qué ha pasado ahí? ¿Qué ha surgido?

[No identificado] (00:03:55): Pues principalmente, o sea, eso es lo que tú dices, ¿no? Tanto en la primera empresa donde estuve yo como cuando ya entré ahí en Lima y con ustedes, empecé por la parte de front, ¿no? Pero cuando ya, sobre todo con Carlos, pues viendo todo este tema de, bueno, sobre todo el tema de Domain Driven Design, arquitectura hexagonal y todo esto, al final, a pesar de que se puede extrapolar al front, donde ves o donde puedes empezar a meter la patita, es principalmente enfocado a BAC, ¿no? Entonces, bueno, me empecé a meter por ahí, ¿no?

[No identificado] (00:04:28): Sobre todo cuando estuve con Sosa en la parte del proyecto que estuvimos ahí, pues ahí estábamos viendo los cursos de Codely, empezando a aplicar ciertas cosas ahí de arquitectura y tal, y bueno, ya cuando entré en ACID fue un poco empujar esto todavía más, ¿no? Bueno, los cursos de Codely para mí fue una fuente de conocimiento muy buena y, bueno, me los he visto todos, creo, y sobre todo los de arquitectura. Y, bueno, ya recientemente, pues leyendo unos libros de, bueno, los de, sobre todo los de

[No identificado] (00:05:01): Implementing Domain Driven Design, ¿no? Que no son los de Eric Kevin, que son muy duros, sino los que son así como un poco más resumidos o más a lo práctico y tal, ¿no? Guay, guay, guay. Y al final toda esa parte, a pesar de eso, lo que te digo, ¿no? Que lo puedes aplicar al front y lo aplicamos al front, donde tiene como más, donde hay más arte de todo esto, al final es todo en la parte de BAC, ¿no? Entonces, bueno, pues me he ido metiendo por ahí muy profundo y al final casi que estoy,

[No identificado] (00:05:27): Vamos, diría yo con 80% enfocado así a la parte de BAC, ¿no? Sí, sí, sí, sí, estoy totalmente de acuerdo. Y ahora que lo has nombrado el tema de front, que lo puedes aplicar también, y estoy totalmente de acuerdo, aquí se empieza a dar ya un debate que vamos a empezar calentito, estamos empezando fuerte, yo pensaba ir como más sosegado, bueno, pero no, no, estamos yendo al medio del asunto enseguida.

[No identificado] (00:05:51): Sí que en frontend puedes aplicar temas de arquitectura y puedes jugar bastante con ello, pero siempre dentro de unos rangos, ¿no? Y cuando, por lo menos en mi experiencia, cuando llegas a un proyecto, te ves los dos extremos, o no hay nada, o estás sobredimensionado que tú dices, ¡ay Dios mío, dónde me estoy metiendo, no, por Dios!

[No identificado] (00:06:14): Perdón. Entonces, ¿cuál es un poquito tu opinión al respecto, no? ¿Dónde están esas líneas en el front? ¿Qué crees que son cosas, que son paradigmas que existen en el backend, pero que no debes aplicar en el frontend?

[No identificado] (00:06:30): Uf, que no debes aplicar, no sé, porque depende mucho de qué frontend, ¿sabes? Porque no es lo mismo una aplicación de React Native que una de React web, no es lo mismo una aplicación móvil que también una web, ¿no? Al final en la web también tienes que compensar otras cosas, ¿no? Por ejemplo, el tamaño del bundle y todo esto, ¿no? Que cambia un poco, o tienes que adaptar el estilo de código, ¿no? Para que funcione bien en web, ¿no? Por ejemplo, al final JavaScript tiene todo el tema de las clases, ¿no?

[No identificado] (00:06:56): Y que puedes hacer clases y está bien, porque eso aplica con, o es más fácil de hacer o de ver con el tema de inyecciones y dependencias, porque se lo pasas por el constructor y todo el rollo, ¿no? Pero tiene un downside, sobre todo cuando lo usas en frontend, en web, ¿no?

[No identificado] (00:07:12): Que es que minifica muy mal el tema de las clases, ¿no? Entonces, hay alternativas para eso que puedes usar como funciones dentro de funciones, que básicamente es como una especie de inyección a funciones directamente, ¿no? O puedes hacer un rollo como lo que hace Rast, ¿no? Que Rast, por ejemplo, no tiene clase, pero tiene como un struct y funciones asociadas a ese struct, ¿no? Pues puedes hacer un poco lo mismo con JavaScript, ¿no? O, bueno, con TypeScript, ¿no? En el front tienes un type y tienes funciones sueltas que están asociadas a… A ese modelo en concreto, ¿no? Sí. ¿Sabes?

[No identificado] (00:07:42): No puedes hacer programación de entradas objetos al uso con JavaScript. Bueno, este es en el caso de JavaScript, ¿no? Tal cual en el front, porque eso minifica un poco mal. Bueno, hay una serie de cosas que tiene. Que bueno. Pero sí, yo creo que lo puedes aplicar casi todo. Casi todo. Sobre todo el tema de… De la arquitectura… Sabonal. De la arquitectura sabonal, ¿no? O de puertos y adaptadores. El tema de tener las dependencias aisladas, ¿no? Con una interfaz delante o lo que sea, ¿no? Yo creo que esa parte aplica mucho al front a la comunicación con APIs, a, por ejemplo, consultar APIs del navegador,

[No identificado] (00:08:16): O consultar APIs de terceros, ¿no? Sí, efectivamente. Sobre todo cuando empiezas a aplicar temas de server-side rendering, por ejemplo, que es el caso más al uso, donde tu código tiene que ser idosomórfico y tiene que ejecutarse tanto en browser como en backend, ahí tienes que desacoplarte muy bien y tienes que saber qué dependencias tienes en cada caso, porque no es lo mismo tirar del fetch nativo que tirar de un fetch que está en backend, ¿no? Ya sabemos que hay librerías que te hacen esa envoltura, que te lo solucionan, pero al final siempre son librerías de terceros, que no es algo…

[No identificado] (00:08:50): Que tengas tú el control total sobre ello. Entonces, muy buen punto y es justo uno de los argumentos que llevo defendiendo un par de semanas, ¿no? Yo he pasado por todo, ¿vale? He pasado por el tema de vamos a hacerlo todo puramente funcional en Fronet, vamos a hacerlo con clases porque así podemos mantener la estructura de objetos, encapsularlo bien y tal, a decir, oye, mira, creo que esto depende del caso donde lo vayamos a usar, igual si lo que estamos haciendo es trabajar un backend con TypeScript, pues las clases tienen sentido, porque al final el tamaño de tu bundle no te es relevante,

[No identificado] (00:09:28): Eso va a estar en el servidor y sabemos que las máquinas hoy en día sus problemas no son de memoria, pero sin embargo cuando estamos hablando de minificados, de enviarlos a la UI, de que se tiene que ver en el navegador ahí, el tamaño del bundle es súper importante, como bien dices, igual tirar por un approach más basado en funciones, que igualmente haces tus envolturas, los devuelves, los trabajas, pero… Sí, una cosa no quita la otra al final.

[No identificado] (00:09:52): Efectivamente, efectivamente. Entonces estoy muy de acuerdo contigo, estoy muy de acuerdo contigo y creo que al final no es la piedra roseta, ¿vale? No es una verdad absoluta donde tú digas, no, no tiene que ser así a rajatabla, porque es una de las cosas que últimamente estoy defendiendo mucho, la arquitectura adaptativa o evolucionaria arquitectura, o como lo queramos llamar. Yo lo he llamado así, arquitectura adaptativa, me gusta mucho.

[No identificado] (00:10:18): Entonces,

[No identificado] (00:10:20): Totalmente de acuerdo, totalmente de acuerdo. Sí, es que hay veces que incluso la parte de arquitectura pues no te encaja, pues por lo que sea, por tiempos o porque crees que aquí complica demasiado. Pues que, por ejemplo, yo qué sé, el tema de Excel dependencias está bien, ¿no? Pero hay veces que te acoplas un poco a la librería y tampoco pasa nada si no eres purista del todo. Por ejemplo, si quieres usar una función tipo loadash, imagina que tienes que usar loadash para algo, ¿no? El groupby, ponle tú, ¿no?

[No identificado] (00:10:48): Vale, no hace falta que inyectes loadash con la librería, o bueno, no loadash, sino que inyectes el groupby o lo que sea para no estar acoplado a que el groupby es de loadash o de otro caso, sino con que le tengas un wrapper cochino ahí en una función, utils o lo que sea, ¿no? Claro. Y así no tienes el import de loadash por todo el código sino tienes uno en un sitio, pues con eso te vale, ¿sabes? Claro, eso te facilita. Entonces, para mí la inyección de dependencias y todo este tema de arquitectura, explica cuando tienes sobre todo problemas al testear, ¿no? De que tienes

[No identificado] (00:11:18): Alguna librería así un poco rara que tienes que usar o alguna dependencia con la API, eso es la API es lo más típico, ¿no? Que tienes que inyectarlo para poder testearlo bien, ¿no? Claro. Totalmente de acuerdo. De hecho, al final te queda muy natural, o sea, todo el testing se ha basado siempre en inyección de dependencias y es uno de los principios de desarrollo, básicamente, es aislarte a las librerías de tercero. Entonces, crearte un wrapper que a ti te resulta muy cómodo hacer un mock, bueno, pues ya está, le tienes la envoltura, haces la envoltura de, perdón, haces el mock de tu envoltura

[No identificado] (00:11:53): Y todo solucionado, no tienes que estar reinventando las ruedas, algo que se lleva usando un montón de años y que funciona. Solucionado. O sea, además, la probabilidad de que cambie la API de Groupby y de Lodash, dime tú. No. Eso no pasa. Pero, te puede pasar, por ejemplo, que ahora pasa de Groupby nativo. Sí. Entonces, bueno, claro, entonces, pasa una cosa, ¿no? Y es que si lo tienes por ahí regado el import de Lodash, o sea, hasta algo que tú dices, coño, es que esto no iba a cambiar, era imposible que cambiase. Pues mira, cambia. Ahora tienes un Groupby nativo. Efectivamente. Y bueno,

[No identificado] (00:12:24): Te va a ayudar !

[No identificado] (00:12:31): Efectivamente. O incluso, lo cambias en tu Grapper. Lo cambias en tu envoltura y tu aplicación es totalmente transparente. Tu aplicación no sabe que nada ha cambiado. Pero, realmente, si lo ha hecho, incluso de cara a las migraciones, todos sabemos que muchas veces cuando actualizas versiones se rompe API y tener que manejar ese cambio de API en toda tu aplicación es un problema. A ver, si puedes evitarlo porque lo tienes en tu envoltura y lo puedes simplemente solucionar a nivel de tu envoltura de lujo. Que no, bueno, pues igual también tienes que cambiar un poquito la firma de tu método de tu envoltura para poder usarlo.

[No identificado] (00:13:11): Pero, a ver, son casos que tú dices dentro de lo peor que podría pasar hemos minificado el impacto bastante. Sí, sí, sí. Y el esfuerzo que te lleva es bastante poco. Quiero decir, ¿cuánto tiempo se puede invertir en crear una envoltura? Nada, eso es… Realmente no es nada. O sea, creas el archivo, le pones la función, devuelves lo que tal y ya está. Exacto, es bastante corto. Me gusta, me gusta, me gusta. Y,

[No identificado] (00:13:39): Bueno, me gusta. Y bueno, también lo que tú comentabas de cara al server-side rendering, por ejemplo, nosotros estamos haciendo la inyección de dependencias en React con el hook del contexto, ¿sabes? La dependencia que tú quieres, o sea, el objeto de contexto de React, bueno, que esto es para que sepa React, el objeto de contexto de React, lo que te devuelve, ¿no? Cuando haces un use context, lo que te devuelve es la interfaz de lo que estás inyectando, no la implementación, ¿no? Entonces, lo guay que tiene eso es que cuando, a nivel de server-side rendering, pues tú puedes hacer el switch

[No identificado] (00:14:10): De que si estoy en cliente, inyecto esto o inyecto esto otro, ¿no? Y al final, como va por el hook de contexto, tú ni te das cuenta, sabes que tienes algo que cumple con esa interfaz, ¿no? Pero no te das cuenta si es un cliente, o sea, una implementación específica para server-side rendering por lo que sea, o es una implementación del cliente que usa un token que está en el local storage o lo que sea, Sí, y además es muy limpio, o sea, a nivel de código no es nada engorroso, o sea, es simplemente eso, una factoría, es una factoría, realmente, no tiene más.

[No identificado] (00:14:41): Es un poquito más engorroso porque tienes que hacer el tema del contexto, el hook y todo el rollo, pero las ventajas que tienes para mí compensan, ¿no? Que es que te queda mucho más limpio el código para poder hacer ese tipo de switches y sobre todo para testear, porque para testear le pasas un cliente fake a ese hook de contexto, ¿no? Que implemente la misma interfaz o implemente determinados métodos que a ti te interesa para testear y listo, con Dios. Totalmente de acuerdo. Me encanta porque todavía me acuerdo de aquellos días en Link Codders cuando empezamos a ver la migración a los hooks

[No identificado] (00:15:15): Que empezamos a decir bocada y a probarlo en directo

[No identificado] (00:15:19): Y me hace gracia que después de casi dos, tres años sin haber hablado, porque es verdad que este tema del contexto no lo habíamos hablado, hemos llegado a la misma solución, o sea, estamos aplicando el mismo patrón para solucionar el problema, así que me encanta, me encanta que ya hemos llegado a eso. Qué bueno, tío. Además, ¿sabes lo guay? Todo esto de inyectar por contexto

[No identificado] (00:15:44): Se puede usar también en los otros frameworks, ¿sabes? Por ejemplo, yo, de hecho, creo que lo último que estuve trabajando fue Vue, ni siquiera fue React con Vue 3 y tiene lo mismo, tío, tiene lo mismo, podéis inyectar cosas por contexto, la pena que me queda de Vue es que no está tan bien tipado como con React, es un poco más complicado, pero bueno, lo puedes hacer, puedes inyectar cosas y es igual de sencillo, al final,

[No identificado] (00:16:07): No sé si tenía hooks para poder inyectar cosas en Vue o era con un parámetro del componente, no recuerdo, pero al final era el mismo efecto, ¿sabes? Desde arriba de toda la aplicación tú le dices, oye, quiero que esta dependencia sea esta instancia de esta clase o este valor concreto, ¿no? Claro. Pero de cara a tú del componente para adentro sabes que es esta interfaz, pero no sabes cómo está implementada por debajo. Claro, y lo bueno de eso es que volvemos a patrones de arquitectura hexagonal, es decir, tú tienes tu parte de infraestructura que al final acaba siendo tu librería de, o sea,

[No identificado] (00:16:37): Tu herramienta de componentes es React, es Vue, es Angular, es whatever, introduja aquí el nuevo framework JavaScript super moderno y molón, pero de ahí hacia adentro es tu dominio y el cómo lo quieras gestionar y está totalmente desacoplado, ¿no? O sea, hay un articulito por ahí que escribí en su momento justamente donde se hace esa comparatoria, ¿no? Cogíamos el mismo código fuente, la misma capa de dominio con su servicio, su llamada API,

[No identificado] (00:17:06): Y el código era exactamente igual, lo copiabas, lo pegabas y lo único que cambiaba era esa capa de adaptador del contexto para React o para Vue y realmente era exactamente la misma aplicación, con el mismo código fuente de dominio lo único que cambiaba era la librería de UI y no tenías que cambiar nada, o sea, solo tocarte o el código de React o el código de Vue, pero la lógica detrás y las llamadas a la API exactamente igual, era un copy-paste, de hecho, está subido en GitHub, intentaré poner el enlace en los comentarios para que la gente lea el hecho si le apetece

[No identificado] (00:17:39): Y el enlace a los de

[No identificado] (00:17:44): Software crafters. Y eso, lo que estábamos comentando ahora de inyectar las cosas por contexto y todo el tema, es algo que se ve súper poco en front, sobre todo en tutoriales o tutoriales estos típicos en plan aprende React en no sé cuánto o es que o por le place que hay por ahí, incluso documentación de librerías de testeo, es que hasta Yes, yo diría que Yes en sí mismo como librería de testing tienes muchísimas malas prácticas, ¿sabes? De que puedes hacer Yes .moc de un import por ahí súper loco, ¿sabes? Y veo como, en general veo como mucha mala práctica por ahí de eso,

[No identificado] (00:18:23): De inyectar, que bueno, a ver, puede ser mala práctica o no, depende de tu estilo de testeo, lo que sea, ¿no? Que yo creo que es debatible también, ¿no? De si merece la pena inyectar las cosas o hacer un moqueo del import, bueno, pues a mí no me gusta eso, no me gusta moquear los imports tal cual, me gusta un poco más tradicional, ¿no? El tema de tener la interfaz y todo el rollo, ¿no? Claro. Al final lo de moquear la interfaz es algo que no es nativo de JavaScript, ¿sabes? Eso es algo que funciona gracias a lo de Required, ¿no? Claro.

[No identificado] (00:18:53): A lo de como JS porque lo que hace Yes es que sustituye la función Required global, ¿no? Sí. Pero con los imports nativos de JavaScript 6 ya eso no te termina de funcionar. Sí. Entonces al final ahí, a futuro, imagínate si no hiciste ya lo de como JS, no podrías hacer este tema que hace Yes ahora mismo, ¿no? Y me parece eso, un poco mala práctica, ¿no? Incluso el tema de las snapshots, hay gente que cae y te hace todo con snapshots, hay ciertas cosas ahí que están un poco tensas, ¿no? Hay dos puntos que tratar ahí que me encantaría tocarlos, tío. Mira, el primero,

[No identificado] (00:19:25): Justamente el viernes, tuvimos algo parecido, ¿vale? Y fue haciendo una sesión de mock programming en LeanMind con el equipo y estábamos viendo cómo podíamos hacer unos test y el problema era que teníamos una clase estática por ahí, dando guerra. Entonces, claro, la solución más rápida y menos elegante era tirar de una librería que te permitía eso, quitando temas de inyección de dependencia y tal, hacer un mock

[No identificado] (00:19:53): Del estático, de la clase estática. Y era como, a ver, sabemos qué se puede hacer, pero realmente a nivel conceptual esto es correcto, o sea, estamos, en realidad lo que estamos haciendo es quitar un código que no es inyectable, que está ahí y que va a ser siempre ese, pero tenemos que hacer un mock de esa dependencia de alguna forma. Entonces, la solución era, oye, podemos utilizar esta librería, creo que ya estábamos hablando de utilizar Power, Power mock o algo así, pero al final es eso, es una mala praxis y pasa lo mismo con Yes cuando haces el mock de esos imports, de esos requires,

[No identificado] (00:20:33): Entonces creo que ahí falta mucho bagaje. Y por otro lado, el tema del código que ves en los tutoriales, creo que ya, de hecho creo que esta conversación ya la he tenido contigo, pero está bien que la manifestemos,

[No identificado] (00:20:47): Tú cuando vas a hacer un tutorial lo que ves es un código de ejemplo y ya está, pero ese código de ejemplo no es copy-paste, o sea, casi que es como irte a Stack Overflow y decir, a ver, ¿qué me han puesto aquí? ¿copio o pego? Tienes que entenderlo y al final eso tienes que modelarlo, es normal que cuando tú estás viendo un código, una demo, ese fragmento o ese ejemplo no te lo puedas llevar a tu aplicación directamente, porque ellos en la demo no te van a poner todo un código de una aplicación real, sino

[No identificado] (00:21:16): La complejidad de entender ese ejemplo crece mucho, no tiene sentido ninguno, tienes que ser gradual y decir, oye, mira, ¿cuántas veces no hemos visto en un ejemplo, en un tutorial de Angular o de React o de Vue que te hacen un fetch al API directamente desde un componente? Tal cual. Y todos los que llevamos un tiempo sabemos que cuando vemos eso nos sangran los ojos, que dices, por Dios, no, no, no lo hagas. También es el público objetivo de esa documentación, esos tutoriales, ¿no? O sea, al final, la mayoría de tutoriales que hay por ahí, en general, de lenguajes y lo que sea, es,

[No identificado] (00:21:49): Aprende X framework, X lenguaje en tanto tiempo, ¿sabes? Pero no, vamos, lo que sí que veo que hay muy poquito en general, es, oye, aprende a organizar bien tu código, aprende arquitectura en general o cómo testear bien, ¿sabes? Y al final, yo creo que es un poco lo que vendo, o sea, yo como React quiero que la gente use mi framework, si te voy a dar un tutorial que sea muy sencillo, no me voy a poner ahí con rollos de arquitectura ni nada de eso. Claro. Pero bueno, que hay que tener eso en cuenta para la gente que está llegando a lo que sea, que,

[No identificado] (00:22:18): Pues, hay un tema que es OK el framework, pero también hay otros temas que es, tiene que estar todo bien testeado y tiene que estar todo bien organizado el código. ¿A qué crees que se puede ver eso? ¿A qué crees que se puede ver que los tutoriales que se hacen sean tan, tan, eh, vamos a demostrar cómo funciona mi framework para que la gente lo use? ¿Crees que tiene algo que ver con la velocidad frenética que ha habido de hasta hace tres, cuatro años de vamos a empezar a sacar librerías o framework para frontend y sin parar y sin justificación simplemente porque el mío

[No identificado] (00:22:51): Mola más? ¿O crees que hay más importancia, que hay más temas por detrás por los que los tutoriales sean así? No, yo no creo que sea por ningún tema concreto porque además creo que es algo que le pasa a todas las librerías en general, ¿no? De que en cualquier framework en cualquier lenguaje no creo que sea algo de JavaScript en concreto, ¿no? O sea, si veo una librería para hacer llamadas HTTP, pues te voy a hacer un tutorial de eso, no de arquitectura, ¿no? Claro. Y un poco lo mismo pues con lo que sea, ¿no? Ya después para temas de arquitectura

[No identificado] (00:23:19): Pues tendrás otros recursos, ¿no? Vale. Ahora que sacas el tema de recursos de arquitectura es una de las preguntitas que tenía preparadas por ahí. ¿Qué recursos de arquitectura recomendarías? ¿Sabemos que son pocos? ¿Sabemos que son escasos? ¿Sabemos que no son asequibles en el sentido de que a veces tienes que sentarte con paciencia, meditar, tomar muchas tilas, compensarlas y equilibrarlas con mucho café? ¿Qué?

[No identificado] (00:23:47): Divagar, probar, entonces es como una religión, ¿no? De decir, bueno, pues vamos a entrar en esta secta de la arquitectura y vamos a ver qué se puede hacer de aquí. ¿Qué recursos recomendarías ahora mismo? Aparte, bueno, si quieres puedes volver a mencionar los que comentaste hace poquito. Sí, sí. Sí, a ver, sobre todo de cómo fue que yo empecé a aprender todo esto, ¿sabes? Que al final fue, pues primero, nada que nada, entrar en Limay, ¿no? Y que Carlos me orientó ahí yo creo un montón. No me enseñó nada en sí mismo, pero sí que me dijo, mira, estos recursos, estos libros, estas cosas, ¿no?

[No identificado] (00:24:20): A los libros no le hice ni caso, pero porque a mí me cuesta muchísimo leer, me cuesta mucho, yo no puedo, no puedo, es algo que me cuesta.

[No identificado] (00:24:27): Pero sí que me recomendó lo de Codely, ¿no? Y por ahí fue que arranqué, ¿no? Y eso, ese es un recurso que a mí me es muy fácil de consumir, todo lo que está en formato vídeo, ¿no? Y me vi, bueno, de Codely yo he visto todo, tío. Es que he visto todos los cursos de la página de ellos y todos los vídeos de YouTube de ellos porque aprendo mucho en general, ¿no? Son muy buenos. Después también,

[No identificado] (00:24:50): Bueno, ya después al final he llegado a un punto en el que yo noto que todavía tengo algunas flaquezas de temas de arquitectura y tal o que hay cosas que no termino de pillar, Y por eso ya al final hemos hecho como un club de lectura interno dentro de la empresa, ¿no? Y nos estamos leyendo algunos libros y esa parte sí me ayuda más, ¿no? Me ayuda a tener un compromiso con leerlo y tal porque si no, si lo leo por mí mismo sé que no lo voy a hacer, ¿sabes? Sí. Pero el hecho de tener tal fecha, tal capítulo y sabemos que la mayoría

[No identificado] (00:25:16): Lo hemos leído, ¿sabes? Eso sí, me marca como un compromiso con el que sí me ayuda Te entiendo. Y además lo que me cuesta leer es libros técnicos porque realmente libros de fantasía y todo rollo sí me puedo leer más fácil pero es que un libro técnico tienes que ir, voy a ir subrayando, ¿sabes? Y tomando apuntes en el Notion y tal y venga. Y releer, sobre todo. Sí, total, igual ves para atrás y vas para adelante. Entonces, bueno, más complicado, ¿no? Pero también es verdad que en los libros de arquitectura tampoco aparece mucho código como tal, son más diagramas, más temas de filosofar

[No identificado] (00:25:49): Sobre lo que estás viendo, preguntas. Depende del libro, depende del libro. A mí, ya te digo, yo no he leído muchos libros, ¿no? Pero el que me estoy leyendo ahora que es el de Implementing Domain Driven Design es un libro que está como pensado para gente que ya tiene nociones de Domain Driven Design, ¿no?

[No identificado] (00:26:07): Sobre todo porque va a muchos sacos. Dice, no, esto lo hace, el capítulo uno que es introducción te habla ya de rollos de agregados y de value objects y todo esto, ¿no? Que si eres nuevo a Domain Driven Design pues igual va a ser duro ese libro. Pero si ya tienes alguna noción de eso, has visto algún vídeo, has visto, y has intentado practicar con eso un poco, ¿no? Te va a venir súper bien el libro. Además, el ejemplo que te pone el libro, ¿sabes? El libro va hablando de todo el tema pero a la vez va como

[No identificado] (00:26:36): Poniendo un ejemplo de gente que sabía un poquito de Domain Driven Design pero no del todo, ¿no? Sí. Y ese para mí es el público objetivo del libro, ¿no? Y va muy bien porque además va a poner un montón de ejemplos a nivel de código, cómo hacer cosas y está bastante moderno, ¿eh? La verdad, o sea, no… Es para Java, o sea, los ejemplos que tiene son en Java y C-Shot, creo, sobre todo en Java, pero vamos, aplica perfecto a todo lo que es JavaScript, a Escribd y todo este mundo. Sí, sí, sí, al final estamos hablando de que los lenguajes de programación

[No identificado] (00:27:06): Tienen sus particularidades pero tampoco son tan distintos, pueden tener un enfoque más funcional, más orientado a objetos, pero ya hoy en día casi que tampoco esa es una diferencia

[No identificado] (00:27:20): Predominante, todos los lenguajes tienen ya programación funcional

[No identificado] (00:27:27): Contextualizada y lo mismo con respecto a programación orientada a objetos. Me gustaría dar un tip aquí porque sí que es verdad que yo soy un gran tramposo en este sentido de leer libros, yo soy el mayor tramposo que ha existido en la historia y es que muchos de los libros los consumo en formato digital pero en modo audio.

[No identificado] (00:27:50): ¿Casi? Yo los escucho, sí, sí, sí, sí, todos los libros intento de buscarlos en formato EPUB o PDF y con aplicaciones lo que hago es que como bien sabéis yo soy un chico fitness

[No identificado] (00:28:04): Entonces cuando salgo a correr cuando estoy entrenando cuando me pongo a hacer cosas en casa me lo pongo en formato audio los voy escuchando sí que es verdad que a veces es súper divertido cuando llegan a las partes de código

[No identificado] (00:28:18): Import almohadilla bla bla bla bla bla bla std int dot y es como vale, ok, gracias no quería ir por ahí esos momentos son súper divertidos pero bueno te hacen dar ese break pararte reflexionar sobre lo que has escuchado mirar el código y ya después sigues a lo que estabas haciendo ¿no? Entonces he de confesar que muchos de los libros a mí también me cuesta leer la parte técnica pero sí que es verdad que hacer esa introducción vía audio y después hacer una lectura más diagonal real de decir oye pues me siento cojo el libro lo empiezo a leer veo los ejemplos

[No identificado] (00:28:56): Como con más detenimiento porque ya tengo el run run ¿no? Como decimos aquí tengo el run run me suena de algo sé de lo que va y me es más sencillo más asequible y además también me ayuda a descartar mucho de lo que me está contando me aporta lo que me está contando no me aporta y descarto muy rápido ya sabes que creo que tú estás en la misma situación que cuando te metes en un montón de fregados al mismo tiempo el tiempo hay que optimizarlo lo máximo posible entonces descartar cosas es prioritario ¿no?

[No identificado] (00:29:27): Y bueno más recursos así que me han servido en general más allá de vídeos y todo este tema bueno primero el Sócrates eso ahí la verdad que aprendes un montón y otros puntos de vista el foco que pone la gente en testeo sobre todo gente que hace cosas así como super ras que tú dices coño no había pensado en esto la verdad

[No identificado] (00:29:47): El Sócrates genial en el evento ¿no? Sí es un open bueno para quienes no conozcan el evento de Sócrates el Sócrates es un evento formato open space donde todas las personas que asisten pueden ser speakers

[No identificado] (00:30:04): Se va al evento no hay una planificación y a primera hora de cada día las personas proponen de qué les gustaría hablar o qué les gustaría que les contasen salen salen las propuestas se votan se organizan en un planning y y ya está y se organiza así el evento sobre la marcha en caliente sin a ver hay personas y es lo más normal que si tú quieres hablar de un tema ya pues a lo mejor lleves algo preparado un poco para moderar de lo que se va a hablar pero bueno la verdad es que a mí ese formato me gusta mucho lo veo muy natural

[No identificado] (00:30:42): Encima al ser un open space ves que cuando la gente

[No identificado] (00:30:46): Es como la polinización tú llegas a una sala están hablando un tema escuchas ves si te interesa o no te quedas cambias a otro es más eso el hablar el conocer distinta gente el ver distintos puntos de vista a mí ese formato me encanta sinceramente y creo que que te aporta mucho y la gente que va además como son eventos

[No identificado] (00:31:08): Digamos que son

[No identificado] (00:31:12): No son asequibles para todo el mundo pero creo que lo que te aporta es muy grande si viene mucha gente internacional también la verdad que es súper guay además es que sobre todo he conocido ahí a gente que después he sido por twitter o lo que sea y digo madre mía hay gente muy buena después también ya de último también lo que estoy escuchando ahora más recientemente es un podcast que tienen los decodesight que se llama The Big Branch Theory

[No identificado] (00:31:45): Y está muy bien la verdad que comentan ahí un montón de rollos de eso de arquitectura de los principios solid pues lo van a ir comentando ahí creo que están sobre todo Miguel Viera y Alfonso y genial la verdad que aprendo un montón ahí y saco cosas de valor escuchar la opinión de ellos está súper bien genial que bueno que bueno lo que me estás contando porque al final se nota que hay comunidad detrás que hay comunidad que tiene esas mismas preocupaciones que yo creo que tenemos todos que las está visibilizando y que además intenta aportar su granito de arena que hacer que todos crezcamos

[No identificado] (00:32:23): Que aprendamos que bueno que bueno que bueno o sea conozco Codesight conozco a varias personas que trabajan ahí pero no sabía que tenían ese podcast el podcast está buenísimo te lo recomiendo pues mira alguno de los libros que escucho en formato audio lo acabaré quitando y lo acabaré reemplazando por ese podcast casi seguro son muy buena gente que bueno tío mira y te iba a decir ya por un poco que no sea todo tan técnico sé que te gustan mucho las mates vale de hecho yo es una camisa de la NASA o sea que por un poco hacer la coña dar este aire

[No identificado] (00:32:59): Refrescante y tal como te gustan las mates la pregunta es me gustaría que me sacases una teoría en caliente aquí y ahora de cuál crees que es la relación proporcional entre el café que consume un developer y el código que genera yo creo que está complicado porque empieza a linear empieza hacia arriba así suave pero llega un momento en el día en el que tienes ahí el efecto rebote y hace y se va a toda la mierda después de comer es el momento crítico que yo me replanteo la vida y digo con el café incluido la calidad baja si se llegó aquí a tope

[No identificado] (00:33:37): Pero la calidad la calidad baja no sé si la calidad pero la velocidad seguro la velocidad de pensamiento hay unos neuronas así moviendo todo el mecanismo en ese momento bueno bueno pero porque yo creo que también influye mucho el cómo trabaja cada uno yo he visto personas que justamente después de comer son brillantes tú dices pero cómo puedo estar yo tan destruido tan enterrado tan por favor cierra todo y vete a dormir y tú estás pletórico lleno de energía o sea cómo lo haces dame la receta porque no yo una cosa que estoy intentando es quitarme un poquito de café por lo menos porque sí

[No identificado] (00:34:17): Yo creo que estaba tomando un poco demasiado

[No identificado] (00:34:21): Pues sí un poquito menos y tomar sumito de naranja y tal bueno ahí poquito a poquito el healthy el healthy estás cogiendo ahí buenas prácticas sí sí tenemos que confesar que aquí el aquí presente se ha llevado a asustar cuando ha visto la cantidad de café que ingería Dani en un solo día primero ahora a la mañana y si es Dios mío que lo tenemos que llevar a urgencia sí sí sí sí no qué bueno me alegro un montón que yo también estoy tomando descafeinado ahora a ver sigo tomando café descafeinado también un poquito

[No identificado] (00:34:54): Eso sí sigo tomando café pero he intentado de meter más descafeinado porque sí que es verdad que cuando de verdad me hacía falta el café y ahora como esto no me hace nada o sea ha llegado a ese punto de da igual si es café si es aguachirri que no no hay efecto no hay efecto positivo pero sí que es verdad que el problema es que a mí me encanta el café me gusta mucho el sabor y es esto de que te ponen un café de máquina de estos baratos y te dirás eh cuando pruebas un café bueno de verdad bien preparado

[No identificado] (00:35:27): Que también es importante dices ¡buah! Esto es la gloria esto es el cielo pero bueno pues sí es lo que es lo que toca es lo que toca mira y tú a nivel de Bach estás tocando algo ahora sí sí sí sí sí sí de hecho te va a sorprender porque tú sabes que siempre yo he sido muy renegado de Java no me ha gustado nunca mucho y es verdad que he trabajado un montón de años con él pero bueno la anécdota para que la gente también me vaya conociendo un poco es que cuando yo aprendí Java ¿vale?

[No identificado] (00:35:59): Yo estaba en el ciclo superior y fue crítico fue un mes que me puse malo tío estuve un mes con 40 de fiebre que no pude ir a clase no pude ir a clase y recuerdo que teníamos la práctica final los profesores lo sabían que yo estaba malo tenía mis justificantes médicos y todo pero bueno la práctica me la comí como un campeón encima con JSP todas esas tecnologías que ya hoy en día es muy difícil verlas salvo en bueno salvo en caso

[No identificado] (00:36:33): Un poquito legacy esperemos si no mal asunto pero sí sí me comí esa práctica yo solo sufriendo y me acuerdo siempre me acordaré que le dije a a mi tutor en aquel momento por favor a donde me mandes de prácticas me dé igual pero que no toquen que no toquen Java

[No identificado] (00:36:53): Y me mandó de prácticas donde nos conocimos a Open Canarias y se lo dije le dije me acabas de hacer un Cristo me acabas de hacer un Cristo me dijo ¿a ti no te gustan los retos? Pues venga campeón y la verdad es que aprendí mucho de esa época aprendí mucho de esa época pero bueno siempre me quedo esa espinita con Java de que le cogí manía por eso porque me lo como dice la gente hoy en día me lo tanqueé yo solo me lo tanqueé con el pecho por delante y dije vamos pero bueno con los años le he ido cogiendo cariño

[No identificado] (00:37:29): Y ahora estoy trabajando en Kotlin estoy tocando Backend estamos en una aplicación bastante grande de una empresa bastante grande

[No identificado] (00:37:40): Esa aplicación la utilizan en todo el mundo el Frontend está hecho en React y el Backend está hecho en Kotlin con Spring Boot y demás y está divertido está muy guay Spring Boot la verdad o sea yo he estado trasteando con Spring Boot con Kotlin justo ¿no? Y solamente para trastear porque al final yo tengo la sensación porque nosotros estamos usando TideScript con Ness que TideScript con Ness es el hijo malparido de Kotlin con Spring Boot ¿sabes por qué? Porque al final lo ves y es todo igual es todo igual los decoradores lo bueno es que Spring Boot tiene el tema de autoinyectables

[No identificado] (00:38:17): Y todas estas cosas que son bueno que están buenas ¿no? Al final para poder yectar las cosas ¿no? Pero

[No identificado] (00:38:24): Parecía un poco como o sea quería estudiarlo un poquito y verlo un poquito porque parecía como el origen o el precursor de todo esto ¿no? Entonces un poco para ver cómo hacían ciertas cosas ¿no? Porque por ejemplo con unas cosas que yo me he estado pegando últimamente es que al final tú tienes tus modelos de dominio y todo tu backend ahí perfecto ¿no? Y al final tienes una interfaz que es el repositorio y ese repositorio tiene una implementación ¿no? Pues una de las cosas que nosotros hacemos es que usamos un ORM dentro de la parte de implementación como detalle de implementación de la interfaz ¿no?

[No identificado] (00:38:56): Pero claro tienes que hacer un mapeo entre tu modelo de dominio y el de ORM ¿no? Sí y eso es un poco fastidio ¿no? Entonces pues estuve haciendo como research ahí de a ver cómo lo hacen en otros lenguajes ¿no? Ese usar a Hibernate con un modelo de dominio a ver cómo cómo juega eso o cómo no juega y bueno tenso ¿no? O sea yo la conclusión que saco es no se joder de ORM con no, no, no, no tienes que desacoplarlo tienes que desacoplarlo mira nosotros justo hemos debatido bastante en ese tema y a la conclusión que hemos llegado es sí que es verdad

[No identificado] (00:39:30): Que hay ciertos paradigmas que tenemos que aceptar porque al final es una empresa bastante grande que tiene su estándar y demás entonces lo que hemos llegado a hacer es definimos por un lado lo que es nuestro repositorio de dominio ¿vale? Que no es lo mismo que creo que eso es uno de los grandes problemas que tiene Spring total creo que ese es uno de los grandes problemas que tiene Spring entonces vamos a partir por la base lo que Spring llama repository no es un repository es un dado entonces ese es el gran problema cuando tú hablas de repository la gente ya asocia ah sí sí

[No identificado] (00:40:04): Repository no no no no ojo repository es un repositorio de dominio y eso habla tiene como input y como output entidades de dominio y eso internamente es una o sea perdón eso es una interfaz internamente tú tendrás una implementación de esa interfaz y ahí es donde tú inyectas los repositorios de JPA claro claro claro claro entonces ya tienes tu repositorio de dominio interfaz tienes tu adapter que es la implementación de esa interfaz y ahí dentro es donde pones donde inyectas todo lo relacionado a la tecnología de JPA haces tus mapeos y demás ¿qué pasa? Que esos adapters son súper engorrosos porque al final es donde

[No identificado] (00:40:54): Incluso es inevitable que tengas cierta lógica porque tienes que transformar tu modelo de dominio a varias entidades de JPA o de Hybern y todo eso es lo que persiste tienes además esas reglas de persistencia tienes además temas de que tu base de datos no tiene por qué reflejar tu dominio ni tu dominio tiene por qué verse reflejado de forma idéntica en la base de datos entonces al final yo creo que muchas aplicaciones donde el dominio es pobre

[No identificado] (00:41:22): Gran parte de la complejidad está en esos adaptadores bueno incluso aunque el dominio no sea pobre incluso te diría que es peor si el dominio es grande y va a diferir mucho de la base de datos esos adaptadores son un horror son un horror son un horror a ver yo

[No identificado] (00:41:38): Pasa lo mismo justo pasa lo mismo en Nest o sea Nest tiene TypeRM que es el que usas ¿no? Y tiene eso inyectas un repositor y el TypeRM ¿no? El user repository ¿no? Pero claro es un user repository de TypeRM no tuyo de dominio ¿no? Entonces hacemos exactamente lo mismo ¿no? Tienes una interfaz que es el dominio que persiste el agregado del usuario ¿no? O que interactúa con el agregado del usuario y después a nivel de implementación de esa interfaz pues ahí inyectas el user repository que ese user es el user entity de TypeRM ¿no? Y el problema es que tienes que tener un mapeo

[No identificado] (00:42:13): Entre tu usuario de dominio y el de el de la ORM ¿no? Y al final es que tú lo piensas y yo no sé si termina de compensar la complejidad porque al final es complejidad accidental el tema de meter un ORM para para facilitarte la vida en ciertos aspectos y es verdad que si te la facilita en ciertos aspectos como las migraciones o o yo que sé hacer un find y tener poder poner la query ahí directamente ¿no? Pero si quitas eso y pones un query builder plano ¿sabes? No el driver directamente sino un query builder yo creo que ahí se facilitan las cosas ¿no?

[No identificado] (00:42:49): No lo he probado todavía seguimos con el ORM y haciendo los mapeos y todo el rollo pero yo creo que con query building se soluciona bastante la movida ¿por qué? Porque no tienes los modelos del ORM sino que directamente pues hace pues el .6 por ejemplo es un insert o un conflict update y ya está ¿sabes? Y después el modelo de dominio puede diferir de la base de datos ¿no? Pero hay que intentar que no difiera mucho ¿no? Porque si no al final te va a costar un montón igual que si modificas algo a nivel de dominio pues seguramente tengas que refactorizar

[No identificado] (00:43:18): Algo en la base de datos ¿no? De pues cambias alguna tabla o no te puedes proteger de eso porque tienes una capa anticorrupción ¿no? En el repositorio pero lo ideal es que al final eso vaya coincidiendo lo más que puedas ¿no? Sí o sea y sobre todo una de las cosas por las que creo que al principio se vendieron bastante el tema de los ORM es porque se supone no se a día de hoy hasta qué punto esto es cierto pero que te protegían de posibles inyecciones de SQL es decir ellos metían la capa de seguridad por ti y bloqueaban que ese tipo de cosas

[No identificado] (00:43:52): Ocurriesen ¿no? Que los parámetros te introdujesen pues esos queries maliciosas a tu sistema se supone que todo se supone que todo eso los ORM ya te lo te lo quitan si no cuando utilizas un query builder igual te lo tienes que currarte un poquito más o no todo es que justo en ay cuño perdón

[No identificado] (00:44:13): Ahí en TypeRM

[No identificado] (00:44:16): En TypeRM

[No identificado] (00:44:18): Ellos usan por debajo un query builder y ya después por debajo el driver ¿no? Y el query builder es justo el que se encarga de escapar todas las cosas ¿no? Si usas bien un query builder que eso es otra cosa

[No identificado] (00:44:29): Directamente puedes poner los parámetros y él te los escapa y tal incluso hay query builders que son súper modernos para javascript que tú puedes escribirte la SQL

[No identificado] (00:44:38): En string ¿sabes? Interpolando las variables dentro que es el tema este de template literal con el perfijo que realmente es una función ¿sabes? Lo que me refiero que es lo mismo que tiene GrasQL que pones GQL y el string ahí pues lo mismo pero pones SQL un string ahí y todo lo que interpoles él lo escapa automáticamente ¿sabes? Qué bueno está súper guay porque te puedes escribir el SQL que te dé la gana interpolando lo que tú quieras y él te lo va escapando todo ¿no? Qué bueno qué bueno pues lo voy a probar lo voy a probar porque hace tiempo

[No identificado] (00:45:10): Que no le he hecho un ojo y suena bien suena bien de hecho estoy totalmente de acuerdo contigo en ese sentido al final lo que tienen los ORMs es que tienen una curva de aprendizaje que es innegable quiero decir cuando quieres hacer cosas que se van un poquito de un crude

[No identificado] (00:45:29): Necesitas saber por debajo cómo está bien implementado total y cuando ya vienes de trabajar o de haber estudiado por lo menos en la universidad en los ciclos SQL o bases de datos no relacionales es más cercano a los nativos es más cómodo ya tienes ese conocimiento no es otra curva de aprendizaje añadir más sus particularidades que después cada uno tiene sus cosas que solo los gurús conocen quieren sacarle de verdad partido a esos ORMs entonces le voy a dar una probada a ver a ver qué tal a nivel interno tenemos un poco esa discusión de que nosotros empezamos así con el tema

[No identificado] (00:46:08): De que el ORM es un detalle de implementación pero ese final yo creo que nos incrementa mucho la complejidad de esa implementación tienes que tener un mapeo tienes que conocer cómo funciona el ORM las cosas las particularidades que puede tener ese ORM al final un query builder es una herramienta súper bajo nivel que no difieren mucho unas de otras entonces bueno pues hay que ver también tienes un poquito más de complejidad en ciertas implementaciones pero bueno hay que ver si te compensa ahí o no te compensa un rollo de debate yo creo que sí es probarlo y verlo sí es probarlo y ver

[No identificado] (00:46:42): Pero yo creo que sí o sea yo te digo un poco por poner casos reales a ver también depende de tu caso o sea sí que es verdad que si tienes que priorizar velocidad frente a

[No identificado] (00:46:55): Digamos calidad aunque sabemos que no es así pero cuando necesitas una solución rápida los ORM te pueden facilitar mucho pero en proyectos donde tienes una fuerte dependencia de base de datos y maneja o sea tu base de datos

[No identificado] (00:47:12): Contiene mucha información de tu dominio por decirlo de alguna forma y tus queries son muy grandes hacer ese tipo de queries de 30, 40, 60 líneas con un ORM basado en entidades es muy complejo y la performance baja mucho también sin embargo si te las picas a mano sabes que son 30 líneas de SQL o de lo que sea pero que al final tú tienes el control y puedes hilar un poquito más fino y reducir esos problemas de performance que en los casos en los que hemos estado trabajando últimamente en estos proyectos que te cuento es lo que nos hemos encontrado que cuando quieres salirte

[No identificado] (00:47:49): Ya un poquito de lo que es lo básico la performance de las queries por los join que te hace el cómo gestionar los ideas y tal eso empieza a decrementar y nos hemos encontrado queries que son relativamente

[No identificado] (00:48:04): Digamos relativamente sencillas en comparación con las más complejas que por no conocer bien el ORM se te pueden llevar 5 segundos de ejecución si porque igual te tienes un N++1 o lo que sea o se traen un montón de datos efectivamente lo del N++1 es lo típico

[No identificado] (00:48:21): Generalmente y después lo otro que es interesante que estamos así pues también investigando o pensando por lo menos porque hay una cosa que nos pasa a ver no creo que sea ningún problema nuevo pero hay una cosa que nos pasa no sé si te ha pasado que es pon tú que tienes una tabla de usuarios ¿no? Y después también tienes otra tabla o sea no tabla sino bueno en el front es una tabla por eso digo tabla ¿no? Sí tienes una tabla de un montón de usuarios todos los usuarios dentro de una plataforma y esos usuarios pueden traer suscripciones ¿no? Y en el front

[No identificado] (00:48:53): Tienes otra tabla que es distinta suscripciones ¿no? Sí y bueno podrían ser dos agregados ¿no? A nivel de implementación de back tienes el agregado usuario tienes el agregado suscripción se relacionan por ID o lo que sea ¿no? Y son modelos totalmente distintos ¿no? Pero hay un problema que es que ponle tú que en en el front tienes que no solamente mostrar los datos de la suscripción sino también el nombre del usuario o el nombre y la edad del usuario ¿sabes? Tienes que mezclar un poco los dos datos de los dos agregados ¿no? Claro eso es un poco complicado entonces no sé si tú tienes

[No identificado] (00:49:28): Alguna solución para eso yo te daré igualmente la nuestra a ver que estamos por lo menos investigando entonces bueno vale a ver yo te diría que una de las cosas que nosotros hemos llegado a hacer últimamente es decir oye

[No identificado] (00:49:42): Dependiendo de cada parte de la aplicación los modelos de dominio no tienen por qué ser los mismos porque son partes del dominio distintas quiero decir no es lo mismo un usuario como agregado dentro de una factura a lo que viene a simbolizar un usuario dentro del dominio de autenticación es decir el concepto como tal si que recibe el mismo nombre son usuario y usuario pero dentro de cada parte de la aplicación dentro del dominio de la aplicación los subdominios que hay son modelos distintos entonces la solución más clara es si son cosas distintas llámalos de forma distinta o ese agregado gestiónalo dentro del dominio

[No identificado] (00:50:26): De forma distinta es decir no hay ningún problema porque existan dos modelos usuarios como modelos de dominio porque la información que van a contener y la información que van a gestionar es totalmente distinta y sería un poco absurdo que dentro de la memoria dentro de la RAM de la máquina con la que te estás trayendo esa query tengas todo un modelo entre usuarios cuando lo único que vas a utilizar es una proyección de ella que es solo el nombre entonces dependiendo de los casos te renta mucho dentro de tu dominio el reflejarlo de una forma o de otra si si ahí esa es una opción

[No identificado] (00:51:02): ¿no? Dices que son dos modelos distintos y tienes dos modelos distintos y ya está si efectivamente

[No identificado] (00:51:09): Nosotros lo que estamos haciendo al final es una disonancia que hay a la hora de consumir datos a la hora de escribirlo si que tienes la parte de suscripción y la parte de usuarios pues súper diferenciada ¿no? Y tienes una serie de acciones que quieres aplicar sobre las suscripciones o sobre los usuarios ¿no? Pero a nivel de consumo de datos es donde yo veo que a veces dependiendo del proyecto ¿no? A veces nos difiere lo que tenemos en el agregado de lo que tenemos en el front ¿no? Entonces nosotros estamos empezando a investigar un pseudo CQRS ¿sabes? No CQRS al uso en plan

[No identificado] (00:51:47): Tengo un comando lo pongo en el en el base de comandos después eso lo consume un handle y dispara el caso de uso y lo mismo con la query ¿no? Sino que hacemos como un remodel y un remodel pero ligerito ¿sabes? Si tienes tus endpoints que atacan un caso de uso y escriben sus cosas y usan un modelo rico de dominio ¿no? Pero después las cosas que son un GET usan también no usan casi bueno no sé no hemos debatido todavía si usar un un caso de uso para eso porque yo creo que no merece la pena porque al final el caso de uso

[No identificado] (00:52:18): Va a ser solo una línea llamada repositoria ya está pero en vez de usar el mismo repositorio que usas para traerte todos tus agregados usas un repositorio específico te trae los datos específicos de esa vista ¿no? Vale y esos datos específicos de esa vista tienes dos opciones ¿no? A nivel tienes por así decirlo imagínate tienes un user repository ¿no? Y después tienes un user remodel repository ¿no? Sí que es una proyección de su usuario ¿no? Y ahí pues le pones datos de más o de menos con joins en distintas tablas ¿no? Es un poco trampa porque los repositorios deberían ser independientes unos de otros ¿no?

[No identificado] (00:52:53): Pero al final como va toda la misma base de datos pues nos viene bien así ya está ¿sabes? Y lo guay es que puedes hacer como modelos de lectura nada más para el front ¿no? Por ejemplo todo lo que es imagínate una vista de listado y una vista de detalle ¿no? Pues en la vista de esa de listado te traes un remodel de la base de datos que coincide justo con los datos que necesitas en el front ¿no? Vale y lo mismo con la vista de detalle ¿no? Igual la vista de detalle también tiene que componer de otras tablas o de otros agregados ¿no?

[No identificado] (00:53:21): Entonces bueno pues eso lo compones en el remodel y es lo que envías al front ¿no? Entonces bueno por ejemplo en este caso de suscripciones lo que tendrías es un subscription remodel repository ¿vale? Y eso te va a traer un type directamente ni siquiera una clase ¿sabes? Tiene que ser un type porque el modelo de lectura es solo el lectura no va a escribir nada sobre eso ¿no? Y ese type tal cual coincide justo con los datos que el front tiene que dibujar ¿sabes? Vale vale entonces de esa forma a todo lo que es una escritura pues tiras el caso de uso

[No identificado] (00:53:55): Cargas el modelo rico de dominio todo el rollo perfecto ¿no? Y a nivel de lectura vas a leer los datos de la base de datos justo a lo que te hace falta ¿no? Entonces ganas en performance porque no tienes que leer datos de más ni datos de menos ¿no? No es CQRS libro ¿sabes? Pues con toda la maquinaria que tienes que tener pero oye no sirve ¿sabes? No a ver eso es como todo o sea

[No identificado] (00:54:20): A ver hace poco escuché un un podcast sobre un chico que hablaba bueno no era un podcast era un video sobre un evento que ocurrió en noviembre y lo que hablaba era de arquitectura ornitorrinco ¿vale? Y era un poco eso o sea hasta qué punto tienes que tener una arquitectura como tal al dedillo de no no todo bien diferenciado mi port mi adapter mi capa de dominio mi repositorio o sea sí que es cierto que hay momentos donde tenemos que ser lo suficientemente flexibles y mira no hace falta que las cosas sean de libro porque

[No identificado] (00:54:58): Podemos pasarnos de sobre ingeniería ¿no? Entonces no le veo ahí tanto problema

[No identificado] (00:55:05): Con respecto a lo que me has contado a ver parece que como solución es válida no le veo problema me puede preocupar un poco como puede llegar a escalar eso ¿no? Cuando haya que empezar a modificar y demás pero también es cierto que no sé cuál es el escenario de la aplicación pero que el escenario donde se usa pues también influye mucho no es lo mismo por ejemplo seguramente estamos hablando de que tanto el frontend como el backend lo controla el equipo es una aplicación completa desde frontend hasta backend a decir oye nosotros lo que tenemos que hacer es un backend y hay una empresa

[No identificado] (00:55:45): De terceros que es quien va a consumir ese backend para montar su UI o viceversa ¿no? Entonces ahí sí puede que hubiesen problemas pero volvemos a contextualizar y creo que es lo mismo de siempre ¿no? Las soluciones deben depender del escenario en el que se está jugando no no hay soluciones que sirvan para todos los casos ni en todos los casos se van a dar los mismos problemas que tengas que solucionar por eso lo de arquitectura adaptativa

[No identificado] (00:56:14): ! Sí total yo creo que eso es algo que estamos pensando ni siquiera hemos metido todavía pero yo creo que es algo que puede estar interesante la verdad que es como un CQRS light

[No identificado] (00:56:24): ¿sabes? Sin toda la complejidad de la maquinera que lleva eso sí sí no lo veo mal porque al final

[No identificado] (00:56:34): Volvemos a lo mismo ¿no?

[No identificado] (00:56:37): Todos sabemos que es bueno tener una capa de dominio pero si solo tienes un CRUD y estás trabajando por ejemplo en una startup donde tienes que dar valor rápido donde lo que te interesa es que hay una inyección monetaria de los inversores y que pues da valor rápido porque tienes que iterar rápido y tienes que equivocarte rápido para corregir rápido entonces ¿para qué quieres estar metiendo capas de dominio cuando de hecho ni siquiera existe un dominio probablemente las personas que están diseñando el negocio y esa aplicación todavía no tengan ni siquiera un negocio lo que quieren es hacer cosas y que eso se guarde entonces

[No identificado] (00:57:12): Sí que igual ni siquiera tienes un backend tienes un Excel cochino ahí efectivamente efectivamente entonces creo que eso es uno de los grandes problemas ¿no? Que hoy en día queremos ser

[No identificado] (00:57:25): Súper pragmáticos y súper puristas y decir no, no es que esto y pecamos de sobre ingeniería y al final nos olvidamos como desarrolladores que detrás hay personas que están trabajando que necesitan usar esa aplicación que tienen que cobrar a final de mes para alimentar a sus familias y que nosotros por nuestro ego de ser perfeccionistas y dejarlo todo del libro y que sea todo perfecto y que quien venga de… Nos pasamos y la liamos parda ¿no? Sí yo lo que creo que es para ser un MVP si eres una empresa sobre todo chiquita en plan una empresa familiar o lo que sea tirame un Excel

[No identificado] (00:58:00): ¿sabes? Tirame un Excel pruébalo y no metas inversión a desarrollo pues lo menos que puedas ¿sabes? Si tal para marketing pero para desarrollo te diría que no si tal hacer una aplicación para mí React Native con un front que tira de un Excel detrás o que ni funciona o es bonito y ya está ¿sabes?

[No identificado] (00:58:30): Sí al final ya nosotros nos llegan gente que o tiene un producto medio caminado o quieren ya lanzar un desarrollo ¿sabes? Nos han llegado gente que estaba tirando un Excel literalmente ¿sabes? Entonces bueno en ese punto sí que ya puedes pensar algo que no es tan cruz de hecho para mí el 90% de los casos que tenemos aquí en Asit son de dominio rico ¿sabes? Es un negocio que tiene yo que sé que sin mascotas o no sé qué que tienes que sincronizar las suscripciones con no sé cuánto o tienes que ir a ponerle no sé qué ¿sabes? Y tienes un montón de lógica

[No identificado] (00:59:01): Que si de un principio no lo hubiésemos hecho aplicando todos estos temas de arquitectura de D y tal nos estaríamos pegando un tiro un poco fuerte sí sí sí sí de hecho esta es una de las cosas que no se dice nunca pero yo quiero desmentirla ya de una maldita vez porque parece que estamos hablando aquí que estamos endiosados que somos seres humanos que nunca nos equivocamos y demás vayamos al salseo ¿vale? De todo esto que hemos dicho oye desacoplamos no sé qué tatatatatatatata claro lo sabemos pero lo sabemos ahora hace cinco años seis probablemente no lo sabíamos entonces seamos sinceros sin decir nombres ¿vale?

[No identificado] (00:59:44): Porque eso sí sería un poquito conflictivo pero

[No identificado] (00:59:48): ¿serías capaz de de de cuantizar cuántas veces hemos metido la pata digo hemos porque a todos nos pasa ¿cuántas veces nos hemos equivocado a la hora de tomar una decisión en cuanto a arquitectura? Yo a ver yo la pata la meto todos los días más o menos más o menos pero todos los días la meto porque sin ir más lejos el otro día hago una pull request me ponen un comentario y digo pues sí la verdad que sí pues no le falta razón todos los días Adrián y las patas más fuertes así que he metido de las que he aprendido que he salido quemadito

[No identificado] (01:00:25): De eso pues primero de lanzarte a hacer un refactor inconmensurable gigante de estos así de tumbar la aplicación y rehacerla eso jamás en la vida lo vuelvo a hacer nunca ¿sabes? De hecho es un caso en el que estoy un poco ahora que hay una aplicación ahí que hay que dejar un poco más fina y eso de tumbarla y volver a hacerlo pues no va a funcionar eso no funciona entonces bueno un poco lo de voy a escar por donde paso pues lo dejo un poco mejor que antes hablamos con el equipo vemos cómo mejoramos pero no decir venga refactorizo toda muerte y ya está

[No identificado] (01:00:55): Y bueno pues eso no va a salir bien ¿no? Pero hace seis años lo hubiésemos hecho ah sí sí sí sí de calle de calle menos más que ya no y no sé qué más cosas montones yo qué sé por ejemplo no saber lo que es un contenedor de dependencia y empezar a inyectar todo ahí por constructor y tener una maquinaria súper grande por no saber algo como lo de inversify o o bueno un contenedor de dependencias ¿no? Sí sí totalmente de acuerdo simplemente hacerte una factoría que al final lo puedes hacer un poquito más craftman y decir oye pues montamos una factoría

[No identificado] (01:01:31): Y que te devuelves sí sí sí incluso de llegar a un código de back y decir repositorio esto que es repositorio y servicio servicio no entiendo nada voy a ponerlo todo en el controlador eso lo he hecho yo bueno a ver eso lo hemos hecho todos eso lo hemos hecho todos pero sí que es verdad que un poco lo que quería era desmitificar eso ¿no? Porque habrá personas que nos estén escuchando que estén saliendo de universidad y tal y vayan con esa idea de guau esta gente son dioses del desarrollo mira lo que están hablando elegancia tal que no que no que nosotros

[No identificado] (01:02:07): La hemos cagado mil veces y la que nos queda y lo que nos queda lo que pasa que no se ve que es la cosa y al final una cosa que me da como un poquito de ansiedad pero no a la vez es que hace 5 años no sabíamos todo esto pero dentro de 5 años vamos a hacer un montón de cosas que no sabemos ahora ¿sabes? Qué cosas son las que no sabemos ahora que las estoy cagando ahora mismo ¿sabes? Ojalá pueda ir al futuro y hablar conmigo del futuro para que me digan mira no hagas eso así literal ojalá pero bueno

[No identificado] (01:02:36): Yo que sé siempre hay una anécdota y de hecho la voy a contar aquí ahora porque

[No identificado] (01:02:42): Fue divertida fue bastante divertida hace unas semanas no sé si te acuerdas de de David Prieto ajá que yo trabajaba en Open y tal pues estuvimos hablando y y una de las cosas que hablamos fue fue esa ¿no? Hubo un momento donde nos reunimos estábamos él y yo y otra persona más y y él decía oye chicos vamos a hacer esto vamos a desacoplarlo mantener esto más limpio y tal y no sé qué

[No identificado] (01:03:09): Y claro yo llevaba trabajando dos tres meses o sea pero ¿para qué quieres estar convirtiendo de esto a lo otro? Eso al final hace que pierda rendimiento ¿para qué quieres transformar? Si lo que nos interesa es que la aplicación vaya como un tiro y que los usuarios estén contentos y tal y no sé qué decía bueno vale

[No identificado] (01:03:31): Y y fue una de las mejores cosas que hizo él coger y decir bueno vale hazlo así ostras vaya estampida me pegué vaya estampida me pegué cuando o sea cuando eso empezó a funcionar y tal

[No identificado] (01:03:49): Después me acuerdo que yo cogí calladito la boca sin decirse lo yo cogí lo cambié todo y lo transformé o sea metí los mappers y y se lo dije y le dije mira David que lo que me habías dicho lo lo cambié o sea lo cogí por mi cuenta porque ese que fue una cagada mía lo lo cambié y y tiene los mapper metidos me dijo y entiendes el porqué yo sí porque si no meto esos cambios cada vez que se cambia algo en la base de datos tengo que cambiar todo hasta la vista y no no tiene no tiene plan ¿no? Vale

[No identificado] (01:04:25): Pues si entendiste el porqué sigue con eso y hace poco quedé con él y se lo o sea lo estuvimos recordando y tal y nos reímos bastante pero sí que son de esas cosas también que tú dices mira para aprender tienes que equivocarte y tienes que tener alguien que te deje equivocarte ¿no? ¿cuántas veces no hemos intentado por lo menos yo hablo en mi caso ¿no? Llega alguien nuevo a la empresa y le empiezas a contar temas de arquitectura que es infraestructura no sé qué tatatata todo súper bonito y claro intentan de plasmar en código lo que tú le estás explicando

[No identificado] (01:04:55): Lo que estamos hablando tú y yo ahora aquí en el podcast y tal dice no me he enterado de papa y empiezan a hacer unas cosas ahí súper raras que tú dices ¿pero qué demonios? Y después llegas y se lo explicas pero no mira que esto pero hasta que nos cogen y se equivocan y entienden el porqué sobre todo el entender el porqué porque se lo puedes volver a explicar lo pueden cambiar pero como que no se convencen ¿no? Cuando ya es ese momento de ¡paf! Me he estallado y he entendido el porqué y el porqué esto es un problema hasta ese momento

[No identificado] (01:05:26): No lo pillas tío

[No identificado] (01:05:29): Es maravilloso si se aprende a base de hostias ¿no? Literalmente literalmente y sobre todo yo tengo que confesar que

[No identificado] (01:05:38): Soy un poco escéptico ¿no? A mí me gusta ponerlo todo a prueba y ver y hasta que no me pego el golpe grande es decir ostras me equivoqué entonces por eso yo creo que es muy importante probar a ver obviamente no no vamos a hacer camicas y vamos a decir uy tenemos un cliente vamos a probar en su proyecto no no no no por eso es tan importante tener un pet project hacer cositas dejarlo un tiempo dos años después retomarlo intentar hacer cambios con lo nuevo que has aprendido y decir ostras pues aquí me equivoqué por esto y vas aprendiendo así ¿no? Obviamente por favor

[No identificado] (01:06:10): Que nadie haga esta locura de coger un proyecto de un cliente y decir vamos a experimentar porque al final no no no ni de coña pero hay una cosa que dice Carlos que a mí me resuena es si tú fueses el cliente ¿pagarías por eso?

[No identificado] (01:06:26): Efectivamente efectivamente así que nada pues no lo hagas efectivamente efectivamente estoy totalmente de acuerdo estoy totalmente de acuerdo ay tío que bueno es hablar contigo es maravilloso maravilloso ay se me quedan cosas de gente entera que quiere hablar pero bueno no todavía tenemos tiempo yo nunca he puesto límite al tiempo que vamos a estar aquí o sea lo que quiera lo que quiera pues mira si quieres una última cosa interesante ahí que tenemos también en back que está guay y bueno es algo que no sé si se verá mucho por ahí o ni idea por lo menos en todo el ecosistema

[No identificado] (01:07:00): De no de no lo veo que que es con el tema de inyección de dependencias y tal al final cuando lo tienes bien montado eh es fácil cambiar una dependencia por otra ¿no? Entonces una cosa que tú tienes en en Nest cuando vas a hacer un test la parte de test es en tu end de Nest que no es en tu end o sea bueno habría que definir lo que es este test en tu end ¿no? Sí pero

[No identificado] (01:07:23): Es test a API ¿no? O sea hace un como si fuera un fetch consume a la API ¿no? Y te vuelve ¿no? Tú puedes instanciar ahí el backend y puedes sobre escribir las dependencias que quieras ¿no? Sí bueno nosotros una cosa que hacemos es cuando tienes que desarrollar algo nuevo te escribes un test de esos ¿no?

[No identificado] (01:07:40): Y tenemos dos formas de lanzar los test en tu end uno es como una variable de entorno que lo que hace es que cambia todos los test o sea cambia todas las interfaces de de los repositorios a repositorios que son en memoria funcionan igual pero internamente usan un array literalmente ¿sabes? Hacen un push a cosas que hay ahí en un disk y ya está ¿no? Es una implementación de repositorio pero local en código ¿sabes? A nivel de memoria sí y después tú tienes otra implementación que es de SQL o lo que sea ¿no? Pues lo que haces es que esa feature la desarrollas

[No identificado] (01:08:11): Usando ese lanzamiento con esa variable en torno apuesta ¿no? Y lo guay es que los test se tiran súper rápido ¿no? Los end to end sí puedes hacer eso pues outside básicamente ¿no? Te picas un test en tu end que te replica todo lo que tú quieras ¿no? Y después ya vas hacia adentro ¿no? Pero puedes hacer bastante testing de ese lo tiras muy rápido ¿no? Porque no tienes ni que tener el docker subido ni nada ¿no? Porque al final estás usando esta implementación ¿no? Claro y lo guay es que ese mismo test te sirve porque después cambias a ver el entorno y se tira

[No identificado] (01:08:38): Contra la base de datos de verdad ¿sabes? Vale y usas una base de datos de verdad y pillas pues si estás insertando algo nulo en una columna o cualquier cosa pues lo puedes pillar por ahí eso no quita que le hagas test al caso de uso y le hagas test unitarios también bueno de integración a la implementación de SQL del repositorio ¿no? Claro claro claro claro pero está súper guay poder hacer así como rápido ¿no? De tener el la implementación de memoria para poder tirar los test así bum bum bum bum todo el rato ¿no? Que tienes el feedback loop ahí súper fresco ¿no? Sí

[No identificado] (01:09:10): Y vas para adelante ¿no? Sí y lo otro el problema que tiene esto son los test en tuel que son un poco chungos de escribir ¿no? Es una recusa la API y todo eso ¿no? Sí y entonces una cosa que estamos haciendo que está interesante es que tenemos un cliente de la API como si fuese una librería ¿sabes? Vale entonces tú por ejemplo puedes pues instancias tienes una clase que se llama el test client ¿no? Sí esa clase las instancias ¿no? Y por debajo usa super test y toda la movida ¿no? Toda esa maquinaria pero desde el punto de vista del test

[No identificado] (01:09:39): Tú lo que ves es new test client ¿no? Y haces API punto create user fulanito de tal

[No identificado] (01:09:48): API punto update payment method ¿no? Y así un par de cosas ¿no? Y puedes interactuar con la API no mediante los endpoints sino como si fuese una librería directamente ¿no? Vale y esto está super interesante ¿no? Porque después incluso puedes hacer agregar comportamiento ¿no? Imagínate que para un test yo necesito un usuario que está registrado con su perfil puesto con su método de pago puesto y confirmado el método de pago ¿no? Son como cinco cosas previas al test que puedes poner las cinco seguidas ¿no? O te creas un método específico en ese test client que dice oye usuario registrado con método de pago ¿no? Sí

[No identificado] (01:10:24): Y ya con eso lo tienes ¿no? Claro y eso hace que los test en Twin queden como super super limpios ¿no? Y con el foco muy bien puesto en lo que tienes que intentar testear ¿no? Y los otros que van super rápido la verdad o sea con el tema de memoria van bastante rápido ¿no? Ya con base de datos no pero con memoria sí ¿no? Me encanta me encanta esa idea tío porque si si somos puristas ¿no? Y empezamos a hablar un poco de hecho lo comentaba Robert C. Martin en el libro de Clean Architecture de postergar decisiones técnicas o sea

[No identificado] (01:10:55): Este approach que estáis siguiendo es muy bueno porque

[No identificado] (01:11:00): ¿cómo te decantas? Porque ¿qué base de datos vas a utilizar? Si ni siquiera sabes cómo va a ser tu dominio ¿no? Tú empiezas la aplicación de cero empieza y hasta que no sabes cómo son el tipo de de interacciones que tiene tu dominio con la base de datos no sabes por cuál decantarte si una SQL una no SQL si necesitas caché si no necesitas caché entonces el poder tirar directamente de la raíz en memoria para hacer esas pruebas y postergar la decisión de la implementación del repository maravilloso o sea es como yo sé que en algún momento esto me va a tener que devolver algo

[No identificado] (01:11:33): Y tienes unos test yo no los llamaría en tu end como tal porque al final sí que es verdad que estás quitando esa parte de base de datos por un mock pero sí que es verdad que a raíz de esos test de integración vas a sacar tus test en tu end cuando cambies una variable porque sí que van a atacar tu base de datos está bastante curioso y además que cuando tomes esa decisión y hagas el switch de la variable

[No identificado] (01:11:57): Ya vas a tener esa decisión tomada y vas a ver que estás escribiendo en una base de datos o en un fichero o vas a poder decir oye pues es mejor esta base de datos esta no está muy guay me gusta ese enfoque me gusta ese enfoque sí son dos patas una es de los test en tu end poder tirarlos con ese switch que puedes tirar contra memoria contra base de datos eso es interesante y lo otro es lo de tener un cliente de la API solo para testeo nada más está súper guay además a mí me gustan mucho ese tipo de test

[No identificado] (01:12:25): Porque son muy caja negra no tienes que el problema que tiene un test unitario sobre un caso de uso es que si cambias el modelo cambias el agregado le quitas atributos le pones atributos te van a romper algunos test depende de cómo lo tengas puede interrumpir algunos el test en tu end acepta en caja negra interactúa con la API pues puedes cambiar hasta los agregados puedes cambiar hasta el dominio que te da un poco igual claro entonces bueno está interesante esa parte el problema es que yo ni siquiera sé qué definición ponerse de ustedes porque en esos test que nosotros llamamos en tu end

[No identificado] (01:13:00): Pero no sé ni qué nombre tienen nosotros moqueamos todos los que son terceros pues por ejemplo todos los que son terceros impuros en el sentido de por ejemplo el stripe lo podemos tirar pero en modo sandbox

[No identificado] (01:13:12): Pero preferimos no tirarlo para nosotros consumiendo de la API a ellos siempre a la intención y usamos un mock ahí pero también otros terceros así pues los tenemos moqueados y el único que tenemos ese switch es el de la base de datos y realmente consume la API pero son test tan limpios tan pequeños y van rápido en general que no sé si se consideran test en tu end y yo lo único que he encontrado sobre esto es una cosa que se llaman test unitario sociable vale que lo que hace es justo eso pues interactúan como con varias cosas ¿sabes? Sí registran un usuario

[No identificado] (01:13:43): Hace no sé qué hace no sé cuánto y una última ¿no? Integran varios casos de uso es un test unitario sociable por lo visto que no he leído del tema tengo que informarme más pero está interesante la verdad porque lo que me pasa es eso que o hemos encontrado o sea haciendo solamente test unitario en los casos de uso pillas errores pues de comunicación de uno a otro que uno escribe una cosa de otra a otra entonces el tema de tirar los test estos así que tenemos pues nos da mucha mucha confianza la verdad sobre todo confianza vale no o sea me llama la atención

[No identificado] (01:14:13): O sea por sacarlo un poco a colación ¿no? Me llama la curiosidad que los llaman test unitarios sociables porque al final sí, sí o sea no son unitarios o sea estás probando varias capas al mismo tiempo entonces por definición muy unitario no es de hecho no es es que estás testeando varios casos de uso atravesando varias capas encima ¿sabes? Estás testeando varios casos de uso y varias capas porque pasas por el end to end pasas por el controlador llamar caso de uso sí es verdad que no llega a la base de datos pero puede llegar con con el switch este ¿no? Que tenemos

[No identificado] (01:14:45): Sí, sí, sí sí, sí suena curioso y creo que es una una buena línea de estudio ¿no? Porque al final sí quitando el tema del nombre sí quitando el tema del nombre que al final son las etiquetas de siempre que queremos etiquetar todo de no, esto es unitario esto es integración ok, vale venga sí como quieras llamarlo pero creo que es una buena línea de investigación porque al final seamos realistas siempre lo que más nos cuesta a todos son los tests en tu end que dice ¿cómo los pruebo? ¿dónde está la línea? ¿qué considero en tu end y qué considero integración? Porque unitario sabemos que

[No identificado] (01:15:23): Unitario es unitario no hay más es la clase o el fichero que tienes delante y que sus dependencias o las omites o les creas un mock pero ya está entonces no hay que reinventar la rueda esa parte sí que está muy muy mascada pero con respecto a lo otro creo que es una buena línea para sí, incluso hay varios nombres en la industria a mí el que me gusta pues un poco son los que dicen Codely en Codely tienen los tests unitarios sobre casos de uso sobre sobre el propio dominio sobre agregados o lo que sea test unitarios sobre esas cosas después tienes

[No identificado] (01:16:01): Test de integración que son probando un adaptador concreto contra su implementación por ejemplo UserRepositoryMaiSQL eso tiene un test que comprueba que está bien implementado o

[No identificado] (01:16:14): PaymentWallStripe eso es el test que está asociado a esa clase es un test de integración y después el test en tu n es mucho más para afuera que aquí es donde se desdibuja un poco yo entiendo que es algo más tipo o tipo Gherkin o un Selenium o algo así que ataca más desde fuera afuera de verdad o al propio contenido de este broker exacto y que llega hasta el final total y ya no prueba con cosas moqueadas sino que prueba con cosas de verdad 100% claro eso es como yo lo entiendo yo por eso también te digo y por eso se dice siempre

[No identificado] (01:16:45): O sea que los test en tu n en cuanto a tiempo en cuanto a infraestructura y en cuanto a complejidad y en cuanto a feedback también son más lentos por eso no te renta tener muchos test en tu n o sea te renta tenerlo sí para asegurarte que todo funciona pero las particularidades del dominio lo pruebas de forma de integración o lo pruebas de forma unitaria pues son son los casos ¿no? De lo otro yo por ejemplo en un entuen no quiero probar que todos los casos que se dan en la UI al detalle de no es que si hago estas combinatorias

[No identificado] (01:17:20): Esto se tiene que ver así y si tengo estas combinatorias se tienen que ver de esta otra forma tío eso son integración unitarios pero en tu n de verdad quieres tener una máquina que tarde un minuto y medio en darte feedback para probar esos casos cuando puedes cubrirlo con un test unitario de integración no tiene sentido lo pones en la balanza y dices oye ¿qué me va a dar feedback más rápido? ¿esto o esto? Esto obviamente el test en tu n lo vas a tener que tener pues para ahorrarte sorpresas pero no necesitas probar todos todos los casos si ahí por eso te digo

[No identificado] (01:17:56): Los test estos que estamos haciendo nosotros donde tenemos todo moqueado y la base de datos a veces sí a veces no no sé en qué línea quedan si lo miras como la pirámide de testing

[No identificado] (01:18:06): Realmente estos test son test que van muy rápido o sea sobre todo cuando van en memoria cuando van contra base de datos un pelín más lento pero tampoco es que sea una locura y

[No identificado] (01:18:19): Y son baratos y fáciles de leer ¿sabes? Baratos en el sentido de eso de que tú lo lees y como tenemos lo del cliente de testing este son súper fáciles de leer y no no dan mucho problema ¿no? Entonces son como un entuendo está como en la barrera de para mí sí como entre unitario y entuendo un rollo así ¿sabes? Lo cual es que nos da mucha seguridad eso para mí es lo importante ¿no? De que tengas confianza de que el código que está subiendo pues va bien y sobre todo el feedback loop tío eso es va a estar rápido y no implementas

[No identificado] (01:18:49): Nada de los modelos te olvidas de la base de datos va todo outside in ¿no? Perfecto tal y cuando ya terminaste de implementar todo lo que tenías que implementar venga pues hago el test unitario de la base de datos tal y cuando yo termine de implementar lo de la base de datos puedo tirar el mismo test que hice de memoria con base de datos y debería pasar ¿no? Si la he cagado pues no va a pasar pero eso es lo guay ¿no? Que tenemos mucha seguridad en ese sentido nos da mucha confianza estoy totalmente de acuerdo al final la importancia de los test

[No identificado] (01:19:16): Es que te den feedback y que te vayas a dormir tranquilo por la noche sabiendo que que todo funciona y lo otro es un posturio de no esto es end to end esto es un integration test o sea no de hecho a ver si te soy honesto bajo mi punto de vista en tu caso son end to end cuando la variable de entorno la tienes a tirar de la base de datos real y son de integración cuando la variable de entorno la tienes a tirar de los mocks pero ya está o sea que me da igual funciona si es una solución viable si está implementada

[No identificado] (01:19:50): Y te está dando seguridad y feedback si si falla algo te lo va a cantar pues ya está a mi me vale como si lo quieres ya darle un nuevo nombre que sean variable end to end integration super amazing power mock test o sea me da igual lo malo como quieras que mientras que cumplan su función a mi me vale y me parece super buena idea la verdad porque todo lo que tiene que cumplir un test lo hace y todos los enfoques de desarrollo que se vienen comentando con respecto a arquitectura de postergar decisiones de poder hacer outside in de inyectar además las estás cumpliendo

[No identificado] (01:20:26): O sea para mi es perfecto es perfecto me encanta a ti no sé lo que estoy haciendo pero me está funcionando efectivamente o sea no a ver si sabes lo que estás haciendo lo que no sabes es cómo etiquetarlo pero oye eso sí nueva línea de desarrollo pues me mola y ya esto un poco por curiosidad ¿no?

[No identificado] (01:20:47): ¿cuánto cuánto tiempo o cuánto esfuerzo vamos a decir esfuerzo más que más que tiempo ¿no?

[No identificado] (01:20:55): ¿les ha llevado el poder parametrizarlo de esa forma o llegar a esa solución? No mucho tío no mucho porque realmente al final

[No identificado] (01:21:05): Lo que tú tienes o sea creo que a ver deja pensarlo

[No identificado] (01:21:11): No mucho no mucho porque al final NEST tiene su sistema de inyección de dependencias ¿no? Y tú lo que haces es override de determinadas dependencias ¿no? Pues literalmente tenemos un if esta variable de entorno está activada haz override de todas las dependencias de base de datos ¿no? Y ponlas de memoria ¿no? Y ya está realmente ya con eso pues el test en tu end lo tiras o no lo tiras y ya está ¿no? Y encima como esa construcción del servidor esa construcción ese ensamblamiento del servidor con todas sus entidades perdón con todas sus dependencias

[No identificado] (01:21:44): Y queda contenido dentro de ese cliente que te he estado comentando ¿no? Que tiene los métodos para poder consumir la API pues queda todo ahí aislado ¿sabes? Y queda bastante limpio ¿sabes? Desde el punto de vista del test tú ves que tienes un cliente de la API y le haces API punto y lo tienes ahí todo ¿no? Register user update client o lo que sea ¿no? Y vas atacando con eso ¿no? Encima ¿sabes otra cosa curiosa que también tenemos? Es que los fixtures tenemos fixtures ¿no? Sí y esos test que bueno tenemos como usuarios modelos ¿no? Dentro de lo que es hacer un user personas

[No identificado] (01:22:19): ¿no? Que tienes a Paco que es el tío de la tienda ¿no? Y Paco pues tiene dos hijos no sé qué haces un user personas ¿no? A nivel de diseño ¿no? Y ese user personas lo puedes trasladar a código a nivel de fixtures ¿no? A nivel de fixtures sí entonces también tienes a Paco que tiene un email que tiene un nombre que tiene un teléfono ¿no? Y esos son los datos por defecto que tiene el cliente de test de la API ¿no? Entonces nosotros sabemos que si es un si yo tengo que hacer algún test que involucra a un usuario que tiene el rol

[No identificado] (01:22:51): De dependiente de la tienda yo por el user personas sé que ese es Paco ¿no? Y siempre es Paco claro ¿sabes? Claro entonces personificas mucho los test y eso está súper guay eso está súper guay sobre todo cuando tienes como cinco roles con tú dentro de de lo que es la aplicación sí ¿no? Y siempre sabes que tienes como una convención de que Paco siempre es la persona que hace esto después tenemos a una persona que no se llama Paco sino que se llama no sé qué que es el que rompe la API y el que intenta el atacante ¿no? O es If ponle tú

[No identificado] (01:23:22): ¿no? Llamas a If ¿no? Y entonces If tú dices que es la persona que intenta siempre atacarte en plan romperte y crear una reserva en los tiempos que no puedes o intenta atacarte sin un JSO web token o este tipo de cosas ¿no? Qué bueno entonces el tema de personificar los test con personas dentro de un user persona está súper guay y encima esos datos los puedes poner en los decoradores del Open API y te quedan ahí todos los datos de los endpoints pues con ejemplos casi reales claro está súper guay está súper interesante y además a nivel de domain driven design

[No identificado] (01:23:55): Te encaja muy bien por el tema de los actores ¿no? Que te dicen que siempre personifiques que apliques claro que te den un ejemplo de storytelling claro claro claro claro me mola mucho esa idea tío entonces literalmente en un test en tu end tú tienes API.registerpago API.añadele un método de pago a Paco o si no pones nada sabes que por defecto ese ejemplo le ataca a Paco entonces pues no puedes si quieres ni poner nada ¿sabes cuál es el mayor problema de eso? Que cuando le des el nombre a la persona que la lía siempre al par de semanas te entre al equipo

[No identificado] (01:24:29): Alguien con ese nombre y ya te imaginas es que sabes lo divertido que nosotros ponemos a gente de la empresa ¿sabes? En plan ostras ponemos a a Jaume o lo que sea y ese es el que rompe la lápida

[No identificado] (01:24:41): Sí sí sí para las risas ¿no? Sí sí sí lo bueno es que ellos nunca verán digo

[No identificado] (01:24:49): Y es literalmente un official para nosotros o sea es un const Paco todo mayúscula ¿no? Igual y un correo un nombre tal todo ahí en un objeto ahí ¿no? Y esos objetos los puedes consumir desde los endpoints ¿no? O sea los endpoints todo el body por defecto tiene valores que tiran de ese fixture ¿no? Sí sí sí eso está súper guay la verdad que a mí me gusta mucho eso ¿no? Me ha molado mucho la idea yo creo que esto es súper constructivo y que lo voy a empezar a poner lo voy a empezar a aplicar bastante me mola me mola me mola porque además

[No identificado] (01:25:23): Vuelvo a lo mismo o sea es de libro ¿no? Son estas cosas que tú dices de lo que hablábamos antes justo de las demos coño pero si al final lo que coges del libro y te lo lees lo que te está diciendo eso y es justo lo que no estás aplicando cuando lo estás haciendo dale un nombre aplícanlo a los test que puedes hacerlo qué buena idea qué buena idea no lo había visto antes y creo que va a aportar muchísimo voy a probarlo y dentro de un par de episodios te doy feedback te doy feedback a ver qué tal de hecho te traeré

[No identificado] (01:25:51): De nuevo te traeré de nuevo y diré episodio número

[No identificado] (01:25:57): Daniel está de vuelta por aquí

[No identificado] (01:26:01): 36º 34º no no esperemos que antes pero te traeré y te daré feedback en plan de oye mira pues lo he estado probando y me he encontrado estas cosas y bien y no bien y tal y molaría mucho molaría mucho sí y ahí lo último que yo quiero investigar que no pues no he tenido tiempo todavía es que ahora mismo tenemos eso api.registeruserpaco api.no sé qué tal estaría guay que también fuese como en el otro sentido que pudieses hacer Paco.createreservation Paco.hacer no sé qué ¿sabes? Y que puedas consumir la api bueno me parece bien que puedas consumir la api como api.as cosas ¿no?

[No identificado] (01:26:40): Pero también puede estar guay que personificas la api desde el punto de vista de alguien ¿sabes? Claro es Paco el que interactúa con la api ¿sabes? Y Paco es el que crea la reserva en la api ¿sabes? Claro entonces ese tipo de test también quiero darle una pensada a ver cómo se puede plantear todo eso

[No identificado] (01:26:59): Podemos sentarnos fuera de directo un ratito y jugar con eso yo creo que está gracioso me estás metiendo el veneno en las venas como siempre da gusto porque terminas de hablar con Dani terminas de hablar con Dani y dices bueno pues creo que voy a estar dos semanas sin dormir porque me ha metido veneno y ahora lo que quiero es quitarmelo haciendo cosas si ahí bueno cuando terminemos esto tenemos el bullet plate donde tenemos un ejemplito de esto así que si quieres te lo puedo enseñar ahí para que lo veas a nivel de código perfecto mientras que no esté hecho en brainfuck como el video

[No identificado] (01:27:31): Que tenemos subido en youtube yo encantado es mi meme personal o sea es mi meme me hice un intérprete de brainfuck bueno puedes decir eso bueno no me hice no lo hicimos lo hicimos es decir que lo hicimos de hecho fue más cosa tuya que mía

[No identificado] (01:27:49): Estuvo divertido si si si además fue en esta misma silla sin el mismo setup pero en esta misma silla si si si yo estaba bien lado realmente bueno yo sé que no estás ahora mismo no estás en tu casa estás grabando en casa de tus padres por facilitar un poco el tema del audio el micro y tal pero creo que una de las cosas que le puede interesar también mucho a los oyentes es el hecho de decir cuál es tu setup qué consideras tú indispensable a la hora de programar de sentarte a desarrollar y decir oye mira si yo necesito trabajar para mí es indispensable

[No identificado] (01:28:26): Esto

[No identificado] (01:28:28): Pues no sé yo bueno yo creo que es un monitor grande más que o sea bueno grandillo por lo menos ¿sabes? Porque cuando estoy con el portátil por ahí puedo programar a gusto ¿no? Pero sobre todo en el webstone que estoy usando el webstone madre ahora

[No identificado] (01:28:43): Desde que abro la base de datos con la terminal con el director de fichero se me queda como un cuadradito así enano para ver el código nada más ¿no? Sí entonces primero que nada tener un monitor más o menos decente ¿no? Sí y después bueno ya puesto un poco lo típico ¿no? Tener una buena silla buena postura al sentarte si puedes si tienes un standing después mejor incluso ¿no? Y si te puedes poner de pie ¿no? Ahí yo de lo que tengo realmente bueno pues tengo una silla ahí que está bien ¿no? La típica la Marcus esta de Liquea ¿no? Sí

[No identificado] (01:29:11): Y standing desk no tengo pero bueno la plancha va bien la tabla de planchar es genial esa la hemos usado mucho esa la hemos usado mucho recomendación de Sosa sí sí sigue funcionando y sigue funcionando yo te diría que cuando tienes un standing desk y lo usas que eso es importante y lo usas ya el tema de la silla no importa tanto pero estoy totalmente de acuerdo contigo o sea ahora mismo nosotros por temas de seguridad y demás estamos trabajando sobre una sobre un escritorio remoto ¿vale? Claro que guay bueno bueno a ver el mayor problema y por el cual he cambiado de pantalla

[No identificado] (01:29:53): Ahora mismo ahora mismo tengo una ultra wide es precisamente porque ese escritorio remoto solo se veía en una de las pantallas no me permitía ponerlo en dos y partirlo y demás o sea solo me pillaba un monitor entonces de los monitores que tenía era como si estuviese literalmente en una pantalla y me mataba yo lo imaginaba más romántico porque una de las ideas felices que a mí me gustaría implementar algún día lo que es caro es el tema porque yo tengo el M1 el Mac ¿sabes? Que consume súper poquito eso es lo para mí es lo mejor que tiene esa máquina que consume

[No identificado] (01:30:26): Es una pila ¿no? Pero aún así cuando tiras test y todo el rollo pues ya consume más y va bajando ¿no? Que me dura un montón igualmente pero una cosa que puede ser interesante abres una máquina de una AWS o lo que sea y abres el VS Code en remoto ¿no? Eso y claro todo ese consumo se lo traga la máquina de AWS claro pero es tu interfaz en este caso no yo te estoy hablando de escritorio remoto físico ventana vale vale vale oye pensaba que decías el VS Code en remoto o algo así ojo cuidado que son unas máquinas brutales o sea

[No identificado] (01:30:57): Tienen sus 32 GB de RAM sus procesadores tocho o sea todo muy bien y la idea es que eso esté securizado el problema que tienes ahí es la latencia y eso que da igual que al final como es una ventana las ventanas no puedes ponerlas en varios monitores sino solo en una entonces al final es como volver otra vez a a mí me agobia un montón sobre todo me pierde mucho porque ya es el tema de espérate acabo de clicar en mi máquina tenía que haber clicado en la máquina remota en la máquina remota abrí el Intel y tengo que cambiar al WebStorm

[No identificado] (01:31:29): Ahora tengo que irme al navegador y vas perdiendo el tiempo o sea la productividad que tienes baja muchísimo baja muchísimo pero bueno ahora mismo estoy contento he pillado una ultra guay y es como ahora es como tengo ahora me sobra espacios como tengo el Intel y el WebStorm el navegador y la base de datos y tú pero si la base de datos la puedes tener en Intel da igual me sobra pantalla para adelante y después la pantalla del portátil la llamada

[No identificado] (01:31:59): Está bien está bien qué te iba a decir yo y quería preguntarte otra cosa más porque bueno sé que hasta hace poco habías estado trabajando físico en oficina ¿verdad?

[No identificado] (01:32:12): Ahora has vuelto al remoto

[No identificado] (01:32:16): ¿lo confirmamos? Sí, sí, sí o sea te cuento un poco la historia bueno quería lanzar primero la pregunta pero si quieres cuéntame y después te lanzo la pregunta no, no hace la pregunta vale

[No identificado] (01:32:29): No, cuéntame venga queda mejor que me lo cuente y después lanzo la pregunta vale, te cuento pues realmente eso cuando yo entreno en el Assy Tango uno de los ellos estaban en físico bueno, estaban en físico en Madrid yendo a la oficina ¿no? Y la idea era abrir una oficina aquí en Tenerife y empezar a contactar a la gente aquí en Tenerife bueno, pues a mí mi solución es el proyecto este y por eso me cambié para allá y bueno pero sí es verdad que empezamos en oficina teníamos el tema de obra flexible y podíamos trabajar algún día de casa o lo que sea

[No identificado] (01:32:57): Pero no era normal de normal íbamos a oficina y bueno, bien pero al final lo del remoto también está muy guay entonces bueno entró lo del COVID y al final pues empezamos a ir hasta en el remoto ¿no? Pero pensábamos que íbamos a terminar volviendo a la oficina ¿no? Sí pero al final se alargó mucho lo del COVID y ya al final pues casi que sobre todo cuando ya terminó de pasar íbamos a la oficina una vez a la semana dos veces por semana o algo así ¿no? Sí que bien está guay ¿no? Pero al final teníamos la oficina un poco muerta de la risa

[No identificado] (01:33:26): Para que mentirte o sea íbamos de vez en cuando ¿no? Entonces bueno al final ya la última decisión que tuvimos es mira no estamos yendo a la oficina casi nunca de vez en cuando vamos los típicos para vernos y tal pero de normal casi que no va nadie ¿no? Sí y al final decidimos cerrarle y ya está ¿no? Entonces si nos tenemos que juntar pues pillamos un co-working o lo que sea ¿no? De hecho dentro de no sé si la próxima semana o la siguiente creo que es la siguiente que tenemos el All Hand ¿sabes? La reunión está así como a nivel de empresa ¿no?

[No identificado] (01:33:53): Y vamos a ir a un co-working allí en Horataba ¿no? Entonces de hecho igual veo hasta Iván y todo porque como está espero por allí creo puede ser igual igual les veo sí sí sí no lo veo descabellado pero eso sí si vas por lo menos pasen un buen rato y envíen fotitos de lo que vayan a almorzar porque sé que por ahí ya hay un par de sitios para comer que amigo mío amigo mío sí sí aprovecho pues y con el tema del remoto bien al final tú sabes que yo ya en lima estaba en remoto entonces bueno pues pues me adapté fácil ¿no?

[No identificado] (01:34:26): Y genial yo la pandemia la pasé súper bien empecé a estudiar rollos ahí de nutrición y no sé qué ¿te acuerdas? Sí que salíamos a caminar tío deberíamos de retomarlo en algún momento lo que no sé si se habrá visto en algún momento por pantalla probablemente sí que tengo las gatitas correteando por ahí y el problema mío es que claro son las dos me las trajeron después de la pandemia y se han criado conmigo entonces yo salgo de casa media hora media hora y cuando vuelvo a ver no me rompen nada pero las pobres están así en la puerta esperándome como

[No identificado] (01:34:57): ¿a dónde te has ido papi? Sí entonces me da un montón de apuro pero un montón o sea yo he dejado de salir un montón de todas esas caminatas que yo me pegaba que domingo primero era la mañana me voy de aquí yo qué sé a la esperanza caminando y vuelvo o me voy de aquí a al rayo me tomo un café allí y vuelvo todo eso lo he tenido que dejar porque me da mucha cosita que las pobres estén aquí pero bueno la vida la paternidad eres un papagato ahora sí tío ya tienes responsabilidades me están saliendo los bigotes y todo ya

[No identificado] (01:35:35): Sobre todo te lo preguntaba todo esto por

[No identificado] (01:35:40): Por el tema del audio tío es un tema que me gustaría tocar

[No identificado] (01:35:44): Cómo o sea al trabajar en remoto cómo te afecta a ti

[No identificado] (01:35:49): En tu setup el tema de la comunicación los cascos el micro la cámara te llega a afectar o es algo que no notas quiero decir cuando hablas con alguien te incomoda que tengas malo creo que lo más complicado así a nivel de remoto es cuando hay 10 personas en una llamada y ahí se abre un debate o quieres o quieres abrir un debate en remoto es un poco complicado porque cuando estás en presencial no pasa nada uno se puede interrumpir a otros o elevar la voz o lo que sea que al final es un debate mucho más orgánico en remoto tienes que controlar

[No identificado] (01:36:23): Eso muy bien y moderarlo porque si no al final se cruza el audio no es que se cruza el audio sino

[No identificado] (01:36:31): Que escuchar dos personas a la vez en llamada es una locura no coges a uno y a otro en físico sí porque en físico pues tenemos las orejas que tenemos que nos permiten instiguir las dos personas aunque estén a la vez pero en remoto eso es lo único que veo ahí un poco chungo a nivel de trabajo día a día sin problema o sea

[No identificado] (01:36:49): Estoy usando el micrófono de portátil porque va bien la verdad y los cascos tengo los sony estos que tienen el tema del aislamiento de ruido y tal que van bien también y poco más de resto bien menos el gato bueno que de vez en cuando me hace algo a mí también me tira algún plato se rompe y digo madre mía de resto vamos bien no pero esas cosas son normales cuando tienes animales en casa es inevitable que en algún momento te salga un miau que aparezca una cola por en medio de la pantalla que te haga alguna araña así pero nada son súper buenos no

[No identificado] (01:37:22): Y ahora mismo estás trabajando con gente en inglés o en español en el proyecto en el que estoy no en el proyecto en el que estoy estoy hablando de español si es verdad que obviamente todo el código va en inglés todo eso típico en inglés pero a nivel de comunicación es todo en español si bien si es verdad que hay proyectos que son internacionales que yo no estoy metido pero si hay que hablar en inglés ahí de hecho es una cosa que tenemos que exigir sí o sí cuando entra alguien en la empresa que tenga un mínimo de inglés porque es que te puede caer

[No identificado] (01:37:53): En un proyecto en el que tengas hablar en inglés u otro que no es muy raro eso vale ahora cuento el porqué venía esta pregunta o sea realmente el tema del setup y tal pues estoy como tú o sea con tener una pantalla grande un teclado pues que te permita trabajar y que no te dé problemas de muñeca y tal pero no es en lo primero que invertiría sino en eso vamos a tener un monitor vamos a tener un equipo que me permita trabajar bien pero sí que es verdad que cuando trabajas en remoto nosotros ahora mismo somos tres personas de LeadMind que están integradas

[No identificado] (01:38:27): En un equipo internacional hay gente de Rusia hay gente de Ucrania literalmente hay gente de Israel hay gente de Alemania y obviamente eso solo puedes hablar en inglés cada uno con sus acentos muy particulares entonces una de las cosas que hemos empezado a valorar muchísimo pero muchísimo es el tema de los micros ! Los cascos igual no tanto

[No identificado] (01:38:54): Pero los micros sí porque cuando hablas hay reverberación hay eco cuando tienes videollamadas haciendo peirin con eso es horrible y sobre todo si ya son más como tú decías cuando ya es una conversación más abierta con más personas es imposible es imposible porque se empieza a nosotapar ruido no sé qué cuando es tu idioma nativo mal que bien pero cuando es un idioma que no es el tuyo nativo es horrible y por eso el tema de los cascos al final te acuerdas que te pregunté cuáles tenías y tal me acabé pillando estos son los Logitech Light Speed no los que teníamos antes te acuerdas

[No identificado] (01:39:33): Que tenían un problema de fabricar el botón a todo el mundo les ha pasado lo mismo con ese botón si te sirve de algo pero estos me han salido buenísimos y sobre todo por el tema de escuchar de poder quitarme un poco ese tema del ruido y tal porque si no es imposible o sea tú sabes que yo nunca he sido un pro del inglés pero ahora mismo me pego ocho horas hablando en inglés al día y

[No identificado] (01:39:57): Sin un buen equipo de audio es horrible sería imposible imposible imposible yo sobre todo a nivel de escuchar bueno puedes tener unos cascos que sean más sofisticados menos sofisticados que más o menos lo vas a entender bien pero sobre todo yo creo que lo que más es no solamente el micrófono sino que se te escuche bien sabes porque hay gente que tiene el micrófono que te cagas el ¿cómo se llama? El blue este fantástico ¿no? Pero lo tienes al lado del teclado ¿sabes? Y se escucha y es como tío vale tienes un micrófono que hay al lado pero no me lo pongas

[No identificado] (01:40:29): Al lado del teclado a ver realmente no sé si te has dado cuenta pero yo en ningún momento he tocado el teclado pues precisamente por eso tengo que comprarme un bracito para el tema del micro porque si no bueno de hecho cada vez que clicase se oiría en el micro es un poco incómodo claro es lo único y no solo eso sino también también para mí es eso ¿no? Que el tema del teclado o las vibraciones que pueda haber que afectan al micro y también la reverberación ¿sabes? Que te has en una en una habitación ahí que no tiene ni un mueble

[No identificado] (01:41:01): Y parece que estás dentro de una iglesia ahí súper incómodo escuchar ahí ¿sabes? Como al principio pero bueno total total

[No identificado] (01:41:10): Pues pues sí es que en verdad con que tengas una librería o eso un sofá o cualquier cosa ahí que más o menos absorba el sonido no hace falta que te pongas espumas ni nada de esto ¿sabes? Nada con tener un par de cositas ahí y el micrófono que sea más o menos decente ¿sabes? Tampoco hace falta uno súper sofisticado ahí de estudio ni nada sino yo qué sé con 20 o 30 euros seguro te pillas un micro ahí que más o menos tira bien los hay los hay que de hecho ya el otro día estuve mirando bueno estuve mirando de una casualidad

[No identificado] (01:41:40): De que pasé por al campo y vi que ya tenían sus micros con sus filtros y todo y tal y de precios 20 euros y tú dices a ver pues realmente dependiendo de para lo que lo uses pero para lo que lo usamos nosotros comúnmente no digo para grabar el podcast pero para un uso común sí, sí para una videollamada para una videollamada que el zoom te va a comprimir el audio y tal igual no tiene ni sentido no, no, no, no totalmente o sea incluso muchas veces con los mismos que te vienen en los cascos ya te vale si funcionan bien ¿sabes?

[No identificado] (01:42:11): La cosa siempre es esa que tú no te escuchas a ti mismo que es el gran problema nunca te escuchas a ti mismo y no sabes cómo cómo lo van a sufrir los demás si no te lo dicen a mí me ha pasado de que no me escucho a mí mismo y me pongo a hacer cosas y se escucha por el audio o se escucha ellos escuchan al gato pero yo no lo oigo ¿sabes? Exacto exacto es maravilloso esos momentos donde dicen estoy escuchando al gato y tú ¿qué? ¿cómo? ¡ah! Que estás aquí

[No identificado] (01:42:38): Sí, sí, sí bueno bueno pues para ya cerrar quería hacerte dos preguntitas rápidas para quitar un poquito el freno y la seriedad al asunto entonces eh tienen que ser respuestas rápidas ¿vale? No te voy a hacer las dos preguntas de Broncano porque estaría feo quizás no quizás debería ser la pena no, no, no es broma vale entonces primera primera pregunta rápida Angular React View React

[No identificado] (01:43:08): Sin duda ¿JQuery? ¿JQuery? No ¿JQuery no? O sea pero vamos vale, vale, vale y después esta va con trampa vale te lo abierto que va con trampa monolito o microservicio monolito pero por mi caso de uso realmente porque teniendo unos copes más o menos cerrados mete microservicios y te va a hacer falta o mételos a posteriores pero así de priori es una complejidad que metas al proyecto que igual no hace falta bueno yo para mí no para mí monolito pero bien organizado de forma que si tienes que sacar un microservicio que te sea más o menos sencillo sí, sí, sí intentaremos

[No identificado] (01:43:43): La idea no es ver código aquí pero sí que hay varios ejemplos que podríamos hablar y hay estrategias a futuro de de cómo separar tu monolito a microservicios porque si no lo puedes hacer fácilmente es probable que el problema sea que no tienes bien definido tu dominio ahí tasca bienvenidos sean los haters que me van a llover a partir de este comentario

[No identificado] (01:44:22): Adiós por falta de experiencia creo yo o solo inside o solo inside o solo inside exacto pero ahora mismo outside estoy haciendo mucho outside me siento cómodo y sí que es verdad que hay momentos hay momentos donde he hecho inside y bien pero de normal y outside outside oye no yo pensaba que me ibas a sacar los colores pero era fácil vamos vamos de hecho ni medio segundo está bien está bien está bien que bueno que bueno pues tío que te digo ha sido un placer tenerte por aquí llevamos un buen rato creo que no voy a recortar absolutamente nada ha sido perfecto

[No identificado] (01:45:08): Tal y como ha sido lo siento si a alguien le parece una chapa pero creo que es súper enriquecedor he pasado un rato contigo brutal hacía tiempo que no hablábamos que no nos veíamos y para mí ha sido como tomarnos un café juntos tío lo echaba de menos lo echaba de menos mil gracias por estar aquí y ayudarme con este primer episodio espero que repitamos pronto sí repetimos repetimos y tío que decirte que muchas gracias también por eso por venir gracias a los oyentes por escucharlo aunque sea en diferido esperamos feedback esperamos que repitáis y bueno en la próxima igual hay sorpresitas igual hay alguien

[No identificado] (01:45:48): Hablando de serverless o cosas así vamos a ver si no me da por cambiar el orden y no surgen cositas pero nos vemos en el siguiente adiós

[No identificado] (01:46:05): No

[No identificado] (01:46:07): No

[No identificado] (01:46:20): No no no no no no no no no no no !

[No identificado] (01:46:28): No no !