 Okay. No slides. Here we go. Hi. When do I start? Okay. So I'm the developer of Bundler. I started a nonprofit called Ruby Together, whose t-shirt I'm wearing. Thank you. The good news is we successfully served gems this year. In the first 10 years of Ruby Gems we served 2 billion gems. Last year we served 4 billion gems. This year we've already served 4 billion gems and we still have almost two months left in the year. As you can probably guess that is hard and it costs money now because there's a lot of work to do that's really hard. If your company doesn't chip back into Ruby Together to make us able to afford the servers and the developers that make this possible, it won't be possible. Please do that. In exciting news, I have stickers. Come get stickers. And now that we're all excited, Ruby Together is launching a merch store. You can now buy Cool Swag. Awesome. Thanks. All right. This is gonna be super quick. I just wanted to let you know I did something at my company. I'm a devops working at Lightspeed back in Montreal. We were organizing tech talks for a while and we had some success with it but it really took off when we actually invited sales, support, legal and those people to come down and talk to the developers to tell them what they thought about the products, what they liked, disliked, what they wanted to see and allow the developers, allow the developers to be able to ask them questions and understand what the impact of what they do actually is. So I strongly encourage all of you to the same in your orgs. Hi everyone. Sam got a haircut! Can we switch slides on please? Thank you. This is a transformation. I used to look like this. Like a day ago. Now I don't. So I want to talk about a long time ago when I was not a maintainer of a popular Ruby gem and how wonderful I thought it might be. How I would learn to write perfect, perfect code and get the unending adoration of my peers. Work with people who mostly agree with me all the time. That would be great but the truth is it's not really like that. Open source software looks radically different to every and all Rails or other Ruby applications that you work on. Just by nature of their work, some of the code is definitely less than perfect. To go back to that thing that I just showed, this is RSpec mox proxy message received. If you use RSpec, you execute this hundreds of times a day and I honestly cannot tell you everything that this method does. That's not to say that the people who wrote it are bad people. That's not to say that they're not spending enough time on their projects or under not enough stress. These are incredibly talented people who are diligent and just don't have enough time to do everything that they want to do. I think time is one of the most precious resources our maintainers have. This number scares the hell out of me every time I see it. That means I'm serving all of you and many beyond who need the help writing their tests. I think a lot of other maintainers feel the same way. Our ecosystem is driven by open source. Literally everybody in this room is here because of an open source programming language that Matt's created. The thing is we have to talk about sustainability in our community. Our maintainers are one of our most important resources. In the past few years, I felt a little bit like the ones I looked up to a long time ago before I was working on open source are beginning to fade away. This is not true of all of them. Some of them are having life priorities changed. Some people are having kids. Some people have moved on to other programming languages and communities that they find really interesting and new and exciting. Some of them just straight up aren't with us anymore. Ruby isn't cool anymore. I think Matt's basically said this in his opening keynote. We've moved to a place of maturity. I think one thing that does for us is it means that maintainers aren't coming in with the same excited fervor that they used to be. We have a rich ecosystem. We have a room full of open source contributors and you're all amazing. Continuity of work is going to be necessary for these large projects. We can't just have one-off contributions. We need more regular committers. If you can, please help. It would be disingenuous for me to tell you that it's easy or that it's always rewarding. The reason I am here and the reason that I work on an open source project is that I love this room, I love this community and I love all of the work I do within it. If you want more exposure to more amazing people, then maybe think about finding an open source project and finding some time to contribute it to it today. Thanks. I'm Caroline Job and I'm very excited and thankful to be here as an opportunity scholar at my first RubyConf. Thanks. I started learning Ruby about six months ago, but I've been throwing parties for a lot longer. So I'm here to talk to you about how to throw a party the Ruby way. Imagine this. You're sitting at home and you're about to eat a delicious hamburger when you hear a knock on the door. You answer it to find 10 of your closest friends have arrived for a dinner party about which you had completely forgotten. Don't panic. Take the hamburger into the kitchen and start chopping. Soon you'll have ham. Problem solved. Now some of your health conscious friends want smoothies with the ham. And you've got fruit. But is it frozen? No. You don't have a blender or a freezer. But Ruby can handle this. Obviously they're blended now. But are they frozen? Yes. Now not everyone came to your party to drink smoothies. Some of your friends are running low on drinks. We've got an empty glass, a half empty glass and your optimistic friend with a half full glass. Just use Ruby to fill all of those glasses at once. Ruby has saved the party again. All good parties and with piles of dirty dishes. But with Ruby cleaning up is as simple as dirty dishes. Clear. That was sure easy. This is great but I want to issue a few words of caution. Let's say you're about to eat a banana split. And your best friend shows up and asks you to share. Be careful. It might seem like a good idea to split a banana split. But will it end up like this? Let's try it. Unfortunately as you may have suspected splitting a banana split will just leave you with a banana while your friend splits. This is a bitter melon indigenous to Asia. And your health conscious friends are back. And they want you to make them bitter melon juice which is all the new rage. It should be easy they say. Just squeeze it right? But does bitter melon dot squeeze actually give us bitter melon juice? Thanks. It does not. Bitter melon dot squeeze actually makes bitter melon which I imagine looks something like this. Hopefully this has been useful but just in case I want to leave you with one practical takeaway. And this is an old family recipe that's been passed down through generations for ruby chicken. You simply pluck the feathers, scrub it, insert the stuffing or split and flatten it, pop it in the oven, rotate it halfway through cooking, inspect it for doneness, let the temperature slightly drop while you set the table, then slice it and join together to chomp on some ruby chicken and enjoy each bite. I'm Caroline Job. If anyone has any other ways they like to use ruby to throw a party, go ahead and tweet me at Caroline underscore Job. And thanks so much. Hi I'm Jen and I'm here to talk about accessibility issues with your app. And what I'm talking about are making sure your app is useful for people who may be hearing impaired, visually impaired, colorblind, motor functions. There's a whole host of issues and reasons and use cases we might want to address. So that's what I'm here to talk about. So why do we want to make this accessible? Well we like to have sites that are functional and usable. And we want our users to be happy. We want them to be able to use those functional and usable sites. Also sometimes it's the law. So that's important too. If you work on a federal project like I do you're very familiar with this. There's lots of ways that we can improve our apps and some of the I'm going to take you through some of the ways you can do that. First of all test your app. And I'm not talking about like write a test. I'm talking about actually open it and go through it. The first thing you want to check for is a keyboard trap. And essentially what this is is you only use the keyboard to run through your app, make sure links work, make sure you can complete forms. If you're going through your app and suddenly you can't do anything that's a trap. The second thing I want to talk about oh well first of all how to solve that. There's lots of ways to solve it. I recommend Stack Overflow. Second loss of focus. This is an issue where you know that little gray bar you see around buttons on like Google. That's a default browser behavior usually. Don't get rid of those. That's actually an important visual cue for users to know where they're at within your application. So try to keep that around and don't listen to your designers all the time. There are some great tools out there for testing and usually these focus on things that make it either visual impairment aware or accessible to screen readers. The one I use is the Wave Chrome extension. There's lots of them out there. I like this one. The first thing you want to look for are contrast issues. So if you do have someone who's colorblind or like visually impaired, you want to make sure that you're hitting a color ratio for your text. Typically a passing ratio for compliance is about 4.5 to 1. Basically you want to make sure that your text is readable on the slides or on the website. Some other things that are pretty common whenever you run a tool like this. Images need alt tags. You want to make sure that alt tags are really concise and that they're meaningful. They actually describe what an image is supposed to be doing. So if you're using an image for a link, make sure it says clicking here does this. And I've included a little reference down here. Forms. So labels. You have a place where you want a user to enter like their first name. It'll say first name and then enter your first name here. So you want to make sure that that label has a four tag that matches the ID of your input. This is like the number one thing we get dinged on on my project. So that's why I included it. Other form elements also like select or drop down boxes. Those also need something to make the screen reader be able to read them. And what I use here is a title. There's lots of different things you can use though for screen readers to read this. So definitely recommend looking into those options. Oh, that's it. Thank you. Okay, hi. Good evening everybody. My name is Star Chen. I work at Excella Consulting. We are hiring right now. I'm looking for karaoke buddies. But today I'm going to be talking about Git and situations where you might have Git shame. So I've been developing for a little over a year now. But whether you've been developing for 10 years or 10 weeks or 10 minutes, I think you might have the anxiety of having a situation where you do something in Git and your reaction is like this. It feels very catastrophic. You don't know how you're going to fix it. Your whole team is going to know that you single-handedly messed everything up. So we're just going to take a little step back and talk about a few in case of emergency lifesavers to get you out of these situations. The first one is Git reflog. Git reflog is going to be a log that shows you all kinds of things that you were doing in Git. It's different from Git log because Git log shows you where your head was. And Git reflog shows you what the head was referring to. And so if you use this and you find the place where you maybe mess things up, you can do a Git reset head to the index of your Git reflog because again you're not going to a specific commit. So you're not going to a commit idea. You're doing things in between as well. Just remember to keep calm and use your Git reflog. I don't know how many of you guys have a lot of Git messages that look like this. This is maybe if you are in a rush, you're a little careless. You just haven't been keeping to your best practices. You have typos in your commit message or in your code itself. You forgot to check RuboCop. You didn't do things that you needed for testing. So what you do is first you just add your one or two character fix to staging. Then you do a Git commit dash dash amend. This is going to be your best friend if you make a lot of typos because you can also edit your commit message itself. But it will add your tiny little change to the previous commit. It will amend that commit. I don't know how often you guys are really eager beavers and you do something really cool. You're working on a new feature and then you commit it straight to master. And you are terrified. This is a pretty easy fix. First you're just going to branch off of master with your fresh awesome commit. And then you're going to create a feature branch that looks exactly like master with your new commit. And then you're just going to delete that commit with a Git reset hard. And then check out your new branch and then you're going to check your logs because you never believe that you've actually fixed the situation. But you did. You're going to be fine. If you are maybe testing a colleagues branch and you forget that you were supposed to be working on your own branch after that. You can do a Git reset soft which then brings your changes back into staging. And then you can stash them. Stashing if you're not familiar is also going to be your friend if you need to move changes from one branch to another. It kind of just like picks them up and then check out your correct branch and then you can put them back down with a Git stash apply or a Git stash pop. And from there you can commit it to the correct branch. Now sometimes you're trying to be fastidious and you do a Git diff to see what changes you've made in this commit. And then there's nothing there and it's very sad. So what happens is Git diff does not show what's in your staging area if you've already done a Git add. So you just have to add a really quick dash dash staged in order to see those changes. You won't be a sad raccoon. Also that raccoon got to eat some candy in the end just so you all know. If you are desperate to get your code working again, you've been trying all sorts of weird Git wizardry and nothing is coming together. You just kind of want to blow up your whole repository. You can do that as long as you've been really good about pushing to your remote repository regularly. So you just kind of you just remove your whole repository essentially. And then you clone it back down. This can be really cathartic and it feels really good. And as long as you actually are being good about pushing to your remote repository, this is not that bad. I know some folks who they just do this very, very regularly. And that's a little scary, but I mean it feels pretty good. If you like deleted code, you're going to love this. So all of these tips I actually stole from part of my language, oh shit, git.com. This is written by Katie Seiler Miller, who's an engineer at Etsy who likes swearing a lot more than I do. But I have this page bookmarked on my browser because one of the I was really scared of git when I started developing. I knew that it was a way that I could mess up my work and other people's work. But git becomes a lot less scary when you realize that any mistakes you make are not permanent and can actually be very easily managed. And so once you conquer git, you feel a little bit invincible. Thanks for your time. Good evening everyone. My name is Olivia Brundage. I'm going to talk to you today about how to automate your productivity through creating Ruby scripts and making them run daily. So just a little backstory. In June I got a new job as a software developer. Everything was going great, but I was really, really busy learning a lot of new stuff. Then my brilliant idea was to get a puppy in July. And let me tell you, taking care of a four month old puppy is a lot of work. So needless to say, I did not know where I'm going to get time. So I'm struggling around for these past few months figuring out how am I going to get things done. Luckily, there's a productivity method called git things done. So I'm here getting everything done using OmniFocus on my Mac to write down all the tasks that I need to get done. But one of the troubling things is my work is used to be tasks I need to do. I don't want to put those tasks into OmniFocus to get things done. I want that to be automatic. So I created a Ruby script just to make that happen. I'm going to walk you through a process of how you can automate some boring tasks. So just as a preface, this only pertains to really macOS and any other bash operating systems. And anything highlighted throughout the slide is things that you need to change. But it's really, really simple. So first off you're going to create your Ruby script to automate your things and just store it somewhere where you're not going to mess with it. Then you're going to create your RVM alias and label it for your app. So this is way that the Mac does not use its native Ruby language and uses the Ruby language that your app actually supports, which is very important. And then you're going to create your bash file and your bash file just runs your Ruby script from your RVM alias. And the last important step is to create your launch daemon file and save it in your launch daemon library, which is located there. And this is what that file looks like. And notice really the only two things you need to change are those two highlighted things right there. And you really much have a automated script that runs for you. And that is it. It's really simple. Thank you all very much for your time. My name is Kate Risenes and I'm a scholar here. And I'm going to teach you. I'm going to talk to you about self-learning. I'm not going to try not to bore you with my talk. Okay. There are two main keys to learning. One, you need the internet. That's pretty self-explanatory. What? Oh, yeah. You need the internet. And then also you need a mentor. This is where you come in. What are the good qualities of a mentor? You're probably wondering. They help you when you get stuck. That's pretty self-explanatory. Everybody needs help when they get stuck. And then they don't touch the keyboard. This is very important. This is very important, okay? Because when they touch the keyboard, you don't know, like, they don't know how the syntax goes, especially if you write coffee scripts. If the spaces get wrong, like, your whole text is messed up. So don't touch the keyboard. Good mentors will check on you constantly because programmers, especially new programmers, don't want to be burdens on anybody. They want to be able to, like, be independent. And they explain the mis-concepts. When you're a mentor, you also want to say, I don't know, because this lets the student know that it's okay not to know that they don't know something. Okay, how do you become a mentor? This is pretty good question, too. First, you find someone who needs help. Second, you make an offer of the help. A good way to find someone who needs help at this at this conference, we have scholars. For one, you could offer a scholar to be their mentor. Even seniors need help mentoring. My mom, she's a senior dev, and last, last, no, it was this year in May. She wants RailsConf and she met a guy named Jag and he's her mentor. They meet every other week. So no matter what level you're at, you can use a mentor. Okay, third, help them, of course. Okay, well that's it folks. My name is Kate Risenes. I'm 16 and I'm coming for you. So I'm going to talk to you today about skills that I've maintained after switching my career into development. So who am I? I am a recovering research scientist. Yeah, I had a background in biology, which seems pretty disparaging, but through the help of my Cincinnati chapter of girl development, in seven months I became a professional developer and I've been there for a little over a year now. So the things that I brought from science to here, because I want to emphasize that just because you come from a non-traditional path and you have low technical skills coming into a career, it doesn't mean that you don't have other high expertise in other areas. So first thing I brought over was working with a team. Now in science, that might have looked like having a primary investigator who was in charge of the research, but in development it's become either a client or a project manager and they have various levels of expertise and what they want. Well, I guess they all know what they want, but I have to be the person that says, okay, that's your problem now, this is how I'm going to solve it. And it's not always clear in either career, but being able to think through a problem is, oh shoot, that's the next one. So other things with working with a team are being able to utilize all of the people in the group. So we're going to have people that are coming from different backgrounds and are used to working on either the front end, the back end, whatever, but you still have to piece together everything to make a final product. And that's something that I didn't expect to be as useful as it is, but you really don't develop or code in a bubble. So you need to be able to work well with everyone that it takes to make things work. My second skill I brought over was problem solving. So at the end of the day, science is about, you know, having a problem, making experiments, and getting a solution, and development isn't that much different. So that might previously have been going through literature and then performing an experiment. Now it's like so much easier. You go through Stack Overflow so there's still that literature aspect, but you don't have to wait for science experiment to last weeks to finish. You just kind of type it in and see if everything explodes or works. Learning at work. So in science that might have been weekly presentations, things to say on the cutting edge of technology, which science is much more slower than technology. It might take like 15 years for a new experiment to really take ground and become valid, I guess. And now things move a lot more quickly, so I'm going to things that are more right on the pulse, meetups, and the learning just really never stops. So you're always not always just learning on your own, but if you go to meetups and things like that, you also have other people, more resources to talk to. And documentation. So in science that was writing a lot of protocols so that someone new could perform the experiment in the exact same way that I could. But now documentation is is that in five minutes? People aren't waving at me. Oh, okay. Oh, good. So now documentation is about writing out. Shoot, I'm so sorry. Requirements that we need to keep up our standards in our code and in our project. And then it also might be a user story. So in science I might have been more about saying what that data means and explaining to people I don't know. Sorry, I'm just going to go to the next slide. And now my surprisingly useful skills, things that I did not think would transfer over. So those things were more like core. I feel like in any new job I would have been able to utilize. My background in data visualization is something that I didn't expect to be using all the time. But being able to have hard concepts or like a lot of numbers and make it something that anyone could just glance at and understand is something that's been incredibly useful. I also have a statistical background and I work in like surveys now. So that stats background has been really helpful. I don't know if it's always useful, but it does actually help me kind of understand like what significant about even, oh, what is it called, like Google analytics and things like that trying to piece out like what is actually important and what's just noise in your data. Presenting at conferences, I did a lot, never to a tech audience that I'm scared in front of, but I think I'm done, so. Ah, you're done. Hi everyone, my name is Asaf Kefet and I am the CTO and co-founder at SNCC. And for many, many years I was a security researcher and today I'm going to talk about the security risk in pooling in gems that we all know and love. So first of all, open source is awesome, it's great, it lets us share our work and makes us much more productive focusing on our core functionality and not reinventing the wheel. But open source is not equal secure. It's not equal insecure as well, but we are seeing many vulnerabilities in open source project. We are all familiar with vulnerabilities like hard bleed, shell shock, image tragic, and more. And we see that attackers are targeting open source projects because it is usually less tested for security, exploited, easy to build and it's open source. So one vulnerabilities equal many victims. So for every gem that you pull, for every open source package that you use, do you know if it's developers have any security expertise? Do you know if it's underwent any security testing? Do you know how quickly the response to new vulnerabilities? For each dependency that you use, either directly or indirectly, it is a security risk that we need to assess. And this is a very big problem, but the first step we should address is non-vulnerabilities and security expert says that non-vulnerabilities are accounts for the major majority of successful attacks. So let's take a look at specific application and go from statistic into reality. And for this, I will use SNCC to approach this problem, but there are other tools that can let you at least find vulnerabilities. So I will use SNCC to test my Github repositories. Okay, so I will try to, maybe there is something that I can do to change the, all right. So the first thing that we are going to do is to test for non-vulnerabilities and we are looking at the project and the dependencies and intersect that with our open source vulnerability database. And for example, if you can see here there is the registry application, registry application, and we can try to view the test reports and we can see here that there is seven non-vulnerabilities. Five of them are high severity vulnerabilities and we are able to see that one of those are from HT Party and Action Pack and we are able to also read more about this vulnerability and to understand what is the actual vulnerability. In this case an attacker can use the request parameters to run arbitrary Ruby commands, which is the only grail for security hacker. So after we find the vulnerabilities, the next thing that we need to do is to fix those vulnerabilities and in order to fix those vulnerabilities, we are able to open a fixed PR. So we find vulnerabilities, the next thing is to fix those. So we have here seven non-vulnerabilities that we saw just earlier. So by creating a fixed pull request, we will be able to address all of those non-vulnerabilities. It's open here. Cool. So you can see here from GitHub screen that it opened pull request and it's fixing those vulnerabilities. So by clicking merge pull request, we will be able to merge to fix all those vulnerabilities and to be vulnerability free. So we find vulnerabilities, we fix vulnerabilities. The next thing to do is to continuously monitor for non-vulnerabilities because as we all know new vulnerabilities are disclosed all the time and we need to make sure that we have a way to respond for them. So either by tracking non-vulnerabilities or by sending a pull request with alerts for those new vulnerabilities. So thank you very much. All right. So my name is Mickey Risenes. I'm with team Tiny Hands over here and I wrote my talk for the members of the majority and as you know in software engineering it's pretty homogenous. So basically it's a talk for white guys. Okay. So what happens is we start talking about white guys. They get nervous and they apologize but I want to show you most people are cool and it's it's oh I just flipped slides. It's not your fault but gifts not running. So we're just going to guys cry on the other side of that gift. So oh there we go. There it is. Great. Most people are cool. It's not your fault but we do need back up in the office. You know like when someone says something wrong if you could just step up that'd be great. But this actually isn't my talk. RailsConf. So I've been working on understanding how what it's like to be part of the minority and most of my interactions in my life are with people who look or live like I do. And this isn't a good thing and it's a hard pattern to pattern to break. And while you might think that being a woman in tech is enough to teach me what it's like to be a minority, I believe I've learned more about being a minority in another arena. All my friends know where I'm going with this. I've learned more about how it feels to be different by skating at a different rank than any other activity. This is skate night. I love skate night. Every Wednesday nights seven to ten carry jelly beans. I'm there with my friends. This is the picture of that rank. It's pretty clear what the demographic is. I've done this for two to three years. I started skating at a Raleigh rank about six to eight months ago. This is my Raleigh rank. I love this rank. It's a different demographic and there's a lot different about it. The carry rank, we have a certain style. We go fast around the outside and we turn together. All the moves are choreographed. It takes a long time to get there. I've broken bones in the process. I love the style of skating that I do and I become pretty good at it. That's my younger daughter Faith there in the green and my best friend Laura on the other side. The Raleigh rank has a very different style and it's rhythm skating. There's more pairs and group skating. There's couple skating which means they're touching me, which I wasn't used to. These require different skating skills. The differences in skating, first of all, it's different equipment. My skates aren't the same. Speed skates go fast. I can blow out anyone in the Raleigh rank almost. But if I put on the artistic skates, I'm slow as a snail. And there's more edge work. Edge works when you're moving side to side and it's something that you don't do a lot of times when you're running fast down the straightaway because if you do that you're going to bite it. You are skating in close proximity to each other, so if you put your legs out wide, you're taking you, your partner, and a bunch of other people down with you. It's a bad idea. The speed of the rank is slower. I can't go my full speed, even in my speed skates because it's dangerous. There's a looser definition of a normal lap pattern. People come out of everywhere at the Raleigh rank and carry. It's all dress right dress. Everyone's just going right around the circle. And like I said, there's more touching, which was an adjustment for me. Oh yeah, that's Kim. I love Kim. Kim's a great person. All right, so the benefits of skating in some place are easy. I've met some amazing people, people that I wouldn't meet anyplace else. My social media pages reflect more varied opinions and backgrounds. And no question, I'm a better skater for doing different style on different equipment. The difficult benefits that I've received are I've had to rethink some of my convenient opinions and I've had to deal with the reality that I have biases. The things about this experience that have made those things come to light was that I was clearly a minority. There was a high risk of embarrassment. Physically, I appear very different and the difference is unescapable. I needed help because I couldn't skate in that style. So I needed someone to teach me that style. And I went to the I go to that rink without a support group. I don't have someone to run away and hide with. I need to be part of that group. And so I had to ask myself, what makes me uncomfortable? What highlights the differences between me and the group? And what actions by the majority comforted me? And when I know those things, I can take that back to when I'm in the majority. Now I can use those same actions to comfort the minority. So it's not the same. Skating is voluntary. I don't have to do it every day. It's not critical. I get a paycheck if I skate or don't skate. But there are a lot of people that are facing minority status. And they have to do it every day in the workplace and you have no clue what they're going through. So the takeaway is you want to put yourself in a minority situation and figure out what things make you comfortable. Then take that learning, that comfort, take it back to your job and help the people that are underrepresented in tech help them feel comfortable at work. I'm Mickey, Team China Hands. Good evening, everyone. My name is Michael Hartle and I have just two things to talk about. Mainly one is about what I'm up to. People ask me what are you up to? So for those of you who don't know, I'm among other things, the author of the Rubin Reels tutorial, which some of you may have read in here. Anyone here who read the Rubin Reels tutorial? All right, cool. So one thing I did recently is I actually added a more advanced tutorial. There's a short tutorial called Learn Enough Action Cable to be Dangerous. This is a follow on to the Reels tutorial. But those of you who've done the Reels tutorial know that it's pretty dense in places. It's pretty tough to get through all, what is it, 14 chapters now. It's a steep climb. So over the past over the past year and a half or so, I've been building out an intro sequence under this Learn Enough brand. And so I want to show you how that's going. So we start with novice developer and this is where you go. You go to developer fundamentals. And that's these three tutorials, Learn Enough command line, text editor, and git to be dangerous. And then I'm working on I published the online version of Learn Enough HTML to be dangerous. And then I'm working with my designer friend and co-founder on CSS and layout, JavaScript. So that's the second trilogy and then the third trilogy again to be written is Ruby Sinatra and Ruby on Rails. So this is meant to be a much gentler slope for people who are just starting out. Like everything I do, there's a free online version of the entire tutorial. And then you can also buy ebooks and standalone videos. There's also a subscription service called the Learn Enough Society. And this covers all of these different tiers. And one of the things about it is that it has the full streaming videos and then also there are places to answer all the exercises. So you can answer your exercises using Markdown and you can also see other people's answers if you want to see the solutions. My answers are here which I hope are generally right. Although if they're wrong let me know. And then you can see what other people do. One of the aspects of my own philosophy is I always like to have a way for people to get this information for free. So it's a subscription service but there is a scholarship you can apply for and there's a free tier. We get applications from all over the world which is really inspiring. The second thing I want to talk about really quickly here is beer. So the the Rails tutorial software when you release software you have to decide what's your license going to be. And so the license that I mainly went with was the MIT license which is very commonly used in open source software. It's pretty simple. You can this is the whole thing. Another common open source license is this, the new general public license. Some of you may have heard of it it's known as the GPL and this is what it is. So what happened is is this man, Paul Henning Kamp was just so disgusted by the situation that he said this is ridiculous. I want a really, really simple license even simpler than MIT. So the Ruby and Rails tutorial source code is dual licensed under the MIT license and Paul Henning Kamp's Paul Henning Kamp's beerware license. And the beerware license the beerware license says Michael Harvey, well it's your name here wrote this code as long as you retain this notice you can do whatever you want with this stuff. If we meet someday and you think this stuff is worth it you can buy me a beer and return. So people have been using this I've gotten a lot of beers over the years for this it actually works. And so in this period at Rails Conf I ran this event and so I'm doing it again here at RubyConf because it was so much fun. Tonight is the the Rails tutorial beerware night it's tonight it starts at 7 o'clock and it's local it's at the Palomino restaurant and bar at 5th and Vine. So if you go to my pinned tweet actually if you go to my pinned tweet at twitter twitter.com slash mhartl you can see the information here for the event bright. So I hope to see you there I can talk more about about learn enough so learn enough is it learnenough.com and that's also where you can find more information about all of those tutorials that are in progress as well as the learn enough society subscription service. Thank you very much. So technical interviews stink. No one is really surprised by this but the more important detail is that technical interviews are part of the process of building your business. So when they stink your business can stink. All right. Now we know about whiteboarding we know about questionnaires we even know about take home exercises all of these approaches also stink they don't give us enough information to be able to figure out whether the candidates we're interviewing are really the people that are best for our company. All the common tools that we tend to use to assess candidates are less than optimal for identifying the candidates we really want. Most of us want candidates that are creative collaborative and competent. We don't normally just care about technical competency we want more than just that. And so we need assessment tools that are better than what we typically use than what we already have what we're familiar with. One of the biggest problems that comes in with our development tools or with our interviewing tools is that they are contrived and they sacrifice clarity for brevity. They sacrifice meaningful information for timeliness. Now at MavenLink we pair all the time. That's how we work. And so we start our interview process with pairing. We can't use traditional tools because they don't tell us enough about the candidates that we want to interview. So we don't use them. Instead we use pair programming as a way to interview our candidates. And this is a technique that can help you as well. Because we pair every day we start pairing in our interviews and this approach could help you. Even if you don't adopt pair program as a practice this is still a methodology that can give you more information about the people that you're talking to. Our very first interview takes about an hour and while it does help us gauge technical competence the candidate actually writes no code. Instead they are asked to tell the interviewer how to implement a series of features in a test driven environment and the interviewer actually writes the code for them. What we're looking for is the ability to communicate technical concepts clearly to another person without having to take control. The interview that we do following this is actually an onsite interview where we call people in and we ask them to pair with people in our office. We have them work alongside our engineers for a day and we get a really good feel for how they work whether or not they're comfortable in the very intense context that pair programming provides and it gives them a very good picture of how we work as a company. It helps both of us understand the relationship that we're looking into. Again even if you don't use pair programming as part of your team's process you can still learn much more about your candidates if you actually take some time to work with them as part of your interview process. And the earlier in this process that you can learn these details the better for you and for the people you're interviewing. Pairing an interview provides an excellent way for you and your candidate to gain the maximum amount of information about the relationship that you're both investigating and exploring. But how can you do this in your existing process? Jim Weirich's ruby rendition of the gilded rose caught it is a great exercise to lead people through. It can give you a great handle on how well someone works through the process of refactoring. Try getting fancy with Fibonacci. Don't start with solving the problem. Go on to generic and local memorization. You can get a really good feel for a person's mastery of a language by seeing how far they can take that exercise in terms of performance. Try writing a blog in an hour not just 15 minutes and add some additional features styling front end capabilities to get a more full stack assessment of the candidates that you're talking to. Whatever you do try doing it with your candidates in a way that gives you more useful information than the tired, highly scripted and generally unreliable methods we all know and have come to rely on. Thank you. I'm James Thompson. I work for Maven Link. Check us out online and you can follow me on Twitter as well. Hi, I'm Victoria Ganda. I am a developer at Collective Idea. We're in Holland, Michigan. This is my first RubyConf. It's been awesome. So I've been dancing a lot longer than I've been programming since I was in kindergarten. So it's been a really big part of my life and actually dancing is kind of what got me into programming. And if you want to hear that story you'll have to come find me. But because of this I'm often comparing dance and programming and there's a lot of comparisons to be made but I'm just going to look at one of them today that I think a lot of us can use. So both dancers and programmers always have room for improvement and learning. Otherwise we wouldn't need Google or classes and none of us would be in this room right now. And because of that we always are in the position to receive instruction, correction and critique. And what I think can be unique is the way that we respond to this feedback. It can be really easy to become disheartened or take it as a personal attack or you can go the route of just ignoring the feedback and assume that you know best. But I think that there are better options than this. When I'm in a dance class and I receive a correction I get really proud and I'm really happy about it. And I started thinking about what reasons this is and how I can apply that to when I'm coding. And the reasons might not be obvious but I think the reasons that I think we all can use. So the first thing is when you receive feedback it's an opportunity to learn. When someone gives you feedback they're taking time out of their day to share some information with you and you can be excited about that conversation. They saw that they have information that they can share and they think that you'd be willing to learn. So you can be proud that they're spending that time to help you learn. Once you've decided to make it a positive experience you can start working on making it a habit. When I receive a correction in a dance class I try to apply everywhere I can from there on out. Sometimes you can even find me at my desk at work practicing some things and you can do the same thing in your code. If you start practicing these things and repeating it wherever you can you start creating that mental muscle memory so that later on you find yourself using that thing without even thinking about it which makes you a stronger programmer. Okay so you can be excited about getting feedback but that doesn't mean you need to seek it out. You still need to try your best because if you keep repeating the same thing over and over again even though you've gotten feedback it shows that you're not really listening and you're not really learning and sure we're all human those repetitions will happen we'll make mistakes but what we can do is we can be really intentional about not repeating those things. So that brings us back here at some point or another we're all going to receive some sort of feedback and we can make a difference in the way that we respond to it. So when you get it it's not a bad thing it's not that you did something wrong it's not an attack it's just a change or an edit it's opportunity it's an opportunity to learn to share information with one another it's an opportunity to grow stronger and become a better programmer it's an opportunity to be intentional about not repeating a mistake by practicing these things I think we can all become better programmers and better teammates so the next time that you receive feedback can you be excited to learn from it and can you strive to apply it everywhere that you can until it becomes a habit and can you be determined not to make the same mistake again I'm going to leave you with these questions today if you want to continue the conversation at all you can find me on Twitter at ttganda and thank you all for listening Hi I'm Jonathan Slate I work at patients like me in Cambridge Mass I created these little creatures I call them Timx they help me understand Git I put them on our tech blog on patients like me and maybe they can help you too now that's what the blog is what is a Timx real quick it's just a commit so here we go this is the blog and I'm going to go through this really fast because I don't have a lot of time but you should look at it later and it has like actual Git stuff down there too so this is a Timx Timx aren't like people usually it only takes one Timx to make a child Timx but Timx are like people and they're all unique individuals each Timx is a complete Timx in its own right they're quite adamant about this the Timx have an impatient and ruthless God named VED VED doesn't like to wait and also kills Timx with reckless abandon over many generations VED can decide to add and remove various features this forms a family tree in this simple case our tree has just one branch this is not the kind of tree where each child has a subset of the features of the parent it's not a perfect metaphor but Timx are more like people than that children are just as complete as their parents one Timx can have more than one child Timx when this happens we get a new branch on the family tree what is a branch really it's just a pointer to a single Timx there's also a special pointer called head which points to one of the branch pointers head is the branch on which VED is currently changing features when a new branch is created it just points to the commit head points to so creating a new branch is very fast which pleases the inpatient VED usually head is moved to the new branch as well so VED can make changes on that branch as new Timx are created on a branch the pointer just moves forward let's say VED makes some changes on a branch called happy later VED might want to include those changes on the master branch in the case above VED updates the original branch to point to the Timx on the branch with the new features it's important to note that no new Timx is created here both branches now just point to the same Timx however this can only work when there aren't any changes in the other branch once the merge is done VED mercilessly kills the happy branch this is a fast forward merge thankfully no Timx are harmed in the process they are all just on the master branch often features from for more than one generation have to be combined when two branches are merged that means you have a Timx with two parents but even a Timx with two parents is a unique individual really go back and look if you want no Timx before this one looked just like this sometimes two branches need to be merged together but the features of the parents conflict this is like a triangle horn and a normal horn if there is a conflict between features VED must come in to resolve them sometimes VED wants to pick Timx from one branch and put them onto another branch this is cherry picking here VED wants to apply the hair and the beer to the Timx with the horns first the differences between Timx on the hairy branch are calculated the new Timx are created as children of the Timx with the horns with the changes included note however that only the changes from the Timx VED specified are applied here VED only picks the Timx with the with the beer to apply so the new Timx is created that only has the beard and no hair on top it's crazy sometimes history can look a bit messy when two branches come together so VED can rewrite history to make it look like there was only ever one branch rebasing before we saw how changes on another branch are used to create new Timx on the current branch but here we do something different changes from the hairy branch are reapplied on the hairy branch but new Timx have a different but the new Timx have a different parent the Timx with horns who did not exist when the hairy branch was first created now when we merge the hairy branch back into the original branch the pointer just gets moved forward to the latest Timx when VED is done it really looks like there was only ever one branch that's all I have for now I hope I hope to add more in the future if you have thoughts please leave them in the comments on the blog post patients like me yes we are hiring and at J Slate is my Twitter and that's it thank you very much that's Raj he was only 15 years old master wine I'm the other Michael Cain all the information that's pertinent is there do a little shot about MochaJS and probably why are we talking about MochaJS and RubyConf well I work for Comcast your neighborhood friendly super conglomerate in the media world and a lot of our jobs currently existed in Sidekick but they've kind of outgrown it so we're moving over to AWS Lambda which uses node to imply all of its stateless operations so how do you learn a new language yeah tasks can help you break stuff and learn by from it so this is great news if you want to learn NoJS there's already a test suite you already know MochaJS so we're going to do a little coda real quick the old calculator function right this is what an R-spec test would look like for the calculator R-spec is your friend this is what a MochaJS test suite looks like Mocha is your new friend now you don't just sit down and part banging out javascript right well it's pretty easy so let's check out what an R-spec test would look like describe is simply a function that calls another function it which calls yet another function expect which evaluates your function and its return MochaJS is exactly the same thing aside from a little bit of syntax difference describe is a function that calls a function it which evaluates a function with should which evaluates your function and then provides the same return now the only exception is MochaJS handles callbacks in a little bit of different way due to the asynchronous nature of node so as you can see if we were going to get a 200 request from google.com you got to slip that done into the parameter for the it call so you can tell the test when the test is done otherwise it's going to sit there and just wait for the rest of nothing to happen this is how you feel when you write your first lambda those are all my sidekick workers dead behind me my name is Michael Cain thank you very much for your time hi my name is Jammy and I'm here to talk to you about Clearwire which is front end development in Ruby so the way this works is it uses this tool called opal to compile your Ruby code into JavaScript and if you're using Rails then there's a pretty simple gem to install to that will automate that compilation for you through the asset pipeline why would you want to do this well I'm more familiar with Ruby than with JavaScript switching back and forth between languages is really difficult when you're used to Ruby JavaScript can be very confusing and you probably have a JS build system anyway that compiles your JS into other JS some people like to say that you know if you're programming for the front end just just learn JavaScript but the problem is you're not just learning JavaScript you're also learning all of these different all of these other other concepts at the same time and if you don't know one or more of them if you're not familiar with them then you have to learn them in a language you don't understand and so this also swapping back between between two different languages gives you a sort of this weird context which in all of a sudden you'll be writing your Ruby in JavaScript or your JavaScript in Ruby and so the ideal is to get write one language on both now node exists to write JavaScript on the server side but I want to write Ruby on the client side instead and so what so I wrote this this framework called Clearwater which is a Ruby front end framework that gives you components virtual DOM rendering optional routing if you're if you need to to render based on the URL and if you also you can opt into server side rendering and so this is kind of what that what that looks like so your your your layout like you have you have you load up your your dependencies just like in regular Ruby code uses actually a sprockets directive then you you create this class that includes a mix in that provides a couple of methods that you know a bunch of methods that you can use to you know this this tag DSL like h1 div span all those then you instantiate the application and you invoke it and the application itself is just an object that has a component a router and an element to render into those last two are optional and then you just invoke the app and when you want to re-render it you just call app.render and components are pretty simple they're just they you they include a mix in define a render method that gives you a that uses this tag DSL and you can see here we're just like a div tag that has some content you call the div method and pass it some content you can pass in properties as well just like react.js uses the the DOM properties API instead of the html attributes for reasons that are actually kind of terrible but so we don't want to use camel case names because we're we're using ruby well that's fine we can use snake case names you can either one also because I screw this up in react all the time you don't have to use class name at all you can say class so and then components they can just take they could take other components as content the components and the virtual DOM nodes that it generates with with div and span and all those other all all those other methods are pretty much interchangeable you know you can combine multiple multiple layers of content with with arrays because single-tiled nodes are not very interesting handling UI events you know on click on submit on whatever you just pass a proc and that proc that proc just compiles down to a javascript function that it gets executed on that event so instead of in place of a proc you can use a lambda or a method object like the result of the method method or any any other object that responds to call and so you can just define whatever whatever class it has it has dot call on it I think I'm probably running low on time Evan okay let's see oh right fantastic all right so still have a lot to get through so this is just an example of something that you could call that you could call it takes it takes the event as a parameter to the call the call method you can use render caching because performance is a thing routing to render render different code based on the you are or render different content based on the URL you can all obviously get parameters just like you know very similar to how you can with Rails controllers with the params method just returns a hash navigating using a special link component things that that handles crap that that really sucks in a lot of other frontend apps where you have back and forward buttons getting all screwed up oh god running low on time there's a whole bunch of gems on that also work with it performance is fantastic don't listen to microbenchmarks because they're terrible time's up Good evening everyone my name is Yulie Yamane I will talk about the toilet implementation is in Ruby This is my talk at RubyKagi in this year at yesterday's Eric session he introduced my talk thank you for Eric so I would like to talk about it here have you ever seen Japanese high tech toilet that Japanese toilet automatically open and closes the deal when you apply the Japanese toilet has a wash rate one water washer and when you press a button it will wash you it will wash you with one water instead of toilet paper for some more that it automatically open and close when person approaches please please see Wikipedia for details I made a model of this wash rate with legomind stones this is a wash rate made with with legomind stones because it is a wash wash rate developed in community called sesame it was called sesame I will show you a movie but before that I will explain the action of it at the beginning the lid is closed as you approach it sensor detect you and lid open like it what is since then you can open the wash rate because if the wash rate move before sitting the flower becomes submit when you press the button it start spraying if you push the button during spraying the spray will stop when you stand up and go out the sensor detects that you are gone the lid closed so please watch a movie as you approach it sensor detect you and lid opens when you use it push the button it start spraying if you push the button during spraying the spray will stop when you stand up the sensor detects you are gone the lid closes thank you just like to use two sensors three motors and two push button the ultrasonic sensor detects person approaching the color sensor determines when whether a person is sitting the motor open and close the lid and performs a spray action the buttons start and stop spraying and start flashing I use real-time OS called EBCRT of TOPAs and make that program with M-Ruby but EBC is a bit expensive so that you cannot easily try it for this reason now I am developing another accessory with EBCRT in this version I use a microprocessor for GRPG made by a Japanese manufacturer named RuneSas it is my it is embedded and Arduino compatible so easy to develop this is a new accessory I am developing however I fortunately I forget bring a battery box from Japan so I can't tell you it's here now I'm very sad but I would like to show more details next year thank you for listening hello Ruby friend hello hi I'm Kay from Tokyo and nice to meet you I'm neither Ruby committer nor Rails committer as well I'm just a fan of Ruby and I'm so glad to say you all to say hi yeah and okay to them I will give I'll talk a little bit about my personal project okay do you know this logo how many here guys you know the this logo could you raise your hand okay maybe 10% or so okay that's that's good are you okay even thanks thanks yes yes nice it's nice and okay let's start so Julia is a programming language relatively new still four years old young and it's a dynamic type language and it's really fast as fast as C in my opinion and Julia has okay maybe I don't have enough time to talk about about so in short write some Julia code then you will get LLVM IR or native code very very easy this is some demo so this is the Julia level and if you type okay maybe clearly you can see that the function hello is defined here and so if you call harder then you will get the string but in Julia you called code underscore LLVM and you pass the a pointer to that function then you will get the LLVM IR very easily write and also the code underscore native function call really give you the native code it's really so it's so easy okay Julia is a seeing now but we are in Rubicon I know so my experiment is what if we can write some Rubicon which can be translated to Julia so then maybe you will get the Julia LLVM IR transferred from Julia which is comes from Ruby right so write Rubicon then you will get LLVM IR or native code so that's the thing I want to show you today so Julia riser which is the Ruby Jam actually is very proof of concept ish Jam so please do not rely on very much but it's just experimental but it's actually working and maybe I can show you some demo today and that's that everything well okay and no so grab it and now okay cool and okay so the simple demo is maybe for example okay okay here you see 2 plus 3 it's too simple but maybe you can see some for example 3.3 for example okay still then well what would be good case okay then maybe well echo depth low 2 times 3 so this is just the Ruby method right and Julia okay you get the Julia function here so what is interesting here is next you can well uh what to do next is maybe called LLVM hello something like this just the key suppression so now you get complete the complete Julia program right now which will be converted oh well ah okay I got a hurry you're over time okay hurry okay which is time to say yeah thank you at the timer is great hey everybody hi it's really nice to be here back at in run so I'm writer Timberlake I work at sales force I'm an iron yard grad yeah woo and I realize it's out of policy to uh give a talk with the backpack on but I'm afraid if I set it down I might forget it and if I forget my backpack sales force might banish me to the roof good it was worth it was worth bringing the prop just for that cool well I wanted to ask a question here to kick things off and that question is in 20 words or less what is the biggest cultural or procedural problem you're facing at work right now obviously we only have time to take a few answers biggest culture yes trust fear of change one more time running out of coffee I mean what I'm about to talk about might help with that in an indirect way still so trust and fear of change you mind if I focus on those okay great awesome so I want to piggyback off of what James was saying earlier about this whole pair programming deal how many of you have any interest in pair programming could you raise your hand of those who have their hands raised right and could you keep them up for a second sorry I should really speck everything at the beginning so I'm not pissing people off so of those of you who have your hands raised so very kindly right now could you leave them raised if you use pair programming in any kind of regular way whatsoever at your job uh-huh oh that's that's hey I'm very pleasantly surprised thank you thank you very much that makes me really happy actually so of those who put your hands down earlier do you find it a hard sell or are you trying at work to push this yeah yeah I find the same thing it's tough do you have any interest in this kind of thing in the pairing okay awesome cool cool yeah for for mentoring very cool so you you've seen this work out I want to do a thing now we're really good oh sure uh yeah well I mean it's uh it's often good like either I'll instruct and they'll type or vice versa or switch back and forth it's a you know them typing is a good way to make sure that I'm not completely losing them and you know me typing can be a good way for me to run off in a random direction and lose them so you find that it gives you a lot of feedback in terms of where they're at yeah absolutely yeah is anybody getting the fact that I didn't plan this out yeah well thank you thank you very much so pair programming is something that I have found in my limited experience to be incredibly useful as far as building trust as far as overcoming the fears that we might have they're just naturally part of working in a landscape that tends to move at a very frantic and frenetic pace that is not really concern itself over much with important things in the ruby community such as developer happiness such as building tools which are enjoyable to use which are transparent which provide good logging airing we could go on for a very long time in this particular vein pairing can address some of those things very directly when you put two heads together and you have good communication if you are one of those people who put your hands down and you are interested in maybe trying to get something going at your place of employment obviously I would recommend just from what I've seen since I've been here speaking with some of the Maven link folks it's it's very exciting what they're doing over there and I'm sure from what I saw there are a number of other people where this is very common at your place of work yeah okay she she nodded and said that's correct so yeah and if you're interested in kicking it off I would document meticulously what you're doing I would document your use case I would document your pros and cons right and any other observations you have and just keep a really rigorous log so you have some empirical data that you can go off of and I wish you the best of luck so a lot of what I do these days is to try and make a program faster and if your benchmark's noisy that's kind of an interesting process by which I mean often I'm wrong so normally when you profile what do you do you run a few times how many well pick a number you find out how long it takes to run you divide by how many times you ran it and then for the second program you do about the same thing so that's enough right well it's not real deterministic you're going to get different time different results every time you do it if you run it on your computer that you use for anything else other stuff runs in the background or if you run on a dedicated DC2 instance you're assuming amazon will never run anything in the background yeah you get different results if you keep trying it how many times do you have to do it before you get the right answer so you've got a bunch of samples and you ask are these things basically the same hey like statistics that's kind of what it does cool well just t-test I looked it up in Wikipedia so you don't have to and doesn't this kind of look like another thing we've seen yes a b testing the other thing where we say turn to the statistician do do what he said um so if you want to write a welch's t-test go use syrupy why not write it even I mean Wikipedia tells you how to write it you just write it right no never write a statistics test you don't know cold if you get it right the first time you're way ahead of me so okay I wrote a little program to do it for you using syrupy I didn't write the welch's t-test there either I called it a b compare it's got some cute options but mostly if you've got time to wait for it to run a minute don't use the options just type a b compare and then put the first command in quotes and the second command in quotes so if you thought hey there's this act thing that searches your directories for a particular phrase and there's there's silver searcher ag which claims to be faster I wonder if it's faster you type a b compare ag the thing you want to find act the thing you want to find hit return go for a coffee because it's waiting until it gets statistical significance so like an a b test it always takes way too long to run but that's okay you can get a coffee it'll sit and run silver searcher for the record is about 36 times faster in my Ruby source directory so you may find a similar thing because it skips all the built files and intermediate stuff which is important if you've got a bunch of see and see an object files now I know if two things are clearly different it'll run for a little while and then pretty quickly stop because statistical significance is easy if the two things are very far apart so it'll give you smaller and smaller p values because that's how a b testing works and then it'll stop and tell you about how many times faster it is if they're the same it'll keep running and trying because it can't find a difference and eventually it'll give up and say as far as I can tell they're the same because that's how the statistics wind up working or as I say here p value stays high no convergence same thing I use it for big stuff and so it does work for big stuff if you've got Ruby in one directory Ruby in another directory you built them both and you're saying did I make this faster or not turns out you can tell ab compare to cd into one directory and run a benchmark cd into another directory and run the same benchmark it'll cheerfully go back and forth running the two so you can eventually you know find that out so opt caret which is a benchmark some of you have heard about in these talks you can use it to check the stuff it does actually work I'm using a slightly more complicated ab prof but it's the same gem it's basically the same program so if you turn profiling on is it slower for instance yeah it's like three times slower you could run it once and get more or less the answer but hey look statistical significance that's probably good if you if you compile in Google perf tool support is it slower not as far as I can tell running many many many times so that's that's good to know again it's nice to be able to check and this is one where if you run side by side you pretty much can't tell because opt caret is noisy the benchmarks we're using are noisy I also found out you can turn inlining way up it shows how on the on the bottom there when you're building Ruby and you can get a seven to 10% speed up there's a cute blog post I wrote about it but again you can check it and if your benchmarks are noisy it's hard to tell this can be a good way to check did I speed anything up anyway opt caret's noisy takes a lot of runs that's what I built this for can you get a copy great yeah it's on Ruby gems if you gem install a B prof and you do that a big compare thing it just works it's pretty straightforward I wrote several blog posts about it on engineering.appfolio.com so you know plug for that is this a new idea now opt caret has a script to do some statistical profiling stuff it's just hard coded to opt caret people have done this before but it's nice to have a really easy tool any questions awesome hi i'm chris vanoie I'm from indianapolis I recently did a event called Plymlo McGotty that spelled I'm not gonna spell it it stands for programming languages I've been meaning to try but I haven't gotten around to yet and I want to strongly encourage you it's just pick a Saturday gives people coffee give people pizza have them come in leave their families and woes behind and concentrate on some programming languages they haven't tried lately sometimes that's Ruby and that's how it's done this is your daily reminder that there is still good things in the world and good people I implore everyone who hears this to be the latter and build the former thank you very much I'm Amit Junction hey there's some slides hi I'm Misha much like Noah I also work at Appfolio yes we are hiring yes we talk a lot the title of my talk is that was easy applying your work skills to a side project I'm gonna talk a bit about a side project I've been working on and currently working on and will continue to work on so it started with a user problem as these things often do up in the corner there is my grandmother she is fantastic she lives in Portland but over the past decade she's been developing some low-level dementia it's actually been great for her because she's been forgetting bad things and been generally really positive because every day is the best day ever which is awesome but she really loves watching nature documentaries and travel documentaries and one problem is that she can't really use modern technology anymore so this is a problem you know I like it when she can watch things that she's enjoying so I started thinking about ways that I could provide her with a simple solution to that problem this problem has some well-defined constraints as I mentioned she's not very technical so that's a huge constraint right there she has nurses they're very good people and they work really hard but there are a lot of people for them to take care of so the solution I build has to be easy and fast so that they can know that it's working and move on to the next person that they are working with it started with a gag toy this is the staples that was easy button actually called the easy button but I don't like that name if you don't know it it's really obnoxious it's really fun to play when you like merge something in it's really fun to play when you beat someone at foosball that you're very contentious with and it's very fun to play randomly and I was playing around with this button one day because that's what I do it's the kind of person I am and I was thinking to myself this is a really great interface it's a button you press it a thing happens you press it a thing happens it's reliable it's tactile it's fun what if I can combine these two things and use the button as a solution to my user problem so it started simply I started by taking a raspberry pi 0 which is just small enough to fit in the bottom of it that was easy button and I wired up a little button to it I soldered it on and I made it so that on the raspberry pi when you press the button a little python script would say played and when you press it again it would say stop all right very simple and then I iterated on it just like we do every day so I took the script and I was like okay well eventually we're going to be able to play video files but we don't need to start by playing let's start by picking random videos my grandmother doesn't really care which one she's watching so I created a directory and modified the script so that when you press the button it would say play and then the name of a random file in that directory and when you press it again it would say stop press it again play new random file you guys get the idea then I took apart that that was easy button which by the way is really fun and really easy that is a very well built button like the tactile it's fantastic and I slid the it's really good and I slid the raspberry pi into the bottom replacing the speaker and then I wired my button I replaced their button with mine and ran the wiring down to the raspberry pi and put the button back together and ran an HDMI cable and a power cable at the back when you hit the button now instead of sorry now when you hit the that was easy button you get the same thing before right play and the movie name the final change of course was to instead of saying play movie nine call a movie player and it played the video at full screen press the button again and it kills the movie player it isn't over yet so I'm going up to Portland next week it's my favorite city to visit my grandmother and I will be user testing us with her so I will be testing it with her with her nurses figuring out where there are usability issues that I can fix because this really does need to be simple and reliable a couple of things that I know I need to do I need to set up a splash screen because the raspberry pi is a little slow to boot that lets people know that it is booting and not to try pressing because you don't want to set false expectations for people and I need to set up a screen that shows at the desktop a background image that lets people know that if they press the button a video will play all right that's it like I said I will be in Portland next week for the next week and a half this is my first time at RubyConf you guys are awesome like please hit me up I would love to grab a coffee grab dinner go to a brewery a micro brewery a micro micro brewery like you know let me know and again I work at Atfolio we are hiring we're a really fun place to work Noah is a fantastic person to work with so you know let me know if you're interested thank you very much well thank you I feel very lucky so I'm Jeff Foster I'm a computer science professor at the University of Maryland College Park I've been having a blast at RubyConf this is great so I want to tell you a little bit about some work I've been doing on types for Ruby and I have to warn you that that little logo is the only picture I have in my talk sorry that's not very exciting so this is a tool that I built that you can actually try it out those are the coordinates it's called RDL please do not ask me what that stands for because I don't know and it gives you if you want optional static type checking for Ruby so this is not what Matt's was talking about he was talking about inference this is checking requires annotations and the moral the the the rule is you get what you pay for so if you want to write stuff down in your program you can check it if you don't want to write stuff down fine there's no cost for that also uses some it also does something called contracts but I'm not going to tell you about that and I have to warn you this is a prototype so it hasn't been fire tested but it does kind of work so if you have comments and feedback so I'm going to try a live demo now right okay so please wish me luck here we're going to see how this goes all right so here's the program this is a fantastic program I wrote okay so I wrote a method called the answer returns 42 right and I could write a test case for this program but if I want to use RDL I could also write a type for it so here's how you do that with RDL so you require the RDL gem see if I can type require RDL and then you say type this takes nothing and gives you back an integer and I want to type check this right now after it's defined and notice I actually made a mistake in the program actually I was supposed to return an integer not a string and I run this with RDL I don't know if the font is big enough I think I'm going to have to make it bigger when I run it you get a type error that says got type string will return type integer as expected yay type checking demos are kind of boring sorry all right so obviously type checking one line program is not very interesting it gets I could write a test case for this trivially but maybe it gets more interesting if say I take an argument x and then depending on x I either return some value or I return 42 so now I have to write two test cases for this but I only have to write down one type and it will check both paths all right see live demo it's very risky all right so I have to write down a so I only have to write down run type and I still get a type error that I got a string where integer was expected so that was pretty good and it's even better if you have your code in the middle of say maybe an error case where it can be really hard to trigger that right so obviously that's not going to trigger an error but maybe there's something complicated here and it's really hard to figure out how to get that to raise an exception to trigger the error case so maybe types are good there now of course you don't just want to type check stuff like this you might want to like call methods because that could be useful right so here's here's a method I'm returning three plus four and if you try this with rdl it complains well that's a long complaint it complains it doesn't have a type for fixed num plus right so if that's your own code that you wrote you have to write down a type for it that's what you have to pay for but if it's part of the standard library you can actually get that if you're lucky enough that I actually wrote it down before which I did for this so if you include type slash core then you can type check this program and it works fine right and these types are actually lying around and you can ask about them so you can say what's the type of fixed num plus like that there's a little command line tool and tells you well plus has all those different possible types you can ask for all the types that are part of fixed num there are a bunch of them you can ask I don't know why you'd want to but you can ask for every method that takes a fixed num and returns a fixed num there they are at least those are the ones I wrote down and you can even ask for everything that takes anything and gives you a fixed num if you're really desperate for a fixed num and can't think of one right all right so there's a lot more to say about that that was really quick so check it out this is a prototype I need lots of feedback but I think it's kind of cool kind of fun let me know what you think thank you