El pulgar lo uso para tener siempre cargando el mega buster en el Y, y saltar con el B. Pero la mayoría de las veces necesito saltar con el A para hacer la deslizada rápida (dash) hacia adelante. También se puede hacer el dash apretando dos veces el d-pad en la dirección en la que queremos ir. Pero es mucho más práctico usar un botón.

Por cierto, siempre empiezo en la pantalla de Chill Penguin. Es donde encontramos la cápsula que nos da la armadura para las piernas, lo que nos permite usar este poder. Para mí siempre fue la primera pantalla de Mega Man X después de la introducción. Es una mecánica esencial el resto del juego.

Mi manera de jugar no es la más cómoda, así que se me ocurrió escribir al respecto en el blog. Creo que hace poco charlamos de este tema con mi primo en una sesión de Nintendo Online

Seguramente los controles fueron diseñados pensando en que al momento de saltar, uno usaría el pulgar sobre el A y B para poder moverse mejor. Pero yo necesito estar cargando el mega buster todo el tiempo. Más allá de que tengo prácticamente memorizado dónde van a aparecer enemigos en todas las pantallas de tanto que lo he jugado, necesito estar cargando mi mega buster, por las dudas.

¿Ustedes también? ¿O son normales y usan el pulgar sobre el A y B? ¿O son más normales todavía y no juegan juegos de hace más de 30 años? Estoy seguro que hay algún hack o una forma más práctica de hacerlo, pero yo todavía no la he encontrado.

En versiones modernas como Mega Man X Legacy Collection, podemos remapear el A al L o R, lo que lo hace infinitamente más cómodo. Pero en el Super Nintendo original, no queda otra que sufrir el A. Aparte si me acostumbro a usar un botón distinto en otra plataforma, cuando vuelva al Super Nintendo voy a sufrir porque tengo que volver al A.

Por cierto, usando el control 8 BitDo Pro 2, me di cuenta que no puedo jugar a Mega Man X en Mega Man X Legacy Collection. Este control está diseñado de forma más ergonómica, y tiene como una elevación en la parte de atrás del control para un mejor agarre. El problema es que el dedo índice y el mayor quedan más separados y tendría que hacer un estiramiento doloroso para alcanzar el A. Así que el dedo mayor pasa al botón R, y todo el peso de la parte derecha del control cae sobre el meñique y el anular (imagen).

No es lo ideal, así que para esos casos tengo que usar el control de Super Nintendo o mi viejo y querido 8BitDo SN30 Pro que ya está pidiendo cambio pobre.

Ese fin de semana jugué hasta vencer a todos los Mavericks, juntar todos los corazones y tanques y conseguir el hadouken. Tengo el password guardado para volver e intentar vencer a Sigma una vez más y terminar el juego. Mega Man X es uno de los mejores juegos 2D que existen, y me encantaría recordar la primera vez que lo jugué. Esta vez cuando termine, voy a ver si vuelvo a Mega Man X2 en Legacy Collection e intento terminarlo. Tanto X2 como X3 he llegado lejos, pero nunca los terminé, tareas pendientes...

El juego fue desarrollado por Petoons Studio, un estudio independiente de videojuegos fundado en Barcelona en 2017. Aspiran a crear juegos y juguetes mágicos para niños y familias de todo el mundo. El equipo es una mezcla de artistas, desarrolladores de videojuegos y educadores. Tienen amplia experiencia en el desarrollo de juegos infantiles y familiares para PC y consolas de algunas de las marcas más populares del mundo: Peppa Pig, PJ Masks, Bratz y Monster High, entre otras.

Es un clásico juego de plataformas 3D. A primera impresión me hizo acordar a los títulos de Bob Esponja que jugué anteriormente en Switch, SpongeBob Squarepants: Battle for Bikini Bottom Rehydrated y Spongebob Squarepants: The Cosmic Shake. Además de los gráficos coloridos, la música tranquila y el estilo del juego, toma la misma decisión de saltar con el botón A en vez del B como nos tienen acostumbrados otros juegos. También puede que tome inspiración de series como Banjo Kazooie (o más recientemente Yooka-Laylee) o Crash Bandicoot.

Está disponible para PC, Xbox, PlayStation 4, PlayStation 5 y Nintendo Switch. Yo lo vengo jugando en mi Nintendo Switch 2.

Una de las primeras cosas que me gustó es que está disponible en español. Pero no sólo los subtítulos y la interfaz de usuario, los personajes tienen voz en español. Me gustó mucho escuchar las voces de distintos personajes en español, le agregan mucho carácter a la ambientación del mundo de Dracamar. ¡También vemos carteles con texto en Catalan! Si bien mi conocimiento de Catalán es muy reducido, me encantó verlo. Mi conexión familiar con Palma de Mallorca hace que no pueda evitar identificar algunos paisajes con la isla.

Hace años que no como unos buenos canelones...

