Mittwoch, 18. November 2009

Barcamp Hamburg 3

Logo vom Barcamp Hamburg 3

Letzte Woche war ich auf dem Barcamp Hamburg 3. Wird höchste Zeit, darüber mal zu bloggen. Das war mein erstes Barcamp. Das zweitägige Event startete letzten Freitag, ich selbst konnte leider nur den Samstag hin.

Der Samstag Morgen begann mit einem Hammer-Frühstück. Der Hauptsponsor @otto_de, in dessen Räumen die Konferenz auch statt fand, hat seine hauseigene Kantine Kochwerk für die 400 angemeldeten und etwa 330 tatsächlich gekommenen Teilnehmer ein fantastisches Frühstück zubereiten lassen. Von 9 h bis 10 h habe ich dann erstmal ausgiebig gefrühstückt und ge-social-ized. Sehr relaxed.

Um 10 startete die Session-Vorstellung: Alle in den größten Raum um jedem zuzuhören, der eine Session vorstellen wollte. Dann melden oder nicht bei der Frage "Wer hat interesse?", damit eine passende Raumgröße gefunden werden kann. Die Sessionnamen wurden danach auf einer Wand im Foyer zu Räumen und Zeiten zugeordnet (elektronische Version). Jede Session sollte nicht länger als 30 Minuten dauern. Großzügige Pausen ermöglichten gute Kontakte und regen Austausch zwischen den Teilnehmern.

Das Highlight der vorgestellten Sessions war eine von @Bastian_twitter über Prokrastinieren, die natürlich "morgen" stattfinden sollte. Dazu passt auch der geniale T-Shirt-Spruch eines anderen Teilnehmers: "Procrastinators - Leaders of tomorrow!" Geek-Humor vom Feinsten!

Anschließend starteten die Sessions. In meiner ersten habe ich von Wireframes erfahren. Das sind Modelle von Webseiten, um das Layout und die gewünschten Features besser durchsprechen zu können, z.B. zwischen Programmierer und Kunden. Die Session war ein lustiges Durcheinander von Tool-Show wie Balsamiq Mockups oder MockingBird oder auch einfach Stift und Papier und der Frage nach dem geeigneten Prozess für das Miteinander zwischen Programmierer und Kunden. Lustig: Am Rande gab's ein wenig Streit: "Wenn Du da mit einem Wasserfall-Prozess ran gehst, dann kann das ja auch nix werden..." - "Was? Ich mache keinen Wasserfall, ich mach das Agil!" Nein, ich war da nicht beteiligt. Fazit: Alter agiler Wein (aka Papierprototypen und -scribbles) in neuen Webschläuchen (aka Tools).

Bei der Folgesession ging's um Google Wave. Bin selbst (bernd.schiffer@googlewave.com) begeisterter Waver. Die Session hat enormen Anklang gefunden und der größte Raum war pickepacke voll. Die zwei Sessionowner haben Google Wave vorgestellt in den Grundfunktionen und haben damit einen soliden Job getan.

Am Vortag schien es schon eine Session mit Erfahrungen über Scrum in einem Webprojekt gegeben zu haben, so dass ich nun eine Session zu Scrum-Grundlagen besuchen konnte. Die Session war gut besucht mit 30 Teilnehmern, allerdings kam keine Diskussion zustande und der Vortragende hat auch bei 100 % Zeitüberzug und in insgesamt 60 Minuten Scrum nicht auf den Punkt gebracht. Keine Krise ohne Chance, konnte ich doch im Nachhinein in netten Gesprächen mit vielen Teilnehmern die Missverständnisse aus der Session ausräumen :-)

Mein Session-Highlight hat mich selbst überrascht: Vivian Pein, Community Manager bei Xing, beantwortete die Frage "Wie optimiere ich mein Xing-Profil für Headhunter?" Mich hat da nun gar nicht so sehr interessiert, wie ich mein eigenes Xing-Profil optmieren könnte. Wobei das ein netter Nebeneffekt war. Was mich eigentlich interessierte war der Umkehrschluss, also wie jemand gefunden werden möchte für Unternehmen, also wie z.B. it-agile mehr gute Mitarbeiter finden kann.

