BEGIN:VCALENDAR
CALNAME:RubyConf Las Vegas 2026
NAME:RubyConf Las Vegas 2026
PRODID:-//github.com/ical-org/ical.net//NONSGML ical.net 4.0//EN
VERSION:2.0
X-WR-CALNAME:RubyConf Las Vegas 2026
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
X-LIC-LOCATION:America/Los_Angeles
BEGIN:STANDARD
DTSTART:20241103T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
TZNAME:PST
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20250309T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZNAME:PDT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DESCRIPTION:Speaker: Marco Roth\n\nERB is one of Ruby’s oldest and most wi
 dely used technologies\, yet many Ruby developers only have a vague menta
 l model of how it actually works.\n\nIn this talk\, we take a deep dive i
 nto the internals of ERB rendering engines. We start by examining how ERB
  templates are compiled and executed today\, and the design and trade-off
 s behind traditional engines such as `erb` and `erubi`\, especially in co
 ntext with rendering HTML. \n\nWe then explore where this string-based ap
 proach breaks down\, particularly when it comes to tooling\, diagnostics\
 , and more advanced rendering techniques in HTML+ERB templates.\n\nFinall
 y\, we look at a different approach: building an HTML-aware ERB engine on
  top of a syntax tree. Using `Herb::Engine` as a concrete example\, we sh
 ow how adding structural understanding changes what is possible\, and wha
 t it unlocks next\, including better tooling and the foundations for effi
 cient\, reactive rendering.
DTEND:20260714T110000
DTSTAMP:20260516T080239Z
DTSTART:20260714T103000
LOCATION:Main Stage - Red Rock
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:The Anatomy of an ERB Rendering Engine
UID:SZSESSION1186019
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Michael Toppa\n\nThe pace and breadth of change with 
 AI coding tools is overwhelming\, and it seems like every day there are d
 ozens of new developments and emerging capabilities. We'll share lessons 
 and strategies gathered from interviews with Rails engineers working in d
 ifferent contexts\, from large and complex legacy codebases\, to small st
 artup codebases.\n\nI've been an active member of the Ruby community for 
 15 years\, and for 2 years I had my own Rails-based startup until I recen
 tly joined the 100-person Rails engineering team at the Planning Center. 
 I'll share my own AI-assisted coding lessons from both contexts\, as well
  as lessons from recent discussions with co-workers past and present. Thi
 s approach helps us both identify patterns and avoid the pitfalls of assu
 ming what works (or doesn't work) in one context is the right approach fo
 r people in other contexts.\n\nSome example of things we'll dig into:\n* 
 Greenfield vs brownfield Rails development with AI\, and identifying the 
 right approaches and tools for each.\n* With code and document generation
  becoming ever cheaper and faster\, human comprehension becomes the new b
 ottleneck. Where these bottlenecks are can vary: we'll discuss how to ide
 ntify and mitigate them. An example is code review: with teams opening PR
 s faster than ever\, how does human code review keep up?\n* BDUF (big des
 ign up front) has made a comeback: when plans and code can be generated q
 uickly and cheaply\, do the human lessons of working in short cycles with
  frequent feedback still matter? We've found that they do\, and we'll dis
 cuss how to harness the best of both approaches.
DTEND:20260714T110000
DTSTAMP:20260516T080239Z
DTSTART:20260714T103000
LOCATION:Breakout 1 - Charleston D-C
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:AI-assisted coding: lessons from small startups to legacy codebases
UID:SZSESSION1185608
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Jeremy Evans\n\nHistorically\, Ruby's Set class was i
 n the standard library.  Starting in Ruby 3.2\, the Set standard library 
 was autoloaded by default.  In Ruby 4.0\, Set is now implemented as one o
 f the core classes.  In this presentation\, I'll go over the history of S
 et\, why and how it was implemented as a core class\, interesting impleme
 ntation issues\, and how it led to a decrease in memory usage for some em
 bedded RTypedData objects (and what RTypedData objects are).
DTEND:20260714T114500
DTSTAMP:20260516T080239Z
DTSTART:20260714T111500
LOCATION:Main Stage - Red Rock
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Implementing Core Set
UID:SZSESSION1151113
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: David Gillis\n\nRuby is a fantastic tool for CLIs\, a
 s long as you're ok waiting 100-1000ms for them to boot. What if you didn
 't have to wait? What if you could get Rust or C speeds instead? Perhaps 
 something like... writing a shell script to intercept the CLI call\, whic
 h then runs a ruby script that connects to a UNIX socket instead of your 
 PATH's ruby\, which then sends its file-descriptors through this socket t
 o a server with your CLI already loaded\, which then signals this server 
 to fork itself a new process\, which then causes the new process to swap 
 its stdin\, out\, err with yours that it received from the unix socket\, 
 which then finally runs your code. And yes\, you can optimize further by 
 compiling those shell scripts into zsh wordcode via zcompile\, so they au
 toload in microseconds and stay loaded.\n\nYes\, this is a spectacular di
 splay of overengineering. But the results do not lie. This chain of event
 s has given me a 12x average speedup across many popular Ruby CLI tools\,
  including kamal\, colorls\, ronin\, ri\, uplot\, and more. Kamal now tak
 es 40ms instead of 700\, ronin takes 50ms instead of 1100\, and I have th
 e full benchmarks to show and demo. I've been using it every day for over
  a year and don't know how I ever lived without it.\nIn this talk I'll wa
 lk through Ready from the bottom up\, in four parts. First\, how a single
  config file drives a build system that pulls source out of gem executabl
 es\, rewrites their require paths\, and wraps them into callable shell fu
 nctions. Second\, the UNIX plumbing that makes it possible — sockets that
  pass file descriptors between processes\, something most Rubyists have n
 ever seen\, but built on something they use every day: $stdout is really 
 just IO.new(1). Third\, the engine underneath: Jeremy Evans' by gem\, a l
 ittle-known library preloader that operates at the process level\, not th
 e framework level — which is why it generalizes to arbitrary gem executab
 les where Spring never could. And fourth\, where things get genuinely har
 d: running interactive tools like irb through this fork chain\, where pip
 es buffer but PTYs don't\, and adding tmux or ssh breaks every assumption
  again.\n\nAlong the way\, a nice side effect: because every invocation f
 orks from the same pre-resolved process\, bundler conflicts\, gem path mi
 smatches\, and shim headaches just disappear.\nYou'll leave understanding
  how Ruby processes talk to each other at the file descriptor level\, and
  with a system you can try yourself.
DTEND:20260714T114500
DTSTAMP:20260516T080239Z
DTSTART:20260714T111500
LOCATION:Breakout 1 - Charleston D-C
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Ready: 12x Faster Ruby CLIs Through Spectacular Overengineering
UID:SZSESSION1185717
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Julia Egorova\n\nYour test suite takes 25 minutes. Bu
 t you have 8 cores. So it should take 3 minutes\, right? If only it were 
 that simple!\n\nWhether you're on Minitest or RSpec\, running tests in pa
 rallel can dramatically shrink your local and CI feedback loops. That sai
 d\, parallelization is no free lunch. Naive approaches introduce flaky te
 sts\, waste resources\, and sometimes make things slower. \n\nIn this tal
 k\, I'll walk you through the full spectrum of Ruby test parallelization 
 – from the simplest CI-level splitting to sophisticated queue-based orche
 stration. We'll see what works\, what breaks\, and why you can't just thr
 ow more cores at the problem.\n\n- We'll start with the fundamentals: why
  parallelization matters and how to think about it. \n- Then we'll explor
 e the most common strategies: splitting work across CI jobs\, using paral
 lel_tests to leverage multiple cores within a single machine\, and Rails'
  built-in parallel testing for Minitest. \n- From there\, we'll go deeper
  into queue-based approaches: how tools like Knapsack Pro dynamically dis
 tribute work across workers\, why static splitting hits a ceiling\, and t
 he critical difference between splitting by file versus splitting by indi
 vidual example (and when each makes sense).\n\nAlong the way\, I'll tackl
 e the real-world headaches: shared state and flaky tests\, the tension be
 tween let_it_be-style optimizations and per-example splitting\, and the a
 rt of balancing workers so no single node becomes a bottleneck. \n\nWe'll
  close with Amdahl's Law applied to your test suite (understanding the ha
 rd limits of parallelization) and what to do when more cores stop helping
 : profiling\, factory optimization\, and making your tests genuinely fast
 er.\n\nTakeaways: The audience will leave with a clear mental model for c
 hoosing the right parallelization strategy for their projects\, concrete 
 tool recommendations for both Minitest and RSpec – and an understanding o
 f when to stop parallelizing and start optimizing.
