[Quicktip] Jenkins zeigt keine Trend Grafiken für Checkstyle, phpmd usw. an

Wenn ihr im Jenkins einen Job auswählt, der eigentlich die Ergebnisse von Checkstyle, phpmd usw. auswerten und anzeigen sollte – ihr aber keine tollen Diagramme sondern nur irgendwelche „headless“ Fehlermeldungen seht:

Installiert mittels

sudo apt-get install ttf-dejavu

die Font ttf-dejavu.

Nachdem die Schriftart installiert ist und Jenkins neu gestartet wurde, sollte Jenkins die Verlaufsdiagramme korrekt generieren und anzeigen.

[Quicktip] Symfony2 Framework läuft nach Update auf Version 2.3.3 nicht mehr

Nachdem ich eine Symfony2 Installation auf die neueste Version 2.3.3 per Composer geupdatet hatte, bekam ich auf dem Zielsystem per app/console immer wieder die Fehlermeldung

[Symfony\Component\DependencyInjection\Exception\InvalidArgumentException]
  The parameter "kernel.trusted_hosts" must be defined.

präsentiert. Scheinbar haben diesen Fehler nicht allzu viele Leute, eine Google Suche brachte keine Ergebnisse. Die Formulierung der Fehlermeldung ist auch relativ ungünstig, denn es fehlt kein Parameter, sondern ein Config Eintrag. Kurz gesagt, müsst ihr folgende Zeile in euere app/config/config.yml Datei eintragen:

...
framework:
    ...
    fragments:       ~
    trusted_hosts:   ~
...

Anschließend sollte die Symfony2 Console sowie das System an sich wieder laufen.

[Quicktip] Symfony2 bringt weiße Seite und keinen Eintrag in den Error Logs

Wenn auch euch dieser Fehler begegnen sollte und ihr nicht mehr weiter wisst: prüft, ob in euren Config Dateien (bei mir war es die service.yml) die Keys (also z.B. der Name eines Service) ungültige Zeichen enthalten – wie z.b. Bindestriche 😉

Eine kleine Einführung in die Technik des Pair Programming

Meinem Arbeitgeber ist Fortbildung und Wissenserweiterung/-auffrischung sehr wichtig. Und deshalb gab es vor einigen Wochen einen Workshop zum Thema Pair Programming, einer Teilmenge von XP, also dem Extreme Programming.

Die Thematik Pair Programming war mir schon länger geläufig, allerdings hatte ich zum Teil völlig falsche Vorstellungen davon und mir waren die Konzepte dahinter völlig fremd. Pair Programming ist eben nicht nur der Zustand, dass ein Programmierer am Rechner sitzt und ein zweiter ihm ständig über die Schulter schaut und kommentiert. Es geht viel mehr darum, dass der Code wirklich gemeinschaftlich entsteht und vor allem nicht ein Entwickler arbeitet und der Partner sich langweilt.

Grundlagen

Die Idee des Pair Programmings basiert auf dem Driver-Navigator Prinzip, welches man aus dem Rally Sport kennt. Der Fahrer ist vom Beifahrer abhängig, der Beifahrer wiederrum vom Fahrer. Und: dadurch, dass beide zusammen arbeiten, sind sie effizienter. Der Fahrer kann sich voll und ganz auf die aktuelle Situation einstellen und seine komplette Energie in die optimalste, derzeit angebrachte Fahrweise stecken. Der Beifahrer hingegen hat den Überblick über das große Ganze. Er kennt die ganze Strecke in- und auswendig. Da er sich nicht primär um die aktuelle Situation kümmern muss, kann er ruhig Ansagen für kommende Ereignisse machen.

Das gleiche Prinzip kommt im Pair Programming zum Einsatz: der Programmierer an Tastatur und Maus ist der Driver, der Programmierer neben ihm der Navigator. Der “Driver” kümmert sich um die aktuelle Problematik, der “Navigator” behält die Überblick über die komplette oder aber zumindest die übergeordnete Problematik. Außerdem führt er nicht den gleichen Gedankengang wie der Driver aus, was ihm ermöglicht, evtl. Fehler eher zu erkennen oder auf kommende Fehler hinzuweisen.

Die 7 Säulen des Pair Programmings

