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

Introduction Into Docker and Continous Delivery with Docker - Docker Usergroup Hamburg 09.06.2014

Docker UserGroup Hamburg

Introduction Docker

General

By Johannes Ziemke from docker

What is Docker

  • version 1.0 released a few hours ago - api stable (a bit)
  • written in go
  • build, packs and ships applications as lightweight containers
  • build once an run almost everywhere (since kernel 3.8.*)
  • rewrite of docCloud PaaS code

Benefits

  • start always from clean slate
  • spawn up complete test infrastructures in seconds
  • run your code against multiple versions easily
  • easy up setup of software environment
  • distribute complex setups as self-contained containers
  • build own infrastructure
  • easy ups deployment per day
  • scaling and mantaining of infrastructure (state convergence, manage everything)
  • helps you to solve managing complexity
    • similar problems
      • modules, classes, plugins
      • human communication: named concepts like car, cat or container
      • shipping goods: intermodal containers
    • solution: create an abstraction
      • does not matter what is in the container nor where it runs
      • clear separation of concerns (reduce communication between developers and ops)
      • developer can take care about used libraries, packagemanager, ...
      • op can take care about the system (alos resource planning and monitoring)
  • running commandos on top of:
    • immutable, shipable, layered images (defined by dockerfile, built by builder and pushed/pulled to registry)
    • copy-on-write storage on top (provides writeable layer on top of read only images to persists changes done by running container)
      • aufs
      • btrfs
      • devicemapper
    • isolated environment
      • using kernal features
        • namespaces (isolation by scoping, available: pid, mnt, net, uts, jpc, user)
        • cgroups (limit, accound and isolated general devices, cou, memory, ...)
        • future (solaris zones ...)
    • via RESTish API
    • missing pieces
      • docker can not address service discovery or dynamic scheduling
      • projects to close the gap
        • openstack
        • coreOs
        • mesos + marathon
        • flynn.io

Demotime

  • --privileged - can break out of container but control host
  • images are read only and creating a container on each start
  • docker commit - creates new image out of running container
  • use boot2docker

Continous Delivery with Docker

By Tobias Schwab from Dynport GmbH

Philosophie

  • continous delivery
  • canarien releases
  • "never touch running system", create a new one when something has to change
  • immutable releases (once created, never change it)

Why They used Docker

  • privacy concerns, aws not an option
  • hoster they could not pick
  • unreliable hoster API
  • flash based structure management
  • limited capacity
  • they are the biggest customer

Learnings

  • image based deployments -> use dockerfiles (do not add dockerfile generators on top)
  • use syslog and rsyslog to log out of the container
  • >>CMD ["/sbin/init"]<< to start debian based image
  • caching
  • configuration management
    • store configuration in environment
    • dependency injected with start of container (use same container for testing, stageing, testing ...)
    • logfiles and data outside of the container
  • do not
    • full blown vm (best case, one service per container)
    • ssh deamon inside containers
    • syslog deamon inside containters (sometimes needed)
    • user management (everything can run as root)
    • chef/puppet makes caching useles
    • rely on external services (github, gem page)
  • build management tools
    • bundler, pip, carton, composer, ...
    • problem is, they are slow on "clean slate"
    • ways to solve
      • add mainifest (like composer.lock) before code and use cached build files
      • pre-bundles base images
  • multi host
    • image distribution via docker registry
    • weighted load balancing via HAProxy
    • SSL termination via HAProxy (container exists by Johannes Ziemke)
  • load balancing
    • HAProxy
    • pool configuration stored in redis/etcd
    • configuration update
      • created
      • uploaded via ssh to host
      • verify configuration
      • replace configuration (old with new)
      • reload configuration
  • logging
    • putting container id, revision of image (host, code, request) via rsyslog out of the container
  • metrics
    • openTSDB
      • distributed, scalable time series database
      • hbase
      • tags/diminsions
      • from syslog via udp
      • rickshaw.js for graphs
      • compare status cudes, counts and times between actions of two revisions
  • benefits (reduces)
    • external dependencies
    • "did work on my machine"
    • unused cpu cycles
    • number of hosts
    • feedback times (number of deploys per day)
    • time to get new host online
    • hosts are more flexible
    • controlled revision change (controlled on each host)
    • faster build
