 Hello, hello, hello. So before I start, I work with 104 interesting people at Digital Ocean, and I wasn't at work on Thursday and Friday, and they were like, where are you hanging out? And I said in Buffalo, they said, what? And I said, yeah, Buffalo. So just to prove that I am in Buffalo, I'm actually going to take a picture of you guys in a second, and smile, or whatever you do when you get in pictures, just to show everybody where I was. So a few months ago, I was asked to speak here keynote, and that's weird for me, because I don't like to keynote. I like to talk about things like computer science. I like to talk about theories. I like to talk about machine learning. I like to talk about simulation theory. And I'm like, wow, keynote about simulation theory at Nickel City Ruby, there's not going to fly. So I was just brainstorming one day, and I said, you know what? I like weird things. I'm going to talk about abstractions. And so I actually just put it on Twitter, and Nick picked it up, put it on the site, so there we go. So I actually am going to move around, but I want to start at my laptop, because she's my baby, and I want to make her know that I love her, and I'll be back. So let's think about abstractions. And because this is a Ruby talk, I'm actually not going to talk about Ruby at first. I'm going to talk about other things, like how fast can we go? Have you ever sat down and thought, how fast can I go? Am I fast as Brian? I'm not very fast. This is why I code. I'm not athletic. Am I as fast as Usain Bolt? But guess what? We're not that fast. So what's fast? So if you think about what's fast, and I do have a point here. Light is fast. And I think about it, and I always actually think about this on the plane on the way here, how fast is light? It's pretty fast. I open my eyes, it's always there. And we're taught in school that light is pretty fast. Anyone know how fast light is? 300, what'd you say? No. No. We actually move through space faster than that. It's 300,000 kilometers per second. There actually is 299,958, 957 possibly kilometers per second, the speed of light. But guess what? They lie to us. That's actually not correct. We are always taught that you cannot go faster than the speed of light. And you believe that, I believed it. I believed it for 38 years. And so the other day when I read in the book that that's actually not true. The real thing is as massless particles, nothing in the universe can move faster than massless particles. And to tell you the truth, light photons just happen to be massless particles. So the real answer is, it's not such thing as the speed of light, it's the speed of massless particles. So why didn't we learn this way? Well, I'll tell you why. And this brings us back to our topic. Abstractions are easy to parse and to process. So saying that massless particles move, you can't move faster than massless particles, doesn't sound as cool as you can't move faster than light. And actually the real answer is we figured light out before we figured out the particles. So the introduction, I work at Digital Ocean. Anyone here heard of Digital Ocean? Right? Anyone here giving me money every month? All right, so I have a deal with you. If you guys sit through this whole entire talk, I will create a promo at the end. And whenever we do tonight, or if you can figure out my email or my Twitter, I will give you guys promo. You guys can surf the ocean for free for a bit. It's the least I can do. I'm Brian L, by the way, and I bought these really cool glasses. I wear contacts, but then I bought a pair of glasses that were on top of the contacts because I thought they were really cool. But they're computer glasses. Anyone here have computer glasses? I found that they're actually kind of yellow tinted and when I'm staring at my humongous screens all day, it actually takes the edge off. You should get a pair. I'm gonna put up my Amazon promo code here in a second, and so a couple more things. I saw this chart earlier and I was like, where do I fit in this? I calculated, I actually brought out Mathematica earlier and I figured it out. I am 99.973% awesome. I don't know where the .027% are. Maybe you just can't get that. And I was thinking about something else. So you guys wanna talk about code? I did that. And I'm pretty proud, I don't do it anymore because that was actually a very stressful year. I actually went 400 days in a row with the commit. And during that time, I was in Asia, I was in Europe, I was down in Mexico, it was fun but scary getting there. And I actually, I wrote code every single day. So, do you guys wanna write software? So I'm actually gonna write some software and this will be the last piece of software I write for you guys. Let me go to my handy-nandy terminal. Can you guys see this? Do I need to be a little bit bigger? So let's talk about abstractions. And I'm trying to frame this context of how abstractions work. There are abstractions in code. And I'm actually gonna do this with one hand because I don't have a lavalier. So I'm gonna type code for you with one hand. Find my mouse, there it goes. So anyone here use Docker? So now you can at least say you've seen it in person. I'm actually gonna fire up Docker containers because a little secret, Macs are awesome but if you've ever done any low-level programming, Darwin is actually pretty horrible and things just don't work like they do in Linux. So I'm actually gonna boot up Linux for these little code snippets and just to show you some things. So I'm actually starting up Docker. I'm gonna run, I have a GCC container and it just has GCC in there so I can actually run that. And I'm gonna fire up my trusty editor. Who here uses cat as their editor? So I'm gonna fire this one up here and I'm gonna just make a file here and I'm gonna type, we'll make an assembly, we'll type some assembly. There we go. And then what I'm gonna do is I'm actually gonna type in this code with one hand. So I'm gonna go, uh-uh, uh-uh, uh-uh, and it didn't work. Try this again. Oh, the demo, they got me early. Mm-hmm, yeah, let me do that for a second here. All right, now I'm gonna use two hands and it's gonna be awesome. Mm-hmm. There we go. We're just gonna, oh, I did type these. So what we have here is I was just thinking about this the other day and I was like, I wanna type a similar on a stage. But then I started typing this out and I'm like, there's no way I'm gonna type a similar on a stage. So what this is, I think it's about 15 lines. It's Hello World and Assembler. So we go here, we'll get up there, we'll compile it, we'll see that it's there. I created it in the root directory and that's what it does. It makes a Hello World. But we realized very early on that first we were writing machine code, people were actually punching ones and zeros in machine code, punching ones and zeros in machine code. We realized really early that that didn't work. So we came up with the similar languages and over the years, there's been lots of similar languages. There's the old things that we were doing in IBM land and then there's 605.2, 6502 that we were doing on Apple. Anyone here done any 8080 assembler? I know someone else here has. Right there, I see him. I used to actually write demos in Assembler, write music and code. And so we was coding that kind of stuff all the time. But some guy back in a few years ago before I was born said, do you know something we can do better than that? So let me show you what he did. I'll put this at the top. We created C. And even with C, I can actually compile this program and it'll pronounce hello world again. But that still is not the proper level of where we want it to be. So let's go ahead a whole bunch of years and let's look at where we are right now. And there we go. Now you see that what we've progressed through through the last few years is actually a whole bunch of abstractions. And that's what actually what I want to talk about today. So there we go. So let me introduce abstractions. What's an abstraction? An abstraction is something that exists only as an idea. Think about it. What we do, literally what we do, we type at computers all day long, it's only ideas unless you are doing something physical or you're making things move, like you're using robots. We are actually only turning ideas into abstractions that run in some, either on spinning rust or some kind of other memory device and it runs code and it puts things there. This is actually, it's not real. What we do is not real. It's an abstraction of some idea. So why do we need abstractions? Well, really what it comes down to is abstractions are the best thing ever. They are how we process the world. If you actually had to understand how I'm standing up here and how my body functions and why I'm not nervous right now, you don't need to understand that. Just understand that I'm gonna give you 30 good more minutes of talks about abstractions. So let's find the right level of abstractions. And this is actually something that's really, really difficult. We spend a lot of times, and actually you as developers, that's what most of your day is about, finding the right level of abstractions. How do we take idea X and turn it into program Y to solve business need Z? And we also use abstractions to reduce burdens. And the cool thing about that is that we don't need a mental capacity of understanding everything. We can actually just use smaller abstractions to actually show this. And I'll demonstrate this later. So let's look at some example abstractions. I couldn't get by without talking about Java. I actually am a rare Ruby developer. I like to write code in Java. Matter of fact, I think this year I've written way more Java than Ruby. So what does abstractions look like in Java? Has anyone here done any Java? Yes. Are you guys, is it a wince or is that a happy face? No, so it's an iffy iffy. So abstractions in Java. There's actually two constructs that Java gives you that are for abstractions. The first one is this example. It's an abstract class. And really what we're defining here is we're saying that we have an abstract class car. The canonical example is vehicle, but I'm going to say car. And what we're saying is that any class that inherits from this actually has to provide implementations for speed up, slow down, and get location. Because all cars have GPS nowadays. The next way you can provide abstractions in Java is with interfaces. And these are pretty neat. What I'm doing now is I'm saying that if my object implements these interfaces, the contract is guaranteed to say that I'm going to do speed up, slow down, and stop. They are similar ways of doing the same thing. I prefer this method because we always want to do composition over inheritance. So how do we do this in Ruby? So this is actually bringing it down to something that's very applicable to people in this room. Who here has written code like this? You have some contract and it has to talk to a remote service. So you're like, fine, I'm a hot Ruby developer. I'm going to write this. So in this case, we have a DNS class and what it can do is create a record. And what you want to do is you would call this and there could be arguments. We'll say there are arguments and you actually connect to the remote service and you do what you need to do. But you know something? There's a better way of doing this. And this is one level of abstraction that I'm going to try to share with you. What we should be doing is creating something called remote DNS. And the only difference here is I actually just changed the class name and I actually added the arguments this time. And what it does is it calls the remote service and then issues the calls. And then how we can use this inside of our code is we can have our original DNS class and we can pass in the implementation and we can call the create record and it calls the right things on the object. Anyone know what this is called? That is correct, it is dependency injection and a dependency injection is a great way of abstracting knowledge that you don't need away. And it's also a great way if you want your test to be fast, you don't ever want to make a remote call. Matter of fact, this code is not testable unless you have a fully replicated DNS environment inside of your CI or whatever you use for testing. And you know what? I work for a big company with lots of money and even we don't have that. So the cool thing about that is because we're using dependency injection now, we can do this cool thing where we can actually swap it out. I can throw a no op DNS in there, object in there, and then I can pass that in and whenever we call DNS code, nothing happens. So one other thing I want to share is defaults are good. You should never make your users think about it. They should be able to fire up your code and it should run. You should not need a whole bunch of fancy options or even knowledge of these options to have default value. So in this case, what I've done is I've just made the DNS initialize with a no op. So, but what I'm really interested in these days is go. Actually, if I didn't have to write any Ruby ever again, I could just write go and it would make me happy. And not because go is any more expressive or any more nicer than Ruby is a language because actually it's not. It's just that when I write go, I can start at the top, iterate over my ideas and most likely it'll be idiomatic go and it'll run like 100 times faster than Ruby. So let's write the same thing inside. Let's see another level of abstractions inside of go. So we have this DNS service thing again, this concept that we talked about in Ruby land, but now we're gonna talk about go. Go isn't a language like Ruby. Go is compiled, so you don't get a rappel, you don't get all that nice stuff. So you have to actually make some kind of decisions up front. And in this case, what we're saying is that we're defining an interface. And it's kind of like the Java interface where we're saying that our interface will do this thing called create record. But the cool thing about go is that interfaces are implicit. All you need to do is have some entity that defines those types of methods. So if I need method A for my interface, if I have something that defines method A, in this case it's a struct, but in go I could actually say, is it on an integer or is it on a flow? It could be on a null, it doesn't matter. As long as I'm doing this, I'm actually satisfying my interface and I can use it. So we'll go through again here and more code, but here's the cool part is, and I'll go to the next slide, here's the cool part. I could actually use both. I haven't said that either my DNS service, no op or the remote one, I have not explicitly defined that they actually do that interface, but I can use them interchangeably in code. I find this interesting, and the lesson here is that abstractions, whether they're in a language like Java or a language like Ruby or a newer language like go, help you, they help you remove the details because details are never important, especially in object oriented. You actually should be hide object oriented language you should be hiding details wherever possible. So there is a very famous book, I don't ever remember the name, but it's the Gang of Four book, the book with all the patterns in it. This book actually codifies a lot of these abstractions and I'm not saying that you should use these abstractions, what I'm saying is that you should be aware of these abstractions and apply them where possible. So how do we go about creating these abstractions? The first thing I want you to do, and this is just me being smarty Brian, not code Brian, is I want you to focus on what? Too many of us as developers, we want to focus on our acumen at writing software in a particular language rather than focusing on what we are trying to solve. And if we spend a little bit more time trying to figure out what we're doing rather than how we're doing it or how fast we're doing it or what language we're doing it or whatever code technique is cool these days, your actual output will be better. So, where do abstractions go? We'll skip that one. Only reason why is because I actually quote myself on a slide and I want to get there because I'm really excited about this one. So, here's the ultimate abstraction, Matt, Guido, Rob Pike, and Go-Lan, whoever the dude who invented Java, Pike or a Kernigan and whoever invented all the other cool languages, they did the ultimate abstraction. What they did is they wrote their own programming language and here's the reason why. New programming languages exist to fill voids of missing abstractions. So the ultimate way of saying that we are missing abstractions is to actually create your own programming language and I know that the guys that created Elixir, that's how they were filling. So they wanted to take the best of Ruby but hook it up to the best of Erlang because they wanted the concurrency but they want the expressiveness. So they actually said we're not, instead of creating libraries on top of Erlang, we're actually gonna create our own programming language. But I'll tell you what, abstractions aren't a panacea. With abstractions come cargo cults. Who here does not know what a cargo cult is? All right, I like telling this story and I'm gonna tell it my way and you can look on Wikipedia later and you can correlate those. Mine will be mostly true. So many years ago in a faraway land, namely the South Pacific, there was islanders and these islanders, so white people would come on ships and they would bring great food and they would bring medicine and unfortunately they would bring their religion. But the islanders actually started liking these so they actually worship these people who were bringing this cargo as gods and they form the religion around these people bringing the ships so they call them the cargo cults. The crazy thing is that the way that we use it is we're saying that someone's giving us information wholesale and we're taking it and believing it as religion. It's actually a really bad thing. And like I said, I had a picture of the Gang of Four book, the Design Patterns book. There are a lot of great abstractions to find in this book. There's patterns that you can use that are actually pretty good but the problem is that people take things like what design patterns, they take things that like DHH says and they take them wholesale without understanding why these things exist. And that's actually, that's pretty bad. And that's the case, that's actually a place where abstractions can fail you. So what you need to do is you need to tread lightly and what I'm asking you to do is to be a smart person and you're gonna say this is hard, Brian, what you're saying is pretty crazy right now. You haven't given us any details or any content. No, I've given you content. You haven't given us any way to actually figure out how to create abstractions and that's the cool part. I'm giving a keynote so whatever I say doesn't have to be true. It just has to be said. And that's why I was kind of wary. I really just wanted to give a talk about nothing but really give you a talk about something at the same time. I'm actually sign felding you guys. So, but really you have to tread lightly. When you're going down the route looking for abstractions and I'm actually purposely being abstract and I'm purposely having very abstract slides here. It's like a whole running joke. You'll get it next week. No, but you need the tread lightly. You can't just say that we're going to abstract all the things because if you do, guess what happens? You get Rails 4.1.6. So here, anyone know what RC2616 is? Show of hands? All right, put your hand down. Who here works on the web? You guys all failed. That's the HTTP RFC. That's the RFC that says how get, put, post, patch, options, head. That's the one that says, that's the HTTP 1.1 RFC. That's the one that says how the web works. So you guys are doing things. You're creating code. You're putting code online. And you don't even know how the web works. But you know what? That's fine because guess what? With Rails, Rails brought along a great set of abstractions to allow you to do that. So is that a good thing? Yes, but is that a good thing? Not really. None of you guys can work for me. I'm just kidding, but not really. So yes, so mixing levels of abstractions make for a long night. You see this all the time in Rails where you will have business logic, how we want to do things. You have domain logic, how things are, mixed with whatever you had for breakfast this morning. And depending on what you have for breakfast this morning, it's gonna be how you think for the day. So now we're mixing all these levels together. So a good example of this would be if you're designing a banking application and you have the banking logic of how data is stored. But at the system level, you have that mixed in with how you're doing transactions. So actually now your banking business logic has to know how the transaction piece works or it all falls down. And we've seen this code before. Where you change one thing and all your tests fail. That's because you mixed levels of abstraction. And that was a code saying, that was a slide saying what I just said. So another thing I want you to do is wrap your exceptions. Because once again, this is an abstract talk so I'm just gonna bounce around. If I'm running your Rails app or your gem and I encounter an exception and it's like a runtime error. What's a runtime error from the RSpec gem? And RSpec gem doesn't do this. But if I'm running RSpec and I get a runtime error, what does that mean? That means that that gem is broken. What you should be doing is expecting exceptions and wrapping those exceptions. It's really easy in Ruby. You just do class, whatever, whatever. You just do class, something, this strong arm to this. You should be wrapping those exceptions because guess what, you need to make sure that you are capturing the right level of abstractions. And I said this. So last year, my soft talk for last year was why versus how? I actually did 40 minutes down in Mexico about this last year. It's actually my favorite talk. So I'm gonna talk about this for a second. So the cool thing that we see, and we see all these blog posts, about how to do something. If you go to Hacker News right now, you're gonna see someone telling you how to do this. I think there was some articles on, actually I don't read Hacker News, but there's articles on how to do things. And you go to Reddit, you go to all these programming things, all the programming subreddits, and it says how to do something. What we're always missing is why do we do this? Why do we want skinny controllers and fat models? Anyone know? See, that's the wrong question. You should have said that's actually the wrong thing. We don't understand. What we've done is we've given someone the answer before we explain the problem. And yes, 120 line controller methods is bad, but guess what, the answer is not just fat models. Because guess what happens when you're fat model? Now you have a 120 line model method, or you said I've extracted method, and now you have 45 line methods, but whenever you can pose them all together, you might as well just put them all in one method. So this actually is where my talk starts. This was the title, abstractions breed intuition, everything around that was let me just get up here and sound like I took some LSD back there while I was in the bathroom. The important thing here, and I am gonna be serious now, from now on the next, at least next three slides, I'll be serious with you guys. Abstractions are important. These things from the Gang of Four Patterns, this is the third time I mentioned this, are very important. Being able to talk at this level, so being able to say that I want some code that can actually observe when something changes when this happens. We've actually wrapped that up in an abstraction called an observer. Whenever we can talk in languages like using observer or facade, or iterator, or command, or state pattern, or whatever else we're going to use, these levels of abstraction allow us to talk on the same level. They allow us to talk more intelligently as developers. This is my favorite abstraction. I've been doing a lot of research in the physics lately, and now I'm actually rewriting Einstein's, all these theory city hacks. I have some better ideas than I think he does. But I've been talking about thinking about general, I've been thinking about this, equals MC squared. This is a great abstraction. Basically this says energy equals what? That's right, mass times speed of light squared. But you know C is not just a C. C is actually a longer equation. And it also depends on how fast you're moving. So there's more to this. But being able to distill things down to this small level is something that you can understand even though you don't understand anything about physics or theoretical physics is a good thing. Because then we all understand that Einstein did this, and we can talk intelligently about it. So what I'm really saying here is that we're looking for clarity through abstractions. And I'm not giving you a definitive answer. I'm just saying that if we can actually have these conversations on the same level, the level of intuition throughout your team will actually go up. So next we have abstractions breed excellence. We are doing this right now. We're standing on the shoulders of giants. Most of us are not writing a similar. Most of us, even in this room, we're not writing C. We're not writing a lot of low level C++. We're not writing any of that. What we are doing is we're focusing on higher level abstractions, like what should I name my RSpec method box? Or instead of thinking how, what happens whenever I do, I open up a TCP connection and I send data to port 80 on a machine and I have to do, first I have to identify that I'm HTTP 1.11 and then I do a get and then I have a path in there. We don't have to think about that. We have code that does that for us. We should also look for the separation of tasks. We should not muddle business objects with like our technical concerns. We should be very careful about how we create our objects. Sandy Metz, if you haven't read the Puder book in Rails and Ruby Land, have you read the practical object oriented design? I don't know what the R stands for. Ruby, that's what it is. The Puder book? I don't do Ruby anymore. You haven't read this book, actually. In Ruby Land, I would say that if she is not the best person to talk about object oriented programming, she is one of the best. But I'm gonna say she's the best. We should work on hiding complexity. And also we should embrace abstractions. We really should. You should look before you leap. You should constantly search for these abstractions. But, and you should also celebrate your abstractions. And I'm rushing to the end because I have like five minutes. And I want you guys to know that DigitalOcean loves developers. I love what you guys do. I don't want to be personal because I don't know you all. But I love what you do. I love that you're here. I love that you let me experiment with you on a new style of just sign felting you guys. I really do like what you guys are doing. And part of the goal for DigitalOcean is to, I'm not selling DigitalOcean, I'm not gonna tell you what we do, is making sure that developers can do what they, we wanna work with developers to make developers more awesome. And when you guys are more awesome, we're more awesome for helping you. We have great community sites. Anything you can search on, like I wanna set up this crazy thing, we have an article on it. And we have lots of VMs. But actually, I did rush to the end. I have five minutes here. And I wanna talk about something pretty important to myself at least. So in our programming community, if you follow Twitter, there's been quite a few controversies in the realm of making our environment more available to people who don't look like the status quo. And you know, I enjoy a good argument every once in a while on Twitter. It gets me through today. But I wanna talk about something from the opposite side. And before I say this, I actually enjoy every single effort I see to get women into this environment, to get minorities into this environment, to get transgender people accepted in this environment as the people they are. But I'm not here to talk about that. What I wanna say is I wanna talk about a success. And I am that success. I didn't grow up rich, but I didn't grow up poor. My parents, my father joined the military because he was 16. And he said, I can go to Vietnam and get shot at, or I cannot eat. So he chose to join the military. When I was growing up, he knew that I was good at math, but I wasn't good at school. So he bought me a computer. And he just said, just go do that. Go do, and then he bought me books on C. So I learned C and then I learned a similar, like 12, 13, 14. So this is before some of you were born, unfortunately. I'm getting old. But what I wanna do is say that we are missing diversity, but there are diversity successes in this room. And I can only talk to myself because I'm the only one that I know of. I don't know. I don't wanna talk for anyone else's. I don't wanna raise anyone else's story. But I'm living proof that given a chance, or just even given an inkling of a chance because sometimes I got less than a chance. I was told in high school that maybe I should just quit because I'm not getting to school. But then I went ahead and got almost perfect on SAT and I did get a perfect on the ACT. And then when I got into college, the guy said, if you can't write code like this, you'll never be successful. And I said, guess what, I'll see you never. And I left and I quit school right after that. But 20-something years later, I'm here today and I ran into you guys for a little while, but I am successful. I have a wife, I have kids, I have a house, I live in Maryland, I work in New York. My people that I work with respect me. I come here and I can do these talks and you guys are listening to me and you're not looking at me as this black guy, you're looking at me as Brian, the guy who used to say the F word all the time. But beyond that, I am successful and I try to help other people be successful, but I'm taking the opposite way. I'm not gonna go and say, hey, you need to hire more blacks because unfortunately when we do that as a community, what we are actually doing is dismissing the successes that we already have. And we are telling the people who look like me who are successful, because I'm not the only black successful dude who's written code, come on. That our achievements and our efforts are actually lessened. So all I wanna leave you with before I get off the stage is we need more diversity. We need more people doing what they're doing, but understand that it's not either or. And my parents couldn't even go into restaurants when they were a little kid. My mother would segregate at schools all the way up into high school. But guess what, that was in the 60s and we're in 2014 now, it's better. And all we need to do is make sure that it's better than we left it. And that's all we can do. You can't change people all the time. Thank you.