 Hello everybody, thank you for having me here, thanks to the organizers for the opportunity. So my name is Fabio Akita, most well-known as Akita Onreos on Twitter and on the social networks. I'm also the co-founder of a company in Brazil called Cold Miner, the software offshore outsourcing company. We have offices in six different places in Brazil and we also do work for several US companies as well, such as VTS here in New York and several others in California. And I also organize the Rubicon of Brazil, which has every year a thousand developers from all over the country. You're all of course invited to join us. And this year is going to be our ninth conference there. So if you're interested, please follow Rubicon of Beard at Twitter. So the pipe operator. For some, if you've ever tried Elixir, Elixir has this new syntax and all this cool Erlang technology that I really think that you should try. And the first thing that you will notice is the different kind of syntax it has and especially the pipe operator, even the official books display this operator as a different thing. And this is what it looks like if you try it. So because Elixir is not an object-oriented language, it does not have the dot notation that we're all so used to in Ruby. So it uses this pipe to chain methods, chain functions together, so it gets the last result as the first argument of the next function call. This is not the first language to do so if you're used to other languages. It's going to use something like this. And the idea of this pipe is to make sure you don't end up with code like this, which is going to be so ugly. So instead of doing that, we use this pipe operator mix for more neat code. And other languages, as I said, use it such as F sharp and Haskell has function composition as well. So in the functional languages, we have something similar to this. And in Ruby, we could either end up with feature MV saying why we can't have something such as neat as this in Ruby, or we can just let it go and say we have something similar, which is just the dot notation with collections and stuff like this. So to present an alternative, I want to try with the first example using the Linux piping and redirection. We are all used to bash programming and in the shell program. You have something like this pipe. And this is just a one-liner that I got randomly from the internet. It just gets the netstat results, pipe it through so I get the netcard ID. So just to make an example, if you never saw something like this, this first command is going to run, resulting a text like this. We're going to use awk. Awk is going to parse this, then pass this as an argument to ifconfig, and just again awk the results and get the idea that we want. So this code, if we're going to do an elixir, for example, how would it look like? So we can just get it through and do something like this. This is a little bit uglier, but I think all of you are going to understand what it does. Just going to split the strings, filter, map the collection, get a line, parse the lines, and map through the columns. Then the next step, we're just going to get the first argument. I'm cheating a little bit because elixir does not have this run cmd command. It's just a function that I wrote to make it cleaner. It's going to run for the ifconfig and then split it over and again do something like this. So this is not beautiful code, definitely not something that I would recommend you to do. So this is just something for quick prototyping. So the argument that I'm going to show is that you don't need to do code like this, but it's nice to have because we can reason more about the code we're writing before doing abstractions, before doing over-engineering over the code, so we can just create a workflow and write a quick and even a little bit dirtier, but something that we can reason about and have a result very fast, just like we do in the shell programming. So in elixir, we have something like this. And what if we could do something like this in Ruby? So Ruby would look something like this, but not so much because in the middle, we don't have something like this to pipe through, and we end up having something like this. So we break it down. And when we start breaking it like this, we have all of these temporary variables holding state and variables just to hold a middle step that serves for nothing but passing the results to the next function. So it's not so good because right now, we're going to start abstracting a way to a function, abstracting a way to another class, and maybe we end up with over-engineering over the code. But what if we could actually do something like this to do quick prototyping? This is an example of the code I'm proposing to you. So this actually works. This is pure Ruby, and you can just install it using this chainable methods gem that I just published. The idea is to think about your code in data transformation workflow. So let's design a workflow. It starts with a simple data, step-by-step transforming it. So we have a nice, neat workflow, and avoid temporary variables and other middle step code that could make it difficult to actually refactory later to a better abstraction. And we can have code like this. Several temporary variables. Again, we start with some text. We want to parse it through. Then we extract the URIs. We parse it. We open them and fetch the results. Then again, we pass through a parser, such as Snowkogiri, and then we can pipe functions together if the resulting objects have the methods that we need. But again, we're going to have several different variables dangling around, and we want to change the order or add more steps. It becomes cumbersome, and all of a sudden, you end up with a mess of a code, and then you start abstracting away, and then you end up with several abstracts that you don't need. But then we can actually create a chain like this. So we start with, in this case, a string. I wrap it around in this CM function that I created, and it creates a chain that I can start chaining and linking methods together. If the object that returns has a response to the method, I can just type dot, dot, dot, as we would doing Ruby, or otherwise, if it's not the same method, I can just change together for a block. But the new version that I just posted today, actually, can do something like this. And this is still Ruby. I can dot to the URI module directly, call the extract method, then the first on the string it results, and keep chaining methods together. So this is the code I'm proposing you as a different alternative to create those kinds of workflows. So this is the chainable methods. The idea is not to do all Ruby like this, it would be very ugly. The idea is to just use this code to reason and make interface discovery a little bit better and maybe not do so much abstraction before you actually need it. And in the next presentation, you're going to see about crystal. And I just started a crystal version as well, so you can try both in Ruby and as well in crystal. So this is chainable methods. I hope you find creative ways to use it. So thank you very much for watching.