DTEND:20260714T123000
DTSTAMP:20260516T080239Z
DTSTART:20260714T120000
LOCATION:Main Stage - Red Rock
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:From cores to queues: parallelizing Ruby tests the right way
UID:SZSESSION1185038
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Nery Campusano\n\nWhat is an Enumerator\, and how can
  it be used for streaming data? While learning about streaming handlers i
 n gRPC Ruby\, I found that the docs mention returning an Enumerator\, but
  why? It didn't seem clear as to why an Enumerator was needed to stream\,
  so I started asking questions.\n\n  What is an Enumerator? I'd never had
  the need to create one before\, I'd only ever used them. Once I understo
 od what they are and how they enable controlled external and internal ite
 ration\, I had a new question: if gRPC just needs something that responds
  to each\, does it matter? Can I return an Array and move on?\n\n It depe
 nds. And that's what we will be exploring together in this talk.\n\n  We'
 ll cover what works\, what doesn’t work\, and the tradeoffs of each appro
 ach. We'll look at what Enumerators have beyond each that make it a power
 ful primitive for gRPC Streaming: how gRPC uses them internally to handle
  incoming requests\, how the same contract drives your responses\, and wh
 y that shapes the streaming interface in ways that aren't obvious from th
 e outside. Whether you work with gRPC or not\, you'll leave the talk with
  a new way to think about Enumerators and when to reach for them\, regard
 less of if values arrive over time rather than all at once.\n\n  Turns ou
 t an Enumerator isn't just a tool for lazy enumeration. It's powerful eno
 ugh to be the backbone of a network streaming protocol.\n
DTEND:20260714T123000
DTSTAMP:20260516T080239Z
DTSTART:20260714T120000
LOCATION:Breakout 1 - Charleston D-C
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Each All the Way Down: How Ruby Enumerators Power Streaming in gRP
 C Ruby
UID:SZSESSION1185486
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Keith Bennett\n\nCommand-line applications are ubiqui
 tous in modern development workflows\, powering tools for cloud services\
 , developer automation\, and AI-assisted development.\n\nRuby’s expressiv
 e syntax\, flexible object model\, and strong testing culture make it wel
 l suited for building command-line applications whose implementations rem
 ain concise\, maintainable\, and easy to extend as they grow into larger 
 systems.\n\nThis talk presents practical techniques and design patterns f
 or building high-quality command-line applications in Ruby.\n\nTopics wil
 l include:\n\n- organizing command-line application codebases for clarity
 \, maintainability\, and extensibility\n- producing clear help output\, l
 ogs\, and error messages that help users diagnose and resolve problems\n-
  achieving a high functionality-to-complexity ratio through careful inter
 face and architecture design\n- designing tools that behave well in pipel
 ines and scripts through predictable output\, multiple output formats\, a
 nd proper exit codes\n- structuring applications so the same functionalit
 y can be used as a command-line tool\, library API\, interactive shell (R
 EPL)\, or backend server (MCP\, HTTP\, etc.)\n- using Ruby’s flexible syn
 tax to enable lightweight DSL-style interaction in REPL environments and 
 command scripts\n\nExamples will draw from real-world Ruby tools includin
 g cov-loupe\, a coverage analysis command-line application\, library\, an
 d MCP server\, and wifi-wand\, a Wi-Fi management command-line applicatio
 n\, library\, and interactive shell.\n\nAttendees will leave with practic
 al patterns they can apply immediately to build command-line applications
  that are easier to use\, easier to maintain\, and more powerful and flex
 ible.\n
DTEND:20260714T143000
DTSTAMP:20260516T080239Z
DTSTART:20260714T140000
LOCATION:Main Stage - Red Rock
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Command-Line Applications in Ruby: Design Patterns and Best Practi
 ces
UID:SZSESSION1184808
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Dalma Boros\n\nWhenever I’m asked why I like Ruby\, m
 y answer is always simple and always the same: because she’s cute. That's
  my tongue-in-cheek nod to the community's shared sentiment that Ruby's e
 legance makes her a joy to work with. But beauty requires maintenance. \n
 \nThis talk is a case study on how I turned my anxiety around mounting te
 ch debt into Makeover Monday 💅✨\, a weekly refactoring ritual. \n\nI did
 n’t set out to be a leader\, I just wanted our TODOs to stop piling up. W
 hat started as a casual\, weekly tech debt session transformed our codeba
 se and our culture and became our fully remote team’s most appreciated (a
 nd only) dev-only space. \n\nAttendees will leave with:\n- An understandi
 ng of why beauty in code is a functional requirement\, not a luxury\n- An
  understanding of how collective code cleanup is a way to level up all de
 vs in a safe\, collaborative environment\n- A practical blueprint for sta
 rting their own refactoring rituals with the confidence to lead from wher
 ever they are in the org chart.
