Article
2013-04-09
1 comment
by Volker

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.

Article
2013-01-23
0 comment
by Volker

Singer-Songwriter Developer

Ich muß gestehen, mit den meisten Singer-Songwritern habe ich ein Problem. Diese “ich brauche nur mich und meine Gitaharre!” Einstellung führt meines Erachtens oft zu dürftigen Resultaten. In einer sehr hitzigen Diskussion gestern fiel mir auf, daß es eine ähnliche Einstellung bei Entwicklern gibt. Gestern führte meine Nachfrage nach MacOS TextEdit auf Twitter innerhalb 2 Sätzen zur Unterstellung mittelschweren Trolltums.

Wenn ich einen Schritt zurück trete und finde ich persönlich 3 historische Phasen:

  • Ganz früher nutzte man die Tool Chain, die das jeweilige System bot.
  • Dann kam die Zeit, als es cool wurde, möglichst komplexe Tools zu verwenden, quasi ein digitales Gear Acquisition Syndrome. Die großen IDEs stammen fast alle aus dieser Epoche.
  • Momentan beobachte ich einen Trend, daß man auf möglichst primitive, meist im Lieferumfang der jeweils benutzten Plattform enthaltene Tools setzt, um relativ komplexe Aufgaben zu lösen.

Während so an und für sich gegen keinen der Trends etwas zu sagen ist (soll doch jeder die Tools nutzen, mit denen er produktiv ist), geht die eigene Einstellung bei IT technisch vorbelasteten Zeitgenossen oft mit einer sehr speziellen Form des Egozentrismus einher, der postuliert, daß der eigene Weg der einzig wahre ist. Man suhlt sich quasi in der Freude über die eigene Askese.

Ein Gutes hatte das Gespräch gestern: ich schreibe ein Posting drüber und denke noch mal drüber nach … nur in der anderen Reihenfolge. Ich plädiere hiermit für mehr Selbstreflexion!

Article
2012-03-14
0 comment
by Volker

Why you should not deploy web applications with unix packaging tools

Packaging and deploying web applications, e.g. PHP apps, can be a very tough topic. One way to deal with automatic deployment and dependencies is to use the packaging tools your unix server supplies, e.g. debian *.deb packages. This approach has indisputable benefits:

  • it manages dependencies
  • it’s possible to manage the deployment process on several servers automatically
  • there is a complete existing infrastructure for this task

But (you knew that would come, didn’t you?): packaging systems like the one used on debian are targeted to control that the package is installed in exactly one version (certainly not always, we’ll come to that later on) in one defined place. Igf we use multiple versions of the same software, it’s version number will define where they will be installed. You get a version tree like:

/usr/local/lib/…
…/applib-1.1/
…/applib-1.2/
etc.

Most system packaging tools also allow you to specify a prefix where to install the package. But altogether its a special tool for a special task.
Using it for web application deployment looks like the “if all you know is a hammer, every task looks like a nail” paradigm. You can accomplish the tasks needed but you have to modify the standard processes very much.
For example I would like to be able to install exactly the same software twice on exactly the same machine. And yes I absolutely definitely want to have two times the same version of the code in different locations. Here the notion of the packaging systems paradigm of a “system” as a whole server and not a virtual host or any other subdivision of a system is in the way.
I prefer to use build systems like phing, ant or make to wrap up things. Especially phing in combination with DbDeploy is a very comfortable way to do things you don’t want to handle manually in the PHP universe.

Article
2011-11-26
0 comment
by Volker

Dereferencing deeply nested arrays with array_reduce

Sometimes you need to grab a value from a deeply nested array and you get a path description to that value as a string. For example you get a path as

$path = “A.B.C.D.X”;

which refers to a value in an array like this:

$param[‘A’][‘B’][‘C’][‘D’][‘X’] = “Dorky”;

Now you would like to get the value “Dorky” only by using the string description in $path. You need to get every indexing step as a string value by exploding the string at the “.” characters.

$patharray = explode(”.”, $path);

Then you need to go along this path in array form and dereference the $param array down to its value. You could do so with a foreach loop on the $path array. But you can do it more elegant using array_reduce.
Normally array_reduce iterates over an array and gathers (in any sense) information to sum it up in some single value. But you can also replace this “sum variable” by something else. For example by a dereferenced value of an array … you get a clue?
And since we don’t want to pollute our namespaces with callback functions, why not use the new PHP5.3 feature of anonymous functions?
Putting it all together leads to a one liner:

$value = array_reduce(explode(’.’, $str), function($v, $w) { return $v[$w]; }, $param);

To try it out here is the complete script:

<?php
$str=“A.B.C.D.X”;
$param[‘A’][‘B’][‘C’][‘D’][‘X’]=“Dorky”;
$value=array_reduce(explode(’.’, $str), function($v, $w) { return $v[$w]; }, $param);
print_r($value);
?>

