Vortrag zum inkrementellen Entwurf auf XP-Days und Scrum-Gathering

Die Präsentation zum inkrementellen Entwurf, die ich auf den XP-Days Germany in Karlsruhe gehalte habe, findet sich hier als Prezi-Flash-Präsentation.

Einen fast identischen Vortrag habe ich auch auf dem Scrum-Gathering in München gehalten. Hier ist die Prezi-Präsentation dazu.

Die Präsentationen habe ich mit Prezi erstellt. Die Vorteile von Prezi aus meiner Sicht, habe ich bereits in einem anderen Blogeintrag beschrieben.

Mikroschritte in Code-Kata

Bernd Schiffer und ich haben eine Code-Kata mit TDD programmiert. Nach ein paar Refactorings hatten wir Groovy-Code, der ungefähr so aussah (ich habe das konkrete Beispiel gegen ein einfacheres ausgetauscht):

def toString(number, range = (1..number).reverse()) {
    if (range.empty) return ""
    def item = range.last()
    "$item" + toString(number, range - item)
}

assert '1' == toString(1)
assert '12' == toString(2)
assert '123' == toString(3)
assert '1234567891011' == toString(11)

"toString" liefert einen String mit den Zahlen 1 bis "number". In "range" finden sich die jeweils noch zu bearbeitenden Zahlen. Das kann man in Groovy natürlich viel einfacher hinschreiben:

def toString(number) {
	(1..number).join() 
}


Aber für den Punkt dieses Blog-Beitrags bleiben wir bei der ursprünglichen Implementation. Wir bleiben also bei der "range" und fokussieren auf ein anderes Problem. Wir verdrehen bei der Erzeugung der Range die Reihenfolge mit "reverse" und greifen hinterher mit "last" darauf zu. Es wäre einfacher, wenn wir die Reihenfolge unverändert ließen und mit "first" auf das jeweils erste Element zugreifen würden. Wir brauchen also ein Refactoring, das diese beiden Stellen im Code ändert.

Dummerweise steht der Bernd davor. Er ist dagegen, dass wir einfach diese zwei Stellen im Code ändern. Er meint, das sei nicht der "grüne Weg", weil nach der ersten Änderung (entfernen von "reverse") die Tests (asserts) nicht mehr laufen. "Aber alle zwei Änderungen finden in derselben Methode statt. Das kann man doch problemlos in einem Schritt ändern und dann ist alles grün. So ist es doch viel schneller." Aber Bernd bleibt dabei. Das ist ihm zu großschrittig (ein Schulungsteilnehmer sagte einmal sinngemäß "Ich dachte immer kleiner als Elektron geht nicht, aber jetzt kenne ich den Bernd-Schritt als kleinstes Element."):

  1. Wir arbeiten an einer Code-Kata. Dabei geht es darum, dass wir unsere Programmierfähigkeiten verbessern. Es geht nicht darum, die Kata in möglichst kurzer Zeit durchzuführen. Es geht darum, sie möglichst gut durchzuführen - wie bei einer Karate-Kata.
  2. Wir stehen in der Praxis immer wieder vor großen Refactorings, die wir nicht in kleine Schritte zerlegt bekommen und die uns den letzten Nerv kosten. Je kleinschrittiger wir vorgehen können, umso besser können wir große Refactorings zerlegen. Wenn wir es schaffen, dass die Tests nach jeder Änderung eines Ausdrucks grün sind, dann können wir für jedes große Refactoring einen komplett grünen und damit sicheren Weg beschreiten.
  3. Wenn wir mehrere Änderungen auf einmal durchführen, laufen wir immer Gefahr, versehentlich Funktionalität zu erweitern - die dann nicht durch Tests abgedeckt ist. Wenn wir jeweils nur einen Ausdruck ändern, können wir normalerweise sehr sicher abschätzen, ob wir die Funktionalität erweitert haben.

"OK, Bernd hat Recht. Versuchen wir es Kleinstschrittig. Äh, geht das denn überhaupt?"

