couchDB speichert Daten ohne Schema

Seit Jahren versuche ich Suppen zu kochen wie meine Tante Hildegard, doch nie hat eine meiner Suppen mal so richtig gut geschmeckt wie jede ihrer Suppen. Klar, meine schmecken auch, aber eben nicht so richtig absolut total köstlich, so, dass man gar nicht mehr aufhören möchte zu essen. Eine sinnlose Suche für mich? Ich hatte es schon fast aufgegeben.

Ebenso suche ich seit einiger Zeit in einem ganz anderen Bereich, nämlich für einfache Internetapplikationen, nach einer Möglichkeit, Daten im Computer so behandeln, wie es das menschliche Gehirn meiner Meinung nach tun würde. Gestern wurde ich endlich fündig.

PHP-Klassen als Pendant zum menschlichen Gehirn?

Meine Vorstellungen darüber sind eher philosophisch als technisch, aber Kai meinte dazu nur, dass alle Informatiker die er kennt philosophisch seien. Ich bin Soziologe.

Der Controller (das Bewusstsein?): jemand stellt eine Frage

“Was gibt’s Neues?”

Woher weiß der Befragte, was nun zu tun ist. Je nach persönlichen Fähigkeiten müsste diese Frage erst einmal eine Folge von kontrollierten Denkschritten erfordern:

Das Bewusstsein wendet sich an die Datenbank des Gehirns, und stellt eine Anfrage ohne selbst Gehirn zu sein, am besten als HTTP-Request. Es fragt:

“Gib mir bitte die Ereignisse zurück, die seit dem letzten Treffen mit der fragenden Person passiert sind!”

Das Model (das Gehirn?): der Zugriff auf semistrukturierte Daten

Unser Gehirn ist zu etwas fähig, was Informatiker mit relationalen Datenbanken leider noch nicht geschafft haben: es kann genaue und ungenaue Informationen abspeichern. Um beim Beispiel zu bleiben, es kennt Ereignisse, und diese sind vielleicht mit Zeitangaben ausgezeichnet, die teilweise genau sind (gestern um 20:15 Uhr), teilweise ungenau (irgendwann in den letzten Wochen).

Das Gehirn fragt nicht nach einheitlichen Strukturen der Ereignisse oder fehlenden Informationen, sondern trifft eine logische Auswahl. Wenn also ein Ereignis keine Zeitangabe besitzt, so wird es auf die Anfrage einfach nicht ausgegeben.

Es kommt etwas zurück: eine einfache JSON-Datei:

[
   {
      "titel": "wetten dass..?",
      "zeit": "gestern, 20:15 Uhr"
   },
   {
      "titel": "Suppenkochbuch gekauft",
      "zeit": "letzten Freitag"
   }
]

Die View (die Kultur?): wir stellen die Daten verständlich dar

Dass JSON als Format gewählt wurde, ist lediglich eine Entscheidung über das standardisierte Austauschformat, wobei JSON bestimmt schon sehr nah an unser menschliches Denken heran kommt. Aber würde der Befragte in JSON antworten, so könnte es nur eine Maschine verstehen, denn JSON entspricht der Kultur der Maschine. Die Antwort an den Menschen muss also umformuliert werden, am besten sogar durch ein Template mit Markern, was hier aber jetzt zu kompliziert wäre.

 $ereignis)
   {
      $antwort .= "$key. ". $ereignis['zeit'] ."passierte Folgendes: ". $ereignis['titel'] .". ";
   }
}
else
{
   $antwort = "Nix Neues. Und bei Dir?";
}
$Kultur->sprich($antwort);
?>

So oder so ähnlich müsste es jedenfalls ablaufen. Hilfreich ist hier auch der Text “Der Menschliche Körper” von Otto Waalkes (nach Gerdhardt soweit mir bekannt).

Das Gehirn heißt couchDB

Ich hatte bereits fleißig angefangen, meine “Brain”-Klasse zu programmieren, als ich gestern Abend auf diesen Artikel stieß: Gibt es ein Leben nach SQL? | PHP hates me – Der PHP Blog.

Und hier findet sich der Hinweis auf die Lösung des Problems: couchDB. Man stellt also in Zukunft die Anfragen nicht mehr an den Webservice Brain, sondern einfach über HTTP-Request an http://127.0.0.1:5984/ und erhält ein Ergebnis im Austauschformat JSON.

Und das Geheimnis der Suppe?

Curry.

WebdixX Nachfolger WIBS