DTEND:20260714T143000
DTSTAMP:20260516T080239Z
DTSTART:20260714T140000
LOCATION:Breakout 1 - Charleston D-C
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Makeover Monday 💅✨: How a Weekly Ritual Transformed Our Codebase 
 and Culture
UID:SZSESSION1185649
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Ziggy the Hamster\n\nWe all have some notion of the p
 latforms that Ruby currently supports\, but considering Ruby is now over 
 30 years old\, have you ever thought about all of the weird and wacky pla
 ces that Ruby can or has ever run? From Japanese-exclusive systems that y
 ou might not have ever heard of to long forgotten systems that were once 
 ubiquitous\, I will cover the history of the most interesting of these pl
 atforms\, try to get Ruby running on them\, and experimentally test the q
 uestion: What operating systems support Ruby?
DTEND:20260714T151500
DTSTAMP:20260516T080239Z
DTSTART:20260714T144500
LOCATION:Main Stage - Red Rock
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Weird and Wacky Machines Running Ruby
UID:SZSESSION1183926
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Cameron Dutro\n\nAt the hack day at RubyConf 2023 in 
 San Diego\, Kevin Newton and I put together an extremely basic Ruby inter
 preter in JavaScript. It was so fun and inspiring that I hacked on it for
  months afterwards\, eventually getting it to run the entire Phlex test s
 uite (and more).\n\nRuby in the browser isn’t exactly new. Opal is incred
 ible\, and recently ruby.wasm has been making a splash. So why do we need
  a new Ruby interpreter for the web? We don’t! This talk isn’t about maki
 ng a better Opal\, production use-cases\, or other Serious Business®. It’
 s about having fun building an interpreter for your favorite language and
  how much you can learn about Ruby along the way.\n\nGarnet.js is an impl
 ementation of Ruby’s YARV (Yet Another Ruby VM) in TypeScript. It uses th
 e new Prism parser and can already run the test suites for some pretty co
 mplex projects. I'd like to explain how YARV works and how contributing t
 o Garnet helped me answer almost all of Drew Bragg’s Ruby game show quest
 ions.\n\nWhen I started writing Ruby back in 2010\, I never thought I wou
 ld have the skills to write an interpreter. That stuff was just too hard 
 for an average guy like me. A few years into my career though\, I realize
 d something: you can just do things. I might have heard it first from DHH
 \, but it really stuck with me. If you want something to exist\, you can 
 just… do it. You can even do really really big things that seem impossibl
 e. Just take it one step at a time\, and before you know it\, you’ve made
  something substantial.\n\nThat’s how Garnet started. It seemed impossibl
 e\, but then without any warning I’m sitting next to Kevin Newton hacking
  away at a Ruby interpreter in JavaScript. We only produced maybe 50 line
 s of code\, but I slowly added to it over the next 2 years and Garnet is 
 now quite capable.\n\nYARV isn’t magic. It’s made up of a few entirely un
 derstandable components wired together to run Ruby code. I hope to give a
 n overview of those components\, demonstrating how Ruby translates raw so
 urce code into an AST\, then into YARV instructions\, and eventually how 
 it executes those instructions. My hope is that explaining YARV via TypeS
 cript will make the concepts more accessible to a Ruby audience than C wo
 uld\, although there should be plenty of Ruby in the talk as well.\n\nOf 
 course\, building a Ruby interpreter has had its challenges (more to come
  I’m sure). Here are a few I’m hoping to share with the audience:\n\nLamb
 das and methods are invoked differently than blocks and procs. How does t
 he interpreter know when to enforce arity\, etc?\nRuby’s argument handlin
 g is extremely complex. How do the parser and interpreter work together t
 o handle all the various combinations? (eg. positional\, splat\, trailing
  positional\, positional with default\, keyword\, keyword with default\, 
 keyword rest\, blocks\, anonymous splats and keyword splats\, forwarding)
 \nRegular expression handling via Onigmo. Compiling C projects to WASM an
 d exposing them to Ruby.\nMy goal here is twofold: to spread the knowledg
 e I’ve gained to more Rubyists\, but also to hopefully inspire someone el
 se to work on something big and ambitious.
DTEND:20260714T151500
DTSTAMP:20260516T080239Z
DTSTART:20260714T144500
LOCATION:Breakout 1 - Charleston D-C
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Garnet.js: Implementing the YARV Virtual Machine
UID:SZSESSION1154852
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Tess Griffin\n\nHave you ever looked at a bug and won
 dered why it actually happens? It's easy to chalk it up to sloppy coding\
 , but that's almost never the case.\n\nIn this talk\, we'll be dissecting
  an exploit from Pokémon Blue known as the "Missingno" glitch. We'll expl
 ore the details of each seemingly random bug behind this exploit and appl
 y the lessons to our Ruby code 30 years later.\n\nIf you've never played 
 or even heard of Pokémon\, that's ok! As long as you're interested in a d
 eep dive into a fascinating set of bugs\, this talk is for you.
DTEND:20260714T151500
DTSTAMP:20260516T080239Z
DTSTART:20260714T144500
LOCATION:Breakout 2 - Charleston E-B
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Learning Empathy From Pokémon Blue
UID:SZSESSION1175224
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Scott Werner\n\nAsk seven people what an "AI agent" i
 s and you'll get nine answers. One person will change their mind twice.\n
 \nWhen we can't name something\, it usually means we're looking at someth
 ing genuinely new. I'll argue that what we're calling "agents" is actuall
 y a new programming paradigm hiding in plain sight. Think about what make
 s up an agent: an LLM\, a prompt\, a loop\, some tools\, a way to talk to
  it. That's a little computer that receives messages and interprets them.
  That's suspiciously close to what Alan Kay actually meant by "objects" a
 nd "Object Oriented Programming". Closer to what we have with Ruby\, not 
 what C++ and Java turned it into.\n\nWe'll take a detour through Xerox PA
 RC circa 1972\, explore what Kay meant by message passing and late bindin
 g\, and discover how LLMs accidentally achieved something he was reaching
  for: semantic late binding\, where the meaning of a message is negotiate
 d at the moment of receipt. \n\nThen I'll demo prompt_objects\, a Ruby ge
 m where markdown files are the program and Ruby is the environment. You'l
 l see objects interpret messages\, modify themselves\, create new objects
  at runtime\, and solve ARC-AGI intelligence puzzles on a small\, cheap m
 odel all with a solver you can read in minutes.
