0 comment

Docker automation for PHP Developers using Python


This posting will deal with using Docker on the developer desktop. I will not talk about deploying these containers to other stages of the track to production. Maybe this is a topic for a follow-up by me or by someone who is more apt with all things devops.

All this started when I realized, that docker-compose.yml needs an absolute path on the host for its shared volumes. This is OK but when you would like to have multiple development setups for multiple projects. What I wanted was a single config file to rule a complete set of Dockerfile and docker-compose.yml files. And a comandline tool to manage that environment without the need to juggle around with several other tools and numerous options and flags.

An intermediary state consisted of a Makefile with several shell scripts for all the stuff that was hard to do in Makefiles. It worked but was a bunch of files. I wanted something cleaner with more possibilities for the future and fewer helper files.

So here it is: a Python file to rule them all (sorry for the pun …) and build Dockerfile and docker-compose.yml from templates and a config.yml file when booting up the environment. The repository is here:

What you get

  • An Apache running PHP7.1 on http://localhost with document root (/var/www/html) as a shared volume in the www subdirectory
  • A MySQL database connected to that PHP container
  • A PHPMyAdmin listening on http://localhost:8080


  1. Check out from the Github repo above. Don’t mind the actual path to your environment. This will be determined and inserted into the docker-compose.yml file by the Python script.
  2. Install the required Python modules with
  3. Have a look at the templates in the templates subfolder
  4. Edit the configuration options in config.yml
  5. Boot the setup using
  6. Have a look at the running containers with

What doesn’t work yet

Using ./dockshell sshweb and ./dockshell sshsql to log into the running containers. Was not able to enter interactive mode. You will have to use:


  • ./dockshell clean removes all containers and images. And I mean all of them. This needs to be fixed!


0 comment

Graph libraries – D3.js

One of the best known visualization frameworks is D3.js. Written by Mike Bostock, the data visualization superstar about whom Edward Tufte said “that he will become one of the most important people for the future of data visualisation” (according to Wikipedia). And who am I to object to Edward Tufte?

So D3 is in its core an SVG handling library around which several so called layouts for different (actually a lot of) types of diagrams gather. One of them is the so called force-directed graph, which is exactly what we will use here.

How does it look?

This is a real physical simulation (although featuring some shortcuts for reduced calculation time) which means that the arrangement of the nodes when reloading the page is a new one every time and dragging around one node lets the others wobble around. One of the shortcuts is that the repulsive force only is active between nodes connected. So dangling ends can cross edges with the rest of the graph. Nevertheless playing around with the mesh can be fun for some time. The complete source code can be found in the GitHub-Mark-32px GitHub repository

How does it work?

Once again it all starts with including the libraries:

The we add some style for nodes and text:

Next we define some variables:

The first line defines width and height of the SVG element, the second line defines n as the number of iterations to be done (I’ll explain later) and the global variables force, svg and drag.

Next we need to define the nodes and edges or links. For the sake of simplicity I’ll do that once again inline. In a real application you would load the dataset in the background:

Then I wrapped up the whole generation and execution of the graph into a function called performGraph():

Lines 2 to 7 set up the force layout engine with some physical parameters, the width and height and an event handler for the ticks. Ticks are D3’s simulation steps. For every tick, a function is called and the positions of the elements are recalculated. We’ll discuss the tick function further down.

Then we define a drag event listener in line 8 to 10 binding its events to two functions called dragstart and dragend. More on those later. Lines 11 to 14 show how to manipulatie the DOM using D3 by adding an SVG element with some attributes to the body.

Lines 15 and 16 handle one of the (for me) most counterintuitive features of D3: we select DOM elements by class that aren’t yet there. Line 17 attaches the nodes and links datasets to the force layout. Line 18 kicks off the physical simulation, line 22 stops it. The for-loop in between counting down from 10000 (the n variable, you remember?) executes 10000 times the force.tick() function. We also could have started the simulation and let it run infinitely but this start-stop handling provides for a steady graph instead of one always wiggling around a bit.