Ja, es geht. Gleicht kommt die Lösung. Wer sich selbst an der Aufgabe versuchen möchte, sollte hier nicht weiterlesen und es erstmal selbst versuchen. Die Regel: Einen Ausdruck ändern, Tests ausführen, es muss alles grün sein. Danach der nächste Ausdruck.

Eine Lösung
Es gibt verschiedene Möglichkeiten, das Problem zu lösen. Hier eine mögliche Lösung:

Zuerst vereinfache ich den "range"-Defaultwert, indem ich das umdrehen der Elemente bereits beim Hinschreiben erledige:

def toString(number, range = number..1) {
    if (range.empty) return ""
    def item = range.last()
    "$item" + toString(number, range - item)
}


Jetzt kommt der interessante Teil. Die Reihenfolge der Elemente in "range" hängt direkt mit dem Zugriff über "last" zusammen. Wenn ich "last" durch "first" ersetzen möchte, muss ich dafür sorgen, dass in "range" am Anfang und Ende dasselbe Element steht. Das erreiche ich, indem ich "range" quasi verdoppele:

def toString(number, range = (1..number)+(number..1)) {
    if (range.empty) return ""
    def item = range.last()
    "$item" + toString(number, range - item)
}


Dass "range" jetzt jede Zahl doppelt enthält, schadet nicht, weil "range - item" alle "item"s entfernt. Mit diesem verdoppelten Range liefert "last" dasselbe Ergebnis wie "first", so dass ich die Ersetzung problemlos vornehmen kann.

def toString(number, range = (1..number)+(number..1)) {
    if (range.empty) return ""
    def item = range.first()
    "$item" + toString(number, range - item)
}


Jetzt kann ich den Default-Wert für "range" wieder vereinfachen:

def toString(number, range = 1..number) {
    if (range.empty) return ""
    def item = range.first()
    "$item" + toString(number, range - item)
}


Und fertig bin ich mit meinem Refactoring. Wir haben nach jeder Änderung eines Ausdrucks die Tests durchlaufen lassen und sie waren immer grün. In der Praxis würde man in diesem Beispiel vielleicht nicht so kleinschrittig vorgehen. Aber hier geht es um den Trainingseffekt!

Eine interessante Frage ist sicherlich, ob es immer solche kleinschrittigen Auflösungen gibt oder ob es Fälle gibt, wo das nicht funktioniert. Wenn Ihr Refactoring-Beispiele habt, von denen Ihr glaubt, dass es keine Kleinstschrittige Zerlegung gibt, schickt mir die! Entweder an stefan AT stefanroock DOT de (AT durch @ und DOT durch . ersetzen) oder als Kommentar an diesen Blog-Beitrag.

Programmierkatas

Auf den XP-Days Germany 2009 fand ein Format namens „TDD mit den Profis“ statt. Die Idee ist, dass Paare bestehend aus einem TDD-Profi und einem nicht so erfahrenen TDDler gegeneinander antreten. Die Paare führen in kurzer Zeit TDD und Pair-Programming vor. Bei den XP-Days hatten die Paare in der Vorrunde 5 Minuten Zeit und im Finale 8 Minuten.
Ich bin mit meiner Pair-Partnerin ins Finale gekommen, musste mich dort aber mit dem zweiten Platz zufrieden geben.

In der Vorrunde konnten sich die Paare sehr frei aussuchen, was sie vorführen. Im Finale gab es vorgegebene Code-Katas (siehe Konzept der Code-Katas siehe Wikipedia). Für die Vorrunde hatten wir mehrere Tage für die Vorbereitung Zeit, für das Finale 2 Stunden.

Code-Katas hatte ich vorher bereits programmiert. Allerdings nicht so, wie es für die XP-Days-Sessions notwendig war. In der Kürze der Zeit lässt sich nur dann sinnvoll etwas zeigen, wenn man die Übung auswendig und flüssig vorführen kann. Und dafür muss man sie einüben. Und das bedeutet, die Kata in der Vorbereitung mehrfach zu programmieren und immer wieder zu variieren, um den besten Ablauf zu finden.