DTEND:20260714T160000
DTSTAMP:20260516T080239Z
DTSTART:20260714T153000
LOCATION:Main Stage - Red Rock
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Talking Shit About AI Agents
UID:SZSESSION1156214
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Gabriel Quaresma\n\nLLMs are the new duct tape of sof
 tware development. Need to generate code? LLM. Summarize a PDF? LLM. Pred
 ict the price of a house? Also LLM\, apparently because at some point we 
 collectively decided that every problem is a nail and GPT is the hammer.\
 n\nSpoiler: it's not. And reaching for an LLM by default can quietly cost
  you accuracy\, speed\, predictability\, and an embarrassing line item on
  your OpenAI or Anthropic bill.\n\nThis talk takes a concrete example tha
 t looks tailor-made for an LLM but absolutely isn't: estimating house pri
 ces. We'll see how train a Random Forest model in Ruby with Rumale\, then
  throw it into the ring against an LLM across four rounds: accuracy\, lat
 ency\, consistency\, and real-world usability. You'll see the actual numb
 ers not vibes\, not intuition\, not a tweet from someone who "felt" the L
 LM did better.\n\nThen we'll flip the script and show where LLMs genuinel
 y shine and how combining them with traditional ML gives you a system tha
 t's smarter\, faster\, and dramatically cheaper than asking a 400-billion
 -parameter model to do basic math.\n\nThis talk is for developers integra
 ting AI into their products who want to think critically about architectu
 re instead of defaulting to "just use an LLM and pray." You'll leave with
  a clear mental model for picking the right tool and combining tools for 
 the right problem.
DTEND:20260714T160000
DTSTAMP:20260516T080239Z
DTSTART:20260714T153000
LOCATION:Breakout 1 - Charleston D-C
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Why a 1990s Machine Learning Algorithm Destroys LLMs at Predicting
  House Prices
UID:SZSESSION1184143
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Edy Silva\n\nI was playing with Ractors\, trying to s
 ee if they could replace Process.fork for the kind of work Puma does. Wro
 te a benchmark\, ran it: Ractors came back 3.6× slower than forks. Shocki
 ng numbers\, something must be wrong with my benchmarks..\n\nTurns out I 
 was running an older Ruby version. Change it to Ruby 4 and the numbers fl
 ipped: 5.6×faster\, matching forks\, beating them at small workloads.\n\n
 That accident is why this talk exists.\n\nFor a decade\, "concurrent Ruby
 " has meant picking your poison: threads that share state and corrupt it\
 , fibers that need to cooperate\, a GVL that pins "parallel" code to one 
 core\, and Process.fork as the heavy escape hatch. Ruby 4.0 rewrote that 
 tradeoff.\n\nWe'll map Ruby's four concurrency primitives — Threads\, Fib
 ers\, Processes\, Ractors — show where each belongs (including how Puma a
 nd Falcon combine them in production)\, walk the structural fixes that cl
 osed the gap\, and look at the API that finally feels ergonomic: Ractor::
 Port\, shareable procs and lambdas\, native exception transport. \n\nPlus
  a few Actor Model patterns from Elixir (worker pools\, mailboxes\, pipel
 ines) that work in Ruby 4.0 today. You'll leave with a clear answer to "w
 hich primitive when?" and a frank read on what Ractors can (and can't) do
  in production in 2026.
DTEND:20260714T164500
DTSTAMP:20260516T080239Z
DTSTART:20260714T161500
LOCATION:Main Stage - Red Rock
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Ractors in Ruby 4.0: Message Passing Without the Pain
UID:SZSESSION1185631
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Andy Andrea\n\nEven in a duck-typed language like Rub
 y\, we often work with structured data that adheres to particular schemas
 . For anyone that's worked in a Rails app\, a schema.rb or structure.sql 
 file is an inherent part of our apps\, and many Ruby devs have worked wit
 h JSON Schema or OpenAPI in various applications. In many of those cases\
 , though\, we have a lot of duplication especially when we're dealing wit
 h CRUD. A `create` endpoint\, for example\, might accept incoming paramet
 ers that look very similar to what's returned by a `show` endpoint\, and 
 both will likely have a lot in common with a corresponding table's schema
 .\n\nThis duplication is not a major problem--it can often be the best ch
 oice--but what would it look like if we tried to DRY things up a little..
 .or a lot? If we're willing to get a little weird\, how far can we possib
 ly take a single schema?\n\nIn this talk\, we'll have a single schema and
  show how it can be applied to (or shoe-horned into) tons of different ar
 eas in a single app from AI tooling to CI to metaprogrammatically generat
 ed Ruby classes.
DTEND:20260714T164500
DTSTAMP:20260516T080239Z
DTSTART:20260714T161500
LOCATION:Breakout 1 - Charleston D-C
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:The little schema that could (...but should it?)
UID:SZSESSION1182223
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Gannon McGibbon\n\nNative extensions are a powerful t
 ool that allows Rubyists to reach outside the Ruby VM into machine code. 
 In this talk\, you’ll learn just enough C to write your first native exte
 nsion\, and all the different ways you can over complicate your Ruby apps
  with interoperability.
DTEND:20260714T164500
DTSTAMP:20260516T080239Z
DTSTART:20260714T161500
LOCATION:Breakout 2 - Charleston E-B
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Overengineering Ruby with Native Extensions
UID:SZSESSION1184597
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Allison Pike\n\nOnce a Maintainer will be a live roun
 dtable discussion based on the popular Once a Maintainer newsletter which
  celebrates the people behind Open Source in the Ruby community. Ideally 
 we'd speak with 3 or so maintainers\, and ask each one to dig into how th
 ey got into software development\, how and why they made their first open
  source contribution\, dig into their primary role in open source\, and e
 nd on where they see the future of open source generally (and their proje
 ct in particular) in the age of AI.
DTEND:20260715T101500
DTSTAMP:20260516T080239Z
DTSTART:20260715T091500
LOCATION:Main Stage - Red Rock
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Once a Maintainer
UID:SZSESSION1176994
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speakers: Colby Swandale\, Marty Haught\n\nThe gems you mainta
 in could be foundational infrastructure for the Ruby community and that m
 akes their security everyone's concern. But most maintainers aren't secur
 ity engineers\, and the path from "I think my gem might have a vulnerabil
 ity" to "I've fixed it and shipped a release" can feel daunting.\nThis ha
 nds-on workshop\, led by the RubyGems team will incorporate lessons learn
 ed from Project Glasswing\, Ruby Central's Alpha-Omega-funded security in
 itiative for the Ruby ecosystem\, and it will give maintainers the tools 
 and confidence to take ownership of their gem's security posture. We'll w
 alk through the full lifecycle: what good security looks like for a gem\,
  how to run a scan against your own project\, how to read and interpret t
 he resulting report\, and how to triage and address what you find.\n\nNo 
 prior security experience is assumed. By the end of the session\, you'll 
 have run a real scan\, reviewed real findings\, and left with practical s
 trategies for fixing vulnerabilities and hardening your gem against futur
 e ones.\n\nWhat we'll cover:\n* An overview of Project Glasswing and how 
 the gem scanning program works\n* What a strong security posture looks li
 ke for a Ruby gem\n* Running a scan and understanding the prompt-driven p
 rocess\n* Reading and interpreting a scan report\n* Walking through an ex
 ample scan together\n* Strategies for addressing vulnerabilities — from q
 uick fixes to longer-term hardening\n\nWho should attend: Maintainers of 
 Ruby gems of any size\, from weekend projects to widely depended-on libra
 ries. If you ship a gem\, this workshop is for you.\n