Man kann die Grundsätze des Pair Programmings auf 7 Säulen aufteilen. Die Säulen verdeutlichen, welche Vorteile Pair Programming gegenüber anderen Konzepten hat:

pair pressure – sich gegenseitig fokussieren und andere wegschicken bzw. Ablenkungen aus der Welt schaffen.

pair negotiation – das gegenseitige Sparring bzw. die gegenseitige Verbesserung durch ständiges direktes Feedback.

pair courage – den Mut, Dinge und vor allem Code zu ändern. Stichwort Refactoring.

pair review – Das ständige Reviewen des Codes.

pair debugging – Vier Augen sehen mehr als zwei – vor allem beim Debugging!

pair learning – das voneinander Lernen und der somit entstehende Wissenstransfer.

pair trust – das Vertrauen zum partner und auch in seine Methoden.

Wissensstufen

Ein wichtiger Aspekt des Pairings ist die Zusammenstellung des Paares. Diese ist abhängig von den verfügbaren Programmierern (und ihren Charaktereigenschaften), aber auch von der zu lösenden Aufgabe. Man kann den Erfahrungsgrad hierzu in 3 Gruppen, die sich aus dem Japanischen Kampfsport ableiten, unterteilen:

Shu, Ha und Ri

Wenn man die 3 Worte bzw. Silben von vorn nach hinten liest, hat man schon die Klassifizierung. Wichtig hierbei ist: JEDER Programmierer wechselt im Laufe seiner Karriere zwischen diesen Gruppen immer wieder hin und her.

Die “Shu” sind Einsteiger bzw. Juniors. Hierbei geht es nicht unbedingt nur um die allgemeinen Programmierskills – auch wenn ein “Ha” oder “Ri” eine komplett neue Sprache oder ein neues Framework kennen lernt, dann ist er zunächst wieder ein “Shu”.

Die nächste Stufe, “Ha” genannt, umschreibt den Zustand, dass man sich mittlerweile schon gut zurecht findet, die neue Sprache oder das Framework oder was auch immer bereits sehr gut beherrscht und die ersten Regeln in Frage stellt. In diesem Stadium baut man stark an Wissen auf.

Wenn man die Stufe “Ri” erreicht hat – und dafür braucht man mindestens ca. 10.000 Stunden Arbeit im jeweiligen Themengebiet – dann ist man an der Spitze angekommen. Auf diesem Level gelten so gut wie keine direkten Regeln mehr – denn diese sind bereits in das Unterbewusstsein übergegangen. Für zu bewältigende Aufgaben findet man so gut wie immer die eleganteste Lösung – nicht zwangsweise auf Basis von Patterns – sondern wirklich die optimale Lösung. Daher: Losgelöst von den Regeln, aber indirekt doch basierend auf ihnen.

Paar-Kombinationen

Nachdem nun die Grundlagen soweit verstanden sind, kommt es zur Anwendung. Ein wichtiger Faktor des Pair Programmings ist die Kombination der Partner – basierend auf ihrer Klassifizierung.

In der Regel sollte man darauf achten, dass zwischen den Partnern eine Wissens-Stufe liegt – das hat den Effekt, dass der Entwickler mit dem geringeren Wissensstand besser Wissen aufbauen kann. Für den Partner in der höheren Klasse dient diese Konstellation als weitere Festigung des Wissens.

Sollte man an eine wirklich brenzlige Stelle mit großem Impact für das Projekt oder die Firma kommen, kann man auch auf die Kombination “Ri” – “Ri” setzen. Diese wird aller Wahrscheinlichkeit nach zu einer sinnvollen und schnellen Lösung des Problems führen, jedoch sollte hier beachtet werden, dass Leute dieses Kaliebers nicht zu lange im Paar arbeiten. Gurus arbeiten im Allgemeinen auch eher allein 😉

Sprünge über 2 Klassen, also die Kombination “Shu” – “Ri”, machen nur selten Sinn. Der Unterschied ist sehr enorm und es besteht die Gefahr, dass der “Shu” den “Ha” Level mehr oder weniger überspringen und sich direkt über bestimmte Grenzen hinweg setzen möchte. Für kürzere Zeiträume kann man diese Kombination allerdings für die komprimierte Wissensweitergabe verwenden.