Have fun!

Article
2011-06-17
0 comment
by Volker

Virtual LAMP develop environment with vagrant on a Mac

Sometimes its preferable to have a controlled development environment. One way to do so is using a virtualization. One of those is Oracle’s VirtualBox. To use it seamlessly in a Mac based development setup there is a way to boot a VirtualBox headless, that means without a GUI. To make life a bit easier some really smart ruby guys have developed Vagrant, a system to build and control headless VirtualBox installations.VirtualBox also supports port forwarding (for ports >1024, we come to that later) so we’re able to access the services inside the box from the Mac outside. It also supports sharing directories, so we also can access the project files from both sides of the box.
Fortunately Vagrant provides a Ruby config file to setup both sharing and port forwaring in a totally easy way. To get started, please install VirtualBox and Vagrant as described on the respective web sites.
We now need to supply a prebuilt Debian Squeeze box. Graeme Mathieson was so kind to supply it here. We follow his instructions and install tha base debian using a

vagrant box add debian_squeeze_32 http://mathie-vagrant-boxes.s3.amazonaws.com/debian_squeeze_32.box

To start now we need a project directory. I keep all my Vagrant projects in a special directory ~/vagrant. Therein I created a project directory called debian_squeeze since I’m going to create a Debian Squeeze box. In this directory we create a Project using vagrant init debian_squeeze_32. This creates project file named Vagrantfile which is already preconfigured to use our Debian box.. Open that with the editor of your choice and add two lines of port forwarding below the one commented out as anexample:

  config.vm.forward_port “http”, 80, 8080
  config.vm.forward_port “mysql”, 3306, 3306

This will forward the MySQL standard port and the web server port 80 to external 8080. In addition I would like to share a directory, where all my web roots will reside. So please go the comment block below the forwarding examples which presents an example for a share_folder function call and enter the following line:

  config.vm.share_folder “opt-sites”, “/opt/sites”, “/opt/sites”

This means: name this share “opt-sites” and link the internal /opt/sites to the Mac directory /opt/sites. Note that both directives are simple ruby function calles and in both the first parameter is a custom string to identify the share / forwarding internally. And please replace my /opt/sites with the paths you like.
Close the editor and fire up your installation with vagrant up. Log into your box with vagrant ssh You will be logged in as user vagrant who is allowed to administer the system with sudo. Now we can install all the needed PHP5 and MySQL packages. The Debian packaging system will ensure that the services will also be started up so we are ready to proceed.
Log out from the system with CRTL-d and test the web server installation and forwarding by pointing your browser to http://127.0.0.1:8080 You s.hould see the default Apache web page. Now if you’re like me you would like to get rid of that 8080 port. On a mac you can do so by reconfiguring the ipfw firewall with an additional local transparent proxy rule. Luckily a user over at ServerVault called Sammy has done this for a slightly different port setup. Since I don’t like to set up the rule on the command line I installed WaterRoof, a GUI for ipfw. Start WaterRoof and add a rule containing

fwd 127.0.0.1,8080 tcp from 127.0.0.1 to 127.0.0.1 dst-port 80

My rule has the rule no. 1000. This is only for the sequence of execution. With that in effect, you now can access your debian web server with http://127.0.0.1 And y.ou can install some MySQL client tool and access the MySQL server on localhost:3306.
One last note of cation: please don’t use vagrant destroy on your project since that deletes any Debian package installed into your Squeeze box and lets you start with a brand new naked box. Hope you enjoyed and happy hacking.

[Update]
To use the port forwarding on the command line, please use:

sudo /sbin/ipfw -q add fwd 127.0.0.1,8080 tcp from 127.0.0.1 to 127.0.0.1 dst-port 80

 

Article
2011-01-29
0 comment
by Volker

Any sufficiently advanced technology is indistinguishable from magic

I just wanted to share some words about the technology used in building this site. After playing around with many different CMS and blog engines I decided to use ExpressionEngine (EE). This has several reasons:

  • Its built using PHP which allows me to put my hands as deep into the code as I want or need to accomplish a given goal.
  • I used EE to build several customer web sites, so there is a significant amount of knowledge about solving complex problems with EE.
  • EE is one of the most versatile blog engines I know since it allows you to create as many blog or channel streams as you like and use as many of them in one page template as needed.
  • EE in version 2 is completely rebuilt using the CodeIgniter framework. This leads to clean compact code and lots of possibilities to extend its functionality.
  • Its well documented. the learning curve is steep (you can do lots of new things in a short amount of time).

I also have a nearly complete blog engine written in Django in my “cool projects drawer” but you know fast such projects advance …