 Hi, we're the Standard Librarians. We are a volunteer group for Rails Girls Summer of Code this year. My name is Jen Diamond, slide please. This is me and my rocker days. I come from a creative background. I did a whole bunch of different creative things and a few years ago I got into coding. I met Josh and Stephanie at our study group and convinced them to sign up to coach Rails Girls Workshop that we were doing. So Wally ended up being at that workshop and it was the first day that we were all in the same room together and in a couple months we'd be a team. Hi. Hello, Rocky Mountain Ruby. My name is Oma Wally. I also go by Wally but I just please ask that whatever you do, you do not pronounce my name as Wale. So as Jen touched on earlier, I was actually introduced to Ruby at a Rails Girls Workshop that she ran. Before that, my background actually had to do with underground live art events for youth in my area and I worked with a friend and we would just put on random shows, anything from sticker trades and street art to break dancing contests to heavy metal and ska shows to even food competitions. So when I went to the Rails Girls Workshop, it was my first introduction to the world of programming and development in general. I actually got onto this project in an interesting way. I had applied for a summer of code with a friend but I didn't get in but our coach actually was the same coach for the standard librarians and he introduced us and that's how I met Jen and Steph and Josh. So hi everybody. I'm Stephanie Bettencourt. I work in education with the California Association of Independent Schools. I've been doing front-end design for about four or five years, starting with WordPress and working my way through, did a little bit of object-oriented stuff, C++ and Python. And then two years ago, I went to Rails Bridge and made the jump to Ruby. So since then, I coached at Jen's Rails Girls event in March and then a couple months later we applied for the summer of code. Hi. So my name is Josh Loper. I'm a remote Rails developer. I'm currently living in Texas and I've been coding since elementary school and I've been interested in web development for a long time. I was a coach for Rails Girls LA like Jen said and I was also participating in the Ruby study group that we were having twice a week and from there Jen asked me to, if I wanted to help with the open source Rails Girls summer of code project and I said yes. So we've said a lot about Rails Girls. Maybe there's a couple of people in this room who don't know what Rails Girls and Rails Bridge are. Who doesn't know what Rails Girls and Rails Bridge is? I'm curious. There's you. Okay. I'm speaking to you. So Rails Girls and Rails Bridge are programs to help get women into coding and excited about coding. So they're, start out as a weekend workshop where you spin up a Rails app really quickly and kind of demystify coding and teach some basic Ruby and then it's followed up by some study groups or maybe some small workshops and other support to keep guides to keep you learning more because as we all know you can't learn to code in a single weekend but you can get excited to start coding in a single weekend. And summer of code is a program put on by Rails Girls to help give women a supportive environment during the summer where they can focus on code. We were a volunteer team so we weren't compensated but for a regular Rails Girls summer of code team they'll get financial support, they'll get access to resources in the form of physical locations for them to work and they'll get access to amazing coaches. So we got access to the resources and amazing coaches. So like Wally said, each summer of code project has a coach and a mentor and ours has happened to be Pivotal Labs in LA who did an amazing job providing us with resources in the space to learn. We had four dedicated Pivotal coaches who worked with us four nights a week on our project. We also had a mentor, Pat Maddox, who was there from the beginning and oversaw the project. So what is Feats of Daring? Feats of Daring is an interactive reple inspired by TryRuby.org to try to help beginners and junior developers learn about the Ruby standard library. And we do this through imagery, storytelling about a cat falling in a well. You'll hear more about that when we show you what the project looks like. So you might wonder why did we choose the Ruby standard library? When I first started coding several people, including Giles Vauquette, one of my main influences, told me that a great way to start learning more about Ruby is to use, to go check out the Ruby standard library and start learning about Ruby through there. So I was really excited to have a direction, went up to the Ruby docs, jumped in, opened it up and as you might know, looking at the Ruby docs, it's incredibly huge, well documented and pretty intimidating as a beginner user to look at just the sheer volume of the things, the libraries, the methods. Each individual library itself can have 25 classes and 25 methods. And then where do you even start to learn about the methods? How do you know which one is good? What libraries do people even use? So when we had to come up with a project for Rails Girl Summer of Code, I figured why not just make a learning tool so that a beginner can jump in and start to parse these libraries and get some value out of it. So as Josh touched on earlier, we created our project in the spirit of why is try Ruby. We did that because we wanted people to be able to jump right in without having to download any software and we also wanted to create a fun learning experience to motivate people to explore the libraries. So when we first started, some of our thoughts were that we wanted to go through the entire standard library, which is about 107 libraries. So we did go through every single library at least a little bit and try to break it into chapters or categories, however you might like to call it, and just tried to group the libraries together. So we came up with several chapters and some of the chapters were HTTP, encoding and compression, IO, Ruby tools, DSL, and more. So ultimately we actually spent the whole summer working on just one library and just trying to come up with the best process possible. One of our coaches, Eric Hu, actually tweeted asking, what is the most popular Ruby standard libraries? And OmniRef actually replied with a blog post with the list of the most included libraries by Jim. So you can see test unit, YAML, JSON, value till, some of the ones you would expect to see there. So we do plan to add more libraries in the future. So like Josh said, there's a lot to learn in the Ruby standard libraries, and sometimes they're overwhelming. I've met people who built a gem only to discover that the gem they built duplicates part of the library, and that's crazy. If Ruby has had a better grasp of what the library could do, we wouldn't need to reinvent the wheel that way. One of our main priorities for our app was user learning for our user personas. And we wanted to be able to make sure that the libraries were understandable and accessible for those people that are accessing our app. But our main priority all was to learn for ourselves, and later we'll tell you a little bit about what we learned. So our project started out how most pivotal projects start out with an inception. And if you're not sure what an inception is, it's an agile process where you have to really think about your project and how you're going to build it. So there are a lot of decisions that have to be made because you're making something from scratch, so it's a real creative process. So you have to think about things like breaking your idea down into stories. You have to think about who your user is, the different levels of your user. You have to think about the technologies you're going to use, the wire frames to how your user is going to move through your application. You have to think about how you're going to work together as a group. We are a large group, so we had to decide whether we were going to work individually as a pairs, as a couple pairs, or as a mob. So because of the size of our group, we needed a little bit of structure. And our mentor, Pat, actually suggested that we try out mob programming. For those of you who are unfamiliar with mob programming, it's just a fancy way of saying working with three or more people at a time sharing a computer. In mob programming, there are defined roles. There are communication guidelines. And there's a rotation cycle. So there is a bit of structure to it. It's not chaotic. In mobbing, a team would meet together before they even write a line of code, and they would establish a set of communication guidelines. After those communication guidelines have been established, they would jump right into working on the project through the use of defined roles. So in mobbing, you have a driver, you have a navigator, and you have assistant navigators. The driver, as you can see in this picture, would be our friend Mike, who's sitting at the keyboard. The driver acts as kind of like an intelligent keyboard. They receive high-level commands from the navigator. The navigator kind of acts like your GPS system and steers the project for the amount of time that role is in play. Thank you. That role is in play. And when you're working on a project, challenges come up. So when a challenge comes up and the navigator is stumped, he or she or they will rely upon their assistant navigators and seek guidance. This is really where the power of mobbing can be seen, because mobbing relies on the power of the collective group's ability to think. So instead of putting a project on pause to hunt someone down who's not in the room or to do an online search on Google, people bouncing ideas off of each other can usually come up with a solution faster. One more thing to note about mobbing. There are some benefits that we experienced to mobbing. The first one was an accelerated learning environment. When one person asked a question, we all gained from that person's question, even though we had varying levels of experience. Number two is synthesis. In mobbing, when a new person decides to be part of the group, you don't have to take time to break down a project. What you'll actually do is you'll put that person last in the rotation cycle, so that by the time it's finally their role to either be a navigator or a driver, they've usually caught up on the gist of the project. And if they're still stuck, help is literally a seat away. And the last thing to note about mobbing, the last thing to note about mobbing is, that's it actually, that's it. Oh, actually, the last thing to note about mobbing is that if you want to learn more about mobbing, you can invite us to come and talk at your conference, because we have probably more experience doing mobbing than most. It's so new that very few people have the amount of it, three whole months of experience like we do. So as you may or may not know, Pivotal uses extreme programming and test-driven development. So over the summer, we did do test-driven development and learn testing best practices, just trying to get your idea out there when you're trying to express what you want to write in the test. And even if it's a little bit repetitive at first, just to try to get the idea out there. So that was helpful to us. So we learned how to write controller specs, model specs, and feature specs. And we were definitely very fortunate to have them show us how to do that. And they also showed us how to simplify the problem and just try to really, really simplify whatever story or feature that we were trying to work on and take it in very small steps. So it sounds simple, but it's a really helpful tool to try to solve bigger problems. So yeah, they told us, don't worry about writing JavaScript at the beginning. Don't worry about writing Ajax. And they even told us, don't worry about using a database. So it was interesting to see how they simplified the problem for us and showed us how to do that. We also got accustomed to using Vagrant. So we all got some exposure to using that. One of us was on a Mac, one of us was on Linux, and one of us was on Windows. So this was kind of important for us to use that. So our process looked a little like this. Some of us had full-time jobs, so we're students. So every night we'd meet up at Pivotal Labs from four to ten. We would write stories and tasks around Emerald, who was green, and our beginner user. And we had other user personas who were a little further along the learning spectrum. But after our inception, we actually decided to focus on the newbie. Even though these other people might find use from the app, we just wanted to focus our stories on her. And at our weekly iteration planning meetings, we'd point stories for the rest of the week. And we gamified the process as much as possible. So we had the timer ringing every 10 or 15 minutes, rotating chairs. And the goal of the game was to complete as many stories and learn as much as possible before the end of the week. So we're finally going to show you what we've been building for the past three months. Can you cue the local running app? Okay, so in the local running app, you're going to see these two characters, the adventures of Mr. Chips. We're going to run through our adventures with these two characters. There's a chip from outer space and his cat, Cudi. And so, can you move it up a little? So we're going to, we tell everybody that it's a really great way to learn. Ruby is by learning the Ruby Sandro library. And then you press the big green start adventure one button. And we move on. Can you press the little green button so the whole thing can be in the screen? It is. Okay. So we start out at adventure one to the story. Each adventure will be for a different library. And each adventure will have a different story. And then there will be three objectives where the people will run through the process of learn submit review. You'll learn a little, you'll submit some code into the repel. And then we do a review so that you can see what you've been doing. So in this story, you find out that Mr. Chips friends Cudi has run ahead and he was curious. He peeked into the well and he accidentally fell down and he's stuck at the bottom of the well and he has a tin can and he thinks it works. So we have to learn a little bit about the NetHttp library so that we can make a call to his friend for him so we can save him. So we continue on to the next page where the user gets some code. And here is their first piece from the library, the NetHttp. Get response method. And we make a web call to this URL and we put it into the repel. And we ask her not to copy and paste like we're doing but to actually type it because as Sarah was saying earlier, maybe it's not 10,000 hours that you need to learn but it is repetition. So we type it in and we hit submit and we get the response in the repel. And this is where it looks a lot like TriRuby. So we see, can you scroll it up a little? So we see that we get the 301 error that the page has moved permanently. And on the left hand side, we explain what happened. We tell Emerald that it's kind of like when you make a telephone call and the operator lets you know that your friend has moved and their phone has been disconnected. So we move on to the next objective. And we find out a little more about errors. And we learn, can you scroll up 401 error? Can you scroll so we can see the cat in his magnifying glass? And then we move to the next objective where we find out about 200 success code. And we're basically gonna move through adventure after adventure so that you can learn a little bit about each library. Well, 10 to 20 libraries is our first goal. So there's a nice cycle, like going through TriRuby really. For a more advanced user, we've broken down the libraries into chapters. So you can just scroll through and just browse through math. Say you're looking for something math and you're like, well, what does the Ruby standard library have? As you might know, if you look at the docs, it's not broken down that way. It's alphabetical. So this is kind of an easier way to jump in and see what math methods are available. This is the house of monkeys doing some math with their pentagram. And then there's a time and date. And as you can see, there's just different chapters. We've broken into about 12 chapters and they might not all be right now. But once we publish this, they will all be correct. So for the future of our application, we're gonna be adding more adventures and kind of beefing it up and maybe different levels of users and adding more to the chapters sections themselves and maybe flesh out more of kind of an easier to parse definition and some examples and maybe links to other sources where you can find out more. And now we're going to touch on what we learned while building this project. So for me, I had to deal with fear, uncertainty and doubt. When I started outside of the Rails Girls workshop, I actually didn't have any programming experience at all. So every day I had this intense fear that I was in over my head. I wasn't certain if I was going to actually make it through to the end of the project. And I doubted if my team was even gonna make it through to the end of the project. But we had some very amazing coaches at Pivotal and they asked me to feel my fear, acknowledge its presence and just get through it. They reminded me that struggle and failure are critical elements of the learning experience. And they told me that when I felt, when I told them, I feel like an idiot. They said, I'm not an idiot. They said that though I have a lot to learn, I know more than I realize. And that just to stick with it, and I'm really glad that I survived this experience and that we all made it to the end. Yes. So I learned a few things over the summer. One of the things that I learned was that programming involves people. Sometimes I don't realize that whenever I'm writing code and working with a computer, it's not just about working with a computer. It's also about working with other people. And Matt says that we need to focus on humans and how humans care about programming. So I thought that was kind of cool how the programming language focuses on humans and we work with other humans as well. So hopefully everybody is happy that way. Another thing that I learned was working remotely. There's some certain advantages whenever you're working with someone in person, you can make eye contact with them. Conversation's a little bit more two-way. It's still doable whenever you're working remotely. There's certain things that are communicated whenever you're working with someone in person that are not being communicated when you're working remotely, just maybe more subtle things. So I just learned that there's a lot that you can communicate to someone through body language as well. So that's it. So this summer was a time of unprecedented learning for me. Believe it or not, most of the lessons I learned were not about code. As programmers, we often are used to working solo and it's very tricky to reintegrate with the team. Early on I kept quiet about my ideas so as not to offend anybody in the group. But I learned that my ideas have value and I need to advocate for them. Another thing I learned from the PIVOTS was to check in regularly on the health of the team with our weekly retrospectives. That's something I hadn't done before because they emphasize that a well-functioning team is just as important as well-functioning code. I learned mainly through the PIVOTS. They really helped me remember that coding is creative. And people said that before and I was like, yeah, sure, it's creative. And then this summer actually building something, I realized like, oh, we're making something. So it's inspired me to go back to my arty roots and start building more things now that I feel more confident with my code. And I want to start doing some performances with coding, which is probably strange, but I almost did it today. So be glad I didn't do it today. And I want to use the Sparks kit that I got here last year at their Arduino workshop. And I think I'm finally feel confident enough to start looking for a job. And for me, that's a win in itself just to feel confident. Because that was kind of one of my main goals this summer was to feel a little more confident coding. So what comes next? All right, so something very strange that happened during the summer was that after a while I actually began to have dreams of code. So I actually want to take some of these ideas that came to me in dreams and actually build them. I'm currently pursuing an interest in game design and I made a physical prototype. So I'm going to continue learning Ruby and continue exploring programming and build a digital prototype of the game that I made. I also plan on experimenting with Twitter bots and tweeting at my friends. And a very serious long-term goal I have is to eventually build an augmented reality game. So as we approach the end of the summer of code I had managed to start a career as a remote Rails developer and I'm going to continue that. And I'm interested in learning more about software engineering whether it's formal or informal education about it. I plan to keep learning. And that's about it. So after writing my first big Rails app in February, I've continued learning and building and this summer was amazing for that. Now a good portion of my time at the nonprofit I work at is actually committed to development. With my work in education I'm focused on supporting teachers and educators who want to teach young girls to code but don't have the resources. I'm also committed to mentoring women in the LA community and of course continuing to coach Rails Girls. This project is super personal and important to me. So one of my main goals in the future is to really keep, to maintain the project and to keep building on it so that the Ruby community can have a really fun tool to learn the Ruby standard library with. I did all the cartoons for it and so it's kind of like a fun creative element for me. So like just, I don't know, to have a kind of fun side hobby project as to keep my coding fresh and want to continue with the project entirely. So our coaches told us that they learned a lot and benefited and had fun by coaching a team this summer. By fostering underrepresented developers they've given back to the Ruby community. If this experience sounds like it might be fun for you, you should think about coaching a team next year. Rails Girls Summer of Code is an amazing opportunity for women to learn to code and I encourage you to join us next year for more fun. Well, can I say that one of our main goals is next year we want to coach a Rails Girls Summer of Code paid team and I'll be coaches for this project. So if anyone in LA is interested, let us know. So lastly, here are the credits. Pivotal Labs LA who we've mentioned a lot. So let's pull the integral to our product process. Pat Maddox, our mentor, he has this Ruby steps program where it's lessons in Ruby and he does mobbing online. It's very cool. Mike Boniface, our story coach, helped us kind of plan it out and think creatively. Woody Zool who invited us down to San Diego to mob with his team who all did .NET and we all were at the keyboard coding .NET for the first time for a lot of us. And then lastly, Karsten Zimmerman from Berlin who supervised our project and of course Rocky Mountain Ruby and you all for inviting us here. Thank you.