Für uns Entwickler ist die Tastatur ohne Zweifel das wichtigste Werkzeug. Ohne sie könnten wir keine Zeile Code schreiben und dennoch wird ihr selten Beachtung geschenkt. Sie ist da und funktioniert – bis man eine Tasse Kaffee darüber schüttet oder sie nach Jahren in Krümeln, anderen Essensresten bzw. Staub ersoffen ist.

Wenn sie kaputt ist, wird für ein paar Euro eine neue gekauft und gut ist. Manchmal gibt man auch etwas mehr aus, z.B. für ein Apple Keyboard oder ein besseres Modell von Logitech.

Dabei macht sich aber niemand Gedanken darüber, wie sie eigentlich funktioniert und ob da nicht gerade für uns Vieltipper Verbesserungspotenzial ist.

Die meisten Tastaturen haben eines gemeinsam: sie nutzen die sog. Rubberdome-Technik. Dabei wird beim Tastendruck eine Gumminoppe mit Kontaktpad nach unten auf die Platine gedrückt und so der Anschlag durch den Kontakt ausgelöst. Alle Noppen befinden sich auf einer Gummifolie, die einfach über die Platine gelegt wird. Kabel ans PCB, Tasten drauf, Gehäuse drumrum und fertig ist die Tastatur.

Das ist günstig, aber auch gut? Leider nein. Es gibt zwar durchaus ganz gute Vertreter dieser Gattung, aber die Schwachstellen haben sie alle gemein:

1. Um den Anschlag auszulösen, muss man die Taste vollständig durckdrücken.
2. Der Anschlag ist nicht über alle Tasten konsistent und verändert sich mit der Zeit.
3. Gerade bei den billigen Vertretern, mitunter aber auch bei den teuren ist das Gehäuse nicht verwindungssteif.
4. Geringe Haltbarheit von max. 5 Millionen Anschlägen.

Die ersten drei Punkte fallen insbesondere für Vieltipper deutlich stärker ins Gewicht, als man meinen möchte. Vollständiges Durchdrücken der Tasten lässt die Hände bzw. Finger schnell ermüden – gleiches gilt, wenn sich die Tastatur beim Tippen verwindet bzw. nach unten verbiegt. Da sich der Anschlag ungleichmäßig über die Zeit und je nach Nutzung der Tasten verändert, kann sich kein Muskelgedächtnis bilden, um schneller tippen zu können.

Und jetzt?

Wie wär’s mit einer Alternative? Mechanische Tastaturen!

Huch? Sind die nicht sauteuer, laut und sperrig? So wie früher diese Totschläger von IBM …

Hach ja, das IBM Model M. Wenn man wollte, könnte man damit wohl wirklich Einbrecher niederschlagen. Zur Selberverteidigung empfehle aber doch eher andere Gerätschaften.

Ein billiges Vergnügen sind mechanische Tastaturen wirklich nicht, aber sie sind es defintiv wert. Hier geht es schließlich um ein Werkzeug. Handwerker geben sich schließlich auch nicht mit einem Consumer-Akkuschrauber für 20 Euro zufrieden. Warum also sollten wir das bei unseren alltäglichen Helfern tun? Ob sie laut und groß sind, hängt dagegen ganz vom jeweiligen Geschmack ab.

Aha, und warum können die Dinger das nun besser?

Um die Kritikpunkte von oben direkt aufzugreifen:

1. Mechanische Schalter müssen nicht vollständig durchgedrückt werden, um einen Anschlag auszulösen – die Hälfte genügt. Die verbreitetesten Schalter (Cherry MX) haben einen Hub von insgesamt 4 mm und lösen darum nach 2 mm aus.
2. Der Anschlag verändert sich weder mit der Zeit noch nutzen sich verschiedene Tasten je nach Gebrauch unterschiedlich ab. So bildet sich mit der Zeit ein Muskelgedächtnis, das schnelleres und komfortableres Schreiben ermöglicht.
3. Bei guten mechanischen Tastaturen sind die Schalter auf einer Stahlplatte angebracht, darunter befindet sich die Platine mit der sie verlötet sind. Da verwindet und verbiegt sich nichts.
4. Mechanische Tastaturen halten Jahrzehnte durch. Die durchschnittliche Lebensdauer von Cherry-Schaltern liegt bei ca. 50 Mio. Anschlägen. Unzerstörbar sind sie aber natürlich nicht.

