Donnerstag, 24. Dezember 2009

Prime Factors Kata - First Try

This is my first try of the Prime Factors Kata. It's my first Katacast of a kata at all. I performed it with Groovy.

Stefan wrote about katas (in German) a while ago, where he described his experience as an attendee of the contest "TDD with the pros" ("TDD mit den Profis", TmdP) at the XP Days Germany 2009 in Karlsruhe. TmdP is similar to "Programming with the Stars" at Agile 2009 in Chicago, where I was an attendee of.

Stefan was in the final of TmdP with his pair partner Franziska Widmaier. Their task was to calculate all prime factors of a given number, which is the same task as in the Prime Factors Kata. Stefan and Franziska had to finish this task in less than 7 minutes - and they failed to do it in time.

Stefan and I started to work on that kata right after the XP Days ended. Our first shot was in the train from Karlsruhe back to our home town Hamburg. After that we met once via Skype and wrote each step we took during the kata. I practiced a few times per week for the last five weeks or so and showed my performance to Stefan today. He said that it'd might be time to show the result to the world, and here it is:

On Youtube:




I've also shared the Katacast on vimeo and on viddler.

My to-do list for the next try so far:
  • Use a parameterized JUnit test instead of not isolated parameters in a map
  • Use more of TextMate's shortcuts and optimize on a keystroke level
  • Find out why 63 is too big... wtf? [Update: @datenreisender found out that this is related to a bug in Groovy.]
  • [Update: @datenreisender suggested in the comments to use primefactors instead of numbers2primeFactors[number] in the assertion.]
My heartfelt thanks to Stefan, with whom it was a lot of fun preparing that kata!

Happy Christmas!

P.S.: If you want to rate my performance, then post a comment with the number 0 (very bad) to 10 (very good). This kind of rating was inspired by Micah Martin. Any additional feedback is very welcome!

[Update: Stefan Roock made a Kata Bunkai - a commented kata - for this kata. Check it out!]

Freitag, 11. Dezember 2009

Running only one of JUnit's Tests


Green Bar with only one of JUnit's Tests

I managed to run all of JUnit's tests. And I failed for some time to run only one test. Here's why and how I finally succeeded.

One test I kept a close eye on: org.junit.tests.running.classes.ParameterizedTestTest. I opened it in Eclipse and tried to run it. A window occured and asked me to select a test:



What was that? I never saw such a window before. Was it something new in Eclipse 3.5.1? I looked around and looked also into the outline of that test class:



After a closer look I thought I knew what that test selection window was all about: One was able to pick a specific test method in one test class. All of the test method names in the test selection window were also in the outline view of that class. Yes, that would make sense. And that would be actually a great thing, since it was never possibile to do that in previous Eclipse versions and that would be a very useful feature for many reasons.

Okay, new feature, cool. But how could I run one test class with all test methods together? Like I was used to do in all the previous Eclipse versions before? I asked other Eclipse users in my current project, but nobody had a clue. I asked on Twitter, and got some doubtful suggestions like "I think there is something seriously broken in your eclipse installation."

After the fifth person or so I begged for help I realized what was going on. Do you see it? It's in the pictures I showed you in this post before. What I saw after a while was this line:



What a bad UI design, I thought. Why on earth would they put an entry for the whole test class in the middle of all the other test methods? Shouldn't it at least be marked in some way? Wrong assumption, again. Those items were all test classes! Oh my, now that I look at the test selection window I see all those green icons with the C in it...

