BASTA!Spring 2010 – Mein Fazit

Auch dieses Jahr war ich wieder Teilnehmer der Frühjahrausgabe der Konferenz für .NET Entwickler BASTA!. Hinter mir liegen 4 Tage voller teils sehr interessanter und unterhaltsamer Vorträge aus allen Bereichen der .NET-Welt. Hier mal ein paar Dinge die ich dazugelernt habe: Das Keyword "var" wurde nicht etwa nur erfunden damit man nicht mehr explizit den Typ einer Variablen angeben muss, sondern um Anonyme Typen darstellen zu können. Das war mir bisher irgendwie entgangen 😉 IPhone Anwendungen muss man nicht in Objective C schreiben, es geht auch in C#. Mit der Hilfe eines Apple Rechners, der Entwicklungsumgebung MonoDevelop (kostenlos) und einer MonoTouch Lizenz (400€) kann man eine C# Anwendung zu einer IPhone App kompilieren. Dazu gabs eine schöne Live-Demo, sah relativ einfach aus. Debugger Habt ihr im Visual Studio 2008 schon mal mit der rechten Maustaste auf einen Breakpoint geklickt? Ich leider nicht, daher sind mir einige sehr hilfreiche Funktionen bisher entgangen... Zum Beispiel kann man hier eine "Bedingung" festlegen die erfüllt sein muss, damit der Debugger die Anwendung anhält. Die "Trefferanzahl" ermöglicht es einem festzulegen, dass der Debugger beispielsweise erst beim 5. Erreichen des Breakpoints das Program anhält und nicht jedesmal! Mit "Bei Treffer" kann dem Breakpoint ein Makro hinterlegt werden, dass bei Erreichen ausgeführt wird. Das neue Visual Studio 2010 kommt allerdings mit einem Hammer-Feature daher, und das heisst "Rückwärts-Debugger". Man kann nun endlich im Programmablauf in der Zeit zurückspringen und sich jeden Zustand anschauen den man will. Leider wird dieses "IntelliTrace" nur in der teuersten Ultimate Version enthalten sein die ca. 2 Scheine kosten wird. TFS 2010 ist die neuste Version vom Team Foundation Server und dieser soll sich  im Gegensatz zu seinem Vorgänger sehr einfach (in ca. 20 Minuten) in Betrieb nehmen lassen und man braucht kein Server-Betriebsystem mehr dazu. Das hier integrierte Code-Versions-Verwaltungssystem ist der Nachfolger vom bisherigen "SourceSafe" und bietet auch sehr kleinen Teams sehr gute Kontrolle über gemeinsame Projekte. TFS enthält auch einen Issue bzw. Bug-Tracker und man kann WorkItems verwalten. Damit lässt sich quasi der komplette Lebenszyklus einer Anwendung abbilden. Sehr schönes Teil wie ich finde. Besitzer einer MSDN-Subscription bekommen das Teil mit einer 5 Benutzer Lizenz wohl schon recht günstig. Das MVVM Pattern (Model-Viev-ViewModel) ist ein Design Pattern, dass häufig bei WPF/Silverlight Projekten zum Einsatz kommt. Hierzu gibt es einen sehr schönen Beitrag auf Codeprojekt von Rainer Stropek wo gezeigt wird, wie das Entwurfsmuster angewendet wird und wie man damit eine wiederverwendbare Codebasis schaffen kann, die sowohl für WPF als auch für Silverlight Projekte gleichermaßen einsetzbar ist. An dieser Stelle möchte ich auch mal ein richtig dickes Lob an Rainer Stropek rausschicken. Er hat während der BASTA mehrere sehr gute und vorallem praxisnahe, Vorträge gehalten die mich wirklich weiter gebracht haben. Danke dafür, weiter so! IronPython ermöglicht die direkte Nutzung der sehr mächtigen Skriptsprache Python aus .NET Assemblies heraus. Hier gabs ein schönes Praxisbeispiel zu sehen in Verbindung mit dem HTML/XML Parser BeautifulSoup für Python, welcher einfaches ScreenScraping ermöglicht. Ist auf jeden Fall einen Blick wert! CodeContracts bieten eine sehr schöne Möglichkeit um Validierungslogik zu implementieren. Anstatt viele If-Anweisungen oder try/catch Blöcke in die Ablauflogik zu packen kann man beispielsweise mit dem Attribut  "Contract.Reqire(...)" über einer Methode oder einem Property eine entsprechende Gültigkeitsbedingung festlegen. Das sieht nicht nur sauberer aus, sondern ist auch deutlich besser testbar. Ist auf jedenfall empfehlenswert, wenn man sehr viele Gültigkeitsbedingungen abzuprüfen hat. RhinoMocks und MOQ sind zwei gute Mocking-Frameworks um Objekte bzw, Verhalten zu "simulieren". Es geht darum Code testbar zu machen in dem Abhägigkeiten "gemockt" werden. Das Ziel ist es, dass ein Testfall nur maximal EINEN Grund haben darf um zu scheitern und nicht mehrere. Sobald aber mein Testfall eine Abhägigkeit hat wie z.B. ein Zugriff auf eine Datenbankverbindung oder einen Webservice habe ich mehrere potentielle Fehlerfälle zu betrachten. Hier springen die Mockobjekte in die Bresche, mit denen man bestimmte Dienste, Rückgabewerte oder Abläufe simulieren kann, obwohl diese evtl. nicht erreichbar bzw. noch garnicht implementiert sind. Damit ist man in der Lage einzelne Dinge zu testen ohne auf die Abhängigkeiten eingehen zu müssen. Zum Thema "Geschwindigkeitsoptimierung" von Anwendungen gab es auch einen schönen Vortrag zu hören in dem auf Möglichkeiten eingegangen wurde, wie man seine Anwendung schneller machen kann. Das betrifft vorallem Anwendungen die viel rechnen müssen bzw, die sehr komplexe Algorithmen durchlaufen. Beispielweise ist die Verwendung von "struct" deutlich besser für die Performance einer Anwendung als bei der Nutzung einer Klasse und Methodenaufrufe in flachen Objekten sind deutlich schneller als bei Objekten die ein Interface implementieren bzw. die von einer Klasse erben. Um Performance von Anwendungen zu messen sollte man dotTrace von jetbrains verwenden. Das ist mit Sicherheit besser als jeglicher handgestrickter Kram. Sehr unterhaltsam war der Vortrag "Why software sucks" von David Platt. Der Mann ist Amerikaner und ein echter Entertainer! Er hat auf sehr amüsante Weise ausgesprochen, was die meisten Entwickler eigentlich nicht hören wollen: "Kein Schwein interessiert sich für deine Software". Leider hat er damit sehr recht, denn Anwender nutzen Software um ihre Arbeit zu erledigen und sonst für nichts. Es interessiert wirklich keinen Anwender wie Software gemacht ist und was alles für spannende Technologien drin verbaut wurden. Es geht dem Benutzer nur darum seine Arbeit zu erledigen bzw. einen Zustand der Zufriedenheit herzustellen. Deshalb sollten alle Entwickler immer darauf achten das Software einfach zu benutzen ist und möglichst kein Handbuch notwendig ist um sie zu verstehen. Es sollten nur Dinge implementiert werden die wirklich gebraucht werden. Maximale Flexibilität in einer Anwendung heisst oft leider auch zu viele unübersichtliche Features die oft eher zu Frustration des Benutzers führen als zur Zufriedenheit.
Don't let your software suck! Make it just work!
So, das soll reichen. Neben den vielen Informationen gabs natürlich auch wieder sehr gutes Essen! Daher möchte ich noch den Veranstalter loben, insbesondere die Küchencrew vom Maritim Hotel in Darmstadt. Das war mal wieder eine Schlemmerwoche vom Allerfeinsten, Super Leistung 😀 Na dann hoffentlich bis nächstes Jahr...