Aber ich frage mich, warum ist das so? Warum werden es überhaupt mehr BVB-Fans? Ist man nicht Fan seines Stammvereins, in guten wie in schlechten Zeiten? Wo sind jetzt die Bayern-Fans, die Mitleid mit dem Verein zeigen und ihm auch in diesen Tagen zur Seite stehen? Ich kenne gerade nur einen bekennenden Bayern-Fan, der nach dem Pokalfinale den Kopf hängen ließ. Wo sind die Millionen, die sonst den deutschen Dauermeister feierten?

Ich als bekennender Nebenbei-Fußball-Ergebnis-Mitbekommer frage mich allerdings andere Fragen als nur das simple “Bayern oder Borussia”: Ist das Wechseln von Vereinen als Fan überhaupt ethisch vertretbar? Ist man dann überhaupt jemals Fan gewesen? Und wenn ja, wie oft pro Saison ist das Wechseln OK? Kann ich dann einfach bei jedem Spiel ab der 79. Minute auf den Gewinner halten? Dann wäre doch für viele alles in Butter.

Ist es aber meiner Meinung nach nicht. Der kleine Misanthrop in mir stellt fiesere Fragen, die noch tiefer in unsere psychischen Abgründe eindringen: Warum halten die Menschen lieber auf Gewinner als auf Verlierer? Gibt einem das Kraft? Möchte man “dazugehören” oder einfach “mitreden” können? Ist man als Fan eines “Verlierer-Vereins” ein schlechter Mensch? Ein schwacher Fußball-Fan? Und müssen wir jetzt alle auf Halle halten, weil RB den Aufstieg vergeigt hat?

Ich weiß es nicht und will ich es eigentlich auch gar nicht wissen. Ich schüttele einfach beim Vorbeigehen den Kopf und ignoriere das Tohuwabohu (wenn man das so schreibt). Es soll ja wichtigeres als Fußball geben. Aber da scheiden sich anscheinend die Geister.

Etwas Werbung in eigener Sache: Am 21. und 22. Mai in Leipzig: die Meet Magento – eine Veranstaltung rund um das Magento-Shopsystem. Ihr findet mich dort!

Cool finde ich am neuen PHP vor allem Traits, die hybride Objekte ähnlich dem Polymorphismus in C++ erlauben. Seit Java war das ja verpönt und galt als “unbeherrschbar” ähnlich wie Atomkraftwerke. Stattdessen sollte man lieber mit diesen leeren Worthülsen von Interfaces werkeln. Doch die erlauben zwar eine gewisse Formalisierung von Analogien, aber keinen echten DRY-Code. Mit Traits ist man “im Objekt” und kann daher in $this schalten und walten wie man möchte – was witzige Sachen erlaubt.

Der nun in PHP selbst eingebaute Webserver ist allerdings nicht so das, was ich mir vorstellte. Eher zum Testen gedacht, durchläuft er pro Request jede PHP-Datei noch einmal und baut alle Objekte immer neu auf. Es ist also keine Deploy-and-Run-Lösung wie ein Zend Server. Immerhin kann man beim Testen schnell per F5 wissen, ob alles so läuft wie man möchte. Und für Bibliotheken kann man eine kleine launch.sh beilegen, die die Lösung auch ohne Webserver an Ort und Stelle demonstriert. Allerdings beantwortet der Server nur einen Request auf einmal, was ihn als echten Ersatz für den mittlerweile vielen als zu fett geltenden Apache nichtig macht.

Neu hinzugekommen ist übrigens die Restriktion, dass man eine date.timezone-Einstellung per ini benötigt, sonst gibts eine dicke Warnung beim Erzeugen eines Datetime-Objekts. Ansonsten ist glaube ich noch der Safe-Mode entfallen und die ganzen unnützen magic-quotes-Sachen…Vielleicht noch interessant sind die neuen Schnellzugriffe auf Arrays – erzeugen per [1,2,3] und auch bei der Rückgabe einer Funktion kann jetzt direkt darauf zugegriffen werden: getArray()[5] – das schreit geradezu nach try-catch.

Auf jeden Fall bewegt sich PHP (wie so oft) in die richtige Richtung. Aus der Spaghetti-Sprache für blinkende Vereinshomepages ist mittlerweile eine Feature-H*re geworden, die neben neuen Features rechtzeitig auch über Konsolidierung nachdenken sollte – auf Abwärtskompatibilität muss man eben manchmal verzichten.

