Tech'Ed 2008: Day 1

Nachdem wir gestern gut in Barcelona angekommen sind und uns zur Konferenz angemeldet haben, haben wir uns die zu besuchenden Events einmal genauer angeschaut. Bei der Anmeldung erhält man ein kleines Buch, welches alle Präsentationen beinhaltet; die Fülle ist beeindruckend und es ist nicht trivial, die persönlichen Interessen möglichst gut abzudecken. 14 parallele Sessions pro Timeslot machen die Auswahl nicht einfach; dennoch sind die einzelnen Vorträge aufeinander aufgebaut, so dass man sich zu einem einzelnen Thema die ganze Woche inkrementell informieren kann.

Die heutige Keynote Speech wird von Jason Zahnder, General Manager des Visual Studio Teams, gehalten.

Visual Studio .Net 2010

Jason Zahnder spricht in seiner Keynote Entwickler an; er zeigt verschiedene Neuerungen der Pre-Alpha Version von Visual Studio .Net 2010 und gibt einen Ausblick auf die neuen Möglichkeiten, welche die Arbeit der Entwikler einfacher machen soll. Beeindruckend sind sicherlich Features wie beispielsweise die inline Generierung von Sequenzdiagrammen, welche vor dem Code live die Aufrufe graphisch darstellen und so dem Entwickler eine grosse Unterstützung sind für das Nachvollziehen des vorliegenden Quellcodes.

Weiterhin sehr beeindruckend war die Integration eines Testvorganges. Ein Tester findet einen Fehler im Programm aufgrund eines vorgegebenen Testszenarios, markiert diesen als Fehler. Der Entwickler kann dann tags darauf nicht nur den Fehler in seiner Taskliste sehen, sondern auch beispielsweise ein Video abspielen, wie der Tester diesen Fehler produziert hat. Oder auch den Zustand der Maschine nachvollziehen, auf welcher der Test durchgeführt wurde. Nicht zuletzt kann ein Entwickler, falls der den Fehler nicht nachvollziehen kann, einfach den Zustand der virtuellen Maschine wiederherstellen, in welchem sich der Tester befunden hat.

Architekturen: The good, the bad and the ugly

In dieser Präsentation von Miha Kralj (Microsoft Senior Architect) werden sogenante Anti-Patterns (etwa: Anti-Empfehlungen) vorgestellt. Dabei werden Architekturen und Vorgehensweisen beschrieben, welche man möglichst umgehen sollte. Er unterscheidet drei verschiedene Projektstadien und ergänzt diese durch diese Anti-Patterns:

• Requirements Phase:
  • Napkin Doodle contra Documentation overkill: Ersters beschreibt die Tendenz, Dokumentationen möglichst auf eine Papierserviette zu reduzieren. Das andere Extrem ist der Documentation overkill, wo alles und jedes Detail im voraus schriftlich festgehalten wird, was einen enormen Aufwand darstellt und meistens nicht praktikabel ist.
  • McKinsey Sydrome contra Obedient Butler: Hiermit wird das Verhalten gegenüber dem Kunden beschrieben; man sollte weder auf dem hohen Ross sitzen jeden kleinsten, noch so widersinnigen Wunsch erfüllen und berücksichtigen, sondern dem Kunden in einem konstruktiven Dialog begegnen.
  • Measurement Abuse contra Softie-Softie: Beim ersten Anti-Pattern geht es darum, dass möglichst alles gemessen werden soll und muss. Letzteres nicht empfehlenswertes Vorgehen beschreibt die Grundhaltung dass man solange in einem Projekt iteriert, bis die vollstmögliche Zufriedenheit erreicht ist, was natürlich dazu führt, dass die Kosten ins Unermessliche steigen.
• Analysis Phase:
  • "Start small, grow fast" contra "Let's go global now": Ersteres Ansatz geht davon aus, dass man kritische Sachen auch erst später einbauen kann und sie noch nicht berücksichtigen muss (was so nicht möglich ist, so lässt sich Security z.B. nicht einfach im Nachhinein konzeptionell einbauen). Das andere Extrem geht davon aus, dass man auf alles gerüstet sein will, was dazu führt, dass man nie fertig wird.
  • Best-of-Breed contra Vendor Lock-In: Bei der Konzipierung der Lösungskomponenten muss man eine Mittellösung suchen zwischen dem Herauspicken der jeweiligen Sternprodukte (z.B. bestmögliches DBMS, bestmöglicher Application Server, bestmöglicher Application Server, etc.) und dem anderen Extrem, sich ausschliesslich auf einen Lieferanten fokussieren. Ersteres führt zu exponentiell steigenden Integrationskosten, letzteres zu einer Abhängigkeit von einem einzelnen Lieferanten, denn keiner kann auf jedem Gebiet top sein.
  • Bei der Patternwahl beschreibt Kralj, dass es nicht darum geht, eine sogenannt "beste" Möglichkeit zu suchen. Er formuliert dies schön mit der besten, der richtigen und der umsetzbaren Wahl eines Lösungsansatzes.
  • YAGNI contra Analysis Paralysis: Dabei geht es darum, die Analysephase nicht durch Unsicherheiten unendlich zu blockieren.
