Wie ich schon angekündigt hatte, war ich die letzten zwei Tage zur Weiterbildung auf der VSone. Leider war ich mit der Konferenz nicht ganz so zufrieden. Ich glaube, das war die letzte Veranstaltung diese Art, die ich besucht habe. Das ist allerdings nicht die Schuld der VSone. Das Problem ist, das viele Vorträge mit 1 Stunde einfach viel zu kurz waren um ein Thema wirklich ausführlich zu behandeln. Die Infos, die ich bei den Sessions erhalten habe, hätte ich auch durch ein wenig Recherche aus dem Internet erhalten können. Ich werde in Zukunft wohl eher versuchen, Workshops mit genau einem Thema, dies aber konzentriert und ausführlich behandelt.

Wie gesagt, das war nicht Schuld der VSone, sondern eher meine, weil ich die falsche Wahl getroffen hatte. Im vorigen Jahr hatte ich irgendwo den Eindruck, mehr Neuigkeiten von der Konfernz mitgenommen zu haben. Die Workshops wurden auf der VSone übrigens auch angeboten. Was solch eine Konferenz allerdings trotzdem sinnvoll und wertvoll macht, ist das Treffen der Community. War doch interessant, sich mit den Kollegen, die zusammen mit mir auf der Konferenz waren, mal außerhalb der Arbeit zu unterhalten. Aber auch die Unterhaltungen mit den Fachleuten außerhalb der Sessions war sehr interessant.

Nun möchte ich noch kurz ein paar Sessions erwähnen, die mir am meisten gefallen hatten.

• Programmieren mit PLINQ und der Task Library (mit Bernd Marquardt)

Ist eine neue Codebibliothek, die momentan als CTP verfügbar ist und später Bestandteil von .NET 4.0 sein wird. Sie hilft dem Entwickler bei der einfacheren Parallelisierung von Aufgaben, die unabhängig voneinander ausgeführt werden können. Sie entschärft z.B. die Komplexität des Aufrufs asynchronen Methoden und das Verarbeiten des Ergebnisses dieser Methoden.

• .NET 4.0 und Visual Studio 10.0 (mit Neno Loje)

Obwohl der Vortrag von zahlreichen Abstürzen von VS 2010 unterbrochen wurde, waren die gezeigten neuen Features doch sehr interessant und vielversprechend. Einige Features kann man bereits jetzt durch den Zukauf von externen Tools (Resharper, NCover) in VS2008 nutzen.

• Windows 7 für Entwickler (mit Neno Loje)

Ich hatte zwar Windows 7 schon selbst kurz in einer VM getestet, aber einige Features die Neno Loje gezeigt hatte, waren mir gar nicht aufgefallen. Interessant fand ich auch die neue im Betriebssystem verfügbare Sensor API. Damit lassen sich sicher einige ganz nette und auch sinnvolle Sachen programmieren. Was mir allerdings auch aufgefallen ist, war das Windows 7 im Gegensatz zu VS2010 während des ganzen Vortrages kein einziges mal abgestürzt oder eine sonstige Schwäche gezeigt hatte. Das erhöht doch deutlich das Vertrauen, diese Beta mal selbst intensiv zu testen. Allerdings war VS2010 im Gegensatz zu Windows 7 noch eine CTP.

• Software Design Principles (mit Stefan Lieser)

Die Software Design Principles (Single Responsibility Principle, Open Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle) waren jetzt zwar nicht neu für mich, gaben mir aber trotzdem einen Anstoss, mal wieder über seine eigene Arbeit nachzudenken, in wie weit man sich selbst an diese Prinzipien bei der täglichen Arbeit hält. Oft werden im täglichen Projektstress Entscheidungen getroffen, die man eigentlich wider besseren Wissens, so nicht treffen sollte.

• MulticoreProgrammierung mit der Microsoft CCR (mit Ralf Westphal)

Die Microsoft CCR (Concurrency and Coordination Runtime) ist Bestandteil des Microsoft Robotics Studio und auch als einzelne Entwicklungskomponente kostenpflichtig verfügbar.  Sie bietet einen vollkommen neuen Ansatz, die Abarbeitung von Codeabschnitten auf mehrer Threads und auch mehrere Prozessoren zu verteilen. Es ist dabei allerdings eines grundsätzliches Umdenken in der Architektur notwendig. Weitere Informationen kann man hier bekommen.

• Unittestautomatisierung mit PEX 

Ein Projekt von Microsoft Research, das dem Entwickler dabei helfen soll, eine möglichst hohe Codeabdeckung mit seinen Unittests zu erreichen. PEX analysiert dazu den bestenden Code in öffentlichen Methoden und versucht für möglichst viele Aufrufvarianten einer Methode Unittests zu generieren. PEX ist nicht geeignet für Testdriven Development, bei dem der Testcode vor der eigentlichen Implementierung geschrieben wird. Kann allerdings auch hier unterstützen, um für die restlichen nicht durch einen Test abgedeckten Codeteile eine Unittest zu erzeugen.