Natürlich ist das neue zentrale .svn-Metadata-Verzeichnis bereits für sich eine große Sache. Aber auch die interne Struktur der Metadaten hat sich verändert: Komprimierte Ablage von Daten (hat git auch), Hashes auf Datei-Inhalte (hat git auch), damit auch die Verwendung von Referenzen bei gleichem Inhalt (hat git auch) und in der nächsten Version soll es wohl auch Stashes (temporäre Änderungs-Speicher) unterstützen – das hat git bereits.

Dann gibt es noch ein Feature namens Merge-Infos, die sich verbessert haben sollen. Hatte ich nie benutzt, ich weiß also nicht, was diese Merge-Infos bringen. Vom Namen her wüsste ich aber ungefährt, dass ich mir bei Git einen diff der beiden Vorgänger-Versionen zum Merge-Commit anschauen könnte, um eine “Info” über einen “Merge” zu bekommen. Und, das klingt auch toll: In-Memory-Caching auf SVN-Server-Seite. Das klingt tatsächlich schwer bei git umsetzbar, schließlich kann man das git-Protokoll oder http benutzen, muss aber nicht, und über ssh doch gehts auch. In der letzten Situation würde der In-Memory-Cache nicht ziehen, höchtens aufwändig zu invalidieren sein.

Noch ein Feature heißt “Optimierte Netzwerkübertragung”, vorrangig durch Komprimierung. Hier habe das Gefühl, das müsste git bereits so umsetzen, denn die Daten werden ja im Repo bereits komprimiert abgelegt, ganze ungeänderte Subtrees werden nur als Referenz von Revision zu Revision übernommen und wer mal auf einen aufwändigen Übertragungsprozess geschaut hat, sieht auch, wie vor der Übertragung ermittelt wird, welche Daten tatsächlich über den Äther müssen.

Also alles in allem habe ich den Eindruck, Subversion wird immer gitter. Ketzerische Frage meinerseits folglich: Warum traut sich das Subversion-Team nicht, SVN einfach wegzuwerfen und ihre Fähigkeiten im Git-Team einzubringen? Das wäre doch mal der berühmte Sprung über den Schatten. Oder braucht man tatsächlich zwei (inkompatible) Versionskontrollsysteme, von denen das eine die Fähigkeiten des anderen Stück für Stück nachprogrammiert?

Nachdem man jahrelang Kunde war, bekommt man als Verlängerungsbonus überteuerte “Smartphones” zum Abbezahlen. Meine Reaktion darauf war die Kündigung.

Sehr witzig: Seitdem ruft mich der Kundenservice jeden Tag persönlich an. Ich sagte Eplus zwar, dass ich das nicht möchte, aber sie probieren es trotzdem jeden Tag neu. Wenn das so weitergeht, schick ich das Anrufprotokoll mal an die Verbraucherzentrale. Die finden sowas auch immer sehr witzig.

Ein Grund mehr, Netzwerk-Verbindungen nicht im Desktop, sondern in /etc abzufackeln – warum sollte ein gewöhnlicher Nutzer einen Rechner in ein fremdes Netzwerk schleusen dürfen? Viel zu riskant, sagt da der Admin! Auf der anderen Seite nicht ganz so zeitgemäß. Der Trend geht eher zum Zweitrechner, und es gibt wohl mehr Rechner als Root-Accounts auf dieser Welt. Jeder ist also Root, und deshalb darf auch jeder seinen Rechner im Desktop dahin einstöpseln, wovon ihn sowieso nur noch ein beherztes sudo trennt.

Um das nervige Problem zu beenden, habe ich mir heute ein eigenes shutdown-Script geschrieben, welches myshutdown heißt und unter /usr/local/bin liegt. Es umountet also erst alle aktiven CIFS-Drives und beendet dann den Rechner per shutdown -h now. Zugegebenermaßen ein sehr krudes Mittel, weil KDE natürlich auch gern sauber beendet werden möchte, aber man kann es leider nicht allen recht machen.

#!/bin/bash

MNT=`mount | grep "type cifs" | cut -d' ' -f 3`
for mntpoint in $MNT
do
        umount $mntpoint
done

/sbin/shutdown -h now