Und dieses mehrfache Programmieren derselben Aufgabe war entgegen meinen Erwartungen nicht langweilig, sondern sehr interessant und lehrreich. So haben wir auf der Konferenz meine Finalaufgabe (Primfaktorzerlegung) nochmal während des Community-Day programmiert (im Rahmen eines Coding Dojos) und auf der Rückfahrt von Karlsruhe mit der Bahn nach Hamburg haben Bernd Schiffer und ich die Code-Kata nochmal programmiert.

Robert Martin hat die Code-Kata sogar zu Musik vorgeführt und damit Programmierung in die Nähe einer Kunstform gebracht.

Buch: Sexy Webdesign

Ich habe das Buch Sexy Webdesign von Elliot Jay Stocks gelesen.

Ich bin kein Web-Designer und habe auch keine Ambitionen, einer zu werden. Ich bin aber natürlich interessiert daran, besseres Webdesign zu machen. Damit stehe ich vielleicht nicht direkt im Zentrum der anvisierten Zielgruppe.

Persönlich konnte ich nicht viel mit dem Buch anfangen. Ich hatte das Gefühl, dass auf den ersten 80 Seiten nur Trivialitäten stehen. Immer, wenn es interessant wird, kommt nichts mehr – allenfalls ein Verweis auf andere Bücher. Dann kommen 20 Seiten, die einige interessante Informationen (vor allem in Form von Internetadressen) bieten. Danach kommen wieder Trivialitäten.

Immerhin ist das Buch optisch ansprechend gestaltet.

Hier meine persönlichen Erkenntnisse aus dem Buch:

  • Der goldene Schnitt liefert eine gute Richtlinie für Seitenaufteilungen, die angenehm aussehen. Es gibt mit goldenratiocalculator.com einen Internet-Service, der hilft, Abmessungen nach dem goldenen Schnitt zu berechnen.
  • Ausrichtung an Rastern ist sinnvoll – das ist trivial. Hilfestellung in Form von Vorlagen für CSS und Photoshop findet man bei 960.gs. Das sind wirklich interessant und nützlich aus. Das werde ich auf jeden Fall mal ausprobieren.
  • Farben, die zusammenpassen, findet man mit Hilfe des Farbkreises. Auch hier helfen Internet-Services wie
    colorschemedesigner.com oder colourlovers.com.

Gute und schlechte Vorträge: Alles eine Frage der Geschichten?

Ich glaube, dass ich inzwischen ein ganz gutes Gefühl dafür habe, wie gut meine Vorträge beim Publikum ankommen. Bei meinen schlechten Vorträgen bekomme ich während des Vortrags aus dem Publikum nichts zurück: kein Lachen, kein Murren, keine ungläubigen Gesichter.

Meine Selbsteinschätzung deckt sich meist mit dem Feedback, das die Konferenzorganisatoren einsammeln.

Lange Zeit war mir unklar, warum einige meiner Vorträge gut beim Publikum ankommen und andere nicht. Ich hatte bereits beoachtet, dass schlecht vorbereitete Vorträge besser ankommen als gut vorbereitete. Das fand ich schon immer sehr merkwürdig. Reicht es tatsächlich aus, schlecht vorbereitet zum Vortrag zu kommen und alles wird gut? Und warum zum Geier ist das so?

Inzwischen habe ich ein Erklärungsmodell gefunden, dass mir plausibel erscheint: Über Twitter hatte jemand seine Beobachtung auf einer Konferenz geschildert, dass die guten Vorträge immer mit einer Geschichte beginnen und daraus eine Einsicht ableiten.

Das passt sehr schön damit zusammen, dass der Fantasy-Autor Terry Pratchett immer wieder betont, wie wichtig Geschichten für uns Menschen sind. Er spricht vom Homo Narrativus. Geschichten transportieren Emotionen und die sind wichtig, damit wir interessiert sind.

Bleibt noch die Frage, wie das mit der schlechten Vortragsvorbereitung zusammenpasst. Ich glaube, das funktioniert so: Es ist ja nicht so, dass ich vollkommen ohne Vorbereitung zum Vortrag gehe. Ich habe nur entweder „zu spät“ mit der Vortragsvorbereitung begonnen oder kurz vor dem Vortrag nochmal das Gesamtkonzept umgeworfen. Ich habe also die Tage bzw. Nächte vor dem Vortrag an dem Vortrag gearbeitet. Gefühlt war die Zeit aber zu kurz und das zeigt sich an niedrig aufgelösten Bildern, Rechtschreibfehlern auf den Folien und allgemeinen Layout-Unschönheiten. Darüber scheinen die Teilnehmer aber gerne hinwegzusehen.