Sind alle 3 Klassen in einem Team vertreten, so kann evtl. auch ein “Shu” – “Shu” Paar Sinn machen. Der Wissenstransfer ist sicher nicht so hoch wie in anderen Konstellationen, allerdings lernt es sich zusammen immerhin leichter als allein und diese Kombination führt dazu, dass man die Nerven der erfahreneren Entwickler schonen kann.

Feedbackschleifen

Ein wichtiges Element in der Entwicklung sind sogn. Feedbackschleifen – also die Zeit, in der ein Entwickler mehr oder weniger das tut, was er für richtig hält, ohne dass es der Kunde oder jemand anderer sieht und beurteilt. Bleibt man im Feld der agilen Entwicklung, dann gibt es dort 2 Feedbackschleifen: Den Sprint (7-14 Tage) und das Daily Standup (1 Tag). Je kleiner die Feedbackschleife wird, desto weniger Fehlentwicklungen können auftreten, da schnell interveniert werden kann.

Wenn man nun ins Pair Programming einsteigt, dann kommt eine weitere Feedbackschleife hinzu, die jedoch im Minutenbereich liegt. Egal, was man gerade codet – der Partner sieht es und kann und wird es umgehend beurteilen sowie kommentieren. Diese extrem verkürzte Feedbackschleife vermindert sehr stark Fehlentwicklungen, zumindest auf Codeebene. Auch werden so sehr schnell Verständnisprobleme der Aufgabenstellung sichtbar.

Zusammenfassend kann man sagen: je mehr Feedback man bekommt, desto besser kann man sich entwickeln – je länger der Zeitraum bis zum nächsten Feedback ist, desto länger kann man auf dem falschen Weg unterwegs sein.

Vorgehensweise

Kommen wir abschließend zum eigentlichen Vorgehen – denn darum liest du diesen Artikel ja 😉

Um jegliche Ablenkung zu minimieren, setzen sich beide Entwickler an EINEN Rechner. Um die Zusammenarbeit zu optimieren, sollte man das System mit 2 Monitoren betreiben, die beide das gleiche anzeigen. So hat jeder Entwickler den bestmöglichen Blick auf das Geschehen. Wichtig hierbei ist: es gibt nur eine Maus und eine Tastatur, die zu einem Zeitpunkt bedient wird! Für einen einfacheren Wechsel zwischen den Rollen des Drivers und des Navigators kann man gern eine zweite Maus und eine zweite Tastatur anschließen.

Für unser Beispiel haben wir den Driver “Tom” und den Navigator “Paul”.

Der Driver Tom beginnt nun damit, einen Unit Test zu schreiben, der natürlich gleich brechen wird. Nun übernimmt Paul (er wird zum Driver) und schreibt die zu bearbeitende Funktion oder Klasse so, dass der Test nicht mehr bricht. Dies geschieht auf einem extrem simplen Niveau! Beispiel:

Test:

function testMethod() {
	assertTrue(method());
}

Der ausgeführte Test wird brechen, weil es die aufzurufende Methode noch gar nicht gibt – und wenn es sie doch geben sollte, dann ist sie leer und liefert keinen Rückgabewert.

Hier nun die zugehörige Funktion, die Paul darauf hin geschrieben hat:

function method() {
	return true;
}

Der Test läuft nun erfolgreich durch. In der nächsten Iteration wechseln beide wieder und Tom muss nun den Test so umbauen, dass er dem gewünschten Ergebnis wieder näher kommt. Er baut den Test so lange um, bis er wieder bricht. Dann wird wieder gewechselt und Paul muss dafür sorgen, dass seine “method” das vom Test gewünschte Ergebnis liefert.

Diese Vorgehensweise wird auch Test Driven Development genannt. Man macht sich erst Gedanken über den Test, der beweisen soll, dass die Funktion so läuft wie erwartet. Und erst anschließend wird die eigentliche Funktionalität implementiert.

Im Bezug auf das Pair Programming nennt man diese Vorgehensweise “ping pong pair programming”. Der Vorteil dieser Methode ist, dass man sich langsam an das Ziel herantastet. Jeder Entwickler kennt den Zustand, in dem man eine Implementierung gleich im ersten Zug baut, sich völlig verzettelt und von vorn beginnen muss. Genau diese Entwicklung soll an dieser Stelle verhindert werden. Man beschäftigt sich eben nicht mit dem großen ganzen, sondern tastet sich über kleine Iterationen immer näher an eine bessere Implementierung. Durch immer wieder einsetzendes Refactoring wird der Code somit immer weiter verbessert und optimiert.

