Haggis Ruby 2026 - Glasgow, Escocia

Después de la primera edición de Haggis Ruby en Edimburgo en 2024, volvió en 2026. Se realizó durante 2 días el jueves 23 y viernes 24 de abril. Esta vez se mudó a la ciudad de Glasgow. La sede fue thestudio, en el 8° y 9° piso de un edificio sobre la calle Hope, enfrente a la Estación Central de Glasgow.

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.