En el inicio elegimos entre uno de 3 personajes: Caliu, Foc y Espurma, pero podemos cambiarlo en cualquier momento. Todos juegan igual, las diferencias están en la apariencia. A lo largo de la aventura podemos ir obteniendo distintos atuendos para personalizar más al personaje.

Comenzando la partida nos encontramos con una pantalla tipo tutorial. Nos enseña cómo jugar, las habilidades de nuestro personaje así como información de los ítems que vamos a ir encontrando. En cada nivel tenemos una serie de objetos coleccionables siguiendo el legado de este tipo de plataformeros 3D y que a veces se denomina "Colectatón".

¿Se acuerdan cuando coleccionábamos figuritas? Tratando de completar el álbum. O tarjetas intercambiables de deportes o personajes ficticios. Supongo que esto es lo más parecido que tenemos hoy en día...

El juego cuenta con 15 niveles normales y 5 extra. Además de enfrentar a enemigos, plataformas y puzzles, tenemos que explorar para lograr encontrar esos coleccionables. Los niveles son bastante grandes y a veces hasta se hacen un poco largos. Me hubiera gustado contar con un mapa del nivel para saber dónde ya he estado, y que facilite encontrar los objetos escondidos. De todas formas se premia la exploración en general y el volver a jugar una pantalla para encontrar más secretos.

Nos van a acompañar unos seres mágicos, Okis. El malvado dragón Rey Crad ha absorbido la energía de Coroki y la convirtió en energía negativa. La usa para transformar a los Okis en Mokis, una versión oscura y malvada de los Okis. Tenemos que rescatarlos y recoger la energía negativa que liberan en forma de moki-bolas para reconstruir los puentes entre las islas.

Los Okis son unos bichitos adorables y se siente un poco mal tener que atacarlos para liberarlos. Pero los desarrolladores incluyeron la habilidad de acariciarlos. Así que el primer rato del juego me pasé acariciando a cuanto animalito me encontrara. Particularmente a los que me sentía mal por haber golpeado para sacarles la energía negativa...

Lo que más se destaca de este juego para mí es la ambientación. Los gráficos, el diseño de los ambientes y la música tienen un encanto particular.

Es un juego sumamente accesible, el nivel de dificultad en general es bajo. Además de las plataformas y puzzles en cada nivel, hay secciones variadas más rápidas como partes con toboganes, deslizándonos por rieles al estilo Sonic, siguiendo la corriente de un río en un inflable o niveles en los que pilotamos un avión. Esto le agrega un poco de variedad al estilo de juego. También hay pantallas de bonus donde podemos obtener más estrellas.

Los personajes cuentan con un doble salto y un ataque con Y que los hace girar y golpear cosas alrededor (tanto enemigos como elementos del ambiente). Encontré que combinando el doble salto con el ataque, a veces podemos alcanzar cosas que están más lejos. En ese sentido me dió un poco un aire a Super Mario Odyssey.

Hay 7 jefes finales, donde la dificultad salta un poco. En mi caso porque perdía intentando aprender cómo atacar a cada jefe. Lo molesto de esto es que cada vez que perdemos contra un jefe, tenemos que volver a jugar una parte donde "llegamos al jefe" que no aporta demasiado, y saltar la presentación del jefe a mano. Esto se vuelve tedioso bastante rápido. Pero una vez que entendemos los patrones de cada jefe, no es demasiado difícil vencerlos.

Hay varios personajes con diálogos en las distintas islas. Por ejemplo en la isla donde encontramos uvas y viñedos, un trabajador nos dice "tengo la espalda doblada de tanto recolectar uva". Habría que convencerle de armar un sindicato. Otro en tono medio agresivo pasivo comenta "podrías echar una mano, ¿no crees?". En la ciudad nos cuentan que con la invasión de Moki se han cancelado los partidos de fútbol!

Todo esto suma a la ambientación del juego, y me dejó muy contento volver a ver después de muchos años la palabra recórcholis.

Dracamar es un juego que sigue la fórmula clásica de plataformas 3D con una ambientación especial que le da un encanto particular. Recomendado si les gusta este estilo de juego. Para completistas, hay contenido para rato. Creo que es ideal para jugadores de cualquier edad, pero particularmente para los más jóvenes (y quienes no somos jóvenes, pero tenemos mente de niño).

• Página en Steam
• Página oficial

Al igual que con FreshRSS, estoy suscripto al feed de lanzamientos. De esta forma me entero cuando se publica una versión nueva y necesito actualizar mi instalación. FreshRSS viene corriendo en Docker, pero Navidrome lo tengo instalado a nivel sistema. Y no hay un repositorio de dónde actualizarlo, así que hay que hacerlo a mano. Pero como soy vago, escribo scripts.

En primera instancia decidí escribir un script en Ruby:

