| Start...End time | Track name |
|---|---|
|
01:50 - 03:00 UTC |
Lang: ja
Track: TrackGrand Auditorium
Ruby meets WebAssemblyWebAssembly (Wasm) is a binary format for programs written in any language, designed to eventually run everywhere without changes, mainly inside Web browsers. Wasm is now used beyond the Web, from edge computing to smart contracts in blockchain. Now CRuby can be compiled to WebAssembly, which can be run in web browsers and many non-web environments with WASI. This talk will give you how we got there, techniques, and its use cases. Memo |
|
04:30 - 05:00 UTC |
Lang: ja
Track: TrackGrand Auditorium
Making *MaNy* threads on RubyWe will introduce *MaNy* project: supports massive number of threads on Ruby. Concurrent mchanism (threads, processes, etc.) is an important language feature especially for multiple network connections. Ruby supports Ractor/Thread/Fiber for concurrency. However making many Threads (and Ractors) introduce huge overhead. Fiber scheduler was introduced for this purpose but it has some limitations. On the other languages, for example, Go language supports goroutine. They can make many goroutines and they can run concurrently or in parallel. Other languages (Erlang, Rust, ...) also support similar features. They use a well-known technique called M:N threading. In short, M:N threading supports many M threads on N (enough small number) system threads. *MaNy* project introduces M:N threading into Ruby. In this talk, we will show the background and progress of *MaNy* project. Because we are replacing the threading mechanism of current Ruby, we can share some details about it. Memo |
|
05:10 - 05:40 UTC |
Lang: ja
Track: TrackMiddle Auditorium
Types teaches success, what will we do?Are there “Types" of Ruby in the project you are involved with? Starting with Ruby 3.0, RBS and Steep are bundled, and Ruby now has static Types. Unfortunately, many projects have not yet introduced Types, I think. One reason for this is the lack of gem Types used in many projects. In this talk, I propose a contribution to `gem_rbs_collection` as one of the things we can do to promote the Type Ecosystem in Ruby. I'll walk you step by step through the process of contributing to `gem_rbs_collection` so that you can commit without hesitation when the opportunity arises. If more Rubyists become interested in gem_rbs_collection as a result of this talk, it is expected to accelerate the spread of the Type ecosystem. Memo |
|
05:50 - 06:20 UTC |
Lang: en
Track: TrackMiddle Auditorium
Adding Type Signatures into Ruby DocsSince Ruby's beginnings, its documentation has been maintained by people who help and support the language. Before the core team releases a new version of Ruby, contributors must update the documentation to reflect the current set of functionality, which presents many challenges to remaining consistent over Ruby's long history. One method may describe a set of arguments and the types one way, but another may tell them differently. Ruby 3 gained a highly requested feature, Type Annotations! A way to describe the structure of your Ruby Programs. In this talk, we'll look at improving Ruby's documentation by leveraging Ruby's Type Signatures to provide users with more accurate and consistent documentation. Memo |
|
06:50 - 07:20 UTC |
Lang: en
Track: TrackGrand Auditorium
Towards Ruby 4 JITFrom Ruby 3.1, we started to see CRuby's JIT compilers optimize real-world applications like Rails. However, you might be still wondering whether you should run it on production or not, given the fact that we're only seeing the beginning of the improvement. How far can we go in the foreseeable future? What would the impact on your production application look like? Let's talk about that together. Memo |
|
07:30 - 08:40 UTC |
Lang: ja
Track: TrackGrand Auditorium
TRICK 2022 (Returns)After four years, the programming contest comes back. Memo |
01:50 - 03:00
WebAssembly (Wasm) is a binary format for programs written in any language, designed to eventually run everywhere without changes, mainly inside Web browsers. Wasm is now used beyond the Web, from edge computing to smart contracts in blockchain. Now CRuby can be compiled to WebAssembly, which can be run in web browsers and many non-web environments with WASI. This talk will give you how we got there, techniques, and its use cases.
04:30 - 05:00
We will introduce *MaNy* project: supports massive number of threads on Ruby. Concurrent mchanism (threads, processes, etc.) is an important language feature especially for multiple network connections. Ruby supports Ractor/Thread/Fiber for concurrency. However making many Threads (and Ractors) introduce huge overhead. Fiber scheduler was introduced for this purpose but it has some limitations. On the other languages, for example, Go language supports goroutine. They can make many goroutines and they can run concurrently or in parallel. Other languages (Erlang, Rust, ...) also support similar features. They use a well-known technique called M:N threading. In short, M:N threading supports many M threads on N (enough small number) system threads. *MaNy* project introduces M:N threading into Ruby. In this talk, we will show the background and progress of *MaNy* project. Because we are replacing the threading mechanism of current Ruby, we can share some details about it.
05:10 - 05:40
Are there “Types" of Ruby in the project you are involved with? Starting with Ruby 3.0, RBS and Steep are bundled, and Ruby now has static Types. Unfortunately, many projects have not yet introduced Types, I think. One reason for this is the lack of gem Types used in many projects. In this talk, I propose a contribution to `gem_rbs_collection` as one of the things we can do to promote the Type Ecosystem in Ruby. I'll walk you step by step through the process of contributing to `gem_rbs_collection` so that you can commit without hesitation when the opportunity arises. If more Rubyists become interested in gem_rbs_collection as a result of this talk, it is expected to accelerate the spread of the Type ecosystem.
05:50 - 06:20
Since Ruby's beginnings, its documentation has been maintained by people who help and support the language. Before the core team releases a new version of Ruby, contributors must update the documentation to reflect the current set of functionality, which presents many challenges to remaining consistent over Ruby's long history. One method may describe a set of arguments and the types one way, but another may tell them differently. Ruby 3 gained a highly requested feature, Type Annotations! A way to describe the structure of your Ruby Programs. In this talk, we'll look at improving Ruby's documentation by leveraging Ruby's Type Signatures to provide users with more accurate and consistent documentation.
06:50 - 07:20
From Ruby 3.1, we started to see CRuby's JIT compilers optimize real-world applications like Rails. However, you might be still wondering whether you should run it on production or not, given the fact that we're only seeing the beginning of the improvement. How far can we go in the foreseeable future? What would the impact on your production application look like? Let's talk about that together.
07:30 - 08:40
After four years, the programming contest comes back.
| Start...End time | Track name |
|---|---|
|
00:30 - 01:40 UTC |
|
|
01:50 - 02:20 UTC |
Lang: en
Track: TrackGrand Auditorium
Ruby debugger - The best investment for your productivityIn this talk, I want to show you how adopting the Ruby debugger (`ruby/debug`) can be the single best thing to improve your productivity. It will include: - The difference between puts debugging, REPL (`Pry`/`IRB`) debugging and debugger debugging - Comparison with byebug - How you can use debugger to achieve even better puts and REPL debugging result: - Replace REPL debugging with breakpoint commands - Replace puts debugging with tracing and context commands - Automate debugging steps with `do:` and `pre:` options - Remote debugging capability - The debugging tooling spectrum and when you should **not** use the debugger Memo |
|
02:30 - 03:00 UTC |
Lang: ja
Track: TrackMiddle Auditorium
Make RuboCop super fastRuboCop introduces the new server options for super fast mode. RuboCop 2.0 has the catchphrase RuboCop 2x2, like Ruby 3x3. the server mode is a big move towards that. This is perfect for the current era where quick feedback to developer is required, especially when interacting with text editors and IDEs. Through the design and implementation of server options, you will get the essence of how fast RuboCop works. Memo |
|
04:30 - 05:00 UTC |
Lang: en
Track: TrackMiddle Auditorium
Ruby x BPF in Action: How important observability isDo you like to measure your code? When it comes to applications that you write mainly in Ruby, there are powerful observability tools such as stackprof, but what about observability outside the Ruby world such as C, C++ and Rust? BPF will be perfect for solving those problems. So, what is BPF? BPF is one of the emerging technologies for Linux. The talk focuses on what the BPF is for the audiences who are new to BPF. I will give a brief history and basic concepts at first. And I will also illustrate its strong points and restrictions compared to existing tools (e.g. strace or perf); The talk will also cover the relationship between the various tools related to BPF (you might have heard of BCC, bpftrace, RbBCC, Rucy, etc.). In addition, I will give examples of BPF use cases applied for smaller or PoC Ruby applications. Finally, practical performance measurement and tuning cases using BPF based on several Rust-based Rubygems (owned by the author) will be introduced. Memo |
|
05:10 - 05:40 UTC |
Lang: ja
Track: TrackMiddle Auditorium
How fast really is Ruby 3.x?Ruby 3 brings novel improvements such as YJIT and Ractor, but the extent to which these techniques can speed up real applications is unknown. Performance claims should not be accepted solely based on abstract theories or micro benchmarks, but by the supporting evidence from actual applications. We recently ported a large-scale, open-source Ruby application (Fluentd) to Ruby 3, and conducted a survey to obtain an estimate of the speed improvements over Ruby 2.x. This talk will explain and discuss the results. Memo |
|
05:50 - 06:20 UTC |
Lang: en
Track: TrackGrand Auditorium
Hunting Production Memory Leaks with Heap SamplingExisting Ruby tooling is quite helpful when investigating memory leaks if and when we can reproduce them on our development machine or staging environment. But what about those cases when the memory leak only really shows up in Production? Perhaps over a long time period? In this talk, we introduce the `ruby_memprofiler_pprof` heap profiling gem, showing how low-overhead heap sampling can be implemented and used to investigate memory leaks in production. We also discuss early production wins when using this technique at Zendesk. Memo |
|
06:50 - 07:20 UTC |
Lang: ja
Track: TrackMiddle Auditorium
Create my own search engine.What do you do after reading the search engine textbook? In this talk, I will explain about the creation of my own search engine. I needed a search engine for Pokemon TCG decks. I will explain the implementation of this search engine and the technique of operation on Heroku. Memo |
|
07:30 - 08:40 UTC |
Lang: ja
Track: TrackGrand Auditorium
Ruby Committers vs The WorldRuby core committers on stage! Memo |
00:30 - 01:40
01:50 - 02:20
In this talk, I want to show you how adopting the Ruby debugger (`ruby/debug`) can be the single best thing to improve your productivity. It will include: - The difference between puts debugging, REPL (`Pry`/`IRB`) debugging and debugger debugging - Comparison with byebug - How you can use debugger to achieve even better puts and REPL debugging result: - Replace REPL debugging with breakpoint commands - Replace puts debugging with tracing and context commands - Automate debugging steps with `do:` and `pre:` options - Remote debugging capability - The debugging tooling spectrum and when you should **not** use the debugger
02:30 - 03:00
RuboCop introduces the new server options for super fast mode. RuboCop 2.0 has the catchphrase RuboCop 2x2, like Ruby 3x3. the server mode is a big move towards that. This is perfect for the current era where quick feedback to developer is required, especially when interacting with text editors and IDEs. Through the design and implementation of server options, you will get the essence of how fast RuboCop works.
04:30 - 05:00
Do you like to measure your code? When it comes to applications that you write mainly in Ruby, there are powerful observability tools such as stackprof, but what about observability outside the Ruby world such as C, C++ and Rust? BPF will be perfect for solving those problems. So, what is BPF? BPF is one of the emerging technologies for Linux. The talk focuses on what the BPF is for the audiences who are new to BPF. I will give a brief history and basic concepts at first. And I will also illustrate its strong points and restrictions compared to existing tools (e.g. strace or perf); The talk will also cover the relationship between the various tools related to BPF (you might have heard of BCC, bpftrace, RbBCC, Rucy, etc.). In addition, I will give examples of BPF use cases applied for smaller or PoC Ruby applications. Finally, practical performance measurement and tuning cases using BPF based on several Rust-based Rubygems (owned by the author) will be introduced.
05:10 - 05:40
Ruby 3 brings novel improvements such as YJIT and Ractor, but the extent to which these techniques can speed up real applications is unknown. Performance claims should not be accepted solely based on abstract theories or micro benchmarks, but by the supporting evidence from actual applications. We recently ported a large-scale, open-source Ruby application (Fluentd) to Ruby 3, and conducted a survey to obtain an estimate of the speed improvements over Ruby 2.x. This talk will explain and discuss the results.
05:50 - 06:20
Existing Ruby tooling is quite helpful when investigating memory leaks if and when we can reproduce them on our development machine or staging environment. But what about those cases when the memory leak only really shows up in Production? Perhaps over a long time period? In this talk, we introduce the `ruby_memprofiler_pprof` heap profiling gem, showing how low-overhead heap sampling can be implemented and used to investigate memory leaks in production. We also discuss early production wins when using this technique at Zendesk.
06:50 - 07:20
What do you do after reading the search engine textbook? In this talk, I will explain about the creation of my own search engine. I needed a search engine for Pokemon TCG decks. I will explain the implementation of this search engine and the technique of operation on Heroku.
07:30 - 08:40
Ruby core committers on stage!
| Start...End time | Track name |
|---|---|
|
00:30 - 01:00 UTC |
Lang: ja
Track: TrackGrand Auditorium
error_highlight: user-friendly error diagnosticsRuby 3.1 has introduced a gem called "error_highlight", which shows a code snippet with an underline to spot where `NameError` or `NoMethodError` was raised. ``` $ ruby test.rb test.rb:1:in `<main>': undefined method `[]' for nil:NilClass (NoMethodError) json[:foo][:bar] ^^^^^^ ``` We will talk about the design and implementation of error_highlight: how it works, why and how we designed it, how we resolved the difficulties we faced during implementation, and the feedback we received. This feature goes further in Ruby 3.2: more error support other than `NameError`/`NoMethodError` and more fine-grained error spotting. We also redesigned its backend by introducing a new API, `Exception#detailed_message`, which allows us to enhance error messages with fewer incompatibilities. In fact, it allowed simple integration with other error message extensions such as did_you_mean and dead_end. We will also talk about what we would like users to help us with to make error_highlight better. Memo |
|
01:10 - 01:40 UTC |
Lang: ja
Track: TrackMiddle Auditorium
RBS generation framework using Rack architectureFor a happy programming experience, type support is a very effective approach. However, type information is still far from sufficient. RBS definition is labor intensive. I have worked on RBS definitions for several libraries and applications. From my experience, I have found that different libraries and applications have very different needs for RBS generation. Therefore, I am developing a code generation framework for RBS. By writing code generation scripts using this framework, you can automate RBS generation as much as possible in accordance with Ruby code updates. You can use the Rack architecture to combine your preferred features to meet a variety of needs. In addition, you can test your own extensions on the fly or publish them as extension gems. This talk will present the progress of the project, implementation details, as well as the usefulness of the Rack architecture in one-shot scripting. Memo |
|
01:50 - 02:20 UTC |
Lang: ja
Track: TrackMiddle Auditorium
Let's collect type info during Ruby running and automaticallCurrently, Ruby is introducing RBS, which defines type information, and developing TypeProf, which statically analyzes Ruby code to extract type information, as efforts to improve the Developer Experience. So I am working on a different approach than TypeProf, using `TracePoint` to collect information on method calls when Ruby code is executed and generate RBS files based on that information. I will explain the advantages and disadvantages of this approach compared to TypeProf, as well as how I achieved it. Let's use this session as an opportunity to get more people interested in RBS and work together to improve the future Ruby Developer Experience! Memo |
|
02:30 - 03:00 UTC |
Lang: ja
Track: TrackMiddle Auditorium
Why is building the Ruby environment hard?The Rubyists are facing the build error with missing libraries like openssl, libyaml and libffi issues when they install the new versions every year. Other people are facing issues of nokogiri, rmagick and others when they develop Rails application. Why we got these issues everyday? I describe the build failure case and their solution from the ruby-build maintainer's point of view. Finally, I introduce the plan for the imcompatible changes about build process in Ruby 3.2 and Rust support of next version of RubyGems. Memo |
|
04:30 - 05:00 UTC |
Lang: ja
Track: TrackMiddle Auditorium
The Better RuboCop World to enjoy RubyTools like RuboCop are very useful. I am very grateful for contributors. I think it's really helpful to keep our code clean and consistent. However, sometimes I feel there is a gap between 'Cop' culture and Ruby culture. In general, 'Cop' restricts our rights though Ruby gives freedom to us. I understand we have right not to use RuboCop or disable some Cops. But it is not very easy in reality, especially for Ruby beginners in their teams. To make them happier, experts would be able to set up config perfectly. But again, it is not very easy in reality. As a result, even though there is no evil, in some case people wrongfully make detour and give up their creativeness to keep CI green. It's a pity, isn't it? In this talk, I introduce my thoughts on RubyCop and programming and some idea of a bit better RuboCop world, with lower risk to damage productivity and to misguide beginners. Memo |
|
05:10 - 05:40 UTC |
Lang: en
Track: TrackMiddle Auditorium
Ethereum for RubyThis talk will cover the use of Ruby libraries that interact with the Ethereum blockchain and their implementation. You will get an overview of the Ethereum ecosystem, how blockchain transactions work, how signatures work, and learn how to use eth.rb. How it is implemented in Ruby code will also be explained. Lets create a web application that connects to the blockchain together. Memo |
|
05:50 - 06:20 UTC |
Lang: ja
Track: TrackMiddle Auditorium
String Meets EncodingRuby's String has Encoding, which allows for very flexible character encoding. What is the trade-off for that flexibility? I recently looked at the bottleneck in CSV.read and found that in one file with Encoding CP932, 30% of the processing time was spent on String#split. From the perspective of optimizing String#split, we will explain the relationship between String and Encoding in Ruby, how String knows its own Encoding, and which process is the bottleneck. Then we will discuss approaches toward faster encoding. Memo |
|
06:50 - 07:20 UTC |
Lang: ja
Track: TrackMiddle Auditorium
History of Japanese Ruby reference manual, and futureI will talk about history of Japanese reference manual and future plans. Contributing to current Japanese Ruby reference manual (rurema) is harder than other projects. Because current document format (based on RD) is not familiar to recent Ruby users, and there are a few documents for new contributors. So I will explain historical reasons and how to improve systems for new contributors. Memo |
|
07:30 - 08:40 UTC |
Lang: en
Track: TrackGrand Auditorium
Stories from developing YJITYJIT is CRuby's second just-in-time compiler first released with Ruby 3.1.0. Much sweat and tears were shed during YJIT's development. What are the performance goals of YJIT and how are we going for them? How do CPUs react to YJIT's output? What is it like to retrofit a JIT compiler into a runtime system with a long history? Why is Rust involved now? Memo |
00:30 - 01:00
Ruby 3.1 has introduced a gem called "error_highlight", which shows a code snippet with an underline to spot where `NameError` or `NoMethodError` was raised. ``` $ ruby test.rb test.rb:1:in `<main>': undefined method `[]' for nil:NilClass (NoMethodError) json[:foo][:bar] ^^^^^^ ``` We will talk about the design and implementation of error_highlight: how it works, why and how we designed it, how we resolved the difficulties we faced during implementation, and the feedback we received. This feature goes further in Ruby 3.2: more error support other than `NameError`/`NoMethodError` and more fine-grained error spotting. We also redesigned its backend by introducing a new API, `Exception#detailed_message`, which allows us to enhance error messages with fewer incompatibilities. In fact, it allowed simple integration with other error message extensions such as did_you_mean and dead_end. We will also talk about what we would like users to help us with to make error_highlight better.
01:10 - 01:40
For a happy programming experience, type support is a very effective approach. However, type information is still far from sufficient. RBS definition is labor intensive. I have worked on RBS definitions for several libraries and applications. From my experience, I have found that different libraries and applications have very different needs for RBS generation. Therefore, I am developing a code generation framework for RBS. By writing code generation scripts using this framework, you can automate RBS generation as much as possible in accordance with Ruby code updates. You can use the Rack architecture to combine your preferred features to meet a variety of needs. In addition, you can test your own extensions on the fly or publish them as extension gems. This talk will present the progress of the project, implementation details, as well as the usefulness of the Rack architecture in one-shot scripting.
01:50 - 02:20
Currently, Ruby is introducing RBS, which defines type information, and developing TypeProf, which statically analyzes Ruby code to extract type information, as efforts to improve the Developer Experience. So I am working on a different approach than TypeProf, using `TracePoint` to collect information on method calls when Ruby code is executed and generate RBS files based on that information. I will explain the advantages and disadvantages of this approach compared to TypeProf, as well as how I achieved it. Let's use this session as an opportunity to get more people interested in RBS and work together to improve the future Ruby Developer Experience!
02:30 - 03:00
The Rubyists are facing the build error with missing libraries like openssl, libyaml and libffi issues when they install the new versions every year. Other people are facing issues of nokogiri, rmagick and others when they develop Rails application. Why we got these issues everyday? I describe the build failure case and their solution from the ruby-build maintainer's point of view. Finally, I introduce the plan for the imcompatible changes about build process in Ruby 3.2 and Rust support of next version of RubyGems.
04:30 - 05:00
Tools like RuboCop are very useful. I am very grateful for contributors. I think it's really helpful to keep our code clean and consistent. However, sometimes I feel there is a gap between 'Cop' culture and Ruby culture. In general, 'Cop' restricts our rights though Ruby gives freedom to us. I understand we have right not to use RuboCop or disable some Cops. But it is not very easy in reality, especially for Ruby beginners in their teams. To make them happier, experts would be able to set up config perfectly. But again, it is not very easy in reality. As a result, even though there is no evil, in some case people wrongfully make detour and give up their creativeness to keep CI green. It's a pity, isn't it? In this talk, I introduce my thoughts on RubyCop and programming and some idea of a bit better RuboCop world, with lower risk to damage productivity and to misguide beginners.
05:10 - 05:40
This talk will cover the use of Ruby libraries that interact with the Ethereum blockchain and their implementation. You will get an overview of the Ethereum ecosystem, how blockchain transactions work, how signatures work, and learn how to use eth.rb. How it is implemented in Ruby code will also be explained. Lets create a web application that connects to the blockchain together.
05:50 - 06:20
Ruby's String has Encoding, which allows for very flexible character encoding. What is the trade-off for that flexibility? I recently looked at the bottleneck in CSV.read and found that in one file with Encoding CP932, 30% of the processing time was spent on String#split. From the perspective of optimizing String#split, we will explain the relationship between String and Encoding in Ruby, how String knows its own Encoding, and which process is the bottleneck. Then we will discuss approaches toward faster encoding.
06:50 - 07:20
I will talk about history of Japanese reference manual and future plans. Contributing to current Japanese Ruby reference manual (rurema) is harder than other projects. Because current document format (based on RD) is not familiar to recent Ruby users, and there are a few documents for new contributors. So I will explain historical reasons and how to improve systems for new contributors.
07:30 - 08:40
YJIT is CRuby's second just-in-time compiler first released with Ruby 3.1.0. Much sweat and tears were shed during YJIT's development. What are the performance goals of YJIT and how are we going for them? How do CPUs react to YJIT's output? What is it like to retrofit a JIT compiler into a runtime system with a long history? Why is Rust involved now?