< Return to Video

RailsConf 2014 - Workshop - Ruby Coding Dojo by Carlos Souza and David Rogers

  • 0:17 - 0:18
    CARLOS SOUZA: Thanks everyone for coming.
  • 0:18 - 0:22
    It's a great pleasure to be here at RailsConf.
  • 0:22 - 0:24
    Just so we know, who's go, coming to RailsConf
  • 0:24 - 0:29
    for the first time? Wow. That's amazing.
  • 0:29 - 0:33
    Cool. Welcome. And, we're gonna be talking
  • 0:33 - 0:36
    to you today a little bit about Coding Dojo,
  • 0:36 - 0:39
    and how you can use the Dojo to improve
  • 0:39 - 0:46
    your coding skills and become better developers.
  • 0:46 - 0:48
    My name's Carlos Souza, and this is my friend
  • 0:48 - 0:52
    David Rogers. We, we're both from Orlando,
    Florida. We're
  • 0:52 - 0:56
    from Code School, and we love development
    and we
  • 0:56 - 1:00
    love teaching. And that love for development
    and for
  • 1:00 - 1:04
    teaching others how to developer brought us
    to the
  • 1:04 - 1:07
    Coding Dojo, and we formed our Coding Dojo
    group
  • 1:07 - 1:10
    back in Orlando a couple of years back. And
  • 1:10 - 1:15
    we ran that biweekly for about two and a
  • 1:15 - 1:17
    half years? And we also used it, the Coding
  • 1:17 - 1:19
    Dojo as a teaching tool.
  • 1:19 - 1:21
    So what we're gonna do here today is try
  • 1:21 - 1:24
    to teach you guys a little bit about our
  • 1:24 - 1:28
    experience running the Dojo, and we're actually
    gonna run
  • 1:28 - 1:32
    a Dojo here with you guys, and hopefully you,
  • 1:32 - 1:34
    you can run Dojos on your own. At your
  • 1:34 - 1:37
    company, with your friends, in your local
    meet ups.
  • 1:37 - 1:43
    And this is a message to all developers, right.
  • 1:43 - 1:46
    We're all developers here, even if you're
    not, if
  • 1:46 - 1:49
    you don't spend your day-to-day coding, I'm
    gonna ask
  • 1:49 - 1:52
    you to put on the developer hat for just
  • 1:52 - 1:54
    a little bit to understand where we're coming
    from.
  • 1:54 - 1:56
    And then the problems that we're trying to
    solve
  • 1:56 - 1:58
    with the Coding Dojo.
  • 1:58 - 2:03
    And we have different levels of exper- expertise,
    as
  • 2:03 - 2:06
    developers. Maybe you're a beginner developer.
    You're just starting.
  • 2:06 - 2:09
    You're on the first couple of years of, of
  • 2:09 - 2:12
    working with the software development, with
    Ruby, with Rails.
  • 2:12 - 2:15
    Maybe you just graduated a Dev BootCamp. Maybe
    you
  • 2:15 - 2:18
    just graduated college, or maybe you're going
    through online
  • 2:18 - 2:20
    classes and learning how to program in Ruby
    and
  • 2:20 - 2:22
    JavaScript and whatever.
  • 2:22 - 2:24
    Or maybe you're a little bit more advanced.
    You're
  • 2:24 - 2:28
    more on the intermediate level. You've been
    working with
  • 2:28 - 2:31
    the, some programming language and framework
    for a couple
  • 2:31 - 2:34
    of years. You're starting to get more responsibilities
    at
  • 2:34 - 2:36
    work. You're starting to lead projects.
  • 2:36 - 2:40
    And maybe you're even more expert. Maybe you've
    been
  • 2:40 - 2:43
    working with software development for maybe
    over a decade.
  • 2:43 - 2:46
    Maybe you're an architect. Maybe you're responsible
    for the
  • 2:46 - 2:50
    architectural decisions in your company. And,
    I guess, regardless
  • 2:50 - 2:54
    of the level of expertise that you're at,
    you've
  • 2:54 - 2:57
    probably realized that this point, the technology
    that you're
  • 2:57 - 3:01
    working with, it gets better. It evolves.
    That's the
  • 3:01 - 3:05
    natural way of things. The tools that we use,
  • 3:05 - 3:07
    they are, they're getting better.
  • 3:07 - 3:10
    And this, especially in the open source community,
    because
  • 3:10 - 3:12
    there's sort of a natural selection. If something
    is
  • 3:12 - 3:15
    not good enough for the community, the community
    will
  • 3:15 - 3:19
    naturally look for better ways of doing something,
    for
  • 3:19 - 3:24
    better practices, for better tools, for better
    frameworks.
  • 3:24 - 3:28
    Just as an example, Rails has an average of
  • 3:28 - 3:33
    a hundred commits every week. So, things change
    very,
  • 3:33 - 3:37
    very, very fast. And, Rails is just one of
  • 3:37 - 3:39
    the projects, or the tools that you use on
  • 3:39 - 3:42
    your day to day, when you stop and think.
  • 3:42 - 3:46
    You're using Rails, you're using Ruby, you're
    using, you're
  • 3:46 - 3:50
    using Bundler. You're using a, a variety of
    open
  • 3:50 - 3:54
    source tools, and they're always changing.
    Every day, there's
  • 3:54 - 3:58
    many changes going into those projects. New
    features being
  • 3:58 - 4:02
    added. Old features being removed. Existing
    features being changed.
  • 4:02 - 4:05
    And it's really, really hard to keep track
    of
  • 4:05 - 4:08
    all the changes that are going on in all
  • 4:08 - 4:10
    the various tools that you're using. So, what
    I'm
  • 4:10 - 4:13
    trying to say is that us, as developers, we
  • 4:13 - 4:16
    are not necessarily getting better at the
    same pace
  • 4:16 - 4:19
    that our tools are evolving. It's very hard
    to
  • 4:19 - 4:21
    keep track of all the changes that are happening
  • 4:21 - 4:24
    in the ecosystem. And still being able to
    put
  • 4:24 - 4:26
    on your, your nine to five and pay the
  • 4:26 - 4:27
    bills.
  • 4:27 - 4:31
    And it's, it's good to look at other types
  • 4:31 - 4:34
    of artists, other people that work with creativity
    or
  • 4:34 - 4:40
    art. Say, musicians and athletes, that also
    rely on
  • 4:40 - 4:43
    their art, right, and they, they need to practice,
  • 4:43 - 4:47
    right. So martial artists, like the first
    guy on
  • 4:47 - 4:50
    the, on the first slide, he goes to the
  • 4:50 - 4:54
    gym 24/7. He's practicing a lot, right. Musicians
    -
  • 4:54 - 4:57
    they practice a lot before going into the
    studio,
  • 4:57 - 4:58
    before putting on a show.
  • 4:58 - 5:02
    And. The microphone died. There's another
    one. Is, is
  • 5:02 - 5:08
    there another microphone, perhaps? No? There's
    just one microphone.
  • 5:08 - 5:13
    Oh man. That sucks. So. Well, so yeah. So,
  • 5:13 - 5:17
    all these athletes and artists, they spend
    countless hours
  • 5:17 - 5:19
    in the gym or at the studio practicing their
  • 5:19 - 5:22
    art, so when the time comes to perform, they
  • 5:22 - 5:25
    are prepared. So they all practice.
  • 5:25 - 5:28
    You want to talk a little bit about practicing,
  • 5:28 - 5:28
    David?
  • 5:28 - 5:33
    DAVID ROGERS: Pass the mic. Yeah, so, I, you
  • 5:33 - 5:36
    know, the one key point here is that as,
  • 5:36 - 5:38
    as practitioners of an art or a craft, we
  • 5:38 - 5:42
    need to practice as well. Anybody read Malcolm
    Gladwell's
  • 5:42 - 5:45
    book Outliers, or heard of Outliers? I think
    the
  • 5:45 - 5:50
    one take away from Outliers is that, the one,
  • 5:50 - 5:53
    while it appears that some people are exceptional
    and
  • 5:53 - 5:55
    live outside of the regular bell curve, what
    it
  • 5:55 - 5:58
    actually turns out to be the case is that
  • 5:58 - 6:01
    they were given, or have spent, much more
    time
  • 6:01 - 6:05
    practicing. That, that, on average, it's somewhere
    around 10,000
  • 6:05 - 6:08
    hours worth of practice in order to become
    an
  • 6:08 - 6:10
    expert in a particular field was, that was
    his
  • 6:10 - 6:11
    assertation.
  • 6:11 - 6:14
    The one big take away from the book is
  • 6:14 - 6:16
    that, that is ind of summed up in one
  • 6:16 - 6:18
    quote there, that practice isn't the thing
    that you
  • 6:18 - 6:21
    do once you get good. It is the thing
  • 6:21 - 6:24
    that you do that makes you good. And, some
  • 6:24 - 6:26
    of you might be saying, well, I practice.
    Of
  • 6:26 - 6:29
    course I practice. I practice every day. I
    practice
  • 6:29 - 6:32
    every day for nine hours, sometimes ten hours,
    occasionally
  • 6:32 - 6:35
    twelve hours, sometimes twenty-four or seventy-two
    hours at a
  • 6:35 - 6:37
    stint. And then eventually take a shower or
    die
  • 6:37 - 6:40
    and fall into a coma.
  • 6:40 - 6:42
    But, the key thing to remember there is that
  • 6:42 - 6:46
    work does not equal practice. Like Carlos
    was saying,
  • 6:46 - 6:48
    when you look at a martial artist or you
  • 6:48 - 6:50
    look at a concert violinist, or you look at
  • 6:50 - 6:53
    someone who practices a craft or a art for
  • 6:53 - 6:57
    their profession, they don't perform nearly
    as much time
  • 6:57 - 7:00
    as they practice. There's a def- there's a
    definite
  • 7:00 - 7:03
    separation between the performance of their
    art and the
  • 7:03 - 7:05
    practice of their art.
  • 7:05 - 7:07
    So we can't really equate what we do on
  • 7:07 - 7:11
    a daily basis, nine to five, as practice.
    That's
  • 7:11 - 7:15
    work. We need, do ship software. We need to
  • 7:15 - 7:19
    perform. We need to hit our deadlines. We're
    concerned
  • 7:19 - 7:23
    with building stuff that works. Work time
    is not
  • 7:23 - 7:24
    practice time.
  • 7:24 - 7:27
    Well, then that brings up the inevitable question,
    how
  • 7:27 - 7:30
    then, do we practice what it is that we
  • 7:30 - 7:34
    do? And how should we practice what we do?
  • 7:34 - 7:37
    What does practicing code actually look like?
    How do
  • 7:37 - 7:39
    I practice, as a programmer?
  • 7:39 - 7:40
    Well, one way we could do that is to
  • 7:40 - 7:43
    emulate how other artists practice their art
    and their
  • 7:43 - 7:45
    craft.
  • 7:45 - 7:50
    C.S.: And we're talking about here, is, for
    example,
  • 7:50 - 7:54
    martial arts. So we have the, the term Dojo,
  • 7:54 - 7:57
    which in martial arts means, the place where
    people
  • 7:57 - 8:00
    practice those arts. And this is a term that
  • 8:00 - 8:05
    was coined by Dave Thomas of the Pragmatic
    Programmers.
  • 8:05 - 8:08
    And he brought that to the programming world,
    saying
  • 8:08 - 8:10
    we should set up a Dojo for programming, so
  • 8:10 - 8:14
    we can practice code.
  • 8:14 - 8:18
    D.R.: And the, the keys to a code Coding
  • 8:18 - 8:21
    Dojo is that we are providing, just like in
  • 8:21 - 8:26
    a martial arts setting, we're providing a
    safe, collaborative,
  • 8:26 - 8:30
    non-competitive location at a, at a space
    and a
  • 8:30 - 8:35
    time to practice together. We get together
    and we
  • 8:35 - 8:38
    code. WE learn something. We actually practice
    programming. WE
  • 8:38 - 8:40
    practice learning and teaching one another.
    And we also
  • 8:40 - 8:42
    have a lot of fun. Just like you would
  • 8:42 - 8:43
    if you, has anybody taken martial arts of
    any
  • 8:43 - 8:46
    sort? Yoga counts. Well, I'll give you yoga,
    right,
  • 8:46 - 8:48
    we'll give you yoga, right.
  • 8:48 - 8:53
    So, that's, that's really the goal of the,
    the
  • 8:53 - 8:57
    Dojo. But, how we actually live it out is,
  • 8:57 - 9:01
    just like in martial arts, we practice Katas.
    And
  • 9:01 - 9:04
    a Kata in martial arts is this kind of
  • 9:04 - 9:09
    detailed choreography of very ritualized movements
    that you practice,
  • 9:09 - 9:12
    either solo or in a pair or in a
  • 9:12 - 9:15
    group. And they don't really have a direct
    translation
  • 9:15 - 9:17
    to, if I was a martial artist, fighting another
  • 9:17 - 9:21
    person. Like, I would not use my Kata skills
  • 9:21 - 9:24
    to win a battle. But, they teach me how
  • 9:24 - 9:27
    to punch. They teach me how to block. They
  • 9:27 - 9:30
    teach me how to evade, through the choreography.
    So
  • 9:30 - 9:32
    that when the time comes to actually block
    a
  • 9:32 - 9:35
    punch or throw a punch, my body remembers
    even
  • 9:35 - 9:37
    though my brain is not thinking about throwing
    a
  • 9:37 - 9:38
    punch here.
  • 9:38 - 9:42
    In programmer, as Carlos was saying, Dave
    Thomas, Pragmatic
  • 9:42 - 9:46
    Programmer Dave, Prag Dave, coined this term
    to describe,
  • 9:46 - 9:47
    along with Kent Beck and some of the other
  • 9:47 - 9:51
    guys, Ward Cunningham, tried to describe a
    method of
  • 9:51 - 9:54
    practice inside of a Dojo. So inside of a
  • 9:54 - 9:57
    Coding Dojo, just like inside of a Karate
    Dojo,
  • 9:57 - 10:01
    we practice Katas, which are choreographed
    patterns of movements
  • 10:01 - 10:04
    that we practice either in solo or in pair,
  • 10:04 - 10:08
    to reinforce skills that we don't necess-
    we wouldn't
  • 10:08 - 10:12
    necessarily use in the choreographed pattern,
    but we would
  • 10:12 - 10:14
    use on a daily basis when we actually come
  • 10:14 - 10:16
    face-to-face with that variable that needs
    to be punched
  • 10:16 - 10:17
    in the head.
  • 10:17 - 10:20
    And we break that down, when we're talking
    about
  • 10:20 - 10:24
    choreographed patterns, inside of the Dojo
    inside of a
  • 10:24 - 10:29
    coding Kata, as Prag Dave coined it, we're
    talking
  • 10:29 - 10:31
    about test-driven development. And, regardless
    of what you may
  • 10:31 - 10:36
    have heard earlier today, tests are not the
    devil.
  • 10:36 - 10:39
    They will not, they are not a sin, and
  • 10:39 - 10:41
    a lot of the Pragmatic guys, a lot of
  • 10:41 - 10:43
    the guys that we're talking about, that coined
    the
  • 10:43 - 10:47
    terms the Dojo and Katas, were in that deck
  • 10:47 - 10:50
    referring to just enough testing.
  • 10:50 - 10:52
    What we're doing in the Dojo is not just
  • 10:52 - 10:56
    enough testing. It is way-too-much testing,
    so that we
  • 10:56 - 11:00
    can practice the art of testing. When we practice
  • 11:00 - 11:02
    martial arts, and we learn a Kata in martial
  • 11:02 - 11:05
    arts, we're not punching just enough. We're
    punching a
  • 11:05 - 11:08
    whole lot, so that when the time comes to
  • 11:08 - 11:11
    actually punch, we know how much to punch
    and
  • 11:11 - 11:13
    with how much force we're to punch.
  • 11:13 - 11:15
    C.S.: And it's, it's kind of, if you play
  • 11:15 - 11:19
    a musical instrument, you, and you practice
    that musical
  • 11:19 - 11:21
    instrument, chances are, you're practicing
    along with a metronome.
  • 11:21 - 11:23
    And I like to make that analogy between a
  • 11:23 - 11:28
    metronome and writing tests when you're practicing,
    right. So
  • 11:28 - 11:30
    you need to metronome when you're practicing
    music to
  • 11:30 - 11:33
    keep that pace, so you can focus on repeating
  • 11:33 - 11:37
    your movements very, very slowly, and with
    very close
  • 11:37 - 11:41
    attention, so you can gradually increase the
    speed to
  • 11:41 - 11:44
    which you play, to get to the point where
  • 11:44 - 11:46
    you're shredding that speed solo. And then
    when you
  • 11:46 - 11:49
    play that live it just feels natural.
  • 11:49 - 11:51
    But, for you to get to that point, you
  • 11:51 - 11:53
    needed to start very slowly, and you needed
    a
  • 11:53 - 11:56
    tool to assist you. In music, that's the metronome.
  • 11:56 - 12:01
    In coding, that's test-driven development.
    That's writing tests. And,
  • 12:01 - 12:03
    like Dave said, in the Coding Dojo, we're
    not
  • 12:03 - 12:07
    practicing just enough tests. We're practicing
    a whole lot
  • 12:07 - 12:09
    of tests. So when the time comes for you
  • 12:09 - 12:11
    to write production code, you'll naturally
    be able to
  • 12:11 - 12:16
    tell whether you need to test-drive that feature
    or
  • 12:16 - 12:20
    not.
  • 12:20 - 12:24
    And one other thing that we practice is pair
  • 12:24 - 12:27
    programming. And pair programming is not just
    sitting down
  • 12:27 - 12:30
    and coding next to someone. It requires a
    set
  • 12:30 - 12:33
    of social skills. It requires knowing how
    to suggest
  • 12:33 - 12:36
    a feature, knowing how to accept a suggestion,
    knowing
  • 12:36 - 12:38
    how to accept a criticism, and not take it
  • 12:38 - 12:41
    personally. So there's way more to pair programming
    than
  • 12:41 - 12:44
    simply sitting next to each other and either
    watching
  • 12:44 - 12:47
    them code or telling them what to code.
  • 12:47 - 12:50
    D.R.: And, and again, like, like Kaikay was
    saying,
  • 12:50 - 12:53
    these are, these are social skills. And while
    they
  • 12:53 - 12:58
    might be accentuated inside of the Dojo, they
    definitely
  • 12:58 - 13:00
    have a lasting impact as a programmer. I,
    I
  • 13:00 - 13:03
    personally, and Kaikay, we both pair program
    as a
  • 13:03 - 13:06
    part of our writing production code, as a
    part
  • 13:06 - 13:11
    of our performant art, and we've found a huge
  • 13:11 - 13:15
    increase in our productivity whenever we selectively
    and intentionally
  • 13:15 - 13:16
    pair with others.
  • 13:16 - 13:18
    Maybe we don't do it all the time. We
  • 13:18 - 13:19
    certainly don't do it all the time, because
    sometimes
  • 13:19 - 13:22
    you just gotta get stuff done, right. But
    when
  • 13:22 - 13:25
    we do pair, we know the etiquettes, we know
  • 13:25 - 13:28
    the social currency to be able to use one
  • 13:28 - 13:31
    of the styles of pair programming. Be it pilot,
  • 13:31 - 13:33
    co-pilot, where I sit back and Kaikay's on
    the
  • 13:33 - 13:38
    keyboard and he types into the, into the editor
  • 13:38 - 13:42
    and I make suggestions, or I notice syntax
    errors
  • 13:42 - 13:45
    or I ask him questions about what he's doing
  • 13:45 - 13:47
    and he tells me how he's going to do
  • 13:47 - 13:50
    something, and then we switch and I start
    typing
  • 13:50 - 13:52
    and he plays co-pilot and helps keep me, navigating.
  • 13:52 - 13:54
    Or you use a ping-pong type approach. There's
    lots
  • 13:54 - 13:56
    of different types that we can, that we can
  • 13:56 - 13:59
    use. For the Coding Dojo, especially when
    we're talking
  • 13:59 - 14:03
    about small pairs or to practice pair programming,
    in
  • 14:03 - 14:06
    this Coding Dojo we're gonna use a ping pong
  • 14:06 - 14:08
    approach. And in that, and that approach is
    a
  • 14:08 - 14:12
    lot like playing ping pong. One person serves
    the
  • 14:12 - 14:15
    ball by writing some tests, and the tests
    then
  • 14:15 - 14:19
    fail, right. Test-driven development. We do
    red-green-refactor. So the
  • 14:19 - 14:22
    tests fail. Then he passes the mic over to
  • 14:22 - 14:25
    the pair, his, his partner then writes some
    code
  • 14:25 - 14:28
    to pass the test. They might talk, the pair
  • 14:28 - 14:30
    will talk through it, but write some code
    to
  • 14:30 - 14:33
    pass the tests. And then, immediately writes
    another test
  • 14:33 - 14:35
    that will fail, to serve the ball back across
  • 14:35 - 14:37
    the net to his partner.
  • 14:37 - 14:39
    We'll see an example of that a little bit
  • 14:39 - 14:41
    later. We'll do a, a, what's called a practice
  • 14:41 - 14:44
    Kata. But, Kaikay, why don't you tell us a
  • 14:44 - 14:46
    little bit more about the different types
    of Katas
  • 14:46 - 14:46
    that we could do.
  • 14:46 - 14:49
    Anybody have any questions so far, before
    we, before
  • 14:49 - 14:51
    we go on? Is everybody tracking on that, you
  • 14:51 - 14:55
    know, for, four to five fingers? Perhaps just
    one.
  • 14:55 - 14:57
    One finger. No? OK.
  • 14:57 - 15:01
    C.S.: So there, there's different types of
    Katas. The
  • 15:01 - 15:04
    three most popular, I want to say, the Randori
  • 15:04 - 15:08
    Kata, the Prepared and the Code Retreat, which
    is
  • 15:08 - 15:10
    more like an event, but we're gonna treat
    it
  • 15:10 - 15:11
    as a Kata.
  • 15:11 - 15:14
    And the Randori Kata is the most popular for
  • 15:14 - 15:18
    meet ups and schools and university. David
    is a
  • 15:18 - 15:21
    teacher at a local university in Orlando,
    and he
  • 15:21 - 15:24
    uses Coding Dojo as part of the curriculum.
  • 15:24 - 15:26
    And the way that the Randori works, you have
  • 15:26 - 15:29
    one computer, and the code in that computer
    is
  • 15:29 - 15:33
    projected onto a screen, where an audience,
    between five
  • 15:33 - 15:35
    and fifteen people, a little bit more than
    that
  • 15:35 - 15:37
    gets a little bit confusing. So, the audience
    is
  • 15:37 - 15:42
    watching the code, is watching the evolution
    of the
  • 15:42 - 15:44
    code towards the solution all the time. So
    they're
  • 15:44 - 15:47
    constantly, you know, learning things and
    watching where the
  • 15:47 - 15:49
    pair is going with the code.
  • 15:49 - 15:52
    And, in the computer, there's always two people
    pair
  • 15:52 - 15:56
    programming. The pilot and the co-pilot. And
    every three
  • 15:56 - 16:00
    to seven minutes, they rotate. So, the driver
    goes
  • 16:00 - 16:03
    back to the audience. The co-pilot becomes
    the pilot.
  • 16:03 - 16:06
    And someone from the audience volunteers to
    be the
  • 16:06 - 16:08
    co-pilot. So that way we have everyone in
    the
  • 16:08 - 16:11
    room collaborating towards learning.
  • 16:11 - 16:14
    D.R.: And, and like Carlos was saying, I,
    I
  • 16:14 - 16:17
    used this in my, in my courses at Valencia.
  • 16:17 - 16:21
    We, we spend, it's an Introduction to Programming
    course
  • 16:21 - 16:23
    where we spend the first half of the course
  • 16:23 - 16:27
    learning the concepts of programming and practicing
    reading the
  • 16:27 - 16:30
    code, reading open source projects, identifying
    pieces of the
  • 16:30 - 16:32
    code that we've talked about, and the second
    half
  • 16:32 - 16:35
    of the class is all these Coding Dojos, these
  • 16:35 - 16:37
    Randori-style Coding Dojos.
  • 16:37 - 16:40
    Over the, the couple years that we ran the
  • 16:40 - 16:43
    Coding Dojo in Orlando, we got a mixed bag
  • 16:43 - 16:46
    of folks from all over the spectrum. People
    that
  • 16:46 - 16:48
    had no coding experience all the way up to
  • 16:48 - 16:50
    people that had been coding for years and
    years
  • 16:50 - 16:53
    and years and years. And strangely enough,
    the super
  • 16:53 - 16:56
    experts were the ones that were least interested
    in
  • 16:56 - 16:57
    the format.
  • 16:57 - 17:00
    But we used it as a method of teaching
  • 17:00 - 17:05
    ourselves new tools, new techniques, completely
    different languages. Our
  • 17:05 - 17:08
    first attempt at a Python Coding Dojo was
    a
  • 17:08 - 17:11
    complete dog's breakfast. But we came back,
    we learned,
  • 17:11 - 17:13
    we learned enough Python that now I actually
    run
  • 17:13 - 17:16
    the Python user group in Orlando, and teach
    other
  • 17:16 - 17:19
    people how to use Python and when to use
  • 17:19 - 17:21
    Python and that sort of thing.
  • 17:21 - 17:22
    We, we taught a bunch of people Ruby. We've
  • 17:22 - 17:24
    taught a bunch of people JavaScript, learned
    that there
  • 17:24 - 17:27
    are like seventeen different JavaScript frameworks,
    and a new
  • 17:27 - 17:32
    one every week, to run tests or implement
    assertions.
  • 17:32 - 17:33
    That's always fun.
  • 17:33 - 17:35
    But the, the key is, we give them, we
  • 17:35 - 17:37
    give everybody a time box and we wait for,
  • 17:37 - 17:40
    either everyone gets a chance to code, we
    solve
  • 17:40 - 17:42
    the problem - which very rarely happens - or
  • 17:42 - 17:45
    we have it, the entire thing time-boxed to
    maybe
  • 17:45 - 17:46
    a two hour time frame.
  • 17:46 - 17:47
    So that really works well for a lot of
  • 17:47 - 17:49
    people, like a classroom setting where you
    know you
  • 17:49 - 17:52
    have x number of hours to participate, and
    you
  • 17:52 - 17:54
    have, you know, somewhere between that magic
    number of
  • 17:54 - 17:56
    five to fifteen people so that everyone can
    get
  • 17:56 - 17:59
    a chance to code inside of that two hours.
  • 17:59 - 18:02
    C.S.: And one thing worth mentioning, too,
    is that
  • 18:02 - 18:04
    the Randori-style Kata is also a great way
    to
  • 18:04 - 18:07
    interview potential developer candidates.
    If you want to move
  • 18:07 - 18:09
    away from the typical, where do you see yourself
  • 18:09 - 18:11
    in five years? And cut that, cut out all
  • 18:11 - 18:13
    that bull shit, and get to what matters, which
  • 18:13 - 18:16
    is coding and seeing, you know, how efficient
    your
  • 18:16 - 18:20
    developer is, and how willing to pair program,
    how
  • 18:20 - 18:22
    willing to collaborate he is. The Coding Dojo,
    I
  • 18:22 - 18:24
    want to say, is the best way to do
  • 18:24 - 18:26
    that, right. Because you're hiring someone
    to be a
  • 18:26 - 18:27
    developer.
  • 18:27 - 18:29
    So, sit with them, code with them. Seeing
    how
  • 18:29 - 18:33
    well the fit with the culture, with the pair
  • 18:33 - 18:36
    programming culture in your company, or with
    the development
  • 18:36 - 18:38
    style that your company adopts. And we use
    it
  • 18:38 - 18:40
    a lot at Code School and Envy Labs, and
  • 18:40 - 18:44
    it's worked out great, I'd say.
  • 18:44 - 18:47
    The second type of Kata is the Prepared Kata,
  • 18:47 - 18:51
    and that is when you watch perform a, a
  • 18:51 - 18:55
    Kata that has been previously worked on. So,
    David
  • 18:55 - 18:56
    and I are gonna show that to you in
  • 18:56 - 18:59
    a little bit. We're going to start coding
    a
  • 18:59 - 19:02
    problem from scratch, and we're going to be
    pair
  • 19:02 - 19:05
    programming on that problem. You can either
    pair program
  • 19:05 - 19:07
    or do it solo, but the thing is, you're
  • 19:07 - 19:11
    showing people one way to solve the problem,
    and
  • 19:11 - 19:15
    you're showing them, also, a bunch of, of
    tricks
  • 19:15 - 19:17
    that you may use. Perhaps you're showing them
    how
  • 19:17 - 19:20
    to use a different editor that just came out,
  • 19:20 - 19:22
    or perhaps you're showing them one feature
    of an
  • 19:22 - 19:25
    existing editor that you might already use.
    You're showing
  • 19:25 - 19:29
    them different API for the language. So there's
    different,
  • 19:29 - 19:31
    there's a multitude of things that you can
    learn
  • 19:31 - 19:34
    by watching someone perform a prepared Kata.
  • 19:34 - 19:37
    And lastly.
  • 19:37 - 19:41
    D.R.: We, we actually had the, the opportunity
    to
  • 19:41 - 19:43
    have Corey Haines - has anybody heard of Corey
  • 19:43 - 19:45
    Haines? If you guys know anything about the
    Dojo,
  • 19:45 - 19:49
    you've probably heard about Corey Haines.
    Corey Haines, yeah,
  • 19:49 - 19:53
    he's local up here. He came down to Orlando
  • 19:53 - 19:56
    and gave what he calls a Code Retreat, and
  • 19:56 - 20:00
    those are fantastic, all-day events where
    you get the
  • 20:00 - 20:02
    opportunity to pair up with people that you've
    never
  • 20:02 - 20:06
    programmed with before, maybe never seen before.
    You, everyone
  • 20:06 - 20:08
    agrees to solve the same problem. He usually
    uses
  • 20:08 - 20:12
    Conway's Game of Life, which is a wonderfully
    brain-bending
  • 20:12 - 20:14
    program in whatever language you're trying
    to learn.
  • 20:14 - 20:17
    You all pair for thirty minutes or an hour
  • 20:17 - 20:20
    or, or whatever the time box is for that
  • 20:20 - 20:23
    event. You pair with different people at the
    end
  • 20:23 - 20:24
    of the time box. You're free to switch pairs.
  • 20:24 - 20:27
    You're free to switch languages. You're free
    to try
  • 20:27 - 20:29
    a different approach. Add some constraints.
    Whatever. But you
  • 20:29 - 20:31
    agree to do it all day. You have a
  • 20:31 - 20:33
    lot of practice and a lot of time.
  • 20:33 - 20:35
    That's similar to the format that we're gonna
    use
  • 20:35 - 20:38
    today for the second half, or second two-thirds
    of
  • 20:38 - 20:41
    the seminar. And if you want to know more
  • 20:41 - 20:44
    about Corey Haines Code Retreat, or perhaps
    bug him
  • 20:44 - 20:46
    incessantly on Twitter for him to bring a
    Code
  • 20:46 - 20:49
    Retreat to your city, you can find him at
  • 20:49 - 20:52
    his horribly ugly website, coderetreat dot
    org. And on
  • 20:52 - 20:54
    the internets as @CoreyHaines.
  • 20:54 - 20:59
    C.S.: Cool. So. I think we're good to move
  • 20:59 - 21:02
    on to show you guys a Prepared Kata that
  • 21:02 - 21:09
    David and I practiced and. Cool. Let's do
    it.
  • 21:09 - 21:12
    Like I said, we're gonna do something that
    we're
  • 21:12 - 21:15
    already worked on. We've previously worked
    on. And we're
  • 21:15 - 21:18
    gonna show you how to implement a very, very,
  • 21:18 - 21:22
    very simple calculator. And, and this calculator
    is going
  • 21:22 - 21:27
    to have one operation, which is gonna be addition.
  • 21:27 - 21:30
    This operation should be able to accept two
    numbers
  • 21:30 - 21:32
    and return the result.
  • 21:32 - 21:35
    Should be simple enough, right? Cool. We're
    gonna use
  • 21:35 - 21:38
    Ruby, Ruby 2 point 0, but if you have
  • 21:38 - 21:42
    Ruby 1.9 in your computer, it's fine. And
    we're
  • 21:42 - 21:47
    gonna use miniTest, also known as Test Unit,
    for
  • 21:47 - 21:49
    this, and that's it. We're not gonna use any
  • 21:49 - 21:52
    framework. Everything is built into the standard
    library.
  • 21:52 - 21:55
    If you can, you can follow along. Or if
  • 21:55 - 21:57
    you just want to watch it, and then try
  • 21:57 - 21:59
    to do it on your own after we're done,
  • 21:59 - 22:01
    that's fine too. Right. So this is like the
  • 22:01 - 22:04
    first Kata that we're gonna run.
  • 22:04 - 22:07
    D.R.: And because pairing, because the ping
    pong style
  • 22:07 - 22:09
    pairing is a lot of vocal back and forth,
  • 22:09 - 22:11
    we're gonna shove the mic right up here in
  • 22:11 - 22:13
    the front, and we'll attempt to talk into
    it
  • 22:13 - 22:16
    as much as possible. So bear with us. If
  • 22:16 - 22:18
    you can't hear us, just holler or throw paper
  • 22:18 - 22:19
    or something.
  • 22:19 - 22:22
    C.S.: And also, if you have any questions,
    if
  • 22:22 - 22:24
    you don't understand anything that we do - we're
  • 22:24 - 22:26
    gonna try to explain everything and describe
    as we
  • 22:26 - 22:29
    go, but if you have any questions, please,
    please,
  • 22:29 - 22:36
    please raise your hand and ask us. Don't hesitate.
  • 22:38 - 22:45
    So, so far we have an empty file. There's
  • 22:46 - 22:50
    nothing on this file. Kata dot rb. And we're
  • 22:50 - 22:53
    going to develop a very simple calculator.
    So I'm
  • 22:53 - 22:58
    gonna fire up Vim, open the file. Can everyone
  • 22:58 - 23:02
    see? Good? Decent? Cool? All right. So we're
    going
  • 23:02 - 23:09
    to use miniTest, the unit. Because you have
    miniTest
  • 23:09 - 23:10
    unit and you also have miniTest specs. So
    we're
  • 23:10 - 23:13
    gonna do the unit type.
  • 23:13 - 23:15
    And, to run our tests, we also have to
  • 23:15 - 23:22
    require 'minitest/auto' to automatically run
    this file. We're gonna
  • 23:22 - 23:24
    start with our test case, which is going to
  • 23:24 - 23:31
    be CalculatorTest < Minitest::Unit::TestCase.
    We got our test suite
  • 23:36 - 23:39
    class, and we're going to write our first
    test.
  • 23:39 - 23:44
    So test_adds_two_numbers.
  • 23:44 - 23:46
    So if we change it and you go to
  • 23:46 - 23:53
    that same folder, if we're in Ruby, Kata cannot
  • 23:55 - 23:56
    load minitest/auto.
  • 23:56 - 23:57
    AUDIENCE: Autorun.
  • 23:57 - 24:03
    C.S.: Autorun. Thank you. There you go. Collaborative.
  • 24:03 - 24:06
    D.R.: Thank you audience.
  • 24:06 - 24:09
    C.S.: Right. So now we got something here.
    Let
  • 24:09 - 24:12
    me add clear. And Ruby Kata.
  • 24:12 - 24:14
    D.R.: Tada!
  • 24:14 - 24:19
    C.S.: Cool. So that gives us proof that we
  • 24:19 - 24:21
    were able to import the correct libraries,
    we were
  • 24:21 - 24:24
    able to create the correct test suite, and
    that
  • 24:24 - 24:26
    Ruby picked it up and it gives us a
  • 24:26 - 24:29
    proper error message, or at least a proper
    message.
  • 24:29 - 24:31
    Cause we don't have any assertions yet. So
    it's
  • 24:31 - 24:34
    just saying, hey, we found one test. There's
    zero
  • 24:34 - 24:38
    assertions, zero failures, no errors, and
    no skips. Right.
  • 24:38 - 24:41
    So moving on to the first failing test, I'm
  • 24:41 - 24:48
    going to create a local variable, and instantiate
    an
  • 24:48 - 24:51
    object from a class that I want to have,
  • 24:51 - 24:52
    but I don't have yet. So I'm gonna let
  • 24:52 - 24:55
    my tests tell me what I should do next.
  • 24:55 - 24:57
    If I run this again, it's gonna blow up,
  • 24:57 - 24:57
    right.
  • 24:57 - 24:59
    So I got a failing test. So now I'm
  • 24:59 - 25:01
    gonna pass it along to David to solve that
  • 25:01 - 25:01
    test.
  • 25:01 - 25:04
    D.R.: Yeah. Thanks for leaving me a lovely
    mess
  • 25:04 - 25:05
    there.
  • 25:05 - 25:06
    C.S.: That's real life, man.
  • 25:06 - 25:08
    D.R.: Yeah. This is a. At least you didn't
  • 25:08 - 25:13
    commit it, right? So I'm gonna actually, gonna
    type
  • 25:13 - 25:15
    only the code that I need to fulfill this
  • 25:15 - 25:16
    task. And I'm gonna do it right in the
  • 25:16 - 25:19
    same file. Some people would split it out,
    but
  • 25:19 - 25:22
    for, for this simple example, we're gonna
    just do
  • 25:22 - 25:25
    exactly what we need.
  • 25:25 - 25:32
    And so, if I just define a Calculator, then
  • 25:33 - 25:38
    that should, at least, change the error message.
    And
  • 25:38 - 25:41
    it does. Now I have one test. No assertions.
  • 25:41 - 25:43
    But I don't have a big giant barf.
  • 25:43 - 25:45
    So I'm gonna write a test. This is using
  • 25:45 - 25:51
    the ping pong method. Equals or equal?
  • 25:51 - 25:54
    C.S.: Equal.
  • 25:54 - 25:59
    D.R.: Equal. Of course. I'm gonna add two
    numbers
  • 25:59 - 26:06
    together, say, one and one. All right? Rerun
    the
  • 26:09 - 26:11
    tests. And now I get barf. And so I
  • 26:11 - 26:15
    hand it back off to my pair. Ping.
  • 26:15 - 26:18
    C.S.: So the error is saying there's an undefined
  • 26:18 - 26:22
    method add. So that's simple enough. I'm going
    to
  • 26:22 - 26:25
    come here and define a method add. If I
  • 26:25 - 26:28
    run it again, now it's complaining about another
    thing,
  • 26:28 - 26:30
    which is sort of good. If you're doing TDD,
  • 26:30 - 26:33
    you want either to make the test pass or
  • 26:33 - 26:35
    to make the message change.
  • 26:35 - 26:37
    So, this is to ensure that whatever code you're
  • 26:37 - 26:42
    writing in your production part is effecting
    your tests,
  • 26:42 - 26:45
    right. Because, I cannot count how many times
    it
  • 26:45 - 26:48
    happened to me in real life, I'm editing a
  • 26:48 - 26:50
    file, but it just happens to be a file
  • 26:50 - 26:52
    with the same name on a completely different
    project.
  • 26:52 - 26:53
    D.R.: Right.
  • 26:53 - 26:56
    C.S.: So I'm editing like a calculated dot
    rb
  • 26:56 - 26:58
    on a different project, and I'm refreshing
    the browser,
  • 26:58 - 27:00
    wondering, what the hell is this not taking
    effect?
  • 27:00 - 27:02
    Right. So when you're doing test-driven development,
    you want
  • 27:02 - 27:04
    to make sure that whatever code you write
    in
  • 27:04 - 27:06
    production, you run the test, so, to make
    sure
  • 27:06 - 27:08
    that your code is taking effect. Right.
  • 27:08 - 27:10
    D.R.: Right. And the, the key there is, run
  • 27:10 - 27:13
    your tests and observe the expected failure,
    or at
  • 27:13 - 27:16
    least observe that something, the failure
    has changed.
  • 27:16 - 27:16
    C.S.: Right.
  • 27:16 - 27:17
    D.R.: That you're, you're having an effect.
  • 27:17 - 27:20
    C.S.: So I'm going to save this. Add in
  • 27:20 - 27:23
    two arguments. Run the test again. Now it's
    saying,
  • 27:23 - 27:25
    now it's giving us a different message. It's
    saying
  • 27:25 - 27:29
    it expected Nil, but, but it got two. So,
  • 27:29 - 27:31
    I'm reading this, and I'm thinking. Well that's,
    that's,
  • 27:31 - 27:33
    that's kind of weird. I'm not expecting Nil.
    I
  • 27:33 - 27:35
    should be expecting two.
  • 27:35 - 27:38
    So that leads me to the conclusion that maybe
  • 27:38 - 27:43
    we passed the wrong order to our assert method.
  • 27:43 - 27:47
    So to go back, here, assert_equal is very
    strict
  • 27:47 - 27:50
    about the order of arguments. So we can produce
  • 27:50 - 27:53
    the best error message for you. So what we
  • 27:53 - 27:58
    should do here, instead, is put two calculator.add
    one
  • 27:58 - 28:00
    and one. And when we do that and then
  • 28:00 - 28:02
    we run our tests again, we can see that
  • 28:02 - 28:05
    now the error message is, it makes more sense,
  • 28:05 - 28:08
    right. It expected two but it actually got
    Nil.
  • 28:08 - 28:11
    Now, it's time to write the simplest thing
    that
  • 28:11 - 28:14
    could possibly make this work. And will probably
    make
  • 28:14 - 28:21
    your skin crawl. Is to return two. Cool. So
  • 28:21 - 28:23
    now we have one test and one assertion. Now
  • 28:23 - 28:26
    it's time for me to write a test, a
  • 28:26 - 28:29
    failing test, or David to fulfill.
  • 28:29 - 28:36
    Equal. Seven. Five and two. So I'm gonna do
  • 28:38 - 28:39
    AUDIENCE: Could that also lead you to splitting
    the
  • 28:39 - 28:46
    two tests out of this matter?
  • 28:46 - 28:52
    C.S.: Say that again.
  • 28:52 - 28:53
    AUDIENCE: Will you, should you be splitting
    the two
  • 28:53 - 28:54
    tests into two assertions. Two assertions,
    two tests.
  • 28:54 - 28:55
    C.S.: That is a good point. I do that
  • 28:55 - 28:58
    when I'm talking about different features,
    right. So there's,
  • 28:58 - 29:00
    it's really up to you how fine-grained you
    want
  • 29:00 - 29:00
    to get. Because we're testing, if you look
    at
  • 29:00 - 29:01
    the name of the test method, the test_that_adds_two_numbers.
    So
  • 29:01 - 29:08
    those two assertions, they still belong to
    that idea,
  • 29:09 - 29:12
    to that context of adding two numbers.
  • 29:12 - 29:15
    D.R.: Right. And we, we talk about the granularity
  • 29:15 - 29:18
    of testing, just simple assertion testing
    which is what
  • 29:18 - 29:20
    we're doing with assert_equal or any of the
    assert
  • 29:20 - 29:23
    methods. That's like the smallest little piece
    of a
  • 29:23 - 29:25
    test. That's the tiniest little piece of a
    test.
  • 29:25 - 29:29
    We then compose those assertions together
    into the unit,
  • 29:29 - 29:30
    and the unit, in this case, like Kaikay had
  • 29:30 - 29:33
    described, is just that we can add two numbers.
  • 29:33 - 29:35
    There might be multiple assertions that describe
    how we
  • 29:35 - 29:37
    can add two numbers, and as we go through
  • 29:37 - 29:39
    the example we'll see that, and we'll start
    to
  • 29:39 - 29:42
    break out, what happens if we give it three
  • 29:42 - 29:43
    numbers?
  • 29:43 - 29:46
    C.S.: And that's when we break into another
    test.
  • 29:46 - 29:50
    D.R.: Right. Does that answer your question?
    More or
  • 29:50 - 29:51
    less? All right. Great.
  • 29:51 - 29:54
    So, I've got this busted up test sitting in
  • 29:54 - 29:58
    front of me. So the simplest thing that I
  • 29:58 - 30:01
    could possibly do is, I'm gonna go ahead and
  • 30:01 - 30:07
    do some math. Actually do some work here.
    Buddy.
  • 30:07 - 30:10
    And now I've got passing tests. But I sort
  • 30:10 - 30:13
    of see, already, that Calculator is gonna
    be a
  • 30:13 - 30:16
    whole lot to type. So I'm gonna take a
  • 30:16 - 30:20
    minute and just refactor. Rather than typing
    calculator all
  • 30:20 - 30:23
    the dang time, why don't we change this to
  • 30:23 - 30:26
    just, like, calc? That's still descriptive
    of what the
  • 30:26 - 30:33
    object is, but it's a lot less repetitive.
  • 30:34 - 30:37
    So I make my couple of changes to refactor,
  • 30:37 - 30:42
    and then I rerun the tests. And boy, it'd
  • 30:42 - 30:44
    be nice if these, if these tests were a
  • 30:44 - 30:45
    little prettier. But I'll leave that to another,
    to
  • 30:45 - 30:46
    another person.
  • 30:46 - 30:51
    Now, what do you think? We've got, we've got
  • 30:51 - 30:52
    the ability to add two numbers. Should we
    add
  • 30:52 - 30:55
    some more two numbers? Or do you, maybe we
  • 30:55 - 30:58
    can move on? Maybe we'll move on and get
  • 30:58 - 30:58
    a little more complicated.
  • 30:58 - 30:59
    C.S.: Yeah. Let's do that.
  • 30:59 - 31:05
    D.R.: So yeah. Why don't we write another
    test?
  • 31:05 - 31:07
    And this time, I'll, I'll throw you a curve
  • 31:07 - 31:14
    ball. You can add three numbers. Now we're
    getting
  • 31:14 - 31:21
    fancy. So, if I, if I expect nine, three
  • 31:21 - 31:27
    and three and three, should add up to nine.
  • 31:27 - 31:29
    But should be clearly, clear, that I'm gonna
    need
  • 31:29 - 31:32
    to do some copy pasta here. Which is a
  • 31:32 - 31:34
    great opportunity to refactor, of course.
  • 31:34 - 31:40
    But I feel like making Kaikay work. Look at
  • 31:40 - 31:45
    that. Ping pong, sir.
  • 31:45 - 31:51
    C.S.: Cool. So. Says the number, wrong number
    of
  • 31:51 - 31:53
    arguments. It took three but it was only expecting
  • 31:53 - 31:55
    two. So, I'm gonna write the simplest thing
    that
  • 31:55 - 32:00
    could possibly work, or change this message,
    right. So
  • 32:00 - 32:03
    what I'm gonna do is add another argument.
    But
  • 32:03 - 32:06
    if I simply add another argument, then I made
  • 32:06 - 32:08
    that test pass but I make the other ones
  • 32:08 - 32:08
    fail.
  • 32:08 - 32:10
    Cause, if I look at the error message.
  • 32:10 - 32:12
    D.R.: If you could look at the error message.
  • 32:12 - 32:15
    C.S.: If I could look at the error message.
  • 32:15 - 32:16
    D.R.: The little green.
  • 32:16 - 32:18
    C.S.: What's that?
  • 32:18 - 32:20
    D.R.: It's too tall. The window's too tall.
  • 32:20 - 32:23
    C.S.: Is it? Right. All right. So, if you
  • 32:23 - 32:25
    can see here, now I broke the other ones.
  • 32:25 - 32:28
    So what I'm going to do is actually make.
  • 32:28 - 32:31
    Let me fix my window. Is actually make this
  • 32:31 - 32:35
    third one optional. If I run it again, now
  • 32:35 - 32:37
    I don't have a syntax error anymore. Now I
  • 32:37 - 32:40
    have an assertion error. Which, again, is
    good, right.
  • 32:40 - 32:41
    D.R.: Man it would be nice if we could
  • 32:41 - 32:46
    see the differences there. That, that white
    text on
  • 32:46 - 32:48
    a white back- on a, on a black background
  • 32:48 - 32:48
    is particularly-
  • 32:48 - 32:49
    C.S.: You're right. I wonder if we can make
  • 32:49 - 32:50
    this colored, right.
  • 32:50 - 32:52
    D.R.: I wondered. If we could make this prettier.
  • 32:52 - 32:57
    C.S.: So let's go ahead and add require 'minitest/bright'
  • 32:57 - 33:00
    and make our tests fabulous. So now you can
  • 33:00 - 33:02
    see, down at the bottom here, that we have
  • 33:02 - 33:04
    a little column. Might not be able to see
  • 33:04 - 33:06
    it clearly on the projector, but it does make
  • 33:06 - 33:07
    a lot of difference when you're look at your
  • 33:07 - 33:08
    terminal, right.
  • 33:08 - 33:10
    D.R.: You get a nice big red F.
  • 33:10 - 33:13
    C.S.: So, the big F is saying that expected
  • 33:13 - 33:15
    nine, but it got six. So I'm gonna go
  • 33:15 - 33:22
    ahead and add C to make it pass. Cool.
  • 33:22 - 33:24
    And because I don't like reading a lot, I'm
  • 33:24 - 33:28
    just gonna remove return, because Ruby automatically
    returns the
  • 33:28 - 33:31
    last expression of the method. So I'm gonna
    run
  • 33:31 - 33:36
    this again, and now all my tests pass, right.
  • 33:36 - 33:37
    Cool.
  • 33:37 - 33:40
    Let's see what we can do now. Should we
  • 33:40 - 33:43
    add more numbers? So we can refactor this
    whole
  • 33:43 - 33:43
    thing?
  • 33:43 - 33:43
    D.R.: Yeah.
  • 33:43 - 33:43
    C.S.: What do you think?
  • 33:43 - 33:44
    D.R.: Let's do, let's do one more, one more
  • 33:44 - 33:45
    test.
  • 33:45 - 33:48
    C.S.: So, I don't want you to cheat, cause
  • 33:48 - 33:51
    I don't want you to keep adding single arguments.
  • 33:51 - 33:57
    I'm just gonna add five numbers, right. So
    I'm
  • 33:57 - 34:00
    gonna copy and paste this, and copying and
    pasting
  • 34:00 - 34:04
    never resulted in any error, ever. And, it's
    gonna-
  • 34:04 - 34:08
    D.R.: It certainly results in highly maintainable
    code.
  • 34:08 - 34:13
    C.S.: Twenty-five. Five, five, five, five,
    five.
  • 34:13 - 34:16
    D.R.: You can tell we're mathematicians as
    well, right.
  • 34:16 - 34:19
    Neither one of us aspire to computer science.
  • 34:19 - 34:22
    C.S.: Cool. So now you got one more.
  • 34:22 - 34:27
    D.R.: Dun, dun, duh! So. Back again we go.
  • 34:27 - 34:29
    The simplest thing that I could possibly do
    is
  • 34:29 - 34:32
    add five, and a bunch of, and a bunch
  • 34:32 - 34:35
    of junk inside my add method. But that seems,
  • 34:35 - 34:42
    well, stupid. So, let's, instead, just replace.
  • 34:43 - 34:48
    C.S.: Hello? Is that a duck? Duck face?
  • 34:48 - 34:51
    D.R.: There we go.
  • 34:51 - 34:53
    C.S.: nice.
  • 34:53 - 34:59
    D.R.: Let's instead replace this with a splat.
    That's
  • 34:59 - 35:03
    my favorite. And that should get rid of my
  • 35:03 - 35:07
    wrong arguments error. Oh god. But I got a
  • 35:07 - 35:11
    whole bunch. And you know what, this, this
    running
  • 35:11 - 35:12
    this test thing's getting kind of tedious.
    I don't
  • 35:12 - 35:15
    like flipping back and forth between the windows.
    Is
  • 35:15 - 35:16
    there a way we could automate that?
  • 35:16 - 35:17
    C.S.: I wonder.
  • 35:17 - 35:19
    D.R.: I wonder. Well, I'm more of a, a
  • 35:19 - 35:22
    bash-y person than most, so, in.
  • 35:22 - 35:26
    C.S.: So we could add auto-watch if we really
  • 35:26 - 35:28
    wanted to add a dependency and all that stuff,
  • 35:28 - 35:28
    right.
  • 35:28 - 35:29
    D.R.: Oh, right. And download a gem or, you
  • 35:29 - 35:32
    know, we know our way around Grunt. I'm more
  • 35:32 - 35:34
    of a JavaScript guy than a Ruby guy, so
  • 35:34 - 35:35
    I know way more-
  • 35:35 - 35:36
    D.C.: Dude, haven't you heard? Gulp is the
    new
  • 35:36 - 35:36
    Grunt.
  • 35:36 - 35:37
    D.R.: Oh, right. And so, and then followed
    by
  • 35:37 - 35:42
    Guzzle and, and Yak, I think is coming eventually,
  • 35:42 - 35:45
    right. We could do all that and wait through
  • 35:45 - 35:47
    like fifteen minutes of downloading stuff.
    But I, I
  • 35:47 - 35:49
    know bash really well, so I'm just gonna write
  • 35:49 - 35:56
    myself a wonderful infinite loop. But I'll
    add a
  • 35:58 - 36:02
    sleep. So that I don't blow my stack out.
  • 36:02 - 36:03
    And now every two seconds or so, it's going
  • 36:03 - 36:06
    to run, rerun the tests, rerun the tests,
    rerun
  • 36:06 - 36:07
    the tests. And I never have to touch that
  • 36:07 - 36:08
    window again. Thank you very much.
  • 36:08 - 36:09
    AUDIENCE: [indecipherable]
  • 36:09 - 36:10
    C.S.: What's that?
  • 36:10 - 36:11
    AUDIENCE: [indecipherable]
  • 36:11 - 36:12
    D.R.: Oh, sure.
  • 36:12 - 36:15
    C.S.: Oh, the code for the, yeah. The bash.
  • 36:15 - 36:17
    D.R.: So it's just a simple-
  • 36:17 - 36:19
    AUDIENCE: [chatter]
  • 36:19 - 36:26
    D.R.: Oh, lame. Lame. Pretty simple. Here,
    let's. Let's
  • 36:29 - 36:35
    do this. So, pretty simple bash infinite loop.
    While
  • 36:35 - 36:39
    true, run the tests. Sleep for two. If we
  • 36:39 - 36:42
    really wanted to make it even, even closer
    to
  • 36:42 - 36:46
    what Kaikay typed last, we'll do a clear.
    And
  • 36:46 - 36:49
    while I run that, every two seconds it's going
  • 36:49 - 36:52
    to refresh the screen and rerun the tests
    for
  • 36:52 - 36:56
    me. That is the poor-man's file-watcher. That's
    just in
  • 36:56 - 36:59
    case you're running free BSD or a clone thereof
  • 36:59 - 37:03
    and do not have watch installed by default.
  • 37:03 - 37:05
    So now the simplest thing that I could possibly
  • 37:05 - 37:08
    do here is numbers. Now, if this was JavaScript
  • 37:08 - 37:11
    I would probably use reduce on this array,
    but
  • 37:11 - 37:13
    this isn't JavaScript. So what is it in, in
  • 37:13 - 37:14
    Ruby?
  • 37:14 - 37:15
    AUDIENCE: Inject.
  • 37:15 - 37:22
    D.R.: Inject? Reduce? Oh, look. You steered
    me wrong.
  • 37:22 - 37:24
    And so, reduce is gonna take, does it take
  • 37:24 - 37:26
    the same arguments?
  • 37:26 - 37:29
    AUDIENCE: The first argument's the seed.
  • 37:29 - 37:32
    D.R.: Right. So I take the seed. And then
  • 37:32 - 37:35
    I give it a block. And so then I
  • 37:35 - 37:40
    have my, my value and my number.
  • 37:40 - 37:47
    C.S.: You might have to use params. I don't
  • 37:47 - 37:47
    know.
  • 37:47 - 37:48
    D.R.: I don't know. Let's, let's find out.
  • 37:48 - 37:49
    C.S.: Yeah. Let's find out.
  • 37:49 - 37:50
    D.R.: Find out what happens, right. So we
    give
  • 37:50 - 37:53
    it a block, and then we'll just return v
  • 37:53 - 37:57
    plus n, from the block. Write the file and
  • 37:57 - 37:57
    D.R.: Yeah.
  • 38:06 - 38:12
    passing a block.
  • 38:12 - 38:17
    D.R.: Oops.
  • 38:17 - 38:20
    And the best part is, I never have to
  • 38:20 - 38:22
    touch this dang test file again. He just keeps
  • 38:22 - 38:25
    running my tests. So now I've got a, I've
  • 38:25 - 38:28
    got a reduce function that works for an infinite
  • 38:28 - 38:30
    number of numbers. And I'm back to green tests.
  • 38:30 - 38:32
    And I, I've already noticed, you know, let's
    just,
  • 38:32 - 38:34
    let's go ahead and make this guy a little
  • 38:34 - 38:35
    bigger.
  • 38:35 - 38:38
    I've already noticed that, I've got all this
    repetition
  • 38:38 - 38:40
    in here, right. I've got calc equals, calc
    equals,
  • 38:40 - 38:43
    calc equals. Oh god. So, let's reduce some
    of
  • 38:43 - 38:44
    that repetition.
  • 38:44 - 38:48
    C.S.: Reduce? That.
  • 38:48 - 38:50
    D.R.: He's a funny guy.
  • 38:50 - 38:54
    AUDIENCE: Trying to inject a little humor.
  • 38:54 - 38:57
    D.R.: Ha. Ha. Ha. Ha.
  • 38:57 - 38:59
    C.S.: Nice. I liked that.
  • 38:59 - 39:03
    D.R.: So I'll, I'll add a little set up
  • 39:03 - 39:10
    method. Get rid of all those. Oops. Do a
  • 39:13 - 39:20
    little find and replace. Rerun. Hey, everything's
    still passing.
  • 39:22 - 39:25
    C.S.: Cool.
  • 39:25 - 39:30
    D.R.: Groovy, groovy. Should we go further?
    Or, I
  • 39:30 - 39:32
    mean, I think we've, we've pretty much added
    as
  • 39:32 - 39:33
    many numbers as we can possibly add. We could
  • 39:33 - 39:37
    add additional tests, or refactor this test
    to say,
  • 39:37 - 39:38
    adds an infinite number of tes- or, numbers.
  • 39:38 - 39:39
    C.S.: Mhmm.
  • 39:39 - 39:41
    D.R.: And throw it all kinds of different
    numbers
  • 39:41 - 39:44
    inside of there. Or we could go do something,
  • 39:44 - 39:46
    something completely crazy and totally off
    the spec.
  • 39:46 - 39:46
    C.S.: We could.
  • 39:46 - 39:47
    D.R.: What else?
  • 39:47 - 39:49
    C.S.: What if we added arguments, instead
    of numbers,
  • 39:49 - 39:51
    as strings? Would that work?
  • 39:51 - 39:52
    D.R.: Ah, I see.
  • 39:52 - 39:54
    C.S.: Does Ruby automatically convert, like,
    each b would
  • 39:54 - 39:56
    do?
  • 39:56 - 40:00
    AUDIENCE: Is Ruby as good as PHP?
  • 40:00 - 40:03
    D.R.: Is Ruby as good as PHP?
  • 40:03 - 40:04
    AUDIENCE: I'll write that down.
  • 40:04 - 40:08
    D.R.: Test. Ruby as good as PHP.
  • 40:08 - 40:10
    So what should, what, what would we expect
    it
  • 40:10 - 40:13
    to equal? If we do a calc dot add,
  • 40:13 - 40:18
    say, one and banana. What should we reason
    we
  • 40:18 - 40:19
    expect this to, to return to us?
  • 40:19 - 40:22
    C.S.: So that would probably generate an error,
    right.
  • 40:22 - 40:23
    D.R.: I would expect so.
  • 40:23 - 40:25
    C.S.: So what if, instead of banana, we pass
  • 40:25 - 40:28
    number two as a string.
  • 40:28 - 40:31
    D.R.: Sure. That seems reasonably. I mean,
    Ruby should
  • 40:31 - 40:34
    be able to convert a string with a numeric
  • 40:34 - 40:34
    value, right.
  • 40:34 - 40:37
    C.S.: So that should equal three integer,
    right.
  • 40:37 - 40:41
    D.R.: Let's see. Oh. Oh. String can't be coerced
  • 40:41 - 40:46
    into fixnum? That sounds wonderful. And I'll
    let you
  • 40:46 - 40:48
    take over from there.
  • 40:48 - 40:52
    C.S.: Cool.
  • 40:52 - 40:56
    So, Ruby has a, a method. I'm not sure
  • 40:56 - 41:00
    if it's. I believe it's injected into object.
    It's
  • 41:00 - 41:02
    extended. It's in a part of object, which
    is
  • 41:02 - 41:05
    to_i, right, which is gonna try to convert
    whatever
  • 41:05 - 41:07
    that object is into an integer. So, in this
  • 41:07 - 41:11
    case, we're converting the string two into
    an integer.
  • 41:11 - 41:15
    And that made our test pass.
  • 41:15 - 41:15
    But now.
  • 41:15 - 41:16
    D.R.: But then we get back to that banana
  • 41:16 - 41:18
    that I was trying to throw you earlier.
  • 41:18 - 41:20
    C.S.: Yeah. So here's the thing. We're looking
    at
  • 41:20 - 41:22
    the test, at the name of the method. Test
  • 41:22 - 41:24
    adds string, right. But we want to be a
  • 41:24 - 41:28
    little bit more specific about what that does,
    right.
  • 41:28 - 41:32
    So I'm gonna rename this method to test parses
  • 41:32 - 41:34
    valid strings.
  • 41:34 - 41:38
    And I'm gonna write another test that says
    test
  • 41:38 - 41:45
    raises error for invalid strings, which kind
    of, kind
  • 41:45 - 41:48
    of gives us a bit of a path of
  • 41:48 - 41:51
    where we're going with implementing this test,
    this test
  • 41:51 - 41:53
    method. So what we want to do, we'll make
  • 41:53 - 41:56
    sure that it raises an, I believe this is
  • 41:56 - 41:56
    in the-
  • 41:56 - 41:57
    D.R.: Yup.
  • 41:57 - 42:01
    C.S.: -in the plural, an argument error, and
    then
  • 42:01 - 42:05
    we'd pass it a block. If we pass it
  • 42:05 - 42:11
    an invalid argument. So in this case, a banana.
  • 42:11 - 42:14
    Kaboom.
  • 42:14 - 42:18
    D.R.: So that brings us back to our original
  • 42:18 - 42:23
    question, what is the numeric value of banana,
    right?
  • 42:23 - 42:25
    Apparently to_i is not working the way we
    expect
  • 42:25 - 42:28
    it to. Or, at least, Ruby's doing something
    with
  • 42:28 - 42:29
    it. It's definitely not throwing an error.
  • 42:29 - 42:29
    C.S.: Right.
  • 42:29 - 42:32
    D.R.: So maybe we should figure out what the
  • 42:32 - 42:34
    numeric value of banana is.
  • 42:34 - 42:36
    C.S.: Right.
  • 42:36 - 42:37
    D.R.: One way we could do that is to
  • 42:37 - 42:40
    write a test for it, right. We could write
  • 42:40 - 42:42
    an expectation. We expect x to be. Yeah.
  • 42:42 - 42:45
    AUDIENCE: [indecipherable] Would it be easier
    to see?
  • 42:45 - 42:48
    C.S.: Do you want me to do that?
  • 42:48 - 42:50
    D.R.: Yeah. Use your magic fingers.
  • 42:50 - 42:53
    C.S.: If you want, you could do.
  • 42:53 - 42:55
    AUDIENCE: That doesn't work?
  • 42:55 - 42:58
    D.R.: I don't think that helped.
  • 42:58 - 42:59
    C.S.: Yeah.
  • 42:59 - 42:59
    AUDIENCE: ??
  • 42:59 - 43:03
    C.S.: Should I make this one bigger and this
  • 43:03 - 43:03
    one smaller?
  • 43:03 - 43:06
    D.R.: Yeah, we can. I mean, the tests. We
  • 43:06 - 43:12
    can even make the font size on the tests
  • 43:16 - 43:16
    smaller.
  • 43:16 - 43:17
    C.S.: Does that help?
  • 43:17 - 43:18
    AUDIENCE: Yeah. Thanks.
  • 43:18 - 43:19
    C.S.: All right. Cool.
  • 43:19 - 43:20
    D.R.: So now we're stuck with this, you know,
  • 43:20 - 43:22
    what is the numeric value of, of, banana.
    And-
  • 43:22 - 43:23
    C.S.: So, yeah.
  • 43:23 - 43:25
    D.R.: -I would approach it by writing a test
  • 43:25 - 43:32
    for it. Test numeric. Numberic. Numberic.
    Numeric value of
  • 43:33 - 43:37
    banana. That's a drinking game actually. Every
    time a
  • 43:37 - 43:44
    presenter says banana you have to take a drink.
  • 43:44 - 43:48
    I, I would expect banana to raise an ex-
  • 43:48 - 43:50
    an exception if I tried to coerce it to
  • 43:50 - 43:52
    an integer. But, apparently Ruby's doing something
    else with
  • 43:52 - 43:55
    that. So maybe it gives it a value of
  • 43:55 - 43:57
    zero. Maybe it's trying to turn it into a
  • 43:57 - 43:59
    number. I know another language that begins
    with a
  • 43:59 - 44:01
    P and ends with a P that does something
  • 44:01 - 44:05
    similar that confounds many people.
  • 44:05 - 44:07
    And we'll use that same to_i trick that you
  • 44:07 - 44:11
    just showed me. And let's see what happens.
    Oh.
  • 44:11 - 44:12
    I get a passing test.
  • 44:12 - 44:13
    C.S.: Yup.
  • 44:13 - 44:16
    D.R.: So. Let's, just to verify, I'll make
    this
  • 44:16 - 44:19
    another value. Like one. Maybe the value of
    banana
  • 44:19 - 44:25
    is one. Nope. The actual value is zero. And,
  • 44:25 - 44:28
    interesting thing there, you can see that
    the, the
  • 44:28 - 44:30
    tests are flipping every time we run it, because
  • 44:30 - 44:36
    it's implemented as a hash and not. Fun stuff.
  • 44:36 - 44:39
    So then if the, if, if the numeric value
  • 44:39 - 44:46
    of, of banana is zero, how are we gonna
  • 44:46 - 44:48
    test- how are we gonna figure out that we've
  • 44:48 - 44:51
    been given a banana instead of a number inside
  • 44:51 - 44:53
    of our calculator?
  • 44:53 - 44:57
    Well, we could start with a little refactor,
    right.
  • 44:57 - 44:59
    We're probably gonna need some code inside
    of this
  • 44:59 - 45:01
    block. And we run into a number, an argument
  • 45:01 - 45:04
    that we've been given that isn't numerically,
    isn't a
  • 45:04 - 45:10
    numericalized varia- or, value. Something
    that we can coerce.
  • 45:10 - 45:16
    Then, we need to do something different.
  • 45:16 - 45:23
    So, we'll put a little guard in there. Because
  • 45:26 - 45:32
    we want to raise an exception, according to
    Carlos's
  • 45:32 - 45:35
    test. And.
  • 45:35 - 45:39
    C.S.: So the reason behind this is, we, we
  • 45:39 - 45:42
    realized that if we pass a valid string that
  • 45:42 - 45:44
    is able to be parsed to a number, say
  • 45:44 - 45:46
    one, in double quotes-
  • 45:46 - 45:47
    Or. So.
  • 45:47 - 45:52
    D.R.: Just take it. Just take it.
  • 45:52 - 45:55
    C.S.: So if you pass a string that is
  • 45:55 - 45:57
    able to be converted to an integer, right,
    say,
  • 45:57 - 46:01
    one in quotes, it's successfully converted
    into one integer.
  • 46:01 - 46:03
    But if we pass a string that's not able
  • 46:03 - 46:05
    to be converted to an integer, it's gonna
    resolve
  • 46:05 - 46:08
    to zero. So, what we realize is that, the
  • 46:08 - 46:13
    valid argument would be if n dash to_i equals
  • 46:13 - 46:17
    zero, and at the same time, if the original
  • 46:17 - 46:20
    string was zero, then that's a valid one.
    Otherwise,
  • 46:20 - 46:23
    raise an error. So the only reason, the only
  • 46:23 - 46:26
    way that it's a valid conversion is if the
  • 46:26 - 46:31
    integer zero came from a string zero.
  • 46:31 - 46:32
    That's what that code means.
  • 46:32 - 46:39
    AUDIENCE: Is there a reason why you're using
    triple
  • 46:42 - 46:43
    equals?
  • 46:43 - 46:50
    D.R.: Because I'm a JavaScript guy, and my
    brain
  • 46:52 - 46:55
    is programmed to use triple equals any time
    I
  • 46:55 - 46:56
    compare to zero. I'm sure is something my
    fingers
  • 46:56 - 46:56
    are trained to type. Oh, you're gonna type
    a
  • 46:56 - 46:57
    zero now, aren't you? Let me just throw another
  • 46:57 - 46:58
    equal sign in there.
  • 46:58 - 46:59
    So yeah. Like, like Carlos was saying. If
    the
  • 46:59 - 47:01
    number what I'm given converts to zero, the
    number
  • 47:01 - 47:03
    that I'm given converts to zero but it isn't
  • 47:03 - 47:06
    actually string zero, then that would be one
    of
  • 47:06 - 47:09
    those strings that coerces to zero for us.
    Thank
  • 47:09 - 47:10
    you banana.
  • 47:10 - 47:11
    Yeah?
  • 47:11 - 47:14
    AUDIENCE: If you, if you coerce it to a
  • 47:14 - 47:18
    string that's the same as itself, as an alternative?
  • 47:18 - 47:20
    D.R.: Taking, what, sorry?
  • 47:20 - 47:23
    AUDIENCE: Take, take, take whatever comes
    in, and coerce
  • 47:23 - 47:24
    it to string, and test whether it's the same
  • 47:24 - 47:29
    as itself. If it is, then it's a literal.
  • 47:29 - 47:31
    It's a, it's a string.
  • 47:31 - 47:35
    D.R.: So, same as that?
  • 47:35 - 47:37
    AUDIENCE: Well, you got. I don't mean in the
  • 47:37 - 47:38
    second bit. Yeah.
  • 47:38 - 47:40
    D.R.: Let's see.
  • 47:40 - 47:42
    C.S.: Doesn't look like it.
  • 47:42 - 47:44
    D.R.: Apparently not.
  • 47:44 - 47:46
    AUDIENCE: Valid strings are failing.
  • 47:46 - 47:47
    C.S.: Yeah.
  • 47:47 - 47:54
    D.R.: Right. Now valid strings are failing.
  • 47:55 - 47:57
    But that's the beauty, again, of the Dojo.
    If
  • 47:57 - 47:58
    there's something that I want to experiment
    with, I'm,
  • 47:58 - 48:01
    I'm at green tests. I can try something else.
  • 48:01 - 48:03
    Just, just to see, how does Ruby behave this
  • 48:03 - 48:04
    way?
  • 48:04 - 48:06
    C.S.: Right. All right.
  • 48:06 - 48:09
    So, we're gonna take a little break. So you
  • 48:09 - 48:09
    all can.
  • 48:09 - 48:12
    D.R.: Yeah. Project Euler is a great- if,
    if
  • 48:12 - 48:16
    you don't know about Project Euler, spelled
    e-u-l-e-r, Euler.
  • 48:16 - 48:23
    Euler. Euler. Hello. ProjectEuler dot net
    has a ton
  • 48:24 - 48:30
    of, of computer science problems that seem
    trivial at
  • 48:30 - 48:32
    first, but if you implement them in the most
  • 48:32 - 48:35
    trivial manner possible, you'll do something
    silly like blow
  • 48:35 - 48:37
    out your recursion stack or take an hour and
  • 48:37 - 48:40
    a half to compute the result or something
    like
  • 48:40 - 48:41
    that. So you have to think about them a
  • 48:41 - 48:42
    little more.
  • 48:42 - 48:45
    But, you can do it in a test-driven style,
  • 48:45 - 48:48
    and, and once you get passing tests on your
  • 48:48 - 48:52
    hour and a half long solution, then optimize,
    refactor,
  • 48:52 - 48:55
    and get a more optimal solution. Figure, there's
    lots
  • 48:55 - 49:00
    of prime number calculations inside of Project
    Euler. Euler.
  • 49:00 - 49:02
    Euler. You'll never forget that now.
  • 49:02 - 49:06
    Code Wars is another. That's, that website
    launched recently.
  • 49:06 - 49:08
    CodeWars dot com. You can sign up for JavaScript,
  • 49:08 - 49:12
    CoffeeScript and Ruby, I think right now.
    They've got
  • 49:12 - 49:14
    a bunch of Code Katas. They even call them
  • 49:14 - 49:17
    Code Katas. You get different belts starting
    from 8kyu
  • 49:17 - 49:20
    and work your way up to Grand Master Black
  • 49:20 - 49:25
    Belt. CodeWars dot com. I, I recommend that
    to
  • 49:25 - 49:29
    my students as well. And it's, again, emphasizing
    test-driven.
  • 49:29 - 49:31
    You totally don't have to do it test-driven,
    but
  • 49:31 - 49:33
    it's a great way to practice.
  • 49:33 - 49:35
    There are, there are books on the subject,
    which
  • 49:35 - 49:37
    we'll talk about at the end of our presentation.
  • 49:37 - 49:38
    There's a great book by-
  • 49:38 - 49:44
    C.S.: Emily Clark, if I remember correctly.
  • 49:44 - 49:49
    D.R.: Navigata. Bam. Coding Dojo Handbook.
  • 49:49 - 49:52
    C.S.: Emily Bache. Yeah.
  • 49:52 - 49:59
    D.R.: Forward by Uncle Bob. Rob Martin. So,
    this
  • 49:59 - 50:01
    has a lot of Katas in it, a lot
  • 50:01 - 50:05
    of very standard Katas. What we found in running
  • 50:05 - 50:08
    the Coding Dojo for a great, for, for two
  • 50:08 - 50:09
    years, two plus years at that point, was that
  • 50:09 - 50:12
    you can recycle the same problems over and
    over
  • 50:12 - 50:15
    again. Once you find a couple that are easy
  • 50:15 - 50:18
    to explain and get everyone to wrap their
    heads
  • 50:18 - 50:20
    around, you use them over and over and over
  • 50:20 - 50:22
    again, and you try them in different languages.
    You
  • 50:22 - 50:24
    try them with different constraints. You just
    try to
  • 50:24 - 50:27
    see if you can solve the dang problem. All
  • 50:27 - 50:30
    kinds of things come into your head in the
  • 50:30 - 50:32
    weeks in between when you do the Dojo, and
  • 50:32 - 50:34
    when you do the Dojo again.
  • 50:34 - 50:36
    Some of the common ones are like, Roman numberals-
  • 50:36 - 50:41
    Roman numeral conversions. Uncle Bob Martin's
    famous one was
  • 50:41 - 50:43
    the bowling game. We did that one time at
  • 50:43 - 50:46
    the Coding Dojo in Orlando. We tried to do
  • 50:46 - 50:48
    the bowling game. One time. And what we discovered
  • 50:48 - 50:49
    is that nerds actually do not know how to
  • 50:49 - 50:51
    score bowling at all.
  • 50:51 - 50:55
    It is, that knowledge is completely encapsulated
    in computer
  • 50:55 - 50:57
    software now and no one has committed any
    of
  • 50:57 - 50:59
    it to memory. And does not even understand
    how
  • 50:59 - 51:02
    that software runs anymore. We just know that,
    occasionally,
  • 51:02 - 51:07
    turkeys come on the screen. And we have, only
  • 51:07 - 51:11
    if we have the numbers up, right. So.
  • 51:11 - 51:12
    Those are great resources for that.
  • 51:12 - 51:13
    C.S.: Take a break now?
  • 51:13 - 51:15
    D.R.: Yeah. Yeah. Let's take a break, and
    when
  • 51:15 - 51:18
    we come back, we're gonna, we're gonna give
    everybody
  • 51:18 - 51:21
    a post-it note, a different-color post-it
    note. This is
  • 51:21 - 51:25
    some logistics. You'll pair up, or, pair up.
    You'll
  • 51:25 - 51:26
    group up into groups of three and we'll do
  • 51:26 - 51:30
    like a Code, Code Retreat-style Coding Dojo
    with the
  • 51:30 - 51:32
    entire group. We got a problem for you. We've
  • 51:32 - 51:35
    got some constraints for you. You can totally
    use
  • 51:35 - 51:38
    what you've, what you've learned just right
    now to
  • 51:38 - 51:41
    practice. We'll do that and we'll take another
    break
  • 51:41 - 51:42
    and we'll do another Coding Dojo after that
    with
  • 51:42 - 51:43
    a different problem.
  • 51:43 - 51:43
    C.S.: Cool.
  • 51:43 - 51:44
    D.R.: Don't have to participate in all three.
    Don't
  • 51:44 - 51:46
    have to participate in any of them.
  • 51:46 - 51:46
    C.S.: Yup.
  • 51:46 - 51:48
    D.R.: If you don't really want to. But we
  • 51:48 - 51:51
    encourage you to, to come and, and play and
  • 51:51 - 51:51
    practice with us.
  • 51:51 - 51:52
    C.S.: All right. Fifteen minutes?
  • 51:52 - 51:53
    D.R.: Yup.
  • 51:53 - 51:54
    C.S.: Sounds good?
  • 51:54 - 51:55
    D.R.: We'll meet back in fifteen minutes.
  • 51:55 - 51:56
    C.S.: All right. Cool.
  • 51:56 - 51:57
    Before we start, I want to make sure that
  • 51:57 - 52:01
    everyone has Ruby installed. That is pretty
    much the
  • 52:01 - 52:04
    only per-requisite, just to have Ruby, at
    least 1.9.3,
  • 52:04 - 52:07
    I want to say, which is the version that
  • 52:07 - 52:07
    comes with miniTest, right. No one-
  • 52:07 - 52:10
    how to run, write Ruby from the command line?
  • 52:10 - 52:17
    How far down the rabbit hole do we need
  • 52:17 - 52:19
    to go?
  • 52:19 - 52:21
    C.S.: So if you want to see what version
  • 52:21 - 52:28
    of Ruby you have, you run ruby dash dash
  • 52:28 - 52:29
    version. And-
  • 52:29 - 52:36
    D.R.: In a, in a window that you can-
  • 52:36 - 52:36
    C.S.: There you go. Ruby dash dash version.
    And
  • 52:36 - 52:39
    it should be, at least, 1.9.3. For this one,
  • 52:39 - 52:41
    I'm using 2 point 0, which is fine. You
  • 52:41 - 52:42
    don't have to be on 2 point 0, but
  • 52:42 - 52:42
    at least 1.9.3.
  • 52:42 - 52:43
    D.R.: And we'll show you that magic bash incantation
  • 52:43 - 52:47
    as well if you want to use that in
  • 52:47 - 52:50
    your, in your tests.
  • 52:50 - 52:54
    C.S.: Cool. So everyone has Ruby at least
    1.9.3
  • 52:54 - 52:57
    and at least one text editor? Cool.
  • 52:57 - 53:00
    D.R.: Something emacs-flavored.
  • 53:00 - 53:01
    C.S.: Not.
  • 53:01 - 53:06
    Right. So the first problem, we want to group
  • 53:06 - 53:11
    into pairs of three, right. So, you might
    have
  • 53:11 - 53:15
    gotten a post-it from David or maybe got yourselves,
  • 53:15 - 53:17
    and what we want to do is, we want
  • 53:17 - 53:19
    to group together into groups of three, with
    people
  • 53:19 - 53:22
    with the same color post-its. So if you have
  • 53:22 - 53:25
    an orange post-it, you look for two other
    people
  • 53:25 - 53:26
    with that same color post-it.
  • 53:26 - 53:28
    D.R.: And that, if you have-
  • 53:28 - 53:31
    C.S.: Someone's gonna have to get up.
  • 53:31 - 53:37
    Going over the etiquettes real quick. Test-driven
    development, as
  • 53:37 - 53:39
    you might have seen us, David and I, doing
  • 53:39 - 53:43
    here, is red-green-refactor, so. You write
    a failing test
  • 53:43 - 53:48
    before you write any production code. Giggles.
    You make
  • 53:48 - 53:50
    that test pass. And if you need to, you
  • 53:50 - 53:53
    go back and you refactor, right. And then
    you
  • 53:53 - 53:55
    do that cycle. That's the cycle that you want
  • 53:55 - 53:55
    to follow. So.
  • 53:55 - 53:57
    D.R.: And just because you get to a green
  • 53:57 - 53:59
    cycle does not mean you have to refactor.
  • 53:59 - 54:00
    C.S.: Right.
  • 54:00 - 54:01
    D.R.: But it's a good time to take a
  • 54:01 - 54:04
    break. Look, you know, look back at the code
  • 54:04 - 54:06
    as a pair, as a group, and say, should
  • 54:06 - 54:06
    we refactor?
  • 54:06 - 54:06
    C.S.: Yup.
  • 54:06 - 54:09
    D.R.: Is there something we can make simpler?
    Is
  • 54:09 - 54:11
    there something we were copying and pasting?
    Is there
  • 54:11 - 54:12
    a different way we could do this? Is there
  • 54:12 - 54:15
    another test we should add? Figure, take,
    take your
  • 54:15 - 54:16
    break. Figure out what you're gonna do next.
  • 54:16 - 54:18
    C.S.: Right. And we're gonna do the ping pong
  • 54:18 - 54:21
    pairing, right. So just like David and I did,
  • 54:21 - 54:23
    you write a failing test. You pass it along
  • 54:23 - 54:25
    to your co-pilot. So you have three people.
    Most
  • 54:25 - 54:26
    of you have three people. So you're gonna
    have,
  • 54:26 - 54:29
    start with a pilot and a co-pilot, and then
  • 54:29 - 54:31
    the third person is gonna be the audience,
    right.
  • 54:31 - 54:34
    And what we recommend is that the audience
    does
  • 54:34 - 54:37
    not talk on red. What that means is that,
  • 54:37 - 54:40
    whenever there's a failing test, you let the
    pair
  • 54:40 - 54:43
    figure out what the solution is, right. So
    only
  • 54:43 - 54:46
    the driver and the co-pilot are part of trying
  • 54:46 - 54:48
    to figure out how to make that one test
  • 54:48 - 54:48
    pass.
  • 54:48 - 54:50
    D.R.: But don't think that you're stuck on
    Alcatraz
  • 54:50 - 54:54
    or something. If you're a pair and, you may
  • 54:54 - 54:57
    be really new to Ruby, or maybe just new
  • 54:57 - 54:58
    to test-driven development and you're like,
    I don't know
  • 54:58 - 55:00
    what to type here. Do you know what to
  • 55:00 - 55:03
    type here? I don't know what to type here.
  • 55:03 - 55:07
    Please ask your audience first, and if none
    of
  • 55:07 - 55:09
    the three of you know what you're doing next
  • 55:09 - 55:11
    or what you need to do next, raise your
  • 55:11 - 55:13
    hand. We've got some helpers that'll be walking
    around.
  • 55:13 - 55:13
    C.S.: Right.
  • 55:13 - 55:14
    D.R.: Helping out.
  • 55:14 - 55:14
    C.S.: And- yeah.
  • 55:14 - 55:15
    D.R.: We'll be walking around too.
  • 55:15 - 55:18
    C.S.: And, and the internet is not super cool,
  • 55:18 - 55:22
    but it's also good to look up. And, I
  • 55:22 - 55:24
    mean, internet's not reliable here, right.
    But you're more
  • 55:24 - 55:27
    than free to look up documentation and references
    and,
  • 55:27 - 55:30
    you know, ways to use the API and different
  • 55:30 - 55:32
    assertions that you can use. This is an open
  • 55:32 - 55:33
    book test.
  • 55:33 - 55:35
    D.R.: Yeah. And another thing to keep in mind
  • 55:35 - 55:39
    is IRB is open game as well. If you
  • 55:39 - 55:41
    are like, like, like you saw with us, when
  • 55:41 - 55:42
    we were doing the banana test-
  • 55:42 - 55:43
    C.S.: Right.
  • 55:43 - 55:45
    D.R.: We wrote a test to describe, to describe,
  • 55:45 - 55:47
    to assert what we thought the value of banana
  • 55:47 - 55:49
    would be when we passed it to integer. You're
  • 55:49 - 55:51
    more than welcome to just close down your
    editor
  • 55:51 - 55:55
    or bring up IRB in whatever fashion you want
  • 55:55 - 55:58
    to. And, what is banana.to_i? Oh, it's zero.
    That's
  • 55:58 - 56:01
    weird, but, you know. Whatever.
  • 56:01 - 56:05
    So, like, Kaikay was saying, don't talk, the
    audience
  • 56:05 - 56:06
    shouldn't, whoever the audience member is,
    if you have
  • 56:06 - 56:10
    one or two people, don't talk on red. If
  • 56:10 - 56:12
    you're not coding, keep quiet unless you're
    part of
  • 56:12 - 56:15
    the pair, right. And it's time to switch.
  • 56:15 - 56:17
    If you have an idea, if you have something
  • 56:17 - 56:19
    - I think it should do this or I
  • 56:19 - 56:21
    think it should do that - rather than trying
  • 56:21 - 56:22
    to describe too much of it in English, I
  • 56:22 - 56:24
    mean, it might be helpful to, to talk about
  • 56:24 - 56:26
    it a little bit in English, show your work
  • 56:26 - 56:28
    in code. Show your idea in code. Just write
  • 56:28 - 56:31
    an assert statement that does what you think
    it
  • 56:31 - 56:32
    needs to do. Ask the code a question.
  • 56:32 - 56:34
    C.S.: And this is not a code golf, right.
  • 56:34 - 56:37
    We're not here to show off, right, some Perl
  • 56:37 - 56:40
    black magic that you inherited from a previous
    job.
  • 56:40 - 56:43
    So make sure that we're, whatever you write,
    it's
  • 56:43 - 56:45
    explicit enough so that everyone in your group
    understands,
  • 56:45 - 56:47
    right. So if you need to write a little
  • 56:47 - 56:49
    bit more. If you need to break out do
  • 56:49 - 56:51
    end from a curly brace, do a do end.
  • 56:51 - 56:52
    So do that.
  • 56:52 - 56:54
    D.R.: Right. And, as the audience, this is
    like,
  • 56:54 - 56:57
    the one exception to the rule. If you see
  • 56:57 - 57:01
    the pair deviating from red-green-refactor,
    like they start writing
  • 57:01 - 57:04
    production code before they write a test,
    you get
  • 57:04 - 57:07
    to say, you know, eh, or test, or if
  • 57:07 - 57:09
    you see them sit on, they, they've written
    some
  • 57:09 - 57:11
    code and they haven't run the test for awhile,
  • 57:11 - 57:16
    eh. Give them the buzzer. Survey says. And
    if
  • 57:16 - 57:17
    you see somebody starting to use voodoo where,
    whether
  • 57:17 - 57:20
    or not you're part of the pair, or they
  • 57:20 - 57:23
    just write something and you're like, what
    is that?
  • 57:23 - 57:26
    Raise your hand and say no voodoo, or call
  • 57:26 - 57:29
    voodoo on them. Call molligan. Tell them to
    do
  • 57:29 - 57:30
    it over.
  • 57:30 - 57:31
    C.S.: And that should be enough.
  • 57:31 - 57:33
    So you guys are in groups. You've selected
    one
  • 57:33 - 57:37
    machine to work off of. And, please delete
    all
  • 57:37 - 57:39
    the code that you had previously. Just make
    sure
  • 57:39 - 57:41
    that you start from a blank slate. You're
    looking
  • 57:41 - 57:46
    at a blank canvas. Blank text editor. Everyone
    good
  • 57:46 - 57:47
    to start?
  • 57:47 - 57:49
    All right. So here's the problem that you're
    gonna
  • 57:49 - 57:50
    do.
  • 57:50 - 57:55
    Boom. A calculator. It's gonna have one operation,
    which
  • 57:55 - 57:57
    is gonna be addition. It should be able to
  • 57:57 - 58:01
    take a variable number of arguments, but,
    we're gonna
  • 58:01 - 58:03
    add in a constraint. You're not allowed to
    use
  • 58:03 - 58:06
    inject or, for that matter, reduce.
  • 58:06 - 58:11
    D.R.: This somewhat limits the playing field.
  • 58:11 - 58:14
    C.S.: Right. So that is the plan of action. And if-
  • 58:14 - 58:16
    D.R.: Any questions about the problem? Right?
  • 58:18 - 58:18
    C.S.: Cool?
  • 58:18 - 58:20
    D.R.: Everybody, everybody grasps the gist
    of it? If
  • 58:20 - 58:22
    you guys get done with this before we get
  • 58:22 - 58:24
    done with the overall Dojo, feel free to do
  • 58:24 - 58:27
    what Kaikay and I did by expanding the problem.
  • 58:27 - 58:29
    What if we gave it strings? Or what if
  • 58:29 - 58:32
    we gave it, you know, bananas. Or what if
  • 58:32 - 58:33
    we threw an object at it?
  • 58:33 - 58:34
    C.S.: Right.
  • 58:34 - 58:35
    D.R.: Or whatever, you know.
  • 58:35 - 58:36
    AUDIENCE: Can you clarify inject?
  • 58:36 - 58:41
    D.R.: So, we were gonna use numbers dot inject.
  • 58:41 - 58:42
    We were gonna use array dot inject.
  • 58:42 - 58:45
    But as we pointed out the audience, we can also use
  • 58:45 - 58:47
    array dot reduce, which I'm much more familiar
    with
  • 58:47 - 58:50
    since I come from JavaScript. So, don't use
    inject.
  • 58:50 - 58:53
    Don't use the reduce methods. There is a third
  • 58:53 - 58:59
    option available to you. If you wanted to
    look
  • 58:59 - 59:00
    at each-
  • 59:00 - 59:01
    C.S.: Right.
  • 59:01 - 59:03
    D.R.: Element in-
  • 59:03 - 59:05
    C.S.: -in an array.
  • 59:05 - 59:07
    D.R.: Just. Just saying.
  • 59:07 - 59:12
    C.S.: Cool. And we're gonna use three minute
    rotation
  • 59:12 - 59:15
    time outs. So let's bring it up here.
  • 59:15 - 59:20
    AUDIENCE: [chatter]
  • 59:21 - 59:22
    C.S.: Oh no.
  • 59:22 - 59:22
    D.R.: Oh, you've got it. You can just stick
  • 59:22 - 59:23
    it over there.
  • 59:23 - 59:28
    C.S.: All right. So, let's do. Simple timer.
  • 59:28 - 59:32
    AUDIENCE: [chatter]
  • 59:34 - 59:36
    D.R.: Pop that on the side window there. The
  • 59:36 - 59:37
    other window.
  • 59:37 - 59:43
    C.S.: Yup. All right. So. So if you need,
  • 59:43 - 59:46
    or. Do we show, like, half of it and
  • 59:46 - 59:47
    half of that?
  • 59:47 - 59:49
    D.R.: Yeah. Yeah. Do the, do the presentation
    again.
  • 59:49 - 59:49
    C.S.: This.
  • 59:49 - 59:51
    D.R.: Yeah. Let's do that.
  • 59:53 - 59:55
    C.S.: Well, but how do we show both at
  • 59:55 - 59:56
    the same time?
  • 59:57 - 59:58
    D.R.: Something bizarre.
  • 59:58 - 59:59
    C.S.: It's called moom.
  • 59:59 - 60:00
    AUDIENCE: Moom.
  • 60:00 - 60:01
    C.S.: Yeah.
  • 60:01 - 60:01
    AUDIENCE: Thank you.
  • 60:02 - 60:04
    D.R.: I use optimal layout, because it's basically
    the
  • 60:04 - 60:05
    same thing.
  • 60:06 - 60:08
    C.S.: So if you need a start, your initial
  • 60:08 - 60:11
    code, kind of a cheat sheet. This is what
  • 60:11 - 60:14
    we used to start. So requiring minitest up
    at
  • 60:14 - 60:18
    the top. Starting off with your test gaze.
    And
  • 60:18 - 60:20
    then writing the first test. If you want to
  • 60:20 - 60:22
    set up like the auto run thing, is down
  • 60:22 - 60:25
    here at the bottom.
  • 60:25 - 60:29
    Remember. Ping pong. Write a failing test.
    Pass it
  • 60:29 - 60:31
    along to your co-pilot.
  • 60:31 - 60:37
    D.R.: So then to do the timer, put the
  • 60:37 - 60:41
    timer up on the right screen.
  • 60:41 - 60:45
    C.S.: Full size? Close that down.
  • 60:45 - 60:51
    D.R.: You actually have to reduce the size
    of
  • 60:51 - 60:52
    the font.
  • 60:52 - 60:53
    C.S.: Yeah.
  • 60:53 - 60:55
    D.R.: Awesome.
  • 60:55 - 60:57
    C.S.: All right.
  • 60:57 - 61:00
    D.R.: So we're gonna give you three minutes
    to
  • 61:00 - 61:03
    go as a pair. Oh. We'll give you three
  • 61:03 - 61:06
    minutes as a pair, right. As the current pair.
  • 61:06 - 61:08
    And then when the timer goes off, switch.
    And
  • 61:08 - 61:10
    we'll do the same thing, and after that, we'll
  • 61:10 - 61:13
    take, we'll do a little half time.
  • 61:13 - 61:16
    AUDIENCE: [chatter]
  • 61:16 - 61:23
    C.S.: All right. Let's stop for here. So,
    stop
  • 61:24 - 61:27
    exactly where you are. All right. And now,
    it's
  • 61:27 - 61:30
    time for us to do a little retrospective on
  • 61:30 - 61:34
    what we just did. On this round, right. So,
  • 61:34 - 61:36
    do we have enough pens here?
  • 61:36 - 61:39
    D.R.: We might.
  • 61:39 - 61:41
    C.S.: We at least have enough-
  • 61:41 - 61:43
    D.R.: Near enough. Enough pens per group.
  • 61:43 - 61:47
    So, just like an Agile retrospective, we're
    gonna ask
  • 61:47 - 61:50
    each other just three question. What did we
    do
  • 61:50 - 61:52
    well, that we would like to do the next
  • 61:52 - 61:54
    time we do this exercise? What would we like
  • 61:54 - 61:57
    to improve for the next time? So what did
  • 61:57 - 61:59
    we do well that we want to repeat? What
  • 61:59 - 62:01
    did we do maybe not so well, maybe we'd
  • 62:01 - 62:03
    like, maybe we'd like to improve for next
    time.
  • 62:03 - 62:04
    And did we meet our goals and why? And,
  • 62:04 - 62:07
    again, our stated goals are not, did we solve
  • 62:07 - 62:08
    the problem?
  • 62:08 - 62:10
    That really wasn't ever an issue. That wasn't
    really
  • 62:10 - 62:14
    any, I mean we, we can continue inventing
    different
  • 62:14 - 62:16
    edge-cases to test this problem against. We
    can continue
  • 62:16 - 62:20
    asking questions of this problem. Even this
    simple problem,
  • 62:20 - 62:22
    for a very long time. So it's never really
  • 62:22 - 62:24
    about, did we solve the problem? No, the world
  • 62:24 - 62:27
    does not need another adder.
  • 62:27 - 62:30
    And most of the problems that we pick are
  • 62:30 - 62:33
    gonna be like that. But did we learn something?
  • 62:33 - 62:36
    Did we find out something new about Ruby or
  • 62:36 - 62:38
    about the people that we work with? Did we
  • 62:38 - 62:41
    practice our skills? Do we feel like we have
  • 62:41 - 62:44
    gained some skill or knowledge because of
    this exercise?
  • 62:44 - 62:46
    And did we have fun?
  • 62:46 - 62:49
    So. We can just, we can start with the.
  • 62:49 - 62:52
    Just give you guys another three minutes to
    figure
  • 62:52 - 62:52
    out-
  • 62:52 - 62:52
    C.S.: Yeah.
  • 62:52 - 62:55
    D.R.: Just ask yours- each other those three
    questions.
  • 62:55 - 62:56
    Did we, what did we do well that we
  • 62:56 - 62:58
    want to do for the next one? What did
  • 62:58 - 63:00
    we do maybe not so well that we would
  • 63:00 - 63:03
    like to improve for the next one? And did
  • 63:03 - 63:05
    we meet our goals, and why or why not?
  • 63:05 - 63:08
    We'll give you guys another timer for that.
  • 63:08 - 63:15
    C.S.: Just write it down on the post-it note
  • 63:16 - 63:17
    we gave you, and then we can.
  • 63:17 - 63:18
    AUDIENCE: [chatter]
  • 63:18 - 63:21
    C.S.: All right. Cool. Stop exactly where
    you are.
  • 63:21 - 63:25
    Go back to your editor. Delete everything.
    And get
  • 63:25 - 63:30
    ready for the next problem. Again, same group.
    Same
  • 63:30 - 63:32
    three minute rotation. But now we're gonna
    do a
  • 63:32 - 63:34
    different problem, right.
  • 63:34 - 63:37
    Still on the calculator realm. Still gonna
    be in
  • 63:37 - 63:41
    addition. But now your calc- your new calculator,
    that
  • 63:41 - 63:43
    you're gonna start from scratch, is gonna
    need to
  • 63:43 - 63:48
    take strings as arguments. As an example,
    you're gonna
  • 63:48 - 63:52
    add one as a string, slash two, and it's
  • 63:52 - 63:57
    gonna need to return the integer three.
  • 63:57 - 63:59
    AUDIENCE: The integer or the string?
  • 63:59 - 63:59
    D.R.: The integer.
  • 63:59 - 64:00
    C.S.: The integer. To make it-
  • 64:00 - 64:04
    D.R.: Stop wherever you want to stop.
  • 64:04 - 64:09
    I, I believe there was an earlier presentation
    on
  • 64:09 - 64:11
    just enough.
  • 64:11 - 64:12
    AUDIENCE: [chatter]
  • 64:12 - 64:13
    C.S.: Cool.
  • 64:13 - 64:17
    D.R.: And you can choose to you, you can
  • 64:17 - 64:21
    choose that last constraint that we offered.
    The don't
  • 64:21 - 64:24
    use inject. You can, and, take it or leave
  • 64:24 - 64:28
    it, right. Doing the calc add with strings
    might
  • 64:28 - 64:28
    be-
  • 64:28 - 64:31
    C.S.: More than a big problem to solve.
  • 64:31 - 64:33
    D.R.: Right. So, if you want to use inject
  • 64:33 - 64:34
    or reduce or yo mama, whatever. It doesn't
    matter.
  • 64:34 - 64:34
    The only, the only requirement we will have
    is,
  • 64:34 - 64:35
    you have to take, you have to accept strings,
  • 64:35 - 64:36
    like, one, two, three, four, in, in words,
    t-h,
  • 64:36 - 64:39
    you know, r-e-e. You go up to ten. You
  • 64:39 - 64:42
    go up to one-hundred. I don't care. How far
  • 64:42 - 64:49
    you want to go. Cause you, there may be
  • 64:49 - 64:52
    some typing involved.
  • 64:52 - 64:54
    C.S.: Right.
  • 64:54 - 65:00
    AUDIENCE: You still want it to return an integer
  • 65:00 - 65:02
    or a string?
  • 65:02 - 65:03
    D.R.: It should return an integer.
  • 65:03 - 65:04
    AUDIENCE: [indecipherable] - or should you
    forget integers?
  • 65:04 - 65:06
    C.S.: Forget. Array delete what you had, and
    then
  • 65:06 - 65:10
    start from scratch, right.
  • 65:10 - 65:17
    D.R.: And really, start from scratch. Even
    back to
  • 65:25 - 65:25
    the boiler plate that we gave you guys.
  • 65:25 - 65:25
    AUDIENCE: [chatter]
  • 65:25 - 65:26
    C.S.: All right everybody. Pencils down.
  • 65:26 - 65:26
    D.R.: No more coding.
  • 65:26 - 65:29
    C.S.: And just like we did before. Quick retrospective.
  • 65:29 - 65:32
    Write down things that worked well for this
    round.
  • 65:32 - 65:39
    Things that could have been better and need
    improvement
  • 65:40 - 65:40
    for upcoming rounds.
  • 65:40 - 65:42
    D.R.: And also as a process, as a whole.
  • 65:42 - 65:45
    Like, what did you guys like about the whole
  • 65:45 - 65:48
    process? What did you guys, what would you
    guys
  • 65:48 - 65:50
    improve about this workshop if you were to
    go
  • 65:50 - 65:53
    to it again? And did you- did we meet
  • 65:53 - 65:56
    our goals, and why or why not? So we'll
  • 65:56 - 65:57
    give you a couple minutes to do that real
  • 65:57 - 66:00
    quick as a group. No more coding. I will
  • 66:00 - 66:02
    come by and delete your files.
  • 66:02 - 66:06
    So, did we learn something? Everybody learn
    something? Feel
  • 66:06 - 66:10
    like you pulled something your way? Did we
    practice?
  • 66:10 - 66:14
    Do you feel like you've practiced some? Did
    we
  • 66:14 - 66:19
    solve the problem? Some? Solved some of the
    problem,
  • 66:19 - 66:23
    right. Ish. Solved-ish the problem.
  • 66:23 - 66:24
    Did we have fun?
  • 66:24 - 66:25
    AUDIENCE: Yeah. Yes. Yeah.
  • 66:25 - 66:25
    D.R.: Awesome.
  • 66:25 - 66:26
    C.S.: Cool.
  • 66:26 - 66:28
    D.R.: So, if you want to know more about
  • 66:28 - 66:32
    the Coding Dojo, this is Kaikay's new favorite
    book.
  • 66:32 - 66:36
    Coding Dojo Handbook. I'm totally picking
    up a copy.
  • 66:36 - 66:38
    There's way more resources out there. There
    are local
  • 66:38 - 66:39
    meet up groups. You should take this to your
  • 66:39 - 66:42
    user group. We started a whole group around
    Coding
  • 66:42 - 66:46
    Dojo in, in Orlando. But we also, because
    I
  • 66:46 - 66:48
    ran the PHP group and I ran the Python
  • 66:48 - 66:49
    group at the time, we also used it for
  • 66:49 - 66:52
    the Python group and the PHP group. We'll
    probably
  • 66:52 - 66:54
    do it again at node. We've done it at
  • 66:54 - 66:58
    Ruby. We've done it all the user groups around.
  • 66:58 - 66:59
    If you want to know, if you want to
  • 66:59 - 67:01
    get some starting points for that, I wrote
    a
  • 67:01 - 67:04
    blog post on getting start, getting past all
    the
  • 67:04 - 67:07
    Yak shaving of setting up the automated tests
    running
  • 67:07 - 67:09
    in the background and the boilerplate for
    each one
  • 67:09 - 67:11
    of the, for each one of the different languages
  • 67:11 - 67:12
    you want to try.
  • 67:12 - 67:15
    That's in the Orlando Dojo reporepo on, on
    GitHub.
  • 67:15 - 67:17
    It's, or the Orlando Dojo organization.
  • 67:17 - 67:22
    C.S.: Talking about meet ups. The best way
    to
  • 67:22 - 67:25
    actually experience more of this is to do
    it
  • 67:25 - 67:29
    in practice, right. So. So go ahead to meet
  • 67:29 - 67:32
    up dot com and look for nearby Coding Dojo
  • 67:32 - 67:36
    meet ups. There's plenty of them out there,
    and
  • 67:36 - 67:39
    if you don't find one, more than welcome to
  • 67:39 - 67:42
    create one yourself. All you need is a friend
  • 67:42 - 67:45
    who you can pair with every week or so,
  • 67:45 - 67:47
    and then, if you just put it out there,
  • 67:47 - 67:50
    put it online that you guys are meeting every
  • 67:50 - 67:53
    week at this specific place at this specific
    time,
  • 67:53 - 67:54
    people will show up. Believe me.
  • 67:54 - 67:56
    D.R.: Right. Just be consistent.
  • 67:56 - 68:00
    C.S.: Yeah. Just be consistent. And, I think
    that's
  • 68:00 - 68:01
    it for today. If you guys want to talk
  • 68:01 - 68:03
    more about this and that-
Title:
RailsConf 2014 - Workshop - Ruby Coding Dojo by Carlos Souza and David Rogers
Description:

more » « less
Duration:
01:08:25

English subtitles

Revisions