Obviamente no todo es tan fácil en la vida como escribir un script Ruby y ya está. En la Raspberry Pi tenía la versión de Ruby del sistema, que era bastante antigua. Creo que algo no anduvo de primera, y pensé "bueno, puedo editarlo para que funcione con un Ruby más viejo, tampoco es un código tan complejo". Pero decidí que era hora de tener un gestor de Rubíes en mi Raspberry Pi. La uso para tanta cosa, que quiero tener la libertad de escribirle scripts en Ruby cuando necesite.

Así que en eso me puse a instalar rbenv en la Raspberry Pi y ruby-build desde git para poder instalar Ruby 4. Mientras tanto, me puse a probar de implementar el mismo script con Bash. En algún momento me di por vencido porque sabía lo que necesitaba pero no sabía cómo hacerlo con jq.

jqes como sedpero para JSON. Se puede hacer un montón de cosas al estilo awk, grep y sedpero con JSON. El tema que no lograba encontrar el código exacto que me permitiera hacer el equivalente a package = data['assets'].find { |a| a['name'].match?(/arm64\.deb/) } en Ruby.

A todo esto estaba charlando con mi amigo Gonza, con el que siempre charlamos de éstas cosas, sobretodo cuando estamos haciendo algo copado. ¿Ustedes no hablan con sus amigues de los scripts que están escribiendo? ¿O de sus Raspberry Pis? ¿No usan XMPP? Bueno, problemas tenemos todos. En eso Gonza encuentra la sintaxis que preciso para que ande el jq y lo comento online. Lo comparto acá porque la respuesta que se mandó Gonza es digna de ser compartida: siempre distrayendo de lo que importa, estoy para trabajar en los medios (enlace, síganlo y denle "favorito").

Y con la pieza que faltaba, quedó el script en Bash:

Ahí queda de referencia para quien le pueda venir bien (y para mí cuando me olvide cómo hacer alguna de estas cosas).

Recientemente se publicó la versión 2.54 de Git, el sistema de control de versiones distribuido. Esta incluye un comando nuevo experimental git history que permite cambiar el texto de un commit en la historia, o dividirlo.

Al ser experimental, el comportamiento puede cambiar en versiones futuras. Pero por el momento lo podemos usar como comento por acá.

En lo personal estoy muy acostumbrado a usar git rebase para cambiar la historia de un repositorio. Entrando a un rebase interactivo con git rebase -i se puede elegir el commit y hacer un reword para cambiar el mensaje o edit para dividirlo, entre otras cosas. El objetivo de history es hacer que esta tarea sea más fácil. Tengo tan memorizados los comando git que uso a menudo que me va a costar, pero estoy intentando probar git history.

Para explicar estos comandos, voy a usar de ejemplo el código de ci_uy. En la consola ejecuto git lg y veo lo siguiente:

Primero veo cómo cambiar un mensaje de commit con git history reword. Supongamos que quiero cambiar el texto del commit 5f916fb (Corrige teclazo accidental). Ejecuto:

Esto llama el editor de texto configurado en el sistema (en mi caso Emacs, siempre Emacs...) con el texto del commit: "Corrige teclazo accidental". Le agrego un punto al final, guardo, y quedó editado el mensaje. Los hash de éste commit y los siguientes se actualizan:

Para probar git history split, podemos usar de ejemplo el commit d4606fa que tiene dos cambios (Actualiza encabezado de licencia, metadata de gema). Ejecuto:

Esto nos muestra el comando interactivo de Git donde van apareciendo todos los cambios del commit. Nos pregunta qué queremos hacer con cada uno (a efectos de esta acción, si incluirlo o no). Lo primero que me aparece es el cambio de licencia, así que lo agrego y hago un commit con esa parte sóla:

Respondo que no a todos los cambios que le siguen y git me vuelve a mostrar Emacs para agregar un nuevo mensaje de commit. Me trae el mensaje viejo "Actualiza encabezado de licencia, metadata de gema". Así que borro todo lo que está después de la coma y guardo. Al guardar y cerrar, aparece nuevamente el editor de texto con el mismo mensaje anterior. Este va a ser el mensaje de commit del resto de los cambios, así que escribo "Actualiza metadata de gema." y guardo y cierro. El nuevo estado de la historia:

Son comandos bastante prácticos, creo que sí terminan ahorrando tiempo. Veremos si me termino de acostumbrar o sigo usando git rebase -i por costumbre. Tendré que estar atento para ver cómo evoluciona git history. Para empezar a usarlo, podemos instalar la versión 2.54 de git en nuestro sistema.

Instalar la versión más reciente de git

Si usamos alguna distribución Linux basada en Debian, podemos agregar un PPA oficial que ofrece la última versión estable de Git:

En la página de instalación hay información para más distribuciones Linux y otros sistemas operativos: Fedora, Gentoo, openSUSE, Mageia, Nix/NixOS, FreeBSD, Solaris, OpenBSD, Alpine, Red Hat, Slitaz y más. Como es habitual, también podemos compliar la versión más reciente desde el código fuente.