Ein paar Gedankenfetzen notiert (in Anführungsstriche Vivians O-Ton):
  • Referenzen in Xing (neues Feature) "gehen ab wie Schmidts Katze!" und sind jetzt schon sehr beliebte Kriterien bei der Bewerberauswahl. Was in USA und Australien schon üblich ist scheint sich demnach auch bald hier zu etablieren: Unternehmen fragen bei vorherigen Arbeitgebern nach, wie der Bewerber drauf ist.
  • Manch lustiger Zeitgenosse möchte geistreich erscheinen und trägt unter Fremdsprache "Klartext" ein. "Klartext als Fremdsprache eintragen heißt 'Labertasche' und 'nicht sozialkompatibel' in Rekruter-Übersetzung." Alles klar?
  • Auf der Suche nach einem neuen Job? "'Herausforderungen' eintragen in 'Ich suche' ist No. 1 Keyword für Jobsucher."
  • Stolz drauf, nicht gegooglet werden zu können? "Headhunter werden misstrauisch, wenn *wenig* über einen im Netz steht." Zur Angst vor ungünstigen Partybildern auf Facebook gesellt sich bald die Angst vor überhaupt keinen Bildern in Facebook. Sollte diese Info wirklich stimmen, so wäre das die für mich unerwartetste Erkenntnis vom Barcamp.
Auch gelernt: Xing nutzt UserVoice zwecks End-Kunden-Feedback.

Der Kaffee war der Hammer - weil ständig da! Das war die bislang erste und einzige Konferenz, in der der Kaffee wirklich jederzeit verfügbar war. Das Kaffee nicht immer verfügbar ist auf Konferenzen galt für mich bislang genauso als ungeschriebenes Gesetz wie ein unstabile Konferenz-WLAN. Die Barcamp-Organisatoren waren aber so clever und haben @kaffee_bazar_de als Sponsor gewonnen. Und dieses ein Jahr junge Start-Up kam mit einem Kaffee-Stand daher mit lecker und immer vorhandenem Kaffee. Tolle Sache das!

Der späte Nachmittag klang dann langsam mit tollen Gesprächen aus. Bei der Abschlussrunde haben die Organisatoren sich sehr gutes Feedback abgeholt. Völlig verdient, wie ich finde, weil sehr guten Job gemacht! Bravo und Danke, komme gerne wieder!

Vorher habe ich schon einige andere Unkonferenzen im Bereich Agiler Softwareentwicklung mitgemacht, alle mit dem Konferenzkonzept Open Space. Die Sessionauswahl aufm Barcamp war schon sehr ähnlich. Vielleicht hätten die Regeln des Open Space dem Barcamp noch ein wenig mehr Selbstorganisation und kollaborative Sessiongestaltung ermöglicht.

Interessant fand ich, dass "Agil" durchaus ein sehr verbreitetes Thema ist. Viele Webworker kommen damit in Berührung nicht etwa deshalb, weil sie selbst in ihrer Agentur dies einsetzen. Aber ihre Kunden setzen es oft schon ein oder nutzen zumindest Teile davon.

Freitag, 13. November 2009

Session mit Pecha Kucha auf der WJAX 2009

Auf der WJAX 2009 habe ich zusammen mit Martin Heider (Xing, Twitter) die Session "Mein Agiler Koffer" auf dem Agile Day vorbereitet und moderiert. Das Format für die Session war Pecha Kucha: Pro Vortrag 20 Bilder á 20 Sekunden = 6'40 Minuten. Was für ein Spaß :-)

