artodeto's blog about coding, politics and the world

Your owncloud is a bit slow, you are using uberspace and you want to speed it up easily?
Easy solution is to use redis.
The compressed howto is down below. It is taken from the uberspace wiki and a privat blog entry.

test -d ~/service || uberspace-setup-svscan
uberspace-setup-redis
svc -du ~/service/redis

#to prevent or fix the following error "Missing memcache class \OC\Memcache\Redis for local cache"
uberspace-install-pecl redis

    //...
    //begin of redis configuration
    'memcache.local' => '\OC\Memcache\Redis',
    'redis' => array(
        'host'      => '/home//.redis/sock',
        'port'      => 0,
        'timeout'   => 0.0 
    )
    //end of redis configuration
    //...

The following lines are loud thoughts so far. I will give it a try and implement a fitting module for that. But so far, it is really just an idea.

You started your zend framework 2 translation by using the official translation guide for zend framework 2 and it was running fine with some words.
But then, you started working agile, using git flow and doing this by using multiple branches. It turned out that you will get a lot of merge conflicts (also on git) with your translation files if something had changed on your develop branch and on your feature branch. This results in high maintenance costs.

So what to do?
Here is my basic idea. Decouple the translation file from your code.

• First of all, you want to shift from file based to database based translation.
• After that, you reduce the usage of the database and add caching

Shift from file based to database based translation

• Create a database with the name like "translation"
• Inside this database, create a table called "keys" with the columns "id", "key_name" (or "name") and "created_at"
• Inside this database, create as many "language" tables as you want
• Each "language" table has the following columns "id", "key_id", "key_value" (or "value") and "created_at"
• After that, create a basic import that inserts all names in the table "keys" and all values in the fitting "language" table
• Next, you have to create an "translation adminstration" frontend to maintain the existing "translation keys" with its fitting "translation values" according to the right language.
• Finally, you have to overwrite the existing view helper with your own, database driven, one

Reduce the usage of the database and add caching

• setup redis in zf 2
• Setup the zf 2 redis cache adapter
• Inject the caching adapter in your translation view helper

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