Día 1

El primer día llegué un poco tarde. Calculé mal los tiempos y me fijé los horarios de los trenes muy tarde. Viajé desde Edimburgo a la estación de Queen Street, que queda a unos pocos minutos de la Central. Había una calle cerrada por un incendio grande que hubo recientemente. Sabía de esto y la organización incluso en alguna de las comunicaciones nos lo recordó. Pero a la hora de planear la ruta más eficiente posible para caminar hasta el lugar, me olvidé. Eventualmente me encontré en la calle Esperanza.

Cuestión que una vez que llegué y me acredité, ya había empezado la primera charla: What happened to RubyGems and what can we learn? (¿qué pasó con RubyGems y qué podemos aprender?) por Mike McQuaid. Me quedé afuera porque la idea de entrar a la sala e interrumpir la charla o que todo el mundo me quedara mirando porque llego tarde me causó mucha ansiedad. Una vez que conocí el lugar un poco mejor me di cuenta que no era para tanto. Pero bueno, así es la ansiedad.

Por suerte la charla también fue presentada en Fosdem 2026, y está online en el sitio web de Mike McQuaid. Imagino que de repente fue parecida, aunque con un público más familiarizado con en el tema. No había espacio para preguntas entre las charlas, así que tampoco es que hubiera generado discusión ni nada. Pero en el enlace está el video a la charla de Fosdem que imagino es similar.

La segunda charla estuvo a cargo de Jess Sullivan: How I Upgraded Rails (and Only Broke Production Once) (Cómo actualicé Rails [Y sólo rompí producción una vez]). Estuvo interesante, comentó su experiencia y los pasos a dar para actualizar Rails a "Rails edge", la última versión. Recomendó ir subiendo de una versión menor a la vez (ej.: 7.0 a 7.1), tener muchos tests, saber cómo revertir código puesto en producción y más. Acá fue una de las pocas veces que escuché "Podés usar AI para esto", pero hablaré más del tema más adelante.

Developer skills worth learning when AI can write code (Habilidades de desarrollo que valen la pena aprender cuando "AI" puede escribir código) por Sue Smith me gustó mucho. Al tener esas dos letras juntas en el título, "AI", mi primera reacción es de rechazo. Pero fue una charla muy equilibrada e interesante. Comentó cómo es importante reconocer que lo que estamos viendo entorno al término "AI" es marketing. Que a la vez genera un estado de miedo por nuestros trabajos y se usa mucho como excusa para hacer despidos masivos. La utilidad y el impacto de los LLMs varía muchísimo.

Están surgiendo patrones. La forma en que se está imponiendo en la industria hace que personas en una etapa temprana de sus carreras no vayan a adquirir las habilidades que necesitan. Esto genera una brecha en la comprensión a nivel de un proyecto. Puede ser un factor en cortes de servicio, problemas de seguridad, mitigación más lenta de incidentes.

La idea que escribir código no es necesario gracias a los LLMs tiene una desconexión con las habilidades implícitas. En esta parte me resultó súper interesante aprender sobre las habilidades implícitas, que uno no siempre es consciente de tenerlas. Mencionó por ejemplo conducir y llegar a un lugar sin necesariamente recordar el camino hasta ahí. Son habilidades que se vuelven persistentes. 

La habilidad es algo repetible. Por eso tratar a los prompts como abstracción es problemático. La salida de un LLM no es repetible, no es un sistema idempotente. Habló de varias cosas desde un punto de vista pedagógico, cómo revelar nuestras suposiciones lleva a conocimiento compartido. La metacognición, ser consciente de nuestros procesos de pensamiento y patrones. Los LLMs facilitan evitar aprender, pero también presentan oportunidades. Hay bastante pedagogía en la programación que podría ser complementada con LLMs.

Hay un balance en cuan profundo hay que entrar en el código para enseñar/aprender algo y qué se podría delegar. Generar código puede ser contraproducente porque escribir el código es parte de explorar el problema. Hay valor en el proceso, no sólo en el artefacto que se produce. A veces hay un valor oculto que se pierde, el código actúa como una representacion compartida de un sistema que nos permite razonar y actuar sobre él de forma confiable. Es un lugar valioso para construir modelos mentales.

Sue Smith comenta sobre esta charla en su blog, y ahí también se encuenta un enlace a la presentación con las notas y todo. Ah, y ya tenía varias razones para hacerlo, pero creo que me terminó de convencer que tengo que mirar The Golden Girls.

Aji Slater de thoughtbot dió una charla titulada How to build a haunted house (Cómo construir una casa embrujada). Cuando empezó la charla, no tenía ni idea dónde iba a llegar. Durante los primeros minutos recorrió la historia de un rifle Winchester, Winchester 73 si no recuerdo mal. Pero todo cobró sentido cuando desencadenó en Sarah Winchester, cuya residencia es conocida como la Mansión Winchester (y la conexión con el arma viene por ser la viuda del magnate dueño de la empresa Winchester). 

