BASTA 2012 - Ein Web-Developer in der nativen Welt?

Dienstag, 28.02.2012: Tag 1 - BASTA-Konferenz  

Ankunft

Start um 07:13 Uhr mit der Straßenbahn in Mainz. Weiterfahrt vom Mainzer Hauptbahnhof mit der Bimmelbahn nach Darmstadt, Ankunft 08:21 Uhr. Zu Fuß geht's weiter bis zum Maritim-Hotel. Dort angekommen, irre ich erstmal umher, da der Haupteingang gesperrt ist und ein Schild auf die Nebeneingänge verweist. Dass ich die nicht gleich sehe, liegt daran, dass ich direkt davor stehe. Ich betrete das Hotel und bekomme von den netten Damen am Check-In meine hinterlegte Teilnehmerkarte, einen Tagungs-Rucksack sowie einen Sessionplan ausgehändigt.

Begrüßung und Keynote

Auf gehts hoch in den Raum "Hamburg", wo die Begrüßung bereits seit 08:30 Uhr stattfindet. Oben angekommen, ergattere ich einen der letzten freien Plätze in der vorletzten Reihe und höre erstmal zu. Hier fallen bereits einige Worte zu Windows 8 und warum wir hier sind: weil wir Programmieren geil finden! Kurz vor 9 Uhr beginnt eine actionlastige Keynote zu Windows 8 mit Jörg Neumann von Acando und Christian Weyer von Thinktecture. Und hier erfahren wir als Erstes, was in der Microsoft-Welt im Moment falsch läuft: alle Programmieren Apps, nur Microsoft-Entwickler nicht. Aber ohne App geht's nicht.

Beim ShowHands ist der Anteil der Teilnehmer mit einem C++-Hintergrund deutlich höher als der der Windows-Phone-Entwickler; ein überraschendes Ergebnis, zumindest für mich. Smartphones und Tablets dominieren zunehmend die Unterhaltungselektronik, nur an den Businessentwicklern geht das Thema vorbei. Notwendig sind neue User-Interfaces und eine entschlackte Business-Logik; der Nutzer möchte schließlich nicht von aufpoppenden Modal-Dialogen erdrückt werden und gleichzeitig soll sich die App auch in das restliche Betriebssystem perfekt integrieren. Eine Neuentwicklung ist also notwendig. Auch dafür bietet Microsoft eine Lösung: Windows RT. Dies steht für Windows Runtime und enthält ein COMeback-Interface. Damit ist gemeint, dass das alte COM-Interface eine Renaissance erlebt, weil native Schnittstellen reaktiviert wurden und überarbeitet worden sind. Zusätzlich unterstützt Windows 8 neben einem in C++ implementierten und damit sauschnellen XAML-Interpreter nun auch die Programmiersprache Javascript, ein Schritt, um auch Webentwickler wie mich ins Boot zu holen. Jedenfalls will Microsoft, dass die Entwickler vermehrt Apps entwickeln, um auch dem Businessmanager auf dem Golfplatz das checken der Statistiken seiner Business-Applikationen zu ermöglichen. Die Apps werden in Windows 8 unter einer zentralen "Datsch"-Oberfläche namens "Metro" zusammengeführt, die auch das zentrale User-Interface für Tablets bilden. Wir sehen auch, dass Visual Studio auf dem Tablet einwandfrei läuft, nur der Nutzen davon sei mal dahingestellt. Vielleicht unterstützt es ja einen Entwickler bei einer Code-Review von der Couch ;-) Nach einer Kaffeepause geht es dann mit der ersten Session weiter.

Session 1: Windows 8 - Metro-Apps mit XAML und C# entwickeln

