 My name is Benjamin Fleischer, and I work at a company called Swipe Sense where we save lives by providing analytics for hand washing at hospitals. But that's not why I'm here. I mean, it's why I'm here. But that's not why I'm standing on stage right now. It's because I love to get everybody up and excited. So everyone stand up, stand up. I'm on stage, so you have to do it. All right, give a little stretch, a little stretch, a little half inning, all right. Thank you, just eight, help digest a little bit. And I'm gonna take a picture, and I'm gonna send it to Aaron Patterson, because I know he likes pictures of lots of people making hugs, so this is an iPhone. But I'm gonna try, I'm gonna try. One, two, anyone, any designers know how to do Photoshop? Just put Evan lying across everybody. So that's really all I have to say. I also like JSON APIs. Hi, I'm Heather Harrington. 10 years ago, I was an emergency veterinarian. Five years ago, I had my own event planning business. And then about a year ago, I started to code. I heard about a program in Seattle called Ada Developers Academy and said, sure, why not? And applied. They have an 11% acceptance rate and somehow took me. Cool. So I used to live in Pittsburgh and I dropped everything and moved across the country to Seattle. And unfortunately, I left behind my husband and my pets. You'll note that the pictures are of the pets and not the husband. Hi, sweetie, I know you're watching, sorry. You may also have noticed that the slides pretty much have nothing to do with what I'm saying and that's intentional. If I'm boring you, there are cute animal pictures. And if that bores you too, get out and we can never be friends. So, show of hands, who in the audience considers themselves a newbie? Call that whatever you want, less than a year, less than two years, you're new. All right, decent number. Show of hands, who considers themselves to be non-traditional, self-taught, boot camp, anything like that? All right, and again, decent number. Who here has ever been in charge of hiring? Give it thumbs up, thumbs down, in some way picking who's going to work. Excellent. This talk is applicable to all of you. It's also applicable to those who are new and not necessary or who are old enough to not remember what being new is like. Being new is hard. Learning how to code is really hard. Way harder than I ever thought it would be. I have struggled learning how to code more than I ever struggled in veterinary medicine or as a business owner. It's really hard. So if you have someone on your team who's new, only, like, oh, that's only this, oh, that's easy, that's something simple, oh, that's just this line of code. Yeah, banish those words right now. If you are working with someone who is a junior developer, everything is hard and please try to remember that. A friend of mine who's at Aida Developers Academy with me is an intern at an unnamed company and she made a mistake. She messed up, she's an intern, she's new, she's human, she made a mistake. The senior developers got together to laugh at her. Don't be that asshole. If there's a junior on your team, don't make fun of them, things are hard. So the reason why I'm up here is to explain to people the merits of hiring a junior developer from a nontraditional background because as you can see, there are a lot of us. Number one, we ask questions and if you are a junior who's not asking questions, oh my god, ask questions. I just got my midpoint feedback from my internship and one of their things was the awesome questions that I ask. If there's something weird, like I said, I'm interning at Amazon, they have all sorts of weird things that they do. If there's something that I don't know, I've learned to say, I don't know this during standup, like is this something I should know? Is it a weird Amazon thing? And it forces them to explain themselves and I'm kind of their fresh perspective. They value that, so be that person and if you're hiring, recognize that it's valuable to have that on your team. Also, because this is my third career and a lot of people who have been pursued nontraditional career paths, this is their second career. They've been around the block a little bit. I'm good at adulting, like I can do it. I show up to work on time, I work my butt off, I get home, sometimes I work at night. It's not something that you need to teach me as a fresh college graduate. And I mean, I remember my work ethos when I was younger versus now and it's different. Last thing, diversity. People always talk about wanting to increase diversity in tech. There are a lot of women in boot camps. Put your money where your mouth is and work on hiring those people. In addition, people from these boot camps or people who are self-taught come from a lot of different backgrounds. I was a vet. I'm good at approaching things in a really logical manner. So anyway, thank you very much for listening to me. If you want more information about ADA or more information about me, I'm wearing the llama corn. Hi, my name is Casey and I am currently a student at the Turing School of Software and Design in Denver, Colorado. So I'm very, very new to tech. I'm excited to be here at RailsConf for the first time. And I'm here today to talk to you about how teaching computer science can bring K-12 education into the 21st century, hopefully with your help. So I'm gonna start with just a really quick poll. First question, what most influenced your career path? If you tried it and you liked it, raise your hand. That's most people. If you saw it on TV and thought it looked cool, raise your hand. That one guy back there. Second question, I had a basic understanding of my field before entering it. Hands up, yep. Again, most people too, nah, just balls of the wall wanted to try it. Okay, a couple of you fearless people out there. If you were here for the keynote earlier, you can note fearless. You don't even have to answer that question. So surprise, most people who enter their field tried it, liked it, and had some kind of understanding. This is where we are failing our students, is most schools in the US do not teach computer science. There's a huge gap here. 90% of parents want their child to study computer science, but only 40% of schools offer these classes. And this was the statistic that was most astounding to me is 54% of schools have a one-to-one student-to-device ratio, which is a big difference to 40%. So what's happening there? Clearly, we are not using our resources very well. And this gap, these statistics, that is why I am standing here on the stage right now. That is why I went to bootcamp. I was working on a project to bring people together in Colorado to address these issues, because currently only eight states have created K-12 computer standards, which to me is mind-blowing. And that is up from last year, last year it was seven states, so it's slowly increasing, but not very fast. And 33 states plus the District of Columbia, computer science classes can count towards any kinds of graduation requirement. In some states, that's science. In some states, that is math. And that to a high schooler can be really intimidating, especially if they don't feel like they have those skills. And what kind of a high school student is going to take a class that they don't get credit for? Not very many, at least from my personal experience with high school students and having been one. And as you can see, this is also increasing, but not as fast or as rapidly as at least I feel like it should. Here's a little bit more data. You may say computer science education is on the rise. And I will say it's on the recovery. We almost have as many computer science graduates as we had 10 years ago. The dot-com bubble kind of made that decrease for a while. And as you can see, less than half the number of those are women as were 10 years ago, which to me is very astounding and is why this work is so important. So what can I do? We have these skills. A lot of the reasons that there's a really big decrease in the number of courses offers is there just aren't teachers who can teach it. And so there are things that you can do to get involved. Code.org has a number of activities that you can get involved in. You can host an hour of code. You can volunteer in an AP computer science classroom. Or if you have a little bit more time to offer, you can help out with the TEALS K-12 program. Woo, snaps for TEALS. And you can help out in a classroom for a year in a school near you and help directly with your community. So I hope that I've at least started to highlight some of the issues of the K-12 CS education landscape that we have here and hope to see you involved as well. Woo! So hi everyone, I'm Kristen Rubin. I'm a developer at Workbar in Boston and I'm here at RailsCon for the first time and I'm really excited to be here. Woo! Today I'm gonna talk to you about couture sewing and coding. Lessons from sewing, a wedding gown. This was a pair programming experience, if you will, with a friend of mine. First of all, why sew your own wedding gown? I don't have a good answer to that. My answer is because crafting is the greatest and really you can't justify it otherwise. You have to think that. My friend's inspiration was my own wedding. She said that she liked my dress, she liked that I made it at my own wedding and wanted to do it herself. I told her, absolutely not, don't do it. I finished mine 10 minutes after our ceremony was supposed to start. But she said, no, no, I really wanna do it. I think it'll be fun. This was about this time last year. And I said, okay, well, you're a good friend of my wife. And although I don't know you that well, I think that if you're gonna do this, I'm going to do it with you every step of the way because it was very lonely for me. Before I get into the whole process, I didn't know what couture really meant before getting into this. What it really means is any handmade garment that is sewn to the specifications of the wearer. It doesn't really mean much more than that. So we set out to make a couture gown for my friend that was completely made up except for our business needs, which was this picture she had found on Instagram and she wanted to copy the stress. After doing a little digging, she determined that it cost $50,000. And so decided that buying it wasn't an option. Kickstarter wasn't an option. But when we started out, we didn't really know why it would cost $50,000. We were like, this is a really pretty dress, but normally. Basically to analyze it a little bit, it is completely hand-beaded and hand embroidered out of the finest silk. So that's what we wanted to do. The iteration process was, when you make any gown, you first need to make a muslin, which is a prototype out of cheap cotton. So the center picture here is a picture of the muslin in progress. And since it was a kind of complex dress and needed some lift to the butt area, she made a cage for the rear and the skirt hangs over that. And then we did a lot of practicing, of embroidery, of silk, to figure out what she liked the best and what looked the best and what looked, most importantly, just like the picture. So here's a picture from a few weeks ago of the almost MVP. Her, another friend, is a shoemaker in Milan and made shoes for her for her wedding. But they haven't arrived yet and her wedding is Saturday. So we have not hemmed it yet and this is not with it zipped in the back and everything. So just to give you an idea of the overall arch of making this dress, it took 11 months. The most important takeaway from making this dress though, I think it's wrapped up in this Abraham Joshua Heschel quote. He was a pretty famous rabbi and he talked a lot about the sanctity of time. And to me, that really resonates in this dress because we definitely spent more than $50,000 worth of labor on it. She's a high-end patent attorney in Manhattan. She bills out at like a zillion dollars an hour and we spent probably a couple of thousand hours on this dress, so I don't know what the math is. But anyway, looking at this gown, it represents a lot of things. It represents basically taking not a Queenton's ship, but almost a baby friendship and it grew into something that was way more than that. We are now practically best friends and it was just a really amazing experience. You would think though that it would be really hard to work with somebody like a bride, bridezilla on their wedding dress. On the contrary, we learned a lot about communication along the way that I think is really applicable to pair programming. We never took anything for granted. We complimented each other on our respective skills at every turn. She lives in New York, I live in Boston and I came down to New York every few weeks to work on this dress with her. Every single time, she didn't expect that I was gonna show up. She, every time I announced I would come down, she was like, thank you so much. It means so much to me. Similarly, I never took for granted that she was gonna like what I was doing. I pretty much always asked, are you sure this is my sewing handwriting? Are you sure this is what you want? And basically the takeaway here is that good communication skills can go a long way and you can develop a really beautiful thing out of it and hopefully good code. If you have any questions on this whole process, you can find me on Twitter and email me. Right, perfect. I'll quickly tell you about Rails and Postgres and how to scale that. I'm Lucas. I work at a company called Citus Data. You can find me on Twitter. So typically when you scale your application, initially you have one Rails, one database. Soon you have multiple Rails servers, right? But you still have one database. And so this kind of becomes a problem and you wish you could do this where you just add more databases. I built a gem called Active Record Multitenant which in combination with a Postgres extension called Citus enables you to essentially scale out your database. So you don't have to worry about all the integrated details. You can keep doing Active Record things. It just works with monkey patches behind. If you're interested in that type of topic, bit.ly slash shard Postgres, it's sharding underneath but you don't see it in your app. And I also tweeted a link to that if you wanna look at that. Thank you. Hello, my name is Justin Collins, President Beef on the internet. I heard a few of you aren't using Breakman yet so I wanted to give you a tutorial. This is it, you install it and you run it. You can put it in your gem file and bundle and stuff but that doesn't fit on a slide as nicely. You'll get a report like this with some security warnings about potential problems in your code. If you want a nicer output, you can use the plain one or the HTML one or if you have a budget, you can buy Breakman Pro and get this interface. However you do it, throw it in your CI, automate it somehow. And if you wanna find out more, go to one of these locations. If you want stickers, it's required to hand them out at RailsConf. I have them tomorrow afternoon, 2.40. There's a security birds of a feather. I'd love to talk to you there. Thank you. Okay, hi. I just wanna show you a quick micro performance improvements that I've found over and over again in Rails applications. My name is Ernesto Takwerker and you can find me on Twitter as Etakwerker and all the code you're gonna see is from my code and other people's code. So don't feel embarrassed if you have written that before. So this talk was inspired basically in Babadsob's Ruby style guide, which is a great resource if you haven't seen it, please go ahead. And in SFRx writing fast Ruby. So let's look at bad code versus good code. Okay, time parse versus time add. Basically, if you can use time add and not time parse and you can see the performance changes or the difference is like 24 times slower if you do use time parse and you struct instead of hash when you can because it's like five times slower if you use hash and I'm out of time, but... It goes fast, doesn't it? If you're interested on this, just go there and look at more of the sample codes. For all this I use Evans gem benchmark IBS which is great and I... I don't know what he's talking about. All right. An ounce and a pound are in jail. The ounce turns to the pound and says, hey, what'd you do? Kilogram? Teach me, master, teach me. Quick show of hands. How many people know what this means? Minus one. Okay, now let's do the opposite. How many people have never heard of this? Wow, it's definitely more people have never heard of this. This stands for maths is nice and so we are nice. Early on in the days of Ruby when it was mailing lists and like four people, they would typically use this as kind of an axiom or a little motto of the Ruby community and I remember hearing about it early on and loving it and it's just kind of a general like don't be a jerk, don't do the typical things that you expect programmers to do on the internet and I think it was a really good kind of foundation for the Ruby community and I wanna make sure that everybody understands about minus one. So as you go out there and are interacting with other people, continue doing what you've been doing all the conference along and continue to be nice just like maths. In the spirit of being nice, I help with a conference. The conference is called Ruby for Good. We're dedicated to making the world gooder. It's a once a year conference. We meet in a beautiful location in the mountains in Virginia and we work on wonderful projects. For example, a project that we help with Red Pandas and not just Red Pandas, there's all sorts of organizations that we help with. Typically nonprofits, sometimes open source but the rules aren't too strict and we work on these things. We get together. It's a four day conference. We head down, plan on working on projects. We need leads to work with stakeholders to get together and then we work all day and then we hang out in the evening and make friends. So I wanted to bring this up because if you want, this year's sold out. So sorry about that. But we would like to have folks like you come out next year but we're also constantly on the lookout for projects. We need people that can lead projects. We need nonprofits and charities that need work done for them and folks like you to pay attention to look for that. If you are interested, and this is the shameless part of my talk and helping out, you can buy a t-shirt which everything that goes towards the t-shirts goes towards helping our scholarship fund. So we'll get people that can't afford to come to the conference and pay their way. So thanks. I'm C.R. Sexton on the internet or Ruby for good and I appreciate it. Thanks. Hello. My name is Mike Topa. I work for EcBlue. We provide, oh, that would help. I'm anchored to the mic. Okay. All right. I don't have no second one. Okay, go ahead. I work for EcBlue Technical Services. We provide software for fundraising for democratic campaigns, committees and also for nonprofits. And I'm here to talk to you today about why planes crash and lessons we can learn for both junior and senior developers. What got me thinking about this was a book called Outliers, the story of success by Malcolm Gladwell. And he has a chapter in there where he talks about plane crashes. In general, the book is about, we think of people we've seen different walks of life who are successful and we often attribute that to their, maybe their native abilities or when people screw up that they did something wrong. And an underlying theme of the book is that they're often really systemic or environmental explanations for these things in addition to the person's abilities. And like I said, there's a chapter in there about plane crashes. And I thought, this kind of reminds me of some of the things that happened with developers. So why do planes crash? There are many reasons. The one I want to focus on since I just have a few minutes is poor communication among the cockpit crew. And what happens often is the more junior pilot, usually the co-pilot, may observe a problem or something they're concerned about. But the captain, usually a more senior pilot, is in a position of authority. So they engage in what's called mitigated speech. They sort of drop a hint about the problem rather than really speaking firmly and indirectly about it. So this is called mitigated speech. And we do this when we try to downplay or sugarcoat the meaning of what we want to say because we're being polite or feeling embarrassed or being deferential to authority. The problem with this is a hint is the hardest kind of requested to code and the easiest to refuse. So let's look at a couple of examples. Air Florida crash in 1982. There was ice on the wing of the plane, which is a dangerous situation. And the first officer is really paying attention to this. But the captain really isn't, captain's tired. He's not paying attention to it. And this is from the black box recording after the crash. First officer saying, look how the ice is just hanging on back there. Do you see that? Boy, this is a losing battle here on trying to de-ice those things. Here's your false sense of security. That's all it does. He's talking about it, but he's not really emphasizing just how dangerous this is. And plane crashes a few minutes after takeoff and 78 people on board died. Another example. So 1990 Avianca Airlines crash. So this is a plane that is literally running out of fuel. It's common to be low on fuel when you're about to land. This one is literally running out of gas. And again, the first officer sees this and he's talking to air traffic control. And the pilots, you know, supposed to be listening to. So he's saying, climb and maintain 3000 and we're running out of fuel, sir. Air traffic control responds with a command to continue circling, ask for confirmation this is okay. First officer says, I guess so. Thank you very much. In talking to the stewardess who was the only member of the crew to survive, she walked into the cockpit at this point and the engineer made a throat cutting motion to her. I mean, they knew there was a problem but they wouldn't speak up to air traffic control. They wouldn't speak up to the captain playing crashed. And I can't see my notes. I forget how many people died, but a lot. So when airline crashes happened, they're studied very thoroughly for lessons. And what they've learned is crashes are more common with the captain. More experienced pilot in the flying seat. And so there's a quote from the book. Plains are safer when the least experienced pilot is flying because it means the second more experienced pilot isn't going to be afraid to speak up. So like I said, I think there's lessons here for developers, for junior developers. When you see something, say something. And you have an asset no one else has. You have what's called the beginner's mind. You're new to the organization. People who are veterans of the organization have been there a long time. They develop line spots. They get used to things being a certain way. You are looking at it fresh and you can point out, hey, this seems odd, this seems strange. Can we talk about this? And I know this kind of thing can be difficult when you're junior, you're just starting out. There's a posture syndrome, you're not necessarily feeling confident. But if you're, there's seconds. Okay, last slide. One of the two things should happen when you speak up. You'll be right and be appreciated for it. You'll be wrong and still appreciated because if you're working in a place with a good environment, this will be a learning opportunity. Senior developers, mentors can use it as a teaching opportunity and they'll appreciate that you're paying attention. Senior developers, be good mentors. Be humble, be empathetic, be encouraging. And you can get the same benefits that pilots have when the more senior person takes a back seat. Thank you very much. So my name is Isaac Sloan. I love Ruby. Don't let the things you're about to hear convince you otherwise. I'm here to talk to you today about a new language that is fun like Ruby and it's called Crystal. So really fast. I do not know why this isn't full screen, but whatevs. So this is crystallang.org and it has some cool examples on it and generally how to make a very simple HTTP server. Anyway, here's a framework. It's pretty much on parity with Sinatra but like incredibly much faster. And I'm going, there's a few other frameworks. There's a lot of open source going on in this community. I'm going to talk about a framework, MVC called Kemalase today and some generators that I've been contributing a lot to both of these projects. Other people have written a code too if you care what, you know, get blame. So over to the terminal. So here, I'm just gonna generate a quick blog-ish object. So our binary is called kgen. So kgen init app. I'll just call it blog go. Okay, cool. So I'm going to see it into blog and you see there's a basic file structure set up here. So I'm going to run a crystal long keys. Crystal depth, which is basically bundle install. Assuming my internet doesn't blow, that will work. Let's hear, read a joke while we're waiting. This guy's brave. So, yeah, here, joke, read it. Machine, please make website. Oh, you meant me, right? No, not really, not fast enough. Okay, cool, it's done. Okay, so kgen generate scaffold. It's not how it's spelled. Scaffold post, title, string, content, text, tags, string. Go, okay, cool. So that's there. Now let's just start it up in Docker. So we'll just run doc compose up. And cool, you want to finish the joke? Here you go. With big pictures. Ooh, use my favorite. Is this supposed to rhyme? I know it isn't. You're ruining it. I should have read it. Anyway, here we go. So, Docker's setting up Postgres. Should be running migrations. There we go, migrations ran. And, yeah, should have a port open here. So let's go check it out. So, okay, it is not actually running yet. Let's go look at, okay, there we go. Now it is running. Cool, so here we go. Basic scaffolding, basic homepage says nothing. Well, I mean, that's something, but what else? So come over here, you have a post, have new, say, welcome to here. Thanks for coming. And so there. So that works, you can edit, read, delete it. Let's just look at the code really fast and then I'll get off stage. Here, I'll just background that. You got a minute and a half, so you're good. Oh, oh sweet. So here's some code. Way too small, I suppose. I gotcha. So, here we go. So we have your config, have database jammer, as you would expect. Come down here. Instead of app, you have source. All of your specs are here. Specs actually look pretty nice. Somewhat like you would expect from our spec or mini-test.spec. Those are crap tests. Okay, here we go. So those will all pass, but let's not run them. So here's the actual controller. Here's the post controller. You have action index, action show. See we're rendering. We have flash messages. We have redirects. Yeah, and it all works. So if you feel like playing it, playing with it, again, there's chrysalang.org, chemocr.org, ambercr.io. And then chemolist is the one I just demoed with chemolist generator. So, enjoy. Well, it helps to plug it in. My name is Reid Morrison. I'm the software architect at Clarity Services. I was, I mean, extremely passionate about Ruby and I was very excited when Rails came along because then I could turn my passion into my career path. So I'm sure all of you have seen code like this. Rails, one of the biggest success factors in Rails, it makes our lives fun, it makes it easy. Makes it easy to do things. So we can look at a very simple actual record model, put in comments the fields that it has, because you can't see the database here, but those are the fields, first name, last name, strings, dates and integers. Then we can do validations. We can also do callbacks. So when before gets destroyed, I'm sure you're all familiar with these capabilities. And then we wanna create a user. We just say user create, give it some fields and it's created that model for us. If the create fails with the bang, it lets us know straight away there's an issue. If we must type something like last name, you say last name without an underscore, it lets us know immediately. So there's no debate as to whether we created that model correctly. So this is bliss. This is what we wanna do. Now your manager comes along. You're not allowed to use active record anymore. Okay, well, that's what it looks like. You can do a select one, we're dealing with hashes now. You know, it's awkward if you put the wrong spelling in there, things are not the same. This is not what we want. So let's have a look at active job. I'm sure many of you have tried out active job for doing background processing. It's a great layer for isolating your application from whatever background job system you wanna use. So we can have a look in there and somewhere in there, I'm starting to see hashes again. But if you can see that there's an end date and a start date, there's even a default for the end date. So going down to the arguments, let's look at the start date, 30 days ago, end date. But there's something wrong with those variables. I left out that underscores. But guess what, when I kick that off, I have no idea there's a failure. There's no errors coming out. Well, what about validations? How am I gonna validate that what the data I supplied is correct? Well, you're gonna find it later when that job fails in the background. So doesn't this feel more like if we look at active record model, it is going down to the device driver level. We're actually dealing with the raw data underneath. So here's a proposal. Let's, we're doing the same job we did just now. This is now a, it's a reporting job, the same one. We got a start date and end date, the actual fields with actual data types. There's a, they are defaults. We have validations. So we also have callbacks. And this is essentially taking active model and applying it to our background job processing. Again, so we look at how we create the job. We just create, just like we create a model. You can see it's reporting job.create. It's right there. If I misspelled it, like I'd put the end date there without an underscore, it lets me know immediately if there's something wrong. If the validation fails, it lets me know. So this is, this is what makes us, makes it fun. This is what we wanna see. So to prove out the concept, we actually put something together, a rocket job that I own, give it a try. My challenge to the Rails team and those working in active job, in the next generation, version two, can you build this in? We want data types. We want validations. We want callbacks. Thank you. Have a great conference. Okay. I am Alejandro Corpeño from ICOMS. We are a small consultancy firm. We build Rails apps and iOS and Android. And my Twitter handle is corp. So I'm gonna talk to you about a site project kind of internal tool we build to keep track of progress and deadlines in projects. We have a remote team. So we have an office here in California and the dev team in Honduras. We have like 15 people working there in Honduras. And as we started getting more clients and more concurrent projects, our project manager started to get a little crazy with all of the year stories, following up deadlines, weekly calls with clients. We're using Slack, Gira and some other tools online. So the main need that we had at that time and the problem was we needed a single dashboard. You have to see all of the clients and in those clients, all of the projects for individual tasks, but not at the user story level. We have that in Gira, but just important things like for this week, we need to have a follow up call. We need a release. We need to do QA, whatever. So the initial solution, and this has been going on for years, is just use Google, right, the spreadsheet. So this is like a spreadsheet I had like in 2015, looking at month availability of resources. So the blue is we're busy. Then the yellow is we have some downtime and we can assess resources like that. Then this evolves at week level. So we have weeks in every month. We have different levels of color coding for busy, doing review work, maintenance. And then this continues to evolve. To today, we were using this one where it's not only for our planning, but we share it with the client. So the clients can see what the milestones are when we're gonna deliver something. And the most important part is that we collaborate with the client to decide like we should leave this date or we should change it and then keep track of those changes across all of the projects. And if you can see there, we have the Gira story linked and the users in Google Docs just seeing everything change in real time. So at some point we said, okay, we'll be using spreadsheets for too long. Let's build an app that does just that so we can do a system for that. So the main stakeholders for this is the PM is the first person. So you can open up this app and see everything you have for the week. Then the lead developer or the head of engineering and the client. So we want the client to be able to see these for transparency. Other people is the developers that are working on the stories and everything. And from the client side, some product managers and project managers. The most haves that we identified is we need to be able to see the weekly events. So it could be a follow-up call, a release, could be anything multi-user. So we need to be able to invite multiple users. The real time feedback is really important that we have on Google Cheats. So we wanna have that. We wanna be able to audit, see all of the changes on decisions that are important for dates and link to your project management tool. So Gira, Basecamp, Trello, whatever. We wanted to take this opportunity to play with Rails 5. We hadn't played before because we're doing maintenance on old software. So Action Cable is for the real time and Troubled Links we wanted to use just to take advantage of the hybrid mobile apps. The one thing we wanted to stick to is let's not come up with problems. Just solve the problems that we have. So whatever we do on the spreadsheet, let's do it here. So we spec that out, did a spreadsheet for this project and this is the first demo we're doing. So I took a screenshot, a video so you can see it working. This is the actual app. We've been working on this for like a month and a half or two and you can create the spaces, you can drag and drop the position of the items. If you change the date, you have to justify it and then you see a lot of the changes there. So whenever you change something, you have a story of why you changed the date. You had comments. So every element is kind of like the same spreadsheet but done in a way where we can keep a better follow up. Here we're creating a new item. Then we set it up for a date on that week and that's how the whole timeline for that starts. Also the releases, for example, we created the concept of a Kraken. So release the Kraken, that's something we had as a culture. So we made the Kraken part of the symbology there and the action cable feature like the techie thing. You see the icons there, the R and the S is other users joining. So we can see who's looking at the app and you can see the shading down there and one of the arrows on the rows means that someone is editing while I'm using it. So we kind of replicate the Google Sheets feature. So with that, we're in this process and you can check it out if you're there because we're doing deployments every few hours but you can follow me and send any feedback. We appreciate it. Thanks. Looks sweet. Heisenberg, Shredding or an Ohm are driving in a car. I'm gonna cop pulls him over. He says to Heisenberg, do you know how fast you were going? Heisenberg says, no, but I know exactly where I am. He says, you were going 90 miles an hour. Heisenberg says, great, now I'm lost. He said, I'm sorry, I'm gonna have to search this vehicle. Looks around, pops a trunk. He said, did you know that you have a dead cat in here? Shreddinger says, we do now. The cop says, all right, I'm placing you under arrest. Ohm resisted. That's six years in grad school at Caltech right there, baby. Time well spent. It's also the best joke we've had all night. So I think the joke's on me as it were. All right. I think that's a double burn. I think I just burned us both. All right, here we go. Is this just a black screen? Yeah. Is that your presentation? That's a, it's a minimalist presentation. Okay, here we go. Okay, I'm gonna talk about the shortest path to a professional grade site. I'm Michael Hartle. Some of you may know me as the author of the Ruby on Rails tutorial. Any Rails tutorial readers out there? Woo! All right, thank you. All right, awesome. Pretty much everything I do these days is under the umbrella of learning enough to be dangerous. And one of the parts of learning enough is an introductory sequence of three trilogies. So you can go to learnenough.com. I'll be talking more about this a little later. The first trilogy is developer fundamentals and these three are all done right now. There's a learnenough command line to be dangerous. Just assuming a basic knowledge of computers. So it doesn't assume any background in programming or anything like that. The next one is learnenough text editor to be dangerous. And then learnenough get to be dangerous. This was not an obvious sequence actually, but I'm really pleased with how it came out. The third, or I'd say the second trilogy is web basics. The first of those is learnenough HTML to be dangerous. This is also done. The next one, learnenough CSS and layout is in preparation. I'll talk a little bit more about that in a minute. You'll note that this is by me and Lee Donahoe, the first author on this is actually the designer for learnenough. So you're glad that it was him and not me. Now the third is JavaScript. This is going to be coming out later this year. So then the third trilogy is beginning development with learnenough Ruby. Sinatra and Rails planned for later this year. So one of the side effects of making the sequence is that we ended up making what, to my knowledge, is the shortest path from basic computer knowledge to being able to develop and deploy a real professional-grade website. So starting with the command line, you learn this. This is useful, but by itself it's not a product. Text editor, you learn how to edit text. Also useful, but it's really a tool for doing other things. Git, also a really useful tool. But one of the things we do in this tutorial is use a project that is an HTML website. It's kind of a sneaky way to get people started on that. And so there's a twist ending, spoiler alert. At the end of the Git tutorial, you actually deploy a live website, but it's really not professional-grade. HTML, you add to your skill set, but you still don't have enough knowledge to make a real product. You can make something that has a little styling that's inline styling. It's really not very good. Great knowledge, but learning of CSS and layout is where it really starts to come together. And if you're anything like me, as a developer, you know that you need to learn more CSS than you know. I've learned a lot from doing this tutorial. It's been great. So one of the things that we do is we take you from this to this. And I should let you know that this is not a how to draw an owl situation. I do actually, we actually do cover all the steps. So this is the kind of website that you end up with, but I want to draw your attention to something you can see in the upper right part of the website. Look at that. This is something you see all the time, right? Navigation menu. But how do you really do this? You can't just copy and paste this from one page to the next. Well, you can, but that's the maintenance nightmare, right? You're violating the drive principle. Don't repeat yourself. So my co-author and I thought through this and thought, how are we going to do this right? So this isn't just CSS, it's CSS and layout. So it's page layout. But if you're gonna do page layout, you really have to have these sort of elements that you can reuse. And we didn't want the overhead of a full web framework because this is a sequence, while it can be read by developers, is aimed at people who are taking this gentler introduction. And so if you look at this, you realize that the minimum thing you need to do this is a static site builder. So we added an introduction to Jekyll as part of CSS and layout. So the result is that if you finish this tutorial, you can build and deploy a real website. Oops, this is now, what's going on? This is now a marketable skill. This is something you can actually go out and say, hey, I'm available for hire, I will build your website. And so that's really amazing to go from zero to having a marketable skill and just five tutorials. I'm really pleased with that as it's come out. You can learn more at learnenough.com, sign up for the mailing list. If you wanna get notifications, we're gonna be rolling out the first chapters for CSS and layout next week. It's a real book, it's over 400 pages, amazing amount of material that turns out learning and up to be dangerous is quite a lot. I'm also hosting an informal event tonight. It starts whenever I get to the venue. Sorry about that. It starts whenever I get to the angels trumpet alehouse. My pin tweet has the information if you wanna come. I'll be there from seven or whenever I get there until 10 p.m. tonight. Hope to see you there, thanks. All right, I'm gonna throw out the pitch first just to make sure that we get to it. Let's do this. Did you know empathy skills helped your career? And also, by the way, help you be a good person. Do you want to build empathy skills? Ask your doctor if Dev Empathy Book Club is right for you. This is a project that I'm officially launching right at the end of RailsConf. We're gonna be reading books about empathy in general, empathy in the context of software development. And you can check out online devempathybook.club. I like cool TLDs. Anyway, let's get on with the not warm and fuzzy at all rest of the talk. So this beautiful slide up here with some cool Cody looking stuff in the background, that is actual code, and it is syntactically valid Ruby. So this talk is not gonna be useful, but it might be fun. There are a number of languages out there that basically are tour and complete, use a minimal number of characters, nothing else in numeric. Someone figured out how to do that for JavaScript and I thought, why not Ruby? So the goal is a tour and complete language which is also syntactically valid Ruby that does not use any alphanumeric characters and of course uses as few characters as possible. So I call it brain Ruby and we're gonna write a program. The program just puts out one empty line. Four characters is pretty much as short as you can go. And this is how it looks. So I know you're all brilliant ninja rock stars. You know exactly how it works just by looking at it, but just in case you can't figure it out, we'll tell you how that works. So fun fact in Ruby, if you take an empty string or a string with stuff in it even, you shovel in an integer, it will take the character with that corresponding character code and append it to the end of the string. So here 65 is a character code for capital A and therefore we get an A at the end of that string. So if we take the numbers corresponding to PuTS, shovel them onto a string, we get puts. Okay, but we're not allowed to have numbers. So let's at least reduce the number of numbers. We're gonna replace each number with one plus one, plus one, plus one, plus one, plus one, plus one. And now we have this clearly much more beautiful code, but we're not done because there's still ones in it which is not okay. So we're gonna use a dollar dollar Ruby global variable. It always holds the current process ID. It'll be different every time, so why is that useful? Well, thanks to our good friend math, we can just divide it by itself and we have one. So we just replace everyone with dollar dollar over dollar dollar and we have this. Okay, this is like what we should all be striving for in our code. So we can generate any string without using alphanumeric characters. But that's just a string. We need an actual code to execute. So we use this template. I think it all got on the screen, yeah. And okay, let's talk about what it's doing. We start with dollar sign greater than, which is standard out. If you shovel into standard out a string, it'll just put that out on the, that's the output, basically. Then we have backticks. Backticks start a new process on the command line with whatever you put inside of them and then they'll return a string which again is gonna be output on the command line. You can use interpolation inside backticks, so that's great. Then we have our empty string, shovel and then the program itself, which is whatever the dollar dollar over, et cetera. So we generate a string, execute with backticks, send the output to standard out. You might have noticed there's a slight problem which is that backticks execute on the command line. They don't actually run Ruby. So that's actually pretty simple to solve. If you run Ruby dash E and then you pass in your programming quotes, it'll just run that as Ruby. So here's effectively what we're doing with this template. We're doing puts within backticks Ruby dash E and then your entire programming quotes. So this is our puts program again. This is Hello World. That's this buzz. I'm sure you can read it, right? Okay, so we have no alphanumeric characters. We only use 10 characters and it is completely legible, which is of course the goal. I'm sure performance is great. I haven't tested it. Here Evan Phoenix has a good gem for that, but we only use 10 characters and no code is faster than no code. There's a slight known issue with brain Ruby which is that you can't require other files. They'll all execute in their own memory space, but there is a known workaround which is that you just put all your code in one file. Is it possible to do this with less than 10 characters? I don't know. I'd love to see somebody prove me wrong. So keep calm and brain Ruby on. That meme used to be cool. Don't forget that code can be for fun. And again, you can check out the code online. Look at devempathybook.club. I'm Ariel Kaplan and this has been great. Okay, so we're gonna give a whirlwind tour of AWS record and we'll keep that under five minutes. So I'm Alex Wood. I work for the AWS SDK for Ruby. You can find me on Twitter. All right, so this is what an AWS record model looks like. It's similar to an active record model and different at the same time. We use inclusion over inheritance. You define your members specifically since in a NoSQL database you might have multiple tables or virtual tables running on the same table. And this supports you doing that. You define your keys and go from there. You also get different kinds of attributes that you wouldn't necessarily get with a relational database like map and list attributes. So this is what a model is gonna look like. We do migrations in a declarative way. So you define the remote configuration of your table on top of the model that you defined in what we showed before. And when you call migrate, it will look at what's on the remote end and make only the changes needed to get you up and running with the model and configuration that you have. Okay, so let's see how the conference Wi-Fi goes because I'm totally typing this as we talk right now. So you can see that creating a new item is pretty familiar for users of active record, defining attributes on it, pretty familiar, and saving pretty familiar structure, pretty familiar. So read operations again work similarly. We have you define the names of your keys before you put the values in since the number of keys can vary. And one interesting problem that we ran into was how we do dirty tracking. So when you support complex types like lists and maps, you're going to have a lot of mutated state, more mutated state than you would have a relational database. So we did build in support for tracking of mutable types such as hashes. This is also helpful when you are making update base saves and trying not to clobber what's on the remote end. If the object exists, we're going to run upserts or you can even run upsert commands directly without creating an item. So, you can even tell I'm totally typing because I make typos in the video. It's amazing. So, okay, we've talked about creating, we've talked about how read operations worked, we've talked about updates and upserting. We also have collection and enumerable support built into the scan and query methods which are a bit different in DynamoDB than they would be in a relational database. But you have the ability to scan, query, and it will build the items out of the response. This is all built on top of the AWS SDK for Ruby. So if you're already familiar with that, you're going to have a head start and deletion's built into that and now everything's gone and we're clean. So that's all I had for a demo to try to fit it in five minutes, respect everyone's time. You can find it on RubyGems at AWS Record. It's been GA for some time now and go check it out on GitHub. There's link to the documentation with more examples and thank you very much. Thank you for everyone that's still staying. I'm Je from Amazon Web Service. I also work with Alex on AWS SDK for Ruby. So today the talk I'm going to show is about waiters in AWS SDK for Ruby. You might already being familiar with the waiter concept if you are using AWS SDKs since it has been out for a while since our V2 SDK. I'm going to show a brief demo that help us refreshing the waiters feature then like talk about all designs that behind this waiter feature. So generally waiter is a simple abstraction around the pattern of pulling an AWS API until a desired state is reached. Let's look at the quick demo. For example, like you want to know when a newly created Amazon S3 object is alive. Let's see. There's a quick demo here. So you can see on the left side I'm using the WineLine waiter that use waiter object exist. You can see it's helping pulling those APIs hard objects but it cannot find object. And on the right, you can see me create the object lively and now yeah, like my waiter reached the state and existed with correct response. So when you think of the implementation about this waiter's abstraction, it may appear simple for some naive approaches like writing for a simple operation. And email still be tolerant if you are writing those handwritten hard-coded waiter abstractions for one single AWS service. But the reality we have today is we have over 90 AWS service and as far as today, the exact number is 97. So it becomes really difficult if we want to handmate these waiter abstractions. So the solutions that I want to show you is the strategy that we take. It's a data-driven approach that we use to unify the JSON file that do the abstraction and those definitions of waiters like this. This is a sample JSON file in our repo on GitHub that I'm just showing you. So this one is bucket exist. You can see we have all definitions like delays between API attempts, those masterments, and we define those states based on our API knowledge. So as you can see with this JSON format, we are able to build a waiter module that helps do the abstraction. But what's even cooler that we are doing right now, we do code generation of those waiters, which is available in our modularized SDK which is currently under preview release. So how do we do the code generation of waiters? We use this cool mustache templates that as you can see, like define those waiter structures actually per service, per operations, that after we fit in all the views and implementations that extracting those JSON values, it renders the templates elegantly. This is a piece of generated code based on the templates of waiters. You can see it has exactly like handwritten code. This is pretty cool. So the thing I want to show you today is like proposing a way like how to scale the problems with minimal code duplication. And this is also a way how we largely reduce double ops. And if you are a library maintainers, if you are facing some like complexity problems in your daily jobs, this may be also like some similar approaches to how tackle those complexities. So if you want to read more, our waiters blog is available, our documentation is available and feel free to check out our code generated source code for the waiters. Thank you. Corporate stock photo. Normally wouldn't use this, but this doc is so happy. He's clearly self-prescribed to Rocky Mountain High. So I thought you all would enjoy that. I'm Lou Parker. I work for the American Thrombosis and Homostasis Network in Denver. We write medical apps for the treatment of rare bleeding disorders such as hemophilia, which I happen to have. Love to talk to anybody about that. We have a great team and we're looking for some people. But for the next five minutes, I wanted to talk about pull request public relations. Here's my joke. This could be the title of my talk, Yachtoss. Really it's dumb ass things Lou has done while contributing to open source and how not to do them. I've worked with exorcism quite a bit and this is where I've made most of the mistakes and Katrina has mentored me through them. Let's hear it for Katrina. She's one of the most awesome women in tech. And I'm honored to be a maintainer of exorcism. So why public relations? Who here would like to get more pull requests accepted on open source projects? Anybody? So in order to get your request merged, it really helps to relate to the maintainer. And here's some common things that I see that either facilitate that or don't. So biggest mistake, no commit bombs, right? Don't come out of the blue with a massive commit. These are huge red flags for a maintainer. And a maintainer kind of feels like this when you drop this. So where to start? This is really important and I think not enough of us do this, but do your homework. These files exist for a reason. Read them and understand what's going on in them. Not reading these things is a disaster for your PR. And yes, I realize the code of conduct is on there twice and that's on purpose. Another important thing is just introduce yourself to the project. Do they have, get our IRC Slack, get in there, help out, help other people who are struggling with issues on the project. Do non-code things. When you are going for a PR, start small. Housekeeping is great, typos, formatting, things like that, just to get your name out there. Elixir is a great place for this. Jose loves these and he merges them himself quite quickly and you'll get the legendary five star rainbow, five heart rainbow. So when you have that great feature that you wanna add to one of your favorite open source libraries, the first important thing is know the right place to ask whether that feature is wanted or not. And every project's different. Read the documents I mentioned earlier and make sure you ask in the right place. And this is what you're looking for, right? PR's welcome. This is the green light to do whatever you feel like you need to put in. But another important thing, and this is also a common mistake that I make, is to try to add that feature all at once. And that's not what I would do in my work life. It shouldn't be what I do in my open source life. So keep it small, small changes, quick feedback, separate that feature out. And be kind to the maintainer so they don't have to use so much mental overhead when reviewing your PR. I also really recommend separating out housekeeping pull requests from normal pull requests. So oftentimes we find typos and mistakes in documents as we're implementing a feature. Pull those out into a separate PR because they can be merged in really quick. They don't require any discussion. And if your original PR doesn't get merged you won't lose that change. So bottom line to sum up, make the maintainer's life easier. Be nice, be patient, keep it small, and have fun. And if you value this talk at all, I just wanna call this out. My good friend Chris Bombadier is a severe chemophiliac. He's attempting to be the first to summit Everest right now and he could really use all of our support. Thanks a lot.