Acá se mencionó DragonRuby, una de mis herramientas preferidas en Ruby. Me sentí muy identificado con la razón para usar DragonRuby. Aji entró a despotricar contra el estado general de las cosas (me encantaría poder citar textualmente esta parte, porque empecé a sonreír como un idiota mientras escuchaba) y cómo DragonRuby es como una escapatoria que te hace recordar por qué te gusta la programación.

Hace unos años en un Bootcamp implementó con su equipo un juego en JavaScript. En el juego implementaron una casa embrujada con cuartos generados de manera procedimental. Decidió volver a ese proyecto y reimplementarlo con DragonRuby. Durante la charla habló de los distintos algoritmos para crear un juego procedimental y mostró ejemplos de código. Estuvo muy buena y muy interesante, y siempre me alegro cuando veo DragonRuby en una conferencia.

Acá cortamos para ir a almorzar. Terminé yendo a almorzar a un lugar de comida mexicana con mi amigo Peter y un grupo de gente que tuve el gusto de conocer en el momento. Las charlas durante el almuerzo estuvieron muy buenas. Terminé hablando con alguien con quien resulté tener una conexión laboral y aprendí un poco más de la génesis de cosas que eventualmente definieron mi historia laboral. Muy meta, interesante.

La vista desde una de las ventanas del edificio donde se realizó la conferencia

A la vuelta del almuerzo hubo un panel con James Bell, uno de los organizadores de la conferencia, como moderador. Los participantes fueron oradores que estuvieran de alguna forma conectados al tema de comunidad, organizando eventos y grupos: Hana Harencarova, Jess Sullivan, Murray Steele y Peter Aitken. Hablaron de algunas de las motivaciones, desafíos y otros aspectos de trabajar en formar comunidad.

Las motivaciones van desde devolver a la comunidad, conocer gente que está haciendo lo mismo e intercambiar ideas, opiniones, etcétera. Una de las recompensas, si bien no va a ser la misma experiencia para todo el mundo, es conseguir trabajo, o conexiones que eventualmente nos sirvan para conseguir trabajo.

Uno de los grandes desafíos es traer más gente a una comunidad, y particularmente llegar a grupos más diversos de gente. También se habló sobre el burnout, o quemarse con el trabajo. Es difícil balancear trabajo con familia, tiempo libre y además hacer este otro trabajo que en la mayoría de los casos no es pago. Me da la impresión que las intenciones son buenas, como resultado comunidades entorno a Ruby que siguen siendo amigables, amables y acogedoras.

Carme Mias presentó Under the hood - exploring digital assistive technology  (bajo el capó - explorando tecnología de asistencia digital). Comenzó con una cifra, el 24% de las personas que trabajan en el Reino Unido tiene una discapacidad. La accesibilidad otorga la habilidad a personas con discapacidad a acceder a las cosas. Aprendí que los sistemas operativos tienen sus APIs de asistencia y las aplicaciones acceden a esta API. Mostró ejemplos de cómo funcionan los lectores de pantalla en distintos navegadores web y mencionó la importancia del text Alt en las imágenes.

Fue una charla muy interesante para aprender más del tema. Hace mucho que no hago desarrollo web, pero debería dedicarle un tiempo a aprender más sobre accesibilidad y empezar a implementar cosas en este blog mismo. Carmen compartió un enlace a Web Accessibility Initiative de la W3C que puede resultar interesante para empezar a darle más atención al tema en el desarrollo web.

Donal McBreen habló sobre Making Solid Cache the Rails Default (haciendo Solid Cache el por defecto en Rails). Fue una charla bastante técnica. Aprendimos sobre la biblioteca Solid Cache, cómo surgió la idea, la política de eliminar caché antiguo con FIFO y los desafíos con los que se encontraron.

A eso de las 17:00 terminó el primer día de la conferencia. A las 19:00 estaba planeado un evento con ceilidh (pronunciado "keili") en Drygate, una cervecería de Glasgow. En gaélico escocés, cèilidh es como una visita, como caer en la casa de alguien a charlar (opcionalmente para contar historias y cuentos, tocar música o bailar). Pero el ceilidh moderno es un evento con baile donde una banda en vivo toca música folklórica y quien quiera puede bailar. Es muy divertido y no hay que saber bailar para participar. He ido a más de uno y creo que parte de la gracia es ir aprendiendo el baile y hacerlo mal, está la mayoría de la gente en la misma.

Estaba agotado y ya había tenido suficiente exposición social por el día. Así que me fui con un amigo de Glasgow a un pub para tomar unas pintas y ponernos al día. Estoy seguro que el ceilidh estuvo muy divertido y se pasó bien.

Día 2