Das ganze Script mit chmod a+x,u+s für alle ausführbar machen und wer will, kann das noch in die /etc/sudoers eintragen:

nudge   ALL=(ALL) NOPASSWD:/usr/local/bin/myshutdown

Das ganze kann man dann per khotkeys auf das KDE-Standard-Shutdown-Kürzel Strg + Alt + Bild runter mappen. Und schon gehts tierisch schnell ab in den Keller mit dem Rechner. Keine Timeouts beim Abwarten auf ein CIFS-Drive ohne Netzwerk mehr – hier sind 300 Sekunden Timeouts nicht Ungewöhnliches.

Witzig ist bei Dual-Stack immer die Vorstellung, IPv4 und IPv6 ist wie warmes und kaltes Wasser aus einem Wasserhahn…

Master of Desaster

Zunächst ist es wichtig zu wissen, was das führende System ist. In einem IT-Unternehmen werden das sicherlich keine Papierzettel sein, sondern ein Ticket-System. Im Ticket-System, bei uns das JIRA, liegen die Aufgaben alle elektronisch vor und sind immer auf dem aktuellen Stand (offen, erledigt, abgelehnt etc). Man könnte also durchweg auch nur im JIRA arbeiten. Dort gibt es zum Beispiel seit den letzten Versionen auch agile Ansichten wie Boards und Burndown-Charts. Eins unserer Teams arbeitet zum Beispiel nur im JIRA und führen damit Standups durch.

Scrum-Standups

Die Standups nach Scrum verlaufen so: Alle Team-Mitglieder versammeln sich im Stehen. Das Stehen ist wichtig: Wenn einer stehmüde wird, ist das Meeting zu lang. Der Reihe nach beantworten alle Entwickler folgende drei Fragen:

1. Was habe ich gestern gemacht?
2. Was werde ich heute tun?
3. Was könnte mich davon abhalten?

Die letzte Frage benennt Schwierigkeiten, die der Projektleiter gleich mitnehmen kann, um diese, gegebenenfalls organisatorisch, zu lösen.

Standups synchronisieren also die Team-Mitglieder. Jeder weiß Bescheid, jeder braucht nur 3 Minuten, und der Tag kann beginnen. Voraussetzung ist natürlich, dass der Projektleiter, bei Scrum hier der Product Owner,  das Backlog (die Sammlung offener nächster Aufgaben) sauber aufbereitet und priorisiert hat. Das Backlog ist vor einem Sprint, also einem abgeschlossenen Entwicklungszyklus, mit dem Team zusammengestellt worden. Jeder kennt also den Umfang und die Zeitdauer der aktuellen Entwicklung. Jeder der Entwickler sollte zu 100% an diesem Projekt arbeiten.

Kanban-Boards

Anstatt wie bei Scrum eine fixe Zeitdauer, das Timeboxing, zu verwenden, setzt Kanban eher auf eine Optimierung des Arbeitsflusses, dem Workflow. Es eignet sich daher sehr gut für Teams, die an vielen Projekten kleinere Dinge umsetzen, wo man keine sauberen Sprints aufsetzen kann. Zum Beispiel das Thema Support kann damit gut unterstützt werden. Auch hier ist wichtig, dass der Projektleiter die Tickets vorher im Backlog priorisiert und eventuelle Unklarheiten in den Anforderungen auflöst. Im Gegensatz zu Scrum ist es aber nicht wichtig, periodisch über die nächsten Tickets zu sprechen: Ist die Zeit reif, d.h. Zeit für ein neues Ticket vorhanden, wandert es einfach durch den Workflow der Entwicklungsphasen: Entwicklung, QA, Test, Deployment oder ähnliches  - diese Phasen muss jedes Team für sich selbst finden.

Statt in einem PUSH-Verfahren die Tickets in die nächste Phase zu geben und einem Bearbeiter zuzuweisen, setzt Kanban auf ein PULL-Prinzip: Tickets werden immer im Prozess von rechts nach links abgearbeitet. Ein Kanban-Board visualisiert diese Phasen für alle. Hier nimmt man den Overhead, Tickets nochmals auf Papier zu bringen, in Kauf, um die Synchronisation des Teams deutlich zu erleichtern. Außerdem erlaubt das Board, sich auf die im Moment wesentlichen Dinge zu konzentrieren. Das geht eventuell bei verteilten Teams vielleicht nicht besonders gut. Für Teams aber, die im gleichen Raum sitzen, ist ein Kanban-Board eine schöne und motivierende Sache. Ein Ticket umzuhängen, ist gleichermaßen Belohnung für die getane Arbeit wie auch Ansporn für andere, die Fackel der Wertschöpfung weiterzutragen.

