Ein Tag im Leben eines Entwicklers

Fühlen Sie sich als Entwickler auch manchmal gestresst und abgeschlafft, weil Sie von Ihrem Chef wieder ein Bündel an Aufgaben bekommen haben und alle auf einmal bearbeiten sollen? Oder weil Sie kurz vor dem Releasetermin neben der Fertigstellung Ihres Features auch noch einen "dringenden" Bug beseitigen müssen?

So können durch die tiefe Integration des TFS in Visual Studio Source-Code "parken" oder für ein Review freigeben, sich Abhängigkeiten zwischen Funktionen und Feldern "kartographieren" lassen und sogar mittels Debugging durch diese "Karte" wandern. Und natürlich noch viel mehr...

In diesem Vortrag lernen Sie die neuesten Features aus Visual Studio 2012 und Team Foundation Server 2012 kennen, mit deren Hilfe Sie Ihren Arbeitsablauf vereinfachen und optimieren können.

Planung ist das halbe Leben

Software-Entwicklung ist mehr als nur Code schreiben und diesen verwalten. Wenn man sich den Lebenszyklus einer Anwendung ansieht, dann wird man feststellen, dass an dessen erster Stelle die Idee (!) steckt und deren Beschreibung, aus der dann die Anforderungen an das Entwicklungsteam entstehen. Die Visualisierung dieser Anforderungen, Aufgaben und der Verfügbarkeit der Team-Mitglieder ist ein entscheidendes Erfolgskriterium, um Software erfolgreicher realisieren zu können. Jedes Team sollte jederzeit wissen, wie viel Arbeit noch zu leisten ist, um ein gemeinsames Ziel zu erreichen.

In diesem Vortrag lernen Sie den Team Foundation Server 2012 und dessen Planungstools kennen. Erfahren Sie, wie Sie Anforderungen, Bugs und Aufgaben im Team Foundation Server anlegen und pflegen und wie Sie einen Überblick über Ihre Teamziele behalten.

Über den Sprecher
Karsten Kempe ist ALM-Berater der conplement AG in Nürnberg. Er verfügt über langjährige Erfahrung in der Softwareentwicklung auf Basis der Microsoft Technologien und hat sich auf Themen rund um Microsofts Team Foundation Server spezialisiert. Er unterstützt Firmen bei der Einführung, Anpassung und Verwendung des Team Foundation Servers, tritt als Fachautor und als Sprecher auf Konferenzen in Erscheinung.

Neben seiner Tätigkeit im ALM Umfeld beschäftigt er sich mit dem Entwurf ergonomischer Oberflächen für Windows 8 und Windows Phone und deren Entwicklung.

Er bloggt auf der Seite: http://www.almsports.net

Was ist neu in .NET 4.5 und C# 5?

Version 4.5 ist das zweite große Update für das .NET Framework in nicht einmal 1,5 Jahren. Notwendig wurde das Update aufgrund der vielen neuen Features für Windows 8. Aber auch, wenn die eigene Anwendung nicht über den Store vertrieben werde soll, gibt es Features, die das Arbeiten mit der aktuellen Version des Frameworks effizienter, einfacher und schneller machen. Ein wesentlicher Teil der Session werden Parallelisierung und asynchrones Ausführen von Code sein. In WCF werden wir uns die wichtigsten neuen Features wie UDP-Binding, WebSockets und IntelliSense in der Konfiguration anschauen. In WPF sind einige der neuen Features, die in dieser Session beleuchtet werden, das Sortieren von Daten zur Laufzeit, das DataBinding an statische Eigenschaften sowie das Ribbon-Control.

Über den Sprecher
Jan Schweda ist Software Engineer bei der conplement AG in Nürnberg. Sein Fokus liegt vor allem auf verteilten Systemen und serviceorientierter Architektur. Jan entwickelt seit mehreren Jahren Consumer und Enterprise-Anwendungen im .NET Umfeld und hat hierbei Erfahrungen in den unterschiedlichen Bereichen des .NET Technologie Stacks gesammelt. Sein Wissen gibt er regelmäßig und gerne als (Microsoft Certified) Trainer, Fachautor und Sprecher weiter.

(siehe Startseite)

Software Engineering 101 - Restructuring Modularity