Je nach Schalter-Typ gibt es auch noch zusätzliche Vor- und Nachteile, so dass man sie ganz nach seinen Präferenzen aussuchen kann.

Schalter-Typen

Ich beschränke mich hierbei auf die gängen Varianten von Cherry, da sie am häufigsten verbaut werden.

• MX blue: löst mit einem Klick-Geräusch aus und hat dazu beim Anschlag einen spürbaren Widerstand. Betätigungskraft: 60 cN
• MX brown: löst ohne Klick aus, besitzt aber den gleichen spürbaren Widerstand beim Anschlag wie der MX blue. Betätigungskraft: 55 cN
• MX black: linearer Schalter, löst beim Anschlag wieder einen Klick noch einen Widerstand aus. Betätigungskraft: 60 cN
• MX red: wie MX black, nur mit geringerer Betätigungskraft: 45 cN

Darüber hinaus gibt es noch verschiedene Varianten der MX blue und MX brown mit höherer Betätigungskraft. Man trifft sie allerdings eher selten an, manche davon sind sogar regelrecht rar.

Grundsätzlich gilt es beim Kauf einer Tastatur zuerst den Schalter-Typ zu wählen. Zum Entwickeln oder Schreiben sind die MX blue definitiv die beste Wahl, da sie ein hör- und spürbares Feedback bieten und daher nach der Eingewöhnung, sehr schnelles und flüssiges Tippen ohne Ermüdungserscheinungen ermöglichen.

Nun mag natürlich so manchen das Klicken auf die Palme bringen, andere widerrum können nicht mehr ohne. Wer sich daran stört oder die Kollegen im Büro nicht zum Amoklauf treiben will, aber dennoch spüren möchte, wenn der Anschlag ausgelöst wird, sollte zum MX brown greifen. Er tippt sich ein klein wenig leichter und ist ohne den Klick erheblich leiser.

Findet man dagegen Widerstand zwecklos, sollte man einen Blick auf die MX black oder MX red werfen. Letzterer ist besonders bei Spielern sehr beliebt, da man sehr schnell mehrere Anschläge hintereinander auslösen kann, ohne wie ein Bekloppter auf die Tastatur hämmern zu müssen. Dafür neigt man u.U. eher zu Vertippern.

Grundsätzlich kann man die Schalter in drei Kategorien aufteilen: Profi-Tipper ohne Klick-Allergie, die eher wenig bis gar nicht spielen, werden mit MX blue am glücklichsten. Möchte man dagegen einen guten Allrounder zum Schreiben und Spielen, ist der MX brown das Mittel der Wahl. Wer mehr spielt als Texte tippt, dürfte mit einem MX black oder MX red am besten klarkommen.

Ich empfehle aber jedem, verschiedene Schaltertypen auszuprobieren. Es gibt genug Spieler, die sich nicht am Klicken des MX blue stören und den MX red hassen wie die Pest – und umgekehrt genauso.

Noch etwas zur Lautstärke: man kann auch mit einem nicht klickenden Schalter schön Krach machen, wenn man auf der Tastatur rumhackt wie ein Irrer. Dazu hängt der Geräuschpegel auch von der Konstruktion bzw. dem Gehäuse ab. Dazu später etwas mehr (dasKeyboard Model S vs. dasKeyboard 4 vs. Corsair K70).

Was kostet der Spaß und wo bekomme ich so ein Teil her?

Der Preis der gängigen Modelle liegt zwischen 60 und 200 Euro.

Die definitiv günstigste Wahl gibt’s von Cherry selbst mit dem MX Keyboard 3.0. Zu bekommen bei Amazon oder den gängigen Hardware-Händlern.

Ansonsten ist die Auswahl an Shops eher eingeschränkt. Die EU und insbesondere Deutschland gehören bei mechanischen Tastaturen eher zur dritten Welt.

Die bisher besten Quellen, die ich neben Amazon ausmachen konnte: GetDigital (dasKeyboard, Ducky, Filco, Leopold), CaseKing (Cherry und Ducky), The Keyboard Company UK (primär Filco und deren Zubehör).

