Wie sollte es anders sein, auch für den Donnerstag hatte ich mir das volle Programm vorgenommen:

  1. AngularJS mit TypeScript programmieren
  2. TFS 2015 – Die nächste Generation im Überblick
  3. The Transition from Application to Infrastructure
  4. App Marketing: Nobody loves my App
  5. Wiederverwendbare JavaScript-Komponenten mit Web Components und AngularJS 2.0 – Deep Dive mit Live-Coding
  6. Neue Möglichkeiten, neue Gefahren – HTML5- und JavaScript-Security

Den ausgewählten Sessions sieht man an, dass ich wohl immer noch nicht genug von Angular und Cross-Platform hatte. 😉
Ja, das Thema beschäftigt mich aktuell sehr, da kann man sich ja nicht genug umhören.

AngularJS mit TypeScript programmieren

Entgegen der Ankündigung anderer Dozenten, dass es keine Slides, nur Code gibt, zieht Rainer Stropek dies ohne vorherige Ankündigung durch. Zur Entwicklung nutzt er einen kleinen NodeJS Web-Server (express).
Anschließend initialisiert er sein Arbeitsverzeichnis mit dem Kommando npm init, was die Datei package.json erstellt, und installiert dann mit npm install <package> –save die für seine Demo nötigen Pakete angular, angular-mocks, angular-route, bootstrap und jquery. Wobei jquery hier nur mit installiert wird, weil es von bootstrap gebraucht wird.
Nach Rainer Stropeks Meinung reicht npm vollkommen aus – weitere Package Manager wie bower oder ähnliche sind nicht erforderlich.
So weit zur Einrichtung eines grundlegenden Webs, jetzt kommen wir aber auch zum eigentlichen Thema des Vortrags, nämlich zu TypeScript. Um die großen Vorteile von TypeScript nutzen zu können, nämlich IntelliSense und Typ-Prüfung, müssen wir uns die Definitionen der Bibliotheken besorgen. Da diese ursprünglich ja in JavaScript geschrieben sind, und es hier keine Beschreibung gibt, hat die Community unter DefinetelyTyped auf github die Definitionen von sehr sehr vielen JavaScript-Bibliotheken zusammengestellt und die meisten der Funktionen auch gut dokumentiert.
Ruft man im Root seines Arbeitsverzeichnisses den Befehl tsd query <packagename> auf, so stellt man schnell fest, ob die gesuchten Definitionen existieren. Mit dem Zusatz –action install –save zu dem vorherigen Befehl können die Definitionen dann installiert und abgespeichert werden. Später werden diese im Code-File dann mit /// <reference path=“<packagename>.d.ts“ /> eingebunden. Hier gab Rainer noch den wichtigen Hinweis, dass das node_modules und das typings Verzeichnis nicht in die Quellcode-Verwaltung eingecheckt werden sollten.
Ab diesem Punkt ging es dann in die Tiefen von Typed-Angular, wo TypeScript in Kombination mit den passenden Typings seine Stärken voll ausspielen kann. Da ich zu diesem Thema jedoch einen eigenen Artikel verfassen möchte, will ich hier noch nicht zu viel vorweg nehmen.

TFS 2015 – Die nächste Generation im Überblick

Da in meinen Augen die eigentliche Entwicklung nur einen Teil des Ganzen ausmacht und das Drum herum, wie Build, Tests und Deployment oft viel zu wenig beachtet werden, durfte auch der Team Foundation Server auf meiner Agenda nicht fehlen. Die Session wurde von Christian Binder und Neno Loje gestaltet, die sich sehr gut ergänzten jedoch vor lauter Neuerungen gar nicht richtig wussten, wie sie alles in den Vortrag packen sollten.

