Underneath the beautiful veneer of our Ruby libraries lies a twisted tangle of writhing guts. Maybe you're curious how the pieces fit together or maybe you're tracking down a bug, either way it's easy to get lost in the blood and bile that ties our code together. In this talk you'll learn how to use simple and sharp Ruby tools to slice into large libraries with surgical precision. We'll do some live hacking on Rails on the stage and cover useful code probing techniques. Turn your impossible bugs into pull requests, and level up your programming skills by Dissecting Ruby with Ruby.
You should also checkout Kernel#caller_locations via Thread::Backtrace::Location
Without saying whether this talk sounds interesting or not, I want to ask a stupid question: isn't a debugger sufficient enough to trace such problems efficiently enough? I'm asking cause I have hunted in the past a lot of such bugs from 3rd party libraries with the debugger and even though it was cumbersome it did work out. Are you going to propose a better alternative or a something complimentary?
Author here - We start with a problem, something we want to fix in a huge library (Rails) but we don't know where to find the offending code. To get to it we use
Module#instance_method and a few more to really dig into the library. These are all standard Ruby functions, but with them you'll see how easy it is to navigate any code base. This is exactly the process that new to intermediate devs need to learn before they can contribute and patch large libraries. I gave the talk in Uruguay, and it was VERY well received. It is technical, fun, and entertaining.
The title looks very interesting!
However the proposal abstract needs some more information. Can you please clarify further?
Seems a very generic presentation. What do you mean by "simple and sharp ruby tools"? I don't know what to expect from it.
I'd suggest you give some examples of techniques so that I can then think "Oh, I'd like to learn that".