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.

Akumajō Special: Boku Dracula-kun

Es un juego de plataformas y aventura donde manejamos a Dracula-kun. Si bien está ambientado en el universo de Castlevania, tiene un estilo caricaturesco, menos serio. Es un spin-off parodiando a Castlevania, un estilo que Konami ya había explorado con Parodius en los 80's. Tienen mucha personalidad y cuenta con versiones más animadas de personajes monstruosos y un humor particular.

El personaje puede saltar (con A) y disparar bolas de fuego (con B) hacia los costados, arriba y abajo. Dejando el botón B apretado, hacemos un disparo especial. Es de esos juegos de plataforma de la época que no hacían las cosas demasiado fáciles. No perdonan en lo más mínimo, si nos apuramos por dar un salto o le damos con la precisión incorrecta, perdemos. A pesar de la dificultad, es divertido y vale la pena. Con la práctica se le agarra la mano. Al repetir cada escena, nos acostumbramos al control, vamos memorizando qué hacer para progresar y se va haciendo más fácil.

Al final de cada escena nos encontramos con el clásico jefe. Tenemos que descubrir su patrón de ataque y/o debilidad para derrotarlos. Finalizada la batalla, obtenemos un poder nuevo para cuando dejamos el botón B apretado. Vemos el nuevo poder en acción en una escena que parece inspirada por los Mega Man. Podemos alternar entre los poderes disponibles en cualquier momento presionando el botón Select. 

El primer poder (disponible desde que empezamos a jugar) es una bala o bola de fuego más potente que las comunes. Después obtenemos la habilidad de disparar varios misiles que persiguen a los enemigos, una bomba y un disparo de hielo que congela enemigos.

Dos habilidades importantes que obtenemos no son específicamente de ataque. Una nos permite transformar en murciélago y volar libremente por la pantalla. La otra invierte la gravedad, permitiéndonos caminar por lo que sería el techo. Ambas duran un tiempo limitado. Agregan variedad a la jugabilidad y las formas de evitar obstáculos o vencer enemigos. Podemos buscar formas creativas de pasar las pantallas, y en algunas partes tenemos que usarlos sí o sí para seguir avanzando.

Cuando eliminamos enemigos con los poderes especiales, dejan una moneda que después podemos usar en las escenas de bonus. Cuando terminamos un nivel, tenemos que elegir una de 4 columnas, pero al presionar A se abren nuevos caminos entre cada columna. Así que terminamos en una de las opciones A, B, C o D al azar. Cada una representa un mini-juego distinto:

Así elegimos las pantallas de bonues. A la izquierda en pantalla moderna, a la derecha en televisor CRT. Ojalá supiera japonés.

Los mini-juegos nos permiten ganar vidas (y más monedas). Al estar todo en japonés, no entiendo mucho lo que está pasando. Pero esto era parte de lo que nos entretenía en su época cuando jugábamos al Family y nos tocaba algún juego en japonés. Lo importante es que el gameplay sea lo suficientemente entretenido para que queramos volver. Con el tiempo íbamos memorizando ya fuera los textos o el orden para lograr avanzar.

No tengo ni idea lo que está pasando en el juego de la izquierda. Pero creo que le agarré la mano al juego tipo ruleta de la derecha (y con suerte logré ganar bastantes vidas)...

¿Quién necesita un Mega Drive para ir rápido? ¿Sonic quién?

La aventura se divide en 9 niveles bastante diversos. Empezamos en el castillo de Drácula, despertando de nuestro ataúd. El 2ndo nivel es en las nubes, con una parte donde nos subimos a un tipo de tren que empieza a acelerar. Acá empezamos a ver la variedad que le metieron a este cartucho, donde no se trata simplemente de avanzar hacia la derecha y saltar. En mi caso también acá es donde empecé a apreciar mucho más la música. La música cambia a algo mucho más dinámico que te vuela la peluca. Es el primer desafío ágil plataformero, pero no el último.

El tercer nivel es bajo el agua, el cuarto en hielo (con el clásico piso que resbala), el quinto en una ciudad con tren subterráneo, el sexto empieza en un desierto en Egipto y termina dentro de una pirámide. En el nivel 7, subimos a algo así como un ascensor espacial. Tenemos que ir saltando de plataforma en plataforma a lo que la cámara se va desplazando hacia arriba. Así que corremos el peligro de perder si no ejecutamos los saltos en tiempo y forma.

