Recent languages like Go compiles a project into a nice executable, why can't good ol' Ruby? We have built an packer for Ruby to do just that. It is 100% open-source, and can produce executables for Windows, macOS and Linux individually. By packing, distributing Ruby apps are made extremely easy, additionally with intellectual property protection. Auto-updating is also made easy, in that the executable only needs to download and replace itself. So, how we did it? How to use it? What goes under the hood? What future will this bring to Ruby? That's what will be unraveled in this talk!
Playing games and interacting with graphics, media, and devices is fun, but programming them rarely is. Even the simplest things can seem overwhelmingly complex and unnecessarily difficult, but it doesn't have to be that way! Let's explore how Ruby can help us design a more natural and expressive experience by leveraging MRI, mruby, and Opal, opening up possibilities natively and on the web. We'll poke under the hood of a cross-platform 2D engine designed to be scripted with Ruby. Many opportunities lie ahead in game development, education, and creative coding, so let's seize them — join us!
Runtime errors can sometimes turn into dark and unpleasant journeys which lead you to question the nature of reality. Thankfully, Ruby often provides friendly feedback for understanding the cause and remedy for exceptions. Yet, there are situations in which programmers don't receive clear enough context for what really caused an exception and how to address it. We'll look at Ruby's error feedback mechanisms and search for constructive ways in which they can be made more helpful to humans.
One of the most important lessons I've learned is that programming languages are tools and not all tools are good for all jobs. Some tasks are easier to solve functionally. Some are clearly suited for OO. Others get simpler when you use constraint solving or pattern matching.
Let's go on a whirlwind tour of 4 different programming languages emphasizing different programming techniques: OO, functional, logical, and procedural. You'll leave this talk with a better understanding of which languages are best suited to which types of jobs and a list of resources for learning more.
Using the popular space simulator Kerbal Space Program and some remote procedure calls, we're going to use Ruby to launch (simulated) rockets into space! We'll discuss the history of computing in the space program, real-life algorithms for getting rockets into orbit like the Space Shuttle's Powered Explicit Guidance Ascent System, and the software architecture of historic space computers like the Apollo Guidance Computer. Finally, we'll build our own orbital rocket, controlled by a Ruby program that emulates space computers of the past.
This talk will teach you how to play rock-paper-scissors (no really, it’s more complicated than you might think) plus a little bit about AI history. It will also make you laugh — at least a little. You'll also learn some game theory, some mind games, and finally, how to build a world champion bot in the universe of Rock Paper Scissors.
This talk is aimed at all levels of Ruby programmers - beginner or advanced. All the examples in the talk and are explained step by step, and many of them relatively basic.
Often we know that our code needs refactoring, but we have no idea where to start. Maybe we studied some common code smells and learned about the things that we should be avoiding, but memorizing the rules doesn’t automatically lead to fixing all problems. In this talk, we explore how you can use Git to recognize and address violations to each of the SOLID principles. Using diffs, commit history and pull requests you can learn to recognize patterns in code that point to problems. These same tools can help you correct those issues and write more maintainable code.
There are a lot of things that can go wrong when working with Unicode data. Some examples of unmeant behavior:
You try to downcase "I" to "i", but your Turkish friends want it to be a dotless "ı"
Your UI is broken, because people use empty usernames, despite the String#blank? check
You think "C" is the same letter as "С", but your system does not think so and crashes
Using ten characters as representatives, I will highlight some Unicode characteristics which require a programmer's attention and demonstrate how Ruby's solid Unicode support can be of useful assistance!
Sonic Pi is a Ruby DSL & IDE for live coding music with a specific focus on education. In this demo-heavy talk, we’ll cover its history - why it was created, how it evolved and what it can do today. We’ll also take a quick technical nosedive into some of the more interesting linguistic innovations that were necessary to perform live with code. For example, we’ll see how we can rhythmically sync multiple threads, use lexical blocks to close over time, accurately sleep without drifting and deterministically manipulate global state concurrently. Expect noise!
I :mustache: you a question.
That's what I send via Slack to folks I'm reaching out to when I'm stuck. Over these first few years of my career, the reach outs are fewer and the problems more specific and/or challenging. Now? I often get that inquiry in a DM. What I'm discovering more and more: That whole rubber duck thing is no joke—moreover, it's often the unofficial mentoring of our industry. What do our own questions teach us? What do they teach others? How can you be a great rubber duck? Beyond that moment, what can the rubber duck do for your career--the easy way?
Programming requires developing ideas about How Things Work that we internalize and rely on in our day-to-day programming life: when I write a class, I can use it like this; all strings have that method; I'm allowed to use private methods in these contexts. We start to rely on them. But which are rules, and which are more like norms? Turns out that with as dynamic a language as Ruby, a lot of rules are made to be broken. Let's take a look at what we can assume to be true in our Ruby programs and what we can't.
Quick: say something about Ruby that hasn't already been said.
Not easy, right? This community is prolific. In thousands of talks, Ruby's story has been told and retold. We heralded programmer happiness, path of least surprise, and confident code. We unleashed metaprogramming (until we tamed our DSLs). We built apps, tested them to death, and then legacy-rescued them.
What's left to say? We could tell the same stories again, but that wouldn't be very DRY. What we need to hear was often said years ago, so this talk will help us rediscover timeless lessons from our community's greatest hits.
Have you ever wanted to change the channel on your TV but the remote was missing? Wouldn't it be great to tell your TV to change the channel by speaking to it? In this talk, you will learn how to control your TV with nothing but your voice. Using Ruby you can connect your TV and cable box with the Amazon Echo, AWS Lambda, and a Raspberry Pi. Once you learn how easy this is to setup, you'll never look for that missing remote again.
What if we traded in our classes for procs, our methods for functions, and took advantage of functional programming to rewrite Ruby's Rack? I kept hearing about the benefits of functional programming (simplicity, immutability, thread safety), but it wasn't until I reimplemented familiar Ruby concepts in a functional language that I really got it. In this talk, we'll steal some powerful FP ideas from Clojure and use them to rewrite Rack. You'll come out of it understanding how to write functional Ruby code that is simpler to reason about, less likely to break, and dead simple to debug.
HyperCard was a visionary application that gave users the ability to create, share, and browse text content years before the Internet became commonplace. We will discuss its key features and explore recreating them in our own Ruby desktop app: RubyCard.
Amongst the exciting challenges of making software, there are some tasks we go out of our way to avoid: linting files, updating dependencies, writing documentation. But even the "boring" parts of the job are opportunities to make big changes for the better, little by little. In this talk, you'll learn how to make even the most mundane development tasks exciting in order to better your applications and become your team's hero in the process.
You've just woken from a coma to find out that Ruby has fallen victim to the programming apocalypse. Walkers have taken over the programming world looking to infect any developers they can find. Posing even more of a threat are the other survivor camps such as Java and PHP all fighting to survive by any means necessary.
After reuniting with the Ruby Community, it's time to fight for survival. Ruby developers who remained safe in the post-apocalyptic Ruby community need a leader to keep the community together and keep the language thriving. Are you willing to step up to keep Ruby alive?
Humans and data science are flawed on their own. Humans lack the ability to process large volumes of information. Machines lack intuition, empathy and nuance. You’ll learn how to guide users of expert-use systems by applying data science to their user experience. Layering data science within our systems allows us to take advantage of the human-touch while leveraging our large data sets. In this talk, you’ll learn the process for sprinkling data science into your applications, the challenges we have faced along the way, and how to measure the business impact.
What if Professor X and Magneto formed the X-Men together? What if Jessica Jones had joined the Avengers? What if Tony Stark wrote Ruby? (Okay, I made that last one up, but we'd probably all read it.) This talk, in the mode of Marvel's What if... ? comics, explores what Ruby 3 might look like if key decisions in its history had been (or might be) made differently. We'll look at three "what if"s in particular: "what if Ruby had a static type system?", "what if Ruby ran in the browser?", and "what if Ruby didn't have a global interpreter lock?"
Ruby applications can be broadly split into two categories: those that run for a short period and those that stick around for a while. Optimizing performance for one often comes at the expense of the other. Over the years, alternative Ruby implementations have demonstrated remarkable performance gains for long-lived applications -- so-called peak performance -- but often lose out to MRI for short-lived applications.
In this talk, I'll introduce the SubstrateVM and show how we use it to massively improve TruffleRuby's startup time with minimal impact on peak performance.
One of Ruby's greatest strengths is its burning desire to make writing software enjoyable for humans. Newer languages, perhaps taking some inspiration from Ruby, have recognized the practical value of doing this. What can Rubyists learn from these new ideas, and what can be adapted from them to improve Ruby?
In this talk, we'll discuss a few of the most interesting Ruby-like features that aren't really in Ruby yet. We'll also show how you can get these features (or an approximation to them) with Ruby today. By the end of the talk, you should feel empowered to try them out yourself!
Diversity and inclusion have become hot topics in technology, but you may not know how you can make a difference. However, this talk will help you understand that, no matter your background, you have privilege and can lend it to marginalized groups in tech.
While web applications dominate much of the computing landscape, sometimes you just want to open a window on your desktop.
Enter Shoes! With a long history in the Ruby community, Shoes is an easy to learn, fun to use framework for writing and packaging GUI apps. It's ideal for kids, beginners, and anyone look for a simple way to build apps that run on Windows, Mac, and Linux.
After many years of development, a release candidate for the new version (4.0) of Shoes is ready! Come learn how to get Shoes, how it builds on the cross-platform power of JRuby, and how you can get involved in the project.
Since Ruby 2.3 and the introduction of RubyVM::InstructionSequence::load_iseq, we've been able to programmatically load ruby bytecode. By divorcing the process of running YARV byte code from the process of compiling ruby code, we can take advantage of the strengths of the ruby virtual machine while simultaneously reaping the benefits of a compiler such as macros, type checking, and instruction sequence optimizations. This can make our ruby faster and more readable! This talk demonstrates how to integrate this into your own workflows and the exciting possibilities this enables.
I lost my password. So I used Ruby it crack it, kinda. I will re-enact the story live in front of a group of strangers.
I'm going to be honest, this is a weird and fairly embarrassing story. You probably shouldn't come see it.
You know what, forget I even said anything.
Types have been a big interest for Rubyists for more than ten years. Even before Ruby3, some researchers have tried to type check Ruby programs. All of them had failed. No one in the world has successfully implemented practical type checker for Ruby programs yet.
Why is it difficult? How have we tried? What do we want exactly? Can we find any solution?
When Bundler 1.0 came out in 2010, it did something really great: installed all of your gems and let you use them in your app. Today, Bundler does something really great: it installs all your gems and lets you use them. So, given that, why has Bundler needed thousands upon thousands of hours of development work? What exactly has changed since then? Prepare to find out. We’ll cover performance improvements, server response optimizations, adapting to new versions of Ruby, and adding features to support new usecases. Learn the tricks of Bundler power users, and find out how to optimize your gem workfl
Have you ever gotten really stuck while trying to understand the cause of a bug? Thinking of your debugging session as a science experiment, and using the scientific method can help you make progress again. Come and learn how to adapt the scientific method (the process used for scientific research) to get past that stuck place and find the cause of bugs or production incidents. You’ll walk away with a great new tool to keep you calm and focused in the face of inevitable bugs.
Whether you're writing documentation, a talk for a technical conference, or a blog post on your work, identity can impact how your audience perceives and uses both written material and code repositories. If you want your work to be accessible to a wide audience, you need to write about it in an inclusive way. This talk will give you hands-on examples and resources to do just that!
Renowned game show Just a Minute has delighted audiences across the world for almost half a century, becoming part of the British national consciousness. Speakers are challenged to speak on an unseen (Rubyesque!) topic for one minute without hesitation, repetition, or deviation. It’s fast-paced, funny, insightful, and much harder than it sounds… and you might even learn something!
Debuggers can seem like dark magic—stopping a running program, tinkering with the program state, casting strange spells on VM internals. I spent much of my career diagnosing problems using “puts” because debuggers intimidated me. If you can relate, this is the talk for you! We’ll use Ruby's powerful TracePoint API to implement a simple but fully featured debugger for Ruby programs. We’ll also explore a few of the advanced techniques behind a "live" production debugger, and discuss some of the debugging features and limitations of the Ruby VM itself.
Programming history is filled with bugs that turned out to be features and limitations that pushed developers to make even more interesting products. We’ll journey through code that was so ‘bad’ it was actually good. Along the way we'll look at the important role failure plays in learning. Then we’ll tame our inner perfectionists and tackle an approach to writing code that will help us fail spectacularly on our way to coding success.
Ruby's philosophy is to provide more than one way to do the same thing. Faced with choice, we are left wondering which methods to use.
In this talk, we will travel together on a refactoring journey. We will start from code that is easy to write but hard to read, and gradually advance to a level where the 4 C's of good code are satisfied: Correctness, Completeness, Clearness, and Compactness.
On the way, we will learn new Ruby 2.4 methods (String#match?, MatchData#named_captures) and review old methods (Enumerable#find, Regexp#===) that are more powerful than they seem at a first glance.
We all know that testing is important. But it's also hard to get right. We'll talk about how to write effective tests that not only protect against defects in our code, but encourage us to write better quality code to begin with. You'll leave this talk with ideas on the philosophies that should inform your tests, and a good idea of what makes a good test suite.
Monday mornings are bad when the coffee runs out, but they’re even worse when all of your impossible to reproduce, “flaky” tests decide to detonate at the same time.
Join us to learn a systematic, proven workflow for expertly debugging any test failure including consistent, order-related, and non-deterministic failures. We’ll discuss the importance of fixing intermittent failures before they reach critical mass and why you should eradicate the term “flaky tests” from your vocabulary.
Don’t wait for an emergency to prioritize fixing the ticking time bomb of intermittent test failure.
Apprenticeships are a great way to ramp up a newbie, but these programs are much tougher to successfully implement than many organizations expect. It is a surprisingly large investment to guide someone through the ups and downs of their first gig as a developer, and if you aren't prepared it can be a bad experience for everyone involved.
Let's dig into what makes a robust and empowering apprenticeship, from full team buy-in to setting clear learning goals to providing a clear path to the optimum final outcome: a new full time junior developer and a team dedicated to investing in education.
ArrayFire gem a General Purpose GPU computing library can be used for high performance computing in Ruby be it statistical analysis of big data, image processing, linear algebra, machine learning.
ArrayFire has an outstanding performance considering other existing Ruby libraries that run on CPU. ArrayFire gem can also be run on clusters and handle real world problems by crunching huge datasets. The ease of using ArrayFire gem makes Ruby a viable choice for high performance scientific computing.
Listening is power. By “tuning in” and applying self management and directed curiosity you can help others thrive and solve their own problems. Doing this not only leads to greater ownership, but also more leaders in your organization instead of “order takers”. In this interactive talk I’ll teach you practical communication skills so you can become a more available and empowering coworker, friend and leader.
Do you know JRuby? Built on the JVM platform, JRuby has been actively developed for over 17 years. But why would you choose JRuby? What benefits does it offer?
In this talk, we will introduce you to the wonderful world of JRuby. After basic setup, we'll show how JRuby's concurrency model and GC can help boost performance. We'll walk through deploying and scaling apps and services on JRuby. We'll demonstrate JRuby's powerful integration with other JVM languages. And we'll talk about how to start migrating to or building new apps on JRuby. Join us and learn what JRuby can do for you!
Ruby have many libraries named standard library, extension and default-gems, bundled-gems. These are some differences under the bundler and rails application.
default-gems and bundled-gems are introduced to resolve dependency problem and development ecosystem around the ruby core. We have the plan to promote default/bundled gems from standard libraries. It says “Gemification” projects.
What Gemification changes in Ruby ecosystem? In this presentation, I will explain details of Gemification and future things of Ruby language.
There is a value in writing tests and there is also a cost. The currency is time. The trade-offs are difficult to evaluate because the cost and value are often seen by different people. The writer of the test bears much of the short term cost while long term benefits and cost are borne by the rest of the team. By planning around both the the cost and value of your tests, you’ll improve your tests and your code. How much do slow tests cost? When is it worth it to test an edge case? How can you tell if testing is helping? Here are some strategies to improve your tests and code.
In 2011, with a team of interns at a Department of Defense contractor, I created a Wi-Fi geolocation app to locate hotspots. It could find the location in 3D space of every hotspot near you in seconds. We made formulas to model signal strength and probable distances. We used machine learning to optimize completion time and accuracy.
I was so caught up in the details that it took me months to see it would be used to kill people. What do we do when we discover that we're building something immoral or unethical? How can we think through the uses of our software to avoid this problem entirely?
Physical computing is very fascinating and fun, but there are also difficulties that were not found in normal Ruby programming. One of the issues is its low portability. Unlike PC, some computer boards that directly uses the devices use only small microcomputer whose memory is less than 1 MB. So most of the applications work only on specific boards. If we found an interesting project, we could not try it unless I had a target board. To solve it, I propose a plan of mruby platform, consisting of a group of mrbgems that absorb incompatibilities. I talk about the project and current progress.
If contributing to open source was only about writing code, it would be easy. In reality open source exposes our insecurities and makes us feel vulnerable. Vulnerability can inspire change, but can also paralyze us for fear of not being good enough. In this talk we'll look at how vulnerability affects open source contributors and explore how maintainers can foster a welcoming community. Contributors will learn how to identify projects with empathetic leaders who value GitHub’s community standards. Cultivating a better environment for contributing makes open source more sustainable for all.
Applications written in Ruby, Python and several other popular dynamic languages become very slow to boot as they grow to millions of lines of code. Waiting to reload code in development becomes a major frustration and drain on productivity. This talk will discuss how we reduced the time to boot a service at Stripe from 35s to 5s and the static analysis tools we built along the way.
Do you feel stressed when you’re trying to hold a big problem in your head? Do you get frustrated when someone interrupts you and you have to start all over again? Those emotions are inevitable if you’re in the common habit of treating each programming task as a long, precarious, all-or-nothing tightrope walk. But it doesn’t have to be that way! In this talk I’ll explain why the tightrope walk is so harmful and show you some practical techniques for avoiding it.
0:00:40:03 - Michael Hartl
0:01:25:27 - Jonathan Slate
0:02:47:07 - Kyle Heironimus
0:04:45:25 - Yechiel Kalmenson
0:07:05:05 - Heather Herrington
0:12:10:23 - Jen Pengelly
0:16:09:12 - Brian Underwood
0:21:15:29 - Cameron Dutro
0:26:14:15 - Aaron Rosenberg
0:31:23:11 - Starr Chen
0:37:28:26 - Margo Urey
0:43:25:21 - Ryan Laughlin
0:49:19:16 - Adam & Julia Cuppy
0:54:24:16 - Jim Remsik
1:00:56:09 - @amirrajan
1:07:06:17 - Dave Aronson
1:12:24:12 - Sam Livingston-Grey
1:17:10:13 - Noah Gibbs
1:22:30:29 - Heidi Waterhouse
1:27:56:12 - Akira Matsuda
I thought of software architects as petty waterfall dictators. Then I became one. My theater background saved me. In this talk, we’ll look at set design — an ongoing, collaborative process — as a model for a more agile kind of “architecture” than building metaphors allow us. You’ll learn about the most important part of any architecture (hint: people), about using architecture to foster team creativity, and about the agile-architecture superpowers that Ruby gives us. No matter your title, you too can architect!
Would you hire a musician to build a web app? After this talk, you might not think it’s such a crazy idea. Transitioning from opera singer to software engineer, I was blown away by the parallels between music and code. During this talk, we’ll study these similarities: how we break down elements to learn, use patterns to build, problem solve with creativity, and succeed through persistence and flexibility. We’ll compare “Mary Had a Little Lamb” to a Ruby method and see how Puccini might have coded a Todo app. Warning: parts of this talk may be sung. Yes, you may bring your own instruments.
Sometimes an email appears in front of you in your inbox that immediately grabs your attention. For me, this was the case with a particularly scarily titled RSpec Mocks bug.
In this talk, you'll hear a story of investigation and fixing of what could have been a day ruining bug for all RSpec users. You'll come away with some deeper knowledge about RSpec's mocking library. You'll learn some protips on good practise when making an open source bug report. If you've ever used with RSpec's mocking library and would like to learn more about deep Ruby metaprogramming this talk is for you.
We will talk about implementing a compacting GC for MRI. This talk will cover compaction algorithms, along with implementation details, and challenges specific to MRI. Well cover low level and high level memory measurement tools, how to use them, and what they're telling us. We'll cover copy-on-write optimizations and how our GC impacts them. After this talk you should have a better understanding of how Ruby's memory management interacts with the system memory, how you can measure it, and how to adjust your application to work in concert with the system's memory.
Close your eyes and imagine what is the worst thing that could happen to you at work. For me, that was charging users thousands of times the amount they should have been charged. In this talk we will find out what caused this particular bug and what we learnt from dealing with the whole situation.
Did someone get fired? Did the company survive the bug? Come to the talk and you will learn the answers, but more importantly a thing or two about how to go through tough times at work.
Much like developing any feature in your app, the best developers start with an idea and then refine it through rapid testing, much of which requires very few technical skills--but does take focus, observation and patience. In this talk we'll discuss the process of developing and playtesting a board game and what we as software developers can learn from it to improve the features and apps we create. If you like board games or just want to create better experiences for your users, then this talk is for you!
Ruby has a rich and flexible syntax. It allows us to write not only an easy-to-read program, but also an "hard-to-read" one. This talk will show its unlimited power. We present and demonstrate some esoteric, obfuscated, and even artistic programs that we have ever created, including a program that contains a spinning globe, a robust program that can have any single character removed and still works, a program that consists only of alphabetical letters, and so on. We will also review the implementation techniques.
You probably heard that Global Interpreter Lock (GIL) in Ruby "allows only one thread to run at a time", while technically it is correct it does not mean what you probably think it means. After this talk you will know why your code can be not thread safe even if GIL is enabled and how even a subtle change in your code can make GIL fail to protect you from race conditions. This talk is junior-friendly, but even experienced Ruby devs most probably will learn something new and important about GIL in Ruby.
01:57:28 - Rich Kilmer
07:10:21 - Nadia Odunayo
12:45:23 - Michael Hartl
18:16:08 - Jim Remsik
23:49:08 - Allison McMillian
Space is really cool. From precision electronics, to giant rockets, spacecraft can represent the best of engineering. But sometimes things go wrong. Terribly wrong.
What do exploding Soviet rockets have to do with Agile development?
How did LISP and Forth hacking save part of the Galileo probe?
What about that time astronauts added life-saving monkey patches... while orbiting the moon!
Exactly how much damage can a little dead code do? (Hint: a lot!)
This talk is for anyone whose love of a good space story is rivaled only by their passion for incredibly resilient software.
What happens when we drop "No, but..." from our daily interactions or life choices in favor of the #1 rule of improv: Yes, and..?
This talk is not a technical deep dive into the Ruby VM or a walk through of a new gem. I won't touch on testing strategies or war stories as a developer. Instead, I'm going to teach you improv.
We'll call it a social strategy for an awesome life! This talk is for introverts and extroverts alike. You won't be brought onstage (unless you want to be).
I will talk about the current situation and the future of Ruby in the field of data science.
Currently, Ruby can be used practically in data science. In the first half of this talk, I will perform some demonstrations to prove this. You will see that pandas, matplotlib, scikit-learn, and several deep learning frameworks are available from Ruby scripts in these demos.
In the future, in order for Ruby to continue to be used in data science, we need to continue some efforts. In the latter half of this talk, we will introduce Red Data Tools project that plays an important role in this context.
Risk Reduction is trying to make sure bad things happen as rarely as possible. It's anti-lock brakes and vaccinations and irons that turn off by themselves and all sorts of things that we think of as safety modifications in our life.
Harm Mitigation is what we do so that when bad things do happen, they are less catastrophic. Building fire sprinklers and seatbelts and needle exchanges are all about making the consequences of something bad less terrible.
This talk is focused on understanding where we can prevent problems and where we can just make them less bad.
After suffering a debilitating stroke, Barbara, my significant other's grandmother, was left disabled, bed-bound, and mostly non-verbal. We visited often, and were with her when she passed earlier this year. For Christmas, I built her a web application to be a window into the life of her granddaughter.
Now that she’s passed, I’m hoping that the project can be a foundation or inspiration for others to build tools that bring them closer to the people they love. This small project--a $5 computer and some “off-the-shelf” technology--increased the quality of life for all of us.
The Rubik's Cube is one of the world's most recognizable puzzles. Knowing how to solve a scrambled cube can almost be called a badge of honor. While there are a multitude of books, articles, and apps on how to solve a cube as a human, what does it take to have a computer solve the problem? This talk will dive into exactly that question. We'll start with an overview of Rubik's Cube algorithms, move onto the logistics of implementing these algorithms, and finish up with some real examples of using Ruby to solve a Rubik's Cube!
The attitude among many developers seems to be that code reviews can be either honest or nice but not both. I see this as a false dichotomy; while code reviews should be both honest and kind, they should be focused on inspiring creators to go back to their work, excited to make it better.
This talk will introduce the Liz Lerman Critical Response process, a framework for giving feedback on anything creative. You'll leave this talk with tips on how to improve your code reviews by putting the creator in the driver's seat and inspiring everyone on the team to make the product even better.
JIT compiler is considered a promising approach to achieve Ruby 3x3 goal these days. But the direction of its implementation is not fixed yet. What will be the ideal approach to achieve that goal?
In this talk, seeing my experiment to implement LLVM-based JIT compiler, you'll know how native code can be compiled from YARV ISeq, what makes it fast in LLVM, what are the difficulties underlying in it and how to solve them. I hope a discussion in this talk will help Ruby 3 to be great.