• Design Phase
  • "Reinventing the wheel" contra "Golden Hammer": Der erste Anti-Ansatz ist im Prinzip die Tendenz von Entwicklern, alles neu erfinden zu wollen (auch bekannt als NIH Syndrom). Das genau so schlechte Gegenteil beschreibt der Einsatz eines einzelnen Produktes um alles damit machen zu wollen, obwohl es nicht dazu geeignet ist und man besser bestimmte Elemente selber entwickeln würde.
  • YAFL contra "No enough layers": Unter YAFL (Yet another fine layer) wird allgemein die Tendenz verstanden, Architekturen mit unendlich vielen Schichten zu bauen, die u.U. keinen Sinn mehr machen und nur die Komplexität unnötig erhöhen. Das Gegenteil davon, ist nicht genug Schichten zu haben (weniger als drei).
  • Sales-driven development contra Technological purity: Das erste Anti-Pattern beschreibt die Tatsache, dass Komponenten der Lösung über das Marketing/Sales definiert werden, aus technologisch nicht fundierten Gründen. Das andere Extrem ist die Tatsache, alles technologisch auf sauberstem Stand halten zu wollen mit der Tendenz, auch alles selber machen, obwohl es pragmatische Lösungen gibt.

Im Fazit beschreibt Kralj verschiedene Ansätze, wie man Architekturen aufbauen kann. Er beschreibt den Middle-Out Approach, also Architekturen so zu bauen, dass sie einerseits sowohl ein gutes technologisches Fundament haben (ohne extrem zu sein) und andererseits gut gegen zukünftige Erweiterungen oder Markteinflüsse abgedeckt sind.

Ausserdem sagt Kralj, dass die Verbindung zwischen Lösungskomponenten einen höheren Stellenwert haben (werden), als die Komponenten selbst. Es geht vorallem darum, die Syntax und Semantik der Kommunikation zwischen den Komponenten zu definieren (IFaP).

What's new in SQL Server 2008 for Developers?

1. Intellisense wurde endlich eingeführt!
2. Debugging von T-SQL ist wieder möglich

Wichtige Erweiterungen in T-SQL sind:

• Zusätzlich zu den CREATE, UPDATE und DELETE Statements gibt es nun einen MERGE Befehl, welcher mit dem UPSERT Befehl von anderen DBMS vergleichbar ist. Dieser Befehl enscheidet selbst, ob auf der Relation ein Datensatz eingefügt oder ein bestehender aktualisiert werden muss.
• Wichtig für Stored Procedure ist die Möglichkeit, dass man Relationen neu als Parameter übergeben kann. Diese Möglichkeit wird auf das .Net Framework ausgeweitet, so dass man z.B. in C# ganze Tabellen als Parameter übergeben kann. Zur Zeit noch nicht möglich ist dies auf SQL CLR Ebene.
• Tracking von Änderungen ist nun über SQL Server 2008 Engine implementiert. Es gibt die Change Data Tracking und Change Data Capture Möglichkeiten, welche es erlauben, Änderungen der Daten jederzeit nachvollziehen zu können, wobei letztere Möglichkeit die einzelnen geänderten Informationen über das Transaction Log nachvollziehen kann.
• Es gibt eine Erweiterung des DateTime Datentyps, DateTime2: Der Datumsbereich ist neu vom 1.1.0001 bis zum 31.12.9999 und die Genauigkeit ist auf 100 Nanosekunden festgelegt. Interessant in diesem Zusammenhang ist die CONVERT Funktion neu auch die indizierten Felder zugreift. In Zukunft werden weitere Funktionen Indexe unterstützen, was natürlich einen Performancegewinn darstellt
• LOBs werden neu als Filestreams auf dem Dateisystem gespeichert. Bei Backup und Restore Aktionen werden diese Daten weiterhin transparent gehandelt. Zugriff auf diese LOBs ist über T-SQL oder normales File I/O möglich.

When you have too much data, "good enough" is good enough

Pat Helland, Microsoft Partner Architect, erklärt in dieser eher essay-orientierten Vorstellung, weshalb die klassischen Datenbank-Paradigmen in der heutigen Zeit nicht mehr unbedingt greifen. Es geht dabei um die Verwässerung von Prinzipien wie ACID und die Tatsache, dass Datenqualität in der Zukunft nicht mehr klar ist, sondern unscharf sein kann.

Die grosse Diskrimante hierbei ist die Unterscheidung zwischen "inside" Daten (wie anhin) und "outside" (oder unlocked) Daten. Letzteres bezieht sich z.B. auf E-Mail Nachrichten, die Einbindung von Hunderten von Anbietern auf einer Integrationsplattform wie Amazon (und der Ambiguität derer Produktdaten) und vieles mehr, was sich mit klassischen relationalen Paradigmen nicht mehr einfach abbilden lässt.

Folgende Themenbereiche wurden bei der Präsentation tangiert und beschreiben die Erosion der bestehenden Prinzipien:

• Streaming: Hängende SQL Abfragen (nach dem Motto: Sag mir, wenn sich das Resultset ändert, d.h. eine Abfrage wird nicht mehr zu einem genauen Zeitpunkt ausgeführt, sondern wird zeitunabhängig).
• Messages and Schema: In Zukunft wird es nicht mehr klare im voraus definierte Schemas geben, sondern viel mehr Property Bags. Ein Ansatz dazu ist bereits mit Amazons SimpleDB ersichtlich. Dies ist bedeutend weniger genau, aber typischerweise sind die darauf basierenden Systeme bedeutend adaptiver.
• ETL: ETL ist ein verlustbehafteter Prozess
• Identity and Replication
• Patterns by Inference
• Versionsmanagement in Schemas
• und vieles mehr