Lines 23 to 44 define, what to do with the links by appending a g (for group) SVG element to the SVG canvas and adding line to the group. Lines 45 to 53 do something similar with the nodes adding a group and a transformation function. In lines 54 to 62 we add a AVG circle element using the nodecolor attribute from the nodes dataset. Lines 63 to 71 finally add the text label to the nodes. Line 72 eventually binds the nodes to the drag event object to allow for the dragging of nodes with a mouse.

Now we need to define all the helper functions bound to event listeners in code above. First the tick() function to do the simulation steps:

And the dragging functions:

The last thing to do: kick it to action by calling performGraph():

Why exactly did I put all the code into a function to call it in the end? In a real application you would have some additional GUI elements for example to switch on and of different types of nodes or labels etc. Every time this is done we need to recalculate the graph. Now this can be done with one function call.

0 comment

Graph libraries – Cytoscape.js with Cola.js

Now it’s time for my favourite graph visualization framework. As an introduction I cite from the Cytoscape website:

Cytoscape is an open source software platform for visualizing molecular interaction networks and biological pathways and integrating these networks with annotations, gene expression profiles and other state data.

Cytoscape.js as a side project is a JavaScript library designed to build graph theory related data evaluation and visualization applications on the web. It comes with some layout renderers but is open to other visualization libraries such as Cola.js. Cola is a constraint based layout library with some very interesting features. In this context, we will use it only as a layout engine for the graph.

How does it look?

When playing around with this graph you will probably notice two things:

  1. When dragging around a single node all the other nodes of the graph remain calm and don’t wiggle around like in most physical based layouts.
  2. When reloading this page you will always see the same arrangement of nodes. The graph is stable to reloads.

These two feature result from the way Cola.js renders the graph and are very useful for real world applications. While it’s big fun wobbling and dragging around nodes in a real application you would always like to see the same graph when reloading the same data. And manipulating the arrangement should not affect nodes not touched. The complete source code can be found in the GitHub-Mark-32px GitHub repository.

How does it work?

Once again we start by including the stuff needed. And this are the two libraries and an adaptor to use Cola.js from within Cytoscape.js:

The adaptor can also be found on GitHub.

The HTML body contains a div to render the graph into:

The remainder of the index.html file consists of a script:

Lines 2 to 7 define the nodes with their name/caption and colour. Lines 8 to 54 define the edges in a similar way. Lines 56 to 70 define the Cytoscape container and attach dynamic properties to the nodes and edges. Line 71 finally kicks off the layout rendering. Note: up to that last line we specified exactly no rendering or geometry information! By changing the name of the renderer from cola  to one of the built-ins ( circle  or cose  are fun to play with!) you can get a completely different outout.

As a last remark I strongly recommend to have a look at the graph theoretical and practical routines and algorithms the Cytoscape.js library has to offer.

0 comment

Graph libraries – Arbor.js

Arbor.js is written by Christian Swineheart from Samizdat Drafting Co. The documentation is concise even though the main page navigation as animated tree layout always drives me crazy :) The example I present here only depends on arbor.js and jQuery. Graph definition is for shortness and clarity done by calls to addNode  and addEdge  methods of the ParticleSystem renderer.

How does it look?

As you can see, the physical simulation is much more fluid and undamped than with Alchemy.js. I’m pretty much shure this can be changed to some degree with a different initialization of the particle system as described in the reference documentation. Once again, the complete source code, in this case consisting only of an index.html file, can be found in the GitHub-Mark-32px GitHub repository.

How does it work?

Once again in the header we start by loading the stuff needed:

arbor-tween.js is not really needed for this example as it allows gradual transitions in the data object of nodes and edges. Arbor.js by default renders its graph in a HTML5 canvas, in the body we need to define this:

The remainder of the file consists of a function defining and binding the renderer object to the canvas and constructing the graph:

Lines 2 to 73 define the Renderer, in detail:

  • get the HTML5 canvas (line 3)
  • grab its 2D context (line 4)
  • an init function for the particle system (lines 7 to 12)
  • a redraw function actually drawing the graph (lines 13 to 33) by iterating over all nodes and edges
  • defining a pretty basic mouse handling (lines 34 to 69)

In line 75 we get a particle system, set the rendering to the canvas in line 76 and define nodes (lines 76 to 81) and edges (lines 82 to 87). That’s pretty much all.

1 comment

Graph libraries – Alchemy.js

Alchemy.js is a library developed by graphAlchemist (site defunct). The documentation could be better and more detailed but it works. Like many other libraries it leverages other libraries to do “the basic stuff”. In this case it is it depends on:

Alchemy uses GraphJSON (similar to GeoJSON) as input format, which is quite nice but undocumented since the website doesn’t exist any more. Looks as if support for it ceded with the graphAlchemist web site …

How does it look?

Like all demos I’ll show it’s a fully functional mini demo, so you can drag the nodes around. I’ll present excerpts of the code to explain. The complete code can be found in a GitHub-Mark-32px GitHub repository.

How does it work?

Our example consists of an index.html file, a GraphJSON data file and the library stuff. In the index.html we first load the stuff needed:

The body contains a div to put the graph in and the include for the base library itself:

Finally there’s the code producing the graph:

As you can see, nearly everything is done in a configuration object. Line 2 defines the source of the GraphJSON file, lines 3 & 4 set the dimensions of the SVG element. The setting of nodeCaptionsOnByDefault  in line 6 switches on the display of the node titles. Otherwise they would only show up when hovering with the mouse. Lines 7 to 9 define a callback function defining what to display as a caption / title. Lines 10 to 15 define valid values for grouping edges and nodes. Nodes are grouped by the role attribute, edges by caption. Lines 16 to 37 define how these groups of edges and nodes should be formatted. There are other, more direct ways to style a graph in Alchemy.js but I wanted to show the (for me) most elegant way. Finally line 39 kicks off the rendering of the graph with the given configuration.

0 comment

Graph libraries – Introduction

This post starts a small series of articles, that will present some JavaScript graph plotting libraries and show how to draw more or less the same simple demo graph with these different libs.

What is a graph?

Graph theory is a mathematical discipline that studies networks of nodes and links or edges connecting them. Graphs are useful for many applications: social media networks, streets connecting cities, transfers connecting bank accounts or networks of people, addresses, bank accounts and cars connected via insurance claims and events. We’ll deal with some of those applications later on when discussing the application of network and graph paradigms to visualizing fraudulent actions.

Which libraries have I examined?

The internet is full, I mean literally FULL of libraries to display networked graphs. I had to choose some and discard others. First I decided to neglect commercial libraries that don’t have an open source edition. Then I stopped evaluating libs when I recognized that the documentation is too poor or functionality too limited to further investigate. So here is the list in alphabetical order:

Libraries I didn’t evaluate due to licensing constraints:

Libraries I gave up on:

  • Dracula Graph Library (Graph Dracula … you understand … haha)
    Needs a raphael.js renderer to display custom node shapes. Too much fuzz for a very short test.
  • sigma.js
    Poorly documented. Didn’t succeed to build a test candidate in short (!) time.

How did I test?

networkI always used the same test network. It consists of 6 nodes and 6 edges. Some edges are red and one node is green. The nodes are labelled “Node 1” to “Node 6”. Colouring and labelling is used to test how easy it is to insert some basic customization into the layout.

On the right side you can see a hand drawn (well not really handdrawn) picture of the demo network. The examples I present are fully functional, not screen shots and I will briefly go through the source code.


The first part for Alchemy.js can be found here.

The second post on Arbor.js is here.

The third part with Cytoscape.js and Cola.js is here.

The fourth part with D3 is here.


Automatische WordPress Updates ausschalten

Vielleicht ging es dem einen oder anderen so wie mir, als ich heute Mails von meinen WordPress Installationen bekam, die etwa so anfingen:

