 Thanks everyone for coming. It's a great pleasure to be here at RailsConf. Just so we know, who's coming to RailsConf for the first time? Wow, that's amazing. Cool. Welcome. And we're going to be talking to you today a little bit about coding dojo and how you can use the dojo to improve your coding skills and become better developers. My name is Carlos Sosa and this is my friend David Rogers. We're both from Orlando, Florida. We work for Code School and we love development and we love teaching. And that love for development and for teaching others how to develop brought us to the coding dojo and we formed our coding dojo group back in Orlando a couple of years back and we ran that bi-weekly for about two and a half years and we also used it, the coding dojo as a teaching tool. So what we're going to do here today is try to teach you guys a little bit about our experience running the dojo and we're actually going to run a dojo here with you guys and hopefully you can run dojos on your own, on your company, with your friends, on your local meetups and this is a message to all developers, right? We're all developers here. Even if you're not, if you don't spend your day-to-day coding, I'm going to ask you to put on the developer hat for just a little bit to understand where we're coming from and then the problems that we're trying to solve with the coding dojo. And we have different levels of expertise as developers. Maybe you're a beginner developer, you're just starting, you're on the first couple of years of working with software development, with Ruby, with Rails, maybe you just graduated a DAF bootcamp, maybe you just graduated college, or maybe you're going through all nine classes on learning how to program in Ruby and JavaScript and whatever. Or maybe you're a little bit more advanced, you're more on the intermediate level, you've been working with some programming language and framework for a couple of years, you're starting to get more responsibilities at work, you're starting to lead projects and maybe you're even more expert, maybe you've been working with software development for maybe over a decade, maybe you're an architect, maybe you're responsible for the architectural decisions in your company. And I guess regardless of the level of expertise that you're at, you've probably realized that at this point, the technology that you're working with, it gets better, it evolves. That's the natural way of things. The tools that we use, they're getting better. And this is especially in the open source community because there's sort of a natural selection. If something is not good enough for the community, the community will naturally look for better ways of doing something, for better practices, for better tools, better frameworks. Just as an example, Rails has an average of 100 commits every week. So things change very, very, very fast. And Rails is just one of the projects or the tools that you use on your day to day. When you stop and think, you're using Rails, you're using Ruby, you're using Bundler, you're using a variety of open source tools, and they're always changing. Every day, there's many changes going into those projects, new features being added, old features being removed, existing features being changed. And it's really, really hard to keep track of all the changes that are going on in all the various tools that you're using. So what I'm trying to say is that us as developers, we are not necessarily getting better at the same pace that our tools are evolving. It's very hard to keep track of all the changes that are happening in the ecosystem, and still being able to put on your nine to five and pay the bills. And it's good to look at other types of artists, other people that work with creativity or art, say musicians and athletes that also rely on their art, right, and they need to practice. So Marshall Artists, like the first guy on the first slide, he goes to the gym 24-7. He's practicing a lot. Musicians, they practice a lot before going into the studio, before putting on a show. Is there another microphone perhaps? No? There's just one microphone? Oh, yeah, that sucks. So, well, so, yeah, so all these athletes and artists, they spend countless hours in the gym or at the studio practicing their art, so when the time comes to perform, they are prepared. So they all practice. Do you want to talk a little bit about practicing, David? Pass the mic. Yeah, so the one key point here is that as practitioners of an art or craft, we need to practice as well. Anybody read Malcolm Gladwell's book, Outliers or Heard of Outliers? I think the one takeaway from Outliers is that the one, while it appears that some people are exceptional and live outside of the regular bell curve, would it actually turns out to be the case is that they were given or have spent much more time practicing. On average, it's somewhere around 10,000 hours worth of practice in order to become an expert in a particular field. That was his assertion. And the one big takeaway from the book is that, is kind of summed up in one quote there, that practice isn't the thing that you do once you get good. It is the thing that you do that makes you good. And some of you might be saying, well, I practice, of course I practice, I practice every day. I practice every day for nine hours, sometimes 10 hours, occasionally 12 hours, sometimes 24 or 72 hours at a stint and then eventually take a shower or die and fall into a coma. But the key thing to remember there is that work does not equal practice. Like Carlos was saying, when you look at a martial artist or you look at a concert violinist or you look at someone who practiced a craft or an art for their profession, they don't perform nearly as much time as they practice. There's a definite separation between the performance of their art and the practice of their art. So we can't really equate what we do on a daily basis nine to five as practice. That's work. We need to ship software. We need to perform. We need to hit our deadlines. We're concerned with building stuff that works. Work time is not practice time. Well, then that brings up the inevitable question. How then do we practice what it is that we do? And how should we practice what we do? What does practicing code actually look like? How do I practice as a programmer? Well, one way we could do that is to emulate how other artists practice their art and their craft. And we're talking about here is, for example, martial arts. So we have the term dojo, which in martial arts means the place where people practice those arts. And this is a term that was coined by Dave Thomas of the Pragmatic Programmers, and he brought that to the programming world saying we should set up a dojo for programming so we can practice code. And the keys to the good coding dojo is that we are providing, just like in a martial arts setting, we're providing a safe, collaborative, non-competitive location, a space and a time to practice together. We get together and we code, we learn something, we actually practice programming, we practice learning and teaching one another, and we also have a lot of fun, just like you would if anybody taken martial arts of any sort, yoga counts. I'll give you yoga, right? We'll give you yoga, right? So that's really the goal of the dojo. But how we actually live it out is, just like in martial arts, we practice kadas. And a kada in martial arts is this kind of detailed choreography of very ritualized movements that you practice, either solo or in a pair or in a group, and they don't really have a direct translation to if I was a martial artist, fighting another person. Like, I would not use my kada skills to win a battle. But they teach me how to punch. They teach me how to block. They teach me how to evade through the choreography, so that when the time comes to actually block a punch or throw a punch, my body remembers, even though my brain is not thinking about throwing a punch here. In programming, as Carlos was saying, Dave Thomas, pragmatic programmer Dave, Craig Dave, coined this term to describe, along with Kent Beck and some of the other guys, word cunning him, to describe a method of practice inside of a dojo. So inside of a coding dojo, just like inside of a karate dojo, we practice kadas, which are choreographed patterns of movements that we practice either in solo or in pair to reinforce skills that we wouldn't necessarily use in the choreographed pattern, but we would use on a daily basis when we actually come face-to-face with that variable that needs to be punched in the head. If we break that down, we're talking about choreographed patterns inside of the dojo, inside of a coding kada, as Craig Dave coined it. We're talking about test-driven development. And regardless of what you may have heard earlier today, test is not a devil. They are not a sin. And a lot of the pragmatic guys, a lot of the guys that we're talking about that coined the terms the dojo and kadas were in that deck referring to just enough testing. What we're doing in the dojo is not just enough testing. It is way too much testing so that we can practice the art of testing. When we practice martial arts and we learn a kada in martial arts, we're not punching just enough, we're punching a whole lot, so that when the time comes to actually punch, we know how much to punch and how much force we're to punch. If you play a musical instrument and you practice that musical instrument, chances are you're practicing along with a metronome. I like to make that analogy between a metronome and writing tests when you're practicing. You need the metronome when you're practicing music to keep that pace so you can focus on repeating your movements very, very slowly and with very close attention so you can gradually increase the speed to which you play to get to the point where you're shredding that speed solo and then when you play that live, it just feels natural. But for you to get to that point, you needed to start very slowly and you needed a tool to assist you. In music, that's the metronome. In coding, that's test-driven development, that's writing tests. And like Dave said, in the coding dojo, we're not practicing just enough tests. We're practicing a whole lot of tests. So when the time comes for you to write production code, you will naturally be able to tell whether you need to test-drive that feature or not. And another thing that we practice is pair programming. And pair programming is not just sitting down and coding next to someone. It requires a set of social skills. It requires knowing how to suggest a feature, knowing how to accept a suggestion, knowing how to accept a criticism and not take it personally. So there's way more to pair programming than simply sitting next to each other and either watching them code or telling them what to code. And again, like Kaikei was saying, these are social skills. And while they might be accentuated inside of the dojo, they definitely have a lasting impact as a programmer. I personally and Kaikei, we both pair program as a part of our writing production code as a part of our performance art. And we've found a huge increase in our productivity whenever we selectively and intentionally pair with others. Maybe we don't do it all the time. We certainly don't do it all the time because sometimes you just got to get stuff done, right? But when we do pair, we know the etiquettes. We know the social currency to be able to use one of the styles of pair programming, be it pilot, co-pilot where I sit back and Kaikei's on the keyboard and he types into the editor and I make suggestions or I notice syntax errors or I ask him questions about what he's doing and he tells me how he's going to do something. And then we switch and I start typing and he plays co-pilot and helps keep me navigating or use a ping-pong type of approach. There's lots of different types that we can use. For the coding dojo, especially when we're talking about small pairs or to practice pair programming, in this coding dojo we're going to use a ping-pong approach. And that approach is a lot like playing ping-pong. One person serves the ball by writing some tests and the tests then fail, right? Test-driven development, we do red-green refactor. So the tests fail, then he passes the mic over to the pair. His partner then writes some code to pass the test. They might talk, the pair will talk through it, but writes some code to pass the test and then immediately writes another test that will fail to serve the ball back across the net to his partner. We'll see an example of that a little bit later. We'll do what's called a practice kata. Kaikei, why don't you tell us a little bit more about the different types of katas that we could do. Anybody have any questions so far before we go on? Anybody tracking on that? Four out of five fingers? Perhaps just one finger? No? Okay. So there's different types of katas. The three most popular, I want to say, it's the randori kata. They're prepared and the code retreat, which is more like an event, but we're going to treat it as a kata. And the randori kata is the most popular for meetups and schools and university. David is a teacher at a local university in Orlando and he uses coding dojo as part of the curriculum. And the way that the randori works, you have one computer and the code in that computer is projected onto a screen where an audience between five to 15 people, a little bit more than that, gets a little bit confusing. So the audience is watching the code, is watching the evolution of the code towards the solution all the time. So they're constantly learning things and watching where the pair is going with the code. And in the computer there's always two people, pair programming, the pilot and the co-pilot. And every three to seven minutes they rotate. So the driver goes back to the audience, the co-pilot becomes the pilot and someone from the audience volunteers to be the co-pilot. So that way we have everyone in the room collaborating towards learning. And like Carlos was saying, I use this in my courses at Valencia. It's an introduction to programming course where we spend the first half of the course learning the concepts of programming and practicing reading the code, reading open source projects, identifying pieces of the code that we've talked about. And the second half of the class is all these coding dojos, this randori style coding dojos. Over the couple years that we ran the coding dojo in Orlando, we got a mixed bag of folks from all over the spectrum, people that had no coding experience all the way up to people that had been coding for years and years and years and years. And strangely enough, the super experts were the ones that were least interested in the format. But we used it as a method of teaching ourselves new tools, new techniques, completely different languages. Our first attempt at a Python coding dojo was a complete dog's breakfast. But we came back, we learned enough Python that now I actually run the Python user group in Orlando and teach other people how to use Python and when to use Python and that sort of thing. We taught a bunch of people Ruby, we taught a bunch of people JavaScript, learned that there are like 17 different JavaScript frameworks and a new one every week to run tests or implement assertions. That's always fun. But the key is we give everybody a timebox and we wait for either everyone gets a chance to code, we solve the problem which very rarely happens in the entire timebox to maybe a two-hour time frame. So that really works well for a classroom setting where you know you have X number of hours to participate and you have somewhere between that magic number of 5 to 15 people so that everyone can get a chance to code instead of that two hours. And one thing worth mentioning too is that the Randoor style is also a great way to interview developer candidates. If you want to move away from the typical where you see yourself in five years all that bullshit and get to what matters which is coding and seeing how efficient your developer is and how willing to pair program, how willing to collaborate he is the coding dojo I want to say is the best way to do that. Because you're hiring someone to be a developer so sit with them, code with them, seeing how well they fit with the culture with the pair programming culture in your company or with the development style that your company adopts. It's really cool and envy labs and it's worked out great I want to say. The second type of kata is the prepared kata and that is when you watch someone perform a kata that has been previously worked on. So David and I are going to show that to you in a little bit. We're going to start coding a problem from scratch and we're going to be pair programming on that problem. You can either pair program or do it solo but the thing is you're showing people one way to solve the problem and you're showing them also a bunch of tricks that you may use. Perhaps you're showing them how to use a different editor that just came out or perhaps you're showing them one feature of an existing editor that you might already use. You're showing them a different API for the language so there's different, there's a multitude of things that you can learn by watching someone perform a prepared kata. We actually had the opportunity to have Corey Haines, anybody heard of Corey Haines? If you guys know anything about the dojo, you probably heard about Corey Haines. Yeah, he's local up here. So he came down to Orlando and gave what he calls a code retreat and those are fantastic all day events where you get the opportunity to pair up with people that you've never programmed with before, maybe never seen before. Everyone agrees to solve the same problem he usually uses Conway's Game of Life which is a wonderfully brain bending program in whatever language you're trying to learn. You all pair for 30 minutes or an hour or whatever the time box is for that event. You pair with different people at the end of the time box. You're free to switch pairs, you're free to switch languages. You're free to try a different approach, add some constraints, whatever but you agree to do it all day. You get a lot of practice and a lot of time. It's similar to the format that we're going to use today for the second half or second two-thirds of the seminar. If you want to know more about Corey Haines code retreat or perhaps bug him incessantly on Twitter for him to bring a code retreat to your city you can find him at his horribly ugly website coderetreat.org and on the internets as at Corey Haines. Cool, so I think we're good to move on to show you guys a prepair kata that David and I practice and let's do it. Like I said we're going to do something that we've already worked on, we've previously worked on and we're going to show you how to implement a very, very, very simple calculator. And in this calculator is going to have one operation which is going to be addition. This operation should be able to accept two numbers and return the result. It should be simple enough, right? Cool, we're going to use Ruby Ruby 2.0 but if you have Ruby 1.9 in your computer it's fine. And we're going to use many tests also known as test unit for this and that's it. We're not going to use any framework, everything is built into the standard library if you can, you can follow along or if you just want to watch it and then try to do it on your own and then once we're done that's fine too, right? So this is like the first cota that we're going to run. And because pairing, because the ping-pong style pairing is a lot of vocal back and forth we're going to shove the mic right up here in the front and we'll attempt to talk into it as much as possible. So bear with us if you can't hear us just holler or throw paper or something. And also if you have any questions if you don't understand anything that we do we're going to try to explain everything as we go, but if you have any questions please, please, please raise your hand and ask us, don't hesitate. So, so far we have an empty file there's nothing on this file cota.rb and we're going to develop a very simple calculator. So I'm going to fire up Vim open the file everyone see? Good? Decent? Cool? Alright, so we're going to use mini test the unit because you have mini test unit and you also have mini test spec so we're going to do the unit type and to run our tests we also have to require mini test auto to automatically run this file we're going to start with our test case which is going to be calculator test mini test unit test case we got our test suite class and we're going to write our first test. So test adds to numbers so if you change it let me go to that same folder for an Ruby cota cannot load mini test auto auto run thank you there you go, collaborative thank you audience nice so now we got something here let me add clear and Ruby cota so that gives us proves that we were able to import the correct libraries we were able to create the correct test suite and that Ruby picked it up and it gives us a proper error message because we don't have any assertions yet so it's just saying hey we found one test there's zero assertions, zero failures, no errors and no skips right so moving on to the first failing test I'm going to create a local variable and instantiate an object from a class that I want to have but I don't have yet so I'm going to let my tests tell me what I should do next if I run this again it's just going to blow up right so I got a failing test so now I'm going to pass it along to David to solve that test yeah thanks for leaving me a lovely mess there it's real life man at least you didn't commit it so I'm actually going to type only the code that I need to fulfill this test and I'm going to do it right in the same file some people would split it out but for this simple example we're going to just do exactly what we need and so if I just define a calculator then that should at least change the error message and it does now I have one test no assertions but I don't have a big giant bar so I'm going to write a test this is using the ping pong method equals or equal equal I'm going to add two numbers together say one and one right rerun the tests and now I get barf and so I hand it back off to my pair ping so the error is saying there's an undefined method add so that's simple enough I'm going to come here and define a method add if I run it again now it's complaining about another thing which is sort of good if you're doing TDD you want either to make the task pass or to make the message change so this is to ensure that whatever code you're writing in your production part is affecting your tests right because I cannot count how many times it happened to me in real life I'm editing a file but it just happens to be a file with the same name on a completely different project so I'm editing like a calculator dot rb on a different project and I'm refreshing the browser wondering what the hell is this not taking effect so when you're doing test driven development you want to make sure that whatever code to make sure that your code is taking effect right the key there is run your tests and observe the expected failure or at least observe that something the failure has changed that you're having an effect so I'm going to save this add it to arguments run the test again now it's saying now it's giving us a different message it's saying it expected nil but it got two so I'm reading this and I'm thinking well that's kind of weird I'm not expecting nil I should be expecting two so that leads me to the conclusion that maybe we passed the wrong order to our assert method so if you go back here assert equal is very strict about the order of arguments so it can produce the best error message for you so what we should do here instead is put two calculator add one and one and when we do that and then we run our test again see that now the error message is it makes more sense right it expected to but it actually got nil now it's time to write the simplest thing that could possibly make this work and we'll probably make your skin crawl is to return two cool so now we have one test and one assertion now it's time for me to write a test a failing test for David to fulfill equal seven five and two so when I do that he's got a failing test awesome say that again what should you be spitting the two assertions in the two assertions test that is a good point I do that when I'm talking about different features right so there's it's really up to you how fine-grained you want to get because we're testing it if you look at the name of the test method it tests that adds two numbers so those two assertions they still belong to that idea to that context of adding two numbers right we're talking about the granularity of testing just simple assertion testing which is what we're doing with assert equal or any of the assert methods that's like the smallest little piece of a test that's the tiniest little piece of a test we then compose those assertions together into the unit and the unit in this case like Kaike has described is just that we can add two numbers there might be multiple assertions that describe how we can add two numbers and as we go through the example we'll see that and we'll start to break out what happens if we give it three numbers and that's when we break into another test method does that answer your question more or less great so I've got this busted up test sitting in front of me so the simplest thing that I could possibly do is I'm going to go ahead and do some math actually do some work here buddy I've got passing tests but I started to see already that the calculator is going to be a whole lot to type so I'm going to take a minute and just refactor rather than typing calculator all the dang time why don't we change this to just like calc that's still descriptive of what the object is but it's a lot less repetitive so I make my a couple changes to refactor and then I rerun the tests and boy it'd be nice if these tests were a little prettier but I'll leave that to another to another person now what do you think we've got the ability to add two numbers should we add some more two numbers or maybe we can move on maybe we'll move on and get a little more complicated so yeah why don't we write another test and this time I'll throw you a curveball you can add three numbers now we're getting fancy so if I expect nine three and three and three should add up to nine but it should be clearly clear that I'm going to need to do some copy-pasta here which is a great opportunity to refactor of course but I feel like making kaike work look at that ping pong sir cool so it says the wrong number of arguments it took three but it was only expecting two so I'm going to write the simplest thing that could possibly work or change this message right so what I'm going to do is add another argument but if I simply add another argument then I make that test pass but I make the other ones fail so if I look at the error message if I could look at the error message the green that's it the window is too tall right so if you can see here now I broke the other ones so what I'm going to do is actually make let me fix my window is actually make this third one optional if I run it again now I don't have a syntax error anymore now I have an assertion error which again is good right man it would be nice if we could see the differences there that white text on a black background is particularly you're right I wonder if we can make this colored right I wonder if we could make this prettier let's go ahead and add require mini test pride and make our tasks fabulous so now you can see down at the bottom here that we have a little coloring might not be able to see it clearly on the projector but it does make a lot of difference when you're looking at your terminal you get a nice big red F so the big F is saying that expected nine but it got six so I'm going to go ahead and add C to make it pass cool because I don't like reading a lot I'm just going to remove return because Ruby automatically returns the last expression of the method so I'm going to run this again and now all my tasks pass cool let's see what we can do now should we add more numbers so we can refactor this whole thing one more test so I don't want you to cheat because I don't want you to keep adding single arguments so I'm just going to add five numbers right so I'm going to copy and paste this and copying and pasting never resulted in any error never it certainly results in highly maintainable code twenty five five five five five you can tell we're mathematicians as well neither one of us aspired to computer science cool now you got da da da so back again we go the simplest thing that I could possibly do is add fives of a bunch of junk inside of my ad method but that seems well stupid so let's instead just replace hello is that a duck duck face there we go let's instead replace this with a splat it's my favorite I should get rid of my wrong arguments error oh god but I got a whole bunch and you know what this is running this test thing is getting kind of tedious I don't like flipping back and forth between the windows is there a way we can automate that I wonder well I'm more of a bashy person than most so we could add auto watch if we really want to add a dependency and all that stuff and download a jam grunt I'm more of a javascript guy than a ruby guy so I know alright so and then followed by guzzle and yak I think is coming eventually right we could do all that and wait through like 15 minutes of downloading stuff but I know bash really well so I'm just going to write myself a wonderful infinite loop but I'll add a sleep so I don't blow my stack out and now every two seconds or so it's going to rerun the tests I never have to touch that window again thank you very much so it's just a simple lame lame pretty simple here let's let's do this so pretty simple bash infinite loop while true run the tests sleep for two if we wanted to make it even closer to what kaike type last we'll do a clear and while I run that every two seconds it's going to refresh the screen and rerun the tests for me that is the poor man's file watcher that's just in case you're running free bsd or a clone thereof and do not have watch installed by default so now the simplest thing that I could possibly do here is numbers now if this was javascript I would probably use reduce on this array but this isn't javascript so what is it in Ruby inject reduce oh look you steered me wrong and so reduce is going to take is it going to take the same arguments first argument is seed so I take the seed and then I give it a block and so then I have my my value and my number let's find out let's find out what happens so we give it a block and then we'll just return v plus n from the block write the file and see what happens you probably need to use for ends if you're passing block the best part is I never have to touch this dang test file again he just keeps running my tests so now I've got I've got a reduce function that works for infinite number of numbers and back to green tests and I've already noticed let's just go ahead and make this guy a little bigger I've already noticed that I've got all this repetition in here right I've got calc equals calc equals calc equal oh god so let's reduce some of that repetition reduce he's a funny guy trying to inject a little humor haha so I'll add a little setup method get rid of all those do a little find and replace rerun okay groovy groovy should we go further I think we've pretty much added as many numbers as we could possibly add we could add additional tests or refactor this test to say adds an infinite number of numbers and throw out all kinds of different numbers inside of there or we could go do something completely crazy and totally off the spec we could but if we added arguments instead of numbers of strings we could automatically convert like HP would do is ruby as good as PHP test ruby as good as PHP so what should what would we expect it to equal if we do calc dot add say one and banana what should we reasonably expect this to return to us so that would probably generate an error I would expect so and then we pass number two as a string sure that seems reasonable ruby should be able to convert a string with a numeric value so that should equal to three integer let's see oh string can't be coerced into fixed num that sounds wonderful and I'll let you take over from there so ruby has a method I'm not sure if it's injected into object it's a part of object which is two I which is going to try to convert whatever that object is into an integer so in this case we're converting the string to into an integer and that made our test pass but now but then we get back to that banana that I was trying to throw earlier so here's the thing we're looking at the name of the method test adds string but we want to be a little bit more specific about what that does so I'm going to rename this method to test parses valid strings and I'm going to write another test that says test raises error for invalid strings which kind of gives us a bit of a path of where we're going with implementing this test method so what we want to do is use this and I believe this is in the plural an argument error and then we pass it a block if we pass it an invalid argument so in this case a banana so that brings us back to our original question what is the numeric value of banana apparently two I is not working the way we expect it to or at least ruby is doing something with it so maybe we should figure out what the numeric value of banana is one way we could do that is to write a test for it we could write an expectation we expect x to be yeah use your magic fingers if you want you can do I don't think that helped now should I make this one bigger and this one smaller you can even make the font size on the test smaller so now we're stuck with this what is the numeric value of banana I would approach it by writing a test for it test numeric numeric numeric value of banana that's a drinking game every time a presenter says banana you have to take a drink I would expect banana to raise an exception if I tried to coerce it to an integer but apparently ruby is doing something else with that so maybe it gives it a value of zero maybe it's trying to turn it into a number I know another language that begins with a P and ends with a P that does something similar that confounds many people and we'll use that same two I trick that you just showed me and let's see what happens oh I get a passing test yep so just to verify I'll make this another value like one maybe the value of banana is one nope the actual value is zero and interesting thing there you can see that the tests are flipping every time we run it because it's implemented as a hash and they're not fun stuff so then if the numeric value of banana is zero how are we going to figure out that we've been given a banana instead of a number inside of our calculator well we could start with a little refactor right we're probably going to need some code inside of this block when we run into a number an argument that we've been given that isn't numerically isn't a numericalized very value something that we can coerce then we need to do something different so we'll put a little guard in there because we want to raise an exception according to Carlos's test and so the reason behind is we realize that if we pass a valid string that is able to be parsed to a number say one in double quotes so so if you pass a string that is able to be converted to an integer say one in quotes it's successfully converted into one integer but if we pass a string that's not able to be converted to an integer it's going to resolve to zero so what we realize is that the valid argument would be if n-2i equals zero and at the same time if this original string was zero then that's a valid one otherwise it should raise an error so the only way that it's a valid conversion is if the integer zero came from a string zero that's what that code means I'm scripting my brain is programmed to use triple equals at any time I compare it to zero I'm sure it's actually my fingers are trained to type oh you're going to type a zero now aren't you let me just build another equal sign so yeah like Carlos was saying if it converts to zero the number that I'm giving converts to zero but it isn't actually string zero then that would be one of those strings that coerces to zero for us thank you banana yeah if you coerce it to a string whether it's the same as itself as an alternative take the number, sorry take whatever comes in and coerce it into a string and test it whether it's the same as itself if it is then it's a literal it's a string so same as that well I don't think you need a second bit let's see apparently not right now valid strings are failing but that's the beauty again of the dojo if there's something that I want to experiment with I'm at green tests I can try something else just to see well how does Ruby behave this way so we're going to take a little break Project Oiler is a great if you don't know about Project Oiler spelled Euler, E-U-L-E-R Euler Euler Hello ProjectEuler.net has a ton of computer science problems that seem trivial at first but if you implement them in the most trivial manner possible you'll do something silly like blow out your recursion stack or take an hour and a half to resolve or something like that so you have to think about them a little more but you can do it in a test-driven style and once you get passing tests on your hour and a half long solution then optimize, refactor and get a more optimal solution there's lots of prime number calculations inside of Project Oiler Euler you'll never forget that now Code Wars is another that website launched recently at CodeWars.com you can sign up for JavaScript, CoffeeScript and Ruby I think right now they've got a bunch of Code Codas, they even call them Code Codas you get different belts starting from 8th Q and working your way up to Grandmaster Black Belt CodeWars.com I recommend that to my students as well and it's again emphasizing test-driven you totally don't have to do it test-driven but it's a great way to practice books on the subject which we'll talk about at the end of our presentation. There's a great book by Emily Clark by Navigato Bam Cody and Dojo Handbook Emily Buck forward by Uncle Bob Rob Barton so this has a lot of Codas in it, a lot of very standard Codas, what we found in running the coding Dojo for two years, two plus years at that point was that you can recycle the same problems over and over again once you find a couple that are easy to explain and get everyone to wrap their heads around you use them over and over and over again and you try them in different languages you try them with different constraints you just try to see if you can solve the dang problem all kinds of things come into your head there are weeks in between when you do the Dojo when you do the Dojo again some of the common ones are like Roman numeral conversions Uncle Bob Martin's famous one was the bowling game we did that one time at the coding Dojo in Orlando we tried to do the bowling game one time and what we discovered is that nerds actually do not know how to score bowling at all that knowledge is completely encapsulated in computer software now and no one has committed any of it to memory we don't even understand how that software runs anymore we just know that occasionally turkeys come on the screen and only if we have the bumpers up so those are great resources for that let's take a break and when we come back we're going to give everybody a post-it note a different color post-it note this is some logistics you'll pair up we'll do like a code retreat style coding Dojo with the entire group we've got a problem for you we've got some constraints for you you can totally use what you've learned just right now to practice we'll do that and we'll take another break and we'll do another coding Dojo after that with a different problem you don't have to participate in all three you don't have to participate in any of them if you don't really want to but we encourage you to come and play and practice with us 15 minutes before we start we want to make sure that everyone has Ruby installed that is pretty much the only prerequisite just to have Ruby at least 193 I want to say which is the version that comes with many tasks right no one except everybody know how to figure out their version of Ruby everybody know how to run Ruby from the command line how far down the rat hole we need to go so if you want to see what version of Ruby you have you run Ruby-dash version there you go boop Ruby-dash version and it should be at least 193 for this one I'm using 2.0 which is fine you don't have to be on 2.0 but at least 193 and we'll show you that magic bash and temptation as well if you want to use that in your tests so everyone has Ruby at least 193 and at least one text editor cool something emacs flavored not right so the first problem we want to group into pairs of three right so you might have gotten a post-it from David or maybe you got yourself and what we want to do is we want to group together into groups of three with people with the same color post-its so if you have an orange post-it you look for two other people with that same color post-it someone's going to have to get up going over the etiquettes real quick test room development as you might have seen us David and I doing here is red green refactor so you write a failing test before you write any production code giggles you get that test pass and if you need to you go back and you refactor and then you do that cycle that's the cycle you want to follow just because you get to a green cycle does not mean you have to refactor but it's a good time to take a break look back at the code as a pair as a group and say should we refactor is there something we could make simpler is there something we were copying and pasting is there a different way we could do this is there another test we should add what you're going to do next right and we're going to do the ping-pong pairing just like David and I did you write a failing test you pass it along to your co-pilot most of you have three people so you're going to start with a pilot and a co-pilot and then the third person is going to be the audience and what we recommend is that the audience does not talk on red that means whenever there's a failing test you let the pair figure out what the solution is so only the driver and the co-pilot are part of trying to figure out how to make that one test pass but don't think that you're stuck on Alcatraz or something if you're a pair and maybe you're really new to Ruby or maybe just new to test-driven development and you're like I don't know what to type here do you know what to type here I don't know what to type here please ask your audience first and if none of the three of you know what you're doing next or what you need to do next I'm going to be walking around helping out Internet is not super cool but it's also good to look up Internet is not reliable here but you're more than free to look up documentation and references and ways to use the API and different assertions that you can use this is an open book test and another thing to keep in mind is IRB is open game as well like you saw with us when we were doing the banana test we wrote a test to describe to assert what we thought the value of banana would be when we cast it to integer you're more than welcome to just close down your editor or bring up IRB in whatever fashion you want to and what is banana to I oh it's zero that's weird but you know whatever so like Kyke was saying the audience shouldn't whoever the audience member is don't talk on red if you're not coding keep quiet unless you're part of the pair and it's time to switch if you have an idea I think it should do this or I think it should do that rather than trying to describe too much of it in English I mean it might be helpful to talk about it a little bit in English show your working code show your idea in code just write an assert statement that does what you think it needs to do ask the code a question and this is not a code golf right some pearl black magic that you inherited from previous job so make sure that whatever you write it's explicit enough so that everyone in your group understands right so if you need to write a little bit more if you need to break that due in from a curly brace do a due in so do that right and as the audience this is like the one exception to the rule if you see the pair deviating from red green refactor like they start writing production code before they write a test say you know at or test or if you see them sit on they've written some code and they haven't run the test for a while and give them the buzzer survey says and if you see somebody starting to use voodoo whether or not you're part of the the pair or they just write something you're like what is that raise your hand say no voodoo or call voodoo on them call them all again tell them to do it over groups you've selected one machine to work off of please delete all the code that you had previously just make sure that you start from a blank slate you're looking at a blank canvas blank tax editor even good to start alright so here's the problem that you're going to do boom a calculator right it's going to have one operation which is going to be addition is you'll be able to take a variable for instance but we're going to add in a constraint you're not allowed to use inject or for that matter reduce this somewhat limits the playing field right so that is the plan of action any questions about the problem right cool if you guys get done with this before we get done with the overall dojo feel free to do what Kite and I did by expanding the problem what if we gave it strings bananas or what if we threw an object at it or whatever you know so we were going to use numbers.inject we're going to use array.inject but as we point out in the audience we can also use array.reduce so don't use inject don't use the reduce methods there is a third option available to you if you wanted to look at each element in an array just just saying cool and we're going to use three-minute rotation timeout so let's bring it up here am I mirroring you can just stick it over there so let's do simple timer pop that on the side window alright so if you need do we show like half of it and half of that this well but how do we show both at the same time it's called Moom yeah I use optimal layout basically the same thing so if you need to start your initial code this is what we use to start so requiring many tasks up at the top starting off with your task gaze and then writing the first task if you want to set up like the auto run thing is down here at the bottom remember ping pong write a filling task pass it along to your co-pilot whatever you expect us to watch this stuff? the timer? so then to do the timer put the timer up on the right screen so we're going to give you three minutes to go at the pier we'll give you three minutes as a pier as the current pier and then when the timer goes off switch I'll do the same thing and after that we'll do a little halftime let's stop for here so stop exactly where you are alright and now it's time for us to do a little retrospective on what we just did on this round so do we have enough pens here we might we at least have enough near enough pens enough pens per group so just like an agile retrospective we're going to ask each other just three questions what did we do well that we would like to do the next time we do this exercise what will we like to improve for the next time what would we do well that we want to repeat what do we do maybe not so well maybe we'd like to improve for next time did we meet our goals and why and again our stated goals are not did we solve the problem that really wasn't ever an issue that wasn't really anything we can continue inventing different edge cases to test this problem again so we can continue asking questions of this problem even this simple problem for a very long time so it's never really about did we solve the problem the world does not need another adder and most of the problems that we pick are going to be like that but did we learn something did we find out something new about Ruby or about the people that we work with do we practice our skills do we feel like we have gained some skill or knowledge because of this exercise and do we have fun so we can just just give you guys like another three minutes to figure out just ask each other those three questions what did we do well that we want to do for the next one do maybe not so well that we would like to improve for the next one and did we meet our goals and why or why not we'll give you guys another timer for that cool stop exactly where you are go back to your editor delete everything and get ready for the next problem again same group same three minute rotation same problem still on the calculator realm so you're going to be in addition but now your new calculator that you're going to start from scratch is going to need to take strings as arguments as an example you're going to add one as a string slash two and it's going to need to return the integer three the integer to make it look yeah stop wherever you want to stop yeah I believe there was an earlier presentation on just enough cool you can choose to use that last constraint that we offered that don't use inject take it or leave it doing the calc add with strings might be more than a big problem to solve if you want to use inject or reduce or you'll mama whatever doesn't matter the only requirement that we'll have is you have to take you have to accept strings like one, two, three, four in words T8 are you 10, 100 I don't care how far you want to go because there may be some typing involved right it should return and integer and your company class forget delete what you had and then start from scratch right right alright everybody pencils down no more coding just like we did before quick retrospective write down things that work well for this round things that could have been better and need improvement for upcoming rounds and also as a process as a whole like what did you guys like about the whole process what did you guys what would you guys improve about this workshop if you were to go to it again and did we meet our goals and why or why not so we'll give you a couple minutes to do that real quick as a group I will come by and delete your files so did we learn something did we learn something did we practice do you feel like you've practiced some did we solve the problem some solved some of the problem right solved ish the problem did we have fun awesome so if you want to know more about the coding dojo this is KK's new favorite book coding dojo handbook I'm totally picking up a copy there's way more resources out there there are local meetup groups you should take this to your user group we started a whole group around the coding dojo in Orlando but we also because I ran the PHP group and I ran the python group at the time we also used the python group and the PHP group we'll probably do it again at node we've done it at Ruby we've done it at all user groups around if you want to know starting points for that I wrote a blog post on getting started getting past all the yak shaving of setting up the automated tests running in the background and the boilerplate for each one of the different languages you want to try that's in the Orlando dojo repo on github the Orlando dojo organization talk about meetups the best way to actually experience more of this is to do it in practice right so so go into meetup.com and look for nearby coding dojo meetups there's plenty of them out there and if you don't find one more than welcome to create one yourself all you need is a friend who you can pair with every week or so and then if you just put it out there put it online that you guys are meeting every week at this specific place at this specific time people will show up just be consistent just be consistent I think that's it for today if you guys want to talk more