Scrum-Standups im Kanban-Workflow

Das Magento-Team von Netresearch führte die Standups bisher nach Scrum durch. Wir standen vor dem Kanban-Board und sagten unsere Sprüchlein auf. Allerdings gab es immer kleine Hakeligkeiten: Wenn ein Entwickler sagte “Heute hätte ich das vor.”, so interventierte ich als PL oft mit “Warte mal, da wäre glaube ich dies hier wichtiger.” oder “Das sollte eigentlich er machen.” Grund ist, dass dieses Jeder-Nacheinander die nächsten Aufgaben verplant, obwohl noch nicht alle wissen, wer was am Vortag gemacht hat und wie der aktuelle Teamstand ist. Daher sollten zunächst alle den gestrigen Tag Revue passieren lassen, bis wir wissen, was tatsächlich die wichtigste Aufgabe des Tages ist. Auf Kanban-Boards bedeutet das, die Tickets an die richtige Stelle zu bringen. Außerdem ist bei Kanban das Pull-Prinzip führend vor der Sicht, was jeder einzelne Entwickler tut. Die Beantwortung der Scrum-Fragen führte dazu, dass wir auf verschiedene Tickets am Board zeigten – letztlich blieb so der Überblick oft vermisst. Wir brauchten wiederum kleine Notizblöcke, in denen jeder seine Tagesaufgaben notierte (das mag in Situationen, wo nur 1 Projekt vorherrscht, kein Problem sein).

Die erste Frage des Tages sollte also reihum lauten: Wer tat was? Im Kanban-Prinzip von hinten nach vorn durchgehend, wird die Ticket-basierte Vorgehensweise zu einem “Wer tat es?“. Der letzte Bearbeiter eines Tickets kann kurz dazu etwas sagen, zum Beispiel Schwierigkeiten benennen. Und die nächste Frage muss folgerichtig lauten: “Wer tut es?“, also wer wird dieses Ticket weitertragen? So kommt derjenige Wert, welcher im Prinzip schon fast beim Kunden ist, als erstes Aufmerksamkeit. Ein fertig entwickeltes und getestetes Ticket wird zum Beispiel ausgerollt. Und das sorgt wiederum sowohl für Freude beim Kunden als auch für eine Kopfklarheit der Entwickler: Dinge eher abschließen und sich auf die nächsten Schritte konzentrieren können.

Das Board ist also eine Art Mikrokosmos, ein Ausschnitt aus dem riesigen Universum des Ticket-Systems. Für die Position dieser Konzentrations-Lupe ist der Projektleiter zuständig, er steuert die Tickets in das Board ein und verarbeitet sie danach weiter: Kunden oder Geschäftsführung informieren, Abrechnungen triggern, die nächsten Schritte mit dem Kunden absprechen oder schlicht Projekte und Sprints im Ticket-System schließen. Wohlbemerkt ist der Entwickler natürlich angehalten, das Ticket im Ticket-System stets aktuell zu halten: beispielsweise das Setzen des Ticket-Status, zum Loggen von Notizen, der Zeiterfassung oder Ablage von Mails an und vom Kunden.

Übersicht inklusive

Während der Benennung von “Wer tut es?” schreiben wir rechts an einer freien Stelle am Board mit, welcher Entwickler welche Tickets bearbeiten wird. Dadurch entstehen kleine Listen der Tagesaufgaben pro Team-Mitglied. Jeder belohnt sich selbst mit kleinen Häkchen daneben und machen es mir als Projektleiter am nächsten Tag ganz einfach, eine Art Mini-Controlling durchzuführen. Tickets, die nicht bearbeitet wurden, falls deutlich schneller auf. Mit denen muss irgendetwas nicht stimmen – ein wichtiger Impuls für mich als Projektleiter. Der spürbare Effekt in der Runde ist, dass die Standups nicht mehr so stagnieren, sondern spielerischer, konstruktiver Natur sind. Und das macht richtig Spaß.

