 I'm Gregory Brown, and I'm the founder of Ruby Menekin University. Now, just to show my hands, who actually knows what that is? Okay, good, most of you. But anyway, what is RMU? Well, it's an online training program. And it's specifically aimed towards intermediate developers. The kind of people who have read some books, maybe done some basic exercises, and know the basics of Ruby, and maybe helped build simple programs, but haven't quite had the body of experience to call themselves professionals. And when we first started, we created this logo, which didn't originally have a meaning to it, but we added a meaning to it. Which is, it's got an interesting line there. And so the Ruby is not quite finished. And that's sort of how we viewed basically everybody. I mean, in a sense, I think everyone here has some room to improve, that's sort of why we're here. But specifically, our students, I think that they could identify with it. But our students, when seeing this logo, they liked it, but they had their own idea of what would represent them. The RMU fighting unicorns. Which is interesting, because I thought that this program was going to be something that was valuable, but really quite dry. I was sort of thinking it would be something that people would do to get up their skills and then they would just leave. But this happened before we ever even taught a course. So I was wrong. It's not just a training program, but it's also a community. And not even in the teaching sessions that we're doing, but just in the general community, we've had over 1,000 mailing list posts and 12,000 lines by our city conversation with less than 100 students in a period of less than six months. Now, this to me was amazing because I thought that most of the reason why people were coming was just to get some training and leave, but obviously I was wrong. So why did the community form around learning? Well, if you look around the room, it's sort of obvious. We're here at a conference working together because we recognize the value of learning in a group where we can draw upon the experience of others. Now, beginning programmers don't necessarily know that. They don't know that there's so much support. So they sort of feel like this. They feel like they're carrying this burden on their own and no matter how hard they try, they're eventually gonna have to fall down and get back up and do it over again. But what our students realize is that learning is really more like this, which is that it can be fun. It can be a struggle, but it's something we can do together. So in order to do anything together or have a community, there needs to be something that everyone does in common. So you might ask, what defines our review? Well, it's our core skills course. When I first started the idea of running this program, I only wanted to have this one course. That's eventually going to change, but this is really the definition of our review, which is it's a three week course and it's problem-based. It's entirely based on having people try and actually build stuff. I thought that that would be a little bit more valuable because anyone who's gotten past the beginner stages knows how to read from books. They know how to Google things. So they actually want to get their hands dirty and that's the idea. So the idea was that I could teach a course for three weeks and then take a week off. So that's why it's three weeks. There's really no other reason. Now, when I first started it, we used to meet twice a week on IRC for about an hour and a half and I would sort of discuss the problems that we were working on and give people a lot of background. But we quickly found that with students in maybe 30 or 40 different countries and in any given session, people being in eight or 10 different time zones that that's almost impossible to do. It meant that I was moving, scheduling things at all sorts of crazy hours for me because it wasn't the best interest of students and it just really didn't work out well. So, but one thing is that we have a very small class size. Only have about 15 students per class. Some of the courses are even smaller than that. And what this meant is that rather than doing these shuffling around of formal meeting times, what I decided to do is make myself available for a large period of time, three days a week to just help students one-on-one or in small groups. And I found that this works a whole lot better because rather than trying to figure out what the sort of general needs of the students are, I could talk one-on-one with people and work on their specific problems. These, if something is a general need, it can be solved in other ways. I could write an article, I could make a video, but the sort of problems that you just sort of need to talk to people about when you're meeting in a live environment, those are the sort of things that don't really benefit from a broadcast format. So the small class size allows us to do that. Another thing is originally our assignments were sequential. The students had basically an individual project and then they had to do three assignments in order and then take a final exam. We found that that didn't work well at all. We decided instead to give them all of the materials up front and we found that that works a lot better. People can come into the course, get a feel for what areas they think will be easy for them and possibly work on those first so that they can meet the requirements and save the harder things for later. Or if they're looking for a challenge, they can work on the thing that's hardest for them and make sure that they get that done first. It gives them choice. This is something that's not typical of say, college course in which you're given a problem, you get evaluated on that problem, you move on to the next one. We found that this is closer to the model that people actually have when they're in an actual working environment. People don't say work on this one feature and then work on this one feature and then work on this one feature. And if they do, then you're working in a really bad environment. Because what happens is if you get blocked on one thing, you're sort of stuck until the next thing comes along. So this works towards promoting an environment that's more like what programmers actually need to learn in. We also do iterative evaluations. The original courses were basically, every assignment was pass, fail, and then you have to pass a certain amount of them to gain recognition at the end of the course. But now instead we say, okay, submit your exercises whenever you want. We'll give you a review. We'll give you some feedback. You rework on it and then you submit it again. And this too sort of reflects, especially in open source culture, the sort of thing that actually happens, which is you work on stuff, you refactor it, you clean it up, you fix your problems, and then you try again. And you just keep repeating that process until you're ready to ship something. This made a big difference. Another thing that's core to our view is open-ended exercises. Programmers are all pretty smart people and many of them have a math background. And a lot of times the sort of exercises that can be given to them are things that are sort of like basically doing basic math problems in which there's one right answer. But as we all know, that's not really how our work is. We have to be responsible for coming up with interesting questions as well as getting the right answers to those questions. So our exercises are designed to make people think and have a lot of different ways to attack them. And that makes it so that a lot more discussion comes out of the course. And that means the materials can be used as a jumping point for further study. And that I think works really, really well. So our core skills course, which was really hard to figure out what to pick for. Because when you have beginners, you basically say, okay, they need to learn language fundamentals and that's pretty straightforward. With experienced people, you don't really need rigid structure. You can just say, oh, let's hack on this project together. And I mean, anyone who experiences the hallway track at a conference knows how that is. But the folks that are coming into our new, they have sort of specific needs, but at the same time, they have general needs as well. What they need to be is exposed to the sort of things that hackers actually need to know. So coming up with that was hard. But what I decided to do is rather than trying to make it perfect, I just picked up some things that I know that I need to apply in my own work and then I tried to make exercises around that. So we chose these sets of things, which is dealing with services and integration, both with like web services and also like third-party software, Gems and things like that. Domain modeling for business logic, academic principles, which is like when we're studying things like design patterns or something like that. Community service, which might be a little bit unexpected, but I'll talk about that a little bit later. And independent practice. How many people here have a side project that they're working on? Okay, almost everyone. And that is really the way to learn the most possible things that you possibly can about programming. So I'm gonna go through each of these and sort of give you an example of the sort of things that we're doing and what people are getting out of them. So everyone loves to be in the cloud, I guess. And this is where I think it's important to expose people to things because has anyone here ever, how many people have interacted with a web service or something like that in their work? Okay, less of you than I would think, but quite a few still. And how many people have used a Ruby gem of some sort? Okay, yeah. So these are the things that are often covered in our basic books. Our books talk about the core language. There's some books that go over all of the stuff that's out there, but integration with other software is just part of what we do. So we're trying to do this in sort of a fun way. One of the sessions we did Twitter box and what we did is it was completely open ended. The rules were you needed to integrate with some web service and you also needed to make something that would either post to Twitter via direct messages or create a timeline. And people were able to pick whatever projects. So they went and had a bunch of weird different things like someone had a thing where you could post and get the weather from them. Other things got RSS to Twitter feeds. There was a language translation thing which was sort of neat. There's a dictionary service, you're all shortening. And in that course, 13 more projects. The neat thing is because everyone was working in a different area, they all had something to contribute to the course that the other students weren't looking at. So they all had something to talk about. Now this sounds like sort of vanilla, ordinary stuff. I mean, in order to build something like this, you normally don't need more than a page or two of code. But you'll notice as a pattern here that there's a lot of emergent lessons when people are learning together and working together. So these are the things that I didn't anticipate when I wrote the exercises, but I hope something interesting would come up. So almost immediately people were talking about deployment strategies for these things. Okay, well I have to monitor some service and I need to post to Twitter at a regular interval. Or I need to wait for messages and then figure out how to respond to them. How do I do that? So people are talking about things like setting up a crime job that fires off a rake task to do scheduling. Or maybe setting up something that just runs in a loop and then sleeps and does polling. Some people are even doing some crazy things where they basically had hooks on Heroku applications to keep the application alive and then did pingbacks to that. It's interesting because these are the things that people actually have to talk about in relation to these problems. Another thing is application configuration. How many people have either accidentally or on purpose checked in credentials that you shouldn't be into a Git repository? Yeah, me too. In fact, I'm pretty sure that we wrote history but we're gonna show the RMU app and I think I checked in all the admin stuff to that at one point. But the thing is there's a difference between doing that by accident that you can fix and not knowing another way to do it. Now, obviously there's a security perspective but there's also the perspective of if I'm gonna build something, I shouldn't make it so that it relies on my own environment. Even if it's a single use application because it's just as easy to make a configuration setting but people don't necessarily know that. So we ended up getting into a number of different things there. Another thing was modular design. So people were talking, how do I break up these parts? Now, maybe they were trying to interact with the service and had some problems while they did that and it was sort of blocking them because their code was this one big long procedure where it connects the Twitter, gets some information, connects to a service and then does its thing and then it's just this one big long procedure. If you start moving towards breaking up those modules so that you can work with things in isolation, you can get part of the problem done. Now, I'm just gonna go through the rest of these briefly. Testing techniques, people got into interesting things. Well, now we're dealing with external resources so now we might actually have a reason to learn MOCs instead of just learning the basics, the cool thing that the cool kids deal. That sort of thing. Technology evaluations. There were a number of different options just for even really basic things. So they all had to communicate with the service and I told them they couldn't use a pre-built gem for that. So that means that they're looking at things like Open URI, they're looking at REST Client, they're looking at HTG Party and they're trying to have this discussion in IRC about which ones are best to use. So it's kind of interesting how much comes out of such a simple thing. And then the last thing is technical collaboration. This is the first experience students have in the class and they're already realizing that they can make use of their experience with one another. At the time that we did this, it was when Twitter switched over to being a lot only for all of their stuff and I actually didn't know that so I felt kind of bad because it made the problem much more complicated and it made a lot of documentation and resources out of date. The students figured that out and sort of shared code with one another until they got off the ground. I thought that was really, really cool. So it's sort of amazing how much can come out of what sounds like a toy example but when you've got a bunch of people who are motivated and want to learn together, this is what you can get. And I think all of you know this and that's why you're here but there's a whole world outside of this room that doesn't know that. And for them it's sort of an enlightening experience to be involved in that sort of thing. Okay, so the thing that I like most and people hate in R&B or Bs, I think they're afraid of it. I was asking people if they wanted a heavy data modeling problem or something else. I can't remember exactly what it was, it's something easier. And they went with the easier thing for sure. Well I really am interested in business logic and data modeling. You can see how much fear programmers have of business logic and requirements by the fact that we have entire frameworks designed to help us communicate with others. Now those things are not necessarily a bad thing but it's clear that programmers are more comfortable when the requirements are well-defined. When they're not well-defined, it requires a lot of communication and different set of skills to be able to do it. Now some people love that sort of stuff but many don't. So what I try to do is give them really badly defined problems at least once per session. I give them stuff that has missing requirements. I give them stuff that is hard and something that where things sort of run into each other and then I make them unweaving. Now I'm gonna show you an example of a video and this is something that the current session is working on and you'll see exactly what I mean. Okay, so this is a game called Preston that my friends and I made up back in high school. And it originally started from the question of what would happen if we played chess where everything was a queen except for the king? And as it turns out that's a pretty boring game so we removed the king and we ended up with everything being a queen. And rather than the goal being a checkmate type scenario the goal was to capture everything. So just filming the game. And basically this is what we came up with and we made some modifications along the way. So it's a two player game and you play with black and white stones and the black goes first so I can go. So the idea is that these all move like queens of chess so your options were sort of limited at first but they can go diagonally, they can go horizontally and vertically in any direction. So if we just have the center here you can see you can move along any of the horizontal, vertical and all of the diagonal paths as well. And they kill the same way that a queen in chess kills. So basically if I wanted to play my first turn and I decided I wanted to kill this guy. Now the white player can go ahead and kill him or he can do something else. It's totally up to them. And you sort of go back and forth like this. But there is a twist to this game which is suppose that this guy doesn't get killed and the player just moves somewhere and doesn't get it out of the way. If I can manage to get a guy into the back row what happens is that if I've got a space open in my back row I get an extra piece. And in this way pieces can regenerate. Now of course it's the moves that I'm showing here are not actually the moves from the game. But the idea is you go back and forth and because the pieces can regenerate the game could actually go on a lot longer than if they were just killing the one for one. So that's the basic idea of Preston and when you're playing it, strategy wise it's sort of nice to have something like this because if this piece gets killed then the player can immediately come over here and kill that and then give them a piece. And it sort of would cycle on infinitely until they managed to kill this piece here. Now let's say that we had a stone here and this stone had just been turned into here. Well because we don't have any space available on the back you don't get any extra pieces. And this makes it so that there was at least some limitations to the amount that you can regenerate. So this game has a bunch of flaws to it. It's not really a great game but it's an interesting one at least. And I think that this pretty much covers the roles of it. You just keep doing that until one of the players resigns or until they manage to kill everything. And so that's pretty much it for Preston. Maybe we can get a video of people actually playing it some of the time and we'll find out those are the flaws. So I could tell you that like 95% of people resign after the first couple moves of this game. Not a really good game. Now how many of you just by seeing that right now could just like go code it and be ready to go? There, well let's do it. So you can't see this. That's okay. I'm just gonna show you this is a fairly complete set of rules and the students built these based on editing a wiki after they heard that video. And first they sort of used the mailing list to talk to me and sort of clarify these requirements because there's at least like three points there that weren't even in the video. They're just things that it's like this doesn't sound right is there something missing and it's like oh yeah there is. And those things that were like outright wrong requirements and we went through that process and I think that that is something that we experience all the time which is like maybe we're on the phone with a client for an hour and then we're taking notes and then we sort of have to build something and then go back and ask those questions. So we're trying as best we can to emulate those experiences. I mean that video that I shot was horrible. I did it in one take on purpose without making any effort of being clear. But yet the students with a little bit of back and forth got to this point. And then once they've got this they actually have to build it and they're working on that now. So the emergent lessons here are like requirements discovery is important and it's actually a skill. And some people are quite good at it and others aren't. But I find that people can get better at it if they watch someone who is experiencing this ask the right kind of questions. When you're sort of in a project and you're just your knee deep in it you can make your life hell or you can make your life much better based on the kind of questions you ask and the way that you ask them. And this sort of teaches that lesson. Now a thing that's interesting about this is that it sort of introduces separation of concerns. There's a lot of control code that needs to go on to implement this game. But there's also a lot of business logic. Now a lot of students are accustomed to basically writing object oriented procedures in a sense. So it's basically the control code and the business logic all jammed up in one. But that makes it very hard to test and it makes it very hard to look at the code and know what it's doing. So this comes up with that. Because it's a larger project than the previous one you can tell pretty much by the way of people who know the standard project layout and those who don't. So with enough complexity you get into the reason why you might want to organize it a different way. Also this involves data structures. A lot of people come from Rails and the data structure points things in at least basic applications pretty much solved for you by active record. So there's a lot of people who aren't really familiar with the idea of sort of making the things that, I don't know, it's something like what Alan Kay was talking about with like the little like individual computers, that sort of thing. So this exposes onto that a tiny bit. Another thing is scope definition. This problem, I told them that if they can't build the whole thing in the timeframe that they could build the usable subset of it. And that sort of goes along with requirements. You can narrow it down the scope and still build something useful. So for a student struggling I could say, okay, maybe just build a generic board and don't worry about the game logic. And that might be something that they could bite off. So I think that these problems are really great and this is an area that when I'm teaching and I do professional trainings and coaching and I do this R&D thing and I teach and work, I feel like heavy business logic modeling and requirements discovery is one of the areas that most programmers would otherwise think are really good and smart, struggle with. And it's just because it's not because they're deficient in it but leads into different scale set. So this is my favorite exercise. I'm not sure if my students agree with me on that. Now academic learning, how many people here like regularly read CS papers? Good, I don't either. But how many people have at least read some of the basics? Like, you know, Gang of Four or SICP or something like that. Right, so most of us do and actually I'd like to ask, why do you think it's valuable? Does anyone wanna, who's done that? Common vocabulary. Was that, oh, common vocabulary. Yeah, that's definitely one. Anything else? Yeah, there's certain things that are sort of common and cross cutting regardless of where you are. So I mean, there's these common truths. Anything else? That's a really good one. But I don't know, I don't know how much I agree because you should know why a rule exists before you bother learning the rule, I feel like. So I think it's easier to show someone with really, really shitty code how they can clean it up than show them how to write clean code from the beginning. And so the reason why I said I don't know is because I think you have to do it as early as possible. Introduce those concepts as early as possible and say, okay, see how that came about? Try doing that until you know when it's okay to break the rules. So one example where I agree with you for sure is things like metaprogramming. But anyone else have a thing about academic learning and why it would be, right? I just wanna be exposed. Okay, so how many people, oh, go ahead. Well, don't reinvent the wheel. Yeah, don't reinvent the wheel. I don't know, how many people think that we shouldn't reinvent the wheel? Aaron, so you've never ever done something like take an existing library and rewrite it to make your own. No, so that's... Well, I was... What's that? I made it happen. So reinventing the wheel. Well, for me, what I meant by that, I mean, obviously it has implications, but if it's a new concept for me, it may take me a lot of code to write something that people have figured out how to write pretty simply. So, I mean, yeah, I could write three pages of code to do something that maybe... Well, I mean, we're talking about things like design patterns and these sort of high-level concepts. And you sort of need to get far enough into a project to realize that you need those things before you apply them. We actually do an exercise in trying to apply first, and that turns to be really, really hard. And I'll talk about that now. But the idea of wanting to just basically use what's already out there, I think there's value in it. But I think that there's also value in trying to frame things in your own level of understanding and then looking at how it compares to something else and then doing a refinement at your level of understanding. These are a lot of times, how many people, and I'll admit to this, read a design patterns book and then try to fit as many patterns as possible into a project? I mean, that's one of the things that you can run into as a risk there. So, we sort of run that, we ran that as one of those exact exercises, which was I told people to go out and read as many design patterns as they want. And then I told them this, that they need to pick one of them that they can think of a practical application for. And they need to write it in a way that's natural and idiomatic in Ruby. Now, the interesting thing about that is when you actually find that, you find the patterns almost disappear. Like, who can tell me what pattern this is? Observer, right. But as compared to the traditional definition of an observer, Ruby has so much more of a serum. I mean, all you're doing is just capturing this block. And the existence of blocks really makes a lot of patterns really whittled down. So I think this is a reasonable thing. I mean, what he did is he built this little account class that had a deposit withdrawal. I just just showed him the withdrawal here, but then he made some observers to create like a letter that showed like whenever a transaction was made, these observers do that. This was a really interesting problem because a lot of people were coming back to me saying, I made everyone pick a different pattern and they could pick whichever one they want, but a lot of people were coming back to me saying, you know, I read a bunch of patterns and a lot of these I don't think we really need in Ruby. And that turns out to be true in a lot of ways. Or there's patterns that work, but only after you translate them. So sometimes people would say, oh, we don't need that. And then someone else would say, well, yeah, it could be useful to try it this way instead. And I think it's really interesting to see when you're trying to apply these ideas rather than just respecting them at first. I think there's this tendency among programmers to say, wow, some really smart person said this, therefore it must be my fault that I don't understand it. And therefore this is really good, but I can't use it somehow. And sometimes it's, yeah, it's good in its context, but it's not necessarily good for you. And if you don't understand how it'll apply in your context, maybe it doesn't. And that was sort of the interesting thing with this, which is we ran into these emergent lessons, which is you have to apply theory to be able to understand it. You have to respect the idioms and best practices in your language, even if there's these really good cross-cutting ideas. You shouldn't necessarily use someone else's hammer for your problem. So also purposeful study, I mean, I sort of forced people to not look at these abstract examples, but put it into something concrete. They were looking through there, trying to look for a pattern that they had to understand. We had to build something useful with it. And it's also a matter of picking the right tools for the job. So as I was saying before, a lot of these patterns don't actually apply. And the last thing was reduction techniques. I made them build working applications for these things. They couldn't just give me a snippet of code, but I forced them to only include the relevant parts that showcase that pattern so that these could be used as learning resources for others. And that's actually really hard for some people. Some people just dropped an application in and didn't know what to shave to show the pattern. Now, this is something that applies way outside of this area. It applies to mainly when you're giving someone a bug report. If you can't produce a reduced example, then it's very, very hard to isolate and fix bugs. So that's sort of popped out of here too. Now, I want to go a little bit at a faster pace through this stuff because I'm going to have Jordan do a demo for us later. But another thing, as I mentioned before, was community service, which is interesting. I mean, RME was a free program, so it sort of makes sense that I want the students to help out with it. And it's a different social contract because in free software, it's sort of like if you want to see change happen, you have to get involved. But if you want to just consume, you can. RME students are strongly encouraged to give back. And it sort of makes an intentional community. So we do this in a number of ways. It's open-ended because I don't want to force people to do a particular kind of work. And also, they aren't absolutely required because they can skip one assignment. Some people skip this one, but most of them don't. And as a result, we got like a student frequently asked questions document, a hacking guide for how to work on the tools we're building. People have been improving the IRC bot that we have. I mean, a big problem is time zone conversion, so someone hacked that in. We've got tutorials. People are adding testing to the application, building puzzles that they can share with each other. It's really sort of great stuff. And the lessons of that are that identifying community needs is actually a skill. And it's something that even like, if it's not applied to community and you're talking about business, if you have a startup, knowing what your customers are gonna need before they explicitly ask for is a real skill and it's a competitive advantage. So knowing how to do that is something that's worth knowing. Also, looking for a place to start and a big complex system is valuable too. Scratching an itch is something that I think a lot of us are motivated for. I mean, how many people got into programming not because of some abstract desire to learn more, but because they wanted to solve a particular problem? I think a lot of us. And contributing successfully is harder than just making a contribution. Sometimes people will drop a fix into a bug tracker and they never realize that it breaks like everything else. And we bring them through the process in a sort of gentle way of saying, oh well, thanks for working on this but we need to fix some things before we can actually bring this in. And we sort of bring them through in an environment that's not quite as intense as the free software environment can be. And also the last thing is paying it forward. And I'll talk about, at the end of this talk, how that's like, our view is entirely about me paying it forward for what I've been given by others. But I think that's an important message too. But the most thing, the core of what our view is about is about individual discovery and progress. And that's how we get our diversity. That's how between all of us in here we can build awesome stuff that we can all share. And that's the most important thing out of all of this stuff. Now so far, and I'm not gonna talk about them but you can go to the website and see them. We've had 22, I think 22 students finish the course successfully and there's 22 new open source projects or decent contribution-filled open source projects as a result of the last three and a half months of sessions which I think is awesome. So the emergent lessons in doing that sort of work, everyone who comes into our view needs to work on an individual project. They need to get it accepted, the proposal for it before they even start their first day. It means that all three of those three weeks that they're there has a particular purpose. They're there with someone who supposedly has some experience in Ruby and they've got a reason to learn. And all the other exercises are just made to have them have something in common that they can discuss. The real purpose is for them to work on these projects. And the emergent lessons from these are everything that we do in the course which is just amazing to me. So working on real problems is the secret sauce of our view. And it's really a lot of fun but it's a whole lot of work. Now when I first started this out I took some donations, I took, I think it was $3,000 or something like that. Because I thought I was just gonna build some exercises and then just sort of let the course run itself. As it turns out, with my first month of working on this the time that I put into it didn't go down but it went up. And at this point I'm working 40 to 50 hours a week on this and I've basically completely stopped my consulting work. As of December 1st I am only doing back maintenance on old projects and I will not do any more consulting work for as long as I can at least I care about this project. So why? Why me for one and why free? So, seven years ago I thought it was a great idea to, okay, to make a text adventure game which made it save files by writing out global variables to a file in Perl and then evalding them back in. And the entire application was one big script that did that. But yet today I literally wrote the book on Ruby Best Practices which was translated into Japanese. It's got a forward by maths and the tech editor in Japan was Takahashi and how the hell did that happen? I mean I to this day am amazed about that and I have exactly one reason why. I'm James. James worked with me. He worked with me since I was 17 years old. When I thought that writing a giant Perl program with nothing but global variables was a great idea. I was just hacking on this stuff because at the time my parents were going through a divorce. Family life wasn't great and this is something I could do to get away from it. I never thought it was gonna be a serious thing but for the last seven years I've worked towards a path where I could be here today and it's all because of that day's work. He worked with me every day talking to me, helping me day by day and that's the spirit I want to promote. He changed my life. One thing is that now that I'm doing this I'm not alone at our meeting. My students have helped. There's a few of you here and they've done amazing things. Yeah. I have the most supportive life that I can imagine and she is an RME student and also the administrative contact at RME that does a lot of our miscellaneous work. I also have a friend that's almost as crazy as I am, the guy that I've made press men with and I've known him since middle school and he decided that he really liked this project and he's a Ruby Rails developer that I've been training and he built a really cool system for us that we're still working on. So I'd like to have him come up here and show you guys what we've been working on the last couple of minutes we have here. So I'm getting off the stage now so thank you. Hello everybody. We've got exactly five minutes but this is exactly how long I plan on talking. So I'm gonna talk about university web real quick. It's this big Rails application that we've been slowly building for the past couple of months and it's what we use so Greg's head doesn't explode when he has to track all these students. Some of the quick features of the app I'm not gonna go through all of them. We have IRC logs in the app. They have a student directory. All of our exams are tracked in that. We have a course registration and courses themselves and all the notes, documents, assignments, student submissions and comments. Those are all in our app. But the thing we're in focus on today is the assignment submission piece because that's the important part. That's what students, how their progress is tracked and how we know if they've become an alumni and all that fun stuff. So before university web, things were kind of a mess. We were all over the place. All of the code was on GitHub and then we had mailing lists and this was in the old design where we had deadlines. So what happened is the deadline would hit, Greg would go through all the forks on the assignment. He would comment on the mailing list and then hopefully all the feedback got back to the student and progress wouldn't sue. It worked, but it really didn't encourage students to collaborate and it also made it very difficult for Greg to track everything and even for the students to track their work. So we took our first stab at it in app and we created this thing called a review and so every time a student wanted a review on a submission they would create this review, they would comment on it and then the review would sort of get closed but that didn't mean the submission was done so we would create it again and they were all kind of in isolation. So it was nice that it was in app but it really wasn't the best solution. It was hard to see what other students were working on because they were in these silos. So then we took another stab at it and our reviews take two and now we've sort of got rid of this idea of the review. We have the submission, there are comments on the submission and it keeps going until it's approved and the other thing that we added was an activity feed so you can see everything that was happening within these submissions. So students were really tied into each other and now I'm gonna pray to the demo gods and hopefully things will work. This is our monolithic login screen. Greg and I spent many hours working on this. So this is our dashboard and I'm gonna jump right into this new goal in one course. We're gonna take a look at RubyConf 101. And in here this is the basic course view that we have, of course that's the descriptions, all those documents I talked about, notes and their assignments are on the side here. This is part of our first attempt of making it visible to what students were doing. You can see my A student, I'm like this A student and these are all my assignments and I've submitted some things and I can see where everybody else is but I don't really know what's happening and that's when we introduce this activity feed down here. So now I can, every time I log in, I can see the latest things that have been happening in R and Mu. I can see Greg is making a comment on A student submission and if anything looks interesting, it's like oh yeah, that sounds like a cool problem I'm gonna jump right into the student submission here. And now we have sort of a historical view looking at A student submission for this first exercise and students can update their description which is nice, all in line, nothing fancy there. And then this is the comment so you can see how the student starts with an idea, Greg comes back and says yeah, it's a good idea, here's some code and some more ideas and the student says oh, that's good, more questions talking about some features he's thinking about and at this point Greg's like oh boy, we gotta go live here so we're gonna go to R and C and you can see sort of how this really helps compared to a mailing list and keeps things sort of sane. So I think I would actually want Undertone just fine because I hope that you guys have questions. If you want to learn more about RMU in general, you have university.com and more about university web it's up on GitHub. So I'm gonna pass it back over to Greg, thank you. I think we have about a minute and 45 seconds for questions. How can we help keep RMU going? Well, there's two ways right now. One is to join when the entrance exams come out and then become part of the community. The other is I'm actually, I started a newsletter while we're trying to get a nonprofit set up but until then I am quickly running out of money so I made a newsletter called Practicing Ruby and what it is is I take some of the concepts that are coming up that are common with the students say wow, that means there's probably not documentation about it so I write up an article about that and then post it. So there's a newsletter, it's $5 a month. You can, I talk about it nonstop later because I'm excited about it so if you follow me there you'll find it. That's it for right now. Once we get a proper organization set up there'll be a lot of ways to contribute. Anything else? No, it's not a problem. The reason why is we do an entrance exam. So people have to get accepted so they have to put the work in in the first place and then on top of that they have to call for the project proposal which takes some time and we do get a dropout rate but as far as I know like for free online courses the average dropout rate is like 90%. Ours we have 50% successful completion and only like 10% dropout rate overall. Sometimes people say I'm too busy I'll come back later but so far we've done pretty well considering and in terms of charging for it I absolutely can't. I started a thing called Ruby Problems and it was only $3 an article but someone wrote to me and said that was basically like in their country and many other countries that's like half a day's pay or a day's pay and I care a lot about making this available to everybody. People have talked about doing like a scholarship sort of model which is a possibility way down the line but for right now this is what I wanna do and because we're gonna produce a ton of open source we're gonna try and find a way to fund it so that that's not a problem. I think I am now maybe one more. People who have some basic language fundamentals already and then they wanna keep going and refining it. Do you thought about expanding sort of downwards to also introduce language fundamentals? It's definitely something that we're thinking about. We don't have the resources for it right now but actually because we don't pass everyone on entrance exams the alumni students wanna start up like a little one-week program that they run every couple of months to give someone some basics so that they can figure out what they need to learn in order to get themselves involved here and I think I'm now over time. Feel free to catch me whenever I'm talking about this but thank you.