Skip to content

PHP UserGroup Hamburg - 2016-02-09 - Putting down the leadtime

Following some notes about my the last php usergroup meetup.

By Judith Andresen

  • what is the leadtime?
    • time between adding the ticket and releasing it as a feature
  • what is a cycletime?
    • time between someone has an idea and releaseing it as a feature
  • we are currently in a time of digital transformation to the "first mover"
    • first idea try/test is the one who owns the bigges marked share
    • try to not be perfect
    • remove bottlenecks
    • try to scale vertical (microservice, duplicated data)
      • one team and service per business value/topic
        • search (including frontend, backend, customer data etc.)
        • product page
      • "community of practice" is a team (per vertical cut/team) that try
        • to keep the big architecture picture in mind
        • to share knowledge, approach and libraries
    • try to add a decision-maker into the team (extend the team in the value chain)
    • try to bring people together, also on an emotional level (increase the "we" feeling)
    • you can argue always with a decreased leadtime / small time to market
  • typical "facts" against
    • we have never done that this way
    • my discipline is better, information silos, no talk between departments (typically between 20 and 80 peoples)
    • there is no "we"
  • how?
    • talk to each other
    • major goal: deliver fast
    • create room for improvment or options
      • time
      • people
      • space/room

PHP UserGroup Hamburg - 2016-02-09 - Dockerizing PHP Applications

Following some notes about my the last php usergroup meetup.

By Sebastian Heuer

  • docker is not one tool but a whole ecosystem
    • machine (provisioning)
    • swarm (clustering and container scheduling)
    • compose (multi container application)
    • registry (image distribution)
    • engine (the container)
    • ktematic (gui)
  • pretty small compared to virtual box/full virtual machines
  • updating means, building a new container
  • theoretically, you can use all the images from the hub
    • always ask yourself if you want to use them in production
      • are they maintained
      • how secure are they
  • docker compose
    • builds and pulls images
    • runs containers
    • enables networking between containers
    • aggregates STDOUT and STDERR output

example Dockerfile

FROM php:7.0.2-fpm

RUN docker-php-ext-install pdo pdo_mysql

COPY php/php.ini /usr/local/etc/php/
# copy the content of the source code into the image
# you can ship this code version now
COPY . /srv/meetup-service

# the date in the container is not persistent
# if ypu change something in it, it will bill lost afterwards

CMD ["php-fpm"]

example docker-compose.yml

webserver:
  build: ./nginx    #path to the docker file and configuration etc
  links:
    - application
  ports:
    - "80:80"   #from port 80 to port 80
  volumes_from:
    - application
application:
  build: ./meetup-service   #your project
  links:
    - database
  ports:
    - "9000:9000"
  volumes:
    - ./meetup-service:/srv/meetup-service  #mounting local source code into the container
  environment:
    - MYSQL_HOST=database
    - MYSQL_DATABASE=application
    - MYSQL_USER=root
    - MYSQL_PASSWORD=parola
database:
  image: mysql:5.7  #no build path, instead an image is used
  volumes:
    - /var/lib/mysql
  ports:
    - "3306:3306"
  environment:
    - MYSQL_ROOT_PASSWORD=docker
    - MYSQL_DATABASE=app

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

Social Human Architecture for Beginners and the Flip Side of Dependency Injection - PHPUGHH

Where

Social Human Architecture for Beginners

General

By Sebastian Schürmann (@sschuermann) (scrum master)
PHP Benelux
Works at mytaxi.de

People

  • introversion vs extroversion (thinking is internal or externalized)
  • nobody is one at all (just introvert for thinking or feeling)
  • talk to you team about it (try to express everybody on a scale to get better understanding)
  • take a look to "Maslows hierarchy of needs"
    • self actualization
    • esteem
    • love/belonging
    • safety
    • physiological
    • internet ;-)
  • try to create your own needs of hierarchy
  • use "non-violent communication" (Marshall Rosenberg)
    • observation (just the facts)
    • feelings (just feeling good or bad won't cut it, try to express yourself)
    • needs (we all have them, feeling bad? need is not fulfilled)
    • honest request

Groups

  • psychology of programming by Gerald Weinberg
  • egoless programming
  • stages of group development
    • forming
    • storming
    • norming
    • performing
    • storming [...]

Motivation

  • engagement can be reached by
    • autonomy
    • mastery
    • purpose
  • let people get into the flow state
  • try a fed-ex day (people can do what they want)

The Flip Side of Dependency Injection

General

Do Not

  • do not add to much dependecies (thing is doing to much)
  • do not hide dependencies by using a container (it's like throwing in "the config")

Do

  • all dependencies must be in code
  • separate object creation from usage
  • there must be the ability to choose the actual implementation on runtime

How to Get There

  • use a factory with explicite API (instead of "get('Foo')", do "getFoo()")
  • avoid injecting factories, try to use locators (locators are returning "FooInterface" and using factories for instance creation)