Inhalt: Die Kernaussage von Sam Carpenter in Work the System ist – wie naheliegend – dass alles ein System ist. Und die meisten Systeme bestehen aus Subsystemen. Systeme laufen meist linear ab, und das oft wiederkehrend. Anstatt also jedes Mal “Feuer zu löschen”, wenn Probleme unerwartet auftauchen, sollte man diese gleich bei der Wurzel packen. Das bedeutet, das Gesamt-System gedanklich zu zerlegen, jedes einzelne der Sub-Systeme zu analysieren, zu reparieren oder auszutauschen und es auf Hochperformance zu polieren, so dass es in Zukunft nachhaltig und perfekt läuft. Danach funktioniert das Gesamtsystem wieder ein Stück besser. Man gewinnt so mehr Zeit für kreative und wundervolle Dinge, weil die Feuer an dieser Stelle nicht mehr ausbrechen können. So kann man sich der eigentlichen Arbeit – der Weiterentwicklung des Gesamtsystems – widmen. Statt passiv einem Feuer nach dem anderen hinterherzurennen, wird man wieder proaktiv und kümmert sich um das System-Management.

Eignung: Empfohlen wurde mir das Buch von Michal, meinem Kollegen. Er interessiert sich auch wie ich für Theorien zu Organisationen und persönlicher Weiterbildung. Ich war zunächst etwas abwartend, da die Kernaussagen mir etwas einfach erschienen, oft wiederholt wurden und sich schnell herunterlasen. Erst nach und nach entpuppte sich der Effekt, der mich verblüfft hat. Das Buch kann nach diesem Erlebnis jedoch nur weiterempfehlen. Für wen könnte es interessant sein? Nun, ich setze es als Projektleiter vor dem Hintergrund “Software-Entwicklung” ein, habe aber auch schon private Sub-Systeme zerlegen können. Es ist vielleicht auch für Leute interessant, die merken, dass ihr Studium oder Hobby, Gesundheit oder Job, eine Organisation zum Beispiel, nicht ganz rund läuft.

Sprache: Das Buch “Work the system” soweit mir bekannt, nur auf Englisch verfügbar. Die Sprache hier kann man aber auch mit mäßigen Englischkenntnissen und dict.leo.org gut lesen, es ist in einem gut fließenden, einfachen Ton geschrieben. Das passt auch zum Inhalt, den Sam Carpenter auch als “Workingman’s Philosophy” beschreibt. Es lohnt sich, das Buch in einem Mindmapper festzuhalten. Ich bin mal gespannt, was noch im Buch kommt.

Hinweis: Es ist ein Buch, welches sich mit dem Thema Effizienz beschäftigt. Man sollte sich erst mit Effizienz beschäftigen, wenn man weiß, was man will. Letzteres erfährt man eher im Bereich Effektivität. Dazu gibts auch ganz gute Bücher, die ich Euch vielleicht noch vorstellen könnte. Also bleibt dran.

Dabei war MySQL seit Jahren berühmt für seine unkomplizierte, initiale Geschwindigkeit, die andere Datenbanken erst durch einen ganzen Beraterstab und viel Cluster-Foo erreichten. In diesem Sinne hat auch MySQL zum Erfolg des Internet beigetragen: Wieviele Foren, Blogs, Boards und Websites laufen nicht auf einer kleinen MySQL? Wenn MySQL später als Version Oracle 13m erscheinen wird, hat diese Linie ein Ende gefunden.

Die verschiedenen Clones dagegen kämpfen derweil mit organisatorischen Schwierigkeiten oder dem zerrissenen Publikum. Jedes der Projekte bietet eine eigene Welt von Vor- und Nachteilen. Damit ist keine gesunde Community vorhanden, die die Software zum Wachsen braucht. Es wäre Zeit, diese zu einem freien Pendant wieder zusammenzuführen. Dass es funktionieren kann, zeigt LibreOffice: Mit zügigen Releases wurde auf technischen Vorteil gesetzt, während in Villa Bajo noch Aktien gezählt wurden. Ich bin überzeugt, OpenOffice wird eines Tages wieder in LibreOffice eingegliedert.

PS: Wer das maximale aus seiner MySQL herausholen will, sollte sich unbedingt meinen Buch-Tipp hier rechts anschauen. Dieses dicke Ding ist voll von Erleuchtungen für den Performance-Jünger!