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