02:10 - Senile Bettflucht treibt mich aus dem Bett. Auch gut, so hab ich wenigstens Zeit um zu arbeiten. Seit längerer Zeit schon arbeite ich an einem Artikel für den ATB-Insider zum Thema Tools für Acceptance Test Driven Development (aka ATDD).
Aus dem Grund steht schon seit langem auf meiner ToDo-List: Concordion anschauen!
Concordion ist eine interessante Alternative zu FIT. Ähnlich wie bei FIT, verwendet Concordion HTML-Dokumente als ausführbare Spezifikation und benötigt Fixtures um die Business-Logik zu testen. Im Gegensatz zu FIT können Concordion-Spezifikationen im Given-When-Then-Format geschrieben sein.
Die Instrumentierung von Concordion-Spezifikationen erfolgt durch die Definition von Testvariablen, Ausführung von Fixture Code und dem Vergleich von Ergebnissen.
Also, ready to face Concordion. Kaffeemaschine anwerfen, doppelten Espresso runter drücken, Netbook aufklappen und a bissal googln.
Meine Mutter fragt mich immer was Google kann was die gelben Seiten nicht können. Ob es wohl eine gelbe Seite gibt zum Thema Concordion? Ich finde auf Seite 356 das Schloss Concordia im 11. Bezirk. Dort gibt’s Schnitzel in Cornflakes paniert aber kein Acceptance Test Driven Development. Thema gelbe Seiten damit abgehakt.
Nachdem mir die Evaluierung von FIT graue Haare gekostet hat, bin ich darauf vorbereiten das es dieses mal wieder so wird. Ich sag nur: Scheiß Classpath, scheiß Klassennamen.
Auf der Concordion-Homepage entdecke ich dass außer Java auch Ruby, Python und .NET unterstützt wird. Python ist vielleicht mein Jetzt-lerne-ich-was-neues-Spielzeug über die Weihnachtsfeiertage. Bevor ich mich aber mit .NET beschäftige häng ich lieber in Apetlon tot über’n Zaun. Und Ruby? Das geht runter wie Honig. Ja ich mach’s in Ruby.
Los geht’s. Installation von Concordion mit Ruby ist ein Klacks. Wirklich. Gem anwerfen, 15 Sekunden später meldet das System:
Fein. Jetzt die Spezifikation in HTML schreiben.
So, jetzt die Business Logik schreiben. Die halten wir kurz und einfach und packen Business Logik und Testfixture in eine Klasse. Wir wollen dann ja auch Refactoring betreiben.
Noch das Startscript schreiben unnd anwerfen. Das Ergebnis kann sich fast sehen lassen. Klar das es rote Bereiche gibt, ist ja die Spezialbehandlung für Bat Man noch nicht implementiert.
So, Business Logik anpassen. In Ruby kostet mich das einen Lacher, in Java würde ich heulen und das System verfluchen.
Fein, alles im grünen Bereich.
Concordion installiert, Spec geschrieben, Ruby-Code geschrieben, Ruby-Code verfeinert. Alles in 90 Minuten.
Ich gehe schon lange damit schwanger unsere SLA-Berechnung durch automatische Acceptance Tests abzusichern. Jetzt hätte ich das passende Framework dafür.
Dazu gibt’s jetzt zwei Möglichkeiten: Entweder Fixture-Code in Java schreiben (Würg!!!) oder unsere ganze Applikation in Ruby umschreiben.
Ich werde morgen gleich einmal mit der-lebenden-Testbasis darüber reden. Worüber?
Eh klar oder?
Posts mit dem Label Java werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Java werden angezeigt. Alle Posts anzeigen
Montag, 1. November 2010
Sonntag, 11. April 2010
Q159: Drachen die fauchen, beißen nicht!
Gestern war Tag der Flugsaurier im Hause Q. Zuerst Natur Historisches Museum, Flugdrachen schauen, dann 3-D Kino „Drachenzähmen leicht gemacht!“.
Im Museum sehe ich einen Film in dem zwei fleischfressende Drachen-Dinos über einen Pflanzenfresser herfallen. Die Szene erinnert mich an letzten Freitag. SAS70-Meeting mit Prozessmanager und Prozessowner zum Thema Releasemanagement.
Ich bin ein SAS70-Controlsaurus-Papyrus (aka Papierfresser aka Vegetarier aka der Pflanzenfresser). Meine zwei Gegensaurier sind vom Typ JAVA-Codusaurus-Rex (aka Fleischfresser). Einer davon, mit schwarzen Stacheln rund ums Maul, dürfte der Giftigere sein. Das bemerkt man an seiner Körpersprache. Totale Konfrontation. Verschränkte Flügel vor der Brust, permanent kommt Rauch aus der Nase. Hat der einen Magic Dragon gepuffed? Sag „SAS70“ zu ihm, und er steckt die Besprechungshöhle in Brand.
Der andere scheint eher ruhiger zu sein, wehrt sich aber weil er nicht Prozessmanager werden will. Der macht einen auf „guter Drache“ im Gegensatz zum anderen, der auf „böser Drache“ macht. D.h., ich muss wohl eher auf den ruhigen aufpassen.
Bereits nach fünf Minuten haben mich die zwei in die Ecke getrieben. Der Stachelige bläht seine Nüstern und reagiert auf Fragen mit aggressiven Gegenfragen: „Wenn ich einen Prozess beschreiben muss, wozu braucht ich dann eine SOP? Das ist doch eh alles das Gleiche! Prozess, SOP, Policy, Guidelines…“. Ich ziehe alle Register um da raus zu kommen.