Ansonsten stellen diverse bekannte Marken aus dem Spiele-Sektor wie Corsair, Razer, CMstorm, Func und auch Logitech mechanische Tastaturen her, die man auch in gängigen Läden und Shops bekommt.

Für professionelle Anwender rate ich zu Filco, Ducky oder dasKeyboard, da sie qualitativ etwas mehr bieten. Besonders Ducky und Filco bauen regelrechte Panzer. Grundsätzlich kann mit den anderen aber nicht viel falsch machen. Man sollte aber inzwischen aufpassen, von welchem Hersteller die Switches sind. Da gibt es leider nicht nur Unterschiede in der Schaltcharakteristik, weil inzwischen wegen abgelaufener Patente auch billigere Kopien der MX-Schalter auf dem Markt sind, zu deren Haltbarkeit es noch keine Erfahrungswerte gibt. Die einschlägigen Foren sehen die Sache allerdings weniger gelassen …

Meine Erfahrung

Ich hatte mich im November vergangenen Jahres dazu entschlossen eine mechanische Tastatur auszuprobieren und entschied mich für eine Corsair K70 mit MX brown und blauer Hintergrundbeleuchtung. Die Tastatur hing nur an meinem Windows-Rechner, an dem ich eher wenig schreibe und mehr spiele.

Abgesehen von der Lautstärke durch die offene Konstruktion ohne einen Rahmen, der die Tasten umgibt, war ich mit der K70 sehr zufrieden. Nach einem Tip im Computerbase-Forum, habe ich Gummi-O-Ringe zwischen die Tasten und Schalter montiert, was die Lautstärke deutlich dämpfte. Allerdings verändern solche Maßnahmen den Anschlag – einfach ausprobieren, die Ringe kann man sehr günstig kaufen.

Für meine Arbeit als Entwickler, die ich ausschließlich am Mac verrichte, habe ich längere Zeit eine geeignete mechanische Tastatur gesucht. Zum Testen entschied ich mich für ein dasKeyboard Model S Professional for Mac mit MX blue. Leider gibt es dieses Modell nur mit ANSI-Layout, was mich anfangs vom Kauf abgehalten hat und schließlich auch nicht damit zurecht kam. Der ständige Wechsel bringt einen nur durcheinander und das deutsche Tasten-Mapping (ISO-Layout) mit einem ANSI-Layout zu nutzen klappt auch nicht – da fehlt schließlich eine Taste.

Die MX blue dagegen haben mich auf Anhieb begeistert. Kurzum: ich habe die Tastatur gegen ein dasKeyboard 4 mit MX blue umgetauscht. Die hat zwar kein Mac-Layout, aber das lässt sich durch den Tausch der Tastenkappen und ein paar Einstellungen in OS X problemlos anpassen. Außerdem funktionieren die Media-Tasten und selbst der Lautstärkeregler ohne jegliche Anpassung mit OS X. Wozu da also noch ein spezielles Mac-Modell?

Parallel ließ mich leider die K70 im Stich. Innerhalb eines halben Jahres gingen drei LEDs der Hintergrundbeleuchtung kaputt. Nach einer Recherche in den Corsair-Forn scheint das ein verbreitetes Problem mit den blauen LEDs (gibt auch rote) bei der K70 zu sein. Corsair hat das Modell zwischenzeitlich vom Markt genommen und wird wohl demnächst eine überarbeitete Version liefern.

Amazon nahm die K70 anstandslos zurück und als Ersatz habe ich mich für ein dasKeyboard 4 mit MX brown entschieden und es bisher nicht bereut.

Zum Abrunden des Portfolios der MX-Schalter, habe ich mir noch als Abwechslung zu den beiden dasKeyboard eine Ducky Shine 3 mit MX black gegönnt. Sie wirkt noch einen Tick solider, hat ein abnehmbares Kabel und zig Beleuchtungsoptionen. Der lineare Gang und höhere Widerstand der Switches ist etwas gewöhnungsbedürftig, aber angenehm, besonders beim Spielen.