Oje. Was habe ich mir da nur ausgesucht. Was zum Geier ist eine Metro-App und was ist XAML? Ich dachte mir ich fange mit einem "leichten" Thema an, um einen Einstieg zu finden. Nach 5 Minuten verstehe ich grob, was da vorne bei Thomas Claudius Huber abgeht. Microsoft besitzt ein eigenes XML-Format namens XAML, womit die Definition einer GUI maßgeblich erleichtert wird. Eigentlich ganz nett. Metro ist auch ganz nett. Alles ist irgendwie vorgegeben und die XAML-Zeilen werden da vorne immer mehr, was er da genau macht, kann ich nicht mehr wiedergeben, dafür ging es zu schnell. Aber um mal einen Überblick zu kriegen, dass man alle Hardware-Sensoren mit allen Sprachen ansprechen kann, sogar nativ mit Javascript über den integrierten Internet Explorer, das war schon beeindruckend. Toll ist, dass das Rechtemanagement vernünftig durchdacht zu sein scheint: Um einen Filepicker zu implementieren, reicht es aus die Standardsettings bei der Rechtevergabe zu belassen, weil die Interaktion vom Nutzer ausgelöst wird und nur darüber Bilder in die Anwendung geladen werden können. Für die Kamera jedoch muss man die Rechte explizit freischalten.

So sehen wir im Verlauf der Session mehrere Beispiele, wie sich Anwendungen mit C# entwickeln lassen und sogar, wie man eine eigene Schnittstelle definiert, die mit Javascript angesprochen werden kann. Man kann damit die Businesslogik ganz normal via C# entwickeln und als Schnittstelle bereitstellen, die über Javascript abgerufen werden kann und zusammen mit HTML5 und CSS3 die Frontenddarstellung meiner App bildet. Ich bin positiv überrascht über diese Möglichkeiten!

Session 2: Deep Dive Javascript

Ich bin Webentwickler, wie in der Einführung erwähnt, daher mein besonderer Fokus auf Webtechnologien. Das heißt nicht, dass ich euch nichts neues erzählen werde, aber ihr solltet nicht zuviele Fachbegriffe von mir erwarten ;-) In der zweiten Session hat Kai Jäger eine tiefere Einführung in Javascript gegeben. Ich beschäftige mich seit gut 4 Jahren mit Javascript, but this Deep Dive was really deep. Es wurden die Grundzüge der Sprache erklärt, wo die Analogien zu C# bzw. Java sind, dass die Sprache funktional ausgerichtet ist und keine klassenorientierte Objektorientierung besitzt, wie man Namespaces definiert, eigene Objekte anlegt und Vererbung realisiert. Ich gehe hier jetzt nicht in die Details, da dies den Rahmen des Berichtes sprengen würde, bei Interesse gibt es später einen eigenen Artikel zu dem Thema.

Session 3: Windows Phone 7 Apps mit Silverlight entwickeln

Hm. Schon wieder Thomas Claudius Huber? Schon wieder was mit Apps? Richtig. Und auch der Aufbau schien mir sehr zu ähneln. Konkret habe ich in Erinnerung, dass das .NET 4.5-Framework deutlich mehr Übereinstimmungen bei den Members und Properties mit WindowsRT hat, als zuvor. Folglich könnt ihr mit Silverlight auch viel entspannter entwickeln als zuvor, da ihr mehr Ähnlichkeiten bei den verfügbaren Klassen habt. Ansonsten sah mir das auch wieder sehr XAMLig aus und ähnelte Session 1 aus meiner Sicht sehr stark. Kann natürlich auch sein, dass mir das Hintergrundwissen fehlt, um die Details bei den Unterschieden genau herausarbeiten zu können. Anschließend wurde noch auf den Windows Phone Marketplace eingegangen und erläutert, dass Apps von Microsoft auf Funktionalität geprüft werden. Wichtig ist jedenfalls zu wissen, dass die Prüfung der App ca. 3 Tage in Anspruch nehmen kann. Im Marketplace selbst lassen sich auch Updates für Anwendungen bereitstellen oder eine Anwendung auch für andere Länder bereitstellen. Es wäre somit auch möglich, unterschiedliche Anwendungen für unterschiedliche Länder bereitzustellen, um beispielsweise die lokale Gesetzgebung zu berücksichtigen. Zusätzlich findet man dort eine Übersicht über die Einnahmen, die über Apps generiert worden sind. Als Hinweis am Rande: Microsoft behält, analog zu Apple, 30% des Umsatzes ein. Davon müsst ihr dann noch Steuern abziehen, die das Finanzamt in Deutschland haben will.

Session 4: HTML5 Single Page Javascript Applications

