 So, the first time I started working in an open source code was an application server called Trinidad, which was working with JRuby specifically in web applications. And, you know, up to that point in my career, I had really thought of engineering and programming as simply something I did as a profession. And simply something that I did to make money and sometimes impact the world. What happened when I was participating in the Trinidad project was we realized that one of our early adopters was Air France. And we were like, oh, shit. Because when somebody is worrying about scheduling airplanes and making the system run on time, you realize all of a sudden that you're impacting people's lives. And it led, and about two years ago, I actually had a personal experience that led into this. Two years ago, they found just over a dozen tumors in my lungs. And I had cancer and tumors through my head and my neck. And they told me that I had four to six months to live. So I went up to Huntsman, went all around the United States to different cancer research centers. And what's interesting is, out of the 16 places that I visited, two had an experimental drug that they wanted to try on me. One of them was out in Boston at Dana-Farber Cancer Institute. And it didn't work. And the other one was at Fred Hutch in Seattle. And one of the neat things about it was they'd actually used a database of chemical expressions that actually worked on top of expressions that happened inside of tumors to determine that there should be an experimental drug putting two drugs together in order to cause an expression and hopefully make an impact. And at the time, I had a prognosis of about two months to live when I started it. And 19 of us started this drug. And today, 10 of us are still alive. And so, when I think about, yeah, thank you. When I think about what the power the people in this room have, the power that each of us have, we have the opportunity to impact the world in a way we never thought possible. We stand on the verge of a brand new world in terms of healthcare, a brand new world in terms of energy. And it's dependent on all of our minds getting together. Not only that, he's not here, but I actually thanked him earlier. When I was originally diagnosed, I met Mike Moore for lunch. And Mike Moore, we were in a restaurant, we were just catching up. And I told him about my diagnosis. And he sat there with me at that lunch and cried with me. And he held me as a friend and just said, hey, man, I'm right here. Anything you need, I got you. And right there, you can see the expression of a community, a Ruby community, the mini swan community that gets together and says, hey, I got you, no matter what. The way that we build, the people we build with, the things that we build, we'll change the future and make it a future that we choose to live in. Thanks, everybody. I'm going to use this extra time. Who here still uses Rails 3? It's okay, you're probably going to be like, it's all right, it's all right. They're still alive, they're still out there. Heroku still supports it, so it's going to be there. So that's what we're doing here. And I don't need it in it, so I'm good. Can you guys see? Anyway, we have a huge monolithic app. And well, we have one main problem is that it's old, it's clunky, it takes a while to do everything. So even running like Rails generate, it takes a long time. So I'm just going to show you here really quick. If you do Rails G, but at the very end, we're going to add a time to it, so we can see how long it runs. I'm just going to let it run. It's pretty slow. And so that affects development, right? And so we want to build things fast and do things. And because it's Rails 3, we can't use Spring to reload our development environment. So you see all those warnings that's leftover, awesome technical debt. And it took about 10 seconds to run, right? And so we can't use Spring, so what do we use? This is awesome gem called Zeus, right? So it's awesome because it says right here, we support Rails 3. So we tried it, but this is one of those cases where it works on my machine and it didn't work on my coworkers. And it's like some magic voodoo of gems that need to happen, collaborating together for it to work. But eventually we figured out that you need some sort of, what is it? Let me see, my history. You need that object C, disable initialize fork safety equals yes, in order to work, just disable some parallelization that happens because this runs on top of a go instance. So when I hit start, oh no, oh Zeus is already running. My bad. See, it's rooming my room. Here we go. If I run this now, it's going to put the output to my log. You can see here, tail. It's like, oh, it's booting and everything. And then it says users fill something. It's like, when did fill create a user in my machine? That's really weird. It's just debugging sucks. But once that's open and running, let's see. If I do time, Zeus, g, what was the previous result, 10 seconds? So here we go, 0.55. We got it, all right? So even better, as you can see here in my super tiny screen. Jeez, this is super small. Anyway, you can't see it. But I can run Zeus off of my RubyMind server or IDE. And it had the configurations. In here, there's an object seed disabled initialized. That's the variable. And the cool thing now is that I can run it directly from here. The other thing, too, is that it generates two files, this JSON right here, and then this custom plan file, which you can use to do a lot of cool stuff. On the documentation, it says, yeah, just init it. There you go, there's your two files. And so here you can see on the left, there's what's actually going to be running. Can you guys see that? Is that good enough? All right. So I took some of them out because I don't need to run a Rails server on Zeus because it turns out that it doesn't really kill database connections cleanly. So I was like, OK, I'm OK dealing with that manually. And there's a custom plan right here. So another quirk that we have, we're running our spec very limited test suite. We want to switch to many tests for speed. And well, it turns out that we ended up having to run both at the same time. And Zeus also runs by default. If you have our spec, it will automatically grab it. There's no way for you to configure it to say, can I use minispec, please? No. You have to overwrite some methods here. As you can see, this is all for the test environment. It loads up the test environment. There's an equivalent on the left side, and then the test helper, and then the actual test. And then it has its own metal runner. Have you guys heard of metal? It's like you can run a single test using many tests instead of a nice little synthetic sugar. So anyway, I'm going to run this really quick. Tricky thing is, when I was running this and Zeus spun up and I was trying to run my test, there was no many tests. I'm like, what's going on? So thanks to your Ruby mind, I was able to go into the source code and then go here. Oh, OK, I can see what's going on. I'm going to go to the metal runner. Why didn't you not execute in my test? And as you can see, I'm highlighting here. It's like, hey, execute. When you're running minute test five or minute test old, what are you going to do? Nothing. Thank you. It's like, replace my arguments. No problem. Let's get out. OK. So we had to do a little monkey patching and actually say, hey, can you please run? Anyway, that way we were able to have both tests running together. So Zeus, T, and then we have run that, please. And then the bottom, Zeus, RSpec. And we have both tests running together. Yay. And that's it. I will let you see the results of the RSpec. It takes a while. If you want to know what happened, just let me know. Just to find me. Brandon kind of made me feel weird about talking about joy right now. But that's when you think about it, it's actually what he was talking about actually is a really joyful thing. But I'm going to talk about something else that I've been thinking a lot about lately. Being open and joyful about learning things and not doing stuff that I've been guilty of, which is to present a facade that I am an expert in something or that I know a lot about stuff and not really exposed particularly to juniors but also my own colleagues and peers that there is a learning process and we're all still learning. And you can be open and joyful about the fact that we're all continuously learning. So yay, we're all learning. Doesn't matter if you're a junior or you've been doing this forever, or you're Jeremy Evans, who every time I've seen him talk, I'm just like, oh man, that guy is so smart. But he wrote the rack on Reloader because he found out that a thing wasn't working the way he wanted it to work. So he went and started poking around and found out. And we don't get to see all that, but that happens for Jeremy Evans, that happens for everyone. So we should be actually trying to do whatever we can to enable that learning amongst ourselves. And part of why we're not open and joyful is because we have these behaviors that hinder being open and joyful about our learning. RecurCenter is not a bootcamp, but it's a place that you can kind of go and learn some stuff. But they've got these social rules, no feigning surprise. So you're never allowed inside the RecurCenter to be like, oh, you didn't know that? Oh, like this is like, how could you not know that 2I converts the integer? Like I just barely heard Ruby was a thing. How would I know about 2I? Like that's a silly example, but that's what I'm talking about. Everything might seem silly to someone that's been doing that, but you didn't know that at some point. And finding that out can be awesome, it can be super fun, but everyone's got to kind of hide that and they got to hide away and learn in secret so that they can present this perfect employable facade. And if you, this is going to kind of get into diversity because that's where inclusivity leads is diversity. So let me just continue with these no well actuallys. So that's another thing that I'm really bad at. So I'll over here, some people discussing something and working back. Well, actually, let me interject with how smart I am. I know this thing and I didn't know it when I learned it. Like there's still working things through and I can contribute to that conversation. But the well actually is me contributing not assistance and not guidance. It's me being like, I'm so smart. That's me, like that's what a well actually is. It's not helpful. It's anti-learning, no backseat driving. It's kind of similar to the well actually. That's like, I'm over here coding and I hear some people talking and I'm like, well, that's not how it goes. But I'm not going to go join them and work with them. I'm not going to go like contribute to that. I'm just going to like sort of hang out over here and be like, oh, no, I don't know. So no backseat driving. Just be thoughtful. Experiences differ. This is a good thing. We should embrace that diversity. Play with things, experiment, explore and share those experiences of the act of learning in a joyful way. Share those discoveries instead of just presenting as an expert on something. I gave a talk last night at drug, the downtown Ruby Meetup on command line apps. I've written a handful of them for little scripts, but I'm not some expert, but I kind of felt the need to sort of present from a place of knowledge, because that's what I was doing, but we can share that this is stuff we're still learning. I didn't know everything about options parser last night and I was open about that and it led to conversations and a bunch of people got interested and so this sort of thing's like, it's not hard to actually expose that you are still on this journey because we just need to get used to the idea that all of us are. All of us are continuously learning. Jeremy Evans is way ahead of me, but I'm catching up. Julia Evans is a perfect example of this. She's got a blog, jvns.ca. This is a comment about some of her stuff. She brings so much enthusiasm about learning technology that she makes me see familiar things that are new. This is from an agri-news commenter. Who is experienced? Who is knowledgeable? But Julia just kind of crushes that joyful learning and discovery. Bring joy. This is Julia Evans. Thank you. Can you see my screen? It's probably way tiny or something. Going to work on that then. So this is actually also from a talk that I gave at a couple of meetups over the last six months. It is about visualizing encryption using bitmap images. Essentially, let me actually just pull that code up really fast. I don't think you need to see the terminals, so too tiny for you. CD image, encryptor. I'll just pull that code up and make it big. Okay, so essentially, I'm reading in a file name. I'm taking that file name. I'm reading in the file and turning it into bytes. And then I take the first 54 bytes off because that's the headers. Every bitmap, the first 54 bytes say, this is how you read this image. This is where it wraps. This is how high, how many pixels wide, how many pixels high it is, et cetera. What the color space that it's in. So you don't really need to know that. Just I'm removing the 54 bytes. And then the rest of it is the data that is actually the image. So then I create a very simple image encryptor in this, all I do is take in a secret, like the key and the data and I sort. Then I come down here and I just actually utilize actual encryption that we would use with SSL or Ruby session usually uses AES 256 CBC for its encryption method. So largely ignore the code here. All you really need to see is I'm creating a simple encryption, which is pretty much what encryption looked like 20 years ago. And then I'm creating ECB, which is still used for SSL in Microsoft Internet Explorer, like up to seven. And because of that, a lot of SSL still is actually using that. Not very secure. Then we have CBC and CTR. I am just going to go back to a terminal and open up this folder. This is all actually on GitHub. So you could pull that up. I'll show you that in a second if I have time. But let's just look at the original image. So right here we have, here's our original bitmap. As you can tell, it looks like Superman. If I were to look at my simple one that I encrypted, as you can tell, you can actually still make out the image, but it definitely looks different. If that was a bunch of fine texts, you probably wouldn't be able to make anything out. If you were to look at the ECB example, which as I said is still used by like a lot of encryption out there, you'll see this also isn't very secure. If this was actually an ASCII file or something, it would probably be a lot harder for you to see that pattern, but a machine learning algorithm could probably find that about as easy as you could look at this and see it, because our brains are optimized for image recognition, not like other kinds of decryption. If we were to click on the CBC one, which is what Rails, at least back with Rails 4, was using for session encryption, you'll see that this is actually a lot better masked. In fact, I don't think you could see the pattern in it. Same with CTR, which is very similar, but multi-threaded, so it's a little bit faster to encrypt and decrypt. And then here's a GCM one that Matt had metered the other day. It looks about the same as well. So let me actually just show you the code for that in case you want to play around with that. github.com slash lrs slash imageencrypter. So let me just make that bigger. So if you are interested in this, that would just be lrs slash imageencrypter at github.com and that has a code that you could play around with different image encryptions or multiple other bitmaps if you wanted to do that and just kind of play around with that. Anyway, thanks for listening to me and have a great Rubyhack. So when I put the title of this up originally, I put it up as Ruby from an ops perspective, but actually in second after thinking about it, it's not really the right title. It's probably more like ops using Ruby or Ruby as used by ops. As an opsist, we have to write a lot of utilities, scripts, tools, jobs of various types. And over the years, the languages and the tools we've used to do those have evolved. The most part, at the very beginning, shell scripts, command-mines, little sharp tools that were always there, it's the way to do things. And that was kind of one of the only ways to do things. You could write some C or a few other types of things, but it was primarily these scripts. And they over time became unwieldy, they became big, they became kind of ugly, hard to maintain, and they got really frustrating and led to lots of bugs and lots of other problems. Perl came to the rescue. And it saved the lives of many systems administrator in the Linux administration world and in other operating systems. It had all kinds of super rich kind of modules to do just about anything. It was like magic, it was cases where you would go to write what could be a simple shell script, maybe five or six lines, you do it in Perl anyways, because it was just that much more powerful. It gave you opportunities that if later on you wanted to add some additional functionality, super easy, super expandable. It was awesome. Over time, it kind of got ugly issues with installing modules via RPMs versus installing modules with C-Pan. You ended up in dependency hell. It got super, super ugly and anybody who's lived through that, I sympathize because it is ugly. They also kind of muck with the language a little bit, confuse things, and it slowly kind of started to fizzle. Ruby came to the rescue after that. So many tools came out 10 years ago or so that used Ruby for the building of some big system administrator tools. Things like formin, puppet, fluent D. All these things were necessary to run a server in a more contemporary way. We're all done in Ruby. So we decided, a lot of us decided to jump on that and learn it and mine the value that it provided. What did we gain from this? We learned a new language. Always good to have an extra arrow in the query. One more thing. Perl always had this idea of there's more than one way to do it. Now we up that and say we can do it a bunch of different ways in Perl and we can do it a bunch of different ways in Ruby. Gave us a huge amount of options depending on the exact situation, the exact server, all those cases. There was some weird interesting side effects to this. Us people using Ruby and developers using Ruby, now all of a sudden we had an interesting common language. We were able to help devs if they ran into problems and they were able to help me if I ran into problems. This was kind of mind blowing to me at the time. I got a new appreciation for what Rubyists and Ruby developers were going through. I think they got a better appreciation of what we were going through. We were able to support each other in all kinds of new ways. It was a brand new era of collaboration between two groups that had traditionally been very, very separate, in some ways very antagonistic. Now, because of this language, things definitely got better. I think there's even an argument that you could make to say that Ruby itself was one of the primary elements that allowed the DevOps world to evolve. I don't know if it would have been the same had Ruby not come into the picture and had not this collaboration started. So I wanna take this opportunity to thank the Ruby community for building such wonderful stuff and being so open to ops people. So thank you. It got ugly again. It got ugly again. Version changes, multiple versions of Ruby, all kinds of that stuff. It got ugly again. Containers to the rescue. I can continue to write Ruby code in containers. Doesn't matter what version, doesn't matter what gems, isolated processes. Wonderful. I look forward to continue to using Ruby in the future as long as it's easy and future rich. Thank you. Thank you. Thank you. Hey folks, my name is Mike Nadel. I am with Drip. We are based in Minneapolis, but we just opened an office here. And I wanted to tell you about what we do. We are an e-commerce marketing automation company. So we have about 5,000 customers and they use Drip to ingest data about their customers. They build automations around that and they use that to engage with their customers in a personalized and meaningful way. We are a Ruby-centric polyglot dev shop. We've got about 20 developers on our team and about 120 overall in the company. We are hosted 100% in AWS. We use AWS services including Lambda, Dynamo, Kinesis. We run on EC2 as well. We have Redis and PostgreSQL. We value pair programming. Some of our teams do it exclusively, other teams do it when they feel it adds value and we let our teams figure out that for themselves. We are a transparent, flat, collaborative culture. We value TDD. We have about, well, our build will break if you drop below the current test coverage of 92%. So we're always trying to push that up. We are heavy sidekick users that drives a lot of our concurrency and our volume. We do about 400 million jobs a day through sidekick. Our database is about 10 terabytes. Operating at that scale introduces some really interesting challenges. It's really fun. We're agile but not particularly dogmatic about it. We deploy to production upwards of 10 times a day and we're hiring. So I'll be at the meet and greet. I would love to talk to you about drip, about technology. I'm also passionate about espresso. Talk about that and I'll be around. How much time do I have to fill? Three more minutes. Shit. Oh man. Any questions? We have three employees in Salt Lake. Two of them are our chief marketing officer and our chief technology officer. They commute part-time to Minneapolis. We have a full-time employee and we also have another full-time employee starting here in about two months. So you deploy a lot. Do you practice U-Bank or U-Bank? We don't actually. So that last step is manual, in part because we haven't found a, well, we haven't yet automated active migration, or excuse me, Rails migrations yet, but that's the final piece and then we can turn on that. Murray can fix that. Yes. We're hiring SREs, or DevOps people as well, so. Any other questions, please? Yes. I may have missed it. What do you guys do? We are a e-commerce marketing automation company. So, I would love to give you a demo, but I was afraid that it would take too much time. Okay, so. I might, man. So, what we do is we ingest data from our customers. They will send us page views, they'll send us their Shopify catalog, their Shopify orders, things like that, and then our customers could go in and segment their users based on that so they could say, show me everyone that purchased something within the last 30 days, but didn't click on an email that I sent them to update them about some information. We could target them for communication. We could build rules and automations around that as well and we allow our customers effectively to build these workflows and rules based on what's happening on their commerce side. Yes. All right. Do you guys have any better shit to pop up? We do not. Ah, nope. Anyone else? Sop up? I'm not sure. 12 seconds, that's right. So, what's up? Tell a joke. Oh no. Um, where does, oh, come find me tonight and I'll tell you the joke and the punchline. I knew that was gonna happen. Thank you.