Getting Betterthrough practice

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 formhttp://exercise.about.com/od/healthinjuries/a/olympictraining.htm

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!

Your Career is your Responsibility

It’s not your employers responsibility

says Uncle Bobbook: The Clean Coder

<start channelling UncleBob>

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>

Ways to Practice

• reading a book

• watch videos at confreaks / youtube

• going to and/or speaking to user group

• mentor someone

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

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)

Functional

• recursion, lists, reduce, map

• Tom Stuart video

• https://skillsmatter.com/skillscasts/1101-enumerators

Traditional TDD

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

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

Write it out on paper

• stepping away from the keyboard

• list every possible way

• sketch it or psuedo code

• then code it!

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

Nola’s interpretation• I’ve seen mocks use badly.

• Very Badly. #facepalm

• 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

shocking white slide of code next!!

Example of London Styleclass 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

Exampleclass 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!!

Exampledescribe 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

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!

Katas as a Group

• Styles for groups:

• working in pairs

• look-at-me-coding

• whole-group

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