Eine weitere Anmerkung zur Lautstärke: die dasKeyboard 4 haben zwischen ihrer Deckplatte aus Aluminum und der Stahlplatte einen sehr festen Schaumstoff, der die Geräuschkulisse dämpft. Der Unterschied zum Vorgängermodell oder auch der Corsair K70 ist ziemlich gewaltig. Sogar die MX blue-Version ist leiser als die K70 samt Gummi-O-Ringen. Die Ducky liegt durch ihre sehr stabile Konstruktion auch recht gut im Vergleich. Dazu tragen aber auch die MX black sicherlich ihren Teil bei.

Generell habe ich mit keiner der Tastaturen eine schlechte Tipp-Erfahrung gemacht. Nur das ANSI-Layout und die defekten LEDs haben mich zu einem Umtausch veranlasst.

Fazit

Nach dem ich nun in einem halben Jahr drei Hersteller und drei unteschiedliche Schalter-Typen durch habe, kann ich nur sagen, dass mich mechanische Tastaturen begeistern, wenn sie nicht sogar eine Sammlerwut entfacht haben (ich hoffe nicht, das wäre ein teures Hobby).

Der Tipp-Komfort und die Zuverlässigkeit sind es mir aber wert. Schließlich sind die Tastaturen auch maßgeblich daran beteiligt, dass ich überhaupt Geld verdiene. Wenn man die Unterschiede erstmal kennt, möchte man nur ungern zu Rubberdome-Tastaturen zurückkehren. Selbst mein früher geliebtes Apple Keyboard lasse ich für eine mechanische Tastatur links liegen.

Dazu gibt es eine unglaubliche Vielfalt an Individualisierunsmöglichkeiten. Seien es nun Tastenkappen, modifizierte Federn in den Schaltern oder gar leicht verrückte Dinge wie Tastatur-Bausätze, mit denen man wirklich alles bis ins letzte Detail für sich anpassen und austüfteln kann. Interessenten zu diesen Themen sowie Kaufberatung etc. kann ich das Forum geekhack ans Herz legen.

Ich habe Amplify grundlegend überarbeitet und mit ein paar neuen Features ausgestattet:

• Redcarpet wurde durch kramdown ersetzt und unterstützt damit auch die Markdown-Erweiterungen, die kramdown anbietet.
• Automatisches Verlinken von URLs
• HTML-Sanitation
• Das Syntax-Highlighting übernimmt nun das Gem ‘pygments.rb’. Der Umweg über Pygmentizr fällt damit intern weg und verbessert die Reaktionszeiten deutlich.
• Das Frontend basiert nun auf AngularJS.
• Komplett überarbeiteter Quelltext.
• JSON-basierte API

kramdown, das automatische Verlinken und die HTML-Sanitation werden über das Gem ‘slodown’ von Hendrik Mans erledigt.

Die neue JSON-basierte API ist über eine andere URL erreichbar:

http://amplify.webcodr.de/api/2.0/transform

Ein Beispiel-Request via POST:

{
 	"source": "# Hello World!"
}

Und die entsprechende Antwort von Amplify:

{
	"html": "<h1 id=\"hello-world\">Hello World!</h1>",
 	"source": "# Hello World!"
}

Wer, wie früher, ohne JSON auskommen möchte, nutzt bitte folgende URL:

http://amplify.webcodr.de/api/1.0/transform

Die bisherige Möglichkeit einfach einen POST-Request auf die Amplify-URL abzusetzen ist nur noch aus Gründen der Kompatibilität zu bestehenden Anwendungen aktiv, wird aber langfristig deaktiviert.

Zukünftige Features werde ich außerdem nur für die JSON-basierte API 2.0 implementieren.

Des weiteren plane ich Amplify langfristig nicht mehr auf Heroku laufen zu lassen, da die App einfach zu häufig in den Schlafmodus versetzt wird und anschließend sehr lange braucht, bis sie auf Anfragen reagiert.

Ich könnte zwar einfach einen Dyno hinzubuchen, aber das ist nicht gerade billig und es gibt wirklich kostengünstigere Möglichkeiten, Ruby-Web-Applikationen zu hosten – beispielsweise bei Uberspace.de.

Aus technischer Sicht dürfte noch interessant sein, dass Amplify nun mit Capybara automatisiert getestet wird und auf Travis CI sowie testweise Circle CI (mit automatischem Heroku-Deployment) läuft.

Was’n das?