-----------------
Übersetzte Ankündigung auf Deutsch:

Die Prinzipien der Modularisierung werden in Ingenieursprojekten angewandt, seitdem Gorak das Rad, und Thag den Schubkarren für das welterste Schubkarrenrad gebaut haben. Thags Schubkarren war es egal, dass das Rad zuerst aus den Stein geschlagen war, und später durch ein leichteres hölzernes Rad ersetzt wurde. Und Goraks Rad-Entwurf wurde wieder verwendet, um den weltersten Streitwagen zu bauen. Das ist die Art und Weise wie Menschen Komplexität benutzen - wir teilen und herrschen.

Dieselben Prinzipien der Modularisierung werden in Software Engineering 101 gelehrt - Kapselung, Schnittstellen, klare Verantwortlichkeiten, hohe interne Kohäsion, niedrige externe Bindung, usw. Wir wenden diese routinemäßig beim Entwickeln an, und refaktorisieren den Code so, um ihn in Klassen zu kapseln. Wenn jedoch die Zahl der Klassen einen bestimmten Grad überschreiten, werden höher gelagerte Abstraktionen benötigt, um mit der Komplexität der wachsenden Codebasis zurecht zu kommen. Dieses Limit wird meistens überschritten, und das Team ertränkt bald in einem Meer von Klassen. An diesem Punkt wird es Zeit, die Codebasis entweder in eine Hierarchie von Modulen, die über der Klassen-Ebene liegt, zu restrukturieren, oder den Frust des Teams weiter steigen, und die Produktivität weiter abstürzen zu lassen.

Dieser Vortrag stellt ein Messungs-Framework vor, das die Qualität einer modularen Struktur beurteilt, Regionen von schlechter Modularisierung identifiziert, und die Auswirkung von Refaktorisierungsaktionen aufzeigt. Basierend auf diesem Framework, werden Strategien dargestellt, um die Modularisierung mit minimaler Auswirkung in eine existierende Codebasis einzubringen. Dieses Material basiert auf Erfahrungen, die dabei gesammelt wurden, während Teams den Restrukturierungsprozess durchlaufen haben. Diese Konzepte werden anhand von Beispielen veranschaulicht.

-----------------
Ankündigung auf Englisch:

The principles of modularity have been applied to engineering projects since Gorak built the wheel, and Thag the barrow of the world's first wheelbarrow. Thag's barrow didn't care that the wheel was first hewn from rock, and later upgraded to a lighter, wooden one, and Gorak's wheel design was reused for the world's first chariot. This is how humans make sense of complexity - we divide and conquer.

Analogous principles of modularity are taught in Software Engineering 101 - information hiding, interfaces, clear responsibility, high internal cohesion, low external coupling, etc., and we apply these routinely as we develop, and continuously refactor the code encapsulated within classes. However when the number of classes reaches some threshold, higher level abstractions are needed in order to manage the complexity of the growing codebase. This limit is usually overshot and the team is soon drowning in an ocean of classes. At this point it is time to restructure the code-base into a hierarchy of modules above the class level, or watch the team's frustration continue to rise, and productivity plummet.

This talk proposes a measurement framework for assessing the quality of a modular structure, identifying regions of poor modularity, and for assessing the impact of restructuring or refactoring actions. Based on this framework, the talk introduces strategies for retro-fitting modularity to an existing codebase, with minimum impact on the code logic itself. This material is based on experience gained while helping many development teams through the restructuring process. The concepts will be illustrated by examples.

Interaktive Webanwendungen mit SignalR

Eines der angesagtesten Frameworks in der Web 2.0-Entwicklung ist SignalR - eine neue, starke und ausgeklügelte Hilfsbibliothek für Client und Server im Web. Das ASP.NET MVC-Team hat sich damit ins Zeug gelegt, um außer des klassischen Request-Response-Patterns auch rückseitige Server-Verbindungen zum Webserver aufbauen zu können. Damit sind hochdynamische ASP.NET Webseiten möglich, in denen sich Teile der Seite nach einem vom Server ausgelösten Event aktualisieren können.

Microsoft hat es wieder einmal geschafft, mit diesem Framework den Vorsprung der .NET-Plattform in Sachen Produktivität und im Pragmatismus für Entwickler weiter auszubauen. Damit bleibt .NET das mächtigste Mittel der Wahl in der heutzutage sehr turbulenten Webentwicklung.

