artodeto's blog about coding, politics and the world

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)

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

Arne Blankerts, Stefan Priebsch - High-Performance Websites

This talk contains information about architecture.

Classical Architecture

When have done this for quite a while.

Browser->WebServer->PHP-Database

This works best in the past. General solution was to add more hardware and that leads to more errors.

• monolithic architecture
• normalized data (in database)
• pull-principle (browser is build per request)
• full page cache is bad
• edge site include (for varnish/ESI) is also not the best solution

We are fast when:

• no real workload per request
• everything from memory
• denomalized data
• snippets

How Often Does Data Change (From Rare To Often)?

Based on the example of a shop system.

• catalog
• product information
• price
• availability

Who Changes Data?

• editor
• product manager
• receipt of goods / outgoing goods

New Architecture (CQRS-Architecture)

• images and static content is deliverd by static content webserver
• only dynamic part is done by php
• snippets are deliverd, not full pages

PHP->Key-Value-Store->Backend-Process->Database
or
PHP->Web-Service->Database

Benefit of key-value-store (for example redis) is, that the database itself can die and the only thing that happens is, that the entries are becoming obsolete.

But What About Filternavigation?

Use a searchengine that returns simple a collection of product keys. Use this product keys and ask the key value store to fetch product data.

But What About Personalization?

• use snippets with variables and default values
• fetch this snippet in the key value store
• thanks to "time to death" feature provided by many key-value-stores, you can easily define "special offers" per day and so on

Nice meetup, incredible how many people are attending already.