| Start...End time | Track name |
|---|---|
|
02:00 - 03:00 UTC |
tomoya ishida
Lang: ja
Track: Large Hall
Writing Weird CodeRuby is a great language to write readable code, and also to write unreadable weird code. In this talk, I will demonstrate how fun it is, and talk about the large effect of writing lots of weird code. Memo
tst
|
|
04:30 - 05:00 UTC |
Samuel Giddins
Lang: en
Track: Large Studio
Remembering (ok, not really Sarah) MarshalThough the Marshal serialization format has fallen out of favor over the past decade, due to a lack cross-language interoperability and security vulnerabilities, I think there’s a lot to learn from it. Having recently reimplemented Marshal.load to sidestep the security concerns, I want to reintroduce the Ruby community to the gem (see what I did there?) that is binary serialization. Let’s walk through how Marshal works under the hood, and see what ideas from it we can salvage for a modern take on data serialization. Memo |
|
05:10 - 05:40 UTC |
Yuji Yokoo
Lang: en
Track: Large Studio
Cross-platform mruby on Sega Dreamcast and Nintendo WiiDo you remember Nintendo Wii? It was a very successful video game console released in 2006. You can now write mruby code that runs on Nintendo Wii, with no hardware modification required. As mruby runs on Sega Dreamcast too, now you can write mruby code that runs on both Dreamcast and Wii (with caveats). I have ported the mruby block puzzle game I wrote for Dreamcast to Wii, and now I am porting the presentation application I used to present on Dreamcast at RubyKaigi Takeout 2020. The aim is to run the same mruby code on those 2 platforms with no or little modification. In this presentation, I will show you how I have done / am doing the porting work, and how you can write your own cross-platform mruby code for those 2 platforms. Memo |
|
05:50 - 06:20 UTC |
Daisuke Aritomo (osyoyu)
Lang: en
Track: Large Studio
The depths of profiling RubyUseful profilers are capable of accurately tracking program execution and providing sleek visualization, with minimal performance impact. When it comes to Ruby profilers, advanced features such as merging Ruby-level and C-level stacks or recording GC / GVL events would be also wanted. There were many challenges in implementing these features in Pf2, my experimental Ruby profiler. In this talk, I will visit the internals of CRuby and present the difficulties in creating a profiler for the interpreter. In this talk, I'll discuss the difficulties of creating a Ruby profiler through exploring the internals of CRuby, and introduce Pf2's design choices to overcome challenges. Let us discuss the future of profiling Ruby! Memo |
|
07:00 - 07:30 UTC |
Mari Imaizumi
Lang: ja
Track: Small Hall
Exploring Reline: Enhancing Command Line UsabilityReline is a pure Ruby implementation of GNU Readline; GNU Readline allows you to write configuration in `.inputrc`, and Reline reads this configuration file and sets key bindings. However, there are many things that GNU Readline can do that Reline cannot. This session will introduce those features and talk about their implementation in Reline. Memo |
|
07:40 - 08:10 UTC |
Misaki Shioi
Lang: ja
Track: Small Hall
An adventure of Happy EyeballsThe Ruby socket library, familiar to many, actually has an issue: it cannot quickly fallback to the other address family if it fails to resolve names or connect in either IPv6 or IPv4.<br/> I am challenging this with Happy Eyeballs Version 2 (HEv2) algorithm specified in [RFC8305](https://datatracker.ietf.org/doc/html/rfc8305). The algorithm performs name resolution for IPv6 and IPv4 almost simultaneously, prioritizing IPv6 but enabling fallback to IPv4. This sounds like a simple and nice idea!<br/> However, as I started the implementation, I realized that understanding the complex properties of HEv2, devising strategies to solve issues, and programming it is a kind of adventure.<br/> In this presentation, I will talk about how to get through them and how interesting it is to implement dual-stack support for socket libraries.<br/> Memo |
02:00 - 03:00
Ruby is a great language to write readable code, and also to write unreadable weird code. In this talk, I will demonstrate how fun it is, and talk about the large effect of writing lots of weird code.
04:30 - 05:00
Though the Marshal serialization format has fallen out of favor over the past decade, due to a lack cross-language interoperability and security vulnerabilities, I think there’s a lot to learn from it. Having recently reimplemented Marshal.load to sidestep the security concerns, I want to reintroduce the Ruby community to the gem (see what I did there?) that is binary serialization. Let’s walk through how Marshal works under the hood, and see what ideas from it we can salvage for a modern take on data serialization.
05:10 - 05:40
Do you remember Nintendo Wii? It was a very successful video game console released in 2006. You can now write mruby code that runs on Nintendo Wii, with no hardware modification required. As mruby runs on Sega Dreamcast too, now you can write mruby code that runs on both Dreamcast and Wii (with caveats). I have ported the mruby block puzzle game I wrote for Dreamcast to Wii, and now I am porting the presentation application I used to present on Dreamcast at RubyKaigi Takeout 2020. The aim is to run the same mruby code on those 2 platforms with no or little modification. In this presentation, I will show you how I have done / am doing the porting work, and how you can write your own cross-platform mruby code for those 2 platforms.
05:50 - 06:20
Useful profilers are capable of accurately tracking program execution and providing sleek visualization, with minimal performance impact. When it comes to Ruby profilers, advanced features such as merging Ruby-level and C-level stacks or recording GC / GVL events would be also wanted. There were many challenges in implementing these features in Pf2, my experimental Ruby profiler. In this talk, I will visit the internals of CRuby and present the difficulties in creating a profiler for the interpreter. In this talk, I'll discuss the difficulties of creating a Ruby profiler through exploring the internals of CRuby, and introduce Pf2's design choices to overcome challenges. Let us discuss the future of profiling Ruby!
07:00 - 07:30
Reline is a pure Ruby implementation of GNU Readline; GNU Readline allows you to write configuration in `.inputrc`, and Reline reads this configuration file and sets key bindings. However, there are many things that GNU Readline can do that Reline cannot. This session will introduce those features and talk about their implementation in Reline.
07:40 - 08:10
The Ruby socket library, familiar to many, actually has an issue: it cannot quickly fallback to the other address family if it fails to resolve names or connect in either IPv6 or IPv4.<br/> I am challenging this with Happy Eyeballs Version 2 (HEv2) algorithm specified in [RFC8305](https://datatracker.ietf.org/doc/html/rfc8305). The algorithm performs name resolution for IPv6 and IPv4 almost simultaneously, prioritizing IPv6 but enabling fallback to IPv4. This sounds like a simple and nice idea!<br/> However, as I started the implementation, I realized that understanding the complex properties of HEv2, devising strategies to solve issues, and programming it is a kind of adventure.<br/> In this presentation, I will talk about how to get through them and how interesting it is to implement dual-stack support for socket libraries.<br/>
| Start...End time | Track name |
|---|---|
|
01:20 - 02:20 UTC |
Samuel Williams
Lang: en
Track: Large Hall
Leveraging Falcon and Rails for Real-Time InteractivityIn the rapidly evolving landscape of web-based gaming, Ruby's potential for building dynamic, real-time interactive experiences is often underrated. This talk aims to shatter this misconception by demonstrating the powerful synergy between Falcon, an asynchronous web server, and Ruby on Rails, the stalwart of web application frameworks. We will embark on a journey to design and implement a real-time interactive game from the ground up, showcasing how Ruby, when coupled with Falcon's concurrency capabilities, can be a formidable tool in the gaming domain. Key focus areas will include leveraging Falcon's event-driven architecture for managing high-throughput, low-latency game data, and integrating it seamlessly with Rails to create an engaging user experience. Attendees will gain insights into the nuances of real-time web communication in Ruby, efficient handling of WebSockets, and the application of Rails' robust features in a gaming context. Memo |
|
02:30 - 03:00 UTC |
Peter Zhu
Adam Hess
Lang: en
Track: Large Hall
Finding Memory Leaks in the Ruby EcosystemRuby 3.3 introduces a powerful new feature for identifying memory leaks. Over the past year we have been working on improving memory usage within Ruby and developing tools to give native extension authors more confidence in memory management. In this talk, we will explain what memory leaks are, the impacts of memory leaks, our new feature RUBY_FREE_AT_EXIT in Ruby 3.3, and memory leaks found through this feature. In addition, we will discuss our future roadmap for Ruby 3.4 to improve this feature for native gem maintainers. Memo |
|
04:30 - 05:00 UTC |
Yuta Saito
Lang: en
Track: Small Hall
RubyGems on ruby.wasmRunning gems on WebAssembly is one of the most requested feature from the initial release of `ruby.wasm`. Today, `ruby.wasm` experimentally supports RubyGems integration, thanks to a recent WebAssembly ecosystem evolution called [Component Model](https://github.com/WebAssembly/component-model). It supports packaging your Ruby application and gem dependencies in a WebAssembly program! This talk will demonstrate the integration and share how it works. I hope it will unlock your interesting ideas. Memo |
|
05:10 - 05:40 UTC |
Jeremy Evans
Lang: en
Track: Large Hall
Reducing Implicit Allocations During Method CallingWhen optimizing Ruby code, one of the best strategies is to try to reduce the number of objects the code allocates. For some types of method calls, Ruby implicitly allocates objects as part of method call. In some cases, these implicit allocations are unavoidable, but in other cases, they are unnecessary. This presentation will discuss changes made in Ruby 3.3 and planned for Ruby 3.4 to reduce or eliminate implicit object allocation during method calling. We'll be going over new virtual machine instructions, changes to virtual machine stack layout in the compiler, method callinfo flags, iseq param flags, and how we fixed multiple bugs discovered during this optimization work. Memo |
|
05:50 - 06:20 UTC |
Maxime Chevalier-Boisvert
Lang: en
Track: Large Hall
Breaking the Ruby Performance BarrierWith each of the past 3 Ruby releases, YJIT has delivered higher and higher performance. However, we are seeing diminishing returns, because as JIT-compiled code becomes faster, it makes up less and less of the total execution time, which is now becoming dominated by C function calls. As such, it may appear like there is a fundamental limit to Ruby’s performance. In the first half of the 20th century, some early airplane designers thought that the speed of sound was a fundamental limit on the speed reachable by airplanes, thus coining the term “sound barrier”. This limit was eventually overcome, as it became understood that airflow behaves differently at supersonic speeds. In order to break the Ruby performance barrier, it will be necessary to reduce the dependency on C extensions, and start writing more gems in pure Ruby code. In this talk, I want to look at this problem more in depth, and explore how YJIT can help enable writing pure-Ruby software that delivers high performance levels. Memo |
|
07:00 - 07:30 UTC |
Benoit Daloze
Lang: en
Track: Large Studio
From Interpreting C Extensions to Compiling ThemSince the start, TruffleRuby took a unique approach to support C (and C++) extensions: to interpret and just-in-time compile them. This gave some unique advantages like optimizing and inlining C and Ruby together in the JIT and being able to debug C and Ruby in a single debugger. However it also has some downsides including long warmup times (it takes a while to JIT compile all the C extension code), compatibility with huge C extensions (e.g. grpc) and slower installation of C extensions gems. In the last release, TruffleRuby changed the approach to run C extensions natively, like CRuby. In this talk, we would like to tell you this story, illustrate the challenges and discuss which parts of the C API could be improved. We also explore how to run C extensions faster by using “Inline caches in C”, which could also be applied in CRuby. Come and learn from 10 years of implementing and optimizing C extensions in various ways! Memo |
|
07:40 - 08:10 UTC |
Martin J. Dürst
Lang: en
Track: Large Hall
Squeezing Unicode Names into Ruby Regular ExpressionsThis talk discusses the future of Ruby regular expressions. Ruby allows matching characters with many Unicode properties. The 'name' property is special, and requires special treatment. Unicode character names are different for each character and up to 80 or more characters long. We show how we can use the structure of the names to produce a compact representation of the data that can be efficiently searched. The solution relies on tries and radix trees as data structures, and care to try to use every single bit of memory. We compare memory requirements and speed with implementations for other languages such as Python, Perl, and Java. Memo |
|
08:20 - 09:20 UTC |
|
01:20 - 02:20
In the rapidly evolving landscape of web-based gaming, Ruby's potential for building dynamic, real-time interactive experiences is often underrated. This talk aims to shatter this misconception by demonstrating the powerful synergy between Falcon, an asynchronous web server, and Ruby on Rails, the stalwart of web application frameworks. We will embark on a journey to design and implement a real-time interactive game from the ground up, showcasing how Ruby, when coupled with Falcon's concurrency capabilities, can be a formidable tool in the gaming domain. Key focus areas will include leveraging Falcon's event-driven architecture for managing high-throughput, low-latency game data, and integrating it seamlessly with Rails to create an engaging user experience. Attendees will gain insights into the nuances of real-time web communication in Ruby, efficient handling of WebSockets, and the application of Rails' robust features in a gaming context.
02:30 - 03:00
Ruby 3.3 introduces a powerful new feature for identifying memory leaks. Over the past year we have been working on improving memory usage within Ruby and developing tools to give native extension authors more confidence in memory management. In this talk, we will explain what memory leaks are, the impacts of memory leaks, our new feature RUBY_FREE_AT_EXIT in Ruby 3.3, and memory leaks found through this feature. In addition, we will discuss our future roadmap for Ruby 3.4 to improve this feature for native gem maintainers.
04:30 - 05:00
Running gems on WebAssembly is one of the most requested feature from the initial release of `ruby.wasm`. Today, `ruby.wasm` experimentally supports RubyGems integration, thanks to a recent WebAssembly ecosystem evolution called [Component Model](https://github.com/WebAssembly/component-model). It supports packaging your Ruby application and gem dependencies in a WebAssembly program! This talk will demonstrate the integration and share how it works. I hope it will unlock your interesting ideas.
05:10 - 05:40
When optimizing Ruby code, one of the best strategies is to try to reduce the number of objects the code allocates. For some types of method calls, Ruby implicitly allocates objects as part of method call. In some cases, these implicit allocations are unavoidable, but in other cases, they are unnecessary. This presentation will discuss changes made in Ruby 3.3 and planned for Ruby 3.4 to reduce or eliminate implicit object allocation during method calling. We'll be going over new virtual machine instructions, changes to virtual machine stack layout in the compiler, method callinfo flags, iseq param flags, and how we fixed multiple bugs discovered during this optimization work.
05:50 - 06:20
With each of the past 3 Ruby releases, YJIT has delivered higher and higher performance. However, we are seeing diminishing returns, because as JIT-compiled code becomes faster, it makes up less and less of the total execution time, which is now becoming dominated by C function calls. As such, it may appear like there is a fundamental limit to Ruby’s performance. In the first half of the 20th century, some early airplane designers thought that the speed of sound was a fundamental limit on the speed reachable by airplanes, thus coining the term “sound barrier”. This limit was eventually overcome, as it became understood that airflow behaves differently at supersonic speeds. In order to break the Ruby performance barrier, it will be necessary to reduce the dependency on C extensions, and start writing more gems in pure Ruby code. In this talk, I want to look at this problem more in depth, and explore how YJIT can help enable writing pure-Ruby software that delivers high performance levels.
07:00 - 07:30
Since the start, TruffleRuby took a unique approach to support C (and C++) extensions: to interpret and just-in-time compile them. This gave some unique advantages like optimizing and inlining C and Ruby together in the JIT and being able to debug C and Ruby in a single debugger. However it also has some downsides including long warmup times (it takes a while to JIT compile all the C extension code), compatibility with huge C extensions (e.g. grpc) and slower installation of C extensions gems. In the last release, TruffleRuby changed the approach to run C extensions natively, like CRuby. In this talk, we would like to tell you this story, illustrate the challenges and discuss which parts of the C API could be improved. We also explore how to run C extensions faster by using “Inline caches in C”, which could also be applied in CRuby. Come and learn from 10 years of implementing and optimizing C extensions in various ways!
07:40 - 08:10
This talk discusses the future of Ruby regular expressions. Ruby allows matching characters with many Unicode properties. The 'name' property is special, and requires special treatment. Unicode character names are different for each character and up to 80 or more characters long. We show how we can use the structure of the names to produce a compact representation of the data that can be efficiently searched. The solution relies on tries and radix trees as data structures, and care to try to use every single bit of memory. We compare memory requirements and speed with implementations for other languages such as Python, Perl, and Java.
08:20 - 09:20
| Start...End time | Track name |
|---|---|
|
01:10 - 02:20 UTC |
CRuby Committers
Lang: ja
Track: Large Hall
Ruby Committers and the WorldCRuby committers on stage! Memo |
|
02:30 - 03:00 UTC |
Takashi Kokubun
Lang: en
Track: Large Hall
YJIT Makes Rails 1.7x FasterHave you enabled Ruby 3.3 YJIT? You’re using a much slower Ruby if you haven’t. YJIT makes Railsbench 1.7x faster. In production, YJIT presents a 17% speedup to millions of requests per second at Shopify. Why does YJIT make Ruby so much faster? In this talk, you’ll explore the latest YJIT optimizations that have a huge impact on your application’s performance. Once you understand what you're missing out on, you can't help but enable YJIT. Memo |
|
04:30 - 05:00 UTC |
Mike McQuaid
Lang: en
Track: Small Hall
Using "modern" Ruby to build a better, faster HomebrewHomebrew is a popular macOS package manager in the Ruby community and is also written in Ruby. When it was first created, it used the (fairly old) Ruby supplied by macOS and, until recently, has been tied to this version. Learn in this talk how and why Homebrew now ships its own Ruby to all users, modern Ruby tooling we now rely heavily on (e.g. Sorbet, RuboCop, etc.), how Ruby versions and our love of ActiveSupport have affected the performance of Homebrew and what we have planned in future to make Homebrew better, faster and more Ruby-like. Memo |
|
05:10 - 05:40 UTC |
Masatoshi SEKI
Lang: ja
Track: Large Hall
ERB, ancient and futureERB was released in 1999. 25th anniversary. In this talk, I will explain what I was thinking when designing the ERB API 25 years ago. I will also explain how supports block methods. Memo |
|
07:00 - 07:30 UTC |
Hiroya FUJINAMI
Lang: ja
Track: Large Hall
Make Your Own Regex Engine!Regular expression (regex) is a critical feature in Ruby. However, developers often say, "Regex is complicated and causes bugs.", so they avoid using regex. This seems to be due to their incorrect understanding of how regex matching works. The behavior of regex matching is actually **simple**, and a small regex engine (`kantan-regex`) can be implemented in a program of less than **300 lines**. In this talk, I will describe the behavior of regex matching through the implementation of `kantan-regex`. Furthermore, I will show how, with a few modifications, extensions such as look-around and optimizations such as memoization can be easily implemented. We believe that this talk will help to deepen our understanding of regex implementations and make using regex in everyday life more enjoyable. A tutorial on implementing `kantan-regex` is [available](https://makenowjust.github.io/kantan-regex-book/) on Web (Japanese only). Memo |
|
07:40 - 08:40 UTC |
|
01:10 - 02:20
CRuby committers on stage!
02:30 - 03:00
Have you enabled Ruby 3.3 YJIT? You’re using a much slower Ruby if you haven’t. YJIT makes Railsbench 1.7x faster. In production, YJIT presents a 17% speedup to millions of requests per second at Shopify. Why does YJIT make Ruby so much faster? In this talk, you’ll explore the latest YJIT optimizations that have a huge impact on your application’s performance. Once you understand what you're missing out on, you can't help but enable YJIT.
04:30 - 05:00
Homebrew is a popular macOS package manager in the Ruby community and is also written in Ruby. When it was first created, it used the (fairly old) Ruby supplied by macOS and, until recently, has been tied to this version. Learn in this talk how and why Homebrew now ships its own Ruby to all users, modern Ruby tooling we now rely heavily on (e.g. Sorbet, RuboCop, etc.), how Ruby versions and our love of ActiveSupport have affected the performance of Homebrew and what we have planned in future to make Homebrew better, faster and more Ruby-like.
05:10 - 05:40
ERB was released in 1999. 25th anniversary. In this talk, I will explain what I was thinking when designing the ERB API 25 years ago. I will also explain how supports block methods.
07:00 - 07:30
Regular expression (regex) is a critical feature in Ruby. However, developers often say, "Regex is complicated and causes bugs.", so they avoid using regex. This seems to be due to their incorrect understanding of how regex matching works. The behavior of regex matching is actually **simple**, and a small regex engine (`kantan-regex`) can be implemented in a program of less than **300 lines**. In this talk, I will describe the behavior of regex matching through the implementation of `kantan-regex`. Furthermore, I will show how, with a few modifications, extensions such as look-around and optimizations such as memoization can be easily implemented. We believe that this talk will help to deepen our understanding of regex implementations and make using regex in everyday life more enjoyable. A tutorial on implementing `kantan-regex` is [available](https://makenowjust.github.io/kantan-regex-book/) on Web (Japanese only).
07:40 - 08:40