Translate to de es fr it pt ja

AwareInterface, Graylog2 with Logstash and Contributing to the new PHPUGHH website - PHP UserGroup

link to meetup event.

Where

Jimdo
Stresemannstraße 375
Hamburg

AwareInterface By Stev Leibelt

  • reminder of dependency injection
  • increases the readability of a class structure
  • defined way of inject object/typ
  • interface injection could lead to a project based rule to distinguish between mandatory and optional dependencies
  • slides available hear.

Logstash and Graylog2 by Alexander Bernhardt

Simple log all.

questions to the log

  • what happens on the other server?
  • what happens when and on what circumstance?
  • what are you logging?

how to solve this?

By using Logstash, Redis and ElasicSearch, aggregate all and push all to a graylog2.

  • graylog can do some kind of monitoring, known as streams.
  • you can add a alert method to each stream.
  • nagios can listen to a graylog stream.
  • could not replace statsd or graphite

Talk And Call For PHPUGHH Website By Stephan Vock And Ole Michaelis

  • two Pages for one user group, which one to choose?
  • the usergroup decides to use the new page.
  • you need to have installed jekyll, rake or use the vagrant box
  • directory structure
    • each speaker should pull his own talk below "talks"

How To Contribute

  • fork repository
  • git checkout -b feature/foo
  • do the changes
  • git commit
  • pull request to the main repository
  • github.io builds new page on its own
  • git remote add upstream git@github.com:phpughh/phpughh.github.com
  • git fetch upstream
  • git merge upstream/master
  • git push
  • issues are available
  • enhancement issues is the roadmap
  • open issues if needed
  • links available as ticket
  • take a look to the bephpug (github)
Translate to de es fr it pt ja

Next Level DevOps And Softwarearchitecture Of A Modern Onlinegame - PHPUserGroup Meetup

Mindworks
Jarrestraße 42A
Hamburg

Next Level DevOps By Ole Michaelis

Preliminary Consideration

  • infrastructure is created by feature (but without clean up or cleaning things up)
  • did a practical training round in admin team for half a year

What Is DevOps?

  • you build it, you run it (until it goes offline)
  • monitor it, automate it, measure/metering it
  • build small tools and services to form an api

How Became A DevOp?

  • extend your development skills
  • learn and do refactoring
  • learn the shell
  • learn the operation system
  • pull deployment with deployment hooks

Softwarearchitecture Of A Modern Onlinegame By Tobias Rojahn

Preliminary Consideration/Requirements

  • crossplattform (mobile and web)
  • realtime game (fast information about status changes)
  • multiplayer (user can influence each other)

Architecture

  • user (request websocket from web server)
  • NodeJS (handles websocket connection to redis and global redis)
  • redis (message queue with push and pull)
  • php worker (long living php process, asks webservices or database, are forkable by using php forking mechanism)
  • if something is calculated by the php worker, the message is pushed in the global redis

The PHP Worker

  • long living workers
  • worker is observing the queue (and event handling) and is pushing the message to the dispatcher
  • each message has a type to push to the right controller
  • dispatcher is using the right controller (with a bunch of internal to external mapping and nearly zero logic)
  • controller is pushing the message to the right domain service (using the right domain objects and/or repositories)
  • controller is working with multiple db views
  • domain service can also call the event dispatcher to trigger other systems (not core systems)

Deamon

  • only creates messages
  • just time controlled game events

Cronjob

  • only creates messages

NodeJS

  • socket (via socket io) replaces session
  • add additional data (with indexes to gain speed) to the socket (via message queues from php)
  • node to php: send all data
  • php to node: a combination of data to all connected sockets
  • forwarding of fitting messages (with removing of internal datas)

Testing

  • API-Tests
    • description
    • ingoing message (test data)
    • outgoing message (expectations)
  • based on fitrues
  • only php layer
  • rollback on each test
Translate to de es fr it pt ja