Anyhow, why are there so many static test classes (yes, that's what they are, static, and the outline view told me with a little red 'S') in one single file? Because those are the input parameters for the tests. The test class contains all the tests for JUnit's Parameterized Test feature, which is a way to deal with one test method called several times with different parameters. It's more than having a for-loop going through a bunch of parameter sets, because with JUnit's Parameterized Test feature every parameter set is treated like a separate test method. With three parameter sets you'd end up with three tests, and if one test would fail, the others won't stop running like they would do in a for-loop.

For that feature you have to provide a annotated method which should return the parameters, you have to provide a constructor and instance variables for the parameters, and you have to reference the parameters in the instance variables from within the test method. That's a lot of stuff which could be broken easily. Each static test class supports a test method for the feature. Eclipse cannot distinguish between a test class as a test class and a test class as a test input parameter, and so it showed every test class in a test selection window.

Well, maybe I shouldn't program late at night, but that was really a hard one to figure out.

Mittwoch, 9. Dezember 2009

Running all of JUnit's Tests


Green Bar with JUnit

After Getting JUnit from Git on a Mac I wanted to run all of JUnit's tests. Here's what happened.

First I opened the whole JUnit project in TextMate. TextMate is my editor of choice when I work with Groovy/Grails and Ruby/Rails. I do whole projects with it. For those kind of languages and frameworks Textmate is suiteable, but since JUnit is a Java project, TextMate's seems to be not enough.

I tried to run all the tests within JUnit with TextMate. There are some AllTests classes, but you can't run them from within TextMate easily, because you would have to deal with the classpath on your own. There's an Ant build file, but unfortunately without a test task. Tests seems to be only executed during a build, but I don't want to build JUnit everytime when I actually want to run all the tests.

In the build file I saw a reference to org.junit.tests.AllTests. Again, it'd be a mess to build the classpath everytime I wanted to execute the AllTests class within TextMate. I switched to Eclipse after I upgraded to Eclipse 3.5.1.

There were already project files for Eclipse in the JUnit project, so I was able to be up with JUnit in Eclipse with a simple import. I executed org.junit.tests.AllTests with Alt+CMD+X T and I saw a green bar with 481 tests. Yay!

Only the execution time wasn't that good. It took me ~23 seconds to execute all the tests, which is quite more than my expected less than 10 seconds.

At least I could run all of JUnit's tests now.

Donnerstag, 3. Dezember 2009

Getting JUnit from Git on a Mac


I want to dig deeper into JUnit for some reasons. Therefore I want to see the latest version in the repository. JUnit uses Git. I use a Mac and never used Git before. Here's what I've done to get JUnit from Git on a Mac.

I installed Git for OS X. It's a dmg file and quite simple to install.

After that I had to add Git's bin path to PATH to use Git in the terminal. I added this to ~/.bash_profile.
export GIT_HOME=/usr/local/git
export PATH=$PATH:$GIT_HOME/bin
Worked now for me: I entered git in the terminal and saw a list of commands.

Now what? I read parts of the official Git tutorial online and in the terminal with git help tutorial. I entered my user.name and my email.adress as a key with git config --global key value where value is my name or email adress, because I should do that "before doing any operation".

I continued reading at paragraph "Using git for collaboration". There's what I was looking for:
Suppose that Alice [aka Kent] has started a new project with a git repository in /home/alice/project [aka git://github.com/KentBeck/junit.git as listed on github.com], and that Bob [aka me], who has a home directory on the same machine [aka ~/projects/junit], wants to contribute.
In the terminal I entered
git clone git://github.com/KentBeck/junit.git ~/projects/junit
Now Git downloaded JUnit. Finally JUnit was downloaded on my computer. The tutorial states that if Kent would commit changes I could be again up to date with a simple git pull.

So far so good to be able to have a look around in JUnit.

[Update: If you want to run Git within TextMate, than you can. TextMate can deal with Git from the start, but you have to set TM_GIT as a shell variable, e.g. to /usr/local/git/bin/git or wherever you've installed Git.]

Dienstag, 1. Dezember 2009

Der grüne Pfad


Schön, wenn einem die Arbeit abgenommen wird: Kollege Stefan Roock schreibt in seinem neuesten Blogeintrag vom grünen Pfad, den ich beim Refactoring gerne gehe. Auf einem grünen Pfad gibt es minimales Risiko, sich im Code zu verlaufen. Aber der grüne Pfad ist nicht ganz einfach zu finden, auch wenn seine Regeln sehr einfach sind:
  1. Einen atomares, d.h. nicht weiter unterteilbares, Refactoring durchführen.
  2. Tests grün laufen lassen.
  3. Weiter mit 1.
Laufen die Tests bei 2. nicht grün, sondern rot, hat man den grünen Pfad verlassen und findet sich unweigerlich in der roten Testhölle wieder, aus der es nur durch Strg-Z oder CMD-Z einen sicheren Ausweg gibt.

Was sind atomare Refactorings? Solche, die nicht weiter durch andere Refactorings unterteilbar sind, etwa Umbenennen, Extrahieren, oder Inlinen. Die meisten anderen Refactorings sind aus atomaren Refactorings zusammen gesetzte Refactorings.

Stefan beschreibt sehr schön, dass es gar nicht darauf ankommt, immer auf dem grünen Pfad zu weilen. Eigentlich braucht man den grünen Pfad nur dann, wenn es knifflig wird. Aber wer nicht oft auf dem grünen Pfad gelaufen ist, der wird ihn nur sehr schwer finden, und wer nicht oft kleine Schritte beim Refactoring gegangen ist, der wird sich unter Druck oder in sehr krudem Big-Ball-of-Mud-Code nicht mehr daran erinnern können, also genau dann, wenn es einem besonders helfen würde.

Stefan hat ein schönes Beispiel aufgeschrieben, bei dem ich ihn quasi auf dem grünen Pfad vor mich hergeschoben habe - und er zu einer, wie ich finde, sehr cleveren Lösung gekommen ist.

Gerne gebe ich den Aufruf von Stefan weiter: Habt ihr Code, der nicht auf dem grünen Pfad zu refaktorisieren sei? Immer her damit: bernd.schiffer@gmail.com oder hier in die Kommentare. Wir freuen uns über jede Herausforderung :-)

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):