Dafür erscheine ich zum Vortrag emotional: Ich bin schlecht vorbereitet und habe schlechte Folien dabei und das weiß ich auch. Das sind keine positiven Emotionen, aber immerhin sind es Emotionen. Sie führen dazu, dass ich den Vortrag meistens emotionaler halte und nicht einfach kühl Fakten runterrattere.

Außerdem bin ich mit diesem Verfahren „voll im Thema“, wenn ich mit dem Vortrag beginne. Gut vorbereitete Vorträge habe ich schon Wochen vor dem Vortragstermin fertig. Wenn ich den Vortrag dann halte, kann ich mich bei einigen Folien nicht mehr erinnern, was genau ich mir dabei gedacht habe und bin auch zu den Folien distanziert.

Ich nehme also zwei Dinge für mich ganz persönlich mit (keine Ahnung, ob sie auch für andere funktionieren):

  1. Beginne mit einer Geschichte und leite daraus Einsichten ab.
  2. Bereite den Vortrag so spät vor, dass er gerade noch fertig wird. Gehe lieber das Risiko ein, mit schlechten Unterlagen zum Vortrag zu erscheinen als mit einem Vortrag, der schon Wochen vor dem Termin fertig war.

Präsentationen mit Prezi

Auf dem Scrum-Gathering in München habe ich meine erste echte Prezi-Präsentation gehalten. Prezi hat einen neuartigen Ansatz für Präsentationen. Es gibt im Grunde nur eine riesige „Folie“, auf der man alle Inhalte platziert. Dann definiert man einen Pfad durch die Inhalte, der angibt, welche Ausschnitte wann angezeigt werden. Die Navigation entlang dieses Pfades visualiert Prezi dann durch coole Effekte (bewegen, drehen, zommen).
Ich habe mir Prezi ursprünglich angesehen, weil die Übergänge so cool aussahen. Das tun sie heute noch. Aber wahrscheinlich verbraucht sich dieser Effekt mit der Zeit – genauso wie die coolen Folienübergänge in Keynote.

Aber auf den zweiten Blick bietet Prezi eine ganz neue Art der Organisation der Präsentation. In Powerpoint und Keynote ordne ich die Folien streng linear an. Bei Prezi habe ich die X- und Y-Achse und außerdem das Herein- und Herauszoomen. Daher eignet sich Prezi auch, um eine Präsentation vorzubereiten und zu organisieren – Powerpoint und Konsorten eignen sich dafür nicht gut, weil sie durch ihre Linearität das Denken zu sehr beschränken.

Und dann spielt Prezi noch einen Vorteil aus, den ich sehr zu schätzen weiß: Prezi basiert auf Flash und läuft auf jedem Browser und offline überall dort, wo Adobe AIR läuft – also auch unter Ubuntu. Prezi ist also wirklich cross-plattform-fähig.

Wenn man sich das erste Mal mit Prezi beschäftigt, ist die Bedienung gewöhnungsbedürftig. Aber wenn man sich mal dran gewöhnt hat, ist sie sensationell gut.

Für einen ersten Eindruck, was mit Prezi möglich ist, siehe hier.

Lernen im dritten Quartal 2009