Fazit
Ich möchte den Artikel an dieser Stelle erstmal beenden, weil im Prinzip auch schon alles gesagt ist. Die Hauptaufgabe, nach erlernen der Grundlagen, liegt nämlich in der Übung. Hierbei sollte man darauf achten, dass man den Partner ab und zu mal wechselt, um konstant neue Einflüsse auf die eigenen Skills zuzulassen.

Eine Problematik bleibt allerdings noch offen: wie verkaufe ich das meinen Kunden? Dabei handelt es sich in der Tat um einen der schwierigsten Aspekte. Man darf beim Pair Programming keinesfalls davon ausgehen, dass zwei Entwickler an einer Aufgabe auch doppelt so schnell entwickeln – wobei man diese Denkweise in der Programmierung allgemein unterbinden sollte, denn: 9 Frauen bringen ja auch nicht ein Baby in nur einem Monat zur Welt 🙂

Was man dem Kunden allerdings verkaufen kann, ist die effektivere Problemlösung und die bessere Verteilung von Wissen. Dies ist besonders interessant, wenn man mit Entwicklern des Kunden zusammen arbeitet. Ein weiteres, sehr wichtiges Argument, ist die bessere Code Qualität und geringere Bug-Anfälligkeit. Durch das ständige Code-Review können Flüchtigkeitsfehler stark vermindert werden, was für weniger Frust auf Seiten des Kunden als auch der Entwickler sorgt.

Abschließend sei gesagt: Probiert es aus! Pair Programming bringt euch als Entwickler deutlich weiter und es macht auch noch extrem Spaß.

Zend Certified Engineer

Seit heut darf ich mich nun offiziell Zend Certified Engineer nennen. Vor ein paar Wochen musste ich dazu eine ziemlich knackige Prüfung mit größtenteils Multiple Choice Fragen ablegen. Auch wenn dies auf den ersten Blick leicht erscheint – man gibt sich bei Zend alle Mühe, dass der Proband ziemlich in die Irre geführt wird.

20120405-220132.jpg

Bei meiner Vorbereitung hat richtig gut unterstützt hat mich das Buch “Zend PHP5 Certification Study Guide” von Davey Shafik und Ben Ramsey. Allen zukünftigen Prüflingen kann ich das Buch nur ans Herz legen.

Readme driven Design – das etwas andere Pattern

Letzte Woche fiel mir ein sehr interessanter Beitrag (How I Develop Things and Why) zum Thema Entwicklungsstil in die Hände. Der Autor, Kenneth Reitz, vertrat dabei die Meinung, dass man alles sinnvoll designen sollte. Das mag jetzt zwar logisch klingen, ist es aber nicht. Wenn Entwickler von Design sprechen, dann ist meist das Design für den Endkunden gemeint. Die gleichen Regeln sollten aber auch für alle anderen gelten. Sprich, auch ein API oder eine Library sollte intuitiv und nutzerfreundlich sein.

Keneth, selbst ein bekennender Python Fan, geht darauf am Beispiel der http Library für eben diese Sprache ein. Sie tut zwar was sie soll, nervt den Entwickler aber mit unzähligen kryptischen Parametern und viel Schreibaufwand für einfachste Aufgaben. Um diesen Umstand zu verbessern, hat er eine Library geschrieben, die als Schnittstelle zwischen dem Entwickler und der ursprünglichen Library sitzt – spirch, ein Wrapper.

Und somit kommen wir zum Kern dieses Beitrages: Als Designphilosophie für diesen Wrapper wählte er das “Readme driven design”. Häh? So in etwa habe ich auch geschaut, als ich es zum ersten mal las. Das Prinzip ist aber recht sinnvoll: in der normalen Entwicklung fängt man mit einer simplen Idee an, baut das entsprechende API und alles ist toll. Nachdem die Grundfunktionen stehen, erweitert man das ganze, passt das API ein bisschen an, refactored ein bisschen, wieder wird das API angepasst usw. Irgendwann hat man zwar eine Library (bzw. ein Tool), die alles mögliche kann, was aber wiederum mit dem ursprünglichen API-Design nicht mehr realisierbar gewesen wäre. Heraus kommt dann ein Konstrukt aus undurchsichtigen Parametern und umständlichen Vorgehensweisen, um das gewünschte Ergebnis zu erhalten.