El segundo día me preparé para salir con más tiempo y llegar temprano. En la mañana y entre las charlas habían recreos en la sala compartida. Podíamos nutrirnos con café, té, agua y algunas golosinas como galletitas, brownies y flapjacks (la traducción que se me ocurre es que son como unas barritas de cereales artesanales ). También estaban las mesas de sponsors, con stickers y demás elementos esponsorizados.

Como en la conferencia anterior, James pedía que durante los recreos siguiéramos la "regla de Pac-Man": Cuando charlamos en un grupo, no cerremos el círculo. Dejemos un lugar abierto, de manera que el grupo visto desde arriba se vería como la forma de Pac-Man. Así dejamos lugar para cualquier persona que se quiera unir a la conversación. Y cuando una persona nueva se suma, asegurarnos de dejar otro lugar para darle la bienvenida a alguien más.

Hana Harencarova dio la charla What working in a high-performing team taught me about shipping my own projects fast and while having fun (Qué me enseñó sobre lanzar mis propios proyectos rápido y divirtiéndome trabajar en un equipo de alto rendimiento). Hana trabaja en un equipo distribuido en GitHub. Con "equipo de alto rendimiento" se refería a un equipo eficiente que también se toma su tiempo para descansar y hacer cosas fuera del trabajo, no que trabajen 80 horas por semana. Tienen el concepto de DRI - Directly responsible individual, como que cada parte del sistema tiene una persona que sabe qué hacer o dónde si pasa algo.

Hana contó de varios de sus proyectos personales implementados con Ruby. Muchos de ellos súper específicos a sus intereses. Hubo más instancias de esto en otras charlas, y la idea que con Ruby podemos hacer uso "personal" de la computadora escribiendo código para necesidades personales. Hana comentó que en una época de su vida leía las convenciones de estilo de Rubocop para irse a dormir

Colin Gemmell de FreeAgent habló de Replacing React with Hotwire for developer happiness (reemplazando React con Hotwire para la felicidad de los desarrolladores). Había tenido la oportunidad de ver una charla similar a ésta por Colin en uno de los meetups de ScotRUG. En el momento me dieron ganas de desarrollar cosas web para probar Hotwire. La charla fue técnica, compartiendo las experiencias y el objetivo de cambiar todo detrás de cámaras y que los usuarios ni noten el cambio.

Tuvieron una muy buena experiencia. Empezaron con Backbone + Handlebars, luego Backbone + React, después Redux + React. React no estaba funcionando para FreeAgent y Redux es muy complejo. Tenían serie de componentes que llevaba muchísimo trabajo cambiar en React. Casi enseguida después de migrar a Hotwire, otros equipos empezaron a actualizar cosas y trabajando en el frontend "se siente como trabajar en Rails".

Murray Steele presentó la charla What's Ruby fo(u)r? (Un juego de palabras que puede leerse como "¿Para qué es Ruby?" y "¿Qué es Ruby cuatro?"). La idea era presentar lo nuevo en Ruby 4, pero repasando la historia de Ruby a nivel del lenguaje. Empezó con los proto rubies, las versiones antes de 1.0 que iban armando el lenguaje y definiendo cómo iba a ser en el futuro. Si no recuerdo mal (y entiendo las notas que escribí), habló de la evolución de los bloques y definición de métodos en Ruby 0.49 y 0.76.

Siguió recorriendo las versiones 1.x y los grandes cambios o características nuevas que aparecían en cada una. Saqué un montón de apuntes, pero creo que sería demasiada información para este post. Pero Murray tiene una página web con la presentación. Promete tener la presentación entera con la transcripción en el futuro. Estuvo muy divertida y nostálgica. Hace muchos años que vengo prestando atención a Ruby.

Cerró con la idea que comenté más arriba de que Ruby es para uso personal de la computadora. Para manifestar nuestras ideas en la computadora, es un lenguaje optimizado para la felicidad humana, así que lo facilita. Comentó de varias aplicaciones también personales que desarrolló con Ruby. Entre ellas una que le dijera qué bebida tomar, lo que me hizo acordar a una aplicación que quería desarrollar para elegir qué tomar cuando iba a Ennis Pub en Tres Cruces hace muchos años. Por último, nos invitó a divertirnos con Ruby.

Miranda Heath habló desde un punto de vista académico sobre Burnout in Open Source: a structural problem we can fix together (Agotamiento en Código Abierto: un problema estructural que podemos arreglar juntos). Creo que mucho de lo que habló de agotamiento también aplica al trabajo. Entre las señales de burnout (no sé si "agotamiento" significa exactamente lo mismo), está la clásica que algo que nos daba placer o alegría cambia a pavor. Con el agotamiento vienen la falta de motivación, fatiga, cinismo y negatividad, escapismo, humor negro y más.