Ihr seid verwirrt? Dann kommt vorbei und schaut auch an, wieviel Potential in diesem Ansatz steckt! Es sind keine Vorkenntnisse nötig.

SOAP 3.0 Webservices in Windows Apps verwenden

Der Visual Studio Service Reference Wizard kann bei Windows 8 Apps keinen(!) funktionierenden Wrapper für die weit verbreiteten SOAP 3.0 Webservices erzeugen. Angeblich ist SOAP "alte Technologie". Die Verantwortlichen bei Microsoft USA glauben, dass man so etwas heute nicht mehr braucht. Mit etwas Hilfe von der deutschen Microsoft Windows 8 App Hotline gelang es uns, einen generischen SOAP 3.0 Wrapper zu bauen, der auch in Windows 8 Apps funktioniert. Wir erläutern die zugrunde liegenden Techniken und zeigen an einem Live Beispiel, was tatsächlich über die Leitung geschickt wird. Dazu haben wir eine kleine Windows 8 App gebaut. Auch dabei gab es ein paar Fallstricke, die wir Ihnen nicht vorenthalten wollen.

Digitale Signatur für Programme und Setups

Kennen Sie das? Der Virenscanner Ihres Kunden löscht Ihr Programm im laufenden Betrieb? Bei Norton/Symantec heißt das z.B. "Sonar hat ein Problem für Sie gelöst". Bei anderen Virenscannern erscheint gar keine Meldung.
Oder das: Ihr Kunde erzählt Ihnen, dass in Ihrer Software plötzlich Fehlermeldungen an Stellen auftreten, die seit Jahren fehlerfrei gelaufen sind. Und das, ohne dass Sie oder der Kunde irgendetwas neues installiert hätten. Ich bin sicher, die meisten von Ihnen können Ihre eigenen Geschichten zum Thema Virenscanner erzählen. Ebenso zu einigen Dialogen in Windows, die uns inzwischen wie potentielle Verbrecher behandeln.
Das alles muss aber nicht sein. Nicht nur Windows selbst, auch die Virenscanner behandeln Ihre Programme wesentlich wohlwollender, wenn sie mit einer digitalen Signatur geschützt sind. Die meisten der oben genannten Probleme verschwinden damit wie von Zauberhand. Wie immer in unserem Job gibt es auch hier die richtige Lösung und ein paar weniger gute Lösungen. Kommen Sie zu meinem Vortrag und ersparen Sie sich jede Menge frustrierende und unnötige Arbeit.

Why the fuck is this app so ugly - was wir Entwickler immer falsch machen

Es scheint eines der ungeschriebenen Gesetze zu sein, dass Entwickler keine schönen und anwenderfreundlichen Anwendungen machen können. Oder wollen? Tatsächlich gibt es einige Fallen, in die man immer wieder stolpert und die Teil des eigenen Selbstverständnisses sind. Wozu braucht man Automatik, wenn man Gang fahren kann, wozu einen Assistenten, wenn es auch manuell geht und warum muss eine Anwendung überhaupt schön sein? Es reicht doch, wenn sie funktioniert. Dass es auch anders geht, und dass das gar nicht so schwer ist, will Bernhard Pichler, Sprecher des Usability-Netzwerkes ef.eu und Geschäftsführer der informare Consulting GmbH, in diesem Vortrag anhand vieler praktischer Beispiele aufzeigen.

Microsoft selbst ist diesen Weg in den letzten Jahren gegangen und lehnt inzwischen Anwendungen für den Store ab, wenn die Schriftgröße nicht passt. Die Designrichtlinien für Windows 8 kommen am Ende zur Sprache.

Über den Sprecher
Dipl. theol. Bernhard Pichler ist Geschäftsführer der informare Consulting GmbH und Gründer des Europäischen Forums für Erweiterte Usability, kurz EF.EU. Sie erreichen ihn über www.informare.de.

Download
Den Vortrag gibt es hier zum Download: 'WhyTheFuckIsThisAppSoUgly.pptx'

ACHTUNG: Unter allen Teilnehmern verlosen wir eine Telerik Ultimate Collection Lizenz im Wert von über 1.000 Euro!