Esta pantalla es de esas clásicas de NES donde al jugarla varias veces, vamos memorizando el patrón. Eventualmente las jugamos en piloto automático a lo que nuestros reflejos fueron respondiendo a cada plataforma en el mismo lugar. Aunque tiene unos ataques de cohetes que aparecen en distintos lugares cada vez. Así como en otras partes del juego, a veces dependemos un poco de tener suerte (o reaccionar muy rápido). No está al nivel de un Battletoads, pero el sentimiento va por ahí. Aunque mucho más fácil y corto que la pantalla de Battletoads que tanto trauma nos dejó en la infancia.

Draculín recién levantado de su siesta.

El nivel 8 es un barco fantasma y el último nivel es el 9. Los jefes y enemigos de cada nivel son temáticos relacionados al ambiente del nivel. Están muy divertidos, con su personalidad característica. La música acompaña muy bien, está muy buena a lo largo de todo el juego. Encontré una lista de reproducción en YouTube con todas las canciones para compartir.

El último nivel me resultó un poco difícil inicialmente. Nos tenemos que enfrentar a 3 jefes y una sección con un desafío de plataformas pero no demasiado complicado. Después de venir jugando por un buen rato, tuve que hacer como en los viejos tiempos. Pausé el Family y lo dejé prendido hacia un costado mientras comía algo y miraba televisión (y no sé si no salí a dar una caminata también). Más tarde, más descansado, volví al nivel 9 y pude vencer a los jefes y ver el final.

Por suerte el juego tiene continues infinitos, y también incluye un sistema de password. Perdí mucho, pero cada vez que jugaba me resultaba un poco más fácil. Y tiene el nivel de desafío justo que no se siente injusto y da satisfacción al terminar un nivel. Nunca me sentí trancado que no supiera cómo progresar. Lo único que me pasó fue lo de programar es como jugar Super Mario con el nivel 9. Pero como conté, seguí mi propio consejo y volví después de un breve descanso. Estoy seguro que lo voy a volver a jugar y sabiendo los patrones y demás, seguramente lo termine más rápido. Pero también es probable que pierda bastante si meto algunos saltos mal.

Como muchos juegos de la época, tiene partes en las que los cuadros por segundo bajan mucho y se enlentece, lo que puede llegar a afectar la jugabilidad. También vemos el típico parpadeo de los sprites. Pero uno creció acostumbrado a eso en esas épocas. En conclusión, es un juego entretenido, con buenos gráficos, buena música y mucha personalidad. Lo recomendaría en cualquier colección de Family, o se puede jugar también en plataformas modernas (y entendiendo lo que dicen si sabemos inglés) en Castlevania Anniversary Collection.

Muchas de mis memorias con Nintendo son con mi primo. Desde chicos compartimos nuestra afinidad por los videojuegos, las Tortugas Ninja y más (y todavía sigue siendo así). Si no recuerdo mal, él tenía este juego en uno de esos famosos multi-cartuchos que también incluía uno de los títulos de las Tortugas Ninja para NES. De esa época tenía el recuerdo del juego, así que lo tenía en mi lista de títulos a adquirir. Insertar el cartucho en el Famicom y prenderlo trajo de vuelta un montón de recuerdos. Debe hacer por lo menos 30 años desde la última vez que lo habíamos jugado juntos. Pero enseguida recordé las pantallas de introducción y el primer nivel y jefe.

Al ser un juego de Konami, probé el Konami code en la pantalla de inicio. Escuchamos un sonido que indica que el código fue aceptado, y nos encontramos con una pantalla negra con texto en japonés:

Aparentemente quiere decir algo así como "Qué lástima. ¡No hay nada aquí!". El código Konami sí funciona en varios juegos, por si no lo conocen, es bueno memorizarlo:

En Contra de NES nos dan 30 vidas si ingresamos el código y apretamos Start en la pantalla inicial.