Finger weg! Diese Mango schmeckt nicht.

Mango ist ein Object Document Mapper für MongoDB und PHP.

Und MongoAppKit?

MongoAppKit hat ein Problem, denn es ist nicht nur ein ODM und kann noch so einiges mehr. Theoretisch kann man zwar die ODM-Komponente auch ohne den ganzen anderen Krempel nutzen, aber es bleibt eine große Abhängigkeit zu Silex, die man auch nicht so einfach wieder los wird.

Dies und das im Vergleich schlechte Handling bzw. der geringe Komfort von MongoAppKit, haben mich dazu bewogen mit Mango einen universell einsatzbaren und leicht handzuhabenden ODM zu entwickeln.

Mango wurde stark von Mongoid für Ruby inspiriert und soll dessen Funktionalität zumindest teilweise in PHP abbilden. Das ist einfacher gesagt als getan, denn Ruby bietet wesentlich elegantere Möglichkeiten diverse Probleme zu lösen, als es mit PHP derzeit machbar ist.

Los geht’s …

Installation via Composer

$ php composer.phar require webcodr/mango:*

Ein Dokument anzulegen ist ein Kinderspiel

<?php

namespace MyProject\Model;

use Mango\Document;
use Mango\DocumentInterface;

class User implements DocumentInterface
{
    use Document;

