 As per tradition, if you are on this list, and rather than giving a 5 minute talk, you would like to give a 1 minute talk without slides, you may do so right now, independent of where you are on the list. So do I have any takers? Perhaps Michael Hartle. Snikeys, I will start after this. Good evening everyone. I'm Michael Hartle from the Ruby on Rails tutorial. And the Rails tutorial software is dual license under the MIT license and the Beerware license. The Beerware license says, you know, hey, if you like the software, maybe buy me a beer someday. So I'm holding the sixth semiannual Rails tutorial of Beerware night tonight at DBA on Frenchman Street, starting at 6.30, running to 8.30. If you're interested in coming, you can go to twitter.com slash Rails tutorial. The pinned tweet has an event right. You can RSVP or not, or just show up. And come on out, get the information for where we're going, Frenchman Street is a great place. I think it's going to be a great time. Hope to see some of you there. Do I have any other takers? For one, yes, please come up, man in the denim pants, I think I'm avoiding names now. You like that? Where are you on the list? Okay, very good. Hi, my name is Jonathan Slate. Have you taken in some of the beautiful city of New Orleans and all it has to offer? I love this town with great people, music, food, architecture. It's almost overwhelming. It's hard not to notice, though, that some people here are struggling. I've seen people sleeping in doorways, people asking for a couple of dollars, people who need a hand. Matt says Ruby is nice, so we are nice. Let's prove it. Every year we swoop into a city, learn about Ruby, take in the local culture, and swoop out again. I did some research and ended up calling the Greater New Orleans Foundation a guide star gold-rated charity that would love our support. They recommended two funds, the New Orleans Works Fund that focuses on employment and second chance, which helps people just getting out of the criminal justice system. I set up a little page with instructions, so if you're interested in making a donation, it's tinyurl.com slash nolaruby2017, that's tinyurl.com slash n-o-l-a-r-u-b-y-2-0-1-7. I'll tweet that out with the ruby.com hashtag as well. Thank you. A splendid idea. Any other takers? Any other? Yes. Very tall man in the blue pants. How long can I keep that up? Hi, I'm Kyle Heronimus. I'm here to talk about GBDD, get blame driven development. I use it all the time. I think it's very underused. I think mostly because people are kind of, they don't really like blame. You're not supposed to blame people at all, and that's an unfortunate naming. But I don't think that it's blaming, but think of it more as getting context before you go in and break something. There's a quote by Santayana, those who cannot blame the past or can then repeat it. So what can you learn from get blame? Well, of course, we know you can learn who, but you can also learn what, where, and when, and why. So of course, you can remember know who committed it. Is this an expert? Was this a newbie? Is this a cowboy coder? What will impact how you react with the code? What? What is the commit message? What was going on at this time? When? When was this committed? Was it committed yesterday? Or was it committed a year ago? Again, those would affect how you would deal with the code. Where? Where are the other changes that got committed with this? Were there a thousand other lines as part of this commit, or was this just a single line commit? And why? What was the issue that prompted this in the first place? So with summary, one more quote from GK Chesterton said, don't take a fence down unless you can blame whoever put it up. Thank you. Thank you. Last call on the one minute talks, going once, going twice. And gone. Okay. So our first speaker who is not using slides, which is totally fine, is Yechil and on deck is Heethur. So she's getting set up and I will give you the floor. My name is Yechil and before I was a programmer, I was a rabbi and a teacher and as such I spent a lot of my time learning Talmud. And Talmud is actually very interesting in that it just, there's like tons of things to learn there, relevant to like all kinds of areas. And I actually took, every once in a while I find a gem in there that just applies to programmers. So this really should be developed into a bigger talk but I'll share one of them. There's a story about a famous Talmudic sage, his name was Rabbi Akiva and he was once talking to a Roman minister and their own minister told them, you know, why are you Jews, you're always advocating charity and helping the poor. If God made them poor, shouldn't they, shouldn't we just leave them at that and say, obviously that's how God intended the world to be. There's poor people. Leave them there. And he told them, no, God created poor people but it's our job to perfect the world, to make the world a better place and to help these people out. What this Roman minister was committing was a famous fallacy known as the just world fallacy where people believe that, you know, people who are poor are poor because they deserve to be poor because they're lazy, whatever it is. And of course we know like that's not the way the world runs. When we see suffering we should try to help out and that's good for a political speech but what does it have to do with programming? I'd like to share a quote from Steve Klabnick. Programming is a movement from a broken state to a working state. That means you spend the majority of your time with things being broken. How if it worked you'd be done programming. As programmers you know that basically all of our work is with broken code. Code that works doesn't need programmers to work on it. You know what I'm saying? I've spent some time coaching at Flatiron and one of the biggest switches I've seen by students like when sort of what turned them from lay people to programmers was when they got this switch that they're not scared of error messages anymore. When they realize that error messages are what actually helps them, you know, there were a lot of talks over the past two days about errors and, you know, failure. So this switch where when you see something broken and you don't think of it as oh my god I just failed what I do, you see as an opportunity to grow, I think that's what makes us programmers and we can take that into the world and just make the world a much better place too. Thank you. Shes show of hands. How many people out there have a dog or a cat or know someone who has a dog or a cat or are vaguely interested in dogs, cats or medicine? What about our dogs or cats? That were two. So if your hand was never raised you're going to be bored and I'm really sorry. My first career was out of a veterinarian and this talk is going to have nothing to do with computers whatsoever. It's going to have to do with things that your dog or cat might eat and how bad it could be. And this is my dog up here. He is very sophisticated as you can see. He sits like that all the time. So cats, things that cats might eat or get into, one of them is topical spot on insecticides so like the flea and tick treatments. If you can buy it at a grocery store or if it's made for a dog and specifically says don't put this on a cat, don't put it on your cat because it can cause seizures. Really if your cat has a problem with fleas go to your veterinarian and get something prescribed by them because the over the counter stuff can be bad. If you're into like Halloween decorations or raves, glow sticks can cause your cat to like foam at the mouth and it looks really bad and it might make them vomit so don't let them chew glow sticks. Lilies is one of a lot of people don't know about. Not all lilies are toxic but the ones that are can cause acute kidney failure and can kill your cat and that's eating belief, the flower, any part of the plant so if you have cats maybe don't have lilies. Canny freeze is also another really bad one. It can cause kidney failure in cats. The bad thing is it tastes good and they've done petitions to put something in there that makes it taste bad and all those petitions fail and even the tiniest amount can be toxic so if you have some in your garage and your cat has access to that or your car is leaking, whatever, don't let your cat drink Canny Freeze. Mouse and rat poison works because it's tasty and so if the mouse or rat is willing to eat it the cat might be willing to eat it too or the cat might eat the mouse or the rat that ate the poison and depending on the type it can cause you their difficulties, clotting blood or neurological issues or a bunch of other things so again if you have poison in your house maybe don't let your cats have access to it. The last one is medication with Tylenol in it and this cat actually ingested Tylenol that's why it's faces all poofy and its lips are kind of blue. Cats lack the enzyme to metabolize Tylenol so if your cat is ever hurt or injured or seems sore don't give it Tylenol. This next slide has kind of a gross picture but I am a vet so I think it's funny. So again mouse or rat poison, same reason in cats it's bad for dogs, same with Canny Freeze. Dogs can tolerate a larger dose of Canny Freeze without dying but it's still bad. Raisin Nuts, so when I put this up here who thinks that I'm talking about the chocolate? Who thinks I'm talking about the raisins? The raisin people are kind of more right. Chocolate is toxic to dogs but not nearly as bad as we think it is. If you're like half a pound teacup whatever little kick me dog eats like a giant bar of 80% delicious chocolate that might be a problem but like if you're 85 pound mastiff eats a Hershey's kiss he's going to live. Grapes and raisins on the other hand one or two grapes or raisins can cause kidney failure and death in dogs. We don't know why. It doesn't affect all dogs but grapes and raisins are very, very toxic to dogs. Non-steroidal anti-inflammatories, if your vet prescribes something like chewable rimadil the dogs eat it because it tastes good and so there's a chance that they might tear into the bottle and eat the whole bottle's worth. Don't let them do it. Put it where they can't get it. Xylitol is not really new anymore. It's a sugar substitute that people find in like sugar-free gum and stuff like that. The Ketch, they're putting it in some peanut butters now which I think is just hateful. So if you give your dog peanut butter and like a Kong or whatever make sure that it doesn't have xylitol in it. So if your animal gets into something what should you do? Well first of all make sure that pets and kids aren't in that area anymore. Is your pet safe? Breathing and acting normally. If so, don't give him any home antidotes. People give like weird things. Like they'll give salt because it makes the dog vomit but it makes the dog vomit because too much salt is toxic so don't do that. Don't induce vomiting yet. Call the pet poison helpline. These folks are awesome. I know a lot of people who work there and they are very, very helpful. If your animal is crashing so not breathing, not acting normally, call your vet or emergency clinic immediately. Probably have if you have a dog some hydrogen peroxide at home because a tablespoon of that and some dogs will make them vomit. Do not give it to a cat because it just causes really bad stomach inflammation. So I want to thank, like I said, pet poison helpline. Take a picture of the slide. If you ever need them, you can call that number. They will charge you a whopping $59 but it's through the duration of the poison. So if there are complications, they will continue to help you. And all of these little fur demons are my pets and I thank them too because they make my life good. Thank you. Thank you. Next up is Briar Underwood. Like the Briar Rabbit I assume, something like that. You're on deck. Oh, by the way, for speakers, there's your time is in the middle here. So if you go over time, you'll hear an annoying beep that I will send through my phone. Avoid that. Don't go over time. Gem and the holograms, go for it. All right, good evening, everyone. How's your RubyConf going? Woo! Mine has also been amazing. My name is Jen Pengali. I'm a web developer and I hail from Washington, DC. I work at a great company called Accela Consulting. You can find me on Twitter at Jen Pengali. So I have a few questions to start us off. First, who likes Ruby? Who likes hanging out with other Rubyists? Helping people and making the world a better place. Yes, I got a few naysayers, that's fine. For the rest of you, I'm here to invite you to Ruby for Good. Ruby for Good is an event held in the spring near Washington, DC. We help organizations that really, really need people with our skillset, but can't necessarily afford them or don't have access. Some of the organizations in the past, we've helped our animal shelters, diaper banks, food banks, red pandas, and many more other organizations, including the New Orleans Habitat for Humanity. Our mission is to help nonprofits and civic organizations grow our awesome community and to learn. There's a big emphasis on learning at Ruby for Good. We pair program, there's mentorship, there is experimentation, and we continue to work on the projects that we launch at this event throughout the year, taking on new issues and maintaining that community through code reviews and pull requests and all the things that come with open source projects. It's an inclusive event. That means that registration covers your meals, your lodging, and everything else, but it's also a very inclusive environment, very friendly, and we're very proud of that. While there is a lot of work to be done launching these projects, we have a hard stop every day at dinner time, and then we really nerd out. We play board games, we play werewolf, those are the werewolves. Some of you are on this picture. Sing karaoke and have lots of other fun in the evening. Here are some of my best friends from last year's Ruby for Good, and here are some more best friends from this year's Ruby for Good. And if you've been to Ruby for Good, please raise your hand. Yeah. Look at those people, those are friends. Talk to those people. If you saw a hand go up near you, make friends, and then come hang out with us. This is the Ruby for Good logo. It's the world that is full of love because it's embracing Ruby, which is super cute. I encourage you to check out the website, rubyforgood.org. Follow us on Twitter at rubyforgood, or check us out on GitHub. We have active open issues right now so you can get right into it. We'd love you to come. If you work for an organization who would like to sponsor an event like this, let us know. Craig, you're out there, raise your hand. Over there, Craig. He has stickers, I have stickers. Come get stickers. Come talk to us about Ruby for Good and we hope you join us. Thank you. Briar Underwood, go for it. So I just want to say that my name is Brian, not Briar. And I was skeptical when he said that he promised to mispronounce our name, so. Hey, my name is Brian Underwood. I am the maintainer of the Neo4j gem for Ruby. So I want to introduce that to you. So I want to get some terms out of the way first. So charts, I'll just read this for anybody who can't see it. He's saying, this is a pie chart describing my favorite bars and this is a bar graph describing my favorite pies. For the purposes of this conversation, let's just call these charts. And this is what we'll call graphs. It's a mathematical term from graph theory and these are, you have vertices and edges or you have nodes and relationships. So that's what we're talking about. So Neo4j is a graph database and that means that instead of storing tables and rows and columns, you're going to be storing nodes and edges and sorry, nodes and relationships. And so nodes, and nodes and relationships have properties in the graph database. So like name and title and date. And then nodes can also have labels to describe them. So like person or author or book and relationships have types like wrote or purchased. And that's how you model your data. So why Neo4j, why is this awesome? Well, one reason, it's very graph, or sorry, it's very whiteboard friendly. So you write down things on a whiteboard in very much the same way. You write circles and lines and the relationships between them. So you generally take that right from your whiteboard and put it right into your graph. There's no particular schema. You just start putting things in there. You would use Neo4j because you have deep or complex relationships that you need to explore and you need to do that in a fast way and in a way where you want to write queries that are sort of easy to understand and work with. This is an example of looking for, this is example of like a fraud ring of different people who are using the same identity information. Neo4j was recently used to expose the rich and powerful and their connections to offshore accounts. You may have heard of the Panama Papers and recently the Paradise Papers. That was using Neo4j. And you might have just even more straightforward things. Like if you have access control with people and roles and resources, you might want to make queries that are efficient and the queries might be complicated but you want to be able to understand them effectively and have them run fast. So it can be used for even really basic things that any database can be used for that you just want to have a nice interface for. So yeah, yeah, Neo4j, let's talk about Ruby. Or sorry, this is, I haven't gotten to Ruby yet. So how do you use Neo4j? One of the ways you use Neo4j is you use the Cypher query language which is inspired by SQL. It looks a lot like SQL but it's designed for graph databases. So you can create a person, you can create a language and then you can create a relationship between those two things. And you can see here on the right is the UI that comes with the Neo4j database. And it's kind of like, I like it because it's like looking at your data under a microscope. So yeah, Ruby. You can create an adapter and a session for Neo4j and then make queries with Cypher. That's fine and all, but not very exciting. We want, we're Rubyist, we want higher level concepts so where are the models? So with models you can have like a person model and a language model, they can have properties and they can have associations just like you can have an active record. But then the cool thing that you can have with associations in Neo4j is that if I said for a person, if I went and found their liked languages, I can give that a variable in the Cypher query, the language variable. I can find all the like languages for a person and find all of the other fans of those languages. And then I limit that by a person that I'm looking for specifically, then I can find all of the common languages between those two people. And that's all one query that happens to the database. Even better, if I wanted to say I had a person and I wanted to find all their like languages and then I wanted to find all the fans of those languages and then I wanted to find all of the like languages of those fans, then I might be able to create a basic recommendation engine where I want to find languages that other people like, that I might like and so you can sort by that. And again, that's all one query that's being made to traverse those associations. So it's really nice and natural to work with. So Neo4j, if you want more information, you can find me. Here's my information. Here's the website information for the gem. It's been around for a while. We try to get good documentation and we try to help people when they come along. So feel free, I also have stickers. So find me. Oh, I forgot. Up next is A-A-A-R-O-N, A-A-R-O-N? I'm not gonna get it. I'm not gonna get it. Do we want to still try the other one or should we just have them wait or? I think it's only with the new MacBooks is the problem. Yeah, that's gonna be everybody. Yeah. Right, should we? Okay, we'll give it a shot. Why don't you go on over and we got another five minutes to see if we can debug it, so. Who are you again? Cameroon, of course. How could I forget? Cameroon. At least you didn't call me Cameroon, which is more than I can say for my little cousins. I can do better. Hi, my name is Cameron. Thanks for coming to RubyConf, this is awesome. This is my second time at RubyConf. Been to Rails a couple more times. I work for Lumos Labs on the platform team, which means we do a lot of infrastructure stuff and a lot of that boils down to performance too. So my talk today is gonna be installing 440 gems in 40 seconds, and it can be faster depending on your internet connection. So raise your hand if you run a Ruby app with Docker. Nice, me too. Docker's awesome, but having to build a Docker image every time you wanna deploy can sometimes be a drag. And why is that? Well, let's look at the steps that most apps go through. One installs stuff that your operating system handles for you or that your operating system's package manager handles for you, app get install, you copy the app into the container, and then you have to bundle install. So these are numbers that I have to admit I kind of made up, but they seem right. So app get install maybe takes 5% of the time that your whole bundle, or your whole container takes to build, copy 1%, but then bundle install takes the rest of it. So why is bundle install so slow? Well, normally for things like this. And that's that native extensions thing that is the real problem. So I've discovered that, you know, whenever we do a bundle install, even with dash dash jobs three, so it parallelizes the builds or the installs, it still takes a really long time. For our main repository called Lumos Rails, it runs in about six minutes and seven seconds. That's all the time, that's all time spent bundling. And we have a disgusting number of dependencies, but I assume that a lot of people are in our pursues as well, so. We could potentially reduce the number of dependencies, but for the moment we're stuck with that. That's wall time. That's about 46 hours a day, 450 jobs. And by jobs I mean a single Travis worker, so not a full build. But that's for, so that's 46 hours of CPU time which boils down to about three hours if you break that down by build, also wall time. So I wrote this thing called pre-bundler that's supposed to address this problem. What it does is it looks at your gem file.lock, installs each gem individually, and then tarballs up that gem's installed files which includes native extensions that have already been built. And then the second time you run it, it tries to suck down all the gems in parallel from S3 or wherever you're storing these things. It untars them straight into the file system where they were before, and then it runs a bundle check and if something went wrong, it'll run bundle install, so it just falls back to that. So what's the speedup? Well, for our repository, it used to take six minutes and seven seconds, now it takes 43 seconds. It's still the same 445 dependencies. So we've gotten it down to about 5.4 CPU hours for those same 450 jobs. It's about 36 minutes for those 30 builds, which leads to an 88% speed increase. So you can check this thing out. I have to say though, it's not really ready. Don't get distracted, don't get distracted. Don't get distracted. What is happening here? Don't get distracted. So does it work? It works locally for me. It works on our Travis builds. It's not something we're using in production yet. That's why I need your help. Needs documentation, needs testing with other large projects with similarly disgusting numbers of gems. So please, if you have some time, help me out with that. You can give it a try and I will have these slides up. So you don't have to take photos of this. Basically you need to set up a couple of things in your Docker file to provide access to S3, or you can also set it up with Google Cloud Storage or whatever else you have. And then there needs to be instead of a bundle install. It's a pre-bundle install. Note that this doesn't actually work yet because pre-bundler hasn't been actually published. So you could build this thing and install it yourself. And then you'll add some configurations. It basically just says what is the backend? Where do I store these things? And then it's just a simple matter of Docker build passing in the S3 access key in secret. And that will install everything in parallel. The first time of course, super slow because it has to build everything and upload it to S3. Once that's done though, the second build is much, much faster. And that's it. This is the URL. You can grab the slides. Thanks a lot. I think I distracted. What do you think? No, no. Pro. Super pro. Cameroon, that guy. What a pro. Next on deck is S-tar, which is ironically my favorite kind of tar. I have all the Tars. You got GNU tar. You got BSD tar. You got S-tar. Definitely my favorite tar is S-tar. Okay, so my talk is called Reading Between the Lines. I just got out of OSHAG Hennessey's office. My name is actually Aaron, but I'm sure you've all seen that skit. And this is about making Ruby informationally dense. Ruby's a very expressive, self-documenting language, so you can make it even more, well, documentingly, by writing your code in certain ways that doesn't change any functionality, but changes it for you, the user. Someone said you should put quotes up so that you look like you're smart, and I want that as well. So basically everyone at RubyConf has said that we're dying. So we need to use our time effectively, and let's maximize that. And it really depends on not just ourselves, but our three selves. There's our future self, our past self, and our current self who's in charge right now. So past Aaron writes the code that's easier and faster for future Aaron to read and understand. And present Aaron's the guy who has to make sure that this keeps happening. There's one major caveat. The things I'm going to show you are not necessarily the best things for you or your team. Only you will know that. Your mileage definitely will vary on these. So let's just get straight to the examples. The code on the left is how you would basically write any class in Ruby that has a simple reader for the variable you pass in. Whereas the one on the right has the adder reader as a private method. The one thing that the one on the right clearly indicates is that that adder reader is not intended to be used outside of this class. So you don't have to worry about modifying it or maybe changing the setter or getter when you're editing this code. Here's a message of a string that got cut off. And with double quotes, you should probably use single quotes because even if you don't care about what's in the string, the single quotes indicate that there's no interpolation going to happen. So you don't really need to worry about what's going on at the end of the string. An even better option though is to just throw it in a constant. When you're programming, it's the purpose of the string that's more important than its actual contents. Ruby has some additional syntax things that you can use that make things very much easier to read. In this, we're seeing if all the dogs are good. You can just check if they are all good by using the ampersand with a symbol which we'll call to proc on it. They're equivalent, but it makes it clear that you're not doing anything else in that block. Here's a more complicated method that is designed to be flexible in that you can call it with one or many of the objects that you're looking at. This actually came up in a pull request the other day. It's supposed to be flexible so that it can modify the items to hold either an array of the single item or all of the items and then iterate through them. Here's how I would normally have written this which actually came up and I should have left a comment because this doesn't do what you think it will do if you pass in a hash. So sometimes just leaving comments is really in your best interest for coming back to this code and working on it later. Here's a method that has a bunch of nested ifs. It's probably easier for you to read later if it was in guard clauses because if you want to know what cases this method would return early, they're right there at the top and then all of the stuff that you're actually doing can be moved out a couple levels of indentation. Here's one that's kind of controversial. You can use parentheses selectively in Ruby. Sometimes you can use them to indicate things. One thing that my team actually does not do because we've just agreed it's not in our best interest is leaving off the parentheses of a final function call if you're trying to indicate that the return value of it doesn't actually matter. This one could be a copy pasta error. It's hard to tell because I don't think twice before I put it's all right. This way I know it's actually not an error because it's very clear that I intended to do it twice. There are tools that can help you with this. One of the best ones out there is RuboCop. I have nothing to do with them except I really like it and I run it through guard all the time. Thanks very much for listening to me run through this because I wasted all my time screwing around with my computer. I'm Aaron Rosenberg. I can be found on Twitter and GitHub at the same name. That's my email. The art is courtesy of Rachel Lange and I work at Splitwise and we're hiring. Check, check. Okay, next up is Margo, like the movie. Like it's Margo, it's Margo movie that I'm going to later on. I know I need to work on it during the five minutes. It's really the, I remind myself that every single time and sometimes it happens and sometimes it doesn't. And now on to my favorite tar. Hi, good evening, everyone. My name is Star, like Ringo, aka Evan's favorite tar. I work for Excelic Consulting and today I want to talk about one of the commonalities between karaoke and programming because, I mean, I'm going to try anyway. And then at the end, I'm going to give you some super important advice for each of those things and we'll start by talking about programming. So who here works on a development team as in you work with code, whether people have written in vice versa. Yeah, okay, so the majority of you. So I think you can agree that when you are writing code on a development team, it's not necessarily about what makes you happy as a programmer or what makes things easiest for you only. It's about people who are not, all these like non-you people that you have to take into consideration. And I know it's really difficult to think about working with all these non-you people, but there was a really lovely talk yesterday that Megan T. you did about the beauty in the mundane parts of programming and how we do them because it makes your code better not only for yourself to work with, but it's easier for your coworkers to be working with as well. If you want to do things for you, which you should always do things for you. You can work on things like solo side projects. You can be really sloppy about it, like write terrible tests and not document anything and pretend solid doesn't exist. But you can also do really cool things that maybe you don't have the flexibility to do with an entire team, like use cutting edge tools that maybe your team can't commit to or invest to learning right now. You do whatever makes you happy as a programmer. For most of us, programming doesn't really look like this where we get to hang out in our lair and write for our eyes only code. Usually it looks more like this where you're working with people, trying to communicate to them how they can make your job easier and also vice versa. So now I get to talk about karaoke, which I love so much, thank you, engineer. It's my favorite thing in the world and when I tell people this, they always ask me, what's your go-to karaoke song? My answer is always whatever song is gonna get people the most excited. I don't think karaoke is about personal enjoyment because you can sing by yourself your favorite songs whenever you want. That's why they invented showers and cars. Karaoke is more about all these non-you people who are in the room with you, whether it's strangers in a bar or your closest friends in like a privately booked suite. So it doesn't really matter that I'm really amazing at rapping Kendrick Lamar when I'm on a cruise ship in front of 30 senior citizens. For the record, I'm not amazing at rapping Kendrick Lamar. I only do it for entertainment value. I am really willing to sacrifice my own dignity for that because karaoke is not about me and trying to look amazing in front of all these people. It's about getting the vibe in the room up, right? And so I don't go to karaoke to pretend like I'm amazing like Mariah Carey and said I'm really more embarrassing all the voice teachers I've had over the years. And it's a social experience. You have to share it with people. You want them to make it good for you and vice versa. So coding on a team project is similar. You want to be like this guy kind of, instead of like this cowboy developer. And I know these gifs are maybe not making the case that the cowboy is not what you want to be, but the guy in the ski mask has friends who help him. All right, and the cowboy dev is making his own job harder than it needs to be, but he's also making everyone else's job more difficult as well. So now for some takeaways because a good talk has some good takeaways. I want you guys to have good experiences at karaoke and in development for yourself and also for others. As far as how things can be good for you, don't take karaoke too seriously. It's not American Idol, have fun. Being a bad singer can even be used to your advantage. For example, if you can rap, I can't rap, but I'll do it for the lulls. And then for programming, I really need you guys to memorize this command. I'm wedging this in there because this was originally gonna be the entire subject. I'm pointing at nothing. The entire subject of my talk was just this command. Last year, if you attended RubyConf, I did a lightning talk about get commands to get you out of trouble. And I don't think I emphasized this one enough because I've used this to help a few people save hours of their time about three times this year. So I'm just gonna explain really quickly what getreflog does. If you consider a video game where you can save and load save points, it's really convenient, but sometimes you might be worried about overwriting a save. Imagine if you had a list that showed you not only when you saved, but every time you opened the menu and you saved or you loaded or you overwrote, and you could go back to right before you did that. That's what getreflog does. It is putting you in that moment in time where you can go right before you, rebased or merged. And so I really need you guys just to memorize this. Look it up if you have to, if the explanation I gave wasn't super clear, but you will save someone maybe yourself. Anyway, we're hiring. I work at Xcela.com slash careers. Also tweet me your favorite songs that you wanna hear at Karaoke. If I'm not gonna deliver, maybe I can find someone who will. Thanks for your time. Estar Bestar. Okay. Up next is Ruan Lamborghini. Ruan Lamborghini. Are you here? I may have gone too far with this one, I fear. I should put a little sign that just says, like remember your number because I won't remember your name on the top here or something like that. Ruan here is number nine. So that's where we are. Please get started. Number eight. Hi, I'm Margo. I work in London for an organization called Money Advice Service. And I'm gonna talk to you briefly about Code Bar. Before I start, can I just get a show of hands? How many people have heard of Code Bar? Yay. I was kind of hoping on that because we're primarily based in England. We are actually international and I'm gonna show you a list of chapters. And there are surprisingly few in the United States. So first off, what is Code Bar? It were a nonprofit initiative to facilitate the growth and make tech more inclusive and more diverse. And we do this in a number of ways. We hold a number of events. We do workshops, monthly tech talks, and annual conferences. But I particularly wanted to mention the workshops. They tend to be weekly or monthly and they're not like your typical meetup where you come and somebody talks to you. They are very interactive and we pair students with mentors and we spend two hours where the student can work on whatever they want. They could be tutorials, they could be personal projects, they could be something that's helping them to learn how to code. And they are paired with a mentor who will just help them be there for the two hours and answer questions. And those two hours can be very productive and very rewarding for both the coach or the mentor and the student. So as I said, I was gonna show you some chapters that we have. These are all in the UK. We have quite a lot. You can see we have three in London. The reason why the West London one is emphasized is because I started that. And this talk was originally planned for the UK and West London. So I forgot to do that one. Here are international chapters. Oh look, there's only one in the US. And the US is such a big country. Never mind, we'll get back to that. Here are some of our sponsors. Again, this is a West London talk. So some of these you won't have heard of, but look, there are quite a few that you will have heard of. I'm guessing you've heard of eBay, Sweaty Betty, Shazam, Gumtree. So we're pretty well sponsored and in order to get involved, you don't have to worry about any sort of sponsorship because we've pretty much got it. So how can you get involved? You can sign up as a coach and just leave the West London bit off that URL and just go to codebar.io and you can choose your chapter. Might be a bit of a problem for a lot of you because there's only one in the US at the moment. That's in New York. You can contribute to the site. It is completely run and built by volunteers. If you go to that, again, if you go to that GitHub, URL, you'll find a number of issues that are outstanding, which you can contribute to. It's a great way to get involved in open source. And the other way is you can create tutorials. You can help organize events and workshops. It's entirely voluntary. It's also non-committal, so you can get involved in as much or as little as you want. So why would you do this? It's a great way, actually, to solidify your own knowledge. I started off my involvement with codebar as a student and I then became a coach. And I realized that, actually, I really learned a lot by coaching and I really, if I could teach somebody or explain a concept to somebody, then I really knew it. And if somebody asked me a question and I couldn't, then it was helpful for me to learn what I didn't know. It looks great on your CV. I don't need to say much more than that. It's a really good way to contribute to the tech community and to individuals' development. Ruby is nice, so are we. It's fun, it's rewarding. There's nothing better than at the end of two hours, somebody coming up to you and saying, thank you so much, you helped me so much. So I briefly wanna touch on, I'll probably only have time for one success story. Claire used to, I can't remember what she used to do, actually, but she decided she wanted to be a developer and she self-taught herself, completely self-taught herself with online tutorials and books and she came to codebar regularly and she is now a developer and not on the high street and that is purely through teaching herself and getting help at codebar coming regularly. So I just wanted to end by saying, get involved. It's really easy to start a chapter. You can find me later and I can tell you how I started West London. It was way easier than I thought it would be. Even if you don't feel like doing that, you can contribute to the site, as I said. We have a Slack channel, so do say hi and that's it. Thank you very much. Thank you. All right, on deck is, I thought this through, Adam Perenn, Cappy. Adam Open Perenn? Just, that's a strange name. Adam Open Perenn. I mean, I guess this person doesn't like Lisp. It's a damn Open Perenn is what it is. Rowan, go right ahead. Last name really Lamborghini? That's amazing. Continue. Don't answer my question. Everybody, my name is Ryan Loefflin, in case you were wondering what it might be. Or Rofreg, if you know me from the internet. I'm one of the co-founders of Splitwise, which is an app for splitting expenses with other people. And I've been lucky enough to work at Splitwise for almost seven years now, as we've grown from hundreds of users at the beginning to millions of users today. And that's exposed me to a ton of really interesting and important lessons about running Ruby in a production environment, especially at a really large scale. And one of the most important things that I've learned is this. Your code is going to do some really weird, unexpected stuff in production that you could never anticipate. And you know what, that's okay. Like, that's part of the job, right? Is that code isn't perfect, it has bugs, it's always going to have bugs. And your goal is not to write code that doesn't have any bugs. Your goal is to try to minimize the number of bugs that there are, and then build a system that helps you discover these new issues as they arrive. Because discovering those things is a chance to improve your skill as a developer and as an engineer. So I wanna talk about a particularly nasty issue that we encountered earlier this year. One of the most important things that Splitwise does is keep track of your total balance with another person. So the reason you use our app is because you split an apartment with someone and they paid for groceries and you paid for the electric bill. And I wanna know, IOA to $83. It's really important that we get this calculation right. We have a ton of tests to validate that this works correctly under a wide variety of situations and scenarios. But one random Tuesday, we had a massive caching failure in production. And all of a sudden, our code started returning inconsistent results for this calculation. So when I asked how much do IOA to, our Ruby code might say IO or $83, or it might say IO or 702. This is obviously a really huge user-facing problem. And it would have been really easy to miss because this just appeared suddenly on a random afternoon. We hadn't deployed anything, nothing had changed. It was that a component was failing in a way that interacted in a really complicated way. So how could we have caught this issue? Well, normally testing helps you catch issues like this, but tests did not help us here. Our tests were passing fine. We'd written tests about caching or about balances and hadn't anticipated this particular intersection of things. Another thing that maybe could have saved us is exception reporting, things like sentry outside, which are really critical for helping you discover random exceptions that crop up in the real world that you weren't expecting. The problem here is this wasn't throwing an exception. This was code that was still returning a perfectly valid value. It just returned a value that was completely wrong. So all of the standard basic techniques for catching bugs and errors had failed us. We were doing the right things and this still happened. Something that came up yesterday when Chad Fowler was up here was he said that tests are a design smell and we all kind of laughed at it, but as he went on to say, he kind of had a point. The point of that I think is that tests are not the same as production and when you're writing a good testing suite and you have good monitoring and exception reporting, it's easy to convince yourself that you have protected yourself from all these kinds of issues when you actually haven't. There are still gaps that we don't address with our standard procedures. So what can you do to protect yourself in this kind of situation? I'd like to introduce the idea of a checkup and this is something I've been starting to workshop and it's not fully formed, so bear with me. The idea of a checkup is it's a test for production. Just like a test, you declare some expectations about how you expect your app to behave in production, then you run code to evaluate those expectations on a regular basis many times a day, just like you would for continuous integration as you make new commits. If your checkup fails, then you need to be alerted so that you can investigate what happened. As I just said, it's basically like CI for production, like you're making sure that production is still behaving the way you think it does. So going back to this horrible balance bug, we actually had a checkup task. We had this rake task and this is a gross simplification that was set to run every 10 minutes or so and look at accounts that have been updated in the very recent past and double check that the balance returned by this method matched the balance if you were to recalculate it from scratch from the database with a whole different path. And by comparing these two values for those accounts, we could continually verify that this method was working as expected and if anything went wrong, we could clear the cache because the cached value was clearly wrong and thank God we did that because it turned, not only did this checkup alert us that something significant had happened, but it actually mitigated the problem in real time while we scrambled to figure out what the hell was going on and release a more permanent fix. So the point I want to leave you with to start thinking about is that maybe you should have a checkup suite. Maybe there's a gap right now in the way that we think about the different components of our code where we're not continuously verifying that production actually works the way that we think it does in our brains. And that can be as easy as making a rake task and running it once a day or once an hour or every five minutes and making sure that things continue to work. That's about all I got. I would love to talk about this idea further. I've been thinking about it a lot recently. I'll be somewhere in the back there, so come find me or at me on Twitter or find me on GitHub, find me anywhere. Thanks so much. On deck is Heim. Heim? I'm pretty sure it's J's H sound. So I want to hear it. List payers of the world unite for this next talk. You go ahead anytime. That was a deep one. That was a deep, that was good. Well, hi everybody. My name is Adam Cuppey and this is? Julia Cuppey. And you can guess by that that we're related. No, we're married. Yeah, that's a bad joke. So tomorrow, number one, we want to invite you to our talk tomorrow. So tomorrow at 1.50, in Solana right across from here, we're going to be giving a talk called Yes and. And effectively the talk is centering around the number one rule of improv, which is Yes and, and building off of one another and what you can do with that and how that might apply in other areas. But before we get too far, oh, go ahead. Yeah, so I just wanted to say, why would we even want to learn about improv at a computer programming conference? I'm going to be the first to say that I don't know the difference between a gem and an R-spec. So I'm not going to pretend that I know and I'm not going to say that I do. What I do is I actually work for a major regional theater company called La Jolla Playhouse where we use theater making skills to actually teach students of all ages how to be better human beings. And so one of the things we'll be doing at our workshop tomorrow is learning a little bit about embracing failure, celebrating it actually. So we're going to do that right now. Yes, so here's what I want you to do. So you're in luck today because this is going to be a very interactive 6.30 at night. Okay, so here's what I want you to do. Okay, I want you to just take a moment and stand up. And for all of you, and I do mean this sincerely, for all of you who do not speak English or well, I apologize, we're going to actually be going through our ABCs. So here's what I want you to do is I want you to find a partner next to you either to your left or to your right. If you don't have a partner, raise your hand. If you don't have a partner, raise your hand. Okay, fantastic. Look for somebody else. Okay, fantastic. Now here's what I want you to do. Between you and your partner, this is a very simple exercise. You got it? So number one is we want to celebrate failure. Okay, and whenever failure occurs, whenever failure occurs. Which happens a lot. All the time. It's about to happen here in a moment. What I want you to do is go, ah-ooh-gah, do it with me. Ah-ooh-gah, it's that simple. And you got to bring your hands up in the air and go ah-ooh-gah, like we're doing the wave. Yeah, you got it. Engage the whole body. Okay, so here's the exercise. Okay, so raise your hand if you have a partner. Yeah, they're good. Perfect, that's all of us outstanding. Here's what I want you to do. Between you and your partner, you're gonna go from A to Z. So it's gonna look something like this. A, B, Z, E, F, G, H, I. All the way up to Z. Now if you fail, you're gonna do what? Ah-ooh-gah. Exactly, all right. A failure is a hesitation, or if you overlap or you say the wrong letter. Okay, ready? On the count of three, go. One, two, three. As loud as you can. And start over. Once you fail, start over. Do it again. Fail more. 10. Okay, all right. 10, nine. Okay, everybody, here we go. Eight, seven, six, five, four, three, two, one. All right, fantastic. Give yourselves a hand. Outstanding. Okay, no, don't sit down. You're not done yet. So here's what I, okay. So raise your hand if you failed. Fantastic, excellent. So now what you're gonna do is you're only gonna go up to C. So A, B, C, and back and all the way up until the point on which you failed, it's gonna look like this. A, B, C, A, B, C, A, B. Oh, got it. Ready and go. Keep going, keep going. And do it again. Okay, that's like, yep, yep, yep. That's right here. Okay. And five, four. Okay, now raise your hand if you failed wonderfully. Fantastic, excellent job. And one thing we like to say is that in these type of exercises, your job is to actually shoot for average and fail cheerfully. So you did excellent job. Nice work. Nice work. Very, very good. Okay, so again, you can sit down now, enjoy. So here's the deal is we would love to have a very full crowd in room tomorrow. So 150 tomorrow, if there's another talk you're really interested in, by all means attend that. But if you are, if you were split a little bit, we would love to see you there. Okay, 150 tomorrow in Solanae. I hope to see you there. See you there, bye-bye. Aruga, that's just me. I guess that was a fail. This next person has cruel parents. They name them, they started their name with an at sign. So I'm just gonna call them at. So Mr. At, come on up. Oh, maybe it's the Twitter handle. No, that can't be it. Is it a YOL handle? Is it a YOL handle? Is it a YOLO handle? Is that a thing now? A YOLO. I love YOLO handles. We should all have YOLO handles. Mine will be Evan. Hi, May, please continue. All right, can you all hear me? You're not, you're not displaying, though. Is that, is that, you gotta hit play. How about that? All right, does that look better? Yep, okay. All right, so our goal today is to discuss who and why we trust ideally so that we can make more trust among us. The audience is all of you, basically professionals at any point in their career. Hopefully by the end of this talk, we'll all agree that making expectations explicit is a good thing. So trust. Trust our ability to predict what is going to happen. Like nerves on stage. Gravity is something that we trust. Why? It's reliable. It always works the same way. So there are those people in our lives whom we trust. Loveland's teachers, coworkers. Who do you trust? Quick. Anyone? Your life. Your life. Hero. Gift card to Marty for $25. Who trusts somebody? You. Who do you trust? There you go. Who else? Who trusts somebody? You. Your husband. Excellent. There you go. So why do we trust? It allows us to tell a future. Predictability allows us to go further and build more complex interactions. We gain reliability and return to those around us. Imagine if you picked up a power cord and you didn't know when you plugged your $3,000 laptop into it whether you were going to get the right voltage. It was going to blow it up, perhaps. So what happens when we break trust? An old boss shared a tip that his therapist gave him which was anger is a violation of expectation. So trust then is a repeated meeting of expectations. Trust is a repeated meeting or exceeding of expectations. So who sets those expectations? It's you, exactly. You read my slides already? So your experience in the world has compiled your expectations to the world. And conversely, your actions create expectations of you and those around you. Awesome. So combined, these expectations build a web of trust that you rely on every day, that we rely on every day. So how can trust be abused? If we know what someone expects and then we do something different, likely for our own benefit, it's unkind and they're likely to wind up unhappy. Let's say that I got up here and set the expectation that I was going to give you a gift card and instead you got a plunger. Maybe you might not be happy, right? Unless you look on the inside of the plunger and there's a card. Because you don't want people angry. So how many people here know, how many people here know users of the internet who don't know every intricacy? They look for the any key. So how many of you have used shortcuts? Like look for the green lock, that way you know it's safe. I mean, kind of. You put a little green lock on there and trick people. How could we forget the great Google phishing docs incident in 2017? Those documents came from our friends and coworkers. Wasn't really expecting anything from Bob, but Google locks are safe, right? So as we build systems, what assumptions of do we have of our users? Do we expect that they're able-bodied adults? Maybe they're children or grandchildren or grandparents. Each could have limited comprehension or mobility. We've settled on texts as a permanent mode of presenting information. What about visually impaired users? Fairly simple updates make screen readers make that text accessible. We don't always do that, do we? So we're all terrible people. I don't believe that we're terrible people. I believe that largely that happens because our experiences of the world are different from the experience that other people have. So how do we learn about how others experience the world? Mind-blowing RubyConf takeaway. Need to talk to other people. And more importantly, we need to listen. Listen to their experiences and listen to where their expectations mismatch. Where do we find people? We're developers. We would probably find a lot of the people that we're looking to talk to at conferences, meetups, open source projects. Go listen. If you're at a product company, user testing. Go out on Twitter. Every once in a while, I'll run a search on Twitter that says, how do I? And then you'll find somebody to help. So providing an understanding of that impact, we'd make those changes, right? Why don't we? Bosses, budgets, deadlines. They all have expectations. Perhaps of them or on us. The beautiful thing about those expectations is that they can be reset. You should do your best not to miss expectations. But expectations can be reset. So especially when you know you're not gonna make an expectation, you should try and reset it. As we interact with people around us, we build a set of expectations of them and on ourselves. And those expectations allow us to build a bigger, more complex interaction and provide more value to those around us. Thank you. Wonderful. Next on deck is, I guess our parents must have named them after the street, D Avenue. D Ave? I mean, I assume that means Ave, Ave store for Avenue, right? Next up, Mr. At, the stage is yours. Testing, all right, that's all. So my name is At Amir Rajan. My parents did actually name me that. They made sure the Twitter handle was available, the website was available. Yeah, they were very pressured. My alter egos are at a darkroom IOS and at Ruby Motion. And this talk is about meaningful work and luck. Around April of 2013, I made a horrible, horrible decision and that was to sell everything I owned except for what you see in that picture and quit my job. And downsized to a one bedroom apartment. And I have the desk, the chair and this backpack, which I still have today. And I just got burned out. Wanted to do something for myself and it was a, in retrospect, it was a very, very dumb idea. So my wife was okay with this. She said, you know what, as long as my quality of life does not change, I'm perfectly okay with you selling everything and me having more closet space. So she was fine with that. And what I ended up finding was this web-based game called The Darkroom. I reached out to the guy, his name was Michael Townsend. Sent him an email and said, have you thought about porting a darkroom to IOS? I'm actually a developer on a sabbatical right now and we'll have to give it a stab. And Michael said, yeah, if you want to port it, you have my blessing. I'm sick of the corporate world also. If it goes well, there may be a mutual beneficial partnership for the both of us. He sent me the source code. It's completely JavaScript, which was horrible. So I ported everything over using Ruby and created the IOS version of the game. It took about four months, 71 emails and two Google G plus hangout sessions I have yet to meet Michael. He lives in Canada, poor guy. At least that's what I said in 2016. Now I'm not so sure. And after releasing, expecting this game to go viral, it didn't. First day made 50 bucks. My highest day was at $246. So I've wasted four months of my life. I have no job. I've sold everything. And I built a text, minimally text-based RPG based off of a JavaScript code base in Ruby, which is not terrible. So I want to take a little segue to talk about survivorship bias. This is where most stories end, right? And many people do the same thing and are never heard. And I was one of the lucky ones that can still be heard. And yes, we are still all dying. Thank you, Aaron, for taking my joke. I had to change this slide because of you. It's okay. It's okay. We are still all dying. Here is, here is what it's like to be a game developer. Oh my gosh. This is, I'm gonna spend one minute trying to get this ding. Ding, ding, to show up here. There we go. Yep, yep. It's gonna open video, new tab. This is the most horrible fail either. Okay, there we go. There we go. Okay. Do you make money off your art? Yes, really? So unfortunately, that's what happens to most game developers. But I was one of the lucky ones. I went viral in the UK. And one day I made, got 4,000 downloads and I got really lucky and went viral in the US. You don't sleep when you see $14,000 get deposited into your bank account in one day. That's pretty much what happened. That spike that you see on the left is the time that I went viral in the UK. So I was one of the lucky ones. I was one of the lucky ones that didn't sleep for 18 days while I was at the number one spot. And I was one of the lucky ones that is able to tell the story today. And I was one of the lucky ones that ended up being one of the Apple's best of 2014 with that being on the list right there. But aside from all that, what makes this work meaningful and makes almost all the horrible mistakes, horrible decisions I made worth it was this email that I got from a kid. I was inspired by your game being that it's text-based and doesn't have 3D graphics. I would like to create my own game using JavaScript. I'm a poor guy. I told him about Ruby, don't worry. I'm 14 years old, which also makes it difficult or maybe easier as I have a lot of time. To do this, how do I get started? So that was one of the emails that I got after the game went viral. Interestingly enough, I did make the game accessible to the blind. And I wanted to pass this, this was a Facebook post. I wanted to pass this on as a thank you for the game of Darkroom. Not only does it take me back to my childhood and fond memories of time spent with my father, playing these types of games, but your game allows my sister who is completely blind since shortly after birth to enjoy popular mainstream game as well. Something those liking site rarely have the pleasure of doing. We much appreciate your efforts. So there's my talk about meaningful work and luck and making horrible, horrible decisions. And if you have any questions about iOS and all the more detailed thing of my journey, please come and say hello and I'd be happy to talk about it. Thank you. Thank you, doctor at, I presume. Next up is someone named same Livingston through gray. That hyphen means through, right? So, D Avenue. It's all you, man. Okay, well it's not projecting. It's not all you. Click this box. And then click this box. Oh, I thought it had been already, okay. And then click that box. And then, yep. All right, good evening everybody. I'm Dave Aronson, the T-Rex of Kodosaurus LLC. And this thing is automatically getting ahead of me. Stop that you. A while back I was thinking about what are the key aspects that make a piece of software high quality and I came up with something that I'm now calling Acrumen. So what is Acrumen? It's originally a Latin word meaning sour fruit like the lemons that life hands you by the bushelful sometimes in the form of low quality software. But what is it in this context? It is an acronym that puts these various aspects in priority order, but not just from the point of view of us developers. It's also taking into account the once in needs of the other stakeholders like users and customers and your managers and so forth. So you're probably wondering what are these names? And aspects already. First off, it has to be a for appropriate, meaning it's doing the right job. This is, I believe, not only more important than any one of the others, but more important than the rest of them put together. We can go through a little thought experiment I don't have time for right now. And the sad thing is we developers are often not taught that this is even a thing, let alone a thing that we should be thinking about. Yeah, ideally you have a requirements analyst, but we don't always have that luxury. After we've determined what job it should be doing, well we have to ensure that it's doing the job right. Appropriate and correct are often referred to, by the way, as validation and verification. You may have heard that term. After we've determined that it's doing the job right, it's gotta be robust. It's gotta be hard to make it misbehave, like fall over and die, or reveal information when it's not supposed to. And that includes even if you're trying to deliberately make it misbehave. So that includes the aspect of security. I did have that separated out in a previous version, but that doesn't make it very pronounceable. Acrusum doesn't quite work. Then we get to usability, something that the previous couple speakers already mentioned and has been mentioned in previous things here, should be obvious what the user can do next and how and what the program can do for them. And regardless of various challenges the user may have like poor or no vision, color vision, hearing, fine motor control, possibly even literacy or intelligence. And then we get into maintainability. The vast majority of software engineering advices aimed squarely at that, so I'm not going to go into much detail. And lastly, it must be efficient. Dead last, despite what a pedestal we developers tend to put it on, you should be easy on not only technical resources, like obviously memory in the CPU as we usually think of, but also screen space, disk space and the very precious resource of user attention and having to figure things out. So now you're probably wondering, what does the end stand for? Nothing, I just tack that on to make it a word. This whole thing is a work in progress. I came up with it fairly recently. There are sometimes conflicts into overlap and your priorities may be different in different situations, so I cope with it. And I'd like to get your feedback if you think I missed anything, included something that shouldn't be there, especially if we've got a better acronym and I'm hoping to work this up into some training courses to add to my consulting offerings and my contact information. And I'm also not planning to go to karaoke, so if you want to talk about this, we can go have dinner or whatever. Thank you very much. Thank you, MCT-REx. On deck is NOAH, which according to the internet, is nitrous oxide satisfactium. Same, Livingston through gray, you are, the stage is yours. Why, thank you. I'm actually pretty happy that my name was hard to mess up. Hi, my name is Sam Livingston, I'm living through gray. I have a tech podcast called Greater Than Code and I think you might like it. And I say Greater Than Code is a tech podcast and that's technically true if only because most of us or all of us who are on the show are in tech. But we started this podcast because tech didn't seem like the most important or even the most interesting thing to talk about with tech people. So we decided to do a podcast about the human side of tech, about being squishy human beings who have lives and feelings. And to that end, we do panel style interviews with the most interesting people we can find. We have a pretty big pool of panelists to draw on. Some of us are on regularly and some of us are more like recurring guest stars. We're a relatively diverse group, as I hope you can see here. We're especially proud to have a majority of women panelists with more than one trans panelist and more than one panelist of color. So I'm pretty happy about all of that. We're also proud to have an amazing producer and editor, Mandy Moore, not the famous one, but our Mandy, wrangles guests and does our audio editing and she makes this all sound considerably smarter than we actually are. We also strive for diversity in our choice of topics. Here are a few of them on the screen that I pulled just from the episode titles. We've got about 50 something episodes out now. One of my personal favorites was the one where we had James Edward Gray and Misha Lewis-Norrell on to talk about accessibility in gaming. And that one was a whole lot of fun because we were all talking about games we loved. But in addition to just the fun, I wanna highlight just two of the things that we've talked about on the show that I thought were really important. One episode that really seemed to strike a chord with a lot of our listeners was episode 38 with Dr. Hyogenia Cheng as our guest. In this episode, she defined two new terms, ingressive and congressive, and here's what she had to say about them. Ingressive, she says, is about going into things alone and not being way-led by what people think or buy emotions. Whereas congressive is about bringing people with you and bringing people together and unifying and making connections between things. And I find these are really useful terms just on their own, but what I really love is that she came up with these originally as a way to talk about behaviors that might traditionally be labeled masculine or feminine. But she didn't wanna have all the baggage that those terms drag along with them, so she made up new words. And that lets her tease apart individual behaviors and talk about them in a different way, which I really liked. I think a lot of our listeners really grabbed on to. Another one I thought was particularly important was episode 33, where we talked to Greg Bogus about mental health. Greg has given some talks about depression at a couple of regional Ruby conferences and at the Code Newbie conference. So there's obviously been some attention paid to issues of mental health in this profession, but we all think that it's really important to shine more light on this topic and to help de-stigmatize these conditions so that people face fewer barriers in getting help. Greg talked about how one of those barriers is shame. In talking about his own depression, he said, the hardest part is that when you go through it, you tend to go through it alone in a way that you wouldn't with physical illness as opposed to maybe having migraines. But when you're suffering with depression, the inclination is to hide. And I wanted to just make sure that we talked about that. By the way, I personally deal with depression and also ADHD. So if you think you might have one of those diagnoses and you wanna come talk to somebody about it, please say hello. I hope that you'll give us a listen if you haven't done so already. We talk about a lot of things that are important to us and I hope that they will be important and interesting to you as well. We also have a Slack community with lots of wonderful people in it. It's one of the most friendly online communities I've ever been a part of. Most importantly, I have shirts and stickers. I have a couple of dozen t-shirts that are in my bag, which means that I don't get to take my own clothing home if I don't get rid of these shirts. So please come see me. I have a full range of both men and women's sizes of shirts and a bunch of stickers. Oh, by the way, we're all gonna die. Thank you. On deck is he die. Waterhouse, that one I can read. It's only last first names for some reason. I don't, should probably get that checked out. All right, I'm told I'm nitrous oxide today, which works okay for me. Yeah. So I gave a talk at RubyKaigi in 40 minutes. Let's see if we can get it in five. I have high hopes for this. How close is Ruby 3x3 for real web apps? In other words, how close are we to three times for large concurrent Rails apps? So real web apps, I mean in production, used by real people, I'm using Discourse, which is forum software, open source, widely available, used by a bunch of folks. It's forum software, so you've got topics, you've got comments, you've got replies to the comments. And so I think it's a good way to check how fast Ruby is for Rails apps. Rails Ruby Bench is a benchmark that I wrote that basically comes up with a series of HTTP requests to simulate a whole bunch of users using your Rails app, and in this case Discourse. So recorded a bunch of interactions, replay it as a randomized thing using a random seed. So it replays the same series of requests each time in order to make sure I'm not adding too much noise to the data. I then stick a whole bunch of load testing threads and Puma with 10 processes and 60 threads all on the same large dedicated AWS instance, run it for a large number of iterations, see how fast it goes. I'd love to talk more about methodology later when I'm not on a five minute time limit, but grab me at any time, I love this stuff. I also use two different versions of Discourse because real world software, it turns out Discourse 1.5 only is compatible up to Ruby 2.3.4, Discourse 1.8 is 2.3.0 plus, so I use for version 2.3.4, I run it in both Discourses. You're gonna see that on the graphs in a second. Love graphs. So what can we learn with that? It's great that I built a bunch of stuff. What's the interesting bit? Well how much faster is Ruby 2.4.1 than 2.0.0 for processing HTTP requests? It's titled a talk, right? So, big graph. Each set of five bars is from the minimum to the maximum, the fastest to the slowest request for each Ruby version and each Discourse version. Discourse version 1.5 is on the left, Discourse 1.8 on the right. So what's this actually mean? Well if you look at how much faster it gets, the direction of the graph, Ruby 2.3.4 is between 45 and 50% faster than Ruby 2.0.0 for Discourse 1.5. Awesome. And Ruby 2.4.1 is three to 5% faster than Ruby 2.3.4. A lot of good stuff was done, but in this case Rails isn't a great way to show it. It's good that we check both versions because otherwise it would look like Ruby 2.4 was slower than Ruby 2.3. And in fact it isn't. It's that Discourse got slower. And so we check both, we find that out. Great. So overall, if you take the two speedups, for HTTP requests Ruby 2.4.1 is just over 150% of the speed of 2.0.0. In other words we wanna get to 300% for 3x. We're not there yet, but it's a good start. Does Monts's Ruby need warm-up iterations? So first off, what are warm-up iterations? Warm-up iterations are additional iterations that you do before you start timing. You let the server go for a little while to load in caches to get the memory set up. If it does, then to do JIT. So basically things tend to be slow at first. You're seeing three different Ruby implementations there and the very flat line at the bottom is Monts's Ruby interpreter is C Ruby. And it's very flat because the warm-up is extremely fast there. It gets to close to full speed pretty much immediately. And specifically, here we've got groups of five, but it's not minimum to maximum anymore. Instead, it's from zero warm-up iterations to 5,000 warm-up iterations in each group. Each group of five bars, it's more warm-up iterations as you go to the right. Or to put it the way the graph does, with more warm-ups, you get better throughput. And so what you're doing is looking at the top of each of those five bars and seeing that it goes up and to the right pretty much at the same rate for every measured Ruby. In other words, it does make a difference. It makes a small difference. None of those graphs go up very steeply. So 5,000 warm-up iterations gives you about a 5% to 7% speed up. That's, now you know about how long you've got to run your server before it hits full speed, but full speed is 5% to 7% faster than baseline. It's not a huge deal. But more interesting, we did much more complicated garbage collection in recent Ruby versions, does that cause a problem? Does that mean more warm-up? And the answer is no because the slope is the same across the top of each of those. If you saw one with a much higher slope, what you'd be seeing is something that needed more iterations to seriously warm-up and none of them do. Awesome. So how about startup time? I'm measuring time to first request, basically just keep looping and try to hit the server until it successfully returns something. Oh, and I'm really over time. So short answer is that there's a large speed up in up to Ruby 2.3, there's another large speed up for Ruby 2.4 and it turns out discourse gets faster in between. So Ruby 2.4.1 is about 30% faster for the first request. The code for all of this is available. Again, I'd love to talk about methodology. I'd love to talk about the code. You can get it from there. I've also written a, you can run it locally. I've written a long series of blog posts about this. And again, I'd love to talk about any of that. Yeah, great to talk to you all. I think he took his first breath there at the end. That was one long breath, right? That was just one continuous breathing for five minutes. Yeah, yeah, exactly. Okay, Heidi's gonna be last. So Akira and Natsushi, I'm sorry. Heidi, please finish it off for us. My name is Heidi Waterhouse. I'm a developer advocate at LaunchDarkly, but before that, I was a technical writer for 20 years and I have some opinions about how y'all write error messages. You need some help. I went and looked up Ruby error messages and I have to tell you that this would make me cry if I were trying to program. Could not add variables A string and B fixed num. Thanks. So that's no good. I don't like it. What's in an error? What should an error contain? How can we make them usable? No, no. Let's not talk about what is in an error. Let's talk about what's in a good error. What's in a useful error? What's in a usable error? It has a unique name. If your error could be attributed to any one of a number of causes, you've screwed up. If you are serving 404s and you have more detailed information, you have screwed up. Make your error name as unique as possible. WordPress does this to me. It said, an HTTP error occurred. I'm like, you bastards, you know what error that was. Pass it through. Tell me what went wrong. So make it, somebody out there has had that error. It is you have too many images in your cache and they can't upload as near as I can tell. Make your error have a unique name so that people can actually Google on it. And then tell people what actually caused the error. Who here has tried to do anything with swagger slash YAML? Yeah, okay. Have you had the thing where it says error in line three and the error is actually in line 59 and it's that your indentation with your spaces was wrong. Because that's how YAML works and it's very picky about its spaces but they're not indicated by anything. And it will tell you that the error is in line three. It isn't, that's a lie. It's a dirty, dirty lie. This is anti-helpful. Don't tell people what the wrong cause is because we don't wanna do that. It doesn't do us any good. So once you've told people a unique name and what caused the error, you should tell them what they should do about it. Like, I can't retrieve that restart your server or whatever it is that's gonna make that better. If a human can take action to fix the error, tell them what it is. Like, be there I fixed that for your user because they really are just pissed off because they've already encountered an error message. And I know we've been talking about how errors or how we learn and mistakes or how we grow but there is that moment where you're like, gonna work this time, gonna work this, ah, did not work this time. So we have a lot of feelings around errors and if we give people a suggestion, an idea of what it is that they should be doing, they're gonna be a lot happier. So this is a bonus. Like I say a good error message has three elements but a really good error message has four elements. You tell them how it worked. Like, if it succeeds, please give them a message that says yes, system has uploaded. You're good to go because the absence of input is not as confirmatory as an actual message. So like just saying, well it didn't fail this time, either means it didn't fail this time or it failed silently and you're really screwed. Make your error messages at least as useful as Stack Overflow. If you are not Googling and reading Stack Overflow about your error messages and figuring out how to fix them, you're doing it wrong because that is the crowdsourced hive mind of all of the smartest slash laziest people out there and you really want their input on how your stuff is working. So go look up your error messages, see how they describe them in the words of the community that's using them because we have this bias, we know what the code is supposed to do and people out there know what they're trying to make it do and those are sometimes super different things. And if you know how to fix it, just fix it. Like if you have some programmatic way to say like you need a retry, put a fricking retry button in there, like there's no reason to make people work harder than they have to. If there is any way that you can solve an error, make it not occur or make it easy for somebody to fix and that's all I have for you except HDMI and USB-C is not a standard yet and don't trust it, I have gone back from my MacBook Pro to an iPad which is what I do all my presentations on because at least it still works. All right, thank you Heidi. Okay, we're gonna finish up with Akira, so okay. So hello, I'm a programmer from Japan on a, sorry, I'm a hobby programmer. Meaning on GitHub, I'm like this in Matsuda. This is me on GitHub, so I said I'm a hobby. I'm a hobby Rails programmer. I enjoy programming in Ruby. I'm on the contributors list as the 22nd of been working on Rails for like more than nine years. So I guess I enjoy programming Rails as a member of the Rails team on there. And also I'm a hobby Ruby programmer as again as a member of the Ruby team. And although I'm in the Ruby team, basically I'm not a C programmer. I mean I'm just a Ruby programmer. And I think my mission there in the team is to be kind of the bridge between these two development teams, Ruby and Rails, right? So also I'm a hobby gem programmer. I created Kaminari, which is I guess your favorite Rails paginator. Maintaining Hamel, the best template engine for Ruby and so many other great gems. So check them out on my GitHub profile. So this is me, but today I'm not gonna talk about the code all right. Today I'm here to talk about another hobby of mine which is organizing a conference. So I'm the organizer of a Ruby conference in Japan which is called Ruby Kaigi. It's a Ruby conference, you know, it's a tech conference, it's a open source conference. It's a programmer's conference in Japan. Have you heard of this? Okay, okay, thank you. Thank you. Thank you. Thank you. Well, I suppose some of you may have read this excellent write up titled Gaijin Guide to Ruby Kaigi by Richard from Heroku. In this article, Richard pointed out that the conference heavily favors technical talks which is kind of true. Yes, well, yes. Because every speaker talks about Ruby because it's a Ruby conference. Every speaker talks about the code they write and publish publicly because it's an open source tech conference, as I told you. But I think he's missing one important point. If you take a look at Ruby Kaigi's schedule, you'll notice that we've got so many talks along these three topics. Types, concurrency and performance. So we're intentionally focusing on these topics which are exactly the goals of Ruby 3, right? So we're kind of encouraging people to bring their hacks, their actual work along these three topics. Because I think we need more discussions. We need to talk more about these actual implementations. We want to see more proposals or thoughts on these topics. Yes, so I said we, so who are we? Well, at this event we've got so many Ruby core committers like this on, this is a picture of Ruby committers, 40 Ruby core committers on stage like this. Also, and the keynote speaker was Vlad. You know him. Matt's mentioned about him and his work at this, at the opening keynote at this event. And the author of the JIT compiler himself took one or a keynote for this event. So, so Ruby Kaigi is aiming to be an event that drives Ruby development by providing opportunities to discuss on these features. And so we're aiming to push Ruby development, right? And when a software development is driven by an event like this, it's called event driven development, right? So this is, I think, a mission of Ruby Kaigi. And this is why I'm organizing this event as a Ruby core committer member. Also, we've got so many other diverse topics around Ruby like C extension alternatives like standard libraries and Ruby, other implementations and data science and Ruby and so on. And we've got so many speakers from all around the world, not only Japanese. And for this conference, this Ruby conference, RubyConf 2017, I joined the program committee. I kind of helped the RubyConf team to making the program. So, you know, I'm a programmer. And... Thank you. In the team as a track director, my track is named Ruby Kaigi Track. It's gonna happen tomorrow in this conference. And my mission in this team, I guess, is to kind of bridge between two conferences, two physically separated conferences and communities. So, I brought the essence of Ruby Kaigi from Japan for this conference. We've got three Ruby core committers from Japan. And, yes. So, it's gonna happen in this room tomorrow. First goes Yusuke, a full-time Ruby committer at Cookpad, maintaining the coverage library and who implemented the keyword arguments in Ruby 2.0. Next goes Kenta, who's another full-time Ruby programmer, I mean, developer at SP, and who's maintaining Big Decimal. And the third speaker is Takashi, the maintainer of ERB. And he's not gonna talk about ERB, but he's gonna present about his toy project. I mean, his hobby, jit implementation for Ruby. So, do never miss them. And, if you're interested in Ruby Kaigi for this event, please join us at the Kaigi in Japan. We're expecting to see more attendees and speakers from other countries. So, the next Ruby Kaigi is gonna be held from May to June next year. So, that's it. Don't miss the Ruby Kaigi track tomorrow and I hope to see you there at Ruby Kaigi in Japan. That's it. Thank you. Thank you for listening.