89. Una de Programación, Formación y Publicación de Libros con Andros Fenollosa (Parte 1)

Esto es Webificando, el podcast de SideProjects. Hola, buenas, bienvenidas y bienvenidos a Webificando, el podcast de SideProjects. Hoy nueva temporada, misma manera de introducir. Bueno, un poco diferente. Primero de todo, Robert, ¿qué tal? ¿Cómo estás? Qué tal, bien. Después de las vacaciones que no he tenido, pero muy bien. Ya después de verano. No has tenido porque has querido cobrar, porque es lo que hacen los autónomos. No tenéis vacaciones porque queréis seguir cobrando. Cosas de freelancing. Entonces, pues bueno, eso te pasa por ser freelancer. A mí no me pasa eso. Y tenemos un crack hoy, tenemos un crack. A ver, ya lo estáis leyendo en el título del episodio. Es que todos los podcasts de mantener la... quién va a venir, quién va a venir, me hace mucha gracia. Porque en el título del episodio ya lo tienes. Pero bueno, antes de nada, antes de decir quién viene, que ya lo estás leyendo, de recordarte a ti que, si no tienes suficiente con las entrevistas de Wayficando, que sepas que tienes el Premium, en que cada semana tienes un episodio exclusivo, en el que ahí sí que podrás escuchar a Robert, ahí sí que lo dejo hablar, por solo 5 horas al mes. Así que wayficando.com barra Premium y ahí tienes un episodio espectacular cada semana, en que contamos nuestros intrínculos de nuestros proyectos. Lo que no decimos en el público, porque se lo preguntamos a los invitados e invitadas, es lo que decimos en el Premium. Así que suscríbete, no te lo pienses más. Y hoy tenemos al gran Andros Fenoyosa. ¿Qué tal, Andros? ¿Cómo estás? Hola. Te hice un chequeo de sonidos. Esto sí, aquí hay falta de aplausos, confetis. ¿Hay confetis? Bueno, la cuestión, estoy súper contento y de verdad, me estáis llenando de una energía. Yo venía con ganas, pero ahora tengo... Esto es una fiesta. Hombre, me siento orgulloso de ser el primero de la temporada. Por supuesto. Es un poco insignia para empezar. Haces muy bien. Es lo que tiene que hayas complementado el link que te envié de Kallen Lee y pusiste la primera fecha disponible. Entonces, eres el primero. Podría esperar. Yo digo, los quiero ya. ¿Cómo que tengo que estar el fin de semana? Bien que haces. Ahora es cuando nos empanamos y publicamos más tarde y quedaría súper raro. Sería fatal, ¿no? Menos mal que has dicho esto para que sepa que no he sido yo el que se ha equivocado. Habiendo todas cosas por medio. Exacto. Estamos obligados ya a publicar si o si el primero. Exacto. Obviamente, porque he dicho que era a principio de temporada. Esto lo que pasa es que en verdad los podcasts no lo puedes hacer porque teóricamente esto es evergreen. Los podcasts son evergreen teóricamente, pero nosotros no lo pasamos. Todas las normas de podcasting no las pasamos por el mismo. Bueno, Andros, primero de todo, yo tengo una pregunta muy clave. Como formador, como escritor que eres, como divulgador, como programador, como otras cosas, ¿a partir de qué edad tú crees que se puede empezar a programar? Guau, ¿a qué edad se puede coger un ordenador? ¿A qué edad puedes hacer tus propios videojuegos? Yo te podría decir que hoy en día, con las herramientas que tenemos, con cuatro años, con cinco, ya que tenemos juegos, sí, por ejemplo, el de Mario. ¿A partir de qué edad ya puedes programar? Sí, perfectamente. Ya tienes algunos juegos interactivos que tú ya puedes hacer tu propio Mario Bros o puedes hacer tu propio juego de rol. Hay un montón de cosas que no teníamos cuando nosotros, los tres nos incluyo, éramos mucho más pequeños. Eso es programar, porque... La pregunta que te haríamos, ¿tú no estás picando código? ¿No hay letras? Sí, porque le estás dando condicionales, tienes bucles, tienes, en un momento dado, que crear una especie de variables que van cambiando con el tiempo, son mutables. Entonces, ¿se puede programar hoy en día en el momento en que eres capaz de manejar un ordenador o una tablet? Qué bueno. Sería como programación en no-código. Al final montas juegos arrastrando bloques o cosas que no son código como tal, pero la lógica sí que te hace falta saber cómo van los bucles y lo típico. Efectivamente. Es muy interesante, porque yo creo que en las escuelas la asignatura de programación debería ser como transversal, ya casi, como de las básicas, porque te sirve tanto para ciencias como para humanidades, como para números, para cualquier cosa. Te sirve la programación en un futuro. Está en todas partes, pero también es verdad que esto es lo típico que decimos los programadores. No, es que tendríamos... Antes de que te enseñen historia, deberías estar ya con un ordenador picando ahí C para entender la base. Pero luego hablas con un matemático... Es que las matemáticas son en todas partes. Esto deberían enseñarlo desde pequeño. Luego hablas con algún físico. Es que la física es en todas partes. Entonces, al final, todos queremos... Yo creo que es también un impulso humano, forma parte del ser humano, el transmitir lo que hemos aprendido. Nos gusta mucho nuestra profesión. Entonces, también queremos que esa sensación la tengan los de nuestro alrededor. A ver, yo perdí la paciencia con mi primo pequeño. Yo le enseñé a hacer páginas web con 11 años. Vi que no le terminaba de molar. Quería más el cifra. Y dije, vale, hasta aquí. Hay gente que lo va a desear y le puedes guiar. Eso sería un formador. Tienes unas personas que tienen esa iniciativa, pero están despistados. Y tú, como buen guía, con una luz en la oscuridad, le tienes que decir, mira, ese es el camino correcto. ¿Por qué? Porque yo he pasado por todos esos y no llevan a ningún sitio. Y bueno, pues, básicamente eso. No sé si te contesta la pregunta. ¿Me he ido por otros sitios? Yo, es que como músico, también creo que es música cuanto antes mejor. O sea, yo empecé en música a los ocho años y yo espero que mis hijos empecen antes incluso que los ocho años. Y si no lo comen, o sea, ellos sabrán. Antes de cenar hay que tocar un poco la batería. Hay que ejercitar antes de cenar, que luego te quedas como yo de gordo. Bueno, es igual. Pobre niño, es que sin música, si programas no has puesto daño, no van a salir de casa en todo el día tus hijos. No, pero es que además puedes programar haciendo música. O sea, puedes hacer programación y música a la vez. Exacto. Y lo bueno de la programación es que puedes aprender otras cosas mientras programas. Porque te puedes hacer ciertos programas que te ayuden a aprender historia o que te ayuden a entender las matemáticas o que te ayuden a ciertas cosas. Ahí creo que tenemos un ámbito para explorar. ¿Y tú sabes los músicos, los buenos programadores que son? Hombre, por supuesto. Además, mira, yo creo que nos escucha David Anguera, que está en la comunidad web de La Activa, ahí hay publicidad para Dani. Es músico y está aprendiendo a programar. Y cuando ya lo domine, va a ser muy buen programador, porque él es músico también. Tal cual. Y yo lo digo por experiencia, porque tenemos una chica que está en prácticas, que ya antes se dedicaba a tocar en una banda. No sabemos por qué. Vio que le gustaba el tema de la programación, debe ser porque hay muchas matemáticas, aunque no lo parezca. Y esa combinación ha hecho que tenga muy buena intuición y sepa resolver muchos problemas. Es que la música, cuando compones, estás resolviendo problemas matemáticos, porque al final la música tiene unas reglas que tienes que seguir, igual que las matemáticas, son unas operaciones que puedes hacer. Entonces, aunque lo haces inconscientemente, porque al final te dejas llevar y estás componiendo tu cerebro, lo está haciendo por ti, tu cerebro inconscientemente está resolviendo estas reglas para que tú puedas componer. Entonces, claro, por eso los músicos acaban siendo buenos en matemáticas en la mayoría de casos. Porque también, claro, si luego no te pones a estudiar matemáticas, no vas a ser bueno en matemáticas. Pero sí que te da un pequeño push, te da un añadido. Pues, es muy interesante. Tú eres formador de adultos, de... De adultos, los niños ya... Les pasa. Ya, les pasa esa experiencia. Sí, me dedico en una academia actualmente a dar máster. Están muy orientados a todas las tecnologías web, como puede ser diseño web, obviamente, frontend, backend, intensivos de Python, de Closures lo intenté una vez, todo lo que va por esa área. Aunque me suelo centrar mucho más, sobre todo en el diseño web, lo que engloba, como el reforcing design, una buena arquitectura CSS, intentar que tu página siga unas reglas mínimas, para que tenga un buen SEO, para que... Ya lo sabéis, unas buenas metas para el tema de las redes sociales, cómo eso luego se publica, qué haces después de que se publica. Y muchas veces me toca también dar el máster de front con esos mismos alumnos, porque debe ser por presiones del mercado, es raro salir y encontrar un trabajo únicamente de diseño web. Te piden también tener ese front para conseguir ese extra, que no se consigue solamente con CSS. Eso es el núcleo principal de mis clases, y, bueno, de forma esporádica, pues lo que os comento, cosas de backend y cosas parecidas. Y estoy súper contento, os invito a todos los que me estáis oyendo y estáis dudando de si queréis meteros en el Mundillo... ¿Online o presencial? Es presencial, pero hay personas que están fuera del país o por X razones no pueden acudir a clase, y los tenemos también a la vez online. Aunque yo siempre he comido... En la academia se llama IDEcrea. IDEcrea.es. Claro, está en Valencia, ¿no? O sea, lo que es la escuela... Es que yo estoy en Valencia, ¿qué le voy a hacer? No, obviamente, obviamente. Pero hay opción de hacerlo online, que eso es importante. Sí, exacto. Muy bien, muy bien. Mola, mola. Primero de todo, es que me has dicho una palabrota y yo las palabrotas las fío de todo. Aunque creo que nos vas a hablar más adelante porque tiene que ver con tu primer libro. ¿Qué es Closure? Vaya, no pensaba yo que esto iba a salir. A ver, Closure es un lenguaje de... Puedo decirlo, ¿no? O sea, YouTube no corta esto... Es un lenguaje de programación funcional. Suele ser una evolución de lo que son los antiguos LIBS, todos estos lenguajes que nacieron en los años 70 han ido evolucionando esos... Como el Ómol o el Pascal o algo así. Exacto. Sí, era como la base de todo lo que conocemos hoy en día. Los paradigmas de la formación orientada a objetos y funcional nacieron a la vez, prácticamente con dos años de diferencia. Y estos lenguajes han sido base para crear los que hoy en día tenemos. Han ido creándose una especie de capas de abstracción que ha facilitado, no sé, el tema de recolectos de basura. Pues ya creamos Java o creamos Python, Ruby on Rails, que ya lo gestione por debajo. Oye, que ahora queremos ya no centrarnos en esa parte tan técnica, sino un poco resolver el problema buscando esa forma de... De aislar, no me salió la palabra, de dividir tareas, de hacer que unas variables no muten otras, para que tu código sea más fiable... Vale, pues vamos a crear... Ahí es donde yo creo que entraría Closure. Porque es un lenguaje que no solamente es funcional, sino que además se basa o se apoya en la máquina virtual de Java. Lo que hace que tenga lo mejor de ambos mundos. Es moderno y no solamente trabaja con código hecho en el propio lenguaje, sino también en la interpolaridad con Java y todo lo que envuelve al ecosistema. Entonces, para resumir, es un lenguaje funcional que funciona bajo la máquina virtual de Java y te permite hacer con una abstracción un poquito más elevada una arquitectura y unas soluciones mucho más limpias. Vale, dos preguntas. ¿Java es una fumada? ¿Closure es más fumada todavía o menos fumada? Hay un libro muy interesante que enseñan a una chica, Haskell, de cero. Y, claro, Haskell es una fumada para nosotros, para los tres que estamos aquí. Pero que alguien empiece de cero, no lo es. De hecho, en el libro se van resolviendo muchos problemas que nosotros mentalmente los tenemos estructurados de una manera para atacarlos, que desde ahí se hace desde otro punto de vista. Esta persona adquiere ese conocimiento y esas habilidades y le pasa justo al contrario. Cuando ve un lenguaje orientado a objetos, le parece una fumada. No entiende por qué hay un bucle aquí, no entiende por qué se puede modificar esta variable, si luego va a haber... Lo que quiero decir es que el problema no es el lenguaje, somos nosotros. Claro. Es como el que aprende japonés o chino y después tiene que aprender español o otro idioma muy distinto que es la fumada. Estos europeos están locos. Imagínate, oye, mi idioma es una fumada, no lo entiendo ni yo. Sí, sí. Hostias, entonces, closure, claro. ¿Pero tienes que aprender Java para aprender closure? No, necesariamente. Es difícil de meter en ese lenguaje o otros funcionales como Raquel o cualquiera, o Haskell, que lo he nombrado antes. No es tanto el lenguaje en sí, porque la sintaxis es rápido, de un fin de semana... En una tarde lees lo mínimo como se han pedido en condicional. Pati una, pa mi dos. Lo difícil es luego aplicarlo. Si yo ahora mismo te digo, a partir de hoy, no quiero que vuelvas a utilizar un bucle. O sea, un for ni un while... Quítate los for, quítate los while. Hostia. Es complicado. Te mato. Sí, sí, sí, un montón de código. O sea, hay como un montón de ifs, ¿no? Claro, ya estás, fíjate. Ya estás buscando con tus herramientas actuales cómo resolverías eso. ¿No? Pues tengo que entonces meter más de esto... Con el tiempo, tú sabes... Bueno, sabes, no. De forma intuitiva, a base de un reset mental brutal, también tengo que decir, eso lo podemos hablar más adelante, aprendes cómo funciona eso desde otro punto de vista. Porque ¿no me has dicho? En esa lista de soluciones rápidas que te han venido ahora mismo, hacer una repulsión, hacer una iteración de una lista y modificarla... Cosas que hago a veces, aunque no utilizo estos lenguajes, que ya las hago a veces. Sí, las haces, pero no es tu core, no es tu corazón. Yo las hago cuando tengo que optimizar. Exacto, lo haces como un complemento, ¿no? Cuando me sobra tiempo. En plan, vale, está tardando demasiado. Eh... Sí, sí, ostras, qué bueno, qué bueno. Claro, de hecho, en la newsletter que publico una vez a la semana, siempre pongo un ejercicio y tres reglas. Una es, no puedes utilizar variables, tiene que ser todo constante, es inmutable. No puedes utilizar bucles, como te estoy comentando. Y la tercera, creo que puedes utilizar el lenguaje que te dé la gana. Porque también quiero dejar caer ahí que no es tan importante el lenguaje en sí, sino tú cómo lo apliques, cómo sea tu metodología o tu forma. ¿Cómo es el código? Sí, o sea, no es tan importante... Es como un teclado, da igual. Si tú eres un buen programador, que te da igual que sea el que te ha regalado McDonald's con el Happy Meal, tú sabes hacer el código de muchísima calidad. Anico no nos hace mejor programadores. No, lo siento. Alguien tenía que decirlo. Pues lo mismo pasa. Si tú cumples esas tres buenas formas de trabajar, eso se va a convertir en tu forma de trabajar. Qué bueno. Una pregunta, Andrés. Tú como formador y para gente que quiere empezar en el tema web, ¿dónde empiezas por esto, que es lo más fácil o lo que te va a motivar más porque no hay tanto... No te vas a dar tantas hostias para empezar. Entiendo que va a que no, sabes más cosas que contestar en el chat mail, supongo. Ahora sí te he entendido. ¿Qué recomiendo por dónde tirar? ¿Cómo empezar? Alguien que no tiene ni idea de... Yo quiero empezar con temas web. ¿Qué tengo que aprender? Y que me sirva en plan ya, para que la gente que se frustra mucho empiece, no le salen las cosas y lo deja, lo abandona. Yo empecé con CMH, que empecé ya así por la mano. Yo también he pasado por ahí. He dicho, esta vez vamos a empezar con Bootstrap. No, no ha funcionado bien. Vamos a tirar por WordPress, a lo mejor por Blocker. Bueno, a ver. Según mi punto de vista, que no significa que tenga toda razón, lo mejor es empezar por cosas muy sencillas. Primero, que el alumno asimile de que va a haber un camino. Al principio va a tener mucha ilusión, luego se le va a acabar, va a necesitar trabajar mucho, tiene que haber una disciplina y se tiene que dar cuenta de que va a pasar por fases. Una, la primera, en los primeros dos días, la mitad de mis alumnos quieren cambiarse de clase, porque eso les parece superraro. Muchos vienen con la idea de que hacer webs es un Photoshop, que tú le das a exportar y mágicamente. Y la pregunta recurrente es, pero no hay ningún programa que haga esto. Hay que ponerse así a escribir. Hay el CART. Claro, hay CMS, hay plataformas online. De eso estamos de acuerdo, pero si tú quieres hacer una web, tú, con tus recursos de cero, tienes que pasar por aquí. Entonces, normalmente suelen ser dos semanas, tres horas al día, solamente con HTML. Después, un mes, mes y medio, solamente CSS. Un pequeño tiempo, no sé, deciros una semana, dos, solamente de reposing design, como coger todo lo anterior y enfocarlo para hacer páginas responsive. También un poquito de SASS suele venir muy bien. Para mí es básico a la hora de maquetar. No he dicho en ningún momento Tailwinds ni ningún framework. Una vez eso ya está sólido y tú te sientes que eres capaz de llevarlo, damos un poquito más de complejidad, le damos estructura al CSS. ¿Cómo podemos dividir los archivos? ¿Dónde metemos las variables? ¿Cómo vinculamos? ¿Cuáles son las mejores estrategias? Y cuando está asimilado todo eso, pues ya yo asumo que tiene la capacidad suficiente y podemos pasar a herramientas que ya están hechas, como un framework, como si fuera un bootstrap o lo que sea. Un Vue, un... Sí, cualquier cosa. ¿Cómo se llama el otro? Ahora me van a matar. Tienes el Bangle, tienes el Bulma. El Bulma, yo lo utilizo este. El Bulma. Es precioso. Yo soy súper fan del creador. Yo soy fan porque es de Son Goku, bueno, de Bola de Drac, ¿sabes? También es verdad. Es el nombre de la Bulma de Bola de Drac. Bueno, Bola de Dragón o Dragon Ball, depende de los idiomas. Entonces, yo utilizo el Bulma. Sí, es muy cómodo, porque simplemente pones la clase que te dice el tutorial que le tienes que poner y ya está. Y te olvidas. Totalmente. Pero claro, el problema está en que si empiezas por ahí... Esto es el debate eterno. ¿Se empieza con un framework o se empieza de cero? Puede darse el caso que tú avances muy rápido al principio, pero sea un espejismo, o sea, no sea real. Tú sientas que eres un buen diseñador, que en un mes, madre mía, mirad todo lo que he hecho, pero yo te quito esa herramienta y no entiendes nada. Eres incapaz de hacer un contenedor sencillo que además se vaya adaptando, o no sabes ni siquiera cómo centrar un cuadro en un exo. Eso es imposible. Eso no se puede hacer. Eso es imposible. Dicen las lenguas que se puede. No, eso es imposible. Centrar un div es imposible. Hay que sacrificar una cabra... Hay que hacer hechicerías, hay que hacer brujería para centrar un div. Si le dices el Closure y haces spam de tu libro... Vale, es genial. Es tu primer libro, ¿no? Es que me gusta mucho el nombre. Te lo digo yo. Don Clojure o Don Closure de la mancha. El ingenioso lenguaje funcional del paréntesis. ¿Eso es porque hay que estar loco para hacer esto? ¿Acabas loco cuando lo dominas o cómo va? ¿Dónde está el símil? Fue por una cuestión de negocio. Fue porque vi un hueco y no hay, incluso hoy, contenido en castellano sobre el lenguaje. No había ni comunidad. De hecho, lo empecé yo junto con un amigo. Creamos un grupo, hablamos con otras personas que habían intentado también hacerlo, reunimos. De hecho, recuerdo dos personas que me vinieron a la escuela solamente para hablar, para concretar detalles. Y poco a poco fuimos creando esa comunidad. Yo terminé el libro, que en realidad fue una manera de llevar mis apuntes a algo un poco más sólido, de más calidad. Y, bueno, pues así empezó todo. La verdad es que hice más cosas, aparte del libro. También con ese conocimiento adquirido hice una plataforma de comentarios. Hice un framework que se llama Tadam. De hecho, luego, si queréis, os paso el enlace. Puedo mejor ayudarte. Tengo tu GitHub aquí, tu GitHub aquí al lado. Luego lo haremos de proyectos. Luego, en la segunda parte, hablamos de side projects. Y este libro lo autopublicaste tú, ¿no? Este primer libro que he autopublicado. ¿Qué tal es autopublicar un libro? Vale, mira, esto es similar, ya que vosotros dos sabéis hacer páginas web. ¿Cuál es la diferencia entre tú hacer una web? Todo, ¿eh? El diseño, el UX, la implementación, la programación, el marketing. ¿Cómo es ese proceso? ¿Es largo? ¿Hay áreas que no dominas muy bien? Sí, algunas áreas. Es lento y si es perfeccionista no acabas nunca. Exacto. Y, además, nunca va a estar bien del todo. Siempre va a haber... Sí. Siempre va a haber una pata que te va a cojear. Pues un libro es igual. Te lo tienes que comer tú todo. Y luego, cuando estás en un editorial, dices... Yo he sido tonto, yo tenía que haber hecho aquí. El problema, esa es mi opinión personal, es que hay mucho ego también. Y uno dice... No, no, este es mi proyecto, quiero estar yo solo, no quiero tener ataduras. Pero, bueno, luego la realidad es que la calidad no es tan buena. Pero, claro, no es fácil llegar a una editorial si no tienes publicado nada antes. O sea... A no ser que te llames Belén Esteban, es difícil que una editorial te dé un libro así como así. O sea, yo creo que antes tienes que demostrar algo, ¿no? No sabría decirte por qué. Puede ser que tengas razón. Con el segundo libro ocurrió al revés. Fueron ellos los que me llamaron a mí. Y me dijeron que querían que lo hagas con nosotros. Y no sé si es a raíz de esto y otros proyectos que tenía, que a lo mejor influenciaron. Puede ser. Pero es verdad que nadie, en cualquier proyecto, te va a llamar a la puerta y te va a decir que vente. Claro, yo creo que también ayuda... Porque a lo mejor te hubieran contactado igual, porque a lo mejor te hubieran conectado con tu web de eventos que has estado, como formador, etcétera. Yo creo que cuando vieron que ya tenías un libro, pues quizás fue más no-brainer el hecho de decirte. A lo mejor hubieran tenido dudas entre tú y otra persona. Sí. Pero al ver que ya tenías un libro, quizás... Puedo ser decisivo, ¿no? Yo creo que debe ayudar el hecho de haber escrito... No sé, creo. No tengo pruebas, pero tampoco tengo dudas. No sé qué hacer. Vale. Tengo una pregunta con esto. ¿Comparar el primer libro con el segundo, el tiempo que dedicaste, en plan de medio año o un año, o no sé cuánto tiempo dedicaste al primer libro, y cuánto al segundo? ¿Te ahorró mucho tiempo? Al revés. Gaste mucho más tiempo. Fue mucho más estresante. Me gasté más dinero, luego entramos en ese detalle. Pero la calidad se nota. Ese esfuerzo se ve recompensado. A lo mejor hiciste un esfuerzo por tres, pero la calidad es por diez. Exacto. Luego entraremos en detalles, porque hablaremos también de la editorial. Vale. Eres escritor de esta editorial en tu Twitter. Y, claro, yo cosa que veo, cosa que me traigo para aquí. Yo soy muy básico en ese sentido. Antes de acabar, para acabar el tema Closure, para hacer un Closure de Closure, lo estaba haciendo encima, eh. Yo, claro, que ya quería... Para hacer un Closure de Closure, ¿qué aplicativos tienes con Closure? O sea, ¿qué puedes acabar creando? ¿Es más para apps? ¿Es más para webs? ¿Es para todo? ¿Es Closed Platform? Actualmente se utiliza muchísimo para microsistemas o para hacer unas funcionalidades críticas. Tú haces una pequeña API o una función, lo que sea, tú la llamas y, bueno, recuperas el resultado. Y a nivel profesional, estoy dándole vueltas y también lo estoy utilizando de esa manera. Eso no significa que puedas hacer una aplicación para el escritorio, ya que por detrás tienes ya toda su GUI para montarte lo que te la gana. Una cosa es lo que te permite el lenguaje, otra es cómo los seniors suelen utilizarlo. Vale. O sea, está más ambientado para tenerlo como una especie de API para que te haga cálculos, ¿no? Sí, sería más similar a un Go en el sentido que está muy ligado a todo lo que son procesos aislados o isolados. Son, al final, una manera de obtener... La palabra en inglés, isolated, ¿no? Te viene la palabra en inglés. A mí también me pasa. A mí también me pasa. Sí, estaba como era, como era. El problema está en que tú a veces tienes unas funcionalidades muy, muy importantes que no te puedes permitir el lujo de que falle, por ejemplo, un avión que tiene parte de Closure por detrás. Otros lenguajes también, no es el único. O puede ser que tú tengas una funcionalidad muy crítica que necesitas un gran rendimiento, pero claro, Java a veces puede ser problemático, necesitas como una capa extra de abstracción que te lo asegure. Si tienes que actualizarlo, no sale el avión, ¿eh? Eso, de hecho, el 737 MAX, el famoso avión que hubo un par de accidentes, tenía este lenguaje por detrás. No tuvo nada que ver. También lo tengo que decir. No es una buena publicidad, ¿eh? No, no lo es, pero tenía que sacarlo. ¡Ja, ja, ja! ¡Qué bueno! Vale, o sea, está más orientado a procesos internos, más que... Y si quieres hacer un programa, pues utilizas Java como para la UI, ¿no? Exacto. Muy bien. Interesante. Vale, pues ahora sí, vamos a hablar de tu segundo libro. Vamos a ver... Que tiene un nombre, un nombre... A ver, Andros, con total sinceridad, tienes que hacer... O sea, yo no puedo aprenderme este nombre, porque yo soy de memoria muy... muy de banana, manzana y pera, y me sacas de ahí y yo no puedo memorizar. Así que lo voy a leer con tu permiso. Building SPAs with Django and HTML over the Wire. Está en inglés, ¿no, el libro? Perfecto. Sí, totalmente en inglés. Learning to Build Time Single Page Applications with Python. Todo esto es el título del libro. Y SPA significa... Single Page... Application. Esto lo he leído esta mañana, ya me acordaba. No lo sabía, no lo sabía. Eh... Ostras, o sea, es para hacer aplicaciones de una sola página, básicamente, con Django y HTML. ¿Qué significa over the wire? Sé que significa en inglés, pero no en el contexto de programación. Vale, esto es muy interesante. El título en castellano, pues si hay alguien ahí que no se ha entendido, no por tu pronunciación, sino por... Bueno, a lo mejor no domina bien el inglés. Es Construyendo Aplicaciones de una Sola Página con Django y HTML en la... En the wire, en el... En hilo, ¿no? En línea, ¿no? Sí, en línea, en streaming. Podría ser también una traducción. Eh... ¿Qué es esto? Es una técnica. Esto no va ni sobre HTML ni sobre Django. Va sobre que ahora mismo hay una nueva forma de resolver el tema, de obtener información en el backend y enviar al front en tiempo real, pero sin depender, que ese es uno de los grandes problemas que tenemos actualmente, de construir una API y además a coger un framework en JavaScript para construir, para generar, renderizar todo el DOM. O sea, ¿cómo podemos quitar toda esa complejidad, pero conservando lo bueno, que a nosotros nos gusta como desarrolladores? Vale, pues aquí es donde entra el HTML over the wire. Funciona de la siguiente manera. Tú tienes, por un lado, un servidor y, por otro, tú tienes el front. Bien. El cliente, el ordenador. El navegador. El navegador, el navegador y el servidor. Vale, perfecto. Tú necesitas que esa página, la que se está visualizando en el navegador, sea dinámica y no quieres que se refresque la página entera. Me explico. Si yo pulso la página de contacto, Twitter, imagínate que tú cada vez que le das al botón de ver más tweets, ver la siguiente, toda la página te refrescara. No, yo es que le clico, yo es que lo veía a F5, soy así de gilipollas. ¡Ja, ja! Este sistema contigo no funcionaría bien, ya te lo digo yo. ¡Ja, ja! Claro, si eso fuera así con todo, no lo del F5, sino que tú fueras pulsando con cada uno de ellos, ver settings, ver opciones, y se te vuelve a refrescar la página. Esto funciona en muchos sitios así, y vamos, los aceptamos como animal de compañía, pero la realidad es que tú cuando quieres fluidez, rapidez, tú necesitas que los elementos vayan apareciendo, que se vayan ocultando. ¿Qué está ocurriendo? ¿Está todo ahí, en la página de esto oculto? No, lo que está pasando es que el servidor... Es megagrande. Claro, envía, imagínate, te descargas internet en un diskette, como en los 90. Se está haciendo una llamada, oye, dame esa información, y la proporciona. Vale, volvemos al caso anterior. ¿Cómo funciona actualmente? Pues el front le hace una petición a través de IaaS o de cualquier protocolo, el servidor genera esa información, envía un JSON o envía un contenido, de igual formato, y cuando lo tiene el front dice, vale, sí, muy bien, o sea, el navegador tiene toda esa información en crudo. Vale, ¿y ahora qué hago con todo esto? Tengo que montarlo, tengo que mostrárselo al usuario final. Aquí es donde entra un framework de JavaScript. Va construyendo, pues, de X manera, va creando todos los módulos. Vale. Es lógico pensar que no puedes hacer nada más, así funciona el mundo. Pues no, aquí es donde entra... Tiene la solución con su libro. Exacto, ahí estamos. Bueno, porque la solución está en mi libro. Y solo lo que... O sea, claro, o sea, di algo. Mira, lo dejo aquí y, vamos, por cada oyente me compro el libro. Pero no voy a ser tan malo. ¿Cuál es la alternativa? Pues es que el front haga una petición, le diga, oye, toc, toc, señor Bakken, necesito que me muestre este apartado, los siguientes tweets, lo que sea, y dice nuestro señor servidor, vale, pues yo lo que voy a hacer es generar todo el HTML que tú vas a necesitar. O sea, no te voy a dar la información cruda, te voy a dar el HTML y te lo voy a enviar. ¿Por dónde? Por WebSockets. Ahora hablamos por qué WebSockets. Se envía... Esa base. ¿Qué tiene que hacer el navegador? Absolutamente nada. Coge el contenido y lo mete donde le diga el Bakken. Claro. ¿Qué consiste con eso? Primero, que el navegador no tenga la lógica de negocio. No lo necesita. Él simplemente es un intermediario. Eso es para que no te hackeen tanto, ¿no? Exacto. Y para no dividir el equipo en dos, para que todo el desarrollo esté únicamente en un sitio, en tu servidor. Lo segundo que consigues es que no dependes de ningún framework de JavaScript, obviamente. No hay nada que renderizar, lo único es coger lo que te dicen y ponerlo donde te dicen. De hecho, un poco por daros... también meterme un poquito más a nivel técnico, es enviar un JSON con tres campos. Uno que se dice la ID donde se tiene que mostrar ese contenido, otro con un bloque enorme del HTML que se va a inyectar en ese sitio y el último, un parámetro que te dice la URL, como quieres mostrárselo al usuario. Solamente eso. Vale. Y pam, lo muestra. Oye, que alguien me ha pulsado un botón, que es el de abrir un modal, ¿no?, para escribir el nuevo tuit. ¿Qué hacemos? De forma tradicional, esa parte estaría oculta, se ve un componente, se quita una clase, se muestra... Vale, aquí no, porque no está en el front. El front dice, oye, me han apretado este botón, el de escribir un tuit. Lo recibe el servidor. Vale, quiere escribir un tuit y nada más veo que es el usuario Pepito. Vale. Genera el bloque de HTML, se lo envía y le dice, oye, colócamelo en esa ID. Y además, para que vea el usuario dónde está, cámbiame la URL. Y ya está. Ya está. Qué bueno. Entonces, en el back, en el servidor, estaría Django, ¿no? En este caso... No es Django, eh. No os confundáis con Django, que no es el cantante. No es Django, es Django. La película de Trampino. También. Es que como tenemos público de varias edades, pues hay gente que habrá ido para el cantante y otra gente para la película. Para ambos. Entonces, Django está en la base edad. En el back. En el servidor. Y el front es HTML puro y duro. Bueno, con CSS, supongo. El CSS también viene del servidor. Todo. Absolutamente todo lo que ve el usuario. Yo lo que veo es que comparado con React o Vue, o al final estas cosas que se han puesto de moda de webs acopladas, que es todo, la mayor fronten, en este caso es casi todo backend. O sea, es un concepto... Todo backend. Esto lo contrario, en ese sentido. En esos partes, entiendo que el rendimiento sea mejor, se pueden encajar muchas más cosas. Pero bueno, que es... Pues mira, te puedo comentar. Te puedo contar experiencias que hemos tenido haciendo proyectos para clientes. El primero es que los front se toca las narices. No hacen absolutamente nada. Porque solamente se hacen en eventos. ¿A dos en todos los front? Ya hemos terminado. O sea, empezamos temporadamente... ¿Hemos tenido un público? No, no, no. Es que siempre, en cada episodio, hay algún colectivo que nos puede cancelar. Entonces... Hay alguien que pilla siempre, sí. Ya, vale, lo reformulo. Los de front tienen mejor vida. No nos importa. Trabajan menos y cobran igual. Exacto. Cobran lo mismo y trabajan menos. De hecho, Robert cada noche tiene unos cuantos... Programadores... Bueno, Build... ¿De WordPress? Enseñadores, WordPress y algunas otras tecnologías, sí. En su casa, cada noche con antorchas y ya está acostumbrado. Así que no te preocupes, Andros. Te puedes... Lo siento mucho. Si necesitas que vaya yo con mis antorchas, espadas, para defenderte, me lo dices. Perdona, ya está. No, nada, eso. Por un lado, tú consigues esa parte, le quitas mucha carga y así se pueden dedicar a otras cosas que son, yo creo, más interesantes, como el tema de animaciones, el tema de carruseles, o de jugar con las propias APIs del navegador. Siempre eso es interesante. Y te llevas todo el HTML, porque al final tú tienes que renderizar, necesitas un motor para hacer HTML, donde tú puedas tener tu cabecera repetida por página, donde puedas tener tus pequeños componentes. Eso te lo llevas al backend, que es mucho más sencillo. Indiscutiblemente. O sea, esto estoy muy seguro. No sé qué voy a hacer nada de esta noche, pero de esto ya os lo digo yo que sí. Al estar unido con la base de datos, es súper rápido tener condicionales, tener ahí también tus propias iteraciones, tus bucles, lo que necesites. Es cómodo para todos. ¿Se consideraría esto un monolito? Sí, creo que sí. Sí, sí, sin duda. La única forma en que se conectan ambos, también es que no me he metido en el tema, es a través de un servidor de WebSockets, porque al final la comunicación tiene que ser bidireccional. Y eso implica que tenemos de regalo dos o tres ventajas extra. Una de ellas es que es instantáneo, en tiempo real. Sí. Otra es que tú puedes cachear, tú puedes decirle al navegador, oye, cada vez que yo te envíe algo de HTML, me lo guardas en la propia memoria del navegador, y si vuelvo o tú vuelves a pedirme lo mismo, no te molestes. Coge lo que tú ya tienes y se lo muestras al usuario. Luego ya podemos jugar con tiempos o tal. En cuanto empiece a navegar un poco por tu web y necesita volver atrás, es instantáneo. No tienes carga sobre el servidor. Qué bueno. Imaginemos la cabeza de Alphute y el sidebar, que siempre es lo mismo, y solo cambias el contenido central de cada una de las páginas. Exacto. Qué bueno. Y luego, ¿qué más? Hay cambios en el servidor. Cuando hay cambios en el servidor, pues porque un agente externo le ha hecho un cambio al servidor, como es WebSockets, se lo notifica al front-seeker, al floreta que está preguntando todo el rato, hay novedades, hay novedades, hay novedades, hay novedades, hay novedades, hay novedades, hay novedades, hay novedades, hay novedades, que es como se hacía antes de WebSockets. No, no, no te vayas tan lejos, que yo sigo entrando en páginas web y veo que cada dos por tres, cada segundo, se está haciendo una llamada de Ajax y yo digo, esto lo he visto yo, en PHP es lo que hay. Justo, digo, esto es PHP, por detrás. No os engañen. Correcto, correcto. Qué bueno, qué bueno. Es que esto de WebSockets, yo lo domino un poquito, porque lo utilizo, utilizo el tema de WebSockets. Yo me he quedado que es un monolito para cosas en tiempo real, que no sabía que con monolitos se podía hacer, porque se me han dicho, no, no, en tiempo real tiene que ser todo desacoplado. Es un... No tiene por qué. A ver, ¿lo puedes conseguir? Sí, claro, te llevas el servidor de WebSockets a un servidor, te llevas el servidor de HTTP, porque no olvidemos que necesitas dar, sobre todo si entra un motor, ¿no?, como Google o cualquier buscador, necesitas darle una página estática en HTML, que eso ya te lo proporciona el propio Django, perfecto, no tienes que hacer nada. Bueno, te puedes llevar eso a otro sitio, te puedes meter, yo no sé, el poquito HTML a otro sitio, puedes hacerlo, pero yo es que estoy bastante en contra de los microservicios. Yo creo que un web monolito, bien gestionado... Sí, la base de datos te la puedes llevar fuera, eso me da igual. ¿Qué lenguaje? ¿Da igual el lenguaje? Sí, a mí eso me da igual. A mí eso me da igual, da igual que esté hago un node con JavaScript y haga la misma antrología. Perdón, me refiero al lenguaje SQL, ¿da igual? O sea, da igual si es... Bueno, el tipo de base de datos, que no me he expresado bien. Si es MongoDB, si es Moskres, si es MariaDB, si es MySQL, da igual. Lo que sea la propia tecnología no es importante, sino la arquitectura, es cómo tú lo montes. Es que el libro, a pesar de que esté orientado en Python, que además yo lo elegí para que fuera lo más abierto posible y mucha gente pueda aprenderlo, de hecho en el libro yo llevo de la mano al lector, es como si fuera, eso lo dije en otro podcast, es como si yo te llevo en un curso de la manita, te voy enseñando cada uno de los conceptos separados, porque es importante, y luego terminamos haciendo un proyecto real que engloba todo el contenido. Entonces... ¿Era de pública web? Puede ser. Porque si me parece lo escuché. Lo que yo escuché es cuando... El mismo, ¿no? Lo que estoy diciendo. Cuando ahora estaba presentando el podcast, que creo que te invito para hablar del libro. Sí, exacto. Pues nada, lo que quiero decir es que no importa que sea Ruby, no importa que sea Node o Dino, me da igual. Si tú haces una buena estructura y sabes lo que estás haciendo, el lenguaje no importa, ni el framework ni nada. Muy bien, muy bien. Esto es muy interesante. Así que, porque a veces nos ofuscamos en que tiene que ser este lenguaje, este framework, este no sé qué, es un... Bueno, tranqui, tranqui. Claro. A lo mejor... Es que la realidad es muy diferente. Acabas tocando muchos lenguajes y muchas herramientas. No te puedes cerrar. El mismo conocimiento que tú utilizas para enviar un formulario, procesar las validaciones, mostrar un mensaje de error, lo puedes hacer en cualquier lenguaje. Porque tú tienes el conocimiento dentro. Tienes HTML, CSS, lo que se muestra finalmente. O sea, a partir de aquí, lo que tú quieras. Exacto. ¿Dónde podemos comprar el libro? Pues el libro lo podéis comprar, a ver que lo vean mis apuntes, en Pack, en Aureli, en Amazon.es y en Amazon.com. Amazon.es, Amazon.com, Aureli, Pack, que se escribe P-A-C-K-T. Exacto. Lo tenéis con la suscripción o lo podéis comprar de forma individual. Yo sé lo que es, pero te pregunto, ¿qué es Pack? Vale, es un editorial. Siguiente pregunta. A ver, es... Sí, es una... Yo creo que todos hemos tenido un libro pirata de ellos en algún momento de nuestra vida. Por cierto, mi libro ya está pirata, lo podéis buscar también, no os lo recomendaría nada. Compradlo, compradlo, hombre, compradlo. Y si lo hacéis, me envíais el dinero, ¿vale? Me lo pirateáis y lo tomáis. Yo digo, po, vale, una con la otra. O le hacéis una donación. Esta editorial ha sido muy famosa porque ha tenido el valor de meterse con muchas tecnologías, muchas técnicas que eran bastante, bueno, difíciles de vender y ellos han abierto las puertas a ello. De hecho, tiene una biblioteca enorme de todo lo que te puedas imaginar. Tienen su sede en Reino Unido, pero gran parte de los trabajadores se hacen en la India. De hecho, no sé, el 90% de la gente con la que he interactuado era de la India. Y son muy, muy profesionales, mucho más de lo que os podía transmitir hoy. Tienen cursos solamente para prepararte a la hora de empezar el libro. Yo pasé por seis revisores diferentes, cada uno estaba especializado en un área. Tuve un calendario marcado, pero además notaba que había experiencia detrás. Sabían por dónde tenían que enfocar, sabían cómo hablarme, sabían qué tono yo tenía que utilizar. La verdad es que yo lo recomiendo mucho. No solamente Pax, sino meterse en un editorial grande para que te enseñe. Yo creo que incluso ahora soy mejor profesor que antes, o al menos a la hora de escribir el contenido, no lo voy a hacer igual. Esto nos lo dijo Emilio, cuando vino Emilio Canut, podcaster que vino también, que nos habló de su libro y tal, que el hecho de haber estado con una editorial le ha mejorado cómo escribir, aunque él ya escribía bien, pero se ha dado cuenta de ciertas cosas para escribir aún mejor. Y para la actitud, que también en su habla le ha ayudado incluso. Qué bueno. Es todo un mundo. Ahora entiendo que has comentado antes de... Es mucho más tiempo, pero la calidad es mucho mejor. Hombre, claro, con seis revisiones por medio y con un curso que te han hecho al principio, pues se tiene que aumentar, pero claro, mucho más tiempo dedicado. Una vez yo escuché el tema de que tú escribes un 15% y el resto del tiempo son revisiones. Y yo digo, qué exagerados. Pues no, no, sí, sí. O sea, hay que decir... Cuando... Esa es la cantidad de borradores. Bueno... Y sí, tú escribes un capítulo, tú lo lees, orgulloso, ahí tomando tu café con tu bata ahí de señor, y dices, listo está, vamos. Luego llegan a los otros, estas frases no se expresan bien, tienes que hablar en tercera persona aquí, esto deberías poner aquí un pequeño párrafo donde explique este concepto. Y tú lo vas leyendo y dices, puede que me hacen algo de razón. Y luego también esto lo explicaste en el anterior capítulo, esto ya lo has vuelto a explicar, o aquí lo explicaste de otra manera y ahora aquí no se entiende, cosas así que pueden suceder, pero... ¿Habría coherencias entre capítulos? Esto tenías que haberlo explicado en el capítulo 1, esto es software privativo, no lo pongas... Mira, os puedo comentar... que lo peor, el peor error que he cometido, bueno, peor no es en la palabra adecuada, digamos que donde más pecaba era la longitud. Yo estaba muy claro que el libro iba a tener X páginas. Y yo siempre me pasaba. Había capítulos, no sé, de 25 páginas y otro que va a 50. O... no, era de 20 y entre que hay 50. Sí, ese, vamos, ese me tuvieron que hacer una reunión. Ese tuvieron que hacer un meeting conmigo para decir... a ver, es que queríamos un libro más pequeño, más de consulta rápida... Y yo, es que no puedo sintetizar más, es que no necesito para explicar estos conceptos. Y te das cuenta de que cuando empiezas a hacer bien las cosas, no te repites, no hay paja. Es que es difícil explicar esto. Digamos que cuando tú de verdad haces bien las cosas, tú necesitas un espacio para respirar, para que ese concepto entre con los ejemplos necesarios. Y, bueno, a veces entra en conflicto con la realidad. ¡Ja, ja, ja! Y pensando que hay párrafos de libros de que los lees y dices, no han dicho nada, como un político, y otros de que los lees y... A ver, un momento, que me vuelvo a leer porque me he dejado algo aquí, o sea, demasiado denso. Muy complejo, muy complejo. Muy complejo. Bueno, pues mira, estoy viendo aquí en la web que si estás suscrito a Packet, puedes leer el libro de Andros for free. Así que, ojo, cuidado. Y si dices, no, pero a ver, es que hay más ilusión tener el e-book de Andros, si solo por 10 pounds, no sé cómo será en euros. Ni idea. No sé si será 10... No, no, no, no está en Amazon, pero... Pero pues tener el e-book con la suscripción en Packet por 10 pounds. Así que, bueno, que no está mal. En Amazon creo que está por 20 algo, creo que he visto. Está actualmente por 23, en Tapa Blanda por 31 y os anuncio que en una semanita, dos como mucho, vamos a publicar un vídeo, yo hablando sobre él y habrá un pequeño descuento. Puede ser que este episodio, cuando tú lo publiques, puede ser que el vídeo lo publiques antes que este episodio. Así que puede ser que ya esté publicado, así que atentos a las notas de este episodio o a la segunda parte, porque si sale una semana después, lo pondré en las notas de la segunda parte para que vayáis rápido a ver el vídeo y tengáis el descuento. Yo se lo digo de que cuidado con la inflación, que compradlo ya al libro, entonces que subo más de precio. ¡Jajaja! Perfecto, pues yo creo que podemos cerrar primera parte. Ahora la segunda parte, vamos a hablar más de otros proyectos de Andros, porque al final el libro también es un side project, es un proyecto. Vamos a hablar de proyectos más de programación, vamos a hablar de cositas que ha hecho que te pueden ser útiles en tu día a día, porque hay uno, un proyecto que te puede ser útil, aunque no seas programador, te puede ser útil en tu día a día. Y hablaremos de más cosas. Esto la semana que viene, así que no te lo pierdas. Stay tuned, stay tuned, como dicen los británicos.