Der erste Tag der Basta! Spring 2010 Hauptkonferenz neigt sich dem Ende entgegen. Begonnen hat er wie üblich mit einer Keynote, in diesem Fall 2010 – Cloud oder Desktop – wohin geht die Reise?.  Adressiert wurde damit das Spannungsfeld zwischen Azure 1.0 als “direkter” Cloud Computing Strategie, Windows 7 (“Hoch lebe der Desktop!”) und Silverlight 4.0 (“Three screens and a cloud“) irgendwo dazwischen. Die Keynote selbst erschöpfte sich dann allerdings hauptsächlich in einer Auflistung/Demonstration neuer (durchaus nicht schlechter) Features hauptsächlich von Visual Studio 2010 und TFS 2010 und blieb für mich eher blass.

Nun folgte für alle weiteren Sessions (bei jeweils 4 parallelen Tracks) die Qual der Wahl, ich entschied mich zunächst für Mit Enterprise Architect durch den Projektalltag mit Horst Kargl: Außer den grundlegenden Konzepten konnte man hier auch den einen oder anderen Denkanstoß mitnehmen, z.B.

• alle Metadaten eines Uses Cases im EA erfassen und die UC-Beschreibung automatisch daraus generieren (dies ist durchaus nicht selbstverständlich, wenn man das Anforderungsmanagement nicht im EA, sondern z.B. mit TFS betreibt und den EA “nur” für die Diagramme nutzt)
• Einschränkung der Freiheitsgrade durch UML Profile (bis hin zur Überprüfung von Designrichtlinien durch Validierungsregeln)
• “Shared Model” vs. “Private Model + Versionskontrollsystem” als unterschiedliche Herangehensweisen für verteiltes Arbeiten
• Steuerung der Dokumentationserstellung durch
  • Modellierung der Doku-Generierung
  • Verwendung des erzeugten XMI z.B. zusammen mit XSD
  • Verwendung der EA-API
• Zur Codegenerierung eignen sich außer Klassendiagrammen noch Aktivitätsdiagramme, Sequenzdiagramme und Zustandsautomaten
• Tipp: automatische Modellgenerierung aus dem Code mittels Build-Skript (zusammen mit CI hat man dann immer aktuelle Modelle)
• hilfreiche EA Features zum Thema “Tracen und Suchen”:
  • Relationship-Matrix
  • Hierarchy View
  • Search query (mittels Query Builder, SQL Editor oder 3rd Party Add-Inns)

Als nächstes ziehe ich mir Dynamisch konsumieren in C# 4.0 mit Oliver Sturm rein. Das erweist sich als gute Wahl, da sowohl spannend als auch aussagekräftig. Hier kurz die für mich interessantesten Punkte:

• “dynamic” wird zwar verwendet wie ein Typ, ist aber keiner, daher
  • gibt es keine Basisklasse dafür
  • kann man nicht davon ableiten
  • kann man keine Extension Methods davon erzeugen (aber wer wollte das auch?)
• es gibt keine IntelliSense-Unterstützung (es gibt durchaus dynamische Sprachen, bei denen das geht…)
• ExpandoObject(): sieht erstmal cool aus – aber gibt es eine sinnvolle Verwendung dafür?

