Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
0800 1 255 255

Neues aus der .Net Welt von der Basta! Spring (1. Tag)

Der erste Tag der Basta! Spring 2010 Hauptkonferenz neigt sich dem Ende ent­ge­gen. Begonnen hat er wie üblich mit einer Keynote, in die­sem Fall 2010 – Cloud oder Desktop – wohin geht die Reise?.  Adressiert wurde damit das Spannungsfeld zwi­schen Azure 1.0 als "direk­ter" Cloud Computing Strategie, Windows 7 ("Hoch lebe der Desktop!") und Silverlight 4.0 ("Three screens and a cloud") irgendwo dazwi­schen. Die Keynote selbst erschöpfte sich dann aller­dings haupt­säch­lich in einer Auflistung/Demonstration neuer (durch­aus nicht schlech­ter) Features haupt­säch­lich von Visual Studio 2010 und TFS 2010 und blieb für mich eher blass.

Nun folgte für alle wei­te­ren Sessions (bei jeweils 4 par­al­le­len Tracks) die Qual der Wahl, ich ent­schied mich zunächst für Mit Enterprise Architect durch den Projektalltag mit Horst Kargl: Außer den grund­le­gen­den Konzepten konnte man hier auch den einen oder ande­ren Denkanstoß mit­neh­men, z.B.

  • alle Metadaten eines Uses Cases im EA erfas­sen und die UC-Beschreibung auto­ma­tisch dar­aus gene­rie­ren (dies ist durch­aus nicht selbst­ver­ständ­lich, wenn man das Anforderungsmanagement nicht im EA, son­dern 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 unter­schied­li­che Herangehensweisen für ver­teil­tes Arbeiten
  • Steuerung der Dokumentationserstellung durch 
    • Modellierung der Doku-Generierung
    • Verwendung des erzeug­ten XMI z.B. zusam­men mit XSD
    • Verwendung der EA-API
  • Zur Codegenerierung eig­nen sich außer Klassendiagrammen noch Aktivitätsdiagramme, Sequenzdiagramme und Zustandsautomaten
  • Tipp: auto­ma­ti­sche Modellgenerierung aus dem Code mit­tels Build-Skript (zusam­men mit CI hat man dann immer aktu­elle Modelle)
  • hilf­rei­che EA Features zum Thema "Tracen und Suchen": 
    • Relationship-Matrix
    • Hierarchy View
    • Search query (mit­tels Query Builder, SQL Editor oder 3rd Party Add-Inns)

Als nächs­tes ziehe ich mir Dynamisch kon­su­mie­ren in C# 4.0 mit Oliver Sturm rein. Das erweist sich als gute Wahl, da sowohl span­nend als auch aus­sa­ge­kräf­tig. Hier kurz die für mich inter­es­san­tes­ten Punkte:

  • "dyna­mic" wird zwar ver­wen­det wie ein Typ, ist aber kei­ner, daher 
    • gibt es keine Basisklasse dafür
    • kann man nicht davon ableiten
    • kann man keine Extension Methods davon erzeu­gen (aber wer wollte das auch?)
  • es gibt keine IntelliSense-Unterstützung (es gibt durch­aus dyna­mi­sche Sprachen, bei denen das geht…)
  • ExpandoObject(): sieht erst­mal cool aus – aber gibt es eine sinn­volle Verwendung dafür?

Dann gibt es zwei Demos, eine zu Excel-Automatisierung (die außer von "dyna­mic" auch beträcht­lich von den unter C# 4.0 mög­li­chen optio­na­len Parametern pro­fi­tiert!) und die andere zu Screen-Scraping mit­tels Python und BeautifulSoup – natür­lich in C# inte­griert. Ziemlich beein­dru­ckend. Als Quintessenz nehme ich mir mit: "C# 4.0 ist nicht wirk­lich dyna­misch, aber man kann damit gut mit dyna­mi­schen Sprachen interagieren."

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

  • "No more no repro!" lau­tet der neue Tenor für Testing und Bugreproduktion
  • Test Impact: von einer Codeänderung/einem Changeset betrof­fene Testfälle ermit­teln (sozu­sa­gen das "Gegenstück" zu Code Coverage)
  • "Debuggen mit meh­re­ren Entwicklern": nicht (wie man ver­mu­ten könnte) gleich­zei­tig, son­dern nach­ein­an­der mit­tels Export/Import
  • ver­bes­ser­ter Profiler: sehr leis­tungs­fä­hig, aber nicht gerade intui­tiv bedienbar
  • IntelliTrace: sowohl für Entwickler (Debugging) als auch für Tester ("Anreichern" von Bugs) interessant
  • Fast Forward für manu­el­les Testen: auto­ma­ti­sches "Vorspulen", um Standardfunktionen wie z.B. Login zu auto­ma­ti­sie­ren und nur den "eigent­li­chen Testfall" manu­ell auszuführen
  • UML Integration
    • 5 Diagrammtypen wer­den unter­stützt: Aktivität, Klasse, Komponente, Sequenz und Use Case
    • Sequenzdiagramme kön­nen auto­ma­tisch aus dem Code gene­riert werden
    • Diagramme kön­nen (wie andere Artefakte auch) mit TFS Work Items ver­knü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 erst­mal "test­weise" aus­ge­führt. Nur wenn der Build (incl.  Unit Tests etc. je nach Konfiguration) erfolg­reich war, wird er end­gül­tig aus­ge­führt – ande­ren­falls zurückgerollt.

Spannend wird es wie­der bei Using Mocks for State and Interaction based Testing mit Hadi Hariri. Zuerst gibt es einen exkurs zum Thema "Design for testa­bi­lity" (Unit Tests tes­ten genau eine Funktionalität und haben genau eine Ursache, fehl­zu­schla­gen. Unit Tests, die DB-Zugriffe beinhal­ten, sind keine Unit Tests, son­dern Integrationstests.) Des Problemes Lösung heißt Dependecy Injection. Die kommt mit "hand­ge­mach­ten" Mocks genau so zum Einsatz wie mit Mocking Frameworks, vor­ge­stellt wer­den RhinoMocks und moq. Der größte Unterschied ist, das RhinoMocks zwi­schen Mocks und Stubs unter­schei­det, woge­gen moq nur Mocks kennt. An die­ser Stelle wird auch noch der Unterschied zwi­schen Stub und Mock erklärt: Stubs ver­wen­det man für das Testen von Verhalten (also z.B. einer Funktion), Mocks dage­gen für das Testen von Interaktionen (was viel sel­te­ner vor­kommt). Quintessenz des ebenso lehr­rei­chen wie unter­halt­sa­men Vortrages: "Unit Testing ist unpro­duk­tiv, wenn man es nicht rich­tig macht".

Mit Datenvisualisierung aus Usability-Sicht mit Tobias Komischke gibt es vor dem Abendbrot noch was "Leichtverdauliches" – des­halb nicht weni­ger inter­es­san­tes. Welche Diagrammarten eig­nen sich für wel­che Visualisierungen? Welche Funktionen haben Farben und Formen? – und wei­tere Fragen die­ser Art wer­den gestellt und – soweit mög­lich – beant­wor­tet. Hier wie­der ein paar Stichpunkte:

  • Legenden sind gene­rell pro­ble­ma­tisch, da der Betrachter immer zwi­schen Grafik und Legende "hin- und her­sprin­gen" muss.
  • Balkendiagramme sind amleich­tes­ten zu verstehen.
  • Tortendiagramme wer­den pro­ble­ma­tisch bei mehr als 5 Segmenten.
  • 3D-Diagramme ber­gen gene­rell ein ziem­lich 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 zusam­men ist ein No-Go.
  • "Show as much as necessary and as little as possible!"
  • "Eine Grafik, die nicht selbst­er­klä­rend ist, ist eine schlechte Grafik."

Zum Schluss noch ein Tipp: unter http://vizlab.nytimes.com/ wer­den ver­schie­dene Datenreihen mit  unter­schied­li­chen Diagrammtypen und Optionen dar­ge­stellt – 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 arbei­ten in agi­len Projekten – ein psy­cho­lo­gi­scher Diskurs mit Michael Tute und Wolfgang Boelmann. Das lässt sich auch inter­es­sant an – wir erfah­ren etwas über Single-Loop-Learning und Double-Loop-Learning und wer­den dann in die "Reflecting Team"-Technik ein­ge­führt. Dies wird dann gleich an einem prak­ti­schen Beispiel aus­pro­biert – unver­än­dert inter­es­sant, aller­dings hat sich ob der zahl­reich anwe­sen­den Raucher die Luftdicke gefühlt min­des­tens ver­zehn­facht – wes­halb ich den Rückzug und die Flucht ins Freie antrete.

Auf dem Weg ins Hotel kann ich den Tag noch ein­mal Revue pas­sie­ren las­sen. Fazit: ein aus­ge­füll­ter Tag – mit teil­weise schon Bekanntem, aber ebenso mit Neuem (oder auch: so noch nicht Betrachtetem), dies alles in brei­ter Themenvielfalt.

Related Posts

Pin It on Pinterest