Und endlich: im Raum "Hannover" gibt es wieder ein Thema, wo ich mich zuhause fühle. Daniel Fisher ist diesmal der Sessionleiter. Zunächst mal klingt alles relativ simpel: Eine einzige HTML-Seite, sonstige Daten werden über Javascript dynamisch nachgeladen. Des Weiteren ist die Webseite aber über die Browserbuttons ansprechbar, d.h. die Inhalte müssen immer in der richtigen Weise ausgetauscht werden, wenn man beispielsweise auf den im Browser integrierten Zurück-Knopf klickt. Ein sehr interessanter Vortrag, der auch hier sehr tief ins Detail ging. Sehr interessant ist natürlich auch, dass die Visual Studio IDE seit kurzem auch Javascript mit Autocomplete unterstützt. Ebenfalls interessant ist, dass Microsoft mit jQuery eine Javascript-Bibliothek, die unter einer OpenSource-Lizenz veröffentlicht wurde, mitliefert.

Session 5: Bidirektionale Real-Time-Kommunikation mit WebSockets

Ui, jetzt wird es sogar richtig spannend! Das Thema, das ich seit einiger Zeit immer wieder verfolge, bekommt nun sogar einen eigenen Track von Christian Weyer. Doch was sind WebSockets und wozu sind sie gut? Wenn eine Webapplikation (vgl. Session 4) mit einem Server kommuniziert, so geht die Kommunikationsanfrage immer vom Client (Request) aus und wird vom Server beantwortet (Response). Das hat natürlich den gewaltigen Nachteil, dass man bei "Realtime"-Applikationen, also Anwendungen, die nahezu in Echtzeit Daten ausliefern, wie beispielsweise die CPU-Auslastung auf dem Server, ständig Anfragen an den Server schicken, ob neue Daten verfügbar sind. Alternativ kann der Server eine einzige Verbindung lange geöffnet halten und regelmäßig <script>-Tags, die mit einem \0 terminiert sind, an den Client schicken und dort direkt ausgeführt sowie interpretiert werden. Eine weitere Alternative wäre, die Daten über Long Polling einmal zu senden, die Datenverbindung aber nicht zu schließen, sondern erst dann, wenn der Server keine weiteren Daten mehr liefern kann bzw. wenn das TCP-Timeout eintritt. Der Client eröffnet dann sofort eine neue Verbindung und kann wieder Daten empfangen. Die sauberste Lösung jedoch versprechen WebSockets: es ist damit quasi möglich ein HTTP-Paket an den Server zu schicken, das jedoch explizit geflaggt ist, d.h. vom Server anders verarbeitet werden kann und womit direkt Byte-Streams versendet werden können. Javascript kann diese Daten auf der anderen Seite empfangen und in ein JSON-Objekt konvertieren, womit eine vernünftige Kommunikation gewährleistet ist. Ein Beispiel wäre eine Zeichenanwendung, wo zwei oder mehr Teilnehmer gemeinsam über das Internet eine Grafik malen können, ohne dass eine nennenswerte Zeitverzögerung eintritt. Allerdings unterstützen die Browser alle unterschiedliche Versionen von WebSockets, sodass hier noch kein einheitlicher Standard bereitsteht.

.NET 4.5 wird in Zukunft RSignal implementieren, ein Framework, das die unterschiedlichen Kommunikationsmöglichkeiten, die ich oben genannt habe, der Reihe nach abklopft und die höchstmögliche Kommunikationsform wählt. Damit wird sichergestellt, dass auf jeden Fall eine stabile Kommunikation zustande kommt, gleichzeitig wird der Server nicht durch eine zu hohe Ressourcenbelastung gefährdet. Und warum machen wir den Spaß? Damit der Manager auf dem Golfplatz live seine Serverauslastung prüfen und überwachen kann und das alles mit dem "Datsch"-Display. Es ist wichtig, in der Anwendungsprogrammierung auch das Web im Auge zu behalten, da die Webtechnologien auch auf reguläre, nativ laufende Anwendungen ihre Auswirkungen hat. Kommunikationswege können damit vereinfacht und standardisiert werden. Dies vereinfach nicht nur die Entwicklung, sondern auch die Wartung und Pflege. Auch ist die Integration in bestehende Infrastruktur besser, da beispielsweise keine zusätzlichen Ports geöffnet werden müssen, da WebSockets die normalen HTTP-Ports mitbenutzen.

Mittwoch, 29.02.2012: Tag 2 - BASTA-Konferenz  

Session 1: .NET 4.5 Web API