Dann gibt es zwei Demos, eine zu Excel-Automatisierung (die außer von “dynamic” auch beträchtlich von den unter C# 4.0 möglichen optionalen Parametern profitiert!) und die andere zu Screen-Scraping mittels Python und BeautifulSoup – natürlich in C# integriert. Ziemlich beeindruckend. Als Quintessenz nehme ich mir mit: “C# 4.0 ist nicht wirklich dynamisch, aber man kann damit gut mit dynamischen Sprachen interagieren.”

Nach dem Mittagessen entscheide ich mich für Visual Studio 2010 & TFS 2010: Neues für Entwickler und Tester mit Neno Loje. Erwartungsgemäß wird es recht unterhaltsam, hier ein paar Stichworte:

• “No more no repro!” lautet der neue Tenor für Testing und Bugreproduktion
• Test Impact: von einer Codeänderung/einem Changeset betroffene Testfälle ermitteln (sozusagen das “Gegenstück” zu Code Coverage)
• “Debuggen mit mehreren Entwicklern”: nicht (wie man vermuten könnte) gleichzeitig, sondern nacheinander mittels Export/Import
• verbesserter Profiler: sehr leistungsfähig, aber nicht gerade intuitiv bedienbar
• IntelliTrace: sowohl für Entwickler (Debugging) als auch für Tester (“Anreichern” von Bugs) interessant
• Fast Forward für manuelles Testen: automatisches “Vorspulen”, um Standardfunktionen wie z.B. Login zu automatisieren und nur den “eigentlichen Testfall” manuell auszuführen
• UML Integration
  • 5 Diagrammtypen werden unterstützt: Aktivität, Klasse, Komponente, Sequenz und Use Case
  • Sequenzdiagramme können automatisch aus dem Code generiert werden
  • Diagramme können (wie andere Artefakte auch) mit TFS Work Items verknüpft werden
• Branching & Merging
  • Branch Hierarchy
  • Tracking von Changesets
  • Annotate View (“Wer ist schuld?”-Ansicht) jetzt auch für Merges
• Gated CheckIn: Der CheckIn wird erstmal “testweise” ausgeführt. Nur wenn der Build (incl.  Unit Tests etc. je nach Konfiguration) erfolgreich war, wird er endgültig ausgeführt – anderenfalls zurückgerollt.

Spannend wird es wieder bei Using Mocks for State and Interaction based Testing mit Hadi Hariri. Zuerst gibt es einen exkurs zum Thema “Design for testability” (Unit Tests testen genau eine Funktionalität und haben genau eine Ursache, fehlzuschlagen. Unit Tests, die DB-Zugriffe beinhalten, sind keine Unit Tests, sondern Integrationstests.) Des Problemes Lösung heißt Dependecy Injection. Die kommt mit “handgemachten” Mocks genau so zum Einsatz wie mit Mocking Frameworks, vorgestellt werden RhinoMocks und moq. Der größte Unterschied ist, das RhinoMocks zwischen Mocks und Stubs unterscheidet, wogegen moq nur Mocks kennt. An dieser Stelle wird auch noch der Unterschied zwischen Stub und Mock erklärt: Stubs verwendet man für das Testen von Verhalten (also z.B. einer Funktion), Mocks dagegen für das Testen von Interaktionen (was viel seltener vorkommt). Quintessenz des ebenso lehrreichen wie unterhaltsamen Vortrages: “Unit Testing ist unproduktiv, wenn man es nicht richtig macht”.

Mit Datenvisualisierung aus Usability-Sicht mit Tobias Komischke gibt es vor dem Abendbrot noch was “Leichtverdauliches” – deshalb nicht weniger interessantes. Welche Diagrammarten eignen sich für welche Visualisierungen? Welche Funktionen haben Farben und Formen? – und weitere Fragen dieser Art werden gestellt und – soweit möglich – beantwortet. Hier wieder ein paar Stichpunkte:

• Legenden sind generell problematisch, da der Betrachter immer zwischen Grafik und Legende “hin- und herspringen” muss.
• Balkendiagramme sind amleichtesten zu verstehen.
• Tortendiagramme werden problematisch bei mehr als 5 Segmenten.
• 3D-Diagramme bergen generell ein ziemlich großes Problempotential in sich.
• “Stress what’s important!” (z.B. durch Farben/Intensität, Formen, Orientierung, Größe, Blinken, …)
• Blau und rot ohne Zwischenraum direkt zusammen ist ein No-Go.
• “Show as much as necessary and as little as possible!”
• “Eine Grafik, die nicht selbsterklärend ist, ist eine schlechte Grafik.”

Zum Schluss noch ein Tipp: unter http://vizlab.nytimes.com/ werden verschiedene Datenreihen mit  unterschiedlichen Diagrammtypen und Optionen dargestellt – dort kann mal sich einen Eindruck über die Wirkungen verschaffen…

Nach Abenbrot und Freibier gibt es noch eine Night School. Ich wähle Agiles Arbeiten oder arbeiten in agilen Projekten – ein psychologischer Diskurs mit Michael Tute und Wolfgang Boelmann. Das lässt sich auch interessant an – wir erfahren etwas über Single-Loop-Learning und Double-Loop-Learning und werden dann in die “Reflecting Team”-Technik eingeführt. Dies wird dann gleich an einem praktischen Beispiel ausprobiert – unverändert interessant, allerdings hat sich ob der zahlreich anwesenden Raucher die Luftdicke gefühlt mindestens verzehnfacht – weshalb ich den Rückzug und die Flucht ins Freie antrete.

Auf dem Weg ins Hotel kann ich den Tag noch einmal Revue passieren lassen. Fazit: ein ausgefüllter Tag – mit teilweise schon Bekanntem, aber ebenso mit Neuem (oder auch: so noch nicht Betrachtetem), dies alles in breiter Themenvielfalt.