En el mundo del código abierto mucho trabajo se hace por altruismo, pero varios factores aumentan las posibilidades de que alguien se canse y lo abandone. Los problemas que señaló fueron la (falta de) paga, la cantidad de trabajo y compromiso de tiempo, mantener código puede ser un trabajo poco graticicante y la hiper-responsabilidad en los proyectos. Me gustó la analogía de cómo un Pull Request es "free as in free puppy" (gratis como en un cachorrito gratis). Si alguien te regala un cachorro, es un regalo que tenés que cuidar por el resto de su vida. Los generadores de slop, LLMs, son también generadores de cachorros de regalo para proyectos de código abierto.

Las comunidades pueden resultar tóxicas, la gente actúa como si tuviera derechos o con exigencias. He tenido experiencia con este tema con mi plugin de WordPress. De acá surgió la duda de si Ruby era una comunidad tóxica, y hubo discusión al respecto más adelante.

Un punto importante que señaló es que "No es tu culpa". Algunas de las formas en las que podemos mejorar la situación es consiguiendo que la gente que trabaja en código abierto reciba remuneración adecuada. Mencionó Open Source Pledge,un grupo de empesas con el compromiso de pagarle a desarrolladoras de software código abierto. Su objetivo es establecer un nuevo modelo social en la industria para dejar atrás el burnout y problemas de seguridad. También agregó que trabajemos juntos, colaboremos y compartamos la responsabilidad. Construyamos relaciones de mentoreo y particularmente compartamos el amor.

Cortamos para el almuerzo y a la vuelta había dos opciones. Una era el workshop Event Sourcing, but in Ruby por Ismael Celis con laptops en el piso 8. Yo asistí a la otra, una actividad al estilo Lean Coffee en el salón principal. Moderada por Colin Gemmel, se agregaron temas de conversación a un pizarrón con post-its. Después los votamos y se llegó a 4 temas a discutir. Nos dividíamos en dos grupos, conversábamos y después nos juntábamos para compartir las conclusiones. Los temas fueron los siguientes:

• Cambio de contexto - discutimos varias formas de lidiar con el cambio de contexto en el trabajo. Se mencionó la técnica pomodoro y variaciones. Compartí mi experiencia porque el cambio de contexto es parte esencial de mi trabajo actual (y supongo que de muchos trabajos de programación). Comenté que no tengo ninguna técnica especial, simplemente escribo notas de las cosas para ir guiándome en lo que tengo para hacer. Pero mi aporte fue que en mi caso con la experiencia se ha ido haciendo un poco más fácil.
• ¿Deberíamos abandonar Rails? Rails es el framework Ruby más popular. Pero su creador es un racista imundo supremacista blanco. Discutimos cómo usando Rails indirectamente le estamos dando poder y una plataforma para que vomite sus repugnantes puntos de vista. Hablamos de Hanami como alternativa, forkear el proyecto, pero no recuerdo si alcanzamos una conclusión específica.
• ¿Es Ruby (como comunidad) tóxica? Hablamos de que la gente que se acerca a Ruby es generalmente creativa y apasionada. Así que se ha documentado mucho el drama en la comunidad. Se bromeó sobre levantar los sitios para phpdramas.com, pythondramas.com, etc. Creo que el consenso fue que Ruby es una comunidad acogedora y de gente con buenas intenciones.
• Comparte tu momento feliz de Ruby - Para terminar en un punto alto, compartimos distintas experiencias relacionadas a Ruby que nos hicieron bien. Hubo más de una mención sobre cómo usando Ruby se pudo ayudar a otras personas a entrar en el desarrollo y conferencias. Cómo usar ciertas herramientas nos alegró, y demás. Buena manera positiva de cerrar la actividad.

No sé si llegamos a demasiadas conclusiones, pero estuvo interesante conversar de estos temas.

La siguiente charla fue por mi amigo Peter Aitken: It’s a Kind of Magic: Shipping Rails Upgrades with Confidence (Es un tipo de magia, actualizando Rails con confianza). Este es el tipo de charlas que nunca debe faltar en los eventos Ruby. No sólo por el contenido sino la forma en que fue presentada. James presentó a Peter mientras hablaba por teléfono con un tipo de "agente" y salió del salón mientras sonaba música de Queen. La pantalla mostraba dinámicamente con letras en una terminal cómo se iba cargando un "disfraz".

Al rato apareció Peter completamente transformado en Freddie Mercury con bigote y todo. Se repartieron bigotes falsos por todo el salón.

Como la charla tenía cosas en común con la charla de Jess Sullivan, Freddie dijo que iba a ser un cover de esa charla. Comentó cómo para actualizar versiones de Rails había que prepararse buscando la lista de cambios, guías y artículos sobre la versión a la que queremos migrar. Hacer una lista y fijarse si las cosas arrancan, si los tests pasan, si funciona en staging. Habló de la técnica de generar una rama nueva con la versión actualizada, y empezar a hacer backport de cambios necesarios a una rama basada en la principal, para ir viendo qué se rompe o no. 