    private function addFields()
    {
        $this->addField('name', ['type' => 'String']);
        $this->addField('email', ['type' => 'String']);
        $this->addField('created_at', ['type' => 'DateTime', 'index' => true, 'default' => 'now'];
        $this->addField('updated_at', ['type' => 'DateTime', 'index' => true, 'default' => 'now'];
    }
}

Es ist lediglich nötig, dass die Model-Klasse das Interface DocumentInterface implementiert und den Trait Document einbindet. In der Hook-Methode addFields() werden anschließend noch die Felder des Dokuments deklariert.

Mango nutzt etwas Magic: Der Klassenname des Models ist gleichzeitig auch der Name der Collection (klein geschrieben). Soll die Collection anders heißen bzw. das Model eine vorhandene nutzen, muss lediglich die Methode getCollectionName() überschrieben werden.

Go, Mango, go!

<?php

use Mango\Mango;
use Mango\DocumentManager;

use Document\User;

$mango = new Mango('mongodb://localhost/galactica');
$dm = new DocumentManager($mango);
$user = new User();
$user->name = 'William Adama';
$user->email '[email protected]';
$user->store();

Das Mango-Object erwartet eine gültige MongoDB URI, falls notwendig inkl. Benutzer, Passwort, Port usw.

Dem Document Manager kommt eine vergleichbare Aufgabe zu, wie dem Entity Manager in Doctrine2.

Für mehr Komfort holt sich eine Model-Klasse den Document Manager über eine statische Methode ab. Daher können Methoden wie store() direkt über die Model-Klasse abgewickelt werden.

Dokumente abfragen

<?php

$user = User::where(['name' => 'William Adama']);
echo $user->count(); // = 1
echo $user->first()->email; // = [email protected]

Eine Abfrage kann einfach über die statische Methode where() ausgeführt werden. Die Syntax der Abfragen entspricht derzeit noch der normalen MongoDB Query API. Für die Zukunft plane ich aber eine Abstraktionsebene für die Abfragen, vergleichbar mit Mongoid.

Eine Abfrage kit where() oder find() gibt immer ein Cursor-Objekt zurück, das anhand der aufgerufenen Methode entscheiden kann, ob der Zugriff auf den MongoCursor oder das Abfrageergebnis in Form einer Instanz von MutableMap erfolgt.

In obigem Beispiel ist count() eine Methode des Cursors, während first() schon auf der Ergebnis zugreift. Wie MongoCursor kann auch die Cursor-Klasse von Mango einfach über das Ergebnis iterieren.

Durch die dynamische Unterscheidung zwischen MongoCursor- und Datenzugriff, können auf eine Instanz der Cursor-Klasse auch alle Methoden von MutableMap angewandt werden.

Beispielsweise:

<?php

User::where()->reverse()->slice(0, 2)->each(function($document) {
    echo $document->name;
});

Natürlich macht dieser Code wenig Sinn, da man das wesentlich effizienter über die Cursor-Methoden erledigen kann. Das Beispiel soll lediglich zeigen, was möglich wäre.

Hydration

Mango sorgt automatisch dafür, dass die Dokumente im Ergebnis immer Instanzen ihrer jeweiligen Model-Klasse sind.

Die Hydration-Automatik sorgt außerdem dafür, dass die Daten intern als jeweilige Typ-Klasse von Mango gehalten werden.

Typ-Klassen halten die Daten und können sie in zwei Formaten zurückgeben. Konfiguriert man ein Feld als DateTime bekommt Mango intern beim Speichern automatisch ein MongoDate-Objekt. Greift man hingegen außerhalb von Mango auf den Wert zu, bekäme man in diesem Fall eine Instanz der Klasse DateTime zurück.

Soweit zum aktuellen Funktionsumfang von Mango. Es ist bei weitem noch nicht fertig, kann aber für kleine Projekte schon einsetzt werden. Ich verwende es selbst in der aktuellsten Version von CodrPress und es macht wesentlich mehr Spaß als MongoAppKit, ohne ein monströses Schlachtschiff wie Doctrine zu sein.

Natürlich gibt’s Mango auch bei GitHub.

Wer kennt das nicht? Man findet eine nette Software-Bibliothek in einer bestimmten Sprache, die vom Server der eigenen Web-Applikation nicht unterstützt wird oder nur sehr umständlich auf andere Weise genutzt werden kann.

So erging es mir mit Tools für Markdown-Rendering und server-basiertem Syntax-Highlighting. Zwar habe ich dafür ja im Oktober die Composer-Pakete SilexMarkdown und Radiant geschrieben, die beide auf bereits vorhandenen Bibliotheken fußen.

Ich war mit beiden nie recht glücklich. Für Ruby und Python gibt es viel schönere, wesentlich umfangreichere Lösungen:

• Pygments ist ein Python geschriebener Syntax-Highlighter, der nahezu jede relevante Sprache unterstützt – selbst esoterische Merkwürdigkeiten wie Brainfuck.

• Redcarpet wurde in Ruby verfasst und bietet einen sehr leicht erweiter- und modifizierbaren Markdown-Renderer.

Gerade für ein Blog-System wie CodrPress liegt es nahe, beide zu kombinieren und damit zumindest teilweise GitHub flavoured Markdown zu unterstützen.

Wie bekomme ich also drei Programmiersprachen unter einen Hut, ohne dass CodrPress nur auf angepassten Server-Konfigurationen läuft? Ganz einfach: Services!

Pygmentizr

Pygmentizr ist logischerweise in Python geschrieben, um Pygments nutzen zu können.

Per POST-Anfrage auf die verlinkte URL erreicht man den eigentlichen Service, der als Parameter die Sprache und den Quelltext erwartet. Zurück kommt HTML, das nur noch per CSS hübsch gemacht werden muss.

Ein entsprechendes Stylesheet für den bekannten Monokai-Stil ist auf der Seite verlinkt oder im GitHub-Repository zu finden.

Pygmentizr bei GitHub

Amplifyr

Amplifyr nutzt Redcarpet und bindet Pygmentizr als Syntax-Highlighter ein.

Wie Pygmentizr lässt sich Amplifyr per POST-Anfrage ansprechen und gibt den in HTML konvertierten Markdown-Quelltext zurück.

Amplifyr bei GitHub

Beide Dienste laufen auf der Cloud-Plattform Heroku.

CodrPress-Integration

Um beide Services in CodrPress nutzen können, habe ich in SilexMarkdown ein paar Umbauten vorgenommen. Beim Registrieren des Service-Providers in einer Silex-Applikation, lässt sich nun ganz einfach übergeben, ob der eingebaute Renderer samt Radiant oder Amplifyr genutzt werden soll. Eine entsprechende Anleitung findet sich in der ReadMe-Datei des SilexMarkdown-Repositories bei GitHub.

Beide Dienste sind bei Heroku untergebracht und kosten mich keinen Cent. daher gebe ich die Nutzung für jeden frei. Viel Spaß!

Wenn man sich zulange nur mit PHP beschäftigt vergisst man schnell, dass man oft Dinge tut, die kaum in andere Sprachen übertragbar sind.

Letztens habe ich mir Scala etwas näher angesehen. Kurz am Rande: eine schöne Sprache, wenn auch die verschiedenen Syntax-Modi etwas verwirrend oder zumindest recht gewöhnungsbedürftig sind.

Vorteil PHP

Scala bietet wie fast jede andere typisierte Sprache verschiedene Listen-Klassen für diverse Nutzungsfälle. In PHP gibt es das nicht. Man hat sein Array, das jederzeit veränderlich ist, jede noch so wilde Mischung von Datentypen akzeptiert und assoziative Schlüssel erlaubt. Es ist einfach umgemein praktisch.

Vorteil Scala

Da PHP leider weit davon entfernt ist vollständig objekt-orientiert zu sein und darum ein Array leider keine Objekt ist, kann man Arrays nur mit diversen Funktionen bearbeiten.

Zwar funktioniert das einwandfrei, ist aber umständlich. Ein Array-Objekt, das entsprechende Methoden bietet, die sich am besten auch noch verkettet aufrufen lassen, wäre doch toll.

PHP goes Scala/Java/Objective-C

Daher habe ich mich ans Werk gemacht und die bereits existierende Klasse IterateableList in MongoAppKit in drei neue Klassen des Namespaces \MongoAppKit\Collection aufgeteilt: MutableMap und ArrayMap.

Die Namen orientieren sich an ihren Pendants in Scala, Java oder auch Objective-C. Während alle die SPL-Interfaces Countable und IteratorAggregate implementieren, verwendet ArrayMap zusätzlich das Interface ArrayAccess und kann damit wie ein PHP-Array verwendet werden.

Außerdem implementieren alle drei die Magic Methods __get(), __set(), __isset() und __unset. Das erleichtert z.B. die Verwendung einer Liste in Twig, in dem keine Methode mehr angesprochen werden muss, um innerhalb eines Templates auf die Inhalte zuzugreifen.

Um diverse Array-Funktionen von PHP abzubilden implementieren alle drei die Methoden:

• first(): gibt das erste Element der Liste zurück
• last(): gibt das letzte Element der Liste zurück
• reverse(): dreht die Reihenfolge der Elemente innerhalb der Liste um
• each(): wendet eine Callback-Funktion mittels array_walk auf alle Elemente an, in der auch auf die Schlüssel zugegriffen werden kann
• map(): wendet eine Callback-Funktion mittels array_map auf alle Elemente an
• slice(): schneidet einen Teil der Elemente heraus und gibt sie in einem neuen Listen-Objekt zurück
• filter(): filtert die Elemente einer Liste anhand einer Callback-Funktion und gibt das Ergebnis in einem neuen Listen-Objekt zurück

Fluent Interface

Um eine Verkettung von Methodenaufrufen zu ermöglichen gibt jede Methode, die sonst keinen Rückgabewert hätte, eine Referenz auf ihre Klasse zurück. Nur slice() und filter() geben eine neue Liste mit den herausgeschnittenen bzw. gefilterten Werten zurück.

Hier ein kleines Beispiel aus CodrPress, was man damit alles anstellen kann:

<?php

Post::where()->each(function($document) use ($app) {
    $md = $document->getProperty('body');
    $html = $app['markdown']->transform($md);
    $document->set('body_html', $html)->save();
});

Die statische Methode Post::where() liefert ohne Quert alle Posts als MutableMap-Objekt zurück. Auf die Rückgabe lässt sich sofort each() anwenden, das alle Elemente der Liste iteriert und die definierte Closure auf jedes Element einzeln anwendet.

In diesem Fall wird das rohe Markdown aus dem Feld body in HTML transformiert und im Feld body_html abgespeichert.

Fazit

MutableMap und seine Sub-Klassen sparen viel Schreibarbeit durch ein simples und komfortables Fluent Interface – einer Vorgehensweise, der in PHP leider viel zu wenig Beachtung geschenkt wird.

Download

Die drei Klassen sind nicht länger Teil von MongoAppKit. Ich habe sie in ein separates GitHub-Repository und Composer-Paket ausgelegt, um eine unkomplizierte Nutzung ohne MongoAppKit zu ermöglichen. Viel Spaß!