FLOW3 – wie erstelle ich eine Ajax Action mit json Rückgabe?

Ganz einfach:

im Controller folgende Klassenvariable setzen:

protected $supportedFormats = array("html", "json");
	protected $viewFormatToObjectNameMap = array(
		"json" => "\TYPO3\FLOW3\MVC\View\JsonView",
		"html" => "\TYPO3\Fluid\View\TemplateView"
	);

und in der Routes.yml (bzw. im Routing) einen Eintrag nach folgendem Muster vornehmen:

-
  name: '[name_der_route]'
  uriPattern: '[gewünschter_pfad]'
  defaults:
    '@package':    '[package_name]'
    '@action':     '[action_im_controller]'
    '@controller': '[controller]'
    '@format':     'json'

Mit der Klassenvariable sorgt ihr dafür, dass der Controller beim Format “json” auf ein Template verzichtet und den Return-Value einer Action direkt ausgibt (also im Normalfall per json_encode() formatiert). Mit der Konfiguration der Route legt ihr nur noch fest, dass die jeweilige Action an Stelle von HTML lieber JSON verwendet.

[Update]
Nach der Frage von Mario hier nochmal als Nachtrag eine entsprechende Beispiel-Action:

/**
 *
 * @param string $param
 *
 * @return json test data
 */
public function getDataAction($param) {
	$data = array("testKey"=>$param, "testKey2"=>"testValue2");
	return json_encode($data);
}

[Quicktip] xdebug 2.2.0 (php 5.4, MAC OSX) stürzt während der Laufzeit ab

Ein sehr ärgerlicher Bug bzw. mehrere Bugs führen bei xdebug 2.2.0 (aktuelles Release) dazu, dass sich der Debugger während seiner Arbeit einfach aufhängt. Teilweise geschieht dies in Zusammenhang mit Doctrine 2, teilweise aber auch nicht 😉

Es gibt aber einen einfachen Weg, dieses Problem aus der Welt zu schaffen – indem man den neuesten Developer-Branch auf github verwendet (derzeit Version 2.3.0). Und das geht so:

Geht auf eure Mac Console, legt ein Temp-Verzeichnis an oder wechselt in ein solches, und gebt da folgendes ein:

git clone git://github.com/derickr/xdebug.git

Anschließend wechselt ihr in das neu erzeugte Verzeichnis “xdebug” und gebt dort nacheinander

phpize
./configure
make
sudo make install

ein. Nach ein bisschen Wartezeit sollte alles durch sein und ihr könnt mittels

php -v

überprüfen, ob alles korrekt installiert wurde. Wenn in der letzten Zeile “with Xdebug v2.3.0dev” oder größer steht, dann seid ihr auf der neuesten Version und die Abstürze beim Debuggen sollten nicht mehr auftreten.

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.

[Quicktip] Mac Ports meldet, dass Xcode nicht richtig konfiguriert ist

Falls ihr, wie auch ich, bei der Verwendung von Mac Ports (v 2.0.4) unter OSX Lion (10.7.3, mit Xcode 4.3) folgende Fehlermeldung erhaltet:

Warning: xcodebuild exists but failed to execute
Warning: Xcode appears to be installed but xcodebuild is unusable; some ports will likely fail to build.
Warning: You may need to run `sudo xcode-select -switch /Applications/Xcode.app`

und das vorgeschlagene
`sudo xcode-select -switch /Applications/Xcode.app`
genau nichts bringt, dann probiert es alternativ mit folgendem Befehl:

sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer

via mac ports bugtracker

[Quicktip] Vagrant zeigt plötzlich Config-Fehler beim Hochfahren einer VM

Beispiel:

"Vagrantfile:4:in `forward_port': wrong number of arguments (2 for 3) (ArgumentError)"

In solchen Fällen hat man evtl. vergessen, sein System zu updaten. Ein einfaches Update von Vagrant hatte das Problem bei mir sehr schnell gelöst:

gem update vagrant

ON AIR Android Beta 0.4

An gewissen Punkten in meinem Leben bin ich durchaus sehr stolz – und so war es auch am Montag, als die neueste Beta von ON AIR für Android fertig gestellt wurde. Wir konnten viele Anregungen und Fehlermeldungen aus der letzten Version aufnehmen bzw. korrigieren, haben extreme Performance Optimierungen durchführen können und die App somit auf noch mehr Geräten verfügbar gemacht. Hinzu kam außerdem die Unterstützung für eine große Palette an Android Tablets. Bereits jetzt muss sich ON AIR Android nicht mehr vor seinem großen Bruder auf der iOS Plattform verstecken.

Das Raster

Die Entwicklung für Android gestaltet sich gegenüber iOS deutlich schwieriger – nicht, weil das System irgendwie komplizierter ist, sondern wegen der schier unendlich vorhandenen Geräte. Auch dies wäre kein Problem, wenn zumindest gewisse Grundsätze eingehalten würden – z.B., dass Bildschirmauflösungen nur ein Vielfaches einer bestimmten Auflösung sein dürfen oder ein genormtes Verhalten des Systems an sich. Die Freiheiten, die Android bietet, bringen leider auch viele Nachteile mit sich, die sich vor allem dem Entwickler offenbaren. Dieser Absatz soll kein Flaming oder eine Ausrede sein, ich möchte den Usern einfach nur näher bringen, warum wir auch immer wieder auf einzelne Geräte stoßen, auf denen unsere App nicht so läuft, wie wir uns das vorgestellt haben. Aber wir sind stets bemüht, diese Probleme aus der Welt zu schaffen.

Um mal ein bisschen aus dem Nähkästchen zu plaudern: ON AIR für Android ist eine reine HTML5 App und nutzt so die neuesten Web-Technologien. Das sorgt zum einen dafür, dass die App auf möglichst vielen Geräten läuft, zum andern vereinfacht es aber auch ungemein die Wartung und Entwicklung. Mittlerweile sind über 30.000 Zeilen Code zusammengekommen, die sich vor allem um die Dinge kümmern, die der Benutzer nicht sieht – also die Verwaltung und Aufbereitung der Senderdaten, die Kommunikation mit den Servern usw. – aber natürlich auch um die vielen grafischen Raffinessen, die wir bereits eingebaut haben. Mit unserer Entwicklung haben wir z.B. das absolut flüssige Scrollen von Listen und natürlich das grandiose Programm-Raster umsetzen können.

Als kleiner Ausblick noch, was euch in den nächsten Beta-Versionen erwartet:

  • Trailer
  • Wikipedia- und IMDB Link
  • Suche
  • Wiederholungen
  • Erinnerungen erhalten
  • Favoriten setzen
  • Sync mit iPhone und iPad
  • Offline-Funktion
  • Optimiertes Design für Tabletts und Android 4.0

Es bleibt also weiterhin spannend 😉

Die App findet ihr im Android Market unter “ON AIR Beta“.

[Quicktip] sehr langsamer Upload mit PhpStorm (collecting files)

Solltet ihr mit PhpStorm bzw. WebStorm mal das Problem haben, dass ihr einen Upload auf einen SFTP/SCP Server durchführen wollt und dieser ewig dauert, was sich durch ein extrem langsames “collecting files” in der Statusleiste äußert, dann solltet ihr unbedingt die Berechtigungen des Zielordners überprüfen. Sind diese nicht korrekt, dauert die Überprüfung der hochzuladenden Dateien ewig und ihr erhaltet erst sehr spät die entsprechende Fehlermeldung!

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?