Martin und ich haben zuerst in einem halben Pecha Kucha (20 Bilder á 10 Sekunden = 3'20 Minuten) die Session anmoderiert. In diesem Speed-Pecha-Kucha haben wir den Rahmen gesteckt für die darauf folgenden sechs Session-Teilnehmer, allesamt Agile Coaches in Deutschland: "Wenn Ihr für ein neues Projekt angeheuert werdet, und Ihr müsst Euren Agilen Koffer dafür packen, was packt Ihr ein?"


Und was haben die Teilnehmer nicht alles für tolle Sachen eingepackt!

Holger Koschek (Twitter, Blog, Xing) war als Erster dran und startete mit "Air Holisticon" in Richtung Rückkopplung, Verantwortung und Spaß:

Deborah Preuss (Twitter, Xing) folgte als Nächste und reiste leicht mit "Powerful Questions":

Christoph Mathis (Twitter, Blog, Xing), Rufname Krishan, packte vier Sachen in seinen Agilen Koffer, darunter das bekannte Inspect and Adapt und Treat People as Adults:

Henning Wolf (Twitter, Blog, Xing) packte seinen Agilen Koffer pickepacke voll mit sechs sehr interessanten Dingen:

Sabine Canditt (Xing) hatte das Thema etwas durcheinander bekommen - was für ein Glück für uns! Seht Euch selbst die Bilder zu "Mein Agiler Kocher äähh Koffer" an:

Das strahlende Schlusslicht bildete Jens Coldewey (Twitter, Blog, Xing), der in seinen Koffer unter anderem Pragmatismus und Humor packte:

Martin und ich haben nach den sechs Vorträgen noch den echten Agilen Koffer verlost, gefüllt mit allerlei Lernbarem in Form von Büchern und Genießbarem in Form von Spielsachen und Kaffeehausgutscheinen.

Mein persönliches Fazit lagere ich aus - in die hier eingebettete Google Wave. Bitte mitsurfen! Die Wave ist offen und jeder kann mitmachen.




Angekommen scheint die Session bei den ca. 130 Zuschauern im großen Ballsaal im Westin Grand Hotel in München: Martin und ich haben viel gutes Feedback bekommen von den Teilnehmern und den Zuschauern. Wir haben schon wieder einen Haufen neuer Ideen für die geplante Wiederauflage auf der JAX 2010. Stay tuned :-)

Bedanken möchte ich mich an dieser Stelle bei den Teilnehmern, die mit Ihrem immensen zeitlichen und kreativen Aufwand dieser Session Leben geschenkt haben. Danke und Hut ab, das war allererste Klasse von Euch! Auch bei den Sponsoren it-agile, dpunkt und infomar möchte ich mich bedanken, ohne die wir den echten Agilen Koffer nicht mit so viel Gutem hätten füllen können. Schließlich geht mein ganz großer Dank an Martin Heider, mit dem es mir sehr viel Spaß gemacht hat, dieses Event vorzubereiten und durchzuführen.

Reaktionen auf die Pecha-Kucha-Session (falls ich hier etwas übersehen habe: bitte in den Kommentaren nachtragen, dann update ich's hier):

Donnerstag, 17. September 2009

Grails on Rails


Gleisanzeiger an der Haltestelle Berliner Tor in Hamburg


Das war mal etwas anderes: Vorgestern habe ich zusammen mit meinem it-agile-Kollegen Stefan Roock (Blog, Twitter, Xing) beim ObjectForum Nord in Hamburg einen Vortrag über Grails gehalten - in der Historischen S-Bahn Hamburg.

Grails auf Rails war das, und zwar wortwörtlich. Der Inhalt der Veranstaltung handelte von it-agiles Erfahrungen mit Grails und sollte dem Publikum aufzeigen, für welche Arten von Webanwendungen sich Grails gut eignet und wo es Fallstricke erwarten kann.

In einer S-Bahn vortragen, das war für uns neu. Während der Fahrt funktioniert kein Vortrag, da es einfach durch die Fahrtgeräusche zu laut ist. Wir haben die Zuhörer an der Haltestelle Berliner Tor in Hamburg abgeholt, nach Blankenese auf ein für uns reserviertes Gleis gebracht, dort in Ruhe den Vortrag gehalten und sie dann wieder zurück zum Berliner Tor gefahren. Die ganze Aktion dauerte etwa zweieinhalb Stunden bei einer Stunde Vortrag.

(Böse Zungen munkeln, dass das eine Butterfahrt war. Das stimmt aber nicht, denn wir haben nicht eine einzige Heizdecke an die Teilnehmer ausgegeben. Ehrenwort!)

Der Vortrag selbst war auch nicht so einfach: Durch die Sitzgruppen im durch eine dünne Trennwand zweigeteilten Abteil konnten wir Kraft eigener Stimme nicht jeden Zuhörer erreichen. Die eingebaute Lautsprecheranlage war dagegen ziemlich verrauscht, so wie es das Klischee der unverständlichen Lautsprecherdurchsagen vom Schaffner passend beschreibt. Eine eigene Boxenanlage musste her - akkubetrieben, da es keinen 240-Volt-Stromanschluss in einer historischen S-Bahn gibt.

Und dann die Sache mit den Folien und dem Beamer. Kein Strom, kein Beamer. Und selbst, wenn wir Strom gehabt hätten, wohin hätten wir die Folien projizieren können? Wir haben uns dann mit Riesen-Post-Its beholfen, die sechs it-agile-Kollegen auf Stefan und mein Zurufen hin umgeblättert haben. Und trotz aller Unkenrufe - Was da nicht alles hätte schief gehen können! -  verlief die Aktion reibungslos.

Die Resonanz: Sowohl Inhalt des Vortrags wie auch die Location kamen gut an. Uns hat es sehr viel Spaß gemacht.

Ein paar Fotos haben wir auch geschossen:



Freitag, 21. August 2009

Pecha Kucha "Inkrementelles Design" (Folien und Video)

Auf der JAX '09 im Frühling diesen Jahres habe ich für it-agile in einer Pecha Kucha-Session auf dem Agile Day einen Vortrag "Inkrementelles Design" gehalten. Host war Stefan Roock (Homepage, Twitter, Xing). Das sind die Folien:

View more documents from Bernd Schiffer.

Das alles ist schon ein wenig länger her, aber jetzt hat die Konferenz-Organisation das Video auf JAX TV veröffentlicht. Danke JAX-Team! Hier das Video:


Ich rede zwar viel zu schnell, trotzdem: Viel Spaß damit :-)

