Transcripción
- Audio: https://www.ivoox.com/devs-lives-10-cesar-alberca-la-artesania_mf_88958062_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:22): Bienvenidos a Devs Lives. Hoy cumplimos con la friolera de 10 episodios. Antes que nada tengo que dar las gracias a todos nuestros oyentes por haber estado aquí aguantándonos durante 10 semanas, por haber hecho posible este pequeño espacio donde compartimos unos breves minutos, a veces no tan breves, con personas de este sector donde nos cuentan su historia y sus incertidumbres. También donde creo que nos reímos bastante en líneas generales. Pasamos muy buenos ratitos, así que antes de nada dar las gracias a toda la comunidad por estar aquí, por apoyarnos cada semana y que sean muchos más.
[No identificado] (00:01:07): Y bueno, no solo por ello, vamos a celebrar el episodio 10 como merece. Hoy tenemos la suerte de contar con una persona que se describe a sí misma como desarrolladora de software, interesada en la arquitectura, interesada en TypeScript, interesada en las buenas prácticas. Pero no es ya tanto como se describe, sino lo que significa para mí. Tenemos la suerte de contar hoy con un gran amigo que nos va a apoyar en este episodio número 10 como merece. Bienvenido, César Alberca. ¿Cómo estás?
[No identificado] (00:01:41): Muchas gracias. Aquí estamos. Con mucha suerte de poder participar en esta iniciativa que ya 10 episodios y los que quedan todavía. Así que enhorabuena y por muchos más. Eso espero, eso espero. Y que pueda contar con vosotros para repetir muchas veces porque… Ah, bueno, eso no hay problema. Vamos, yo quiero aquí a la gente de bien fichada para hablar porque parece que no, pero siempre compartir estos ratitos con vosotros, pues no sé. Lo primero, siendo egoísta, es que yo me divierto, me lo paso bien y aprendo. Y lo segundo es que dejamos un montón de pildoritas para la comunidad y lo pasan bien.
[No identificado] (00:02:22): O sea que al final es un win-win para todo el mundo.
[No identificado] (00:02:26): Justo, justo. Y vamos, sí, yo con estas cosas también aprendo un montón y me llenan. Entonces es una gran iniciativa y un honor poder participar aquí. El honor, como siempre digo, el honor es nuestro de que dedicáis este ratito a pasarlo con nosotros y con la gente. Y es súper importante. Y sobre todo, bueno, que el tiempo no es… El tiempo es oro y siempre estamos a mil cosas. De hecho, hay que reconocer que nos ha costado un poquito tener este episodio funcionando. Pero, hey, aquí estamos. La ocasión lo merecía y aquí he estado. O sea que es maravilloso.
[No identificado] (00:03:11): Pues, César, no te vas a librar de la primera pregunta. Ya yo he hecho una breve intro sobre ti, pero cuéntanos. ¿Quién es César Alberca?
[No identificado] (00:03:21): Pues, sí, bueno, mi nombre es César Alberca. Trabajo en Autentia.
[No identificado] (00:03:28): Yo he hecho un poco de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo de tiempo
[No identificado] (00:03:52): Eso es eso eso es lo importante no aparentar pero bueno entonces un poco a raíz de que se me dio mal pues me puse un poco con el diseño y al final pues una cosa llevo a la otra y acabé haciendo pues un juego de preguntas con angular js ya hace un montón de tiempo y no me gustó y digo pues mira voy a probar con el módulo y nada ahí sí que verdaderamente me enamoré de la programación y ya vi que es que para programar hay que practicar no para aprender a programar
[No identificado] (00:04:22): Hay que practicar hay que hay que practicar y practicar no te vale solamente con la teoría no te vale solamente con leer escuchar podcast o ver cursos no sino que tienes que ponerte a programar no entonces a partir de ahí pues terminé el módulo empezar las prácticas en autentia y ahí llevo llevo ya tiempo y como el tema de la enseñanza siempre me ha gustado y siempre he querido enseñar a la gente como me hubiese gustado que me enseñasen a mí pues me metí en temas de profesor de un máster luego todo el tema de charlas que me
[No identificado] (00:04:52): Apasiona poder compartir conocimiento con la gente y nada entonces mi rol es un poco eso desarrollador de front he tocado también un poquito de android y nada también tema charlas enseñanza compartir y bueno por ejemplo nuestras iniciativas tan tan guay y luego también tema de eventos me gustó tanto que al final acabé en el comité de la codemotion así que nada ahí estoy revisando el call for papers y cosas así y bueno eso es un poco un
[No identificado] (00:05:22): Poco mi historia sé que al final eres una persona que está implicadísima en la comunidad las charlas revisas eventos siempre que puedes te apuntas a apoyar y a participar o sea que eres lo deseable en cualquier equipo no bueno espero que sí espero que sí pero bueno luego siempre pues aquí falta un punto y coma no aquí es un piso más a la derecha no esa figura de alguien también estricto alguien
[No identificado] (00:05:52): Obsesionado un poco con con con con que el código esté bien y tal también soy yo o sea que a veces quizás no sea tan deseable pero pero entiendo que a lo mejor sea lo bueno para para el proyecto no porque también lo mencionaba este tema de buenas prácticas arquitectura eso es algo que también me encanta pero también porque lo he hecho las cosas mal no he hecho cosas que digo ostras este código que he hecho haría vomitar una cabra no dice algún compañero mío
[No identificado] (00:06:19): Entonces como he hecho las cosas mal pues siempre intento aprender de mis errores y por eso me adentré en el tema de pues de las buenas prácticas arquitectura y demás y me apasionó y desde entonces también es algo que por lo que intento velar y para que se intenta pues pues bueno al final todo el tema arquitectura buenas prácticas es para poder aportar más valor a negocio no a nuestros productos y es una una forma de hacerlo no fue un poquito por ahí por donde nos conocimos recuerdo que fue a
[No identificado] (00:06:49): Aproximadamente en 2018 2019 ahora tengo la duda 2019 creo que bueno carlos carlos blé había estado unos días por autentia y demás había coincidido contigo tú estabas preparando una charlita para él para el gf canarias y y viniste un par de días antes y estuviste en la oficina y demás y la verdad es que fue conocerte y conectar enseguida porque todo ese conocimiento que no es poco la cultura a nivel de cómo piensas de cómo gestionas y de lo que te preocupa en el día a día como que yo tengo esa sensación que conectamos enseguida fue como
[No identificado] (00:07:31): Guau este chico este chico sabe este chico sabe por dónde hay que ir y no sé a nivel de de eso mismo de
[No identificado] (00:07:45): Pues de calidad de buenas prácticas ahora mismo que crees que es lo que lo que afecta en el desarrollo software quiero decir está lo típico que todos decimos bueno pues sol y pues está pero yendo ya más a la realidad no en tu día a día qué cosas consideras que hay que tener en cuenta y que todavía hay veces que como tú dices pone el punto y coma que la gente no que no está tan atenta a ello principalmente porque todos somos personas y lo más probable es que a nosotros también nos pase no pero
[No identificado] (00:08:21): O sea yo creo que muchas veces lo que nos pasa es que nos centramos en por ejemplo temas y problemas técnicos no el punto y coma o que aquí no hace falta punto y coma o cosas así que son debates que bueno puede estar bien tener pero a lo mejor por dedicar tiempo y esfuerzo en ese debate más técnico a lo mejor nos estamos olvidando de la parte de negocio de que a lo mejor tienen que terminar una funcionalidad porque tienen que publicar esa aplicación porque tienen que buscar inversores para que el producto funcione
[No identificado] (00:08:51): Para que nos puedan pagar nuestros sueldos o lo que sea entonces muchas veces nos falta a veces tenemos que favorecer hay que intentar hacer lo que tenemos que hacer en vez de lo que nos gustaría hacer o sea pues por supuesto nos mola meternos ahí en debates de de tabs versus espacios punto y coma o no punto y coma o no temas así más técnicos typescript versus javascript cualquier cosa que no hay debate
[No identificado] (00:09:21): O sea cualquier cosa que que con la que estamos cómodos debatiendo y demás y a veces nos olvidamos que al final lo que lo que hacemos no es aportar valor pues a un producto o a negocio entonces tenemos que estar alineados en ese sentido vale ponernos el sombrito de como decía el sombrito de las personas de negocio para pensar como ellos y ver un poco sus necesidades
[No identificado] (00:09:49): Crees que a lo mejor eso se podría mitigar de alguna forma quiero decir quien diga que no miente como un bellaco o sea al final bien sea conscientemente o inconscientemente parece que hay una línea entre negocio y desarrollo que siempre está presente y aunque se intente de acercar igualmente las personas técnicas tenemos un perfil técnico las personas de negocio no suelen tener ese perfil y están precisamente más enfocadas a negocio y sí que hay reuniones como puede ser las que se hacen cuando aplicas BDD cuando simplemente intentas hacer una sesión de captura de requisitos definición de dominio
[No identificado] (00:10:29): Pero siempre hay un punto ahí que acaba faltando ¿no? Entonces ¿cómo crees que podríamos un poco mitigarlo en tu experiencia? ¿qué es lo que a ti te ha funcionado? Para ver si se podría replicar en otros escenarios o no pues yo cuando comienzo en un proyecto o en un negocio en concreto al final lo que intento es aprender de ese negocio que voy a estar en un proyecto yo que sé de banca pues me estudio
[No identificado] (00:10:56): Cómo funciona pues la banca los términos que usan pues me envío algún vídeo o algún libro y empiezo a entender el negocio ¿vale? Porque la gente que se piensa que los programadores nos tenemos que dedicar a la parte técnica y la de negocio se encarga otra persona y nos mandan los quehaceres ¿no? Por gira o pivota o lo que sea se equivocan completamente tenemos que estar muy inmiscuidos en el lenguaje de negocio para al final traer esos conceptos a código que es lo que realmente muchas veces cuesta
[No identificado] (00:11:29): Pero una vez se hace eso correctamente tu código empieza a tener sentido ya no son palabras ahí el controller manager repositorio cosas que dices joder esto no tiene ningún sentido sino que ya empiezas a dar ese lenguaje semántico y ya empieza todo tener sentido y al final lo que ocurre muchas veces es que cuando estamos desarrollando en un negocio al final los desarrolladores sabemos mucho más del negocio que la propia gente de negocio pero vaya es algo necesario y es algo que bueno además a mi me mola porque aprendes de un montón de negocios distintos
[No identificado] (00:12:04): Que si empresas a lo mejor eléctricas que a lo línea no o sea todo tema de productos de mil cosas ¿no? Entonces es un mundo el desarrollo muy interesante pero tenemos que a veces tener pues bueno la visión técnica y la visión de negocio y de esa forma vamos a ser mucho mejores profesionales si estoy a favor de lo que has dicho y además hay una frase que recuerdo que los desarrolladores sabemos de todo y no somos expertos en nada y creo que es perfecto porque cuando te implicas con negocio acabas sabiendo un montón de él
[No identificado] (00:12:39): No acabas siendo un experto porque por desgracia no estás día a día pues a lo mejor de cara al cliente o trabajando tú mismo con la aplicación sino que la estás desarrollando pero conoces el dominio no eres el perdón y por otro lado hay tantas ramas en el sector del desarrollo que sabes de ello eres profesional pero acá es muy complicado llegar a un nivel a un nivel de expertise supremo de no no soy la persona que más sabe es imposible o sea al final siempre vamos un poco ahí de somos la parte técnica pero sabemos de los negocios donde vamos cayendo
[No identificado] (00:13:15): Y al final somos nos acabamos convirtiendo en el cuñado de las reuniones de navidad cuando llega y sale un tema y dice ah si las eléctricas pues yo sé que las facturas que no mira que es que voy a coger un barco ah pues ten cuidado porque en estas horas los barcos no mira que es que voy a ir al supermercado pero tú has pensado que te ya o sea no sé sí sí desde luego pero ese conocimiento es necesario y lo que digo aporta mucho valor al código
[No identificado] (00:13:45): Al final yo por ejemplo cuando también cuando comienzo en los proyectos me hago un diccionario de los términos que se usan normalmente en las reuniones lo que va surgiendo y lo voy apuntando y me voy haciendo definiciones pues mira esto significa tal cosa esto significa tal cosa y al final cuando desarrollo pues me baso también ese diccionario para dar nombre pues a las funciones a las clases a las entidades entonces ya sé que cuando negocio habla de un término se refiere a mi término en en código y muchas veces pasa que a lo mejor negocio encuentra un término mejor o modifica el nombre del término
[No identificado] (00:14:23): Entonces yo lo que hago es inmediatamente cambiarlo en el código vale que tengo que cambiarlo en base de datos en el controlador de la pirrest en el front en el formulario en todo sí pero no pasa nada porque estoy ya más alineado con negocio y no hace falta que haga esa indirección de a es que cuando se refieren a x cosa realmente quiere decir y y es que y ahora es z entonces es una locura no entonces estar alineado eso es muy valioso yo creo que es una de las cosas que al final hace que las cosas tengan más sentido no el desarrollo
[No identificado] (00:14:56): Si es este denominado obligue ti documento ubicud y y y y y y y y y y y y y y y y y y y y y y ! ! !
[No identificado] (00:15:27): Y
[No identificado] (00:15:30): !
[No identificado] (00:15:56): Y
[No identificado] (00:16:00): ! !
[No identificado] (00:16:13): ! ! ! Y ! Y !
[No identificado] (00:16:26): Y
[No identificado] (00:16:36): ! !! ! Y y
[No identificado] (00:16:37): !! ! ! Y y y
[No identificado] (00:16:37): Y
[No identificado] (00:16:40): Y y y y y y y y y y y y
[No identificado] (00:16:48): Y
[No identificado] (00:16:50): Y
[No identificado] (00:16:56): Y y ! ! ! !
[No identificado] (00:16:58): Coincidiendo un poco con las últimas empresas con las que he hablado es que o con las personas que han estado buscando entrar a empresas
[No identificado] (00:17:07): Lo que buscan es un poco captar a los desarrolladores ¿no? Entonces cuando
[No identificado] (00:17:13): La empresa ofrece tecnologías más novedosas pues como que es como ah pues vas a poder estar trabajando con lo último ¿no? Y al mismo tiempo las personas quitan el foco de negocio y dicen ah no pues voy a prepararme las nuevas tecnologías porque es lo que las empresas están pidiendo están pidiendo estar a la última o sea a ver es importante desde luego si tienes la posibilidad es maravilloso pero recordemos lo de siempre ¿no? Que de nada te vale estar trabajando cinco años en un producto que no llega a producción porque los ingresos de algún lado tienen que salir
[No identificado] (00:17:45): Y si no estás en producción no produces puedes tener inversores detrás inyectando dinero pero va a llegar un momento donde digamos oye pues si esto no produce y no tiene un retorno de inversión yo me doy media vuelta y me voy
[No identificado] (00:17:59): Correcto o sea por eso por ejemplo en autentia y tal al final lo que se busca es gente que le interese en los temas transversales que se puede aplicar a cualquier proyecto o a cualquier framework al final framework el lenguaje pues da un poco más igual ¿no? Pero las ideas prevalecen ¿no? De pues el tema de separar por capas el tema de los conceptos de pues de pues arquitectura hexagonal el domain design el testing ¿no? Tan importante que la gente pues entienda que el testing es bueno y es necesario ¿no? De hecho también siempre me hace mucha gracia que la gente dice
[No identificado] (00:18:35): No a mi no me dejan hacer testing en mi proyecto y tal pero ¿quién no te deja? Es decir ¿y cómo has hecho participar a lo mejor de una decisión técnica a alguien de a lo mejor de negocio?
[No identificado] (00:18:48): Yo por ejemplo si voy al cirujano no le digo que me opere con con un martillo y con una hoz yo delego en el cirujano que ha estudiado mucho ¿no? Mucho tiempo
[No identificado] (00:19:00): Para que me opere como es crea conveniente ¿no? Entonces el tema del testing yo lo veo pues oye al final es una herramienta que uso yo para que mi código tenga más calidad y al igual que no me dicen con qué ID tengo que trabajar pues el testing es una herramienta más que tengo en mi arsenal para mejorar la calidad del producto en el que trabajo claro yo creo que al final es porque muchas veces ya no es solo porque negocio no vea el valor de invertir tiempo en código que al final no está en producción es un poco como ellos lo ven
[No identificado] (00:19:32): Yo no estoy con ese punto de vista porque igualmente si está en producción es un código que está garantizando aunque no sea la ejecución principal está garantizando que lo que tú despliegas pues está funcionando lo cual
[No identificado] (00:19:44): No sé qué más valor le quieres ver creo que es lo lo principal de decir oye esto que está en producción está funcionando y está ahorrando tiempo de un desarrollador o de un QA de estar ahí replicando las mismas pruebas de forma manual o el descontento de un usuario que use la aplicación y diga no funciona ¿y ahora qué hago? Entonces creo que que da muchísimo valor y muchas veces ya no solo convencer a la parte de negocio sino a la propia persona o el propio equipo que no le ve ese valor añadido o el siguiente punto que siempre digo que todo conocimiento
[No identificado] (00:20:23): Que vayas a aplicar requiere una curva de aprendizaje y sí que es cierto que el testing en concepto parece sencillo pero lleva un tiempo acostumbrarte y saber cómo enfocarlo
[No identificado] (00:20:38): Incluso ver los síntomas cuando algo es muy complicado de testear pues igual es porque el diseño que estás intentando aplicar no es del todo correcto entonces a mi forma de ver el testing ya no es tanto hago testing hago TDD por el hecho de voy a probar lo que estoy haciendo sino porque es una herramienta que me ayuda a validar no solo el código a nivel funcional sino a nivel estructural decir oye esto que estoy haciendo es complejo o no es complejo mantiene un poco unas reglas porque si tu arquitectura es sencilla y pues estás teniendo en cuenta que tus componentes son atómicos tienen responsabilidades
[No identificado] (00:21:15): Únicas y demás va a ser muy sencillo testear al final a base de test unitario la capa de integración puede ser más o menos compleja dependiendo de las relaciones que existan pero a nivel unitario debería ser casi que soplar y hacer botella siempre y cuando tengas esa curva de aprendizaje más o menos lograda entonces a mi forma de verlo parece que me estoy enrollando pero es un poco que los equipos cuando llegas y te dicen no es que no me da ganas hacer testing es también porque no ven tanto el valor añadido de es que voy a estar probando esta funcionalidad o desarrollando código
[No identificado] (00:21:49): Para esto que me va a llevar 20 minutos cuando son dos líneas bueno es que yo creo que justo suscribo lo que dices porque para mi los test son muy fáciles el testear es muy muy sencillo lo difícil es hacer que el código sea fácil de testear eso es lo difícil entonces si no conocemos conceptos como la inversión de control si no hacemos uso de pues bueno de justo de este mecanismo que muchas veces va ligada a un motor de inyección de dependencias y demás claro te toca moquear todas tus dependencias entonces
[No identificado] (00:22:26): Ahí ya entramos en temas más complejos que las bibliotecas de hoy en día que sí te permiten moquear esas imports que haces pero no es la forma idónea bajo mi punto de vista de hacerlo si tú tus dependencias ya uses pues clases o uses funciones si esas dependencias vienen por el constructor o vienen por parámetros tú en el test lo que vas a hacer es pasar a una dependencia falsa entonces el test pues es muy sencilla luego en la pieza que construye esa instancia o llamas a función pues le pasarás lo de verdad pues la dependencia que llama al backend o lo que sea entonces
[No identificado] (00:23:07): Llegar a ese modelo mental cuesta y hay veces que la gente no ve el valor añadido de este modelo mental y piensa que es una complejidad innecesaria yo creo que no porque al final el test es mucho más sencillo el diseño es mucho más limpio y es mucho más flexible a mí muchas veces uno de los efectos secundarios de hacer testing es que tu aplicación va a ser más flexible porque al ser fácil de testear vas a poder cambiar piezas y vas a poder pues cambiar el comportamiento de tu aplicación de forma sencilla que es un poco al final como es el objetivo nuestro desarrollo
[No identificado] (00:23:47): Sí y que negocio cambia si negocio cambia vas a tener que cambiar tu software cuantas veces no pasa que hay un cambio de requisitos un cambio no funcional porque siempre nos centramos en los requisitos funcionales pero y dónde están los requisitos no funcionales y tu negocio cambia tienes que cambiar y dices no no es que cambiar esto es dos años de trabajo y dices pues has fracasado o sea en cuanto a desarrollo tampoco tienes que conseguir la solución
[No identificado] (00:24:16): Súper resiliente súper modular una joya de la ingeniería pero por lo menos que lo mínimo y los mínimos principios de principio abierto cerrado o sea los principios sólidos en general adaptados a lo que estés usando que se puedan aplicar bien y que cualquier cambio no suponga un trauma de años de desarrollo pues si no claro justo o sea ¿por qué hacemos testing? ¿por qué hacemos buenas prácticas? ¿por qué tenemos arquitectura? Porque si a día de hoy nos viene un proyecto donde nos dicen mirar este proyecto va a durar seis meses aquí tenéis las historias que tenéis que hacer están súper bien descritas no hay vamos
[No identificado] (00:24:58): O sea están perfectas ¿no? Estos usuarios súper completas y además te prometen te hacen un pinky promise ¿no? Te dicen te prometemos que es que a los seis meses no te vamos a cambiar ninguna historia de usuario
[No identificado] (00:25:14): No va a haber nueva funcionalidad no va a haber que hacer nada más a los seis meses a los tres meses a lo que sea no cambia nada
[No identificado] (00:25:24): Entonces no haría falta arquitectura no haría falta buenas prácticas porque dices pues si es que todo lo que hago de buenas prácticas de arquitectura de testing está orientado para que podamos encajar mejor el cambio si no hay el cambio si no hay cambio pues bueno vale pero ¿cuántas veces ocurre eso en la vida real? Es que de hecho si se diese ese caso bajo mi punto de vista es que la aplicación está muerta o el servicio está muerto no tiene usuarios que lo usen que tengan otras necesidades porque a medida que más usas una aplicación surgen las necesidades eso para mí es un síntoma clave
[No identificado] (00:25:56): Cuando tú tienes una aplicación que no requiere cambio es que la aplicación está muerta no la usa nadie absolutamente nadie
[No identificado] (00:26:05): Entonces eso al final todo el tema de optimizar para la legibilidad en vez de para escritura todo lo que hacemos es en pos de que podamos hacer cambios más fáciles luego claro también lo que dices no podemos hacer una no podemos pecar de sobre ingeniería al final la arquitectura debe ser emergente yo no puedo irme a una cueva tres meses idear el sistema perfecto hacer un excel un powerpoint con un montón de diagramas y de flechitas y dibujitos y salir de ahí y emerger de la cueva con ya una barba irsuta y bien poblada y llegar al equipo de desarrollo y decir lo tengo
[No identificado] (00:26:43): Ya tengo aquí en este powerpoint en esta slide tenéis todo lo que necesitáis saber y me marcho y me voy y ya está y he hecho mi trabajo no porque es que los humanos no somos muy buenos adivinando cosas entonces lo suyo es posponer las decisiones que son difíciles de cambiar hasta el último momento porque es cuando más información vamos a tener entonces si en vez de tomar un conjunto de decisiones muy grandes que son difíciles de cambiar al principio el proyecto me ir esperando hasta los momentos en los que realmente tengo que tomar esa decisión pues al final va a hacer que mi arquitectura
[No identificado] (00:27:20): Sea más flexible y bueno se vaya construyendo poquito a poco así que es verdad que yo comienzo con una serie de ideas por repositorios casos de uso
[No identificado] (00:27:33): Ciertas capas ¿no? Y en base a eso eso ya es como lo que yo ya he determinado que siempre me va a hacer falta pero bueno una parte ligera y ya sobre eso voy construyendo
[No identificado] (00:27:47): De todos modos si te has leído bueno en tu caso sé que obviamente te lo has leído Clean Architecture es una de las primeras cosas que ahí está es una de las primeras cosas que habla Ankel Bob en su libro ¿no? Que él hacía un proyecto con su hijo y gracias a postergar las decisiones y basarse solo en esas interfaces de repositores y demás estuvo escribiendo de adfichero hasta el último momento de entregar el proyecto y eso les ayudó a tomar la decisión técnica porque obviamente desde negocio ellos no te van a decir que es mejor utilizar una base de datos relacional o no relacional
[No identificado] (00:28:20): Solo como desarrollador como técnico o como arquitecto eres tú o es el equipo quien tiene que tomar esa decisión pero ¿en base a qué? Pues tienes que conocer el negocio bien y tienes que haber hecho pruebas y haber visto cómo reacciona eso para poder tomar ese tipo de decisiones porque si no es llegar y decir bueno hago esto porque es lo que conozco es lo que el equipo conoce pero no es lo que el negocio necesita o igual sí también depende de las necesidades de negocio igual tienes un MVP muy cercano y dices oye este es el equipo lo que hay este es el tiempo
[No identificado] (00:28:53): Que tenemos vamos a hacerlo con algo con lo que estemos cómodos y después lo cambiamos pero tienes que diseñarlo bien porque después sabes que lo quieres cambiar sí o la gente que se aflige cuando hay un montón de cambios y dicen joder si es que lo he hecho de esta manera y me han dicho que lo cambie que lo tengo que cambiar pues sí es que este es nuestro trabajo o sea no te van a pagar menos espero vaya si te piden muchos más cambios sobre lo que ya había ¿no?
[No identificado] (00:29:21): Pero bueno al final tenemos yo diría cierto ego y nos encanta que nuestro código esté bien y esté pristino y funcione genial pero hay que desapegarse un poco de eso ¿no? El código que haces no no eres tú ¿no? O sea es código que es de todos de hecho de todos sobre todo más de negocio que es el que ha pagado por esto ¿no?
[No identificado] (00:29:45): Pero hay mucho mucho apego al código ¿no? La gente por ejemplo cuando vino alguien a ayudarte y a mejorar el código que has hecho siempre se puede hacer ¿no? Las formas importan ¿no? Se puede mencionar y hacer una call y hacer el programming ¿no? Y mejoras ahí el código pero hay veces que la gente se enfada ¿no? Mejor han tocado mi código dices ya bueno pero ostras es que había algo que se podía mejorar bueno siempre es bueno enseñar ¿no? Para que no vuelva a ocurrir estos posibles errores ¿no? Pero ostras mucho apego al código ¿no? No sé cómo lo ves tú no, no totalmente
[No identificado] (00:30:20): O sea lo tomamos como algo muy personal yo a ver considero que por suerte me he ido desapegando hasta el punto de que ya yo veo código y no me acuerdo si lo he hecho yo o no eso es lo mejor generalmente me acuerdo ¿vale? Y digo ostras que liada pero sí, sí o sea me opino lo mismo o sea tenemos desarrollamos un amor
[No identificado] (00:30:41): Parental hacia el código como no, no este es mi pequeño y no me lo toques y cuando a lo mejor hay cambios en negocio la sensación un poco es ostras que es que estoy cogiendo mi trabajo y lo estoy tirando y lo estamos desechando porque no es válido no, ojo no es que tu trabajo no sea válido es que lo que negocio necesita lo que negocio necesita ha cambiado los requisitos han cambiado no es que lo que hayas hecho en su momento era válido en ese momento y ya no lo es efectivamente ya está o sea es como si la gente de Microsoft se cabrea
[No identificado] (00:31:13): Porque ya no utilizamos Windows 95 y chicos no sé creo que es normal ¿no? O los móviles no, mira que es que tengo mi Samsung Galaxy S3 y lo sigo usando en 2022 porque es que no quiero que Samsung se ofenda porque porque bueno porque fue el móvil que yo compré en su momento tus necesidades cambian a lo largo del tiempo entonces es normal que tu código cambie y lo que hiciste en su momento no se o sea se desecha pero no quiere decir que durante un tiempo eso no haya sido útil o que se haya desarrollado en base a un concepto erróneo que cambia
[No identificado] (00:31:49): Y hay que solucionarlo oye pues ya está o sea no hay más problema desde luego que seguramente cuando lo hiciste lo hiciste con toda la buena voluntad y la buena fe del mundo si no hazte lo mirar
[No identificado] (00:32:00): Si luego al final todo lo que aprendemos ¿no? Por el camino muchas veces no es el destino ¿no? Sino el camino que vamos recorriendo y todas las enseñanzas que vamos acumulando ¿no?
[No identificado] (00:32:11): Entonces eso también es súper valioso yo aprendo un montón cuando llega alguien nuevo al equipo siempre porque quieras o no tienes esas inquietudes de querer aprender de ver y sobre todo me gusta cuando esa persona no es vamos a decirlo pasiva y sedentaria sino que empieza a mirar oye ¿por qué no lo has hecho así? ¿por qué no? Sabes que que critique un poco pero no que critique en el mal sentido de buah esto no hay por dónde cogerlo buah mira este código mejor borrarlo no oye ¿por qué? ¿sabes? Sobre todo cuando te hacen la pregunta de por qué porque te hace reflexionar
[No identificado] (00:32:44): Y en la mayoría de los casos
[No identificado] (00:32:48): Pues te planteas y te aportan ideas y dices oye no mira pues esto se hizo así porque en su momento no había más tiempo a lo mejor oye pues un buen argumento en su momento de negocio nos dijeron mira tenemos un problema va a haber un pico de usuarios necesitamos tener esta funcionalidad y después la mejoramos oye mira pues está funcionando cumple unos mínimos de calidad que no es que tú digas esto está hecho al trancaso y a correr ¿no? O sea cumple lo mínimo claro y eso por ejemplo es al final entender que entienda negocio que ellos pueden asumir la decisión de de de
[No identificado] (00:33:19): El equipo que bueno que va a tener que asumir deuda técnica es decir vamos a sacrificar cierta calidad ¿no? En nuestro proceso para poder salir a producción con una funcionalidad que a lo mejor es que o la sacamos o o se acabó el producto entonces hay que decir no no no es que mira yo es que si no tengo un 99% de cobertura que bueno cobertura luego también pudimos hablar algo entendido sobre ello si no tenemos eso no no te puedo hacer no no no si la pull request que hay que hacer esta finalidad no la revisan cinco personas
[No identificado] (00:33:57): No no no no no no o sea hay que ser flexibles al final ¿no? Nos centramos en lo que decíamos al principio en la parte técnica que es la que tenemos control y es la que nos da seguridad y y nos olvidamos de de empatizar ¿no? Con con justo con estas casuísticas si si si si tenemos que estar muy cercanos a negocio porque además vuelvo un poco a a a a a a a a a a a a a a a a a a a
[No identificado] (00:34:24): ! A ! ! ! ! ! ! ! !
[No identificado] (00:34:52): Entonces hay que hacerles entender que oye bueno si es una decisión que pueden tomar pero que tiene consecuencias consecuencias negativas ¿no? De no te vamos a asegurar que esto vaya a funcionar tan bien como las otras piezas eh no vamos a ¿no? Eh o sea pues a lo mejor el diseño es peor eh o lo que sea entonces vamos a tardar luego más tiempo en arreglarlo que si lo hubiésemos hecho bien a lo mejor desde el principio entonces eh tienen que entender que tiene consecuencias no todo el proyecto puede ser eh duda técnica ¿no? Claro volviendo al ejemplo del cirujano antes decíamos mira
[No identificado] (00:35:29): Yo no le voy a decir al cirujano si me tiene que operar con un martillo con un a ojo con lo que sea pero la verdad que tú como persona que te van a operar tampoco aceptarías que el cirujano te dijese oye mira eh tienes un agujero así en el pecho ¿vale? Eh tenemos dos opciones o que te lo cosa que vamos a tardar una hora en coserlo con lo cual te vas a morir desangrado o te cojo te tapo te hago un lo que sea te tapo con lo primero que pueda para que no te mueras y en ese proceso ya después pues
[No identificado] (00:35:56): Vamos cosiendo y vamos arreglando obviamente lo que le vas a decir es con lo que tengas arréglalo ya después me vas cosiendo pero lo primero es que yo no muera desangrado pues es lo mismo es lo mismo parece muy bruto y muy bestia pero es la verdad o sea hay momentos donde no queda otra que decir oye eh decisión extrema lo que hay que hacer ahora es tenemos que hacer un torniquete para después coser no sé si desde el punto de vista de la medicina eso es válido pero creo que el concepto se entiende perfectamente ¿no? Sí justo y pues también por ejemplo eh no
[No identificado] (00:36:28): O sea muchas veces también hay que exponer a a negocio eh temas tan ¿no? Que están en nuestro día a día como por ejemplo el burnout ¿no? De eh a lo mejor es que hay un pico de trabajo que es que no ha durado ya una semana y media dos sino que ya lleva durando un mes dos meses tres meses cosas ya que ¿no? Entonces también hay que hacerles ver de y esto por ejemplo habla se habla en el libro de Clean Coder eh en nuestro deber informar de que ostras si el equipo está eh sobre explotado ¿no? Eh que vamos a producir peor código
[No identificado] (00:37:03): Que vamos a cometer muchos más errores y esos errores que vamos a cometer vamos a tratar más en arreglarlos que si estuviésemos descansados y o sea porque si todo es urgente nada es urgente de acuerdo las cosas son importantes todo es importante pero no todo es urgente ahí está la gran diferencia claro entonces ahí pues eh no está el típico diagrama ¿no? De es urgente importante no urgente no importante entonces depende de si es urgente importante pues hay que hacerlo primero y demás ¿no? Sí entonces es eso yo creo que hay muchas veces que que no hacemos partícipes en negocio de de toda esta información
[No identificado] (00:37:43): Y y luego nos quejamos ¿no? Eh entonces es exponer ¿no? La información también depende un poco de cada caso también puede ser yo yo me he sentido también a veces un poco con la sensación de miedo ¿no? De decir oye es que si le decimos a negocio que que es que que no podemos más que esto está llegando a un límite insostenible bueno bah pero es que te quejas con nada es que no aguantan aquí ni dos plumazos y tú dices chico el que hay que dormir claro o sea también es entender hacerles entender que al final la programación no es
[No identificado] (00:38:16): O no debería ser ¿no? Una actividad eh
[No identificado] (00:38:20): Pues como es una actividad muy creativa ¿no? Entonces depende mucho de de si estás descansado de si puedes pensar bien si estás centrado entonces es importante ¿no? Para producir buen código o sea yo a últimas horas de la tarde o cuando no estoy bien centrado me tomo un descanso eh
[No identificado] (00:38:41): Descanso y eso y ya pues joder si luego tengo que continuar pues ya busco mucho mejor código ¿no? Entonces es es eso también autogestionarse sí también no sé si te ha pasado pero cuando llevas varios días en el mismo código estancado ya no no lo ves como da igual lo que descanse porque ya estoy obcecado con esto y a veces simplemente haces un switch cambias de pareja eh lo ve otra persona que no tiene nada que ver le haces un breve intro y dices ah pero si estos son dos tonterías eh el ojo amigo ¿no? Eso también ayuda muchísimo nosotros intentamos generalmente cambiar de pareja
[No identificado] (00:39:18): Cada dos tres días
[No identificado] (00:39:21): Da igual para la gente que no lo sepa está hablando de paid programming ¿vale? Bien visto sí yo ya lo doy por sentado es que llevo cuatro años que de hecho en nada voy a los cuatro años en LeanMind esto es maravilloso ostras el el 3 de el 3 de julio y de hecho lo voy a celebrar en el Agile Open Spain en Barcelona o sea que va a ser una celebración de cuatro años en LeanMind impresionante que guay pues sí o sea intentamos hacer rotación de parejas cada máximo cada tres días ¿por qué? Porque da igual que una tarea se quede a medias
[No identificado] (00:39:59): Por una de las personas salvo que sea algo de oye mira que es que tengo la meta y está a punto de terminar si me gustaría porque para mí es un logro personal oye vale pues si si va a ser solo un día quita más perfecto pero si no intentamos eso rotar de pareja cada tres días primero para que el conocimiento no esté solo en en o sea en las personas que están tocando esa parte sino que el conocimiento esté disperso en todo en todo el equipo todo el mundo sabe de todo nadie es responsable de de una parte en específico el equipo es responsable
[No identificado] (00:40:33): De de la aplicación ¿no? Y por otro lado también para tomar aire fresco cuando te enfrentas a retos distintos pues coges aire y y también incluso después puedes hacer de de abeja ¿no? Y seguir polinizando si ves algo en una tarea te lo puedes después volver a traer a la tuya ¿no? Entonces siempre estamos ir rotando también motiva ¿no?
[No identificado] (00:40:59): Realizar proyectos nuevos y aunque sean no sean proyectos nuevos ¿no? Sino que sean una parte nueva del código y demás sí ahí ya uno también se tiene que empezar a conocer y y un poco organizarse también en ese sentido ¿no? A lo mejor pues mira tengo tres tareas importantes que hacer pues voy a hacer una y luego voy a otra así que un poco de contexto ¿no? Siempre que tenga sentido claro y también a nivel personal o sea no olvidemos que que cuando haces programming estás con una persona y cada persona es un mundo tenemos formas de ser distintas entonces también el tener esos bypasses
[No identificado] (00:41:36): De tres días así que que no tengas eso o sea que no se lleguen a crear grandes asperezas porque al final estás siempre todo el día pues debatiendo opinando no todos los días estás igual de energías entonces puede haber momentos donde haya conflictos asperezas y el hecho de decir pues como no es que estés un mes haciendo programming con la misma persona te evitas ese tipo de cosas ¿no? Porque ah bueno sí tuvo un comentario un poco da pero no le das importancia te olvidas y vuelves a hacer paid programming con él a las dos tres semanas y ya ni te acuerdas
[No identificado] (00:42:09): Porque ha sido algo como muy salvo que cojan y te insulten ¿no? Pero eso como que en un entorno de trabajo no es así ni debería de ser y no pasa y no pasa te dicen que TypeScript que no hace falta ¿no? Eso ya es un insulto bueno eso ya para mí es directamente que despido despido procedente además total total o sea te ganas un follow en github en twitter desde luego quedas baneado de todas las redes sociales no no cuando dicen es que TypeScript
[No identificado] (00:42:41): Yo a mí me cuesta mucho entender y poner la posición de la gente que dice que a esa persona que no le hace falta en proyectos medios grandes con bastante gente aunque sea con dos personas o tres me cuesta entender cuáles son las razones por las cuales no ven que sea necesario yo creo hablando aquí muy raw vale muy a lo bruto creo que es porque no han pasado la curva de aprendizaje y porque probablemente los proyectos no han tenido el tiempo de vida suficiente o sea porque no han llegado todavía a ver las virtudes me explico un poquito más en detalle vale después del
[No identificado] (00:43:19): Super disclaimer
[No identificado] (00:43:22): Obviamente TypeScript tiene una curva de aprendizaje que está ahí o sea es innegable vale
[No identificado] (00:43:28): Eso es cuando cuando algo cuesta pues sientes rechazo de primera como oye pues claro pero ahí hay que aguantar el tipo claro porque después es a la inversa ¿no? O sea cuando pasan dos años de proyecto tienes que tocar un módulo del que ya ni te acuerdas ¿dónde está esa documentación? O el equipo crece alguien cambia una propiedad lo renombra vale undefined buena suerte buena suerte y ahora ¿dónde estás? Y empiezas a tirar del hilo y empiezas a buscar no es que lo estés
[No identificado] (00:44:01): Lo que quieras vale
[No identificado] (00:44:03): Pongamos soluciones pongamos soluciones aportemos semántica ¿por qué no? Entonces yo creo que las personas que no que digan oye pues no no me termino de sentar de sentir como si no no no es que estoy inútil que además que es como no no no no TypeScript ¿para qué? No han llegado a ver todavía las virtudes y seguro que si les das la oportunidad y el el playground ¿vale? Para que puedan jugar un poquito y conocerlo y puedan sentirse a gusto sin presión y demás
[No identificado] (00:44:34): Seguramente lo acaben adoptando porque ya te digo es una virtud no sé cómo lo ves tú pero sí sí totalmente o sea yo de frameworks he probado ya los tres los tres grandes he probado Angular React, Vue he probado Lead he estado con Stencil
[No identificado] (00:44:53): Bueno hay veces que cuadra más uno veces que cuadra más otro pero siempre TypeScript
[No identificado] (00:44:58): Porque al final la mayor parte de mi código es TypeScript no solo es componente no es el framework yo separo por capas entonces la mayor parte de mi código no tiene que ver con el framework entonces yo quiero poder lidiar con ese código de forma fácil sencilla y que la gente pueda hacer cambios que no se rompa o por lo menos si se rompe verlo en compilación no en runtime entonces de otra forma la gente que dice no pues si no tienes tipo pues ahora tienes tendrás que hacer más test y demás ostras que de test ¿no? Y ¿qué haces? Comprobas que cada función
[No identificado] (00:45:29): Si le pasas el tipo incorrecto que se gestiona de forma distinta ¿qué haces? ¿tienes cláusulas de guarda que comprueban el tipo en runtime? Claro ¿qué pasa con eso? Genera más código es más complejo ostras ¿y qué feedback le das al usuario?
[No identificado] (00:45:46): Porque cuando por ejemplo te equivocas ¿vale? Te has olvidado de parciar un input a un number
[No identificado] (00:45:53): ¿qué feedback le vas a dar al usuario? Uy usuario es que como desarrolladores
[No identificado] (00:46:00): Hemos cometido un error ¿sabes que al final también el usuario cuando hubo un error le gusta entender el porqué en el sentido de oye pues si he hecho algo mal dime cómo lo soluciono no, no, no es que no está en tu terreno es que está en el mío está en el de desarrollo
[No identificado] (00:46:13): Chapuzas estos no saben hacer las cosas mira tú
[No identificado] (00:46:18): Ahorratelo porque es que al final a quien le van a a calentar el lomo como se suele decir es a ti como desarrollador como equipo a quien le van a apretar el saludo y decir este mes no comes este mes no cobras es a ti no a nadie más
[No identificado] (00:46:33): Pues sí total
[No identificado] (00:46:37): En base a todo esto que hemos hablado de arquitectura y calidad
[No identificado] (00:46:42): ¿qué recomendarías leer?
[No identificado] (00:46:46): Pues desde luego el último libro de Carlos Blé Código Sostenible de hecho tengo ahí varias copias vaya yo tengo dos por aquí también una mía y la otra es para alguien que lo tengo por ahí se lo compré lo tengo dedicado y a ver si coincido hola David ¿cómo estás?
[No identificado] (00:47:06): Pues no bueno yo empezaría sobre todo cuando la gente entra en Autentia la gente más nueva pues siempre le recomiendo dos libros que son aparentemente sencillos que son cortitos pero ostras que te tiene unas enseñanzas brutales pues uno es las cuatro reglas del señor simple de de Corey Haynes y luego 99 botellas de Sandy Metz son dos maravillas una maravilla de libros la verdad luego pasaría ya a algo un poquito más complejo como Clean Code he hecho Clean Code hay que leerse varias veces cada vez que te lo lees extraes cosas nuevas y bueno luego ya si quieres pues puedes pasar a Clean Architecture
[No identificado] (00:47:53): Por ejemplo la de
[No identificado] (00:47:56): Head First Design Patterns para ver patrones de diseño y luego es que hay un montón más de recursos de tutoriales de un montón más entonces pero bueno yo creo que considero que ese es un buen inicio y luego ya pues tienes temas más de lo que hemos hablado de un poco de que ser pragmático ¿no? Pragmatic Programmer Clean Coder
[No identificado] (00:48:19): De test tiene un montón de libros entonces también sin fin tú has hecho el discrimer a Carlos voy a hacerlo yo también a la inversa también están los recursos de Autentia tenéis un montón de documentos y ahora también estáis publicando cositas en redes sociales con explicaciones sobre pues sobre Kotlin sobre Java que son muy interesantes para los desarrolladores entonces también que no todo tiene por qué ser libros sabemos que los que somos muy old school pues nos gusta sentarnos en nuestro despacho y ser muy bohemios nosotros pero también hay otra otra forma otros recursos ¿no? Sí hay muchas formas de aprender creo que tanto
[No identificado] (00:49:00): En este caso Sabil y Lindman como Autentia están haciendo una labor de formación a la comunidad que joder quería agradecer porque primero porque somos nosotros los primeros que lo consumimos como internos pero es que como externos creo que es una pasada
[No identificado] (00:49:20): Justo justo barremos para casita que le vamos a hacer
[No identificado] (00:49:26): Que guay y estábamos hablando antes de la cobertura de código ¿qué? ¿cómo se te queda el 100% de cobertura? ¿le ves realmente a eso de sentido a la cobertura de código o algo que no? Pues no sé si nos da tiempo ya meternos también en este tema vamos en tiempo pero el tiempo de descuento a ver en cuanto a la cobertura al final yo lo que miro es que con los test que haga ya sean de inventarios integración en tu en lo que busco es que me aporten confianza yo quiero tener confianza en que lo que haga ¿vale? Se despliega en producción
[No identificado] (00:50:05): Con un alto nivel de fiabilidad y eso realmente no me lo da un numerito de la cobertura ¿no? Porque yo puedo hacer trampas yo puedo hacer un test que entre por una rama del código y que diga expect true to be true ¿no? Sí sí pero ese test ¿me va a dar confianza? No porque no tiene un reflejo de dominio claro entonces yo miro más para que los test estén bien hechos que aporten valor y que luego al final si hacemos TDD ¿no? Pues de forma natural nuestra cobertura va a ser alta pero me fijo más en esa sensación de confianza de fiabilidad antes que
[No identificado] (00:50:46): Cualquier numerito o estadística totalmente de acuerdo al final son números y si los números o sea un número fuera de contexto no vale nada un número con contexto y en este caso para mí son las reglas de negocio es lo que de verdad cubre o sea de que me vale a mí que yo haga que haga que mi código pase por rama que realmente en su conjunto para negocio no tiene sentido
[No identificado] (00:51:13): Bueno pues César vamos a pasar a las dos preguntitas sorpresas ¿estás preparado? Sí claro venga vale pues primera pregunta sabemos que bueno estamos familiarizados con hacer catas de código ¿vale? No vamos por ahí a tomar vinos y demás también podríamos pero catas de código sabes que generalmente hay retos que te dicen oye pues no uses esto no uses lo otro yo me he decantado por una de las complicaciones es cierto si tuvieses que elegir en un código en una cata por solucionarla sin bucles for o sin condicionales sin if else ¿con cuál de las dos te quedaría? Uff
[No identificado] (00:51:59): Me parece más interesante la de sin bucles if porque a lo mejor se puede hacer con pues
[No identificado] (00:52:08): Ciertas cositas ¿no? De orientación a objetos y tal entonces me parece como un reto más interesante para aplicar ahí diseños curiosones además la pregunta trampa está ahí presente he dicho bucles for pero bueno los operadores funcionales también están o sea que ¡ah! Vale vale que malo que malo ha sido que malo ha sido pues bueno y después está la otra pregunta que es
[No identificado] (00:52:35): Si serías capaz de decirnos ¿cuál es tu sitio favorito para trabajar?
[No identificado] (00:52:40): Para trabajar ostras pues fíjate que el mes pasado ¿no? Que fui a la JCD Canarias pues dije bueno pues ya que estoy aquí me quedo un mes hago uso del teletrabajo y y ostras teletrabajar ahí con vistas a la playa a ver no en la playa porque yo lo de trabajar en la playa no lo veo aquí es inviable no no pero ostras sí sí ahí en la orataba
[No identificado] (00:53:11): En un colibit buen sitio bueno pues ya hemos cumplido nuestra misión todos los espectadores saben que el mejor sitio para trabajar son las Islas Canarias por favor ayuntamiento cabildo gobierno aquí la subvención tiene que caer que estoy haciendo broma broma la verdad es que es un sitio maravilloso para vivir tenemos los problemas que tenemos con el tema de los envíos a Canarias y demás pero bueno se puede vivir se puede vivir con él
[No identificado] (00:53:40): Pues nada César que te digo muchísimas gracias de estar aquí de compartir este episodio número 10 con nosotros y con toda la audiencia es todo un honor la verdad es que yo por lo menos he tenido la sensación de que se nos ha pasado el tiempo volando hasta que me dijiste oye que vamos pues sí pero bueno la verdad es que estamos sacando algo muy chulo adelante de nuevo gracias por estar aquí gracias por hacer lo posible gracias por estar estos ratitos espero que podamos repetir pronto se vienen cositas no voy a decir más igual eso y nada ser posible a ver si nos vemos
[No identificado] (00:54:21): Pronto ya no solo por video y demás sino en persona que siempre es un placer cuando nos tomamos por supuesto a ver vamos a estar del 1 al 12 de julio en el IAIL Open Spain en Barcelona o sea que nos podemos pasar por allí y hablar y vernos y charlar y quien se quiera pasar pues hombre igual igual tienen algún regalito cuando siempre hay decir hola o sea que
[No identificado] (00:54:48): Pues nada muchas gracias nada muchísimas gracias a ti y bueno a las personas que nos están escuchando de nuevo muchísimas gracias por haber pasado estas 10 semanas con nosotros que se dice rápido gracias por estar aquí cada semana por ayudarnos por apoyarnos por sugerir ideas y al final que la comunidad siga creciendo y sigamos todos adelante aportando valor porque al final esto no no sacamos mayor beneficio más que que la comunidad crezca y que se genere buen rollo y buen ambiente así que bienvenidos todos a formar parte de esta comunidad nos vemos en el siguiente episodio
[No identificado] (00:55:28): Adiós y
[No identificado] (00:55:37): Y