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!

Ansonsten kann ich den Vorschlag von Scott Remnant nur begrüßen: Persönlich möchte ich nie wieder ein System benutzen, bei dem ich jedes halbe Jahr um die Gesundheit meines Rechners bangen muss.

Was hat sie bewogen, dies zu tun? Weil es Trend, schick oder nerdy ist? Oder sehen sie auch langsam ein, dass sie nicht wirklich Schritt halten können mit Googles Entwicklungs-Geschwindigkeit? Immer mehr Hersteller, darunter auch HTC, öffnen nun ihre Bootloader von den Sperren oder erlauben explizit sogar Custom ROMs für ihre Geräte. Davon kann sich Apple für’s iPhone 4 noch eine Scheibe abschneiden. Ist also alles in Butter?

Leider hat diese im Grunde positive Entwicklung zwei kleine Schmutzflecken: Erstens haben die Hersteller diesen Weg oft nur nach massiven Protesten ihrer User beschritten, und zweitens bleiben ältere Gerätegenerationen schamlos außen vor. So auch das HTC Desire, welches ich mein eigen nennen darf. Nach etwa einem halben Jahr Besitz schon auf dem Abstellgleis gelandet? Das habe ich mir anders vorgestellt. Wer kauft sich schon ein niegelnagesneues Telefon, nur um ein Update zu erhalten?

Wer die Entwicklung nicht verfolgt hat, kann sie in der Zusammenfassung auf androidnews.de nachlesen. Generell spielte HTC, die vor zwei Jahren mit viel Tamtam ihre überarbeitete Sense-Oberfläche als großen Knüller für Social Networking präsentierten, mit den Update-Gefühlen ihrer Desire-Gerätebesitzer Ping-Pong. Kurzfassung: Nein, Gingerbread kommt nicht, ja, doch, kommt, hmm nee, geht nicht wegen RAM, oh, eventuell abgespeckt, ja dann Ende Juli, hmm, es ist ja schon August, [schweig......]

Ein Custom-ROM kam für mich erst einmal nicht in Frage. Ich wollte updatefähig bleiben, hatte einige Apps gekauft, deren Daten ich auch nahtlos benötige. Als der Leidensdruck groß genug war, stellte ich bei der Installation des CyanogenMod fest, dass mein Bootloader auch noch eine Version hatte, sodass ich für das Patchen einen Sonder-Patch für den eigentlich Patch benötigte. Das war mir dann doch etwas zu heiß. Die darauffolgende Ansage von HTC, Gingerbread Ende Juli mit nur abgespeckter Sense-Oberfläche zu liefern, war für mich dann eher Freude als Trauer: Der knappe RAM des Desire wäre mit einer Plain-Vanilla-Android-Variante wie beim “Original” Nexus besser bedient. Wer braucht schon Sense?

Nach zwei Wochen völlig netz-apathischer Urlaubszeit trimmte ich mich dann zur Update-Check-Orgie Ende Juli ein. Nichts, nichts, und wieder nichts. Enttäuschend! Und keine Meldung zu Gingerbread seitens HTC in Sicht. So bleibt mir nichts anderes übrig, als täglich neu zu hoffen und wie Götzi zu trällern: Sag mir Quando, sag mir wann…sag mir quando, quando, quando…

“This is the third update to the stable version of LibreOffice.
It contains only safe code fixes and translation updates, and is considered safe for production use.”

Außerdem verweist das Projekt an dieser Stelle auf Ungereimtheiten mit der Java-Umgebung von Sun (jetzt Oracle). Es wäre daher besser, OpenJDK zu verwenden. Um auf dieses umzustellen, verwendet man am besten update-alternatives:

$ sudo update-alternatives --config java

Es gibt 4 Auswahlmöglichkeiten für die Alternative java (welche /usr/bin/java bereitstellen).

  Auswahl      Pfad                                      Priorität Status
------------------------------------------------------------
  0            /usr/lib/jvm/java-6-openjdk/jre/bin/java   1061      Auto-Modus
  1            /usr/bin/gij-4.4                           1044      manueller Modus
  2            /usr/bin/gij-4.6                           1046      manueller Modus
* 3            /usr/lib/jvm/java-6-openjdk/jre/bin/java   1061      manueller Modus
  4            /usr/lib/jvm/java-6-sun/jre/bin/java       63        manueller Modus

Drücken Sie die Eingabetaste, um die aktuelle Wahl[*] beizubehalten,
oder geben Sie die Auswahlnummer ein:

Sollte das Sternchen anders gesetzt sein, so wählt man hier im Beispiel die 3 und bestätigt das durch Enter. fertig.

Update: Mittlerweile ist die Version 3.3.4 erschienen.

Aber heute hat der Linux-Kernel den Versionsstand 3.0 erreicht. Nachdem ich die letzten Wochen fast täglich auf www.kernel.org schaute, kam heute morgen endlich per heise.de die Erlösung: Er ist fertig. Allerdings steht er noch nicht zum Download bereit.

Wer jetzt denkt, der neue Kernel ist ca. 1,5 mal so groß wie der letzte, wird enttäuscht: Die Serie 2.6.x findet vom letzten stabilen Kernel 2.6.39.3 einen (fast) nahtlosen Übergang, der neue Kernel ist also im Prinzip 2.6.40. Nur fast, weil die Änderung der Länge der Versionsnummer nicht ganz unproblematisch war – oder vielleicht noch ist. Und um das Thema abzurunden: Auch Microsoft erscheint in der Liste der Firmen, die sich recht aktiv an der Entwicklungsarbeit beteiligten. Allerdings wurde hier angemerkt, dass die vielen Commits eher kleinere Änderungen am eigenen Hyper-V-Modul waren.

Sobald er auf www.kernel.org erscheint, werde ich zwei Rechner damit ausstatten. Dank der offiziellen Debian Kernel Configs (die zumindest auf Stand 2.6.38.2 sind) ist so ein eigens gebackener Kernel auch keine zeitraubende Konfigurationsarbeit mehr. Ich werde dann von meiner Erfahrung mit der Stabilität berichten.

Stay tuned!