Apropos Pecha Kucha I: Auf den XP Days Germany 2009 im November diesen Jahres gibt es gleich 9 Pecha Kucha-Vorträge in drei Blöcken (siehe Programm). Das sind für mich die Perlen dieser Konferenz, also nicht verpassen!

Apropos Pecha Kucha II: Auf der WJAX '09, auch im November diesen Jahres, gibt es wieder eine Pecha Kucha-Session, die ich zusammen mit Martin Heider (Xing, Twitter) auf dem Agile Day halten werde. Thema: "Mein agiler Koffer - Reisetipps mit Pecha Kucha".

Links:

Montag, 17. August 2009

Zu meinem Verständnis von TDD und BDD


Mein Kollege Stefan Roock schreibt in seinem Blogpost von einem "Vergleich: BDD und TDD":
"Ich [wurde] bereits früh von TDD (Test Driven Development) infiziert. Irgendwann kam eine neue Bewegung auf: BDD (Behaviour Driven Design). Wie viele andere TDDler habe ich lange nicht verstanden, was der Vorteil von BDD sein soll."
Dito. Verstehe den Vorteil von BDD bis heute nicht. Ich präzisiere: Verstehe ich bis heute nicht für mich.

Stefan scheint seinen Frieden mit BDD nun gemacht zu haben, denn er schreibt:
"[Der Vorteil] ist mir inzwischen klar gewor[d]en."
Stefan nimmt in seinem Blogpost eine Portion Ruby-Code eines TDD-Beispiels mit RUNIT her und übersetzt es in ein BDD-Beispiel mit RSpec. Dabei fällt ihm dies auf:
"Strukturell sind Test und BDD-Spezifikation identisch. Die BDD-Spezifikation ist bei den Vergleichen lediglich etwas leichter lesbar.
Der Vergleich termin.bezeichnung.should == "TDD-Dojo" ist der natürlichsprachlichen Formulierung "Die Terminbezeichnung sollte 'TDD-Dojo' sein." ähnlicher als assert_equal("TDD-Dojo", termin.bezeichnung)."
Lange habe ich gegrübelt, was mich hier stört. Und das ist mir inzwischen klar geworden. Was heißt denn leichter lesbar? Was ist natürlichsprachlich?

