Program
The largest official gathering, RubyConf brings together top talent, companies, and project representatives from around the world. Learn and build with the best in sessions, workshops, keynotes and other events.
Talks
TruffleRuby together with Truffle Regex can now execute Ruby Regexps up to 40 times faster than CRuby! This is possible by just-in-time compiling Ruby Regexps to machine code by using Truffle Regex, a Truffle language for regular expressions. Truffle Regex uses finite-state machines, a much faster alternative to backtracking regexp engines. Because of the unique capability of GraalVM to inline across languages, the Ruby code and the Regexp are optimized and compiled together for ultimate performance.
What to wear what to wear! The lemurs have a love for new robes and clothes, but these clothes are magical, and do some very interesting things. As it turns out decorating in Ruby can do rather unusual things to methods, classes, and even the lemurs.
Join the lemurs on a fashion-filled journey through decoration patterns in Ruby including tricks with method, define_method, method_added, and Module#prepend.
Async Ruby is an exciting and innovating part of Ruby. It's a new approach to concurrency best described as "threads with NONE of the downsides". Async Ruby has mind-blowing capabilities, and is so good Matz invited the gem to the standard library. Despite the upsides, and strong support from the Ruby core team, Async gem has stayed relatively off of Ruby mainstream.
This talk is suitable for both beginners and experts, and is relevant for you if you're making web requests in ruby. It will introduce you to some the most impressive async features and explain its core concepts.
JRuby is back! Development slowed during 2020 and early 2021, but with the release of JRuby 9.3 (supporting Ruby 2.6) and our work on full Ruby 3.0 support, we are back in the game. This talk will bring you up to date on the status of JRuby development. We will show examples of Ruby 3.0 features running at full speed on JRuby and demonstrate running the latest web and database frameworks with our enterprise-class performance. You will learn how to get started running apps on JRuby and how you can help us take JRuby compatibility and performance to the next level.
Desktop applications supporting line-of-business, enterprise functions live on as massive, complex beasts. Without an easy route into its internals and modernization falling by the wayside, it's up to you to make sure any small change doesn't break — well — everything. In this talk, we'll discuss the journey of bringing up a Windows VM to poke at an app using screenshots, image recognition, and Minitest to create our own Robotic Process Automation (RPA) framework.
When talking about performance, most developers think application speed, faster algorithms or better data structures. But what about your test suite? CI time is developer waiting time!
At Shopify we have more than 170,000 Ruby tests and we add 30,000 more annually. The sheer amount of tests and their growth requires some aggressive methods. We will illustrate some of our techniques including monitoring, test selection, timeouts and the 80/20 rule. If you have experience in writing tests and want to learn tricks on how to speed up your test suite, this talk is for you!
As the size of your project grows, some blocks of code become irrelevant. How can you find and delete them? And how can you be sure code is actually dead?
This talk will review a few techniques I learned from removing 50,000 lines of Ruby code at work.
We will see how git can help, with commands like blame, log --follow, and bisect.
We will talk about static analysis, and running code coverage in development.
We will explain how Ruby meta-programming can conflict with the "Find in Project" approach.
We will show how to be nice to reviewers when submitting Pull Requests that delete code.
We're used to using Regular Expressions every day for pattern matching and text replacement, but... What can Regexes actually do?
How far can we push them? Can we implement actual logic with them?
What if I told you... You can actually implement Conway's Game of Life with just a Regex?
What if I told you... You can actually implement ANYTHING with just a Regex?
Join me on a wild ride exploring amazing Game of Life patterns, unusual Regex techniques, Turing Completeness, programatically generating complex Regexes with Ruby, and what all this means for our understanding of what a Regex can do.
Have you ever stared at a blank feature spec file hoping for tests to magically appear? Well, you’re not alone! In this talk we’ll take a look at how the combination of Test-Driven Development, pseudocode and RSpec can help get you to your initial commit with confidence, one RSpec error at a time!
Mocking: it’s one of the most controversial topics in the testing world. Using mocks, we can more easily test parts of our applications that might otherwise go untested, but mocks can also be misused, resulting in tests that are brittle or downright self-referential.
So… how do we know when to use mocks in our tests? In this talk, we’ll identify three important questions that can help us make that decision. By the end of the talk, you will have a framework in mind to help you answer the question: to mock, or not to mock?
Pair programming is your best tool for getting new team members up to speed and writing high quality code, so your team can move faster and build for the long term.
In this talk, I’ll give you the How and Why of pair programming with your mentee, as well as practical actionable advice to have more productive, educational, and even fun pairing sessions. You’ll come away from this talk excited for your next pairing session, where you’ll write better quality code with a longer shelf life, and give your mentee programming superpowers they couldn’t achieve on their own.
Modern humans aren’t great at risk assessment.
We often blithely ignore that which could harm us, and are conversely intimidated by things that are quite safe. This inability to recognize threat has vast implications for many aspects of our lives, including our careers.
In this talk, we’ll explore root causes of fear and anxiety, and discover how we can start to deliberately rewrite our “instincts”. This will allow us to redirect our worry toward what actually matters, and channel it into productive outcomes that make us safer, happier and less stressed, both at work and in our personal lives.
PicoRuby is an alternative implementation of the mruby interpreter which runs on one-chip microcontrollers.
PRK Firmware is the world's first keyboard firmware framework in Ruby. You can write not only your own "keymap" in PicoRuby but also configure additional behavior with Ruby's features such as the open class system and the Proc object.
The ultimate goal is certainly not a small one --- let's make Ruby comparable to projects such as MicroPython, CircuitPython or Lua in terms of viability as a scripting language on Board!
Imposter syndrome is rampant among tech workers and there are so many ways that we put ourselves down and minimize our own accomplishments without even realizing it - and shame is a powerful and dangerous emotion. But everyone makes mistakes and in fact, making mistakes and learning from them makes us smarter! The tenets of cognitive behavioral therapy suggest that these kinds of harmful thought patterns are automatic, ingrained in us from years of practice. This talk will help you identify some of those thought patterns so you can challenge them and reframe them in healthier ways!
Are dynamically generated methods always slow? In this talk, we’ll recount our journey developing MemoWise, Ruby’s most performant memoization gem. It’s a tale of benchmark-driven development, unexpected object allocations, and learning to love eval. We’ll cover common performance problems in Ruby metaprogramming and the arcane techniques we used to overcome them.
The GitHub code base is growing at over 25% every year through contributions from over 1000 engineers, clocking in at 1.7+ million lines of Ruby. In this talk, we'll share how we use linters to keep our codebase healthy by ensuring best practices are applied consistently, feedback loops are as short as possible, and code reviews bring the most value, all without creating too much friction.
Want to know how to create and publish a Ruby gem? It only takes 15 minutes to learn, and this talk will show you how.
But when should you create a new gem? And how will the type of gem you make (e.g. an API wrapper, a testing DSL, or a CLI) impact its design, testing, and long-term maintenance?
Answering those questions is… harder. That's why the remaining 15 minutes of this talk will compress a decade of design missteps, dependency regrets, and versioning nightmares into actionable advice to help ensure that your next gem is a great one.
Ruby's long had leftward assignment (x = 3) and recently got rightward assignment (3 => x). The problem here is obvious: we need a vertical assignment operator. In a complete abdication of good taste and common sense, this talk will walk through correcting this heinous oversight. We'll abuse otherwise-respectable metaprogramming tools like Ripper and TracePoint to add a fully functional vequals operator. While this talk is almost 100% bad-ideas-by-volume, you'll learn a few tricks that you can use in your day-to-day work (or at least to terrify your co-workers).
This talk introduces ruby/debug: Debugging functionality for Ruby, a completely rewritten debugger for Ruby and it will be shipped with Ruby 3.1 at next Christmas.
The new debugger has several advantages:
- Fastest debugger: Using recent introduced
TracePointfeatures and (almost) no penalty on normal execution. - Remote debugger
- Native VSCode (DAP) integration
- Easy integration with applications
- Thread/Ractor support
- And more useful features!
In this talk, I'll introduce useful features of this new debugger and tips for Ruby development.
"Hi, this is a friendly reminder you have an appt on 12/07, Thursday 2pm". How hard can building and scaling an Appointment Reminder system be? An average developer can build such proof of concept in under a day. But to scale it to sending to millions of patients a week, nobody in our team thought it'd take us to rewrite it the 4th time. From dealing performance pain and ever increasing complexity, we poured in countless hours to come up with the perfect design. We have a thing or two to share about solving a seemingly trivial problem.
Breaking changes are sad. We’ve all been there; someone else changes their API in a way you weren’t expecting, and now you have a live-ops incident you need to fix urgently to get your software working again. Of course, many of us are on the other side too: we build APIs that other people’s software relies on.
This talk will cover how you can: (a) Get really good at identifying what changes might break someone’s integration (b) Help your API consumers to build integrations that are resilient to these kinds of changes (c) Release potentially breaking changes as safely as possible
What's a function? A function is a black box that takes an input and returns an output. Similarly, from the outside, HTTP requests take some request data to give it back as a response. Functions may compose if the output of one matches the input of the next one. web_pipe helps you build rack applications by plugging small process units that progressively create a response from a given request.
Ractor is a new concurrency mechanism in Ruby that unlocks great performance improvement possibilities. Its well defined sharing and messaging system makes it easier to reason about than threaded models.
Raft is a distributed consensus algorithm that backs distributed data stores such as Etcd, Console, and soon, Kafka; it’s designed to be straightforward and easy to understand.
In this session we’ll build a simple Raft implementation from scratch using Ractor. Ractor is one of the most exciting new features of Ruby, and modeling a distributed system is a great way to see what it can offer.
"Native gems" contain pre-compiled libraries for a specific machine architecture, removing the need to compile the C extension or to install other system dependencies. This leads to a much faster and more reliable installation experience for programmers.
This talk will provide a deep look at the techniques and toolchain used to ship native versions of Nokogiri (a commonly-used rubygem), and will discuss why human trust is an important requirement. Gem maintainers will learn how to build native versions of their own gems, and developers will learn how to use and deploy pre-compiled packages.
Repetitive stress injuries are scary for tech workers. If I can’t type, is my career over?
When my finger was injured last year, I had a long recovery period, and during that time, I learned to code using voice recognition software. In this talk, I’ll tell the whole story and demo the tool I learned.
Every language teaches you something beautiful, leading new and experienced programmers alike to novel and joyful ways to think about code. Would you benefit from a broader bag of programming concepts, or are you just curious about what can be learned when venturing outside your current box? From C++'s template metaprogramming to Scala's companion objects and more, this talk will explore a multitude of different programming languages and how the ideas and principles exemplified by each can be used by any other - but specifically, Ruby.
In 2009 _why tweeted: "programming is rather thankless. you see your works become replaced by superior works in a year. unable to run at all in a few more."
I take this as a call to action to run old code. In this talk we dig, together, through historical Ruby. We will have fun excavating interesting gems from the past.
Further, I will answer the following questions:
- What code greater than 12 years old still runs in Ruby 3.0?
- What idioms have changed?
- And for the brave: how can you set up an environment to run Ruby 1.8 code from ~2008 on a modern machine?
Do you know that methods are objects in Ruby? We can manipulate method objects just like other object, meaning that we can store them in variables, get information from them and wrap them in other objects like Proc.
In this talk, I'll show a real-world example of manipulating methods. I'll cover from the basic such as listing available methods and getting a method object to the difference between Method and UnboundMethod and redefining methods with original method object.
You spot a subtle security bug during a code review and flag it, making sure it's fixed before it gets deployed. Taking this one step further you want to make sure others don't make same mistake. Short of reviewing every piece of code, what can you do?
That's where Rubocop comes in. You can save time in code reviews by using it to enforce coding patterns and styles. As a security-minded engineer you might ask: could we use it to find security bugs? Turns out you can!
This talk will cover how Betterment uses Rubocop to detect vulnerabilities and the thought process that went into this work.
Service objects are an important tool in your toolbox, and Dry.rb's Transaction library is one of the most powerful, and one of the most magic. It's a "business transaction" DSL, and has error handling as a primary concern. We'll start by exploring Monads in Ruby (they're not scary!). Then we'll see how that simple concept unlocks another level of service objects that are far more robust and testable, and how to wire them all together with Dry::Transaction. Finally we'll touch on extending transactions with custom steps, and how to integrate them into an existing application.
Nothing stops a program from executing quite as fast as a syntax error. After years of “unexpected end” in my dev life, I decided to “do” something about it. In this talk we'll cover lexing, parsing, and indentation informed syntax tree search that power that dead_end Ruby library.
When thinking about issues faced by the underrepresented groups, we cannot ignore intersectionality. For eg. Women face plenty of challenges in STEM fields, and also face additional challenges based on their race, sexual orientation, nationality, disability, education, etc. This talk highlights the fierce urgency of now, in planning for intersectionality.
How do you become an expert? Why some Ruby developers can't explain what they know? Why some developers don't develop expert skills? What does it mean to be a Ruby expert?
To discuss these questions, we'll explore Perceptual Learning (PL) research. PL is a natural learning process that complements traditional Education. It accelerates expertise by speeding pattern recognition, intuition and fluency on a given subject.
In this talk, we'll learn how to create expertise based on PL's techniques, and how you can apply them to become an expert Ruby developer.
So much talk about good software revolves around finding the “right abstraction”. Even programming itself is an act of abstracting the world into some form of bits and bytes. If, like me, you missed out on a proper introduction to such a fundamental concept, this talk will teach you what abstraction is and why it’s important to software development.
We’ll also dig into a real-world example of fighting a troublesome abstraction and learn strategies for identifying when one no longer works for you—the first step toward imagining new abstractions for your code to take shape.
ArgumentErrors, TimeOuts, TypeErrors… even scanning a monitoring dashboard can be overwhelming. Any complex system is likely swimming in exceptions. Some are high value signals. Some are red herrings. Resilient applications that live in the entropy of the web require developers to be experts at responding to exceptions. But which ones and how?
In this talk, we’ll discuss what makes exception management difficult, tools to triage and respond to exceptions, and processes for more collective and effective exception management. We'll also explore some related opinions from you, my dear colleagues.
Programs which manipulate other programs are extremely fun and incredibly powerful. To write them, we need a way to represent code as a data structure which we can analyse, manipulate and eventually execute. In this talk we’ll learn how to store executable code as data in Ruby, and explore how to write different kinds of programs that process it.
It was the best of times, it was the worst of times: it was debugging time. Debugging is an inevitable reality of writing software; every developer has had a piece of code behave unexpectedly at some point or another.
But debugging can feel like magic: Where do you start looking for the bug, and how do you know where to find it?
In this talk, we'll learn what makes debugging hard, and the cognitive process behind it. We'll also explore using the scientific method as a debugging process model in order to help us get better at finding the bugs in our own Ruby programs. Let's become better debuggers together!
The rich development experience in integrated development environments (IDEs), including on-the-fly error reporting, refactoring feature, completion, etc., has become increasingly important. To achieve this, many programing languages are incorporating annotations such as type hinting. However, is such IDE features infeasible without annotations? We are challenging ourselves to achieve modern development experience with non-type-annotated Ruby programs by using TypeProf, which is a type analysis tool bundled in Ruby 3.0. In this talk, we demonstrate our prototype, and present its roadmap.
A black swan event refers “to unexpected events of large magnitude and consequence which then play a dominant role in history". With open source ecosystems increasing in complexity and growth as sociotechnical systems, we must examine how often these events are happening and if they are truly unexpected.
This talk will explore a series of events in open source history, some of which came as a surprise to users of the open source project and industry as a whole, had a wide and long-lasting impact on technology, or was inappropriately rationalized after the fact with the benefit of hindsight.
Are you:
- an embodied, thinking, feeling human
- who works together with other humans
- in a context of technical systems
- and wants that to go well?
If so, let's talk about aviation: a field that's become exceptionally safe by obsessively investigating accidents and sharing lessons learned. In addition to being fascinating engineering detective stories, these retrospectives yield recommendations that are useful for anyone who said "yes" to the above questions. I'll tell you stories of key accidents in aviation history and what we can learn from them.
(CW: injury, death.)
Software systems are made of code, and the people who work on them. But most of all, they're made of the stories those people tell. Heroic legends of shipping to deadline, spooky ghost stories of refactors gone bad... and a lot of sci-fi, projecting out into a utopian (or dystopian) future. How can you edit this story to make it go right? In this talk, we'll apply fiction-writing tricks to the art of engineering roadmapping. We'll learn how to build narratives, develop our characters, and world-build our way to healthier teams and healthier code.
Resilience is the ability to function in the face of damage or failure. This is a desirable trait in all of our work, but can be rather difficult to achieve. Let's look outside of our own practices to find inspiration for our own work!
In this talk we'll bring examples from outside tech. We’re talking aircraft carriers, race cars, priceless works of art, and hard-fought wisdom from across the accomplishments of humans and even nature itself. Join me in marveling at they ways things keep working, and we’ll get some cool ideas for how to create resilience in your organization or systems.
Ten years ago, Boeing faced a difficult choice. The Airbus A320neo was racking up orders faster than any plane in history because of its fuel efficiency improvements, and Boeing needed to compete. Should they design a new plane from scratch or just update the tried-and-true 737 with new engines?
The 737 MAX entered service seven years later as the result of that and hundreds of other choices along the way. Let’s look at some of those choices in context to understand how the 737 MAX went so very wrong. We’ll learn a thing or two along the way about making better decisions ourselves and as teams.
In the aftermath of John Allspaw's hugely influential "Blameless Post-Mortems", blamelessness has become a shibboleth for modern production operations teams. But it seems that something has been lost in translation. Organizations that try to "be blameless" without understanding blame often make activities taboo that can lead to blame. But many of them (like attribution and event analysis) are not inherently harmful — and they are necessary for learning. When we throw the baby of learning out with the bathwater of blaming, we also lose opportunities to become more resilient.
What could be simpler than the array? It's just a list of indexed values, right?
Well, not so fast. Ruby reimagines what an array can be, turning it into a randomizer, a 2D map, a stack, a queue, and a mathematical set. It also provides built-in utilities for unparalleled analysis and search of its contents.
Understanding arrays deeply is a powerful step forward in writing concise, beautiful, semantic Ruby.
Being early in your career always presents unique challenges, while being early in your second career later in life has its own particular issues to grapple with. The typical pipeline for the software industry does not fit the paradigm of an older career changer, and their presence can often throw the system for a loop.
In this talk, we will cover practical steps for navigating specific challenges related to hiring and being hired as a second-career dev. If approached with intention and thoughtfulness, the benefits can be immense for all involved.
You probably already know: In a unit test, use test doubles to sub real dependencies. You probably also know: In reality, things are not so easy. What do you do if the dependencies span multiple layers? What if the dependencies are implicit? If we can't find the best level of isolation, test doubles can be unwieldy very quickly and they will make the test, as well as the future you, miserable. In this talk, we will look at symptoms that produce unreliable and unmaintainable tests, and develop a strategy that will make your test suite more resilient and actually enjoyable.
We, as developers, spend a large portion of our time debugging software. Sometimes the problems are easy to understand, but many times they are not and we are thrown into unfamiliar code and are expected to quickly find the problem and craft a solution. However, honing the skill of debugging doesn’t come up as much as it should. In this talk, I’ll go through a generic approach to debugging that can be applied and built upon to help you excel as you move through your career solving problems for a living.
Is open-source intimidating? Are you nervous about your code being rejected by the maintainers? Or maybe you just don’t know where to start. I know those nerves well. Let’s talk about it. We'll go step-by-step through the process of finding an issue, creating a PR, and collaborating with maintainers. Let’s get you that first open-source PR!
Technical books can be a key and important source of learning for engineers and developers of all experience levels. However, it is not uncommon for some of us to pick up even a famously “approachable” text and struggle to hack our way through each page.
Help, however, is on the way -- there are concrete skills that engaged readers of all kinds of texts employ while reading. This talk will outline those techniques while also providing concrete questions that can be used during reading to help you stay more engaged, get more from the reading, and ultimately enrich your skills and knowledge.
From daemons that conceal themselves, to apps which lie to us, every day you're impacted by software with dishonest intentions.
No one starts their career building dishonest tools, but over time, the norms & incentives in specific industries (ex: infosec, advertising) can compromise the ethics of even the most principled developer.
In this talk we will...
- Define dishonest software using examples & counter-examples
- Arm you with compelling arguments to convince product leadership to build ethical software
- Explore how engineers can advocate for the data privacy rights of others
As engineers, we are constantly confronted with decisions, from the tiny – “how thick should this border box be?” – to the huge – “how will this algorithm affect the world?” How do we make those decisions? Come learn about contractualism, or how to treat your users as a part of a larger community. We’ll discuss the concept of the “user stack,” anyone who will use or be influenced by your work. Understanding the principles of contractualism and how to apply them makes it easier for you to make ethical decisions as a software engineer, and convince others at your organization to listen.
Am I My Algorithm's Keeper?
If I write an AI that then goes on to make unethical decisions, who's responsibility is it?
In this Talmudic-styled discussion, we will delve into ancient case laws to try and find legal and ethical parallels to modern-day questions.
We may not leave with all the answers, but hopefully, we will spark a conversation about the questions we should be asking.
Your app blows up in production. It's an outage and you're under pressure. You read the code. "How does this work? Why is this exception being caught here?" And so begins a long, stressful journey to understand how to fix your code.
Rescuing exceptions is normalised in Ruby, but it's a clumsy way of reacting to error conditions and causes your code to be difficult to reason about.
You'll refactor an existing app to use a functional style and see first hand how easy monads are to use and how they can make your code incredibly clean and expressive.
Background jobs have become an essential component of any Ruby infrastructure, and, as the Sidekiq Best Practices remind us, it is essential that jobs be "idempotent and transactional." But how do we make our jobs idempotent and transactional? In this talk, we will explore various techniques to make our jobs robust and ACIDic.
We began adopting gradual typing on Shopify's giant monolith almost 3 years ago. Today, we are running the monolith with great type coverage and even see some internal teams commit to stricter typing in their components.
The road to get here was not easy, though. We had to work with our developers to solve the right problems at the right levels of abstraction to ensure the adoption was healthy. This talk will go over some of the challenges and some of our wins along the way. It will also help you decide if gradual typing might work for your codebase and your team, as well.
Parallelizing tests is an opportune way of reducing the total runtime for a test suite. Rails achieves this by forking multiple separate workers that fetch tests from a queue. In Ruby 3, Ractors introduced new mechanisms for executing code in parallel. Can they be leveraged by a test framework? And how would that compare to current parallelization solutions?
Let’s find the answers to these questions by building a test framework built on Ractors, from scratch. We’ll compare the current solutions for parallelization and what advantages or limitations Ractors bring when used in this context.
Let's write a JIT for Ruby, in Ruby! We're going to learn how a JIT works from the ground up by building TenderJIT, a pure Ruby JIT compiler. First, we'll learn how Ruby's virtual machine works, then we'll learn how to plug a JIT in to the virtual machine. Finally, we'll generate machine code from our Ruby programs. By the end of the presentation we'll have a working JIT that converts Ruby code in to machine code all written in pure Ruby! But don't forget: some assembly is required!
Did you know that there have been at least sixteen attempts to build a compiler from Ruby to machine code? Why have there been so many? What were the ideas and context of each of these compilers? How are they similar and how are they different? What can we learn about compilers and Ruby from looking at them all? It turns out that we can trace the major advances in compiler research from the last couple of decades through Ruby!
Since Ruby's inception, there have been many different projects that parse Ruby code. This includes everything from development tools to Ruby implementations themselves. This talk dives into the technical details and tradeoffs of how each of these tools parses and subsequently understands your applications. After, we'll discuss how you can do the same with your own projects using the Ripper standard library. You'll see just how far we can take this library toward building useful development tools.
Ruby’s current memory model assumes all objects live in fixed size slots. This means that object data is often stored outside of the Ruby heap, which has implications: an object's data can be scattered across many locations, increasing complexity and causing poor locality resulting in reduced efficiency of CPU caches.
Join us as we explore how our Variable Width Allocation project will move system heap memory into Ruby heap memory, reducing system heap allocations and giving us finer control of the memory layout to optimize for performance.
Have you ever wondered how class variables (CVARs) in Ruby work? Would you be surprised to learn that their performance becomes increasingly worse as the inheritance chain grows? I’m excited to share that in Ruby 3.1 we fixed the performance of CVARs.
In this talk we'll look at the language design of class variables, learn about how they work, and, deep dive into how we improved their performance in Ruby 3.1 by adding a cache! We'll look at the cache design and real-world benchmarks showing how much faster they are regardless of the size of the inheritance chain.
At Stripe, “make it faster!” is one of our most requested features, but we don’t want to have to pause work on other features to get speed. Instead, we’ve built an ahead-of-time compiler for Ruby, powered by Sorbet and LLVM, focusing on improving latency in Stripe’s multi-million line Ruby code base.
In this talk, we’ll cover why we built it, how it works, and share preliminary results from compiling Stripe’s production Ruby code. It’s not quite ready for prime time yet, but we’re interested in sharing our approach and getting early feedback on the design.
Backtraces are very useful tools when debugging problems in Ruby programs. Unfortunately, backtrace generation is expensive for deep callstacks. In older versions of Ruby, this is true even if you only want a partial backtrace, such as a single backtrace frame. Thankfully, Ruby 3 has been optimized so that it no longer processes unnecessary backtrace frames, which can greatly speed up the generation of partial backtraces. Join me for an interesting look a Ruby backtraces, how they are generated, how we optimized partial backtraces in Ruby 3, and how we fixed bugs in the optimization in 3.0.1.
YJIT, an open source project led by a small team of developers at Shopify to incrementally build a new JIT compiler inside CRuby. Key advantages are that our compiler delivers very fast warm up, and we have complete, fine-grained control over the entire code generation pipeline. In this talk, I present the approach we are taking to implement YJIT and discuss early performance results. The talk will conclude with a discussion of what steps can be taken to unlock higher levels of performance for all JIT compilers built inside CRuby, be it YJIT, MJIT or any future JIT compiler efforts.
Since we introduced a JIT compiler to Ruby in 2.6, it had been known to slow down production applications like Rails. This year, we finally figured out why it was the case and found a way to fix it. Now we can even see the JIT compiler of Ruby 3.0 optimizes one of the most popular Rails applications.
In this talk, you'll learn some tricks to make sure it happens on your production application. Get the easy speedup of your application for free!
Everyone knows that to build great software you need great teams. Experts are quick to offer principles and processes that are “the key” to greatness.
But what if your team’s not “great”? It’s not “getting things done”. People don’t trust each other. There’s a lot of conflict. Low morale. Something is wrong.
Now what?
“Debugging” a team is a lot like caring for a complex distributed software system: it’s less about fixes, and more about observation, hypotheses, intervention, and more observation. Whatever your role, these are skills you can learn and apply right now, on your own teams.
If you or someone on your team ran away to join the circus, how stressful would it be for the rest of the team? How can we minimize that?
After a year+ in a pandemic, many are considering taking new roles or extended PTO. It's more important than ever to invest in minimizing our "circus factor" and building resilient teams so that everyone can unplug and do what's best for them with as little stress as possible. In this talk, we'll discuss low-friction changes you can make today so that if you join the circus tomorrow your team is empowered and enabled for continued success.
"Mid-level Engineers". Who are we? We have enough experience to understand the domain of a project and the technical know-how to provide guidance to earlier-career teammates. But how do we continue to grow and reach the next level of team leadership? Let's explore some of the initiatives we can take as mid-level engineers to level up our leadership skills, while contributing to the mentorship of newer engineers. You'll walk away with strategies to do so internal to the engineering team, across disciplines of Design and Product and externally with stakeholders and/or product owners.
What can fighting goblins teach us about working together? How can going on a perilous journey guide us through our careers? What if I told you I sit in a 4-hour meeting online every Friday night for fun?
Having played Dungeons and Dragons for almost a decade and playing remotely for half that time, I have learned lessons that have taught me how to interact as a developer on a distributed team. From general online etiquette to building great teams, I will discuss tips and tricks of roleplaying that can make someone a better coworker.
Code Golf is a fun form of programming competition where the aim is to produce the shortest source code that implements an algorithm. In this talk we will show how we tackle a complex problem: helping Santa schedule the work of his elves Army to deliver presents on Christmas Day. We will go step by step on how to find an algorithm to solve it and how to use Ruby’s language features to make it as short as possible. You’ll learn a few secret shortcuts built into Ruby that you probably don’t know about.
Simulation for robots is useful. But how do robots translate to real life factory environments? Find out with a mixed-reality simulation featuring real robots, lots of projectors, and of course, Ruby!
We use the excellent DragonRuby Game Toolkit to develop-mixed reality robotics simulations to: - enhance robot development - provide unique testing methods using real world robots - showcase robot behavior in digital-twins of our customer sites in our testing lab - take a break and build fun interactive experiences
Join us in an exploration of this dynamic and interactive robot exploration lab!
mruby is a lightweight implementation of the Ruby language. This talk focuses on how mruby differs from ruby, how its build system works, how to optimize its configuration for controlling a certain category (Tello) of programmable drones. It will include - flight control using UDP sockets in mruby - multiple drone control using Fibers in murby - multiple drone control using using Ruby Actors The talk will end with a demo of multi-drone acrobatics.
The terminal glowed a sickly pale green, reflecting in her lenses. “What do you mean, RecordInvalid?” she scoffed, and set to the task of debugging the factory. Hairs stood up on her neck as she realized the implications of her findings — she could practically smell the corrosion, but it was nobody’s fault. It was everyone’s fault. Data was long ago divorced from the human lives they were intended to improve. Dmitry bolted upright in a sweat. She was safe at home — it was all a dream, at least for now. There was still time. She started her morning routine, but breakfast was the last thing on her mind. She didn’t know all the factors, but she knew where to begin. Join me in this whimsical exploration of some not-so-whimsical tactics to put your test factories to work in some unconventional ways.
Curious about the Ruby and Rails Infrastructure team at Shopify and the projects the team is working on? Got questions from the various Shopify sessions at RubyConf so far? Join us at this meet-great-and-ask session to engage with Shopify's engineers in the Ruby and Rails Infrastructure team. Feel free to drop your questions here on Slido - bit.ly/shopifyrubyconfama - in advance.
Interested in learning about companies in the industry, or searching for your dream job? Join us at the RubyConf and hear from our Sponsors!
Writing boilerplate code can be draining. Breaking things out into classes and modules doesn't always make this process more enjoyable either. At Weedmaps, we've developed a suite of Domain Specific Languages (DSLs) for the vast majority of our workflows. This includes things like query objects all the way to crawlers. Done right, these tools allow team members to accomplish more with less. Done wrong, team members would have been better off writing everything from scratch. This talk is meant for those who want to build better tooling around repetitive workflows. It's also for those that want to better understand how some of these tools work under the hood. Embrace the magic!
Called “downcase” on nil? Forgot to return the right object in one of your logic branches? Called “first” on a String instead of an Array and spent half an hour trying to figure out why a single character was getting passed around everywhere?
At Grailed, these situations were not uncommon. We are the largest marketplace for luxury men's fashion, with over 7 million users, and a growing Rails codebase that spans hundreds of thousands of lines. Before typing, changes to core interfaces often required creative grepping, modification of type checking unit tests, and updating brittle type documentation.
Ever since we started gradually typing our codebase with Sorbet, we’ve been able to make intrusive changes faster and confidently. In this talk, we’ll walk you through our prior art, challenges, learnings, and big benefits of typing our codebase.
Interested in learning about companies in the industry, or searching for your dream job? Join us at the RubyConf and hear from our Sponsors!
Root is a car insurance company founded on the belief that good drivers should pay less for insurance since they’re less likely to get into accidents. Some drivers are paying significantly more than they should for car insurance because most carriers base rates primarily on demographics, not driving. We’re fixing that.
Root is reinventing the broken insurance industry by using technology in smartphones to measure driving behavior. The Root app measures things like smooth braking and turning to determine who is a safe driver and who isn’t. By only insuring good drivers, we can offer more affordable rates. And the software the engineering team built from scratch powers it all.
Maria will share more about how we built an insurance company from scratch and how our Engineering teams continue to unbreak the insurance industry every day.
Do you struggle to write documentation for your REST API? Do you often forget to update the docs after changing an endpoint? Does your API feel like a black box to other engineers? Do your docs say one thing, but your API does another? This talk is for you! We’ll explore all of these problems and discover how Rswag can solve them for you.
Scaling engineering organizations doesn't have to mean chaos, stress or losing the ability to have impact. In this talk I'll explain the principles we are applying at Wrapbook for scaling our Engineering teams to provide a healthy, happy and productive environment for people to do their best work