Damit habe ich mich im dritten Quartal 2009 beschäftigt:

  • Ich habe das Buch Subject to Change gelesen. Meine Eindrücke habe ich bereits im Blog beschrieben: Es geht darum, wie heute Produkte und Services entwickelt werden müssen. Das ganze passt wenig überraschend mit agilen Ansätzen wie Scrum ganz wunderbar zusammen.
  • Dann habe ich mich ziemlich intensiv mit Prolog beschäftigt und einige Beiträge in diesem Blog darüber veröffentlicht. Das war allemal horizonterweiternd – Prolog ist eben doch sehr anders als andere Programmiersprachen. Ich finde es nach wie vor Schade, dass Prolog heute ziemlich tot zu sein scheint und die Sprache nicht ernsthaft weiterentwickelt wird. Relektionen über Prolog.
  • In Prolog habe ich ann auch gleich ein kleines BDD-Framework gebaut und damit mein BDD-Verständnis verbessert.
  • Joseph Pelrine ist dafür verantwortlich, dass ich noch etwas über Teamdynamik gelernt habe: Hochproduktive Teams kochen.
  • Von einem Kunden habe ich mich belehren lassen, was die mögliche Produktivität verteilter Teams anbelangt.
  • Ein ganz kleines bisschen Perl habe ich gelernt. Und zumindest für kleine Skripte kann ich nicht erkennen, was an Perl schlecht sein soll.
  • In einem Projekt habe ich Selenium RC eingesetzt und den designierten Nachfolger Google Web-Driver.
  • Ich habe meine Rails-Kenntnisse deutlich vertieft. Dazu habe ich das Buch Rapid Web Development mit Ruby on Rails gelesen. Das ist nicht mehr ganz aktuell, aber ich hatte es ohnehin noch im Bücherregal stehen und für einen Überblick war es OK. Anschließend habe ich begonnen, eine echte (kleine) Anwendung in Rails zu programmieren und bin davon ganz angetan. Nur mit der Installtion unter Ubuntu hatte ich anfänglich einige Probleme.
  • Im Rails-Zusammenhang habe ich mich auch mit RSpec, Cucumber und Webrat beschäftigt. Auch das sieht für mich alles sehr schön und elegant aus. Das Oberflächentesten mit Webrat ist z.B. sehr schön einfach und schnell.
  • Bei einem Kunden habe ich mich etwas mit TestNG beschäftigt. Naja. Für TDD kann ich gegenüber JUnit keine Vorteile erkennen.
  • Ich habe mit dem Buch SOA in Praxis ein weiteres Buch aus dem Regal geholt, dass dort schon eine Weile stand. Mein Review dazu habe ich im Blog beschrieben. Das Buch war durchaus lohnenswert, auch wenn ich kein SOA-Fan bin.
  • Bei einem Kunden durfte ich erleben, wie Kanban in der Praxis eingesetzt wurde – zumindest anfänglich auch mit interessanten Schwierigkeiten.
  • Neben CSM-Kursen biete ich inzwischen auch CSPO-Kurse an. Bei der Vorbereitung des CSPO-Kurses habe ich viele Dinge über Product-Owner-Arbeit reflektiert und neu gelernt.
  • Und zum Beweis, dass ich noch nicht vollkommen Plem-Plem bin, habe ich auch etwas im Bereich außerhalb der IT gemacht. Ich habe beim Windsurfen Racejibe und Sinkerwende gelernt. OK, Racejibe geht bisher nur rechtsrum, aber das wird noch. Ich hoffe, auf einen milden und windreichen Jahresausklang.
  • Und dann habe ich mir von meinem kleinen Bruder zeigen lassen, wie Brustschwimmen und Kraulen richtig funktioniert. Und siehe da: Das einzige, was ich bisher richtig gemacht habe, dass ich eine Badehose anhatte. Immerhin erklärt es, warum ich so ein schlechter Schwimmer bin. Jetzt muss ich die richtige Technik „nur“ noch üben.

Damit habe ich von dem, was ich mir für das dritte Quartal vorgenommen habe, fast alles geschafft. Nur Scala habe ich mir nicht angesehen. Ich fand es dann doch spannender einfach Rails zu programmieren und aus demselben Grund werde ich wahrscheinlich auch im vierten Quartal nicht dazu kommen, mir Scala anzusehen.

Buchtipp: „SOA in der Praxis“ von Nicolai Josuttis

Ich weiß, dass ich etwas spät dran bin, wenn ich jetzt noch SOA-Bücher lese. Das dpunkt-Buch „SOA in der Praxis“ von Nicolai Josuttis aus dem Jahr 2008 hatte ich bereits kurz nach dem Erscheinen in meinem Bücherregal. Aber ich bin jetzt erst zum Lesen gekommen – wer bösartig ist, könnte das Buch heute auch als eine Art Nachruf auf SOA verstehen. Der SOA-Hype ist sicher inzwischen vorbei. Jetzt kann man sich trefflich darüber streiten, ob jetzt einfach der unspektakuläre SOA-Einsatz stattfindet oder ob schon Verwesungsgeruch in der Luft liegt.