BDD selbst verweist als eines seiner Vorteile auf die Sapir-Whorf-Hypothese. Diese Hypothese besagt
"... dass die Sprache das Denken formt."
Nach dem, wie und was wir (be-)sprechen, nach dem handeln wir auch. Sprechen wir über Tests, so sichern wir primär Eigenschaften zu. Sprechen wir dagegen von Spezifikationen, so beauftragen wir Eigenschaften und geben an, wie sie sein sollen. Demnach weichen test und assert aus xUnit specification und should aus RSpec. Die Idee ist, dass wenn der Programmierer keine Tests mehr schreibt, sondern Spezifikationen, wenn er keine Zusicherungen über, sondern einen Auftrag (should; soll; Auftrag) an den Code schreibt, dass er dann anders denkt.

Dieses Andersdenken bezieht sich auf das letzte D in TDD: Die einen übersetzen es mit Development, die anderen mit Design. Letzteres ist für viele TDDler die eigentliche Qualität des TDD: Das Design wird getrieben durch die Tests. Es geht nicht um Verifikation, sondern um Spezifikation. Diesen Gedanken greift das BDD nun auf und fragt: Wenn wir spezifizieren statt zu testen, wenn wir schreiben, was der Code tun soll, anstatt etwas zuzusichern, dann sollten wir das auch so aufschreiben, damit wir durch die Worte wohl geleitet handeln.

Mag sein, dass das für jemanden gilt, der neu ist in TDD. Das kann ich mir gut vorstellen. "TDD? Was soll das sein? Ach, Tests? So so, verstehe, geht ums Testen von Software. Alles klar, man her damit!" Und schon ist der Neue mit falschen Annahmen bei der Sache. Nicht gut. Da hilft BDD, oder?

Seit über 8 Jahren programmiere ich testgetrieben, was mich als TDD-Neuling disqualifiziert. Meine Vorstellung von Tests sind stark kontextbehaftet. Geht's um TDD? Dann sind meine Tests keine Verifikationen, sondern meine Mittel fürs Design. Geht's um die Endabnahme, Akzeptanztests, QA? Dann sind meine Tests verifizierend. Da hilft kein BDD, um mein Handeln durch eine andere Terminologie zu besseren Ergebnissen zu leiten.
"BDD"
, frei nach Dave Astels,
"macht man, wenn man TDD richtig macht."
Und bislang war das der Strohhalm, nach dem ich gegriffen habe, wenn ich nicht verstand, warum BDD nun anders sein soll als TDD. Dieser Strohhalmgriff beruht auf meiner Annahme, dass ich bereits korrektes TDD mache. Subjektiv, vielleicht vermessen, möglicherweise anmaßend, auf jedenfall nicht objektiv bewertbar ist die Aussage, ob ich korrektes TDD mache. Das war mir immer ein sehr kleiner Strohhalm.

Wittgenstein ist da schon ein größerer Strohhalm. Von ihm las ich neulich wieder in Prechts "Wer bin ich und wenn ja, wie viele?", und von seiner Idee der Präzisionssprache. Wittgensteins Theorie besagte, dass die Sprache als Abbild der Realität dienen kann. Und er lag falsch, wurde widerlegt:
"[Der Sprache] wichtigste Funktion besteht darin, zu verstehen und verstanden zu werden. Ob etwas verständlich ist oder nicht bestimmen sowohl die Grammatik wie der Kontext. So kann der Satz 'Ich sehe schwarz' meinen, dass ich vor einem schwarzen Bild stehe und seine Farbe beschreibe. Ebenso gut aber kann er bedeuten, dass ich in einer Sache pessimistisch bin. Dem jungen Wittgenstein waren solche Sätze ein Greuel, aber die Sprache wimmelt nur so von Mehrdeutgkeiten. Die schlichte Wahrheit, die jede Idee einer Präzisionssprache zum Scheitern verurteilt, ist, dass die Bedeutung eines Satzes durch den Gebrauch der Wörter geformt wird."
Die Bedeutung wird also durch den Gebrauch der Wörter geformt. Die Wörter selbst formen nicht die Bedeutung. Es ist eine Implikation, keine Äquivalenz. Und ich benutze Worte wie Test und Zusicherung schon seit 8 Jahren. Kein Wunder also, dass die Bedeutung von TDD bei mir entsprechend geformt wurde. Das, was hinter TDD steckt, erschließt sich mir mehr über die Worte Test und Zusicherung, weniger über Spezifikation und Auftrag.

