 rather than deal with all of the madness of trying to do lightning talks, which can be expensive to manage, we decided we'd just pick three people to do awesome talks and squash them all into one session and give them a few extra minutes than you usually get in a lightning talk. So we're doing three mini talks. So enough about why, who. Our first speaker is Tony Arsieri and he's going to talk to you about celluloid. Tony is a living social and you can introduce yourself anything else you want to say. Thanks guys. All right, so I'm Tony Arsieri and I assure you all I know what I'm talking about despite the fact I sound like Jeff Spicoli. So how many of you have heard of celluloid? All right, that's a nice showing of hands, I'm happy. So as I said, I work at Living Social on the architecture team in case you forgot we're hiring. So celluloid I like to think of as threats on rails. So it's a comprehensive framework with a lot of features for building multi-thread programs and a lot of abstract and generalized solutions around that, particularly around fault tolerance. The main project you may have heard of that's using celluloid in production is sidekicks. Celluloid isn't like a science experiment. Lots of people are running it in production right now. So what celluloid does is combine object-oriented programming in the actor model and I think these things go together like peanut butter and chocolate. So this is my favorite quote from Alan Kaye. I put it in probably half the talks I've ever given in my life, but really when I read this what I think is that object-oriented programming should be a natural way to do concurrency, right? Alan Kaye thinks of objects as being servers or biological cells. So celluloid provides you active objects as opposed to the normal, like sequential passive objects you might use and unlike other concurrent object-oriented programming techniques, this one is based on the actor model. So I was a huge fan of Erlang if you haven't heard of any of my Erlang projects, particularly Rea. I think these guys were really into concurrency before it was popular and kind of pioneered a lot of really good techniques for building concurrent programs. So the actor model might sound kind of scary, but it's really simple. Basically you have these actors, each one has an address you can use to talk to them. If you know the address you can send them messages kind of like if you know anybody's postal address you can send them a letter and then actors can create new actors. So I'm not the first person to try to combine these concepts by long shot. This is actually a pretty major research topic in the late 1980s and early 1990s. The main project I found that was really similar to celluloid was called Adam. So this was developed in Python in 1997 as this guy, Michael's PhD thesis there. And unfortunately they never really went anywhere with it. I think they may have been a little bit too early. So to me combining the actor model and object-oriented programming is kind of this like for gotten solution, right? So when you hear about concurrency these days you hear a lot about functional programming or languages like Go, right? And nobody's really talking about actor-based object-oriented programming. So I'm trying to single-handedly revitalize it. I'm getting a lot of good feedback on it. A lot of people were like, celluloid made it so simple to write this concurrent program. So I'd like to show you today the basics of celluloid and how to use it. So here is an example. This actually comes out of a Railscast on celluloid. I'd strongly recommend you watch it because he covers stuff I don't. But so we basically got this thing. It looks like a normal Ruby class except what you're going to do is include celluloid there. And then we got this whole launch method. It's going to do a little countdown and blast off. So we do dot new instead of getting a normal object back. What we get is a celluloid actor. So the first thing we're going to do is do a synchronous call to it. So synchronous calls are just like normal method calls that you'd be using in Ruby. So we're going to do dot launch on it. And then it's going to do the little countdown there and blast off and we get the result back. So it's actually going on behind the scenes. It's a little bit complicated. So we have a proxy object intercepting that call. And those little chevrons you see that say celluloid call and celluloid response are actually messages being sent between threads. And the mailboxes are where we do all the synchronization. So the request to make the call comes in. The actor processes these messages one at a time. So you don't need to worry about synchronization yourself. And then it'll send the response back as a message. So where things start to get really interesting is a synchronous call. So you can kind of think of this like rescue or next tick in event machine if you're familiar with that. Basically what it does is schedule work to be executed. You're not really sure when it's going to be executed. It's going to be executed whenever the actor gets around to it. So to do that you do dot async before you call the method. So this is a new syntax. Actually if you happen to know about earlier versions of celluloid they use dot bang on the end of the method instead of that dot async. I think that dot async syntax is nicer. And one of the main complaints I have gotten about the previous API was that people couldn't call bang methods. The goal is to deprecate that syntax and then you'll get your bang methods back in celluloid 1.0. So if we do dot launch asynchronously what's going to happen is that's going to return immediately. So the current thread is free to continue doing whatever it wants. But that same countdown there is still going to happen anyway. So synchronous calls are just straight through, right? You're never waiting for a result so it's a really simple way to schedule work. So whatever anybody sees this it's like okay well what if I actually care about the return value of an asynchronous call. So to do that you can use futures. So the best analogy for futures I can think of is calling ahead to a restaurant to order food so when you show up hopefully it's ready. Maybe it's not, maybe you still got a couple minutes left before your food's done but you're still going to save yourself some time versus showing up to the restaurant and ordering it when you get there right. So this is a Ted Dizuba style non-close form of Fibonacci function if you're familiar with that. So this is, you know, this basically does a lot of CPU intensive work. So call a future on it, you do dot future instead of dot async, it's a very similar syntax. And again that's going to return immediately regardless of how long it takes to execute that function. You actually want to get the return value back, you call dot future and that's going to block until that's actually complete there. The messaging model there is a little bit more complicated and maybe you can follow that. It looks similar to asynchronous call but you have that little stop at the bottom for, you know, getting this celluloid feature handle back and then obtaining this valulator. So now the neatest feature of celluloid is pools. So pools let you have a group of actors and you can schedule work inside of it. So create a pool, you just call dot pool on any class, include celluloid. You can give it a size if you want to or if you don't it will automatically build a pool that's as big as many CPUs as you have on your system. Which is a nifty feature that certain other overhyped concurrency technologies don't support. One minute Tony. Alright, so to do a parallel computation here you can create a bunch of futures using map and then obtain their value just by mapping across those values. So we can calculate all those Fibonacci numbers in parallel there and get all the results back. One thing to worry about here is the gill. So you can do parallel IO with YARV. If you want to do a bunch of net HTTP requests you can do that but for this Fibonacci thing you're bound to one core. So for that you probably want to use JRuby or Rubinius. And that's it. I'm basculent on Twitter if you don't want to hear me rant you can also follow celluloidRB which is just celluloid specific stuff. And visit celluloid.io if you want to learn more. I also have stickers if you want a celluloid sticker. So hit me up when I'm done. Alright. So please to welcome back to our stage Chris Epstein. You probably know him from the Compass framework and his work on SAS. He doesn't have any AV so just the mic. So please welcome back Chris. Can you guys hear me okay? Alright thanks Josh. So this is actually my first time not talking about SAS I'm a little nervous. But give it a try. After Josh asked me to give this talk I sat back and was kind of not quite sure what I talk about. And I was driving to work one day and I heard this. There's like some eco activist guy who's been spending the last like 30 or 40 years of his life dedicated to fighting. All the bad things that happened to our ecologies. And he had succeeded in making all these wonderful things happen. And the interesting thing was at the end of all this interview he said like you know 30 years ago I was walking through the forest with my son and I came across this clear cut forest and it just broke my heart and I said I have to do something about that. And so he dedicated his life from that point on to doing this. But it was one small thing after another he didn't know he was going to dedicate his whole life to this. And when he got there you know at the end of this interview he's like you know looking back I think if I had known what I was getting myself into I'm not sure I would have done all this. But he didn't sound like there was any regret in his voice. He was mostly just kind of happy that he was ignorant of what was going to come down because he never would have taken those risks. And this really resonated with me because throughout my life I feel like there's a number of things that have happened where I've taken a risk without knowing it. Where I've just made some foolhardy decisions and they should have really come back to bite me but somehow everything turned out a little bit better than expected. So I just want to take a few minutes and tell you guys a couple of stories and hopefully I'll enjoy them. When I was in high school I walked into a home room one day and sat down and the girl that was sitting next to me looked over and said did you replicate working on your applications? Applications of what? And she said oh well today's the due date for applying to college. And I said oh no no I didn't I didn't do that. And so I planned to go to college after high school but here I was totally unprepared. And I should have known this all the teachers were telling us about the due dates and stuff but I don't know in one ear and out the other. And when I so I went home and I told my parents I'm like I guess I'm not going to college. And my mom said why don't you go get a job? So I got a job at the pizza place around the corner and I worked there for a number of months and the teacher or the assistant manager that was there she didn't like me she kind of really had it out for me. And one day we were like arguing about something or another and she said to me you're a piece of shit. And you're not going anywhere in your life you're just a stupid pizza boy. What a fucking bitch. But here's the thing is that when an assistant manager of a whole pizza place in a town of really no consequence tells you that you're a piece of shit and not going anywhere I think you need to take stock of your life. And so I looked at her and I did all the calculations and I'm like maybe I'm on a path I don't want to be on right here. And I looked at her I'm like hey fuck you I'm going places this is just a stepping stone. And she laughed because I think she saw that I was being a little naive. I didn't have anything going for me. So the next day I went to junior college the junior college that was local to us and said please let me in. And they they got me all signed up. And I was a music major I was going to go into theory and composition and while I was there I took calculus because you have to take calculus that's like the math that you take in college. Except you don't to be a math major don't be calculus. And I got about halfway through the semester before I realized that I didn't need to be there. But I loved it and I ended up taking all the math and all the science and individual study classes and all this other great stuff. And I had all these personal attention from these instructors at this junior college. And this was perfect for me it was what I needed. And I didn't consciously choose this I didn't do the research I didn't know. But if I'd gone to a four year none of that would have happened and I built up a lot of confidence there. And that was really great for me. In fact maybe a little too much confidence because. Towards the end of my time in junior college I asked my. Physics instructor I said hey. I'm kind of interested in this physics thing. But I know that if you get like a bachelor's in physics it's not very cool you know you generally can't do much with that. But if I was going to where should I go. He said oh well Caltech. But you can't get in there. This guy was very important mentor to me and I really wanted to prove him wrong so. I got it in my mind that I would apply and I spent the next. Hundred and sixty hours of my life for. Something like that like studying for these entrance exams I had to take. But I actually didn't even know that much about Caltech. I didn't realize that it's the math and science engineering school on the planet. I just thought it was a good school. And so. But I dedicated my this all this amount of time in into just. Studying for this test that I knew it was important I knew I had to do good on it. If I was going to have any chance. And even though he had initially dissuaded me when I asked him for help he was there he was giving me a hand. And guiding me along the way and I ended up getting in. And when I got there I met all these people and they spent all their lives preparing. To go to this school and I just was like you know one day I was like maybe I'll come here. And that actually made some of them mad. But. But if I had known that people. Do that like who how naive was I to think that I could just. Sit down and like maybe get accepted. But this changed my life it set me on a trajectory that. You know I never could have imagined and if I had known how hard Caltech was. That I was going to get depressed and get addicted to drugs and all these other horrible things that were going to happen in my life. I wouldn't have done it. But I'm glad I did. When I first found SAS. I'm like holy crap this is the coolest software project. It's it's it's cool that Ruby is good to have it but what if. More people can have it and I really did I just said. I'm going to make SAS famous. I was pretty naive. Because. How many open source projects are there on GitHub I mean. The idea that you could make something and somehow. Get it into the popular mindset is just. Such a hard. Thing to do and. I didn't know the first thing about anything about community management I didn't know anything about. Managing an open source project I'd never submitted a single patch to an open source project. But. Here we are a few years on and and SAS is actually quite popular in these days when. People are starting a new project they asked themselves you know should be SAS on this project. One minute Chris and I told my wife I said three years ago one of these days people are going to do that. She believed me she had no idea how naive I was. So all through my life I've been doing these really stupid things I put myself into them with like a hundred and fifty percent of my effort. And sometimes they turn out but not always I really wanted to be like a grandmaster of that chess at one point. That didn't pan out. And I wanted to be awesome at poker but I lost a lot of money. But the thing was all along this way I had these really awesome people in my lives and they were they weren't there to dissuade me they were there to support me. And now that I've gotten older and I'm more of a mentor and I'm getting asked for advice sometimes I find myself saying. Do you fucking clue how hard that's going to be. And I'm sorry I'm sorry I did that because you know what if you think you can do it if you think you can give it your all. Who am I to say you can't. That's my talk. So OK our next speaker is Sarah May. You probably all know her. I had the great privilege to work with her at Pivotal Labs. She's a wonderful person to work with. She's put her heart and soul into so many things that have affected the community. She helped create Rails Bridge and has done a lot of work to expand diversity in the community. She's worked with the Diaspora Project and done a lot of good stuff there. And so I'm going to let her speak now. Thanks Sarah. Thanks Josh. Good afternoon. As Josh said I'm Sarah May. I'm a developer at Pivotal Labs here in San Francisco. And I am the co-founder of Rails Bridge. And I'm involved in a bunch of open source projects. The largest of which is Diaspora. But I am not here to talk to you about any of those things. I'm here to tell you a story. Apparently it's afternoon story time. It works for my preschooler. I told Josh what I was going to talk about was the guts of Ruby. The C code that is inside of the MRI that maps Ruby implementation. Which is the implementation of Ruby that evolved from the very first version. But I can't do that in ten minutes. I discovered. So instead, what I'm going to talk about is the Ruby creation myth. You may be surprised that we have a creation myth. But we do. And we're at a Ruby event so I expect most of you to know the basic history of the Ruby programming language, right? Japanese programmer Yuki Hiromatsu-Moto, known as Matz, writes the first version of the language and releases it in 1995. And if you look at the Wikipedia page for the Ruby programming language, which is, of course, the canonical source of knowledge, I'm sure, is, there is a section on history where you will find the Ruby creation myth. And it goes something like Matz was a C programmer. What he really wanted out of life was an object-oriented scripting language. So he looked at Pearl and decided it was a toy. And he looked at Python. And he decided that Python's object facilities were grafted on and not very useful. And so being thus dissatisfied with the existing state of object-oriented scripting languages, he decided to write his own. So that's the myth. And everything in that entire story is true. But telling it like that leaves out what for us as developers and for us specifically as Ruby developers is the most interesting part of that story. And that is the how. How did he go from being a C programmer and then suddenly hand wave to hand wave, Ruby is born. How does that happen? So let me back up for a moment and tell you about a conference I went to about a year and a half ago called the red dot Ruby conference which is in Singapore, which is a really great conference by the way. And if you ever have a chance to go out there, you should definitely take it. And I was doing the tutorial that was the day before the real conference. So I showed up. I've never been to Singapore before. I came by myself. And the organizer of the conference had arranged to lead a walking tour of Singapore for all of the speakers that were there from out of town. So I thought that sounded pretty fun. So I went downstairs and the only other speaker who was there, besides me for the walking tour, was Matz. So Andy, the organizer, me and Matz took a three hour walk around Singapore. And this was incredibly, incredibly intimidating for me. Here I am, me and the creator of Ruby, who I had never really talked to before. I mean, he knew who I was because I had been at RubyKaigi the year before and anyone who is not Japanese who goes to RubyKaigi in Tokyo is really conspicuous. And I think we had even been introduced briefly, but I'd never actually had a conversation with him. And I kind of thought of him as programming royalty, programming super genius. I could never do what he does. I don't know what it is he does, but I'm pretty sure I can't do it. And so, but here where I was, right, I have three hours with Matz and I can ask him anything I want. And the best part about it was that if I made a complete ass out of myself, no one would ever know. Because the only other time that I would ever have to talk to Matz is during a conference, right? And if you've ever been at a conference where Matz is speaking, you'll notice that he attracts a little cloud of people around him and they follow him around. And the entourage that he attracts means that you can't really have a real conversation with him. Like, the way that people have conversations with Matz under those circumstances is mostly like go up, ask a very specific question, have a small conversation, thank Matz for his time and leave. But here's my chance, right? Here's my chance. And I figured it probably was a little rude to start grilling him about the history of Ruby as we stepped out the door. So we spent an hour walking around and admiring the gum-free sidewalks and the many beautiful shopping malls. And finally I said, okay, all right, I gotta fucking ask the question. Just gotta do it. I said, I want to ask you a question about how Ruby was created. He was like, sure, because of course he's a really nice guy, right? Mina Swan and all that, he's gonna answer my question. So I said, okay, so you're a C programmer. And he said, yes, I've been doing C for over 20 years. Okay. And I said, well, okay, I've done some C. And the act of writing C and the act of writing Ruby feel very different, right? There's some resource issues, but there's also a qualitative difference to the experience of writing those languages. And we all feel that otherwise we would not be here on a sunny Saturday talking about Ruby. And so what I don't understand is you're a C developer and then suddenly Ruby exists. How does that happen? And, you know, because to me it felt like the creation myth of Ruby to me felt like, like the birth of Athena for any of you that are into like Greek mythology, right? Zeus, the ruler of all the gods has a headache. And it gets worse and worse and worse. And suddenly his skull splits open and out comes Athena, fully dressed, fully armed and ready to go. And in my imagination, I think it was something like, you know, maths has a headache. And it gets worse and worse and worse. And then his skull splits open and Ruby comes out for all of us to use. So when I actually asked him this question, I left out the part about the skull splitings. I wasn't sure if he was going to have the right cultural context to appreciate what I was talking about. And I didn't think, I didn't want him to think I was a psychopath. He thought about it for a few minutes and he said, well, you know, I was writing Ruby for a really long time before Ruby existed. And for a moment I thought we were having more translation difficulties. But he actually meant that. And what he meant by that and he explained is that as a C developer starting in the 80s, he had started customizing his programming environment to make it more like how he wanted it to work. You know, he wrote little extensions to see, like, type defs and macros and whatever it is those C people do. And each one was a response to a particular problem he had. Each one was a very small change. But over a fairly long period of time, right, so his C extensions evolved and they grew. And as a result the C code he was writing that used these extensions started to look a lot like Ruby. It's C code that looks like Ruby. Matt's essentially implemented Ruby as a DSL in C, which just blew my mind. And he did it over a fairly long period of time. So in the early 90s, right, when he was thinking, oh, this is kind of cool. Well, I think other people should take a look at it, right? Turning it into its own language was an incremental evolution of something he'd been working on for a long time. It was a fairly small step. He didn't have some one great big idea and then he locked himself in a cave and he made it. It was like he had a lot of little ideas that were all good over a long period of time and he just acted on each one and they kind of accumulated. And after I had thought about that for a while it actually really changed the way that I thought about programming languages and programmers and the way that I relate to people in the community. Because I'm not the type of person who has the big grand idea and then goes and works on it and, you know, code flows out of my fingers and then, ta-da, something magical appears, right? That's really not my creation process. But having a bunch of decent ideas one at a time and acting on them when they occur, that I can do. And you can do that, right? Any one of us in this room could be the next maths or maybe the next DHH if you'd rather be him. And what I really got out of this was that someone who that we think of as a technical genius as someone so far above us, the genius that he has was really just in the process of noticing the small problems and fixing them as they happened over a long period of time. And he did it over and over and over again. And if you do that, you may realize one day that the small problems you've been solving are really all sort of component parts of this one big problem. And your assembled solution suddenly starts looking like it might be able to solve much bigger problems than you previously thought. And when that happens, then you too can have an entourage that follows you around at conferences. Thank you very much.