Bueno, sigo con otros juegos de Family. Hace tiempo vengo escribiendo la reseña de Parodius Da!, pero sigo pasando más tiempo jugando que escribiendo, y sacarle fotos al televisor CRT mientras juego se complica. ¿Conocían este juego? ¿Alguna vez lo jugaron?

Entre toda esa gente, lo vi a grilix que me tiró una sabiduría importante, decía algo así como "Tenés que aprender a aceptar la imperfección humana, Nando". Es que le tengo poca paciencia a la humanidad...

Vi a un montón de amigos y familia, comimos, conversamos, tomamos cervezas, paseamos, tomamos café, fuimos a un toque. Está buenísimo cómo hay tanta gente que puedo no ver durante tanto tiempo y en el reencuentro es como si nos hubiéramos visto ayer.

Lo que es estar de vacaciones y la lectura. Venía con una racha mala, leyendo muy poco libro. Pero al tener tiempo y no estar constantemente estresado y enojado con el estado de las cosas, pude concentrarme en leer de nuevo. El primer día de viaje empecé y terminé el libro Engines Beneath Us de Malcolm Devlin. Es una novela corta con toques de terror. Tiene como una ambientación misteriosa y macabra con un toque de distopía que me resultó bastante atrapante. Recomendado.

Yendo a la playa leí The Employees de Olga Ravn. Este libro lo compré el mismo día que compré The Kaiju Preservation Society. Es extremadamente interesante, una historia de ciencia ficción contada a través de reportes realizados por empleados de una nave espacial. Los empleados son humanos y humanoides, con distintas percepciones de la realidad, el trabajo y su relación entre ellos y con ciertos artefactos recuperados en un planeta lejos de la Tierra. Es en parte crítica al mundo laboral, como ficción de oficina. Por alguna razón me encanta este tipo de ficción sobre el mundo del trabajo (Office Space, Microsiervos, Sign Here). ¡Recomendado!

No podían faltas las visitas a tiendas de libros. Aprovecho que estoy allá para comprar libros en español de autores latinoamericanos y uruguayos. No fui a tantas como veces anteriores (¡no hubo tiempo!), pero pude comprar algunos libros. Entre ellos, una nueva edición de Sobredosis Pop de Ignacio Alcuri. Es el primer libro del autor, con el estilo que lo caracteriza de cuentos cortos y varios experimentos literarios. Es una edición aumentada y revisada por su autor (no demasiado, tampoco abusar), y muy recomendada. Lo empecé a releer en Uruguay y voy poco más de la mitad, creo. Será terminado en breve. ¡También recomendado!

En el viaje de ida miré la serie Severance. Mucha gente me la había recomendado. De las películas disponibles en el avión, no hubo una que me dieran ganas de mirar, un desastre. Pero estaba disponible toda la primera temporada de Severance, así que la miré. Si mis cálculos son correctos, fueron aproximadamente 7 horas de televisión en un viaje. Está bastante interesante y es entretenida. Se trata de los empleados de una empresa donde tienen que pasar por un proceso de "severance" (¿ruptura?). Este proceso divide la personalidad de cada persona entre el trabajo y la vida real. Las dos personalidades son independientes, por lo que una no sabe por lo que pasa o lo que vive la otra.

Cuando me contaban la premisa, mi reacción inicial era que estaría buenísimo. No tener que estresarse fuera del trabajo por todo lo que pasa dentro del trabajo. Pero la serie nos muestra cómo eso puede salir mal... Debería "buscar" la segunda temporada

Estuve mirando algo de televisión durante las vacaciones. Donde me quedaba había una tele con YouTube (entre otros) y miré muchos dibujitos (Looney Tunes, Popeye, entre otros clásicos), Los Tres Chiflados, Mr. Bean y más. También experimenté la pesadilla que es usar YouTube con anuncios, no sé cómo hay gente que vive así.

Por primera vez saqué el Nintendo Switch 2 de casa y me lo traje en el viaje. Estuve jugando mucho a Cyberpunk 2077. Llevo unas 80 horas jugadas, está tremendo y todavía me faltan varias misiones para terminar la historia principal y la expansión Phantom Liberty. El juego "nuevo" de estas vacaciones fue Super Mario Galaxy 2. Jugué al primero en Wii (o Wii U en su momento), en el compilado 3D all-star que salió para Switch, y lo terminé dando vuelta de nuevo en el nuevo compilado que trae ambos títulos. Pero no había jugado al 2. ¡Está muy bueno! Jugué más que nada en el viaje de regreso.

