Inspired by the Coding Dojo book and Uncle Bob Martin, I wrote this talk to inspire you to invest into your own career by practicing katas. This is a slide deck I intended to give at AustinRB group but due to mother nature I presented online at Google Hangouts followed by a demonstration of the string kata.

1. Getting Better
through practice

2. Athletes train
•
Train Every Day
•
Keep Eye on the Prize
•
Be specific in training
•
Fuel body for peak performance
•
Know when to rest
•
Have perfect form
http://exercise.about.com/od/healthinjuries/a/olympictraining.htm

3. Musicians Train
•
Continuous improvement is a fundamental part
of the job and of the performer.
•
Many musicians continue to pay for their own
lessons to further develop their skills.
http://www.prospects.ac.uk/musician_training.htm!

4. Your Career is your
Responsibility
<start channelling UncleBob>
It’s not your employers responsibility
says Uncle Bob
book: The Clean Coder

5. Not Your Company’s
Responsibility To
!
•
•
•
buy books
send you to conferences
subscriptions ( CodeSchool, PluralSite, TreeHouse )
!
!
Take Responsibility for your own career!
</end channelling UncleBob>

6. Ways to Practice
•
reading a book
•
watch videos at confreaks / youtube
•
going to and/or speaking to user group
•
mentor someone

7. Practice with Katas
•
Kata is a simple programing problem
•
Goal is to train your fingers and brain
!
•
Pick one to work on every day for a week, ok
maybe at least 3 days :)
•
Uncle Bob does one in morning and at night

8. Variations
•
Practice with new languages
•
editors (VI, Emacs, Textmate, Sublime, Atom,
Light Table)
•
practice keyboard shortcuts (shortcutfoo.com)
•
test libraries (rspec, minitest/spec, test unit)
•
styles (Functional, TDD, London Style, etc)

9. Functional
•
recursion, lists, reduce, map
•
Tom Stuart video
•
https://skillsmatter.com/skillscasts/1101enumerators

10. Traditional TDD
http://ryantablada.com/post/red-green-refactor---a-tdd-fairytale

11. Write all the tests
•
rapid fire, just write out every test you could think
of as it statements
•
keep them in pending state
•
pass them one by one
•
fiveruns gem is a great way to look at test
output, spec —documentation is also great

12. Write it out on paper
•
stepping away from the keyboard
•
list every possible way
•
sketch it or psuedo code
•
then code it!

13. London-Style TDD
•
Developed in London by early adopters of of Extreme
Programming
•
Mock Everything
•
Test relationships
•
Naysayers say using mocks is crutch for bad design
•
Good video from Gary Bernhardt
https://www.youtube.com/watch?v=tdNnN5yTIeM

14. Nola’s interpretation
•
I’ve seen mocks use badly.
•
Very Badly.
•
Great to “skip” certain parts of the problem, as a
temporary measure.
•
Great to “skip” making expensive API calls
•
Just depends what part your tests are focused on
#facepalm

15. shocking white slide
of code next!!

16. Example of London Style
class Calc!
end!
describe Calc do
before do
@c = Calc.new
end
!
!
it "should be a class" do
@c.should be_an_instance_of(Calc)
end
it "should accept a string" do
@c.should_receive(:add).with("1").and_return(1)
expect(@c.add("1")).to be 1
end
it "should accept a string with 2 numbers" do
@c.should_receive(:add).with("1,2,3").and_return(6)
expect(@c.add("1,2,3")).to be 6
end
end

17. Example
class Calc!
def add(input)!
return 0 if input.empty?!
numbers = input.split(/[,n]/)!
numbers.map!(&:to_i)!
sum = 0!
numbers.each do |num|!
sum += num!
end!
sum!
end!
end!
!

18. Example
describe Calc do
before do
@c = Calc.new
end
!
!
it "should be a class" do
@c.should be_an_instance_of(Calc)
end
it "should accept a string" do
@c.should_receive(:add).with("1").and_return(1)
expect(@c.add("1")).to be 1
end
it "should accept a string with 2 numbers" do
@c.should_receive(:add).with("1,2,3").and_return(6)
expect(@c.add("1,2,3")).to be 6
end
end

19. The Coding Dojo Book
!
•
•
group “Dojo” and how to lead a group
Has 23 katas with variations
http://www.kataclub.com is inspired by this book
I am attempting to index all the Katas I know about there!

20. Katas as a Group
•
Styles for groups:
•
working in pairs
•
look-at-me-coding
•
whole-group

21. Randori - a Group Format
•
Code is project with one computer
•
Everyone codes
•
Taking turns
•
Whiteboards to explain problem
•
if you have keyboard:
•
you decide what to type
•
or you ask for ideas