Ich kann den Stacheligen etwas bändigen, das fällt der andere über mich her. Der Stachellose faucht mit funkelnden Augen: „Nein, so geht das überhaupt nicht. So machen wir das nicht. So werden wir das nicht machen! Das ist ein Blödsinn! Es kann nicht sein dass ein Prozess anderen Prozessen Regeln vorgibt!“. Doch auch da komm ich raus. Ich ziehe vorgefertigte Argumentationen aus meiner Prozessmanagementkiste. Erkläre Geschäftsprozesse, Prozesse, Teilprozesse und Prozessschnittstellen. Nach 30 Minuten haben wir vorerst einmal einen Kompromiss. Ein guter Anfang. Die ganze Besprechungshöhle stinkt nach Rauch.
Der Stachellose wird noch aggressiver. „Wie bitte bist du auf solche Controls gekommen? Was bringen uns die?“. Ich erkläre den beiden das COBiT die Controls vorgibt und nicht ich. Mit einem: „Ahha, wir dachten das sei auf deinem Mist gewachsen!“ nähern wir uns einem Konsens.
Nach langem hin und her, kann ich die zwei davon überzeugen dass uns SAS70, diese Controls und ein dokumentierter Releasemanagementprozess weiter helfen. Trotzdem spucken sie weiter permanent Feuer. Jetzt bin aber ich dran. Die giftige Frage des Stachellosen: „Warum zerlege ich alles in lauter kleine Teile und beschreibe nicht alles einfach in einem riesigen Prozess?“ beantworte ich mit einer Gegenfrage: „Warum zerteilt ihr euren Code in lauter kleine Methoden und Klassen und schreibt nicht eine einzige riesengroße Klasse mit 1000en Lines of Code?“
Zwei Blutunterlaufene Augenpaare funkeln mich an. Ich bemerke ihnen ein paar Kratzer zugefügt zu haben. Die zwei winden sich und schnauben. Die Hitze wird unerträglich. Haha, Drachen die fauchen beißen nicht. Nach 50 Minuten sind wir bei einem Konsens. Wir haben uns auf Prozessablauf, Zuständigkeiten, SOPs und Controls geeinigt, und das alles bis Ende nächster Woche fertig sein soll. Naja, geht ja. Die Fleischwunden haben sich also ausgezahlt.
Im Museum sehe ich einen Film in dem zwei fleischfressende Drachen-Dinos über einen Pflanzenfresser herfallen. Die Szene erinnert mich an letzten Freitag. SAS70-Meeting mit Prozessmanager und Prozessowner zum Thema Releasemanagement.
Ich bin ein SAS70-Controlsaurus-Papyrus (aka Papierfresser aka Vegetarier aka der Pflanzenfresser). Meine zwei Gegensaurier sind vom Typ JAVA-Codusaurus-Rex (aka Fleischfresser). Einer davon, mit schwarzen Stacheln rund ums Maul, dürfte der Giftigere sein. Das bemerkt man an seiner Körpersprache. Totale Konfrontation. Verschränkte Flügel vor der Brust, permanent kommt Rauch aus der Nase. Hat der einen Magic Dragon gepuffed? Sag „SAS70“ zu ihm, und er steckt die Besprechungshöhle in Brand.
Der andere scheint eher ruhiger zu sein, wehrt sich aber weil er nicht Prozessmanager werden will. Der macht einen auf „guter Drache“ im Gegensatz zum anderen, der auf „böser Drache“ macht. D.h., ich muss wohl eher auf den ruhigen aufpassen.
Bereits nach fünf Minuten haben mich die zwei in die Ecke getrieben. Der Stachelige bläht seine Nüstern und reagiert auf Fragen mit aggressiven Gegenfragen: „Wenn ich einen Prozess beschreiben muss, wozu braucht ich dann eine SOP? Das ist doch eh alles das Gleiche! Prozess, SOP, Policy, Guidelines…“. Ich ziehe alle Register um da raus zu kommen.

