 Eric for the introduction. Hopefully, I have a fresh breath. So hi, everybody. I'm Christophe. I'm the co-founder of Preview, as he said. I also co-organized several Ruby things in Belgium, like Arkham, Rails Girls, and also Ruby Burgers. So what I proposed today is to dive together. So because code has to be written, we forgot that we read far more code than we write. Reading and understanding the code is, by far, the most common development activities. Still, we picture ourselves while typing on the keyboard when, if you pause one minute and take attention, you don't write code, you're reading it. It could be the one you just typed or the one you typed two months ago, or a colleague had, or it's the code of a gem that you need to use. So yes, we dream of us capable of this pre-use continuous typing when, most of the time, it looks like that. Us looking at code, trying to understand it, thinking about what we could write, but how much do we read? So we can at least state the following. For each line that we have written, it has to be read at least one. So we can do a quick estimation based on the number of changes we did on the code base. So just take one example of mine. It's a project I spent 300 days on it to get about 15,000 lines. I did change 600,000 lines. So it means that for every final line, I change 43 times more. And I don't even count all the changes that I didn't commit. Neither the time I spent to understand again and again the code I've written before. Still, it's a good estimation of the ratio between writing and reading. And indeed, we can accept that bottom line, which is 85% of the development activities consist in reading. And if you discover a new project, it's even more something like 95% of your time. So if you consider a work day of eight hours, you have barely 30 minutes to actually achieve something. So if you want to write something in that time, you need to be quick. You need to find quickly what you need. So you need to learn to dive deep into the project to find quickly the treasure you're looking for and use it in order to fix a bug, implement a feature, whatever. So I like this analogy with scuba diving. Because in scuba diving, when you dive on a rake, for instance, you cannot dive without any planning, without preparing you dive. Because it's the best way to get lost, to have a problem, or even worse, to dive. So from the easiest to the most complex dive, you will prepare what you will do. And it's the same when you code. Wondering without any goal, without any plan, it's the best way to waste your time. It's the best way to not ship something on day one. And you don't need to read the whole code base in order to achieve something. You can do it step by step. And at the same time, write something, achieve something like fixing a bug. Because it's what's really valuable, not reading just for the sake of reading the code base. So for me, it's really like a journey. And it needs to be planned. So what I would like to do today is really present the approach I use each time I need to discover a project, to dive into it. And it's really about how to discover the project, the important parts you need to read, and write some code at the same time. So the plan consists in defining a goal, getting the map, using the right equipment, and dive. I mean, write code, and do it again. So the first thing you need is really to get a reasonable goal, something that motivates you, that drives you, something that you can plan for. That could be fix a bug, implement a feature, or even add some documentation, or just use it. So I will illustrate the following with an example of mine. Two years ago, I was browsing Stack Overflow. And I found that question about Open URI module. And normally, when you pass false or nil to the option proxy, the open method should ignore the HTTP proxy environment variable. As I did already use that option before, for me, I was surprised that it didn't work anymore in Ruby..0. So the first thing I tried is to reproduce a problem. So I write a very small script that you see here. So very complicated. And I got that error stack. So indeed, it was using the proxy variable environment when it shouldn't use it. So for me, fixing that bug was the first reasonable goal to discover MRI codebase. I had a goal, but a goal in itself is not enough. What you need is a map. I mean, to know where you need to go, because if you don't have a map, you don't know how to reach a goal. So it's about raise the project, raise the code, raise the introductory documentation with all the basic information about the project. So for instance, the readme file that explains how to install it, how to use it, where to communicate with other contributors and developers, and so on. So in my case, this was pretty simple. Something where on GitHub, the issue tracker is still on RedMind, and this is it. So it's great to have a map, but you still need to read it to understand that map. So you need a legend, a great one. So the first you can look for is the contributing guideline. There you'll find plenty information about how to contribute to the project, like how to report a bug, how to submit a patch, which code convention you need to follow, which tests you need to write, is there a CI, and so on. Another less technical one is the code of conduct. It will remind you how to behave with others. Both are important. Not following them is rude. But don't be afraid. If you're not sure you do it correctly, just ask, and people will help you. So in my case, I found quickly the contributing guideline. And it contained two links, one to the issue tracker and another to the wiki of MRI. So by reading those pages, I learned how to build a patch, how to use it, how to test it, and so on. Then the other thing you need to understand is the hierarchy of the directories, because it's really about where you can find what in the code base, where are the tests, where are the resources, where are the documentation, and of course, where are the code source. You don't need to be exhaustive. Just find what you need. If you just look for one file, just look for that file, and you will understand the role of the directory where the file is. So for instance, in my case, I was looking for the file containing the OpenURI module. And so I just go for it. And then I found where all the other files of that module were restored. And also, I looked for the documentation to check that's what is officially expected for that module. So sometimes, it's hard to find this information. Then talk to the people that know it. They will give you a quick overview of the projects. They will help you. And I think that's the easiest way to know about a code base. For open source software, you will find them usually on the issue tracker, on the IRC or mailing list. And for a job, they are your colleagues. So just ask them during a coffee break or lunch. Or simply send an email to us. So in the case of MRI, all those information are into the readme file. So this probably applies less for open source software, except maybe for bigger projects. But for a job, it's really common to have a development meeting. And it's a great moment to listen and to learn what are the current problems, how people work, the kind of workflow they follow, to ask questions if you do not understand something, or to discuss what you can do if you don't have yet a goal. I think if you are blocked, you need to ask someone to help you. Because if you don't stay blocked the whole day, you will waste your time. Open source or not, people are ready to help. Because eventually, you will do the same by contributing. So also, you need to realize the importance of all those information. Someone has taken time to write them down. So it's nice to have the habit of doing so in return. So if you create a new project, try to write those contributing and readme files, and so on. So now you know where to go. You know more about the place. It's time to get the right equipment to dive into the project. So of course, to read and edit code, you need an editor. I don't waste your time with that. Or maybe you have too many time for that. Then you need to prepare your environment to check your requirements, like do you need a database, or data storage, what are the dependencies. It will give you a better idea of the whole architecture of the project. If you have a gem file, use BenentVis, it will give you the graph of all the dependencies. So for instance, this is the dependencies for GitLab. So just if we zoom, this is a part of all the gems that GitLab is using. Running the test is, I think, the best way to check that you have all the minimum needed to develop. Also, check if the project uses a particular CI, or do they run some tools like Rubocop? And of course, don't forget to sign up to the issue tracker. So I found that running the application is a great way to have a better feeling about the application, what it does. But sometimes it's very complicated to set up the whole environment. So more and more project-provided veteran machine or container are ready to run the app. So if there is one, it's very convenient, go for it. So in my case, it consists just in running that script. So the idea is that you just need to run what you need. You don't need to test every features possible in the project. So just use what makes sense according to your goal. So you have all this information. Still, we doesn't have dive into the project. So I mean, we didn't read anything. So I think that's the right time to do it. So thanks to all this information, you know where to look for, but you don't know what to read. So if you look at the OpenURI module, which is a quite small module, you can see there's a lot of things to read. So you have two options. One is to read the whole code base. The second one is just to read what you need. I prefer the second option. And for that, the first thing you need to ask yourself is what's your goal? In my case, it was to understand where is the proxy management implemented, to understand how does it interact with other parts of the code, and also by doing so, spotting the bug. So for me, the best way to discover a code base to read is to get the whole code graph of the case. So for that, I use TracePoint API. So the idea is to track every call that comes from your case and the scope of that call. So you can see there, on the even line in call, the line will give you the scope of your call, and the call will give you the location of the implementation of the method. So just apply that on my case, and I get a very long list of all the possible calls that come from that case. So the first one is simply the call of the open method. Then we can read that there is some part to parse the string to make it a URI instance. Then you have the creation of the URI instance itself. Then you have the management of all possible options that you can pass to the open method. And then this is interesting because you have the call to open HTTP. We know that we will open an HTTP resource. So now I know where to look, where to start my reading. Then you have several calls, not very interesting, about requires again. And then we find something very interesting because they are related to the management of proxy. So in blue you see the creation of the HTTP client, and then you have the test if there is a proxy. So with that, have the location where to look to understand the different parts without opening any file. So I use that sequence of calls to read my code, to follow the execution. And thanks to that, I can find the important line where the bug is. So that line consists in creating the HTTP client. And normally when you create that instance, you can pass an option to enable or disable the proxy. And in that case, it wasn't disabled because by default it's enabled. So by tracing the calls, you've got a lot of information. And it has the location of the different calls. And you can, of course, use this information to search for some specific information. So you can use grep for that. Like to look for all the calls of open HTTP or the definition of the methods, or the definition of the constructor or HTTP class, and so on. So it doesn't apply in that case. But if you have a gem file, it's very easy to open the source of a particular gem by using a bundle open. So it's a very quick way to open the source of a gem. If you don't have a specific case, I found that test is really a nice context to start from. So just get the call graph from a particular test. They will give you context to understand what you're reading. So it's a test of GitLab. I just put my tracing of call graph on a particular test. And then I will get all those call graph. And I can read the code in the context of this particular test and understand what I'm reading. So I've read a lot. Now it's time to edit the code and fix the bug. So the bug relied in one line. The fix is just one line. And again, I think I've read 100 line, which is less than the whole module. But still, it's a lot. So you have done everything. It's nice to report what you did, to report the bug, and to submit the patch. In other words, it's about communicating what you plan for and what you have done. So in my case, I get my first bug report in MRI. It took me two hours to learn how to contribute to MRI, to learn about the structure of the project, to find a bug, to fix it. Even if I didn't know about the MRI code base before, and report the bug, submit the patch, and answer the question. So the problem was simple in a way. It helps me to discover the MRI code base and projects. And in fact, it's an approach that I use every time I need to dive into a project. I found it very useful, whatever the language is, using that approach is, for me, an efficient way to do. So again, if you are stuck, just ask someone. Don't freeze. Interact. So when you do it once, you can do it twice. And I think it's a good moment to discuss what is a good goal to drive you to discover a code base. So the first question is, how long does it take? A good period is about half a day. So it keeps you motivated, because if it's too long, it's difficult to stay motivated. If you don't know what to do, you can just check the issue tracker. Usually, they list some bugs, some features you can do, or also into the contributor guideline. Usually, contributors can list the kind of contribution that you can do. You can run a static analysis tool like RibgoCop and check if there are any issues that you can check. It's a great way to navigate through the code base to discover something by doing something. So when you are active, you learn more about the code base. So this is it. There are plenty of options to discover a code base. Just keep it simple. You know how to plan it. You're free to discover what you want. And just by doing and by writing code, and by respecting your limits. Again, if you block, just ask. People are always ready to help you. So health recap. If you want to dive, just get a good goal, something that motivates you, like fixing a bug. Get a map in order to know where you can find the things you need. Get the right equipment so you can efficiently read your code base to efficiently write what you need to write. And just do it again and expand your horizon. So thanks a lot for your attention. I'm running apparently. OK, questions? Anyone? No questions? There is a question. There you go. I was wondering, you have this call graph technique, which I find very interesting. But how do you deal with understanding what these calls do when you haven't read the code yet? Excuse me? How do you deal with understanding the call graph when you haven't actually started reading the code yet? Oh, that's why it's important to have a context. Because you have a context, a specific use case or test, you know what the code should do. And you can then infer several things by reading the sequence of calls. When you start to read without any clue what is about, you need to read a lot before to figure out what is exactly about. So I think the first starting point, very important starting point is to have a clear context, a functionality, something that the code does. Hi. This is the second time I've heard a metaphor about diving. And the first time was a writer of children's fiction explaining how he came up with plots in his story and the types of challenges he had. How did you come up with this metaphor? So I just started a few months ago to do scuba diving. And I like when I explained something technical, to have something concrete I can relate to, to have a story. And by learning how to dive correctly, I found there were a lot of parallels between that practice and by the fact to dive into code base. And diving is a lot about process, to create habits and discipline. So you don't have to wonder what you need to do in order to correctly do the thing. That's why preparation is important. That's why to have that process is important. And I think it's not because we are smart, that we cannot follow some good practices. And I realized that I use some processes to read code base. And so I frame it. I didn't really change the thing. I just put the process I use into the right case, the right box. And it fits quite well. So for me, it was a great way to present it. I hope you enjoy it. Thanks. Very well. One more quick question. Only very long questions. OK. Then Eric? Yep.