Wenn ich einem xDD-Neuling im TDD-Camp erkläre, dass er die Tests vor dem Code schreiben, dass er Einfachheit anstreben, dass er gnadenlos refaktorisieren, dass er Redundanzen eliminieren und dass er noch ein paar TDD-Gebräuche mehr anwenden soll, und wenn ich dem xDD-Neuling dann sage, dass das Testgetriebene Entwicklung ist, dann habe ich die Bedeutung von Tests im Kontext des TDD durch den Gebrauch der Worte wie Tests und Zusicherungen entsprechend geformt. Aus meiner Sicht heraus sind für einen xDD-Neuling beide Begriffsgruppen, Tests-Zusicherung und Spezifikation-Auftrag, am Anfang seiner Ausbildung gleich bedeutungsleer oder -voll. Das, was diese Wortgruppen mit dem verbindet, was hinter TDD/BDD steckt, dem Treiben des Designs also, wird erst durch den Gebrauch, also durch die Anwendung dieser Wörter geformt. Wenn das stimmt, dann ist es schnurzpiepegal, ob man nun TDD oder BDD macht.

Mein Fazit: Taten mögen den Worten folgen (Sapir-Whorf-Hypothese; BDD), sicherlich wird Bedeutung durch den Gebrauch von Worten erlangt (Widerlegung Wittgensteins; xDD). Egal, ob ich BDD oder TDD anwende, beide benutzen eine jeweils eigene Terminologie, die Bedeutung durch den Gebrauch derselben erlangt. Ergo hat weder BDD noch TDD einen Vorteil gegenüber der jeweils anderen Technik.

Versöhnlich möchte ich schließen. Precht schreibt:
"Und die entscheidende Frage beim Verständnis von Sätzen ist nicht, ob etwas wahr ist oder falsch, sondern ob die Verständigung im beabsichtigten Sinne gelingt oder nicht gelingt."
Verständigung im beabsichtigten Sinne: Egal ob TDD oder BDD, es geht nicht darum, ob Tests oder Spezifikationen, es geht darum, zu verstehen, dass in beiden Fällen Design getrieben wird.

Wir verstehen uns?

Freitag, 14. August 2009

Wenn's mal passt


Bin gerade in einer sehr glücklichen Beziehung. Vor Kurzem hat es angefangen. Wir kannten uns schon ein wenig vorher, aber so richtig zusammen sind wir erst seit fünf Wochen. Wir wußten damals nicht mit Sicherheit, ob es mit uns beiden klappen würde. Umso glücklicher sind wir jetzt darüber, dass wir anscheinend richtig gut zusammenpassen.

Woran ich es erkannt habe, dass es gut passte? Da war dieses Bauchgefühl, dass mir in der ein oder anderen Situation Bestätigung gab. Und natürlich haben wir unsere Differenzen über die ein oder andere Sache. Sogar über gegenteilige Ansichten hinaus kommen wir miteinander gut aus.

Wir sehen uns fast jeden Tag und verbringen dann viel Zeit miteinander. Ich würde es gar nicht aushalten, wenn wir ständig Probleme miteinander hätten. Darum finde ich es geradezu notwendig, dass wir uns gegenseitig riechen können, dass wir auf einer Wellenlänge funken. Gar nicht auszudenken, dass ich so eng mit jemandem zusammen sein müsste, mit dem ich mich nicht gut verstehe.

Wir lernen viel voneinander. Wir beide haben schon viele Beziehungen mitgemacht und haben daraus viel geschöpft. Und es sind nicht nur die Techniken (obwohl das schon jede Menge Spass machen kann, sich gegenseitig die abgefahrensten Praktiken vorzustellen und dann miteinander auszuprobieren). Es ist der Respekt, der uns gegenseitig zuhören lässt, wenn der andere spricht; es ist das offene Feedback, dass wir uns geben und vom anderen annehmen; es ist der Spass, den wir miteinander haben, ohne unser gemeinsames Ziel aus den Augen zu verlieren; es ist der Flow, in dem wir zusammen agieren.