Was ist der Sinn von Informationen? In der Regel, dass sie möglichst weit verbreitet werden. Wenn man sich eine typische Anwendung ansieht, so folgt diese einer klaren Struktur, oft wurde sie auch nur für eine Zielplattform entwickelt. Im Zeitalter von Apps ist dies allerdings nicht mehr nützlich, da der Großteil der Benutzer die Anwendung nicht mobil nutzen kann. Folglich ist es empfehlenswert, Datenstrukturen über Webservices abrufbar zu machen. Sehr bekannte Vertreter sind SOAP und REST. Beide setzen in der Regel auf XML, wobei SOAP deutlich komplexere XML-Konstrukte erstellt. REST jedoch setzt nicht direkt auf einen Standard, die Repräsentation kann sowohl in XML oder HTML, als auch in der Javascript Object Notation (JSON) erfolgen. Gerade letzteres ist für die Verwendung in Javascript-Applikationen sehr vorteilhaft, da die Daten bereits als serialisiertes Javascript-Objekt zurückgegeben werden. Ein weit verbreitetes Ziel von REST ist die Leichtigkeit, mit der Anwendungen kommunizieren. Zunächst wurden unterschiedliche URLs in einer C#-Anwendung definiert, die dann über die HTTP-Methoden GET und POST angesteuert werden können. Anschließend wurde über Javascript direkt auf diese Methoden eine JSON-Anfrage gestartet und die Daten weiter ausgewertet. Als Entwickler möchte man allerdings auch nicht für jede Plattform eine eigenständige Anwendung entwickeln. Dank der Software Phonegap ist dies auch nicht zwingend notwendig: man entwickelt eine HTML5-Anwendung mit CSS und Javascript, die im Browser ausführbar ist. Phonegap ist quasi ein Wrapper, der eine eigene Web-View mitbringt und die Anwendung lokal auf einem Smartphone ausführt. Die Web-View wird mit den ganzen Dateien in eine App kompiliert, sodass man diese direkt in die App-Stores von Apple, Android, Blackberry und Microsoft einstellen kann. Die Nutzer können die Anwendung direkt auf Ihre Smartphones installieren oder direkt im Browser nutzen. Die Quelle für die Anwendung ist relativ egal, wichtig ist lediglich, dass eine Internet-Verbindung besteht und Daten vom REST-Service abgerufen werden können. Auch ist es durch einen solchen Service relativ einfach, nachträglich einen weiteren Client, beispielsweise in Silverlight, zu implementieren, da diese auch auf diesen Service zugreift und die Daten anzeigt. Die komplette Logik kann serverseitig ausgeführt werden, während die Anzeige vollständig lokal generiert wird. Ich möchte an dieser Stelle anmerken, dass ich derzeit auch beruflich genau damit arbeite und ich kann diese Technik wirklich sehr empfehlen, solange die Anwendung weitgehend statisch sein soll, d.h. keine Animationen o.ä. dargestellt werden sollen.

Session 2: Javascript Q&A

Ja, was soll ich sagen, schon wieder Javascript. Eigentlich war hier eine Session mit Mario Meir-Huber geplant, der aber krankheitsbedingt kurzfristig absagen musste. Dafür sprang Daniel Fisher mit zwei weiteren engagierten Javascript-Gurus ein und beantwortete unsere Fragen. Hier wurde konkret, m.E. auch für Anfänger anschaulich, vorgeführt, wie man relativ einfach JSON-Daten von einem selbstgeschriebenen Webservice abruft. Dies ähnelt zwar sehr stark Session 1 dieses Tages, allerdings lag der Fokus bei Session 1 mehr auf dem grundsätzlichen Konzept, während bei dieser Session die Umsetzung in Javascript ausführlich behandelt wurde. Auch gab es auf meine Anfrage hin hinterher Buchempfehlungen zu Javascript. Wichtigste Kernaussage jedoch: Javascript ist nicht schwer. Javascript ist nur ein wenig anders. Und es ist halt dynamischer, d.h. man muss etwas mehr aufpassen. Dies kann durchaus eine Hürde bei den ersten Gehversuchen sein, man sollte sich aber nicht davon entmutigen lassen, immerhin hat die Sprache auch schon mehr als 15 Jahre auf dem Buckel.