DTEND:20260715T123000
DTSTAMP:20260516T080239Z
DTSTART:20260715T103000
LOCATION:Main Stage - Red Rock
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:From Scan to Fix: A Maintainer's Guide to Gem Security
UID:SZSESSION1229976
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Amir Rajan\n\nBuild a video game using DragonRuby Gam
 e Toolkit!\n\nHere's what we'll end up covering:\n- Hello world.\n- Links
 /resources overview (sample apps and book).\n- Getting a sprite to move o
 n the screen.\n- Setting up keyboard and mouse input.\n- Collision.\n- An
 imations.\n- Scene management.\n- Minimal implementation of Flappy Bird- 
 I mean Flappy Dragon.
DTEND:20260715T123000
DTSTAMP:20260516T080239Z
DTSTART:20260715T103000
LOCATION:Breakout 1 - Charleston D-C
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:DragonRuby Game Toolkit - Soup to Nuts
UID:SZSESSION1215666
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Joe Masilotti\n\nBring your Rails codebase. Leave wit
 h an iPhone app.\n\nIn this hands-on workshop\, you'll take an existing R
 uby on Rails application and see it running as a native iOS app on your o
 wn iPhone. No iOS experience required. You won't need Xcode\, an Apple De
 veloper account\, or even a Mac.\n\nWe'll use the Ruby Native preview app
  to wrap your server-rendered Rails views in a native iOS shell. Your exi
 sting views\, authentication\, and business logic all carry over. You con
 figure a few settings and point it at your app.\n\nHere's what we'll cove
 r:\n\n- Configuring your Rails app for mobile rendering\n- Connecting to 
 the Ruby Native preview app\n- Handling navigation\, tabs\, and native ch
 rome\n- Tweaking your views for a great mobile experience\n- Understandin
 g the path from preview to the App Store\n\nYou'll hit real problems alon
 g the way\, the same ones I've debugged across the 25+ Rails-powered mobi
 le apps I've shipped\, and we'll solve them together. By the end\, you'll
  have your app running on your iPhone and a clear picture of what it take
 s to go from Rails app to the App Store.\n\nPrerequisites: an iPhone and 
 your Rails codebase running locally on your laptop.
DTEND:20260715T123000
DTSTAMP:20260516T080239Z
DTSTART:20260715T103000
LOCATION:Breakout 2 - Charleston E-B
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Build an iPhone app with Ruby and YAML
UID:SZSESSION1182970
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Carolyn Cole\n\nHanami (hanamirb.org) is a relatively
  new Ruby framework that is focused on inclusivity and developer happines
 s.  In addition to the inclusive community\, the Hanami framework focuses
  on functional Ruby\, which has the promise of less bugs too!   \n\nIt wo
 uld be nice to think that we all have tons of greenfield projects where w
 e could utilize Hanami.  In reality most of us do more maintenance of exi
 sting applications than creating new applications.   That is why I have b
 een working on converting some of my existing Rails applications over to 
 Hanami.\n\nIn this workshop we will take the demo Rails Bookshop applicat
 ion and convert it to a Hanami application.  While we do the conversion w
 e will discuss the different component parts of Rails (Model\, View\, Con
 troller) and how they map to the component parts of Hanami (Relations\, R
 epositories\, Views\, Templates\, Actions). \n\nI hope that you will leav
 e the workshop feeling empowered to utilize Hanami in place of Rails!\n
DTEND:20260715T160000
DTSTAMP:20260516T080239Z
DTSTART:20260715T140000
LOCATION:Main Stage - Red Rock
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Converting from Rails to Hanami
UID:SZSESSION1177012
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Miguel Marcondes Filho\n\nWhen was the last time you 
 wrote Ruby that wasn't a web app? In this workshop\, you'll build a game 
 where monsters race\, fight\, and evolve — using genetic algorithms for n
 atural selection and LLMs to generate their stories. All in pure Ruby\, n
 o frameworks. You'll leave with a working project and practical patterns 
 for both evolutionary algorithms and LLM integration.
DTEND:20260715T160000
DTSTAMP:20260516T080239Z
DTSTART:20260715T140000
LOCATION:Breakout 1 - Charleston D-C
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Evolving Monsters: Build an AI Game Engine with Ruby and Genetic A
 lgorithms
UID:SZSESSION1184726
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Noel Rappin\n\nI've taught Ruby to a lot of people\, 
 and often people seeing Ruby's dynamic types ask how a Ruby developer avo
 ids type errors and gets things done.\n\nThis session is my answer to the
  question.\n\nRuby rewards thinking about types with a dynamic mindset in
 stead of a static one. \n\nIn this workshop\, we’ll show how use Ruby’s d
 ynamism to your advantage. \n\nFrom runtime type checking to coercing dat
 a. From nil-avoidance  to full object-oriented design\, you'll come away 
 with techniques to take full advantage of Ruby's power.
DTEND:20260715T160000
DTSTAMP:20260516T080239Z
DTSTART:20260715T140000
LOCATION:Breakout 2 - Charleston E-B
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Workshop: The Dynamic Ruby Toolkit
UID:SZSESSION1180096
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Brandon Weaver\n\nThere was a time when Ruby felt lik
 e magic. It gave an entire generation of developers wings\; tools to ship
  fast\, dream big\, and start companies from anywhere. It wasn’t just cod
 e\; it was a movement built on empathy\, simplicity\, and joy. Ruby taugh
 t us that developer happiness wasn’t a luxury\; it was a revolution.\n\nN
 ow\, a new kind of magic is emerging: AI. It’s promising\, powerful\, and
  most importantly it’s perilous. As the world rushes to automate\, optimi
 ze\, and amplify\, we in the Ruby community have a chance to pause and as
 k better questions—not just *can we*\, but *should we*?\n\nThis talk isn’
 t a demo reel. It’s a conversation about responsibility\, creativity\, an
 d care. About how we bring our whole selves to this moment\, with wonder 
 and with skepticism. We'll reflect on what AI means not just for our tool
 s\, but for our teams\, our values\, and the future we're quietly writing
  together.\n\nRuby taught us to be kind and to focus on people over techn
 ology\, and that lesson is more important today than ever.