Und wenn ja, was braucht dann ein CMS? Zugegeben, die Frage klingt etwas provokant. Der Mensch braucht gewiss kein CMS, aber in gewisser Weise hat die Internetnutzung zugenommen und zunehmend stellen Menschen Content ins Netz ein. Daher lässt sich fragen, wie der Mensch eigentlich diesen Content einstellt, ober er dazu neue Werkzeuge und was überhaupt er dazu benötigt.

Ich habe versucht, dieser Frage nachzugehen. Ausschlag für diese Überlegungen waren zwei Dinge. Zum einen ein Blick auf eine neue Datenbank-Software für den Mac. Diese leider nicht freie Software ist wirklich intuitiv zu bedienen, das ganze sieht aus wie eine Mischung aus einer Tabelle und den Suchfiltern von Mozilla Thunderbird. Andere Inspirationsquelle war das Buch Getting Real von 37signals, das man übrigens auch kostenlos im Netz lesen kann unter http://gettingreal.37signals.com/. In diesem Buch geht es im Prinzip um die Vereinfachung unseres Denkens, um eine optimale Software für bestimmte Zwecke zu entwickeln.

Denkt man darüber nach, was ein CMS eigentlich ist, so kommt man auf den Schluss, dass es das Gegenteil von zielorientierter, praktischer Software ist, denn das CMS weiß ja nicht was man letztlich mit ihm vorhat. Also muss es alle Möglichkeiten einplanen. Ist das wirklich der Zweck eines CMS? Oder sollte das CMS eher eine Ansammlung von Tools sein?