Aber zum Inhalt: Der Autor beschreibt SOA vor dem Hintergrund seiner umfangreichen Praxiserfahrungen. (Für alle, die noch lahmer sind als ich: SOA steht für „Service Oriented Architecture“.) Und gerade diese Praxiserfahrungen mach einen erheblichen Unterschied zu vielen anderen SOA-Veröffentlichungen. Bei Josutti werden die ganzen unangenehmen Probleme beschrieben, die beim Einsatz von SOA zwangsläufig auftreten: Transaktionen, Versionierung, Migration, Verfügbarkeit etc. Diese und andere Probleme treten beim SOA-Einsatz auf. Sie können gelöst werden, aber nicht einfach. Josuttis schließt mit:

„Aus diesem Grund sollte SOA nie ein Selbstzweck sein. Wenn man Verteilung vermeiden kann, sollte man das tun.“

Ich empfehle das Buch jedem, der SOA einführen muss oder will. Diejenigen, die SOA einführen müssen, finden hier die zu erwartenden Probleme inkl. möglicher Lösungsstrategien. Diejenigen, die SOA einführen wollen, bekommen vor Augen geführt, wie komplex die ganze Angelegenheit ist und können sich dann nochmal ernsthaft überlegen, ob sie SOA wirklich wollen.

Ich bin nach dem Lesen des Buches jedenfalls froh, dass ich bisher nichts mit SOA zu tun hatte und hoffe, dass das auch so bleibt.

Trotzdem war die Lektüre keine Zeitverschwendung. Viele der Konzepte lassen sich in großen Systemen auch dann anwenden, wenn es nicht um SOA im eigentlichen Sinne geht. So ist das Thema Idempotenz beispielsweise relevant, wenn man seine Internetanwendung mit einer REST-Schnittstelle versieht. Die Diskussionen zu Entkopplung sind ebenfalls auch ohne SOA relevant. Etc.

Ubuntu, Audiogeräte und Skype

Die Audioeinstellungen für Skype unter Ubuntu zum Laufen zu kriegen, kann ziemlich umständlich sein. Hier meine bisherigen Erkenntnisse.

Zuerst sollte man sicherstellen, dass die Soundwiedergabe unter Ubuntu überhaupt funktioniert. Dazu einfach ein YouTube-Video abspielen oder eine MP3-Datei mit Rythmplayer o.Ä. Meistens funktioniert die Soundwiedergabe aber per Default.

Jetzt sollte man prüfen, dass das Mikro prinzipiell unter Ubuntu funktioniert. Dazu den Audio-Rekorder (Menü Anwendungen->Unterhaltungsmedien) verwenden. Hier taucht dann häufig schon das erste Problem auf: Die Aufnahme funktioniert nicht. Jetzt:

  1. Prüfen, dass man überhaupt die Rechte für den Zugriff auf das Mikro besitzt (Menü System->Systemverwaltung->Benutzer und Gruppen, Kartenreiter Benutzerrechte). Wenn die Rechte fehlen, „Entsperren“ anklicken und die Rechte ergänzen. Ich bin mir nicht sicher, ob man danach neu Booten muss oder sich zumindest neu anmelden.
  2. Prüfen, ob das Mikro aktiviert ist. Dazu rechts oben auf dem Lautsprechersymbol rechte Maustaste drücken und sicherstellen, dass „Stummschalten“ nicht angehakt ist. Danach dort wieder rechte Maustaste und Menü „Lautstärkeregler öffnen“ anwählen. Dann „Einstellungen“ wählen und alle Aufnahmegeräte anwählen. Anschließend die Regler für die Aufnahmegeräte hochdrehen und ggf. Mikros aktivieren.
  3. Pulse-Audio scheint bei mir immer das Mikro zu blockieren, manchmal auch die Lautsprecher. Wenn ich mit ps aux | grep pulse nach den entsprechenden Prozessen suche und diese kille, funktioniert wieder alles. Bisher ist mir noch unklar, warum diese Pulse-Audio-Prozesse überhaupt gestartet werden.

