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.  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 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 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.  I wouldn't have done it. But I'm glad I did. When I first found SAS.  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.  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.  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.  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.  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.  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?  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.


Welcome to JSA TV, where we're covering the latest stories, trends, and innovations from leaders in global connectivity, digital infrastructure, and the networks within. I'm Allison Whelan, coming to you live from Metro Connect USA 2024 in beautiful Fort Lauderdale. And joining me today is Bob Thompson, CEO of Underline Infrastructure. Bob, thank you so much for joining me. Thank you for having me, Allison. It's a pleasure. Of course. So we're just chatting a little bit. You have such a diverse background. What inspired you to found Underline? Well, the short version of the story is while I spent 25 years working as a banker I took a bit of a weird detour and spent the better part of 18 months working in Haiti after the earthquake back in 2010. Oh, wow. So the reason I share that is it was in Haiti managing three of the refugee camps that I got kicked in the face with what I call my American ignorance about critical infrastructure. We all naively take for granted that water comes out of the spout and the lights work and so forth. But I was in a place where I would say I was very morally responsible for the well-being of about 4,300 people And there was no power and no telecoms and the water was killing people. That experience started me on what's now a 10 year plus personal research project. What I would call the role of critical infrastructure in the fabric of communities. To the point where in 2018 I gave my wife the good news I was going to quit an otherwise pretty good job and try to start a company that could actually do something about transforming the capacity of American communities to flourish. So the background of underline is just that our mission is to deliver the critical infrastructure from a connectivity perspective that's necessary for American cities to flourish. Yeah, what a wonderful mission and thank you for everything you're doing. That sounds like it really changed the trajectory of things there that trip, huh? It really did. Yeah. To call it life altering is an understatement. Wow. Well, that's an amazing story. And what are some ways that you're seeing open access networks changing from the technology side of things right now? Well, there's there's a lot of different business models operating under the banner of open access. Ranging from purely wholesale fiber focused on the residential internet problem. We all the way to the other side of the spectrum, which is where we operate. We we build single multi-purpose fiber networks capable of serving every single client segment in the market from a poor family on government subsidized internet access all the way to complicated enterprise and local municipal utilities. So from a technology perspective, we would say community need needs to drive the technology. So communities need cyber secure foundations to modernize their other infrastructure. So that's where we believe the technology has to go and open access. Emphasis on cyber security, emphasis on capital efficiency, multi-purpose, multi-use infrastructure. But also the the transformation of fiber into a delivery mechanism for innovators. So the underlying platform of technologies is built to sit on top of our own owned fiber or to snap on top of someone else's fiber and bring it to life. And we think that's where the technology has to go. Of course. And so that's the technology side. What are you seeing from the business economic side of things? Well again, there's a lot of smart people and a lot of capital here in this conference that are focused on different segments of the market. People are building residential internet optimized fiber. There are people building fiber targeting the enterprise, etc. From from our perspective, the cost of putting fiber under the ground is the same for all of us properly done. So we don't want to serve one segment. We want to serve every segment. And I think that's where the economics will drive the activity. But it's also more complicated and requires more technology. So we're early in the evolution of the market, but I think the economics will drive toward multi-purpose infrastructure. Yes, it's insightful. And I know you're speaking on a panel. Can you tell us a little bit about that? Maybe give us a preview or a key takeaways that you want attendees to leave with? Sure. I'm quite frankly, I'm really appreciative of the chance to speak with this group. The panelists range from Utopia, which I give a lot of credit. They were early to the notion of open access internet to sci-fi and ubiquity, rock, etc. So it's a great group of experienced people. Each of us are doing things a little bit differently. Again, we are an infrastructure technology company, first and foremost. So I would say with no disrespect to anybody else's business model, we've just taken a different approach. So it's going to be an interesting discussion. There's some serious divergence of opinion among the group about how the future should unfold. So it should be a pretty fun panel. Good, good. I think we'll have to add that one to our agenda. Please come see us, 12 o'clock. Yes, 12 o'clock. Well, thank you so much for joining us. If our viewers want to go to learn more about underlying, where can they go to either connect with you or go to learn more? Very simple. It's underline.com. Easy to find. Well, keep an eye out for Bob and that panel and head to underline.com to know more. Thank you viewers for tuning in and thank you for joining me. My pleasure. Thank you, Allison. Until next time, happy networking.


Poland prepares to send South Korean shells to Ukraine. Mateusz Morawiecki, Prime Minister of Poland, plans to persuade the European Union partners that joint procurement of projectiles outside the borders of the EU is necessary since Ukraine already needs them, but Europe does not have enough of them. Morawiecki said it in an interview for RMF FM. It is not that big of a secret in Brussels that Europe has no shells. On the other hand, there are a few places in the world, specifically South Korea, where there are far more of these projectiles. So I hope that our discussions with the European Commission and with a few key countries, Germany and France, will lead to the rapid supply of projectiles because Ukraine needs them here and now. Morawiecki said. At the moment, France is against the procurement of ammunition outside the EU, insisting that profitable contracts must be signed by European companies. I will convince France that shells must be supplied very quickly. Since we do not have such shells here in Europe in sufficient quantities, we have to buy them externally, just like Poland buys ultra-modern armament K2, K9 and Abrams from abroad at the moment. Poland's PM remarked. At the same time, he admitted that the external suppliers agreement, for instance, that of South Korea is needed. This is where we should begin. We can only do it if the ones selling it allows export and permits the transfer of these projectiles. We are certainly a reliable partner, so we will only do it with permission. Morawiecki stressed.