Dieser Essay ist bestimmt nicht zu Ende gedacht, aber er spiegelt meine Überlegungen von vor 2 Woche wider. Inzwischen steht die Basisversion eines neuen, einfachen CMS “WIBS” (Arbeitstitel , die auf jQuery und PHP basiert. Natürlich mal wieder zu komplex. Aber der Anfang ist gemacht.

CMS, CMS, CMS und die besten Seiten sind einfach

Inzwischen gibt es so zahlreiche CMS im Umlauf, die meisten davon kostenlos, sogar Open Source. Jeder hat so seine Erfahrungen mit dem einen oder anderen davon gemacht. Doch was man heute im Internet findet sind zunehmend funktionale Seiten. Was macht eine solche Seite aus? Und was braucht eine solche Website? Dieser Beitrag versucht Anforderungen moderner Websites einzugrenzen und anschließend ein Konzept für ein CMS zu erstellen, das diesen Anforderungen genügt.

User Interface Design: Navigation und Zugang zum Content

Moderne Webseiten verwalten mindestens ebensoviel Content wie ihre Vorgänger, doch fällt es dem User erst einmal nicht mehr auf. Auf Youtube zum Beispiel werden laut Wikipedia täglich rund 65000 Filme hochgeladen. Doch wer einen Film sucht, findet ihn meist mit weniger als drei Suchbegriffen. Entwickler überall auf der Welt haben erkannt, dass es wahrlich schnellere Möglichkeiten gibt, durch eine Website zu navigieren als über eine Sitemap oder ein dreifach geschachteltes Menü.

Für einen schnellen Zugang zu Seiteninhalten gibt es kein Patentrezept. Vielmehr sind hier innovative Lösungen gefragt. Je nach Inhalten einer Seite kann eine Stichwortsuche hilfreich sein. Die Möglichkeit, Inhalte nach Datum, nach Kategorien oder nach Tags (Stichwörter) zu sortieren, ist ein weitere Möglichkeit, die den Zugang vereinfachen kann. Es gibt nahezu unbegrenzte Möglichkeiten, die jedoch bei der Planung einer Website nicht willkürlich sondern geplant eingesetzt und ggf. entwickelt werden müssen.

Variable Darstellung und Ausgabeformate

In dem Moment, wo der Mensch den Unterschied zwischen Content und Darstellung, oder noch präziser zwischen Content und Ausgabeformat erkennt, verändert sich sein Denken. Diese Überlegung ist insofern philosophisch, als dass es um die Grenze zwischen Inhalt (Content) und Form (Ausgabe) geht. Die Form ist das, was wirkt, was echt oder unecht erscheint. Der Mensch sieht die Form, aber er behält den Inhalt. Unser Gehirn produziert reinen Inhalt. Gedanken sind Content, eine Idee ist Content, eine Information ist Content. Versucht man eine Information an andere zu übermitteln, so bedarf es der Darstellung. Selbst wenn ich meine Idee in eine Datenbank eintragen möchte, so verändere ich sie bereits. Die Idee wird geschrieben zur Zeichenkette (string), oder theoretisch umgesetzt als Methode (function) oder zu einer Gruppe von Methoden (class) in ein übergeordnetes Konzept (parent class) eingeordnet. Vielleicht denke ich auch ein Objekt (object), das wiederum eigene Methoden enthält.

Doch was kann man daraus für einen abstrakten Entwurf moderner Websites schließen? Der Inhalt muss so formlos wie möglich gespeichert werden, so dass es einfach ist, ihn in unterschiedlichen Formen auszugeben. Eine Information muss sowohl auf der Seite selbst (HTML) als auch per RSS-Feed (XML) oder als Druckvorlage (PDF) abgerufen werden können. Welche der Formate man letztlich zur Verfügung stellt, wird je nach Anwendungsfall entschieden.

Unvorhersehbar: offen sein für alles

Erfindungen fallen dadurch auf, dass sie gemacht werden, nicht dass sie jemand voraussagt. Und dann sind sie da und niemand will mehr auf sie verzichten. In großen Firmen gibt Forschungs- und Entwicklungsabteilungen, doch welche dieser Abteilungen hat schon mal eine wirkliche Innovationen hervorgebracht? Der Vorteil von Innovationen ist gleichzeitig ihr Nachteil: die Unvorhersehbarkeit.

Flexibilität macht unflexibel

Fast alle CMS der Vergangenheit haben versucht, Unvorhersehbares zu integrieren und so möglichst flexibel zu sein. Man denke dabei beispielsweise an TYPO3: Jedes HTML-Element wird mit zig CSS-Klassen versehen und in diverse DIVs verschachtelt, damit man auch ja jedes davon direkt ansprechen kann. Erweiterungen werden in ihrer Basis-Version mit diversen Eigenschaften ausgestattet, die es erlauben sollen, all das zu machen, was der Entwickler des CMS noch gar nicht weiß. Innovationen sollen eben einfach in das System aufgenommen werden. Und kaum kommt einer an und erfindet AJAX und JSON, und schon ist alles für’n A****.

Aus schlanken Systemen sind eigene, schwerfällige und träge PHP-Welten gewachsen, die nun daran scheitern, dass es ihnen an Schlichtheit fehlt. Sie haben fast alles vorhergesehen ausser das Unvorhersehbare selbst, die wirklichen Innovationen eben.

Die Zukunft: back to the roots?

Es fing einfach an und es wird noch einfacher enden. Die Anforderungen für die Zukunft:

Datenstrukturen sollen lesbar sein.

JSON ist beispielsweise ein solches für Mensch und Maschine gut lesbares Format für kleine Datenstrukturen.

Eine Seite braucht dynamische Bereiche.

Hier ist Javascript und AJAX unverzichtbar. Das Javascript-Framework jQuery erlaubt schnelle Eingriffe in nahezu alles, was HTML darstellen kann.

Ein Template soll lesbar und veränderbar sein.

Die Seitenaufteilung muss sich zwar nicht stets ändern, aber die Möglichkeit muss geboten sein.

Inhalte sollen lesbar sein.

Wie die einzelnen Inhalte in das CMS kommen, muss dem Programmierer selbst überlassen bleiben. Für eine reine HTML-Seite reicht HTML aus. Bei anderen Ausgaben wäre allerdings ein reines Datenformat wichtig.

Nichts darf fertig sein.

Der Programmierer muss das CMS selbst erstellen. Seine Idee muss die Idee des CMS werden, nicht umgekehrt. Wenn das CMS vorher schon fertig ist, dann ist es nicht sein CMS und zudem ist es starr. Und Starrheit ist das Gegenteil von Flexibilität, und das wollen wir doch alle, oder?

Fazit: alles wird einfacher

Hier ein Fazit zu bringen, ist gefährlich, denn der Gedanke ist noch nicht zu Ende gedacht, und was ich hier heute schreibe, denke ich morgen schon wieder anders. Vielleicht kommt die Komplexität wieder in Mode. Eigene Standards und Systeme, die gelernt werden müssen, nicht weil es keine Alternativen gibt, sondern weil der Programmierer Neues erfinden will. Er braucht diese Erfahrung, sie gibt ihm ein gutes Gefühl. Die Welt verstehen und beherrschen, alles kontrollieren, selbst das Risiko. Ich persönlich glaube nicht daran und buildLess von 37signals bleibt für mich eine wichtige Lektion, da ich selbst zuvor immer glaubte, man müsse alles dynamisieren und flexibel sein in der Form, dass jede Laune des Nutzers vorhersehbar gemacht wird. Stattdessen sollte der Nutzer aber vorher sagen, was er will, dann kann der Programmierer es genau auf diesen Fall angepasst bauen. Das spart neben Nerven auch noch Kosten. Es bleibt uns also nur die eine Hoffnung: Alles wird gut.