Va a ser la de Carlos Blech. ¿Por qué? Porque nuestro siguiente invitado lo que sabe hacer bien es código sostenible.
Código que va a poder ser entendido, mantenido, entendido y muchas cosas más.
Así que vamos a darle la bienvenida al bueno de Carlos. ¿Qué tal, Carlos? ¿Cómo estás?
Muy buena, Miguel Ángel. Encantado de estar aquí contigo y con toda la audiencia que hay. Espectacular.
De 8.000 y pico personas ahí. Impresionante.
Sí, ¿no? Increíble. O sea, la gente está aquí a saco.
Y, oye, muchísimas gracias por pasarte. La verdad es que ya sabes que para mí eres todo un referente.
He aprendido un montón contigo. Ya no solo en la parte técnica sino humana también.
Así que para mí es un privilegio tenerte aquí con nosotros hoy.
Yo estoy agradecido de corazón porque te admiro muchísimo el trabajo tan constante que haces.
Es muy difícil ser tan constante y tener tanta calidad en lo que se hace.
Para mí eres un fuera de serie. Tu audiencia, así lo dicen también. Y bueno, para mí es un honor.
Bueno, así que si quieres ya entramos en harina. Yo no tengo pantalla para compartir.
Ah, tú vas a saco, ¿eh?
Sí, al final comparto un par de slides. Que la gente estará bien que pueda hacer captura a pantalla.
Que estén rápidos porque ponen enlaces y cupones de descuento y tal.
Vale, buenísimo.
Y si tú me quieres transmitir preguntas me puedes interrumpir en cualquier momento, ¿vale?
Vale, buenísimo.
Y yo creo que sí la puedo responder ahí.
Te pongo en primera persona y si veo alguna cosa ahí, pues le doy, ¿vale?
Te pongo, a ver si soy capaz de ponerte a ti.
Ahora.
Ahí está, muy bien. Genial.
Muy bien, pues yo soy Carlos, trabajo en LeanMind.
Dirijo esta empresa actualmente que fundé hace cuatro añitos.
Y este año, pues hace unos meses he publicado este libro.
Bueno, hemos publicado porque es el trabajo de muchísimas personas.
Prólogo del gran Javier Ferrer que habéis tenido hace un ratito ahí.
Y de eso vengo a hablaros en esta sesión.
En LeanMind lo que hacemos es ayudar a equipos de desarrollo, entre otras cosas, a implementar código sostenible, ¿vale?
Entonces, ¿qué es esto del código sostenible?
Bueno, pues cuando yo llevaba un par de años ya ganándome el pan como programador.
Pues hace, igual hace de estos 17 años o algo así, 18 años.
Yo ya he llevado un tiempo manteniendo código de otras personas.
Código Legacy y también código mío.
Y hubo un momento que pensé, bueno, quizás no sé programar.
Porque esto de mantener código es tan duro que debo estar haciendo fundamentalmente algo mal.
Esto de programar, yo no quiero estar toda la vida acostándome a las tantas de la madrugada antes de una entrega.
Incluso a veces se me hacía de día.
Y con mucho miedo a darle al botón para desplegar en producción.
En aquellos tiempos incluso era tocar el código en caliente en el entorno productivo.
Era una locura.
Pero siempre con mucho miedo.
Yo decía, ojalá, tiene que haber otra forma de programar que no sea así, ¿no?
Y decía, bueno, ¿por qué, cómo es posible que arregle una cosa y rompa a tres?
¿Por qué siempre vamos con prisa?
¿Por qué siempre, nunca hay tiempo, ¿no?
Y cómo puede ser que cueste tanto hacer una modificación?
Y luego la pregunta del millón.
Oye, ¿cuándo vamos a tirar el proyecto abajo, vale?
Y lo vamos a reescribir completamente desde cero.
Que eso es lo que lo va a solucionar, ¿no?
Eso, luego, años después, trabajando como consultor con muchas empresas.
Equipos, bueno, en las últimas décadas, pues, con equipos de desarrollo de varios países.
Es una pregunta común o es un reclamo, una petición, ¿no?
Del equipo.
Oye, vamos a tirar todo abajo porque esto no hay que lo toque.
Hay que empezarlo desde cero, ¿no?
Y entonces, bueno, yo lo que le planteo a esos equipos ahora, con esos años de experiencia,
es qué harías diferente para que dentro de un año, si lo empezamos a reescribir hoy,
dentro de un año no haya que volverlo a reescribir.
¿Qué es lo que harías diferente?
Y, bueno, me voy a ayudar en el señor Agorer, ¿vale?
Que va a ayudarme a responder algunas preguntas que me hagáis y otras mías, mía, aquí.
Bueno, él va a estar aquí bastante rápido, ¿no?
Para las preguntas.
Bueno, se sigue riendo ahí.
Entonces, hay gente que sale con la fe de la religión del framework, ¿no?
Pues dice, bueno, pues vamos a usar donde core la nueva versión 38.43 con el nuevo Entity Framework
y entonces saldrá todo bien, ¿vale?
O vamos a React 80.000 con los hooks y con Redux y con Sagas y con Mongo.
Bueno, y ahí va a salir todo bien seguro, ¿no?
Es como una creencia súper optimista, todopoderosa de que librerías y framework nos van a solucionar.
Porque, bueno, total, si las ha hecho Microsoft o Facebook o Netflix, funcionará, ¿no?
Bueno, y la realidad es que los últimos 20 años no han parado de salir librerías y framework.
De hecho, salen más y más rápido cada vez.
Y seguimos escribiendo el código que da pena, ¿no?
Y manteniendo el código que nos quita a veces las ganas hasta de trabajar y de vivir, ¿no?
Entonces, por ahí, esa no debe ser la solución o por lo menos no solo eso.
Luego hay otra teoría que responde a la teoría de la arquitectura megalomaníaca, ¿vale?
Montaremos el servidor de...
Mira, se está partiendo de risa aquí.
Está cantando.
Pues, en esa teoría, montaremos un sistema de eventos, de colas, con patrones de diseño.
Usaremos todos los patrones, microservicios.
Y, por supuesto, pondremos Kubernetes.
Bueno, y con eso, pues, saldrá todo muy bien, ¿no?
Y tampoco creo que sea la solución mágica.
Porque llevamos muchos años viendo sobre ingenierías de muchos tipos.
Yo me acuerdo de la época Heavy DJ2GE con los EJB, SOAP y los servidores de aplicaciones rimombantes.
Bueno, que eso era un infierno, un dolor y todo sobredimensionado.
Y eso tampoco solucionaba el problema de mantenimiento de los proyectos, ¿no?
De hecho, algunos de los peores proyectos de los que yo he trabajado en mi vida eran diseños de arquitectura.
Y de una idea iluminada de una persona sola en su torre marfil que, además, luego ni siquiera tenía que usar esa arquitectura.
Se iba a otro proyecto y los que nos quedábamos ahí nos comíamos eso con papas, ¿no?
Y, bueno, gracias a Dios, a mí en esa época no me dejaban diseñar la superarquitectura.
Yo era un code monkey nada más.
Y porque si no la hubiera liado muy parda, si yo hubiera sido un superarquitecto, ¿no?
¿Qué dice el señor Agor el que hubiera pasado si me hubieran dejado a mí hacer una superarquitectura?
Yo pienso lo mismo, la verdad, francamente.
Entonces, bueno, ninguna de estas dos vías es la solución al problema, ¿no?
Ni la tecnología solamente, ni la arquitectura.
Entonces, ¿por qué se nos va de las manos el software, no?
¿Por qué, en qué momento dejamos de tener el control del proyecto?
¿Qué es lo que pasa?
Cuando tenemos un proyecto Greenfield, no un proyecto nuevo, avanzamos muy rápido.
Implementamos las funcionalidades de todo el code base, el repositorio, lo tenemos casi en la mente, ¿no?
Y es muy divertido y es muy rápido avanzar.
Pero poco a poco vamos perdiendo esa cadencia y, sin darnos cuenta, empezamos a pasar más tiempo leyendo código,
sobre todo depurando, y menos tiempo escribiendo líneas de código nuevas, ¿no?
Bueno, y al cabo de los años, pues ya olvídate.
Es muy poquito lo que escribes nuevo y casi todo el tiempo te lo pasas leyendo, depurando código.
Y tratando de arreglar bugs, ¿no?
Bueno, ¿por qué pasa esto?
Pues los tres principales motivos de la degradación, y esto lo resumo después con unas diapositivas que os voy a compartir,
son la complejidad accidental, ¿vale?
Y esto es que añadimos más complejidad de la que es necesaria.
Escribimos código por si acaso.
Elegimos soluciones que no son ni de lejos la más sencilla, si no es la primera que se nos ocurre y es muy complicada.
O intentamos anticiparnos al futuro y al final lo que hacemos es complicar mucho las cosas, ¿no?
Mis herramientas favoritas para reducir la complejidad son P-Programming y Test Driven Development, TDD.
Tengo un libro en limp-up de TD, pero obviamente ahora no os lo puedo pasar porque habéis tirado limp-up, ¿no?
Pero en algún momento ese libro pronto va a estar en Sabili y va a estar en papel también.
Yo creo que el mes que viene va a estar y ahí ya lo avisaré.
Pasaré a las newsletters también.
Y os voy a compartir un online talk de J.B. Reisberger que se llama Complejidad accidental,
el teorema fundamental de la agilidad en 7 minutos que está muy bien.
Vale, otro punto es que el código que escribimos no habla del lenguaje de dominio,
sino que habla de artilugios técnicos, de interfaces, se orienta a la base de datos relacional,
no se orienta a un dominio rico de verdad.
Y el tercer punto es que el código no se hace explícitamente para que un ser humano lo entienda.
O sea, no está pensado, diseñado con el objetivo de que otra persona lo pueda mantener.
A veces porque tenemos prisa y decimos, bueno, pues si funciona, estamos listos para entrega,
del line boom, lo lanzamos y se acabó, ¿no?
Y si la máquina lo puede escutar bien, vamos para adelante.
O a veces porque lo hacemos excesivamente genérico.
Tiene mucho que ver con la complejidad accidental.
Entonces, ¿qué es el código sostenible?
Pues lo que intenta es minimizar estos tres elementos degradantes con una serie de técnicas y principios
que van desde los detalles más pequeñitos hasta lo más global.
Y veréis que tenemos el problema grave de que programando no le prestamos demasiada atención
o lo suficiente a los detalles pequeñitos del código, a la, ¿cómo se llama?
Una variable, a cada línea que escribimos.
Y el código realmente no se arruina en un día.
O sea, nadie es un codebase tremendo y en un día lo revienta, ¿vale?
Lo vamos degradando poquito a poco porque no somos conscientes, ignoramos o infravaloramos
que cada línea de código importa.
Y cuando nos damos cuenta que el código ya es un lugar inhóspito, digamos,
ya cuesta mucho reparar el daño, ¿vale?
Entonces, hay que ir a esos pequeños detalles.
Hay cuatro reglas, que también las compartiré por escrito después, del código sostenible
que son, el código tiene que estar cubierto por test y por buenas.
La segunda regla es que los test tienen que ser buenos, útiles y fáciles de mantener.
Las abstracciones tienen que ser precisas y adecuadas.
Y ahora les cuento eso de qué va.
Y luego tiene que haber una intención explícita, clara, de por qué escribimos cada línea de código
y qué queremos decir con ella.
Y veréis que todavía hay muchos equipos que no escriben test, que no saben,
que no escriben suficientes test o que no son de buena calidad y al final son insostenibles
e incluso los acaban borrando. Es una pérdida de dinero tremenda.
A día de hoy es totalmente imprescindible escribir test y que haya una buena cobertura
para que se pueda mantener una cadencia de desarrollo.
Si tú quieres implementar una arquitectura hexagonal y domain driven design y patrones de diseño y todo eso,
no va a evitar que pierdas el control del proyecto y que el código te gane y que el código os barra, ¿vale?
Si no habéis puesto una buena batería de test automático, ¿vale?
¿Qué opina el señor Algorger de hacer un proyecto de desarrollo hoy en día sin ningún test?
No sabe muy bien.
Sí, yo opino lo mismo.
No se puede, no sé, se sigue descojonando.
No se puede hacer el código sin test.
Hoy en día es súper importante.
Y el asunto es que, aunque tú tengas mucho cuidado haciendo código o tengáis,
el código nunca lo haces de la manera idónea a la primera.
Siempre cuando ya lo pones en producción aprendes cosas de la forma que se usa.
Vas aprendiendo del dominio, del negocio conforme pasa el tiempo.
Es imposible hacerlo bien a la primera.
Hagas lo que hagas.
Entonces, lo que lo va mejorando es una refatorización diaria, permanente.
Y eso tienes que hacerlo, como ha dicho Yodra antes, con test, ¿no?
Que, por supuesto, enhorabuena la sesión de Yodra que me ha gustado mucho.
Bueno, la refatorización, cuidado, aquí hago un disclaimer, así, un aviso grande, ¿vale?
Y es que la refatorización no es eso que hacemos durante dos semanas seguidas
con todo parado una vez al año y todo lo ponemos patas arriba, ¿vale?
La refatorización tiene que ser algo que hacemos todos los días, unos minutos, cada día, ¿vale?
Esa es la forma sostenible de hacer refatorización.
Bueno, y ahora os cuento una historieta y es que, bueno, ¿cómo aprendí yo esto?
A ver, bueno, no sé si lo quiere contar Agorer porque lo vivió y se rió de mí en su día, ¿no?
Yo en 2004 monté mi primera empresa de desarrollo con tres amigos.
Y teníamos un cliente que representaba casi la mitad de nuestra facturación o quizá más.
Y este cliente era una empresa pequeña de telefonía, ¿no?
Y nos habían cargado, uno de los proyectos era un portal de clientes donde ellos se pueden registrar y demás.
Yo llevaba la parte del registro y una mañana pues me llaman, oye, hay tal cliente que no se puede registrar.
Y resulta que tiene un apellido extranjero con apóstrofe, con otros caracteres y la validación no le dejaba y no se podía registrar.
Entonces yo no tenía ni idea de lo que era un test, ni siquiera teníamos un entorno de pruebas, todo se hacía en producción y cada vez que compilábamos y desplegábamos, digamos, cambiamos el entorno, se perdía la sesión y los lugares tenían que volver a entrar.
Era un desastre, ¿no?
Y me llamó como 10 veces esa mañana por casos diferentes.
Y claro, yo no tenía test, iba ahí como un cowboy resolviendo este y cuando este resolvía se rompía otro.
Y bueno, al final del día lo que pasó, pues, os podéis imaginar, el cliente me llamó súper enfadado y canceló el proyecto.
Nos lo quitó, vio que no éramos solventes, estábamos haciendo mucho daño a su negocio y nos lo quitó y perdimos muchísimo dinero y la empresa se resintió mucho.
Entonces cuando después aprendí a hacer test dije, madre mía, lo que podíamos habernos ahorrado si hubiéramos sabido hacer test en ese momento.
Y en aquel entonces no era tan grave como hoy en día porque hoy hay tantas alternativas que los usuarios ni siquiera se molestan en llamar para quejarse.
Directamente se van a otro sitio y tú no te enteras, se van a otra aplicación online, otro servicio, van a la competencia y tú no lo sabes.
Entonces el coste de un bug en producción hoy en día es más alto que nunca.
Y la tolerancia de la gente es menor que nunca. La gente no tiene paciencia ninguna.
Si no funciona, bueno, me voy a la competencia y se acabó.
Entonces el consejo es que hay que reducir el mínimo la cantidad de bugs que llegan a producción, ¿vale?
De defecto y hay que impedir que aparezcan bugs que ya estaban corregidos porque eso hace que los usuarios pierdan la confianza, ¿no?
Si algo se reporta, se arregla y tres versiones más adelante vuelve a aparecer, perdemos toda credibilidad y toda confianza.
Muy bien. Ahora quería hablaros de las abstracciones. ¿Qué es una abstracción?
Bueno, pues cuando ponemos el nombre de una variable, una constante, un método, una clase, todo eso son abstracciones.
Es decir, representan conceptos y deberían de hablar de un dominio concreto, de un negocio, ¿no?
Si estoy en un taller de coches o una clínica dental, pues tendría que hablar de esas cosas y no hablar de primitivos, de booleanos, de abstract no sé qué y no sé cuánto.
Es decir, si la gente de negocio no habla de abstract no sé qué, pues evita que el código lo hable, ¿vale?
O sea, hagamos que el código utilice el mismo lenguaje que la gente que no es técnica y que, pero sí que son expertos en el dominio.
Y lo que pasa es que abusamos mucho de los primitivos, de los tipos integrados del lenguaje, ¿vale?
Primitivos, cadenas, colecciones, cuando deberíamos crear nuestros propios tipos sobre los que tenemos control y que pueden tener una semántica de dominio, ¿no?
Si yo tengo una visita o una cita, pues tengo mi tipo cita, no tengo un string con el código menos uno si no ha venido o si no está reservada, ¿vale?
No hago eso, no pongo valores mágicos para encriptar.
Entonces, dentro de lo que es core de negocio, deberíamos tener nuestros propios tipos y dejarlos, que son integrados del lenguaje para pintar en la vista, para la base de datos, para una HTTP, para enviar datos por la red,
pero dejarlos primitivos para eso, ¿vale? Y, bueno, en fin, los strings, todo esto.
Y otro problema de las abstracciones es que a veces queremos hacer el código muy genérico.
Entonces, decimos, bueno, esto es para una clínica dental, pero ya que lo he hecho, le doy un par de vueltas, lo configuro con YAML y no sé qué,
y me vale también para SpaceX, ¿no? Para el siguiente lanzamiento de cohetes que haga Elon Musk.
Y, claro, cuando haces eso, no tienes unos nombres que ponerle al código a los artefactos que creas, a las clases,
porque como es tan genérico, acabas poniendo nombres que son realmente marcianos, alienígenas, para ese negocio concreto.
Bueno, igual va de SpaceX, que va del espacio, los nombres alienígenas, pues, te quedan bien, ¿no?
Pero, vamos, en las aplicaciones que yo he hecho, acaban quedando unos churros que eso no entiende nadie a qué te querías referir.
Entonces, intentemos que los nombres sean concretos.
Vale, y la última regla es que hay que programar con una intención explícita, ¿vale?
No podemos programar de manera arbitraria de esto ahora lo hago así y después lo hago de otra manera y no hay una razón.
Es random porque según me ha apetecido, ¿no?
Incluso en el código donde estás, en el proyecto donde estás, intenta ir más allá de decir,
no, es que aquí esto se hace así porque las cosas se hacen así en este proyecto, en este equipo.
Eso, al final, es un dogma.
Lo que nos interesa es razonar lo que hacemos.
Cada línea de código deberíamos ser capaces de razonar de por qué la hemos escrito de esa manera.
Y si tiene, ¿y qué ventajas tiene? ¿Qué inconvenientes tiene?
Pues, esa es la regla, ¿no?
Busca que el código deliberadamente se vea qué intención tenías para programarlo
y que se vea que hay un sentido lógico razonado de cada línea de código.
Y eso es complicado y eso lleva tiempo, obviamente.
Pero lo recuperas muy rápidamente.
Es una inversión que haces una vez para toda la vida y que siempre está ahí, digamos,
que estás recuperando continuamente.
A mí lo que mejor me va para escribir código de esa manera es trabajar en pares,
pair programming.
Y sobre pair programming tengo un episodio del podcast que también lo enlazaré por ahí
que habla de qué significa eso y cómo se hace.
El principio de diseño que más me aporta para conseguir ese código es el principio de menor asombro
o de menor sorpresa.
En inglés lo abrevian como POLA, Principle of Less Astonishment.
Que lo que viene a decir es que, bueno, no sé, no sé si en el chat alguien sabe poner
qué significa o cómo explicaríais el principio de menor asombro en el código.
Para mí es el principio más importante de la programación, ¿vale?
Para mí es el número uno que yo me planteo cuando estoy trabajando.
Entonces, no sé si alguien ahí se anima a decir cuál es el principio de menor sorpresa.
Venga, que se anime la gente.
Que no te debe sorprender el código, dice Wolfero.
Buenas prácticas, hombre, eso es demasiado general.
Fácil lectura y comprensión, dicen por aquí.
Código sencillo, dice gente que acaba de escucharlo.
Limpieza de código y código ordenado.
Que tenga una intención detrás.
Que lo pueda leer un junior.
Que lo pueda entender hasta Midu.
Código optimizado, concentración de cosas, eliminar comentarios innecesarios.
Hay un montón de ideas ahí, ¿no?
Sí, hay un montón de ideas.
Vale, el código debería de hacer lo que tú piensas que hace cuando lees.
Tú imagina que estás leyendo un bloque de código y hay una llamada, una función, ¿no?
Y esa llamada, la función pone find user by name, ¿no?
Y le pasas una cosa que se llama name.
Pues tú no esperarías que ese código por dentro borre un usuario, ¿verdad?
Ni que actualice el usuario y le ponga un flag a no sé qué.
Sería una sorpresa.
O que envíe un email, ¿no?
Bueno, pues esto es un poco exagerado, aunque he visto cosas así.
Pero, en definitiva, es eso.
Si tú estás leyendo código, bueno, pues que haga lo que esperas.
Que haga, que sea natural, que no te dé una sorpresa.
Y esto es difícil de conseguir.
Y es muy importante.
Aquí os doy un consejo que a mí me ha aplicado, me va muy bien desde hace muchos años.
Y es que, en cada día, cada mañana, dediquéis 10 minutitos solamente a releer el código que escribisteis en el día anterior.
A ver, si sois un poquito humildes, sabéis que el día anterior no habéis escrito 50.000 líneas de código.
Con suerte, habéis escrito pocas y bien, más que muchas, ¿no?
Entonces, leer el código el día anterior no te va a llevar más de 10 o 15 minutos, ¿vale?
Pues en esa lectura, te va a parecer que el código es de otra persona.
Y eso que fue ayer, ¿no?
Que solo ha pasado una noche.
Y vas a ver posibles sorpresas.
Vas a decir, este código aquí igual sorprendería a alguien que lo leyese.
Bueno, pues ahí es cuando tienes que guiarte por este principio, el de menor sorpresa,
y hacer pequeños refactoring, como los que ha contado antes y otra, que son seguros, que son con el IDE.
Rename, extract method, inline method, cosas que son muy básicas y automáticas.
Eso es consejo que os doy 100%, que me funciona muchísimo.
O sea, empieza calentando tu día, te tomas tu café, ¿vale?
Y tu café, tu mate, tu bebida a la que te apetezca, un té.
Y entonces ahí piensas y lees el código, ¿no?
Como si fuera un libre.
Y dices, bueno, ¿qué significa este código?
¿Cómo lo puedo entender a otra persona que venga?
Muy bien.
¿Qué te hablamos de tiempo, Miguel?
¿Quieres que siga algo?
Vamos, Regulín.
Pero no sé yo si quiero tomarme el café y releer mi código del día anterior.
A ver si me va a sentar mal el café para la primera cosa que me tomo al día, ¿sabes?
Y decir, no, mierda, ¿qué hice?
Dios, qué asco de día tuve ayer.
Así que sería un poco...
Si quieres, lo dejamos aquí.
Comparto los recursos, ¿te parece?
Y ya está.
Sí, y te traemos otro día para hablar, porque aquí la gente está que le está volando
la cabeza a la peña, ¿eh?
O sea, la gente está como, Dios, había uno que decía, no quería hacer test en mi
vida y Carlos está haciendo que me entren ganas de hacer test, ¿sabes?
Pues no es que te entren ganas, es que te cambia la vida radicalmente.
Espera a ver si lo puedo hacer esto grande.
Totalmente.
Mira, mucha gente dice, muy buenos tips, quédate todo el día.
Mira, sigue hablándome al oído, decía, bueno, por aquí, no te conocía y me encantó.
Había gente que decía, necesito tu libro.
Bueno, lo tenéis por aquí, vale, me voy a pasar directamente, si esto carga bien, a las
likes de recursos, ¿vale?
El libro os lo enseño por aquí a cámara.
Sí, código sustenible.
Sí, ahí tenéis la URL.
Este es un buen momento para capturar pantalla, para que tenéis todas las URLs.
Mira, os digo una cosa, el código miduconf tiene un 20% de descuento.
¡Ojo!
Y solo va a durar 24 horas, ¿vale?
¡Ojo!
¡Dios!
Y el código midudef...
No, a ti te mando uno firmado o regalado que tengo pendiente.
Y el código midudef tiene un 10% y vale para siempre, ¿vale?
Porque gracias a Miguel Ángel, pues, estoy aquí y siempre puedes contar con ese código
un 10%.
Bueno, y luego, si queréis más sobre mí, tengo un podcast en Telegram, os podéis enterar.
Y vale, para el sorteo, ¿tú quieres sortearlo ahora o lo sorteamos mañana?
Lo sorteamos ahora, hombre, que está aquí la gente, está la gente que se está subiendo
por las paredes.
Vale, vale.
Yo os propongo sortear dos libros, entonces.
Uno ahora y el otro.
Las personas que se apunten a la newsletter de Savily, entre hoy y mañana, vamos a coger
todos los emails y le enviamos otros.
¿Vale?
Y el de ahora lo sorteamos como tú digas.
Si quieres, podemos llamarle al código sostenible o sostenible a secas.
Pongan en el chat código sostenible, todo junto, y toda la gente que pone código
sostenible en el chat entra en el sorteo del pedazo de libro de Carlos Blé, que es
que, a ver, yo creo que me encanta porque la descripción, siempre hablo de este libro
y digo, hombre, sería el libro, o bueno, esta misma charla, esta misma charla es la charla
que a mí me hubiera gustado tener cuando tenía, no cuando estaba de cero, porque cuando estaba
de cero a lo mejor estaba demasiado tierno, pero cuando ya tenía unos cuantos años y te
creía ya un poco el rey del mundo que decía, madre mía, esto está un poco chupado, ¿sabes?
Pero aún así decía, yo no, ¿para qué voy a hacer test con lo listo que soy?
Pues, a modo de colleja, a mí esta charla que he escuchado ahora me hubiera venido bastante
bien, ¿sabes? Bastante bien. Así que espero que mucha gente la haya visto así y que sobre
todo lo hayan apuntado, porque la verdad que estas son las cosas que realmente mucha gente
dice, oye, ¿cómo puedo ser senior? ¿Cómo hago a ser senior? Bueno, pues con muchas
de las cosas que ha dicho Carlos, que al final te das cuenta por la experiencia, ¿no?
Que es lo que te pasó a ti, Carlos, ¿no? Que a ti también decías, bueno, que sí,
que voy sobrado, pero que si en ese momento te hubieran dicho, venga, hazte una arquitectura,
y digo, claro que sí, claro que sí. Y luego, pues tu amigo, oye, por cierto, ¿en el libro
viene el muñeco? Mucha gente estaba preguntando.
No, la verdad es que no, pero no sé qué os parece, ¿ha caído bien Ágore?
Joder, sí, ha caído muy bien, ¿eh? Ha sido la estrella, en el chat estaba todo el
mundo, ¿viene en pack con el libro?
Pues igual hay que planteárselo. Bueno, oye, una cosita, nos pregunta mucho si en
Latinoamérica está el libro en papel, va a estar muy pronto, no está todavía, pero
si alguien lo compra en digital en Latinoamérica, cuando lo tengamos en papel, le descontamos
lo que pagó el digital, ¿vale?
Ah, qué bueno, muy bien, buen detallazo. Vale, pues vamos a hacer el sorteo, ya tenemos
aquí a 600 personas que están participando, ¿solo 600? ¿De verdad? No me lo creo,
dadle cañita al chat. Venga, os doy 5 segundos para que queméis esto. Bueno, ya se ve que
está subiendo, ya hay más, ya hay más gente, mil personas.
Está echando fuego.
Está echando fuego, la gente está refactorizando mientras escriben. Vale, 1.200 personas, 1.300,
vale, pues le doy, ¿eh? Amigos, amigas, vamos, a ver a quién le toca el código sostenible
y le va a tocar a Fosforus, Fosforus-M. Fosforus, felicidades, hombre, felicidades por el pedazo
de libro que te llevas y ya sabéis que tenéis la oportunidad de utilizar el código de MIDUCONF
durante 24 horas para comprarlo con un 20% de descuento.
Así que aprovechen, aprovechen, no se lo pierdan.
Pues nada, Agoré y yo, hasta que está alegre hoy, me voy a tomar unas cervezas con él ahora
que se las ha ganado.
Muy bien, a tu salud.
Así que muchísimas gracias a toda la gente que nos está viendo, ¿vale? Y a ti, Miguel, sobre todo.
Nada, muchas gracias a ti, Carlos. Muchas gracias no solo por la charla, sino por todo lo que aportas
a la comunidad con el podcast, que también lo recomiendo. De hecho, os dejaré en el chat los enlaces,
no solo para el libro, para que utilicéis el descuento, sino para que veáis la editorial
de Sabli, donde podéis ver tanto el podcast como el libro y más contenido que Carlos
y la editorial en general va a generar. Y, Carlos, muchísimas gracias por estar aquí.
Te mando un abrazo enorme y a ver si nos vemos la siguiente por ahí en Canarias
y nos tomamos un algo y damos un buen paseo por ahí.
Eso espero. Un abrazo grande.
Hasta luego, crack.
Qué bueno. Bueno, pues, Agoré. Espero, oye, esta charla, de verdad,
amigos, muchas veces me preguntáis, oye, quiero crecer en programación,
quiero ser senior, ¿y qué cosas necesito? Pues, estas experiencias como las que ha comentado
Carlos, es muy difícil a veces que encuentres un libro que te lo plasme también,
encuentres una charla que te lo plasme también. Y Carlos Ble es capaz de hacer esto.
O sea, es capaz de hacer esto. Es una persona que traslada las buenas prácticas,
el cuidado, la artesanía al código, muy bien, muy bien. Así que realmente espero
que hayáis disfrutado esta charla. Yo creo que es de estas charlas que hay que
poner en favoritos y escucharla no una vez, sino de vez en cuando para recordar
los principios que no podemos olvidar, ¿vale? Así que espero que la hayan disfrutado
mucho. ¿Cómo estáis? ¿Estáis todos bien? ¿Estamos todos cómodos?
Gracias.
Gracias.
Gracias.
Gracias.
Gracias.
Gracias.
Gracias.
Gracias.