Es ist nur ein kurzes Projekt, etwa sechs Wochen. Es ist nur ein kleines Projekt, wir zwei eben. Das Risiko war also sehr gering, zwei, die sich nicht kennen, zusammen da reinzustecken. Trotzdem hat das Nahezu-blind-miteinander-Arbeiten schon nach drei bis fünf Wochen geklappt. Wenige Zeilen Code sind entstanden, als wir nicht zusammen im Paar programmiert haben. Jedes Mem, das mindestens einer von uns für wichtig hielt, haben wir besprochen, sind dabei richtig in die Tiefe gegangen, und sind jeweils beide gestärkt daraus hervorgegangen. Architektur, Design, Pattern, solche Dinge meine ich. Shortcuts, Programmiersprach-Idiome, Tipps & Tricks, die meine ich auch. Coole Tweets, Youtube-Videos und Blogposts, auch die gehören dazu.

Ich genieße diese Zeit. Es kommt nicht oft vor, dass man so gut miteinander kann innerhalb eines Projektes. Fast nie kann ich mir aussuchen, mit wem ich programmiere. Und dann ist es eben eine gewisse Chance bishin zu reinem Zufall, wenn's passt. Das kommt vor, aber weitaus weniger oft, als man annehmen könnte.

Kernaussage dieses Posts soll sein... - nun, keine Liebeserklärung jedenfalls. Dass ich gut mit meinem Kollegen kann, und er mit mir, dass wissen wir beide seit einigen Retrospektiven. Dieser Gewissheit bedürfte es keines Blogposts. Nein, Kernaussage dieses Posts soll sein, Wert auf gute Beziehungen innerhalb eines Projektes zu legen lohnt sich. Nie arbeite ich so produktiv, so effizient, so effektiv, so nachhaltig gut, als wenn ich einen guten Partner habe.

Schönes Gefühl, wenn alles passt.

Freitag, 7. August 2009

Beispiel für Refactoring von Beispiel für Closures

Vor ein paar Wochen hat mein Kollege Stefan Roock (Xing, Twitter) auf seinem Blog von einem "Beispiel für Closure" geschrieben. Wie so oft geht mir beim Lesen (fremden) Codes mein Das-ist-nicht-DRY-Alarm an. So auch bei Stefans Post. Es folgt ein Refactoring.

Stefan will die Laufzeit je Methode für eine Menge von Methoden messen. Die Menge hat er so bechrieben:


Ich konnte in seinem Post die Implementierung von tueA(), tueB() und tueC() nicht finden. Meine Annahme ist, dass sie ein wenig Laufzeit verbrauchen und etwas ausgeben:

Führt man nun die Menge an Methoden aus, so ist das die Ausgabe:

Stefan misst nun die Laufzeit der Methoden, und sein Output sieht (mit meiner Implementierung der Methoden) so aus:

Da ich ein Refactoring beabsichtige, darf sich das Verhalten des Codes, in diesem Falle der Output, nicht ändern.

Aber warum eigentlich Refaktorisieren? Mit Stefans Implementierung als solcher bin ich eigentlich zufrieden. Naja, da kann man noch ein Semikolon weglassen sowie eine Variable duration einführen und im GString hinterm println substituieren. Aber das ist Kleinkram, nebenbei machbar und hier kaum der Rede wert. Stefans Implementierung der Closure:

Nein, es geht mir um den Aufruf von Stefans Lösung (siehe Stefans komplette Lösung). Was muss ich tun, um die Laufzeit einer Menge von Methoden zu messen? Wo ist der Schalter, den ich einschalten muss? Stefan legt diesen Schalter um:

Seht Ihr die Redundanz? Stefan legt nicht einen Schalter um, sondern drei. Drei Mal muss er vor die Methoden timeLogged schreiben, inklusive geschweifte Klammer vor und nach der zu messenden Methode. Das ist nicht DRY.

DRY wäre es, eine Menge von Methoden einzeln zu messen. Das hier schwebt mir vor:

Und das geht. Die Closure-Magie, mit der das geht, hat Ted Naleid (Twitter, LinkedIn) in seinem Blogpost "Groovy closures make unit testing with “soft asserts” simple" ausführlich beschrieben. Hier ist meine Lösung:

Keep on DRYin', Stefan! "Bleib trocken, Stefan!" lag mir auf der Zunge, ging aber hier nun echt nicht... :-)

Links: