Article
0 comment

Docker based dev environment with PHP 7, MariaDB, phpMyAdmin, Mailhog & ELK stack

Docker can be used as a flexible development environment for (web) applications. With docker-compose you can add up several services to a complete scenario. Here I would like to present a new setup that contains a lot of things to make a developers life more comfortable, notably:

If you don’t need all these components, you always can disable whatever you’re not going to use. Your application will reside in the html subdirectory, the MySQL/MariaDB db files will be in the mysql directory so nothing is lost when you shut down the services.

If you need something else (PostgreSQL e.g.) please let me know and I will add it. Have fun!

Article
0 comment

Run Oxid CE V6 locally using Docker and docker-compose

Recently the public availability of Oxid eShop V6.0.0 was announced. And it finally runs with PHP7 and is a major step towards a modern and comfortable web shop.

If you would like to test it locally or develop with it there are many options. Some time ago another one, flexible and versatile, opened: Docker.

In this GitHub repository I assembled an environment with:

  • Apache webserver with PHP 7.1 and all extensions needed (and xdebug)
  • MariaDB
  • phpMyAdmin
  • ELK stack to analyse and show apache log files

If you encounter any problems or bugs please file an issue with GitHub. I’m here and on Twitter to answer any question you might have. Have fun!

Article
0 comment

How to install dependencies from a requirements.txt file with conda

Just a little reminder: pip has this very useful option to install a bunch of packages from a single text file mostly called requirements.txt. Anaconda’s command line tool conda doesn’t support this option directly. It does support reading the package names from a file using the –yes and –file option

but that does not automatically install all the dependencies. To do this, we need to iterate over the file and install each package in “single package mode”:

Thanks to Luis Capelo for this snippet which I use to install dependencies in a dockerized instance of Anaconda / Jupyter (more on that in a later post).

Article
0 comment

Docker automation for PHP Developers using Python

Introduction

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: https://github.com/vgoebbels/docker-php7

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

Usage

  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:

Caveats

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

 

Article
1 comment

Note to self: bash path hashing /o\

Did you ever stumble across something like this:

Yes, this is strange, isn’t it? The PATH variable is set in the correct order (this is why ‘which’ finds the local Python). Googling about this behavior at first didn’t bring up any solution. But then I came across this now closed question on Stackoverflow.

So once you know what you are looking for Google reveals lots and lots of people having trouble with path hashing. Now, my solution was quite simple:

 

Article
0 comment

Note to self: Allow to run applications from unverified sources on MacOS X Sierra 10.12

Every now and then I stumble across some more or less cool application I install on my Mac. Some of them were built by authors not verified by Apple. Whenever this happens you see a box popping up telling you that you can’t run that app. You can go to the security / Gatekeeper pref pane and allow for this app for this time to run but the option just to allow all unverified apps to start is gone since 10.11 I suppose.

Since Apple very seldom removes a functionality from a new release there is a way to switch to allowing those apps from the command line. I found a solution on the german Mac site MacGadget:

This works just like to old option setting. HTH.

Article
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.

Article
0 comment

Innovation means breaking the rules

6264574707_47f374a312_oToday I paged through a book by Martin Gaedt, called “Rock your idea”. Despite the  english title the book is written in German. One of the first and central ideas presented there was:

Innovation means to break the rules.

I’ve been scientific and innovation enabler for several projects and companies now and this is nearly all you need to know about injecting new ideas or technology into companies.

If you want to work out a totally different and optimal solution for a given  problem or even want to create a new area of business, you have to break the rules.

  • The rules defining what is possible. Maybe someone just invented the technology needed to build your idea. You might at the moment not know that.
  • The rules what we think customers need or want. Ever heard that argument “None of our customers asked for that! Why should we build that?”?.
  • The rules of the existing business. Ever heard that your idea doesn’t fit into the portfolio of the company? WHAT THE HECK? The portfolio is where the money is, for God’s sake!
  • And sometimes even the rules of hierarchy. Having an innovator working ‘at a short leash’ often means preventing innovation. Sometimes managerial control is the worst you can do to harm your company.

So to reformulate the negative arguments to positive actionable items:

  • When having a new idea, don’t instantly think about existing technology to build it. When you need it, there will be a solution. There always was one when I needed it. Finding technical solutions is the job of people like me.
  • When you don’t know if a customers will buy into your idea, TALK TO THEM. Sometimes you will get a piloting customer aboard for an idea that is nothing more than that: an idea. Sometimes you will have to invest a small amount of money and time into a prototype or mockup to win a customers interest.
  • If you only look for ideas fitting into an existing portfolio, I’m sorry to tell you, that your company will not have any chances to survive a future disruptive change in its very own field of business. There will be someone else having a similar idea and with no reluctance to realize it, portfolio or not.
  • If you have people working for you on innovative ideas, trust them. At least a bit further than you feel comfortable with. Micromanaging people is a great way to let them look for another company that offers a broader field of work. If you expect your researchers to follow working instructions to the point you’re exactly missing the point.
Article
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.

Article
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.