Muy divertida la charla, ¡que los eventos Ruby sigan siendo divertidos (y raros)!

El cierre estuvo a cargo de María Gutierrez con la charla I’ve seen this movie before: what three inflection points taught me about the only career strategy that works (Esta película ya la vi antes: lo que me enseñaron 3 puntos de inflección sobre la únca estrategia que funciona para mi carrera). Fue interesante escuchar sobre su involucramiento con Ruby y la comunidad desde muy temprano en la vida de Ruby. 

Comentó cómo todos los "líderes"  de las empresas de tecnología están preocupados con problemas existenciales con los cambios que ha tenido la industria en los últimos tiempos. Como todos están siendo presionados para abaratar costos y aumentar la productividad a la vez. Después contó cómo los LLMs la ayudaron a crear cosas después de un tiempo sin tocar código.

La conferencia cerró con un juego masivo de piedra, papel o tijera donde todos nos enfrentamos hasta que quedó un ganador. También se sacó la foto tradicional para el Friday Hug y se hizo la despedida.

Ruby Passport

En uno de los recreos conversé con Caroline, Embajadora de Ruby Passports, y obtuve mi Pasaporte Ruby. Es un pasaporte oficial (no oficial) que obviamente no sirve como documento para viajar ni es reconocido por ningún gobierno. Es un cuadernito muy lindo para llevar a los eventos Ruby y coleccionar recuerdos. Está conectado a Rubyevents.org donde podemos crear una cuenta y agregar eventos Ruby a los que hemos asistido. Está bueno tener algo así, espero acordarme de traerlo cuando vaya a otras conferencias. Por ahora tiene la fecha de cuando "se emitió", el 23 de abril en Haggis Ruby, y un sello de la conferencia. Hay más información en el sitio web del pasaporte.

Sobre IA

A pesar de mi rechazo absoluto a la ideología fascista que nos quieren vender (e imponer) como "IA" o "Inteligencia Artificial", quedé contento con el estado de las cosas en el mundo Ruby. Si bien hubo alguna mención, en general me parece que la comunidad Ruby no está tan envenenada con este cáncer como otras. Y a pesar de que en el trabajo esté escuchando sobre estas boludeces todo el tiempo, el panorama afuera pinta más optimista, por lo menos lo que vengo viendo de Ruby.

Algo que escuché en alguna de las charlas de discusión o entre pasillos fue que la gente que programa Ruby disfruta de escribir el código. Así que es una de las cosas que no le delegarían a estos generadores de basura.

Noté que la gente que habló en contra de la IA tiene un montón de fundamentos, incluso si tienen que usarla por obligación de su trabajo. Pero la que lo mencionaba como manera positiva o de pasada, ni siquiera reconocían el aspecto moral como un factor en el tema. En mi experiencia también todo lo que he oído de "más productividad" ha sido anecdótico. Sin embargo todo lo que he leído de daño cognitivo, problemas que genera y ni que hablar de todo el lado ético, está soportado por datos, evidencia científica.

Obviamente el empuje a favor de este veneno viene más por el lado del marketing que otra cosa. Y los psicópatas que se benefician de todo esto. Pero no me quiero adentrar más en el tema porque ya me entró a subir la presión. A rasgos generales, me fui de la conferencia sintiéndome optimista con Ruby y su relación con los slop generators.

Conclusiones

Siempre es bueno volver a Glasgow. Hizo un clima increíble e inesperado para la costa oeste, cielos azules y mucho sol, clima taps aff. Cada vez que voy a Glasgow digo "debería venir más seguido". Esta vez conocí el centro en hora pico, un montón de gente caminando de acá para allá en pleno centro de la ciudad. Generalmente voy a toques en la tarde/noche, o los fines de semana, así que fue una experiencia distinta.

Quedé contento con la conferencia. Siempre me resulta un poco un desafío por el tema de la ansiedad social, pero la comunidad de Ruby me sigue pareciendo genial y siempre termino pasando bien. Tuve el gusto de conocer a mucha gente nueva, volver a ver a gente que no veía hace un rato, tener muchas charlas interesantes y ser relativamente social por dos días.

Como pasa muchas veces en estos eventos, me fui inspirado y con muchas ganas de hacer más cosas con Ruby. Quiero seguir con mi agenda para Aprende Ruby, desarrollar un par de proyectos web y seguir creando cosas divertidas con DragonRuby. Vamos a ver cuánto me dura antes que el trabajo me vuelva a drenar completamente de ganas de hacer cosas. Por lo pronto también intentaré seguir yendo a los meetups de Ruby y espero el año que viene poder asistir a Haggis Ruby 2027. Con suerte me mandaré a alguna otra conferencia de Ruby en Europa también.

James, uno de los organizadores, comentó que quería hacer la conferencia en un lugar distinto de Escocia cada año. Yo sugerí Shetland, pero de repente complica demasiado la logística. Veremos dónde termina siendo la próxima.