[Technologyscout] Deine Website wurde auf WordPress 3.8.1 aktualisiert

Ich war ein wenig überrascht und fand dann bei Frank Stachowitz eine Erklärung: das ist ein neues “Feature” von WordPress.

Blöd ist nur, daß man diese automatischen Updates nicht per Admin ausschalten kann, sondern dies per define() Statement in der wp-config.php tun muß. Der WordPress Codex sagt dazu, daß man generell 2 Möglichkeiten hat:

  1. Automatische Core Updates ausschalten bzw. auf minor version Updates beschränken. Von dieser Einstellung nicht betroffen sind dann Plugins, Themes und Sprachdateien.
  2. Automatische Updates generell ausschalten. Das betrifft dann Updates der WordPress-Software selbst sowie Plugins, Themes und Sprachdateien.

Wer sich also wie ich generell ungern in seine laufende Software reinfingern läßt, schreibt irgendwo in die wp-config.php folgende Zeile:


Wer nur Softwareupdates manuell machen möchte, das Beiwerk aber automatisch updaten lassen will, der nutzt:

define(‘WP_AUTO_UPDATE_CORE’, false);

Und wer Softwareupdates bei Unterversionsnummern erlauben möchte, der nimmt:

define( ‘WP_AUTO_UPDATE_CORE’, ‘minor’ );

Man kann in beiden Fällen auch mit Filtern arbeiten, die dann in manchen Fällen eine feinere Abstufung erlauben, aber das kann man dann im Codex nachlesen. Vielleicht hilft dieser Text hier aber schon dem einen oder anderen, eventuelle Unklarheiten zu beseitigen.

0 comment

Webshop Entwicklung

Nachdem es in der letzten Zeit ja hier etwas “off-topic” zuging, wird es in der kommenden Zeit wieder vermehrt Artikel zum Thema Webdevelopment und speziell Oxid Webshops geben.

Zudem bin ich der Meinung, daß gerade hier der Westzipfel / Aachen ja eher etwas unterrepräsentiert ist, was Oxid-Knowhow bzw. seine Sichtbarkeit betrifft. Hinzu kommt, daß wir gerade ein tolles eigenes Oxid-Projekt in der Entwicklung haben, über das ich dann quasi im Laufe der Entwicklung berichten kann.

Den Anfang wird ein Artikel zur unaufwändigen Erstellung eines XML-Feeds für die Google Produktsuche machen. Ihr dürft gespannt sein! Natürlich freue ich mich auch auf Fragen, zu denen ich dann evtl. auch Postings schreiben kann. Wer also Fragen oder Ideen hat, möchte sich bitte melden :)

0 comment

Mac App für Entwickler: qPHP

Heute möchte ich kurz eine kleine App meines Kollegen Dean Tomasevic vorstellen, die eine fantastische Hilfe bei der täglichen Arbeit mit PHP sein kann. qPHP ist ein kleines Tool, daß man im App Store erwerben kann.


Das Tool besteht aus einem Fenster mit 2 Bereichen, einem Input-Feld in der oberen Hälfte und einem Output unten, dieser mit zwei Tabs für eine HTML gerenderte Ausgabe und als reiner Konsolentext.


Zusätzlich gibt es natürlich einen “Execute” Knopf, der den Code ausführt und – besonders interessant – ein Dropdown zur Auswahl einer PHP Version. Momentan werden die Versionen PHP 5.3, 5.4 und 5.5 zur Verfügung gestellt. Das spannende ist: man muß die PHP Interpreter nicht selbst installieren, die kommen mit der App!

Anders als bei der App “Quick Programming” muß man keine PHP Processing Instructions (<?php und ?>) mit angeben, das weiß die App von selbst (was soll man auch sonst eingeben, wenn nicht PHP Code?). Man kann das aber doch machen, dann stellt die App das fest und ergänzt den Quellcode nicht intern um die Instructions. Dieser Automatismus ist sinnvoll, man kann nämlich auch mittels CMD-O ein beliebiges PHP-File öffnen und in der App ausführen. Und die enthalten ja nun meistens die PIs.