Una noche comí pizza con fainá y jugué Nintendo con mi primo, con el que hacemos partidas online al menos una vez por mes (o eso intentamos). Creo que el juego que pasamos más tiempo jugando fue Mario Kart World.

También gracias a mi primo tuve el gusto de conocer a Martín y Federico Pérez. Los dueños de un coworking en Punta del Este, Wonder Works, van a abrir una exhibición en el cowork mismo con su colección de videojuegos. Todavía no está abierta al público, pero tuve la oportunidad de ver lo que hay y me quería quedar a vivir ahí. Hay muchísimo material, ideal para amantes de Nintendo como uno. Es una colección excelente y no creo haber visto algo así antes. La recomiendo una vez que abra al público, yo sin duda voy a querer volver. El coworking también está muy lindo y nos encontramos ahí con mi amigo fluxocrat con el que anduvimos también compartiendo lúpulos.

Como siempre, intenté comer mucha pizza y fainá. Ya comenté sobre la pizza en Escocia en la entrada anterior. Esta vez comí mucha pizza casera y pizza y fainá en Sumo, La Pasiva, El Horno de Juan y alguna más que me olvido. Una de las tantas tradiciones en Uruguay para mí son las mini pizzas caseras que hace mi tía. Esta vez en la despedida me dió un tupper de mini pizzas para llevar. En el aeropuerto de Carrasco, tras despachar mi valija, nos fuimos afuera con mi padre a comer mini pizzas.

También comí tarta de zapallitos que me hizo mi madre. Acá no hay zapallitos, y me gustan mucho. Entonces cada vez que voy mi madre me cocina algo con zapallitos, generalmente tarta. ¡Muy rica!

Vi muchos perros, algunos conocidos y otros nuevos. También vi nutrias, teros, un cascarudo, lobos de mar, un cangrejo muerto, caballos, vacas y más. Le discutí a mi sobrina que se dice "carpincho" y no "capybara". ¿Qué les están enseñando en la escuela a la gurisada?!

Fui lo más que pude a la playa, a pesar de la amenaza de las fragatas portuguesas (no vi ninguna). El calor se prestaba para disfrutar de la arena y sol, el mar azul, contigo yo conmigo tú.

El viaje de vuelta tenía conexiones bastante cortas. Viajé de Montevideo a Madrid a Londres a Edimburgo. En el aeropuerto de Madrid, corrí hasta la puerta del vuelo a Londres, pero ya habían cerrado el embarque. Como el avión todavía no había salido, lo llamaron, y terminaron llevándome en ómnibus a mí sólo hasta el avión. Se sintió en parte como si fuera un VIP, pero también un poco de vergüenza por llegar tarde. ¡Pero no fue mi culpa! Estaba haciendo conexiones con poco tiempo (y el aeropuerto de Barajas es caótico en un buen día, el fin de semana de pascuas fue un despelote).

Al subir, mi asiento asignado estaba ocupado, así que el staff del vuelo me sentó en una fila de asientos de emergencia que iba vacía. Tenía todo el espacio para estirar las piernas y los brazos a los lados. Hubo al menos una persona que embarcó todavía más tarde que yo. Todo terminó saliendo bien.

En Londres perdí la conexión a Edimburgo. El vuelo llegó en buen tiempo, pero estuvimos más de 20 minutos en el avión sin desembarcar desde que aterrizó. Escuché a una azafata decir "Esto pasa siempre en Londres". Hice el chiste a mi familia que es porque los ingleses son todos Mr. Bean.

Me reasignaron a un vuelo más tarde, así que me fui al bar del aeropuerto y me comí un bowl de papas fritas acompañados de un par de pintas de cervezas cask. Llegué a casa tarde en la noche, desorientado y cansado. Y al día siguiente de vuelta al trabajo. 

Unas vacaciones sumamente exitosas. Importantes para desconectarme del trabajo y la rutina y reconectar con tanta gente. Pero acá andamos nuevamente, de a poco volviendo a la vida cotidiana en Escocia.