Wenn damit sichergestellt ist, dass Aufnahme und Wiedergabe unter Ubuntu prinzipiell funktionieren, kann man sich Skype zuwenden. in Skype „Optionen“ öffnen und dort „Audiogeräte“ auswählen. Standardmäßig stehen die Audiogeräte auf „Default“. Das hat bei mir noch nie funktioniert. Gute Erfahrungen habe ich mit „HDA Intel (hw:Intel,0)“ gemacht. Mit „Testklang abspielen“ kann man dann prüfen, ob die Lautsprecherwiedergabe funktioniert. Mit „Testanruf tätigen“ kann man auch die Mikrofunktion testen.

Mind. einmal hatte ich auch den Effekt, dass in Skype „Automatische Soundeinstellungen aktivieren“ nicht angehakt sein durfte: Wenn der Schalter angehakt war, hat Skype meine Mikro-Regler runtergeschoben.

Ergänzungen nehme ich jederzeit gerne hier auf.

Surfen auf Rügen

Die ersten beiden Oktoberwoche war ich mit der Familie im Urlaub auf Rügen. Mit Pausen haben wir 8 Stunden für die Anreise gebraucht – wer hätte gedacht, dass man auf Rügen von links unten nach links oben mehr als eine Stunde brauchen kann… Aber die Insel war für mich dann doch überraschend groß und überall ist der Bodden im Weg, so dass man große Bogen fahren muss.

Windsurf-Reviere
Auf der anderen Seite bietet der Bodden coole Surfreviere. Wir haben in Dranske gewohnt. Dort kam allerdings der westliche Wind schräg ablandig und war durch die Abdeckung erst weit draußen einigermaßen stabil. Daher sind wir jeweils die 10 Minuten nach Wiek gefahren. Dort kann man (gegen Geld) direkt am Wasser parken, hat einen großen Stehbereich und Westwind kommt auflandig. Man hätte in Wiek auch direkt am Wasser wohnen können (z.B. Villa Maris, Strandhaus Wiek), aber das wussten wir vorher nicht.

Sowohl in Wiek wie auch in Dranske gibt es Surfstationen – die in Wiek sah aber etwas schäbig aus.

An einem Flautentag haben wir uns noch Surendorf auf Rügen angesehen. Dort hat man in der Breite 12 km Stehbereich, kommt aber nur über den Campingplatz ans Wasser. Sah aber auch sehr nett aus.

Der Wind
Mit dem Wind hatten wir Glück. Wir waren 14 Tage auf Rügen und hatten an zwei Tagen weniger als 4 Bft. Drei weitere Tage lagen bei 4 Bft., so dass man mit dem Kite oder großem Windsurf-Segel hätte auf’s Wasser gehen können. Das bedeutet, dass wir 9 Tage zwischen 5 und 9 Bft. hatten – eine ganz nette Wind-Ausbeute.

Das Wetter
Der erste Tag war sonnig und über 20 Grad warm. Danach kam der Temperatursturz auf 10-14 Grad. Allerdings hatten wir kaum Regen und häufig Sonne. So war es ganz gut auszuhalten.

Die Landschaft
Landschaftlich war Rügen überraschend hügelig und überraschend stark bewaldet. Auf jeden Fall sehr nett. Und obwohl Rügen eher dünn besiedelt ist, haben wir für die Kinder immer ausreichend Abwechslung gefunden. Dabei hat uns der Reiseführer Was machen wir morgen, Mama? sehr geholfen.

Die Leute
Wir hatten das Gefühl, dass die Leute im Service im Schnitt unfreundlicher und weniger aufmerksam waren, als wir das in anderen deutschen Urlaubsgebieten erlebt haben. Es gab aber auch Ausnahmen, wie z.B. unseren Vermieter der Ferienwohnung Alter Schwede.

Mein Fazit
Kann man mal wieder machen. Mehr Infos zu Rügen findet man z.B. unter http://www.ostsee24.de/ostseekueste/insel-ruegen.