Zunächst stellten die beiden die Unterschiede zwischen Team Foundation Server und TFS Online heraus, wobei letztere, die Cloud-Version, ständig neue Features erhält, sich ständig ändert und weiter entwickelt. Hierzu gibt es eine Feature Timeline im Netz (https://www.visualstudio.com/en-us/news/release-archive-vso.aspx), aus der auch ersichtlich ist, wann welches Feature es in die On-Premise Version des TFS schafft.

Sie teilten den Vortrag in die Bereiche Planning Tools + Collaboration, Source Code Collaboration, Build Automation, Release Management, Application Insights und Open/Cross-Platform auf. Zunächst wurden das Kanban Board und die Backlog Item List demonstriert sowie die umfangreichen neuen Konfigurationsmöglichkeiten gezeigt. Anschließend war der verbesserte Git Support das Thema und es gab eine Demonstration von lokalem Branching mit Git, anschließendem Publish und danach dann ein entsprechender Pull-Request und das Löschen des Branches.
Im Weiteren wechselte dann das Thema zur neuen Build Engine. Die Build-Agents basieren hier auf NodeJS und sind damit plattformübergreifend einsetzbar. Die Engine zielt mehr auf Continuous Integration und die Build Tasks gibt es auf Github als Vorlagen. Damit wird das System auch in diesem Bereich wesentlich agiler als bisher. Die alte Build Engine wird zukünftig nicht mehr weitergeführt.

Im nächsten Teilbereich, dem Package Management Service wurden weitere neue Möglichkeiten zur Verwaltung von binären Paketen erläutert. Auch diese Funktionalität wird plattformübergreifend lauffähig sein und Systeme wie npm, bower und ähnliche unterstützen. So wird es auch einfach möglich, während des Build die passenden Pakete herunterzuladen. Zur Visualisierung von Kennzahlen zum Programmcode wird weiterhin SonarQube eine Integration in TFS erhalten (weitere Details unter http://aka.ms/sonarqubeintegration). Auch das Release Management wird vollständig in den TFS integriert, sodass zukünftig für Continuous Delivery Ansätze nicht mehr der Build ein Deployment ausführen muss, sondern dies in einem passenden System ermöglicht wird.
Zum Abschluss wurden dann noch zwei weitere Funktionen angesprochen, nämlich die Insights, die Daten zur Verwendung von Apps für tiefe Analysen in der Cloud sammeln und die Extensibility über REST und Service Hooks, die sich zukünftig durch das ganze System bis zum Web Access ziehen wird.

Der Vortrag hat gezeigt, dass Microsoft nicht nur auf der .Net Schiene Vollgas gibt, sondern auch in allen Bereichen um die Entwicklung herum sehr viel passiert.

The Transition from Application to Infrastructure

Auch die letzte Keynote der Konferenz war nicht von reiner Entwicklung geprägt, sondern von den Themen nach der eigentlichen Programmierung. Paul Stack begann hier mit seiner Meinung, dass Software-Entwicklung einfach ist – Jemand hat eine Idee, die Anforderungen werden zusammen getragen, es wird programmiert, getestet … und irgendwann ist das Leben der Software zu Ende. Zumindest sollte es so sein, denn jede Software sollte einen Lebenszyklus haben und da ist Entwicklung nur der Start.
Doch wie kommt der Code zu den Benutzern? Hier propagierte Paul die Optimierung der Pipeline bis zur Auslieferung und damit den Ansatz der Continuous Delivery. Denn seiner Meinung nach denken die meisten Entwickler nicht über die Auslieferung nach. Seine Frage an das Plenum war, wodurch sich ein Bugfix von einem Feature unterscheidet, jedoch ein Bugfix meist sehr schnell entwickelt und ausgerollt wird, ein Feature jedoch oft sehr lange Release-Zyklen durchläuft.

In seiner Ansprache schwärmte er von Continuous Delivery, was einigen Firmen bereits enorme Möglichkeiten bei der Weiterentwicklung ihrer Software bietet. Seiner Meinung nach sollte jedem, der an einem System mitarbeitet, klar sein dass alle ein Team sind und jeder sollte Verantwortung für die Gesundheit des gesamten Systems übernehmen. Denn am Ende arbeiten alle, um Geld zu verdienen und Geld wird dann verdient, wenn das Produkt online ist und produktiv läuft.

App Marketing: Nobody loves my App

Nach dem sehr guten Vortrag von Gregor Biswanger am Mittwoch, wollte ich auch seinen Vortrag über App Marketing nicht verpassen.

Zum Einstieg gab es wieder eine Vorstellung, die dieses Mal jedoch um einiges kürzer ausfiel. Dann stieg er auch direkt ins Thema ein und erklärte, dass ein zentraler Baustein des App Marketings in der Analyse des Benutzerverhaltens liegt. Wichtig ist seiner Meinung nach auch, sich Ziele zu setzen – hier vor allem die Motivation für die Nutzung, die Kundenbindung und die möglichst höhe Verbreitung der App. Hierfür gab er seinen Zuhörern vier Strategien an die Hand, nämlich eine Marke aufbauen, einen Brand setzen, Gamification und Content Marketing. Er erklärte die psychologische Verbindung zwischen der Tatsache, dass man von jemandem etwas kostenlos erhalten hat und der innerlichen Verpflichtung dann auch etwas zurück zu geben, was man unter anderem nutzen kann, um Interesse zu wecken und andere eigene Apps bekannt zu machen.
Als einen sehr wichtigen Punkt wies er dann auf die Gamification hin. Das Spielen ist anscheinend in jedem Lebewesen tief verankert, lässt sich nutzen und wird von vielen Firmen auch bereits erfolgreich ausgenutzt. So lässt sich über die Implementierung spieltypischer Elemente Wunschverhalten festlegen und Steuern. Möchte man beispielsweise das regelmäßige Nutzen der App erreichen, so kann man hierfür Punkte vergeben und bei bestimmten, vorher festgelegten Punkteständen (diese sollen auf jeden Fall auch für den Nutzer einsehbar sein) dann Belohnungen freischalten.
Im nächsten Schritt erklärte Gregor, dass heute niemand mehr „Push“ Werbung haben will. Die Verbreitung von Ad-Blockern in Browsern nimmt zu, die Werbung im TV wird per Timeshifting umgangen und jeder ist davon nur noch genervt. Daher sollte man das Thema Werbung subtiler angehen und lieber andere Ansätze nutzen. Hierfür bietet sich Content Marketing an. Am Beispiel einer Nichtraucher-App erklärte er, dass es viel mehr bringt, wenn man den potentiellen Kunden regelmäßig gute Tipps gibt, wie sie mit dem Rauchen aufhören können. Damit triggert man wieder den psychologischen Aspekt, dass jemand etwas kostenlos erhält und generiert Interesse. Für eine solche Strategie eigenen sich soziale Medien hervorragend. Eine gute Präsenz auf Youtube, Twitter, Facebook und Co mit interessanten Inhalten generiert Interesse und ermöglicht das unaufdringliche Leiten des Benutzers zu den eigentlichen Angeboten.
Als absoluten Top-Punkt erklärte er, dass jeder Mensch Ich-zentriert ist und eine passende Strategie hierzu eigentlich immer zieht. Die Kombination aus Story-Telling und Identifikation des Benutzers mit der Geschichte weckt Emotionen und Aufmerksamkeit. Auch hier ist die subtile Einbringung des eigenen Produkts wichtig. So sollten 70-80% der Geschichte oder dem Nutzen vorbehalten sein und nur 20-30% auf das eigentliche Produkt fokussieren.

Wiederverwendbare JavaScript-Komponenten mit Web Components und AngularJS 2.0 – Deep Dive mit Live-Coding

Manfred Steyer begann seinen Vortrag mit einer kurzen Einleitung zu Angular 2.0 und erklärte die Konzepte hinter Angular. Er vergaß auch nicht zu erwähnen, dass Angular nur eines von sehr vielen Single Page Application-Frameworks ist, jedoch eines, das sich bereits sehr lange hält und das inzwischen eine sehr große Community hinter sich versammelt hat. Wichtig bei einer Angular 2 App ist, dass diese immer wie ein Baum aufgebaut ist. Die Wurzel ist das zentrale App-Element, dieses enthält Komponenten, die wieder Komponenten enthalten und so weiter. Angular 2 wurde im Vergleich zu Angular wesentlich vereinfacht und die Zahl der unterschiedlichen Komponenten reduziert.
Eigentlich sollten Angular 2 Komponenten auf ein Element des kommenden Standards aufsetzen, nämlich Web Components. Da sich der Standard hier jedoch verzögert und sich damit auch Angular 2 stark verschoben hätte, entschied sich das Team, die Angular 2 Components nah am zu erwartenden Standard aufzubauen, jedoch zunächst ein eigenes Konzept zu etablieren, das später jedoch mit überschaubarem Aufwand auf Web Components umgestellt werden kann.
Damit ging es auch schon an den Code. Zunächst erklärte Manfred den üblichen Aufbau einer Angular 2 Komponenten mit den @Component und @View Bausteinen bzw. Attributen und verglich dies mit C#. Dann ging er unter anderem auf die geänderte Syntax beim Databinding ein und erklärte, dass unter Angular 2 prinzipiell kein Two-Way-Databinding mehr existiert – was bei AngularJS zum Standard gehörte und sehr häufig eingesetzt wurde. Dies hat unter anderem Performance-Gründe und vereinfacht auch das Verständnis des Programmflusses. In einem HTML Element kann nun mit einer neuen Syntax ein Property Binding durchgeführt werden: <input type=“checkbox“ [checked]=“checkedState“> wobei checkedState hier die Eigenschaft der dahinter liegenden Klasse referenziert und die checked Eigenschaft des input Elements damit befüllt wird. Umgekehrt lassen sich natürlich auch Events einbinden. So kann das Beispiel folgendermaßen erweitert werden: <input type=“checkbox“ [checked]=“checkedState“ (click)=“changeState()“>. Die Syntax ist hier für bisherige Angular-Nutzer oder auch HTML-Entwickler zwar sehr gewöhnungsbedürftig, jedoch ist sie HTML-konform und in meinen Augen auch sprechend.
Um nun trotzdem ein Two-Way-Databindung zu ermöglichen gibt es hier etwas Syntax-Zucker – man kann die Syntax einfach kombinieren und erhält dann folgenden Aufbau: <input type=“checkbox“ [checked]=“checkedState“ (checked)=“checkedState=$event“> was sich noch einfacher als <input type=“checkbox“ [(checked)]=“checkedState“> schreiben lässt. $event ist hier eine Pseudo-Variable, die das ausgelöste Event enthält.

Die Session ging noch um einiges weiter in die Tiefe, was jedoch hier den Rahmen sprengen würde. Hierzu werdet Ihr in den nächsten Wochen hier jedoch noch mehr lesen.

Neue Möglichkeiten, neue Gefahren – HTML5- und JavaScript-Security

Zum Abschluss der diesjährigen Basta! gab es nur noch zwei Sessions parallel. Christian Wenz hatte nicht nur das Glück einen der ersten Vorträge zu halten, sondern durfte außerdem auch einen der letzten präsentieren.
Zunächst gab es eine kurze Einführung zu JavaScript, das seiner Aussage nach in 10 Tagen aus der Taufe gehoben wurde und bereits seit 1995 existiert. Glücklicherweise gab es in diesen 10 Tagen auch ein paar Minuten Zeit für Überlegungen zu Security und dieses Sicherheitskonzept bildet bis heute die Grundlage für JavaScript.
Einige der größten Probleme bei JavaScript bestehen darin, dass Funktionen und Variablen global sind und sich damit ins Gehege kommen können. Außerdem laufen alle JS Dateien im gleichen Namensraum und damit auch im selben Sicherheitskontext, was besonders beim Einbinden externer Scripts problematisch sein kann.
Gefährlich im Bereich der Programmierung sind vor allem: eval(), XHR, Redirects und etwas eher unscheinbares, nämlich Tastaturereignisse. In Kombination mit einer Cross Site Request Forgery (CSRF) Lücke wäre es nämlich möglich, mit einem eingeschleusten JavaScript alle Tastatureingaben abzufangen und an eine andere Seite weiter zu geben. Was dann einem einfachen Web-Keylogger entspräche.

Glücklicherweise – und hier kommen wir jetzt wieder auf die paar Minuten aus 1995 zurück – hat JavaScript eine Same Origin Policy (SOP). Diese untersagt es, auf Objekte zuzugreifen, die nicht vom selben Ursprung stammen, also zum Beispiel auf einer anderen Domain liegen. Doch dies behindert auch häufig gewollte Aktionen. Liegt zum Beispiel die Seite auf www.beispiel-domain.de und eine Api, die für die Anwendung benötigt wird, auf api.beispiel-domain.de, so wird der Zugriff nicht funktionieren. Daher gibt es auch seit jeher – nicht nur von Hackern – den Versuch, die SOP zu umgehen. Hierzu stellte Christian einige gängige Ansätze vor. JSONP ist hier ein recht bekannter jedoch umständlicher und unschöner Ansatz, die Browser Messaging API ist eine eingebaute Browser-Funktionalität, jedoch eher unbekannt. Auch CORS, das über den http-Header funktioniert und WebSockets sind hier gängig.
Ein neuer Ansatz in diesem Bereich ist Content Security Policy. Hier wird bereits in der Seite eingestellt, was erlaubt ist und was nicht. Leider wird dieser Ansatz noch nicht von allen Browsern unterstützt und hat auch noch weitere Nachteile. So wird bei aktivierter Content Security Policy mit entsprechender Restriktion auch alles Inline-JavaScript und auch Inline-Styles deaktiviert, was bei sehr vielen Web-Seiten dazu führen dürfte, dass diese nicht mehr nutzbar sind. Um seine Seiten hier zu testen und erstmal zu prüfen, ob Content Security Policy eine Möglichkeit ist, kann über einen Parameter eingestellt werden, dass erst einmal nur reportet wird, was geblockt werden würde. So kann man auch Schritt für Schritt seine Seiten darauf umstellen.
Zum Abschluss gab Christian seinen Zuhörern noch den Tipp mit, dass das inzwischen gerne eingesetzte Local Storage die Daten auf dem Client ungeschützt ablegt und diese damit für jeden einsehbar sind.

 

Fazit

Der Besuch der Basta! war für mich ein voller Erfolg. Viele tolle Speaker mit super Sessions, sehr viele Information und Eindrücke, die erst einmal verarbeitet werden müssen. So viel geballten Input bekommt man nicht oft und ich kann jedem nur empfehlen, auch mal einer der Basta!-Konferenzen einen Besuch abzustatten.

Wir sehen uns dann auf der nächsten Basta! 😉

 

Lest doch auch meine anderen Berichte zur Basta! 2015, hier sind die Links dazu:

Dienstag auf der Basta!

Basta! es ist Mittwoch