DTEND:20260716T110000
DTSTAMP:20260516T080239Z
DTSTART:20260716T103000
LOCATION:Main Stage - Red Rock
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:We Who Remember Magic
UID:SZSESSION1154479
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Madison Sites\n\nRuby and AI are supposedly a perfect
  match. In less-than-ideal legacy codebases\, the reality is messier. Age
 nts stumbled on the same things I had during onboarding: unnecessary comp
 lexity\, conflicting patterns\, and conventions that actively fought Rail
 s. My PR review queue grew while I made the same corrections over and ove
 r - in my editor and then again on GitHub.\n\nI hit a breaking point\, un
 sure if this career was still for me. My coworker's advice seemed like a 
 joke: "The antidote to too much AI is more AI." I didn't have time to bec
 ome an AI expert\; I would drown before I could get department consensus 
 on strategy\, so I ran a small experiment\, changing only how I communica
 ted with AI in my workflow.\n\nWhat started as survival evolved into a fl
 ywheel. Whether you're skeptical\, curious\, or drowning in AI-generated 
 code\, you'll see how small experiments compound into real leverage — and
  how capturing your team's knowledge where both humans and agents can fin
 d it changes everything. No special title or pristine codebase required.
DTEND:20260716T110000
DTSTAMP:20260516T080239Z
DTSTART:20260716T103000
LOCATION:Breakout 1 - Charleston D-C
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Legacy Rails and the AI That Couldn't
UID:SZSESSION1184928
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Miles Georgi\n\nI was bored so\, as one does\, I deci
 ded to goof-about with Ractors! Come explore what you can and cannot do w
 ith Ractors and other forms of Ruby concurrency!
DTEND:20260716T110000
DTSTAMP:20260516T080239Z
DTSTART:20260716T103000
LOCATION:Breakout 2 - Charleston E-B
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Come Discuss Ractors and Concurrency with 'The Dude'!
UID:SZSESSION1185693
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Alexander Baygeldin\n\nProcessing background jobs can
  often have challenges—especially at scale. For example\, multi-tenant ap
 plications often struggle with fair prioritization of background tasks: a
  single large client may enqueue tons of jobs\, monopolize available reso
 urces\, and block smaller client tasks.\n\nIn fact\, this was my story ju
 st recently\, so in this talk\, we’ll learn if it’s time for you to take 
 background job prioritization seriously–and how to design your system in 
 a way that  makes it fair for everyone (regardless of their size or billi
 ng plan).\n\nFirst\, I’ll demonstrate an unfair scenario and show how to 
 spot it in a production environment. We'll look at its root causes and de
 fine what “fairness” means in the context of background job processing. W
 e’ll then recall how background processing works in Rails (and Ruby in ge
 neral)\, using Sidekiq\, GoodJob\, and SolidQueue. We’ll also touch on ho
 w GVL factors into the problem\, and whether using Async can help mitigat
 e it in certain cases.\n\nI’ll next explore strategies for introducing fa
 irness while staying in the constraints imposed by our background job pro
 cessors. These strategies include shuffle shards\, throttling (based on l
 eaky buckets)\, and interruptible iteration. We’ll discuss the pros and c
 ons of each\, and see cases where they may fall short.\n\nIn the last par
 t\, I’ll explore an alternative approach that relies on virtual per-tenan
 t queues and dedicated schedulers instead of the background job processor
 s’ built-in capabilities. I’ll show why this approach achieves the most f
 airness\, at what cost\, when it’s worth implementing\, and how to do so–
 in almost any setup.\n
DTEND:20260716T114500
DTSTAMP:20260516T080239Z
DTSTART:20260716T111500
LOCATION:Main Stage - Red Rock
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Fair by design: orchestrating background jobs in Ruby
UID:SZSESSION1184373
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Mike Dalton\n\nTechnology has made our lives better i
 n many ways. But despite all of these advances we're still juggling authe
 ntication methods. Enter a password\, click a push notification\, enter a
  code. It feels never ending... But what if it actually was never ending?
 \nIntroducing "Welcome to Authentication Hell"\, a browser-based game wri
 tten in Ruby. You play a developer trying to escape Authentication Hell. 
 At each level you must authenticate with increasingly more frustrating au
 thentication methods. Will you reach the surface or collapse under the we
 ight of push notifications and passkeys?\nAlong the way\, we'll learn abo
 ut implementing various methods of authentication in Ruby. Passwords\, pa
 sskeys\, biometrics\, and more.
DTEND:20260716T114500
DTSTAMP:20260516T080239Z
DTSTART:20260716T111500
LOCATION:Breakout 1 - Charleston D-C
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Welcome to Authentication Hell
UID:SZSESSION1185678
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Peter Zhu\n\nLast year\, the Modular Garbage Collecto
 r feature in Ruby was introduced. With this feature\, we shipped an alter
 native garbage collector using the Memory Management Toolkit (MMTk) frame
 work. At the time\, however\, MMTk was significantly slower than the defa
 ult garbage collector in Ruby.\n\nOver the past year\, the MMTk Ruby inte
 gration has been significantly improved and the performance is now on par
  with the default garbage collector. It now supports the Moving Immix gar
 bage collection strategy\, improved parallelism\, and numerous optimizati
 ons.\n\nIn this talk\, we will go over the Modular Garbage Collector feat
 ure and its differences with the default garbage collector\, examine the 
 techniques used to speed up the Ruby MMTk integration\, and discuss how i
 t can be improved further in the future.
DTEND:20260716T114500
DTSTAMP:20260516T080239Z
DTSTART:20260716T111500
LOCATION:Breakout 2 - Charleston E-B
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Building the Next-Generation Garbage Collector in Ruby
UID:SZSESSION1156071
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Sam Ruby\n\nRails is the fastest way to go from idea 
 to working application. JavaScript has the broadest reach — browser\, edg
 e\, mobile\, desktop. Choosing one means giving up the other.\n\nUnless y
 ou don't choose.\n\nOpen two browser windows pointing at a GitHub Pages U
 RL. Create a blog article in one. Watch it appear in the other. Close the
  browser. Come back. The data is still there. Open developer tools. Find 
 `app/controllers/articles_controller.rb` in Sources. Set a breakpoint. It
  hits.\n\nThere is no server. There is no Ruby runtime. Just static files
  on GitHub Pages.\n\nThis is a standard Rails blog tutorial — RESTful con
 trollers\, Active Record models with associations and validations\, ERB v
 iews\, Turbo Streams — transpiled to JavaScript and running entirely in t
 he browser. And it gets weirder from there: an in-browser editor with hot
  reload\, a transpiler that transpiled itself\, system tests that run in 
 75ms without a browser\, production deployments where every user gets the
 ir own SQLite database\, and a future where the write pattern — not the f
 ramework — determines the architecture.\n\nYou'll leave knowing which Rai
 ls patterns survive transpilation\, which ones don't\, and why "develop a
  monolith\, deploy a mesh" might be the future of Rails applications.
