 Thank you. All right, our next speaker is Steven Ragnarok. Steven is a professional student. And he's newly at GitHub. So congratulations, Steven. And he does a lot of teaching, especially with RailsBridge. So thank you for your contribution to the community. And apparently, this talk is at least partly my fault. I said something about how I didn't understand why people tried to teach Ruby without starting with the core of Ruby, which is objects. And Steven apparently took that to heart and did something pretty cool with it. So Steven Ragnarok telling you about sugar-free Ruby. Hi, my name is Steven. I'm going to be talking to you today about sugar-free Ruby, which is kind of my way of looking at Ruby in a way that emphasizes what Ruby is all about, which is objects to people who might be brand new to it. You're probably wondering who I am. My name is Steven. My last name is fake. That's not my real last name. I go by Nuclear Sandwich on the majority of the internet everywhere that I care about. And I was once pointed out in a bar as that guy with all the opinions. So I'm here to talk to you about teaching programming. Teaching programming is something that I do a lot of. It's something I love. And it's something that's genuinely important to the future of our field, our hobby, our love. Whatever you want to call programming to you, if we don't teach it, it's going to go away. All of you have teachers. Be they the authors of the books that you wrote, the teachers you had in school if you went to the boring educational route to programming, the parents who taught you about computers and how to program. Everyone here learns to program from probably a set of teachers. And you owe it to those people and their teachers and their teachers' teachers to continue this tradition and to push it forward and constantly be inviting people who may have never had an opportunity to program to come in and sit down and see why we spend an inordinate amount of time tapping on keys in front of a screen. There's one problem, though. Teaching programming is really hard, really hard. It's one of the most difficult things to introduce to someone who's never done it before. And there's a number of reasons why teaching programming is so hard. I think one of the biggest ones is that if you're teaching someone to program, that means you already know. And if you've been programming long enough, you've completely forgotten what it's actually like to learn to program. And that's a huge deal. There's plenty of assumptions that you make every day that somebody who's outside of the programming field wouldn't even think of. So that's one of the major difficulties. You have to relearn what it's like to be a total noob. And that takes a lot of empathy and a lot of work. The other reason is that as people, we tend to bogart our secrets. We don't want to dispense with knowledge freely because knowledge has a value. And you don't want to be giving something that's valuable away. So it's really hard to actually share with people what you've learned without trying to gain some value out of it. And whether that value is financial or in terms of social status, there's value in the knowledge that we have. And we wanna make sure that we get an equal trade for it. And it takes a while to realize how rewarding programming is in terms of rewarding you for the value of your knowledge and how to share it. In short, the big issue is that programming takes a lot of self reflection to teach. You have to do it constantly. You have to do it extensively. You constantly need to look at what you are doing and how you can be better. And we're great at that as programmers. We continually assess ourselves and how our programs look and comparing them to the programs we've written in the past and thinking of what the programs we might write in the future will look like. But it's another thing to take that skill and apply it to everything else we do. One of those things is teaching. But it's okay. Programming teaching is getting better. There are plenty of organizations out there now that are making a serious deal out of teaching programming. There's Living Social has the Hungry Academy. Railsbridge has started and there are plenty of Railsbridge workshops and groups starting up all over the United States. We have workshops happening in Europe and in Asia all over through Railsbridge and Rails Girls, Pie Ladies is a big thing. So there are groups out there dedicated to teaching and I'm gonna talk a little bit about some of those groups and my involvement with them and I'm gonna get into some of the ways that we're teaching Ruby and how we're doing that now and how we might do that better. So Coder Dojo is an organization dedicated to setting up kids' programming clubs all across the world and the whole idea behind Coder Dojo is that kids come in for a couple hours on a Saturday or a weekday evening before it gets too late and they learn about making games with Game Builder or fiddling around with the scratch visual programming environment, playing with Python. When the stars are aligned just so and Hackety Hack is working well then we get to use Hackety Hack. And this is really fantastic that we expose kids to all this stuff but really what kids are learning is that programming is fun and kids reward things that are fun by wanting to do them more often. We're instilling in them this idea that all this stuff that we do every day is awesome and that they wanna do more of it and that's really, really rewarding for them and for us, this is the way that we engage young programmers and it's the way that we need to continue to engage young programmers. One of the other groups I work with a lot is RailsBridge. You're gonna hear a lot about RailsBridge, we have a number of speakers who've been involved with the program and the organization. If you've never volunteered for a RailsBridge workshop, do it, you'll learn a lot about what you know about programming, you'll learn a lot about what you know about teaching, and you'll learn a lot about how to take all of that information back to the rest of your team. RailsBridge primarily holds workshops for women right now. We've done kids ruby workshops in the past and one of the things that we've done before and I really wanna start doing again is getting our workshop format and our curriculum into languages beyond just English. At RailsBridge, the big thing that we're trying to bring to our attendees is that, yeah, programming is hard, but it's only hard, it's not an impossible feat to learn to program for anyone in this room or in this world. It's something that is attainable by everyone and the main goal of the workshop is just demystifying that process and bringing that to everyone. So we use different techniques when we're working with kids at Coder Dojo than we would ever use working with women and minorities at RailsBridge. So with RailsBridge, one of the ways we accomplish this is we get all of the development tool set up out of the way the night before. All of the hideousness of getting ruby onto a Mac right now, we do it on a Friday night over pizza and drinks so that it's not part of the actual fun and joy of programming, it's not part of that process and we have the full day to focus on the act of programming itself and not on infrastructure because that stuff sucks. Even if you've been programming for 10 years, setting up a development machine isn't a lot of fun. And then we get to spend that whole day focusing on ruby for people who are brand new to it, mixing in a little bit of Rails or doing like a Ruby crash course and then going right into Rails depending on the past experience of the people in the group or just going whole hog and throwing a Rails app up on Heroku doing something fun with a day's work and that's really excellent. And so what all of this comes down to is that the real challenge in teaching Ruby is gonna be finding out why your pupils wanna learn Ruby, what is their goal, what do they want to achieve and how can you as a teacher actually help them realize that? So the easiest way to figure this out, I've discovered, believe it or not, is just to ask, why do you wanna learn Ruby? So I've had a bunch of answers to this. My three favorites so far are my job sucks and I hear you guys make tons of money. I want in, how can I do this? Anyone who's coming, who sees what we have in this room right now and is coming from another programming environment is probably gonna be like, why are you guys all friends? Like this is great, this is something wonderful that we have and it's not the language that makes that so, it's the people but the people are gonna bring others into the language so we have to make sure that the people who know how to program but not in Ruby that their needs are met because if we spend the whole day teaching basic programming, they're gonna get bored and leave. And the last one are the people who are just curious about programming, never done anything beyond like a word document with a computer in their life or maybe even never used a computer in a serious fashion and just wanna know how they work. There's a driving curiosity as all of you know and many people of just how do I take this apart and figure out what's going on? Ruby's not the best language for that on a computer as I'll get into a little bit later but this is still a class of person who might ask you to teach them Ruby and it's good to know what they want out of it. So at this point, I'm gonna ask that you check your assumptions at the door and keep an open mind. I'm definitely up for debate about all of this but don't dismiss anything that's about to happen out of hand and if you are a hater, the doors are staged left now is a great time to have a coffee break. Great, no one's leaving, awesome. So what are we doing right now teaching Ruby? Well, we generally start with data types. So we've got some numbers, numbers are cool. We've got both integers and floats here and then we might talk about strings and symbols or maybe we'll just pretend symbols don't exist because they're hard to explain and then we'll talk about truth and false and our truth is true and false and bullying expressions and how those work in Ruby and then we'll go over like collection structures like arrays and hashes and then we'll maybe assign some variables and then maybe we'll use those variables in Ruby expressions and then we'll do some console output, good old puts, nothing beats puts and then we'll get into conditionals which is like the first kind of mental overhead of putting things together where we say if some condition holds true then do this one thing otherwise do something else or maybe do nothing at all and then we start talking about loops in like the pure computer science sense of the thing where we just step over and change a value and check an expression's truth value a bunch of times and then maybe if we're lucky, if we have time we might do something like food.upcase and actually talk about methods. So what's wrong with this picture? Did you guys feel like that went a little fast? I went through that pretty quickly and if you spent four hours on all those things the rush of information that just hit you is what that feels like to somebody who's completely new to Ruby. It just all comes at you way too quickly and that was purposeful to try and put you in the mindset of somebody who's new to this. So one of the things that's wrong with this picture one of the big things is that we introduced six whole disparate concepts before we even talked about the concept of a method which is pretty central to Ruby. I think you'll all agree. And what's worse is that we didn't even talk about classes or objects, right? Like the things that we hold dear to Ruby were just like that's hard, let's do conditional statements. So we don't actually teach the things that we love about our language and that doesn't make any sense. Why are we still doing this? I don't have a good answer for you. The best I can come up with is that the majority of people in this room actually let's do hands, hands are fun. Raise your hand if your first language was object-oriented. That's more than I expected. Raise your hand if when you first learned it you knew what object-oriented actually meant actually. All right, kinda, maybe, a little. Yeah, we all learned from venerable programming languages. These languages are awesome, don't get me wrong. I love me some C. I don't touch Pascal with a 10-foot pole. But anyway, Ruby is not a computer language and this is the part where I expect most of you to walk out the door. Ruby, like it runs on the computer but that's not central to what Ruby is. Not even a little bit. If I gave you a magic ball and said this language called Ruby runs on this ball then it wouldn't make any difference than if it runs on an Intel CPU or a PowerPC CPU. It doesn't matter to Ruby. There's nothing in Ruby that cares about the fact that it's running on a computer. So why are we teaching Ruby like it's computer programming language? Instead, let's teach objects. Let's let Ruby be the computer. Let's treat objects as the lowest level concept that we ever talk about with our students and see where that takes us. But Steven, if we try to teach objects and all of that other stuff that I already whirlwinded past you, everyone's head would explode. Well, yeah, it would, but their head was gonna explode anyway with all that stuff I just showed you. So instead, what I wanna do is teach objects and only introduce that other stuff that we started with when it actually matters towards furthering our goals, seeing what else Ruby has to offer. So don't just go ahead and teach them a whole bunch of things. Give them this idea, Ruby is objects. And then let that idea sink in through exploration. So the best tool for learning Ruby is IRB. We've all experienced that. It's wonderful. So what I'm gonna show you now are some code samples that you might bang into IRB when you're kind of pair learning with somebody who's brand new to Ruby and you're gonna be teaching them object-oriented programming through Ruby. So what's the first thing that you start with? Well, everything is an object. Five is an object, 42.0 is an object, hello is an object, and an array containing one, two, and three is an object. Everything in Ruby is an object. Object is an object. Class is an object. Seriously guys, everything is an object. Like, everything. Everything. Objects receive messages. Something crazy that happens here is they actually use send explicitly. And I do that for a really specific purpose. I've taken out everything that we love about Ruby in order to emphasize what's actually going on behind the scenes. So any method that you send to Ruby is a message sent to an object. And we all know that, that's great. What's not great is that method calls look like a bunch of other things that happen in other languages or in other ideas of what a computer is that collude in the student's head and obscure that concept. So let's actually send messages explicitly just for a little bit. I'm not gonna do this all day. In order to really review the fact that that's what's happening, everything here is intended to reveal what Ruby actually does when stuff happens. So you can send some messages, and I just have some example messages that we might send. And then we get to talk about the fact that objects have class. So you can get the class of an object with this really sweet method called class. So you send them a class message and you get back the object that represents that class. Holy crap, guys, classes are objects. They weren't kidding. When they said everything was an object, especially to people who come from other object-oriented languages, or as I like to call Java, procedural language with objects. It's really important that you emphasize this fact that objects and classes are one and the same, and classes are as dynamic as anything else in the system. So five has a fixed num class, four point not is a float, and the array containing he's crazy, which I know half of you are thinking right now, is actually an array. So now we get to talk about a narrative. And I like to teach with narratives because they give the user something to pay attention to that's not a bunch of technical mumbo jumbo. It gives them a thread to follow and an arc where they can kind of figure out where the information that they're receiving actually comes into play. And so my kind of demo right now is called the pen and the scribe. And like every good story, it begins with object.new. So this first concept that we have here, there's a message called new, which you can send to any class and you will get back a new object of that class. And we've just given this object a name, which is pen. So rather than talk about, well, this is a variable and we're setting a variable. We're giving a name to an object that we want to use. And now let's define a method on this object. So we're going to define a method called 2s because that string that we saw on the last slide wasn't all that pretty. So we've decided to dub this pen, a trusty pen. And now we can move on, we get back now, which is just an artifact of the method definition. And we can use this by sending the 2s message to our pen. And what's more, any time our pen needs to be represented as a string in Ruby, we'll get back that same string. This is wonderful. So we have our trusty pen and now we're going to introduce just a pinch of syntactic sugar to really drive home this concept. This is actually going to help the user link in their minds what's going on. And this is one of the reasons I start with a single object instead of starting with a defining a class because we see, we've defined this method pen or this method 2s on this pen. And now when we send that 2s message, we get the results of that method that we wrote. And that visual link is really key for some types of learners, but it doesn't hurt anyone else and it's a really wonderful thing. So do this more. And now we're just going to assume that everything in Ruby is magic and unicorns and rainbows and we're just going to pretend that a right method exists. And we're going to get an error. But we're going to get the best error in the entire Ruby language, which is a no method error. And this no method error is great because it tells us what we need to do. Assuming that we've been doing this the entire time, we know how to fix what happens when a method is undefined. We can just define that method. But instead of defining it with good old puts, we're going to use the kernel object explicitly. And we're going to do that because now is not the time to explain implicit receivers. Now is not the time to explain mixins or the fact that there's this kernel module that every object has access to and you can just kind of call methods on nothing and they'll work. That's a lot to take into if you are brand new to programming. So let's have this kernel object handy and let's use it explicitly. And we're just going to put this thing out to the console like you do. And now we can write anything because we can write any object to the console. And since everything in Ruby is an object, we can write anything. We can even write our own trusty pen. This is great. And after about five minutes, this is boring again because you've written all of the things that you care about and it's time to move forward and how might one move forward but adding a little bit of color to your life. So we have a feature request which is that we want to implement color. In order to do this, we want to have this pen contain an ink color and like any good Rubyist, we're just going to pretend that this works and see that it doesn't. And this is why no method error is the best thing in Ruby. And this is because we get a no method error. We didn't get like a no property or like a no actually like nothing happened here that is variable setting. What we had was a no method error. So Ruby has no method ink color equals for our trusty pen. Wow, that's crazy, right? Like didn't that look like variable assignment just now? It did to me when I first started Ruby. The fact that this is a method is kind of mind blowing but it's also kind of awesome because it means we know how to solve this problem yet again given the context of what we've already learned. So we can define our method pen color equals and we'll have to spend some time here talking about instance variables which I'm not going to do for you guys because well you know enough Ruby. And now we can actually display this color by revisiting our 2S method and redefining it so that we have a trusty colorful pen and we can set our ink color to purple or if we teach too much we might set it to red. And now every time we evaluate our pen we'll get back our trusty purple pen and everything is great except that we're not actually printing color to the console and we're not gonna right away because who wants to deal with ANSI sequences on a day like today when we're doing great and having fun? So instead let's just make the text prettier. So let's actually implement a method that I call sparkly write and we'll use some hideous ASCII sparkles that I use whenever I don't have access to Emoji and what we're gonna do is we're just going to change the string that we're gonna write to the console by putting it inside some other text. But then what's gonna happen is we're gonna use this write method and what's funny is that we didn't specify to which object we are sending this write method. Well dear student, as it turns out if you don't specify the object you're sending a message to it sends it to itself. So our pens own write method is being called here by one of our other methods sparkly write and we can use this just like we do our regular old write method and everything is fantastic, great. And we have our trusty purple pen in wonderful sparkles. So now let's revisit that color issue but again, hence these sequences. Let's do something else. Let's instead generate an HTML P tag and do that. So next up is the most hideous slide in my deck because 30 column text does not a good code editor make but the complexity here is not in the string that's just some escapes to wrap around HTML style attributes. What we're doing instead is this conditional and unlike the first conditional that we introduced where it was just one of many things that are sort of unrelated this conditional is a way of accomplishing things under the context of our objects and their messages. So if we have an ink color on our pen we're just going to write a P tag with a particular style attribute that gives it that color. And if we don't, we're going to write it out like it's just a regular old P tag and now we can write anything we want in HTML and everything is fantastic. So what have we introduced at this point? Well, we've talked about objects and how objects send messages to each other and that we can define and use methods for responding to those messages. This is really key. This is something that I didn't learn about Ruby until I peeled back like eight layers of the onion around this weird looking basic like language that I had been fiddling with because Bash wasn't doing enough for me. We've done a lot of cool stuff and now it's time to bring out the big guns. It's time to get a little classy. So what we're going to do is we're not going to use the class syntactic sugar because that again that hides the fact that a class is just another type of object and we emphasize that a class is an object through two ways. We assign that class to a value in this case a constant scribe and we create that class with class.new. So class is a class that creates new classes. Everybody remember learning that? Did that not break your head a little bit? This is great like that feeling of learning and so we can initialize our scribe and we can give it a pen and we're also going to create an array of items that this scribe is going to take note of throughout the session and then we're going to implement that note method just by taking in an item which is any old object and we're going to use the shovel method. Note that there's a dot in there that is a method not an operator syntax. We haven't talked about operator syntax yet. We're just dealing with objects and messages. So we use this shovel to just put that item on the end of the array and I don't have enough room on one slide. So now we get to actually teach our scribe how to write everything and we do that by sending a message. There's not a loop here, not in any way that we care about. This is just saying that each item we have in this array there's a method each that will just walk over and just say like well this method or this object and then I'm going to run this block of code and then next object and I'm going to run this block of code. Sure we know that somewhere in there a loop happens but who cares? Who really cares that a loop happens? We have an each method. So we use this each method, we write everything to the console and that's our scribe. So let's get a new scribe and I've dubbed my scribe Miello who you can all Wikipedia if you care and I've entrusted him with my trusty pen. I've given my pen away to Miello and he's going to hang on to that pen and use it to take note of things and later to write them down for me. So Miello's going to note the current time and he's going to note the fact that I'm just about done with this demo and then when I ask him to write everything he's going to do it and that's my story. So I've just shown you what it might look like to teach Ruby with objects or if you want to look at it a different way I've shown you what it's like to teach objects with Ruby. You could do this same thing in any other valid object oriented language as in not Java. I hate to bash but really it doesn't work the way it should. So why is this better? By starting with everything in Ruby as an object you give the student an axiom that they can then use whenever they're considering any other piece of information that you give them for the rest of their learning career. If everything in Ruby is an object I have a constant piece of knowledge to which I can place everything else around that. It's a root that you can hold on to. Something fundamental that you don't get when you jumble everything out at the beginning and then try to relate these things later. We also don't bombard people with new concepts. I didn't throw infinity new things at you and then be like now use all of those things and make a game. I introduced them only as they were needed to further the plot. And that just, again, it gives that a context so that you can use all that information. And once you understand how Ruby works introducing all of the things we love about Ruby like class syntax, like operator syntax, like all of this extra value add that Ruby has because Ruby loves us is really easy to digest and understand because they understand what's going on under the hood so to speak. We didn't bother teaching them about array offsets or pointers or any of that stuff because Ruby doesn't care. But what Ruby does care about are objects and how they interact with each other. So by teaching that as our base we've enabled them to better absorb any information that they'll learn about Ruby for the rest of their programming career. Thanks.