Session 3: Scrum vs. Kanban

Nachdem ich so im Javascript-Fieber war, war ich schon fast enttäuscht, dass im letzten Track keine Session war, die Javascript enthielt. Daher habe ich mich, auch aufgrund meines Wirtschaftsinformatik-Studiums, mal in die Session Scrum vs. Kanban gesetzt. Allerdings gab es dort sehr viel Theorie, unterm Strich kam es für mich, der bislang noch nicht auf den agilen Vorgehensmodellzug aufgesprungen ist, wie eine Mischung aus Scrum, Wasserfall und sehr spontanen Entscheidungen, die abhängig von der Workload getroffen werden, vor. Ich werde mir das Thema aber auf jeden Fall nochmal ansehen, da mir Andreas Hafellner sehr kompetent vorkam und auch den Eindruck erweckte, dass sie damit einen großen Fortschritt in Ihren Prozessen erreicht haben, die die Kunden- und Mitarbeiterzufriedenheit stark gesteigert haben.

BASTA-Lounge

Die BASTA-Lounge war dieses Jahr eine Premiere. Gedacht ist diese als Austauschbasis zwischen den Sessionleitern und den Teilnehmern, um über Grundsatzfragen zu philosophieren, ein wenig Code zu hacken oder einfach nochmal nett bei einem Bierchen zu plaudern. Das ganze war Tischeweise organisiert. Ich brauche euch ja nicht sagen, an welchem Tisch ich gesessen habe, das wisst ihr sicher schon ;-) Jedenfalls hat der Software und Support Verlag, der die BASTA veranstaltet, als die Zeitschrift .NET präsentiert - als Überraschung zum zehnjährigen DOT.NET-Jubiläum wurde diese umgetauft in "windows .developer". Im Laufe des Abends habe ich einige interessante Gespräche geführt, die teils pragmatisch, teils aber auch sehr enthusiastisch geprägt waren. Jedenfalls habe ich mich mehrfach verquatscht, weil es einfach so spannend war und drei Züge verpasst. Gegen 21:30 Uhr habe ich mich dann zum Bahnhof begeben.

Fazit  

Wahnsinn!

Ich habe ja schon einige Workshops und Meetings besucht, aber die BASTA war bislang der Höhepunkt auf meiner Reise durch Business Conferences. Ich bin sehr positiv überrascht, dass soviele Sessions perfekt auf mein berufliches Tätigkeitsfeld gepasst haben. Und das alles vor dem Hintergrund der nativen Anwendungsentwicklung. Microsoft versteht es, Webentwickler dort abzuholen und auf den Windows 8-Zug aufspringen zu lassen. Umgekehrt ist es für Microsoft aber auch notwendig, die Webentwickler zu integrieren, um plattformübergreifende Anwendungen zu ermöglichen und die Applikationsentwicklung für das Metro-UI voran zu treiben. Durch Javascript wird Microsoft dies nach meiner Einschätzung schaffen, da sich ein Web-Entwickler keine komplett neue Sprache, sondern lediglich den Umgang mit den neuen Libraries erlernen muss.

Zur Info: Windows 8 Beta und die Visual Studio 11 Beta sind ab sofort verfügbar

Vor diesem Hintergrund möchte ich mich nochmals bei allen, die mir die Teilnahme ermöglicht haben, ganz herzlich für die tollen zwei Tage bedanken!

Mit freundlichen Grüßen


Reiner Kempkes

PS: Ein Schmankerl zum Schluss:
Das Buffet im Maritim-Hotel war genial. Die Organisation vor Ort war großartig. Der Service hat sich größte Mühe gegeben: ich habe mehrfach bewusst eine geleerte Flasche irgendwo abgestellt und gewartet, bis die weggeräumt wurde. Das höchste der Gefühle waren drei Minuten, länger konnte die leere Flasche nicht alleine verbringen. ;-)

Ihre Meinung  

Falls Sie Fragen zu diesem Artikel haben oder Ihre Erfahrung mit anderen Nutzern austauschen möchten, dann teilen Sie uns diese bitte in einem der unten vorhandenen Themen oder über einen neuen Beitrag mit. Hierzu können sie einfach einen Beitrag in einem zum Thema passenden Forum anlegen, welcher automatisch mit dieser Seite verknüpft wird.