Ich kann den Stacheligen etwas bändigen, das fällt der andere über mich her. Der Stachellose faucht mit funkelnden Augen: „Nein, so geht das überhaupt nicht. So machen wir das nicht. So werden wir das nicht machen! Das ist ein Blödsinn! Es kann nicht sein dass ein Prozess anderen Prozessen Regeln vorgibt!“. Doch auch da komm ich raus. Ich ziehe vorgefertigte Argumentationen aus meiner Prozessmanagementkiste. Erkläre Geschäftsprozesse, Prozesse, Teilprozesse und Prozessschnittstellen. Nach 30 Minuten haben wir vorerst einmal einen Kompromiss. Ein guter Anfang. Die ganze Besprechungshöhle stinkt nach Rauch.
Der Stachellose wird noch aggressiver. „Wie bitte bist du auf solche Controls gekommen? Was bringen uns die?“. Ich erkläre den beiden das COBiT die Controls vorgibt und nicht ich. Mit einem: „Ahha, wir dachten das sei auf deinem Mist gewachsen!“ nähern wir uns einem Konsens.
Nach langem hin und her, kann ich die zwei davon überzeugen dass uns SAS70, diese Controls und ein dokumentierter Releasemanagementprozess weiter helfen. Trotzdem spucken sie weiter permanent Feuer. Jetzt bin aber ich dran. Die giftige Frage des Stachellosen: „Warum zerlege ich alles in lauter kleine Teile und beschreibe nicht alles einfach in einem riesigen Prozess?“ beantworte ich mit einer Gegenfrage: „Warum zerteilt ihr euren Code in lauter kleine Methoden und Klassen und schreibt nicht eine einzige riesengroße Klasse mit 1000en Lines of Code?“
Zwei Blutunterlaufene Augenpaare funkeln mich an. Ich bemerke ihnen ein paar Kratzer zugefügt zu haben. Die zwei winden sich und schnauben. Die Hitze wird unerträglich. Haha, Drachen die fauchen beißen nicht. Nach 50 Minuten sind wir bei einem Konsens. Wir haben uns auf Prozessablauf, Zuständigkeiten, SOPs und Controls geeinigt, und das alles bis Ende nächster Woche fertig sein soll. Naja, geht ja. Die Fleischwunden haben sich also ausgezahlt.
Mittwoch, 4. November 2009
Q32: Made in Taiwan
Meine Lieblingsszene ist die wo die Helden auf der Mir einen Zwischenstopp machen und auftanken. Irgendwann kommt die Katastrophe. Ein Ventil geht nicht zum Schließen. Alle hantieren außerst vorsichtig herum und wollen das Kleinod der Technik reparieren. Dem Russischen Kosmonaut Lev Andropov, der seit Jahr und Tag auf der Mir Dienst schiebt, reichts. Er drischt mit dem Hammer drauf und das Ding funktioniert wieder.
"Made in Usa, Made in Sowetunion, alles Made in Taiwan!".
Warum ich das erzähle?
Y. mein Ukrainischer Kollege, der im Gegensatz zu Lev schon eine MIG gesteuert hat, repariert seine PC jeden Tag aufs neue. Wie? Hier ein Augenzeugenbericht:
Y. kommt in die heiligen Hallen und dreht seinen PC auf.
Man hört wie der Lüfter leise zu surren beginnt, Leben durchflutet das Motherboard. Ein leiser Pieps verrät uns dass das Bios erwacht.
Plötzlich fängt die Gurke an zu rattern. Die Entwickler wachen aus ihrer Java-Starre auf und starren panisch auf Y. PC's.
Explodiert der jetzt? (Den PC mein ich, nicht Y.) Spielt die Festplatte UFO und wir müssen einen Skydiver* starten?
Und was macht unsere Ukrainischer MIG-Pilot? Gemäß dem Montesorri-Motto "A gsunde Watschn hat noch keinem geschadet" verpasst er dem PC eine mit der flachen Hand.
Das Zucken seiner Schulter im gleichklang mit der Aussage "Na, geht ja" zaubert wieder ein leisen Surren in die Eingeweide des PC's.
Die Watschen werden täglich stärker, die Geräusche auch. Bin gespannt wer zuerst aufgibt.
*Mit der Anspielung könnten nur ältere Semester was anfangen.
Labels:
Armageddon,
Java,
MIG-Pilot
Donnerstag, 11. Juni 2009
Q6: Ich will auch so einen Großen haben
Jetzt hat's nur mehr 00:03:46 gedauert. Das Sprichwort "Was Haenschen nicht lernt, lernt Hans nimmermehr" ist somit widerlegt.
HMMMM..., Irgendwo im Büro ist ein Buch "Java - für Hänschen" herum gelegen. Das werd ich jetzt mal suchen und danach lass ich mich beim Mann mit dem 30Zoll Bildschirm ( "Baueh, bin ich neidig auf die Größe! Typisch Mann halt.") auf die Warteliste für das neuen DEV-Package setzen.
Labels:
DEV-Package,
Java
Abonnieren
Posts (Atom)