Die bessere Alternative ist nun folgende: man schreibt zuallererst die Readme Datei inkl. ausführlicher Syntax und Beispielen – genau so, als ob das Stückchen Software bereits existieren würde und fertig wäre. Und erst dann beginnt man mit der Umsetzung. Der Vorteil ist nun, dass man das API so designt hat, wie man gern damit arbeiten würde – unabhängig von auftretenden Hürden und Problemen. In der Regel sollte ein großer Teil der Entwickler in dieser Hinsicht ein gleiches Verständnis von “leicht” haben. Hinzu kommt: man “überdesignt” nicht – denn der Funktionsumfang ist ja nun genau definiert.

Wie man bereits feststellen kann, eignet sich diese Methode natürlich nicht für große Projekte – dafür macht sie für kleine Scripte oder Libraries umso mehr Sinn.

Was haltet ihr davon? Sinnvoll, oder Quatsch? Oder konntet ihr bereits Erfahrung damit sammeln?

[Quicktip] Callback-Funktionen mit Javascript

Neben der Möglichkeit, unter Javascript anonyme Funktionen direkt als Parameter zu übergeben, kommt man vielleicht auch mal an die Stelle, dass man einer Methode den Namen einer anderen Funktion übergeben möchte, die diese dann nach Fertigstellung ihrer Aufgabe ausführen soll. Da man nicht einfach wie z.B. bei php den Funktionsnamen dynamisch per Variable angeben kann, muss man einen kleinen Trick anwenden. Und der geht so:

if(typeof window[funcName] == 'function') window[funcName]();

In der Variable “funcName” steht der Name der Funktion drin, die ihr aufrufen wollt. Der if-Block davor dient nur der Sicherheit – die Funktion wird nur aufgerufen, wenn es sie auch gibt. In der Klammer bei ” window[funcName]()” könnt ihr natürlich wie gewohnt Parameter übergeben.

[Update]
Und hier noch eine weitere Möglichkeit, die mir persönlich besser gefällt und die auch zuverlässiger funktioniert:

function funktionEins(data, callback) {
    //...
    //do something with data...
    //...
    //run our callback
    if(callback != undefined && typeof callback == 'function') callback();
}

Optional kann man natürlich auch Daten/Variablen an die Callbackmethode übergeben:

callback(data);

Wir haben nun also eine Ausgangsfunktion. Rufen wir diese nun auf und übergeben eine existierende Funktion oder eine anonyme Funktion, so kann diese ausgeführt werden:

function funktionZwei() {
    //do something
}
funktionEins("test", funktionZwei);

oder eben

funktionEins("test2", function(data) {
    alert(data);
});

mit einer anonymen Funktion, die in diesem Beispiel eben auch einen Parameter anbietet.

via selfhtml.org

[php] Einzeiler: aktuelles Jahr, Monat oder Tag auslesen

Wenn ihr mal eine Möglichkeit braucht, um das aktuelle Jahr, den aktuellen Monat oder den aktuellen Tag auszulesen und dies in einer Zeile erledigen wollt, dann macht es doch so:

$year = date("Y");
$month = date("m");
$day = date("d");

Wenn ihr das komplette Datum braucht, dann geht das so:

$date = date("d.m.Y");

Und falls ihr nicht den aktuellen Zeitpunkt, sondern einen gegebenen Timestamp verwenden wollt, dann geht das so:
$date = date("d.m.Y", $timestamp);

50+ Tips für die Optimierung von php Applikationen

Eine sehr gute Sammlung an Hinweisen, wie man seinen php Quellcode optimieren und beschleunigen kann. Punkte wie ” ‘else if’ statements are faster than select statements aka switch/case.” oder “Use echo‘s multiple parameters (or stacked) instead of string concatenation. ” waren mir und sind sicher vielen Entwicklern nicht SO bewusst. Eine kleine Referenz, die man sich bookmarken sollte…

50+ PHP optimisation tips revisited

via Patrick auf Facebook