Skip to content

Apigility and Pair Programming - PHPUGHH

PHPUGHH

Apigility by Ralf Eggert

Whats the problem?

  • new api in two hours
  • do rapid prototyping

In a nutshell

  • create a RESTful web services quick
  • create a rpc web service
  • supports versioning per url or negotiation (content type)
  • returns JSON and HAL JSON out of the box
  • authentication (database, code based, other)
  • api documentation
  • data validation (zend filtering)
  • supports deployment
  • modular based

Example

  • databased rest service
  • see slides for steps
  • good for easy stuff or complex stuff
  • good for rapid prototyping of see how the modules are working

To pair or not to pair by Sebastian Schürmann

About Sebastian

  • freelancer developer, coach, trainer
  • first contact to xp in 2005
  • scrum since 2008
  • loves open source
  • blog
  • mail

@s0enke

  • reduce bus factor
  • improve teamwork
  • improve learning

Pair Programming

Prefrace

  • pair programming illuminated (book)
  • specification by examples (book)
  • workshop

Critics

  • two programmers doing the work of one

Thesis

  • working alone, undistrubed is good
  • talking is disturbance which is bad

Theory

  • two persons (comes from rally driver)
    • driver (with the keyboard, focused to the current problem)
    • navigator (looking more at the whole concept)
  • switching roles regulary

Why

  • less bugs
  • faster in development (problem solving)
  • continous knowledge exchange
  • tightest feedback loop you can get in programming (even unit tests take longer)
  • P (plan), D (do), C (check), A (act) - loop
  • communication
  • simplicity (doing simple things, because two people have to understand)
  • feedback
  • respect
  • courage
  • bring back fun into work

Principles

  • feedback
  • embracing change (also the guy which code is change would became less grumpy)
  • assuming simplicity
  • seven synergies
  • pair pressure (chance they get interrupted is become lower)
  • pair negotiation
  • pair courage
  • pair review
  • pair debugging
  • pair learning
  • pair t(h)rust

Seven Habits of Effective Pair Programmers

  • take breaks (five minute breaks after 30 minutes)
    • take a look at "pomodoros" (5 up to 7 pomodoros is a full day work)
  • practice humility
  • be confident
  • communicate
  • listen
  • be a teamplayer
  • compromise vs standing firm
  • introverts vs extraverts / introversion vs extraversion
  • skill
    • shu-beginner (repeat presented action)
    • ha-intermediate (start break the rules/make innovations)
    • ri-expert (do not care about the rules)
    • do "shu" and "shu" - easy up starting into things
    • do "shu" and "ha" - create another master
    • do "shu" and "ri" - kickstart the shu
    • do "ha" and "ha" - biggest bang for the buck
    • do "ha" and "ri" - create another expert
    • do "ri" and "ri" - solve big problems

Type of Pairs

  • everybody pairs with everybody once in a time - good for knowledge sharing
  • pair hinging - do a user story together
  • test first pairing - implement, make the test red, switch and replay
  • stakeholder pairing - explain the stakeholder your code or the flow
  • newbie pairing - pair a newbie to a experienced one and finish a user story
  • pair bugfixing
  • pair release
  • write userstories/requirements as pairs
  • coding dojos - navigator and driver, audience can give feedback

To The Critics

  • knowledge iceberg (small explicit, tacit is the big part)
  • bug fixing cost (small: requirements, design, code, test, productiom :big)
  • flow state is established easily
  • groupflow
  • teamwork

Translate to de es fr it pt ja

work - pair programming

What a session, my team and obviously i finished a pair programming task and it was such a joy to work that way. It feels like a race against each other but you are absolutely happy when you crossed the finish line as team!

A great fun, but as on every race, you are a bit drained when you finished ;-).

And by the way, you are feeling like "going to swim without life jacket" when you commit your code without a unittest so that a teammate can work and test with the code :-D.

Translate to de es fr it pt ja