Sehr schön ist auch, daß das App-Fenster fast beliebig in Größe und Aufteilung zwischen den beiden Bereichen variierbar ist. Klingt normal, kann aber nicht jeder.

Alles in allen eine klare Kaufempfehlung für PHP Entwickler auf dem Mac!

1 comment

Ist ein CMS ohne Datenbank kein CMS?

Vor einiger Zeit entspann sich eine kurze Diskussion zwischen Christian Aust und mir auf Twitter, die in einer Aussage von mir gipfelte, daß ich Content Management Systeme ohne Datenbank für nicht gut halte. Nun hat er ein Posting dazu geschrieben. Das möchte ich kurz beantworten.

  • Keine Datenbank, somit keine Migration: Das ist so nicht richtig. Migrationen entstehen, wenn sich das Datenmodell ändert. Auch Content auf der Platte in Textdateien hat ein inhärentes Datenmodell. Wenn sich das ändert, muß man alle Dateien einzeln durchgehen und umbauen. Das halte ich für schwieriger. Zudem existieren für alle CMSse, die ich kenne, Updater, die sowas im Hintergrund für mich erledigen.
  • Das Produktivsystem ist nicht dynamisch schreibbar: verstehe ich nicht ganz. Ist das Verzeichnis mit dem Content-Baum read-only? Wenn ich einen Hacker auf dem Rechner habe (durch eine OS Sicherheitslücke), dann ist das völlig egal. Wenn es sich um eine CMS Sicherheitslücke handelt, ist es auch egal, weil das Markdown der Contentdateien ja noch dynamisch durch das Ruby CMS müssen. Vielleicht verstehe ich das Argument auch einfach noch nicht.
  • Dateiverwaltung geschieht über Dateitools und Versionsmanagement: WordPress ist ein denkbar schlechtes Beispiel für gute Softwarearchitektur bzw. es ist ein brilliantes Beispiel dafür, was man alles nicht machen soll. Wie z.B. URLs oder Pfade der Installation in die Datenbank schreiben. Und das auch noch in serialisierten PHP Arrays. Ansonsten ist die bitemporale Datenhaltung in SQL Datenbanken ein seit langem gelöstes Problem.
  • Workflow-Management über git sign off et al.: Was daran jetzt leichter sein soll als den Workflow eines ausgewachsenen CMS zu nutzen weiß ich nicht. Gute CMSse bieten dieses Feature von Hause aus an.

Nesta CMS verwaltet seinen Content, wie ich auf der Webseite gelesen habe, in Markdown Dateien in einem separaten Verzeichnisbaum. Dieser Baum bildet dann nachher die URL-Pfade online ab. Ich werde wohl nie verstehen, warum man eine Markup-Sprache (HTML) durch eine andere (Markdown) ersetzt. Im Zweifelsfall stehen mir diese Dinger im Weg. Das Argument, daß ja nur ein bestimmtes erlaubtes Subset von HTML aus der anderen Markupsprache in HTML übersetzt wird und damit für mehr Sicherheit gesorgt wird ist ja auch nur ein gewisses Scheinargument. Das steht und fällt mit der Güte des Parsers.

Für größere Unternehmen eigent sich so ein filebasiertes CMS eher nicht, weil man hier z.T. zeitgleiche Schreibzugriffe auf einzelne Dateien hat. Das funktioniert eher schlecht. Beim Lesen des Contents gehe ich mal davon aus, daß hier der Filesystem Cache Kollisionen verhindert bzw. Zugriffe beschleunigt.
Es gibt ja auch noch CMSse, die allen Content in einer Datei speichern. Die sind dann auch noch beim Lesezugriff langsam.
Mein Fazit: Nicht jedes CMS ist für alles und jeden geeignet. Da spielen faktische Rahmenparameter genau so eine Rolle wie der persönliche Gusto des Benutzers. An einer Evaluation verschiedener Kandidaten führt wohl kein Weg vorbei.