 very pleased to be here today. It's also my first talk at the Ruby Conference. So thanks, especially, you know, the first time you speak and the next speaker is Aaron. It's kind of a little bit terrifying, but well, I try to do my best. So I'm Christophe. You can find me on Twitter and GitHub. I come from Belgium, a tiny country in Europe between Netherlands and France. And we are known to like beers and chocolates. And in fact, I like beers and chocolates. We have a lot of different beers and different chocolates. Because I think we do the best chocolate in the world. I bring with me, I think, more than two kilos of chocolates. So after the Aaron talks, what I propose is that you come by me, say hello, and take one piece of chocolate and taste what we do quite the best in the world. Belgium is also known to do some absurd things very efficiently, like the previous government. We needed more than twice the time than the Iraqis. They have need to build their own government. It was about 550 days. And well, we did pretty well with just a resigning government. We succeeded to have very good economical results since more than 10 years. So you will see the kind of country we are. I'm the Co-Founder of ProReview. So it's an automated code review tool for Ruby. It's presented like that. If you don't know, we can talk that after the talk at the party, for instance. Basically, the idea is to give you feedback on your code so you can know how to improve it. And today, I would like to start not with a software story, but with a story from my watch job. She has, every day, she goes to drop to with one goal, which is curing conqueror. And she's a medical physicist. And she likes to play with big machine. So these kind of machines, the idea is to beam some electrons and photons in order to put energy at a certain place in your body. So it looks like that. You have different beams. And the idea is to deposit some amount of energy on the conqueror so you can burn it and eradicate it. So the problem with that is that you have some side effects like through the body, you deposit other energy so you can burn the skin and organic tissue. You can induce other secondary cancer. So something that you need to take care of. It needs a lot of people. For one patient, it's about three nurses, one doctor, one medical physicist. It's very complex, and you need to use complex program to calculate the dosage of energy that you would like to deposit on the conqueror. It's long. It's not only the treatment, but it's also the diagnosis, the measurements to position it correctly the patient on the machine to check if everything goes well and so on. And because of all of that, it costs a lot. Just for one treatment, you can count between $3,000 and $15,000 just for one treatment. That means that if you do one error, you can have an ineffective treatment. You can have some casualties like burning, like secondary cancer. It's costly and time consuming to fix their errors. You can break the equipment, the machine. That means that at the end, you will make the people busy to fix their error or to fix the machine. And finally, you cannot treat other patients and other cancer. So it's very important to try to do less possible errors that you can. So she has an engineer. She tries to do her best. And her best is to catch errors as early as possible and to mitigate the risk to do error. How she can do that, for instance, she has to check if the machine is working correctly. So on the left, you have a cube of water. It's a good model of the human body. And they do some measurements to check if the machine beams correctly. And so you have the correct energy. So when you use a machine, you know that it's correct. You do also in vivo measurements. So during the treatment, you put some diodes on the body of the person. So you can check again at a specific point if the energy is correct. You need also to be sure that your calculation are correct. You use peer-review or other program to calculate your treatment. Or sometimes you just do some quick-hand calculation to check the order of magnitude. You have to check also if the requirements have been met, like because the machine has some physical limitation or because if you go too high in the energy, you know that you will induce other cancer. So you need to check those constraints. And again, one way to do that is to use peer-review or to follow some ISO process. And for instance, in that process, it's noted that you have to do peer-review and so on. It sounds probably familiar to you and it's for a good reason. And we will talk that later. The reason that we put those strategies in place is that because we are human. And like Homer, we make mistakes just because we are tired or inactive or you just miss something. And because we are human and we know that we can fail, it's finally our decision to do something or not. As you know, if you have a pool and a baby, you don't want to find your baby drawn in the pool. So you put in place some equipment, some safety nets, to be sure to keep it safe. So what we can do in radiotherapy, we do it also in civil engineering and manufacturing and also in software development. It's what I call safety nets. It's the idea that you put in place safety nets so in case you fail, it will catch you up and you can continue and nothing blows up. So in an ideal world, you would like to have only one safety net that catch everything. But you know, there are no silver bullets. So you try to have different kinds of safety nets to catch different kinds of errors. And in the end, it's really a trade-off between the cost of safety nets, your knowledge, your skills and also what you want to achieve. And the real idea with safety nets is to be informed. So you know, if there's an error and that you can catch it and you inform it, you can decide if you fix it or if you let that error in place. And in software development, I think the three Command 1 tests, static analysis and code review. I will illustrate the three. And for that, we go through a very simple invoicing application. I'm sure that everybody has already deal with that. So the idea of tests, it's that you can write before or after. That's not a question here. In the invoicing application, you have different items in your invoice. Each item has a price and a quantity. And you would like that if the invoice is empty that the total is null. And if you have different items, the total should be correct. And if you update the quantity of an item, for instance, you update also the total after. Very basic. We write the class invoice, initializer, the method to add the items. Nothing very complicated. And the total methods, that's calculate the methods. So we go through all the items and we sum over the multiplication of price and quantity. Okay, you run the test, everything is green. Yeah, you did a great job. And now, for any reason, you decide that you would like to make the total an attribute member. You put it in the initializer. You update the total methods. And you run the tests and they're red. In fact, when you changed your code, you did it too quickly and you miss it that it was important to reset the total at the beginning of the method. So because your tests were broken, you know there's a problem and you can fix it. So the idea of tests, their benefits is that they allow you to check the functionality of your software. Only the functionality that you can think before, that you think how your software should behave. If you discover some edge cases or some bugs afterwards, you can write the regression test to check if later, the bugs are really fixed and that you deal correctly with those edge cases. Of course, the tests have some drawbacks like, you know, what are we testing? Are we sure that we test everything? So with Test Coverage Report, you can have an idea how you cover your code base. Has someone launched the test? Especially, you know, you don't ship your machine in production. So that's why it's important to automate the tests with a CI and to have a test environment to close as possible to the production. And that's the typical question of manager who tests the test. There's also some strategy to be sure that your tests are correct with test mutation like with the mutant gem. They're basically, they change your code and they verify that when you change the code, your tests fail. So that was for the test, for static analysis. There are a program that reads your code, they don't interpret your code and they try to find, to underline problems in your code. They try also to measure some specific properties like if it's readable, maintainable. So yeah, I would like to handle VAT which is a sales tax in Europe. It's quite complex. Basically, if you come, if you sell from a given country to another country and that your customer is a company or not, you don't apply the same sales tax. So for instance, if I'm a Belgium company and I sell to a person or a company, I need to apply 21 person. But if I sell to another European company, the rate is null and so on. So it's complex, it's like that. We cannot do anything against that. So it's complex, we have that feeling but we have tool to measure that complexity like FLOG and the idea is to give you a score. If the score is high, it's kind of proxy to tell you that it's hard to read and that means if it's hard to read, it will be hard to change and there's a high risk to introduce a bug. And complexity at the end could like that and when you need to change a wire, you don't know where to start. That could happen in your code. So to be sure that it's easy to read, you try to fix it as early as possible. Well, so it's complex but we continue to implement other things like we would like to issue some quotes and a quote is basically an invoice but with a given total. But the quote is also to handle the VAT. So we are very lazy and we copy paste the VAT, that's okay maybe at the beginning but at certain point you need to remove that duplicate. Hopefully even if you forget it, there's a tool that check the duplicate. It's like play and it tell you that you find two piece of code similar in different files. So we know that we need to refactor our total method and we start by the beginning. We extract the first part which is the calculation of the sub-total. So we create a new private method. We put that code in that private methods. We do, we try to use the reduced IDUM, okay the test are green, everything is okay but with Ruby or Rubikop you can check that there are some flows in that piece of code. In fact, if we come back here, we still have that local variable total but it's useless and we have assigned something. It's useless because in the block we have a parameter with the same name that shadow the local variable. That means that if you forget it's a dead code and at certain point it could be a problem later and the same when you shadow another variable it's probably not the best thing you want to do. Hopefully with Rubikop or Ruby warnings you can be informed of those problem and because of that you can then refactor your sub-total method and make it better. So with static analysis you can check flows in your code and smells. You need to be sure that you run them like the test so you can use a CI with the gem dev tool or a specific quick task. We use a state software as a service like Codeclimate or all SpoolReview. You can get some false positives of course. They are machine, they are not perfect but they're probably not perfect but they are better than us because each time you run them you be sure that if there's problem and they are able to detect it they will report you that problem and Jordan Karmak, if you know it it's the guy behind Doom ID3 software the famous very old video game and for him it's really important to use static analysis because maybe your automation will fail but all failures are legend as a human and the fact that the static analysis will be very consistent and that each time you run it it will report the problem every single time that value is very huge. So you have tests, static analysis they help you to check functionality and if there are no problems in your code but they don't tell you how you can improve your code and CodeReview for that is really useful. It's the ID to ask a colleague how you could fix something to check your code read it if the naming is correct and at the end it's the ID to spread knowledge and for instance, oh, I don't know how to remove duplicates and your colleague know, okay you can extract the VIT rate calculation put it in a module and specific methods and then you make it the total method very simple only three lines and it's easier to read and hopefully you don't have any more duplicates and indeed when you run play it didn't find any duplicates. We can go further and extract everything that's related to a country and a specific country class and to make it more meaningful when you test over it and when you will run Flog you have a lower score for the complexity that means it's more readable and again you inform that you have a more readable code source. So the ID of CodeReview is really to spread the knowledge and with CodeReview because we are humans we can check anything but because we are humans we cannot check everything every time and that's why it's not the silver bullet and it's very complementary with test and static analysis. So I have illustrated the different kind of safety nets that you can put in place and we don't do that without purpose. The real goal is that you want to reduce the cost and the risk to introduce errors in your code when you change it because more and more you wait, more it will cost you. If you can fix something at the moment you write a code it's far cheaper than wait too cheap in production and that it blow off your product and as Kilt said yesterday you can even be so confident in your code that you can go to continuous deployment. Martin Foller reminds recently that it's not about writing clean code to have the best quality it's really about the economics and because we are only humans we want to do, we are lazy and if we can do something in less time and with less money I think we would be happy to do it. So with different kind of safety nets you could be more confident to do something and to go forward to just change your code and not be scared each time you change one line in your code base that it could introduce a bug. So you just change it and if there's a problem the safety nets will catch you and you can continue without any worryness. So yeah the reason if you have two options A and B and maybe you are too busy to improve but with some time you can make it better and you can go further and faster. So the last question is where you can start. I presented to you different solution. Just take a look of what you do today. If you do test but you don't automate them you should start maybe by that. If you do test and have a CI but don't do code review or static analysis just pick a tool and start to use it and try to find if it's useful for you in your workflow or ask a colleague to read each time you finish a feature branch to read your code and give you feedback. Just step by step do a first one, a very tiny one and at the end you will reach probably more, you will cover more distance that you can expect at the beginning. That's it. You can find the code I presented in a Git repository. Each commit represent a different step and you can find me on Twitter, GitHub or pull review and don't forget, shot plate. Thanks, Christophe. Any questions for him? Hi, thanks for the talk. I think along with Flock, Clay, I think we'll also talk about the security features using Breakman. Any thoughts on that? What are you thinking about? Security about applications in Breakman? Yeah, Breakman is effectively capable to check your Rails application and different kinds of security vulnerabilities. They could be simple but they are quite common mistakes that you can do so it's really useful to have Breakman check your code and be sure that at least the common errors have been covered. Perfect, I think it should also be a part of your presentation, it was pretty cool. The other question I had was also about having good coding guidelines can also help you recover from a lot of issues. Sometimes you're converting a parameter in your controllers into a symbol and stuff like this. Breakman catches a lot of this, but having these kind of code lines are they going to be part of your repository? Because that would be very, very helpful. Good coding guidelines towards how you go about writing good code from the start. Yeah. The excessive use of instance variables or excessive use of symbols and how you code such that you're always writing code which is not going to get you a larger clock score. Are you going to have such coding guidelines written on something? Not sure to have understand, sorry. So try to recap in other words. So how could we use code to make it better from the beginning or? Simply put, if you could add a little bit more content about Breakman and something about coding guidelines when you start programming to ensure that we get a good clock score rather than running clock every time to reduce my score. Okay, so guideline about that, I think it's at a certain point you can increase the complexity because when you refactor your code, sometimes it's not important that your code is complex just because you need to move the things and find a good way to abstract your things. So it's interesting to know it's complex because you can spot where are the problems and when you spot the problems you start to refactor that part but you don't care about the score, you just check them frequently until you reach a reasonable state where your code is more readable and simpler to read. And indeed, when you can split the things in different modules that are very simple and more short and shorter, usually your score, your complete score for each module will be lower. In fact, what you do is you spread your complexity but because you have individual modules, they are just very dedicated to a simple task. It's easier to understand and to read it so it will be easier to change it without introduce a bug. Have I answered your question? Yes, very well, thank you so much. Thanks. Apart from the chocolates, have you also got some magic beer for tasting? Yeah, I'm sorry, the problem with beers that my flight were about 15 hours and they are far more heavy than the chocolate so if I needed to bring 400 beers, I'm not sure that it will be feasible. You would have been more popular than the Golden Age sponsors here. That could be a good goal for the next one. Thank you. Thanks.