DTEND:20260716T123000
DTSTAMP:20260516T080239Z
DTSTART:20260716T120000
LOCATION:Main Stage - Red Rock
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:There Is No Server
UID:SZSESSION1184315
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Fito von Zastrow\n\nCode reviews got slower after we 
 introduced AI into our Ruby on Rails monolith. AI-generated code was maki
 ng the legacy problems worse\, not better. Technical debt\, fat controlle
 rs\, tests coupled to implementation. AI reproduced all of it\, faster th
 an ever. It's as if legacy code has gravity. In this talk\, you’ll learn 
 the concrete techniques we use in production: how to specify what you wan
 t\, how to provide architectural guidance to agents\, and how to use skil
 ls to put guardrails in place so feature work incrementally improves the 
 codebase instead of reinforcing legacy patterns. Leave with everything yo
 u need to defy Legacy Gravity.
DTEND:20260716T123000
DTSTAMP:20260516T080239Z
DTSTART:20260716T120000
LOCATION:Breakout 1 - Charleston D-C
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Defying Gravity: Teaching AI to Write Better Ruby
UID:SZSESSION1182989
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Hilary Stohs-Krause\n\nIf you work mostly on the back
 -end of the tech stack\, it’s easy to assume that your role is disengaged
  from accessibility concerns. After all\, that’s the front-end’s job! How
 ever\, there are multiple\, specific ways back-end devs can impact access
 ibility - not just for users\, but also for colleagues.
DTEND:20260716T123000
DTSTAMP:20260516T080239Z
DTSTART:20260716T120000
LOCATION:Breakout 2 - Charleston E-B
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:How to Accessibility if You’re Mostly Back-End
UID:SZSESSION1176206
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Alicia Rojas\n\nRails succeeded because it replaced t
 housands of micro-decisions with conventions. AI coding agents face the s
 ame problem at a different scale: they can write working code\, but witho
 ut structure\, they produce inconsistent\, insecure\, non-idiomatic outpu
 t that your team won't ship.\nThe bottleneck in AI-assisted development i
 s no longer writing code: it's verifying it. If your senior engineers spe
 nd their time reviewing AI-generated pull requests line by line\, you've 
 traded one bottleneck for another. The teams that will win are the ones t
 hat design systems to make AI output trustworthy by default.\nHarness eng
 ineering is that system design. Think of it this way: someone just invent
 ed a super-fertilizer that makes your plants grow seedling-to-oak-in-six-
 hours fast. Without a structure to make them grow the way you want\, you 
 get a jungle\, not a garden. The harness is the garden architecture. And 
 just as Rails gave Ruby structure\, the harness gives structure to the AI
  writing your Rails code.\nIn this talk\, I'll walk through the progressi
 on from "spicy autocompletion" to agentic engineering and the production 
 harness our consultancy built along the way\, organized around four pilla
 rs:\n\n- Instruct. A layered documentation system (global standards + pro
 ject-specific context) that acts as onboarding for the AI. Configuration 
 memory that gets smarter over time -- every mistake becomes a rule. The a
 gent reads your architecture decisions\, code patterns\, and reusable abs
 tractions before writing a single line.\n\n- Constrain. Custom RuboCop co
 ps (rubocop-harness) whose error messages are written for the AI agent\, 
 not just for humans. When a controller method is too long\, the message t
 ells the agent exactly where to extract\, which service pattern to use\, 
 and where to read more. Your linter becomes a communication channel to th
 e robot. You don't review style\, you enforce it mechanically.\n\n- Workf
 low. Structured commands that encode your development process as repeatab
 le\, agent-executable steps: plan before coding\, have a second agent rev
 iew the plan\, challenge before shipping\, verify before pushing. Agents 
 reviewing agents. You stop reviewing code and start building the systems 
 that review it for you.\n\n- Verify. AI-powered end-to-end testing (agent
 _e2e) where a separate agent drives a real browser against your running a
 pp\, executing plain-English test cases. The coding agent writes the code
 \; the testing agent proves it works. Agents validating agents\, with dif
 ferent trust boundaries.\nYou will leave knowing where you are on the pro
 gression\, what the next shift looks like\, and concrete patterns you can
  implement on Monday.\n
DTEND:20260716T151500
DTSTAMP:20260516T080239Z
DTSTART:20260716T144500
LOCATION:Main Stage - Red Rock
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Convention Over Hallucination: Harness Engineering for AI-Powered 
 Rails
UID:SZSESSION1182135
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Kyle d'Oliveira\n\nAre you ready to journey into the 
 weird side of Ruby? Join us as we dive deep into the Fibonacci sequence—b
 eyond the simple and into the spectacular. Forget the first\, tenth\, or 
 even the thousandth Fibonacci number\; we’re setting our sights on the bi
 llionth!\nIn this unusual talk\, we'll unravel eleven ways\, from simple 
 to downright mind-bending\, to compute Fibonacci numbers in Ruby. From st
 raightforward iterations\, to tail call optimization\, to complex matrix 
 operations. Discover some secret techniques and bizarre quirks of Ruby th
 at make calculating the billionth Fibonacci number not just possible\, bu
 t fast too. Whether you’re a Ruby newbie or a seasoned vet\, you’ll leave
  with a toolkit full of Fibonacci hacks and a newfound appreciation for t
 he playful power of Ruby. \n
DTEND:20260716T151500
DTSTAMP:20260516T080239Z
DTSTART:20260716T144500
LOCATION:Breakout 1 - Charleston D-C
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Fibonacci Funhouse
UID:SZSESSION1146179
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Markus Schirp\n\nAI code generators are great amplifi
 ers. They let developers move faster and produce more code. But amplifier
 s do not distinguish between signal and noise. They amplify misalignment 
 too.\n\nTests are the behavioral contract. A test can pass without verify
 ing the behavior you think it verifies. This has always been a problem. A
 t human speed it was survivable. At agentic speed it is a structural risk
 .\n\nMutation testing answers a simple question: are there semantics in t
 he code that the tests do not ask for? It systematically modifies code an
 d checks if the tests notice. Every surviving mutation is either dead cod
 e to remove or a missing test to write. Both outcomes are wins. Both are 
 actionable by humans and agents alike.\n\nThis talk explains how mutation
  testing closes the open loop between AI-generated code and AI-generated 
 tests. It demonstrates how mutant\, the mutation testing engine for Ruby\
 , fits naturally into agentic development workflows as a deterministic ve
 rification layer. Live examples show what surviving mutations look like\,
  how to act on them\, and how the feedback loop tightens both code and te
 sts regardless of who wrote them.\n\nNo prior mutation testing experience
  required.
