2014 05-14-pythoncodingdojo
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

2014 05-14-pythoncodingdojo

on

  • 62 views

 

Statistics

Views

Total Views
62
Views on SlideShare
62
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

2014 05-14-pythoncodingdojo Presentation Transcript

  • 1. Python Coding Dojo May 14th , 2014 PyUGAT
  • 2. Coding Dojo? Code! Learn! Have fun!
  • 3. Coding Dojo? ● Safe place, not work ● Our Goal: to learn ● Not our goal: to finish the task
  • 4. Practices ● Test-Driven Development ● Pair Programming
  • 5. Test-Driven Development Overview Analyse Problem Test List Guiding Test Red Declare & Name Arrange-Act-Assert Satisfy compiler Green Implement solution Fake it Start over Refactor Remove Fake Remove Code Smell (No new functionality) Note new test cases
  • 6. Test-Driven Development from nose.tools import * import fizzbuzz def test_1_returns_1():     result = fizzbuzz.fizzbuzz(1)     assert_equal(result, "1")
  • 7. Test-Driven Development def fizzbuzz(number):     return "1"
  • 8. Test-Driven Development […] def test_2_returns_2():     result = fizzbuzz.fizzbuzz(2)     assert_equal(result, "2")
  • 9. Test-Driven Development def fizzbuzz(number):     return str(number)
  • 10. Test-Driven Development […] def test_3_returns_Fizz():     result = fizzbuzz.fizzbuzz(3)     assert_equal(result, "Fizz")
  • 11. Test-Driven Development def fizzbuzz(number):     if number == 3:         return "Fizz"     return str(number)
  • 12. What will be the next test?
  • 13. Pair Programming ● Driver: types at the computer ● Navigator – Looks for: ● Tactical defects: Syntax errors, Typos, Calling the wrong method ● Strategic defects in the driver's work – Driver's implementation or design fails to accomplish its goal – Strategic, long-range thinker of the pair ● Effective Pair: Constantly discusses alternative approaches and solutions to the problem ● Dysfunctional Pair: Quiet navigator
  • 14. Kata: „Binary Chop“ Write a binary chop method that takes an integer search target and a sorted array of integers. It should return the integer index of the target in the array, or -1 if the target is not in the array. The signature will logically be: chop(int, array_of_int) -> int You can assume that the array has less than 100,000 elements. For the purposes of this Kata, time and memory performance are not issues (assuming the chop terminates before you get bored and kill it, and that you have enough RAM to run it).
  • 15. Randori ● 10 min introduction ● 10 min discussion ● 40 min working on the problem – 1 driver, 1 navigator – Every 5 min ● driver → audience ● navigator → driver ● audience (1 person) → navigator ● 5 min break ● 40 min working on the problem – Like before ● 15 min retrospective
  • 16. Randori in Pairs ● Coding – Split into pairs – Work on the Kata for 45 minutes – 5 minutes debriefing ● 5 minutes break ● Coding – Split into pairs – Work on the Kata for 45 minutes – 5 minutes debriefing ● 10 minutes retrospective
  • 17. Happy Coding!
  • 18. Retrospective ● Are you happy with the design of the code you ended up with? Should you have refactored it more often? ● What are the best aspects of the design of the code we've ended up with? ● Did we learn anything new? ● Did anything unexpected happen? ● What do we still need to practice more? ● What should we do differently in the next dojo? ● What will you do differently tomorrow in your production code?