DTEND:20260716T151500
DTSTAMP:20260516T080239Z
DTSTART:20260716T144500
LOCATION:Breakout 2 - Charleston E-B
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Pattern Parrots and the Semantic Knot: Mutation Testing in the Age
 ntic World
UID:SZSESSION1166776
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Alan Ridlehoover\n\nCode used to be something we cult
 ivated by hand. Now machines write it for us\, and a quarter of a million
  tech workers have been laid off in less than a year. If you've been quie
 tly grieving your relationship with code\, you're not alone. And you're n
 ot the first.\n\nIn 1958\, NASA began replacing its human computers with 
 IBM mainframes. Three women from the segregated West Area Computing Unit 
 — Dorothy Vaughan\, Mary Jackson\, and Katherine Johnson — made themselve
 s indispensable to the mission anyway. Each chose a different strategy: r
 etool\, transform\, or specify.\n\nNow it's our turn as Rubyists. The mis
 sion is still here. The role is not. This talk borrows their strategies\,
  with gratitude\, for the transition we're living through now — and shows
  how to stay indispensable.
DTEND:20260716T160000
DTSTAMP:20260516T080239Z
DTSTART:20260716T153000
LOCATION:Main Stage - Red Rock
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Indispensable: What Human Programmers Can Learn from Human Compute
 rs
UID:SZSESSION1183761
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Joé Dupuis\n\nAI is coming for our jobs! It's time to
  fight back!\n\nRuby is fast. Mass produced. Impersonal. What if it wasn'
 t? What if we could return to a simpler time\, when every computation was
  handcrafted by a real human being?\n\nIn this talk\, I fire the CPU and 
 hire real people to run Ruby instead. I built a human-powered virtual mac
 hine out of duct tape and Amazon Mechanical Turk. Every instruction lovin
 gly performed by hand\, while AWS burns a hole in my finances I'll never 
 recover from!\n\nI lied to the program committee that you'd learn about:\
 n\n- What happens after Ruby parses your code\n- Where to start if you wa
 nt to contribute to Ruby itself\n- How to use LLMs to learn the internals
  of complex projects\n- The economics of micro-labor\n- Cursed uses of Go
 ogle Sheets\n- ...and much more!\n\nAnd you just might!\n\nBut we all kno
 w you're here to see a Cronenberg abomination.\n\n"Why?\," "Is this tax d
 eductible?\," and "Are you okay?" are some of the many questions you'll b
 e asking yourself after this talk.\n
DTEND:20260716T160000
DTSTAMP:20260516T080239Z
DTSTART:20260716T153000
LOCATION:Breakout 1 - Charleston D-C
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Artisanal Computing: Handcrafted Ruby Execution for the Modern Age
UID:SZSESSION1175482
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:Speaker: Antônio Paulino\n\n## Abstract\n\nTribology is the sc
 ience of friction\, wear\, and lubrication. Might seem worlds apart from 
 software engineering. But there are some concepts we can use to connect t
 he dots: systems slow down under load\, interfaces degrade over time\, an
 d without proper "lubrication"\, can result in unexpected failures.\n\nIn
  this talk\, we'll explore how tribological principles apply to software 
 architecture and demonstrate how Rails conventions and tools act as the p
 erfect lubricant for building smooth\, maintainable systems. From reducin
 g friction in APIs to preventing wear in long-running applications\, you'
 ll see your codebase through a mechanical engineer's lens.\n\n## Outcomes
 \n\nAfter attending this talk\, the audience should know:\n\n1. How tribo
 logical concepts (friction\, wear\, lubrication) map to software engineer
 ing challenges\n2. Identifying "friction points" in your Rails applicatio
 ns and how to measure them\n3. Rails patterns and tools that act as "lubr
 icants" in your system architecture\n4. Strategies for preventing "wear" 
 and degradation over time\n\n## Outline\n\n### Intro: When Mechanical Eng
 ineering Meets Software\n\n- Brief introduction to Tribology: friction\, 
 wear\, and lubrication in mechanical systems.\n- The surprising parallels
  between mechanical and software systems.\n\n### Software Tribology\n\n**
 1. Friction: The Resistance to Motion**\n\n- In mechanics: Energy lost as
  heat when surfaces slide against each other.\n- In software: Cognitive l
 oad\, high CPU usage and slow API response times.\n- **Rails Solutions:**
 \n  - Convention over Configuration\n  - Generators minimize setup\n  - A
 ctiveRecord abstractions smooth database interactions\n\n**2. Wear: The P
 rogressive Degradation**\n\n- In mechanics: Material loss through repeate
 d contact and stress.\n- In software: Technical debt and performance degr
 adation.\n- **Rails Solutions:**\n  - Strong test culture (RSpec/Minitest
 ) catches bugs early\n  - Database migrations track schema evolution clea
 nly\n\n**3. Lubrication: The Layer That Enables Smooth Operation**\n\n- I
 n mechanics: Substances that separate surfaces and reduce direct contact.
 \n- In software: Caching\, middleware\, abstraction layers.\n- **Rails So
 lutions:**\n  - Rails.cache for increase performance\n  - ActionMailer/Ac
 tiveJob for asynchronous processing\n  - ActiveRecord Validations to prev
 ent bad data\n  - ActiveRecord Associations abstract complex joins\n  - A
 ctiveRecord Query Interface for readable queries\n\n### Measuring Tribolo
 gical Health\n\n**Tools for the Rails Tribologist:**\n- RuboCop\n- Brakem
 an\n- SimpleCov\n- Active Support Instrumentation\n\n### Conclusion: Buil
 ding Tribological Systems\n\n- Embrace Rails conventions as your primary 
 lubricant\n- Regularly measure and monitor friction points\n- Plan for we
 ar because it will eventually happen\n\n## Why This Talk Matters\n\nSoftw
 are engineers rarely think about their systems through a mechanical lens\
 , but the parallels are profound. By borrowing concepts from Tribology\, 
 we gain:\n\n1. **New vocabulary** for discussing system problems (frictio
 n vs. wear vs. inadequate lubrication)\n2. **Quantitative thinking** abou
 t code quality and maintainability\n3. **Preventive mindset** rather than
  reactive fixes\n4. **Appreciation for Rails design philosophy** as a "lo
 w-friction" framework with solid conventions\n\nThis cross-disciplinary a
 pproach offers fresh insights into age-old problems and demonstrates that
  great engineering principles transcend their domain of origin.
DTEND:20260716T160000
DTSTAMP:20260516T080239Z
DTSTART:20260716T153000
LOCATION:Breakout 2 - Charleston E-B
SEQUENCE:335136
STATUS:CONFIRMED
SUMMARY:Tribology on Rails: Reducing Friction and Wear in Software Systems
UID:SZSESSION1184153
END:VEVENT
END:VCALENDAR